IRC channel logs
2023-01-04.log
back to list of logs
<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. <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 <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 - https://paste.rs/YFP.scm - so now you may draw using g-golf :), have fun and let me know if you find some other problems ... tx for the report <mfiano>it depends on what you need. They have different time complexities. <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>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>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 <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>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>So, there is a difference between #:export and (export ...)? <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 <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 <sneek>Welcome back graywolf, you have 1 message! <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>Hmm. Not directly. But I'm pretty sure there are ways to get binary ints/floats/etc to/from bytestrings. <dsmith-work>'s code to read/write elf files, so *some* kind of binary access exists somewhere. <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 <ArneBab>mfiano: can you pastebin your file? This sounds like details that are easier to see with the code at hand. <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>e.g., (define data (pack ">2Hd" 3 22 34.0) <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 schemers.org says? <tremon>(verified in Debian's guile 3.0.5 and Guix' 3.0.7) <stis>Ok, I'm experimenting with a new kind of continuation (one shot), genrators are 2X faster than Cpython's <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>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>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>If peaple poke me I can make a new release ... <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!