Re: Adding to the end of the load path
On 11/11/12 13:51, Mark H Weaver wrote: This is certainly the cleanest solution, but there is a complication: if a user has multiple versions of Guile installed on their system, some of which look for GUILE_LOAD_PATH_SUFFIX and some which do not, there is no way for them to configure their environment variables that will work correctly for all versions. Guile 2.0.5 will be widely deployed until at least 2017, since it is part of Ubuntu 12.04 LTS. We have to cope with that somehow. Declare Guile 2.0.5 to be buggy and recommend Ubuntu/Debian to upgrade with a patch that fixes the LD_LIBRARY_PATH/*_LOAD_PATH stuff? What do you think? Maybe a 2.0.5.1 release that just fixes this bit and fold it into the main branch, too.
Re: [PATCH] Fix `get-string-n!' i/o-decoding exception behavior
Mark H Weaver m...@netris.org writes: Andreas Rottmann a.rottm...@gmx.at writes: Mark H Weaver m...@netris.org writes: Why not leave the API as-is, and in the event of an error, just raise the proper R6RS exception from within 'scm_get_string_n_x'? The problem here is that we have no easy way to raise R6RS exceptions from C code, AFAICT. It is certainly possible, but if it involves convoluted code of doing imports of condition types and appropriate constructors, then constructing a proper invocation, all in C, I'd rather avoid it. It's not that bad. In Guile 2.0 we have some convenient procedures for accessing arbitrary Scheme variables from C. Looking at your patch, I see that if '%get-string-n!' returned an error, then you did: (raise (make-i/o-decoding-error port)) This can be written in C as follows: scm_call_1 (scm_c_public_ref (rnrs exceptions, raise), scm_call_1 (scm_c_public_ref (rnrs io ports, make-i/o-decoding-error))); Alternatively, you could write one or more private helper procedures in Scheme to raise R6RS exceptions, and call those private helpers from C using 'scm_c_private_ref' instead of 'scm_c_public_ref'. What do you think? OK, I'll give this approach a try; I suspect it will indeed result in the least churn. Regards, Rotty -- Andreas Rottmann -- http://rotty.xx.vu/
[PATCH] Add missing R6RS `open-file-input/output-port' procedure
* module/rnrs/io/port.scm (r6rs-open): New internal helper procedure for
opening files.
(open-file-input-port, open-file-output-port): Make use of
`r6rs-open'.
(open-file-input/output-port): Implement in terms of `r6rs-open',
add to exported identifiers list.
* module/rnrs.scm (open-file-input/output-port): Add to exported
identifiers.
* test-suite/tests/r6rs-ports.test (test-input-file-opener): New
procedure, collects several tests for opening file input ports.
(7.2.7 Input Ports): Use `test-input-file-opener' for checking
`open-file-input-port'.
(test-output-file-opener): New procedure, collects several tests for
opening file output ports.
(8.2.10 Output ports): Use `test-output-file-opener' for checking
`open-file-output-port'.
(8.2.13 Input/output ports): New test prefix, making use of both
`test-input-file-opener' and `test-output-file-opener' to check
`open-file-input/output-port'.
---
module/rnrs.scm |2 +-
module/rnrs/io/ports.scm | 70 +--
test-suite/tests/r6rs-ports.test | 98 +-
3 files changed, 100 insertions(+), 70 deletions(-)
diff --git a/module/rnrs.scm b/module/rnrs.scm
index 9fff820..a132c53 100644
--- a/module/rnrs.scm
+++ b/module/rnrs.scm
@@ -180,7 +180,7 @@
call-with-bytevector-output-port
call-with-string-output-port
latin-1-codec utf-8-codec utf-16-codec
- open-file-input-port open-file-output-port
+ open-file-input-port open-file-output-port
open-file-input/output-port
make-custom-textual-output-port
call-with-string-output-port
flush-output-port put-string
diff --git a/module/rnrs/io/ports.scm b/module/rnrs/io/ports.scm
index fddb491..7c17b0c 100644
--- a/module/rnrs/io/ports.scm
+++ b/module/rnrs/io/ports.scm
@@ -64,7 +64,10 @@
call-with-string-output-port
make-custom-textual-output-port
flush-output-port
-
+
+ ;; input/output ports
+ open-file-input/output-port
+
;; binary output
put-u8 put-bytevector
@@ -305,19 +308,46 @@ read from/written to in @var{port}.
(with-fluids ((%default-port-encoding UTF-8))
(open-input-string str)))
-(define* (open-file-input-port filename
- #:optional
- (file-options (file-options))
- (buffer-mode (buffer-mode block))
- maybe-transcoder)
+(define (r6rs-open filename mode buffer-mode transcoder)
(let ((port (with-i/o-filename-conditions filename
(lambda ()
(with-fluids ((%default-port-encoding #f))
-(open filename O_RDONLY))
-(cond (maybe-transcoder
- (set-port-encoding! port (transcoder-codec maybe-transcoder
+(open filename mode))
+(cond (transcoder
+ (set-port-encoding! port (transcoder-codec transcoder
port))
+(define (file-options-mode file-options base-mode)
+ (logior base-mode
+ (if (enum-set-member? 'no-create file-options)
+ 0
+ O_CREAT)
+ (if (enum-set-member? 'no-truncate file-options)
+ 0
+ O_TRUNC)
+ (if (enum-set-member? 'no-fail file-options)
+ 0
+ O_EXCL)))
+
+(define* (open-file-input-port filename
+ #:optional
+ (file-options (file-options))
+ (buffer-mode (buffer-mode block))
+ transcoder)
+ Return an input port for reading from @var{filename}.
+ (r6rs-open filename O_RDONLY buffer-mode transcoder))
+
+(define* (open-file-input/output-port filename
+ #:optional
+ (file-options (file-options))
+ (buffer-mode (buffer-mode block))
+ transcoder)
+ Return a port for reading from and writing to @var{filename}.
+ (r6rs-open filename
+ (file-options-mode file-options O_RDWR)
+ buffer-mode
+ transcoder))
+
(define (open-string-output-port)
Return two values: an output port that will collect characters written to it
as a string, and a thunk to retrieve the characters associated with that port.
@@ -331,23 +361,11 @@ as a string, and a thunk to retrieve the characters
associated with that port.
(file-options (file-options))
(buffer-mode (buffer-mode block))
maybe-transcoder)
- (let* ((flags (logior O_WRONLY
-(if (enum-set-member? 'no-create file-options)
-0
-O_CREAT)
-(if
Re: thoughts on native code
Thanks for your mail Noah, Yea libjit is quite interesting. But playing around with an assembler in scheme I do not want to go back to C or C++ land. The only problem is that we need a GNU scheme assembler and right now I use sbcl's assembler ported to scheme. We could perhaps use weinholts assembler as well in industria if he could sign papers to make it GNU. For the register allocation part I would really like to play a little in scheme to explore the idea you saw from my previous mail in this thread. Again I think it's natural to have this features in scheme and do not want to mess in C land too much. Am I wrong? Cheers Stefan On Sat, Nov 10, 2012 at 11:49 PM, Noah Lavine noah.b.lav...@gmail.comwrote: Hello, I assume compressed native is the idea you wrote about in your last email, where we generate native code which is a sequence of function calls to VM operations. I really like that idea. As you said, it uses the instruction cache better. But it also fixes something I was worried about, which is that it's a lot of work to port an assembler to a new architecture, so we might end up not supporting many native architectures. But it seems much easier to make an assembler that only knows how to make call instructions and branches. So we could support compressed native on lots of architectures, and maybe uncompressed native only on some. If you want a quick way to do compressed native with reasonable register allocation, GNU libjit might work. I used it a couple years ago for a JIT project that we never fully implemented. I chose it over GNU Lightning specifically because it did register allocation. It implements a full assembler, not just calls, which could also be nice later. Noah On Sat, Nov 10, 2012 at 5:06 PM, Stefan Israelsson Tampe stefan.ita...@gmail.com wrote: I would like to continue the discussion about native code. Some facts are, For example, consider this (define (f x) (let loop ((s 0) (i 0)) (if (eq? i x) s (loop (+ s i) (+ i 1) The timings for (f 1) ~ (f 100M) is 1) current vm : 2.93s 2) rtl : 1.67s 3) compressed native : 1.15s 4) uncompressed native : 0.54s sbcl = compressed nativ + better register allocations (normal optimization level) : 0.68s To note is that for this example the call overhead is close to 5ns per iteration and meaning that if we combined 4 with better register handling the potential is to get this loop to run at 0.2s which means that the loop has the potential of running 500M iterations in one second without sacrifying safety and not have a extraterestial code analyzer. Also to note is that the native code for the compressed native is smaller then the rtl code by some factor and if we could make use of registers in a better way we would end up with even less overhead. To note is that compressed native is a very simple mechanism to gain some speed and also improve on memory usage in the instruction flow, Also the assembler is very simplistic and it would not be to much hassle to port a new instruction format to that environment. Also it's probably possible to handle the complexity of the code in pure C for the stubs and by compiling them in a special way make sure they output a format that can be combined with the meta information in special registers needed to make the execution of the compiled scheme effective. This study also shows that there is a clear benefit to be able to use the computers registers, and I think this is the way you would like the system to behave in the end. sbcl does this rather nicely and we could look at their way of doing it. So, the main question now to you is how to implement the register allocations? Basic principles of register allocation can be gotten out from the internet, I'm assure of, but the problem is how to handle the interaction with the helper stubs. That is something i'm not sure of yet. A simple solution would be to assume that the native code have a set of available registers r1,...,ri and then force the compilation of the stubs to treat the just like the registers bp, sp, and bx. I'm sure that this is possible to configure in gcc. So the task for me right now is to find out more how to do this, if you have any pointers or ideas, please help out. Cheers Stefan On Sat, Nov 10, 2012 at 3:41 PM, Stefan Israelsson Tampe stefan.ita...@gmail.com wrote: Hi all, After talking with Mark Weaver about his view on native code, I have been pondering how to best model our needs. I do have a framework now that translates almost all of the rtl vm directly to native code and it do shows a speed increase of say 4x compared to runing a rtl VM. I can also generate rtl code all the way from guile scheme right now so It's pretty easy to generate test cases. The problem that Mark point out to is that we need to take care to not blow the instructuction cache. This is not seen in
Re: [PATCH] Add missing R6RS `open-file-input/output-port' procedure
Hi Andreas, This patch looks good to me! Thanks, Mark
