Yes, I saw. Thank you!!
Yours is merged. Thanks very much! Just updating my branch now
I'm opting for straight code for the first pass, and then I'll add more complex instructions. I'm breaking from the paper in that I want it to compile in-line. So Rather than sketching api's and later filling it out, instead just creating them and explaining how they suit the purpose.
(Not sure if this is the best approach, but the papers approach is definitely not very friendly to repl style development)
I honestly can’t remember how the paper structures the example. Is it not a direct translation?
Also, could you please run
scalafmt on your change? And there are a couple of instances where two words do not have a space between them in the reindeer description (“themto”, “is both”, etc). Thanks so much!
I’ll try to get a chance to look at the hanging today
I am also awful at it
Thanks, just saw you added it to your PR :)
@ChristopherDavenport so sorry, I added a comment on the PR - I think the standard seems to be a scalameta implementation of the formatter, which seems to give different results (I think that’s why you got so many changes when you ran it). I’m so sorry to be a pain but would you mind adding that one instead and running the formatter again. I’ve added the import line you need in a comment on the PR so should only take a minute
Again, my bad for using a global plugin. I should have committed a project plugin ages ago
Technically as two commands.
Awesome. I’ll merge asap this evening. Many thanks again! :)
but that was just 5 minutes of debugging
and I’m pretty sure that logic is already dodgy - we’re not tracking which txns we’ve already retried or which ones have already succeeded
just haven’t had time yet to think through what the behaviour should even be, never mind how to implement it
I once automated Travis to just do that if the user forgot, but it annoyed people to have Travis append to their PRs.
Hey @ChristopherDavenport I actually merged some of my changes as they fix some definite bugs around retries and they don’t always lock up when running the santa claus problem. I’ve also pushed to a branch
debug-santa-claus that you might want to look at. At the moment, all it has is two print statements looping in fibers but the interesting thing is that they keep printing even when the santa problem stops so I don’t think we have thread deadlock. It looks to me like we aren’t correctly identifying/tracking opporunities to retry txns. The print shows that it gets stuck in a state where there are some pending transactions that never get retried
It looks to me like we aren’t correctly identifying/tracking opporunities to retry txns
I had exactly the same issue in my STM, btw, and it was due to two threads acting on retries in parallel, one beginning a retry the very same moment another added one on top.
- Everything just worked in a single thread setting
- I ended up using a transaction ID to check "if a last-transaction-written has changed for any of the variables, retry immediately" (though it sounds easier than it was to actually fix, it took me several attempts)
Also a big fan of better monadic for btw :)
You can also probably use
STM.synchronized { ... } instead of semaphore for easy scala-js compatibility (synchronized does nothing on SJS, but using Java semaphore causes linking errors)