<jegdemir>Anyone know how best to talk to MS SQL Server from guile? I'm stuck on a windows box in cygwin using freetds and iodbc but working outside of cygwin is an option too. <rlb>atgnag: it's a reference to the novel Cat's Cradle (recommended). <davexunit>jegdemir: is there a C library that you write wrappers for? <davexunit>I don't know of any pre-existing library for this <davexunit>but I would bet there's a C client library that you can wrap with Guile's C FFI <jegdemir>@davexunit: yeah, that's pretty much what I'm looking at now. Both freetds and iodbc are c libraries that I can use with ffi. They work well and are totally reliable. I was just hoping to avoid diving in to the deep end of the guile pool. :) <jegdemir>davexunit: I know, I know... I'm just lazy by nature. Ur right though. I'll put on my swimmies... heh. <davexunit>you'll be fine. Guile has less ready-made libraries than other languages, so it's important to be willing to get your hands dirty from time to time. <davexunit>so hopefully the next hacker won't have to. :) <rlb>btw, turns out that (test-group "foo" ...) doesn't crash as long as you've called (test-begin ...) somewhere before it, which lines up with the earlier observation about a similar crash with test-runner-aux-value!. Offhand, I'd guess that's not the intended semantics, but I'll have to look more carefully later. <jegdemir>davexunit: I'm just reviewing the ffi docs in the manual for 2.0 and ran across this: 'The most natural thing to do with a dynamic library is to grovel around in it for a function pointer.' I never grovel... See, I've always felt I'm more of a snivler. Whine... maybe. But grovel? *NEVER*! <rlb>Yeah, that's probably just a bug since (test-group suite-name ...) is supposed to be equivalent to: <rlb>(if (not (test-to-skip% suite-name)) <rlb> (lambda () (test-begin suite-name)) <rlb> (lambda () decl-or-expr ...) <rlb> (lambda () (test-end suite-name)))) <rlb>hmm, can you not have #:use-modules ((foo) #:prefix f: #:select (...))? <rlb>i.e both prefix and select? <rlb>(I'd like to select a few unprefixed symbols and have the rest available via the prefix, a-la (:use-modules [some.foo :as foo :refer [bar baz]]) in clojure. ***nalaginrut_ is now known as nalaginrut
<amz3>I found, another bug in my wrappers, it's happenning *sometime* <amz3>sometime is becoming more precise <amz3>I think it's because of my test macor : / ***nalaginrut_ is now known as nalaginrut
<amz3>fixed! I incorrectly wrapped several let, which lead to some ffi object to be GC'ed, I guess <amz3>nalaginrut: do you need help to test artanis before the release? <amz3>I promise I won't break anything ;) <nalaginrut>amz3: yes, it'll be better, you could play it for testing according to a tutorial or document, I need sometime to update the document <amz3>nalaginrut: it will be easier with a tutorial <nalaginrut>hmm...maybe unnecessary new site, but I think the tutorial don't have to use the same theme of the manual <amz3>nalaginrut: I think haunt has texinfo support now <amz3>or you have something else in mind? <nalaginrut>even we pick other document tool, it's temporary, finally I'll use a Guile based one <nalaginrut>amz3: at lease, we have to make sure Artanis works when uses copy/paste from tutorial <amz3>copy/pasting is evil, I prefer to use images <amz3>users will learn the good old days of computing, and learn to type correctly <amz3>Artanis is ok, it's the anachronic part, a glimpse into the future <amz3>my texinfo level is rather low <amz3>I will update it to texinfo <amz3>I will update haunt config I've done to texinfo <nalaginrut>amz3: I don't know texinfo grammar too, just use org-mode <amz3>there is a oauth library (linked earlier) <amz3>anyway the website is broken somewhat <amz3>something is wrong, I'll tell davexunit later <nalaginrut>should I consider to write a Markdown parser in pure Scheme? <amz3>I have a markdown parser, but it's not complete <amz3>For instance, I don't support nested bullets <amz3>I could support single level bullets <nalaginrut>no, actually I rarely use regex if I can use LALR <amz3>I can't not decide for you, for my blog i use my little markdown parser it's enough <amz3>the problem is that full markdown is too complicated <nalaginrut>amz3: I mean, is it worth to delay Artanis release till I done markdown parser? ;-P <nalaginrut>BTW, I'm thinking about what cool project could be tried for IOCCC <amz3>maybe we can hack a website, like guix and guile <amz3>I know the discipline, but I don't know what i takes to win those kind of games <amz3>nalaginrut: did you read about executable poetry? <amz3>but at the same time, it's not really obscuficated if it's readable but well <amz3>maybe it's an area to have a look at <amz3>well there is many link on the web, I have no particular prefered poem, just know about the discipline <amz3>there is also the poetry of unexecutable code <amz3>I really like mez breeze work ^ <amz3>so maybe, there must be 'the code of unreadable poetry' <amz3>I have the goal to make mezangelle a executable code at least in the sens of html, but it's not for right now <wingo>civodul, mark_weaver: wdyt about a 2.1.1 prerel <wingo>ACTION still updating his guix to have email setup on this laptop, hence the irc question <wingo>i would release master as 2.1.1 as-is <amz3>guile 2.1 is the one with the new GC? <civodul>i'm not promising much in terms of actual work though... <civodul>wingo: i'd also like to release 2.0.12, but we need to come to an agreement on the SMOB replacement API <wingo>your complaint was about goops, right? <wingo>humm, to my mind that api solved a common complaint, that there was no way to unify smobs and goops even if you wanted to <wingo>is it just the time/memory overhead of loading goops? <wingo>i don't see measurements in that mail <civodul>i measured the startup time with and without GOOPS in 2.0 <civodul>with guile -c '(use-modules (oop goops))' <civodul>time for i in `seq 1 20` ; do guile -c '(use-modules (oop goops))' ; done <wingo>for me with 2.0.11 i get 260ms/20 for no goops and 835ms/20 for goops <wingo>for master i get 304ms/20 with goops and 148ms/20 without <wingo>hum, i said those numbers right but i presented them in opposite orders, sorry <wingo>so it's not an order of magnitude; can you confirm? <wingo>this is on a 3.5-year-old i7 <civodul>ok, not an order of magnitude, but still :-) <civodul>the problem is that SMOBs are a very basic feature <civodul>i'd rather have it come for free, as was the case until now <civodul>i'm also slightly concerned about side effets, since now a lot of things would be generics etc. by default <civodul>i wonder if there are use cases where it could change the program's behavior <wingo>i think it's only equal? and write that's turned into a generic when you load goops <wingo>i mean there is the ability for many gsubrs to go generic but that's not enabled until a method is installed, so there should be no issue there <wingo>i get what you're saying but i am not sure that the perf matters -- we gain a lot of expressiveness for these values by allowing goops, and its cost isn't terrible in 2.2 at least <wingo>and will continue to get better as the compiler/runtime improves... <wleslie>304ms is only marginally more than 260 <wingo>it would be best if they were records that goops could extend <wingo>like, if goops could treat any old vtable as a class <wingo>so you wouldn't have to load up goops to class-enable a foreign object type <wingo>but if you did, then that type would automatically be treated as a class <wingo>but that needs more work in the struct system <wingo>er, in the goops system i mean (i think) <wingo>tho probably structs too; would be nice if vtables always named their fields :P <wingo>but i think the api is about right tho, regardless of goops or not <wingo>it doesn't mention goops at all <wingo>er, i guess the scheme api does tho... <civodul>wingo: yes, but equal? and write is already a bit too much of a change for the 2.0 series, IMO <civodul>what i was hoping is that, using structs, we would avoid GOOPS while still allowing GOOPSy features to be used for those who want <wingo>i cannot agree with your assessment of the impact of equal? and write :) <wingo>it is not incompatible as we are talking about new code <wingo>and it is not incompatible in that the difference is not observable <civodul>right but GOOPS would always be loaded, right? <wingo>currently there are 0 users of this api :) <civodul>there's still the problem that, as a replacement, it ought not to impose too much overhead, IMO <civodul>if structs could give us the best of both worlds, that'd be great :-) <wingo>are you still concerned about equal? and write or no? i am assuming no but it is hard to tell :) <wingo>it seems to me the api is fine and it's just a question of load-time overhead <wleslie>if there was some goops-using code and the struct implementation of (system foreign-object) is used, what do I need to do to get my foreign objects treated as classes? <civodul>wingo: my main concern is startup/memory overhead; a secondary concern is side-effects that come with loading GOOPS, for those who do not specifically wish to use it, but it's a vague concern in that i don't know have examples of bad things that could happen <wingo>i think the struct proposal fails to address the goops use-case; e.g. some future guile-gnome written only in scheme couldn't use it effectively <wingo>if you wrap an object system you want to be able to subclass foreign object types <wingo>and wrapping an object system is not that uncommon, unfortunately.. <civodul>but i thought structs would be somehow treated as GOOPS classes when GOOPS is loaded <wingo>you mean in some future? yeah that would be nice <wingo>common lisp has facilities for that i think, not sure tho <wingo>it currently doesn't work tho <civodul>what happens with vtables when GOOPS is loaded? <wingo>i think there's a wrapper class created for the vtable <wingo>scm_class_of on a non-goops struct returns a wrapper class <wingo>whereas it should be able to just return the vtable <civodul>IMO what matters is that one is able to use class-of, define-method, etc. <wingo>so the vtable could be treated as the class <wingo>i don't know -- but subclassing is one other thing <wingo>and you can't (make <subclass-of-foo> ...) on wrapper classes <wingo>because you can't (make <foo> ...) on a wrapper class either <wingo>i mean you can, but there's no way the wrapper class knows how to construct the struct <wingo>it doesn't know the names of the fields, et <wingo>guile doesn't know anything about constructors for raw structs <civodul>what if the wrapper class had a special meta-class to address that? <civodul>i admit i'm fuzzy on the details here <wingo>unfortunately that doesn't work -- there are no classes whatsoever until goops is loaded <wingo>and <class> is a vtable-vtable <wingo>really everything goops starts with <class> <wingo>you could try to half-initialize things from c but then we'd be back where we were, with lots of goops in c... <wingo>much better as it is with goops in scheme <wingo>the thing we could do would be to have a different root to the vtable hierarchy <wingo>i.e. not <class> but <vtable> or something <wingo>it's another project to try to make guile so it has only one vtable-vtable <wingo>i would like to do that, and that would fix the load time issue <wingo>still, 7.5 ms is not that bad, and it will get faster with native compilation <wingo>everyone who cares about speed will be on 2.2 soon enough... <civodul>how can we reconcile the two concerns for this API, at least keeping 2.0 in mind? <civodul>that is, the ability to use GOOPS when writing bindings, and the ability to have the same overhead as with SMOBs <wingo>so for me the 2.0 implementation is a way of allowing new programs to compile with old guile <wingo>if someone is using this api they are writing a new program <wingo>and thus they are probably targetting 2.2 <wingo>maybe that is why i don't feel the importance of the 2.2 performance -- if it works, it's fine, at least imo <wingo>but that is not your perspective it seems <wingo>also in the future i do want to unify the vtable hierarchy <wingo>and make it so that you don't load goops at all when you load (system foreign-object) <civodul>yes, and it's important to keep that in mind, agreed <wingo>but i think the goal of supporting non-goops classes is not impeded by this api <wingo>since it doesn't expose goops functionality to the user without the user having loaded goops to get at the functionality, then i don't see the hazard <civodul>well it does turn a couple of procedures into generics, doesn't it? <wingo>yes but that's not user-visible <wingo>the only way they could know would be if they loaded goops! <civodul>generics are mutable, so that changes the way one must think about the program <civodul>in 2.2, GOOPS would essentially become a requirement <civodul>unless you don't use foreign-objects at all <wingo>*importance of the 2.0 performance <- that's what i meant before <wingo>civodul: ah so i don't see us using this api internally <civodul>i mean, let's assume a world where SMOBs have been entirely replaced by foreign-objects <civodul>in practice, Guile would always be using GOOPS <wingo>i think that world wouldn't come for a while... <civodul>yes, but that's what we're aiming for <wingo>firstly because just running guile wouldn't load anything that creates foreign objects <civodul>yes, but as soon as you'd load C bindings, you'd get GOOPS <wingo>unless we fix goops to understand non-goops vtables <wingo>but tbh that is on the to-do list as well <wingo>so it could be that by the time this world comes into being this issue is fixed; dunno <civodul>or, what about having two variants of the API? one GOOPS, and one non-GOOPS? <wingo>how would the api differ? :) <wingo>i think it would be the same <civodul>one would use make-struct and the other would use 'make' <wingo>so if we fix guile to not have to load goops for foreign vtables we can avoid loading goops when foreign object types are created <wingo>and that can be a change we can do in a stable series <wingo>because it's not user-visible whether we use make or make-struct <wingo>and in fact instances are allocated from c with make-struct <civodul>well if this can be done, i guess the problem is solved? <wingo>this == fixing guile to not have to load goops to create and instantiate foreign vtables <wingo>the problem == the load-time overhead <wingo>because the load-time overhead is already "fixed" to an extent in 2.2 and will continue to improve as well... <wingo>so the q for me is, is the current situation acceptable to you, anticipating this change sometime in the future <wingo>ok talk to you when you get back :0 <wingo>wait a couple minutes for it to finish uploading <taylan>ACTION builds it with guix environment --pure <taylan>should have tried out --container actually :) <nalaginrut>wingo: is it the same with the current master? if so, I think it works for Artanis, and works fine <wingo>nalaginrut: it is current master, yes <wingo>with one commit to mark it 2.1.1 <wingo>did you build guile in the last week? <wingo>i flipped the stack and renumbered a bunch of opcodes <wingo>so you will need to clean all stale .go files <wingo>and most locals are addressed relative to the SP, not the FP <nalaginrut>yes, I encountered some problem ,and it works fine after cleaned something <wingo>that should make native compilation be able to use the vm stack directly <wingo>yeah we will have cached registers only for $rip, $rsp, and one for the current thread, i think <taylan>still building, need to go AFK, laters (wish it didn't take so long to build :-) <wingo>compilation is a little faster now but not a whole lot <nalaginrut>and it's longer when compiling .go modules of Artanis, but looks faster when running ;-) <wingo>if you make -j4 on a recent-ish machine the compilation should take about 50 minutes <wingo>yeah me too, depends on the machine :) <wingo>ACTION wants one of these 2x12 core machines <lloda>wingo: master works w/o issues on both my machines, Ubuntu 12.04 and OS X 10.9 <wingo>i don't have such a machine but it's good to hear there are no portability problems <wingo>btw lloda the "union scm_vm_stack_element" stuff is designed to support unboxed floats on the stack :) <wingo>dunno if you do float things in your work that don't dispatch down to BLAS or whatever <wingo>but that's the goal, to avoid so much allocation when working with floats... <amz3>using guile 2.0 there is no more leak in my script, very strange. <amz3>anyway, I will try 2.1. My script use ffi and assoc (through pure scheme msgpack library) <lloda>but it's usually on the repl or a script where 1s vs 2s doesn't matter <lloda>it'd be great to be able to use f64 with no penalty <amz3>wiii! 2.1 is 5x times faster <amz3>davexunit: hi, your git server is buggy, I don't need it, just saying <rekado>I cloned sly and haunt from there just fine. <amz3>git protocol doesn't work and the website css is absent <davexunit>amz3: thanks. something must have not come up right when linode rebooted the VM after maintenance. <davexunit>the problem is that I don't have an init.d service for the git daemon, and I'm not going to write one because they are terrible. <davexunit>and the CSS issue is some permissions thing I have to look into. <taylan>wingo: make and make check fine here in 'guix environment --pure guile' with a recently updated guix master branch <davexunit>taylan: how about 'guix environment --container' ;) <davexunit>I'll run such a build with an Ubuntu host system shortly <taylan>I also thought I should have used the opportunity to test that :) in fact I think I'll do it now <davexunit>building guile with 'guix environment --container guile-next' right now ***rlb` is now known as rlb
<csed>Or SICP, actually. Although SICP shouldn't be that big of a deal. <dsmith-work>wingo: Latest master built in 'real 95m24.870s' for me at work. <dsmith-work>wingo: I've got one running at home. Yesterday I think it took about 6 hours. Actually timing it today. <dsmith-work>wingo: Thanks for working on getting the build time down. <dsmith-work>ACTION shakes the Fist of Consternation at wingo for not mentioning he was getting married <paroneayea>wingo, yes, it's great to see you back in here. Getting energized about Guile 2.2! <amz3>csed: thanks for poiting this, I more interested in aima tho <csed>amz3: AIMA isn't language specific though. So you should be fine. <csed>It's pseudo-code, mostly. <csed>amz3: Reading it now, actually. Well, once I get off work. <csed>Doing the first set of exercises. <paroneayea>wingo: is the 2.1.1 tarball basically the latest master commit? If so, I'll submit a patch to guix for guile-next to update the version <davexunit>guix environment --container guile-next -- sh -c "./autogen.sh && ./configure && make -j4" <civodul>phase `build' succeeded after 6627.9 seconds <civodul>wingo, mark_weaver: in other news, the web site is ready <civodul>i wonder if we should do anything "smart" in terms of communication <civodul>it seems 2.0.12 is not there yet though, and i would not want to delay that too much <civodul>OTOH if a 2.1 pre-release is ready, we can do that <wingo>dsmith-work: is that a real comparison of build times? 6 hours -> 1.5 hrs? <wingo>sure you didn't do -jN or something? <wingo>i did hopefully improve things recently but you never know <wingo>paroneayea: that tarball is master + a commit that bumps the version <wingo>that i haven't pushed yet because i wanted to check with civodul / mark_weaver <dsmith-work>wingo: Vastly different machines. 1 core 32bit vs 4 core 64bit with -j4 <wingo>not sure what to do in the 1 core case. <wingo>the bootstrap time of guile 2.2 is my one regret of the series <wingo>civodul: so retaking the foreign object topic... <wingo>i do think we will be able to make vtables work as goops classes without wrappers <wingo>but i don't know whether that will make 2.2.0 or no <civodul>so what we do for 2.0.12 remains an open question, no? <wingo>i think it is an open question between us <wingo>i am happy with the situation but you were not, so i wanted to see if what we discussed addressed your concerns or not :) <wingo>i agree that a world in which everything is foreign objects shouldn't be a world in which goops is loaded <civodul>but for 2.0.12, we'd have to live with GOOPS being loaded, right? <wingo>if we stuck with the current implementation, yes <wingo>probably also, depends on how long 2.1.x goes on <stis>yeahh bootstrapping is finished <wingo>which is another topic -- what is our schedule for 2.2.0 and what do we want to get in <civodul>i think we have everything we could ever dream of, no? :-) <civodul>as far as the compiler and VM are concerned, at least <civodul>my inclination would be to "stop here" for 2.2, and do lots of testing <wingo>yeah that makes sense to me too <wingo>dunno if we should incorporate libgc though <civodul>in the 1.9 series we added lots of new stuff each month <wingo>to allow us to gc mmap'd elf segments <civodul>here it might be best to not do that <civodul>wingo: for when one unloads a module? <wingo>civodul: well currently when you compile something, you effectively add an elf image to your address space <wingo>in master those images are never gc'd <wingo>because we don't know what points to them -- closures, static data, heap data, etc <wingo>it's not the compilation that's the problem, it's loading the compiled data :) <wingo>whether via mmap or via malloc <civodul>i'm not familiar enough to suggest anything useful here <wingo>i think we need to start thinking about incorporating the bdw-gc into our source tree <wingo>and modifying it to suit our needs <civodul>if each load translates into an mmap, that's not good <wingo>it could be an mmap or a malloc <civodul>one of the points of using it was to offload maintenance of the beast ;-) <wingo>owning our own gc does seem like a good idea tho... <civodul>IMO there has to be a significant benefit to outweigh the cost <civodul>so i would first check whether libgc's API can be changed to do what we want <civodul>(to address this particular problem) <stis>ACTION maintains an own bdw-gc for spanking gc into prolog <stis>only fordie hard hackers :-) <civodul>so for 2.2.0, i don't know what's best <wingo>another thing about libgc is that it's hard to reason about memory usage <wingo>if it were internal to guile we could do better at providing memory-limited sandboxes <civodul>but we need to distinguish between what we must have for 2.2.0, and the would-be-nice <stis>2.1.1 compiled just fine on my box :-) <wingo>civodul: should i push the 2.1.1 tag? <civodul>wingo: could you email guile-devel about that, rather? <civodul>like "i'd like to tag commit XYZ as 2.1.1" <wingo>well i have to push a commit too to update GUILE-VERSION <civodul>after all the work, we can wait for a couple more days ;-) <civodul>i'd like to hear what mark_weaver has to say <wingo>maybe i can slip in unboxed floats into 2.2 <civodul>but yeah, if that can be done this week, that's great <civodul>preparing a release requires schizophrenic behavior ;-) <wingo>haha i won't put it into 2.1.1 :) <wingo>the other thing that would be nice to fix for 2.2 would be ports... would be nice to allow a blocking port to suspend a user-space thread <wingo>scheduler etc to be implemented later; just need the ability for scheme to work on port buffers <paroneayea>wingo: great... well, I'm updating guile-next in guix now <paroneayea>compiling and making sure all is well before I push the patch <wingo>so working on ports doesn't mean you have to bounce to C and back again <paroneayea><civodul> i think we have everything we could ever dream of, no? :-) <paroneayea>wingo: I agree with civodul's general impression: the compiler/vm is at an advanced state, getting it into users' hands would be good <paroneayea>wingo: I keep finding myself reading the docs of Guile and switching to the VM infrastructure section and perusing and thinking, oh right! I should be reading master :) <paroneayea>wingo: btw, did you see my bug about the sluggish elf stuff? I wonder about your thoughts <paroneayea>I think the thing that was trigging the regular elf parsing was using (receive) and (values) <paroneayea>wingo: the tl;dr is that I was surprised to find my library slower in guile 2.2 than in 2.0, and it seems to be because of all the arity checks from using multiple value return I'm hitting <wingo>it's checking for thunk? on something <paroneayea>wingo: I can point you to my code if you would like to test / reproduce this <paroneayea>I also think it shouldn't hold back the release probably <paroneayea>but it's something I thought you should be aware of <wingo>make-promise is evidently checking for thunk? on its argument <paroneayea>oh right it might have been on promises, not the multiple value return <paroneayea>it's been a while since I looked at my own bug :) <wingo>probably it should punt and not check the arity of the procedure <paroneayea>wingo: basically I take it that checking arity is a lot more expensive now than it used to be? <paroneayea>wingo: anyway. I hope I didn't distract you terribly with this <paroneayea>but I thought it might be something you'd like to be aware of <wingo>yeah we should probably remove those checks <wingo>or, i guess we could parse the code of procedures <wingo>paroneayea: not sure :) in the olden days they existed in the heap-allocated procedures as a field <wingo>not sure what the story is in 2.0 <wingo>i think in 2.0 there's a "meta" field in procedures that is a thunk to call to get meta info <wingo>it's a little closer, you don't have to go grovelling through elfie things <paroneayea>wingo: maybe attaching arity to the procedure for "fast access"? <paroneayea>wingo: because of Don't Repeat Yourself reasons, or? <wingo>yeah you don't want to do that. you want side tables that you can strip from the binary. <wingo>side tables that aren't usually loaded... <wingo>but parsing the bytecode to determine the arity is not so bad <paroneayea>if they're stripped from the binaryb, won't it hit the same problem in binary form? <wingo>or interpreting the bytecode with a separate vm ;) <wingo>well if they are stripped then you don't know <wingo>like is this a thunk? (lambda _ #t) <wingo>what about (lambda () (error)) <wingo>you have to dynamically check the argument count anyway in code when a proc is invoked, and handle it appropriately <wingo>so an early check doesn't make sense <wingo>the question 'does this proc apply to these arguments' isn't limited to just arity either <paroneayea>somewhere in the distance, a dog barks "typed guile"! (???) <wingo>so (make-promise (lambda (invalid) #t) is indistinguishable from (lambda () (error)) <wingo>haha yeah, much of the cost of gradual typing is precisely this :) <wingo>especially wrapping higher-order typed functions <paroneayea>wingo: so, the arity check really isn't helpful in the promises anyway, because that's no guarantee that things will work any better anyhow <paroneayea>wingo: I don't think I'd be at fast at doing that :) <amz3>ACTION looks for a small/micro/nano web framework, something that provides routes... <davexunit>amz3: you can write your own router using 'match' <paroneayea>yes "match" turns out to be a pretty efficient basic router <amz3>I split the path, and then go match? <davexunit>(split-and-decode-uri-path (uri-path (request-uri request))) <davexunit>beats the pants off string-based routing from in other languages <davexunit>stringly typed data is no way to go, especially in Scheme. <amz3>yes... I was again thinking too complicated for scheme <amz3>I don't know why, I always want to build this hierarchical views thingy <davexunit>well, when literally *everyone* uses string-based routing, it's easy to think of doing the same thing. <amz3>I think match will be good enough <davexunit>I think some additional syntax on top of match would allow for a nice routing hierarchy <davexunit>if every URI starts with /user/<id>, it would be nice to factorize that bit. <amz3>I am always doing things top-bottom <amz3>and forget about the other away <paroneayea>wingo: btw, if you do remove that check, let me know. But I can also try removing it, if you can tell me where it is! <csed>So I'm curious. If I have an (if ...) and there's no else clause specified, it returns unspecified. I was doing this in hopes of just not getting a return. For instance, I'm mapping a lambda function over a list to filter out some elements, but instead of the filtered list I get (a b #<unspecified> ...) etc. <daviid>csed: see filter-map (srfi srfi-1) <csed>daviid: Brilliant, works like a charm. Cheers. <csed>As a side note. Is it possible to get guile to find modules in the CWD? Or maybe to symlink the CWD to the module folder? And second question, can you export everything in a module or do you need to specify it per definition via #:export? <daviid>csed: (1) yes but you need to add the (getcwd) to %load-path before to import modules, and (2) you must specify all export yes <csed>daviid: Alright, cheers. <dsmith>sneek, later tell wingo: real 305m9.874s <dsmith>sneek, later tell wingo: That was for "time (git clean -dxf; ./autogen.sh && ./configure && make && make check)" <dsmith>sneek, later tell wingo: v2.1.0-2470-ge5bccb6 <sneek>rlb was here Oct 26 at 02:58 am UTC, saying: ). <amz3>csed: it depends of what you need exactly but if you run something.scm with: guile -L `pwd` something.scm <amz3>`pwd` will be in %load-path <amz3>you can also use GUILE_LOAD_PATH or something like that <csed>amz3: So an (add-to-load-path (getcwd)) wouldn't work? <amz3>In my situation, every module can be started with `guile` command, so I don't want to tweak the load path in each of them