hmm, this bit me... can't use each within an afn because each uses afn internally, and it leaks the 'self binding into the body. I changed it to use an rfn with a uniq name and it works.
Are you going to fix this and other small bugs in the tar or are we just going to patch them on the fly? If the plan is to patch maybe we need a thread with patches - so people can get up and running fast.
Personally I think using Anarki is fast, straightforward and community friendly... So that may be my choice in the end when arc3/mz372 has some time to stabilize.
Is there a reason you are avoiding source control?
Just giving it a preliminary look over, it seems like you changed 'set to 'assign. Any reason for this in particular, pg? It seems like it changes a lot of code, and as 'set is fairly common, it kind of goes against the philosophy of short names for common operators.
It's not so many uses that it's impossible to update. Many if not most of these uses could admittedly be replaced with '=, and arguably this was the correct thing to do in the first place. It just seems like an odd decision, and I'm wondering if there's any specific reason for it.
In my opinion "set" is a better name for what "assert" used to do, and I think "set" was available since it was being used for a low-level operation for which in user code "=" is a better and shorter name.
"I worry about releasing it, because I don't want there to be forces pushing the language to stop changing. Once you release something and people start to build stuff on top of it, you start to feel you shouldn't change things. So we're giving notice in advance that we're going to keep acting as if we were the only users. We'll change stuff without thinking about what it might break, and we won't even keep track of the changes."
Yeah, I didn't try to suppress error messages because I'm curious how often it actually finds something.
When you say blank, do you mean completely blank, or just no stories? Because caching means that stories take a minute to show up to nonlogged-in users.
Ok now it's not my environment. I have made no changes just the arc3 files and mzscheme372.
* I have only 3 posts and 3 comments, if I log in as admin and keep hitting the comments link - not crazily like, but right after the page load completes - about the 10th time or so the hyperlinks change format then the whole forum get locked and goes blank.
I am using mac osx.
After about an hour I'm getting the impression the forum is glitchy. There's just a bunch of quirky behavior like the above (pages are slower to load - page painting is noticeable.... etc etc)
I've already pushed arc3.tar to anarki's "official" branch and merged the changes into "stable". Merging them into the master branch may prove more difficult and tedious, but I think it can be done.
Hmm, as an interim step you could make a macro called "set" which you loaded after Arc and before Anarki. That way you could try out Anarki with arc3 and get things working before going on to do all the tedious renaming.
The trouble is, I wouldn't know where to start with testing anarki as a whole. There's just too many different parts, because anarki has so many things:
- Forks and compilers (arc2c, arc-f)
- Pet projects and examples (LightMakesRight, wiki-arc)
- Extensions to arc (help strings, function signatures, compilation)
- Bugfixes to arc (making 'atomic work even on exception throw)
I think I can probably update the latter three, but the former will just have to rely on whoever contributed them. Perhaps it's time for a new anarki - throw out the unmaintained cruft and try and separate changes to core arc functionality (bugfixes, extensions) from additions/libraries from standalone projects.
From my cursory look, pg has fixed many if not most of the core issues that anarki resolved. (ie cut fn not handling -1, providing a static directory for files to be published, added some basic math functions - sin cos etc..).
I would suggest starting a new branch with arc3 and if the libraries from anarki are still relevant then people will incrementally add them. This way were not integrating a bunch of code just because it's there - even though it's no longer useful.
+ just because you make them work with core arc3 files doesn't mean there will not be conflicts - as example the int function in the anarki math.arc library conflicts with news.arc only (as pg added an int function).
Some of the things anarki adds that are not in arc3 are tremendously useful.
For example, help strings and the 'help macro to access them, and similarly, the ability to call up any function or macro's source with 'src.
I do think the idea of integrating anarki code incrementally is probably the right way to do it. To this end, I've forked anarki's "official" branch (http://github.com/rntz/arc), and I've been applying CatDancer's "minimum-distance-from-arc" patching philosophy (http://catdancer.github.com/sharing-hacks.html). We'll see how many things from anarki I end up converting this way.
When you're done with you're patching process (I wouldn't mind helping) we should probably merge it back into nex3's copy, as his has public commit access.
One approach is to only port over things that you personally use and care about; and let other people port over things they care about. That's a pretty good filter for separating out the important from the unimportant.
It still says to get arc2.tar; they haven't updated the page yet. Maybe it's because pg says, on Hacker news (http://news.ycombinator.com/item?id=634113) that it's a "preliminary release".
a bit surprised there isn't a sync call in writefile before the rename. how come? if there is data in user space buffer (there's no fflush) and the rename gets committed it could lead to corruption if the process crashes. maybe?
The data will be flushed when the file is closed, which happens before the rename. This means that the mzscheme process can be hard killed (kill -9) or can crash right after the rename, and the data will still be saved safely by the operating system.
sync, now, is completely different issue: that's for when you want to crash your operating system or power off your computer and have had your data physically written out to disk already. I've heard it said (though I don't know if this is true) that sync will really slow down your write performance, unless you carefully use a complicated technique such as first writing your updates to a journal log file (which can be replayed if your computer crashes) and then writing those changes to their permanent location (file or database tables).
i get your point regarding performance. arc does it right. it basically leverages file system magic to sync asynchronously at the (small) risk of zeroing out files on an os crash or power failure.
Is your question, "how do I back up my data files written by my Arc program?"
In Unix, rename is an atomic operation in the kernel. Renaming a file does not immediately delete the old contents of the file, instead, the old contents are deleted when no process no longer has the file open.
Say you have some file "data" which contains "foo". You have some process B such as tar or rsync which is reading your files to back them up. Meanwhile Arc is writing "bar" to "data".
B opens "data" for reading.
Arc creates "data.tmp" and writes "bar" to it. Then Arc renames "data.tmp" to "data".
A process which now opened "data" would read "bar" from it. However B is still reading the previous version of the file, and so reads "foo".
Thus the backup process will always read either the complete previous version of the file, or the complete next version of the file.
(Whether or not the data has already been physically written out to disk makes no difference to what the processes see).
