<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 <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 <wingo>civodul: doesn't get-bytevector-n! do that? <civodul>wingo: for an unbuffered port it always returns at most... 1 byte <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) <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) <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>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) <rekado>I was going for R markdown style code blocks, and the separator there is ``` <wingo>probably we should allow guile to map extensions to reader options or something <wingo>or default languages (.el for example) <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. <davexunit>maybe just to clarify: is "instruction explosion" a phenomenon happening in the 2.2 stable series? <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. <davexunit>lists.gnu.org/archive/html/bug-guile/2018-01/msg00005.html <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 <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>the continuation in wisp needs higher indentation in the continuation line <rekado>line 18 is where I’d like to support a line break <rekado>#---{python} is a reader macro that ends with “---” <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. <civodul>ArneBab: does wisp have special syntax for (list a b c) ? <ArneBab>ah, so you want #--- on the beginning of the line? <civodul>ah yes, but i meant specifically for building lists <civodul>[ a b c ] would be nice, for example <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 #--- .... ) <ArneBab>civodul: wisp doesn't add anything there which isn’t in scheme <ArneBab>civodul: that’s to keep the scope small <civodul>it could have a wispy "read syntax" thing to add this <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 ;-) <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? <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>let me know then , I'll re read the site <daviid>ArneBab: where you have lot's of examples (wisp modules...) <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>python does not mind starting with an empty line <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>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