Hmm... It looks like it's my turn to have trouble! What version of Racket are you using? I might need to revert to that version to get Arc/Nu working on my system. XD
---
"Then I decided to try to run the news from a directory(not the installation one). So i put all the library files in that directory [...]"
Now that I've read this again, that sounds like something that would break the libraries in some way. The files of Arc/Nu contain relative paths to each other. If you move some files, you might need to edit the paths that occur in the other files. Which files were you trying to move where?
---
For anyone here who can help, here's the problem I'm encountering.
When I try to start Arc/Nu on Windows 10 with Racket 6.4 or 6.5 installed, I get this error:
I've tracked it down to a specific place: The execution of the Racket code (mac % args (% args)) in lang/arc/3.1/main.
That line is trying to set a hash table entry in Arc/Nu's (globals) table. In the file "compiler", when (namespace-require path) is called to load lang/arc/3.1/main dynamically, the (globals) parameter has been parameterized to contain an appropriate table to store that definition.
However, when lang/arc/3.1/main requires the "compiler" module, it loads a second instance of the module. So when it tries to access (globals), it gets the original value: (define globals (make-parameter #f)). Since #f isn't a hash table, hash-ref raises an exception.
Does anyone know if there's a way to make lang/arc/3.1/main reuse the same "compiler" module instance that's already been loaded?
That sounds super strange. From what I understand, Racket automatically caches modules, so they are only loaded once.
But then again, Racket does have multiple phases, so it's possible that it's loading the "compiler" file in two different phases, causing duplicate variable definitions.
In addition, Racket doesn't allow for mutually recursive modules, but Arc/Nu is using "namespace-require", which apparently bypasses that restriction. It's possible that there is a race condition that is causing the "arc/3.1/main" file to be loaded before the "compiler" file is finished loading, which then triggers a second load of the "compiler" file.
Just to clarify: have you tried inserting a "displayln" in the "compiler" file to verify that it is being loaded twice?
