***karswell` is now known as karswell
<rlb>does anyone recognize this failure? <rlb> Running 00-initial-env.test <rlb> Running 00-repl-server.test <rlb> FAIL: 00-repl-server.test: repl-server: simple expression - arguments: (expected-value "scheme@(repl-server)> $1 = 42\\n" actual-value "$1 = 42\\n") <rlb> Running 00-socket.test <rlb>Looks like powerpc had the same problem, whatever it is. ***mario-go` is now known as mario-goulart
<civodul>wingo: re _IO*, i can see two issues: <civodul>1. it brings very little but annoys developers in that there's no way to write code that runs with both 2.2 and 2.0 without warnings <civodul>2. using symbols instead of variables means that you have no compile-time warnings if you use the wrong symbol <wingo>re dev annoyance, point (1) is inevitable in general i think <wingo>not quite inevitable but close <wingo>like, there will be things that we want to deprecate in 2.2, basically. dunno <wingo>we could use (buffer-mode none) i guess <wingo>but in 2.0 that returns a symbol <wingo>i really hate the names _IONBF or whatever that thing was tho :) <wingo>so we should change in any case :) <wingo>do you have any ideas about how to use not-terrible names? <wingo>we could un-deprecate _IONBF of course <wingo>i was bothered that we were following libc names and values when libc has an entirely different set of constraints, conventions, and a different implementation that we're not using <civodul>wingo: initially setvbuf was just a bindings of that C function, so in that case it makes sense to follow libc IMO <civodul>using R6-style enums would be inappropriate here IMO, because we've never done that for core interfaces <civodul>maybe we could just define and advertise aliases for _IO*? <civodul>like (define buffer-mode/unbuffered _IONBF) <civodul>dunno, just trying to be creative ;-) <wingo>i wonder (and this is not a vote against :) about namespace bloat tho <wingo>one day we should have all of this in modules of course :) <civodul>or we could indeed start using R6-style enums <wingo>i think we can do it post-2.2 maybe <wingo>if 2.2 gets modules for things, and those modules are used by boot-9 <wingo>i did that for threads a couple days ago <wingo>anyway the migration strategy would be to deprecate using bindings without importing the module <wingo>i took a look at hydra after making that change but it wasn't done building; have to check again... <civodul>i think annoyance-avoidance is important: as a developer you don't want to change your code and write a compat layer and everything just because of "ugly names" :-) <manumanumanu>I am sad. I am worknig through project euler in scheme, and I did something that I thought would be fast, however it is slow. Then I tried a naive brute force thing, and it is faster. Can someone maybe explain why? <manumanumanu>both work, of course, but the one I thought would be fast runs in 0.5s, and the one I thought would be slow runs in 0.1s <manumanumanu>and increasing the nth prime to 100000 yields an even bigger performance hit. 3s vs 50s <manumanumanu>oh... I got it down 0.1s by not using destructive operations to count the number of primes... <thomasd>manumanumanu: not a scheme expert, but append! will have to traverse the list up to the final element <thomasd>so building up a list of n elements by repeatedly appending becomes order n^2 I think? <manumanumanu>the thing is, building the list using cons, I would start trying to divide using the last found prime (large) and then work myself downwards. <manumanumanu>thomasd: I solved it in a good way. Instead of append! I keep a pointer to last-cdr and simply use set-cdr!. Still mutating the list, but without having to go through each element <manumanumanu>or rather, sjaaman over in #chicken pointed it out to me <rekado>I find myself in a situation where I’d really like to use Emacs-like dynamic binding to override a procedure for the duration of one expression. <rekado>i.e. without the cooperation of the affected code. <rekado>is there a “temporary” variant of “module-set!” that only modifies a binding for the current scope? <davexunit>rekado: no, but if you look in (guix tests) I wrote a macro called 'mock' <rekado>it just so happens that I need this for Guix :) <rekado>I’m having trouble with match again. Is it possible to match multiple alist entries in arbitrary order? <rekado>currently I’m using something like (match expr ((_ *** ('key a ...)) a)) <rekado>but I seem to only be able to use this once. <amz3>what should we do to make guile more awesome? <amz3>what can I do to make guile more awesome? <OrangeShark>amz3: maybe more awesome software using guile and growing the community? <jmd>amz3: To make something awesome you need to fill it with awe. <jmd>What kind would you like? Iron? Gold? Uranium? ***nafai1 is now known as Nafai
<joolean>I was wondering whether I could interest you in applying that Ecmascript patch I submitted a little while ago <ArneBab>amz3: maybe awesome: I updated my three witches script. It now allows for natural script writing <ArneBab>^ that’s the actual code, though Enter must come before the first use <ArneBab>it allows for inline-code via unquote - i.e. ,(+ 1 2) <rlb>I'll delve later, but just wanted to see if it was familiar to anyone here. <rlb>(Click "Build-Attempted" for the log.) <civodul>ERROR: ecmascript.test: compiler: new Object; - arguments: ((misc-error #f "~A ~S" ("unrecognized tree-il" (call (@ (language ecmascript impl) new) (toplevel Object))) #f)) <civodul>i naively thought that this part hadn't changed between 2.0 and 2.2 :-) <civodul>so i need to update/build my 2.1 tree, which will take a bit of time :-/ <lmat>construct a pair. got it. <civodul>joolean: checked and pushed, thanks :-) <joolean>civodul: Thank you! I might poke at our ES a bit more. Hoping to get to a point where we can run some of the “official” ES test suite