IRC channel logs


back to list of logs

<manumanumanu>amz3: chez's ffi lets you use bytevectors directly in C functions. Even strings, which it automatically converts to bytevectors (using utf8). That is quite nice :D
<manumanumanu>ZombieChicken: I have used guile-ncurses with guile-2.2
<rekado>I’m playing with wisp now.
<rekado>can I mix wips and regular scheme modules and have Guile do the right thing for files written in wisp?
<rekado>e.g. by using a “language cookie” comment somewhere?
<rekado>for now I’ll just compile the wisp code to bytecode.
<civodul>hmm, looks like we don't have a way to read as much as possible from a port without blocking
<civodul>like read(2) would do
<wingo>i think we do
<wingo>ACTION looks
<rekado>wisp is great
<wingo>civodul: doesn't get-bytevector-n! do that?
<civodul>wingo: for an unbuffered port it always returns at most... 1 byte
<civodul>wait, sorry
<civodul>get-bytevector-some returns at most 1 byte
<civodul>get-bytevector-n! blocks until it has everything you asked for or EOF is reached
<rekado>I’m playing around with the Guix workflow language and using the wisp with some extra syntactic sugar makes the language look very … “modern”, i.e. very close to what users of other workflow languages might expect.
<civodul>internally, only scm_i_read_bytes does like read(2)
<civodul>rekado: modernity! :-)
<wingo>humm, there should be something that's closer to read... humm
<wingo>i would look to r6rs binary ports specification, see which function looks like it should do what you want, and then see if guile's implementation is correct
<wingo>get-bytevector-some is probably doing the right thing fwiw
<civodul>i think get-bytevector-some should be like read(2)
<civodul>but for unbuffered ports it's not
<civodul>let me see why that happens
<wingo>i think it's probably just because an unbuffered port really is a single-byte-buffered port
<wingo>and so it is taking 1 byte to be the default buffer size, the default read size
<wingo>and so it fills that buffer and gives it to you
<civodul>oh right, it calls scm_fill_input, so it fills its 1-byte buffer
<civodul>what we'd need is a get-bytevector-some! procedure, so the user can provide a buffer of the size they want
<wingo>or maybe if the port buffer is 1 byte, then get-bytevector-some! could default to e.g. 2048 bytes or something
<wingo>calling the port's read functions directly in that case if the port buffer is empty
<wingo>that way all users of get-bytevector-some would get more bytes at a time, which is probably the right thing
<civodul>sounds reasonable, yes
<civodul>i've emailed the details to bug-guile
<wingo>ArneBab: rekado is enjoying wisp :)
<rekado>civodul: appearing “modern” is somewhat important to attract bioinfo people. When something looks like yaml (is this all it takes to be “modern”?) it’s more likely to get a chance.
<civodul>rekado: actually i wanted to put a wisp package definition on the guix-hpc web site for instance
<rekado>we can’t do that when it takes too much extra effort to get wisp to work with Guix
<rekado>for example, (guix discovery) looks only for .scm files, and would ignore .wisp files.
<rekado>is there a “safe” way of registering a reader extension?
<rekado>I have a file in which I do (eval-when (compile eval) (define the-reader …) (read-hash-extend #\\` the-reader))
<rekado>when I compile modules that use this module, however, I get a crash because for some reason this reader is used on my own code.
<rekado>and that’s even though that module does not contain “#`” at all.
<civodul>wingo: i've posted a tentative patch
<civodul>rekado: re .wisp, good point; we could fix it though
<civodul>rekado: note that #` is already taken (quasisyntax)
<civodul>so it's a bad idea to register it
<rekado>oh, you’re right :-/
<rekado>I was going for R markdown style code blocks, and the separator there is ```
<rekado>I guess #- is still free…
<civodul>i think so :-)
<wingo>civodul: some nits :)
<wingo>probably we should allow guile to map extensions to reader options or something
<wingo>or default languages (.el for example)
<dsmith-work>Wednesday Greetings, Guilers
<davexunit>wingo: did you see my bug report about float unboxing in 2.2.3 by any chance? trying to understand if it was an intentional change or not.
<wingo>davexunit: no i did not
<davexunit>okay, no worries. just checking :)
<davexunit>maybe just to clarify: is "instruction explosion" a phenomenon happening in the 2.2 stable series?
<wingo>davexunit: no that's in 3.0
<wingo>in master
<wingo>it might make things slower until we add a jit, because although the total amount of work will be lower, it will be done by more instructions, and in the interpreter we have a significant per-instruction cost
<davexunit>wingo: okay thanks for the clarification. I thought this was the case but wanted to make sure.
<davexunit>in that case, I believe that the performance regression I found in 2.2.3 is a legitimate bug.
<rekado>ArneBab: in wisp I’d like to break a line and continue it in column 0 of the next line. Is this possible?
<civodul>rekado: i'll need your examples for the FOSDEM talk :-)
<rekado>civodul: the GWL with wisp examples?
<rekado>will send them to you once Roel is willing to accept my changes.
<davexunit>civodul: oh you're talking at fosdem? I thought all the guix talks got rejected this time around?
<civodul>davexunit: i'm giving a talk in the HPC devroom, and cbaines is giving one in the container devroom i think
<civodul>two rejected, two accepted
<davexunit>oh cool
<davexunit>that's better than I thought
<civodul>yeah not too bad! :-)
<ArneBab>rekado: that's not possible because it would break the core concept of representing parentheses by indentation
<ArneBab>rekado: to simulate it, you'd have to create a macro which assembles the line step by step
<rekado>ArneBab: hmm, that seems too messy. I guess I can live with keeping things on one line.
<ArneBab>rekado: or wrap it into parentheses
<ArneBab>rekado: what do you need?
<ArneBab>the continuation in wisp needs higher indentation in the continuation line
<ArneBab>proc arg1 arg2
<ArneBab> . arg3 arg4
<rekado>ArneBab: here’s what I’m currently working on:
<rekado>line 18 is where I’d like to support a line break
<rekado>#---{python} is a reader macro that ends with “---”
<civodul>inline python, woo :-)
<rekado>civodul: and inline R!
<rekado>it’s a mess, but it’s also convenient
<ArneBab>rekado: if it adjusts the reader, wisp shouldn't even see it, just like it does not see linebreaks in parens
<ArneBab>the example looks really cool, by the way!
<rekado>ArneBab: this already works, but I would like to be able to break *before* the reader macro.
<rekado>i.e. start the line with #---
<rekado>thanks :)
<civodul>ArneBab: does wisp have special syntax for (list a b c) ?
<ArneBab>ah, so you want #--- on the beginning of the line?
<civodul>that would be handy
<rekado>ArneBab: exactly.
<ArneBab>civodul: you can use ' a b c
<ArneBab>(start the line with ')
<ArneBab>that’s like '(a b c) then
<civodul>ah yes, but i meant specifically for building lists
<civodul>[ a b c ] would be nice, for example
<civodul>as in Python (?)
<ArneBab>rekado: the only thing I se would be to use something like an identity function and put a ( on the indented line
<rekado>civodul: I was thinking of letting the “process:” and “workflow” macros abstract away the list building.
<ArneBab>rekado: procedure (identity \\n #--- .... )
<rekado>I see.
<ArneBab>civodul: wisp doesn't add anything there which isn’t in scheme
<civodul>yeah, sure
<ArneBab>civodul: that’s to keep the scope small
<civodul>it could have a wispy "read syntax" thing to add this
<civodul>yes, that makes sense
<ArneBab>yepp - but that syntax would also be useful for non-wisp scheme
<civodul>but adding sugar is very tempting in this setting :-)
<ArneBab>I consider that as a trap the readable folks fell into
<civodul>i don't feel the need for syntactic in Scheme, but in wisp it seems to be an expectation ;-)
<civodul>readable has extra syntax?
<ArneBab>not for lists, but for other structures, like << >> for double parens
<daviid>ArneBab: when someone writes a module in wisp, can we rewrite it in scheme? so it would produce a module, perfectly indented in scheme?
<ArneBab>daviid: yes
<daviid>I mean is there an automatic way to do it?
<ArneBab>daviid: guile wisp.scm MODULE.w > MODULE.scm
<daviid>ArneBab: cool! then I suggest you add all the scheme modules next t the wisp modules you wrote I can't reember where :)
<ArneBab>wisp.scm acts on the pure text, so it even keeps the comments
<ArneBab>daviid: I’d like to publish the cool stuff of that as scheme
<daviid>ArneBab: so I do wisp -> scheme, opens in emacs and it'd all indented as if I firt wrote it usng emacs
<ArneBab>daviid: if you indent like that in wisp (which you should), then yes
<ArneBab>daviid: and if not, scheme is very easy to automatically reindent
<daviid>ArneBab: I have difficulties to read wisp, but i was interested by some of the odules you worte, then I disisted because it was not in scheme (so to speak)
<ArneBab>the tarballs ship a wisp.scm which allows you to do that automalically
<ArneBab>so you can even skip the bootstrapping for that
<daviid>ArneBab: ok, but on that site of yours, it would be nice to have both afiles, imo
<daviid>going afk, bbl
<ArneBab>I can do that, yes
<ArneBab>daviid: do you mean bitbucket?
<daviid>let me know then , I'll re read the site
<daviid>ArneBab: where you have lot's of examples (wisp modules...)
<ArneBab> ?
<rekado>note that if you use reader macros you have to load them first or wisp.scm won’t do the conversion correctly (as in my example)
<daviid>ArneBab: yes there, it would be nice to have both the wip and the scheme versions, imo
<ArneBab>rekado: reader macros could be a problem for wisp.scm, since that does not use the reader … it’s either keeping comments or using the reader
<ArneBab>rekado: argl, that’s a complication - will need manual tweaking on that one
<ArneBab>(except if you go for the (identity route - then it will be seen as inside a paren )
<rekado>while the identity trick is nice I feel that it pushes the amount of syntax over the threshold.
<rekado>admittedly “#---{python}” is already a lot of syntax
<ArneBab>why not the #---{\\npython}?
<ArneBab>python does not mind starting with an empty line
<rekado>I’m mimicking Rmarkdown syntax
<rekado>for embedded code blocks it uses this syntax: ```{language}\\ncode…\\n```
<rekado>but I guess I could ignore whitespace before “{”, which wouldn’t look too bad.
<ArneBab>ah, now I understand (took a while)
<ArneBab>yes, I think having {python} at the same indentation as the code would be useful to make it clearer where the code starts and ends
***spk121_ is now known as spk121