Re: guile-vm .go files in GUILE_LOAD_PATH
2008/9/18 <[EMAIL PROTECTED]>: > 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? I agree. I think that's what Emacs does, and Emacs is a good example to follow. It may also be worth checking out what Python does. Neil
Re: RFD: drop the GH interface.
Hi, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > Do we have a consensus? Yes, fine by me, but no rush. ;-) Ludo'.
Re: array handles and non-local exits
Hi, "Neil Jerram" <[EMAIL PROTECTED]> writes: 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().) Yes. >>> 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. Exactly. >> 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. I submitted this bug: https://savannah.gnu.org/bugs/index.php?24292 (Oops I forgot "and dynwinds" in the bug title...) I would suggest that we drop that mention of dynwinds from the manual. Thanks, Ludo'.
Re: call-with-values compilation!
2008/9/17 Andy Wingo <[EMAIL PROTECTED]>: > 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. Cool, thanks for the explanation! Neil
Re: RFD: drop the GH interface.
2008/9/18 Ludovic Courtès <[EMAIL PROTECTED]>: > Hi, > > Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > >> Do we have a consensus? > > Yes, fine by me, but no rush. ;-) Do you mean anything specific by "no rush" here? I think we should do it before we forget that we have a consensus. :-) Han-Wen, would you like to do the work? (I assume it should be just in the master branch for now.) Regards, Neil
Re: array handles and non-local exits
2008/9/18 Ludovic Courtès <[EMAIL PROTECTED]>: > > I submitted this bug: > > https://savannah.gnu.org/bugs/index.php?24292 That's great, thanks. > I would suggest that we drop that mention of dynwinds from the manual. In my view, this part is still useful: "You must take care to always unreserve an array after reserving it, also in the presence of non-local exits. To simplify this, reserving and unreserving work like a dynwind context (see Dynamic Wind): a call to scm_array_get_handle can be thought of as beginning a dynwind context and scm_array_handle_release as ending it. When a non-local exit happens between these two calls, the array is implicitely unreserved. That is, you need to properly pair reserving and unreserving in your code, but you don't need to worry about non-local exits." But this part is misleading and can be removed: "These calls and other pairs of calls that establish dynwind contexts need to be properly nested. If you begin a context prior to reserving an array, you need to unreserve the array before ending the context. Likewise, when reserving two or more arrays in a certain order, you need to unreserve them in the opposite order." Is that what you had in mind? Neil
Re: RFD: drop the GH interface.
"Neil Jerram" <[EMAIL PROTECTED]> writes: > 2008/9/18 Ludovic Courtès <[EMAIL PROTECTED]>: >> Yes, fine by me, but no rush. ;-) > > Do you mean anything specific by "no rush" here? I just meant I'm not gonna do it Right Now but that's fine by me if somebody else does. Thanks, Ludo'.
Re: array handles and non-local exits
"Neil Jerram" <[EMAIL PROTECTED]> writes: > 2008/9/18 Ludovic Courtès <[EMAIL PROTECTED]>: >> I would suggest that we drop that mention of dynwinds from the manual. Just to clarify: I'm suggesting fixing the manual so that it conforms to the implementation, not the opposite. > In my view, this part is still useful: > > "You must take care to always unreserve an array after reserving it, > also in the presence of non-local exits. To simplify this, reserving > and unreserving work like a dynwind context (see Dynamic Wind): a call > to scm_array_get_handle can be thought of as beginning a dynwind > context and scm_array_handle_release as ending it. When a non-local > exit happens between these two calls, the array is implicitely > unreserved. > > That is, you need to properly pair reserving and unreserving in your > code, but you don't need to worry about non-local exits." > > But this part is misleading and can be removed: > > "These calls and other pairs of calls that establish dynwind contexts > need to be properly nested. If you begin a context prior to reserving > an array, you need to unreserve the array before ending the context. > Likewise, when reserving two or more arrays in a certain order, you > need to unreserve them in the opposite order." > > Is that what you had in mind? Not quite. If get/release are left as is (i.e., they do not establish a dynwind context), I would write something along the lines of: You must take care to always unreserve an array after reserving it, also in the presence of non-local exits. If a non-local exit can happen between these two calls, you should install a dynwind context that releases the array when it is left (see Dynamic Wind). In addition, array reserving and unreserving must be properly paired. For instance, when reserving two or more arrays in a certain order, you need to unreserve them in the opposite order. I would simply remove the following paragraph: These calls and other pairs of calls that establish dynwind contexts need to be properly nested. If you begin a context prior to reserving an array, you need to unreserve the array before ending the context. Likewise, when reserving two or more arrays in a certain order, you need to unreserve them in the opposite order. What do you think? Thanks, Ludo'.
Re: RFD: drop the GH interface.
Ludovic Courte`s wrote: Hi, Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: Do we have a consensus? Yes, fine by me, but no rush. ;-) From a Guile-user and not developer perspective, the sequence needs to be: 1. the most retrograde platform must have all the GH capabilities in the SCM interfaces for their releases. It seems to take quite a few years for BSD to get around to building newer versions. 2. Once that happens, a couple of years must pass 3. I finally get around to removing GH stuff from my code (is there a guide?) 4. a couple more years pass 5. now it's okay by me for released code to not have GH. I think we're to step 3 now, but I need to check the Guile version distributed with net/open/free BSD. Last I looked (~4 or 5 years ago...), it was either 1.4.x or, perhaps, 1.6.x. It was many years behind. In any case, I would suggest checking with your "customers" and "redistributors" instead of this list. IMHO, anyway. Regards, Bruce
Re: [PATCH][VM] Fix first-time compilation
On Tue 16 Sep 2008 23:16, [EMAIL PROTECTED] (Ludovic Courtès) writes: > The attached patch fixes first-time compilation, by ensuring SRFI > modules are built before "guile-tools compile" is ever run. Merged, thanks. I wish that all of the C could be compiled before all of the scheme, though. Perhaps if I'm feeling ambitious I'll do that at some point (compile the scheme last). Andy -- http://wingolog.org/
Re: guile-vm .go files in GUILE_LOAD_PATH
Hi, On Thu 18 Sep 2008 00:57, <[EMAIL PROTECTED]> writes: > 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. A few thoughts: (1) Guile shouldn't have installed paths (its system paths) in its path when running uninstalled, otherwise you can get strange issues like you saw -- it's not limited to .go files, it could be .scm as well (2) I can imagine cases in which you would want compiled files not in the same location as source; e.g. /usr/lib64/guile/ vs /usr/share/guile/; although currently .go files are not platform-dependent (I don't think) (3) Currently there is no linkage between the absolute directory of the .scm file and the .go file, neither in the compilation nor in the loading; but there is a linking with the relative path if you use primitive-load-path (4) We already check to make sure that the .go file is newer than the .scm file I would suggest that the current way is sufficient, if we disable loading from the installed paths when running pre-inst-guile; because I kinda want to allow (2), but I don't want to deal with ordering issues within %load-path of "compiled locations" versus "source locations". Sorry about your bug, I know it was a bit painful. But you would not have had it if guile were operating correctly in the first place, regardless of the .go vs .scm issue. We certainly need to have a better story regarding versioning, so we don't load incompatible .go files. Andy -- http://wingolog.org/
Re: guile-vm .go files in GUILE_LOAD_PATH
Andy Wingo <[EMAIL PROTECTED]> wrote: > Hi, > > On Thu 18 Sep 2008 00:57, <[EMAIL PROTECTED]> writes: > > > 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. > > A few thoughts: > > (1) Guile shouldn't have installed paths (its system paths) in its path > when running uninstalled, otherwise you can get strange issues like > you saw -- it's not limited to .go files, it could be .scm as well True. > (2) I can imagine cases in which you would want compiled files not in > the same location as source; e.g. /usr/lib64/guile/ vs > /usr/share/guile/; although currently .go files are not > platform-dependent (I don't think) Hmm. Also true. > (4) We already check to make sure that the .go file is newer than the > .scm file Good. > I would suggest that the current way is sufficient, if we disable > loading from the installed paths when running pre-inst-guile; because I > kinda want to allow (2), but I don't want to deal with ordering issues > within %load-path of "compiled locations" versus "source locations". I'm pretty sure the case of not using the already installed system .scm files while building is handled now. I'm thinking more along the lines of some user wanted to override a system file for some reason. This issue came up for me when I wanted to use a newer gnus than what came with the system supplied emacs. At that time I didn't have admin privs so I just installed gnus somewhere under my home dir and made sure that the emacs load path searched there first. Can this situation ever come up in Guile? Maybe. As Neil mentioned, emacs is a good example to follow. That's why I'm suggesting this. > Sorry about your bug, I know it was a bit painful. But you would not > have had it if guile were operating correctly in the first place, > regardless of the .go vs .scm issue. No problem there. Finding (and fixing) bugs is what makes using developing code fun. ;^) Thanks, -Dale
Re: [PATCH] Use Gnulib's `strftime'
Hi Neil,
"Neil Jerram" <[EMAIL PROTECTED]> writes:
> 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?
No, you're right.
That was a double mistake of my side: I misunderstood the UTC argument
to `nstrftime ()' as a boolean indicating whether to honor `tm_zone',
and overlooked the part of `scm_strftime ()' intended to "simulate" the
`tm_zone' fields on platforms that lack it...
Thanks!
Ludo'.
Re: guile-vm .go files in GUILE_LOAD_PATH
Heya Dale, On Thu 18 Sep 2008 22:49, <[EMAIL PROTECTED]> writes: > I'm pretty sure the case of not using the already installed system .scm > files while building is handled now. It is, but only because the uninstalled dirs are before the installed dirs. I committed a patch to the vm branch to remove the installed dirs from guile's load path when running as pre-inst-guile: http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=02b84691b274155f4528f99e90fbe39c77ed546d NB, relative to master, that patch depends on this one: http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=be52b55a3213c8f683d1007a542771daa3f9a06b > I'm thinking more along the lines > of some user wanted to override a system file for some reason. This > issue came up for me when I wanted to use a newer gnus than what came > with the system supplied emacs. At that time I didn't have admin privs > so I just installed gnus somewhere under my home dir and made sure that > the emacs load path searched there first. Can this situation ever come > up in Guile? Maybe. Sure it can. Hopefully you could get through it via the newer-than check... but I do see your point. > As Neil mentioned, emacs is a good example to follow. That's why I'm > suggesting this. I did look at its docs for quite some time before implementing it the way that I did. That said, your solution may be the better one in the long term. Does anyone else have an opinion? Cheers, Andy -- http://wingolog.org/
Re: guile-vm .go files in GUILE_LOAD_PATH
Hi, <[EMAIL PROTECTED]> writes: > I'm pretty sure the case of not using the already installed system > .scm files while building is handled now. I'm thinking more along the > lines of some user wanted to override a system file for some > reason. This issue came up for me when I wanted to use a newer gnus > than what came with the system supplied emacs. At that time I didn't > have admin privs so I just installed gnus somewhere under my home dir > and made sure that the emacs load path searched there first. Can this > situation ever come up in Guile? Maybe. That can be handled by setting $GUILE_LOAD_PATH appropriately; even `boot-9.scm' can be overridden this way (which `-L' and `%load-path' do not allow). Thanks, Ludo'.
