Issue

In commit 6715e3a, there is a new test which runs the bubble sort as a set of goroutines instead of a sequence of function calls. It results in errors that does not occur in non-concurrent code. They seem to vary seemingly randomly meaning it may be a race condition in more than one area.

Solution

The solution may be to add a lock to the cache file and project file.

err := syscall.Flock(int(file.Fd()), syscall.LOCK_EX)

To reduce clutter in a user's workspace, and to reduce the amount of boilerplate, being able to produce the data file in the .jewl directory would be a nice streamline of passing the data from jewl-go to Jewl.jl

Jewl.jl could also update it's API to use GetProject instead of Load so that it checks for a .jewl directory, and gets whatever project is in there. This would require some more changes on Jewl.jl's end but this could help reduce clutter and boilerplate for users.

A lot of stuff that should be in their own files are crammed into recorder.go such as

• RecorderConfig
• RecorderCache

Also, there is some housekeeping to do within functions of recorder.go such as simplifying and homogenizing the header and frame creation operations such that

• All header operations are in their own functions
• Operations related to Frames are given their own functions

Note: this is not to follow clean code this is just so that maintenance is easier

We need to stop deleting .jewl for issue #7 to work. It can also be used by configs to generate other stuff there if needed (such as log files).

Note: This should be done just before 1.0-rewrite is merged to main

Issue

Nobody knows how to use my library; but that is intentional as I am still developing it, however, the overall structure is pretty much worked out. It's all just tweaks and improvements from here on out.

Conclusion

A separate wiki shall be created to explain how to use the library with Jewl.jl

Just like in Issue #2, we need to decouple the RecorderCache from Msgpack such that user/config schema can customize how the cache is marshalled/demarshalled.

A point of contention I have about this is how useful it would be to customize the RecordeCache since that is an internal function, and not something that users would likely need to customize. However, I expect that the cache may be expanded upon in the future, so I will keep this here in the event that it is need.

This may be closed by the time the 1.0-rewrite branch is finished without this being implemented. If it turns out that this is not really needed, we can close it. If we end up reversing that decision, we can always reopen this issue.

Recorder should be independent of the storage method/protocol used to store results, with the data format being decided only by the concrete implementation of the RecorderConfig.

When calling a function multiple times, it will just override the current index in the header.

Solution
Change the header from map[string]int to map[string][]int and append the frame index to the function's header entry.