On Unix the null device is /dev/null. On Windows NT+ the equivalent is NUL. We can verify this by writing the following small C++11 program:
#include <cstdio> int main() { auto f = fopen("NUL", "r"); if (f == nullptr) { fprintf(stderr, "Cannot open file `NUL'."); return 0; } printf("Opened file `NUL' successfully."); }
The above program, when compiled and run on Windows, will always print "Opened file `NUL' successfully."
This brings me to Gambit, via Black Hole. BH contains some code (in compile-load.scm and lib.scm) that assumes `/dev/null' exists. This is obviously not true on Windows where instead we have `NUL'. It's easy enough to modify BH accordingly but the problem remains that Gambit tries to normalize all paths passed to `compile-file-to-target' so we end up with `<absolute path to cwd>\NUL' instead of just `NUL'. This essentially prevents us from using the null device as input to `compile-file-to-target' on Windows & means the following code from BH will fail on Windows:
(define (compile-sexp-to-c sexp fn #!key (options '())) (##gc) ;; Avoid out-of-memory related crashes (let ((hook (lambda (_) sexp)) (prev-hook #f)) (dynamic-wind (lambda () (set! prev-hook c#expand-source) (set! c#expand-source hook)) (lambda () (compile-file-to-target "/dev/null" ;; Change to "NUL" on Windows output: fn options: options)) (lambda () (set! c#expand-source prev-hook)))))
I've searched through the Gambit source code & tried to make the necessary changes to get this working but have been unable to do so. I probably just don't yet have a good enough understanding of the code. (I tried modifying ___os_path_normalize_directory in lib/os_files.c)
Is anyone able to help with this? I really want to run Black Hole on Windows!
Many thanks, Ralph
Afficher les réponses par date
Hi Ralph!
Yeah Black Hole on Windows is completely relevant.
Re BH, you may be interested in checking out the nonsyntactic tower version at https://github.com/pereckerdal/blackhole/tree/legacy as that one is most tested and tried currently.
You find a current version of this nicely bundled on http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds#Module_systems under the download link http://dynamo.iro.umontreal.ca/wiki/images/6/64/2012-11-28-bh-non-syntactict....
For installation please refer to the mailing list post of 2012-11-29.
Further updates are coming to Black Hole, at a currently unspecified date.
I would guess it works great on Windows either directly or with some trivla tweak, feel free to let the list know.
Now, did this solve your problem, or do you by some reason want to proceed with digging into the (compile-file-to-target "/dev/null" ... issue with syntactictower BH?
Mikael
2013/4/13 Ralph Moritz ralph.moeritz@outlook.com
On Unix the null device is /dev/null. On Windows NT+ the equivalent is NUL. We can verify this by writing the following small C++11 program:
#include <cstdio> int main() { auto f = fopen("NUL", "r"); if (f == nullptr) { fprintf(stderr, "Cannot open file `NUL'."); return 0; } printf("Opened file `NUL' successfully."); }
The above program, when compiled and run on Windows, will always print "Opened file `NUL' successfully."
This brings me to Gambit, via Black Hole. BH contains some code (in compile-load.scm and lib.scm) that assumes `/dev/null' exists. This is obviously not true on Windows where instead we have `NUL'. It's easy enough to modify BH accordingly but the problem remains that Gambit tries to normalize all paths passed to `compile-file-to-target' so we end up with `<absolute path to cwd>\NUL' instead of just `NUL'. This essentially prevents us from using the null device as input to `compile-file-to-target' on Windows & means the following code from BH will fail on Windows:
(define (compile-sexp-to-c sexp fn #!key (options '())) (##gc) ;; Avoid out-of-memory related crashes (let ((hook (lambda (_) sexp)) (prev-hook #f)) (dynamic-wind (lambda () (set! prev-hook c#expand-source) (set! c#expand-source hook)) (lambda () (compile-file-to-target "/dev/null" ;; Change to "NUL" on Windows output: fn options: options)) (lambda () (set! c#expand-source prev-hook)))))
I've searched through the Gambit source code & tried to make the necessary changes to get this working but have been unable to do so. I probably just don't yet have a good enough understanding of the code. (I tried modifying ___os_path_normalize_directory in lib/os_files.c)
Is anyone able to help with this? I really want to run Black Hole on Windows!
Many thanks, Ralph
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
On Sat, 13 Apr 2013 16:41:17 +0200, Mikael mikael.rcv@gmail.com wrote:
Re BH, you may be interested in checking out the nonsyntactic tower version at https://github.com/pereckerdal/blackhole/tree/legacy as >that one is most tested and tried currently.
You find a current version of this nicely bundled on http://dynamo.iro.umontreal.ca/wiki/index.php/%3EDumping_Grounds#Module_syst... under the download link http://dynamo.iro.umontreal.ca/wiki/images/6/64/2012-11-28-bh-non-%3Esyntact... .
For installation please refer to the mailing list post of 2012-11-29.
Further updates are coming to Black Hole, at a currently unspecified date.
I would guess it works great on Windows either directly or with some trivla tweak, feel free to let the list know.
Thanks for this info. I downloaded the bundled "non syntactic tower" version you linked to & followed the instructions in your ML post. Unfortunately I get the following error when launching `bsc'
*** ERROR IN ##u8vector->object -- deserialization error
A quick grep found the offending code in module.scm, function `read-ns-table'. Not sure how to go about fixing that.
Now, did this solve your problem, or do you by some reason want to proceed with digging into the (compile-file-to-target "/dev/>null" ... issue with syntactictower BH?
Well, as described above I couldn't get the "non syntactic tower" version to work, so unless there's a quick fix for the issue I'd be tempted to just fix Gambit to treat an argument of `NUL' to `compile-file-to-target' as a special case & not prepend the CWD. Can you provide help with either issue?
Regards, Ralph
2013/4/14 Ralph Moritz ralph.moeritz@outlook.com
** On Sat, 13 Apr 2013 16:41:17 +0200, Mikael mikael.rcv@gmail.com wrote:
Re BH, you may be interested in checking out the nonsyntactic tower version at https://github.com/pereckerdal/blackhole/tree/legacy as that one is most tested and tried currently.
You find a current version of this nicely bundled on http://dynamo.iro.umontreal.ca/wiki/index.php/Dumping_Grounds#Module_systems under the download link http://dynamo.iro.umontreal.ca/wiki/images/6/64/2012-11-28-bh-non-syntactict....
For installation please refer to the mailing list post of 2012-11-29.
Further updates are coming to Black Hole, at a currently unspecified date.
I would guess it works great on Windows either directly or with some trivla tweak, feel free to let the list know.
Thanks for this info. I downloaded the bundled "non syntactic tower" version you linked to & followed the instructions in your ML post. Unfortunately I get the following error when launching `bsc'
*** ERROR IN ##u8vector->object -- deserialization error
The only u8vector<->object serialization done is of ns.dat in Black Hole's home directory. I believed this was not included there.
Please remove this file and try again - it'll make a new one.
If this was the thing, my fault.
A quick grep found the offending code in module.scm, function `read-ns-table'. Not sure how to go about fixing that.
Now, did this solve your problem, or do you by some reason want to proceed with digging into the (compile-file-to-target "/dev/null" ... issue with syntactictower BH?
Well, as described above I couldn't get the "non syntactic tower" version to work, so unless there's a quick fix for the issue I'd be tempted to just fix Gambit to treat an argument of `NUL' to `compile-file-to-target' as a special case & not prepend the CWD. Can you provide help with either issue?
Regards, Ralph
-- Using Opera's mail client: http://www.opera.com/mail/
On Sun, 14 Apr 2013 02:17:17 +0200, Mikael mikael.rcv@gmail.com wrote:
Thanks for this info. I downloaded the bundled "non syntactic tower" version you linked to & followed the instructions in your ML >>>post. Unfortunately I get the following error when launching `bsc'
*** ERROR IN ##u8vector->object -- deserialization error
The only u8vector<->object serialization done is of ns.dat in Black Hole's home directory. I believed this was not included there.
Please remove this file and try again - it'll make a new one.
If this was the thing, my fault.
That did it, thanks.
On 2013-04-12, at 6:29 PM, Ralph Moritz ralph.moeritz@outlook.com wrote:
On Unix the null device is /dev/null. On Windows NT+ the equivalent is NUL. We can verify this by writing the following small C++11 program:
#include <cstdio> int main() { auto f = fopen("NUL", "r"); if (f == nullptr) { fprintf(stderr, "Cannot open file `NUL'."); return 0; } printf("Opened file `NUL' successfully."); }
The above program, when compiled and run on Windows, will always print "Opened file `NUL' successfully."
This brings me to Gambit, via Black Hole. BH contains some code (in compile-load.scm and lib.scm) that assumes `/dev/null' exists. This is obviously not true on Windows where instead we have `NUL'. It's easy enough to modify BH accordingly but the problem remains that Gambit tries to normalize all paths passed to `compile-file-to-target' so we end up with `<absolute path to cwd>\NUL' instead of just `NUL'. This essentially prevents us from using the null device as input to `compile-file-to-target' on Windows & means the following code from BH will fail on Windows:
(define (compile-sexp-to-c sexp fn #!key (options '())) (##gc) ;; Avoid out-of-memory related crashes (let ((hook (lambda (_) sexp)) (prev-hook #f)) (dynamic-wind (lambda () (set! prev-hook c#expand-source) (set! c#expand-source hook)) (lambda () (compile-file-to-target "/dev/null" ;; Change to "NUL" on Windows output: fn options: options)) (lambda () (set! c#expand-source prev-hook)))))
I've searched through the Gambit source code & tried to make the necessary changes to get this working but have been unable to do so. I probably just don't yet have a good enough understanding of the code. (I tried modifying ___os_path_normalize_directory in lib/os_files.c)
Is anyone able to help with this? I really want to run Black Hole on Windows!
There was an issue with opening UNC filenames (Universal Naming Convention) on Windows that I have now fixed. So now it is possible to use \.\nul for the nul device (so "/dev/null" should be replaced with "\\.\nul" on Windows). Note that the path-expansion algorithm will map "nul" to "<cwd>/nul" so a (open-output-file "nul") will open a local file called "nul". This consistency with Unix is a good thing.
Marc
On Mon, 15 Apr 2013 18:29:16 +0200, Marc Feeley feeley@iro.umontreal.ca wrote:
On 2013-04-12, at 6:29 PM, Ralph Moritz ralph.moeritz@outlook.com wrote:
...
This brings me to Gambit, via Black Hole. BH contains some code (in compile-load.scm and lib.scm) that assumes `/dev/null' exists. This is obviously not true on Windows where instead we have `NUL'. It's easy enough to modify BH accordingly but the problem remains that Gambit tries to normalize all paths passed to `compile-file-to-target' so we end up with `<absolute path to cwd>\NUL' instead of just `NUL'. This essentially prevents us from using the null device as input to `compile-file-to-target' on Windows
...
There was an issue with opening UNC filenames (Universal Naming Convention) on Windows that I have now fixed. So now it is possible to use \.\nul for the nul device (so "/dev/null" should be replaced with "\\.\nul" on Windows). Note that the path-expansion algorithm will map "nul" to "<cwd>/nul" so a (open-output-file "nul") will open a local file called "nul". This consistency with Unix is a good thing.
Awesome, thanks a lot for fixing this. Being able to access the null device on Windows means I can now try to get Black Hole trunk working on Windows.
Hi Ralph,
The nonsyntactictower version of BH is the real deal for now in the sense that it's been thoroughly tested an tried in practical use.
The syntactictower version has quite not got that, though it may very well deliver for your purposes.
There will be updates with BH.
Brgds
2013/4/15 Ralph Moritz ralph.moeritz@outlook.com
On Mon, 15 Apr 2013 18:29:16 +0200, Marc Feeley feeley@iro.umontreal.ca wrote:
On 2013-04-12, at 6:29 PM, Ralph Moritz ralph.moeritz@outlook.com wrote:
...
This brings me to Gambit, via Black Hole. BH contains some code (in compile-load.scm and lib.scm) that assumes `/dev/null' exists. This is obviously not true on Windows where instead we have `NUL'. It's easy enough to modify BH accordingly but the problem remains that Gambit tries to normalize all paths passed to `compile-file-to-target' so we end up with `<absolute path to cwd>\NUL' instead of just `NUL'. This essentially prevents us from using the null device as input to `compile-file-to-target' on Windows
...
There was an issue with opening UNC filenames (Universal Naming Convention) on Windows that I have now fixed. So now it is possible to use \.\nul for the nul device (so "/dev/null" should be replaced with "\\.\nul" on Windows). Note that the path-expansion algorithm will map "nul" to "<cwd>/nul" so a (open-output-file "nul") will open a local file called "nul". This consistency with Unix is a good thing.
Awesome, thanks a lot for fixing this. Being able to access the null device on Windows means I can now try to get Black Hole trunk working on Windows.
-- Using Opera's mail client: http://www.opera.com/mail/ _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list