IRC channel logs


back to list of logs

<flatwhatson>Aurora_v_kosmose: re: 10x slower reading from pipes, there's actually a bug in guile around that which should be fixed in the next release (
<flatwhatson>mfiano: this should fix your "guile for quick-launch shell scripts" use-case too
<flatwhatson>(assuming that involves some degree of shelling out)
<Aurora_v_kosmose>I'm having some difficulty reason about the difference between let-binding something locally and parameterizing.
<Aurora_v_kosmose>Ah. Nvm
<Aurora_v_kosmose>Some quick test disamguated the behavior.
<flatwhatson>parameters are a special kind of storage, the manual covers them pretty well
<flatwhatson>but the name is a bit overloaded with "the parameters to a function", a completely separate concept
<Aurora_v_kosmose>One of those sanity-check moments I've got sometimes...
<mfiano>flatwhatson: Ah great, thanks
<mfiano>Aurora_v_kosmose: parameters are like special variables in CL. I have seen you around those parts a bit :)
<mfiano>And I agree that the naming was a very poor choice.
<daviid>sneek: later tell akirakyle, i found the cause and pushed a fix, to the devel branch - with this fix, the 'drawing widget' blog example you wanted to try is working fine here - - so now you may draw using g-golf :), have fun and let me know if you find some other problems ... tx for the report
<flatwhatson>the naming of parameters is a scheme thing, guile is just following convention:
<mfiano>flatwhatson: I am aware
<daviid>sneek: later tell akirakyle here is a screenshot for the above code ...
<Aurora_v_kosmose>Does Guile handle docstrinsg in any particular way?
<Aurora_v_kosmose>Hm... Vhash vs Hash tables?
<mfiano>it depends on what you need. They have different time complexities.
<Aurora_v_kosmose>Rapid accesses, mainly.
<mfiano>and how will you be doing these accesses?
<mfiano>Then vlists sound like a good solution. Like arrays, their contents are packed contiguously in memory, helping cache locality when accessing adjacent memory.
<mfiano>Though do check the disadvantages in the manual. More space, slower to allocate, etc
<flatwhatson>guix uses vhashes a lot for things like building unique sets of packages
<flatwhatson>which are "small" as far as hash-table sizes go, holding at most a few hundred entries
<flatwhatson>presumably there was some performance testing done to choose vhashes for that use-case
<mfiano>ArneBab: What is -C?
<mfiano>Oh I see. I didn't realize `guile -h` has switches listed that the manpage does not.
<mfiano>ArneBab: I cannot get your wrapper to work. I get an error in ice-9/read.scm
<mfiano>ice-9/read.scm:126:4: In procedure read-expr*: #<unknown port>:1:15: unexpected end of input while reading quoted expression
<mfiano>Not sure if I did something wrong or I ran into a bug.
<yarl>Hello guile.
<dthompson>hello yarl!
<yarl>I am playing with some sources. I tried to move some (syntax-rules) macros from one file to another, to make them available to another new file. The problem is that now, some others macros that depend on them (in the original file) fails : during the compilation, I got "source expression failed to match any pattern in form ...". Any idea?
<dthompson>the macro needs to be in scope in all places that it's used
<dthompson>ACTION needs to go afk
<yarl>I properly #:export in define-module.
<lloda>if you're using the macros in some other macro it might be an eval-when issue
<yarl>lloda: I thought it might be this kind of stuff. Could you give me some more insights please? What and when should I eval-when?
<yarl>The source is guix if that can help and the macros I am trying to move are 'define-enumerate-type', 'operation-id' from guix/store.scm to guix/store-protocol.scm.
<yarl>in the new module, I export operation-id and in (guix store) I #:use-module (guix store-protocol).
<yarl>in (guix store) some macro use operation-id.
<yarl>I find it hard to create a minimal example.
<lloda>have you checked if the use of operation-id works in the repl
<yarl>lloda: What do you mean/how I do that? I didn't write any macro, I just moved it.
<yarl>ok, in guix sources : `guile -L .` then `use (guix store-protocol)` then `(operation-id valid-path?)` returns 1. So that's ok.
<lloda>that looks like it could really be eval-when then. Have you checked
<lloda>i think it gives a clear example
<yarl>lloda: Yes I already read that but that's not yet crystal clear to me.
<lloda>yeah imported defs should be available before expand so idk. The example is for needing to eval before expand
<yarl>lloda: I could get a minimal working example. Unrelated with eval-when.
<yarl>May I share?
<yarl>lib.scm :, main.scm : guile --no-auto-compile -L . main.scm. Runs perfectly. Replace main.scm with Fails. replace again with runs.
<yarl>So, there is a difference between #:export and (export ...)?
<lloda>that might be a bug
<lloda>i don't think there should be any difference
<lloda>when i've done similar things, i've put the export in the define-like macro, maybe define&export-xxx, because it saves you from having to repeat the name
<lloda>still i don't think it should matter if you #:export instead
<yarl>lloda: Moreover, when everything is in a file I can use (operation-id valid-path?) after (define-operation (valid-path)). I can't when it's separated.
<yarl>(simple-format #t "~S\n" (operation-id valid-path?)) for example.
<yarl>That's very odd I think.
<yarl>I'll post my questions on guile-devel.
<a12l>Is it common to use the name loop when creating named let expressions?
<a12l>When you write a function that's recursive
<a12l>To me it sounds so "imperative", which is far away from recursion
<old>`loop' or `lp' yes
<Aurora_v_kosmose>You can of course disregard that convention if you want.
<a12l>I'll try to keep to conventions, just want to make sure that I follow is actually conventions :)
<mwette>I used to use `iter' but now use `loop' (to follow convention).
<lloda>using loop for named let is like using i for an integer, or x for a real, or l for a list
<lloda>it can be ok, or there can be a better name
<dsmith-work>UGT Greetings, Guilers
<count3rmeasure>Good morning!
<graywolf>Hello, does guile (or scheme in general) have some procedures for reading/producing binary strings? Something like (un)pack I know in ruby (
<sneek>Welcome back graywolf, you have 1 message!
<sneek>graywolf, rekado says: 15 lines of Guile:
<old>graywolf: Look at module `(ice-9 iconv)' for `string->bytevector' and `bytevector->string'
<old>It's also available in `(rnrs io ports)'
<old>I'm not sure if that's what you want. I don't know any Ruby
<dsmith-work>graywolf: Tht
<dsmith-work>s like the Python pack/unpack ?
<dsmith-work>Hmm. Not directly. But I'm pretty sure there are ways to get binary ints/floats/etc to/from bytestrings.
<dsmith-work>(I just don't remember right now)
<dsmith-work>'s code to read/write elf files, so *some* kind of binary access exists somewhere.
<dsmith-work>graywolf: This is kind of what you are looking for:
<dsmith-work>External package though.
<graywolf>Thanks for the link :) bytevectors looks like they should be useable at first glance (albeit bit more low level then I hoped for), if that does not work out, I'll use the bytestructures library
<dsmith-work>graywolf: Also see
<ArneBab>mfiano: can you pastebin your file? This sounds like details that are easier to see with the code at hand.
<avp>Hello Guilers!
<avp>I came across the 'pk' procedure in Guile (e.g. it is used in Fibers examples) and it is used in Guile manual once, but there's no information about it in the manual.
<avp>In Guile REPL its value is #<procedure peek stuff>
<dthompson>avp: it's a handy little secret thing. it will print out all the arguments you pass to it and the return value is the last argument. handy for debugging.
<avp>dthompson: Thanks, I see! It is useful indeed, just a little bit too sneaky, I think. :-)
<dthompson>it should be advertised in the manual, because maybe it wasn't intended for everyone who uses guile to use it but everyone does :)
<daviid>i find peek to 'space' consumming, using ;;; (instead of ;;) and to many newlines, so i wrote mine based in it ofc, called dimfi - dimfi is a word in wallon (wallonia - Belgium) that means, sort of 'hey, you! :) - fwiw, it's in all project i maintain, in g-golf ofc ...
<mwette>graywolf: what about this?
<mwette>e.g., (define data (pack ">2Hd" 3 22 34.0)
<tremon>from (fold-right cons* '() '(a b c) '(1 2 3 4 5)) => (a 1 b 2 c 3)
<tremon>but when I run this in guile, the result is (a 3 b 4 c 5)
<tremon>is there a known difference between guile scheme and what says?
<tremon>(verified in Debian's guile 3.0.5 and Guix' 3.0.7)
<daviid>tremon: fwiw,
<stis>Hello guilers!
<dsmith-work>Heya stis. How goes the Python hack?
<stis>Ok, I'm experimenting with a new kind of continuation (one shot), genrators are 2X faster than Cpython's
<stis>using those
<stis>essentially when you call this, you crate a new stack and use that and then optimize that use case
<stis>But this is for a modified guile VM
<stis>So this is what can be done if wingo put some work on that
<stis>dsmith-work: ^^
<stis>I also rebased the python dictionaries onto my new hash infrastructure which allow custom hashes to be as fast as native one. Much better than guils hashx
<stis>unfourtunately it is impossible to base guiles hashx otnop of that one as guile's leak internal implementation details by using a custom assoc in stead of a custom equal
<stis>That hash implementation I'm pretty proud over as it is a well designed approach that uses both scheme and C in a nice way
<stis>Well worth to study if you ask me and it is a library that one compiles and uses and does not need any modifications of guile altghough I do have some VM ops top imporve the speed but it's optional
<stis>I do need to separate things into more fine graned packages ...
<stis>maybe will be my potluck project later to do this refactorizatoin
<stis>Another thing is that I imporved the speed for a lot of for loops, also my python for loop macro has been worked on
<stis>fixed bugs as well
<stis>I plan to improve the speed of dictionare handling in for loops e.g. ducuce that x is used as a dictionary and make sure to ise (with-hash ((x : ref set rem)) code ...)
<stis>This means that you can unpack data structures for the hash. Also looping over dictionaries is now much faster with the new hash
<stis>infra structure as it is just looping over an array
<stis>and the looping is done in insertion order which is according to the python spec
<stis>Lot's of good stuff
<stis>If peaple poke me I can make a new release ...
<yarl>Is Maxime here?
<mfiano>ArneBab: Thanks for the offer, but let's hold off just a bit first. dthompson and I are going to sit down tomorrow night and try to figure out why guile's load path is giving me so many headaches.
<mfiano>stis: That sounds very exciting. Congrats!