Right, I'm using Git as a way to pull in and manage hack dependencies, instead of for version control.
You can first use Git to develop a library using Git as a version control system and then publish your library using Git in my approach. However you can't use the same commit for both: you can't take a commit that has version control type ancestors and publish it as a dependency type commit. Instead you have to create a new commit which has only prerequisite hacks as ancestors.
This is somewhat similar to creating a clean patch series: you don't lose your development history, but you don't expose the upstream recipients of your clean patches to the messy details of your development history either.
Thanks for the comment, I'll add a paragraph talking about this.
I don't know yet if Git is up to what I want it to do either, but it seems to be OK so far, if a bit awkward. (Which isn't surprising, since after all it was designed as a version control system).
Branches are useful for developing libraries and for following along library development. It was a pain trying to pull in different libraries from different repositories by referencing them by branch name, at least the way I was doing it.
The installer will ask you where you want to install mzscheme, you can choose any directory that is convenient for you. You do not need the option to create links in standard directories, say "no" to that.
Then you'd run mzscheme from the directory that you installed it to.
In what you posted above, you don't include the path to mzscheme. Are you now including the path? If so, what exactly are you typing, and what error message are you getting exactly?
* tried it with the absolute path
* tried it without
* tried running it in its directory
* tried running it without parameters just to see what happens
all of these ways with the exact same output result (except the path changes as it should)
You're going to need to get help on the PLT Scheme user mailing list for this one. (This is the first mailing list listed at the top of http://www.plt-scheme.org/community.html)
Tell them what operating system you're running, including the output of "uname -a", and which distribution of PLT Scheme you downloaded. Mention you need to run PLT Scheme version 372 specifically. No need to include the "-m" or "-f" options or to mention Arc, just show them the output of when you're in the bin directory and you type just "./mzscheme"
Then, once you have mzscheme working, we may be able to help with any Arc problems you have... :-)
Is ./mzscheme a symbolic link pointing to a missing file? Or is ./mzscheme a shell script with an invalid interpreter line? (the first line, beginning with #! )
arguably, this is incorrect, because 1.234 obviously isn't an integer, so arc3 improves on this by rounding. But (coerce "1.234" 'num) isn't available (in arc 2 or 3), so there's no way to use coerce for non-integers.
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'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."
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).
