<davexunit>mark_weaver: hey. taking a look at the *repl-stack* business <davexunit>we push *repl-stack* into the reader thread via an mvar, and I'm having trouble figuring out how to hide that from the user. <mark_weaver>davexunit: in this case, I think you can simply fetch the value of (fluid-ref *repl-stack*) before calling the read-wrapper, and then referencing that as a free variable from within the thunk. <davexunit>oh yeah, all of prompting-meta-read is the main thread. <mark_weaver>well, not really. in your case, the body of the (lambda () ...) passed to 'read-wrapper' will be called from another thread.. but regardless, it still has access to lexical variables. so if you simply add another clause to the outer 'let' in 'prompting-meta-read' to stash the value of *repl-stack*, the inner lambda will be able to access it. <dsmith-work>Woah. Just noticed some people have IPv6 adders. Cool. <davexunit>mark_weaver: back from making a pizza. that worked out very well. <davexunit>does guile follow a particular standard for version numbers? <mark_weaver>well, we maintain ABI compatibility within a stable series (e.g. 2.0.x), where the second number is even. if the second number is odd, that's a development release (e.g. 2.1.x). <mark_weaver>I'm not sure precisely what our policy is between major releases. <mark_weaver>sneek: later tell ijp: with current stable-2.0, running "guild update" leads to a deprecation warning: The #:extra-headers argument to http-get has been renamed to #:headers. <dsmith-work>Are there ever any x.odd.x "releases" ? Mostly just snapshots right? <dsmith-work>I guess when built from git and installed, it identifies non-release code. <mark_weaver>and maybe we'll produce some prerelease tarballs before the 2.2.0 release that have version number 2.1.x <b4283>sneek: tell ijp i think i found out what's going on with guildhall installing wak-common-0.1.0 for wak-irregex <sneek>ijp, b4283 says: i think i found out what's going on with guildhall installing wak-common-0.1.0 for wak-irregex <dje42>How does hash-set handle smobs? Would there be a use for a hash routine in struct scm_smob_descriptor? <dje42>Hmmm, do all smobs hash to 17? <dje42>s/17/some-fixed-value-per-table-size/ <mark_weaver>dje42: unfortunately, yes. Guile 2.0's hash function is very bad for smobs and several other kinds of aggregate objects. Things are significantly better in the master branch (to be 2.2), but still not great for smobs. <mark_weaver>There has been reluctance to change the hash function in 2.0.x because we never fully evaluated the question of whether the hash function is considered part of the ABI, which we promise to keep stable in a given release series. <mark_weaver>personally, I don't think the hash function should be part of the ABI. <mark_weaver>dje42: anyway, a hash function for smob descriptors sounds like a good idea to me. I just don't know about compatibility issues. would you like to raise the issue on guile-devel? <sneek>ijp, mark_weaver says: with current stable-2.0, running "guild update" leads to a deprecation warning: The #:extra-headers argument to http-get has been renamed to #:headers. <sneek>ijp, b4283 says: i think i found out what's going on with guildhall installing wak-common-0.1.0 for wak-irregex <ijp>mark_weaver: I know it is deprecated. I originally used #:headers but that isn't in 2.0.5 so I changed it back <ijp>I know there are two packages but since they have different version numbers it _should_ be irrelevant <ijp>removing one would work, sure, but it would not be resolving the real issue <ijp>mark_weaver: I even have the deprecation noted in the commit message for that change :) <mark_weaver>ijp: any idea what's going on with wak/private/include.sls having the .sls extension, and thus not being found by guile? <ijp>I checked the zip for 0.1.1 and there is no .sls files <mark_weaver>indeed, "guild list-packages --all" listed wak-common 0.1.1, but "guild install ..." installed wak-common 0.1.0 <mark_weaver>I got old versions of wak-syn-param and wak-foof-loop as well. <b4283>mark_weaver: if you run "guild install wak-common" you can get 0.1.1 <mark_weaver>okay, that's good :) but there's still a bug here to be fixed. <ijp>b4283: or just =guild upgrade= <ijp>but yes, I'll need to look into this <b4283>i'm thinking changing the precedence between the two versions in available.scm may do the trick <ijp>the newer one is already supposed to have precedence <ijp>is there a version of resolve-module that _doesn't_ create the module? <ijp>ah, nvm, the ensure keyword <ijp>well at least you have some good news :) <wingo>whee, ,disassemble prints source info for rtl functions now *dsmith-work is going on vacation for 2 weeks. <add^_>When does the vacation start dsmith-work? <add^_>Not gonna be here at all in that period? <dsmith-work>Nope. Will probably be working on the house. Might take some short 1-2 day trips. <wingo>woo, i just compiled eval.scm to rtl <ijp>it's better to get it over with so you can get to fixing it :) <civodul>alternately: leave it alone, celebrate that milestone, and wait until tomorrow to see what the problems are <wingo>meta/uninstalled-env guild compile -t rtl module/ice-9/eval.scm <wingo>meta/uninstalled-env guild disassemble cache/guile/ccache/2.2-LE-8-3.1/home/wingo/src/guile-master/module/ice-9/eval.scm.go <ijp>civodul: well, it is friday... <wingo>dudes and ladies, it seems to work <wingo>ok, doesn't really work yet :) ***bubbleman is now known as bubble
***bubble is now known as bubble_
<sneek>bipt was here Sep 19 at 09:44 pm UTC, saying: so for CL, for example, i wouldn't find it too inconvenient to require a modules.scm packages or similar, vs. having a module definition written in portable CL. i also think ML-style module features are more natural with separate configuration, at least based on my limited experience with scheme48. <aleix>ok, can you believe i just figured our sneek is a bot <ijp>that's okay, no-one has figured out I'm a bot yet <aleix>is the code available somewhere? <ijp>but it is an instance of bobot++, which is online somewher <mark_weaver>sneek: later tell civodul: I've used '@' to reference macros, even a few days ago, and it always seems to work for me. <mark_weaver>sneek: later tell civodul: e.g. ((@ (guile) define) (foo x y) (+ x y)) (foo 2 3) => 5 <mark_weaver>sneek: later tell civodul: afaict, it even works for primitive syntactic keywords that aren't macros, e.g. ((@ (guile) @) (ice-9 local-eval) local-eval) => #<procedure local-eval (x e)> <ijp>mark_weaver: I've had it work fine, but I have had also problems with record accessors <mark_weaver>sneek: later tell civodul: and ((@ (guile) quote) (1 2)) => (1 2) <ijp>but since none of my examples are working today, you'll need to wait till tomorrow :) <ijp>I'm not even kidding, nothing is working for me today <mark_weaver>all of my computers are broken except for the new YeeLoong I just bought (and my internet server). <mark_weaver>the backlight just died on the thinkpad I'd been using :-( <handheldCar>gNewSense/Debian libltdl7 is not sufficient for configure which needs libltdl. <bananagram>can you execute a shell command in guile and get its output? <mark_weaver>'open-pipe*' is a bit lower-level, but has the advantage that you don't have to worry about escaping string arguments and such (because you avoid the shell entirely) <mark_weaver>if you read the Guile manual in emacs' info mode, you can just type 'i' primitive-fork RET <mark_weaver>do you know how to use fork from C? it's basically the same.