Re: array handles and non-local exits
2008/9/16 Ludovic Courtès <[EMAIL PROTECTED]>: > > If `get_handle ()' creates a dynwind that ends in `release_handle ()', > then code like the following will no longer work as expected: > > scm_dynwind_begin (); > scm_dynwind_unwind_handler (); > scm array_get_handle (); > > ... > > scm_dynwind_end (); > scm_array_release_handle (); > > Perhaps that's what is implied by the manual's wording but I find it a > bit tricky. Yes, that definitely is what the manual means by "properly nested" - but I also agree that it is a bit tricky. >>> and (2) I don't know of any other function that does a dynwind behind >>> the scenes (IOW, let's not break the "rule of least surprise"). > > I meant "I don't know of a function that does a `dynwind_begin' > *alone*" (of course there are plenty of functions that do > `dynwind_begin' + `dynwind_end'). Yes, I see what you mean now. (The scm_dynwind_begin() being in scm_array_get_handle(), and the scm_dynwind_end() being in scm_array_release_handle().) >> I think you're imagining a clear boundary here where there isn't one. >> If needed, either the scm_dynwind would be inside >> scm_array_get_handle, or it would be inside scm_uniform_vector_read. >> Both of those are public libguile functions, so where's the >> difference? > > The difference is that `scm_array_get_handle ()' is a low-level > function. It may be used, say, in code that passes SRFI-4 vectors to C > that implements "performance-critical" code. Adding consing in there > wouldn't feel right. If you add in " and which can't possibly do a non-local exit " there, I see your point. > Right, I hadn't thought about it, but as you mention, a dynwind in > `uniform-vector-read!' will only affect soft port implementations. With that in mind, do you think we need to solve this now? I think this is low impact, so for now I'm inclined just to raise a bug in Savannah, containing our discussion so far, so that we don't forget it. Regards, Neil
Re: call-with-values compilation!
2008/9/16 Andy Wingo <[EMAIL PROTECTED]>: > This new instruction, mv-call, takes three byte arguments, and at least > two stack arguments. The byte arguments are the number of args, and two > bytes to specify an offset to the multiple values return address. The Why _two_bytes to specify an offset? Is it just to support offsets > 255, or is there some other interpretation of the two bytes? > Guile (with the VM) now supports multiple values, without consing at > all! Nice! Neil
Re: [PATCH] Use Gnulib's `strftime'
Hi Ludo...
2008/9/2 Ludovic Courtès <[EMAIL PROTECTED]>:
> Hello!
>
> I'm planning to use Gnulib's `strftime' module on `master' to fix
> portability problems related to `strftime', aka. #24130
> (https://savannah.gnu.org/bugs/?24130). The good thing is that
> `strftime' will now work the same regardless of the underlying libc.
Excellent!
> The source modification is attached.
I'm just a bit confused about %Z, because it seems to me that the
documentation contradicts the test.
Here's the doc change:
> +Note that @samp{%Z} always ignores the @code{tm:zone} in @var{tm};
> +instead it prints just the current zone (@code{tzset} above).
Here's the test:
> + (pass-if "strftime %Z doesn't return garbage"
> +(let ((t (localtime (current-time
> + (set-tm:zone t "ZOW")
> + (set-tm:isdst t 0)
> + (string=? (strftime "%Z" t)
> +"ZOW")))
The doc seems to be saying that (strftime "%Z" tm) will ignore TM's
zone, but the test makes it look like (strftime "%Z" tm) uses TM's
zone. Am I misunderstanding?
Regards,
Neil
Re: call-with-values compilation!
On Wed 17 Sep 2008 21:42, "Neil Jerram" <[EMAIL PROTECTED]> writes: > 2008/9/16 Andy Wingo <[EMAIL PROTECTED]>: >> This new instruction, mv-call, takes three byte arguments, and at least >> two stack arguments. The byte arguments are the number of args, and two >> bytes to specify an offset to the multiple values return address. The > > Why _two_bytes to specify an offset? Is it just to support offsets > > 255, or is there some other interpretation of the two bytes? Yep, just for offsets >= 255 -- while unlikely in practice, it is likely for the `br' family of instructions, and I reused that machinery. In the future, as Ludovic mentions, we should probably look at word-aligning all of our instructions; that is, once everything is working and we can do some meaningful benchmarks. Then we could probably have 3 bytes of "argument", potentially, for all fixed-length instructions. Andy -- http://wingolog.org/
guile-vm .go files in GUILE_LOAD_PATH
I've been tracking the guile-vm branch lately and had a recent problem. After much head scratching we finally figured out that a previously installed .go file was being used during the buld. We (Andy and I on irc) hacked around it by creating a new environment variable that pre-inst-guile-env can use to override or disable things that libguile adds to the load-path. However, I think there is still a problem. Basically, a .go file will be preferred over a .scm file even if the .scm file is earlier in the load-path. I think that the file earlier in the load-path should win. Thoughts? -Dale
Re: guile-vm .go files in GUILE_LOAD_PATH
Le Wed, 17 Sep 2008 18:57:19 -0400, <[EMAIL PROTECTED]> a écrit : > I've been tracking the guile-vm branch lately and had a recent problem. > After much head scratching we finally figured out that a previously > installed .go file was being used during the buld. > > We (Andy and I on irc) hacked around it by creating a new environment > variable that pre-inst-guile-env can use to override or disable things that > libguile adds to the load-path. However, I think there is still a problem. > > Basically, a .go file will be preferred over a .scm file even if the .scm > file is earlier in the load-path. I think that the file earlier in the > load-path should win. > > Thoughts? > -Dale Should it not be a user responsibility? I mean: I would place my .go files next to my .scm files and expect the loading process to warn me if the .scm file was newer, but still would load all .go files when available. David
Re: RFD: drop the GH interface.
Do we have a consensus? Ludovic Courtès escreveu: >> The GH interface was marked as deprecated in >> * Explain GH deprecation & plan for scm documentation. >> >> >> Let's really drop it now. > > Why? It doesn't cost much to keep it, does it? > -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
