darth-cheney: hello all, is there some built-in function or set of functions I can use to compute CPU usage as a percentage every N number of seconds or something like that? daviid: sneek: later tell dthompson same here, since switched to guile 3, and the latest geiser, not sure which causes the problem- if you find a solution, let meknow ... sneek: Got it. tohoyn: darth-cheney: what about statprof? stis: Tja guilers! manumanumanu: Tja stis stis: whats up manumanumanu: *: stis is wotking with binary serializers and deserializers stis: https://gitlab.com/tampe/stis-data/ rlb: mfiano: fwiw, recommend reporting non-debian bugs "here", i.e. bug-guile@gnu.org since they'll just have to be forwarded otherwise. Sheilong: I am appending items to a list with append! however it is not making any effect to the list. Sheilong: The list is defined in the body of a let statement and the value is appended in another let nested to this one. Sheilong: I wrote a minimal example to show what is going on here https://paste.ofcode.org/wdjEUWbyVYwgBAbvfaS6pC Sheilong: append! is not mutation the list. I don't know what I am doing wrong here lloda: that isn't how append! works. The appended list is the return value lloda: https://srfi.schemers.org/srfi-1/srfi-1.html#append! lloda: the argument might get modified or not. You use append! instead of append when you don't care what happens to it, that's the only difference Sheilong: lloda: At least here it seems to modify the list if there is already elements on it. If the list is empty it does not. lloda: you can't count on that. The result is the return value, not the argument. Sheilong: My problem here is to save a result from a computation in a list in by appending it and reusing these values yielded from the computation later on. lloda: i think this is what you want lloda: https://paste.debian.net/1206851/ lloda: personally i find do unreadable chrislck: named let = ftw clone: In guile 3.0.7, I can't use this extended symbol read syntax: https://www.gnu.org/software/guile/manual/html_node/Symbol-Read-Syntax.html#Symbol-Read-Syntax clone: did that get removed? the (read-enable 'r7rs-symbols) syntax doesn't work either, it looks like it expands to the not-working #{}# syntax rlb: clone: may or may not be related, but I believe wingo changed the reader a good bit recently. rlb: Is there a way to catch an (error ...) raised during a syntax-rules expansion or similar? (Current application is writing tests for some macro expansion error handling.) leoprikler: you could try compiling your scheme to bytecode "on the fly", but I don't know how practical that is lloda: clone: works fine here (?) lloda: 3.0.7 lloda: both #{}# and the r7rs || if you enable it lloda: what error do you get? rlb: leoprikler: thanks - and yeah, I should have thought of that. i.e. if it'll work, just test via a catch around an explicit macroexpand of the relevant form. clone: lloda: #{foo bar}# gives me clone: ice-9/boot-9.scm:1685:16: In procedure raise-exception: clone: Unbound variable: #{foo bar}# jgart: Hi Guilers! jgart: do you happen to know if there is something built into guile that reads a file as a string? Something similar to this function: https://paste.sr.ht/~jgart/f03d300dc83a408ce8c494644c320889f2b7bd01 clone: jgart: i think you want get-string-all from ice-9 textual-ports jgart: clone, thanks! avp: Hello Guilers. I'm testing Guile-SMC on binary data parsing. Here are first results -- Guile-PNG: https://github.com/artyom-poptsov/guile-png lloda: clone: and if you write foo-bar, what do you get? clone: #{foo-bar}# gives: Unbound variable: foo-bar lloda: you need to quote symbols lloda: foo-bar alone without the #{ }# will give you the same lloda: if you do (define #{foo bar}# 0) that will work fine clone: oh that makes sense, i thought #{foo}# meant 'foo, thanks lloda: yw lloda: maybe the doc needs an actual example bc it's not the first time that i see someone think that ArneBab: leoprikler: you have to jump through some ugly hoops to make it unhygienic easbarbosa: hey, whats is meaning of: #$output #~() and the likes? tnx rlb: sneek: later tell tohoyn it's unlikely to be added to unstable until bullseye releases (i.e. too far in the freeze to be accepted, and we'd also want the macro fix we added recently), so once bullseye is out, we can add it to unstable, and then it'll propagate to testing. sneek: Got it. *: rlb guesses that it'll be 3.0.8 that goes into unstable, though I'd also like to resolve the inlining issues first too. vijaymarupudi: daviid: Thank you, the get-cursor method now returns a pointer. The docs mention there being two out values for this method. How would I get the other one? Additionally, am I responsible for manually managing the lifetime of the pointer? https://docs.gtk.org/gtk4/method.TreeView.get_cursor.html daviid: vijaymarupudi: (ice-9 receive), or let-values ... let me paste an example vijaymarupudi: I've been using call-with-values, maybe I'm going it wrong, one sec vijaymarupudi: Ah, I still can't see the other parameter vijaymarupudi: Actually, I stand corrected vijaymarupudi: I see both the values now vijaymarupudi: What about lifetimes? daviid: https://paste.gnome.org/piwoectpc - this is 'your example', just removed the with, and a few tiny changes .. daviid: vijaymarupudi: i still need to fix the other problem ... mfiano: rlb: Are you a maintainer? vijaymarupudi: daviid: Makes sense to me! This is excellent. Will I have to free the gtk-tree-path? vijaymarupudi: vijaymarupudi: I see, that bug looked a lot trickier... vijaymarupudi: daviid* vijaymarupudi: I like g-golf's little touches like using multiple returns, seems as idiomatic to guile as oop can be daviid: vijaymarupudi: tx, but i didn't invent anything - all languages that implement multiple-values do so in their GI bindings and 'out arguments ... vijaymarupudi: Ah I see, well, that's good then :) vijaymarupudi: daviid: Just making sure I have an answer, do I have to free the gtk-tree-path? Don't want to have any memory leaks if possible. vijaymarupudi: Using `gtk-tree-path-free` that is daviid: vijaymarupudi: no, as itis you don't need to free the path daviid: vijaymarupudi: but after i fix 'that problem' exposed by clone, probably, we'll see - in the mean time, you should extract the path indice(s) as you receive the path, as it will be gc'd ... daviid: vijaymarupudi: actually need to double check, i mixed twoinfo here daviid: *two infos ... daviid: vijaymarupudi: sorry for the confusion, but yes, you'll need to free the path returned by get-cursor daviid: *you/one need to free the path returned by get-cursor ... daviid: vijaymarupudi: while talking about 'out arguments, makesure you read this in the manual - https://www.gnu.org/software/g-golf/manual/html_node/Function.html#index-_0025gi_002dstrip_002dboolean_002dresult vijaymarupudi: daviid: I was not aware of that, thanks for the heads up vijaymarupudi: sounds good, I'll free the path vijaymarupudi: In PyGObject, they seem to make a class for the struct? I wonder if that's manual vijaymarupudi: Or automatically generated from the bindings daviid: vijaymarupudi: as things are, in g-golf, none opaque struct are serialize/deserialized, and so you receive or pass a list of values - opaque struct, you receive and 'blindingly' pass the lib pointer - opaque struct -> goops class, maybe (probably), but not a priority for now ... daviid: vijaymarupudi: wrt PyGObject, opaque struct as classes is definitely done automaticallty, not sure about how they 'treat' none opaque struct though vijaymarupudi: Ah I see! jgart: Hi, is there an async version of system or system*? jgart: I'm having trouble finding it jgart: what does the guile community think of having crowd sourced docs like janet or clojure? https://janetdocs.com/ jgart: or maybe a guile cookbook? tohoyn: sneek: botsnack sneek: tohoyn, you have 1 message! sneek: tohoyn, rlb says: it's unlikely to be added to unstable until bullseye releases (i.e. too far in the freeze to be accepted, and we'd also want the macro fix we added recently), so once bullseye is out, we can add it to unstable, and then it'll propagate to testing. sneek: :) manumanumanu: leoprikler, ArneBab : No. It only guarantees outward hygiene. I was hit by this recently: I tried to write a looping facility using syntax-case, and I programmatically expanded the (in-list ...), (in-xxxx ...). in-list introduces 2 bindings (%pair and %cursor), but since I was never leaving syntax-case during the programmatic expansion, these 2 bindings collided even thought they were not from the manumanumanu: same expansion, nor from the same place and time. This is all documented in syntax-case, and not surprising. It is what I usually mean when I say that syntax-case is not hygienic enough. If you introduce bindings, and you risk introducing the same binding twice within the scope of one call to the syntax transformer you must use gensym (yuck) to ensure hygiene. manumanumanu: srfi-72 solves this by making sure that any binding introduced will be unique unless they are the same object. manumanumanu: but that never caught on so now I have to either gensym or use continuation-passing syntax-rules macros, which is as much fun as you'd expect. manumanumanu: like this: https://git.sr.ht/~bjoli/goof-loop/tree/master/item/goof-impl.scm#L120 manumanumanu: until about line 262 is what I use to dispatch and retain expansion control from user-defined macros. manumanumanu: jgart: pipes or (@@ (ice-9 popen) open-process), maybe? ArneBab: manumanumanu: ah, yes. Thank you! leoprikler: manumanumanu: Guile has quasi-syntax tho: see #` leoprikler: And I'm pretty sure it's defined in terms of syntax-case lloda: benchmark of core vector-fill! vs the vector-fill! that was in (scheme base) lloda: https://paste.debian.net/1206757/ leoprikler: so core is significantly quicker? leoprikler: btw. this is compiled mode, right? no interpreter overhead lloda: ofc lloda: this isn't surprising, the core version is just a for() *a++ = x loop dthompson: anyone had issues evaling guile code in geiser lately? dthompson: I can eval stuff in the geiser buffer just fine dthompson: but when I do C-x C-e in a scheme buffer it throws a strange error defolos: hey folks, anyone knows how well guille supports elisp? dsmith-work: Happy Friday, Guilers!! lloda: benchmark of (scheme base) vector-copy! vs a new version using memmove https://paste.debian.net/1206772/ lloda: (scheme base) vector-copy! uses move-left/move-right, so it's C either way leoprikler: defolos: enough to run vaguely do stuff in it, but it's no drop-in replacement defolos: leoprikler: thanks, so the basic stuff should work I guess? leoprikler: depends on what you mean by "basic stuff", but yeah lloda: memmove is smart enough to do nothing when asked to copy self, but there's enough improvement for the mid sizes that I think it's worth it defolos: leoprikler: mostly get basic lists out of an elisp file leoprikler: probably yes, but maybe no leoprikler: for instance, it has no setf vijaymarupudi: Q: Is there a way to get destructor semantics from GOOPS? In other words, can I arrange for a method to run when the instance is being garbage collected lloda: vector-move-left! vector-move-right! are bad primitives, there's always one which is the correct one and the other is wrong, vector-copy! frees you from that decision vijaymarupudi: Also, speaking of vectors, I wonder if it's possible to have a vector-resize function that uses realloc to take advantage of the mremap syscall lloda: if that is linux only, an alternate impl would be needed lloda: probably worth writing to guile-devel about it defolos: leoprikler: ok, well I guess I'll just try it first defolos: and if it works then I'll stick with guile, otherwise I'll use emacs itself vijaymarupudi: Oh, libc's realloc in Linux uses mremap, one would just need a function that uses it to resize a vector. The only way to do this right now seems to be making a new vector and copying it in vijaymarupudi: it being realloc vijaymarupudi: I don't know if guile-devel can be used for feature requests lloda: seems all right to me vijaymarupudi: Will draft one up right now manumanumanu: leoprikler: yes. That I know. But the know-how to implement a (forcefully-hygienic-quasi-syntax ...) is currently not available to me manumanumanu: hmmm. I could do an eq-hash of all syntax-objects AND symbols and only allow colliding symbols if the eq-syntax-objets is also in there. manumanumanu: but, continuing my proud tradition of lacking intellectual rigour: this is the way of someone who doesn't understand how quasisyntax works under the hood. There are probably loads of problems with this. manumanumanu: Pondering this while doing laundry I already found at least one problem. RhodiumToad: do you have a simple example of the problem? manumanumanu: (let ((a #'banana) (b #'banana)) #`(let ((#,a 5) (#,b 4)) (+ a b))) makes for an invalid let. manumanumanu: this is a simple inane example manumanumanu: But it shows the problem. I had a looping construct that I tried to write in syntax-case where I programmatically expanded the loop clasues. The problem was that if I had 2 (in-list the-list) in the same loop, they introduced the same bindings using that method manumanumanu: (the loop variables were called %cursor and %pair) or something like that. I didn't want to push the use of gensym on to whoever were writing the clauses, so I had to solve it differently manumanumanu: RhodiumToad: sorry, that example is an error anyway: the (+ a b) should be (+ #,a #,b). manumanumanu: srfi-72 solves it, but it seems pretty forgotten. RhodiumToad: let: duplicate bound variable in form (let ((banana 5) (banana 4)) (+ banana banana)) RhodiumToad: like that? manumanumanu: RhodiumToad: yes. SRFI-72 guarantees "internal hygiene", whereas r6rs syntax-case happily consider two #'bananas to be the same, even though they can be introduced at completely different times, as long as they are introduced within the execution of one syntax-transformer. manumanumanu: SRFI-72 would treat those as two different bindings, and rename one of them. manumanumanu: (let ((banana 5) (banana-1 4)) (+ banana banana-1)) manumanumanu: This is only really a problem once you start expanding macros programmatically. Racket has local-expand which expands a macro in the context of the current macro, which solves the problem IIRC. manumanumanu: using gensym for your own variables isn't bad. But in my case I would have had to force others to use it, which feels icky. RhodiumToad: why? manumanumanu: because if anyone wants to write an iterator clause for goof-loop I want them to be able to do it in syntax-rules. manumanumanu: If I programatically expadn a body of something and splice the results into a syntax object, I don't want it to behave differently than if I had not programmatically expanded the macro. manumanumanu: Anyway, SRFI-72 explains this better than I can. dsmith-work: !uptime sneek: I've been running for 2 days sneek: This system has been up 2 weeks, 2 days, 4 hours, 22 minutes Sheilong: Is it possible to break a do loop? ft: Arbitrarily? There is call/ec from (ice-9 control). dsmith-work: Sheilong: `do` does not. `while` has break (and continue). dsmith-work: I think do is not used very much. Named let seems preferred. dsmith-work: (I know I like it better) Sheilong: Yes, arbitrarily. Anyway, I need to debug my code, I did some mistake in here and things are not work as it should lol. leoprikler: obviously exit :P dsmith-work: Hah rlb: mfiano: I do maintain debian's guile. mfiano: rlb: I see. I never formally reported a bug I discovered, being new to Scheme. Just wanted to get a maintainer's opinion. ArneBab: Starting next week, there will be new votes to cast on r7rs-large — this time for macro systems: https://github.com/johnwcowan/r7rs-work/blob/master/ColorDockets.md alextee[m]: I'm trying to figure out what's the easiest way for creating guile bindings for my c code without having to write interfaces manually like in the manual alextee[m]: I just discovered swig alextee[m]: There's also that nyacc ffi helper thing. What would you recommend? alextee[m]: Swig seems easier and better documented imo manumanumanu: ArneBab: I don't think people's stance on syntax-case has changed much. manumanumanu: Marc wrote this in the chez issue tracker, which I in many ways find more exciting than r7rs-large: https://github.com/cisco/ChezScheme/issues/574 manumanumanu: I don't think much of that is actually very controversial. except the immutable cons pair thing (which IMO is a great thing). manumanumanu: So... optional arguments are not always a good thing. I just spent 20 minutes looking at ,traces and what-not not understanding why my recursive function was not working properly. The error was in the simplest clause not propagating an argument :( :( manumanumanu: But now it works! I have a small program reading scribble-like syntax into SXML (with a slightly diverging at-expr). lloda: wingo: ok to push http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=81f12bf86eed96c7ecdf6c9ce40d5abe6c729457 lloda: i mean, to merge wingo: lloda: sgtm lloda: thx, done manumanumanu: lloda: well done. you have been at this for some time, iirc. lloda: yeah lloda: it will take a while yet tohoyn: can you estimate when we will have Guile 3.0.7 in debian (testing/unstable)? tohoyn: new debianized version 0.1.0v5-2 of G-Golf has been released. Support for Guile 3.0 has been improved. See http://tohoyn.fi/g-golf-debian/index.html dsmith-work: UGT Greetings, Guilers manumanumanu: I just released this for no real reason: https://git.sr.ht/~bjoli/guile-at-expr manumanumanu: It is not quite compatible with racket's version, but close enough for what I'm using it for. tohoyn: Theme-D version 4.0.1 has been released, see http://www.iki.fi/tohoyn/theme-d/ tohoyn: new versions of Theme-D-Golf and Theme-D-Gnome have also been released leoprikler: manumanumanu: how come @{1} => 1, but @{a} => "a"? Is there some deeper meaning behind that? manumanumanu: damn manumanumanu: haha manumanumanu: thanks manumanumanu: What? Which guile? leoprikler: i mean it breaks the + example if you don't special-case numbers but it's still weird not to be documented leoprikler: The Guile interpreter in my head while reading the documentation :P manumanumanu: Ah. No: there is a difference. Everything between [] or () is scheme manumanumanu: everything between {} is string unless an at-expr leoprikler: okay, my bad, my squiggly detection sucks ._. leoprikler: regarding the hash extension, can't you simply (fix-atexp (read-atexp port)) ? manumanumanu: I don't know what you mean. read-hash-extend extends the guile reader so that it calls my procedure when it finds #@ leoprikler: sure, I mean the code inside the read-hash-extend leoprikler: looks weird with the define first manumanumanu: yup. I had to add a (pk ...) there during development manumanumanu: don't look too closely at the source. it is pretty awful manumanumanu: I start with point A, where I am now, and some vague vision of point B, where I want to be, and i spaghetti myself between the two. manumanumanu: And this code I broke out from a larger project. manumanumanu: no intellectual rigour at all leoprikler: haha, point taken lloda: (scheme base) redefines a lot of core bindings, shouldn't it be using #:replace ? lloda: like srfi-43 does lloda: also i dislike srfi-43 intensely manumanumanu: that should probably replace, yes. manumanumanu: why hate srfi-43? lloda: it's weird manumanumanu: or dislike was the word you used. lloda: yeah lloda: vector-map with index lloda: vector-copy where end can be > the size of the source manumanumanu: yes. it is clunkier to use for most cases. manumanumanu: that last one seems... not great... leoprikler: how would that work? With python-style wraparound? :P lloda: no, it just makes a bigger result and fills it with a filler lloda: i mean it just fills it with a filler, sorry leoprikler: hmm, that sounds somewhat useful tho leoprikler: albeit only somewhat lloda: when there are many ways to extend the meaning of something, it's time to stop leoprikler: imagine you want to grow your vector to some larger size while retaining the existing elements lloda: give your extensions some other names leoprikler: well, you could name it vector-copy/extend lloda: you can just make the big vector yourself and vector-copy! in it leoprikler: that's ew lloda: it's not leoprikler: everything with ! is instant +1 ew lloda: that's what vectors are for /shrug lloda: and that's what the extension was doing anyway leoprikler: sure, but you have to differentiate between API and internals leoprikler: internals can be ew when no one looks at them :P lloda: fair enough lloda: i still don't think it's a good extension leoprikler: Well, it doesn't break compatibility with the existing thing and does extend it in a very defined manner. leoprikler: Think of SRFI-1 iota leoprikler: you could achieve the same thing with map and basic arithmetic, but having it built-in makes the code read much nicer lloda: for review http://git.savannah.gnu.org/gitweb/?p=guile.git;a=shortlog;h=refs/heads/wip-vector-cleanup-2 lloda: only nit is that the C versions cannot be extended compatibly :-\ lloda: but the same thing happened already with scm_vector_fill_partial_x lloda: not sure how to solve it tbh leoprikler: wdym "extended compatibly"? leoprikler: iiuc the partial copy assumes the destination to be smaller than the source, right? leoprikler: hmm, seeing how this is defined in terms of vector-move-left!, does vector_move_left_x exist in C? dsmith-work: leoprikler: libguile/vectors.c:372 lloda: leoprikler: logically it's fine and in Scheme there are no issues leoprikler: fair enough lloda: but in C, adding arguments means breaking the previous interface lloda: that's why i left the C as it is leoprikler: oh, I didn't know there existed a procedure beforehand lloda: it's funny in a way bc vector-fill! was already r7rs compliant, but the doc doesn't say it, so the r7rs libraries had their own implementation leoprikler: heh manumanumanu: lloda: is that vector fill slower than the C one? I have noticed that some string functions I have rewritten in scheme have been just as fast as the ones in C in guile. If there is no performance penalty, maybe rewriting them in scheme wouldn't be a bad idea. manumanumanu: I haven't talked to Andy about that, but I have a feeling he wouldn't disagree if there is no real performance impact. lloda: yeah I don't disagree with that. If the perf is similar Scheme is ofc better lloda: when you need to provide a C binding then it's a bit more difficult lloda: tbh I think functions such as scm_vector_fill_x are a bit superfluous since they're just a for loop in C. You can just give the pointer and the size and let C users figure it out lloda: but once they're in the public interface you have bear them lloda: I think functions that are loops in C that call Scheme functions are likely always going to be better in pure Scheme lloda: vector-fill!, vector-copy etc aren't like that, they are raw C lloda: but I didn't benchmark them ArneBab: manumanumanu: what is the stance on syntax-case? ArneBab: manumanumanu: I now provided my enter-three-witchen macros as a benchmark for expressiveness of other macro systems. manumanumanu: Lets just say some people still whine about it since r6rs :) manumanumanu: If I would say anything it is that syntax-case is not hygienic enough. Srfi-72 solves a real problem with syntax-case. If I ever understand guile's syntax-case, I will write a (extra-hygienic-quasisyntax manumanumanu: ...) manumanumanu: that will always introduce bindings hygienically unless you are unquoting the same syntax object. manumanumanu: anyway. Now to bed! daviid: vijaymarupudi: I just pushed a fix for the bug you reported, g-golf develbranch, please pull, autotool danse :), try and let me know ... leoprikler: syntax-case is pretty hygienic by default tho, no? jgart: When using the basic http server module, how do I parse a request body? jgart: Hi cwebber, will you continue to develop Spritely Goblins racket implementation in parallel to the guile implementation? rlb: mfiano: I don't think there's any enforced mapping, but if you say (use-modules (foo bar)), then unless there's a foo/bar.scm file in your GUILE_LOAD_PATH that has a (define-module (foo bar) ...) in it, guile won't know how to find it. But nothing prevents any given file from defining multiple modules, and if you've already defined the module, then guile won't go looking for it. rlb: (already defined, perhaps programmatically via the functions in boot-9.scm, etc.) rlb: (or whatever) cwebber: jgart: yes cwebber: part of the reason I'm doing both is to demonstrate compatibility across two runtimes daviid: vijaymarupudi: i found what causes the problem, will push a solution in an hour or so ... it is 'funny to note that you both 'hit the exact same g-golf few lines of code :), though both reported problems need a different fix ... vijaymarupudi: I'm glad you didn't have to hunt down two distant bugs :) vijaymarupudi: Thank you very much! daviid: vijaymarupudi: the fix triggered a(nother) gtk-tree-path related bug, and the other problem reported by clone needs more thinking, so it will take more time then initially said here earlier, probably a day or two, sorry, but will ping you both when something to test is ready ... mfiano: rlb: Ok. What is the recommended solution to automatically fetching third-party scheme libraries to your load path, perhaps some even shared between multiple local projects? mfiano: I am really liking Guile coming from CL as my first Scheme, but I often work with very large projects in CL, so just trying to get an idea of a proper workflow for managing/loading large projects and their transitive dependencies clone: daviid: thanks for working on it! clone: When I was looking for the bug I thought a little about solving it. I'm not very experienced so I don't know how good of an idea it is. clone: but I thought about making a class that has slots for a pointer and a bytevector, and making all of the pointer functions in (system foreign) generic over pointers and gc-safe-pointers. you'd really need to make the generic pointer functions were included everywhere though. vijaymarupudi: daviid: Sounds good, thanks for taking a look at it! vijaymarupudi: In the past, I've faced a problem with Guile FFI where I'd send a pointer to a closure to C, and then the closure would get GCed I think and I'd get a segfault when I called it later. I had expected that libgc would take care of it, but it did not. You can't scm_gc_protect from Scheme, so there was no way around it without using a C extension. vijaymarupudi: Unless I used an internal hash-table combined with a mutex, but that seemed like it was duplicating scm_gc_protect tohoyn: I'm making a call tree of a large program with statprof. Now I have procedure A calling procedure B once but I have two nodes for this call in the call tree. Why is this so? mfiano: Does anyone use geiser here? I'm running into an issue that completely prevents me from learning Guile :( mfiano: With geiser's guile repl and one of my guile module source buffers open, attempting to evaluate anything in my source buffer with C-c C-c, or using company to complete any symbols results in Emacs hanging forever until I cancel the hung operation with C-g mfiano: Googling a bit seems to indicate this is an issue with the repl package changing or something, and a proper regexp needs to be added to guile-geiser--prompt-regexp. I tried a few things and I just can't get any work done mfiano: s/package/module/ tohoyn: mfiano: I have set guile readline not active when using guile from emacs mfiano: How do I do that? Sorry I'm just trying to get set up to learn Scheme leoprikler: vijaymarupudi: there are guardians, which work sort of like gc_protect tohoyn: mfiano: do you activate guile readline somewhere? mfiano: in my .guile tohoyn: mfiano: then pass option -q to the guile command in emacs tohoyn: mfiano: it suppresses loading the init file mfiano: What if I want to evaluate the rest of that file? leoprikler: well, you could jump into that buffer and evaluate it on your own tohoyn: mfiano: use the -l option in guile tohoyn: mfiano: and write a separate guile init file for emacs leoprikler: mfiano: regarding the 1:1 file mapping, no, they aren't necessarily bound to files (see the (guile) module for example), but when they are not, you need to do some special things to ensure those non-file modules exist before you want to access them leoprikler: that's how Guile-GI works internally mfiano: Not seeing how to supply arguments to the guile binary. it is erroring when applying them to the geiser-guile-binary string. but i suppose i could just set geiser-guile-init-file mfiano: That seemed to do the trick! and wow, completion and everything is much snappier now too mfiano: Thanks all wingo: moin tohoyn: I use the following code in statprof to track callers to a Scheme procedure: https://paste.debian.net/1206513/ tohoyn: could someone check it? tohoyn: The purpose of the code is to measure the time used in procedure check-if-subtype? for each caller tohoyn: I.e. I want to know where the most time consuming calls are made tohoyn: are there any statprof gurus here? tohoyn: it looks like same procedure call may have different procedure addresses manumanumanu: tohoyn: I do not understand what is going on there, but are you relying on procedure equality? tohoyn: no, I'm just profiling the procedure calls lloda: wingo: i really want to remove the array handling in vector-copy / vector->list / vector-move-left! / vector-move-right!. It is undocumented and vector-fill! / vector-ref / vector-set! / vector? are already type strict, so i'm 99% sure no one will miss the old behavior lloda: plus the move functions are bugged, they accept nonzero lower bounds and just ignore them wingo: humm! wingo: lloda: do any other vector- functions operate on arrays? lloda: those I listed are the only ones manumanumanu: lloda: what exactly is going on with the vector patches. Just cleanup? I am curious :) lloda: i want to layer the array impl on top of the various vectors so that it can be replaced eventually lloda: arrays depend on the various vector types but the vector types shouldn't depend on arrays lloda: that is already true for all of the vector types, the srfi-4 types, strings, the bitvectors lloda: actually lloda: I could do something like this http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=libguile/bitvectors.c;h=3a279e40111253380a59b22920aee48263e00de5;hb=HEAD#l456 lloda: that looks like the way to go vijaymarupudi: leoprikler: thanks for the suggestion on guardians, I was not aware of them. They wouldn't have solved the issue I described because I needed precise control on when to free certain closures that I retrieved from C, however I can think of many other uses for guardians. dsmith-work: UGT Greetings, Guilers manumanumanu: good day! civodul: o/ vijaymarupudi: \o pizzapal: hi, is it expected that using hash-clear! on a srfi-69 hash table would produce a "wrong type argument" error? manumanumanu: yes manumanumanu: srfi-69 hash tables are not the same as the built-in ones pizzapal: ah, i see manumanumanu: you will have to roll your own using hash-table-delete! from srfi-69 pizzapal: do you know an efficient way to clear out a srfi-69 hash table? pizzapal: so just iterate over it? manumanumanu: (hash-table-walk hash-table (lambda (k v) (hash-table-delete! hash-table k)) manumanumanu: but a named let over (hash-table-keys hash-table) will probably avoud the procedure call overhead and will be ever so slightly faster pizzapal: oh really? manumanumanu: the difference isn't huge manumanumanu: and you won't notice it unless you have several thousand keys pizzapal: it is usually only a few dozen keys, but i have to wipe it very frequently pizzapal: so that seems to be my bottleneck manumanumanu: did you benchmark the different hash-tables? I believe srfi-69 is built upon guiles built-in hashtables pizzapal: yeah, i am using statprof to do a comparison at the moment pizzapal: i was just using set! with make-hash-table to clear it out and that was not fast haha manumanumanu: set! is almost always a code smell. mfiano: Can someone tell a newbie why I don't have access to the program-arities procedure in (system vm program) ? manumanumanu: guile implicitly boxes everything touched by set!, which will make it slower manumanumanu: chez does the same manumanumanu: mfiano: it seems to not exist anymore... mfiano: Hmm, it's in the documentation manumanumanu: I know. I'm trying to figure it out now manumanumanu: oh, even more weird manumanumanu: try (program-arity + 0) and it will complain there is no program-arities mfiano: sounds like a bug mfiano: can confirm manumanumanu: It seems like program-argument-alist might be what you want mfiano: manumanumanu: I'm following along Software Design for Flexibility, Sussman's new book, and I need MIT Scheme's procedure-arity-min and procedure-arity-max mfiano: and procedure-arity it seems manumanumanu: mfiano: you can implement that from program-arities-alist without much fuzz unless you want to define a nice heuristics for keyword args mfiano: Fair enough, thanks. Hopefully Andy and the team can update the docs for other confused newbies :) rlb: mfiano: not sure what's "common" wrt external dependencies. Most of my uses of guile for a while have been fairly self-contained, i.e. as an extension, or as the foundation underneath lokke, or for things that can mostly get-by with what's built-in, and/or in debian. That said, I think there are probably a number of options. rlb: mfiano: ...and if you're needs are simple enough, just arranging for the deps you need to be in the load-path might suffice, whether via explicit (build-system) clones, or submodules, or... rlb: s/you're/your/ dsmith-work: mfiano: You were asking the other day about module <-> file relationships? dsmith-work: mfiano: Generally, as rlb said, though it is possible to use load or include withing a module file. dsmith-work: But that's not usual. mfiano: I see. Thanks everyone mfiano: I'm a long time Common Lisper and trying to unlearn lots dsmith-work: mfiano: Cool. I'll be having some questions or you. ;^} mfiano: sure jgart: Hi, does guile have something like (void): https://docs.racket-lang.org/reference/void.html dsmith: jgart: Is that what (if #f #f) would return? dsmith: jgart: That's the # value. chrislck: #unspecified and #nil: here be dragons chrislck: "abandon hope all ye who enter here" jgart: dsmith, jgart: #;5> (eq? (if #f #f) (void)) jgart: #t jgart: it looks like it is jgart: I tested that it chicken but gambit has the void function also jgart: Should the fact that you can add a docstring to the following style of function definition be documented? jgart: (define hello (lambda (x) "docstring" (+ x x))) jgart: it breaks if I add the docstring immediately after the define keyword jgart: the metacommand ,d also works in the repl for it jgart: scheme@(guile-user)> ,d hello jgart: docstring jgart: In other words, should guilers know they can add docstrings to that style of define in the docs? jgart: If so, I don't mind adding it dsmith: jgart: It's hard to find but it's there: https://www.gnu.org/software/guile/manual/guile.html#index-procedure_002ddocumentation dsmith: "By convention, if a procedure contains more than one expression and the first expression is a string constant, that string is assumed to contain documentation for that procedure." jgart: It seems like some keywords explicitly document the docstring and some don't jgart: so it feels a bit inconsistent in the docs jgart: for example: Syntax: define-syntax-rule (keyword . pattern) [docstring] template jgart: from this page: https://www.gnu.org/software/guile/manual/html_node/Syntax-Rules.html jgart: It's explicit about define-syntax-rule supporting a [docstring] dsmith: Ya, the manual is inconsistent. The docs for case-lambda show a docstring in the examples, but not in the text. jgart: Ok, I'll keep that in mind jgart: maybe I'll send a patch at some point with some fixes for that jgart: It seems like there is also a lot of functions that could benefit from a docstring jgart: so that we can have the convenience of accessing them from the ,d metacommand jgart: instead of just returning #f because they don't have any docstring jgart: for example see the difference here between janet and guile doc for first: jgart: https://paste.sr.ht/~guixtogether/c83d532a255c4d31465f7ca632648ddc00c3e325 jgart: that's maybe a trivial example as people can guess what first does but it is still nice to get something back in the repl without having to search through docs. This is especially useful for beginners of guile and/or scheme. jgart: that's maybe a trivial example as people can guess what first does but it is still nice to get something back in the repl without having to search through docs. This is especially useful for beginners of guile and/or scheme. Given that the metacommand ,d exists I think we should use it fully for getting all documentation. Would it be ok if I add docstrings for functions that are missing them? jgart: I can send patches for that for review daviid: lloda: maybe you can help - i'd like to define a null terminated array (vector) of 'what-ever, say unsinged-long to start with ... from scheme, for the g-golf test-suite, how do i do that? mfiano: Hi mfiano: Perhaps a dumb question, but why do Linux distributions, even those that live on the bleeding edge, only have Guile 2.x in their repositories? daviid: lloda: i answered my own quiz, tx jgart: mfiano, not enough interest to rush to package it leoprikler: jgart I would welcome it if we could generate such documentation uniformly with texinfo leoprikler: our current texinfo game is somewhat weak jgart: leoprikler, Wouldn't it just be a matter of adding a docstring just like other functions that currently have a docstring? leoprikler: Not quite. jgart: Or, do you mean that the texinfo curently does not parse the docstrings in the code? leoprikler: If you e.g. have texinfo in a docstring, that docstring will yield texinfo code and not attempt to render it jgart: I mean the doc system leoprikler: not very human-friendly leoprikler: if you have texinfo in a doc comment (the kind of comment that can be snarfed via doc-snarf) it won't show up as docstring jgart: leoprikler, is there any documentation on doc-snarf? jgart: scripts/doc-snarf.scm? leoprikler: "guild help" jgart: cool! hadn't used guild yet jgart: https://paste.sr.ht/~guixtogether/2edf3e00248c4df2f2224dfe172625851724d19a civodul: jgart: hey, where does "graph-easy" come from? looks cute! leoprikler: apparently cpan? civodul: ah, we need a package then :-) lloda: texinfo now does svg math in html output. It's pretty great, I wanted the feature for years jgart: civodul, yes it's a perl package jgart: lorem is cute too jgart: I'll try to work on those two soon if nobody else gets to it first ;) jgart: https://metacpan.org/dist/Text-Lorem/view/bin/lorem mfiano: is there anything like asdf for guile? leoprikler: (guix build-system guile) :P leoprikler: There is hall, which generates guix and automake packages, but imo it's more fun to just write plain automake if your project is complex enough mfiano: hall hasn't worked in months mfiano: syntax error attempting to invoke it leoprikler: Okay, there was hall :P mfiano: things look barren coming from CL :) leoprikler: Well, you'll eventually come to see that things are not barren but chaotic. leoprikler: CL is a language with many implementations (as is C/C++), but a common structure across them, which makes everything seem samey and neat. leoprikler: Scheme OTOH is a wild land where every implementation does as it pleases. mfiano: I decided on Guile as it seems batteries-included enough, and has GOOPS etc mfiano: Just read the entire language reference in one sitting. It was rough leoprikler: yup, GOOPS is inspired by CLOS, but I don't think it has all the features mfiano: I'm still unsure on best project management practices. how to define packages and manage file load order, etc mfiano: I guess i dont know how to start other than just writing code in a scratch file :p leoprikler: I think there are some books out there with practical project examples, not that I give a damn about those usually. mfiano: oh? leoprikler: [in general Scheme, not particularly guile] leoprikler: also note that R6RS onwards has a library system, though Guilers prefer define-module mfiano: whatever gets me up and running would be appreciated mfiano: now that i read how to use the language leoprikler: Reading a language reference once is not enough to understand it :P leoprikler: It's rather a place to grep in when you're asking yourself "how do I X" or "what does car do tho?" mfiano: the language reference doesn't really talk much about dependency management, file load order, downloading libraries, discovering libraries, publishing libraries, and all the other things that make a programming language useful for collaborative coding. leoprikler: discovering and publishing libraries is stuff for package managers mfiano: like, not sure where to begin to create a "project" that knows how to load itself such that macros are defined before use, etc leoprikler: you can do that with Guix for example leoprikler: for dependency management, guile has autoconf macros that you can use to check whether a given module is defined leoprikler: E.g.: https://gitlab.com/leoprikler/tsukundere/-/blob/0.3.x/configure.ac#L42 leoprikler: I don't really understand the term file load order or how it becomes a problem, but typically it's (public-module) vs. (public-module very hidden "private" stuffy) leoprikler: for the module names mfiano: Fair enough mfiano: Guess I'll have to learn autoconf/make or guix in addition to Nix :) mfiano: But bed time now. see ya dsmith-work: UGT Greetings, Guilers rlb: civodul: if we think fash (at least -- suppose there's also fector) is suitable, then I'd be more than happy to have it in guile itself (definitely like for guile to have a good built-in persistent vector/map/set), and would also be happy to help with the process of including it. rlb: No idea what they should be named ...(ice-9 persistent)... rlb: And presumably we'd still need some reasonable function prefix foo-set, foo-fold, etc. given the normal scheme convention there. lloda: i miss an extension mechanism for constant-type in (language cps). I have a reader for a new type but I don't see a way to have literals work in the REPL :-| lloda: ideas welcome rlb: mfiano: if it helps https://packages.debian.org/search?keywords=guile-3.0 and bullseye should be released as "stable" soonish. rlb: mfiano: and wrt getting started, if you were just asking about setting up something simple for now, a minimal arrangement is perhaps a directory with a subdirectory, say "module" or "mod" containing your guile module tree, i.e. mod/my/somemodule.scm, and then in somemodule.scm you'd have a (define-module (some module) ...)., and you'd run things from the top level via 'GUILE_LOAD_PATH=$(pwd)/mod guile "$@"' (or a similar wrapper rlb: script). I mean if you just wanted to understand the basic mechanism. (Could also use "guile -L mod ...".) rlb: At that point, (use-modules (my somemodule)) should work, and handle dependencies (between your modules, and any built-in guile modules), etc. rlb: bbl cwebber: hello hello! cwebber: I'm porting Spritely's Goblins library to guile today, how are you all liltechdude: Hello gyus. How I can bound built-in webserver with varibale (define my-server (server 'http)) and run in foreground with something like (server-start my-server)/stop with (server-stop my-server)? hendursaga: cwebber: sounds cool, is it public yet? no pressure, just wanted a link to check it out later drakonis: oh, nice. daviid: clone: I had to fix another problem, not a bug but something to adapt to someanotation changes in gtk 4.3.1 that 'broke' the clipboard example, and shall push that work later today, then back to solve vijaymarupudi's bug report wrt get-cursor, and yours 'simulatenously'... mean while, it would be nice if you could work on an example to reproduce, that i could run here .. doesn't need to be 'that small' ... vijaymarupudi: daviid: oh yeah I was going to report that today, glad you found it! daviid: vijaymarupudi: didn't find the solution yet, i will start to work on it latertoday ... cwebber: hi hendursaga, haven't pushed it up, but let's see if I can by the end of the day, still self conscious over its current state :) cwebber: but things are starting to work clone: daviid: https://paste.gnome.org/pxg6m827k drakonis: hoho, that looks like a fun trick clone: it should throw an invalid iter error pretty quickly, or run forever once you've fixed it. Thanks for looking drakonis: goblins in guile. drakonis: neat. daviid: clone: ok tx! - note that you may activate 'scheme' when you paste using gnome or debian, which 'renders' the code ... (don't repaste this one of course, just mentioning for future pastes ...) mfiano: rlb: Thank you mfiano: I have another question that the documentation didn't answer for me mfiano: In Scheme, is it always a 1:1 mapping between modules and files? In CL, "module"s can extend to many files, or many modules can be in a single file. daviid: vijaymarupudi: the url you pasted privately were https://paste.gnome.org/pbceokaf6 and https://paste.gnome.org/p8b2lsbwm - i prefer if you (always) use paste.gnome or paste.debian ... but now i don't need any, tx vijaymarupudi: daviid: Debian seems to think I'm pasting spam for some reason vijaymarupudi: Oh well haha vijaymarupudi: I know my code can be bad, but Debian gives me the honest truth daviid: vijaymarupudi: it happens to 'all of us', when that happens, prefer https://paste.gnome.org/ scheme mode ... daviid: in a few hours debian will 'clear' your name from paste spamers ... :) daviid: any one knows what i need to put in my .emacsso M-x run-python startspython3? daviid: 'no matter what' (i triedso far), it starts Python 2.7.18 daviid: ah, gotit, nevermind dsmith: manumanumanu: "dragon-infested" ? clone: daviid: I think I found a bug in g-golf. My GtkTreeIters were randomly becoming invalid in my g-golf program, but not in an equivalent python program. clone: i think the issue is in function.scm:1065, in the prepare-gi-args-out function. You do (bytevector->pointer (make-bytevector.. and I think the bytevector is getting garbage collected clone: I did this bandaid change to confirm and it stopped the iters in my program from becoming invalid: https://pastebin.com/raw/pB56NrzK clone: i'll try to make a simple program to reproduce but since it's related to garbage collection i'm not sure how to make sure it triggers daviid: clone: tx, will look at your patch - could you please not use pastebin.com, tx daviid: clone: invalid as in #f? or did this crashed g-golf? daviid: clone: that seens a very nice catch, have to confirm, but tx! clone: invalid as in (gtk-tree-store-iter-is-valid) returned #f. Parsing it as a struct showed random values daviid: clone: ok clone: thanks for looking at it, i'll try to remember to use a better pastebin next time daviid: clone: yes, please prefer debian, gnome, sourcehut ... paste services, no js, no tracking ... tor-friendly ... tx leoprikler: doesn't gnome have js tho? manumanumanu: i believe it works without scripts lloda: do we need a deprecation cycle to break (define a (make-shared-array (make-array 3 3 3) (lambda (j) (list 1 j)) 3)) (vector-copy a) lloda: note that (vector? a) is #f lloda: also stuff like (vector-ref a 0) etc already doesn't work roelj: Are there RPMs for Guile >=2.2 for CentOS 8? RhodiumToad: lloda: what do you want to break exactly? lloda: (vector-copy a) should be an error because a is not a vector RhodiumToad: that doesn't seem useful lloda: what doesn't seem useful? RhodiumToad: having it be an error lloda: why not? a isn't a vector. Most vector functions won't work on it. And that's for a good reason. Having vector- functions support arrays makes vector depend on array depend on vector. It was a mess and we already got rid of most of it. lloda: there is array-copy lloda: i just want to finish the job leoprikler: If it makes stuff cleaner, then having a separate array->vector is all fine, but I don't really get what's wrong on the outside either lloda: array-copy returns a vector if the result has rank 1 lloda: well if the type is #t, also lloda: it's a burden to support such things. We don't support (list-copy vec), even tho it's well defined RhodiumToad: an array with rank 1 and lower bound 0 seems to be a vector for almost all purposes lloda: arrays can have a step != 1 lloda: and refer to a piece of some other vector, that is they don't own their storage RhodiumToad: yes, so? lloda: they are just different types. The vector- ops aren't polymorphic, they apply to the vector type. If you need a polymorphic api, the array- api does that. leoprikler: yeah, and? lloda: it's not enough that something is 'functionally' equivalent to a vector. We don't support (vector-copy #f64(...)) either, for the same reason. I think i'm repeating examples. lloda: let me put it this way lloda: it is a burden to the implementation for vector-copy to support 'some' non-vector arrays. lloda: it isn't a burden to the user to use array-copy when the object they're dealing with isn't a vector. lloda: actually i think it's a burden to the user for (vector? a) to return #f and (vector-ref a i) to return an error and yet (vector-copy a) to magically work dsmith: roelj: Not built/distributed by the Guile project. Check your distro. roelj: dsmith: Thanks, I thought at least one Guiler would've run into a RHEL 8 derivative with an outdated Guile and would have a pointer to an additional repository. :) roptat: can I get something like number->string to complete with leading 0s? like 2 -> "002", 15 -> "015", 452 -> "452"? lloda: format from (ice-9 format) does that lloda: search for '0 in https://www.gnu.org/software/guile/manual/html_node/Formatted-Output.html dsmith: roelj: I suspect most run Guix these days. I'm somewhat partial to Debian myself. roelj: dsmith: Ahyes, I produced a Guix pack and untarred it on the RHEL8 machine, works beautifully ;) roelj: It's unfortunate tho that it seems Guile is getting behind in the RHEL distributions. apteryx_: having a handle to an object, how would I find the symbol its associated with? Is there some reflective procedure to do that? apteryx_: seems I must manually search the exported variables with module-map? b4283: https://en.wikipedia.org/wiki/Singularity_%28operating_system%29 b4283: 原來 MS 早就已經用 C# 寫過一個 kernel apteryx_: oh, seems there's module-reverse-lookup apteryx_: but most introspection procedures appear to operated on variables made via `make-variable', which (define myvar "some-value") isn't, for example. apteryx_: map-module is useful in that it allows a procedure passed to it to access both the symbol and the variable (as a boxed variable), but it does so only for public variables, not variables in the local scope. civodul: hi apteryx_! civodul: apteryx_: in general, you can't rely on module-private variables existing at run time civodul: they can be inlined civodul: that's why you may or may not see them when iterating on a module's set of variables apteryx_: civodul: hi! :-) OK. In my case the variables are actually public (package variables). I think I've nearly found a Guix-specific way to get to it, but it feels convoluted (and doesn't work yet): https://paste.debian.net/1206360/ apteryx_: this works, but still feels convoluted :-) https://paste.debian.net/1206363/ apteryx_: more correct version https://paste.debian.net/1206369/ leoprikler: can we do something about the name tho? fash sounds a little fashy dokma: I'm having issues posting to this channel. Can anyone see this? sneek: dokma, you have 1 message! sneek: dokma, lfam says: With Guix, install the gcc-toolchain package in order to compile things by hand wilfred: dokma: I can see your message dokma: Finally... dokma: Back to my issue. I'm trying to figure out how to shutdown a server started by run-server from the repl module. dokma: I don't see any way to do it from the source. dokma: https://github.com/skangas/guile/blob/master/module/system/repl/server.scm dokma: I've embedded the repl into my C++ app and it works as expected. But I cannot shut it down. dokma: I have tried (stop-server-and-clients!) from the repl but all it does is it closes my current repl session and I can connect right back in. In other words, run-server is still running. leoprikler: dokma: (quit)? dokma: leoprikler: it just closes my current repl session. dokma: It doesn't stop run-server. I can connect right back. dokma: I suppose that there should be a way to shutdown the repl server properly without killing the C++ host? dokma: Or am I wrong? leoprikler: I think you need to run stop-server-and-clients! on the server side somehow, but I'm not sure whether that power is handed to every connecting repl leoprikler: it also shuts down if you somehow find the port and close it, apparently leoprikler: Perhaps the comment in L38 hints at the culprit tho leoprikler: or no, the server-socket is probably never closed, because it's not in open-sockets leoprikler: well, nope, it's the first to be added to *open-sockets* dokma: leoprikler: I've implemented a C++ function that I can call from the repl. dokma: I can call stop-server-and-clients! from there. dokma: But I don't see how that would make a difference as opposed to just calling it from the repl. leoprikler: I'm not sure, but the server might think you no longer care about the evaluation if your client exits and thus stop early dokma: leoprikler: I totally didn't understand this last line dokma: I'm a scheme noob. Just for the record. leoprikler: Try to do good ol' printf debugging in stop-server-and-clients! dokma: Will try that too... leoprikler: in particular make it spit out the sockets it closes on your server leoprikler: (in some place you can retrieve the logs from) leoprikler: apparently the server socket is also closed when you throw sigint on the server side dokma: Can I throw sigint from the repl? leoprikler: you have a guile repl, you can probably get shell access through it too leoprikler: try (kill (getpid) SIGINT) dsmith: leoprikler: "fash the stampede" ? sandwich: i'm writing some procedures in c to use as callbacks. i want them to share local variables without having a userdata pointer passed. in scheme, i could just use closures. but what do I do here? i could just make wrapper procedures in scheme that use closures and pass the local variable to the c functions, is that the best way? ArneBab: Please let us NEVER EVER do something like Python3. I just lost another important local tool, because I have no time to convert it to py3 and cannot easily run it with py2, because it’s started with a custom runner. ArneBab: It’s never OK to push work onto maintainers — many useful tools have exactly zero maintainers. dokma: leoprikler: (kill (getpid) SIGINT) works! This is the only way to stop the server from the repl for now. dokma: Is this a clean shutdown though? leoprikler: dokma probably not, but you're one step closer to understanding what's going on, hopefully dokma: leoprikler: if I understand correctly accept is called with call-with-sigint so wouldn't SIGINT simply stop accept from waiting for a new connection? dokma: I'll try debugging to see if control returns to C++. leoprikler: it also kills the server socket leoprikler: but IIUC it doesn't flush existing connections dokma: leoprikler: the server socket is there just to accept new connections no? dokma: So it should be closed. dokma: If I do (kill (getpid) SIGINT) from the last active repl it seems to be a clean shutdown to me. Will do some tests. leoprikler: sure, but the server socket is the thing that doesn't get closed by you report dokma: leoprikler: it wasn't getting closed by calling (stop-server-and-clients!) or (close-port port). dokma: What does the arrow do on line 51 here: https://github.com/skangas/guile/blob/master/module/system/repl/server.scm dokma: I've never seen this in Scheme. But I've been learning Scheme for only the past week. dokma: Here's a permalink to the line itself: https://github.com/skangas/guile/blob/01e909d90a130f4987b70edae2dbd5a2b33edae7/module/system/repl/server.scm#L51 dokma: leoprikler: are you still here? dokma: ^^^ leoprikler: wadup? leoprikler: oh, this is a variant of cond that takes whatever the condition evaluates to (unless it's #f) and passes it on to a procedure ft: Yeah, the right hand side of the arrow must evaluate to a procedure and the result of the test is passed to it and the result of that application is the result of the cond. ft: The same thing exists for case. dokma: I've never seen it. Is that some recent addition or? dokma: Is that arrow some special syntactic sugar or just a symbol that gets passed to cond? ft: I'm pretty sure it's been in Guile for a while. Not sure if it's part of the standard. dokma: Thanks a bunch guys. You're really helping me out. ft: It's in r7rs, and I bet in previous versions too. dokma: But I supposed that => is nothing special syntax wise? Just a symbol the goes into cond ? dokma: *that goes* leoprikler: => is syntax-boudn leoprikler: *syntax-bound dokma: leoprikler: it's a special token? leoprikler: meaning it has a special meaning and can't be used as a symbol in that context leoprikler: similar to _ dokma: leoprikler: outside of that context? ft: It's in r5rs too, at least for cond. Can't see it in case's description in it. But I just skimmed the document. leoprikler: (define => >=) leoprikler: works fine ^^ dokma: So it's not some special token recognized everywhere. Just in cond leoprikler: not just in cond leoprikler: but in the context of cond it's a special token dokma: I see ft: Like else. :) dokma: leoprikler, ft: well if what you guys told me is true and if I understand stop-server-and-clients! correctly it will never close the server socket because it closes a socket only if there is a pair of them. Since the server-socket is the first one added, it will never be closed by this function? leoprikler: pair? is true for lists dokma: but it closes the cdr leoprikler: and the procedure is called recursively dokma: ooops no, closes the car leoprikler: so it should continue until the list is empty dokma: server-socket should actually be the first one to get closed dokma: actually last dokma: (cons s *open-sockets*) dokma: pushes new sockets to the front of the list leoprikler: yup dokma: So I can't figure out why (kill (getpid) SIGINT) shuts the server down but stop-server-and-clients! doesn't. dokma: After (stop-server-and-clients!) from the repl the server-socket is still opened and I can connect back in. dokma: *still open* leoprikler: which is why I hypothesize, that stop-server-and-clients! erroneously exits early vijaymarupudi: dokma, just curious, what are you working on? daviid: vijaymarupudi: did you see my yesterday's msg, i pushed a fix ... vijaymarupudi: daviid: I did, thank you! I responded but it looks like IRC bugged out. daviid: ok great vijaymarupudi: Here were my responses: https://paste.gnome.org/pt45edzl3 vijaymarupudi: Basically, I can't seem to figure out how to get and use TreePath daviid: you need to set-cursor ... see the gtk manual .. for cursor i mean vijaymarupudi: Shouldn't I be able to get it from the TreeView though? daviid: vijaymarupudi: GtkTreePath is an opaque struct, not an object vijaymarupudi: Ah I see, I didn't know that vijaymarupudi: How would I get the values from this function? https://docs.gtk.org/gtk4/method.TreeView.get_cursor.html vijaymarupudi: It seems to return false no matter what I do vijaymarupudi: Even after click something in the TreeView vijaymarupudi: Here's a snippet to experiment on: https://paste.gnome.org/pvn6ise5v daviid: you need to set-cursor, so that get-cursor returns, right in that descrption you pasted ... try to ask for help or example on #gtk maybe? daviid: going afk, bbl ... vijaymarupudi: This might be a misconception on my part, will get back to you vijaymarupudi: daviid: I think this might be a bug, here's a fairly equivalent Python program. If you observe stdout, you can see that it prints the TreePath and focus_column to stdout, but the g-golf version always prints false. vijaymarupudi: Make sure you click on some of the treeview entries to see the events happen vijaymarupudi: Python: https://pastebin.com/raw/bNfbnXvy vijaymarupudi: Guile: https://pastebin.com/raw/tDUrUzL4 chrislck: any looping gurus? in a hierarchical tree, i want to collect all descendants. anyone knows how to refactor to eliminate set! ??? https://pastebin.com/raw/kiS4R8iX chrislck: hmm I think there's a nested fold in here chrislck: yass: https://pastebin.com/raw/PZcJHuDW RhodiumToad: use a tree fold? stis: tja guilers! manumanumanu: tja Stis! manumanumanu: I passed you dragon-infested home region just hours ago manumanumanu: chrislck: I would use the colloquial "good" flatten (which is a tree fold) manumanumanu: I have it somewhere manumanumanu: the downside is that it works on improper lists manumanumanu: chrislck: https://paste.debian.net/1206265/ manumanumanu: which happens to be what you shold use instead of all the ugly flatten versions out there using append. manumanumanu: chrislck: and of course I didn't read longer than my own nose. You solved it yourself :) leoprikler: but, but append :( manumanumanu: go search for "flattening a list in scheme" and all solutions you find will use append. manumanumanu: sad times. daviid: sneek: later tell vijaymarupudi ok, will look into the problem and let you know ... sneek: Got it. daviid: sneek: later tell vijaymarupudi both paste you posted 'privetely' expired (but no problem, i know what/where to look at the problem,tx) - sneek: Got it. leoprikler: for the record, i think your version might not do proper tail recursion leoprikler: (foldts (const '()) (lambda (s0 s1 t) (append s1 s0)) xcons ) should only have call depth tree depth + 1, IIUC fold correctly daviid: fwiw, here is 'mine' :) - https://git.savannah.nongnu.org/cgit/grip.git/tree/grip/list.scm#n73 leoprikler: that looks the same but with match manumanumanu: daviid: well, you wrote that after I sent you mine and gave you the permission to do whatever you wanted with it, iirc :) manumanumanu: leoprikler: which for guile means faster, since no reverse at the end. manumanumanu: the largest problem with it is that it accepts improper lists without complaint manumanumanu: that is how guile's map works, iirc. And chez's as well manumanumanu: and racket's I suppose leoprikler: map* at least, from oop goops manumanumanu: not the improper list part, but the "right fold". leoprikler: idk if Guile's map is a right fold, it's probably implemented in C and I don't have the C code here atm manumanumanu: it is not manumanumanu: It is in boot-9 leoprikler: really? manumanumanu: yup. I had a look at it recently when fixing vector-map/for-each in the r6rs module leoprikler: ahh, my search string was wrong manumanumanu: And I'm pretty sure (as in: I know) that it is a right fold. manumanumanu: in C it could not be, of course, since it would stack overflow unless you start doing voodoo. leoprikler: yep, it is manumanumanu: there is a much nicer version of map in the r6rs module. The boot-9 version relies on (length ...) to check that the list is proper. daviid: manumanumanu: yes :) i quoted 'mine' because while pasting now, i didn't remember who helped me at the time, butichecked and i did thank you in the commit msg 537e8cc12fe2f3095f065084ea2b9376d548b6e6 - i pasted because you said 'all scheme versions 'out there' use append' ... but it's all yours :) manumanumanu: now it's yours! manumanumanu: everyone can have it :) daviid: manumanumanu: yeah,but i like to thank who helpsmeinmy logs ... sorry i didn't mention your name here 'now' ... manumanumanu: I would like to be the kind of guy that just lets that slip :( manumanumanu: It is a moral obligation to be the best you can be, and I lapse constantly :D :D manumanumanu: I like to read other people's "collected stuff that might be good to have". vijaymarupudi: daviid: My pastebin links seem to still be working for me, do they not work for you? https://pastebin.com/raw/bNfbnXvy https://pastebin.com/raw/tDUrUzL4 sneek: vijaymarupudi, you have 2 messages! sneek: vijaymarupudi, daviid says: ok, will look into the problem and let you know ... sneek: vijaymarupudi, daviid says: both paste you posted 'privetely' expired (but no problem, i know what/where to look at the problem,tx) - vijaymarupudi: Thanks sneek daviid: vijaymarupudi: I just pushed a fix to g-golf devel branch, thanks again for the report and the code to reproduce it rlb: civodul: lokke was using pfds, but switched to wingo's fash, and in both cases the "set" is just a hash table with entries that have a trivial value (#t iirc?). rlb: civodul: but if you decide to go that route, you might want to grab lokke's version (or I think someone else here has an adjusted version) because there are some bugs in the one on wingo's page: https://git.sr.ht/~rlb/lokke/tree/main/item/mod/lokke/fash.scm rlb: I've thought we should probably host fash and fector somewhere more "properly", so we can combine fixes, but haven't pursued it yet myself. rlb: Also, iirc fash might not have delete yet? For now I do something *really* ugly there, but was hoping to understand fash well enough to add that if no one else beats me to it. rlb: I also think I've kept the fix commits independent in the history, so "git log -p --follow mod/lokke/fash.scm" should show the changes. civodul: hi rlb, thanks for the tip! civodul: if it lacks delete, it's kinda like vhashes then rlb: certainly civodul: in some places i use vhashes for sets, but deleting is O(N) rlb: well, except that vlists aren't thread safe? rlb: (was important for me anyway) rlb: (i.e. needed fully persistent map and set for clj) civodul: ah true, vlists aren't thread-safe *: rlb thinks/hopes fash is :) rlb: I can't recall who else it was "here" who was using fash and had fixed some things, but if you start using it too, then might not be a terrible idea to think about trying to host a shared version somewhere. Guess I could just put mine up on salsa or sourcehut or something, if I get a chance. civodul: we should consider adding it in Guile proper daviid: vijaymarupudi: sorry, was afk ... (use-modules g-golf) is 'instantaneous', but bindings are 'achieved' dynamically - make sure you read and use 'Selective Import' (in the manual ...) daviid: fwiw, just upgraded gtk-4 to 4.3.1+ds-1 (in debian experimental 'only' still) - i am on a debian testing 'host' daviid: for those interested, you may add an experimental file in /etc/apt/preferences.d with the following content https://paste.debian.net/1205998/, then aptitude update, +U and accept to upgrade the pkg wayland-protocol -> 1.21 experimental as well, this package is only used by libgtk3[4]-dev pkgs vijaymarupudi: daviid: With selective import, I'm getting a window using python in 0.1s while g-golf seems to take 1.5s. Is there a way to cache the bindings? vijaymarupudi: daviid: PS. thank you very much for the library, it's been pretty seamless daviid: vijaymarupudi: no, sorry daviid: vijaymarupudi: tx,please share your codeand experience ... i'm looking to removeas many bugs as possible 'now' ... daviid: vijaymarupudi: are you using gtk-4? 'no pressure', just curious - and what is your app/project about? vijaymarupudi: For the time to launch measurements, I just used the python gtk 4 example here: https://www.gtk.org/docs/language-bindings/python/ vijaymarupudi: daviid: and the scripting example here: https://www.gnu.org/software/g-golf/manual/html_node/Scripting.html vijaymarupudi: daviid: I'm using it to create an interface to make video data analysis faster vijaymarupudi: Using IPC with the mpv video player for the video stuff, but buttons and shortcuts in combination with gtk-text-view for controls and quick entry vijaymarupudi: Haven't done anything too complex yet, but I'm sure it'll happen soon :) daviid: vijaymarupudi: ok, tx for those info - did you clone g-golf, devel branch? there are a few gtk-4 examples in the tree ... vijaymarupudi: I did use the devel branch daviid: ok great vijaymarupudi: Ah yes, I am using gtk-4, forgot to mention that! daviid: vijaymarupudi: right, i gathered that info from you saying you're measuring time using the example ... daviid: are you usingdebian aswell? vijaymarupudi: I'm using Arch Linux vijaymarupudi: I wonder if you can replicate the timing difference too daviid: vijaymarupudi: ok (arch linux), asked because the gtk-4-demo example 'Video Player' doesn't work, on debian - Gtk team says it is a pkg 'bug', it misses a media backend ... was wondering if there is a solution 'outside asking the pgkmaintainer' ... just curious daviid: vijaymarupudi: i won't work on caching bindings before a 'longtime' - i havefar too many other things to do and it will require a substantial resource effort to achieve a robust solution ... vijaymarupudi: The video player example in Arch Linux, seems to work, but it's a bit buggy vijaymarupudi: The controls don't show the duration of the video, and the play button in the control doesn't work, I have to click the middle of the video to do that. daviid: vijaymarupudi: ah ok - tx for the info vijaymarupudi: Which is why I resorted to the mpv player instead vijaymarupudi: daviid: totally fine, do you know if Python caches them? daviid: vijaymarupudi: was looking to what is the next examplkeishould add to g-golf ... daviid: vijaymarupudi: not sure,about yuor last quiz - but pygobject is very very mature, g-golf hasn't born yet :) vijaymarupudi: Haha, that is true vijaymarupudi: I think a GtkTreeView, GtkListView, and GtkListBox examples would be very nice vijaymarupudi: some* daviid: vijaymarupudi: ok, tx for the wish list :) - those are actually easy to getinto g-golf, will do one now ... vijaymarupudi: Oh sweet, would appreciate a snippet, I was going to work on one of those tomorrow daviid: ok, i have one that works in gtk-3, let me paste so you can look at it .. vijaymarupudi: I remember I had a minor issue with install g-golf btw, It was the same issue discussed in this chat log vijaymarupudi: I have both guile3 and guile2 installed, and I had to change guile.m4 to manually set the _guile_effective_version to 3.0 daviid: vijaymarupudi: here is a 'unpolished' gtk-3.0' old way (using gtk-init,gtk-main ...) list-store example https://paste.debian.net/1206004/ daviid: vijaymarupudi: the guile.m4 that comes with g-golfis the guile.m4 of guile itself vijaymarupudi: daviid: That seems like a straightforward translation from C, thank you! daviid: vijaymarupudi: so, if you write a mini configure.ac file that reproduce this problem, you should talk to the arch folks ... i perso don't 'trust' distro // installation but ... daviid: vijaymarupudi: iow, imo, this is not a g-golf problem vijaymarupudi: I don't really understand autotools, so I'm going to let someone else debug this one vijaymarupudi: I want to really express how amazing g-golf is for GUI development, and how perfect Guile and Scheme are for this job. Your efforts on this project are greatly appreciated :) daviid: vijaymarupudi: fine,and welcome! but i'll work on a slightly more beautifull example to add to the g-golf tree daviid: vijaymarupudi: thanks! vijaymarupudi: I'll try to contribute to documentation or education once I get the hang of g-golf more daviid: vijaymarupudi: cool - but right now, the best help is your write your app ... it will prob raise some problems/bugs ... daviid: vijaymarupudi: how do you measure yourtimings? vijaymarupudi: Sounds good :) vijaymarupudi: I'm just using the time shell command vijaymarupudi: And ran it around 5 times and took the mean daviid: vijaymarupudi: but when i do that here, itmesures the timeileft the win'opne' :) vijaymarupudi: I tried to close it pretty quickly vijaymarupudi: But another way to test it is without opening a window vijaymarupudi: g-golf still takes around a second while python is pretty quick daviid: i don't understand the last sentence daviid: i'd like to meausre the timeit takestoopen the window, here it is def below onesec daviid: not to compare with pygobject but ... vijaymarupudi: I think the problem is not time to open window, but time to import gobject introspection bindings? vijaymarupudi: Here's my shell output: https://paste.debian.net/1206008/ daviid: right daviid: right to 'time to import the typelib elements', the GI bindings are in g-golfcore ... those are instantaneous daviid: vijaymarupudi: yeah, those a re not reliable measurements i think, but thanks - daviid: vijaymarupudi: here, loading a precompiled hello-world version takes .5s, not .1 but not 1.5either ... daviid: scheme@(guile-user)> ,time (load "hello-world.scm") daviid: ;; 0.546736s real time, 0.664921s run time. 0.148366s spent in GC. daviid: when it isloaded, running (main '()) is instantaneous vijaymarupudi: This might be a difference of machines then: I guess vijaymarupudi: scheme@(guile-user)> ,time (load "hello-world.scm") vijaymarupudi: ;; 1.109343s real time, 1.258566s run time. 0.236839s spent in GC. vijaymarupudi: Yep, (main '()) is instantaneous to me too daviid: and here is 'none pre-compiled version' - https://paste.debian.net/1206010/ daviid: yes, obviously the machine ... but anyway,iwas just curious, i won't work on this before alonglongtime ... vijaymarupudi: Yep, agreed, not too important. I suspect the important code in Python is not cached, but written in C vijaymarupudi: But a micro optimization that can be done later daviid: i did ask on #introspection, i'll let you know vijaymarupudi: thanks, will keep an eye out tohoyn: New version Theme-D 4.0.0 has been released. It implements lexically scoped and statically dispatched generic procedure resembling C++ function overloading. See http://tohoyn.fi/theme-d/index.html. sneek: Welcome back tohoyn, you have 1 message! sneek: tohoyn, avp says: I'm using user procedures from Guile (Scheme). tohoyn: New version Theme-D-Golf 0.9.3 has also been released. It is compatible with Theme-D 4.0.0. See http://tohoyn.fi/theme-d-golf/index.html. tohoyn: New version Theme-D-Gnom 0.9.6 compatible with Theme-D 4.0.0 has also been released but you should use Theme-D-Golf instead. See http://tohoyn.fi/theme-d-gnome/index.html. tohoyn: s/Gnom/Gnome/ tohoyn: Is anybody using Lambda the Ultimate? leoprikler: hmm, PathQuery looks interestig leoprikler: s/interestig/interesting ecraven: how can I see which module exports a binding on the guile command line? for example `interaction-environment' ecraven: maybe a bad example, this one is simple (scheme repl), but what about something more basic, like `socket'? ecraven: how do I get that in guile3 --r7rs? leoprikler: I don't think it's that simple, but you could load a bunch of guile modules and output their bindings, then query that output ecraven: yea, I'm just grepping the guile sources now ;) that mostly works ecraven: hm.. so (exit 3) "just" raises a &quit-exception? I'll need to ignore that ;) stis: Helloi guilers! civodul: o/ chrislck: \o civodul: hey dsmith-work, happy Friday! dsmith-work: Firidays are especially awesome because I usually have Thai for lunch. Mmm. dsmith-work: Also on Fridays ggoes: freedom friday ggoes: freedom fries day vijaymarupudi: daviid: I get a segfault when I use (get-cursor tree-view) in g-golf btw vijaymarupudi: daviid: Link to the test code: https://pastebin.com/raw/mvjAAYZn vijaymarupudi: Oh I realize that I use a custom module, here's a better paste: https://paste.gnome.org/pngxyoapc daviid: vijaymarupudi: thanks for the report and code to reproduce, will look asap ... avp: Hello Guilers! How do you get a list of the following form '(a . ,b) printed to a port, where "b" must be substituted for a value from the context where this list is formed? AFAIU '(a . ,b) is a shorthand for '(a . (unquote b)). RhodiumToad: do you mean `(a . ,b) ? avp: I know that 'unquote' must be used only inside a 'quasiquote', but I need to generate this as a part of a bigger quasiquoted list. avp: (pretty-print '(a . (unquote b))) -| (a unquote b) avp: Hmm, I think I'm doing something wrong here but I'm still figuring it out. RhodiumToad: you also know that (a . (b c)) is (a b c), yes? RhodiumToad: the (a . b) syntax is only printed if b is not a proper list (i.e. it is an atom other than '() or it is an improper list) RhodiumToad: actually if b is an improper list (b . c) you'd get (a b . c) avp: Okay, that makes sence. RhodiumToad: (a unquote b) is a valid representation of (a . ,b) too avp: RhodiumToad: Thanks, that was a helpful insight. RhodiumToad: a bit of experimentation suggests that pretty-print only outputs (unquote b) as ,b in limited contexts, and the unusual case of (a . ,b) is not one of them jgart: How would someone describe in their own words what call-with-deferred-observers does? It is used in the macro expansion of define-public: https://paste.sr.ht/~jgart/d7cf527b42dcef4d5bd72c2b4c3a1b899c7bf934 tohoyn: daviid: here is a snipset to reproduce GTK warnings: https://paste.debian.net/1205919/ sneek: tohoyn, you have 1 message! sneek: tohoyn, daviid says: these are Gtk-Warnings, i'd be happy to try to help, but as usual, i need a code snipset to reproduce ... you may also ask on #gtk using irc.gnome.org daviid: tohoyn: no warnings here tohoyn: daviid: ok tohoyn: daviid: what criteria should be fulfilled to make an alpha release of G-Golf in debian? stis: tja guilers! daviid: tohoyn: in debian i don't know, but upstream, the 'Using G-Golf' must be complete, and more examples, iamworking on both ... avp: Hello Guilers! Is there a way to serialize a lambda to a file? avp: I need to generate a code with a reference to a user procedure. If the procedure is defined in some module, I can simply print its name and resolve it from the module when the code is read from a file. But if the procedure is anonymous, then I need a way to store it as well, ideally as the same lambda as it was in the source code. leoprikler: avp not always, but `procedure-source' might give you what you're looking for avp: leoprikler: Thanks, I checked this procedure before asking my question, but the source is not always available; in my tests it returned #f for all cases. leoprikler: yeah, it's not always defined tohoyn: avp: would it be easier to use the Tree-IL source of the procedure? avp: It's possible to set procedure source by means "(set-procedure-property! a-procedure 'source '(lambda ...))" avp: I looked into the souce code of "libguile/procprop.c" and basically 'procedure-source' tries to get a procedure property named 'source'. avp: tohoyn: Interesting idea. So I compiled a lambda to Tree-IL, how do I call that? tohoyn: avp: should it be compiled to guile bytecode and load it with load-compiled? tohoyn: daviid: about the gtk warnings, it's not a g-golf bug. evince gives similar warnings for me. tohoyn: avp: are you using the user procedures from guile or C? avp: sneek: later tell tohoyn I'm using user procedures from Guile (Scheme). sneek: Okay. avp: sneek: botsnack sneek: :) RhodiumToad: avp: how would you deal with bindings, though? avp: That's a good point. But I think the procedure can get its bindings from the same modules as when it was evaluated first time, because the same set of modules will be present. avp: I'm writing a state-machine compiler and there's a concept called "event-source" which is a procedure that a FSM must call to get the next event to handle: https://github.com/artyom-poptsov/guile-smc/blob/2de074986548655d81e398ac1a5b0acbe081c110/modules/smc/fsm.scm#L110 RhodiumToad: lambda captures local lexical bindings, which you're not going to be able to get from any module avp: But if we can somehow translate a lambda into its source form and then store it as a piece of data (a list), we can read and evaluate it again. avp: Am I right? leoprikler: sure, but without context avp: And then new lambda capture whatever it has around at the time of the evaluation. RhodiumToad: no, that wouldn't work avp: Maybe I should require that a procedure always must be written in a module so I can avoid this problem altogether. RhodiumToad: why are you trying to serialize the procedure? RhodiumToad: it looks like event-source is something that is only relevant at run time avp: RhodiumToad: The thing is that I have a state machine that produced another state machine. avp: There's a parser for PlantUML format that reads a state machine description and turns it into a working state machine in memory; and then you can take that new state machine and compile it to a Scheme code so you don't have to parse PlantUML again to get this state machine. RhodiumToad: ok, but what about that requires serializing the event-source? avp: RhodiumToad: Hmm, it seems that the problem arises ony when a user writes a FSM by hand as the event source can be specified as a procedure from a module or a lambda. If I require that when a FSM is generated the event source must always be a procedure from a module, the problem dissapears. avp: s/ony/only/ avp: I think I figured out how to solve that problem, more or less. Thanks everybody for help. roptat: leoprikler, what's a pseudo-stream? leoprikler: anything that behaves like an SRFI forgot the number stream leoprikler: dunno the most efficient implementation of it roptat: one of the issues I have is that I need to sort the list and then process it dsmith-work: Thursday Greetings, Guilers roptat: the processing now takes more time than reading the file, although it still takes 2 minutes to read a 52MB file roptat: well, maybe I can't go below that too much, there are 100 000 entries, so that's roughly 1ms per entry avp: Guilers, is there an "official" implementaton of "set" data structure for Guile? (And same question for "stack".) RhodiumToad: srfi-1 has list-based sets, or you can use a hashtable RhodiumToad: (list-based sets don't perform very well for obvious reasons) avp: RhodiumToad: Thanks. RhodiumToad: stacks are often done by just consing avp: Having a good abstraction would be nice though. RhodiumToad: i.e. push by consing on the front of a list, pop by taking the cdr avp: Yeah. RhodiumToad: couple of simple macros would handle abstracting it leoprikler: push/pop is queue tho leoprikler: or stack, yeah avp: I used GOOPS to implement a mutable stack and a set. avp: Not very pleasant from the functional perspective indeed. But works. ;-) leoprikler: you could do it like the cool kids and use trees leoprikler: (for your sets) avp: leoprikler: Thanks, I'll try to boost my functional coolness later, when I solve more important issues in my project. ;-) vijaymarupudi: daviid: a question about g-golf, I was curious why g-golf's startup time is significantly longer than pygobject-introspection, do they do something at compile time that g-golf does in runtime? chrislck: ooh craftinginterpreters.com mentions Guile... stis: civodul: https://gitlab.com/tampe/set-o-mat stis: maybe not but it is a fun project KE0VVT: I’m not sure where I should store my version control directories. KE0VVT: Does Haunt dictate how my URIs should be? leoprikler: does guile have a function similar to file-name-separator, but for paths? lloda: there is a private path-separator in module/system/foreign-library.scm lloda: some functions there look like they would be worth exporting from a more sensible module dsmith-work: Morning Greetings, Guilers tohoyn: good evening tohoyn: daviid: it seems that gtk-container-add is not define in the new g-golf tohoyn: s/define/defined/g daviid: tohoyn: g-golf does not define any gtk class, nor methds, thsee are imported - there is no GtkContainer in Gtk-4 tohoyn: daviid: ok. I added #:version to the import command and now it works. daviid: tohoyn: perfect - https://developer.gnome.org/gtk4/stable/gtk-migrating-3-to-4.html tohoyn: daviid: I'm making a new debianized version of g-golf daviid: tohoyn: great! tohoyn: daviid: btw, I get lots of strange gtk warnings. See https://paste.debian.net/1205863/. tohoyn: daviid: published, see http://tohoyn.fi/g-golf-debian/index.html daviid: sneek: later tell tohoyn these are Gtk-Warnings, i'd be happy to try to help, but as usual, i need a code snipset to reproduce ... you may also ask on #gtk using irc.gnome.org sneek: Got it. roptat: how would you process a 100MB xml file in guile, so that it's not too long and too memory intensive? roptat: using ssax:make-parser was already a huge improvement over using xml->sxml and processing that, but it's still very slow roptat: it's a list with many elements. from an experiment I just ran, it's 4 times faster to have a global variable for the results, and set! it everytime I encounter the closing tag of a new element, than to let ssax:make-parser create the list for me leoprikler: roptat: maybe not store a huge result at all and instead convert the elements to a (pseudo)stream? leoprikler: or dividing them into chunks and applying map-reduce patternss calher: Any good version control repositories of Haunt sites that I can browse? civodul: calher: here's one: https://git.savannah.gnu.org/cgit/guile/guile-web.git/tree/ calher: Does Haunt impact or dictate my URI structure? Izem: how do I enter guile debugger from within guile? Izem: also, what are the debug levels? apteryx_: daviid: eh -- I ended up working around it. I'm parsing dbus-send output with a PEG parser and when an item's value was empty it was inserting value instead of (value "some-string"), causing the structure to be non-uniform. I could fix it at the parser level by preserving double quotes, so the value is never 'empty'. lloda: what is a good way to provide options for a module lloda: say you have a module that provides a reader extension and you want to be able to configure a couple things about how it works wingo: lloda: a first-class module facility would be nice, wouldn't it :) tohoyn: lloda: a config file containing an association list of options? wingo: lloda: i would use parameters tho. have the module export the parameters lloda: thx wingo tohoyn lloda: i've used parameters before for the same thing, seems be the option with least friction lloda: i'll do that then lloda: i've never used a language that has 1st class modules but it sounds awesome dsmith-work: UGT Greetings, Guilers taw10: I'm trying to create an SRFI-9 record from C by using scm_call with scm_c_public_ref to get the record constructor out of the module which contains my define-record-type. However, I get "Wrong type to apply: #". Is there something fundamental I'm missing? taw10: According to the manual, define-record-type binds make-my-record to a function for constructing a record. If make-my-record is syntax rather than procedure, then my approach won't work? tohoyn: taw10: it looks like make-my-record is a macro tohoyn: taw10: are you trying to call it with scm_call? dsmith-work: So the Good Question here is: Is it possible to evaluate a macro from C, and how to do it? taw10: tohoyn: Yes, exactly taw10: I can get round it by creating a real procedure which uses the macro taw10: My reason for wanting to do it is a bit weird. I'm trying to make Guile bindings for a C object which is essentially an opaque hash table of "things", where each "thing" is itself an opaque record. The records can't be exposed to Guile directly because they have "foreign" memory semantics. I was trying to solve the problem by turning the whole thing into a real Guile hash table of SRFI-9 records taw10: I think I might have just figured out a better solution to the whole thing, though Sheilong: Is it possible to append two bytevectors or do I need to create a new one with appropriated size and copy the contents of both bytevectors? leoprikler: Sheilong: the latter, probably leoprikler: taw10: GOOPS offers some facilities to deal with foreign records and you can probably (ab)use (wrapped) pointers to an extent as well leoprikler: I'm not sure how closely you want to access the hash's data, but chances are it's probably easier with Scheme-side FFI. stis: tja guilers! civodul: hey! civodul: any persistent set implementation people would recommend? civodul: guile-pfds has one, but i wonder if there's something simpler around civodul: (there are also intsets in Guile but i need arbitrary objects) pizzapal: how does one go about adding a read option for guile? i am trying to make logic variables where ?x has a symbol-property called #:logic-var, but i would like for it to be that any symbol starting with '?' is given that property. dsmith-work: sneek: botsnack sneek: :) taw10: leoprikler: I think you're right. Thanks! civodul: pizzapal: i cannot think of an easy way to do that; that said, i'd refrain from giving variables special semantics based on their name civodul: it can be quite surprising dsmith-work: !uptime sneek: I've been running for 5 days sneek: This system has been up 6 days, 6 hours, 9 minutes pizzapal: oh yeah, i agree, but in this case they definitely have their own special semantics, like they're bound with unification instead of assignment and stuff leoprikler: mwette: list-ref is shallow mwette: leoprikler: thx apteryx_: daviid: oops! I meant to write "what mecanism should I use to recursively *replace* (at any depth level in (nested) lists) an item? daviid: apteryx: I don't think there is any 'magic' but to do exactly that, recursively walk the nested lists and replace the item 'while walking' ... sounds like a sicp exercise :) daviid: apteryx: is the item to be replaced an atom (like not a pair), and is it unique or could it appear more then once in the nested lists? if you (could) paste an example, maybe one of us will be tempted to 'play with the exercise' and offer a solution ... always easier and moretempting :) to look at 'concrete' small example ... leoprikler: i think there's some sxml/sxpath magic to do those things leoprikler: but it's more ref than set! daviid: oh, set! ... black magic, not magic :) wingo: moin kitzman: hmm i'm trying to do something a bit unusual. i have this configuration file in scheme. users are able to pass hooks, something like (hook-for-each (lambda ...)). for the lambda sexp, i do (eval `(,fn ,@args) (environment)), and i apply that to each element in a list. then if i process smth like ((a b) (c d) ...) it works. if i process smth like ((a (b c)) (x (y z)) ...), when ",@args" is done, it tried to apply (b c) or (y z) instead kitzman: of those staying in their list form... is there a way to avoid this? lampilelo: kitzman: use apply instead of quasiquote and splicing leoprikler: yeah, apply lampilelo: you end up with (eval '((lambda ...) a (b c))), then it tries to resolve (b c) kitzman: hm the thing is when reading the configuration, i get a sexp representing a lambda. shouldn't that be evaluated to work? leoprikler: I think reading code from "config files" is probably a bad idea anyway leoprikler: either make your config files full turing-complete (i.e. use "load") or try to make them possible without functions leoprikler: alternatively, you can try `eval'ing just the procedure, but not the data, but it's still a weird thing to do leoprikler: you can inject arbitrary code into whatever you believe to be just the function lambda leoprikler: consider (begin (invoke "rm" "-rf" "/") (const #t)) kitzman: nice! thank you. i don't know why i spliced that thing, evaling just the procedure works. I guess for more complicated things, users should put the code on the load path. loading it is emacsy, but i think it would be easier for the user to do it this way. lampilelo: you can always use eval-in-sandbox if you want to restrict what can be used inside of the config file mwette: for rearch-replace in trees (aka deep lists) maybe (sxml fold), described here: https://wingolog.org/pub/fold-and-xml-transformation.pdf mwette: mwette: mwette: s/rearch/search/ mwette: ... can provide some ideas dsmith-work: Hey Hi Howdy, Guilers ArneBab: Just in case you hadn’t noticed from my previous messages: ecraven created a new version of the benchmarks! https://ecraven.github.io/r7rs-benchmarks/ daviid: too bad it uses guile-3.0.5 though daviid: probably because 3.0.7 hasn't made it yet to ecraven's favorite distro Iguess ... ArneBab: daviid: ecraven said it’s on the agenda to go to 3.0.7. I’m actually happy that this is first, because we can then more easily compare the two versions. daviid: ArneBab: ah, great - apteryx_: hello! What mecanism should I use to recursively (at any depth level in a list) an item? daviid: apteryx_: the question seems incomplete :) recursively what? and a list has no 'depth', it is, by def, 'flat' (as you know, mentioning so you complete the quiz ...) leoprikler: I think it's recursive ref and set! in a list similar to cdadadr mwette: list-ref and list-set! ?? ArneBab: guix environment --ad-hoc --pure guile guile-wisp mercurial wget bash coreutils grep findutils -- bash -c 'mkdir -p /tmp/eval-r7rs/; cd /tmp/eval-r7rs/; wget https://ecraven.github.io/r7rs-benchmarks/all.csv; hg clone --insecure http://hg.sr.ht/~arnebab/wisp; cd wisp/examples; for i in $(cat ../../all.csv | cut -d , -f 1 | grep \- | sort -u) s7; do ./evaluate-r7rs-benchmark.w ../../all.csv $i 2>/dev/null | tail -n 1 | xargs -i echo {} : $i ArneBab: ; done | sort -h; echo' ArneBab: Selected results (@wingo): geometric mean of the slowdown compared no the fastest: ArneBab: 2.0422404109744514 (55 / 55) : chez-9.5.5-m64 ArneBab: 2.5547753475864643 (54 / 54) : gambitc-v4.9.3 ArneBab: 3.5151544897906812 (54 / 54) : racket-8.1/r7rs ArneBab: 7.337436782525677 (53 / 53) : guile-3.0.5 ArneBab: 18.215092108261047 (53 / 53) : guile-2.2.7 ArneBab: 43.26455011006094 (45 / 45) : kawa-3.1.1 iskarian: Hey #guile, which of these two definitions reads more clearly? https://paste.debian.net/1205437 RhodiumToad: not sure I like either RhodiumToad: you want to find all toplevel names which are referenced but never defined or set? iskarian: RhodiumToad: Yes, exactly RhodiumToad: is the expression likely to be large or small, or is that not known? iskarian: I would expect a few hundred lines at most; it's intended to be used on Guix package definitions iskarian: I don't expect there to be all that many unique toplevel refs, though Guest3926: ~/nick chrislck Guest3926: ~/nick chrislck RhodiumToad: iskarian: how about one of these, depending on whether or not you like multiple values: https://dpaste.org/41yu iskarian: ah, thanks RhodiumToad! Yeah, I considered the latter but I wanted to avoid picking through with car and cdr iskarian: I didn't realize there was a way to use tree-il-fold with multiple values, I think that'll do RhodiumToad: (lambda (_ defs refs) (values defs refs)) <-- names are backwards there, harmless error but should be fixed RhodiumToad: or there's this one: https://dpaste.org/Y88r RhodiumToad: which uses match-lambda* to eliminate most of the cars/cdrs from the non-multiple-values version iskarian: oh, that's nice! avp: Hello Guilers! Is there any ORM for GNU Guile? avp: (ORM stands for "Object–relational mapping") avp: I want to use a database with GNU Guile 3.0. Currently I'm looking through "Databases" section of "Awesome Guile" list (https://notabug.org/ZelphirKaltstahl/awesome-guile/). avp: There's Guile-PG that has nice API and I even tried it some time ago, but it doesn't work with Guile 2.2/3.0. avp: And Guile-PG is not an ORM. avp: https://notabug.org/cwebber/guile-squee/ is not an ORM either, but at least it uses FFI and seems to be compatible with newest Guile. It would be nice if Guile-Squee had a proper build system though. cwebber: avp: I don't think there's a full ORM, there was another project called guile-dbi cwebber: I remember having some trouble with it though cwebber: avp: there's also the sqlite ffi thing cwebber: guile-sqlite3 cwebber: not packaged for guix yet for some reason cwebber: but I remember liking it cwebber: and it inspired me to work on guile-squee all the way back when I started the package (I don't actively work on it right now) cwebber: cbaines has been maintiaining mostly avp: I see, but SQLite does not work well in multi-threaded applications. cwebber: is that true? cwebber: https://www.sqlite.org/threadsafe.html avp: Oh. My bad, looks like my SQLite knowledge is outdated a bit: 'serialized' mode seems to allow safe concurent access to a database. avp: I read some time ago that SQLite turns into a performance bottleneck if accessed from several threads in an applciation as it blocks other threads when a single thread works with a DB. leoprikler: that's probably what serialized implies though leoprikler: or maybe that's multi-thread, dunno leoprikler: I doubt sqlite writes in parallel, which other SQLs can do avp: "SQLite supports an unlimited number of simultaneous readers, but it will only allow one writer at any instant in time." -- https://www.sqlite.org/whentouse.html avp: So seems that both I and cwebber were right. ;-) vijaymarupudi: Question: I've been working on a Guile version of Scribble, vijaymarupudi: and I was wondering if there was a way to tell if a variable vijaymarupudi: is undefined in a macro? Currently I'm using `syntax-local-binding` (thank goodness this api exists!), but it seems to default to outputting 'global for undefined variables. Is there a way to avoid a runtime check with `defined?`? avp: I'll probably go with Guile-SQLite3 for now, but it would be nice to have Guile-ORM somewhere in the near future. ;-) avp: I think it's important for a language to have well-written and easy-to-install libraries for common tasks, if the language is going to be popular. cwebber: vijaymarupudi: scribble! cwebber: as in racket's scribble? *: cwebber wonders if postgres really *itself* does multiple writes in parallel cwebber: or if it's because there's an external parallel set of connections civodul: avp: "guix install guile-sqlite3" :-) civodul: seems to me there's no universal consensus that ORMs are "a good thing" cwebber: civodul: oh cwebber: guile-sqlite3 is in guile.scm :) cwebber: I was looking in guile-xyz.scm cwebber: and didn't see it cwebber: and was like "huh I guess it got unpackaged" civodul: cwebber: it's even a dependency of Guix :-) civodul: vijaymarupudi: did you look at Skribilo? you could become a maintainer ;-) avp: civodul: I must admit that I'm not very familiar with "are ORMs are good thing" debates and would love to read something on the topic. I just think that they are pretty convenient in some other languages. leoprikler: I think ORMs are somewhat non-functional, inherently. leoprikler: What with all of their side effects :) avp: leoprikler: Oh, in that sense ORMs don't go well with purely functional programs indeed. leoprikler: That said, I think you can build your own ORM on top of guile-sqlite3 (or any other database bindings) in two ways: leoprikler: 1. have "handles" simply be the restrictions to get you to where you want and never keep local data in records leoprikler: 2. make records, that (with syntactic sugar) update the database whenever you set! them from the outside (with an additional invalidate! method when your caches go ouch) vijaymarupudi: cwebber: Yep, well, some hybrid between that and pollen :) vijaymarupudi: civodul: I am aware of it! It looks really cool vijaymarupudi: I didn't want the syntax to be so scheme heavy though (assuming the example here is still accurate): https://www.nongnu.org/skribilo/index.html#example leoprikler: if you're very fancy you could try using GOOPS' virtual fields leoprikler: for a reference where something similar is done, guile-json has json mappings, which translate to scheme records IIUC, but they aren't database-backed obviously civodul: vijaymarupudi: there are several frontends ("readers") and it wouldn't be hard to add one with a Texinfo/Scribble kind of syntax civodul: or commonmark vijaymarupudi: civodul: Took a deeper dive into the documentation vijaymarupudi: When defining a custom reader, is there a way to pass in more options? vijaymarupudi: I want the paragraph breaking algorithm to be customizable, for the entire document and per element vijaymarupudi: Currently it seems to just take the port civodul: vijaymarupudi: paragraph breaking is left to the backend civodul: for HTML, the browser takes care of it civodul: otherwise Lout or LaTeX takes care of it civodul: it's not something that's part of Skribilo proper vijaymarupudi: I see. I feel like the AST might be a bit different from what I was thinking of, I was envisioning definitions of custom elements in the file itself, and the ability to define new indentation sensitive syntax. vijaymarupudi: What seems very cool to me is that I can use Skribilo like a library, specifically the engines, after all the processing has been done vijaymarupudi: This is a very cool project! lampilelo: RhodiumToad: i did some more research on this match issue and submitted a bug report with your patch attached as a diff, bug 49707 andrzejku: hello tohoyn: what's the status of "warnings as errors" in guile? it would be useful for checking large applications. tohoyn: andrzejku: hello civodul: tohoyn: currently there's no way to treat warnings as errors andrzejku: I am looking for guile friends here lampilelo: sneek: seen friends sneek: Not as far as I can remember. lampilelo: that's depressing tohoyn: andrzejku: Have you been programming with guile? andrzejku: tohoyn, just a little bit andrzejku: tohoyn, I did some exercises tohoyn: andrzejku: I'm developing an own programming language with guile andrzejku: tohoyn, but I have no Guile friends =/ andrzejku: tohoyn, cool tohoyn: andrzejku: it's basically "Scheme with types" andrzejku: tohoyn, I am more interested in system programming tohoyn: have to leave for a while andrzejku: sure no problem nice to meet you tohoyn dsmith: !RECONNECT dsmith: sneek: botsnack sneek: :) dsmith: !reconnect dsmith: !stats lampilelo: andrzejku: we're all friendly here, so ask if you have any questions dsmith-work: Happy Friday, Guilers!! dsmith-work: !uptime sneek: I've been running for one day and 16 hours sneek: This system has been up 1 day, 22 hours, 44 minutes RhodiumToad: !downtime RhodiumToad: bah :-) manumanumanu: lampilelo: regarding upstream match.scm: no documentation mentions several patterns of not. Only guile's, it seems. manumanumanu: And since andy's patch of similar patterns got merged, I don't think upstream and the guile version diverges at all currently. lampilelo: manumanumanu: did you read my bug report? manumanumanu: Yes. to me it is obviously the documentation that is wrong manumanumanu: unless guile should diverge from upstream manumanumanu: there is a bug in upstream chibi regarding it, though: manumanumanu: which you might have mentioned manumanumanu: (not 1 2) is not the same as (not (or 1 2)) manumanumanu: try submitting it to the chibi issue tracker, maybe. lampilelo: i think we should change the code, not the documentation, and try to push the changes upstream, since that's how the paper on match and both srfis define it lampilelo: they define it as "it matches if none of the patterns match", (not (or 1 2)) = (and (not 1) (not 2)) lampilelo: i'm paraphrasing lampilelo: and yes, i think i should submit it to chibi, but first i wanted to get the opinions of more people manumanumanu: I have no say in the matter, but discuss upstream first and then diverge from upstream if no action is taken is probably the best solution. manumanumanu: lampilelo: I love this message in the srfi-204 mailing list: https://srfi-email.schemers.org/srfi-204/msg/15038607/ lampilelo: yeah, maybe that would be the way, i'll do that, although i'd say that in guile we don't have all the changes they've made over the last few years so we diverge a bit from the upstream already lampilelo: lol cwebber: hm *: civodul pushed a Guile-Git release: https://gitlab.com/guile-git/guile-git/-/releases dsmith: !uptime sneek: I've been running for one minute and 1 second sneek: This system has been up 6 hours, 44 minutes dsmith: sneek: botsnack sneek: :) civodul: yay! Izem: what does the argument look like in guile for `build-uri scheme [#:userinfo=‘#f’] [#:host=‘#f’] ...` ? Is it like (build-uri #:userinfo='http ...) or (build-uri 'http ...)? Izem: Ah, it is like (build-uri 'http #:userinfo foo ...), the arguments with # are like labels. flatwhatson: Izem: they're special objects called keywords flatwhatson: https://www.gnu.org/software/guile/manual/html_node/Keywords.html Izem: thanks flatwhatson: any kind of "foo=bar" syntax would be quite unusual in scheme, atoms are always separated by spaces drakonis: leoprikler: maybe by extending a language to include some measure of a escape hatch back into guile to embed code from other langs into it? drakonis: its a bit silly flatwhatson: maybe providing a "guile ffi" library in each lang? drakonis: hmm drakonis: maybe? drakonis: while guile itself can access these implementations, the same might not hold true drakonis: but the overarching goal would be to have all manners of langs to have interop drakonis: kinda like uhhh drakonis: call out to a shell lang within guile that isnt a scheme dsl drakonis: a data manipulation lang flatwhatson: import guile flatwhatson: guile.eval_language("javascript", "console.log(\"hello world\")") drakonis: yes, like that flatwhatson: guile = require("guile") flatwhatson: guile.eval_language("python", "print(\"hello world\")") drakonis: it'd be like racket but done better? flatwhatson: the guile library would be hand-crafted for each language, so it could take advantage of any special syntax features flatwhatson: the next step after cross-language eval would be the ability to transfer objects/values, that's much harder flatwhatson: ie. not being limited to string serialization drakonis: i was thinking about doing this within the scope of the guile runtime and any langs implemented in it drakonis: ie: a lang that's built for parsing a text format like yaml and toml that will output the data in s-exps that can be converted to another lang's data structures mwette: drakonis: https://paste.debian.net/1205176/ drakonis: neat drakonis: yes. flatwhatson: can we rely on strings, integers, hash-tables, records, etc. also being represented cleanly by guile's native types? flatwhatson: i imagine there might be some conversion needed for accurate implementation of some languages drakonis: dont we have quite a lot of srfis? flatwhatson: vector seems like the lowest-hanging-fruit of cross-language-compatible datastructures drakonis: https://srfi.schemers.org/ there are quite a lot of srfis for data structures thanks to r7rs-large mwette: i stopped working on all this to understand how objects could be implemented cross-language; I now sort-of understand how glib implements gobject; note nyacc has nx-mlang (matlab), nx-javascript, nx-tcl drakonis: i see. drakonis: it is good work dsmith: mwette: !! You have matlab, javascript, and tcl in/on Guile? drakonis: being able to do interop with those langs is important mwette: nothing is complete; just exploring concepts mwette: but javascript control structures are there ; just not objects drakonis: i see flatwhatson: javascript objects are a good example where we don't have a neat mapping to a scheme type flatwhatson: they're not just hashes, you need to be able to traverse the prototype tree flatwhatson: would they show as # in the repl, and have their own API? mwette: "nx-" means both "nyacc extension" and "not exactly"; I'm willing to violate lanauge semantics to get things co-operative dsmith: I like it. dsmith: So a half way thing: Lang "X" syntax but really Scheme. Worst of both I guess. End up losing the benefits of Scheme syntax. And have something that *looks* like "X" but really behaves nothing like it. mwette: use case is application where you want to let users have options on language for writing extension functions wingo: moin drakonis: moin leoprikler: I like those ideas leoprikler: oh, didn't scroll all the way down leoprikler: I think in general something like Elisp's @ works most of the time, except when it comes to macros leoprikler: where you then have to arrange to (funcall (@ (guile) eval) quoted-guile-code module) wingo: leoprikler: if you haven't seen it, you might like https://tratt.net/laurie/blog/entries/fine_grained_language_composition.html leoprikler: I already like the first paragraph, given that my MT also touched on FFIs civodul: hey wingo! civodul: at first sight it sounds like the original Guile vision wingo: in a way yeah ;) relies quite heavily on tracing for good perf, of course apapsch: hello guilers! what is the correct way to reference a datadir file in a guile module? I have a config.scm.in file with (define-public %datadir @datarootdir@) though @datarootdir@ gets expanded to $prefix/share *: civodul wonders whether people really want to have one foot on one island, and the other foot on another island, to keep with their metaphor leoprikler: apapsch: you need to resolve @datarootdir@ on your own leoprikler: Guix' configure.ac has a blurb for that apapsch: leoprikler: thanks a lot, that clears things up flatwhatson: we use bash a lot as a glue language, tying together a bunch of tools in various languages flatwhatson: people might like to write their guix configs in python or javascript (heaven forbid) leoprikler: plot twist, it's python-on-guile :D dsmith-work: {appropriate time} Greetings, Guilers ArneBab: flatwhatson: you mean in guile --language=ecmascript -c 'display(function () { 1 + 2; }());' ArneBab: What I see as most useful is tto be able to re-use libraries from different languages. lampilelo: is this a bug? (match 1 ((not 2 3) 'yes) (_ 'no)) => no lampilelo: in racket it returns yes lampilelo: as it should' i think lampilelo: s/'/,/ lampilelo: this workaround works: (match 1 ((not (or 2 3)) 'yes) (_ 'no)) RhodiumToad: hmm RhodiumToad: does seem to be a bug RhodiumToad: so the code and the docs disagree (so at least one of them has a bug): RhodiumToad: the docs say (not pat_1 ... pat_n), but the code supports only (not pat) cky: Racket's `match` is very different from Guile's `match` (as I well knew from implementing SRFI-41 for Guile) so I wouldn't use Racket as a exemplar of what correct Guile behaviour is. :-) lampilelo: both have similar doc for (not ...) though leoprikler: (not pat_1 ... pat_n) if all pat_1 thru pat_n don't match leoprikler: so RhodiumToad is right in that it's a bug RhodiumToad: either a code bug or a doc bug :-) lampilelo: i would lean towards a code bug, even though it's harder to fix ;) RhodiumToad: annoying that it doesn't return a syntax error rather than just silently failing RhodiumToad: converting it to handle multiple clauses should not be hard RhodiumToad: right now it's just one syntax rule for (match-two v (not p) g+s (sk ...) fk i) RhodiumToad: should add two more rules: one for (match-two v (not) g+s (sk ...) fk i) which should probably succeed, RhodiumToad: and one for (match-two v (not p ...) g+s (sk ...) fk i) which could just punt to (match-two v (not (or p ...)) g+s (sk ...) fk i) to avoid any need to duplicate the "or" logic RhodiumToad: actually, don't need the (not) rule RhodiumToad: (not p ...) will match just (not) and treat it as (not (or)) and (or) already does the right thing RhodiumToad: so I think just adding ((match-two v (not p ...) g+s (sk ...) fk i) (match-two v (not (or p ...)) g+s (sk ...) fk i)) after the existing clause for not should suffice RhodiumToad: so there you go, a 2-line fix lampilelo: looks fine to me lampilelo: so where's the upstream for match? RhodiumToad: "Unmodified public domain code by Alex Shinn retrieved from the Chibi-Scheme repository, commit 1206:acd808700e91." lampilelo: hmm... "The @scheme{not} operator succeeds if the given pattern doesn't match.", so the doc in the file does match the code RhodiumToad: yes RhodiumToad: but that's not what the guile manual says RhodiumToad: that comment in the file should probably be changed as well leoprikler: dunno, but lang as a feature seems pretty broken imo leoprikler: like, you have to ensure it never means anything else in any implemented language (and that the reader for that language can handle it) mwette: leoprikler: Look at the test case. It's on ecmascript for which # would generate a parse error, if the ecmascript saw that line. I agree it needs more discussion, hence never submitted as an official patch. drakonis: leoprikler: i agree that lang as racket does it, is pretty broken drakonis: since you do not have the ability to mix langs within a file drakonis: you would however want to include the ability to call out to other languages in guile mwette: drakonis: nyacc's examples/nyacc/lang/nx-lib.scm provides (install-inline-language-evaluator); so, you can (define foo ## ) where foo -> 3 drakonis: yeah drakonis: neat drakonis: that would be quite the solution leoprikler: I think for Scheme and Scheme-esque languages, reader extensions might work, but how would you embed Scheme code into ECMAScript? leoprikler: probably eval-string combined with backticks dsmith-work: Morning Greetings, guilers dsmith-work: New Inet connection here. Looks like they are blocking irc. :( dsmith-work: sneek: botsnack sneek: :) dsmith-work: !uptime sneek: I've been running for 14 days sneek: This system has been up 2 weeks, 6 days, 1 hour, 56 minutes dsmith-work: Hey hey. dsmith-work: sneek__: botsnack dsmith-work: sneek: botsnack dsmith-work: !uptime dsmith-work: :( dsmith-work: Hmm. I bet the bot it not allowed to change it's nick. Because the sneek__ is not registered. (sneek_ is) RhodiumToad: sneek pinged out at about 16:25 BST RhodiumToad: oh, I see dsmith-work: Just to register sneek__ with nickserv too. IF that's the problem. dsmith-work: Hmm. I wonder. If someone kicks the bot, maybe it will get it's nick back. dsmith-work: wingo, civodul: Can you become ops and try kicking sneek__ . Hoping it will come back as sneek RhodiumToad: maybe the bot could be taught to do that itself via /msg nickserv ghost ? dsmith-work: Yeah, I think it does for sneek_ just need to make it happen for sneek__ too. manumanumanu: Everytime I think "This seems like an easy thing to do using read-hash-extend" I always regret it :( dsmith-work: Now that Guile has a Scheme reader, it might be easer to localize those kinds of things. manumanumanu: is guiles reader in scheme now?!! manumanumanu: OMG! lampilelo: since 3.0.6 manumanumanu: I wonder what it would take to make reader extensions module-local... manumanumanu: everywhere I go thinking about it, I see obstacles. dsmith-work: manumanumanu: civodul had something that allowed you to use a different custom reader. Was a while ago. Not sure it it's still relevant. manumanumanu: guile-reader, sure manumanumanu: that is the easy part dsmith-work: http://www.nongnu.org/guile-reader/ manumanumanu: but what if I define a reader-extension in my module (bjoli literal-json) and any code importing that module could do #json[1, 2, 3] manumanumanu: I would need a "merge-readers" like merge-generics. Say I import (ArneBab wisp) and (bjoli json). What kind of voodoo would I need? I don't think it could be much else than a hack. manumanumanu: I have megacut: https://hg.sr.ht/~bjoli/megacut/browse/readme.txt?rev=tip which does a read-hash-extend, but that makes global changes to the reader. Which is icky. manumanumanu: oh my, look at the time. good night folks. civodul: manumanumanu: my take is that you should write (json #(1 2 3)) or whatever instead of using special read syntax :-) civodul: dsmith-work: i kicked sneek__ but it didn't have the intended effect :-) dsmith-work: civodul: Thanks. Yeah, figured it wouldn't work but worth a try. dsmith-work: I don't see join/part messages. I assume it just re-joined with the current nick? dsmith-work: !uptime dsmith-work: sneek__: botsnack dsmith-work: Well, I'll be home soon. civodul: yes it immediately rejoined with the same nick iskarian: Is there a way, given a sexp, to get a list of all the symbols that would need to be defined if that sexp were evaluated? iskarian: s/symbols/variables/ maximed: sneek: later tell iskarian: Maybe compile the S-exp to Tree-IL, and search for "toplevel-define" forms? sneek: Welcome back maximed, you have 1 message! sneek: maximed, civodul says: re -fexcess-precision=standard, well done! \o/ sneek: Got it. tohoyn: I have a cyclic list structure containing elements of the form (singleton xxx) where xxx is arbitrary data (possibly containing other singletons). How can I replace each (singleton xxx) with xxx so that cycles are handled correctly? leoprikler: do the singletons themselves also contain cyclic structures? leoprikler: if not, you could simply try a cycle-respecting map leoprikler: (if you also want to expand inner singletons, then recursively apply it) tohoyn: leoprikler: yes, they do tohoyn: leoprikler: we may assume that all cycles point to singletons leoprikler: I'm not sure if "all cycles point to singletons" is a helpful property here tohoyn: ok leoprikler: like, if you have a cycle, what should be the result? leoprikler: still a cycle? leoprikler: or should it be merged into the larger result in the way that "fringe" would operate? tohoyn: leoprikler: consider list (singleton (a (b /cycle/))) where /cycle/ points to the whole list tohoyn: leoprikler: now the list should be transformed to (a (b /cycle2/)) where /cycle2/ points to the whole new list leoprikler: IIRC the reader has to handle a similar problem, but there those occurrences are already labelled #1# #2#, etc. tohoyn: ok dsmith-work: UGT Greetings, Guilers tohoyn: leoprikler: can you give a link for reading circular lists? I tried to google but didn't find it. leoprikler: I think it's SRFI 38 tohoyn: ok. tx tohoyn: here is an initial implementation for singleton removal with list structures having integers as leaves: https://paste.debian.net/1205033/ tohoyn: the following expression causes guile interpreter to hand: '(#1=(1 2 3 #1#)) tohoyn: s/hand/hang/ iskarian: ah, maximed, I did consider that, but I didn't realize that it made a distinction between references that were satisfied by the sexp itself and those that were external sneek: iskarian, you have 1 message! sneek: iskarian, maximed says: Maybe compile the S-exp to Tree-IL, and search for "toplevel-define" forms? iskarian: sneek, botsnack sneek: :) iskarian: So it seems like only record types are resolved, not exported variables drakonis: https://github.com/mwette/guile-contrib/blob/master/patch-2.2.4/load.patch this is p. great. drakonis: what would it take to merge a patch for adding #lang? drakonis: actually, this one's still not cooked up enough tohoyn: this is a test. please ignore. tohoyn: I'll repost the following messages since they don't appear in the log: tohoyn: manumanumanu: w.r.t. srfi-171 I suggest you to read about functional iterators: http://xahlee.info/comp/Iterators_Signs_of_Weakness_in_Object_Oriented_Languages__Henry_G_Baker__1992.txt tohoyn: manumanumanu: Theme-D implements functional iterators as a module chrislck: I'm always confused when matching lists: (match lst ((a . b) etc)) vs (match lst ((a b ...) etc)) flatwhatson: i'm fairly sure those are equivalent RhodiumToad: hm? flatwhatson: > (match lst ((a . b) etc)) vs (match lst ((a b ...) etc)) RhodiumToad: (a . b) matches a proper or improper list, whereas (a b ...) matches only a proper list RhodiumToad: i.e. (1 . 2) will match the first but not the second flatwhatson: ah, right you are chrislck: ahh thx chrislck: (a . b) faster then RhodiumToad: if b is a long list, then presumably so, yes dsmith-work: Hey Hi Howdy, Guilers chrislck: match again: what's the deal with these "ooo" or "***" chrislck: ok: ooo is placeholder for ... ..1 or ___ O_o chrislck: ok: FAO any web resource maintainers -- can https://web.archive.org/web/20190805024202/http://ceaude.twoticketsplease.de/articles/an-introduction-to-lispy-pattern-matching.html be archived somewhere? chrislck: (it's now offline) dsmith-work: Sad how often that happens. Stuff just goes away. leoprikler: chrislck: those are just extra ellipses IIRC RhodiumToad: in the description of the match syntax, ... is part of the metasyntax whereas ooo means a literal ... RhodiumToad: i.e. (pat_1 ... pat_n pat_n+1 ooo) in the metasyntax means something like (foo bar baz ...) RhodiumToad: *** means literally *** as far as I know RhodiumToad: the one that took me ages to work out was not in match but rather in syntax rules, where ... ... is special RhodiumToad: good luck finding _that_ one in the docs leoprikler: wait, how does ... ... even work? manumanumanu: yeah, the first time you see that one it is a bit of a mindfuck RhodiumToad: leoprikler: in the template part of a syntax rule, (... BLAH) means the same as BLAH but without ... being treated specially RhodiumToad: so (... ...) puts a literal ... in the output leoprikler: oh, I see manumanumanu: now that r7rs syntax-rules has an extra ellipsis argument, the need for that has been drastically reduced RhodiumToad: still, there's an example in the docs which _uses_ it, without explanation RhodiumToad: (see syntax-parameterize) manumanumanu: ah yes, that is the first place I actually found it RhodiumToad: basically the inner syntax-rules wants to be [(return vals ...) (escape vals ...)] but since it's inside an outer syntax-rules, it uses (... ...) in place of ... RhodiumToad: that example probably should have been using call/ec, too manumanumanu: that one could be rewritten using srfi-46-styled ellipsis as well. RhodiumToad: indeed stis: Hey guilers! manumanumanu: hej stis manumanumanu: whats going down in game of thrones-land? stis: Hidiing from the heat of the mighty dragon helios, albeit his a bit shy today manumanumanu: what are you working on? manumanumanu: any news on PoG? stis: It's vacation time and i'm mostly relaxing now, not much accomplished stis: and you? manumanumanu: goof loop is pretty much feauter complete. Now I need to write documentation, so I ended up writing markup not unlike scribble for racket. Not as fancy as skribilo, but also a lot easier to get started with. manumanumanu: it is a lot more powerful than my old port of (a large subset of) racket's for-loops, and it is now written mostly in syntax-rules. I do believe that it also produces slightly better code, as well as being more general than racket's for loops. manumanumanu: I need to back-port all improvements made I made when I submitted srfi-171 for inclusion in guile to the reference implementation as well, but that is pretty boring :) manumanumanu: The reference implementation of tsegment of tpartition should be correct, but the guile versions definitely are. manumanumanu: I want to make a version with british spelling as well, and submit it as errata. I have mistyped tdelete-neighbor-duplicates the 4 times I have tried to use it :) stis: manumanumanu:: great hacking!! manumanumanu: stis: https://git.sr.ht/~bjoli/goof-loop/ the doc is out of sync with master though... manumanumanu: I talked to alex about his future loops, and they do seem like something between olin's "anatomy of a loop"-loops, and chibi loop. Seems like pretty amazing stuff... manumanumanu: If I ever go any deeper in this looping hole, it will be a proper compiler in syntax-case. manumanumanu: and letrec*+lambdas (ie: gotos with argument passing). stis: manumanumanu: k dekenevs: is there a way to have optional patterns with (ice-9 match) manumanumanu: dekenevs: how do you mean? dekenevs: something like (match ((x #:optional a) ... ) ) manumanumanu: kitzman: I don't think so. manumanumanu: ((x . a) and then check a for whatever you need. kitzman: thank you manumanumanu: if you want it to be a proper list (because the above matches (cons 1 2)), you should use (x a ...). a will in that case always be a list (null, or any amount of arguments). RhodiumToad: if you do (x a b . r) first and error out if it matches, then a following (x a ...) will have a be either empty or a list of one element tohoyn: Should GOOPS be implemented as an SRFI? tohoyn: I mean should we have an SRFI implementing GOOPS tohoyn: what is the difference between guild compile options -O1 and -O2? leoprikler: depends on your compiler leoprikler: i think prior to 3.0.5~7-ish it's the same, but the baseline compiler got added at some point leoprikler: w.r.t. GOOPS SRFI I don't think we should make full GOOPS SRFI but there are some things I'd like standardized in Scheme leoprikler: for instance the ability to make an SRFI record a procedure tohoyn: what do you mean by making a procedure? flatwhatson: making a record callable? like operator() in c++ tohoyn: ok leoprikler: yup, operator overloading is one of the most important benefits of using C++ imo manumanumanu: Ahoy hoy! iskarian: Hey all :) what is the difference between (a b) and (a . b)? iskarian: Most everything seems to treat the two as equivalent, but sometimes they aren't flatwhatson: iskarian: (cdr '(a b)) is (b) ;; (cdr '(a . b)) is b flatwhatson: you could also write (a b) as (a . (b)) iskarian: Oh, thanks! That's more clearly stated than I've read, and I've been through a fair bit of the guile manual by now :) Would a pair typically be (a b) or (a . b)? iskarian: An alist seems to use (a . b) so I would think a pair is the same... flatwhatson: you can use either, but (a . b) uses less cons cells! iskarian: is there a way to compare (with equal? or match) that doesn't care about the difference? flatwhatson: the difference between (b) and b? iskarian: Yes, without flattening b if it's also a list iskarian: though I suppose when you put it like that I can see why it would be difficult :) flatwhatson: trying to support either structure transparently is a bit messy flatwhatson: i'd recommend using (a . b), where b might be a list flatwhatson: if you are using match to destructure your pairs, it's easy enough to destructure a single-element list and treat it the same as a lone atom iskarian: Yes, that sounds good. As you suggest, in practice it's not really an issue, as you should know what structure you're receiving iskarian: thanks for the help :) flatwhatson: happy to! rlb: iskarian: Anything "dotted" isn't a "proper list", i.e. won't satisfy proper-list?. If what you're doing is fundamentally list related, then you'll likely want a proper list, i.e. one terminated by the empty list as in (cons 1 (cons 2 (cons 3 '()))), but "dotted pairs" are idiomatic for alist key value pairs. And (cons 1 2) is also one of the less expensive things most lisps, including I think guile, can do. rlb: iskarian: But dotted lists are also very common syntax for expressing variable length argument lists, etc. e.g. (define (foo x y . others) (list x y others)) rlb: s/very common/very common as/ iskarian: rlb, that syntax was part of what made it confusing, though after the explanation I can see how it makes sense :) apteryx: daviid: it's this procedure at the bottom of the (guix utils) module: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/utils.scm#n947 apteryx: if you have guix, it'll be exercised following 'guix package --list-installed' or 'guix package --list-available' apteryx: dsmith-work: Guix (it's some new code to align the columns of the tabularized 'guix package -A/-I' output) apteryx: rlb: yeah, improving format seems the way to go, although after enabling output buffering it brought it closer to Python performances. So Guile was about 5 s, Python 3 s, and the 'column -t' command about 2 s to format the 18000 something rows table. apteryx: (that's the current count of packages in Guix :-)) rlb: Oh, well yeah, I'd expect it might well be terrible if you're not buffering output to some reasonable extent (i.e. dominated by syscall overhead or similar). rlb: apteryx: Might not matter, but I'd also suggest maybe testing a larger setvbuf buffer size, say 4096, 8192, or 16384. I think the default's 1024? rlb: wingo: was looking at bugs https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39314 and I thought maybe that whole @deffn might be vestigial now? i.e. the @deffn including program-bindings to binding:end. rlb: Happy to handle that, but just wanted to make sure it was plausible. iskarian: is it possible (or advised) to fold with keyword arguments? leoprikler: wdym fold with keyword arguments? tohoyn: could somebody look at the error message I got when compiling a guile program with guild: https://paste.debian.net/1204564/ tohoyn: I use guile 3.0.7 (pulled recently) dsmith-work: Happy Friday, Guilers!! dsmith-work: sneek: botsnack sneek: :) dsmith-work: !uptime sneek: I've been running for 9 days sneek: This system has been up 2 weeks, 1 day, 2 hours, 42 minutes tohoyn: when I raise an exception of user-defined type theme-d-condition (a numerical overflow) it gets transformed in the following compound expression: https://paste.debian.net/1204593/ tohoyn: what is happening tohoyn: ? tohoyn: s/expression/exception/g tohoyn: I think I found the error zap: hey guilers! Looks like broke my config or something... When I set GUILE_LOAD_* variables they have top priority for %load-path right? zap: I'm in a werid situation when (getenv "GUILE_LOAD_PATH") one thing but %load-path other, and I dont run any script that might fiddle with %load-path -- just invoke guile binary zap: * shows one thing but %load-path the other leoprikler: %load-path also has Guile internals, so GUILE_LOAD_PATH should be a subset of it zap: leoprikler: ah yes. But Im interested in presedence GUILE_LOAD_PATH should be in front? leoprikler: doing a quick check GUILE_LOAD_PATH should be first zap: This is so weird dsmith-work: $ GUILE_LOAD_PATH=/FOO guile -c '(display %load-path)';echo dsmith-work: (/FOO /usr/local/share/guile/3.0 /usr/local/share/guile/site/3.0 /usr/local/share/guile/site /usr/local/share/guile) dsmith-work: Looks anything like that? dsmith-work: That's a no-extra-argument ./configure zap: dsmith-work: ha! yes and no; it work with guile but doesnt work with guile from guix source tree seems like guix doing something tricky ss2: hello! Can I ask anything related to geiser here? dsmith-work: ss2: You can, but there *is* a #geiser channel. ss2: it is very small, and am hoping to find more geiser users here. dsmith-work: ss2: As usual in IRC, it's better to ask than to ask to ask. ss2: okay, then: I've run into an issue, that when I copy text from the REPL, Emacs will go in to a read-only state: https://gitlab.com/emacs-geiser/geiser/-/issues/25 ss2: It'd be good to know if this can be confirmed. dsmith-work: I've never seen that. dsmith-work: But I'm using 26.1 emacs. dsmith-work: And geiser-guile 20210508.1838 ss2: That is from melpa, I assume? dsmith-work: Yes dsmith-work: And Guile 3.0.7 ss2: haven't thought about this yet. Will fetch an older Emacs and see how it is from there. dsmith-work: ss2: Did you try C-x C-q ? dsmith-work: Which is also M-x read-only-mode ss2: yes, but all buffers are read-only, making it basically unresponsive. dsmith-work: That has got to be very frustrating ss2: This only happens when I select text in the REPL, otherwise it everything is fine. dsmith-work: Hmm. What happens if select something in a different application? ss2: okay, installing Emacs in Debian, and pulling the rest over melpa doesn't show this problem. ss2: nothing, that works as usual. dsmith-work: So an emacs 27 thing. dsmith-work: Does that emacs do that Weyland stuff? Or is it X11 ? ss2: X11 dsmith-work: Very odd. I'd ask in #emacs ss2: oh, but this doesn't happen when I'm in a terminal! dsmith-work: Right, becuse the termial is doing the selection dsmith-work: And by "selection" I've been assuming you mean swiping with the mouse. ss2: what? no! :D ss2: I don't need a mouse in Emacs. dsmith-work: How are you making a selection. ss2: shift, arrow? ss2: hang on, gonna do the classic way with Mark set. dsmith-work: I usualy set the mark, move somewere, and then M-w dsmith-work: That loads the kill buffer/whatever it's called. dsmith-work: Ask in #emacs ! ss2: will do! Thanks for helping still. dsmith-work: I've got my exterm wired up backwards to use the cut-buffer instead of the selection. Makes copy-paste to/from windows easier. (gotta run Debian in a VM) ss2: and after all those years I finally taught urxvt to select and copy text with a keyboard. I do have some old habbits on me. So there's the part where I'd still select and copy with a mouse. leoprikler: zap: Guix source guile has to ensure you find the local packages, so… zap: leoprikler: in my case it does the opposite :) leoprikler: I think Guix source Guile adds its own stuff on top of whatever you have specified as GUILE_LOAD_PATH leoprikler: whereas usually it'd be GUILE_LOAD_PATH expanded on top of %load-path leoprikler: I think that's mostly a potato potato thing, but okay dsmith: dsmith-work: Poke apteryx: is there a way to parallelize fold in Guile? apteryx: another question! Is there a way to get the current-output-port terminal's width? daviid: apteryx: not exactly parallel fold, but see if you can use par-map instead daviid: note that it's only 'worth it' if proc is a long/costly operation ... as par-map itself has a cost ... apteryx: I see, thank you! apteryx: the algorithm records the lengths of words in a list of list apteryx: it's used for presenting tabulated data neatly apteryx: list of list are the table rows apteryx: list of lists* apteryx: it currently looks like this: https://paste.debian.net/1204411/ apteryx: here with profiling data (not just for that bit, but the whole application, but it's definitely on the hot path, raising total execution time from about 2 to 12 s) https://paste.debian.net/1204412/ apteryx: hmm, perhaps I'm reading that profiling data wrong, it's not clear that it's on the hot path from it. apteryx: Yet another question; how can I create a string that repeats "~a\t" for N times? apteryx: I came up with this: https://paste.debian.net/1204414/, although it feels a far cry from Python's number_of_columns * "~a\t" lampilelo: why do you need this format string? can't you write a function that will create a string from real data? flatwhatson: what about: (string-join (map display ls) "\t") flatwhatson: otherwise: (apply string-append (make-list n "~a\t")) chrislck: apteryx: you'll probably want to upgrade from map/make-list/length eventually as far as possible. consider (map fn1 (map fn2 lst)) gets slow if lst is large -- it creates intermediate list. better: (map (compose fn1 fn2) lst) apteryx: sneek: later tell lampilo the format string is used to pretty print table columns so they all appear aligned sneek: Got it. apteryx: flatwhatson: (apply string-append (make-list n "~a\t")) that's much better than what I had, thank you. apteryx: chrislck: the list of rows needs to be scanned at least twice; once to discover the maximum column widths, and a second time to print the rows apteryx: I've tried moving the drop-right into the fold kons, but it slowed by 1 sec in my tests. Strange. apteryx: I'm starting to think that simple, \t separated yet jagged columns are not that bad. It takes less screen real estate and works reliably with 'cut'. chrislck: (string-concatenate (make-list n "~a\t")) apteryx: even better! apteryx: thanks :-) chrislck: tip: building a long string via string-append and string-concatenate isn't that clever -- it allocates numerous strings, and needs to allocate a big string at the end. check the source for string-replace-substring in guile sources to see what wingo recommends :) apteryx: OK! chrislck: hint: (with-output-to-string (lambda () (let lp ((idx 100)) (unless (zero? idx) (display "a") (lp (1- idx)))))) *may* be surprisingly faster than (string-concatenate (make-list 100 "a"))... apteryx: interesting chrislck: ok maybe not: with-output-to-string with 4x10^6 elements does 1.813090s real time, 1.811567s run time. 0.000000s spent in GC. dsmith-work: Thursday Greetings, Guilers chrislck: whereas string-contatenate scores: 0.509411s real time, 0.562900s run time. 0.349726s spent in GC. chrislck: see, much more gc dsmith-work: apteryx: Looks like you are using format? Have you looked at ~{ ~} for iteration? RhodiumToad: how much of that GCing is attributable to make-list? apteryx: I've simplified it a bit, it now looks like: https://paste.debian.net/1204496/ apteryx: rows is a very long list (17000 entries about) of few items (4 columns) apteryx: the only costly operations (due to the large 'rows' list) should be: (map (cut drop-right <> 1) rows) as well as the fold, and finally the formatting of each row (the full list is iterated thrice). Interestingly moving the drop-right inside the fold doesn't improve things. RhodiumToad: thrice? RhodiumToad: oh I see RhodiumToad: that (map (cut drop-right ...) rows) seems like useless overhead RhodiumToad: why not just calculate all the column widths and leave the last one off? RhodiumToad: this function is doing a lot of consing apteryx: RhodiumToad: I tried computing column-widths for all column (including the last one), and simply using excluding the last column at the time of computing column-formats; this caused about 1.7 s extra to be used. Any optimization I try seem to make things worse, eh. apteryx: perhaps what I have is already close to the true cost of using format on a 17000 something list and can't be made much faster. RhodiumToad: bets? apteryx: hehe apteryx: I'd be happy to be proven otherwise :-) RhodiumToad: working on it *: apteryx is thrilled RhodiumToad: I assume the return value is not interesting? apteryx: it isn't! apteryx: (I'm now using for-each) RhodiumToad: the final (map) in your version is incorrect anyway RhodiumToad: interesting. for-each to repeatedly call format for each row is faster than using a ~:{...~} specifier within format itself apteryx: that's surprising apteryx: what was incorrect in the last map of my version? I fail to see it. RhodiumToad: should have been for-each or map-in-order, since you're relying on the side effect of (format) and not its result RhodiumToad: map doesn't guarantee order of evaluation RhodiumToad: do you care what happens if there are no columns? apteryx: I don't, as there wouldn't be anything to print daviid: if you only use "~a\t", you can use simple-format (and see if it is faster to,don'tknow) apteryx: it doesn't support padding I think (as in ~46a\t) apteryx: which in the manual is called the minwidth parameter RhodiumToad: meh. it looks like optimization is mostly moot since all the time is spent in the final (format) ss2: Hello! *: dsmith-work waves RhodiumToad: yeah. the actual (format #t ...) takes something like 95% of the runtime ss2: I just noticed, that when I copy a number from geiser to calc, Emacs will enter a ‘Text is read-only’ state. ss2: hangon, might try this again with emacs -q. :) ss2: yeah, it is the same there. Is this a bug? apteryx: RhodiumToad: ah! Thanks for checking :-) apteryx: perhaps an interesting read, related: https://bug-guile.gnu.narkive.com/Hd5JeB63/bug-12033-format-should-be-faster apteryx: Ludovic's findings there says (ice-9 format) is an order of magnitude slower than simple-format apteryx: and simple-format was fixed at that time to become 15% faster than 'display'. dsmith-work: I wonder if the recent optimizations for case/cond will improve (ice-9 format). Probably not. apteryx: not totally fair because I'm not starting the whole application and simply reading the data from a file before printing it, but with Python it takes ~3 s instead of ~6 s. apteryx: using the following script: https://paste.debian.net/1204513/ apteryx: doing '(setvbuf (current-output-port) 'block)' reduces the time to under 5 s with Guile :-) apteryx: or close to 5 s at least apteryx: I think it must be close to Python, factoring in the startup time of Guix itself. dsmith-work: apteryx: Guix or Guile? rlb: apteryx: if you know exactly what you want, and it isn't hard, I suppose you could just build the strings you want and use put-string, etc. -- see if that's faster. rlb: ...and if you know it's all ascii, could even do something more primitive and use put-bytevector, though I hope there's not too much difference there. rlb: Ideally, though (or also), we'll eventually improve format. ArneBab: wingo: did you see the GC + Java finalization question in the mailing list? daviid: apteryx: can you paste your guile script 'of the above python' as well daviid: i don't think it is possible to use schmutz without writing C/C++ code either leoprikler: yeah, but it's wrapper c++ ;) daviid: from my admittedly superficial look at this, the vigra_c approach seems cleaner (which is also what the opencv 2.x C wrapper did) - lookat this codeforexample https://github.com/BSeppke/vigra_c/blob/master/src/vigra_imgproc_c.cxx, line 72+ ... tohoyn: it seems that guile doesn't generate xxx-3.0 links anymore. why is this so? tohoyn: I just pulled the main branch and installed it3 rlb: If you mean PREFIX/bin/guile-3.0, etc. you may want ./configure ... --program-suffix=-3.0 tohoyn: rlb: what if I want both "guile" and "guile-3.0" tohoyn: rlb: maybe guile-3.0 is enough tohoyn: rlb: if you have several versions of guile installed you need both guile and guile-VERSION tohoyn: I get following warning when I try to compile a guile program with guild: WARNING: (#{ g103}#): imported module (rnrs) overrides core binding `display' tohoyn: here is the program giving the warning: https://paste.debian.net/1204313/ Guest2263: apteryx: gnucash still uses swig to expose C API to guile and python Guest2263: apteryx_ ^ tohoyn: I got the following message when building Theme-D: /sbin/ldconfig.real: /usr/local/lib/libguile-3.0.so.1.4.0-gdb.scm is not an ELF file - it has the wrong magic bytes at the start. tohoyn: the build uses guile 2.2 dsmith: sneek: later tell tohoyn Those "wrong magic" messages are from the system dynamic linker. Annoying, but can be ignored. (it expects only ELF files in */lib/) sneek: Got it. dsmith: rlb: There is already a special case from some other non-ELF type. Think there is any chance of Debian making another exception for *-gdb.scm files? dsmith: Probably needs to be upstream I guess. rlb: dsmith-work: not sure - would need to investigate. apteryx: any idea if libguile should be usable on iOS? dsmith-work: Hey Hi Howdy, Guilers dsmith-work: In glibc, elf/readlib.c around line 168. There is an exception for Python files. tohoyn: sneek: botsnack sneek: tohoyn, you have 1 message! sneek: tohoyn, dsmith says: Those "wrong magic" messages are from the system dynamic linker. Annoying, but can be ignored. (it expects only ELF files in */lib/) sneek: :) apteryx: chrislck: thanks! old: Hey! As anyone have tried to compile libguile for iOS? old: I asked the question on the user mailing list without much answer. Was wondering if someone here could have more to say apteryx: old: fun, I asked the question a bit earlier here :-) I think it's a rare thing to try, eh. apteryx: another question: can Guile be built statically? I get 'ld: script.c:(.text+0x3c2): undefined reference to `rpl_free' apteryx: passing LDFLAGS=-static to configure seems to help lampilelo: i think the default is to build both shared and static libraries apteryx: perhaps something to do with my environment, thanks dsmith-work: For iOS devlopment, do you need a mac along with a paid develper account? dsmith-work: Can someome mention my nick in a few seconds? Trying out some notificaitons.. lfam: Hello dsmith-work dsmith-work: Bah dsmith-work: Again please? lfam: Okay dsmith-work dsmith-work: lfam: Thanks! lfam: Cheers dsmith: Just got my new "Programming Rust" today! And who do I see quoted on Page 1? Andy Wingo! dsmith: (also one of the authors, Jim Blandy, was an early Guile developer) sneek: Cool *: RhodiumToad prefers his software to be corrosion-free dsmith: heh dsmith: I think it's supposed to be something like ice-9. It covers everything. pkill9: lol flatwhatson: someone mentioned "typed guile" earlier, is that "theme-D" or something else? flatwhatson: it would be amazing to have something like this: https://lisp-journey.gitlab.io/blog/compile-time-type-checking-in-common-lisp/ drakonis: oh i have yes. drakonis: i meant it as a vehicle to enable guile to evolve some interesting new tricks apteryx: trying a relocatable guix pack of guile on armhf-linux: error: 'clone' failed: Invalid argument\nguile: run.c:123: rm_rf: Unexpected error: Device or resource busy.\nAborted apteryx: hmm. seems it's a proot problem. it works when not using the relocatable bits. apteryx: not sure, it works on another system. Perhaps the kernel config (buildroot-based) is too bare-bone. tohoyn: sneek: botsnack sneek: :) tohoyn: flatwatson: see http://tohoyn.fi/theme-d/index.html for Theme-D. It's a "typed Scheme". sarna: hey, suppose I wanted to share my program with someone, and I'd like them to be able to run it with as little friction as possible. they shouldn't have to have guile installed, and ideally they wouldn't need to know the software is in guile sarna: how would I go about making such a package? sarna: I think guile doesn't support static linking or anything like that ft: Guile doesn't do native compilation, so the program is required for running code, even if it is byte compiled. sarna: can I package it somehow? `guix pack` comes to mind, but I don't know if it's not too heavy-handed ft: Classic distributions can solve that, by having your package depend on Guile. And then there are approaches such as guix pack, flatpak and the like. tohoyn: Should guile be able to do native compilation? I think it could be useful. sarna: I like dynamic languages, but they're such a pain when I need to send my stuff to somebody else :( ft: I think wingo has plans in that direction, but it sounds like quite the undertaking. :) wingo: plans, yeah, but time is constrained atm :) ft: Speak of the devil. :) sarna: I'll try with `guix pack` and we'll see how it goes, thanks! lampilelo: you can make a simple main.c file that loads scheme code, and compile it, statically linking against libguile, you'd have to install the binary with all the guile modules it uses, preferably precompiled, and set the load paths correctly lampilelo: i've never done it but theoretically it should work lampilelo: and remember: if you distribute binaries linked against guile you need to include the license and some way to get the source code of your program lampilelo: sarna: ^ lampilelo: i'd probably stick to "guix pack" though sarna: lampilelo: oh no I forgot it's GPL! then it's gonna be a pain, hahaha sarna: thanks for the tips lampilelo: yeah, it's LGPL but statically linking or distributing it with your program will mean you'll need to use a compatible license lampilelo: s/but/so/ sarna: can't do that at work, sadly rlb: sarna: if you really needed to, you could also likely install guile to a --prefix, and then distribute that along with your code, and your program (#! script or compiled C) would just set the appropriate PATH, GUILE_LOAD_PATH, and LD_LIBRARY_PATH. But of course it'd be somewhat platform specific unless you statically linked guile (do we support that easily?). rlb: i.e. guile itself would be dynamically linked to the built-system's libs, and so would require compatible versions wherever you ran it. rlb: Oh, I think that's similar to what lampilelo was suggesting. And might have been clear, but as lampilelo also suggested, the source distribution requirements vary depending on whether static or dynamic linking is used. lampilelo: yes, but if you distribute guile along with your software LGPL applies to that too, doesn't matter if you link it dynamically leoprikler: does it though? lampilelo: https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic leoprikler: doesn't the LGPL make a clear difference between changing guile itself (must be LGPL) and building stuff on top (can be anything) leoprikler: this doesn't say anything about licensing tho rlb: Interesting, I wasn't familiar with (1) there. rlb: i.e. that a foo.o might be adequate wrt the license terms. leoprikler: I think this refers to the point 4d of the LGPL (v3) leoprikler: Hmm, this does state that the Minimal Corresponding Source must be conveyed under LGPL terms though leoprikler: which means the things that you need to link things together plus the original library, I guess lampilelo: so it means not all of your code needs to be under LGPL, but only the part that's needed to link dsmith-work: Hmm. Is it still possible to statically link guile with all dep libs? lampilelo: then i was wrong, also this faq states that if you distribute lgpl'ed software with your own, you need to provide the source for lgpl'ed stuff only lampilelo: hm sarna: so can I link it into one binary and include "built using guile which uses LGPL, grab the source at $WEBSITE" and it'll be okay? sarna: the source for guile of course sarna: oh, I'd need to include links to all libraries I use that are GPL.. hrm. apteryx: does Guile fall-back to no JIT on platforms it isn't supported? Or must it be built with --enable-jit=no on those? leoprikler: sarna if you link to GPL libs, you need to distribute your entire program under the GPL anyway leoprikler: if it's just LGPL, listing them and making sure you can link against modified versions is enough dsmith-work: apteryx: Yeah, at configure time, JIT_AVAILABLE defaults to "no" unless arm/x86. apteryx: dsmith-work: thanks! apteryx: any real life example using Swig to generate C/C++ Guile bindings? dsmith-work: swig? is that still maintained for Guile? lampilelo: i don't know if it's still maintained but works with guile 3 no problem sarna: thanks leoprikler! I have no experience dealing with that stuff so it helps a lot lampilelo: although it created functions for enum values instead of variables dsmith-work: Wrapping C stuff directly (SMOBS) is not all that hard. dsmith-work: But the current trend is to use Guile's FFI for that stuff. lampilelo: for big interfaces it's a pain lampilelo: there's also nyacc, it generates ffi in scheme instead of making a c module dsmith-work: There have been a few others too. dsmith-work: nyacc parses header files? Needed for #define's lampilelo: i think so lampilelo: i know it broke for me when tried to parse the header file that included math.h, i don't think it's documented yet but there's a certain thing you need to put in your nyacc instructions for it to work with cstd files lampilelo: so i guess it recurses leoprikler: nyacc is in a weird spot where it does both too much and too little at the same time drakonis: rewrite it in guile? leoprikler: nyacc is already written in Guile tho? leoprikler: Or do you mean the C thingy drakonis: the guile thingy drakonis: C thingy leoprikler: that's not always an option leoprikler: think of moderately large stuff like SDL or even bigger stuff like GTK leoprikler: (GTK really is an outlier here as there's at least two implementations of GObject Introspection in Guile, but still) dsmith-work: There is also g-wrap dsmith-work: Mainly for guile-gnome leoprikler: okay but g-wrap tried to be a more general c wrapper like nyacc, no? dsmith-work: Yeah, I think it tried to be general. dsmith-work: Looks like hasn't been touched in a while. daviid: not sure who asked what wrt g-wrap, but I'd recommend not to use it anymore, because it was designed at a time wedidin'thave dynamic ffi ... it produces/generates C (libguile) code ... and afaict,is unmaintained daviid: one should use nyacc, if the objective is to bind a C library that is not GObject Introspectable, then do some 'manual' tuning where necessary, but nyacc does an amazing job, at least to get you started (I'd say much more then 'get you started' ... but ...) daviid: but nor g-wrap neither nyacc will help if the lib is in C++ leoprikler: True, C++ is a different beast. leoprikler: I think Schmutz helps you with that, but it's kinda like manually doing libguile stuff in C. leoprikler: but if you C++ thingy has C bindings, you could nyacc those daviid: my 'distant' experience wrt C++ lib, like vigra (used by guile-cv) is that someone first write a C wrapper, vigra_c in this particular case, that merely wrap the C++ function in a C function that calls the C++ func, deals with the exception and return a code (sortof) daviid: openCV 2.x did that to,then they abandonned (too much work i guess) the C API in 3.x ... daviid: fwiw, here https://github.com/BSeppke/vigra_c daviid: the author of vigra_c did that to be able to bind vigrafor racket, called it vigracket :), and that was my luck because i wouldn't want to do that wrapper myself, but if/when we conewith some magic, i'd use openCV in guile-cv ... leoprikler: yeah, if you don't like writing wrapper C, you'll be left with schmutz rlb: What's the "main" python dialect project right now? sarna: can one extend match somehow in guile? something like https://docs.racket-lang.org/reference/match.html#%28form._%28%28lib._racket%2Fmatch..rkt%29._define-match-expander%29%29 in racket leoprikler: sarna: not simply… you can write your own match, but basically everything else will need to be handled in terms of ? sarna: leoprikler: got it, thanks sarna: also, is it just me or is guile really fast at loading code? in racket every import came with a startup time penalty, in guile everything's stable no matter how much stuff I import leoprikler: I think there are some noticeable delays with particularly big things like Guix, but subjectively it feels quite fast too. sarna: guix executes in 0.144s for me, that's reasonably fast for a huge chunk of code sarna: meanwhile loading racket alone (not racket/base) and printing "hello" takes 0.304s leoprikler: Overall Guile's performance is somewhere in the middle leoprikler: there are both faster and slower Schemes sarna: yeah, just talking about load/startup times here sarna: which ones are the fast ones now, by the way? chez and gambit? leoprikler: Gambit, Chez, Cyclone, MIT, Guile leoprikler: We're number five, baybee leoprikler: And we're dominating chudnovsky and pi :) sarna: are you talking about https://ecraven.github.io/r7rs-benchmarks/ ? sarna: last run was on guile 3.0.4 :^) ecraven: I hope to finally do a new run soon :-/ sarna: talk about devil! :D lloda: you can use array-cell-ref or array-slice on any axes by using transpose-array on the arguments lloda: but i stopped trying to build on make-shared-array bc it's not a good interface lloda: why call an arbitrary function to find some affine transform coefficents? it's easier/safer/faster to give the coefficients directly RhodiumToad: eh... not sure RhodiumToad: some of the things I've done with make-shared-array would not have been easy as just coefficients jlicht: does guile have something similar to python generators? lloda: you can have some function that computes the coefficients for you, for some specific use lloda: that's probably what you do with make-shared-array anyway, bc it's so cumbersome at point of use dsmith-work: Monday Greetings, Guilers lampilelo: jlicht: you can create a closure that will store some state, e.g. (define (make-iter) (let ((num -1)) (lambda () (set! num (1+ num)) num))), or if you need something that behaves like a list, use streams from srfi-41 jlicht: lampilelo: that is what I did now, but after looking at my ugly code I suddenly realised this is basically what generators could/(should?) be used for. dsmith-work: !uptime sneek: I've been running for 5 days sneek: This system has been up 1 week, 4 days, 4 hours, 33 minutes Noisytoot: !uptime vijaymarupudi: jlicht: You can use delimited continuations to have generators similar to python vijaymarupudi: the function creating the generated would need to call reset, and the function yielding needs to call shift jlicht: vijaymarupudi: thanks! vijaymarupudi: jlicht: thinking about it, I think it would be easier to use % and abort from ice-9 control instead, abort is pretty much yield, and % is pretty much next() (as in python) jlicht: vijaymarupudi: already got all the toys I need now :-) RhodiumToad: I think for generator-type stuff you want shift/reset and not %/abort RhodiumToad: the details of where the prompt is re-established matter marusich: Does "map" guarantee stability of the list order, even though it does not guarantee the order in which the procedure is applied? marusich: The guile docs didn't say. RhodiumToad: the result list matches the order of the input, yes marusich: That makes sense. I also see that R5RS says as much on page 32: "(map proc list 1 list 2 . . . ) / library procedure / The lists must be lists, and proc must be a procedure taking as many arguments as there are lists and returning a single value. If more than one list is given, then they must all be the same length. Map applies proc element-wise to the elements of the lists and returns a list of the results, in order. The dynamic order in which marusich: proc is applied to the elements of the lists is unspecified." RhodiumToad: put another way, (map (lambda (e) (pk (1+ e))) '(1 2 3)) is guaranteed to return (2 3 4), but it will also print out three diagnostic messages in some unspecified order marusich: Right, that makes sense. chrislck: marusich: map-in-order offers such guarantee marusich: I did see that. Thanks for mentioning it. My hang-up was the fact that the stability was not explicitly mentioned in the Guile manual, but R5RS and common sense says it's so. RhodiumToad: map guarantees the correspondence between input and output sequences but not the order of procedure calls; map-in-order guarantees both RhodiumToad: the difference should only matter if the procedure has side effects chrislck: and par-map is even worse in ordering of procedure calls :) RhodiumToad: presumably that doesn't even guarantee that executions of the procedure are not overlapped? :-) leoprikler: Is there some Guile function to iterate over differently-sized arrays? leoprikler: I have a 3x3 matrix and a 3x1 vector, that I want to put together into a 3x4 matrix RhodiumToad: you could do it with array-index-map, but maybe would be better using array-copy! and shared arrays RhodiumToad: yeah, it works with shared arrays RhodiumToad: basic idea is: create the result array with make-array, then array-copy! into appropriate regions of it defined using make-shared-array leoprikler: hmm, that's an interesting idea leoprikler: I've used array slices plus match-let, because the indexing was the important thing for me, but for memcpy-like behaviour obviously your solution is the better one leoprikler: quick question though, would this also work with array-cell-ref instead of make-shared-array? leoprikler: I suppose make-shared-array is more generic, but it's also a pain to write oftentimes ^^" RhodiumToad: array-slice is more limited in what it can do, it can only fix the values of an initial subset of indices RhodiumToad: sometimes that's enough RhodiumToad: whether it's enough for you depends on the shape of your input arrays drakonis: hmm, how do you detect a language for guile to use on runtime? ft: you mean (current-language)? ft: But for that you kind of need to know the language already. :) leoprikler: drakonis: Is this about selecting a language for a file or about knowing which language is currently used? ft: Doesn't seem like ‘current-language’ is bound in elisp mode in any case. So it wouldn't even help with syntactically similar languages. leoprikler: bummer :( jlicht: How can I use srfi-1's `remove', instead of the 'default' `remove'? rlb: There's a default remove? rlb: Regardless, you'd typically just add a "#:use-modules ((srfi srfi-1) #:select (remove))" or "#:use-modules (srfi srfi-1)" (if you want everything) to your define-module form. jlicht: rlb: no, there is not XD. I got very confused somehow, but your snippet still helped. Thanks! rlb: certainly. jlicht: any Scheme-ish resource on how to compute all possible distinct covering partitions of a list? jlicht: (of a fixed size) jlicht: so e.g. (my-cover '(1 2 3 4) #:size 2) ; => '(((1 2) (3 4)) ((1 3) (2 4)) ((1 4) (2 3))) RhodiumToad: the 2 refers to the size of each partition element? jlicht: RhodiumToad: exactly jlicht: I know how to get all combinations, but not 'grouped' by them covering the entire original list drakonis: leoprikler: selection rlb: wingo: I pushed the #nil syntax fix to main after a bit more testing. I thought we were keeping main and master in sync, but it looks like they're not right now, so I didn't push to the latter. rlb: s/push to/update/ jlicht: Is this about lokke? rlb: Sorta? lokke was how I noticed the problem, but I think it was a more general issue. There's a simple test in the commit: https://git.savannah.gnu.org/cgit/guile.git/commit/?id=d79a226359d28f4a1dc5df136e5544d699903a96 drakonis: lokke? rlb: That should fix lokke wrt 3.0.7, but it's still broken for main due to some issue I haven't figured out wrt cross-module inlining. rlb: https://git.sr.ht/~rlb/lokke/ (also on gh) drakonis: ooo nice rlb: Well... fsvo "nice" :) It's still not remotely industrial strength. *: rlb is working on defprotocol/defrecord at the moment drakonis: hmm, why clojure instead of clisp? drakonis: clojure lives and dies by its java interop rlb: I might break out the new edn parser if I have time, and it seems like something people might want -- the clj side is based on an intentionally scheme friendly module underneath (i.e. collection types returned are configurable, returns scheme-only structures as-is). drakonis: hm rlb: drakonis: I could imagine any number of possible motivations. For me, because I like guile, direct posix-ish access, and clojure :) drakonis: i see drakonis: a clojure that can be embedded i see rlb: (i.e. I've quite enjoyed the collection interfaces, persistent data structures, some of the concurrency handling, etc.) drakonis: not having to deal with java for anything seems like a good idea though rlb: drakonis: it's a pretty tight integration right now - you can write modules in either scheme or clj, etc. rlb: And it's faster startup than clj/jvm fwiw (though it's not as much faster as it would have been -- clj/jvm's been getting better). rlb: But you're absolutely right -- has nothing remotely comparable to the jvm ecosystem, e.g. java.util.concurrent, etc. rlb: atm drakonis: this is interesting though rlb: (otoh, it's "easy" to extend via C) drakonis: yes drakonis: that's an advantage drakonis: it is a fine way to pull in developers into the guile ecosystem rlb: ...I'd assume the scheme-based namespaces will generally be somewhat faster than the clj based namespaces right now (in part why I've written so much of it in scheme -- that and define-syntax), because they don't have the universal "invoke" trampoline insinuated during compilation. No idea atm how much that costs. drakonis: i don't think i quite grasp the difficulty of a building a clojure dialect rlb: Anyway, feel free to badger me on #lokke about any details if you like. drakonis: cool rlb: The syntax issue is why the macos tests are broken atm -- because brew's already moved to 3.0.7. rlb: fwiw drakonis: aint no mac user here drakonis: am a guix user drakonis: there's no other way to drive adoption without something cool drakonis: i'm curious however, guile is capable of being used for writing langs, yet it doesn't quite present itself in a manner that takes advantage of that rlb: drakonis: that was one of guile's founding principles, i.e. to support multiple languages on the same platform. One related bit https://www.gnu.org/software/guile/manual/html_node/Compiling-to-the-Virtual-Machine.html In particular, "Compiler Tower". drakonis: it doesn't present that the way racket does drakonis: it definitely needs more of that lang written with guile chutzpah first rlb: There are also likely some rough edges -- I don't think languages other than scheme have seen all that much heavy use, so far. drakonis: indeed drakonis: it needs more langs for solving specific problems though rlb: When I get time, I'd like to see if I can fix up the repl modules to be more language agnostic. For lokke I had to just copy-paste some of the code and make adjustments, and it still doesn't preserve the clj printer in an error prompt (reverts to scheme's). rlb: For that I *think* we'll probably need to teach the repl functions to pay attention to the custom printer "all the way though", but I haven't really delved yet. drakonis: also fix up guile to have an easier time loading languages drakonis: switching between them, as well rlb: Yeah, I hit some bits wrt the language spec and environment handling that I still don't fully understand, but "got something to work". drakonis: in the same file, as that's an racket thing that mildly annoys me drakonis: rather, i think it is doable already drakonis: but its not well supported by the other existing langs yet rlb: One thing I'll probably eventually need *if* I pursue more complete clj support is some solid thread-pool infrastructure. Figured I might see if I can do that in a way that's more broadly useful, but we'll see. drakonis: native fibers implementation that's shipped with guile? rlb: i.e. maybe just see about abstracting the existing future pool so that it can be re-used. drakonis: or just something else? drakonis: that could be useful for guix rlb: Hmm - I forgot about that (guile fibers). Have heard people mention it, but hadn't remembered to look. drakonis: it implements concurrent ml features drakonis: also a way out there project rlb: *very* interesting - wonder if that might be able to support core.async. drakonis: typed guile drakonis: lol rlb: (wrt core.async https://clojure.org/news/2013/06/28/clojure-clore-async-channels ) drakonis: i've heard about that rlb: I've found it very useful, but also sometimes a bit tricky. rlb: It's not on my short list :) drakonis: it has some adoption weirdness leoprikler: oh, by the way, I found the life hack for working out the byte length of a string in scheme leoprikler: here it comes: just convert it to a bytevector :) rlb: leoprikler: oh, right -- I'd originally thought you needed a (fast) offset length, without necessarily converting the entire string. leoprikler: tbf the less allocation the better, but it seems like even with the APIs I'm using you can't get around allocating anyway leoprikler: not easily at least leoprikler: I could theoretically rip out some internals if I needed them for performance sake, but it works fine so far rlb: Right, you could write a pretty "simple" loop/switch over the relevant chars to compute the length yourself in either scheme or C -- iirc the utf-8 encoding rules aren't too bad. rlb: (if it mattered) iskarian: Is there a way to have an optional (part of a) pattern in an ice-9 match? iskarian: Or do you just write a new branch? flatwhatson: iskarian: do you have an example of what you're trying to achieve? iskarian: flatwhatson, I want to match something like ('replace ('path path) ('version version) '=> ('path new-path)), where ('version version) may or may not be present iskarian: Ideally I'd like to provide a default value for version if it is not there flatwhatson: iskarian: have you considered just using a function with optional arguments? flatwhatson: iskarian: you can use "or" and "..." to represent some kinds of optional patterns flatwhatson: this works: ('replace ('path path) ('version version) ... '=> ('path new-path)) flatwhatson: if you're happy to receive version as a list, and have a loophole that multiple versions could be provided! flatwhatson: i can't work out how to do "zero or one" instead of "zero or more" though iskarian: you're brilliant! I didn't even think of just passing off to a fn with optional arguments iskarian: ah, it's fine if it can technically take more, since the parser feeding this only accepts one anyway flatwhatson: yeah keyword arguments might be a bit more straightforward if you're in control of the syntax iskarian: this though... this is why I find match syntax absolutely impenetrable: ('replace ('path path) ('version version) ... '=> ('path new-path)) iskarian: how does the ... make the previous pattern optional? flatwhatson: ... is like regex *, zero or more matches of the previous rule iskarian: Ahhhhh flatwhatson: implicitly promoting all of the affected bindings to lists iskarian: okay, that makes sense. My best approach before asking was ('replace spec ... '=> ('path new-path)) and then using assoc-ref or such to pull apart spec later. I had no idea why the ellipsis worked though! sarna: "the implementation of continuations in Guile is not as efficient as one might hope, because Guile is designed to cooperate with programs written in other languages" - is that true only for call/cc, or for delimited continuations too? civodul: sarna: wingo would know better, but i think that applies to call/cc civodul: there cannot be C stack frames in the middle of a delimited continuation taw10: That was my interpretation of that part of the manual as well. Two paragraphs later it explicitly says to use prompts instead where possible taw10: call/cc inefficiency doesn't only apply to Guile. It's overkill for most things in any Scheme implementation (see e.g. http://okmij.org/ftp/continuations/against-callcc.html) civodul: yeah, call/cc is not very useful sarna: I see, thanks civodul sarna: IIRC only chicken has fast call/cc because of the way their VM works dsmith: sarna: There are some call/cc implementations that are *very* efficient. Like if your call frames are heap allocated lists. A call/cc is just pointing to a different list. Not compatible with C, however. dsmith-work: Happy Friday, Guilers!! vijaymarupudi: Happy Friday to you too :) sarna: dsmith: not compatible with C FFI you mean? dsmith-work: sarna: Yeah, C->Scheme->C or Scheme->C->Scheme. dsmith-work: sarna: Often it's copying around the processor stack. ArneBab: dsmith-work: wasn’t the problem of call/cc that it is more powerful than expressive, so it doesn’t actually reduce complexity? sarna: dsmith-work: got it, thanks ArneBab: And that it does not match the requirements of hardware, so it forces slowpaths? dsmith-work: ArneBab: Yeah, there is that too. dsmith-work: I've never used call/cc much (becase the thought of copying whole stacks back and forth just makes me shudder) ArneBab: dsmith-work: yes … daviid: yes, grab an msys2 image, the latest of course, then launch/run it, in it (a terminal) run a few pacman commands to update it to the very latest, then use pacman to install guile, autoconf, automake, ssh ... what evert you need, then i cloned guile-cv and compiled install, then yes, just grab the window's dir (big, but ok ...) and send it ... leoprikler: i think you mean "use pacman to install autoconf, automake, then install guile from source" ;) leoprikler: at least for guile3, that is leoprikler: and especially for guile-3.0-latest daviid: i use guile 2on msys2 leoprikler: come to think of it, could we do msys2 as a guix pack target? daviid: leoprikler: at the time, guile-3.0 didn't even exist, and guile-cv runs fine with 2.2 ... but i think if one email the msys2 guile packages mainainter, they might easily get guile-3.0 (not me, at least not 'now' ... but my intuition is that it should be easy forthe maintainer ...) morganw: From what I had read it last I don't think it would build, and there was a suggestion that it might be possible to get it working again without threading support and 32-bit only. daviid: morganw: don't confusewindow 'native' guile compilationand msys2, mingw-64, that hasnothing todowith one another... leoprikler: the 2.2.7 PKGBUILD has --with-threads though daviid: yes,nsys2 is 64bits,threads... morganw: aren't msys2 ports built with mingw ? leoprikler: it's a mingw/cygwin hybrid of sorts daviid: morganw: look/read the msys2 homepage, thewiki ... it has everything you need toknow leoprikler: though iiuc cygwin does have guile-3.0-latest leoprikler: but SDL2 has been stale for 3.5 years now leoprikler: otoh msys seems to not even have sdl2, so… daviid: leoprikler: https://packages.msys2.org/search?q=sdl2 leoprikler: oh, right, mingw exists daviid: msys2 is based on mingw-w64 ... leoprikler: yeah, but the way packages are partitioned is a bit weird leoprikler: I was looking in the github repo if that helps understanding :) daviid: it even has gtk4 4.2.0 (debian only has 4.0.3) :) daviid: and GI, so g-golf will also run on msys2 ... daviid: the msys2 folks are extremely nice as well, i had (back then) to ask for help, #msys2 on oftc fwiw ... dsmith: A special thanks to those brave souls who labor tirelessly to bring free software to those under the oppression and tryanny of M$ sarna: "Guile only adopted with-exception-handler and raise-exception as its primary exception-handling facility in 2019." - how much of real-life code uses exceptions instead of the legacy stuff? leoprikler: Guix uses exceptions throughout IIRC sarna: that's useful, thanks dsmith-work: Morning Greetings, Guilers apteryx: FTR I wasn't able to test guile on Android because my Android is not root, and the Guix relocation option for aarch64-linux is not currently usable due to proot-static failing to build on that platform civodul: apteryx: hi! maybe you can skip proot tests to see how it goes? *: apteryx tries apteryx: hm, it fails during the build phase, not the check phase Guest7431: sneek: botsnack sneek: :) sarna: btw, guile runs fine on iOS with iSH :^) sarna: it's emulating i686 linux, so it's not the fastest - but it works civodul: apteryx: bah :-/ civodul: apteryx: you could also hack around to remove the proot "engine", so that you can at least try the "fakechroot" engine apteryx: sarna: good to know! We should compile a list of these hacks somewhere, so that someone can have an overview of the Guile cross-platform picture. apteryx: seems proot should support aarch64, at least in the changelog of the previous version (v4) there were mentions of it, such as "Fix build for AArch64." (c.f.: https://github.com/proot-me/proot/blob/8c0ccf7db18b5d5ca2f47e1afba7897fb1bb39c0/doc/proot/changelog.rst). apteryx: I'll try building that previous version civodul: apteryx: another option would be to allow -RR without the "proot" engine civodul: kinda boring, but doable apteryx: v4.0.3 could be built for aarch64-linux apteryx: so it's a regression apteryx: I'll open an issue on the project's tracker civodul: great apteryx: for the record I used: guix build proot --with-git-url=proot=https://github.com/proot-me/proot --with-commit=proot=v4.0.3 --without-tests=proot --system=aarch64-linux to validate this (I had to make a minor change to the package def so its test suite would be skipped) apteryx: transformation options are really handy! iwan: how can I run subset of guile tests? e.g. elisp.test civodul: apteryx: neat :-) civodul: iwan: you can run: ./check-guile elisp.test iwan: thanks dsmith: !uptime sneek: I've been running for 38 seconds sneek: This system has been up 5 days, 9 hours, 39 minutes rlb: (Oh, I also needed "-shared" on not macos, and "-bundle -undefined dynamic_lookup" on macos, apparently.) sarna: leoprikler: I can just as well run `ls` from shell instead of `find-files` from guile, right? sarna: it's not like the files will disappear in the meantime.. sarna: leoprikler: I noticed that hall is capable of creating guix files, so I just nuked `guix.scm` and let hall generate it - now it works! leoprikler: sarna: ls won't give you the full tree, but yes leoprikler: also IIRC hall expects you to regenerate everything if stuff changed, so yeah, that's probably expected sarna: oh, so I don't need to modify these files at all? that's neat, TIL! sarna: thanks :)) leoprikler: sarna: au contraire, since they're machine-generated, changes you add to them will be lost! sarna: leoprikler: that actually happened! and I typed them out again 🙈 sarna: I'm not the sharpest tool in the shed leoprikler: you could (package (inherit (load "guix.scm")) ...) if you're really cheeky :P leoprikler: is there a way of composing procedures with setter? leoprikler: e.g. (set! ((compose bar foo) spam) value) -> (set-bar! (foo spam) value) sarna: is there a complement function in guile? I mean something that'd roughly do `(lambda (func) (not (func)))` flatwhatson: sarna: yes, negate sarna: flatwhatson: thanks! sarna: are there any utility functions for paths? right now I'm appending strings, and that doesn't feel very solid :( I haven't been able to find anything in the guide flatwhatson: not that I know of! you have string-append, string-join, and file-name-separator-string if you're concerned about portability flatwhatson: from what i've seen in guix, using string manipulation for paths is perfectly normal sarna: I see. thanks again :) leoprikler: for the record, there are several libaries doing path strings (one written by yours truly), but it kinda seems Guile folks prefer doing string manip leoprikler: hum, can we do mv-respecting setters? lampilelo: it would be nice to have maybe an ice-9 module for paths, also realpath would be cool dsmith-work: Hey Hi Howdy, Guilers leoprikler: isn't realpath canonicalize-path? RhodiumToad: not all realpath implementations return an absolute path in all cases, apparently RhodiumToad: though the spec for realpath() does seem to require it RhodiumToad: otherwise, yes, canonicalize-path is documented as doing what realpath does lampilelo: ah, right, i always forget about canonicalize-path, always searching for realpath in the docs and not finding it apteryx: is it possible to run Guile on Android? apteryx: perhaps as a Guix pack? drakonis: hmm, use something like userland or termux drakonis: it is theoretically possible apteryx: 'pkg search guile' in termux returns no result drakonis: termux is based on a subset of debian's packages drakonis: you'd need to use something like userland instead drakonis: which provides a whole distro lampilelo: apteryx: maybe it's possible with this: https://developer.android.com/ndk/guides lampilelo: if you manage to do it, please tell me, i've been thinking about trying it myself but never got to it dsmith-work: sneek: botsnack sneek: :) *: apteryx installs UserLAnd from F-Droid apteryx: seems arch and debian/ubuntu would have only guile 2.2, at least in their default repo *: apteryx tries 'guix pack --target=aarch64-linux guile -S /bin/guile=bin/guile' morganw: I think it is now split in packaging between guile-3.0 and guile-2.2, at least in Debian 11. leoprikler: debian has the super new 3.0.5 in unstable IIRC :) daviid: it is in testing even... civodul: apteryx: *aarch64-linux-gnu :-) daviid: apteryx: fwiw https://packages.debian.org/search?keywords=guile-3.0&searchon=names&suite=all§ion=all morganw: Would anyone happen to know what the status is for building with msys2? daviid: morganw: https://packages.msys2.org/search?t=binpkg&q=guile morganw: Oh, I meant the current version, but thanks for the link I didn't realise it was available as a package. morganw: From the mailing list (~2020) it seemed that building version 3 wasn't easily doable on Windows. daviid: morganw: windows is 'another story', msys2 current version is 2.2.7-1 apteryx: OK, so for a "multi-platform" application, Guile is currently at 2.2 (thanks to windows) apteryx: but could get by with WSL perhaps? which is the Ubuntu's runtime, IIUC. apteryx: has someone managed to run Guile on WSL (the Linux-ABI compatibility layer for Windows thing)? morganw: I'm interested in distributing a working program (or extending an existing one with scripting) so I can't really assume the WSL bits are setup. It also causes conflicts with default configurations for Docker and Hyper-V. drakonis: wsl2 is the better option but it is just linux in a vm daviid: fwiw, imo if you don't need a 'native' version on win, msys2 might be a much better choice, for various reasons, one is that you can prepare everything, then send a 'complete' msys2 image, and that's it leoprikler: so packaging my software for msys will be as easy as it is to package it for arch? :) daviid: leoprikler: i didn't pkg anything myself, i prepare(d) an msys2 image with guile, guile-cv (using the autotools, so dead easy), other guile scripts, then cp the image on a usb key and sent it to the 'customer' ... that'sit leoprikler: hmm, so lemme see if I understand this correctly leoprikler: you start with some msys2 build, then compile+install guile, compile+install guile-cv and finally tar+gz everything into one big shiny ball leoprikler: with "compile+install" being your typical "autoreconf -vif"..."make install" chain, right? sarna: thanks all! :) sarna: does anyone here use guile-hall? I'm having some trouble generating a package.. it complains with `configure: error: 'guild' binary not found; please check your guile-2.x installation.` sarna: I have guile 3 :( leoprikler: you might want to check the configure.ac whether it mentions guile 3.0 and patch it if it doesn't leoprikler: hmm… GUILE_PKG([3.0 2.2 2.0]) lampilelo: sarna: maybe you have a version of guile-hall that's linked to guile-2.2 and it wants to use that? i don't know how guile-hall works, never used it, just throwing hypotheticals lampilelo: maybe this will help? https://gitlab.com/a-sassmannshausen/guile-hall/-/issues/4 leoprikler: what does thread/async-safety mean in the context of finalizers? wingo: leoprikler: what do you mean? do you mean, can finalizers run asyncs? leoprikler: the Guile manual states, that finalizers must be both async and thread-safe leoprikler: does this mean, that two threads may both try to finalize the same object or something along those lines? wingo: no wingo: so, in a guile configured without threads, finalizers are run via asyncs. wingo: this is a bad situation because you don't know what locks the continuation has wingo: it is a similar situation to signals, where you don't know what locks the "main" program has when you are processing a signal wingo: to be async safe is to never take a lock that might be held when an async runs wingo: (see asyncs in the manual) wingo: however......... you might just assume that you're deploying on a guile with threads leoprikler: which brings me to thread-safety in the context of finalizers… wingo: in that case finalizers are run not from an async, but from a separate thread. so the property that you need is thread-safety, that if you go to grab a lock in a finalizer, that you are guaranteed to eventually get it leoprikler: here it is probably not the locks being held, which are problematic, right? wingo: and also that you don't mutate shared data structures (those that are referenced by the finalized object but themselves are reachable) in a thread-unsafe way leoprikler: so if I just call free() on a bunch of data, that's owned by my struct and supposedly invisible to Guile, everything ought to be fine? leoprikler: *supposedly invisible in that the user could get to that data through pointer arithmetic, but shouldn't do that sarna: lampilelo: it finds guile 3 in my case, but I get the same error as in the issue. `./configure GUILE=/usr/bin/guile` helped, now I'm getting a different error! leoprikler: what if you autoreconf -vif first? sarna: leoprikler: well, the full command I'm running is `autoreconf -vif && ./configure GUILE=/gnu/store/0r5qh5wyb2cp6799l8wph1k1zqvx9vnh-profile/bin/guile && make && exit` sarna: this time it worked??? sarna: I didnt change anything! wingo: leoprikler: yeah, should be fine wingo: free is threadsafe sarna: when I try to install my package with guix though, I'm getting this error from hall - http://paste.debian.net/hidden/adda1169/ sarna: why is this so cryptic :(((( leoprikler: because of cutoff, you don't see which directory doesn't exist leoprikler: it's probably an issue in how hall generates the recipe tho sarna: can I somehow make it spew whole lines? sarna: because the path that I see from here exists, it has to be some part near the end sarna: well now I can't even run `hall clean`, it crashes every time sarna: eh.. tricon: sarna: What the hall... sarna: Grieg should be playing in the background as we debug it leoprikler: sarna: life hack: call find-files on the destination directory before the crash leoprikler: that should give you a list of what already exists vijaymarupudi: I'm trying to include a .scm file relative to a r7rs library (not in current directory) and it doesn't seem to work vijaymarupudi: However, https://www.gnu.org/software/guile/manual/html_node/Local-Inclusion.html, seems to state that this is possible vijaymarupudi: "If file-name is a relative path, it is searched for relative to the path that contains the file that the include form appears in. " vijaymarupudi: Using strace, I found this syscall vijaymarupudi: "openat(AT_FDCWD, "containers/./queue_impl.scm", O_RDONLY)" which is not the relative path. I assume this is a bug? leoprikler: in which way is it not the relative path? leoprikler: containers/./ looks somewhat relative to me vijaymarupudi: I'm in /a and running test.scm. I have on my guile load path /libraries, which contains /libraries/containers/queue.scm that wants to include /libraries/containers/queue_impl.scm. Importing (containers queue) works for the queue.scm file, but the include then does not work. leoprikler: in that case containers/./queue_impl.scm is the correct (albeit not canonical) path, I'm afraid leoprikler: does this openat fail? vijaymarupudi: Yep, the openat fails, because there is no /a/containers/./queue_impl.scm vijaymarupudi: That syscall would be correct is CWD was /libraries, but it is not vijaymarupudi: And "If file-name is a relative path, it is searched for relative to the path that contains the file that the include form appears in." seems to suggest that it would be relative to the directory of queue.scm leoprikler: let's see if I can get a MWE going vijaymarupudi: fingers crossed :) leoprikler: yeah, you'll have to make do with include-from-path, sadly :) leoprikler: it's probably not an issue if you byte-compile, but it trips the interpreter up vijaymarupudi: Looks like you were able to reproduce it? vijaymarupudi: bytecompiling vijaymarupudi: How does one do that? leoprikler: "Also, the particular form of include, which requires an absolute path, or a path relative to the current directory at compile-time, is not very amenable to compiling the source in one place, but then installing the source to another place." leoprikler: so yeah, it's known :P leoprikler: guild compile vijaymarupudi: I feel like the docs contradict themselves on that page maximed: Did someone see this build warning for guile before? vijaymarupudi: Personally, the earlier mentioned behavior "If file-name is a relative path, it is searched for relative to the path that contains the file that the include form appears in." is more intuitive and r7rs recommended vijaymarupudi: guild compile appear to work as a duct tape fix vijaymarupudi: Would you consider this a bug leoprikler, given the docs? If so, I can try to see if I can find where the fix would have to be leoprikler: The issue is not that the file is not relative to the path of the file with the include form. leoprikler: The issue is that the path of the file with the include form itself is a relative path, which is interpreted as relative to the current directory. leoprikler: This is completely fine when doing compilation, but it's not fine when not doing compilation leoprikler: hence include-from-path. vijaymarupudi: Wouldn't canonicalizing the paths after find them be sufficient to fix that? vijaymarupudi: finding* vijaymarupudi: The syscall to find /libraries/containers/queue.scm uses the correct absolute path for example vijaymarupudi: I feel like the same can be done for the relative path leoprikler: I'm not so sure. leoprikler: call-with-include-port uses the syntax form to find the dirname, and paths within that are relative instead of absolute leoprikler: which makes sense, you wouldn't want the syntax to change post install vijaymarupudi: I'm having trouble with the concept of pre and post install because my library has always been where it is civodul: maximed: i've seen it like you when building on 32-bit platforms dsmith-work: {appropriate time} Greetings, Guilers leoprikler: well, that's one problem with people nowadays, they can't imagine actually installing their programs :P maximed: civodul: was that an i{3,4,5,6}86 system, or another 32-bitplatform vijaymarupudi: leoprikler: haha, that's fair, but for library development, it's nice to test and hack stuff quickly, without reinstalling for each change, that's the spirit of the REPL, right :) leoprikler: perhaps, but when it's time to load stuff from directories that's not the working directory, one really ought to think about include-from-path instead :P vijaymarupudi: that would definitely work, but would restrict my code to just guile. I'm trying to switch from racket to guile, but currently need both to run the same code vijaymarupudi: besides the way the docs are worded, and the way r7rs discusses include, this sounds like it has to work! civodul: maximed: i686 i think vijaymarupudi: (to explore this, is there a way to run guile from the build directory of the git repo, without installing it?) leoprikler: ./meta/guile leoprikler: note that the thing you want to patch is not C source tho vijaymarupudi: leoprikler, thanks! I think I'll start with call-with-include-port leoprikler: can autotools build shared libraries without libtool? leoprikler: this is particularly interesting in the context of 3.0.7, in which guile supports shared libraries built differently civodul: leoprikler: you can always do things by hand in Makefile.am civodul: that's no fun though leoprikler: what would that roughly look like? adding some -DPIC -fPIC to a LIBRARIES' LDFLAGS? leoprikler: I imagine not rlb: To some extent it probably depends on how portable you need it to be. When I recently changed bup to handle it manually, in addition to the pkgconfig pythonN-cflags I think I just needed -fPIC, and so far haven't heard complaints, but we also haven't had a release with that in it yet, and I've only tested it personally on linux, some of the bsds, and macos. rlb: (previously we were relying on one of python's tools to build them) leoprikler: can guile arrays do reinterpret_casts? leoprikler: e.g. bytevector to native f64? RhodiumToad: yes maximed: leoprikler: (bytevector->pointer ...), use the resulting pointer? maximed: If this is pure Scheme code, bytevector-ieee-double-native-ref leoprikler: pure Scheme, how do I get the memory-backed f64vector from that pointer? maximed: leoprikler: I don't know what a f64vector is maximed: srfi-4, it apppears leoprikler: a vector of 64bit floats (i.e. doubles) maximed: You could use the FFI to make bindings to scm_c64vector_elements and scm_c64vector_writable_elements? RhodiumToad: no need? RhodiumToad: you can just pass a bytevector to the srfi-4 functions RhodiumToad: (define a #vu8(0 0 0 0 0 0 240 63 0 0 0 0 0 0 0 0)) (f64vector-ref a 0) (f64vector-ref a 1) RhodiumToad: (returns 1.0 and 0.0) leoprikler: true, but what I want is to cast the #vu8 to an #f64, so that (array-ref a 1) == (f64vector-ref a 1) maximed: (if you do low-level type-punning, remember that guile does some optimisations based on types) maximed: Guile has a kind of ‘strict aliasing’ rule leoprikler: though tbf it probably wouldn't matter much to write a wrapper… RhodiumToad: you could create an #f64 initially and access it as a bytevector? leoprikler: nah, can't do that leoprikler: I'm already using make-c-struct, which returns a raw pointer leoprikler: I *could* use that raw pointer and section it though leoprikler: if I knew how RhodiumToad: isn't the "Foreign structs" part of the FFI doc what you're looking for? leoprikler: that only does the (make-c-struct ...) and (parse-c-struct ...) thing leoprikler: however, I want to modify the structure produced by make-c-struct in-place RhodiumToad: but the parse-c-struct can handle various C types? leoprikler: sure, but I don't want to always make and parse to change a single field leoprikler: that's a bit wasteful in terms of memory leoprikler: probably also in terms of runtime RhodiumToad: ok, so you have a bytevector created by make-c-struct, and you want to alias it as a typed array? maximed: leoprikler: I though I saw a C function somewhere to turn a C (float / u64 / ...) array into a Guile array but I can't find it anymore leoprikler: yup leoprikler: well, a pointer generated by make-c-struct, but I'm currently wrapping it in a bytevector leoprikler: I could skip the bytevector, though if there was a direct way to do what I want leoprikler: hmm, I could use (array-copy! ) tho… RhodiumToad: that's making a copy though leoprikler: oh, sure, but under the assumption that I can't alias, memcpy is the next best thing leoprikler: (particularly for a struct that holds a fixed sized array) leoprikler: but I guess there'd be problems with how guile interprets that array-copy leoprikler: hmm… leoprikler: although if invoking memcpy directly does what I want… leoprikler: okay, I just noticed the uvec_type on pointer->bytevector leoprikler: d'oh vijaymarupudi: After some investigating of troubles with relative include, I think the problem is that syntax-source returning the path relative to the load-path, but call-with-input-port using that path as relative to the current directory. vijaymarupudi: This mostly restates what you said leoprikler, but I think I understand it now leoprikler: we're all beginners :) vijaymarupudi: looking to contribute to guile eventually, so this was a nice exercise vijaymarupudi: When compiling a file, guile does know the absolute path of the file, so I need to find where that is and use that instead vijaymarupudi: Because include's behavior right now makes no sense vijaymarupudi: Any pointers to where that would be? vijaymarupudi: A git blame shows that wingo wrote the docs for local inclusion, can you clarify whether it is supposed to be relative to the current directory guile is begin run in, or the current file being compiled? Because the docs say both things here; https://www.gnu.org/software/guile/manual/html_node/Local-Inclusion.html vijaymarupudi: Sorry if I'm being a nuisance, just trying to contribute :) leoprikler: again, as I explained, it's relative to the current file, which is relative to the current directory leoprikler: double relativity vijaymarupudi: I guess I'm motivated by r7rs (https://small.r7rs.org/attachment/r7rs.pdf) pg 14 which talks about include vijaymarupudi: If it is relative to the current file, then the path to the library should be ../libraries/containers/queue.scm and then the relative include should be ../libraries/containers/queue_impl.scm which would be great vijaymarupudi: I'm fine with include being relative to the current directory, but maybe check for a file relative to the current file being compiled first leoprikler: vijaymarupudi: *apply an implementation-specific algorithm to find corresponding files* vijaymarupudi: yep, I'm not saying guile is not compliant vijaymarupudi: The current algorithm I feel is confusing vijaymarupudi: I'm more inspired by the note: section leoprikler: be more inspired by the latter half leoprikler: provide a way for users to specify other directories to search. leoprikler: Guile does that leoprikler: it's called include-from-path leoprikler: use it leoprikler: be happy leoprikler: if you want it to be portable, use cond-expand leoprikler: (next page in the r7rs) vijaymarupudi: I'm all for making it just work, I just want to make sure the current behavior is intentional vijaymarupudi: I'm trying to think of use case when a library would want to include a path relative to the user's current directory, when there is a similar file relative to the libraries path. vijaymarupudi: I think I'm coming off as annoying, I'll take it easy now leoprikler: Again, Guile discourages the use of plain include, probably because its semantics are weird and there are better ways of specifying what you want. leoprikler: It tolerates you includeing stuff if everything is within one directory tree. vijaymarupudi: Right, which makes sense. I think I was suggesting a minor semantics change, in which it checks relative to the file being compiled first, before going back to the usual behavior. vijaymarupudi: I'll stick to cond-expand and forget about this for now vijaymarupudi: I feel like the text in the docs: "If file-name is a relative path, it is searched for relative to the path that contains the file that the include form appears in." is misleading, I would change that if I could. dsmith-work: :( dsmith-work: Anyone have a log of when the bot went away? dsmith-work: !uptime RhodiumToad: there were some server restarts and temporary loss of sasl auth dsmith-work: RhodiumToad: Thanks. vijaymarupudi: I'm trying to use include-from-path in an define-library environment and I'm getting an unbound variable error. Is there a module I have to import? vijaymarupudi: I'm having trouble with speed after using a hashtable with a million keys and values for data analysis. I was wondering if there was anything I could do to help the GC? rlb: Which guile version? rlb: There were some hashing issues in 2.2. iirc that could cause serious performance trouble. vijaymarupudi: guile3 rlb: OK, then I think that issue should be fixed. rlb: I'm a little surprised that a million key hash table has trouble, depending on what kind of trouble you mean. dsmith: vijaymarupudi: Are you giving it an initial size? vijaymarupudi: I'll have to apologize for the artificial example, but it's reproducible vijaymarupudi: https://pastebin.com/raw/PzUArBFJ vijaymarupudi: Python version here: https://pastebin.com/raw/Dftd65yL vijaymarupudi: The guile version takes 2.5s on my machine vijaymarupudi: Python takes 0.4s vijaymarupudi: Racket seems to zoom through similar code vijaymarupudi: I suspect I'll have to take this to C vijaymarupudi: Looking at strace, it seems like it seems to "stop" at a null byte written to a pipe vijaymarupudi: The source code says that this is the sleep pipe vijaymarupudi: Not entirely sure what that means vijaymarupudi: dsmith: initial size seems to take my example down to 1.19 seconds, but I don't think I know what the size would be in my data analysis code dsmith: vijaymarupudi: How about something like a prime number larger than your number of keys? vijaymarupudi: dsmith: that does seem to improve things a bit vijaymarupudi: it still seems slower than a directly equivalent python program vijaymarupudi: guile seems faster at the numerics, but slower at the hashtable dsmith: vijaymarupudi: Another thing may be the hashing function. vijaymarupudi: hash(i) == i in python3, I assume guile does the same? rlb: I *won't* be surprised if (c)python is faster for some "normal" hash operations. I have the impression it's pretty fast there. vijaymarupudi: I just checked with pypy3, which does it 0.5s, which is slower than cpython vijaymarupudi: I'm pretty impressed with python here vijaymarupudi: Huh, I wonder if there's a way to optimize guile's hashtables? dsmith: Well, picking a large enough size would prevent it from resizing (and re-hashing) the table. dsmith: A fast hasher that doesn't have (m)any duplicates for your keys should be faster too. vijaymarupudi: That does help, but I was curious if it was possible to reach python perf here vijaymarupudi: Looking at https://github.com/python/cpython/blob/main/Objects/dictobject.c, it seems like they use an algorithm that doesn't have to recalculate hashes on resize vijaymarupudi: They put the objects (with cached hashes) in a separate vector and only refer to the index from the "main table" vijaymarupudi: Comparing with https://git.savannah.gnu.org/cgit/guile.git/tree/libguile/hashtab.c, it seems like guile rehashes on each resize vijaymarupudi: Which explains why passing the size helps so much vijaymarupudi: (I'll have to leave for a bit, will check the logs later, thanks for taking my questions!) rlb: guile also doesn't cache hash values for immutable objects/trees the way the jvm (and/or clojure/jvm) do. rlb: I have a foo.test file that works fine if I run it via ./check-guile foo.test, but it crashes if I run it via "make check" like this: rlb: ERROR: json.test: (tree-equal? x (call-with-input-string (call-with-output-string (lambda (port) (write-json x port))) read-json)) - arguments: ((misc-error "simple-format" "FORMAT: Unsupported format option ~~~A - use (ice-9 format) instead" (#\f) #f)) rlb: rlb: The test module has no references to format. rlb: Oh, hmm, might have found it. rlb: Hit another weirdness with srfi-88. I just wanted to use keyword->string, but using it in a foo.test file crashes tests later on, i.e. creating a test-suite/tests/breakthings.test containing this causes subsequent tests to crash: (define-module (test-suite breakthings) #:use-module (srfi srfi-88)) rlb: And just #:selecting keyword->string doesn't help. rlb: wingo: wonder if that might be reader related ^ Haven't tried that with anything but f449d2ebcb242b5824e167ae9cf73bec6218c683 yet. rlb: My previous issue with srfi-99 was that reader changes persist after the end of a module file -- be more useful if there were a way to say that "just this module uses 'prefix", but this is caused just by loading the module. rlb: "this new issue is caused" rlb: wingo: oh, I take it back. That issue was found with current master, not that sha. rlb: Oh, right, I forgot that just using srfi-88 calls read-set!. That's pretty surprising, but maybe that's what the srfi wants... I just need to avoid srfi-88 -- can always define keyword->tring and string->keyword myself. At least for now, there's no more direct function. leoprikler: rlb perhaps we'd want to provide those in (guile), WDYT? ecraven: how do I tell the guile3 command line to load an r7rs library? how do I point it at the sls file? ecraven: also, which library exports `interaction-environment'? wingo: ecraven: guile --r7rs should work fwiw. to load an sls you use import in the file you load, as usual sarna: hey, I have a `let*` in which I just pass the previous variable to the next one. does guile have something like clojure's threading macros? ( https://clojure.org/guides/threading_macros ) Guest8193: srfi-197 chrislck: sarna: srfi-197 sarna: thanks chrislck! sarna: oh, guile doesn't support it :^( vijaymarupudi: I was trying to make a c extension wrapper around GLib's hashtable to get around performance problems with Guile's hashtable (I really want to use guile), and it performs similarly to Guile's hashtable. This is odd, because in pure C, GLib's hashtable is really fast. Turns out the culprit is scm_gc_protect_object, which appears to acquire a mutex on each call, and uses Guile's hashtable, making the c wrapper kinda redundant. I was vijaymarupudi: wondering if there was a way to get around this? vijaymarupudi: Solutions I can see working here: An API to protect multiple objects at once (to prevent mutex locking in tight loops) or to convert the scm_protects hash_table to c? I'm not sure which one is responsible for the performance impact, is there a way for me to know? vijaymarupudi: To quantify performance impact, removing scm_gc_protect improves runtime for hashtable loops from 300ms to 50ms vijaymarupudi: (ignoring the segfault afterwards :)) dsmith: heh leoprikler: ignoring segfaults reduces runtime to 0ms in the optimal case :) vijaymarupudi: :) in a less ridiculous approach, I have paired GLib's hashtable with a Guile list (which keeps the references) and performance is now 100ms with no segfault. vijaymarupudi: But with this approach, removing an item from the table doesn't make it available to the gc chrislck: sarna: I believe guile *could* import srfi-197 however I don't know how sarna: chrislck: I don't need it *that* much, I'll just use `let*` :D sarna: how do I make libraries visible to my program? I installed one with guix and when I run `guile myprogram.scm` it can't find the module civodul: sarna: hi! when you run, say, "guix install guile guile-lib", there's a hint displayed about setting environment variables civodul: if you follow that hint, it'll set GUILE_LOAD_PATH civodul: from then on, "guile" will find the Guile-Lib modules leoprikler: vijaymarupudi: what if you used the list pairs as keys though? leoprikler: in that case, for a deleted key, you would have to seek that pair (O(n), maybe one can do it faster) and then simply drop the car vijaymarupudi: I might do that, and then drop the cars during hash table resizes vijaymarupudi: thanks for the suggestion! sarna: civodul: I must have missed it. I'll set it up, thanks! rlb: sarna: If it helps, these may work fine in scheme too: https://git.sr.ht/~rlb/lokke/tree/main/item/mod/lokke/base/syntax.scm#L108 And the cond->/cond->> in there will likely work if you chagne the %scm-if to if, etc. rlb: (And of course, I'd be happy to contribute scheme versions of any of that to Guile proper if we were to decide it's desirable.) manumanumanu: sarna: this is a guile module I wrote a long time ago: https://hg.sr.ht/~bjoli/guile-threading-macros manumanumanu: but if anyone has a working implementation of srfi-197 you should use that dsmith: Hmm, The sample implementation https://github.com/ar-nelson/srfi-197/tree/draft-3 has Guile working with the r6rs lib rlb: wingo: nevermind - the #nil handling is still broken in main, I had unwittingly left my patch applied to the working tree. The make-struct/no-tail issue appears to be new (after 3.0.7). dsmith: sneek: botsnack sneek: :) dsmith: !uptime sneek: I've been running for 2 days sneek: This system has been up 2 days, 15 hours, 48 minutes leoprikler: given a SCM UTF-8 string, is there an "easy" way to determine the byte offset (and possibly count) of the char at a given (char) offset? rlb: On the C side or scheme side? leoprikler: I'll take either leoprikler: For context, I plan to (indirectly) use a library, that uses C-style strings and byte offsets, whereas any Scheme API would use char offsets to be useful rlb: On the C side If you're OK with null termination, then perhaps u8_strlen or u8_strnlen: https://www.gnu.org/software/libunistring/manual/libunistring.html#Elementary-string-functions-on-NUL-terminated-strings. Otherwise (not as "easy", fsvo "easy"), you can loop via u8_mblen, etc.: https://www.gnu.org/software/libunistring/manual/libunistring.html#Elementary-string-functions rlb: Though iirc I think I discovered that u8_next() (also in the null terminated section), might not actually care about nulls, and is a bit easier to use than the corresponding non-null-term function. Might not be something you'd want to rely on, though. rlb: But if you're writing this as an extension (outside guile), I suppose you might or might not want to depend on libunicode. leoprikler: perhaps not, but within the context of a guile extension it might still make sense to use libunicode leoprikler: do I understand this correctly, that I'd basically loop over u8_next() and then subtract new_ptr - old_ptr? leoprikler: it'd still be nice if I could instead determine the width by… say code point leoprikler: e.g. code point < 128 → 1 byte and so on rlb: Right, or you could keep two counts, or... i.e. you just use the iterators to skip ahead the right amount for each char, assuming it's valid. Though iirc u8_next may not have comparable error handling... rlb: wingo: tracked down the commit introducing the "Unbound variable: make-struct/no-tail" lokke compilation failure and filed a bug: https://debbugs.gnu.org/49404 I don't understand the situation well enough to pursue it further myself atm, but happy to assist if I can. lampilelo: it would be possible to create a system on top of srfi-37 for that, use a swappable dispatch in option processors and switch states, you'll have a layer of indirection and some options in some state could throw errors while others would behave differently depending on the state lampilelo: or you could just (let ((var #f)) (args-fold ...)) and set the var to whatever and use that in the processor for some other option if that's what you want vijaymarupudi: me vijaymarupudi: Whoops, sorry about that stikonas: RhodiumToad: figured out my problem, turns out I had to adjust boehm gc CFLAGS for musl libc... apteryx: lampilelo: indeed; the fold-args seem like it'd provide the most flexibility. Thanks for the hintsights. apteryx: how can I get the keyword value from a list? (assoc-ref '(#:something value1 #:more value2) #:more) doesn't return 'value2 apteryx: hm,m not assoc-ref because it's a plist, not a alist daviid: apteryx: get-keyword, from (oop goops) daviid: apteryx youmay just importthat proc if you don't want to import the all (oop goops) module apteryx: OK, neat. Thanks. daviid: welcome! flatwhatson: apteryx: memq returns the pair, so you could (memq elem plist) and then car is key, cadr is value apteryx: right, (and=> (member #:my-key the-list) second) would work too apteryx: but get-keyword is to the point :-) leoprikler: note that (let-keywords ) and lambda* are probably a better idea most of the times sarna: hey, will artanis work with guile 3? lampilelo: sarna: based on the title of this commit, yes: https://gitlab.com/NalaGinrut/artanis/-/commit/4654b125cfaddbd3d4a07f2c6ad1dfbf407b499e sarna: lampilelo: woo, great! who to ping so it's changed here? https://www.gnu.org/software/guile/libraries/ ft: Isn't that page based upon the packages in gnu guix? ft: And the guix package still depends on guile 2.2; so probably that. lampilelo: yes leoprikler: so we ought to get guile-artanis bumped to the 3.0 version :) sarna: oh! hmm. no idea what the workflow is here haha xiews: sarna: there is a branch for guile 3.0 in artais. manumanumanu: wingo: I don't know if you saw this, but if it gets some traction it could potentially be interesting: https://github.com/cisco/ChezScheme/issues/574 manumanumanu: I believe I saw your name in the old R6RS mailing lists, and given your current position it seems like it could be directed towards you and ludo. manumanumanu: sneek: seen ludo sneek: lloda?, pretty sure was seen in #guile 4 days ago, saying: erc didn't tell me anything, my chat window looked as if the messages were getting through, but they weren't. manumanumanu: dang manumanumanu: sneek: seen civodul sneek: I last saw civodul in #guix 15 hours ago, saying: nope. sarna: which revision does guile support by default? r6rs? RhodiumToad: it's not quite compatible with either r6rs or r7rs by default RhodiumToad: the docs claim it complies fully with r5rs RhodiumToad: there are options --r6rs and --r7rs that switch various defaults to be as close as possible to the specified revision, but not all features are implemented sarna: RhodiumToad: what would you suggest for a beginner to stuck with? the default? sarna: then I'd need to be reading r5rs docs, I've been reading r6rs - hmm.. flatwhatson: stick to the guile manual sarna: oh, okay. makes sense, thanks! rlb: info guile rlb: Heh, oops. manumanumanu: sarna: guile is pretty compatible with most r6rs code out of the box. manumanumanu: i had a bunch of pure r6rs modules before starting guile, and they all ran without problem manumanumanu: however, guile code is not r6rs-compatible by default. You have to limit yourself to r6rs, either usirg --r6rs at the command line or (install-r6rs!). manumanumanu: sarna: https://www.gnu.org/software/guile/manual/html_node/R6RS-Incompatibilities.html rlb: taylan: I haven't caught up on all the nil related discussion, but though I'd mention this https://www.gnu.org/software/guile/manual/html_node/Nil.html to make sure you'd seen it. rlb: (and the discussion of equality, etc.) taylan: rlb: yeah, I know about it. if I'm not mistaken, nothing in it contradicts the idea that #nil could be made equal? to () in Scheme to make sure equal? works for comparing Elisp and Scheme lists. taylan: it would however cause the weird situation that a false object is equal? to a true object, and I guess that would be very surprising. taylan: although as surprising as it seems, I'm not sure whether it would cause any issues in practice. rlb: Would it break transitivity? If so, that might be a hard restriction. rlb: i.e. that's what the info page seems to imply? *: rlb only skimmed. rlb: I can consider it more carefully later... taylan: rlb: if you make #nil equal? to both () and #f, but not make () and #f equal?, then it breaks transitiveness. if you make #nil only equal? to (), then it doesn't break it. rlb: Yeah, I was thinking more about "truthiness" than equality, and agreed, having two things be equal? but one "false" and the other "true" doesn't, offhand, seem plausible to me. sarna: thanks manumanumanu! "mostly compatible" sounds good enough for me haha rlb: wingo: hmm, I just tested against current main (i.e. past 3.0.7), and I'm not sure, but it's looking like whatever has changed since then may have fixed the #nil issue with lokke. If so, we may be able to ignore and/or close that bug I filed. However, now it's crashing further on, when trying to compile a clojure file: rlb: ice-9/boot-9.scm:1685:16: In procedure raise-exception: rlb: Unbound variable: make-struct/no-tail rlb: rlb: ...I just randomly wondered if there's any chance that might be because the lokke namspaces are #:pure. dsmith: !uptime sneek: I've been running for one minute and 37 seconds sneek: This system has been up 10 hours, 15 minutes rdrg109: !uptime dsmith: !uptime sneek: I've been running for 12 hours sneek: This system has been up 22 hours, 15 minutes dsmith: rdrg109: (no leading space) dsmith: Woah! 145 memebers civodul: dsmith: have we reached the number of people we had on freenode yet? dsmith: I think it was around 160 ? leoprikler: it feels like 3/4ths over here and in #guix dsmith: 150 right now civodul: 116, according to ERC :-) leoprikler: polari also says 116 leoprikler: or is that 150 poor souls using the wrong channel? civodul: heh dsmith: Hmm. My erc says 156 dsmith: wait dsmith: Doh! dsmith: Sorry. 116 dsmith: I was looking at the line number *: dsmith blushes dsmith-work: Happy Friday, Guilers!! tekakutli: happy friday dsmith stikonas: hi, in #bootstrappable we are trying to bootstrap guile (3.0.7). So I'm building guile with GCC 4.7.4 but once build process builds initial guile, it crashes. https://paste.debian.net/1203162/ any ideas what I might be doing incorrectly? RhodiumToad: in frame 1, what's the value of *(void**)ptr ? RhodiumToad: looks like something is screwed up between boehm-gc and guile stikonas: $1 = (void *) 0xfffbb0a7 stikonas: oh, I guess you want me to dereference it stikonas: $2 = (void *) 0x0 stikonas: so it's 0 stikonas: that was (gdb) p *(void**)ptr RhodiumToad: that's supposed to point to a function, the finalizer for some object apteryx: is it possible to have dynamic options based on the value of another CLI option using (srfi srfi-37) apteryx: hmm, thinking more about it, I don't see how that'd be feasible dsmith: sneek: botsnack sneek: :) daviid: as savannah uses cgit, which does not render image files, i've updated g-golf's web-site 'learn' page, so now it briefly describes and shows a screenshot for each example that comeswith g-golf ... https://www.gnu.org/software/g-golf/learn.html vijaymarupudi: g-golf looks interesting! vijaymarupudi: looking forward to following it's development wingo: moin :) MysteriousSilver: o/ sarna: o/ sneek: Welcome back sarna, you have 1 message! sneek: sarna, maximed_ says: guix has ‘git-style’ subcommands, so you could look there as well sarna: sneek: later tell maximed_: I looked there but haven't found anything haha, I'm not that good with reading guile source yet :D but thanks! sneek: Will do. sarna: what does `ice-9` stand for? I can't really find anything on it dsmith: sneek: ice-9? sneek: Last time I checked ice-9 is "a nod to the fictional substance in Kurt Vonnegut's novel, Cat's Cradle, capable of acting as a seed crystal to crystallize the mass of software" sarna: thank you! dsmith: sneek: botsnack sneek: :) dsmith: !since sneek: I've been running for 8 minutes and 11 seconds dsmith: !uptime sneek: This system has been up 8 minutes dsmith: Had a power outage.. dsmith: !uptime sneek: This system has been up 16 minutes dsmith: !uptime sneek: This system has been up 19 minutes dsmith: !since sneek: I've been running for 2 minutes and 54 seconds dsmith: !uptime sneek: I've been running for 56 seconds sneek: This system has been up 26 minutes dsmith: Yey dsmith: sneek: seen rlb sneek: rlb was last seen in #guile -49 minutes and -21 seconds ago, saying: Oh, though I should perhaps mention that on some of the platforms some tests have been marked as "unreliable", and their failures ignored.. chrislck: sneek: what is a time traveller? chrislck: you are! dsmith: sneek: seen rlb sneek: rlb was last seen in #guile one day and 21 hours ago, saying: Oh, though I should perhaps mention that on some of the platforms some tests have been marked as "unreliable", and their failures ignored.. dsmith: Time was not set correct when power came back up. dsmith: !uptime sneek: I've been running for 5 minutes and 57 seconds sneek: This system has been up 6 minutes dsmith: sneek: botsnack sneek: :) dsmith: The time was Nov 3, 2016 ! lampilelo: why? lampilelo: that's when the docker image was created or something like that? chrislck: sneek: who's a good bot dsmith-work: lampilelo: The system rebooted but didn't have Inet connectivity to contact NTP servers. dsmith-work: (Router was not up yet) dsmith-work: lampilelo: The device has no RTC and relies on NTP to set the date lampilelo: yeah, but why 2016? dsmith-work: Not sure. Has Debian on it. Paritally upgraded (thing only has 2G flash). Probably some initial date in that. dsmith-work: !uname sneek: Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux rlb: wingo, civodul: filed a bug to capture what I know about the 3.0.7 #nil problem and record the "fix" I came up with: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49305 I'd be happy to apply it if we decide it's reasonable, but I'd *definitely* want a second opinion. civodul: rlb: i'm no reference in these matters, but what you propose looks reasonable to me civodul: $sc-dispatch, via match*, does (cond ((null? p) ...) ...) civodul: and (null? p) matches #nil civodul: which prolly explains the bug you're seeing Aurora_v_kosmose: I don't suppose Guile has the ability to dump executable images? maximed: sneek: later tell: Aurora_v_kosmose: Guile has some modules for manipulating ELF and Guix has some other modules as well maximed: sneek: later tell Aurora_v_kosmose: Guile has some modules for manipulating ELF and Guix has some other modules as well sneek: Got it. maximed: sneek: later tell Aurora_v_kosmose: It's not quite ‘dumping executable images’ though sneek: Got it. Aurora_v_kosmose: Alright. I'd been wondering for the case of rumprun VMs. sneek: Welcome back Aurora_v_kosmose, you have 2 messages! sneek: Aurora_v_kosmose, maximed says: Guile has some modules for manipulating ELF and Guix has some other modules as well sneek: Aurora_v_kosmose, maximed says: It's not quite ‘dumping executable images’ though dsmith-work: Aurora_v_kosmose: unexec used to be a thing at one time. Aurora_v_kosmose: The gcc feature which Emacs recently stopped using, correct? dsmith-work: But with all the dependant .so's and stuff like address space randomization, I question if that's even possible anymore. Aurora_v_kosmose: (Or was it glibc? Meh anyway) dsmith-work: Ya. Take a running process and write the whole address space to disk as an executable. dsmith-work: Guile used to be really slow to start. Aurora_v_kosmose: Right, glibc wants to remove unexec so that's probably going away soonish. dsmith-work: Aurora_v_kosmose: Why are you interested in unexec? (what's a rumprun VM?) Aurora_v_kosmose: dsmith-work: rumprun allowed one to turn executables into unikernels. Unfortunately now that I look again... the project seems to have died. dsmith-work: !uptime sneek: I've been running for 7 hours sneek: This system has been up 7 hours, 55 minutes wingo: moo tekakutli: moo leoprikler: moo chrislck: leoprikler: I guess using deifne-foreign-object-type *does* require using (oop goops) ? *: chrislck does not grok goops leoprikler: not really? leoprikler: lemme check again leoprikler: yeah, you only need is-a? for type checking if that's what you want, but the record accessors also typecheck for you leoprikler: match et al. should also work if you prefer those chrislck: thanks. there are very few examples out in the wild unfortunately leoprikler: yeah, I haven't really been able to use guile-fontconfig beyond those toy examples either leoprikler: font handling is just weird imo sarna: hey, what library would I use for making git-style command line programs with subcommands? lampilelo: sarna: you could use args-fold from srfi-37 sarna: lampilelo: looks great, thanks! maximed_: sneek: later tell sarna: guix has ‘git-style’ subcommands, so you could look there as well sneek: Okay. dsmith-work: Wednesday Greetings, Guilers dsmith: RhodiumToad: How about non-continuable-error? ? RhodiumToad: dsmith: that doesn't do what you might think it does RhodiumToad: that tells you whether an exception object has a &non-continuable element in it RhodiumToad: but the lack of that doesn't mean it's continuable. dsmith: I was thinking that depends on how the exception was raised. If the continuable flag was set or not. dsmith: Up to the coder of the exception to get it right. Right? RhodiumToad: nope dsmith: That section of the manual is a bit light on examples. RhodiumToad: (with-exception-handler (lambda args (format #t "print2 ~S ~S\n" args (non-continuable-error? (car args))) 'continued) (lambda () (raise-exception (make-exception (make-error) (make-exception-with-message "foo!")) #:continuable? #t))) dsmith: Interesting.. RhodiumToad: er, that's not quite what I actually meant RhodiumToad: better example: RhodiumToad: (with-exception-handler (lambda args (format #t "print2 ~S ~S\n" args (non-continuable-error? (car args))) 'continued) (lambda () (error "foo!"))) RhodiumToad: that clearly isn't a continuable error, get non-continuable-error? still returns #f RhodiumToad: *yet dsmith: If you set #:continuable? to #t or #f, non-continuable-error? always is #f RhodiumToad: right, because non-continuable-error? is a property of the exception object, not of the way it was raised RhodiumToad: non-continuable-error? is true only for exceptions of type &non-continuable RhodiumToad: (which happens to be what gets raised if you try and continue after raising with #:continuable? #f) dsmith: I wonder if this is what was intended. dsmith: sneek: later tell wingo So what's up with #:continuable? ? sneek: Okay. *: daviid added a revealer.scm (g-golf) example (based on the revealer.c, from gtk-4-examples that comes with gtk-4) which demonstrate how to use , , g-timeout-add and a detailed signal-name - the screenshot is 'static', but the 'real' example 'animates' 9 revealer instances, fun :) wingo: dsmith: honestly, not very fleshed out. such an exception needs to be raised via raise-continuable tho sneek: Welcome back wingo, you have 1 message! sneek: wingo, dsmith says: So what's up with #:continuable? ? wingo: or raise exn #:continuable? #t wingo: hey ppl, any idea why MysteriousSilver can't post to the channel? wingo: is the channel misconfigured or is there something MysteriousSilver should do? *: wingo irc idiot who happens to have op privs taylan: we're probably still registered users only? *: taylan gtg lloda: I did need to register before i could post lloda: erc didn't tell me anything, my chat window looked as if the messages were getting through, but they weren't chrislck: Is there anyway to assign some guile code to be called when a SCM object gets gc'd? chrislck: (let ((my-object (newArray))) ...work on my-object...) chrislck: my-object will eventually be gc'd but the newArray is C code which allocates and must be freed. chrislck: I know ideally the code should be: chrislck: (let ((my-object (newArray))) ...work on my-object... (freeArray my-object)) RhodiumToad: wingo: the channel is set to that unregistered users can join but not speak; if you want to change that, you can remove the -q $~a mode RhodiumToad: chrislck: you can use finalizers or guardians leoprikler: chrislck: there are finalizers, specifically pointer finalizers chrislck: thx both -- finalizers are very new to me. is there a one-liner that I can use? leoprikler: not so much a one-liner, but we've used them e.g. in guile-fontconfig (no release yet, but it works™ for some tests) chrislck: ok will read when i have time :P RhodiumToad: is there a way to use finalizers from pure guile code (i.e. not using C)? I didn't find one on a quick search leoprikler: https://gitlab.com/leoprikler/guile-fontconfig/-/blob/master/fontconfig/char-set.scm#L30 leoprikler: TL;DR: (system foreign-object) is your friend RhodiumToad: ah right sarna: hey, which architectures does guile support? is it only x86_64 and i386? I can't really find it on the main page wingo: jit support on arm64, armv7, i386, x86-64. without jit on pretty much everything else that you can compile linux on. not great windows support currently tho sarna: hey wingo, I just watched your talk! :D I was mostly wondering if I could run guile on my RPi, thanks! *: RhodiumToad has run guile on an rpi RhodiumToad: had to fix some bugs, but those fixes are all in recent versions sarna: neato RhodiumToad: I've only tried it on armv7 and not aarch64, though RhodiumToad: the rpis I have in use are older ones sarna: are the platforms listed anywhere? I can't find them in the reference manual either, wiki lists only two - https://en.wikipedia.org/wiki/GNU_Guile RhodiumToad: pretty sure all of the code outside the jit library itself is intended to be architecture-neutral MysteriousSilver: Hello! RhodiumToad: good afternoon or other relevant time of day MysteriousSilver: salute RhodiumToad MysteriousSilver: i previously had trouble sending messages to this channel RhodiumToad: the channel is currently set to only allow registered and identified nicks to talk RhodiumToad: (though anyone can join) RhodiumToad: it's to cut down on spam, though it may not be necessary MysteriousSilver: new to irc, took time to realize sarna: damn, I can't install guile on my RPi :( aarch64, debian RhodiumToad: huh, why not? sarna: complains about libc6 version (expects >= 2.29 but debian only has 2.28 it seems) RhodiumToad: what exactly complains? sarna: apt sarna: if I try `apt install guile-3.0` it complains that I don't have guile-3.0-libs, if I try `apt install guile-3.0 guile-3.0-libs` it tells me libc6 is too ancient RhodiumToad: ok, so that's just a package management problem RhodiumToad: and I don't use linux so probably not the best person to help chrislck: leoprikler: thx looks like it's the solution :) sarna: RhodiumToad: what do you use? BSD? RhodiumToad: freebsd, yes sarna: neat! RhodiumToad: (for which guile does need a couple of patches, mainly to do with bad assumptions about off_t) RhodiumToad: (thanks to *BSDs having never been infected by the ghodawful largefile hacks) chrislck: leoprikler: looks good. however my constructor doesn't need an argument, and am struggling to make it work. leoprikler: a constructor without an argument? leoprikler: do you have a fieldless record? chrislck: uhh chrislck: yes chrislck: something like (newArray)... it's populated via something like (InsertAt array 1 1) and finalized via (freeArray) dsmith: sarna: The bot here ran on an rpi for a while. Now it's on a beaglebone black. dsmith-work: Morning Greetings, Guilers tekakutli: hello dsmith rlb: sarna: wrt architectures, all the green ones here at least build and pass "make check": https://buildd.debian.org/status/package.php?p=guile%2d3%2e0 rlb: and 2.2's doing a bit better: https://buildd.debian.org/status/package.php?p=guile-2.2&suite=sid right now, though I suspect sometimes it has mattered which build host picks up the job... rlb: Oh, though I should perhaps mention that on some of the platforms some tests have been marked as "unreliable", and their failures ignored. sarna: dsmith-work: it's a pretty small board! my rpi is beefier, I got the new one sarna: rlb: thanks, that's a lot of archs 👀 dsmith-work: sarna: Nice! leoprikler: chrislck: you should still have something like an array* that's returned by newArray and wrapped by your civodul: roptat: no crash for me! https://gitlab.com/guile-git/guile-git/-/issues/19 vijaymarupudi: hello all! sneek: Welcome back vijaymarupudi, you have 1 message! sneek: vijaymarupudi, leoprikler says: scm_gc_protect vijaymarupudi: ah yes, that's for storing it in the heap, I think I can live with the gc for the stack variables for now vijaymarupudi: I wanted to ask for any large guile project I can read the source code of and learn from! maximed: any particular reason bytevector=? doesn't accept offset & length arguments, or a bytevector-range=? doesn't exists, besides ‘that's not RnRS’? maximed: fwiw, I worked around this lack with bytevector->pointer & pointer->bytevector maximed: maybe something for (system foreign): (define (bytevector-range bv offset length) (pointer->bytevector ...))? maximed: I've seen the combination pointer->bytevector & bytevector->pointer a few times before (or was it the other way around?) sarna: vijaymarupudi: guix? :) vijaymarupudi: sarna: haha I was expecting that :) however I suspect that it's macro heavy, which might be a bit difficult for me to understand right now vijaymarupudi: Maybe medium sized rather than large lampilelo: vijaymarupudi: http://sph.mn/foreign/guile-software.html vijaymarupudi: lampilelo: that's perfect, thank you! maximed: except for the 'package' macro, Guix doesn't use macros all that much maximed: There are plenty of procedures in guix/lint.scm, for example maximed: lilypond hould be a good example of a guile project as well vijaymarupudi: that's good to know vijaymarupudi: thanks! maximed: And gexp (#~) is a macro as well. Actually, Guix uses plenty of macroology. But there's plenty of ‘procedurology’ as well. leoprikler: Don't forget about Guix' advanced record wizardry. leoprikler: plus anything having to do with monads :P vijaymarupudi: advanced record wizardry? leoprikler: (guix records) to name a start RhodiumToad: modern compilers make the logic of boehm-gc questionable drakonis: when is it time to replace it then? drakonis: now? merazi_1: Hello guile! RhodiumToad: good evening tekakutli: hello merazi merazi_1: how are you doing? RhodiumToad: same as usual merazi_1: Oohh, I hope that's good. tekakutli: merazi_1 what did you do today to further our agenda? dsmith: leoprikler: Actually, guile had it's own GC before boehm. Inherited from SCM. merazi_1: tekakutli: Nothing really 😓 I've been doing some basic uni stuff today, preparing for the week. rlb: ...and iirc, getting the handling right *everywhere* on the C side was not always easy (wrt the previous non-conservative collector). dsmith: Ya. lots of mysterious bugs just went away, but on the other hand, added another dependency. vijaymarupudi: I'm not sure how central boehm is to the code, but I wonder if no-ops (for now) could be provided to increase or decrease a ref count for an SCM object vijaymarupudi: So that in a future, a command line flag could opt for a more hands on approach? vijaymarupudi: In the interest of high performance of course leoprikler: sneek later tell vijaymarupudi scm_gc_protect sneek: Okay. apteryx_: how do we recursively dereference a (potential) symbolic link? readlink would only dereference it once, correct? apteryx_: ah, there is an example as readlink* in (guix utils0 apteryx_: (guix utils) dsmith-work: Monday Greetings, Guilers RhodiumToad: also see canonicalize-path leoprikler: Does Guile (the language) have something similar to Emacs Lisp's with-demoted-errors? leoprikler: I know Guix has false-if-exception*, but it's not quite what I'm looking for. RhodiumToad: there isn't a builtin for it, but it should be doable RhodiumToad: actually RhodiumToad: it doesn't seem to be documented, but false-if-exception has an optional warning arg dsmith-work: Ur? dsmith-work: Woah. RhodiumToad: (false-if-exception expr #:warning template arg ...) RhodiumToad: (false-if-exception (error "foo!") #:warning "demoted error ") outputs ;;; demoted error foo! RhodiumToad: that said, doing your own thing using with-exception-handler or catch might be preferable leoprikler: yeah, it also prints the entire exception RhodiumToad: what do you want to happen to the error? leoprikler: just the error be printed (perhaps with the right prefix) leoprikler: I don't know how continuable exceptions are handled – would the code continue after the throw without me doing anything or would I need extra code for that? RhodiumToad: do you want demoted errors to be continued if possible? leoprikler: yep RhodiumToad: false-if-exception doesn't do that, it unwinds all errors leoprikler: thought so leoprikler: so I need an unwind-handler instead of catch? chrislck: dynamic-wind? leoprikler: I should probably just read the manual on continuable exceptions first RhodiumToad: you shouldn't need or want dynamic-wind for this leoprikler: so it appears this is the default (#:unwind?=#f) behaviour of with-exception-handler? dsmith-work: How timely. I was just looking at with-exception-handler last night. RhodiumToad: the default for with-exception-handler is to invoke the handler without unwinding, in the tail position of the raise-exception call dsmith-work: https://paste.debian.net/1202724/ RhodiumToad: however, most exceptions are not continuable, so if the handler just returns, it'll throw another exception (to the previous handler) RhodiumToad: it works to have two nested handlers, the inner one to print the error and the outer one to unwind for &non-continuable, but I don't know if there's a more elegant way dsmith-work: RhodiumToad: Is that double level needed? Just print the error in the unwound handler. RhodiumToad: that wouldn't continue a continuable exception, though dsmith-work: Ahhh RhodiumToad: the request (aiui) was for code that would automatically continue any continuable exception and catch any non-continuable one, printing it either way RhodiumToad: something like this: https://dpaste.org/1OHe RhodiumToad: that assumes that #f is always a reasonable thing to return to a continuable exception RhodiumToad: also this assumes guile 3 with its unification of exceptions and throws JLouis: what would be equivalent in Guile to prin1-to-string that data can be saved in file? dsmith-work: JLouis: Perhaps object->string JLouis: aha let me try JLouis: that is right for guile JLouis: thanks dsmith-work: np dsmith-work: So what makes an exception continuable or not? Yeah, by calling raise or raise-continual or whatever. What are examples of exceptions that could be continuable and some that are not? RhodiumToad: raise-exception has an optional argument which says it's continuable RhodiumToad: (raise-exception blah #:continuable? #t) RhodiumToad: afaik it's not dependent on the type of exception or anything else dsmith-work: Right, but I'm really asking the deeper question. What kinds of execeptions are or should continuable? Or should not be? RhodiumToad: good question leoprikler: dsmith-work: if you're writing procedural code you might want to throw continuable exception for optional stuff failing leoprikler: RhodiumToad: what would happen if I inverted the order? leoprikler: I.e. in the inner exception handler unwind the stack if it's a non-continuable exception, then rethrow as continuable and in the outer one simply format the error? RhodiumToad: why? RhodiumToad: the problem is that I didn't find a way to know if the exception was continuable except to try and continue it RhodiumToad: which results in a &non-continuable exception if it turned out not to be continuable RhodiumToad: and that gets thrown to the outer handler and not the inner one RhodiumToad: (i.e. it gets thrown to the handler outside the one that tried to continue the error) iskarian: Hello all :) I have a method X that returns unspecified, or multiple (unknown number of) values, but using (let ((value (X)) (if (not (unspecified? value)) value ...)) only produces the first value. Is there a way to check for unspecified and also get all values? rlb: iskarian: depending on what you need perhaps https://www.gnu.org/software/guile/manual/html_node/SRFI_002d11.html or receive https://www.gnu.org/software/guile/manual/html_node/Multiple-Values.html iskarian: rlb, thanks for the reply; I saw those, but I do not know the number of values ahead of time... is there a way to make them work with an arbitrary number of values? iskarian: Another question: is there a way to format an exception just like I'd see printed if I raised the exception? flatwhatson: iskarian: you can (recieve args ...) instead of (receive (a b) ...) flatwhatson: there's also call-with-values, eg. (call-with-values myfun list) will return a list of myfun's return values. iskarian: oh... thanks, flatwhatson! that makes a lot of sense sense, but it'd be nice if it were in the manual, haha flatwhatson: well, it does say "like the argument list in a lambda", which hints at this flatwhatson: similarly, you can (receive (first . rest) ...) iskarian: fair enough! all the dots make my head spin :) flatwhatson: eg. (receive (a b . cs) (values 1 2 3 4 5) cs) gives (3 4 5) leoprikler: There's also SRFI 71 let and compose leoprikler: e.g. (compose list mv-producer) gives you the values as a list garjola: Hi all. I am new to guile and I am looking for a good book to get started. I am familiar with lisps (Elisp, some clojure years ago) and I have configured geiser on Emacs to start playing around. I have the info reference manual, but I was looking for a «project oriented» book to get familiar with modules and the usual dev cycle with guile. Any recommendations? Thanks! leoprikler: There are books on Scheme, such as SICP, but few of them teach the Guile flavour for more or less obvious reasons. leoprikler: I think The Little Schemer is also among the book titles, that people can read dsmith: sneek: books? sneek: books is try htdp and scip dsmith: sneek: htdp? sneek: I could be wrong, but htdp is How to Design Programs, http://www.htdp.org/ leoprikler: is it scip or sicp? dsmith: heh dsmith: sicp dsmith: sneek: forget books sneek: Okay. dsmith: sneek: books is Try htdp and sicp sneek: Understood. dsmith: goodbot mwette: sicp: structure and interpretation of computer programs mwette: tspl: the scheme programming language: https://www.scheme.com/tspl4 (this has a chapter on syntax-rules and syntax-case) dsmith: tspl Is great garjola: Thanks for the pointers. I understand that there are no specific Guile books. I know SICP and HTDP, I will have a look at TSPL. vijaymarupudi: Hello all! I'm new to guile, and looking into whether to make it my "main" language vijaymarupudi: I was watching a bunch of talks by wingo on youtube, and was curious if there was any progress into the question of a new garbage collector? vijaymarupudi: I don't want to depend on the Boehm for my C extensions if possible vijaymarupudi: But generally, I've been enjoying Guile, thank you very much for maintaining and improving it! leoprikler: It's all Boehm? Always has been. leoprikler: w.r.t. GC in C extensions, I don't think you manually interact with boehm anyway, instead using the scm_gc_ calls leoprikler: if at all vijaymarupudi: I see vijaymarupudi: At 21:00 in https://www.youtube.com/watch?v=qS121jMhMpE, wingo seems to talk about possible future plans dsmith: !since sneek: I've been running for 21 hours apteryx: hello! I'm surprised that this is not valid: https://paste.debian.net/1202456/. It seems to be because in the template, each variable must be immediately followed by the ellipsis ... apteryx: Ideas? apteryx: substitute* is a macro from (guix build utils); see: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/utils.scm#n793. apteryx: I want the macro to expand into multile substitute* usages (one per file). apteryx: seems I'm forced to strip the last ... and manually repeatedly use the 'disable-tests' macro leoprikler: apteryx I think you'll need to express that as a syntax-case, but I can't help you write it :P lampilelo: apteryx: i think just wrapping substitute call and the ellipsis with begin should work bricewge: How can I get from such data sctrucutre “'(("user" . ("alice" "bob" "eve")) ("admin" . ("alice")))” to “'(("alice" . ("admin" "user")) ("bob" . ("user")) ("eve" . ("user")))”? bricewge: Should I use alist in that case? leoprikler: bricewge: first (append-map cdr groups+users) and delete-duplicates leoprikler: that gives you a list of users leoprikler: then per user (filter-map (lambda (group) (and (member user group) (car group))) groups+users) leoprikler: gives you a list of groups, which finally you can cons to the users to get the restructured alist leoprikler: your data is already an alist, so that works out bricewge: leoprikler: Thanks a bunch, it works! bricewge: Is that a convention to call alist key+value, like the previous groups+users? lampilelo: alist is a list of pairs lampilelo: alist = association list bricewge: Yes, but is it a convention to name an alist variable "key+value" as leoprikler did with "groups+users"? lampilelo: not really tekakutli: hello gentlement, finally decided to give guile a go bricewge: lampilelo: Thanks tekakutli: I have a question: what t tekakutli: what does # mean? tekakutli: like #f or #:key lampilelo: it depends on a context, #:foo is a keyword, which is just like a symbol but (symbol? #:foo) => #f and (keyword? 'foo) => #f lampilelo: #f and #t are booleans, don't have anything to do with keywords lampilelo: and #\z is a char 'z' tekakutli: thanks, I know, I was refering specifically to the # tekakutli: but yea, I guess its contextual lampilelo: by itself it doesn't mean anything, just a part of a syntax tekakutli: thanks lampilelo leoprikler: bricewge: key+value is a semantic variable here, you can name your variables however you want leoprikler: I personally do write this occasionally and there's also a procedure called car+cdr which for alists exactly produces key+value as multiple values *: leoprikler → afk again mwette: I think of # as telling the reader the next character is special; #\ for chars, #x for hex numbers, #; for comment #{ for symbol, ... There is a section in the manual about adding your own https://www.gnu.org/software/guile/manual/html_node/Reader-Extensions.html#Reader-Extensions chrislck: even more confusing #(1 2 3) is shorthand for (vector 1 2 3) chrislck: and wingo has uncovered some unusual bugs involving # recently in the reader mwette: I've used # to allow in-line expressions from other languages: https://paste.debian.net/1202498/ dsmith: #/ice-9/foo used to be reader syntax for modules rlb: wingo: while I'm still not certain I understand things well, I wondered if this might be feasible as a follow up to 0cc799185576712d69f11fc794454f2f5447bef7: rlb: --- a/module/ice-9/psyntax.scm rlb: +++ b/module/ice-9/psyntax.scm rlb: @@ -2157,6 +2157,8 @@ rlb: (lambda () rlb: (gen-syntax src #'(e1 e2 ...) r maps ellipsis? mod)) rlb: (lambda (e maps) (values (gen-vector e) maps)))) rlb: + (x (eq? (syntax->datum #'x) #nil) rlb: + (values '(quote #nil) maps)) rlb: (() (values '(quote ()) maps)) rlb: (_ (values `(quote ,e) maps)))))) rlb: rlb: rlb: O' rlb: I'll need to triple-check, but that just includes a case for #nil alongside the patch's original case for (), and it does fix the problems with lokke. dsmith: Ya, see the comment for SCM_MATCHES_BITS_IN_COMMON in scm.h rlb: sneek: later tell taylan Have you seen https://www.gnu.org/software/guile/manual/html_node/Nil.html *: rlb never remembers how that works... rlb: leoprikler: if I'm not around when taylan is, might also be plausible to mention my original motivation to fix the change in 3.0.7, i.e. rlb: https://git.sr.ht/~rlb/lokke/tree/main/item/mod/lokke/base/util.scm#L61 which is used in methods like this: https://git.sr.ht/~rlb/lokke/tree/main/item/mod/lokke/base/collection.scm#L712 rlb: *: rlb looks at that again to make sure he's not just doing it wrong... rlb: I'm actually not sure I understand why that fails, and/or how it'd OK for it to fail, if the problem is the handling of that (eq? #nil arg). rlb: s/it'd/it'd be/ dsmith: Anyone know how to kill a tcp client program in such a way that it doesn't shudown the socket cleanlly? Want to simulate pulling an ethernet cable out or powering off a switch. (Testing keepalives) dsmith: Sorry not Scheme related... flatwhatson: dsmith: maybe add an iptables rule to drop packets on that port? dsmith: Yeah, that might do it. But iptables. (Ugh) dsmith: flatwhatson: Using iptables worked great! Thanks. flatwhatson: no worries :) emanuele6: part daviid: dsmith: sneek is sleeping? dsmith: sneek: botsnack dsmith: :( dsmith: sneek: botsnack sneek: :) dsmith: daviid: thanks daviid: welcome! tohoyn: Happy Midsummer Eve leoprikler: rlb tbh i don't understand what this code is trying to achieve rlb: leoprikler: the require-nil syntax? It's just used elsewhere in calls like (define-method (foo (x )) (require-nil ...) ...) to make sure that foo reports an error if x is not #nil, i.e. foo should not work for #t or #f. leoprikler: I… don't understand the rationale behind doing such a thing leoprikler: is this for stuff that really wants x to be a list, but must also accept x being #nil? rlb: leoprikler: if I understand what you're asking, nil in clj is somewhat like it is in elisp, but even broader, i.e. in many places it acts like an empty collection. rlb: i.e. empty vector/set/list/map etc. rlb: so (empty? nil) is true, but (empty false) should be an error. leoprikler: ah, i misspoke, of course #nil ought to be the empty collection or false in Clojure semantics rlb: guile's current policy wrt nil worked well wrt a clj dialect. leoprikler: I'm just worrying whether you can really apply goops here leoprikler: is there a way of providing your own checker for is-a? rlb: Hmm, what's the problem you're thinking of? rlb: (So far, using goops seems to have worked fairly well.) leoprikler: imho (is-a? #nil ) should return #t leoprikler: so that in the code above you could (define-method (blah (x )) ...) rlb: iirc null is intentionally only EOL, but I may be remembering wrong. leoprikler: I don't know how GOOPS works tbph rlb: And i do use and in other places. leoprikler: but it feels weird that and null? work differently leoprikler: (same with and list?) rlb: In any case, perhaps you saw it, but this was the only real problem I was having atm, i.e. the fact that 3.0.7 broke this: https://paste.debian.net/hidden/18ce7c3c rlb: I haven't seen any issues with the goops-related bits yet. rlb: Oh, and I don't think it matters what the argument to foo is, i.e. iirc (foo 'x) would also crash. leoprikler: ahh, i think that may be related to emacs lisp where (defun frob nil ...) is valid syntax leoprikler: hum, that's weird, but I'll try in a repl rlb: I found the commit - that's what I was asking about earlier, but I need to delve a bit more on my own first.. rlb: 0cc799185576712d69f11fc794454f2f5447bef7 rlb: Didn't try the repl, but loading that file via "guile foo.scm" is how I was able to reproduce it. leoprikler: I think ice-9 match has a similar issue where (match #nil clauses) throws rlb: Right, I think the suggestion was that it may have been related to recent syntax/reader/or-similar changes. *: rlb has to wander off soon. leoprikler: rlb: (define foo (match-lambda (#nil #t) (_ #f))) leoprikler: matches #nil or '() leoprikler: I don't know whether match is acceptable in your context leoprikler: and of course if you drop the _ part, you get a match error :P kitzman: yay so I wrote my first scheme utility. https://git.disroot.org/kitzman/lieferhund . i guess adding it to guix will be better when it will have more features kitzman: (constructive) criticism is needed leoprikler: lieferhuendchen should be lieferhündchen leoprikler: I think using a peg parser might be more appropriate than string-replace-substring leoprikler: basically, you want to get to something similar to what you'd pass to Guix' mixed-text-file, e.g. '("Title: " title "\nContent: " content) leoprikler: where title and content are then replaced by the actual title and content leoprikler: I think doing this with lists and symbols directly might also be beneficial leoprikler: no need to do the text parsing leoprikler: but if you want you can translate "Title: ~~TITLE~~" to (list "Title: " title) kitzman: peg parser on the issue list now ^^ kitzman: ah, i knew about the umlaut - maybe i can use the correct spelling in the README while using the "latinized" one in the script kitzman: btw - i only lived few years there, and mostly in english-speaking communities - isn't substituting "ä" with "ae" non-official but still acceptable? leoprikler: In terms of computing it's an antiquated practise hailing from the age of dinosaurs leoprikler: we call them welpen if you need something without umlaut leoprikler: well, perhaps there's some different between welpen – puppies and hündchen – small dogs, but the analogy probably still works kitzman: "lieferwelpe" sounds cute ^^ i'll go with that dsmith-work: Happy Friday, Guilers!! roptat: is there a way to give a property to a procedure, so that I can read it later with procedure-properties? roptat: (it's enough for me if it's limited to adding properties when defining the procedure) roptat: ah, set-procedure-properties! I should have read the manual dsmith: !seen dsmith: !since sneek: I've been running for 4 days apteryx: Hello Guilers! I'm trying to define a 'define-with-source' macro that'd expand to a procedure definition and also a directive to set the source to the newly defined procedure: https://paste.debian.net/1202204/. For some reason the 'set-procedure-property!' doesn't work as intended; (procedure-source PROC) returns #f. apteryx: hints welcome :-) leoprikler: docstring body is weird leoprikler: Interestingly it works inside a REPL leoprikler: apteryx what happens if you peek the procedure properties directly after setting them inside the syntax? apteryx: I think the trick is delaying the set-procedure-property! with eval-when: https://paste.debian.net/1202205/ apteryx: the above code seems to work apteryx: instead of docstring body it could be body body* ... I guess :-) leoprikler: hmm leoprikler: apteryx: If I put the entire thing into (eval-when (load) ...) and load the compiled go, it also works apteryx: I think it's safe to do the define at expansion time, but the set-procedure-property! needs the procedure object to exist, which not being a top level syntax is not guaranteed to be at expansion time, IIUC. leoprikler: oh, so you mean it breaks if you have a procedure-local define? apteryx: What do you mean by procedure-local define? leoprikler: (define (foo ...) (define-with-source (bar ...) ...)) apteryx: I think the subtlety might have more to do with macros being able to use other top level macros, but not other top level definitions at expand time (see "info '(Guile) Eval When'") leoprikler: hmm you mean having the define-with-source in a different file from the expansion? apteryx: even locally to the expansion, the proc defined is not syntax itself, so even if it appears at the top level, the syntax being expanded can't refer to it at that time apteryx: IIUC, which may not be the case as I need to get some zzz apteryx: later :-) rlb: wingo: I'm don't yet completely understand the code that was changed, but I wondered if guarding it so that it only operates on EOL, not nil, would still accomplish what was needed. It does appear to fix the problems with lokke: rlb: (x (eq? (syntax->datum #'x) '()) rlb: (values '(quote ()) maps)) rlb: leoprikler: rlb will that still work if you terminate your list with #nil? leoprikler: other than that, IIUC syntax-case, match et al have order to them, so if you put your #nil case first, that ought to handle it leoprikler: though perhaps the syntax for that might be a little awkward, idk dsmith-work: Hey Hi Howdy, Guilers taylan: heya taylan: leoprikler: I believe the point is not to match #nil, although I haven't followed the full conversation. taylan: not sure why one would want to avoid matching it. IMO #nil should work like () in all respects and be equal? to it. leoprikler: not equal?, but match '() leoprikler: but the thing is you want to detect #nil as #f also in languages like clojure and emacs lisp taylan: if #nil doesn't equal '() then the Scheme list (foo) and the Elisp list (foo) can't be equal? to each other, which they probably should leoprikler: IOW make (match #f) also match nil? taylan: (currently indeed they aren't) taylan: match uses equal? semantics, right? to keep transitiveness of equal? I would not make #nil equal? to #f. leoprikler: I don't think match uses equal taylan: basically what I suggest is to "privilege" '() when it comes to equal?'ing #nil, because I think that's a lot more useful than equal?'ing #f leoprikler: instead, it special cases a bunch of stuff leoprikler: boolean constants being one thing leoprikler: if you specify (match #f) => matches #f and #nil, that's exactly what it does taylan: hmm. not sure how to feel about that. I've mostly just thought about this in terms of equality predicates. taylan: intuitively I'd say #f shouldn't match #nil because it's neither eqv? nor equal? to it, but I haven't used match much so far leoprikler: in that case match shouldn't do the nil either, but obviously it has to leoprikler: so match needs something else than equal? semantics leoprikler: or good ol' helper predicates taylan: IMO #nil should just equal '(), and also match it in match. consistent, and probably most useful and least surprising behavior. leoprikler: no taylan: why not? leoprikler: #nil is not equal to either '() or #f leoprikler: it is distinct taylan: I know it's currently not, but IMO that's pretty much a bug leoprikler: that's not a bug, there is a philosophical difference leoprikler: saying nil is the empty list is like saying void is any other data type taylan: Elisp nil is the empty list though. if you evaluate () you get nil in Elisp. leoprikler: I'd write that as '() ~> nil rather than '() = nil, though taylan: I guess one could argue that there is no empty list in Elisp and CL... but I don't see the usefulness of thinking of it in those terms. taylan: anyway, philosophy aside, I think Scheme '(foo) should be equal? to Elisp '(foo), and that requires (equal? '() #nil). leoprikler: I think I prefer erring on the side of uselessness in that case. leoprikler: '() is not "structurally equivalent" to #nil, though taylan: well it is if you see it as the empty list, so that's the same philosophical question as before leoprikler: comparing lists with equal? is imo weird anyway taylan: IMO pragmatism above semantic purity is preferable whenever it won't cause (more) headaches down the line. there's already some headaches #nil will invariably cause, but I think making it equal? to '() will actually reduce them. leoprikler: making #f equal to '() will cause more headaches taylan: that's not what I'm proposing taylan: just making #nil equal to '() leoprikler: not making #nil equal to #f is the same headache as the list thing though leoprikler: so i really don't get your rationale other than "I like lists", I guess taylan: I don't think so. checking boolean equivalence with equal? is probably much rarer than checking structural equivalence of lists with equal? taylan: it's basically a guess/prediction, but I'm almost sure that if we inspected all uses of equal? out there, there would be many more cases checking structural equality than Boolean equality taylan: structural equality involving lists* leoprikler: Even if that is true, I don't think that gives us the right to make some "equalities" more equal than others taylan: basically, (equal? '() #nil) => #f means that any use of equal? involving lists will "break" when an Elisp list is involved. OTOH (equal? '() #f) => #f will only "break" when an Elisp #nil intended as a Boolean involved. leoprikler: what if you have a procedure, that returns a list, including the empty list on success and #f for failure? taylan: we're assuming this is a Scheme procedure, and is called from Scheme, right? in that case you have to check (eq? result #f) anyway because (if result ...) will also break. taylan: wait, that's not entirely true... taylan: can you explain what the problem with that situation would be? leoprikler: the problem can be whatever you want it to be leoprikler: of course emacs lisp and clojure interop will not be given, so that's one problem leoprikler: there will be more depending on what you decide to do with equal? taylan: well it has to be a Scheme procedure (otherwise it can't distinguish between empty-list and false in its return), and when called from Scheme it won't pose any problem. both 'if' and 'equal?' on its result will do the expected thing. leoprikler: also, i think '() equal? #nil breaks if as well taylan: unless I suppose it just so happens to return #nil when it meant empty list, because an Elisp list got in there somehow... but in that case (equal? '() #nil) and (not (equal? #nil #f)) is exactly what you want. leoprikler: ahh, but what if Elisp #f got in there? :P taylan: no, 'if' doesn't use equal? in any way taylan: Elisp doesn't have #f :D leoprikler: What I'm saying is it breaks the semantics of if taylan: how so? taylan: do the semantics of if say that when (if x 1 2) returns 1, then for every y that's equal? to x, (if y 1 2) must also return 1? leoprikler: (if (equal? a b) (equal? (if a 1 0) (if b 1 0))) leoprikler: It's at least a headache taylan: it certainly is, but remember that currently #nil isn't equal? to #f so we already have that headache :) taylan: so from that perspective 'if' is already "broken". (I hadn't realized this until now...) leoprikler: it would also break other stuff like and leoprikler: (and #nil #t) => #t ;; whut? taylan: no, why would that happen? 'and' hopefully relies on 'if' semantics? leoprikler: (and '() #t) => #t ;; okay leoprikler: breaking if basically means breaking your entire language taylan: as I said, 'if' is already broken if you consider that breakage. taylan: and somehow Guile Scheme still manages to work :D leoprikler: it's not if that's broken, it's your concept of equal? taylan: hmm wait, yeah I think my previous assertion was wrong. leoprikler: note that elispers expect to match the tails of their lists with if from time to time taylan: leoprikler: (if (not (equal? a b)) (not (equal? (if a 1 0) (if b 1 0)))) <- do you think this is accurate? (I'm really not sure) leoprikler: no taylan: but only because (equal? #nil #f) is false, is that correct? taylan: i.e. in a world where #nil didn't exist, it would be accurate? leoprikler: (or (not (equal? a b)) (equal? (if a 1 0) (if b 1 0))) leoprikler: no leoprikler: 'a is not equal? to 'b, but both return 1 taylan: oh, derp taylan: ok let me try that again... :D taylan: (if (not (equal? a b)) (not (equal? (not a) (not b)))) <- how about this one? *: taylan has gotten way too confused, pulls up a REPL leoprikler: hmm, lemme check taylan: I think I wrote nonsense again leoprikler: it's been a while since i did logic&computability taylan: the simple example of 'foo and 'bar defeats that, so yeah that was nonsensical again, sorry leoprikler: I posted the true tautology a little earlier, try it: (or (not (equal? a b)) (equal? (if a 1 0) (if b 1 0))) taylan: well I'm trying to find a different tautology that already breaks due to #nil, hence proving that Guile Scheme is already "broken" in a similar way that (equal? '() #nil) would "break" if taylan: let me put my logic in English first: currently, we already have a pair of values that are both false, but not equal? leoprikler: Gödel claims I can't have a proof for this, but I think the way Guile currently works is consistent. taylan: hmm, actually no, that doesn't necessarily mean it's broken leoprikler: that's not how implications work taylan: values that are both true don't have to be equal? so values that are both false don't necessarily have to be equal? either... taylan: however, in standard Scheme, values that are both false are equal? because there is only one false value... leoprikler: that is true, if you take "only one value for #f" as an axiom, then Guile violates the RnRS taylan: in that case I think it's two different layers of "breakage" at least with respect to standard Scheme. the first being, breaking the assumption that two false values are equal? this is already the case. my proposal would add a second layer: that a true and a false value can be equal?. taylan: however, I would dispute that this makes the semantics of 'if' broken, because equal? isn't eqv?... leoprikler: I would say so leoprikler: since eqv? is stricter than equal? we do have (and (eqv? a b) (equal? a b)) taylan: I don't think anything changes in that respect. (list 'foo) and (list 'foo) are also equal? but not eqv? for instance. *: taylan has to go AFK for ~25 minutes leoprikler: sure, but (cons 'foo '()) (cons 'foo #nil) is an even laxer comparison leoprikler: you need equal-modulo-nil? for that leoprikler: (or list-equal?) leoprikler: hmm, that makes me wonder… leoprikler: taylan: (if (not (equal? a b)) (not (equal? (not a) (not b)))) <- how about this one? this one at least works for pure booleans, but not much else I guess taylan: leoprikler: I mulled it over a bit while driving. I would posit that (equal? #nil '()) doesn't break 'if' because for every other equality predicate EP, "iff (EP a b) then (EP (if a 1 0) (if b 1 0))" continues to hold. so we just "break" equal? so to say. leoprikler: I humbly disagree leoprikler: using srfi-1 to define your own list equality predicate is not that difficult leoprikler: (list= eq? (cons 'a #nil) (cons 'a '())) taylan: leoprikler: BTW you can send your objection to https://bugs.gnu.org/48425 so it's documented kitzman: i encountered something that it's most probably lack of attention rather than behaviour which I don't know... https://bin.disroot.org/?ad95f95bfe8ef039#D52R2kDN9bZWPTDV5odKDdWNieL1z2EyvjK1fXJBJZwC kitzman: the returned exp is matched later, and the lambda is evaluated a couple of times. the error message is that "int-orig" is unbound (line 46). which i find unexpected leoprikler: kitzman, I think it would be slightly easier with match-lambda*, but that's a style thing leoprikler: I also don't think this definition is safe against expansion attacks leoprikler: e.g. ~~TITLE~~ = ~~NAME~~ and ~~NAME~~ = ~~TITLE~~ leoprikler: or wait, my bad, it does at least only process them once leoprikler: but it might make funky replacements, so watch out for those leoprikler: I so far don't see the problem with the thing itself, what does peek say? kitzman: i'll try match-lambda* i'm a relatively new schemer. also thank you for bringing the expansion attack in my attention, it will be useful later kitzman: hmm, the string seems okay. kitzman: i think it has smth to do with the quoting - for example if i use a let* and car, name is considered a symbol dsmith-work: Shouldn't null? be used for detecting the end-of-list? IIRC, the bit-level values of '() and #nil were very carefully chosen to make null? effient. dsmith-work: Instead of comparing directly with '() or #nil ? dsmith-work: There were huge debates about this years ago. leoprikler: match () does the right thing w.r.t. null checking leoprikler: but otherwise yeah, in plain guile use null? chrislck: Wednesday greetings? wingo: ahoy :) dthompson: yarrr dsmith-work: UGT Greetings, Guilers wingo: heya dsmith-work *: dsmith-work waves rlb: wingo: regarding your comment about using "the right EOL in that case", not sure I understood yet. In the lokke example above, I was just trying to make sure that an incoming is eq? #nil. Perhaps that's not what I "should" be doing? (Setting aside for the moment the fact that I was only using a macro for inlining, and don't actually *need* it...) wingo: the macro is the problem, it thinks #nil is the same as () in a source term wingo: is a syntax-case problem wingo: i think anyway *: wingo gtg rlb: OK, so that usage is "fine", but we might just have a bug? If so, understood, and not a big deal. I can just change it to a function for now, perhaps forever (and maybe even get it inlined). rlb: Though I wonder if I'll hit other issues given that clj has similarities with elisp on this front, and I'm doing most of the compilation via syntax expansion. rlb: wingo: bisect points to 0cc799185576712d69f11fc794454f2f5447bef7 as the commit where that #nil macro issue appeared. wingo: interesting wingo: rlb: to my mind, all of the null? calls in psyntax.scm:2880-3019 (the pattern matcher used by syntax-case) should instead be eq-null?, defined as (define (eq-null? x) (eq? x '()) wingo: #nil should probably never match () from the POV of syntax-case wingo: dunno, i guess i can see the argument for building scheme expressions from elisp, but really i think it's not too much to ask to use the "right" EOL in that case, dunno wingo: if we wanted to relax that stance, we could use eq-null? only when dispatching on patterns, but null? on incoming syntax taylan: wingo: rlb: I seem to have missed part of the conversation here so dunno if these came up: taylan: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48315 taylan: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48425 taylan: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48318 taylan: wingo: also, I sent quite a few patches to the bug tracker a couple weeks ago, hope they don't get forgotten :) *: taylan gtg rlb: wingo: hmm, I'll need to understand what you've said more carefully later, but here's where I was using that check: https://git.sr.ht/~rlb/lokke/tree/main/item/mod/lokke/base/util.scm#L61 which is used in methods like this: https://git.sr.ht/~rlb/lokke/tree/main/item/mod/lokke/base/collection.scm#L712 dsmith-work: Tuesday Greetings, Guilers thmprover: Random question: what's the convention for guile docstrings? I couldn't find it in the reference manual... leoprikler: thmprover: You can choose between Emacs-style "Frob VAR." and texinfo-style "Frob @var{var}." leoprikler: both are accepted and which you prefer somewhat depends on your tooling tohoyn: sneek: botsnack sneek: :) thmprover: leoprikler: for texinfo-style, can I use *any* texinfo commands? Or is it a restricted subset of texinfo? Specifically, is there a way to encode math? leoprikler: Again depends on your tooling, but AFAIK the texinfo module from Guile should not interfere with your math code leoprikler: Try object-stexi-documentation to get a closer feel thmprover: Awesome, thanks! mwette: thmprover: github.com/mwette/guile-contrib/scheme-texidoc.el is (non-robust) minor mode that will take comments in texi format preceeding a function and turn them into a doc string pasted as the first expression in a function body mwette: look at the bottom of this file: https://git.savannah.nongnu.org/cgit/nyacc.git/tree/module/nyacc/parse.scm thmprover: mwette: interesting, thanks! daviid: rlb: did that because i don't trust // installation, i mean back then i had problems becauseof that, then opted for the above schema, and then never 'changed', that schema never fails ... rlb: daviid: that was it -- apparently if you have guile and guile-3.0 installed, it won't find the former, even if it's "first" in the relevant vars, and is also guile 3.0. Or perhaps GUILE_PKG just doesn't work for unsuffixed installs. If so, we should definitely mention that in the manual, and even perhaps changing to suffix installs by default.... rlb: s/changing/consider changing/ rlb: i.e. set --program-suffix to -X.Y by default. rlb: wingo: OK, so now that that's working, lokke fails to build with 3.0.7 (was fine with 3.0.5). It fails with: rlb: Syntax error: rlb: unknown location: unexpected syntax in form () rlb: rlb: Ring any bells? daviid: rlb: is there anything you couls 'easily' spot in the NEWS file maybe? daviid: *could rlb: I wonder if I might have an unquoted () somewhere, which is normal clj, but of course isn't in scheme, and maybe I was getting away with it until the new reader or other compilation changes... *: rlb will delve later rlb: daviid: right, and worst case, I suppose I can also try bisecting. rlb: Loading this file causes the crash: https://paste.debian.net/hidden/18ce7c3c/ Do I have something wrong there? rlb: (3.0.7) dsmith: rlb: The #nil is confusing reasoning about '(), is my guess *: rlb checks 3.0.6 and then might see about bisecting the relevant region... rlb: (Though perhaps wingo will just know what it is.) rlb: 3.0.6 does it too rlb: ...automated git bisect doesn't work all that well because it keeps halting on changes to config.rpath, etc. wingo: rlb: humm, i think that is probably an issue with #nil vs '() treatment inside syntax-case... there would appear to be a few of those rlb: I think it may have broken between 3.0.5 and 3.0.6, fwiw, but bisect didn't find the right failure. I'll try again with a hopefully smarter bisect run script later. wingo: it could be that the expander thinks that #nil when wrapped in syntax is the same as () wingo: and before, a raw #nil was never wrapped in syntax wingo: manumanumanu: where does foof maintain upstream match ? wingo: ah in chibi i think wingo: https://github.com/ashinn/chibi-scheme/commit/05c546e38d886a660018c6d9a3c6bec2bcf325d7 fwiw dsmith-work: {appropriate time} Greetings, Guilers rlb: wingo: do I recall correctly that you thought that string ports (i.e. open-output-string, etc.) weren't likely to perform all that well (as compared to just gathering a list of strings/chars and reverse joining them)? hendursaga: I might finally get back into Guile coding - GNU Dico uses it for extensions hendursaga: Can anyone recommend a XML/HTML manipulation library? hendursaga: Would something like SXML be my only realistic choice? Basically I'll toying with the idea of a Dico extension that renders HTML dictionary entries into potentially structured text. pkill9: haunt uses sxml hendursaga pkill9: it lets you produce HTML from s expressions hendursaga: huh I had that in my TO-DO list to look into already... hendursaga: did the project move or has it really been archived? hendursaga: never mind I found it @ https://git.dthompson.us/haunt.git/ rlb: I'm surprised that ./configure --prefix=/some/where produces a guile-3.0.pc file in /some/where that refers to /usr/local rather than /some/where. Is that a bug? rlb: (and as a result /some/where/bin/guile-config compile produces -I/usr/local/... which isn't going to work) *: rlb tries to make sure it wasn't broken make deps after a git tree switch... civodul: rlb: you sure? guile-3.0.pc looks good to me rlb: civodul: it must have been something in my tree. It worked after a git clean -fdx, though I'd have expected the ./configure --prefix... to have clobbered any previous values. rlb: (Looks like maybe it didn't.) rlb: civodul: and what's the right way to get our configure macros to pick up that non-system guile? It looks like setting the PATH, PKG_CONFIG_PATH and ACLOCAL_PATH doesn't work. GUILE_PKG still finds /usr/bin/guile-3.0 instead of /some/where/bin/guile, even though the latter is newer (3.0.7 vs 3.0.5) and is first in the path. daviid: rlb: you need to define, export (in a my-config file) and source it (in a bash sence, like '. my-config' at least these vars, ACLOCAL_FLAGS, PATH, LD_LIBRARY_PATH and PKG_CONFIG_PATH - well, that's what i do :), it works fine for me daviid: rlb: my manually built guile 3.0 and guile-3.0.pc is also correct (it only isstrange wrt version, which says Version: 3.0.6.1-19f38a in the .pcfile, but it actuallyis 3.0.7, no idea why, but guile --version reports the correct version rlb: I have that, but I wonder if the problem is that /some/where/guile/bin/guile(-config) is first in the PATH and newer than /usr/bin/guile(-config) or /usr/bin/guile-3.0(-config), but maybe it's not checking .../bin/guile(-config) when you use GUILE_PKG([3.0]). If not, maybe it should? rlb: i.e. the system guile was configured with a suffix, but the /some/where guile wasn't. rlb: I'd have imagined the autoconf macros might check every guile and suitable guile-X.Y in the path, and take the first one that reports a matching X.Y... rlb: Have to see what they actually do, and we should document this better in the info pages. I might see about a patch if I get time (both to figure it out and to write some docs). rlb: i.e. does it rely on checking guile-config or guile itself, and what's the selection algorithm. daviid: i dothat allthe time, one terminal with theabove vars,then another pointing to2.2 ... rlb: But do all your guile /bin/ commands have a suffix? rlb: (or all not) daviid: none have suffix rlb: And what's your GUILE_PKG() invocation? daviid: http://git.savannah.gnu.org/cgit/g-golf.git/tree/configure.ac?h=devel daviid: GUILE_PKG([3.0 2.2 2.0]) - GUILE3_PROGS([3.0.7]) is only there to make sure, iif it finds guile 3.0, that it is >= 3.0.7 daviid: rlb: fwiw, no debian guile pkg installed 'here', all guile v are manually installed, in diff tree branches, /opt3, /opt2 and /opt emestee: any way to do destructuring bind on a list without resorting to syntax? RhodiumToad: match? emestee: yep thought so ;P RhodiumToad: there's also some stuff in one of the srfi modules for converting lists into multiple values lampilelo: also let-optional and let-keywords, or you could return values if possible and use let-values, call-with-values or receive RhodiumToad: I was thinking of srfi-71, which allows things like (let ((first next rest (uncons-2 somelist))) ...) leoprikler: match is syntax tho RhodiumToad: what binding construct is not syntax? leoprikler: eval >:) emestee: RhodiumToad: oh this could be useful, thanks RhodiumToad: I'm still kind of on the fence about which of the various binding constructs to use for multiple values. RhodiumToad: one can of course import just uncons etc. from srfi-71 without importing its redefinition of (let ...) flatwhatson: it's not the most ergonomic, but srfi-11 is in r6rs and r7rs RhodiumToad: I know about all the options RhodiumToad: let-values is very heavy on the parens flatwhatson: yep, just making the case for the "don't overthink it" option :P *: taylan really doesn't mind the number of parens on srfi-11 rlb: manumanumanu: there's some discussion in the info page https://www.gnu.org/software/guile/manual/html_node/Strings.html -- and yeah, I think substring always shares (substring/copy doesn't). dsmith: sneek: botsnack sneek: :) leoprikler: does anyone else get configure errors when trying to set up Gettext with a pure Guile program? leoprikler: (might be a pretty Guix-specific problem, as gcc might not be visible in dev environments) manumanumanu: So: I have a piece of code that is slow due to call/cc. I want it to be portable, which is why I am not using prompts, but I also want it to not be slow as hell. I translates pretty well to continuation-passing-style, but I could also dump performance problems on other schemes and write it using coroutine generators, of which I have a fast guile implementation and a call/cc portable implementation. manumanumanu: I am leaning towards CPS, but I am not really sure how well that performms. Lots of procedure calls, etc. Does anybody have any experience or any intuition about it? manumanumanu: Right now call/cc is by a pretty fair margin the largest cost for me. leoprikler: manumanumanu: Note, that performance isn't the only thing to consider here. Consider the API changes that would happen if you rewrite all things in CPS (assuming you already have an API). manumanumanu: There will be no API changes since this in well hidden from users. lampilelo: hi leoprikler: I don't think procedure calls are that much of a problem when writing CPS, since the continuations will be in tail position. Also, this is just my ignorance, but how would coroutine generators result in less procedure calls? Do you need to thread your continuations through many procedures? manumanumanu: Well, the cost of prompts would be that of restoring some half-large continuations done in a way guile does pretty well. What I believe I am asking is whether the overhead of the "manual" CPS will be larger. manumanumanu: I am just curious if anybody has any insight. manumanumanu: I could spend the roughly two hours converting my code just to test of course... leoprikler: There is certainly an overhead in the manual method w.r.t. code maintainability. leoprikler: As far as performance is concerned, I don't know, but I do know that Guile transforms your code to CPS under the hood, so it's certainly something to consider. leoprikler: I wonder if there's coroutine benchmarks, that one could implement in Guile prompts/manual CPS. Then you'd have a metric to go by. *: leoprikler → afk manumanumanu: meh... I go down the simple path: The coroutine version preforms admirable. The other schemes get call/cc-coroutines. emestee: i just want it known that trackballs are AWESOME mwette: howdy mwette: manumanumanu: Is there a way you can add a macro front end that uses call/cc or prompts? manumanumanu: mwette: that's what I went with. manumanumanu: But I remember porting (srfi 146 hash) to guile, and it didn't work due to them relying on full continuations. For me it will be fine, but I don't like the idea of incompatibilities manumanumanu: So, guile does copy-on-write for strings, at least when there are shared substrings. But does it hold on to huge strings if I have 50-char substring? leoprikler: probably maybe leoprikler: I don't think it does if you're explicitly copying them though dsmith: ninety-nine guilers are here in the chan dsmith: ninety-nine guilers are here.. dsmith: if one of those guilers should happen to /part dsmith: ninety-eight guilers are here in the chan apteryx: hello! is there a way to programatically retrieve the source code of a procedure? RhodiumToad: in theory there's procedure-source, but I don't see it returning anything other than #f manumanumanu: apteryx: you could define it yourself, if it is supposed to be used in a system where you don't need to retrieve source of built-ins manumanumanu: either using applicable structs where you store the source and the lambda (and some identifier-syntax trickery to make recursive calls fast), or by some hash-table thingie (probably less robust. proceduce equality is a bit weird due to... eh... beta-reduction??) apteryx: RhodiumToad: eh, that's my experience with procedure-source as well RhodiumToad: manumanumanu: I think you can just explicitly set the source property on a procedure, too manumanumanu: even better! :) apteryx: manumanumanu: thanks for the hints RhodiumToad: (set-procedure-property! foo 'source whatever) makes a subsequent (procedure-source foo) return whatever RhodiumToad: at least by default the compiler doesn't seem to set that, I don't know if there's maybe a knob for it manumanumanu: apteryx: if you want to, you could define a module that redefines define to do what RhodiumToad suggests. That would be the best solution. daviid: i've pushed a few important patches to g-golf, overriding some gdk-4 clipboard related functions (methods) and added a clipboard.scm gtk-4 example, to the devel branch - pretty cool the clipboard example ... :) civodul: hmm, can't #:re-export srfi-1 'delete' without getting "overrides core binding" warnings at run time RhodiumToad: shouldn't that be a #:re-export-and-replace ? civodul: ah ha, true! civodul: lemme check civodul: i had forgotten about that one, thanks RhodiumToad! civodul: i was close to being creative and use something other than 'delete' as a syntactic keyword for my macro :-) taw10: manumanumanu: An 'applicable struct' solves a similar problem for me, but I could never find any documentation on how to create them. Do you have any pointers? leoprikler: In GOOPS you can inherit , dunno about C taw10: leoprikler: Thanks. But when creating a new "", where does the procedure body go? civodul: taw10: i don't think applicable structs are documented, but see in boot-9.scm dsmith-work: Morning Greetings, Guilers Zelphir: Hello dsmith tohoyn: hello manumanumanu: taw10: you have to use the low level interface. an example: https://github.com/lloda/guile-newra/blob/ee633920bd779463e43510ed07db17ce296eb85d/mod/newra/base.scm#L179 taw10: civodul, manumanumanu: Interesting, thanks! RhodiumToad: taw10: in goops, you can inherit or stis: heya guilers! civodul: by any chance, does someone have a reader and/or pretty-printer that can deal with comments? wingo: civodul: what do you mean? which returns comments in the result? civodul: wingo: yes civodul: apparently Racket has "special comment" values: https://docs.racket-lang.org/reference/Reading.html wingo: i don't have one but it should be reasonable to build from read.scm civodul: yes, i guess so civodul: i was looking for a quick'n'dirty way to hack something atop 'read' civodul: but it's probably safer to just hack 'read' directly civodul: s/probably/undoubtedly/ :-) dsmith-work: civodul: No Comment civodul: :-) *: wingo has an ,optimize-cps repl command, that prints in a standard-ish form kinda like llvm ir civodul: wingo: oh, that can be handy! dsmith: !since sneek: I've been running for 6 days dsmith: Ur? dsmith_: !seen dsmith: !uptime sneek: This system has been up 6 weeks, 21 hours, 55 minutes dsmith_: sneek: botsnack sneek: :) dsmith_: !uptime sneek: This system has been up 6 weeks, 22 hours, 1 minute dsmith_: !since sneek: I've been running for 52 seconds dsmith: !since sneek: I've been running for one minute and 3 seconds unknown_lamer: dsmith: so I guess adding multi-server support to sneek *really* would have been a waste of time ha unknown_lamer: rip freenode dsmith: unknown_lamer: Heh. Yeah. Gone gone gone. unknown_lamer: 20y 29w apparently since I registered and the day it died *: unknown_lamer is getting old now dsmith: Ya. #guile had about 12 users then dsmith: Not sure why ! commands are not working from my work nick *: sneek yawns sneek: Remember, the S in IoT is for Security dsmith: https://isfreenodedeadyet.com/ dsmith: sneek: seen rotty sneek: rotty was last seen in #guix 3 months ago, saying: hmm, this is qemu (via libvirt/virt-manager). dsmith: sneek: test chrislck: Wednesday greetings dsmith-work: UGT Greetings, Guilers dsmith-work: sneek: botsnack sneek: :) dsmith-work: !uptime sneek: This system has been up 6 weeks, 1 day, 14 hours, 3 minutes dsmith-work: !since sneek: I've been running for 16 hours apapsch: Hi, what is the recommended way to copy from port to port? I have a input port from (pipeline) result and want to write to a file. Currently I (get-bytevector-n!) in 8KB chunks and then (put-bytevector) to the output port, though it seems rather verbose leoprikler: that is indeed what you're supposed to do unless you somehow want line-based stuff leoprikler: see the Guix download logic as well ;) apapsch: alright, thanks :-) i think i'll go with get-bytevector-n without the !, seems a bit easier to use. guile docs don't mention that it returns an eof-object, while the r6rs doc says so. is it a docs issue or does the impl differ from r6rs? dsmith-work: apapsch: If you are willing to go linux-specific, sendfile and copy_file_range move data around without copying to userland. dsmith-work: https://man7.org/linux/man-pages/man2/sendfile.2.html dsmith-work: https://man7.org/linux/man-pages/man2/copy_file_range.2.html apapsch: dsmith-work: thanks, but that's going even deeper into the weeds :-) i'll make a mental note for the optimization on a rainy day dsmith-work: Guile does have sendfile. Often used in web servers. copy_file_range is new to me. Looks very interesting. apapsch: indeed interesting. though it requires a count parameter, which I can't know beforehand (the input port returns the xz output from the pipeline) wingo: miscompilation bug has me delving in the guts of "match" :/ manumanumanu: haha. how much syntax rules can you take? wingo: omg wingo: (use-modules (srfi srfi-9) (ice-9 match)) wingo: (define-record-type wingo: (make-pair head tail) wingo: pair? wingo: (head pair-head) wingo: (tail pair-tail)) wingo: (define (test x) wingo: (match x wingo: (($ (x ...) (x ...)) wingo: (pk x)))) wingo: what do you think (test (make-pair '(1 2 3) '(1 2 3 4))) does wingo: aaaaahhh!!! manumanumanu: no guess. wingo: ok this one is simpler wingo: (use-modules (ice-9 match)) wingo: (define (test x) wingo: (match x wingo: (((x ...) (x ...)) wingo: (pk x)))) manumanumanu: I think I know what it SHOULD do. *: dsmith-work really needs to lean match sneek: Yes please wingo: run as (test '((1 2 3) (1 2 3 4))) manumanumanu: oh yes wingo: am i misunderstanding something???? wingo: i thought the two "x"'s in the pattern would unify manumanumanu: yup. manumanumanu: that shouldn't match? wingo: consider (match-lambda ((x . x) x) (_ #f)). returns false unless a pair and car and cdr are equal? wingo: but (match-lambda (((x ...) (x ...)) x) (_ #f)) -- should return false unless a 2-element list and first and second elements are the same list wingo: but not the case apparently?? manumanumanu: wingo: (chibi match) does the same manumanumanu: Maybe I should continue my work to port Trivia from CL... wingo: does the same as guile you mean? manumanumanu: racket match fails: (match x ((list (list x ...) (list x ...)) x)) manumanumanu: yes manumanumanu: and the code is the same. manumanumanu: I would guess wingo: right i think we use foof's match so it would make sense that chibi & guile's behavior has the same bug manumanumanu: That kind of syntax-rules is no fun to debug. I know. I wrote this: https://git.sr.ht/~bjoli/goof-loop/tree/master/item/goof-impl.scm#L120 manumanumanu: ocaml does the correct thing as well. wingo: this causes a miscompilation, as you might well imagine :/ manumanumanu: I thought you thought this was a result of a miscompilation, which is why I compared to chibi. wingo: seems to be an artifact of the optimizations for (p ...) -- match.upstream.scm:512 wingo: because ((x . _) (x . _)) does correctly unify x manumanumanu: foof hangs in #scheme, btw wingo: manumanumanu: because the compiler uses match, it actually causes a miscompilation :) manumanumanu: That is better than "We have a miscompilation. it manifests itself in (ice-9 match)", though... wingo: marginally :P dsmith-w`: Morning Greetings, Guilers dsmith-w`: !since dsmith-work: !sinc dsmith-work: !since dsmith-work: !uptime dsmith-work: sneek: botsnack sneek: :) leoprikler: sneek: seen dsmith-work sneek: dsmith-work was last seen in #guile one minute and 43 seconds ago, saying: sneek: botsnack. dsmith-work: !uptime dsmith-work: Odd leoprikler: what's !uptime for? dsmith-work: leoprikler: Shows $(uptime -p) dsmith-work: Hmm. All the bang command seem broke dsmith-work: commands manumanumanu: wingo: I ha manumanumanu: wingo: sorry; I have a 4-line patch to implement definitions in cond and case clauses, by switching (begin ...) => let in boot-9.scm. Would that be of interest, or is that a no-go? manumanumanu: 3-line, sorry. manumanumanu: regarding prior art in the area: this is what racket does for cond and case clauses. begin is the only form with a body that actually warns about define in expression context. manumanumanu: Guh... I forgot when and unless... awaiting further instructions manumanumanu: (I am back on my phone, that's why). ArneBab: avp: nice! flatwhatson: daviid, raghavgururajan: i've got guix gtk4 built, but g-golf example aborts with "GLib-GObject:ERROR:../glib-2.68.0/gobject/gbinding.c:898:g_binding_class_init: assertion failed: (gobject_notify_signal_id != 0)" daviid: flatwhatson: oh nice, the gtk-4 build - never seen that error, but let's investigate daviid: flatwhatson: so, it very much feels like not a g-golf bug (everything works fine here), but i'd be happy to (try to) help - 1st, does gtk-4 has a test-suite, does itpass? daviid: flatwhatson: i bet you see the same error with both example? flatwhatson: daviid: yes same with both daviid: flatwhatson: right, something went wrong either with the build, or the executionenv ... flatwhatson: i agree this is most likely not g-golf's fault, it might be a problem with gtk4 package or my precarious setup to get this far :) daviid: flatwhatson: justr asked on #introspection for somehint,including ifthere is a 'better' channel (then #introspection) for quiz related to building gtk flatwhatson: raghavgururajan mentioned he needed help getting gtk4 tests working, so that is probably the best way forward flatwhatson: yeah, tests are currently disabled for this gtk4 build daviid: flatwhatson: ok, i thing the very first thing to do is making surethe gtk-4test suite pass daviid: flatwhatson: i'll let you know if/when #introspection answer ... meanwhile, see if you can join one of the gnome chamnels and ask for help - https://wiki.gnome.org/action/show/GettingInTouch/IRC?action=show&redirect=Community%2FGettingInTouch%2FIRC daviid: #gtk i guess #gtk (Matrix or irc) - GTK+ toolkit and GLib channel flatwhatson: sure, thanks :) daviid: flatwhatson: irc.gnome.org, notlibera.chat daviid: flatwhatson: tx you, i think it is extremely important to get gtk-4 in guix... flatwhatson: daviid: yep absolutely! i need to put it down for a bit but will keep chipping away daviid: tx you, raghavgururajan and who's involved of course ... raghavgururajan: flatwhatson and daviid: Thanks for working on this. :) *: raghavgururajan joins #gtk on GIMPnet taylan: sneek: hello leoprikler: raghavgururajan: Your GTK 4 stuff probably gets mixed with the older GLib/GTK stuff from the environment. Sometimes purifying helps, but not always. stis: Tja guilers! manumanumanu: Tjabba! manumanumanu: stis: what's up? stis: answering the question of how I would like to interact with data tables to replace excell stis: manumanumanu: ^ ^ manumanumanu: For you own sake, or for the public good? manumanumanu: because the later case, I hate to tell you: excel is going nowhere :P stis: probably just mine ;-) as I'm an outlier, but I do hate excell stis: cell based formulas is soo overrated stis: just lead to spaghetti hell stis: and I basically never hit use cases where cell based formally shines (on the spot editing of large datashetts with instant updates) leoprikler: org-mode tables are nice leoprikler: if you really need spreadsheets tho, just use libreoffice instead :P apteryx: is there something available in guile to compute md5 checksums? apteryx: looking at https://www.gnu.org/software/guile/libraries/ there's 'hashing', but the link it points to is dead apteryx: looks like it may have been absorbed into https://weinholt.se/industria/industria.html daviid: sneek: guile-software sneek: guile-software is at http://sph.mn/foreign/guile-software.html daviid: apteryx: ^^ lampilelo: apteryx: maybe guile-gcrypt? gcrypt has md5 so i would guess the guile wrapper would expose it too lampilelo: i use a custom wrapper for hashing functions from nettle for my project lampilelo: yeah, guile-gcrypt has md5 apteryx: lampilelo: looks like yes! thanks apteryx: daviid: thanks for the link *: wingo finally writes a proper dump-cps routine dsmith: lampilelo: That's about the most concise explanation I've seen. dsmith: It not a hard concept, but sometimes hard to explain dsmith: sneek: modules? dsmith: sneek: remember modules is (use-modules (foo bar baz)) means to search for the baz in the file foo/bar/baz.scm, relative to any dir in the path. sneek: So noted. dsmith: sneek: modules? dsmith: sneek: what is modules? dsmith: sneek: modules is (use-modules (foo bar baz)) means to search for the baz in the file foo/bar/baz.scm, relative to any dir in the path. sneek: Okay. dsmith: sneek: what is modules? sneek: Someone once said modules is (use-modules (foo bar baz)) means to search for the baz in the file foo/bar/baz.scm, relative to any dir in the path. dsmith: sneek: forget rememeber modules sneek: Okay. dsmith: sneek: forget modules sneek: Okay. dsmith: sneek: modules is (use-modules (foo bar baz)) means to search for the module baz in the file foo/bar/baz.scm, relative to any dir in the load path. sneek: I'll keep that in mind. dsmith: sneek: modules? sneek: Someone once said modules is (use-modules (foo bar baz)) means to search for the module baz in the file foo/bar/baz.scm, relative to any dir in the load path. daviid: dsmith: great! i would say '... search for the module defined as (define-module (foo bar baz) ...) in the file ...' daviid: dsmith because 'beginners' often think (define-module (baz) ...), (use-modules (foo bar baz)) or (define-module (foo bar baz) ...), (use-modules (baz)) ... will 'also' work ... daviid: leoprikler: when time permets, could you kindly update the gtk gitlab g-golf 'page' to mention that g-golf also works with guile 3.0 (>= 3.0.7), thanks! daviid: *permits daviid: and Gtk-4.0 if 'possible' emestee: there's no guile on Windows, correct? leoprikler: Guile 2.2 has a MinGW and Cygwin port IIRC, dunno about Guile 3.0 but it's at least WIP leoprikler: daviid: https://gitlab.gnome.org/leoprikler/gtk-web/-/jobs/1344379 currently building, let me know if there's an issue leoprikler: gtg now dsmith: sneek: forget modules sneek: Consider it forgotten. dsmith: sneek: modules is (use-modules (foo bar baz)) means to search for the module defined as (define module (foo bar baz)) in the file "foo/bar/baz.scm", relative to any dir in the load path. sneek: I'll keep that in mind. flatwhatson: sneek: it should be define-module flatwhatson: sneek: botsnack sneek: :) dsmith: Bah! dsmith: sneek: forget modules sneek: Okay. dsmith: sneek: modules is (use-modules (foo bar baz)) means to search for the module defined as (define-module (foo bar baz)) in the file "foo/bar/baz.scm", relative to any dir in the load path. sneek: Okay. dsmith: flatwhatson: Thanks dsmith: daviid: Thanks too! chrislck: sneek: botsnack sneek: :) lampilelo: it's kinda amusing kitzman: so another beginner question - (sxml match) - is there an (undocumented) way of matching elements, but not ordered? it seems so obvious that the matching should not care about ordering... kitzman: i guess sxml fold... but still, it's a bit unexpected manumanumanu: kitzman: what do you want to do? manumanumanu: pre-post-order is my swiss-army-bazooka of choice for most things kitzman: i'm trying to process an atom feed. the tags are not in the same order for every feed manumanumanu: oh, sxpath maybe? kitzman: apparently foldt checks if it's an atom. i was trying to write my own fold function, which instead of (atom? ...) would have a match kitzman: that would work indeed manumanumanu: kitzman: https://docs.racket-lang.org/sxml/sxpath.html is probably the best documentation manumanumanu: and is not racket specific kitzman: seems to work for now, thank you. panicked a bit manumanumanu: np. manumanumanu: glad to help! manumanumanu: ArneBab: just FYI, I am making (syntax define) compatible with 3.0 and expanding it to be complete with when and unless. I did some restructuring to allow making shims for srfi-71, 11, 8 and (ice-9 match). manumanumanu: In guile3, you get definitions in _all_ expression contexts with no penalties. in guile2 you get definitions in expression context that is as slow as letrec :) manumanumanu: rlb: the above might be useful for lokke. I am pushing it later tonight manumanumanu: to the repo at https://hg.sr.ht/~bjoli/guile-define rlb: manumanumanu: interesting - thanks. ArneBab: manumanumanu: very cool! kitzman: hm, what is the general consensul on GOOPS vs srfi-9 records? i would go with the latter because it's schemish kitzman: sensus* kitzman: i guess one would only need goops when needing inheritance manumanumanu: I would go with goops when I need generic methods leoprikler: Who needs records, when you can have closures? :P leoprikler: Just pick whichever abstraction suits your needs and feels helpful :) manumanumanu: otherwise I would go with r6rs records if I need inheritance. I usually go for srfi-9. kitzman: nice, i'll do records because i don't need anything specific for now manumanumanu: r6rs records also supports the nongenerative clause which is pretty nice to use when you are doing repl thingies and have data defined in the repl. kitzman: writing yet another rss news aggregator/processor (i.e: one can configure it - you want a desktop notification? you want mails a-la mailing list? you want mails to go to your own nntp server?) manumanumanu: But I might just be doing things in a bad style :) kitzman: seems like a handy feature kitzman: a bit of an uneducated question - does the dynamic wind "out" execute even if errors happen? leoprikler: you mean stuff like scm_dynwind_free? manumanumanu: in case of (error "..."): no avp: FWIW, I managed to write my first Guix package -- for Guile-SMC: https://github.com/artyom-poptsov/guile-smc/blob/master/guix.scm daviid: leoprikler: ok tx! kitzman: decided to try out (web client). for a request, wouldn't it be sufficient to do (read-response-body request) ? the port is closed and there's an error getting thrown because of that kitzman: the port is open if i check it, but probably when i finish reading, it closes kitzman: oh #:streaming? ^^ daviid: raghavgururajan, flatwhatson great! good work on guix gtk-4 pkg and good luck ... when you have a working pkg, you may try g-golf examples/gtk-4/*.scm and let me know rlb: manumanumanu: I've been away from that work for a bit, but assuming I get back to it, I think one of the key decisions we'll need to make is whether we "just want utf-8 strings" for more or less transparent interop, etc. That's what I have, though there are two physical "types" (underneath), ascii vs non-ascii. The former can be (and is) indexed directly (and may end up being pretty common for now), but of course both are utf-8. In rlb: that world, I suppose you might use switch to the "immutable text" srfi when you need "more". rlb: manumanumanu: and of course aside from "transparent/possibly-less-expensive" interop, we might also have better perf in some cases given likely optimized versions of utf-8-related code, the ability to just use bulk memcpy, etc. Dunno. rlb: (cache locality), but all of this is tradeoffs everywhere you look... emestee: is there a library for finite state machines I should use instead of reinventing the wheel? leoprikler: emestee p sure guile-fsm exists leoprikler: okay, maybe not, but there is this thing for guile 2.2: https://github.com/artyom-poptsov/guile-smc emestee: yes that's a little overkill for what I'm doing emestee: I havent found anything else emestee: I guess I'll implement it with ice-9 match and be done with it ;P leoprikler: if it's just for string matching you can also use pegs emestee: hmm, is the use of [ frowned upon? emestee: it seems popular in racket but seldom in Guile code leoprikler: It's generally a matter of taste imo. leoprikler: I personally don't find the arguments for [ very convincing emestee: match patterns are easier to grok, for me leoprikler: for match patterns, i'd really use ( emestee: I am developing normal lisper brace vision, yeah :D leoprikler: Also through my investigations I've learned that [] is not valid R5RS, though it is valid R6RS. emestee: this is due to absence of support in the reader I imagine? taw10: Rainbow parentheses in the editor seem to solve the same problem better, for me at least. Once I got them set up, I forgot all about [..] emestee: yup just set it up 10 minutes ago manumanumanu: I think many see it as a waste of matching pairs. [] could be much more manumanumanu: A shortcut for https://hg.sr.ht/~bjoli/megacut/browse/readme.txt?rev=tip maybe? :) manumanumanu: [+ %2 (* %1 2)] => (lambda (%1 %2) (+ %2 (* %1 2))) manumanumanu: the infix syntax srfi already stole { ... } lampilelo: that would be really cool abcdw: hi guile! Why (display '(1+ 2)) produces (#{1+}# 2) instead of (1+ 2) ? sneek: Welcome back abcdw, you have 1 message! sneek: abcdw, ixmpp says: would be nice to be able to `Include ` in ssh/config... im not able to use that module right now cause i need that emestee: abcdw: 1+ is a procedure with special reader syntax abcdw: emestee: Make sense. Is there a way to print a sexp without enclosing 1+ in #{}# ? leoprikler: you could cheat and use symbol->string, but that's dangerous abcdw: leoprikler: I can't modify original sexp, I need something like (print-disable 'r7rs-symbols), but for the #{}# pizzapal: hey schemers pizzapal: can you use relative paths for module load paths? pizzapal: hm, using an absolute path doesn't work either. i keep getting "While compiling expression: no code for (my-module)" when i try to import it with (use-modules)... but if i use (load "./my-module.scm"), it works dsmith: pizzapal: Normally "." isn't in the load-path. pizzapal: i added the directory with add-to-load-path. so this is what works and what doesn't: https://paste.gnome.org/pko18d7z6 pizzapal: the file shown in the paste is "physics.scm", so it is just one directory up from the one that i'm trying to load pizzapal: and i have `(define-module (box2d))` at the top of guile-box2d.scm pizzapal: oh shoot, i think i see what the problem is pizzapal: nope, i guess not pizzapal: so this works: https://paste.gnome.org/pqic50lng pizzapal: but (use-modules (box2d)) only works if i first evalulate the buffer, and then enter it in the repl *: pizzapal scratches head, picks nose, eats booger lampilelo: i mostly use (add-to-load-path (dirname (current-filename))) lampilelo: of course it won't work in the repl pizzapal: should i just install it to site packages? the guile-box2d.scm file is in development too, but i won't make any changes to it in this context lampilelo: for development i use (add-to-load-path "/full/path/do/source/dir/"), modules relative to that path should load fine lampilelo: s/do/to/ lampilelo: also you could use GUILE_LOAD_PATH env variable pizzapal: yeah, i will try the env var pizzapal: yeah, used the absolute path and all, i get the same thing "no code for module" lampilelo: how is the module defined? pizzapal: just like `(define-module (box2d))` at the top pizzapal: and then i use define-public for my public defs lampilelo: afaik the file that defines a module should be named the same as the module itself pizzapal: oooooooooh... pizzapal: yup, that was it, haha! pizzapal: thank you!!!!1 lampilelo: yeah, (use-modules (foo bar baz)) means to search for the module baz in the file foo/bar/baz.scm, relative to any dir in the load path pizzapal: i figured it just looked at the first line of the file pizzapal: but i suppose they could be compiled, so it couldn't do that then daviid: [my (brand new laptop :( kb spacebar only half works ... sorry] leoprikler: hmmm… #:search-ltdl-library-path?=#t by default, so it ought to work as before daviid: ok,so i added :$abs_top_builddir/libg-golf/.libs and it fixes the problem, but i think i 'shouldn't have to', no big deal daviid: leoprikler: in (system foreign-library), it seems it adds .libs, not sure daviid: (augment-ltdl-library-path path) ... (cons* dir (in-vicinity dir ".libs") ... leoprikler: maybe that code path is not triggered for some weird reason? daviid: andinthecomment above, "So as a stopgap solution, we add a ".libs" subdir to the path for each entry in LTDL_LIBRARY_PATH, in case the .so is there instead of alongside the .la file. daviid: leoprikler: probably not triggered, yes dsmith: sneek: later tell dsmith-work: just a test sneek: Okay. dsmith: sneek: later tell dsmith-work just a test sneek: Got it. hugo: Is there a directory-watcher -> live-reloader of guile modules available? dsmith: Ahh. Some people are using a ":" and that's seen as part of the nick. daviid: flatwhatson: i pushed a fix, could you (when times allow) pull (the devel branch), and try to build g-golf in guix without 'your fix' ... and let me know ... tx! dsmith: sneek: later tell dsmith-work, comma test sneek: Got it. dsmith: And the "," gets added too. leoprikler: sneek seems to have troubles parsing commands leoprikler: is later tell dos still a thing? dsmith: sneek: later tell dsmith test! sneek: Will do. dsmith: ok sneek: Welcome back dsmith, you have 1 message! sneek: dsmith, dsmith says: test! dsmith: leoprikler: Working. But not as cleanly as I'd like. dsmith: If you "later tell nick[:,]", It also is including the "," or ":" in the saved recipient. :( dsmith: Well any non-whitespace I guess. leoprikler: I actually meant stuff like leoprikler: sneek later tell dsmith later tell dsmith hi sneek: Okay. leoprikler: hmm leoprikler: sneek tell dsmith hi sneek: dsmith, leoprikler says: hi leoprikler: sneek tell leoprikler later tell dsmith hi sneek: Okay. leoprikler: welp leoprikler: it works FSVO works dsmith: heh sneek: dsmith, you have 2 messages! sneek: dsmith, leoprikler says: later tell dsmith hi sneek: dsmith, leoprikler says: hi dsmith: I should probably ensure that remembered nicks are only from the set "][a-zA-Z0-9_{}\`|-" leoprikler: can IRC nicks contain Unicode? dsmith: Well. Didn't used to. And the []{}` etc was becuse they are accent chars on some european encoding. dsmith: rfc1459: "Because of IRC's scandanavian origin, the characters {}| are considered to be the lower case equivalents of the characters []\, respectively." dsmith: dsmith: /nick d% dsmith: dsmith: Hmm. flatwhatson: daviid: yep it fixes the dynamic loading of libg-golf.so, thanks! dsmith: can I send a λ daviid: flatwhatson: ok, great, tx as well dsmith: Yes flatwhatson: i still need to set LD_LIBRARY_PATH to load libgirepository-1.0.so and libglib-2.0.so, but i think that's a problem unique to guix flatwhatson: how would you feel about including a guix.scm in the project? leoprikler: IIRC there exists a g-golf package upstream and it probably uses git as origin leoprikler: so you can just inherit from that package most of the time daviid: flatwhatson: yes, to the first sentence, but for the second, i prefer as things are leoprikler: (I use a similar hack in Tsukundere's guix.scm because I'm too lazy to maintain two separate versions of it.) flatwhatson: my reasoning is that the project-local guix.scm can evolve with the latest version, as dependencies or packaging might change over time flatwhatson: at a point when the upstream pkgdef is updated, they can reference the latest one from the project flatwhatson: it makes it easier for people who want to jump in testing the latest from master, they don't all need to individually work out how to package the latest again (or more likely just give up) daviid: leoprikler: not in g-golf, but in nomad maybe daviid: anyway, i'll rely on the guix contributors and the guix g-golf pkg, but tx leoprikler: flatwhatson agree in principle, perhaps disagree on the specifics, but it's always the package maintainers' choice flatwhatson: oh totally. i'm still working out what "guix everywhere" development looks like, i understand it's still a bit radical daviid: leoprikler, flatwhatson how far isguix from having a gtk-4 and deps pack? daviid: *pkg daviid: just curious, no 'pressure' flatwhatson: i honestly have no idea, haven't touched gtk packaging before daviid: ok flatwhatson: tempted to have a go at it so i can run your examples, or failing that maybe trying to port them to gtk3 daviid: flatwhatson: the search-bar example won't work in gtk-3, the searchentrysignals changed, i think apteryx: Is Guile able to FFI with C++ shared libraries? wingo: not really. if you know the symbol mangling and abi mapping you can hack some things leoprikler: daviid: It's at least one c-u away, though work is still done on wip-gnome leoprikler: IIRC raghavgururajan is working on it atm lampilelo: apteryx: swig can create a wrapper of c++ code for guile, i've never tried it with c++ so i don't know how well it works, but may be worth a try lloda: the schmutz lib that leoprikler linked to looks good lloda: i'd probably adopt that if i didn't have my own ancient wrappers apteryx: wingo, lampilelo thanks for the hints apteryx: lampilelo: hmm, http://www.swig.org/Doc4.0/Guile.html "SWIG works with Guile versions 1.8.x and 2.0.x.". apteryx: seems 2.2 is supported now (https://github.com/swig/swig/pull/1232/files). I'd have to try and see :-) lampilelo: apteryx: maybe they didn't update the page but it works for me fine with guile 3 apteryx: Seems a high value piece of software if it allows Guile to tap into any C++ library. apteryx: lampilelo: nice! pkill9: yea sounds like a coollib dsmith-work: Happy Friday, Guilers!! sneek: dsmith-work, you have 3 messages! sneek: dsmith-work, dsmith says: just a test sneek: dsmith-work, dsmith says: just a test sneek: dsmith-work, dsmith says: comma test raghavgururajan: daviid and/or flatwhatson: Gtk v4 (https://issues.guix.gnu.org/48554). Looking for help with enabling/fixing tests. flatwhatson: thanks raghavgururajan i'll have a crack over the weekend raghavgururajan: flatwhatson: Thank you! manumanumanu: How are guile strings represented internally? manumanumanu: it seems very much like vectors of chars from a performance pov. dsmith-work: manumanumanu: See the comments in libguile/strings.h dsmith-work: manumanumanu: Somestimes it's bytes and sometimes it's wide chars, depending. manumanumanu: huh. manumanumanu: thx manumanumanu: I am testing an immutable string library of my own design, and it is about half as fast on narrow strings, and anywhere 2-4x slower on wider ones. But I suspect it is a lot more compact in memory manumanumanu: but then, it is implemented in scheme manumanumanu: random access is of course a lot slower, even though it is technically O(1). dsmith-work: manumanumanu: Recently rlb was looking into changing string internals. manumanumanu: (internal representation is utf8 in a bunch of smaller bytevectors). manumanumanu: exciting! manumanumanu: rlb: what kind of thoughts did you have? dsmith-work: manumanumanu: http://logs.guix.gnu.org/guile/2021-03-05.log manumanumanu: dsmith-work: not that one, but I found the one you meant. dsmith-work: manumanumanu: yey! (the searching of the logs seems a bit wonky) manumanumanu: rlb: regarding string representation: how about storing strings as chunks of bytes? Any wide string part can be a wide type, whereas any narrow type can be represented as a regular char array. You'd waste less space than with the current "whole-string-is-wide" approach for many western languages. flatwhatson: lampilelo: i'm fairly sure std::function must not be bigger than a pointer, so function pointers are unboxed but capturing lambdas always allocate daviid: tohoyn, and g-golf 'followers', I made subtantial changes to the way g-properties are defined, added the GStrv GValue boxed type (used in css-classes properties), then g-golf now also defines(imports) GObject Binding, BindingFlags and last but not least, GObject methods - so it is now possible to bind properties daviid: I also added an examples/gtk-4 dir, with a hello-world.scm, a search-bar.scm and their respective screenshot examples - all this pushed to the devel branch daviid: tohoyn: whenever you have sometime, please pull the devel branch and try ... let me know ... flatwhatson: daviid: is gtk4 required then? i got it built with guix, but fails at runtime because i only have gtk3 flatwhatson: Typelib file for namespace 'Gtk', version '4.0' not found daviid: flatwhatson: no, it is not required at all, you can even use gtk-2 if you wish daviid: but the examples i added are gtk-4 based daviid: make check (still) refers to clutter and gtk-3, i hope i cna clean that in the future - but building g-golf does not requireanything but gi, glib andgobject flatwhatson: i had to do some nast LD_LIBRARY_PATH to get it to compile, otherwise dlopen complained about missing libraries, but I think that's a guix problem not yours daviid: flatwhatson: there is a g-golf guix package already flatwhatson: yes but it doesn't build your latest devel version daviid: ah, could be aproblem here as well then daviid: i didn't run make distcheck will do daviid: flatwhatson: make distcheck passes here daviid: fwiw daviid: flatwhatson: one change that might be 'culprit' is the develbranch changes libg-golf flatwhatson: daviid: here's my efforts: https://paste.gnome.org/pmc8ehmdy daviid: flatwhatson: note that (you probably knowbutjust to make sure) examples are distrib, not compiled, otherwise yu'd have to have gtk-4 - which is nnot meant to be... flatwhatson: yeah, i hoped to try the examples but packaging gtk4 for guix is too much for today... ':D daviid: flatwhatson: sure, but this libg-golf.so problem, could it be that my am/guile.mk is incorrect? flatwhatson: i don't know sorry, autotools are still dark magic to me flatwhatson: oh i see, maybe pre-inst-env should be setting LD_LIBRARY_PATH appropriately daviid: hum, but it does set it daviid: not sure if 'appropirately' though flatwhatson: daviid: patch for the g-golf.so: https://paste.gnome.org/ptrkc39kb lampilelo: flatwhatson: capturing lambda by itself doesn't allocate, std::function boxes it if it doesn't fit it's internal storage flatwhatson: looks like that builds into g-golf/.libs now, though i'm not sure who's responsible for that path lampilelo: lambda's size is known at the compile time flatwhatson: i removed the src path, i don't think that will ever be needed for LD_LIBRARY_PATH daviid: this sounds a bit strange to me, but i'll look into this, not exactly now though, but tx flatwhatson: lampilelo: yes, but at least for gcc i think std::function<> must be the size of a pointer? so in practice only non-capture lambdas or function pointers (basically the same thing) can be stored without allocation? lampilelo: std::function (on gcc) is 32 bits, if it can fit all the data it stores it locally lampilelo: iiuc flatwhatson: my bits/std_function.h has sizeof(_Nocopy_types), a union of various pointer types, maybe 32bits in practice flatwhatson: i assumed it would always need to store a function pointer there, but maybe lambdas are smarter than that flatwhatson: it would be nice if [this]{ my_method(); } would fit without allocation! lampilelo: we should probably look at the standard, not the code, but i'm pretty sure your example would be put into std::function without allocation, look at the _Base_manager::_M_init_functor - it uses placement new for data that fit into _Any_data union (which has the size of _Nocopy_types) lampilelo: also _Base_manager::__stored_locally lampilelo: and i think the lambda from your example is 16 bytes lampilelo: hmm, it's 8 bytes flatwhatson: oh right, std::function is 32 *bytes* lampilelo: ah, sorry, i misspelled it lampilelo: i thought about bytes and didn't notice we both wrote "bits" flatwhatson: thanks though, til :) lampilelo: these nooks and crannies of c++ can get confusing, i'm trying to make sense of them lloda: lampilelo: np, i couldn't use that code directly since i already have a crummy wrapper that does scm2c etc. I'll have to adapt it. But the idea behind the code is useful to me sneek: Welcome back lloda, you have 1 message! sneek: lloda, lampilelo says: sorry for the faulty code i gave you earlier, this should be much better: https://paste.debian.net/1200610/ lampilelo: we should make a library for c++, preferably in guile's source tree lampilelo: because right now everyone needs to reinvent the wheel lloda: i agree lloda: at the very least have some pointers in the manual lampilelo: that's for sure dsmith-work: Thursday Greetings, Guilers lloda: i simplified a bit and put it in a working example lampilelo https://paste.debian.net/1200733/ lloda: still not sure how it fits my use case, but having something like this in Guile would be nice leoprikler: fwiw there are already some Guile compat libraries out there (IIRC schmutz is one of them) lampilelo: lloda: nice, i thought about moving dest_t definition to the top of the function to simplify it but now i don't have to do it myself! what is also useful is adding "typename = std::enable_if_t>" to destructor_wrapper's template parameters list, just to be sure that destructor_wrapper can be safely free()'d lloda: i use requires now :-D lampilelo: yeah, maybe i should switch to c++20 in my project too lampilelo: lol i copied schmutz to search for it and then proceeded to type it by hand in the search bar lloda: i'm still using smobs so lampilelo: lloda: hmm... after i uploaded the last paste i made my make_destructor destroy passed objects in the reverse order for consistency, your simplified version can't do that, is this something that could be an issue to you? lloda: since you have to pass the args to scm_dynwind_cpp_destroy, i could just pass them in reverse order lloda: but it's true that the comma fold doesn't give you that choice lloda: also what happens if you declare the unwind handler several times, can one do that? lloda: like A a; scm_dynwind_cpp_destroy(a); B b; scm_dynwind_cpp_destroy(b); ... manumanumanu: Whoa! That tailify branch seems awfully web-friendly manumanumanu: it even says so in the source comment... I should really read stuff before opening my mouth avp: Hello Guilers. I just released Guile-INI 0.2.0: https://lists.gnu.org/archive/html/guile-user/2021-06/msg00036.html lampilelo: lloda: yes, it will work and they will run in the reverse order they were registered in, just like scm_dynwind_free, they just get added to a dynstack and since the data associated is allocated through the gc it should be completely safe (iiuc ofc; i tested it by interspersing scm_gc() between the calls to scm_dynwind_cpp_destroy and it was fine, maybe it needs some real life testing to be sure though) lampilelo: avp: will you publish your libraries on guix? they are not on the list: https://www.gnu.org/software/guile/libraries/ daviid: lampilelo: guile s/w list is here - http://sph.mn/foreign/guile-software.html amirouche: re tailyfication: It looks much better than mine. daviid: flatwhatson: this .libs 'problem' seems to only occur while using guile 3.0(.7) - and looking at guile's meta/uninstalled-env.in LTDL_LIBRARY_PATH is (alsonot) adding .libs, 'just' doing the usual "${top_builddir}/${dir}" - only DYLD_LIBRARY_PATH is, in that file, but that is for macos iiuc daviid: guilers, any one has experienced a foo project, that has a libfoo lib that it needs to build foo ... using 3.0.7, that 'also' fails? daviid: in a g-golf git clone, git clean -dxf, ./autogen.sh, ./configure --prefix=/opt2 --with-guile-site=yes, make uninstall (to make sure it won't find libg-golf.so from a previous install), make pass leoprikler: I'm not quite if I parsed that correctly, but I think you're encountering some trouble with the change in dynamic library loading. leoprikler: In particular, Guile 3.0.7 no longer uses libtool, so the inner workings are a little different daviid: but using guile 3.0.7, git clean -dxf, ./autogen.sh, ./configure --prefix=/opt3 --with-guile-site=yes, make uninstall (to make sure it won't find libg-golf.so from a previous install), make boum - https://paste.debian.net/1200795/ daviid: leoprikler: I think it should still find libs 'as before', though I amhappy to temporarilylocallypatch g-golf lispmacs[work]: (drain-input (uart-in-port uart)) lispmacs[work]: oops, wrong emacs window dsmith: heh lispmacs[work]: I want to be able to try to read a char from an input port, but if nothing is available (say, after 10ms) then return false or throw an error or something. I found section 6.12.13 Non-Blocking I/O but was wondering if that is the simplest way to do it lispmacs[work]: I'm just trying to clear garbage out of an input stream before sending commands to the output stream lispmacs[work]: I thought drain-input might be what I was looking for, but it doesn't work dsmith: select with a timeout should work on a serial port, shouldn't it?' ft: It does. I've done something like this: https://gitlab.com/ft/chip-remote/-/blob/master/scheme/chip-remote/io.scm#L73 dsmith: There are also some funky tty ioctls I think. From before sockets I imagine. ft: Yeah, there's stuff like VTIME in termios. But I would rather use select. lispmacs[work]: dsmith: "select"? ft: ",d select" at the guile repl. lispmacs[work]: okay, taking a look at it in the manual lispmacs[work]: I've read the description of `select' but am not understanding how to use it to be honest lispmacs[work]: so, I could put the input port as the READS parameter, with a usecs timeout ft: You give it lists of ports that you're interested in reading and writing, plus a timeout. When it returns either you can do one of those things with one of those ports, or the timeout triggered. ixmpp: hey lispmacs[work]: ft: what happens if I timeout? ft: lispmacs[work]: You can take a look at that io-read function I linked to. It basically does that. ft: It returns an empty list. lispmacs[work]: ah lispmacs[work]: ft: could you send me the git clone url so I don't have to unblock the gitlab javascript? ft: (that io-read is for a line based protocol, so it does ‘read-line’ to read) dsmith: You can give it no fd's and then it behaves just like a pure timeout, or you can not pass in a timeout, and it can block forever. ft: https://gitlab.com/ft/chip-remote.git ixmpp: is there a convenient tool for formatting guile? ixmpp: indenting it properly etc dsmith: emacs! ixmpp: but as a drive-by command line tool? ixmpp: i want to pipeline it dsmith: I've not heard of one. I wonder if it's possible to batch emacs to do that. Iv'e heard vi people do org-mode stuff that way. dsmith: I really suspect most lispers just use emacs. ixmpp: hmm ixmpp: maybe i'll see if i can pipeline vim then dsmith: I've finally gotten used to paredit. Most of it anyway. mfiano: I would check out smartparens. Switched from paredit like 6 years ago dsmith: mfiano: What's the advantage over paredit? mfiano: It does everything paredit does, plus more like allowing numeric prefices. It also works in other non-lisp modes, and pairs good with other packages like cleverparens, mfiano: Mostly though, it just seems to be less buggy. I use a lot of structural editing commands and sometimes paredit can leave the tree in an inconsistent state. dsmith: Hmm. mfiano: I guess another plus is that it's shipped with both Doom and Spacemacs, so likely has a lot more users...and is also actively maintained unlike paredit. dsmith: sneek: botsnack sneek: :) daviid: sneek: seen str1ng sneek: Not as far as I can remember. daviid: sneek: seen str1ngs sneek: str1ngs was in #guix 4 months ago, saying: hello daviid just going over your e-mail in regards to LGTM. I just had to switch to the new !event-type method vs !type. I'll test some more with removing gdk as a dependency.. daviid: sneek: seen spk121 sneek: I think I remember zzappie in #guix 20 days ago, saying: yesss. daviid: dsmith ^^ zzappie? dsmith: It does a think called metaphone matching. dsmith: I'm guessing it's supposed to match thinks like dsmith dsmith_ dsmith` ... dsmith: Kind of like soundex dsmith: It also seems to fail miserably at times. daviid: dsmith do we have to ask again then, when it 'fails' dsmith: No. It will give the same results. dsmith: For example, "sneek" and "seems" matched. daviid: that the bot 'links' zzappie and spk121 is a bit of a mistery daviid: to me, but then i am not a bot :):) daviid: well at least i think i am not, but in // universes ... who knows ... dsmith: (metaphone "zzappie") ;; -> "sp" dsmith: (metaphone "spk121") ;; -> "sp" dsmith: So it actually saves by the metaphone... dsmith: (metaphone "sneek") -> "sn" dsmith: (metaphone "seen") -> "sn" dsmith: I would like to remove that, but then all that "seen" history would be inaccessible. dsmith: I could just purge that table and start over. daviid: dsmith oh, i didn't mean to give you any work, and history is very much 'needed' i think dsmith: And it's working well enough for the most part... lispmacs[work]: select is working for me dsmith: lispmacs[work]: Yey! *: sneek dances daviid: i was just curious, and wanted to ask last time spk121 appeared here, but ok ... dsmith: I think that metaphone thing is tuned for real words. dsmith: https://en.wikipedia.org/wiki/Metaphone dsmith: It ani't pretty: https://github.com/igorhvr/bedlam/blob/master/sisc/sisc-contrib/irc/scheme/sarah/metaphone.scm lispmacs[work]: on a loosely related subject: I've noticed that if I do a pretty small write to a file output port, like 16 bytes, that force-output and sync don't actually force the data to the file lispmacs[work]: I have to actually close the port lispmacs[work]: I was wondering if anybody had insight into that. I'm on a Guix Gnu/Linux system. dsmith: Hmm. dsmith: SOunds like buffering, but force-output should handle that. dsmith: lispmacs[work]: I forget, is there a way to disable buffering? You might (or might not!) want to. lispmacs[work]: dsmith: I would say I don't need to in my use case, mainly just curious lispmacs[work]: I would end up closing the port anyway dsmith: IS it a socket? dsmith: If so, maybe need to disable nagle? lispmacs[work]: for this specific question, the output port is a file port lispmacs[work]: though the data does come down the chain from a file input port which is a FIFO dsmith: Hmm. Dare I say it: strace it! lispmacs[work]: which is tied to a serial comm port dsmith: A fifo. lispmacs[work]: strace, great idea! dsmith: Getting stuck in there perhaps. *: lispmacs[work] looks up what strace is on the internet... dsmith: strace -e write or maybe -e file dsmith: strace is kind of like wireshark for system calls. lispmacs[work]: that sounds handy lispmacs[work]: guix environment --ad-hoc strace lispmacs[work]: emacs seems to slow down a little once you have 273000 lines in a buffer lispmacs[work]: just brief pauses every once in a while lispmacs[work]: in the strace, nothing gets written until I close the port, and then all 16 bytes are writting in one write call lispmacs[work]: *written dsmith: So. Buffering. dsmith: https://www.gnu.org/software/guile/manual/html_node/Buffering.html lispmacs[work]: dsmith: I've read that, but it doesn't explain why force-output is not working here dsmith: Yeah. Wondering that myself. lispmacs[work]: unless, I have to drain some input elsewhere lispmacs[work]: ... dsmith: I *would* try setting the port to unbuffered though. dsmith: Are you sending a byte at a time, or larger chunks? dsmith: I know it's only about 16 bytes... lispmacs[work]: a byte at a time dsmith: Hmm. I would think if unbuffered that would be a write() for every byte. lispmacs[work]: okay, I'll set it to none dsmith: IF nothing else, it's a datapoint to help understand what's going on. dsmith: Sometimes, you just have to poke it with a stick to see if moves or not. dsmith: That metaphone thing does not do well with "funky" chars. Like non-alpha dsmith: The old bot in #debian had a "nick-o-meter". And it would tell what percentage lame your nick was. dsmith: "Your nick is 100% lame, ===!sam!=== lispmacs[work]: dsmith: everything is immediately dumped if I do (setvbuf op 'none) first dsmith: That means it works better? dsmith: (not sure what "immediately dumped" means) lispmacs[work]: dsmith: well, like I said, doesn't really make much practical difference in my case. I just was curious because I thought force-output was supposed to pull out things that are buffered dsmith: Indeed it should. dsmith: Smells like a bug to me. lispmacs[work]: immediately dumped means I didn't need to close the port to get the data to file dsmith: AHh. GOod then. lispmacs[work]: if I watch strace, I can see that now it is calling one `write' for each byte dsmith: Ya. Expected. dsmith: Getting stinkier every minute. dsmith: Ok, just to make sure. You *are* calling force-output on the correct port, right? lispmacs[work]: dsmith: yes. however, what I haven't tried yet was 'flush-all-ports'. I not 100% sure that buffering isn't happening further up the chain lispmacs[work]: the chain is UART -> USB -> picocom -> FIFO -> file *: dsmith shakes fist at usb dsmith: The thing is, you should really be seeing a write after calling flush. dsmith: And by "flush" I to mean "force-output" dsmith: s/to/do/ manumanumanu: In what conditions could guile receive a SIGKILL? manumanumanu: out of memory? manumanumanu: I have a some guile code for generating permutations, and trying to generate it for (iota 11) (which is very very big, I know) guile just quits with a SIGKILL emestee: if it's an out of memory issue you'd see that in dmesg manumanumanu: thanks manumanumanu: yes that was it lampilelo: manumanumanu: do you need a list of permutations or just want to iterate over them? lampilelo: because if you want to iterate, just like lloda suggested yesterday (although to someone else) you can use algorithms from knuth (they're mutating an array and visiting on every iteration) manumanumanu: oh, I have those as well taw10: Or, perhaps you need section 3.5.3 of SICP? manumanumanu: I just wanted to see if I could make a faster version of my already pretty fast lexicographical permutations code manumanumanu: so I implemented Heap's algorithm, and it is a little bit faster manumanumanu: The one that generates lexicographical permutations is fast, and can easily be made as a generator manumanumanu: it generates all permutations of (iota 10) in about 1s manumanumanu: whereas Heap's algorithm does it 10% faster lampilelo: ok, so everyting is under control manumanumanu: yes. thanks anyway emestee: ahhh I get to implement a FSM in scheme emestee: exciting ft: emestee: I think this conference call with william byrd may be of interest: https://www.youtube.com/watch?v=yrf1AYtrKm0 emestee: thanks, that can be useful flatwhatson: nice video! my "better way to do this": https://paste.gnome.org/plver7xld flatwhatson: lightbulb, it's a fold: https://paste.gnome.org/p8yaa8pfd dsmith-work: Hey Hi Howdy, Guilers ft: flatwhatson: Hehe, yeah I had this in a let: (fsm (lambda (input) (fold transition start input))) :) ft: https://paste.grml.org/hidden/aa5596d7/ flatwhatson: neat :) lloda: using Guile from C++, in { X x; scm_error(...); } x isn't destroyed. How to fix this lampilelo: lloda: that's because scm_error uses longjmp, c++ destructors won't run, what i do is use dynamic wind and a handler that calls them, of course the handler should be set up to run only on non-local exits lloda: thx lampilelo: lloda: https://dpaste.com/4H4YAG5U9 lloda: thx again, that helps lloda: i've been avoiding the obvious cases by closing scopes early etc but probably i have leaks all over the place lampilelo: yeah, it's a pain, most of the time putting stuff in { ... } is enough, the problems arise when you call scm_* and c++ functions interchangeably lampilelo: lloda: the code i posted is incorrect, you shouldn't use it lampilelo: i had a feeling something was wrong so i tested it lampilelo: it will work only if you use it once per dynamic wind lampilelo: i don't know how i thought it will work, it worked fine with my small library i wrote a while back but i called scm_dynwind_cpp_destroy once per dynwind, the problem is this thread_local variable stores only one lambda at a timem which will get replaced on every subsequent call, i don't have a solution right away lampilelo: but i have an idea stis: Heya guilers! lampilelo: hi stis stis: aret here a concept of programmers spreadsheet? mfiano: you mean like dataframes? stis: well consider constructing a spread sheet program ontop of guile, how should onw do that!! stis: Basically a framwoke of tables that allow you to filter/sort/rearrange(take-sellections etc mfiano: google for dataframe libraries mfiano: Such as https://github.com/hinkelman/dataframe stis: coolio stis: perfect!! lampilelo: you can use g-golf to make a gui for it stis: That would be perfect dsmith-work: Scheme In A Grid: https://siag.nu/siag/ manumanumanu: dsmith-work: that is a name with history! dsmith-work: manumanumanu: pre-history for some daviwil: Hey folks! I'm using (web client)'s `http-post' function to make a request to an HTTPS endpoint. My understanding is that `#decode-body?' is `#t' by default but for some reason I still receive a bytevector as the response body that is returned. The `Content-Type' header is `application/json' so I'd imagine this should be interpreted as text. Any idea what I might be doing wrong? daviwil: Passing the bytevector through `utf8->string' gives the desired result, so I suppose that's good enough for now! ft: I think that only happens if the content-type makes text-content-type? return #t. ft: So if you want to decode for other content-types too, you'll have to do it yourself, as you are. ft: daviwil: text-content-type? is (or (string-prefix? "text/" type) (string-suffix? "/xml" type) (string-suffix? "+xml" type)) daviwil: ft: Thanks! That explains it lampilelo: lloda: what do you think about this? https://dpaste.com/GM79HHZCY daviid: lampilelo: how about using a tor friendly paste service, debian, gnome ... "Your IP has been blocked for violating the dpaste.com Terms of Service...' well, happy it did, your (dpaste.com) are violating my privacy ... lampilelo: no problem, i chose dpaste because other people on #emacs use it, i thought it was alright lampilelo: daviid: if you want to take a look: https://paste.debian.net/1200603/ lampilelo: i don't think std::function allocates but i'm not sure lampilelo: if it doesn't this should be a safe way to destroy c++ objects on non-local exits RhodiumToad: daviid: paste sites are heavily abused by malware, it's not at all surprising that they would block anon access lampilelo: hmm... now that i think about it std::function always has the same size, so it will probably store the data attached to it on the heap dsmith-work: Someone was asking about http-request the other day. Did you ever get that figured out? lampilelo: ok, last revision today, if someone's interested: https://paste.debian.net/1200610/ lampilelo: switched to lambdas since they store everything inside lampilelo: sneek: later tell lloda sorry for the faulty code i gave you earlier, this should be much better: https://paste.debian.net/1200610/ sneek: Will do. lispmacs[work]: i seem to recall there was some trick I could do to hook a cleanup action to an objects garbage collection event. Am I remembering correctly? taylan: lispmacs[work]: I think they're called GC hooks? mfiano: You mean finalizers? lispmacs[work]: those both sound vaguely familiar lispmacs[work]: I think Guardians was what I used in the past lispmacs[work]: a "finalizer" sounds simpler, but I don't know how to make or attach one mfiano: They're not a trick. Infact, it is usually the developer being tricked, because they aren't reliable; they have a few caveats. dsmith: !uptime sneek: up 5 weeks, 12 minutes mfiano: Section 5.5.4 explains why they should probably be avoided. ixmpp: (lambda (f g h x) (if (f x) (g x) h)) does this function or similar exist anywhere? ixmpp: Dunno if im reinventing the wheel dsmith: sneek: botsnack sneek: :) dsmith: sneek: seen dsmith-work sneek: dsmith-work was last seen in #guile 13 hours ago, saying: {appropriate time} Greetings, Guilers. dsmith: sneek: botsnack sneek: :) tohoyn: topoi: here is a function computing permutations: https://paste.debian.net/1200366/ lampilelo: tohoyn: it's 10x faster if you use append! dsmith: sneek: botsnack sneek: :) tohoyn: here is a permanent link: https://paste.debian.net/1200368/ tohoyn: sneek: botsnack sneek: :) lampilelo: actually using cons instead of append is A LOT faster tohoyn: lampilelo: here is an updated version: https://paste.debian.net/1200371/ lampilelo: yeah, this doesn't do any garbage collection leoprikler: tohoyn: this looks nice and all, but it computes recursive perms many times leoprikler: I think one can do faster if one counts from 0 to k instead of the other way round tohoyn: ok tohoyn: this page claims that R7RS and R6RS library syntaxes are similar: https://www.gnu.org/software/guile/manual/html_node/R7RS-Support.html tohoyn: is it so? AFAIK R6RS defines a "library" form and R7RS a "define-library" form. wingo: similar != the same tohoyn: wingo: yes, but are the syntaxes compatible as the WWW page says? wingo: you should check :) tohoyn: wingo: IMHO the syntaxes are not fully compatible, though they are similar dsmith: !since dsmith: !since dsmith: !since sneek: 23 seconds dsmith: !uptime sneek: up 5 weeks, 8 hours, 59 minutes dsmith: !uptime sneek: This system has been up 5 weeks, 9 hours dsmith: !since sneek: I've been running for 23 seconds dsmith: goodbot civodul: sneek: botsnack sneek: :) lloda: when i've had to do combinations/permutations, i've just transcribed knuth to C lloda: a library of 'best known' routines for Guile would be very nice to have sneek: /who * sneek: /who * dsmith: !since sneek: I've been running for 34 minutes and 41 seconds chrislck: lloda: isn't it a matter of copying rosettacode.org into (ice-9 algorithms) ? lloda: that sounds too simple to work, but maybe it's a starting point chrislck alextee: making an appimage and I noticed that this directory is 30mb: usr/lib/x86_64-linux-gnu/guile/2.2/ccache alextee: that's precompiled guile stuff right? is it safe to delete? dsmith-work: Morning Greetings, Guilers dsmith-work: Did someone bisect the evaluation problem with Geiser? dsmith-work: Yes! http://logs.guix.gnu.org/guile/2021-05-06.log#005719 wingo: iirc lampilelo fixed it in geiser too dsmith-work: Hmm. Works with a fresh emacs process. Proabably some old geiser code dsmith-work: Oh! It's such a delight to use! yoctocell: Is there an empty char? yoctocell: #\null ? emanuele6: you mean the null character? (ascii 0) emanuele6: that is #\nul emanuele6: but i think #\null is a valid alias emanuele6: https://www.gnu.org/software/guile/docs/docs-2.2/guile-ref/Characters.html yoctocell: emanuele6 yeah, ok, thanks! lispmacs[work]: is there a convenient debugging procedure in Guile for "print out the return value of this expression and then return that return value"? manumanumanu: pk manumanumanu: (pk 'hej) => ;;; (hej) and returns 'hej lispmacs[work]: manumanumanu: okay, thanks lispmacs[work]: after doing a (load file-path) to re-load a module from the interpreter, is there any reason to ",use" the module again? dsmith: emestee: As in, not yet provided by a C library? Not sure. dsmith: However A C prog might do it could possibly be done though through the ffi. Not sure. dsmith: syscall() flatwhatson: i wonder how nyacc goes on ? flatwhatson: just fine, apparently! flatwhatson: hmm, i can't seem to convince it to emit the SYS_ defines tohoyn: xeno: could you explain the example to me, too? tohoyn: xeno: I think I got it. The key is the continuation of the call/cc expression. wingo: moo tohoyn: wingo: the corrected cumulative time counting in statprof seems to get some times wrong. I have a situation where procedure A calls procedure B but the cumulative time of A is smaller that the cumulative time of B. could you look at the code? tohoyn: wingo: I also filed a bug about statprof not displaying call counts wingo: could it be that B is ever called by not A? wingo: or that A sometimes calls B in tail position and sometimes not? tohoyn: wingo: I'll check. tohoyn: wingo: if the body of the procedure A is (if B var1 (C ...)) is the call of B in tail position? tohoyn: ^(B...) wingo: tohoyn: not in tail position tohoyn: wingo: is it so that guile optimizes the tail position calls so that they do not have a stack frame? wingo: yes, as required by the scheme semantics tohoyn: wingo. ok. tx. tohoyn: wingo: it might be useful to be able to switch this feature off tohoyn: wingo: for profiling wingo: unlikely to change in the near future fwiw, and in any case it is probably more useful to update your mental model of how scheme runs to incorporate tail calls wingo: after all, you wouldn't want a backtract to include every loop iteration, and those are tail calls tohoyn: ok dsmith: Scheme doesn't have "TCO". In Scheme *ALL* calls are actually jumps. However there *are* some exceptions, like when needing the return value, or in a sequence. RhodiumToad: eh... disputable RhodiumToad: scheme explicitly distinguishes where tail position is and makes specific requirements about tail calls leoprikler: yup, IIRC TCO stems from observations made in FP first dthompson: it's not an optimization. it's semantic. leoprikler: It's semantic in Scheme, it's not semantic in C/C++. RhodiumToad: the specific requirement as stated in r7rs is that the number of active tail calls must be unbounded RhodiumToad: that is to say, if you implement a loop via tail calls, it should not terminate unless something within the loop stops it for whatever reason leoprikler: But C/C++ compilers will look for instances in which similar semantics are used to perform so-called "tail call optimization". RhodiumToad: yes, if a function ends with return otherfunc(); then the emitted code may drop the current function's stack frame and jump to otherfunc RhodiumToad: or the equivalent RhodiumToad: but this is not required by the language so it's up to the compiler whether it happens or not RhodiumToad: (and usually won't happen if optimization is off) topoi: What is the combinatoric problem called where you pick k from n elements in a list? topoi: I could cut and filter permutations but this is profanely inefficient. RhodiumToad: does order matter? topoi: RhodiumToad: yes. topoi: Ahh, it's called "k-permutations"? : ) topoi: I often like to reimplement basic functions, but sometimes it's exhausting. : / topoi: RhodiumToad: but without repetition resp. without put back. RhodiumToad: right, those are permutations RhodiumToad: if order doesn't matter they are combinations lloda: https://en.wikipedia.org/wiki/Permutation#k-permutations_of_n lloda: variations (variaciones) is actually the name i'm familiar with topoi: lloda: How familiar are you with them? :3 topoi: I'm so desperate, I'll construct them soon from power-sets. :P dsmith-work: {appropriate time} Greetings, Guilers topoi: Okay, I hate this solution: http://ix.io/3p2G : ) manumanumanu: topoi: I have some code that generates lexicographical permutations manumanumanu: if you want to manumanumanu: have it. It is for vectors. manumanumanu: I also recall having a pretty fast powerset somewhere manumanumanu: topoi: that powerset is the same as I have :D manumanumanu: Maybe we should have some library collecting efficient versions of some maths procedures like that. We could model it after racket/math. lampilelo: omg u nuts bud: yeah. This is the last thing i really miss from my old windows setup. bud: i had this script that let me, do things like: hold right+scroll -> switch tab bud: hold left+scroll -> switch program (alt+tab) bud: right+middle close tab bud: left+middle close program bud: it was great. dsmith: The only "chording" I've ever seen before is in Plan 9 bud: YES! bud: https://0x0.st/-_p9.txt bud: this works, hold right and scroll to send control+page_up/down bud: try it in the browser! bud: and just pressing right, at least have its own function (notify-send alone) dsmith: nc tohoyn: retropikzel: terve retropikzel: tohoyn, moro emestee: I don't presume anyone here is a character terminal magician that could explain me why sending an ANSI escape command to interrogate the terminal causes the terminal to print the response locally? dsmith: emestee: What do you mean by "locally"? What are you expecting to happen? emestee: dsmith: i send an ANSI device status request to guile standard output and read the terminal's response on standard input. However, something duplicates the terminal's response to its screen. Guile is execute from the shell that lives in tmux. I don't know which component is echoing the terminal's response (e.g. encoded cursor position) back to the terminal emestee: executed* emestee: it's basically putty -> ssh -> shell -> tmux -> shell -> I assume pty -> guile dsmith: And the Guile prog does read the response? dsmith: Hmm. Might need to turn echo off or something like that. dsmith: I think I ran into something similar one time. Was sending some escapes to determing screen size. dsmith: I don't have that code here. dsmith: Hah! Found it. dsmith: emestee: Yeah, I'm disabling echo. emestee: dsmith: how? dsmith: emestee: https://paste.debian.net/1200172/ emestee: ah termios, so it *is* done by linux and not the terminal itself emestee: well then, time to abuse the ffi I guess emestee: thanks! dsmith: It's the pty I think. dsmith: A terminal is just a thing on the end of a serial port that you send chars to and read from. dsmith: emestee: There was a nice article I read recently that goes into the history of serial ports on unix and why xterm behaves the way it does. dsmith: Sadly, I don't have a link to it. dsmith: emestee: Might have been this: https://www.linusakesson.net/programming/tty/ xeno: hi, I don't get the simple call/cc example from The Scheme Programming Language: (let ([x (call/cc (lambda (k) k))]) (x (lambda (ignore) "Hey!")) - why is the last lambda evaluated rather than returned? xeno: oh damn, I think I just got it emestee: is there a method to perform arbitrary system calls? panicking: Hi All! Is there a way to specify a to each slot of a class using goops? Regards. dsmith: There was some talk a while back about Geiser not working with Guile 3. Did anyone ever get to the bottom of that? dsmith: (seems to be working for me with a fresh geiser and geiser-guile install) flatwhatson: yep i think lampilelo got to the bottom of it, so the latest should work flatwhatson: it was specifically the syntax changes in 3.0.6, was working fine before that dsmith: Oh man. I forgot how nice geiser is. flatwhatson: yep i also use flycheck-guile and turn on geiser's company-mode support emestee: is it a good style for a function to accept either a list _or_ a function that returns a list in the same argument? ArneBab: emestee: I think I would rather use define* from (ice-9 optargs) to pass a named argument: #:args '(…) or #:argument-provider fun emestee: thanks! RhodiumToad: or just accept the function returning the list; the caller can use (const '(...)) to pass a list ArneBab: RhodiumToad: I didn’t know const — thank you! stis: Hello guilers! tohoyn: I filed bug #48847 about statprof not printing call counts ix: Hello.. say i have this sexp: (public-key ix: (ecc ix: (curve Ed25519) ix: (q #7514F8D729DB1935470A581CE3851ED9FD6F1F9BAFE1D8BEC77A931ADB7A4337#))) ix: Can i reproduce that in literal guile? ix: The hashes seem to mess things up dsmith: Yeah, The Guile reader won't know what to do that #...# thing. dsmith: s/do that/do with that/ ix: dsmith: whats my best option? flatwhatson: sed 's/#/"/g' ix: Ooh, there's (@ (gcrypt pk-crypto) string->canonical-sexp) and canonical-sexp->string ix: And s/string/sexp ix: I'll use those bud: hello guile people! bud: i was looking around for something that could do "mouse-chords" bud: and found that it is possible with xbindkeys if configured with guile. bud: this is the config i am trying now: https://0x0.st/-_90.txt bud: it works and the chords are defined on the last lines. bud: holding b:3 (right mouse button) and pressing b:1 displays the popup "helloC" bud: this is cool and all, except that now, right mouse button only acts as a modifier, and i cant use it normally. bud: so what i am asking, is there a simple way to set a default command, if b:3 is released by itself? bud: https://wiki.archlinux.org/title/Xbindkeys <- this is where i got the scm file dsmith: Wow, that's pretty cool. Didn't know about xbindkeys dsmith: sneek: help later tell dsmith: goodbot Noisytoot: sneek: botsnack sneek: :) dsmith: sneek: botsnack sneek: :) dsmith: sneek: seen wingo dsmith: sneek: botsnack sneek: :) dsmith: sneek: seen wingo sneek: wingo was last seen in #guile 5 hours and 45 minutes ago, saying: instead the function should be identified via its code (ip). dsmith: sneek: help later tell dsmith: sneek: help dsmith: sneek: later tell dsmith-work testing sneek: Got it. dsmith: sneek: tell dsmith-work testing dsmith: sneek: tell dsmith-work testing dsmith: sneek: later tell dsmith-work testing sneek: Got it. dsmith: sneek: seen wingo sneek: wingo was last seen in #guile 5 hours and 52 minutes ago, saying: instead the function should be identified via its code (ip). dsmith: sneek: bugs? sneek: Someone once said bugs is Send reports to bug-guile@gnu.org, and see bug reports at https://bugs.gnu.org/guile dsmith: sneek: atest is a test dsmith: sneek: atest is a test sneek: I'll keep that in mind. dsmith: sneek: seen someone here that sometimes answers to wingo sneek: Nope. dsmith: heh dsmith: sneek: what is atest? sneek: Last time I checked atest is a test dsmith: sneek: where is atest? dsmith: sneek: atest? sneek: atest is a test dsmith: sneek: forget atest sneek: Consider it forgotten. dsmith: sneek: later tell dsmith-work testing sneek: Got it. dsmith: sneek: tell dsmith-work testing also dsmith: sneek: help later test dsmith: sneek: atest is also something else sneek: So noted. dsmith: sneek: atest dsmith: sneek: atest is something sneek: Understood. dsmith: sneek: atest? sneek: atest is something dsmith: sneek: atest? sneek: Last time I checked atest is something dsmith: sneek: something else? sneek: I could be wrong, but atest is something dsmith: sneek: forget atest sneek: Okay. dsmith: sneek: forget something else sneek: Consider it forgotten. dsmith: sneek: help later test dsmith: sneek: help later tell dsmith: sneek: botsnack sneek: :) dsmith: sneek: tell lloda Hello! sneek: lloda, dsmith says: Hello! dsmith: Well! The somewhat useless "tell" coommand is working again. tohoyn: statprof-display doesn't display call counts even though I use #t as the third argument to statprof-reset tohoyn: what is wrong? tohoyn: calling statprof with "#:count-calls? #t" doesn't work either dsmith: sneek: botsnack sneek: :) dsmith: sneek: seen rlb? sneek: rlb was last seen in #guile 2 days ago, saying: But I *did* like being able to write clj code for the browser (though I haven't been doing any of that for a good while now).. dsmith: sneek: help later tell dsmith: sneek: later tell help manumanumanu: sneek: botsnack sneek: :) wingo: dsmith: yeah, see what (system vm frame) does wingo: (get proc name from ip) dsmith: wingo: The tricky bit is getting to the SCM frame when you only have the scm_thread * wingo: all of this should be done from scheme fwiw wingo: in (system vm frame) wingo: there you have the ip because you have the stack trace canant: Hi Guys, canant: I'm a newbie on guile and trying to be familiar with and understand the fundamental concepts. canant: I couldn't get the Parameters concept. Why we need this instead of passing data as arguments? canant: make-parameter and parameterize are very hard to understand for someone like me from the C/C++ world. canant: Any help? :) taw10: canant: Think of it as kind of like an improved version of a global variable taw10: You *could* pass things round as arguments everywhere, but I'm sure you've encountered situations where that becomes a complete mess. Parameters fix that canant: Thanks, taw10. Are there any meaningful examples rather than simple official ones? canant: Those ones are so simple. canant: Uploaded file: https://uploads.kiwiirc.com/files/9055ec35f4afe73098c6e4dec0748470/pasted.txt taw10: I use it in one of my projects to help allow essentially arbitrary code to be used to create a certain type of object (https://github.com/taw10/starlet) - (lighting-state ...) expands to (parameterise ((current-state (make-empty-state))) ...), so anything inside the lighting-state form has access to the current "state" object tohoyn: you could also consider fluid-let tohoyn: see e.g. https://www.informatik.uni-kiel.de/~scheme/doc/mzscheme/node20.htm canant: Thanks again taw10 and tohoyn. I'm looking into those. taw10: Just for comparison, imagine how my lighting-state thing would look using arguments. I'd have to use some macro magic to inject the argument into every sub-form that needs it. And since there can be any type of form there, I'm not sure that's even possible. taw10: tohoyn: Guile doesn't seem to have fluid-let. Guile parameters are built on top of fluids, though. The manual recommends to use parameters rather than fluids. But sure, it's the same basic idea. leoprikler: tohoyn: with-fluid* and with-fluids* work kinda like let but take thunk as procedures tohoyn: taw10: fluid-let is easy to implement. see https://paste.debian.net/1199993/. lloda: you can use parameterize lloda: there's a bunch of stuff that has multiple versions in Guile, the original Guile version, the srfi version, the standard version lloda: i try to stick to one dsmith: Guile modules (which predate r6rs (and r5rs)) are mostly just mapping of names to scheme objects. dsmith: R6rs modules (or is it libraries?) expose *immutable* bindings to objects. dsmith: For the benefit of compilers I guess. dsmith: But sometimes, you just need to provide a value that can change. dsmith: So then comes in parameters. dsmith: Through an immutable binding, you get or mutate a value. lloda: you don't need a parameter for that. You can export a box dsmith: Did r6rs provide boxes? tohoyn: use one-element vectors dsmith: I've always thought the parameters were a r6rs thing. Pretty sure Guile didn't have them until it started added r6rs support. lloda: guile had fluids, which are the same thing dsmith: Yes. But I think r6rs lib immutability is the "why?" of parameters. mwette: sneek: botsnack sneek: :) dsmith-work: Happy Friday, Guilers!! sneek: Welcome back dsmith-work, you have 4 messages! sneek: dsmith-work, dsmith says: testing sneek: dsmith-work, dsmith says: testing sneek: dsmith-work, dsmith says: testing sneek: dsmith-work, dsmith says: more testing dsmith-work: goodbot *: sneek wags manumanumanu: dsmith-work: parameters are for dynamic binding. I use them to change behaviour of libraries whern parameters doesn't cut it manumanumanu: You _can_ use parameters to change variables in a library, but boxes are probably more efficient dsmith-work: manumanumanu: Soo... You use parameters when parameters aren't good enought? ;^} manumanumanu: dang dsmith-work: heh manumanumanu: I meant parameters as in function arguments dsmith-work: Indeed. :) dsmith-work: But still fun. dsmith-work: (Please! No offence meant!) lispmacs[work]: manumanumanu: this is scheme. Infinitely recursive explanations are okay. lispmacs[work]: how do I change the current working directory, in regards to relative paths in (load path) commands? lispmacs[work]: (chdir path) seems to work lispmacs[work]: sneek: give lispmacs a botsnack sneek: :) lispmacs[work]: sneek: quit smiling *: sneek gives lispmacs[work] a botsmack amirouche: goodbot leoprikler: lispmacs[work]: there's also string-tokenize IIRC, plus good ol' regexp and peg flatwhatson: ah, i see doc-snarf is in need of some love... was hoping to use this for my projects flatwhatson: i found your patch for (define*, thanks leoprikler! flatwhatson: it seems to struggle with internal docstrings though, so some more attention is needed flatwhatson: i'm thinking the way forward might be to start with adding some test cases robin: uh, i think i just killed sneek, by asking it "help later tell" robin: i don't remember who runs sneek or i'd ping them directly, sorry about that :( leoprikler: flatwhatson if by internal docstrings you mean the "First string in a function", then I'd rather suggest the texinfo module(s) manumanumanu: dsmith-work: see what robin wrote above. robin: ty manumanumanu manumanumanu: robin: np. It is a funny bug :) leoprikler: I once confused sneek using tell later tell leoprikler: Then tell was disabled, but it seems later tell is the real bug :P leoprikler: Or rather it appears sneek doesn't know what to do with multiple commands manumanumanu: Is there any IRC library for guile? flatwhatson: leoprikler: ah thanks, will look into it leoprikler: I think 8sync might come with something, but I'm not sure flatwhatson: https://git.savannah.gnu.org/cgit/8sync.git/tree/demos/ircbot.scm manumanumanu: I just realized guile is pretty fast starting up. On my system it even beats python3. Only perl and python2 is actually faster. manumanumanu: RhodiumToad: I remember john asking you about some bytes->hex thingie (you have a lovely sparse array imlpementation). Did that ever materialize? Did you ever put it in a library? It would be great to have RhodiumToad: I think you mean this? https://github.com/RhodiumToad/scheme-bits/blob/master/hex/hex.scm wingo: moo RhodiumToad: it's not really a sparse array as a cheating way of storing 257 distinct values per byte RhodiumToad: rather than storing byte x at index i, it stores (- x (logand i 3)) because due to the nature of the values stored, we know that x can't be less than i RhodiumToad: and we also know that if x is 255, (logand i 3) is not 0 RhodiumToad: so the upshot is that the value 255 never needs to be stored, so we can use it as a flag for "this value isn't valid" emestee: wait, guile has sparse arrays?! RhodiumToad: ? RhodiumToad: who said it did? civodul: when you have a URI-reference relative to some URI, what's the proper way to build the corresponding URI? civodul: as in: URI-reference + base-URI => URI lloda: my readline troubles are over after... reinstalling the proprietary nvidia driver. That doesn't use libedit while the mesa driver did. Haha. dsmith: sneek: seen robin? sneek: Not as far as I can remember. dsmith: sneek: help later tell dsmith: sneek: botsnack sneek: :) dsmith: sneek: help later tell dsmith: sneek: botsnack sneek: :) lloda: sneek: later help tell lloda: sneek: how far can you remember dsmith: sneek: seen rlb sneek: rlb was last seen in #guile one day and 17 hours ago, saying: But I *did* like being able to write clj code for the browser (though I haven't been doing any of that for a good while now).. dsmith: sneek: robin dsmith: lloda: say that "help later tell" command again, and then stay quiet for a bit please. I want to see something. dsmith: (or anyone) lloda: sneek: help later tell dsmith: sneek: seen lloda? sneek: lloda was in #guile 56 seconds ago, saying: sneek: help later tell. dsmith: Ok! dsmith: C0ol RhodiumToad: lloda: why would mesa use libedit? lloda: apparently it comes through llvm RhodiumToad: hmm... lloda: and llvm added it for convenience since a couple libraries using llvm also needed that functionality RhodiumToad: that seems like a bug lloda: from what i read yesterday lloda: i agree RhodiumToad: yeah, that's definitely bad manumanumanu: RhodiumToad: that's the one! Thank you! alwalo: Sorry I am not trying to spam, but I think my messeges were invisible cause I didn't finish registration on IRC, now I finished and I send my question again (doesn't mean to spam) sorry if it was visible before alwalo: I am using (http-request "url") without any other parameters, I do get error: web/http.scm:252:2: Bad media-type header component: "text/xml", of course I am trying to download xml file, how should I do it ? dsmith-work: Thursday Greetings, Guilers emestee: alwalo: that doesnt sound right, are you sure the remote server is functioning correctly dsmith-work: wingo, civodul: Might be a good idea to update the /topic to mention that your nick must be regisered to speak in the channel. civodul: dsmith-work: oh, was it the case back on Freenode? dsmith-work: civodul: I don't remember. dsmith-work: There was a weird thing that I couldn't change my nick back unlesss I parted the channel. alwalo: here is my sample code that results in error: https://pastebin.com/PwpzPyNH alwalo: there is misspelling in last (display) call but it is because I had to retype it by hand alwalo: I have now checked it exact same program written in Python using Requests library and everything works fine, file gets downloaded and saved on drive dsmith-work: alwalo: I would wireshark the attempts for both and compare what is different. Possibly a missing content-type header? dsmith-work: alwalo: Maybe somtething this is needed: (http-request "http://myurl" #:headers '((content-type application/xml))) dsmith-work: alwalo: Or maybe need an Accept header? alwalo: can you give an idea how #:headers should look like ? alwalo: web/request.scm:133:2: In procedure validate-headers: alwalo: Bad request: Bad value for header accept: (application/xml) dsmith-work: Posisble (http-request "http://142.250.191.110/" #:headers '((accept (application/xml)))) alwalo: web/http.scm:252:2: Bad media-type header component: "text/xml" lispmacs[work]: leoprikler: string-tokenize sounds pretty close to what I want, though I'm not sure about the challenges of applying that to a live input stream in my use case dsmith-work: alwalo: Hmm. I dunno. ((@@ (web http) validate-media-type) "text/xml") -> #t dsmith-work: Not sure why that's Bad dsmith-work: alwalo: Did you wireshark and compare? dsmith-work: alwalo: How about this, try adding #:validate-headers? #f to your http-request dsmith-work: alwalo: https://www.gnu.org/software/guile/manual/html_node/Requests.html#index-build_002drequest dsmith-work: Sorry, looks like you can't pass that to http-request alwalo: (read-request-body (build-request "url" #:headers .....)) should this work like this ? I will try lampilelo: lispmacs[work]: for live string input streams maybe 'expect' would be of interest to you manumanumanu: lispmacs[work]: what do you mean live input stream? lispmacs[work]: lampilelo: thanks, that looks interesting manumanumanu: srfi-171 can handle streaming transformations... manumanumanu: depending on case, of course. lispmacs[work]: manumanumanu: just that I'm reading from a port in real time connected to a device that delivers whitespace separated tokens that need to be processed one a time in real time lispmacs[work]: I'm pulling output from a FORTH interpreter running on a microcontroller lispmacs[work]: and sending commands manumanumanu: sure thing. srfi-171 does that, but you will need to write your own reducer for it that writes to a port manumanumanu: you could use the tbatching transducer manumanumanu: sorry, tbatch. dsmith-work: lispmacs[work]: Yey Forth! lispmacs[work]: when our powers combine, I become forthmacs[work]: ta da! forthmacs[work]: It is becoming harder and harder to find a telephone booth these days dsmith-work: :) forthmacs[work]: SHAZAM! lispmacs[work]: I'm back manumanumanu: lispmacs[work]: I am not sure how to do it best, though. Unless you want to do some kind of processing, transducers seem like a waste of processing power. lispmacs[work]: manumanumanu: this Expect module might be what I was looking for manumanumanu: jesus, why have I never seen that before?! manumanumanu: but that unhygienic capture of variables is pretty unsexy though. dsmith-work: leoprikler: Heh. I can't tell if that means cargo is a good thing or not. leoprikler: I would call it contemporary baggage, but that's just me. amirouche: hey :) amirouche: I am reading on foldts, foldts* and foldts*-values amirouche: As far as I understand those are very important for guile because that is the tool used to describe the transformation of the guile IL / IR called tree-il (module/language/tree-il) amirouche: sort of like what nanopass framework is for chez. amirouche: here is the associated paper https://wingolog.org/pub/fold-and-xml-transformation.pdf amirouche: here is the documentation https://www.gnu.org/software/guile/manual/html_node/SXML-Tree-Fold.html amirouche: my first question is / was stupid: what is the point of -values variants, afaiu it does not matter, one could pass a list as seed to fold and its variants. amirouche: I am correct to think that foldts* allows to rewrite a tree in context sensitive manner, without building a closure? amirouche: That is exactly what is explained in section 3 of the above paper. amirouche: That is prolly overkill: is there a variant of fold that support cyclic data structures? lloda: found something about my problem with readline lloda: once I call some gl functions, guile-readline starts calling into libedit2 instead of libreadline lloda: so everything gets corrupted and i get crashes in short order lloda: my program doesn't use libedit2 or libreadline except through Guile lloda: i've compiled guile with --with-libreadline-prefix=/opt/readline/ and i compiled readline from source lloda: libedit2 is a dependence of some of the gl libraries in debian and I cannot remove it lloda: but I don't understand how the switcheroo is possible at all lloda: neither guile nor my program are linked to libedit2 lloda: directly, i suppose i should say wingo: i would guess ELF superposition sneek: Welcome back wingo, you have 1 message! sneek: wingo, maximed says: When using #:drain? #t, I notice some fibers are not actually run to completion (tested by adding a few (pk 'i fiber-index); some indices are missing from the log). Does that sound a bell? (I need to make a minimal test case & try to work-around with condition variables) wingo: or imposition or whatever that is wingo: weird thing is, guile loads guile-readline via load-extension which doesn't pass RTDL_GLOBAL wingo: so am not sure exactly how the interposition would work lloda: >:( dsmith-work: As usual, an strace might reveal what is loading what. lloda: dsmith-work: thx, i should learn how to use that. I used gdb dsmith-work: So libedit2 provides the same api/abi as libreadline? Sounds similar to a problem I had with apache. dsmith-work: Apache provided it's own regex, and it was statically linked into the exec. The functions were nameed the same as the libc ones, but the actual structures were different and had different sizes. lloda: even if the libraries are byte identical their runtime data wouldn't match lloda: this is a bit of a nightmare tbh dsmith-work: Yep. lloda: that's why my history was always being deleted, i was building it up in libreadline but when the program was closed it was calling libedit2's functions to write it out and of course for libedit2 there wasn't any history dsmith-work: So what I ended up doing was #include'ing the apache headers dsmith-work: https://cvs.savannah.nongnu.org/viewvc/mod-guile/mod-guile/mod_guile.c?revision=1.3&view=markup#l703 dsmith-work: lloda: That's not going to help with readline :( lloda: i'm trying to link readline statically dsmith-work: lloda: Good chance that's not going to work. The code that calls into libedit will probably call into your staticly linked libreadline. Unless you can hide the symbols. lloda: my bet is that no one is calling into libedit and it's a spurious dependence lloda: else I'll try to use libedit with Guile and remove libreadline lloda: this elf interposition sounds gross dsmith-work: There *are* ways to hide symbols. lloda: but i have no control of the other library dsmith-work: I was thinking staticlly link readline, and somehow not expose the global symbols. dsmith-work: So ldso (or whatever) doesn't see them when it links in libedit lloda: yeah it doesn't work lloda: i mean linking statically doesn't work lloda: still finds the symbol on the other library dsmith-work: Something with __(attribute)__ hidden? Looking for it.. dsmith-work: https://gcc.gnu.org/onlinedocs/gcc-8.5.0/gcc/Code-Gen-Options.html#Code-Gen-Options dsmith-work: Near the very bottom -fvisibility=[default|internal|hidden|protected] dsmith-work: lloda: I wish you the best. Looks like a very nasty problem. dsmith-work: Oh, and this might help: https://gcc.gnu.org/wiki/Visibility dsmith-work: The real problem remains, a clash between two libraries providing the same function symols but with different data structures. dsmith-work: Maybe if there was a way to rename things.. dsmith-work: And https://holtstrom.com/michael/blog/post/437/Shared-Library-Symbol-Conflicts-%28on-Linux%29.html dsmith-work: lloda: Make a symlink libedit2 -> libreadline ;^} apteryx_: there's no equivalent to gdb's 'list' in the Guile debugger, correct? lloda: i'm trying the symlink now dsmith-work x_x lloda: guile complains that readline is missing functions and is too old :p apteryx_: It seems most of my debugging in Guile Scheme is at the primitive 'print' level (pk in the sources) and the occasional ,trace at the REPL. I haven't become good at using ,break and ,step yet, it seems. Is it me, or is it notoriously tricky to use the 'live' debugger? lloda: symlink method failed as there's a libreadline.so.7 that a ton of stuff depends on that gets in the way as well lloda: apteryx_: i have tried a couple times and given up dsmith-work: lloda: The symlink *was* a joke. lloda: on me, then haha lloda: it would have worked if it wasn't for the other library tho dsmith-work: On an old mac-mini, they provide something that looks like readline, but isn't. So at build time, guile thinks it has readline, but at runtime, it was failing to find certain symbols. dsmith-work: I think they had a symlink from readline -> whaeveritwas lloda: i think i've seen that lloda: as long as there is only ONE, i guess apteryx_: one thing about the debbugger I haven't sorted out is how to break at a specific line. I'm trying ,bs NNN, but it wants a file argument. So I try for example ,bs the-module.scm 529 and it says: No procedures found at ~a:~a. "the-module.scm" 529. Ideas? apteryx_: ah OK, it wanted the absolute path of the file apteryx_: nevermind, relative path is fine if I adjust the cwd of the REPL first. stis: heya guilers! dsmith-work: stis: Heya! How goes the Python battle? stis: forward, been enjoying nice weather recently though apteryx_: what seems to work best for debugging is; ,break some-proc. Then run the code exercising the proc at some point. Then define an Emacs macro for ,step RET ,backtrace #:full? apteryx_: that way you can step at the press of a button and keep track of the locals in every frame. apteryx_: err, should have been ',step RET ,backtrace #:full? #t' apteryx_: F3 to start recording the macro, F4 to stop recording. F4 again to play back. lloda: found a couple links reporting similar problems lloda: https://developer.blender.org/T43491 lloda: https://bugzilla.redhat.com/show_bug.cgi?id=1201897 lispmacs[work]: hi, I'm needing to process an input stream as a series of whitespace delimited tokens, and am wondering what guile tools / modules would be useful manumanumanu: lispmacs[work]: guile-dsv might be useful, but that is for actualy DSV amirouche: later tell maximed use fibers issues and ping @amirouche amirouche: sneek: later tell maximed use fibers issues and ping @amirouche sneek: Will do. amirouche: sneek: later tell maximed and/or ping me here sneek: Will do. drakonis: dsmith: hey, where would i find the source for sneek? I'd like to use it in a private channel dsmith-work: drakonis: Ahh. Good quesiton. *: dsmith-work looks nckx: The core is bobot++ (https://unknownlamer.org/code/bobot.html), that much I know. *: nckx knew a thing, gets snack. dsmith-work: drakonis: Know that is is merely a dump of what I have. It's not ready as something you can run. dsmith-work: drakonis: https://gitlab.com/dalepsmith/sneek dsmith-work: drakonis: The old sarahbot is at https://github.com/igorhvr/bedlam.git under sisc/sisc-contrib/irc/scheme/sarah drakonis: thanks dsmith-work: drakonis: I basically wanted to run sarahbot, but on Guile instead of sisc drakonis: neat. jcowan: Does anyone know how the decision was taken to add R6RS support to Guile? I can't see any obvious Guilers on the R6RS editorial committee (unlike Chez and Racket). taylan: jcowan: I'd say it was done at the whim of either Andy or Mark. my guess is on Mark. could check commit logs... taylan: commits seem to be primarily from Andy dsmith: iirc, someone else provided the initial patch for r6rs library/module syntax. dsmith: "Guile now has implementations for all of the libraries defined in the dsmith: R6RS. Thanks to Julian Graham for this excellent hack." dsmith: Looks like first appeared in Guile 2.0 dsmith: https://mail.gnu.org/archive/html/guile-devel/2009-11/msg00000.html jcowan: THanks. So that means there are three kinds of R6RS implementations: (a) those maintained by members of the committee, (b) R6-from-scratch implementations that did not exist before R6; (c) Guile. taylan: hehe rlb: alextee: for web stuff, I'd likely lean toward clojure/jvm. The options there are broad and deep, both with respect to the jvm and available java libs (which are easy to use directly from clojure), and the available clojure-specific libraries. But other platforms may be preferable if you want faster startup and/or solid POSIX/unix/linux support (i.e. the jvm has only recently admitted symlinks and filesystem sockets exist). rlb: alextee: and that's in part what I'd hoped for with lokke -- faster startup solid support for #! work, POSIX/linux calls, etc. rlb: (you can also use clojure on both sides, server and client with clojurescript, and that works well too) rlb: At least to the extent that I've done client-side work, which has only been a bit. lispmacs: is there some procedure already which converts multiple return values into a list? lispmacs: instead of (receive (a b c) (someprocedure) (list a b c)), for example d4ryus: lispmacs: I dont know any, i use (call-with-values somprocedure list) lispmacs: d4ryus: a little nicer, thanks alextee: rlb, thanks for the info. being able to use it in both client and server side seems like a nice benefit leoprikler: lispmacs (compose list your-proc) lispmacs: leoprikler: that doesn't quite make sense, and doesn't seem to work when I try it lispmacs: leoprikler: oh wait, I must have typed it wrong. seems to be working now lloda: my readline troubles seem to have to do with threads. My program uses a GL thread and if I spawn it before activating readline, readline doesn't seem to initialize properly and I get the strange file-completion behavior and no history across sessions. If I spawn the GL thread after activating readline, then I get broken history, broken keys (C-k for some reason) and sometimes crashes. lloda: I'm kind of lost atm :-| wingo: humm :/ wingo: is calling readline only from one thread an option? lloda: yes, that's what i do now lloda: the GL thread doesn't do anything with readline, it only does GL things lloda: rlwrap works, so i'll use that instead fttb wingo: blah dsmith-work: Tuesday Greetings, Guilers apteryx: hello! Is there something ready to use such as string-split, but splitting on a string separator rather than a character one? dsmith-work: apteryx: Were you asking this about a month or so ago? apteryx: eh, I hope not *: apteryx checks logs civodul: apteryx: see string-tokenize* in (guix search-paths) lampilelo: apteryx: you could use something like this: (lambda (str sep) (string-split (string-replace-substring str sep #\us) #\us)) lampilelo: requires loading (ice-9 string-fun) lampilelo: does 2 passes though apteryx: civodul: neat! apteryx: dsmith-work: my logs say no! :-). Phew. I'm not totally loosing it. dsmith-work: apteryx: Ok. np. *someone* did. dsmith-work: I wonder if the srfi-13 funcs that take a predicate can coerced into doing the job. apteryx: it's a relatively common procedure provided out of the box in other languages I think (Python, Java at least) apteryx: in the browser: "Hello something World".split("something") -> Array [ "Hello ", " World" ] taylan: wow, kinda crazy that SRFI-13 doesn't have string-split jcowan: And does have -upcase!. It's things liike that that keep SRFI 13 off the R7 ballots: it's not designed for a Unicode world dsmith-work: jcowan: Is there a better replacement? (/me not up on r7rs stuff) jcowan: We have no less than five string SRFIs with a new one on the way. If you don't care about immutability, use SRFI 152, which is completely portable. leoprikler: Five? Preposterous! We need a new SRFI, that covers all potential use cases. dsmith-work: leoprikler: So we can then have 6! (insert xkcd link here) jcowan: They serve different use cases: mutable strings, immutable strings, both; string cursors vs. string indexes; backward compat with R7RS vs. no backward compat. leoprikler: except for the R7RS stuff, everything else is no either/or jcowan: We could have lived with SRFI 13 indefinitely if it weren't for UTF-8/UTF-16 internal representation and immutability becoming popular jcowan: A or B or both is a choice, even if not an either/or choice. Libraries that provide cursors also provide indexes for backwards compat dsmith-work: Ugh jcowan: Also, I should have sais "R[567]RS" jcowan: dsmith-work: Can you clarify a bit? dsmith-work: Heh. Just seems a mess. jcowan: Oh, at the meta level, yes; but we have what we have. I am writing the sixth with the intention of providing both mutable and immutable strings, no cursor support, and backward compat. I believe it may be said to fairly subsume four of the five other SRFIs. manumanumanu: jcowan: (I am clearly beating the dead horse)why no cursors? To me it seems like the most efficient way to iterate over utf-8 representation strings... manumanumanu: Everything is of course a compromise, and it is not a very common way to handle strings, but I wrote some code for chibi and found it quite elegant... jcowan: Oh, I don't deny that. I thought fitting cursors into the Sixth Library would overload it too much, but it's certainly possible to do so. rlb: alextee: certainly, though of course there are tradeoffs, i.e. the happy path in that world is the pip/gem/mvn "download giant piles of code from ..." track, unless your distribution actually packages everything you need, and even then, it may not be trivial to make sure you're only using the distribution versions (if that's what you want). rlb: But I *did* like being able to write clj code for the browser (though I haven't been doing any of that for a good while now). manumanumanu: dsmith-work: I usually say that one wouldn't design a "2021 scheme without historical luggage" with mutable strings (or cons pairs for that matter). SRFI-135 seems reasonable to me :) manumanumanu: (mutable cons pairs manumanumanu: ) dsmith-work: « and » for quotes eh? leoprikler: R8RS when? jcowan: manumanumanu: Owl Lisp is an immutable Scheme (modulo I/O) drakonis: Guile 4 when? jcowan: leoprikler: I sure don't know; after I'm dead most probably. For sure I won't be leading it manumanumanu: dsmith-work: something like that. I would definitely vote for having to write "please" often enough to make it compile like in intercal. manumanumanu: "immutable strings with manners" manumanumanu: Good night! dsmith-work: I've been learning/using Rust quite a bit lately, and the way they do strings feels right. Maybe it's just because I'm used to it? dsmith-work: Internal is all utf8. Os things (filenames, etc) are Os-specific. Iterate over strings, no direct idexing. The differece between a String and a &str was weird at first, but makes sense dsmith-work: Of course they have the luxury of no historical baggage. leoprikler: But in turn, there is Cargo :) tohoyn: sneek: botsnack sneek: :) RhodiumToad: moo taylan: sneek: botsnack sneek: :) ManDay: No macros involved, I get this error 'In procedure car: Wrong type argument in position 1 (expecting pair): #f' on a line which reads merely '(complete-branches pd-branches completion)'. If that's not weird enough, if I make that line read '(complete-branches pd-branches (identity completion))' the error is suddenly marked on the line before (which reads '(if (or (dep.eq? branch (car parent-cp)) ManDay: (member branch downstream dep.eq?))') ManDay: Anyone mind to make sense of this? ManDay: btw: same happens if I put the (identity) around pd-branches. ManDay: well, apparently in the (car) on the line before is #f ManDay: Which explains the problem, but not this weird as hell error message taylan: ManDay: which Guile version is this? ManDay: 3.0.4 ManDay: uh oh, lemme guess, i'm direly outdated? taylan: no that's very recent :) ManDay: oof taylan: so if I understand correctly, the line number of the error is reported wrong? I would file a bug report, ideally after producing a minified self-contained example that showcases the bug. ManDay: ok, fair answer. I was afraid I'd get some intricate explanation why despite all odds reporting weird lines actually made sense :D ManDay: i'll try to strip that down when I have some downtime dsmith: ManDay: Might want to try it on git (or at least 3.0.7). Just to make sure it hasn't been fixed already. ManDay: yeah that's true, i'm sorry you have to point it out ;-/ ManDay: i'll try it first iwan: hello *: dsmith waves iwan: anyone interested in Guile-Elisp here? drakonis: sure why not drakonis: getting guile on emacs, is it? iwan: hmm, more like emacs on guile iwan: I recently submitted two Elisp reader bugs, but no one replied yet :^( drakonis: oh i see lispmacs[work]: hi, I'm trying to create a child process and get textual ports to its input and output. however, with the open-pipe command, it seems that you instead run the process and it inherits your current i/o ports. So, if I keep separate my guile program std i/o from the child process i/o, I guess I need to create some ports first and make them the current i/o ports. But I'm not sure how to go about that iwan: set-current-input/output-ports I guess lispmacs[work]: iwan: that seems like about half the puzzle. but I would need to create i/o ports first...? lispmacs[work]: some string ports...? iwan: maybe file ports? smth in /tmp or /log dsmith: iwan: How manye years have you waited? ;^} lispmacs[work]: iwan: if the process is reading from a file in /tmp, will I have a problem with the process getting an eof when I am not feeding data to the tmp file? iwan: dsmith: for what? lispmacs[work]: i would need to create a FIFO file...? dsmith: iwan: elisp reader bugs you mentioned. dsmith: Often it takes a while before the guile devs get to bugs. Even with patches. dsmith: Usually it's just before a release, there is a flurry of patches applied. iwan: they are pretty easy tho iwan: bugs, not patches dsmith: Just sayin, don't be surprised if no response for days or weeks (or months or..) lispmacs[work]: seems like there must be a better way to do it, but I see now I could create some FIFO files with mkfifo, open them as files, and then open the processes with those set as default ports iwan: can you give a more detailed example? lispmacs[work]: I don't think so pyveteran: Hi iwan: hi! pyveteran: Why should I learn Guile? lispmacs[work]: it seems kind of funny that guile has a built-in function for generator random coordinates for the surface of a sphere. Is there an interesting story behind that...? mfiano: also volume of a sphere lispmacs[work]: is there an easy way to convert a number to a hex string? drakonis: pyveteran: why not lispmacs[work]: built-in? iwan: yep drakonis: also that's a terrible question drakonis: i've seen it a hundred times iwan: (format #f "~x" ...) lispmacs[work]: iwan: thanks! pyveteran: drakonis: ok thanks, I'll try to figure out by myself. dsmith: lispmacs[work]: There is also number->string dsmith: The second arg is the base. lispmacs[work]: dsmith: okay, thanks, I didn't know that one had a radix parameter dsmith: But if you want more control, format lispmacs[work]: MORE CONTROL!!!! apteryx: uh; (mkstemp! "/tmp/dbus-send-output-XXXXXXX") -> string is read-only: "/tmp/dbus-send-output-XXXXXXX". Am I using it wrong? forthmacs[work]: wha HA HA! dsmith: apteryx: Yes. A string literal is read-only. drakonis: pyveteran: to be fair, its such a common question that people expect to be answered by simply waltzing into a channel and hoping for a satisfying answer apteryx: dsmith: according to http://osr507doc.sco.com/cgi-bin/info2html?(guile.info.gz)File%2520System&lang=en, mkstemp! takes a TMPL, which should be a string apteryx: ah, perhaps mutable string objects are a thing, I've never used those. dsmith: scheme@(guile-user)> (mkstemp! (string-copy "/tmp/dbus-send-output-XXXXXXX")) dsmith: $2 = # apteryx: I see! Thanks. dsmith: apteryx: A string literal is immutable. (or should be!) iwan: @dsmith have you ever contributed to emacs or guile? dsmith: I've submitted a few small patches over the years. Long ago, contributed a patch to dos emacs so it could use the windows clipboard. iwan: your nickname seems familiar, but I can't remember where I saw it dsmith: Well, "smith" is a *very* common name. iwan: yeah, I know, maybe I just remembering time when #guile was on freenode dsmith: Been there a while. I started when there was about 6 people in the channel. I remember how cool it was to see it double to 12! taylan: heh :) taylan: iwan: I responded to a few Elisp reports recently, dunno if yours was under them iwan: a-ha, your name is the same as nick taylan: iwan: oh, I see you sent a patch earlier today. well I've sent some patches two weeks ago and am still waiting, so better to be patient :P iwan: nice to meet you, Taylan iwan: I was hoping to meet you or Maxime Devos here *: holomorph checks to see how long the wip-elisp branch has been dormant dsmith: There has been some recent activity. bipt has a new nick (can't remember right now) and was on here a few days ago. dsmith: sneek: seen bipt? sneek: bipt was last seen in (here?) 9 months ago, saying: i saw that your guile-emacs package made it into a guix release :). taylan: iwan: happy to hear from another person who's interested in Guile-Elisp. sadly progress is slow, as everyone's quite busy ManDay: Sorry to come back with more traceback trouble, but I can't fathom how guile can simply not mention stackframes. This for example http://dpaste.com/HAR22QBAH drives me mad to have to deal with this all the time. taylan: bipt's new nick is robin, alternatively terpri dsmith: taylan: Ahh yes. Thanks dsmith: sneek: seen terpri? sneek: terpri?, pretty sure was seen in #guix 10 days ago, saying: so far, it's great. dsmith: sneek: seen robin? sneek: Not as far as I can remember. taylan: dsmith: robin is in the channel :D ManDay: How am I supposed to find that error with that kind of debugging information?! ManDay: I'm at a total loss! taylan: ManDay: 'map' takes two arguments. since the (lambda ...) will certainly not be #f, it must be 'pivots' ManDay: taylan: Yes, I realize that has the wrong type. But how am I supposed to find the error?! ManDay: pivot->strings is called all over the place in my code iwan: dude, I have had exceptions during printing stacktrace ManDay: so have I ManDay: (but that was fixed) taylan: ManDay: from the fact that it points at idg.scm line 61, and that this line is the start of the 'map' call, which has two arguments, one of which is evidently #f as the error message says ManDay: taylan: idg.scm line 61 IS that map. that's what I marked in the paste ManDay: but where is pivots->string called from!? ManDay: i can't belive I have to ask that question. are you not familar with stacktraces from normal compilers? taylan: ManDay: isn't it in idg.test.ss line 27? ManDay: taylan: no. line 27 in idg.test.ss calls idg.recurse taylan: is idg.recurse a macro? ManDay: no taylan: oh nevermind, idg.recurse is in the stack trace taylan: ManDay: well the pivots->string call ought to be somewhere in the body of idg.recurse then? ManDay: many many times dsmith: ManDay: How about move that lambda into it's own define. From a repl (or geiser) try feeding it with what you expect the arg to be. ManDay: dsmith that function (pivots->string) is fine. dsmith: There has been a *lot* of work on the compiler lately. Bound to be some bugs. dsmith: AH ManDay: ok, i'll try the master version anyway (tomorrow) ManDay: maybe that'll help it ManDay: dsmith what is geiser? dsmith: Emacs interface to Guile (and some other Schemes) dsmith: It's nice to be able to C-x C-e to evaluate an expression. taylan: not sure if updating from 3.0.4 to 3.0.7 will make much of a difference ManDay: i rather have working stacktraces ;-/ dsmith: Yeah. dsmith: Hmm. taylan: ManDay: is the code uploaded somewhere? ManDay: nah ManDay: there is a macro involved, though taylan: I'd like to understand better what's going on... dsmith: I wonder if using less optimization would provide better backtraces? ManDay: it encapsulates the entire body of idg.recurse ManDay: dsmith I've written that thing, I ll try it : http://dpaste.com/ELNB5TP3T ManDay: Not sure what else I can do to prevent optimization taylan: could you paste the entirety of idg.scm and idg.test.ss? ManDay: ironically, the macro which encapsulates the body is there to help me debug... ManDay: taylan: you mean in a state that you can run it? or just look at it? taylan: just look at it ManDay: ok, one sec taylan: the state that produced that error would be ideal of course :) ManDay: idg.test.ss is really nothing though dsmith: There is a way to pass an -O1 or -O2 to guild compile. Not sure if there is a way to do that within a repl. ManDay: can't one upload file to github gists? ManDay: dsmith I'm not using the repl. taylan: gist works, any pastebin works just as well IMO iwan: termbin.com is my favorite ManDay: i want the paste to disappear after a while dsmith: sneek: paste? sneek: Someone once said paste is https://paste.debian.net dsmith: I think that one goes away after a while. iwan: it'll disappear after one month ManDay: i set it to 1 h ManDay: https://paste.debian.net/hidden/7dffd798/ ManDay: by then we'll have that figured out either way :-P ManDay: see the dbg-* macro at the beginning ManDay: that's the only non-functional or macro thing there is ManDay: idg.test.ss coming right up taylan: this is not the state of the file when that stack trace was produced though, right? ManDay: https://paste.debian.net/hidden/4aedcfb8/ ManDay: taylan: yeah, line numbers don't match ManDay: l61 -> l31 taylan: did you mean 37? ManDay: ah yeah, my eyes... taylan: no problem. so, I think pivots->string might be getting inlined or something... taylan: it's certainly a crappy stack trace, no argument there ManDay: thanks ^^ ManDay: i just wish I could turn off all those optimizations ManDay: so I guess I'll have to try guild manually ManDay: gosh, I wish `guile` could simply pass -O0 to guild taylan: you could also see what the interpreter does, by executing the file like 'guile --no-auto-compile foo.scm' after deleting the cached .go file ManDay: since compiling it isn't as easy as `guild compile idg.scm` I think I'll postpone this entire operation to tomorrow (which starts in about half an hour anyway) taylan: ManDay: it should be as easy as that, actually taylan: possibly with an -L thrown in there, just like when executing the file with 'guile' ManDay: ah yeah -L was needed ManDay: ty taylan: and you might want to add a check for the 'pivots' argument to the beginning of pivots->string to give a marginally better error ManDay: ooooh ManDay: that's much better now! ManDay: 142:2 3 (idg.recurse ((# . #)) …) taylan: like (when (not pivots) (error "pivots->string called on #f")) ManDay: 148:46 2 (vary-conjunctions -1 #f) ManDay: 61:2 1 (pivots->string #f) taylan: yeah I guess a lot was being optimized out there! ManDay: i'll file a bug for guile to accept -O0, this seems awefully important ManDay: thanks a lot! ManDay: i had tried to disable optimizations in the case of messy stacktraces in the paste but it had not helped taylan: there might be an environment variable for that, lemme check... ManDay: i didn't expect improvement this time ManDay: *in the past taylan: hmm I think there was just an env var to force fresh recompilation ManDay: yes, i have also searched for any method to pass -O and didn't find any ManDay: everything works now. many thanks!!! taylan: can't even find that now, maybe I was dreaming. anyway, I guess an option to 'guile' and/or an env var to determine the optimization level might be good. taylan: yw! ManDay: gn dsmith: ManDay: What made it work? Disableing optimizations? dsmith: Ah, left mattrw: sneek later tell ManDay I used to effectively set -O0 in guile using https://paste.debian.net/1199535/ and running (noopt) but I think that broke recently (3.0.X, X > 2 ??) sneek: Okay. mattrw: leoprikler: got it -- thanks topoi: When using (string-match "\." ".") I get the error "illegal character in escape sequence: #\." - doesn't "." need to be escaped with "\"? topoi: ^-- Ohh, nevermind; "\" itself has to be escaped. ; ) topoi: But I'm not exactly sure why (c. https://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Backslash-Escapes.html ) apteryx: any idea why waiting for a pid from Shepherd's fork+exec-command (from the (shepherd service) module) takes multiple seconds? ,time (let ((pid (fork+exec-command '("sh" "-c" "echo 'hello!'")))) (waitpid pid)) --> ;; 2.436732s real time, 0.013448s run time. 0.000000s spent in GC. apteryx: 2.43 s to fork a shell and print hello, every time alextee: how does guile compare to clojure? ahungry: clojure ecosystem, having all of maven/the jvm available, and npm/nodejs, is quite a bit bigger. Syntax wise, I like clojure, but guile/scheme has some beauty in it's simplicity daviid: alextee: see https://git.sr.ht/~rlb/lokke alextee: hmm alextee: being able to use java libraries sounds pretty nice daviid: alextee: if that's what you want, then imo, kawa is much better then clojure - here i just wanted to point 'to the existence of lokke' alextee: thanks, I'm just looking for a web dev language to learn and stumbled upon clojure. I think I'll focus on the popular ones that have more support, like clojure. guile seems like it's great for C integration but I'm not sure how powerful it is for web dev (considering there's not too many popular libraries) flatwhatson: any thoughts about vectorization/SIMD support for guile? i guess it would need to start with teaching lightening to emit the instructions? leoprikler: apteryx: it looks like you're setting up a shell within a shell, how long would it take to just run "echo hello"? apteryx: 0.12 s or something apteryx: I had checked apteryx: the hello comes out quickly but the waitpid seems to linger emestee: what'd be the nicest way to represent two dimensional coordinates? '(x y)? (x . y)? RhodiumToad: is it always going to be 2 dimensions? RhodiumToad: (x . y) is one cell while (x y) is two, so there's some advantage in the first; but a record might be preferable b4285: a list is a container for isomorphic element, so i'd go with tuples, i.e. (x . y) b4285: i don't know what i am talking about, shouldn't use the word "isomorphic" RhodiumToad: there's probably a good argument for using immutable records for something like that taw10: Arguably it doesn't matter, because the real representation should be abstracted away anyway? Start with a single cons cell, then switch to something like a GOOPS class if/when you realise that you want to have other ways of accessing the value, e.g. polar coordinates (c.f. SICP section 2.4)? RhodiumToad: hmm. the docs say that immutable records can't be mutated even via struct-set!, but the code says they can be RhodiumToad: define-immutable-record-type is a bit simpler than defining your own set of abstract accessors for a cons cell emestee: thanks! RhodiumToad: of course for two dimensions you could also just use a complex number ArneBab: emestee: '(x . y) uses less memory than '(x y) or a two-element record, you might want to benchmark (1 . 2) and the record. ArneBab: simple starting point: ArneBab: ,time (let loop ((s 100000000) (v '(1 2 3 . 4))) (when (not (zero? s)) (cdr (cdr (cdr v))) (loop (- s 1) v))) ArneBab: (import (srfi srfi-9)) ArneBab: (define-record-type (v a b c d) v? (a va) (b vb) (c vc) (d vd)) ArneBab: ,time (let loop ((s 100000000) (vt (v 1 2 3 4))) (when (not (zero? s)) (va vt) (loop (- s 1) vt))) ArneBab: emestee: '(x . y) uses less memory than '(x y) or a two-element record, you might want to benchmark (1 . 2) and the record. ArneBab: simple starting point: ArneBab: ,time (let loop ((s 100000000) (v '(1 2 3 . 4))) (when (not (zero? s)) (cdr (cdr (cdr v))) (loop (- s 1) v))) ArneBab: (import (srfi srfi-9)) lampilelo: just use dpaste or something like that ArneBab: lampilelo: if it had been more lines, I would have. for 4 lines I prefer having them in the history lampilelo: the formatting though... emestee: thanks I am going to experiment with this emestee: I assume cdr for a tuple would be slightly faster too? chris: emestee: profiling is the only way to answer. guile devs will usually optimize code iff profiling supports it. chris: mostly you'd be better off using a srfi-9 record chris: (for code readability) ArneBab: emestee: (cdr '(a . b)) => b; (car (cdr '(a b)) => b ; that is the speed difference lampilelo: was this missed by the maintainers? https://lists.gnu.org/archive/html/guile-devel/2021-04/msg00008.html lampilelo: IF it's confirmed to work, seems like a no-brainer, the person that posted it will probably use it dsmith: lampilelo: Never heard of arc before. Is it old? stis: Hello guilers! apteryx: what could couse such autoload failures? ;;; Failed to autoload %precious-signals in (shepherd service): apteryx: cause* apteryx: ;;; In procedure resolve-interface: no binding `%precious-signals' in module (shepherd service) civodul: o/ sneek: Welcome back civodul, you have 2 messages! sneek: civodul, apteryx says: hey! I was wondering what happens with autoloaded modules w.r.t. to 'source-module-closure'? Seems they might not be added? I've been debugging a problem when I lazy bind (shepherd service) and something seems amiss. sneek: civodul, apteryx says: ah, I see extract-dependencies in (guix modules) has a case to cover #:autoload civodul: apteryx: that suggested the (shepherd service) module that was loaded lacks '%precious-signals' civodul: maybe because it comes from an older version? civodul: 'source-module-closure' takes #:autoload into account apteryx: could be, I'm replaying a service start slot 'by hand' with my root user, it's not exactly a tightly controlled environment civodul: note the default #:select? of source-module-closure, though civodul: heh, i love that kind of debugging civodul: adventure and risks :-) apteryx: I wanted to do the same in a VM corresponding to the right environment, but http://issues.guix.gnu.org/48739 prevents SSH'ing, so I'm struggling to debug :-) civodul: the qemu syntax for port forward is terrible apteryx: the qemu syntax *for anything* I'd add ;-) civodul: right! civodul: ffmpeg too apteryx: it seems purely designed as the low-level engine of higher level interfaces such as virt-manager, and it shows civodul: (funnily, both started by the same person :-)) civodul: so i'd copy the syntax from our code civodul: which is Known Good *: apteryx checks apteryx: seems strictly equivalent; mmh apteryx: perhaps QEMU is sensitive to the order in which options are given chrislck: anyone remembers OPEN "COM1:300,N,7,1"? chrislck: guile doesn't even have a (CLS) taylan: sneek: botsnack sneek: :) lampilelo: did mwette stay behind on freenode? taylan: lampilelo: he asked on the ML for assistance, ERC related issues I think lampilelo: i see lampilelo: i'll reply to him dsmith: I mentioned to him he needed to register his nick lampilelo: i have some more info because the current version of erc doesn't really know what libera is so there are some issues dsmith: I've been using erc, but have beem msg'ing nickserv by hand. dsmith: Prob should tune that up lampilelo: i'm writing the email, you should read it too in that case lampilelo: lol, i think i sent it just to him, not to the mailing list lampilelo: dsmith: i uploaded an excerpt from the mail: http://dpaste.com/EQAEJ9HSB lampilelo: for your nickserv issues dsmith: lampilelo: Thanks! dsmith: Yey lampilelo: emacs 28 will fix it, i believe dsmith: I'm using ERC with GNU Emacs 26.1 (x86_64-pc-linux-gnu, GTK+ Version 3.24.5, multi-tty) of 2021-01-30. mattrw: Hi All. This is Matt, formerly mwette. dsmith: Not even on 27 yet lampilelo: now to figuring out how to send mails to the mailing list with gnus using gwene nntp, is it possible even? dsmith: mattrw: wb! lampilelo: mattrw: did you get my email? mattrw: thx! lampilelo: you got here oddly quick philip: Is it possible in Guile to restrict the effect of read-hash-extend to a certain dynamic extent, say with dynamic-wind? In Racket, I would parameterize current-readtable. mattrw: I found https://libera.chat/guides/registration lampilelo: dsmith: you're using debian? i think ubuntu already has 27 dsmith: Yep Debian. mattrw: I'm on Ubuntu 21.04 and it has emacs 27.1 lampilelo: mattrw: ah, ok, i sent you an email with some workarounds for erc and libera, but for some reason it was off mailing list mattrw: lampilelo: I got your email. Thanks. I'm just using libera now, and things are working so hoping it stays that way. Thanks for the help. lampilelo: mattrw: actually i was asking about you earlier because i tried to play with nyacc and had some issues with it mattrw: You're not alone. :) dsmith: philip: Pretty certain read-hash-extend is a global setting. However Guile now has in recent changes a Scheme based reader insted of a C reader. So who knows, maybe that change. lampilelo: mattrw: for a function taking a struct, not a pointer, it made a function that takes a nyacc version of that struct and destructuring it internally to a bytevector but then throwing an error because the internal function wanted to have the bytevector by pointer, not by value dsmith: that can change lampilelo: is this a known issue? lampilelo: (i'm talking about the ffi functionality) mattrw: So, I'm not sure exactly. If the C function takes a struct (by value) then the fh-link-proc should be using a (list xxx) for the struct arg, not a '*. That may be broken in pre-1.04.0 but I hope working. mfiano: Hello all lampilelo: mattrw: the generated code's internal function has this as the argument list (list (list ffi:uint8 ffi:uint8 ffi:uint8 ffi:uint8)), but when ((fht-unwrap Color) color) is passed to it breaks, but it works if you wrap it with pointer-to lampilelo: hi mfiano mattrw: Ah. OK. The signature is OK but looks like the unwrapper is not working. mfiano: Never used a Scheme before, but somehow spent the day reading the Guile reference guide. mattrw: mfiano: maybe this: https://www.scheme.com/tspl4/start.html#./start:h0 lampilelo: mattrw: unwrapper returns a plain bytevector with all of the data from the struct mattrw: Hmm. So I wonder if I need to use Guile's make-c-struct. That would be sad. mfiano: I will probably get more from the manual. There seems to be a lot of overlap with Common Lisp in those getting started guides. mfiano: I should have mentioned I've been using CL exclusively for the last 20 years or so mattrw: lampilelo: and I just found another bug in the passing struct stuff. mattrw: lampilelo: added as bug #60697 lampilelo: and also i discovered the existance of c99-std-help the really hard way - the library included - imagine trying nyacc for the first time and getting some weird syntax errors lampilelo: mattrw: thanks lampilelo: nyacc is neat mattrw: lampilelo: maybe only bytevector->pointer is needed. Can you try that? mattrw: (Meaning just hack the .scm output file just to see if it works.) lampilelo: i can check it, but give me a moment lampilelo: mattrw: bytevector->pointer works, just like pointer-to lampilelo: are they different? mattrw: yes. Full fix maybe this easy: mattrw: --- a/module/system/ffi-help-rt.scm mattrw: +++ b/module/system/ffi-help-rt.scm mattrw: @@ -321,7 +321,8 @@ mattrw: (define type mattrw: (make-fht (quote type) mattrw: (lambda (obj) mattrw: - (bytestructure-bytevector (struct-ref obj 0))) mattrw: + (bytevector->pointer mattrw: + (bytestructure-bytevector (struct-ref obj 0)))) mattrw: (lambda (val) mattrw: (make-struct/no-tail type (bytestructure desc val))) mattrw: #f #f mattrw: Noisytoot: mattrw: use a pastebin (like bpa.st or paste.debian.net) mattrw: Noisytoot: thanks -- usually do, senior moment mattrw: lampilelo: pasty: https://paste.debian.net/1199323/ lampilelo: mattrw: you should ask on #libera about recovering your nick, it will probably expire since you didn't confirm the registration lampilelo: i'll try that patch mattrw: lampilelo: thanks. *: mattrw afk for a bit lampilelo: mattrw: it works now but you forgot to add ffi: prefix to bytevector->pointer linas: So running ChanServ on this channel is intentional? Because when I try to msg chanserv, all the responses come back here, mo matter where I started... linas: anyway, hello libera-world linas: and a few exclamation marks of approval drama!! RhodiumToad: that's probably something weird about your client RhodiumToad: chanserv is here because (for whatever reason) the GUARD option is set on the channel linas: OK, thanks! the drama of onboarding... emanuele6: wingo: I just found out libera.chat hosts an instance of kiwiirc at https://web.libera.chat/ RhodiumToad: that's new, I think wingo: emanuele6: neat! emanuele6: yeah, I think it's new tohoyn: new version Theme-D-Golf 0.9.2 has been released. see http://www.iki.fi/tohoyn/theme-d-golf/ leoprikler: Is it difficult to generate Theme D bindings from scheme or is it rather straightforward? tohoyn: leoprikler: you mean accessing guile procedures from Theme-D code? leoprikler: yup, more or less tohoyn: leoprikler: it's easy. tohoyn: leoprikler: here is the definitioj of Theme-D procedure d-car that is implemented by guile procedure car: (define d-car (unchecked-prim-proc d-car () pure)) tohoyn: leoprikler: the first is the argument type tohoyn: leoprikler: the second is the result type leoprikler: and pure vs. nonpure is whether they change state tohoyn: leoprikler: "pure" means that the procedure has no side effects tohoyn: leoprikler: yes leoprikler: can it deal with arbitrary arities? leoprikler: e.g. format tohoyn: leoprikler: yes tohoyn: leoprikler: here is an example: (define string tohoyn: (unchecked-prim-proc string ((rest )) pure)) tohoyn: leoprikler: procedure string takes an arbitrary number of characters as arguments tohoyn: leoprikler: "unchecked" means that Theme-D compiler/linker does not generate code to check that the result value is of correct type. leoprikler: can it do (and (* ( )) (rest ))? leoprikler: or do I just have to write (rest ) and let it be caught at runtime? tohoyn: leoprikler: what are you trying to define? leoprikler: The return value of this baby: https://gitlab.com/leoprikler/tsukundere/-/blob/0.3.x/tsukundere/entities/person.scm#L76-90 leoprikler: I guess would be fine, but still tohoyn: what are the argument types and the desired result type of this procedure? leoprikler: the procedure gets an and returns a procedure leoprikler: Functional programming with side-effects :D tohoyn: leoprikler: you can define procedure types in Theme-D tohoyn: leoprikler: see https://paste.debian.net/1199199/ for an example tohoyn: leoprikler: procedure map1 applies the argument procedure to the argument list tohoyn: leoprikler: what are the argument and result types of the returned procedure? are they arbitrary? leoprikler: pseudo-arbitrary leoprikler: it's a keyword-value list followed by optional string + rest (rest is just a bool atm, but not important) tohoyn: leoprikler: (declare myproc (:procedure () (:procedure ((rest )) nonpure))) tohoyn: leoprikler: it's ok if you pass the keyword-value list as one argument leoprikler: it's many args tho :P tohoyn: leoprikler: I'm afraid that can't be done leoprikler: okay, so I'll still have the work inside the match-lambda leoprikler: what's the difference between declare and (define d-car ...) btw? leoprikler: could I "use-modules" a guile module and then just put a bunch of declares and be done with it? tohoyn: declare declares a procedure and it is used mostly in interface files (each module has an interface and body) tohoyn: leoprikler: you have to tell the Theme-D linker to generate code to include your guile module in the Theme-D program tohoyn: leoprikler: then you have to put the declare's into the interface file and the correspoding define's into the body file leoprikler: speaking about linker, what does theme-d compile to? tohoyn: leoprikler: guile Scheme or Tree-IL leoprikler: is it theoretically possible to write a theme-d header for a scheme body? leoprikler: i.e. omitting the theme-d body? tohoyn: leoprikler: no, you have to define the procedures as "prim-proc" or "unchecked-prim-proc" tohoyn: leoprikler: but it would be quite easy to write a program to generate the body tohoyn: leoprikler: actually Theme-D-Golf resembles that tohoyn: leoprikler: the interface and body files are generated from a "Golf import" file tohoyn: leoprikler: then Theme-D-Golf has a third script that generated a guile module to be included (use-modules) in the target program tohoyn: ^generates dsmith-work: Happy Friday, Guilers!! civodul: hey dsmith-work! civodul: happy Friday! chrislck: happy Friday, in this new home *: sneek dances apteryx: how do I return all the matches for a given regexp pattern in a string? civodul: apteryx: there's a fold-matches procedure apteryx: thanks! will read on it apteryx: oh, I see a list-matches too apteryx: neat apteryx: Would someone be able to tell why the following service fails with: Unbound variable: pattern ? Perhaps the and-let* syntax is somehow not made available? Otherwise I fail to see it. https://paste.debian.net/1199223/ RhodiumToad: apteryx: I don't see anything that imports and-let* ? RhodiumToad: needs (srfi srfi-2), no? apteryx: oh! I thought I added that... but it's indeed missing. Let me regenerate that (it's created by a Guix G-Expression) to make sure. Thanks! apteryx: ah! I see my mistake; I added (srfi srfi-2) to the wrong service. eh. Sorry and thanks again for lending me your eyes :-) civodul: apteryx: i suggest avoiding srfi-2 in Guix :-) civodul: granted, it's a matter of taste RhodiumToad: why avoid it? civodul: RhodiumToad: like i said, it's a matter of state; i find i'm usually better off with 'match' and sometimes 'and=>' leoprikler: match and and=> work super if you have a common source, but are somewhat clunky if you're dealing with inputs coming from multiple places leoprikler: though in the specific case of Guix, that ought to be rare RhodiumToad: I've used it in cases that basically amount to: compute a value, check its range, compute a further value from it, check that RhodiumToad: (and then do something if everything was valid) apteryx: right, that makes sense to me, but perhaps it's more procedural in style than functional leoprikler: yup, Guix tries to be very functional indeed lispmacs[work]: hi, I am wanting to write a guile program to interact (RX and TX) with some firmware I have running on an Arduino board, through a ttyACM connection (UART over USB). i.e., to do stuff you would normally have to type into minicom. I was wondering if Guile has some kind of support for serial communications, or if I try piping things in and out of the modem program, or if there some better approach... lispmacs[work]: s/if I try/if I should try/ RhodiumToad: bidirectional piping to a subprocess is very difficult to do cleanly without deadlocking RhodiumToad: it should be possible to handle the serial port directly from guile without too much difficulty lispmacs[work]: RhodiumToad: how do I handle the baud rate settings and such from Guile? RhodiumToad: hm, tcgetpgrp etc. are present, but not tcgetattr/tcsetattr RhodiumToad: seems an odd omission RhodiumToad: you could always spawn the stty command for that RhodiumToad: or use the FFI to call tcsetattr dsmith-work: For serial stuff in general (but it seems to be mostly usb serial these days), I like to use ser2net. Yeah, you must edit a config file. dsmith-work: I usuallly have different ports for different baud rates. dsmith-work: (ser2net maps a serial port to a socket) dsmith-work: And then I just telnet or nc to that port. dsmith-work: As a bonus (or sercurity hole) I can than get to get serial port from anywhere in the network. dsmith-work: s/get to get/get to that/ dsmith-work: I used that almost daily to talk to linux serial consoles or other embedded devices with a uart. dsmith: Offtopic quesiton: What could possibly cause a ping to not see replies yet I can see the replies in tcpdump? prite: dsmith: iptables/nftables rules? dsmith: Yeah, that's where I went first. But I think everything is set to allow. My iptables-fu is weak however. *: dsmith prefers openbsd pf tohoyn: wingo, dsmith: I think that -Werror would be useful, too tohoyn: wingo, dsmith: it would be also useful to be able to declare warnings for errors for individual warnings separately tohoyn: ^warnings as errors clacke: The problem with -Werror is that different versions of a compiler have different warnings, so builds with an upgraded compiler will suddenly start failing, right? clacke: maybe it would be reasonable to enable explicit errors in git, but add -Werror in CI? dsmith-work: Thursday Greetings, Guilers dsmith-work: sneek: botsnack sneek: :) taylan: heya tohoyn: daviid: is it possible to build G-Golf for Guile 2.2 even though Guile 3.0 is installed in the system? tohoyn: daviid: Guile 3.0.7 has not yet been published in debian. that's why I don't want to build the debianized G-Golf package for Guile 3.0.7. daviid: tohoyn: yes, even with 2.0 unknown_lamer: dsmith-work: I guess adding dual network support to sneek would have been a waste of time after all ;) (rip freenode) tohoyn: daviid: how is it done? daviid: tohoyn: look for GUILE#_PROGS in guile-ext.m4 daviid: * GUILE3_PROGS tohoyn: daviid: I tried the following: GUILE=/usr/bin/guile-2.2 ./configure --with-guile-site=yes tohoyn: daviid: result: configure: error: found development files for Guile 3.0, but /usr/bin/guile-2.2 has effective version 2.2 daviid: tohoyn: yes, you need more env var (re)def when you have //install... tohoyn: daviid: I set GUILE_EFFECTIVE_VERSION=2.2. ./configure works now. tohoyn: daviid: BTW, does G-Golf use gtk-4 by default? daviid: tohoyn: no, which version is used is determined by which are available and GI protocol, that is it will import the latest, unless you require/pass a specific #:version optional kw value tohoyn: daviid: ok flatwhatson: probably need to update the "#guile on Freenode" on https://www.gnu.org/software/guile/ dsmith: unknown_lamer: Yeah taylan: does anyone know who controls the website? taylan: there's been a dead link on http://www.gnu.org/software/guile/manual/ for years now :D wingo: dsmith-work: like, an option that would make "guild compile" fail if there were a call that is known to have the wrong arity? wingo: actually -Werror would be nice... wingo: the web site is modifiable by any project contributor, technically wingo: is the dead link on /manual/ the postscript file? wingo: that page is generated by gendocs.sh; we probably need to update ours taylan: yeah it's that one, also subject of this report: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15536 taylan: I've been trying to do a bit of housekeeping on debbugs and that one annoyed me for being so minor and yet unresolved for ... *checks* ... about 8 years :D RhodiumToad: the link to freenode is probably a more urgently required fix :-) RhodiumToad: (for those not aware, #guile on freenode got killed a few hours ago) wingo: is there a web irc client that new irc users could use to access this channel? emanuele6: kiwiirc.com works RhodiumToad: looks like libera doesn't have its own web client (yet?), probably it's not at the top of their priorities list right now wingo: i guess i will update the web site without a link to some web client wingo: (kiwiirc claims to be sponsored by PIA -- isn't that related to the entity that took over freenode?) emanuele6: oh, i did not know that wingo: dunno, that was an old sponsorship note emanuele6: they have libera.chat on the default server list though RhodiumToad: sponsored by, but afaik still independent of - more serious is that the kiwiirc project lead (prawnsalad) is quitting over the whole incident RhodiumToad: https://gist.github.com/prawnsalad/4ca20da6c2295ddb06c1646791c61953 wingo: (i am not against sponsorship fwiw, just that it seems that PIA is... not good) wingo: wow this thing is high drama :) *: wingo avoids looking into it any more :P wingo: ok web site updated fwiw wingo: tx emanuele6 for kiwiirc suggestion emanuele6: you are welcome :) tohoyn: daviid: is there any way to find out what is the default gtk version that g-golf uses? tohoyn: daviid: i.e. what gtk version g-golf uses if #:version is not specified opfez: i'm having a problem with alists. if i have a file "f.scm" which contains a definition for an alist (define a '(("foo" . 1))) i cannot change the value if i load it via (load "f.scm) opfez: (assq-set! a "foo 2") just adds a new entry: '(("foo" . 2) ("foo" . 1)) opfez: are alists loaded from another file immutable, and how can i make them mutable? tohoyn: daviid: I made a new debianized release of G-Golf. See http://www.iki.fi/tohoyn/g-golf-debian/. RhodiumToad: opfez: the use of assq-* functions means you're expecting the keys to be eq? rather than equal? RhodiumToad: opfez: and strings are not eq? to other strings with the same content except by chance opfez: RhodiumToad: if i later do assq-set! on the new alist, it correctly changes the value opfez: it correctly changes the value of the new entry, but i want to change the value of the old entry RhodiumToad: opfez: I think what you're finding is that two string literals in the same compiled file refer, by chance, to the same actual object and are thus eq? opfez: i'm testing this in the repl RhodiumToad: opfez: but this is an implementation artifact and therefore your code is incorrect tohoyn: opfez: try (define a (list (cons "foo" 1))) opfez: i will RhodiumToad: bottom line is that you should be using assoc- and not assq- functions RhodiumToad: or use symbols rather than strings as keys opfez: RhodiumToad: i did use assoc- before, and it gave me an error: set-cdr! expected a mutable pair opfez: tohoyn: hm that doesn't work unfortunately RhodiumToad: ah, that's a different issue tohoyn: opfez: try to use assoc-xxx instead of assq-xxx together with my previous suggestion RhodiumToad: by defining the alist as a literal list, it's being made immutable by the compiler opfez: ah now it works opfez: thank you RhodiumToad and tohoyn ArneBab: The new freenode owners zapped the #guile topic. I’m glad we moved here. civodul: ArneBab: are there still people there? RhodiumToad: they zapped the whole channel, really RhodiumToad: #guile is now invite-only and moderated, when I left it still had people in it but nobody could say or do anything civodul: woow RhodiumToad: on join, #guile redirects to ##guile now RhodiumToad: ~8 people in ##guile RhodiumToad: (which has no owner or ops) emanuele6: if it has no owner why does #guile redirect to ##guile? civodul: seen on the fediverse: "andrew lee just seized over 700 channels on freenode because they mentioned libera.chat in their topic." RhodiumToad: emanuele6: it's to take it out of the reserved topic namespace emanuele6: oh, it says that the founder is freenode-placeholder-account ArneBab: civodul: yes, many. clacke: whether PIA is sleazy needs to be evaluated on its own merits; LTM, which owns Freenode Ltd, sold PIA two years ago lampilelo: afaiu the number 700 is an arbitrary estimate, it's just the number of channels that mentioned libera in their topic, there's no concrete evidence all of them got cancelled lampilelo: at least i haven't seen one yet lampilelo: test lampilelo: i joined the channel as a guest from kiwiirc and the messages from it don't show up and there's no indication in the kiwiirc client that's the case, what if a noobie joins by clicking the link on guile's webpage and tries to ask a question? daviid: tohoyn: as sais earlier, there no 'default' version, it will import the latest installed on the system it's being used on, unless passed #:version ... daviid: tohoyn: you may list available versions, see (g-irepository-enumerate-versions namespace) daviid: here, scheme@(guile-user)> (g-irepository-enumerate-versions "Gtk") -| $2 = ("2.0" "3.0" "4.0") daviid: tohoyn: tx for the updated g-golf debian package daviid: tohoyn: https://www.gnu.org/software/g-golf/manual/html_node/Repository.html#Repository tohoyn: daviid: I built the new g-golf package against gtk-3 because libgtk-4 is currently in the experimental distribution. daviid: g-golf doesn't require gtk daviid: to build tohoyn: daviid: ok tohoyn: daviid: what about the test cases in g-golf? daviid: as tested here, they pass using any of gtk2, 3 or 4 - tohoyn: daviid: anyway, the g-golf debian package has currently a dependency to libgtk3 daviid: you should remove the dependency - what about someone want to try gtk4 ... leoprikler: I think the question is how to handle the case, when no Gtk is available at build time (more exactly during `make check`) leoprikler: Does g-golf handle that gracefully? tohoyn: leoprikler: test cases work but they required two patches to pass tohoyn: leoprikler: the patches were required in order to get test cases pass during the debian package build tohoyn: leoprikler: one patch is for using xvfb to run the tests daviid: i'll change the test suite - later on, have other priorities now ... - not to depend on gtk, nor clutter ... but you should _not_ make it depend on gtk3,nor clutter to build ... anyway,afk, bbl tohoyn: daviid: I'll work on that tohoyn: leoprikler: another patch was about removing a test case involving a TTY tohoyn: daviid: as long as the test cases depend on GTK it has to be in the dependencies tohoyn: daviid: but I'll change the dependencies so that libgtk4 is accepted, too tohoyn: daviid: ok? tohoyn: daviid: actually it should be sufficient to have the GTK and Clutter dependencies only in the Build-Dependencies daviid: not the build dependencies, the test dependencies daviid: these are pre-rebuild pkg, not official releases ... and that the test requires a gtk typelib is 'a thing', making it a specific version is 'wrong' tohoyn: what do you mean by test dependencies? Is there such a field in the Debian control file format? wingo: lampilelo: weird! happy to switch web irc links if we find one that works daviid: tohoyn: just not make the build depend on gtk nor clutter lampilelo: wingo: can people that are not logged in talk on this channel? i used just the default nick and didn't identiy tohoyn: daviid: since this is a pre-build package it should be ok to disable the tests during the Debian package build. Otherwise the package will not build unless gtk and clutter are not in the build dependencies. tohoyn: daviid: shall I disable the tests in the package build? wingo: lampilelo: no idea -- i am not an irc expert :P wingo: i don't think chanserv needs to identify you, if that's the question lampilelo: me neither, the last time i owned an irc channel was like 13 years ago daviid: tohoyn: yes, the pre-official deb package should not impose any of gtk and clutter ... tohoyn: daviid: ok lampilelo: hmm... maybe civodul knows more about it? tohoyn: daviid: changes done. dsmith: wingo: Yeah, -Werror might help that. And -Werror is a good thing to have anyway. dsmith: It's there an irc scheme for urls? Like irc://irc.libera.chat ? dsmith: ircs://irc.libera.chat/#guile taylan: hmm yeah, guile-guest can't speak. I had muted unregistered users on the first day of creating this channel because there was extreme spam due to the Freenode drama, it's probably that taylan: "Channel #guile modes: +ntz" I can never remember these mode letters... taylan: strange, according to https://libera.chat/guides/channelmodes none of those should mute unregistered users. dsmith: taylan: Weren't those spambot promoting freenode? taylan: yeah something like that. they were spamming "this channel has moved to freenode" in all-caps on repeat, like that's going to convince people :P dsmith: Ya. taylan: hmm, guile-guest can message #guix but not here, even though #guix also has +ntz set (and also C and c which seem irrelevant) taylan: also can't message #scheme which has the exact same flags as here. maybe the C or c flag on #guix does make a difference somehow. roptat: civodul, wingo you probably want to set a few more flags on #guile: it has PUBACL currently, whereas #guix has SECURE KEEPTOPIC TOPICLOCK GUARD PUBACL civodul: roptat: i'm a complete noob: what do we have to type? :-) roptat: /msg ChanServ set secure on roptat: and same for the other flags roptat: you can learn more about these flags with /msg ChanServ help set civodul: roptat: thanks, i think we're good now! taylan: the guest user still can't send messages taylan: roptat: ^ any insight on that? it can send to #guix but not here dsmith-work: Hey Hi Howdy, Guilers dsmith-work: https://libera.chat/guides/channels#why-cant-i-talk-in-a-channel dsmith-work: How do you contact a staffer? I'm not seeing that anywhere. dsmith-work: In #libera I guess leoprikler: Nice, #guile now has as many users here as in the compromised server dsmith-work: leoprikler: #guile or ##guile? I tried to connect earlier today and ##guile had about 8 nicks in it. dsmith-work: #guile was up to about 160 or so before the drama started, right? leoprikler: #guile dsmith-work: s/#guile/freenode #guile/ dsmith-work: leoprikler: are you in there? Can you invite me? leoprikler: just left dsmith-work: heh tohoyn: what's the problem with #guile? leoprikler: We were naughty and redirected people to Libera dsmith-work: Oh the drama roptat: taylan, I think I don't see all the flags/options, so to me the two channels look the same roptat: or I'm not looking at the right thing roptat: civodul, taylan I think you'd need to set -m on this channel roptat: but it doesn't seem to be set, so I'm confused dsmith-work: sneek: botsnack sneek: :) lloda: (check) flatwhatson: manumanumanu: +1 for srfi-197 in guile, i think they'd be particularly useful in guix where you can be chaining a bunch of package transform functions taylan2: tbh I'd rather just use let* or let-values* than learn all these new macros taylan: chain-when looks pretty neat though. although a good 'loop' macro should be able to do it as cleanly. (I never familiarized myself with any of them, like foof-loop.) apteryx: how can I handle an exception by doing some specific action (e.g., re-establish a lost connection), and restart from where the execution failed? I'd need to use some mechanism that doesn't unwind the stack, right? Would the continuation resume by re-attempting the call that caused the error, or would I need to unwind the stack by one step? apteryx: one frame* RhodiumToad: depends how the exception is thrown, I think taylan: apteryx: you could call the operation in a loop, breaking on success or after N attempts apteryx: taylan: right, a retry loop. I was thinking something more unusual such as where the connection problem is detected, throw an error that'd contain the information necessary to fix the connection in place, and resume from there taylan: hmm, I think that would require every possibly-throwing operation to be aware of this mechanism and restart itself after the handler fixes the issue taylan: in the end it will be like a retry loop that's just more granular in where it restarts apteryx: the condition raised could contain the continuation to resume perhaps? apteryx: and when that specific condition would be raised, the handler could reusem it after fixing the problem apteryx: changing topic, is anyone else having issues with ,break-at-source ? It doesn't seem to want to; I'm in a (guix scripts offload) module, I try: ,break-at-source offload.scm 721 (there's a procedure definition on that line) and it returns: "No procedures found at ~a:~a. "offload.scm" 721" maximed: test maximed: apteryx: about non-unwinding exception-handlng: see with-throw-handler or #:unwind? of with-exception-handler maximed: apteryx: also see raise-continuable wingo: moin maximed: wingo: Something I was wondering about the new cross-module inlining: does it work well when cross-compiling? For example... wingo: hoooo very good question! wingo: maybe it should be off in that case. it would inline from the host architecture maximed: ... I have this Scheme file defining O_NONBLOCK, O_PATH, ... flags (actually, they were different flags but whatever) wingo: i hadn't even thought about that maximed: for cross-platform support, I've defined a define-enumeration macro. It looks at %current-target-system. maximed: Something like (define-enumeration O_NONBLOCK #:hurd 9 #:linux 3) (actual values are different) maximed: wingo: I don't think cross-module inlining needs to be disabled altogether (but idk the implementation details). Maybe just check if the .go files we're trying to inline from are for the correct architecture and OS? wingo: we couldn't even load them if they were for the wrong architecture, but for hurd vs linux i dunno wingo: probably i would just turn it off if host and target systems are not the same, at least in the short term maximed: Maybe a CROSS_GUILE_LOAD_COMPILED_PATH is required, to keep the natively-compiled .go (which we'll use for macro's) and cross-compiled (which we'll use for cross-module inlining) separatere maximed: just disabling cross-module inlining when cross-compiling seems good in the short term maximed: wingo: did you receive my patch to guile-fibers? (wait-until-readable-operation or something) IIRC, the last version works and even has some tests and documentation maximed: sent it to guile-user@gnu.org IIRC, also on https://notabug.org/maximed/fibers/commit/08592e01dcbf5ba9d6ee74a2674272790a122352 maximed: I haven't really had an opportunity to use it yet though wingo: i think i saw it but have not been a good maintainer :P wingo: did you not want to re-use the existing epoll for some reason? wingo: like there is schedule-task-when-fd-readable from (fibers scheduler) wingo: which could be a good primitive for the "block" part of the operation wingo: maximed: ^ maximed: wingo: https://notabug.org/maximed/fibers/src/master/fibers/io-wakeup.scm#L75 maximed: I guess the first version did not use schedule-task-when-fd-readable, but the latest version does wingo: ah i see wingo: the select call is a problem tho, as it won't work for fd > 1024... maximed: select does not work for fd > 1024? First time I've heard of that. Is that guile-specific? wingo: nope :) maximed: do you mean ‘number of fds’ > 1024, or the fd > 1024? wingo: http://0pointer.net/blog/file-descriptor-limits.html wingo: i mean fd > 1024 wingo: >= actually wingo: see BUGS in select(2) wingo: of course guile should probably translate its scheme select interface to use poll or something... maximed: Could ‘we’ implement 'select' (the Scheme procedure) with 'poll' (the C system call) in Guile? *: maximed checks if that's done already wingo: would require some more work maximed: wingo: Read NEWS. In ‘Bugs fixed’: ** Prefer poll(2) over select(2) to allow file descriptors above FD_SETSIZE. maximed: Since 2.0.3 maximed: or maybe that's juts (ice-9 poll) maximed: * just wingo: i was looking at the implementation of "select" fwiw wingo: which uses the fd_set data type, which is the data type that has the limit maximed: (ice-9 poll) is not documented unfortunately wingo: thing is, if you are using fibers, there's no issue -- just schedule-task-when-fd-readable in a scheduler in a new thread wingo: checking again for readability doesn't add any safety wingo: right? maximed: The idea is to avoid suspending a fiber if the port is already writable / readable maximed: 'select' seemed convenient for that wingo: but you have to syscall for that wingo: and if you're going to syscall, you might as well use the epoll in the scheduler wingo: dunno wingo: different tradeoffs obviously maximed: latency / performance tradeoff I guess? maximed: I don't have any benchmarks or something. Whatever works I guess wingo: fwiw you can use char-ready? for input wingo: it returns #t even if only a byte is ready wingo: and bottoms out to "poll" maximed: yes but there is no can-write-char? for output. maximed: I guess the (readable? port) and (writable? port) can be removed for now (presuming tests pass) until we have concrete performance figures wingo: i think that's a good option wingo: humm wingo: right, this is for the operations interface... yarr wingo: ok in that case i would use char-ready? for the readable? -- it's strictly better as it is more portable, takes fd > 1024, and returns #t if there is data in the read buffer *: maximed is in what's called the "block" (translated, pun intended) here. I'll update io-wakeup.scm ... when the (study-thunk) fiber completes. wingo: ah :) wingo: sneek: later tell maximed the writable? side would have to take buffering into account somehow -- what to do if there is room in the write buffer? sneek: Okay. maximed: wingo: from 'select' documentation in Guile: "The ability of port buffers to provide input or accept output is taken into account. sneek: maximed, you have 1 message! sneek: maximed, wingo says: the writable? side would have to take buffering into account somehow -- what to do if there is room in the write buffer? *: maximed "blocking" for real this time civodul: wingo: heya! civodul: great that you found 8b994be59fc4d9d23d8fad546deca3dbb2d29df7 as a potential culprit civodul: these kinds of bugs are always interesting :-) wingo: civodul: fixed it too fwiw wingo: dunno if you saw civodul: wingo: great! haven't seen it yet civodul: (i have much less enthusiastic stuff to do for work...) dsmith-work: Morning Greetings, Guilers dsmith-work: wingo: Thinking about bugs 42345 and 42757 . What about making a call to an internal definition with the wrong number of args an error instead of a warning? dsmith-work: sneek: botsnack sneek: :) leoprikler: It's on 3.0.2 taylan: dsmith: I'm now at least able to explain the bug in detail: https://bugs.gnu.org/42345 leoprikler: applying that fix doesn't seem to work for me ._. dsmith: taylan: Very nice daviid: spacebat1: for info https://gitlab.com/a-sassmannshausen/guile-hall (which is not and not related to guildhall) is an option, although most of us use the autotools chain daviid: spacebat1: akku is another one https://akkuscm.org/ daviid: spacebat1: fwiw, hall is mentioned in the guile manual, here 4.8 Distributing Guile Code dsmith: taylan: Are you thinking that wrong-num-args bug is becuse how the function name is accessed, or becuse the frame is being constucted incorrectly? taylan: dsmith: not entirely sure yet but leaning towards "frame constructed incorrectly" because the docs about the calling convention seem fairly clear that the called procedure should be put in slot 0 taylan: dsmith: the comment about slot 0 not necessarily containing the procedure might be meant in the sense that the procedure's own instructions might decide to put something else there, when it's not needed anymore dsmith: Ahh. Yeah, I was wondering about that comment. apteryx: is here a way to programmatically add a breakpoint in the sources? something like '(use-modules (system vm traps)) (breakpoint)' (pseudocode) ? tohoyn: sneek: botsnack sneek: :) apteryx: I got a 'source-properties' object equal to '((filename . "/tmp/test.scm") (line . 6) (column . 33)), but somehow (source-property obj 'filename) returns #f. apteryx: seems to me source-property should be equivalent to assoc-ref, but apparently not apteryx: here's my current attempt, which fails with "No procedures found at ~a:~a. "/tmp/test.scm" 6": https://paste.debian.net/1198577/ *: apteryx zzzz apteryx: basically I'm after an equivalent to Python's 'import pdb; pdb.set_trace()' one liner. tohoyn: I'm compiling a large guile program with 3.0.7 and I get the following error: mmap(PROT_NONE) failed tohoyn: the compilation has worked with older versions of guile tohoyn: compilation with command "guild-3.0 compile -o tmp.go target-1.scm" tohoyn: I think this is a compiler bug tohoyn: Is it possible to attach large files into a bug report? wingo: tohoyn: i think that bug is libgc 8.x -- https://github.com/ivmai/bdwgc/issues/353 sneek: Welcome back wingo, you have 1 message! sneek: wingo, dsmith-work says: What's the difference betwen an OPn and a DOPn ? wingo: sneek: later tell dsmith-work same encoding, only that by convention the DOP writes to its first operand sneek: Got it. tohoyn: wingo: does that mean that there was not enough memory to compile the file? wingo: sneek: later tell civodul that shepherd bug looks interesting :) surely a problem with 8b994be59fc4d9d23d8fad546deca3dbb2d29df7 somehow sneek: Will do. tohoyn: wingo: Compilation of the file with guile 3.0.5 worked. wingo: tohoyn: that's possible. the question is, are you using libgc 8.x or 7.x wingo: there are other differences between 3.0.5 and 3.0.7 that can affect when and how gc runs tohoyn: wingo: version of package libgc-dev is 1:8.0.4-3 wingo: i think then that you are running into the aforementioned bug wingo: guile itself does not mmap(PROT_NONE) wingo: fyi compiling at -O1 uses less memory. could be a way to get around this issue in the short term, if you need something that will just let you move forward tohoyn: wingo: -O1 as an argument for guild? wingo: yeah guild compile foo.scm -o foo.go -O1 tohoyn: wingo: tx apteryx: any idea in which situation reading from a port (SSH connection) would return a object? unexpectedly? Could this signal the connection was lost? wingo: certainly. or shutdown on remote side. see shutdown(2) apteryx: OK! So I'm trying to add the ability to retry a connection in case it dies and resume normal operation; the code flow is currently something like this: create all connections, check they are alive, do X with connections, batch processing them. The problem is that at the time we batch process them, they might have died. I've modified the code to raise an exception in this case, and I could use a apteryx: brute-force retry mechanism that redoes all the things mentioned earlier from zero for a finite number of retries. Going further, is there a pattern/building block I should look into to make this more granular (at the level of an individual connection)? The current code looks like: apteryx: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/offload.scm?id=2b76179ecd951172288f5f6f78402d9304d2da41#n646. apteryx: phew, sorry for the wall of text dsmith-work: Morning Greetings, Guilers sneek: Welcome back dsmith-work, you have 1 message! sneek: dsmith-work, wingo says: same encoding, only that by convention the DOP writes to its first operand dsmith-work: D for Destroys Destination with Data from the Doing manumanumanu: Ahoy! manumanumanu: I had a small discussion with Zelphir about some old threading macros I wrote a long time ago. I told him that I advice against using them now that SRFI-197 exists. Would there be any interesti of having srfi-197 in guile? manumanumanu: not for, but in. I can take it upon myself to implement it and rewrite the SRFI document as texinfo. rlb: manumanumanu: I suspect I might well like them. rlb: fwiw manumanumanu: it is one of those often asked-for things, and there are a billion implementations of them. My old ones are fine, full-featured and portable - but ultimately not something I think anybody should use now that there is a standard alternative. manumanumanu: srfi-197 is a superset of most implementations, with good handling of multiple values to that jackhill: Recommendations on a good way to answer this question in guile: "have I seen this object before?" I'm thinking a set library may be useful. Thoughts? RhodiumToad: hashtable, possibly weak? jackhill: sounds reasonble. Do you know if there is an implentation already available for Guile? RhodiumToad: make-hash-table, hashq-ref, etc. are built in *: jackhill check the reference manual again. RhodiumToad: make-weak-key-hash-table if you want a weak one jackhill: Ah yes, thanks taylan: ecraven: dsmith: what is the purpose of this sign-extending or zero-extending? dsmith: taylan: You have an smaller bit value that needs to be placesd into a register with more bits. What do yout fill the "empty" bits with? taylan: dsmith: I would guess it doesn't matter, since they will be masked out anyway? dsmith: taylan: If you have an immidiate value, say "3". Why take up 32 or 64 bits of code when 8 will do? dsmith: IIRC on arm, there are no 32 bit immediates, you need to use two 16 bit immediates. (or is that 64 and 32?) dsmith: arm has some really wacky immediates. There was a nasty bug some of us were working on about a year ago. dsmith: IF you wanted to load 00xx00xx00xx00xx, where "xx" was the same, there special bits that do that with only haveing the "xx" in the opcode. dsmith: It was actually a jump or branch, iirc. dsmith: So -3 in twos-compliment in 8 bits is 0xfd, in 64 bits it's 0xfffffffffffffffd, if you want to load -3 into a 64bit registere, you gotta sign extend. 0x00000000000000fd is NOT -3 it's 253 or something. dsmith: Yeah, 253 dsmith: So the simple rule is, unsigned: use zero-fill, signed: use sign-extend. taylan: thank you for the explanation! dsmith: Np! dsmith: taylan: Thank *you* for stomping on all those bugs! tohoyn: sneek: botsnack dsmith: sneek: botsnack sneek: :) tohoyn: sneek: botsnack sneek: :) apteryx: is there a way to see which architecture a .go was compiled for? objdump says the architecture is 'architecture: UNKNOWN!, flags 0x00000150' dsmith: apteryx: "file" doesn't show that either. dsmith: apteryx: At one time, I had some rules for old-format .go files. apteryx: also, this still confuses me, why are .go target-specific? I thought they were targetting the Guile VM (being byte-compiled), with VMs being typically target-agnostic (that's their point, no?) spacebat1: is there a package manager for guile? guildhall seems quite old - I see a nice list of libraries on the guile website, which says they are gleaned from guix, but I can't run guix on MacOS apteryx: spacebat1: Guix is one option (it's not Guile-specific, but it's written in Scheme/Guile :-)) spacebat1: I can't use guix though, unless there is a way to run it on OSX spacebat1: maybe you run it in a container and have it install to the macos filesystem spacebat1: so that you can get to the artefacts directly running guile on macos, but that sounds dodgy spacebat1: how do people normally manage their dependencies in guile projects? write a makefile target that checks them out using git? dsmith: apteryx: There are 4 diferent "targets" in .go files: the combinations of 64bit/32bit and bigendian/littleendian. dsmith: So th same 32-LE .go file runs fine on 32bit intel and also, say, mipsel. dsmith: file on my laptop shows "64-bit LSB", and on my beaglebone black "32-bit LSB" dsmith: Yes! The big endian versions show "MSB" instead of "LSB" dsmith: apteryx: So there you go. You *can* see what "arch" a .go file was compiled for. leoprikler: spacebat1: the overlap between guile and guix is big. Other than that, most Guile stuff uses Autotools, so you ought to be safe if you check out all your dependencies and run `make install` dsmith: apteryx: Also, those old-format go files were also of just 4 kinds {64,32}-{B,L}E , but were not ELF. apteryx: dsmith: Thanks a lot for explaining! Using the 'file' utility I can see this too now. apteryx: Now wondering if this is Guile-specific; I'm guessing other byte-compiled languages such as Python (.pyc) files would have to solve that problem too, but I haven't been exposed to it yet. taylan: heya dsmith: apteryx: iiuc, pyc files are arch idependent, but not version independent. RhodiumToad: a common technique (I don't know what python does) is to have a magic identifying string that includes any important details. going full ELF as guile does seems not to be common dsmith: Yeah, I've never heard ELF used for anything but .so's and executables. taylan: I only now realize that the numbered slot references in disassembled bytecode, e.g. (make-immediate ), are backwards from the max slot. so 0 is the last slot, N the first. terribly confusing :\ taylan: (it's because of the downward-growing stack) RhodiumToad: ELF has the advantage that there's a lot of tools, but it's also a whole lot more complex than most languages would ever need dsmith: taylan: Making any more progess? taylan: dsmith: very slowly, trying to grok everything at every step :D dsmith: There is a very nice text diagram in the comments of one of the source files. dsmith: libguile/frames.h taylan: I saw it, it's in the info manual too, but it's a little misleading as it shows the slots numbered top down, but the slot references in disassembly are the other way around taylan: the fourth last paragraph in the manual actually explains this but I had missed it until now taylan: fifth last and fourth last, rather taylan: are negative pointer references actually slower than positive ones? seeing slot references 0 to -N would have been less confusing than N to 0 IMO. taylan: (using the frame pointer instead of the stack pointer as the base) manumanumanu: Ahoy! *: sneek waves manumanumanu: sneek has new features! manumanumanu: Scrapt that. Sentience!!! *: dsmith snorts manumanumanu: Does "potentially unbound variable" warnings warn before DCE? manumanumanu: yes manumanumanu: I am old enough to repl (when #f (display unbound!!)) civodul: i found an interesting miscompilation issue with >= 3.0.5: https://issues.guix.gnu.org/47172 civodul: does that ring a bell? dsmith: civodul: Wow. Inlcudes a heisenbug. taylan: civodul: yeah I think that's in debbugs already, let me check taylan: civodul: the report even comes from guix-land: https://bugs.gnu.org/48368 taylan: I see Marius already referenced that bug in the Guix report RhodiumToad: is there a self-contained example of that? I haven't managed to reproduce yet civodul: taylan: indeed! dsmith: I wonder if swapping the args to eq? changes things, since swapping the and sub-expressions did. As in (eq? 'detailed-status action) leoprikler: Can someone tell me what can get GC to deadlock in pthread_cond_wait? leoprikler: call-with-trace does not seem very helpful, it barfs on FFI stuff dsmith: Is that with the recent patch? dsmith: This: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43102 lampilelo: taylan: write a blog post about it, when i decide to study the vm i want to do it on easy mode! taylan: lampilelo: lol, might do so. that being said, I had completely forgotten that the VM is documented to some degree in Guile's Info manual taylan: if it explains everything that I figured out manually in the past two days, I will be quite bummed :P well, I guess it's always good to have seen the code anyway. lampilelo: hmm, seems like there's a lot of info there hwpplayer1: hi people! tohoyn: sneek: botsnack sneek: :) ArneBab: leoprikler: what do you mean by a wisp sexp? Do you mean inline-parenthesized-code? If yes: prefix the first paren with a period: . (display foo) leoprikler: no, i mean stuff like "\t\tdisplay foo" leoprikler: If I jump to a line like that and then try to read a sexp, wisp errors out because of the indentation maximed: Why are cons and vector in *effect+exception-free-primitives*? They can throw an 'out-of-memory exception, no? leoprikler: everything can throw out-of-memory potentially :P amirouche: maybe not `values` amirouche: nvm idk leoprikler: car and cdr should be really safe, but both can throw :P amirouche: if there is no more memory, even values can fail. leoprikler: (invalid-argument, that is) dsmith: Probably doesn't matter, as nothing seems to call effect+exception-free-primitive? anyway. avp: Hello Guilers. avp: So the Guile chat moved here, I guess? ArneBab: welcome :-) ArneBab: moved here because #guix also moved here, iirc avp: Okay. I'm curious what was the reason for the Great GNU Guile Migration? avp: I fixed Guile-SSH building/testing issues on Fedora GNU/Linux 34. Also now there's a Docker image based on Fedora with GNU Guile pre-installed: https://hub.docker.com/r/avvp/fedora-guile taylan: hi all taylan: does anyone know what "sign-extended" and "zero-extended" immediates are? ecraven: probably extending 8->16 bit by copying either the msb, or 0 into the high byte ecraven: and the same for 16-32, ... efraim: I'm getting a test error for guile-3.0.7 on powerpc-linux, ERROR: suspendable-ports.test: revealed port fdes not closed - arguments: ((system-error "seek" "~A" ("Bad file descriptor") (9))), happened on two successive runs efraim: didn't happen with 3.0.5, didn't test 3.0.6 civodul: efraim: i've seen it reported (for x86_64), but this seems non-deterministic and quite infrequent civodul: there were changes around finalizers in 3.0.7 so it could be related efraim: I'm sending it though again without my bootstrap optimisations, should find out if it worked in 3 or 42 hours dsmith: taylan: What ecraven said, upper bits are filled in with either 0 or the sign. ecraven: so you have an immediate #b10000000 to some instruction. if you sign-extend it, it'll be filled with 1s to the left (because the most-significant-bit is 1), if you zero-extend it, it'll be filled with 0. usually you want sign-extension for signed integers, and zero-extension for unsigned integers dsmith: So 0x7f -> 0x00000007f is the same for bother zero-extend and sign-extend, but 0xf2 -> 0xfffffff2 (sign-ex) or 0xf2 -> 0x000000f2 (zero-ex) dsmith: I guess that's assuming twos-complement, which all modern cpus are. dsmith: Are there any sign-magnitue or ones-complement machines still running? dsmith: sneek: botsnack dsmith: sneek: botsnack dsmith: sneek: botsnack sneek: :) dsmith: goodbot dsmith: sneek: botsnack sneek: :) dsmith: sneek: logs? sneek: Someone once said logs is http://logs.guix.gnu.org/guile/ manumanumanu: So, this channel is actually happening. civodul: hi! :-) lampilelo: hello lampilelo: i removed freenode from my config already lampilelo: so i hope everyone will transition or i'll miss out civodul: yeah civodul: wingo: i looked a bit at peval of (let ((x (list 1 2))) (car x)) civodul: i'm not sure whether/how to fix it without also breaking (let ((x (list 1 2))) (lambda () x)) wingo: sneek: later tell taylan thanks for grabbing the channel! i adjusted the flags so it is me and civodul now, but don't hesitate to ask if you need anything sneek: Got it. wingo: civodul: yeah we certainly can't break (let ((x (list 1))) (lambda () x)) wingo: civodul: fwiw CPS optimization does manage to punch through it wingo: hum interestingly it doesn't manage to fold the "string?" but it does punch through the caar manumanumanu: now, I might be admitting to being an idiot, but why can't this be inlined to (lambda () (list 1)) ??? Does it have to be a closure? civodul: manumanumanu: because of pointer identity manumanumanu: ah manumanumanu: of course. civodul: wingo: if CPS gets it, maybe that's enough civodul: the assembly still looks like more than just emitting an immediate though wingo: the assembly shows that it effectively emits (string? "x") wingo: instead of #t wingo: i mean in your initial test from yesterday wingo: right, paging this back in. the issue with inlining (car x) when x is bound to (list 1) is that someone could set-car! on x wingo: to know whether that happens or not, you need flow analysis, which isn't what peval does wingo: there are obviously some patterns that peval could recognize if useful, e.g. transform (let ((x V)) (f x)) to (f V) wingo: but in the case you were looking at, already it was getting more complicated because it was (let ((x V)) (if (pred x) ... ...)) wingo: was even (if (string? (car (car x))) ...) wingo: so... tricky and ad-hoc wingo: better to have a comprehensive flow-based analysis wingo: sometimes i think we should have an SROA pass early in CPS (https://llvm.org/doxygen/SROA_8h_source.html#l00065) civodul: wingo: i see; it was surprising to me that peval would be stopped by a mere 'let', but i see it's probably not the right level to do these things taylan: tohoyn: heya sneek: Welcome back taylan, you have 1 message! sneek: taylan, wingo says: thanks for grabbing the channel! i adjusted the flags so it is me and civodul now, but don't hesitate to ask if you need anything taylan: wingo: perfect like this, the less responsibility I have the better ;-) dsmith: civodul: erc is working for me with both #guile's civodul: dsmith: you think it's working, but you'll see... :-) civodul: it'll start behaving strangely civodul: bandali confirmed yesterday dsmith: civodul: Hmm. I haven't noticed anything. dsmith-work: Happy Friday, Guilers!! dsmith-work: sneek: botsnack sneek: :) *: sneek wags dsmith-work: wingo: Some of us were looking at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42757 yesterday. dsmith-work: wingo: There is a comment before scm_c_frame_closure in frames.c dsmith-work: wingo: Sepcifically, "If you want the procedure, look it up from the IP." dsmith-work: wingo: Any hints on how to do that? dsmith-work: wingo: Specifically, in error_wrong_num_args in intrinsics.c dsmith-work: (And I'm considered cheating by asking.) taylan: dsmith-work: I think I figured it out, by following the definitions of: frame-procedure-name in frames.c -> (@@ (system vm frame) frame-procedure-name) -> primitive-code-name taylan: I made a corresponding patch, but in our pathological case it just ends up saying "#f" instead of naming the procedure, even though the disassembly contains the name, so evidently it still misses an opportunity to find the name ruffni: it seems impossible to (make-regex "asdf \\") (Trailing backslash). is this a bug or a feature? is it best practice to also include a (hopefully) following whitespace or newline character? taylan: here's the current state of my patch: http://paste.debian.net/1198345/ taylan: ruffni: a lone backslash at the end of a regexp is a regexp syntax error I believe RhodiumToad: exactly RhodiumToad: if you want to match a literal backslash you need "\\\\" anyway ruffni: yeah, got it :) (make-regex "\\\\") works ruffni: thanks! RhodiumToad: one level of \-escaping is processed by the "..." literal, and another level by the regex compiler dsmith-work: taylan: Probably becuse scm_i_primitive_code_p() in programs.c:scm_primitive_code_name returns false. taylan: dsmith-work: yes taylan: I have no idea what the IP actually points to in our case taylan: what I also noticed is that (@@ (system vm frame) frame-procedure-name) takes an optional "info" argument from which it can get the name, and we might perhaps get a hold of such an "info" object somehow dsmith-work: taylan: How about a different approach. Instead of a warning when outer is defined, make that an error? taylan: dsmith-work: you mean a compile-time error? not sure if the compiler can be 100% sure about it... hmm, in this case I suppose it could, since it's an internal definition. taylan: I can imagine that the mechanism for detecting wrong number of args in the compiler is implemented in a generic way so it's also used for top-levels though, which can change at runtime dsmith-work: Yeah. dsmith-work: I'm suspicious that the frame is not constructed properly becuse the differnet number of args. dsmith-work: I really don't know. Just wonderng.. taylan: I wish I could understand what "DOP1 (X8_S8_ZI16)" means :D dsmith-work: Why *obviously* it makes a 16 bit value from an 8 bit immediate! dsmith-work: ;^} taylan: dsmith-work: are you serious or did you just make that up? :P dsmith-work: taylan: Only half serious. Look at line 1643 in vm-engine.c dsmith-work: Don't know what X8 means. Maybe size of the opcode? taylan: what's also confusing me right now is that that argument to the VM_DEFINE_OP macro doesn't actually seem to be used anyway dsmith-work: The S8 and ZI16 are prob source and destination? taylan: there are two possible definitions of VM_DEFINE_OP (based on whether one is using a compiler that supports &&label to get the address of a goto label) but neither use that argument dsmith-work: taylan: There is some Makefile magic that might use it. dsmith-work: taylan: See the contents of vm-operations.h dsmith-work: taylan: And the FOR_EACH_VM_OPERATION is used is many places. taylan: dsmith-work: oh I see, vm-operations.h is autogenerated from vm-engine.c via sed :D Noisytoot: sneek: botsnack sneek: :) lfam: Hello sneek *: taylan abandons Freenode entirely as all the channels he cares about officially migrated to Libera :P dsmith-work: taylan2: If you look at the places FOR_EACH_VM_OPERAION is used, sometimes that "meta" *is* used. And it's named "arity" in some places. dsmith-work: wingo: What's the difference betwen an OPn and a DOPn ? dsmith-work: Destructive? Destination? dsmith-work: sneek: later tell wingo What's the difference betwen an OPn and a DOPn ? sneek: Got it. taylan: aww netsplit dsmith-work: I imagine there will be some growing pains. taylan: dsmith-work: you still here? I'm 99% sure that the DOP/DST stands for destination. all but one of the VM ops defined with DOPn declare a uintN_t dst; first thing in their body, and that seems to be used as a destination address. dsmith-work: Ok. taylan: not sure why that's special-cased, probably just because it's extremely common taylan: from what I can tell it seems one could have also defined another "word type" say DST and every OP (...) as OP (DST, ...) dsmith-work: One (only?) difference is when printing. The "D"'s have "<-". Non-D's have "!" dsmith-work: In parse_instruction in instructions.c taylan: interesting. I guess the arrow means "puts something there" and the bang means "does something in-place" or so dsmith-work: tail = scm_cons ((meta & OP_DST) ? sym_left_arrow : sym_bang, tail); dsmith-work: As fas as I can tell, that's the only palce OP_DST is used. taylan: one thing I'm wondering is, why those cryptic identifiers like Xn_Cn_... dsmith-work: Mnemonics. Shorter to write and fit on screen. IF you origianly wrote the code. ;^} taylan: in case my last messages didn't make it: I'm wondering why the "instruction word types" have cryptic names like Xn_Cn_... taylan: I like it how at the end of vm-engine.c there's a piece of Elisp code to auto-update the opcodes for you :D bjoli: taylan: better than visual studio! dsmith-work: taylan: Ya, that's pretty sweet. ArneBab: taylan: nice! sneek: ArneBab, you have 1 message! sneek: ArneBab, leoprikler says: should it be possible to read a Wisp sexp from the middle of a file assuming proper indentation? *: taylan is starting to get the hang of how the VM works sneek: No this is not sneek. Just registering the nick nckx: You gave us hope only to snatch it away. taylan: FYI, since wingo isn't registered on libera yet, I gave channel founder and other rights to civodul for now, since he's also an official maintainer. I'm going to sleep now! taylan: wingo: you have full founder rights to the channel now, feel free to revoke mine if you decide to take control over it wingo: tx lampilelo: how does guile handle threads and gc? is it safe to pass an SCM object to another thread by SCM_UNPACK_POINTER->body_data->SCM_PACK_POINTER, using scm_spawn_thread? is the object safe to use from both threads? leoprikler: Guile should check all *stacks* for GC, but it doesn't care what's on the heap. Quits:: nicole (ilbelkyr@freenode/staff/atheme.ilbelkyr) (Killed (grumble (My fellow staff so-called 'friends' are about to hand over account data to a non-staff member. If you care about your data, drop your NickServ account NOW before that happens.))) *: daviid has a g-golf wip-3.0 branch that now successfully works with 2.2 and 3.0.7 wingo: yay :) wingo: ffs https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409 taylan: wingo: I already opened #guile@irc.libera.chat and can give you channel ownership when you want :D nickserv registration doesn't seem to work yet though... wingo: good to know! flatwhatson: nickserv worked for me just now leoprikler: sneek later ask ArneBab should it be possible to read a Wisp sexp from the middle of a file assuming proper indentation? sneek: Got it. dsmith: taylan: Is irc.libera.chat actually working? Connection closes for me when I use erc-tls to connect taylan: dsmith: maybe it's TLS-only. I was able to connect to irc.libera.chat:6697 with TLS dsmith: Hmm. I'm not able. davexunit: I connected with erc-tls no problem dsmith: Doh! typeoed the fqdn civodul: peval reduces (string? (caar `(("x" ,+)))) to #t, yay! civodul: but it fails to do that with (let ((x `(("x" ,+)))) (string? (caar x))) civodul: wingo: what are your thoughts on this? ft: Hm. Didn't guile have something that turns a file glob pattern into a list of matching file names? Did I just dream that? civodul: ft: i don't think there's anything for glob patterns in Guile civodul: Gash has that, and Guix has a regexp-based 'find-files' procedure ft: civodul: Thanks! I may have to borrow that real quick. :) lampilelo: guile has readline support that you could use for that, if filename completion worked, but it doesn't lloda: i saw your bug report on that a while ago lampilelo lloda: i've had this problem for a while that i have filename completion in embedded guile and i don't know how to switch back to normal completion lampilelo: the report has a patch attached lloda: the switch happened one day i updated some debian packages i think. No idea how lloda: do you happen to have a link? lampilelo: wait, filename completion worked for you? with filename-completion-function? lloda: no lloda: i didn't do anything lloda: it just works lloda: but only in embedded guile lloda: in plain guile i get normal completion lampilelo: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45339 lampilelo: i don't think it solves your issue of not being able to switch to normal completion though lloda: maybe lloda: patch seems straightforward tho lloda: i'll push it lloda: I tested with (with-readline-completion-function filename-completion-function (lambda () (read))) which i remember not working before lloda: thx lampilelo lloda: civodul: wdyt about reverting master to 3.0.7 like wingo was saying lampilelo: thanks for pushing it, i remember rewriting a script from guile to elisp because filename completion didn't work, elisp is fine but not very good for scripts so i wrote this patch anyway lloda: np, sorry it took so long lampilelo: i forgot about it too wingo: civodul: weird :) re the peval thing lampilelo: fwiw i'd prefer if you just outright removed master branch because i'm sure some day i'll try to compile master and be surprised by the wrong version, i'm saying it from a perspective of someone who git checkouts to the newest tag after a release and rarely compiles the most recent code lloda: yeah that's also my take lloda: there's no confusion if the branch is gone wingo: removing is fine with me lampilelo: i have an unrelated question: do you require copyright assignment to fsf from contributors? lloda: lampilelo: yes lloda: tbh i'm not sure of what is the size of patch where that becomes a thing dsmith-work: UGT Greetings, Guilers wingo: i would like to stop requiring assignment fwiw wingo: haven't gotten around to doing that yet tho wingo: will require some policy statements etc lloda: i've pushed the patch in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43102 lampilelo: i think it was >15 lines total? per contributor, not per commit dsmith-work: Oops. Commit 02439a1 doesn't follow gnu style. lloda: what's that dsmith-work dsmith-work: (I personally really dislike the GNU C style, but I appreciate having a consistent style) lloda: ah i see lloda: i didn't even notice tbh dsmith-work: lloda: { on a separate line, indented 2. body idented 4 lampilelo: ah, sorry, that's my commit dsmith-work: It is just such a small commit that it popped at me. lloda: i'll try to remember dsmith-work thx lampilelo: yes, me too lampilelo: should i send an updated one? dsmith-work: civodul, wingo: ^^ chrislck: uh oh: https://blog.bofh.it/debian/id_461 https://www.kline.sh/ chrislck: ah old news dsmith-work: What's with the "THIS CHANNEL HAS MOVED TO IRC.FREENODE.NET" messages on libera? lampilelo: i sent a new commit to bug-guile: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45339 lampilelo: dsmith-work: could you review it? ft: dsmith-work: Sounds like trolls? dsmith-work: lampilelo: LGTM dsmith-work: ft: Yep rekado: hmm, guile-redis cannot be built with guile 3.0.7 rekado: “unknown location: unexpected syntax in form ()” lloda: lampilelo: pushed lampilelo: thanks lampilelo: and sorry for trouble rekado: very confusing. There’s no “()” in the file it complains about. taylan: rekado: and it surely doesn't use #nil, right? civodul: lloda, wingo: i think i missed something: reverting master to 3.0.7? taylan: (I happened to work on a #nil-related bug in 'match' recently that produced that same error message) taylan: civodul: master has been moved to "main" civodul: ah rekado: taylan: no #nil. civodul: hmm dunno lloda: the other option is to remove master entirely *: civodul goes afk for a bit lloda: but maybe some distro relies on that? no idea rekado: it’s this file here: https://github.com/aconchillo/guile-redis/blob/master/redis/main.scm rekado: it might be because of “(syntax-rules () …)” in redis/commands.scm rekado: ah, and there’s a #nil rekado: yup, replacing the #nil with (list) fixes it. taylan: rekado: this was the bug I worked on FWIW: https://bugs.gnu.org/48315 taylan: rekado: the main takeaway for me was that the syntax-rules pattern (x ...) matches #nil, which can be surprising but makes sense in a way I guess rekado: thanks for the pointer! rekado: I reported this as a bug in guile-redis here: https://github.com/aconchillo/guile-redis/issues/7 – I think #nil shouldn’t be used. taylan: rekado: do you know why they use #nil? the general idea is that it's strictly for elisp-compatibility purposes and shouldn't ever be used explicitly in Scheme... rekado: yeah, I don’t know. lloda: maybe that point hasn't been stressed clearly enough lloda: https://www.gnu.org/software/guile/manual/html_node/Nil.html leoprikler: I think it's fair to use #nil in contexts where you want something to be both the empty list and false :P leoprikler: Who cares about RnRS? taylan: leoprikler: I'm not sure... it can cause headaches to the Guile maintainers when they want to tweak an aspect of how exactly #nil behaves when they realize they can improve Elisp compatibility, or improve Guile's performance without breaking Elisp compatibility leoprikler: wdym exactly? taylan: it's less about RnRS and more about why it was added to Guile in the first place, which is: an Elisp compatibility hack taylan: leoprikler: for instance it's unclear whether (equal? '() #nil) should be #t or #f, and if your Scheme code relies on either, then Guile maintainers realize that it would improve compatibility to change it, your code will break... taylan: and next thing you'll complain at the Guile maintainers for "breaking" your code :P leoprikler: I would never demand from Guile maintainers to make #nil equal? to either '() or #f taylan: if you're ready to tweak your code in accordance to changes Guile makes to the semantics of #nil then no problem I guess :) leoprikler: I do however rely on ((@@ (ice-9 match) match) (cons 'a #nil) ((a) #t) (_ #f)) => #t leoprikler: Which I personally think is a fair assumption to make. taylan: yeah IMO that should keep working, otherwise lists coming from Elisp-land won't work properly with 'match' leoprikler: funnily enough you can't write (match #nil ...) leoprikler: you have to write (match (identity #nil) ...) taylan: leoprikler: there's a bug report about that and I have a patch for it: https://bugs.gnu.org/48315 terpri: leoprikler, technically, it already breaks rnrs (unless #nil is considered not to be a scheme object), by extending null? for example. but that's a fairly conservative extension imo leoprikler: that's exactly what I meant with "who cares about RnRS" :P terpri: whereas making equal? a...tolerance relation, i think? rather than an equivalence relation might have consequences for optimazation or something even though it might be convenient on a pragmatic level to make r5rs do the intended thing in the presence of #nil dsmith-work: So the nil #f '() issue is one thing. I'm curious about the lisp-1-ness of Scheme and the lisp-2-ness of emacsl-lisp. How is that handled? terpri: dsmith-work, at the moment, very simply: the values of the symbol slots are stuffed into separate guile modules (value-slot-module, function-slot-module, etc.) terpri: the elisp symbol slots, that is terpri: it was written that way mostly for expediency; it's probably not the ideal design leoprikler: I think the problem could easily be solved by the user defining false? as (member '(#f #nil)) and using null? leoprikler: note, that emacs does have the notion of an obarray, but it's used sparingly wingo: in guile, that is more efficiently implemented as (not x) terpri: yeah, iirc there's no obarray in guile-emacs leoprikler: wingo: I didn't say it was the best implementation of false? :) (define false? not) (define true? (negate false?)) should work manumanumanu: civodul: peval reduces this: https://paste.debian.net/hidden/8f48a9f5/ to (reverse (list 3 1)). manumanumanu: civodul: that is not quite true. It becomes something like (let* ((cursor (list 1)) (cursor-1 (cons 3 cursor))) (reverse cursor-1)) wingo: leoprikler: i just mean that (not #f) => #t and also (not #nil) => #t leoprikler: Oh sure, but people seem to hate writing (not) leoprikler: especially as (not (not )) wingo: ok if this is an aesthetics question, sure :) wingo: there is ->boolean fwiw wingo: ->bool rather wingo: not recognized by the compiler tho leoprikler: lemme guess (compose not not) :D wingo: haha if only we could be so elegant in boot-9 ;) leoprikler: well, (define (->bool what?) (not (not what?))) is semantically the same anyway terpri: wingo, fwiw i think i'm probably wrong about the idea of making #nil equal? to other scheme values, since that would emphasize either its boolean-nature or list-nature at the expense of the other. making it equal? to a boolean or a list would privilege one interpretation, making some rnrs programs "just work" while others would be broken leoprikler: #nil equals wingo: ah i think i am missing some of the scrollback on this laptop leoprikler: * #nil equals #nil, nothing else wingo: terpri: you were considering a change but decided against it, if i understand correctly terpri: right, i was (perhaps a bit selfishly) focusing on more transparent elisp compatibility wingo: hehe wingo: omg if you are back on this hack, that is fantastic news!!! wingo: (if not, that is ok too, no pressure :) wingo: but do as you will re: elisp in guile, i trust your judgment leoprikler: I can't wait to rewrite half of dystopia.el in 3.0.8, because keywords are finally recognized :) terpri: wingo, the idea is due to taylan, and i agreed with them initially, but it can't be done "the right way" (or, per newer rnrs, the very wrong way) by adding more equalities, since as someone helpfully pointed out... leoprikler: by the transitivity you would have (equal? #f '()) in the end, which is silly :P terpri: (equal? #nil #f) and (equal? #nil '()) would reduce equal? to a mere tolerance relation terpri: due to transitivity leoprikler: fwiw, elisp should also have not and null? leoprikler: as in standard elisp manumanumanu: wah... I had a closer look at some of the scheme benchmarks things. the scheme benchmarks are _not_ comparing the same thing at all, even if we only do safe optimizations. cyclone does memoization of pure recursive functions :) And does no cycle detection. terpri: lacking the extra #nil equalities will surely break the "intent" of some rnrs programs (for n > 3, iirc) terpri: but maybe that can be papered over with a lisp-compat module or something that redefines equal? and friends leoprikler: does RnRS want people to compare booleans and lists with equal? terpri: (another idea is to have, internally, a "lisp box" which is totally transparent to scheme except for #nil, and for #nil requires an explicit coercion, but that sounds a bit clunky and maybe bad for perf) *: terpri should be writing this up for emacswiki leoprikler: or is this about (equal? '(a b c) (cons* 'a 'b 'c #nil)) leoprikler: (which I'd argue should be done in terms of match anyway) terpri: leoprikler, yes, that sort of expression is the "problem" taylan: terpri: are you sure privileging (equal? '() #nil) over (equal? #f #nil) would be a problem? IMO privileging one would be better than neither, and I think #nil is the better choice due to its ubiquitous role in list structure, but not sure... leoprikler: taylan since you mentioned clojure the other day, what would happen if (equal? '() #nil) and (equal? #() #nil) :P taylan: leoprikler: I'm not well-versed in Clojure... leoprikler: maybe that was someone else then, sorry, my memory might be fuzzy taylan: leoprikler: but IIRC nil doesn't equal the empty vector in Clojure? justin_smith: I hope #() was a typo leoprikler: why would #() be a typo? justin_smith: oh right #() is a vector in guile leoprikler: didn't someone say that #{}, #(), '() and #nil are same-y in Clojure? justin_smith: taylan: correct, conj treats nil as if it were an empty vector, but an empty vector and nil are not equal terpri: rlb is a clojure/lokke expert in this area, who mentioned #nil's utility in clojure-on-guile justin_smith: leoprikler: not quite - the "seq" function collapses all of them to nil but that's an abstraction layer used for sequential data, and not a property of those data structures terpri: taylan, well, we can define it either way, considering it's a unique(?) extension for modern scheme justin_smith: so instead of having map-list map-vector map-set etc. we have map, which uses seq to get a sequential view of any collection leoprikler: ahh, yeah, thank's for clearing that up justin_smith: leoprikler: which might be an approach worth emulating - instead of treating empty collections as nil as false, using a function that is false for empty collections and nil and true for other inputs terpri: taylan, it's just a situation where we (probably) can't have our cake and eat it too, in terms of behavior matching a scheme programmer's likely intent in all situations taylan: terpri: BTW another elisp issue: https://bugs.gnu.org/39221 would be interested in your thoughts / review of the patch :) terpri: taylan, i think any of (and (equal? #nil '()) (not (equal? #nil #f))), (and (equal? #nil #f) (not (equal? #nil '()))), or (and (not (equal #nil '())) (not (equal #nil #f)))) are all acceptable in a formal sense leoprikler: taylan: I'm all for extending emacs symbolp leoprikler: i.e. symbolp = (or symbol? keyword? #t #nil) terpri: i don't have a good intuition for which "pun" would be more useful, if any, but i wouldn't object having one of them enabled -- probably little harm in just trying one out at this point if you find one distinctly preferable, or if one choice makes #nil an appropriate representation of clojure nil but not another, etc. (the only caveat i can think of is that for the "punning" options, there might be low-level bits terpri: of guile to consider, like equal? as a hash table predicate) leoprikler: I really think the pun should be handled by some separate entity like seq terpri: (tbh the mathematical-logician part of me doesn't like the idea of introducing equality "puns", but as long as it's marked experimental, it should be harmless enough to try it out and perhaps we could do some testing with important programs like srfi-1) leoprikler: I think stuff like SRFI-1 should just handle #nil internally without a pun. terpri: sort of a Solomon-esque solution ;) terpri: "no you can't have either convenient thing, fix your program or import a compatibility module" leoprikler: Not only would this probably solve most issues that could arrive in RnRS programs, it's also show how to implement things correctly *: terpri reads the symbol patch leoprikler: and people wouldn't be led into the temptation of comparing with equal terpri: leoprikler, yeah, that's the ideal outcome, people using procedures like null? where appropriate and not relying quite so much on the concrete representations of things (even though it's perfectly legal per rnrs) leoprikler: IMHO Guile documents its RnRS incompatibilities pretty well. leoprikler: that's more valuable than "Oh, it's legal RnRS, it should work." leoprikler: The equivalent C would be "It compiles, so I don't care." terpri: i don't know if it's technically feasible, but it would be neat if it were a runtime option (perhaps an, ah, optional runtime option) so that people could test their programs under different modes and find out "how broken will my program be when the million-line elisp elephant enters the room" leoprikler: I think a compiler warning about (equal? '()) and (equal? #f) should do the trick as well leoprikler: assuming people use the compiler :P leoprikler: and of course optional so as to not confuse people, who know what they're doing dsmith-work: Speaking of compiler warnings, wouldn't it be nice to *only* display all those "hey I'm compiling this now" messges when specifically asked to? As in a -v option? leoprikler: you mean the auto-compilation? imo the current stuff is fine, because it gives you performance by default but warns you about the side effects that may have terpri: taylan, to answer your earlier question, pragmatically speaking, imo you're probably right that the equal? issue will pop up more often with lists. i'd guess (eq? #nil '()) => #f and (eq? #nil #f) => #f will both cause issues with real-world programs, but we can't do anything about that in core guile, at least without a radically different design for lisp<->scheme communication leoprikler: auto-compilation can break programs in unforeseen ways after all :P terpri: which doesn't mean we should necessarily introduce the pun, but i concur it'll be more of an issue (how often is it likely to show up with booleans? (member? #nil '(#f ...)) and the like?) terpri: i like the compiler-warning idea too (which could help with more than just equal?) taylan: dsmith-work: I have a patch to add --silence-auto-compile here: https://bugs.gnu.org/16364 I guess it could use an env var too. taylan: the CLI switch was my priority since that'll allow script authors to do it dsmith-work: taylan: Yes, saw that. I'm suggesting the logic should be inverted. *: terpri pokes around debbugs to see if they can commit things through that interface (as a savannah-level guile commiter) taylan: dsmith-work: hmm, maybe so. I have no strong opinion on it. terpri: taylan, the symbol? patch lgtm on an initial skim, thanks for fixing that! (might be the sort of bug where emacs ended up redefining the boot.el definitions...or maybe it's just been broken this whole time, who knows) taylan: terpri: btw any plans of rebasing your branch on 3.0? :P I guess it's probably a big task... oh and, you've seen rekado's rebase on a more recent 2.2, right? terpri: wingo, i'm afraid i'm not back on the hack just yet, as i'm working at a gamedev-tools startup which needs me full-time atm, lest it run out of runway. but in 3-6 months my client expects that i should be able to work roughly half-time terpri: and then full, er, half speed ahead! rlb: In case it wasn't fully covered, yeah, in clj nil is also effectively an empty collection for most purposes, and it's also "false", while other concrete empty collections like #{} [] '() are not. terpri: taylan, yes, provided it's not too time-consuming. thanks for mentioning rekado's rebase, i rememebered someone worked on it after dustyweb but not who) rlb: and if I remember the history correctly, clj used to be more like elisp, in that '() was false too, but they intentionally changed that, I believe to improve laziness. rlb: Think this may talk about it, and in case you didn't see it earlier: https://clojure.org/reference/lazy rlb: Personally, I find the collection/seq (laziness) abstraction often very convenient, but it's indeed not very traditionally "schemey". taylan: rlb: assuming there's an 'equal?' of sorts in clojure, nil isn't equal? to any of '(), [] or #{}, right? taylan: assuming ClojureScript has the same semantics, according to https://clojurescript.io/ (= nil '()), (= nil []), and (= nil #{}) are all false, only e.g. (= nil (seq '())) are true taylan: but I'm not sure if clojure's '() is represented via Scheme's '() in lokke. if so, then (equal? #nil '()) might pose a problem I guess. taylan: I feel like we discussed this a few days ago already but I forgot since I couldn't keep clojure's semantics in mind, sorry ^^ terpri: taylan, same results for = on regular clojure dsmith: sneek: seen taylan sneek: I think I remember taylan in #guile 6 hours ago, saying: there's an unresolved, trivial, 8 year-old bug about it :D. dsmith: sneek: botsnack sneek: :) dsmith: RhodiumToad: Do you of any decent cheap mips boxes that run netbsd? I ha{ve,d} a cobalt qube, but that doesn't seem to be viable any more. dsmith: RhodiumToad: (it's where sneek used to live) dsmith: Oh! https://wiki.netbsd.org/ports/cobalt/ Maybe it is still supported *: RhodiumToad has no experience of netbsd *: RhodiumToad also hasn't touched any mips systems for, oh, 25 years? more? dsmith: RhodiumToad: Ahh. Sorry about that. Thought we were talking about netbsd before. Maybe it was freebsd instead. *: RhodiumToad only does freebsd *: dsmith makes a mental note lampilelo: how would you debug a segfault on scm_flush_all_ports()? one port has NULL write_buf but how can this happen? wingo: i would imagine that is memory corruption, tho who knows wingo: use rr, set a hardware watchpoint on the addr of write_buf, and reverse-cont lampilelo: i'll do that, i have a feeling this is a pipe created by open-pipe from a thread lampilelo: something definitely amiss with that because sometimes it errors out inside close-pipe on waitpid, saying there's no child process (just throwing, not segfaulting in that case) wingo: hummmm wingo: lampilelo: i wonder if you might be hitting bug 10836... wingo: bc there is a guardian for pipes and also there is the global weak port table lampilelo: hmmm ilmu: 7gggguymn/" taylan: cat on keyboard? :D lampilelo: the cheat code for money was klapaucius, not 7gggguymn/" lampilelo: wingo: does rr need some special settings for guile? lampilelo: nevermind taylan: lampilelo: what is rr? lampilelo: taylan: https://rr-project.org/ taylan: neat! lampilelo: dumb name btw, try to search for it lampilelo: i wanted to check if it's in my distro's repository and it yielded 231 results taylan: heh, I guess it might be good to give it a canonical name like "rr-debug" or "rr-dbg" or something in package databases and the like. liltechdude: Hello! It's possible to use non-english characters in guile-chickadee? (draw-text "Шла саша по шоссе и сосала сушку.\n\nА я нет." #v(140.0 240.0)) This is rendered to ? mark instead of normie characters. May be I something liltechdude: missing in info manual? lampilelo: does the font you're using support cyrillic? or maybe it's a locale problem, in that case check if setlocale(LC_ALL, "") fixes it lampilelo: note that i'm guessing here, i'm not that familiar with chickadee meo: hey chickadee is cool stis: Howdy guilers! taylan: heya :) lampilelo: hello *: wingo poking at webassembly compilation... opfez: on the guile homepage it says guile has compiler frontends for elisp, is this what is used in GuileEmacs? opfez: (or can i use it to write extensions/config in normal emacs?) lloda: I've pushed https://lists.gnu.org/archive/html/guile-devel/2021-05/msg00013.html wingo: great lloda: how is it with master/main wingo? are we dropping the old one? wingo: humm, i am thinking we should reset master back to v3.0.7, and continue with main wingo: wdyt? wingo: eventually we can remove master but i don't want to cause ppl problems lloda: i think i prefer a quick break rather than having to keep both branches updated but just mo wingo: yeah i mean let's not update master any more lloda: alright wingo: like reset it back to v3.0.7 and then don't move it forward any more wingo: we could remove it of course, or replace the tree with checkout-main-plz.txt or something mwette: taylan: For undeclared data size issues I'm thinking of using bytevector-unwrap* to force the user to define a descriptor on a case-by-case basis based on provided offset. WDYT? justin_smith: rlb: yeah I worded that imprecisely, of course nil is treated as false, but the only "false" that is actually false is Boolean/FALSE and a freshly constructed one like (Boolean. "false") is treated as true justin_smith: ser=> (let [f (Boolean. "false")] (prn "equal to false?" (= false f) "false?" (false? f) "falsey?" (if f "not-falsey" "falsey"))) justin_smith: "equal to false?" true "false?" false "falsey?" "not-falsey" dsmith-work: Tuesday Greetings, Guilers leoprikler: opfez: guile-emacs uses a known-good commit of guile, that has nothing to do with Guile 2.2 or Guile 3.0 leoprikler: that said Guile Elisp is somewhat usable, albeit a bit lacking in certain aspects opfez: ah, so there's no way to use like `guile --language=elisp ` for vanilla emacs? leoprikler: Depends on your Vanilla Emacs more or less. leoprikler: You obviously won't be able to use any of the buffer stuff, but even disregarding that, the runtime is somewhat limited. leoprikler: e.g. no setf, keywords are buggy, ..., there certainly is room for improvement opfez: i see. thanks for the explanation :) leoprikler: also (make-symbol ) does not work for macros, you have to use gensym. rlb: justin_smith: ahh, right - https://clojure.org/reference/special_forms#if tohoyn: sneek: botsnack sneek: :) apteryx: interesting, raising an error in a forked process bubbles up to the parent process -- I didn't expect so, but it is a nice property. RhodiumToad: uh RhodiumToad: are you sure? apteryx: mmh. Not so much anymore, but I'll comment if I can straighten my understanding up :-) apteryx: I don't think that should be possible, so most probably I got confused by the output of the program taylan: hmm it would sure be great if someone reviewed all my patches :P apteryx: funny exception message on (getgr "does-not-exist") -> In procedure raise-exception: In procedure getgr: Success taylan: apteryx: that seems to be a common theme. I wonder what causes it. a similar error message can be seen while booting Guix, and this bug report mentions one too: https://bugs.gnu.org/25412 taylan: apteryx: actually, I'd love to debug this. what's "getgr"? apteryx: it's part of guile proper taylan: oh, nice apteryx: :-) taylan: in this case it seems to be because Guile calls strerror on 0 due to a small bug: when getgrgid or getgrnam return NULL, Guile assumes errno will be set, even though NULL can also mean "entry not found" without an error having happened taylan: yay, another thing to patch :D apteryx: thanks for looking into it! apteryx: is there an easy way to connect a forked process stdout/stderr to the stdout/stderr of the parent process? RhodiumToad: that's the default? apteryx: eh, really? That's great. Then my child is exiting way earlier than I expected; and I can confirm that exceptions do *not* bubble up to the parent process. manumanumanu: apteryx: exceptions no. but stderr yes RhodiumToad: at the OS level, fork doesn't change any file descriptor, so all open files are still open, stdin/out/err point to the same place as before, etc. apteryx: then perhaps something weird in Shepherd, because in my forked process I don't see pk messages even if they're the first instruction run RhodiumToad: however, note that fork can be quite disruptive RhodiumToad: there are issues of buffering, threads, locking, etc. that can all cause havoc RhodiumToad: how are you forking it? apteryx: (primitive-fork) RhodiumToad: so that's the OS level fork, with all the chaos that implies RhodiumToad: are you then doing an exec of some kind? apteryx: RhodiumToad: the start slot is set to this Guix G-Expression: https://paste.debian.net/1198020/ RhodiumToad: so what's happening in between the primitive-fork and that? apteryx: I'm not sure I understand the question; the execution goes like: Shepherd starts, calling the corresponding procedure; does some cleanup, forks a first process, then forks again via primitive-fork and enters the child process to run the remaining instructions (that communications with the earlier process via dbus to finalize the setup) apteryx: that communicates* apteryx: currently I'm totally blind as to what happens in the child process created via the primitive-fork call (it strangely doesn't output anything). RhodiumToad: does the primitive-fork itself cause a warning message to be output? apteryx: this is the output I see from the corresponding test, which exercises the start/stop/restart actions of the service and checks for expected files: https://paste.debian.net/1198022/ RhodiumToad: iirc, pk outputs to stdout not stderr, is it possible/likely that stdout has been redirected? apteryx: we should at least see the backtrace caused by '(error 'exit-fork-with-error)' then? RhodiumToad: maybe try (format (current-error-port) "some string") apteryx: ok RhodiumToad: make sure to include a newline in the string apteryx: RhodiumToad: OK, I can see stderr :-) RhodiumToad: so possibly stdout has been redirected elsewhere, not too unusual apteryx: ok soda__hobart: alright, so i'm flailing wildly trying to figure out how calling scm_init_guile changes some environment variables that have to do with C strings. I think it has something to do with whether the strings are null-terminated or not? soda__hobart: this is basically what I'm trying to do: https://paste.gnome.org/p6bs9uy7o soda__hobart: the input data for the program is produced by this procedure and sent over the local network: https://paste.gnome.org/pwutehy48 RhodiumToad: so nothing in the environment can affect whether strings are null-terminated or the result of strcmp() soda__hobart: ok that's good to know RhodiumToad: how do you know that msg->child->data is null-terminated? your code is incorrect if it is not RhodiumToad: i.e. how did you create that value? soda__hobart: like this: `(string->bytevector (string-append msg "\0")` soda__hobart: or, actually: `(string->bytevector (string-append msg "\0") "ascii")` soda__hobart: and i've tried "utf8" instead of ascii too soda__hobart: the string-append thing doesn't seem to do anything, though. it works as expected, like with strcmp and everything, if I literally type in (my-send-msg-func "quit\0") though RhodiumToad: no, I mean in the code that calls strcmp in your first paste soda__hobart: otherwise, the value I get after casting the void pointer to char* will be somehting like "quit3y" RhodiumToad: what stores the value in msg->child->data and how? soda__hobart: it's a void pointer soda__hobart: I would assume that it is not null-terminated unless I went in and added a null byte to the end, right? soda__hobart: the `msg` struct is initialized on the heap using malloc lampilelo: so how did the bytevector find it's way into this struct? RhodiumToad: soda__hobart: allocating msg doesn't allocate space for either msg->child or msg->child->data RhodiumToad: soda__hobart: so show us the code that stores those values soda__hobart: like this: https://paste.gnome.org/p78nqjawd soda__hobart: what's weird is that it works if I don't call scm_init_guile in my main loop RhodiumToad: it works by pure chance soda__hobart: I was wondering if that was the case RhodiumToad: if you ran it under valgrind or with memory sanitation you would likely see the error RhodiumToad: you're allocating and copying only "size" bytes of data, not adding any terminating null yourself RhodiumToad: if meta.size isn't expected to count the null terminator, as appears to be the case, this means that the subsequent use of strcmp on that pointer is forbidden RhodiumToad: you should probably be allocating meta.size+1 and adding a proper terminating 0 yourself soda__hobart: ah, ok. so the C code should be responsible for adding that terminator? RhodiumToad: that all depends on where this data is coming from and what the specification for that source is RhodiumToad: but in general yes soda__hobart: yeah, the data is coming from a client process, so I feel that it would make sense to to require the client to do all that validation, especially when there could be different flavors of clients. soda__hobart: i mean not require the client to do it lampilelo: malloc in c++, the dread... RhodiumToad: well, yes, leaving aside questions of c++ style soda__hobart: haha I make Bjarne cry lampilelo: it's like you just pasted c code into a c++ file dsmith-work: soda__hobart: Yeah, if your app data is using counted strings, you gotta NUL terminate them if you are going to call any stdlib string functions. soda__hobart: cool, yeah it is working now, thanks to everybody for the help! taylan: seconded :) taylan: good night guilers mwette: night -- installed bytestructures-1.0.10 today wingo: moo abralek: Hi all, Can I somehow generate Unix password hash for /etc/passwd with guile? abralek: I see crypt, but I also have to generate sha512-crypt lampilelo: abralek: (crypt "passphrase" "$6$salt") lampilelo: more info in the libc documentation: info "(libc) Passphrase Storage" lampilelo: more useful than the man page abralek: lampilelo: wow I see, It parses the prefix. Many thanks! apteryx: How can I check if a possibly unbound variable is bound? daviid: apteryx: see module-bound? daviid: module-variable apteryx: ah right. I got confused thing variable-bound? would be a shorthand for (module-variable (current-module) 'var-symbol) apteryx: apparently it's not apteryx: thinking* daviid: module-bound? is available, but undocumented] apteryx: OK! thanks daviid: apteryx: see the def of module-bound? in (ice-9 boot-9) apteryx: works well! I used (module-bound? (current-module) 'my-proc-symbol) chrislck: (defined? 'variable) lampilelo: is it possible that scm_gc() segfaults when a pthread mutex is locked when in guile mode? seems that switching to scm_pthread_mutex_lock() stopped the crashes but i can't really prove it apteryx: chrislck: even better, thanks! dsmith-work: Monday Greetings, Guilers lampilelo: is there a way of debugging memory (in)correctness when dealing with guile? valgrind is pretty useless with this wall of text due to gc, are there any suppression files floating around? terpri: rlb, lokke looks really neat! iiuc in clojure, nil is false but not an empty sequence? rlb: Right, iirc, it actually *is* JVM "null", i.e. java null. rlb: basically "the null pointer" (ish). rlb: And also iirc (cf. that link wrt "null punning") clojure used to support empty sequences acting as nil/false, but changed that early on for reasons in that doc. rlb: "making clojure lazier" rlb: In clj false is false, and nil is faise. And for sequences/collections now, you call (seq something) i.e. (when (seq something) ...) is idiomatic. taylan: who controls the contents of http://www.gnu.org/software/guile/manual/ ? taylan: there's an unresolved, trivial, 8 year-old bug about it :D terpri: rlb, and (seq nil) is false? terpri: er, true, i meant rlb: nil is false, and (seq []) becomes nil. rlb: [] is the empty vector. terpri: ah rlb: https://clojure.github.io/clojure/clojure.core-api.html#clojure.core/seq terpri: "(seq nil) returns nil" is potentially quite helpful (because it sounds like Lispy behavior) terpri: taylan & rlb, it's also useful to remember that we completely control the interface between scheme and lisp/clojure, and that we can define any useful semantics for #nil that don't break scheme programs justin_smith: terpri: clojure's "conj" (a close relation to a lisp cons) treats nil as an empty vector, its "cons" (list specific) treats nil as an empty list terpri: justin_smith, ah, good to know justin_smith: clojure's "into" (kind of like (partial reduce cons)) treats nil as an empty list justin_smith: rlb: a gotcha about clojure's false is that unlike java, only Boolean/FALSE is false in conditionals, and any other false which is not identical to that value is effectively true - this allows faster bytecode at the price of weird code misbehaving terpri: so far it sounds like clojure nil is treated very much like lisp nil, enough that guile shouldn't need separate #clojure-nil and #lisp-nil (which would turn the boolean cube into a...boolean dodecahedron? :P) justin_smith: identical as in the "idenitcal?" function - meaning "a pointer to the same object in memeory" justin_smith: haha justin_smith: boolean tessaract! terpri: lol terpri: lambda: the ultimate platonic solid justin_smith: if my memory was better I'd have a paula beans file-not-found quip ready rlb: justin_smith: depending on what you mean, I believe nil is also false. rlb: (when-not nil (prn :yep)) rlb: :yep rlb: *: rlb wishes clojure had picked unless :) leoprikler: (defalias unless when-not) :D taylan: hi guilers manumanumanu: hi taylan. you are doing a heroes work in bugs-guile manumanumanu: hero's manumanumanu: after one week trying to re-learn german, english exits my brain taylan: I'm mostly picking low-hanging fruits :) manumanumanu: well, for one thing those fruit start looking bad if they are hanging for too long. I am slowly digging my way through guiles internals to hope I can do it myself some day mwette: taylan: working ffi-heper stuff today ... *: mwette afk for a bit soda__hobart: does anybody know why after calling scm_init_guile in a C++ program, the expected behavior of char* strings (received from a network socket and sent by a guile program) changes? i think it has something to do with whether they are null-terminated. does some environment variable get changed by calling scm_init_guile? i'm getting a few characters of cruft on the end of the strings. soda__hobart: i bet it's a geiser/emacs thing, probably different environment vars than what you get from scm_init_guile lampilelo: "expected behavior changes" from what to what? soda__hobart: ok, for example: i comment stuff out so i DON'T call scm_init_guile in my program. while the program (it's a server) is running, i use the guile REPL to send a data serialized to bytes (using rnrs bytevectors, etc.) through a local socket to the server. the server de-serializes the bytes and initializes a struct, and then dispatches some functions based on string lookups ("quit" makes it exit, etc.) --this all works as expected soda__hobart: but if i do call scm_init_guile, then all the strings i send have to be written like "quit\0" or else there is cruft on the end mwette: locale issue? I'd try env LANG=C . wingo: good evening wingo: soda__hobart: either as mwette says, or GUILE_INSTALL_LOCALE=0 in environment wingo: see Environment Variables in the manual soda__hobart: oh ok, cool, i was just looking at it, but this clears it up for me i thnk soda__hobart: hm, no luck. well, i'll just have to study the documentation more but i'm going to play outside now :) o/ mwette: wingo: If you are interested, taylan and I are dealing with generating FFI code in situations where C declarations do not provide enough size information to indicate how large a containing bytevector should be. Examples are where C pointers provide an address of an unknown vector size, or pointer to struct where latast element is something like "foo_t x[];" This is somewhat analygous to using "char *" for strings. mwette: One option to handle this is to have unsafe-bytevector where set and ref are not checked for size. Another option is to force the user to somehow deal with the size, but that would take some work in the type handling and could be inefficient. Thoughts? ArneBab: wingo: thank you for working on the core of Guile! It’s awesome where you already took it! — no special reason for saying it now, except that now is always a good time to say thank you. taylan: roptat: hmm, the online manual seems mangled somehow, here's a relevant page that's not accessible from the other for some reason: https://www.gnu.org/software/guile/manual/html_node/Dynamic-FFI.html taylan: roptat: but yeah, creating an extension is also an option roptat: I think that's my question: how do I create an extension? I've seen examples of function that manipulate numbers, but what about a C structure and pointers? daviid: roptat: look for make-c-struct and parse-c-struct in the manual daviid: roptat: guix has some magic to acheive this at compile time taylan: roptat: if you aren't familiar with bytevectors yet, look into that a bit. then see pointer->bytevector: https://www.gnu.org/software/guile/manual/html_node/Void-Pointers-and-Byte-Access.html taylan: and finally, either make-c-struct / parse-c-struct, or the more sophisticated alternative bytestructures: https://github.com/TaylanUB/scheme-bytestructures roptat: thanks taylan: here's a basic example: https://www.gnu.org/software/guile/manual/html_node/More-Foreign-Functions.html taylan: roptat: here's an example using bytestructures: https://paste.ubuntu.com/p/HymfvYgKwk/ taylan: (didn't test but I think it should be correct) taylan: I'm the author of bytestructures so if you decide to use it I'm happy to offer assistance. for now AFK though (zzzz) mwette: Do you want access to struct elements from scheme or just want to pass pointers daviid: rlb: looking at your lokke re-export-and-replace!, and have a few quiz :) daviid: rlb: in (lokke boot), you call (re-export-and-replace! '(clj-quote . quote)), but i am confused, should it not be (re-export-and-replace! '((clj-quote . quote))) or (re-export-and-replace! '(clj-quote quote)) if these are two seperate names .. . jusdt curious how that lands in the module-re-export! call daviid: also, any particular reason why you didn't make it a syntax? daviid: i mean the re-export-and-replace! definition itself daviid: rlb: in the re-export-and-replace! code, as you do not have a guile-2 entry, why not 'just' (cond-expand (guile-2.2 (module-re-export! (current-module) names)) (else (module-re-export! (current-module) names #:replace? #t))) ? maybe i a missing something ... daviid: rlb: got the answer to the first quiz, (define (re-export-and-replace! . names) ... - i didn't see the . names chrislck: running statprof #:display-style 'anomalies has caused error chrislck: "In procedure =: Wrong type argument in position 1: #f" chrislck: guile-3.0.4 rlb: daviid: wrt re-export-and-replace!, I wanted at least a function, so I started there (similar to module-use!, etc.), but of course could create a syntax (wrapper) too later. Ideally, I'd eventually like to just have support for that in define-module. rlb: And regarding the versioning - at the time I just added the supported versions, but I suppose I could change it to assume any newer versions might work with the 3.0 approach. Didn't think about it too hard at the time, was mostly busy being surprised at the way cond-expand works :) rlb: taylan flatwhatson: sounds like y'all may have figured it out, but yeah, integers up to a certain size are "free", i.e. the fixnum is "in" the SCM value (the pointer address value). There's no allocation. If you haven't seen it, this bit (and the parent chapter) may be interesting: https://www.gnu.org/software/guile/manual/html_node/Faster-Integers.html rlb: (and as I think mentioned, then perhaps libguile/scm.h) rlb: terpri: fwiw, the current #nil handling was *very* helpful with respect to creating lokke https://git.sr.ht/~rlb/lokke/ So if we make changes, it'd (selfishly) be nice if we could preserve the relevant bits. Right now at least, the clj and scheme side are *very* close, i.e. easy to write any given module in scm or clj, and many things have direct mappings. I also wonder if the way clj dynamic vars are handled might have some rlb: similarities to what you were suggesting (cf. magic fluid). rlb: terpri: and I'd imagined that an emacs that supported elisp, scheme, and clojure more or less directly might also be fairly interesting to the clojure world (since emacs is still one of the primary tools there - interactive code excution, etc.). taylan: rlb: I wrote a few patches recently that affect the behavior of #nil. One is to make it equal? to (), another to make lists ending in #nil be written as (foo bar . #nil) instead of (foo bar). taylan: rlb: would either of those be undesirable for your purposes? taylan: also... nice project! :D let's implement ALL lisps in Guile :P rlb: Hmm, I'd have to think about that, and perhaps test the patches, but might not matter? i.e. lokke likely doesn't care about the scm written representation in any critical way, but the latter might be a problem. Not sure, and also not sure if it is a problem, if it'd be expensive to accommodate. I'll have to think about it. rlb: $ clojure rlb: Clojure 1.10.2 rlb: (= () nil) rlb: false rlb: user=> rlb: rlb: And at least right now, I've just let scheme lists pun as clojure sequences, so scheme '() currently works just fine anywhere clj's "persistent empty list" should work. rlb: (well, proper lists -- lokke will *not* like improper lists in many places) rlb: It might also be that I can just rework clj equality to handle that. I'm just a bit concerned that there might be a bunch of places where there are implicit assumptions that might be hard to track down or expensive (at runtime) to adapt. rlb: taylan: in any case, if it ends up looking like something we're likely to pursue, could you ping me and if/when I can get some time, I'll try to figure it out in more detail (and/or test the change). taylan: sure thing, if I remember :) leoprikler: iirc the rationale is to use if for #f or nil and null? for '() or nil rlb: fwiw, from the clj side, empty "collections" are intentionally not false. rlb: (empty, possibly lazy, collections) rlb: You have to call (seq x) on them to find out if they're actually empty. rlb: For anyone interested: https://clojure.org/reference/lazy#_the_victim_nil_punning taylan: rlb: does that mean clj's "if" is not the primitive "if" since it has to interpret #nil as true? rlb: #nil isn't true, it's false in clojure rlb: i.e. clj works somewhat like elisp taylan: oh, I assumed that "empty collections" includes #nil taylan: since it's the empty list... rlb: which is why our current elisp support made things easier - clj has nil and () rlb: taylan: clojure has a broader "collections" abstraction, i.e. cons works on anything that's a collection, including lists, vectors, sets, etc. rlb: so as far as clj is concerned, in some senses (), [], and #{} are the same (empty list, empty vector, empty set). rlb: (And map, for, filter, remove, drop-while, reduce, ... work on any collection too -- anything that's "seqable".) rlb: taylan: I suppose another question might be what "level" of release a change like that might require, i.e. X, Y, or Z... rekado: terpri: I would love to help in whatever way I can to revive guile-emacs! I have been blindly rebasing and poking things, but I never got it to work with slightly more recent versions of Emacs and/or Guile, because I don’t know what I’m doing. mbakke: rekado: matplotlib installs jquery to a nonsensical directory, i.e. it has been broken a while. should it be updated or removed? rekado: matplotlib is pretty essential for this whole science Python thing. dsmith-work: Happy Friday, Guilers!! taylan: wingo: quick question: how is (equal? x y) compiled? doesn't seem to call scm_i_equal_p from eq.c unless I eval it. taylan: or at least does some quick-fail stuff before calling it. taylan: I seem to have found it: module/language/tree-il/compile-cps.scm, starting from line 2477 there's some quick-success and quick-fail cases being added to eqv? and equal? calls manumanumanu: taylan: If any of the variables are comparable using eq? or eqv?, the comparison is cahnged to that. At least if it can be decided during compile time I don't know if that helps you RhodiumToad: it looks like that at compile time it also peels out one layer of "eq?" comparison RhodiumToad: i.e. if the values are eq? then they must also be eqv? and equal?, if they're not eq? then they're eqv? if they are equal numbers, RhodiumToad: if they're not eq? and one or other is not a heap object then they can't be equal? taylan: yeah, (equal? x y) is compiled to (if (eq? x y) #t (if (or (immediate? x) (immediate? y)) #f (c-equal? x y))) RhodiumToad: are you looking at 2.2 or 3.0? taylan: 3.0 taylan: (it's compiled to something equivalent to that in logic, I mean) taylan: (the immediate? and c-equal? above are pseudo-code) RhodiumToad: yeah RhodiumToad: I should have said that "if they're not eq? then they're eqv? IFF they are equal numbers" taylan: ugh, apparently there's a further place where (equal? #nil '()) gets optimized to #f, because now I get #t when I (define (test x y) (equal? x y)) then call (test #nil '()), but if I compile (equal #nil '()) directly it's #f taylan: of course, it constant-folds it. now on to find where that happens... :P taylan: oh nice, that was easy, since I had already looked around module/language/tree-il/peval.scm before. RhodiumToad: you defined an equal? that treats #nil and '() as equal? taylan: RhodiumToad: I changed equal? to treat them as equal. Just submitted the patch: https://bugs.gnu.org/48425 taylan: I think it makes sense but maybe I'm missing something. I'll let the higher ups decide :P RhodiumToad: I think having them be equal? but not eq? will be a problem. RhodiumToad: you want #nil equal to '() but not equal to #f ? terpri: RhodiumToad, it might be equal to both terpri: it ought to be equal to both, i should think RhodiumToad: it can't be terpri: see (info "(guile) Nil") RhodiumToad: the problem is that equal? must be transitive, and '() is not equal to #f terpri: (boolean? #nil) ⇒ #t, (not #nil) ⇒ #t, (null? #nil) ⇒ #t RhodiumToad: so #nil can't be equal? to both terpri: RhodiumToad, you're quite right, thanks for dredging up memories of logic class :p yeah, that would make equal? not an equivalence relation which is required by r5rs taylan: yeah, I made it equal to '() but not #f based on the assumption that we want to keep the transitiveness of equal? terpri: i think i got confused by the different behavior in elisp, where #nil, '() and #f are all equal RhodiumToad: it's exactly that different behavior that leads to having #nil in the first place roptat: I have a C source file with a function that takes a pointer to a structure as argument in my project, and I'd like to call it from guile. How can I create the structure pointer in guile (ideally at compile time), and how can I call that function? roptat: I'm not sure where to look at in the manual taylan: roptat: this would be the part of the manual to look at: https://www.gnu.org/software/guile/manual/html_node/Foreign-Function-Interface.html taylan: roptat: and if you want to access/modify complex C structures from Scheme, this library might be helpful: https://github.com/TaylanUB/scheme-bytestructures roptat: mh, I've used foreing interface before, to use code from other libraries, but this time I it's a C source file from my own repo, so I think I want an extension instead? roptat: but all the examples I see are about using int and double dsmith-work: heh: http://www.galassi.org/mark/mydocs/guile-user_6.html dsmith-work: Wow. Was 25 years ago! dsmith-work: twen. ty. five. years. taylan: pretty sure I still used to drink human milk back then civodul: fun tohoyn: sneek: botsnack sneek: :) flatwhatson: revised pointer-ref/set draft: https://paste.gnome.org/p6rn4detz flatwhatson: i'm not sure i understood the suggestion about taking address as a fixnum, should it support passing a numeric value as the pointer arg? taylan: flatwhatson: 404 on the link taylan: but yes, passing a numeric value instead of a pointer object would be preferable, since pointer objects are allocated on the heap. flatwhatson: taylan: weird, it vanished! flatwhatson: revised pointer-ref/set draft: https://paste.debian.net/1197437/ taylan: flatwhatson: looks pretty good to me except that I'd also allow the pointer arg to be a number. though if pointers were made into "immediate" objects like civodul suggested, that would become unnecessary... taylan: and wingo said he's not a fan because the compiler could do it. if the compiler really could avoid bytevector/pointer allocations a lot of the time then I guess it would be mostly unnecessary, though IMO it's good to also have an API to accesses memory without the bytevector abstraction in between. taylan: because if I know I want a uint64 at memory location 0xDEADBEEF then it seems excessive (conceptually) to create a bytevector of size 4 referring to that memory location just to get that uint64. taylan: if you have structs, unions, etc., bytestructures takes care of that whole layer of logic. no need for bytevectors there either. *: taylan goes AFK wingo: https://wingolog.org/archives/2021/05/13/cross-module-inlining-in-guile davexunit: very cool. thanks for the write-up, wingo. flatwhatson: how can pointers be made immediate if SCM are uintptr_t, we need some bits for the tag too? wingo: flatwhatson: either unboxing, if the whole lifetime of the pointer is visible to the compiler wingo: or tagging, if the pointer has suitable alignment (e.g. if it's 8-byte aligned, then the bottom 3 bits are 0) wingo: or tagging, if address space size is less than the word size -- is the case for all 64-bit systems currently wingo: fwiw we also need to consider improvements to the gc. maybe if we have a bump-pointer generational gc, then the cost of allocating a could words might be insignificant wingo: *couple words flatwhatson: interesting thanks! flatwhatson: re: generational gc, would that mean replacing bdw-gc with something else, or writing one bespoke? wingo: yeah replacing bdw-gc with something internal to guile taylan: wingo: not to rush but did you have a chance to look at the R6/R7 SRFI module names patch? it's a pretty straightforward improvement IMO and will significantly improve R7RS compatibility. *: wingo has not done so yet taylan: ok, happy to hear feedback whenever you have time :) mwette: "GC, GC, read all about it!": https://www.cs.rice.edu/~javaplt/411/17-spring/Readings/wilson92uniprocessor.pdf mwette: Some other issues with the FFI are lack support for variadic args and unions. And maybe the pointer->procedure spec's for arg types. I'm working on how to handle structs and unions better, but varargs is a kludge: every call to the function generates a pointer->procedure call. davexunit: a first-class API for creating/parsing C structs would be a huge quality of life improvement davexunit: I know guile-bytestructures exists, but it's hard to justify the additional dependency when I can hack together something specialized that works for my specific case when I need to. taylan: mwette: isn't bytestructures sufficient to handle unions? taylan: davexunit: hmm, I've been thinking a bit whether it would be welcome to include bytestructures in Guile proper. any opinion on that? it's pretty small after all. davexunit: taylan: other languages have FFIs that include this functionality, so yes I think it should be in Guile core. davexunit: anyone that has tried to wrap a C function that doesn't use only primitive types has been burned by the lack of good struct support davexunit: parse-c-struct and co. do not cut it. dsmith-work: {appropriate time} Greetings, Guilers taylan: hi :) davexunit: I've wrapped many libraries at this point and each time I wish guile had something built-in for handling structs. mwette: taylan: pointer->procedure and the underlying libffi API doesn't do unions. So I'm approaching with (struct-covering ) -> struct; and if a vector is inside a struct/union then I need to do (list int int int ...) (equiv (make-list N int)) taylan: mwette: oh, you mean like when a function directly takes a union by-value instead of a pointer to it, right? davexunit: any function that uses structs by value are a pain to wrap in guile davexunit: my freetype bindings are gross as a result taylan: davexunit: have you looked into the bytestructures API to see whether it would solve your problems nicely, by the way? I don't even really use the library myself (!) so I need external feedback to make sure it's actually practical and useful, and not just nice in theory :P taylan: it all just started as an academic exercise; I don't even remember what sparked the idea to make something like it. didn't even realize it would be useful for FFI until someone made me aware! mwette: taylan: yes; structs by-value are handled but not unions by-value; so my approach will be to figure out the size+alignment and make a list that size; but i have to understand how the compiler will deal with floats mwette: pointer->procedure does not accept bytestructure (descriptors), so nyacc's ffi-helper has code to convert bytestructures to (list ...) taylan: wait, I could swear I've written a transformer for that taylan: or... I saw yours and wanted to adopt it but didn't because unions couldn't be handled? been years that I seriously on this project. :\ taylan: *seriously worked taylan: ah, here it is: https://github.com/TaylanUB/scheme-bytestructures/blob/master/bytestructures/guile/ffi.scm taylan: mwette: ^ you're aware of that module? mwette: yes: I remember looking at it, but not the details davexunit: taylan: I haven't used it. I should try it out. mwette: here is .ffi file and (partial) auto-generated .scm for pango: https://paste.debian.net/1197454/ https://paste.debian.net/1197455/ mwette: the ffi-helper will parse structs from C headers and generate scheme code for bytestructure API and for the pointer->procedure API taylan: hmm, not sure how to feel about (equal? '(1 . ()) '(1 . #nil)) => #false. I guess it has to be. taylan: on the flip side, (syntax-rules () ((_ #nil) ...)) will match () and I'm not sure how to feel about that either terpri: after hearing that #nil was being used by the API of some json library, my first thought was that we should make that value much more difficult to access from ordinary programs terpri: almost the *entire* utility of it depends on both scheme and lisp programs' ignorance of its existence terpri: like, possibly it shouldn't even be accessible or (read)able outside of module/language/elisp and a few other places terpri: it's possible to misuse it, simply difficult under ordinary circumstances, but something "more correct" would likely require heavy-duty capability-security tricks that divide guile into multiple "worlds" terpri: and finding a clever but technically slightly-incorrect solution that works in nearly all real-world use cases is very much in the lisp tradition, if one has read the rrrs-authors archives or maclisp news files... terpri: actually, i'm going to track down that json library author and give them a stern talking-to^W^Wfriendly explanation about why guile has #nil in the first place, which i ought've done years ago terpri: taylan, btw, are you working on elisp stuff or just tinkering? terpri: seeing native-comp progress in emacs -- in a way that was not encouraged for guile-emacs -- has motivated me to engage in some friendly, ahem, socialist emulation when i get the time to commit to it terpri: i'm a bit annoyed by the different treatment and would really quite like to make guile-emacs superior to native-comp in both performance and compatibility (guile-emacs would have far better performance if it hadn't been designed for 100% compatibility) terpri: $work is taking up too much time as usual but will be winding down soonish, enough to do other *real* work terpri: and i'm quite willing to fork emacs if that's what it takes, and go for the egcs approach (ecgs was a much-improved gcc fork that quietly replaced the original gcc in 1999) terpri: (furthermore, my odd mixture of roles at $work is actually fairly good preparation for a guile-emacs revival, as i have to do quite a lot of things i used to be not very good at) terpri: (not to mention my fairly extensive JIT-related work with wingo at igalia) terpri: it remains a big project (i only finished the *first* 90%...) but years later, i still have a good grasp on what remained to be done terpri: perhaps i'm tilting at windmills, but perhaps some windmills need tilting-at, and i'm too stubborn to simply give up and let the project die a quiet death. to quote angela davis, "you have to act as if it were possible to radically transform the world, and you have to do it all the time" taylan: terpri: I'd like to work on elisp stuff more seriously but my knowledge of lower-level stuff is not good, such as the VM, the whole compiler stack, etc. I'm confident I could get good at it but I lack time, and a mentor who in turn has time for me :) taylan: I'm in the second week of a two-week vacation so I'll probably return back to being mostly inactive again very soon, though I think I can restart allocating some time to free software on evenings and weekends, like I used to a couple years ago. terpri: taylan, you were a top-notch contributor to guile-emacs all those years ago, second to none, and i was (and am) very grateful for your help; i should have told you that years ago if i haven't already taylan: terpri: thanks for the kind words! I wish I had been able to do more actual programming though. what I did was mostly just talk, to put it bluntly. taylan: I guess one could call it "awareness raising" :) terpri: i also have to admit that i was a really mediocre maintainer, in terms of all the responsibilities of maintainership beyond cranking out a great deal of code; but it was also my first big project, and i'd like to think i've learned a bit in the intervening years taylan: terpri: wait a minute, I have to sheepishly ask now, you're bipt?.. terpri: taylan, yeah, i changed my nick a few years ago (changed first name to robin, so the initials didn't match). no need for sheepishness, i remember the guile GSoC folks were confused too since i didn't actually announce it anywhere ;) taylan: terpri: ahh ok, good to see you again then :D you did *amazing* work IMO, would love to collaborate more on the code-level if we both find the time. davexunit: oh wow welcome back terpri davexunit: more guile-emacs stuff would be rad dsmith-work: terpri: Indeed. Thanks so much. terpri: to be clear on the timeline, the startup i'm working at is promising but has a...short runway, so it could be 3-6 months before i can really attempt a revival (working full-time off of savings, working half-time at this startup or another (which would be allowed here at least), that sort of thing) dsmith-work: terpri: Something that has come up here a few times, is the difference between emacs-lisp the language, and emacs the application. dsmith-work: Emacs buffers for example. terpri: maybe with crowdfunding or an altruistic angel "investor", maybe not, lots of details and not a lot of certainty at the moment terpri: dsmith-work, yeah, there've been some discussions in emacs fora. i'll file it away as a topic for a future blog post :) terpri: guile-elisp provides exactly enough of the language to bootstrap emacs by itself. as bits and pieces of emacs are rewritten in scheme or elisp, guile should have access to more emacs "application" functionality one way or another terpri: it hasn't escaped by attention that emacs has added *some* highly-visible guile-emacs features like bignums, so i'd also have to provide new motivations for it terpri: but, eventually creating a (fast, powerful) lisp machine atop linux is a decent one; i bet you could do some cool things with guile-emacs + guix + spritely-goblins (an object-capability based library for distributed scheme programming), for instance terpri: lisp was prominently mentioned in the gnu manifesto for a reason ;) terpri: heck, just providing secure, networked, distributed programming amongst emacs instances via spritely goblins would be nifty terpri: (spritely goblins = https://spritelyproject.org/) pkill9: cool terpri: quite possibly you could use it *within* emacs to bypass the "M-x gnus is slow" problem, with preemptive multitasking/real threads, but that's just speculation manumanumanu: now, I have to admit I am not too keen on the actor model, but "transactional", "actor model", and "distributed" _does_ tickle the right places. nojr_: hello taylan: terpri: didn't Emacs add support for real threads also? TBH I find it really neat how they added a bunch of nice stuff to Elisp... as in, I'm happy that Emacs's Elisp got all these nice features in the short term, even if it means less motivation for Guile-Emacs in the long term... nojr_: how is everyone :). I've tried joining this chat for over a year now I have acquired enough technical skills to do so:)) taylan: nojr_: hi :) nojr_: that's why I'm happy. Anyway, I have a question I keep getting this error when I run guile in a terminal or in Geiser Emacs nojr_: guile: warning: failed to install locale terpri: manumanumanu, agreed, i like CLOS a lot nojr_: warning: failed to install locale: Invalid argument manumanumanu: nojr_: are you running guile through guix? nojr_: yes terpri: taylan, and i'm happy to see emacs' progress too. i *think* they only have cooperative concurrency though manumanumanu: ah, you need to install glibc-locales (or whatever it is called) terpri: welcome nojr_ manumanumanu: nojr_: ^ taylan: terpri: ahh you're right: https://www.gnu.org/software/emacs/manual/html_node/elisp/Threads.html manumanumanu: or, if you are one of the lucky few, you can install the small bundle of utf-8 locales nojr_: thanks everyone! I'm installing glibc-locales right now. I have a question: I really want to learn Guile but how do I start? terpri: also, it's Top Secret(TM) but i've been *slowly* implementing CL for Guile, so you might eventually be able to do absolutely bonkers things like running maxima *inside of emacs* nojr_: manumanumanu: wow that solved it, was very easy! manumanumanu: nojr_: I don't think there is a very good on-boarding story for scheme. TSPL is dense (and r6rs only, which is fine for guile). terpri: so i can come up with motivations, and in fact we don't even have real benchmarks for emacs-native-comp vs. guile-elisp, so "it runs faster" might still be one (or "its performance profile is better for interactive use", etc.) manumanumanu: nojr_: SICP is fine if you are willing to spend some time thinking (if you are stupid like I am). HTDP is actually very good imho, but is more tailored to racket. nojr_: manumanumanu: I think there is a way to improve that. I looked at artanis as a good project to base a small website tutorial to get started nojr_: maybe building a small CRUD app with it to get used to Guile manumanumanu: terpri: I can't imagine a better argument than being able to work on things like ORG without a full emacs session. nojr_: that's how many people learn to program today with CRUD apps, it's most familiar to lots of young devs at the moment nojr_: manumanumanu: I have tried SICP like three years ago but I am very dumb. That's why I thought maybe I could tinker with artanis, build a small app and write a blog entry?? terpri: manumanumanu, that should eventually be possible! it'd take some serious emacs refactoring, but that's on the long-term TODO list anyway (necessary for rewriting chunks of emacs in guile, almost certainly) manumanumanu: nojr_: That seems like a fine idea. I don't know about your previous experience, but I can say that python programmers usually spend a month or two writing quite slow and icky code - and that's fine! terpri: someday: (use-modules (emacs org)) :D nojr_: manumanumanu: I'll try writing down my progress. I hope that maybe I'd be useful in the future for other beginners like me nojr_: manumanumanu: I'm not much of a beginner since I know Python already but I'm not an expert either, I've only been doing this on my freetime for two years now manumanumanu: nojr_: the main thing is that the main data structure (cons cells/linked lists) don't have fast random access. Going front to back is fine, but programming with them as a python list will be an awful experience and lead to very slow code. manumanumanu: and (set! ...) is usally a code smell manumanumanu: now go write code! :D nojr_: manumanumanu: thanks!! manumanumanu: nojr_: jokes aside. If I am not AFK I can always help with feedback. terpri: but to clarify, the #1 priority is to make a better emacs than emacs, whatever that entails, and there will be plenty of time for pie-in-the-sky projects down the road terpri: and since i also got a privmsg, yes, i'm robin templeton/bpt/bipt (should probably change that hexchat "realname" default) taylan: terpri: btw any opinion on (equal? #nil '()) ? taylan: having (equal? '(1 . #nil) '(1 . ())) => #false feels very wrong to me at least terpri: brb lampilelo: i don't think emacs and real threading is possible, nothing in it is thread safe, fake, js-like threads are good enough to make non-blocking stuff terpri: taylan, yeah, that seems...odd. i'd have to check the original #nil proposal to be sure, but they're supposed to be difficult to distinguish... terpri: might have to dig up an ancient version of guile to see if the behavior changed terpri: iirc the bit-level representation of #nil was designed to make ()-or-#nil tests cheap taylan: yeah there's some special magic in scm.h and pairs.h terpri: lampilelo, difficult, but i wouldn't say impossible. imagine, for example, independent buffer groups that can only communicate with other such groups in special ways, or maybe "rejoin" other groups when a task is done terpri: but if cooperative threading is good enough for elisp programmers, that's fine too, and means less work terpri: although you could also create a pure-guile "real" thread that can only "talk" to emacs via erlang-style messages, something like that terpri: and really if emacs remains unithreaded indefinitely, and can only use threads via calling out to guile, that should be fine as long as the guile side of things doesn't mess around with the main emacs thread, and still might enable some neat demos lampilelo: terpri: what about the global, mutable environment, dynamic context, an idea of (current-buffer) etc.? you'd have to restrict the access to most things on secondary threads or do a major rewrite of the core terpri: emacs will use guile variables, guile fluids and quite possible delimited continuations for buffer-local variables, unless the latter are too slow terpri: but there's definitely C-level structures that threading would break, so it would be either pretty limited and/or a long-term goal lampilelo: oh, i was thinking about threading in emacs, not guile-emacs terpri: ah, yeah. one of them is very slightly easier :) terpri: guile-emacs would still have to be extremely cautious about threading, of course. you could do weird things like stuffing a buffer in a dynamic variable and using FFI to mutate it from another thread, which would almost certainly be a bad idea lampilelo: i'm sure package developers would find simpler ways to do bad stuff with threads terpri: well, also elisp can be blocked from guile access, it just exists for fun and demos atm lampilelo: nah, i would rewrite my init file in guile! terpri: :) lampilelo: for some reason i like guile more than elisp, if we had emacs' "standard library" exposed to guile i'd be in heaven terpri: reconciling lisp-1 and lisp-n is the tricky part there. but we could always do heuristics, or some kind of lispm-style elisp:::(+ 2 2) syntax terpri: kent m. pitman had some notes on just that topic, called lisp-omega i think, which i have yet to review terpri: guile-emacs currently is supposed to store emacs variables and functions in guile modules, which makes .emacs.scm not terribly painful. i don't know if it will stay that way or not terpri: i believe i had to turn it off for "production" because of my old nemesis, buffer-local variables. guile quite reasonably can't (or couldn't) capture bits of the C stack in a delimited continuation, which broke BLVs terpri: but they can be implemented inelegantly *shrugs* terpri: (to clarify: you can implement dynamic binding with delimited continuations, and in fact customizable dynamic binding, which is what i initially tried to do for BLVs. using some kind of magic fluid is probably more practical) dsmith-work: Hmm. recent updates anyway. Looks like mostly for chibi civodul: dsmith-work: i think the original snow was started ca. 2006 civodul: it didn't really take off flatwhatson: not sure about snow usage, but it says there's a client built into chibi so maybe some folks use that? flatwhatson: there's also https://akkuscm.org/ which is more recent and mirrors the snow packages flatwhatson: i love guix but it's pretty heavyweight as "just" a language package manager on non-guix-system machines tohoyn: sneek: botsnack sneek: :) wingo: good morning :) lampilelo: hi manumanumanu: Great morning, everyone! taylan: bit of a weird question but does Guile offer a way of accessing bytes at arbitrary memory locations without having to allocate a bytevector object for it first? think bytevector-u8-ref but taking a memory address as an argument instead of a bytevector and index. leoprikler: taylan you can do a few things with just pointers, but IIUC bytevectors should not be much of an overhead leoprikler: in particular, bytevectors are "backed" by whatever memory you have there, so it's about as much overhead as a pointer taylan: leoprikler: there's the overhead of allocating a Scheme object, which later has to be garbage collected. let me shortly explain the problem... taylan: with the bytestructures library, you can represent a pointer, including the pointed-to type, then use it to access the pointed-to values... taylan: pointers often point to the beginning of an array, whose size may not be known until some time during run-time. taylan: to allow fully dynamic access to the elements, what the library currently does is create a bytevector every time you want to access a value, only to have it thrown away again taylan: if you want to loop over 1000 elements, that's 1000 bytevectors being allocated and thrown away, which is not OK leoprikler: hmm, that does sound like an issue taylan: so I need either a way to access bytes without allocating a bytevector, or the user has to tell the library to explicitly instantiate the bytevector at some point with the appropriate size. leoprikler: taylan I personally think it's fine to ask the user to tell you the size of the bytevector taylan: added an example on how to avoid the allocations, search for "example with guile" on the page: https://github.com/TaylanUB/scheme-bytestructures leoprikler: I don't quite understand how the third version does its magic, but otherwise LGTM flatwhatson: it's re-interpreting the chars buffer as a bs:vector, which can get bytestructure-ref'd efficiently bjoli: taylan: that define-inlinable does nothing in that case, btw. Define inlinable defines the procedure and replaces any direct application with the code expansion, but any reference like (for-each ref million-times) with a pointer to an otherwise hidden definition of ref with a gensymmed name manumanumanu: so: even though it is not immediately obvious, you are still subject to the same run-time lookup if you are referring to a top-level procedure. flatwhatson: taylan: would you like a routine like (pointer-ref pointer type [offset]) where type is one of guile's "foreign types"? flatwhatson: i guess it would make sense to have a corresponding pointer-set! flatwhatson: basically peek and poke taylan: flatwhatson: (system foreign) pointers are Scheme objects so that'd also require allocation. what I need would be like (memory-ref address type), or a number of memory-type-ref procedures like bytevector-u8-ref and such leoprikler: numbers are also scheme objects, so you gain nothing taylan: leoprikler: numbers up to a given size reside on the stack in Guile. actually I'm not sure now whether pointers are really allocated, or use the same kind of optimization, lemme check... taylan: does seem like it. (pointer-ref pointer type) would be OK too then I guess. manumanumanu: taylan: great work on srfi-64, btw :) I have been linking to your implementation about 600 times. taylan: manumanumanu: thank you! great to get positive feedback :) manumanumanu: I have been bitten by the reference implementation 2 times myself flatwhatson: taylan: curious, what did you check to determine that pointers are optimized? taylan: flatwhatson: I found make-pointer in libguile/foreign.c, which uses scm_from_pointer, which creates the pointer as follows: ret = scm_cell (scm_tc7_pointer, (scm_t_bits) ptr); taylan: that scm_tc7_pointer thing is a type flag (they're all called ...tc7...) and the value of the pointer is saved directly in the cell as well. taylan: contrast for instance to what make_bytevector_from_buffer in libguile/bytevectors.c does: ret = SCM_PACK_POINTER (scm_gc_malloc (SCM_BYTEVECTOR_HEADER_BYTES, taylan: SCM_GC_BYTEVECTOR)); taylan: libguile/scm.h is also a useful place to look at to understand some of the magic. I don't have a very firm understanding of it all but from what I can tell, make-pointer doesn't allocate, whereas pointer->bytevector indirectly does flatwhatson: makes sense, thanks! taylan: flatwhatson: correction on what I said before: comes out scm_cell actually allocates a pair. the TC7 type codes identify special kinds of objects that fit into "fake" pairs somehow. taylan: it's the TC3 codes that identify objects that reside directly on the stack mwette: taylan: (pointer->bytevector (make-pointer #x12345678) 128) mwette: where #x12345678 is the address and 128 is the size; from (system foreign) mwette: but doen't help if you don't know the size taylan: yeah, that's the problem. dereferencing a bs:pointer already does exactly that, but with the size only as big as the referenced type, so e.g. size = 4 for (bs:pointer uint64) taylan: in other words, bs:pointer was originally meant really just for pointers to a single value, not as pointers to the beginning of an array. taylan: I now added the ability to dereference it with an integer like you suggested, but it has to do the (pointer->bytevector (make-pointer x) y) for every such reference *: taylan goes AFK for now flatwhatson: rough draft pointer-ref/set: https://paste.gnome.org/p1ow9dbyn *: wingo not really a fan, fwiw flatwhatson: the idea in general or this approach? wingo: a few things. in general, pointers to raw scalars aren't so common -- you have pointers to structs, etc. where it's important, we shouldn't be allocating heap pointers at all. where it's not, the bytevector api is more expressive and ties together better with the rest of the system wingo: we do need a more efficient ffi but i think the path there is through the compiler and not through run-time routines flatwhatson: is it feasible for the compiler to eliminate intermediate bytevectors? flatwhatson: the chez FFI has (foreign-ref type address offset) and (foreign-set! type address offset value) wingo: yes i think it's feasible for the compiler to eliminate those. the chez low-level ffi looks nice tho, i assume the "address" is just a fixnum wingo: or usually a fixnum anyway; anyway the compiler could lower such a foreign-ref / foreign-set very nicely wingo: quite the cowboy primitive of course civodul: i think pointer objects should be immutable civodul: and i think we should have "immediate pointers" when possible amirouche: flatwhatson: IIUC what you want is http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-1.html#node_toc_node_sec_2.4 amirouche: except instead of bytevector, you have a pointer? amirouche: Chez can not expose a bytevector from a C pointer, see also https://github.com/cisco/ChezScheme/issues/486#issuecomment-808829706 wingo: civodul: i think when you have access to make-pointer, then you might as well have the equivalent of foreign-ref / foreign-set amirouche: (pointer->bytevector pointer length) that works without copy will be very handy wingo: amirouche: the compiler could eliminate that fwiw amirouche: eliminate what part ? the copy ? wingo: it doesn't right now, but it could do so relatively easily wingo: making the bytevector wingo: iirc pointer->bytevector aliases memory without copying, right? *: wingo looks wingo: yes, there is no copy there amirouche: that is good then :) wingo: just an allocation of a bytevector dsmith-work: Wednesday Greetings, Guilers davexunit: allocation of bytevectors in pointer->bytevector can be problematic sometimes. davexunit: like in ffi-using code in hot loops that needs to keep allocation low davexunit: bytevector->pointer also davexunit: depending on the situation I usually cache these when performance is a concern taylan: wingo: FWIW how this topic first came up was: how to support the "flexible array member" special feature of C structs in the bytestructure library. taylan: since the bytevector API doesn't allow accessing beyond the declared size of a bytevector, one effectively has to create a second bytevector after getting the length information (that would typically be in the struct somewhere) via the first bytevector. taylan: wingo: do you think it would be useful to have a bytevector sub-type of sorts that doesn't have size info / doesn't do bounds-checking? civodul: wingo: actually i'm sure what foreign-ref is; i thought it was Chez's equivalent of pointer->address, but maybe not? leoprikler: pointer->address just gives a number idk how that would be usable to e.g. reference some int inside a struct pkill9: has anyone created a GUI application with guile? taylan: leoprikler: re. your bug report on elisp keywords: while using Scheme you can call (read-set! keywords 'prefix) to allow :foo to be read as #:foo. have you tried activating that in elisp mode somehow? leoprikler: taylan whatever I do in Scheme has no effect on the Elisp reader, that seems to be a specific bug within it taylan: leoprikler: I think it's normal, since every language defines its own reader. I'm not sure if elisp reuses the regular Scheme 'read' somehow so one just has to set a parameter when starting up the language, or if actual coding is needed... I think it's the latter. taylan: yeah it seems one has to fix it in module/language/elisp/lexer.scm taylan: hmm, or one could just let them parse as symbols like currently, then special-handle them later. compile-symbol in module/language/elisp/compile-tree-il.scm looks promising leoprikler: IIRC Elisp knows the difference between symbols or keywords, so keywords as self-quoting symbols won't fly taylan: leoprikler: hmm. I was planning to compile them into keywords, but I guess that's not enough, as (read ":foo") will then still return a symbol. taylan: what I find puzzling is, there was (is?) a whole Guile-Emacs that actually starts up, and how can that be if the Elisp parser doesn't even know keywords. are they not used anywhere in Emacs's standard libs? or maybe bpt's branch had a fix for this. taylan: does anyone happen to know what happened to bpt aka Robin Templeton? their work was very promising, it's sad that they didn't continue working on it. leoprikler: they use a known-good commit, that perhaps has a different parser leoprikler: I'm using Guile 3.0.2+ RhodiumToad: as far as I recall, elisp has no "keyword" type at all leoprikler: (keywordp :really?) RhodiumToad: that is, :foo is a symbol whose initial value is itself (rather than being unbound) leoprikler: (setting-constant :really) leoprikler: (setq :really nil) RhodiumToad: (symbolp :really?) leoprikler: yeah, elisp symbolp is (or (symbol? this) (keyword? this)) when translated to guile RhodiumToad: elisp's keywordp is like (and (symbolp x) (symbol-name-of-x-starts-with-:)) RhodiumToad: so elisp keywords are just a subset of symbols, not a separate type leoprikler: still, I'd argue that for Guile interop it might be more useful to have them as keywords leoprikler: (define (my-function #:keyword a b c) ...) leoprikler: ,L elisp leoprikler: (my-function :a 5) leoprikler: please don't mind the typos in the scheme part civodul: wingo: i'm preparing the 3.0.7 upgrade in Guix and it's a tiny bit slimmer: 129 MiB vs. 132 MiB for 3.0.5 wingo: nice wingo: probably was the assembler optimizations civodul: er sorry, that's for its whole closure wingo: sure civodul: guile itself is unchanged actually civodul: (libltdl and gmp were removed from the closure) wingo: ah wingo: ah! neat wingo: well, we got away with rewriting "read" in scheme and still made the thing smaller. good civodul: yes, that's nice pkill9: anyone know of any GUI applications written in guile?\ RhodiumToad: the state of play with GUI bindings for guile is not entirely satisfactory RhodiumToad: I wrote some stuff for myself using guile-gnome, it could be made to work but got crashy as soon as you tried anything fancy with events RhodiumToad: guile-gi and g-golf are the more recent attempts at providing access to gtk rekado: https://gitlab.com/kavalogic-inc/inspekt3d.git has disappeared rekado: I liked it as a libfive viewer that can be used from geiser. pkill9: guess i might just have to use python RhodiumToad: tcl/tk is still orders of magnitude easier than any other scripting language for doing simple gui stuff zzappie: rekado: :( libfive is cool. now looking back I think playing with libfive was my first exposure to guile. taylan: oh man, I'm building the wip-elisp branch and Guile used to take AGES to build :D civodul: rekado: it's 503, perhaps that's a transient issue? civodul: it's apparently on Software Heritage too zzappie: civodul: ha, what do you type into the search field? I checked swh and there wrere no results pkill9: RhodiumToad: what programming language do you use for it? python? civodul: zzappie: i run "guix lint -c archival inspekt3d", which does it fo me :-) RhodiumToad: pkill9: for what? RhodiumToad: pkill9: tcl is a language pkill9: ah pkill9: I meant for tk dsmith-work: Deep in the dim dark past, Guile actually had Tk in it. rekado: taylan: I rebased wip-elisp: https://git.elephly.net/?p=software/guile.git;a=shortlog;h=refs/heads/wip-elisp zzappie: civodul: wow! didn't know its an optioin :) taylan: rekado: OMG neat! rekado: taylan: with that I was able to build guile-emacs but it crashed ¯\_(ツ)_/¯ pkill9: dsmith-work: why was it removed? *: zzappie -> zzz dsmith-work: pkill9: No idea. Maybe because it also needed Tcl? taylan: rekado: well it wasn't all that stable to begin with... I'd love to work on it but my knowledge of low-level stuff sucks and my 40 hr/week job is so taxing... RhodiumToad: tk is basically unusable except with tcl. there are tk bindings for other languages, but as far as I know all the still-maintained ones work by embedding tcl into the other language too. RhodiumToad: (there used to be a couple that worked by ripping the tcl parts out and filling them in from the host language, but I believe they all died due to the heavy maintenance effort in keeping up with Tk changes) dsmith-work: Looks like the Tk stuff was removed before the first CVS commit. dsmith-work: RhodiumToad: !! flatwhatson: awesome! flatwhatson: are you working on the pbr renderer for chickadee? brendyyn: I just discovered that one can't nest defines inside a define-public. is there a particular reason for that? ArneBab: Are there existing implementations of the snow r7rs repository standard? https://small.r7rs.org/wiki/Snow/ ArneBab: (it does look a lot like Guix on the surface) wingo: good morning manumanumanu: Good morning! flatwhatson: ArneBab: maybe this? https://github.com/sethalves/snow2-client lloda: why is *random-state* a global var and not a parameter? leoprikler: probably because making it a parameter would be unsafe when considering multiple threads leoprikler: assuming you copied the state between threads, you'd inadvertently get the same result in both threads, which could be dangerous tohoyn: file guile-3.0-uninstalled.pc.in is not used to generate a .pc file in meta subdirectory. is there some reason for this? if not I can fix it. tohoyn: when we are in the uninstalled environment should be have guile-3.0.pc generated from guile-3.0.uninstalled.pc.in? tohoyn: s/be have/we have/ lloda: leoprikler: i don't follow, if you want different results you should restart the generator on each thread. Else you should be getting the same leoprikler: you mean constructing one truely random random-state per thread? That might work, but I wonder how costly it'd be manumanumanu: I don't think copying the random state so that individual parts of the program have the same state is a good default for randomness. manumanumanu: However, doing it yourself would be pretty simple with the current API manumanumanu: Just (copy-random-state), roll your own parameter-based solution and generate the same random numbers in different threads all day :) leoprikler: right, state as function argument allows for such things dustyweb: hi dustyweb: wingo: I'm attempting to un-bitrot ijp's compile-to-js branch dustyweb: the main thing that I'm unsure what to do about is dustyweb: system/base/compile.scm:245:17: In procedure failure: dustyweb: multiple compilers; language should supply chooser dustyweb: via pk I can see: dustyweb: ;;; (compilers ((bytecode . #) (js-il . #))) dustyweb: but it looks like tree-il/spec.scm *does* specify a #:compiler-chooser so I'm not sure what should be done? tohoyn: wingo: I fixed the guile code so that file guile-3.0-uninstalled.pc is generated. are you interested? wingo: not sure! there are a few things you need to get right to be able to use guile uninstalled and be sure not to load .go files from the installed dir tohoyn: wingo: I rebuilt Theme-D to use the uninstalled guile. It seems to work. dustyweb: wingo: ah, figured it out dustyweb: it was in the cps section that it needed the chooser dsmith-work: Hey Hi Howdy, Guilers manumanumanu: hi-ho, dsmith-work dustyweb: hm dustyweb: okay dustyweb: I merged ijp's 2017 compile-to-js branch dustyweb: I can now compile (+ 1 2) to js ;) dustyweb: however more the amb.scm example ijp wrote out in his gsoc ending email no longer works, unfortunately dustyweb: I think "the land of cps" changed a bit dustyweb: it appears things fall apart converting between cps and js-il.scm dustyweb: wingo: I think I may have reached the point where I'm going to need help dustyweb: but I posted to the mailing list about my progress, and pushed the branch as it stands *: wingo gtg, happy to give more feedback tomorrow dustyweb: wingo: look forward to talking then :) dustyweb: oh wow dustyweb: https://gitlab.com/tampe/stis-parser is cool *: wingo going to merge cross-module inlining, la la la davexunit: :) davexunit: excite civodul: woo! taylan: very cool taylan: BTW I faintly remember a discussion long ago about supporting the .sld file extension. is there anything new about that? I think there were concerns about performance or something (lots of additional file-name lookups) lampilelo: taylan: i was just reading your mails to guile-devel regarding srfi-64 lampilelo: i see this implementation has the same bug as the reference implementation had until some time ago, if a global runner wasn't installed it installs what should be a temporary one, but doesn't uninstall it after the test is complete lampilelo: this was fixed by a patch in the reference implementation some time ago, but that one broke it the other way, it instead uninstalled a runner unconditionally after the test, even if there was a global one already lampilelo: and that one was fixed very recently lampilelo: taylan: at least i'm assuming you are the person who proposed new implementation, judging from the nick rekado: taylan: “.sls” is already supported. I don’t know of any discussion about .sld. taylan: lampilelo: yes, it's me. can you elaborate on how exactly that constitutes a bug? i.e. what would be the motivation of explicitly unsetting the test runner again after test-end? lampilelo: taylan: from the srfi-64 spec: "Additionally, if the matching test-begin installed a new test-runner, then the test-end will de-install it, after reporting the accumulated test results in an implementation-defined manner." lampilelo: although i have to say this implementation doesn't have the other bug i was thinking about fixing upstream lampilelo: the one that makes the test suite error out on test-group if you don't have a runner installed taylan: lampilelo: interesting catch, I guess I can implement uninstalling the default runner to be fully conformant to the spec. lampilelo: taylan: said that, i don't have any say on what gets to be included in guile, just pointing some stuff out, your code runs my tests as expected taylan: lampilelo: the implementation is also part of my Scheme SRFIs project so I'll implement the fix either way :) taylan: will have to send yet another updated version of the patches, LOL lampilelo: :D taylan: lampilelo: do you think it would be correct if test-begin stored a flag "auto-installed" in the test runner when it auto-installs it, and test-begin checks for that flag, and sets the current runner explicitly to #f if that flag is set? taylan: I'm trying to think if there's any situation in which it would be wrong to set it to #f, like if instead I have to keep a stack of test runners or something... taylan: but since the auto-install behavior only happens when it was #f during test-begin, I think it should be fine to set it to #f after, given that said flag was set to indicate that it was, indeed, #f before. lampilelo: this might break if you had nested tests lampilelo: i mean maybe not break, but it would install and uninstall a runner on every test in a test group, which would be a waste lampilelo: taylan: my fix for the srfi-64 upstream was to install a finalizer with test-runner-on-final! when creating such temporary runner, i don't know if it's the best solution but it works with their implementation taylan: lampilelo: when a nested test starts, the runner will not be #f, so it won't install a new one... but when the group ends, it will be deinstalled and that's clearly wrong, heh. taylan: but yeah I can do it on the same condition as when on-final is called lampilelo: you're right lampilelo: in that case i think it's a cleaner design *: taylan goes to zzz dsmith-work: !uptime sneek: up 1 week, 20 hours, 16 minutes ArneBab: flatwhatson: yes, like this — thank you! dsmith-work: Does anyone use snow? dsmith-work: Heh dsmith-work: "Scheme is like a ball of snow. You can add any amount of snow to it and it still looks like a ball of snow. Moreover, snow is cleaner than mud." -- Marc Feeley ArneBab: dsmith-work: I don’t know tohoyn: sneek: botsnack sneek: :) meo: how would I implement a DSL like (with-foo foo (bar-fn 1 2)) where foo is passed to exp implicitly and bar-fn is not a top-level definition? parameterize foo and use syntax rules for bar-fn? meo: s/exp/bar-fn/ leoprikler: what is bar-fn? meo: leoprikler: foo is an immutable srfi-9 record, it contains text terminal buffer, cursor position and similar settings, bar-fn are procedures that e.g. move cursor or apply changes to buffer meo: so I would like to do something like (in-terminal term ((move 10 10) (fill-rect 5 5))) etc leoprikler: i think you could implement the latter part inside a match(-lambda) meo: oooh let me google it leoprikler: e.g. (move x y) gets translated to (set-fields term ...) leoprikler: meo: search for "ice-9 match" inside the documentation meo: yes found it already, thanks meo: how would I pass the context object to these methods? isn't using an implicit argument to a procedure a violation of functional purity? meo: oh right pattern matching would be able to do that on syntactic level I guess meo: well more homework to do, excellent leoprikler: as for in-term, that would than be (call-with-term term (lambda (term) (for-each (match-lambda ...)))) meo: oh yeah I saw that pattern leoprikler: (for-each (match-lambda ...) ) leoprikler: oh, but since you're using immutable records, you should (fold (match-lambda ...) term ) meo: then I can apply a top level syntax transformer to abstain from explicitly quoting the DSL calls meo: I'm a bit too excited leoprikler: actually... I think you can (fold (match-lambda ...) term quoted-syntax) directly leoprikler: no need to jump through an extra lambda meo: I'm going to try it all out in the evening meo: thanks tons for the advice meo: any suggestions to using arrays inside an immutable structure? I basically spawn a new deep copy on every modification and it feels.. uncomfortable leoprikler: if you can make do with lists, lists are typically wiser leoprikler: otherwise I'd suggest using some functional data structures like fector meo: list-ref isn't O(n) is it? leoprikler: list-ref is O(n) wingo: morning :) sneek: Welcome back wingo, you have 1 message! sneek: wingo, civodul says: hi! WDYT of this 'sleep_pipe' issue when forking and of the proposed patch? https://issues.guix.gnu.org/41948#6 ? leoprikler: what are you using that array for? meo: leoprikler: abstract character and attribute buffer wingo: excellent debugging, civodul and flatwhatson :-) wingo: so i guess we should release 3.0.7 today, wdyt civodul meo: leoprikler: it's rank 2 meo: I _suppose_ I could implement some data structure on top or just do something silly like a map hased by coordinates leoprikler: I imagine that gets filled quite quickly tohoyn: wingo: what do you think about bug #45131? meo: actually at this point I care more about correctness than performance civodul: wingo: hi! SGTM! meo: the underlying structure is private and can be changed later meo: maybe I should just implement it in C or something civodul: wingo: can you take care of it? civodul: i think we need to update NEWS for earlier fixes meo: oh yeah speaking of which, one of the tests in guix causes guile to crash meo: I need to isolate that... leoprikler: since you need O(n) for copying, what exactly is the problem with using lists instead of vectors then? I assume the access, but if you're clever with your fold's you should have overall O(n) for your algorithms leoprikler: s/fold's/folds/ wingo: civodul: yeah i can do it wingo: tohoyn: sure can apply that one wingo: tx for poke tohoyn: wingo: ok. tx. tohoyn: wingo: could you inform me when it has been applied? meo: leoprikler: im cheating by buffering the changes, anyway it's too early to consider this a problem wingo: tohoyn: done tohoyn: wingo: tx wingo: lloda: do you anticipate breaking chanes from the srfi-64 change? *: wingo recalls quite a number of user problems from the last srfi-64 update wingo: release all done; the manual commit is taking time because fucking CVS lampilelo: wingo: the change to srfi-64 fixes the bug introduced by the last one, if someone, in the meantime, wrote code that relies on that bug, it will break wingo: omg what, are we going to have another round of people wondering why their srfi-64-based test suites fail??? lampilelo: the problem with the last change was that the test runner was getting uninstalled every time the test group finished lampilelo: this change makes it so the test runner is gettin uninstalled only if there was no test runner to begin with and the test group introduced a temporary one lampilelo: it shouldn't have any side-effects other than fixing the bug, also i can take all the blame because it's my patch lampilelo: s/test group/test/g civodul: wingo: yay, thank you! \o/ wingo: lampilelo: sounds good :) lampilelo: i'm thinking about another fix to srfi-64 because there's a problem of test-group not working if you don't have a runner installed, i suspect people don't like srfi-64 for testing because of this kind of small bugs that prevent it from "just working" wingo: compatible fixes that smooth user experience are golden lampilelo: so you say there was a slew of people complaining but nobody made a patch! outrageous! ;) wingo: :-) lloda: i had to fix my own tests after the earlier srfi-64 patch, but i didn't have to do anything for the latest one fwiw meo: b emanuele6: b chrislck: d rekado: q mwette: meo: look at share/guile/3.0/module/language/cps/with-cps.scm meo: thanks, will look meo: aaaah! meo: thanks much appreciated meo: I dont have the faintest idea how to test constructs like these dsmith-work: Morning Greetings, Guilers dsmith-work: RELEASE!! taylan: heya, is there an actual bug tracker for Guile? I was only able to find the mailing list archive, which can't give me a list of open reports if I'm not mistaken. rekado: taylan: bug-guile@gnu.org is backed by debbugs lampilelo: https://debbugs.gnu.org/cgi/pkgreport.cgi?bug-rev=1;archive=0;package=guile taylan: ah, thanks. for some reason Google was useless. dsmith-work: sneek: bugs? sneek: bugs is Send reports to bug-guile@gnu.org, and see bug reports at https://bugs.gnu.org/guile taylan: does anyone happen to know where the module (system syntax internal) is defined? I can only find module/system/syntax.scm which uses it but doesn't define it. taylan: ok, I found where the forms exported from the module are defined (in libguile/syntax.c), still curious how the module is defined though. dsmith-work: taylan: Look at line 4700 in boot-9.scm taylan: oh, doh, like 10 lines above where I looked :) dsmith-work: Behold the mighty power of grep! (or ripgrep in this case) zimoun: hi! sneek: Welcome back zimoun, you have 1 message! sneek: zimoun, efraim says: changing the zstd test to use compression level 16 worked. I'll commit the change to core-updates. efraim: I think that was a while ago zimoun: yeah probably. :-) zimoun: civodul: test-assert with with-exception-handler fails excepts if it is wrapped with call/cc. The exception is generated by raise-exception make-error. I guess, I miss something. Why does it work with call/cc and not without? civodul: zimoun: do you have a specific example? civodul: BTW, as a rule of thumb, never use call/cc except for SICP :-) zimoun: a function that returns an exception (define-exception-type). This function is “new” gem->guix-package from Guix and we are trying to test “(gem->guix-package "do-not-exist")” civodul: zimoun: so what about: (test-assert "xyz" 'exc (guard (c ((error? c) 'exc)) (gem->guix-package "does-not-exist"))) ? civodul: there are quite a few tests like this civodul: (note: Guix doesn't use the Guile 3 exception API yet) zimoun: civodul: thanks. Is it a willing to not use Guile 3 exception API? Or can we add it for the new tests? civodul: zimoun: for now we'll stick to srfi-34 or good'ol catch civodul: (current Guix still builds with 2.2) davexunit: in case anyone else likes this stuff: here's the classic Sponza scene as currently rendered by a glTF importer and renderer written in Guile https://blob.jortage.com/blobs/4/5c7/45c744b520e0956b824a97517543e328411904acf7308073df0893458d2dcc61a2ceb871c07f59883f6f581d0e7914c139e6da15772335b13b0d74f3d8277827 davexunit: (TODO: apply lighting) davexunit: thanks, guile-opengl flatwhatson: nice, thanks ludo! tohoyn: sneek: botsnack tohoyn: it seems that correction to bug #45131 has not been integrated to the upstream guile. why is this so? tohoyn: I just fetched new guile with "git clone" and checked that. RhodiumToad: moo RhodiumToad: sneek: botsnack RhodiumToad: sneek awol again? dsmith: sneek: botsnack sneek: :) dsmith: sneek: tell Kimapr[m] just testing sneek: Kimapr[m], dsmith says: just testing RhodiumToad: sneek: botsnack sneek: :) dsmith: leoprikler: Something you said in #guix killed the bot. "sneek tell Kimapr[m] {something}" dsmith: leoprikler: Do you what the {something} was? leoprikler: I can test it here if you want: sneek tell dmsith to use "later tell" instead of "tell" leoprikler: sneek tell dmsith to use "later tell" instead of "tell" leoprikler: yep RhodiumToad: bwahaha RhodiumToad: how to confuse a bot to death :-) lampilelo: lol dsmith: In bot/infobot.scm: lampilelo: poor sneek dsmith: 154:22 8 (_ "leoprikler" "#guix" "sneek tell Kimapr[m] use \"lat…") leoprikler: I pity sneek for trying to figure out what I said :( leoprikler: sneek: botsnack sneek: :) lampilelo: wait till a bug kills a sentient ai you liked leoprikler: That happens all the time in media :( RhodiumToad: sneek tell sneek to tell sneel to use "later tell" instead of "tell" RhodiumToad: oops, typo dsmith: The bare "tell" functionalty (which I never tried to get working) is so the bot addresses the answer to someone else. RhodiumToad: ah dsmith: sneek: botsnack sneek: :) dsmith: sneek: tell me something dsmith: sneek: tell dsmith something dsmith: sneek: later tell dsmith something sneek: Got it. dsmith: ok sneek: Welcome back dsmith, you have 1 message! sneek: dsmith, dsmith says: something dsmith: sneek: later tell dsmith use later tell, not tell sneek: Will do. dsmith: sneek: botsnack sneek: Welcome back dsmith, you have 1 message! sneek: dsmith, dsmith says: use later tell, not tell sneek: :) leoprikler: sneek tell dsmith hi leoprikler: ahh, so tell is disabled dsmith: Since "tell" is currently not really useful, I've disabled that leoprikler: could you make sneek reply "Tell them yourself."? dsmith: Hah dsmith: Maybe, I'd have to think about it some. RhodiumToad: sneek, later tell sneek to later tell sneek to use later tell, not tell sneek: Umm, I'm right here. RhodiumToad: heh *: RhodiumToad is easily amused leoprikler: sneek tell RhodiumToad hi leoprikler: oh, tell is still enabled dsmith: leoprikler: "later tell" is, "tell" is gone. leoprikler: s/en/dis/ D: manumanumanu: Does anyone here know stuff about RRB-vectors? I don't want to go reading some other source code to get the answer, but I am having trouble with maintaining the invariant... lfam: Hi, user vivien_ reports "There’s a typo in the guile manual, raise-exception is documented with #:continuable but in reality it’s #:continuable? with a question mark" civodul: sneek: later tell wingo hi! WDYT of this 'sleep_pipe' issue when forking and of the proposed patch? https://issues.guix.gnu.org/41948#6 ? sneek: Got it. apteryx: RhodiumToad: serializer #f or empty-serializer (defined elsewhere) would be sufficient! RhodiumToad: apteryx: does that code work as is? RhodiumToad: oh, I see the problem I'm having RhodiumToad: try it like this: https://dpaste.org/pjKg RhodiumToad: (all I've checked is that it produces something that looks vaguely sane when rendered from tree-il back to scheme RhodiumToad: the (%location -location) thing looks wrong but as far as I can tell it's not changed apteryx: RhodiumToad: oh, that makes sense! Thanks for showing me how to propagate the needed information to the helper. apteryx: about the %location -location, yeah, that looks like a bug; I've seen warnings when compiling modules making use of define-configuration. RhodiumToad: looks like a missing arg to me RhodiumToad: first arg to that "id" macro is the syntactic context, not one of the elements of the name RhodiumToad: that's probably not the only way to address the problem, but it was the most obvious to me apteryx: ah, indeed! apteryx: RhodiumToad: I had thought about doing something like this, but had failed to see that I could use exact patterns such as #t to convey the needed information apteryx: so to me it looked like I'd go in circles, eh. RhodiumToad: well in this case the #t / #f passed to the helper is a normal datum RhodiumToad: the only hard part was figuring out how to make the helper generate the right syntax in the no-serialization case apteryx: hm, yes, that's what I meant with my broken jargon 'exact pattern' ;-) apteryx: It seems to work perfectly! Thanks for having guided me through it! Who should I credit in the commit message (if you don't mind!) ? RhodiumToad: me :-) you can credit me as RhodiumToad or as Andrew Gierth (or both) apteryx: OK! Thanks. apteryx: if you pm me your email I could simply give you authorship of the commit, which would be more accurate :-) RhodiumToad: I'd prefer not, just credit me in the message apteryx: alright! *: chrislck never thought define-syntax-rule could be inside a (define) environment... civodul: o/ emanuele6: o/ civodul: flatwhatson: i followed up on the libgc/munmap issue at flatwhatson: ah great, really happy my stubborn investigation of that unit test paid off! civodul: it did! much appreciated civodul: i have patches regarding the finalizer pipe and thread "sleep pipes", not sure if that's what you were looking at civodul: https://issues.guix.gnu.org/41948#6 civodul: lemme know you think! flatwhatson: ooh, nasty flatwhatson: (the bug, not your patch... :) flatwhatson: civodul: lgtm, except i think GC_set_finalizer_notifier should only happen if thread is created successfully flatwhatson: do we need to worry about unlocking the mutex when throwing scm_syserror? flatwhatson: civodul: https://paste.gnome.org/pyuzibuur flatwhatson: the full patch to finalizers.c: https://paste.gnome.org/ph3lewjl8 flatwhatson: guile: finalizers.c:258: start_finalization_thread: Assertion `finalization_pipe[0] == -1' failed. flatwhatson: oh, right, if creating the pipe succeeds but creating the thread fails, it's left inconsistent flatwhatson: this one is *tested*: https://paste.gnome.org/pnhdjp5qy flatwhatson: running test-out-of-memory gives multiple "error creating finalization thread", which means it's properly retrying thread creation and properly cleaning up if/when that fails tohoyn: sneek: botsnack sneek: :) civodul: flatwhatson: ah yes, that makes sense to me, thanks! civodul: could you send the updated patch to 40525@debbugs.gnu.org? civodul: i'll give it another look later today and apply it if everything goes well civodul: i'd also like to have a test for the sleep_pipe problem flatwhatson: civodul: should that be 41948@debbugs.gnu.org, as a follow-up to your patch? flatwhatson: sneek: later tell civodul https://issues.guix.gnu.org/41948#9 sneek: Okay. civodul: flatwhatson: thanks for the revised patch, i've pushed it! civodul: i also pushed the 'sleep_pipe' patch i posted earlier civodul: it fixes the problems we were observing before \o/ civodul: maybe wingo can comment later flatwhatson: sneek: later tell civodul I've tested with libgc-7 and confirmed it doesn't have the mmap(PROT_NONE) bug. The difference is that libgc-7 defaults to `--disable-munmap` where libgc-8 defaults to `--enable-munmap=6`. Building with a libgc-8 with `--disable-munmap` doesn't suffer from the bug. sneek: Got it. civodul: hi! civodul: flatwhatson: thanks for digging the libgc/--disable-munmap issue! civodul: do you know if there are other implications of building with --disable-munmap? civodul: i suppose the effect is that GC memory is never reclaimed, right? flatwhatson: civodul: correct, so more likely to get oomkilled if it's a legit memory exhaustion flatwhatson: otherwise i think it's not a big deal, especially as libgc-7 defaulted to having it disabled flatwhatson: disabling it until upstream fixes the bug seems sensible to me civodul: flatwhatson: yes, agreed civodul: did you report it upstream? civodul: i'll change the libgc@8 package in Guix wingo: civodul: issue with flipping jit permissions is if thread A is running code from partially-filled page P, and thread B goes to add to that page, it would probably cause a fault wingo: a solution is, each jitted function starts on its own page. but that is terrible for memory civodul: wingo: uh, indeed civodul: perhaps you can have one function per page on macOS if that's what it wants civodul: and on GNU/Linux you'd make it read-only only once it's filled civodul: dunno if that helps wingo: yeah i think that makes sense as a short-term solution wingo: not sure what an optimal solution looks like. apple silicon is really memory-constrained so i can't imagine that's their optimal use case amirouche: hello, anyone can tell me how much time the following program take in seconds with a recent guile version? amirouche: https://dpaste.com/68DLGDSY5 amirouche: with guile 3.0.1 coming with ubuntu 20.04 (LTS), it runs forever. wingo: probably similar on more recent guile, because it uses call/cc wingo: should use call-with-prompt if you want it to go faster flatwhatson: civodul: yes it's reported upstream here: https://github.com/ivmai/bdwgc/issues/353 civodul: flatwhatson: awesome, thank you! flatwhatson: happy to help :) flatwhatson: i think there is another bug here around "error creating finalization thread", spawn_finalizer_thread() sets the notifier callback to notify_finalizer_to_run regardless of whether start_finalization_thread succeeds, so we'll never retry launching the finalizer thread wingo: aaah i see wingo: do you think the finalizer thread should be the one to set the finalizer notifier? wingo: i.e. move that call up to line 214 or so flatwhatson: i was thinking 266 but yeah, maybe better to do it from the thread? wingo: yeah dunno, hard to say wingo: no strong opinion there wingo: i guess i would want to make sure that entering guile didn't throw an exception -- assuming that in this case we're talking about severe OOM wingo: so perhaps better to do so in the inner function, once we know that the thread is ready to do the finalizations civodul: i have a stash with a fix in this area: https://web.fdn.fr/~lcourtes/pastebin/guile-finalizer-fixlet.html civodul: (i don't recall what the impetus was nor why i dropped the ball) *: wingo cheers civodul and flatwhatson on :) civodul: ah yes, it must have been this: https://issues.guix.gnu.org/41948 lampilelo: is it better to (let ((proc-input-param (modify proc-input-param))) (use proc-input-param)) or (set! proc-input-param (modify proc-input-param)) (use proc-input-param)? leoprikler: lampilelo: (use (modify proc-input-param)) :P lampilelo: lol leoprikler: if you need to extract that logic though, let is friendlier lampilelo: (use1 proc-input-param) (use2 proc-input-param) ... lampilelo: my question is more about what's the best practice, set! wouldn't allocate as much as let leoprikler: Are you sure about that? lampilelo: no lampilelo: i should add theoretically in my mind leoprikler: As long as you don't use set, the compiler can optimize very much. leoprikler: In particular do stuff like inlining etc. leoprikler: once you do alter variables, things are no longer so clear leoprikler: see also the good old tail recursion loop equivalence wingo: let is free wingo: set! is not davexunit: as in... set! allocates??? lampilelo: ok, so let is the way to go, then leoprikler: davexunit: For set! you need boxes IIRC, for let you don't leoprikler: so if a variable is never set! you can just pass the pure value around leoprikler: if OTOH it is, you need to implicitly generate variable-refs etc. davexunit: makes sense davexunit: I don't use set! much. I do use the generic method set! in goops code, though. davexunit: but most of my low level code is using special setters for bytevectors and such lampilelo: that's good to know, i try to avoid set! but now i think i'll avoid it more rekado: there seems to be a bug with r7rs include-library-declarations rekado: getting errors like this: unknown location: source expression failed to match any pattern in form (((include "test-runner-simple.body.scm"))) rekado: or this: unknown location: unexpected syntax in form () rekado: I don’t know where this extra wrapping in parentheses comes from. rekado: (I’m trying to package Taylan’s scheme-srfis) wklew: rekado: I don't know if it's related, but cond-expand in r7rs define-library forms is also broken wklew: it leads to similar looking errors wklew: https://www.mail-archive.com/bug-guile@gnu.org/msg10146.html wklew: actually the same error: (from that post): unknown location: source expression failed to match any pattern in form (((begin (define foo 42)))) wklew: oh wow looks like wingo just patched it! wklew: https://www.mail-archive.com/bug-guile@gnu.org/msg10468.html wingo: took me long enough :P wingo: will roll a 3.0.7 shortly rekado: ooh, super neat! wklew: I'm really excited for that, trying to develop portable R7RS libraries has been frustrating dsmith-work: Happy Friday, Guilers!! emanuele6: happy friday :) amirouche: re https://dpaste.com/68DLGDSY5, i replace both call/cc with call/ec it raise an error: ERROR: In procedure abort: Abort to unknown prompt amirouche: replacing either of the call/cc with call/ec does work too. amirouche: same error. RhodiumToad: why would you expect it to work with call/ec ? RhodiumToad: you can (I believe) do generators with delimited continuations, but (as the name implies) the dynamic scope of the generator has to be delimited somehow *: RhodiumToad has played around with shift/reset to do some of this kind of stuff amirouche: Andy W. told me to use prompts so I did. amirouche: It seems like make-coroutine-generator can not be implement with delimited continuations. I have no practical experience with delimited prompt, even if I understand they re not "unlimited" RhodiumToad: in particular, the thing you can do with call/cc that you explicitly can't do with call/ec is to store the continuation somewhere and reuse it after the call/ec has returned amirouche: that is what I had in mind. RhodiumToad: using prompts is better, IMO, but you can't just switch call/cc for call/ec amirouche: The way I say it is: given (call/ec proc), PROC will take the continuation as argument, and that continuation must be called during the extent of PROC, once PROC has returned the continuation is invalid. amirouche: I was doing benchmarks about call/cc but I only tested wall clock time with bash's time. I need to also benchmark memory use, but that is more complicated. amirouche: I mean, I think it is difficult to predict what will be on the stack in real program, and whether it matters. RhodiumToad: it took me a couple of days of serious study to get my brain around shift/reset, mostly by using some stuff I found on oleg's site at okmij.org/ftp RhodiumToad: I got to the point of being able to do a tree comparison coroutine-style RhodiumToad: (i.e. given two generators each of which walks a tree, do they generate the same sequence) wingo: i will be honest, i never got my head around the shift/reset formulation of prompts. the only concept that stuck was call-with-prompt / abort-to-prompt RhodiumToad: is that why the documentation on them is so sketchy? :-) civodul: wingo: same for me (and i'm glad i'm not the only one :-)) apteryx: hello! I've revisiting some misunderstanding/problem I couldn't solve with syntax-parameterize. Is the following expected to work, or am I doing something wrong? https://paste.debian.net/1196664/ apteryx: It seems the syntax-parameter value doesn't stick when the syntax recurses itself wingo: RhodiumToad: yeah probably :) leoprikler: W.r.t. 3.0.7, has 45131 made it upstream yet? :P wklew: i think of shift/reset as being like prompt/abort except that the inner operator (shift) is "in control" wklew: as opposed to abort, which acts like a handler wklew: it is a funky inside out way of looking at a program wklew: sorry, meant to say prompt acts like a handler, since it receives the continuation from the outside RhodiumToad: control flow with shift/reset can get weird RhodiumToad: e.g. (define (k3) (shift c (c 1) (c 2) (c 3))) (reset (let ((x (k3)) (y (k3))) (pk x y))) RhodiumToad: that sort of thing can get very "COME FROM"-y apteryx: is it possible to pass an ellipsized value as an argument to a syntax helper procedure? RhodiumToad: not by itself, it would have to be inside a #' form I believe RhodiumToad: (define (myhelper s) (pk (syntax->datum s)) s) (define-syntax foo (lambda (s) (syntax-case s () ((_ blah ...) (myhelper #'(blah ...)))))) RhodiumToad: (foo write 1) then pk's ((write 1)) and then writes 1 leoprikler: btw. I just noticed, that ice-9 match doesn't handle #nil :( leoprikler: okay, screw me, I just messed up my order lampilelo: ok, i hope my adventure with geiser problems is over, i made a patch, don't know if it's 100% correct but works for all cases i tested for, of course throwing away some syntax metadata but whatevs! i just want it to work lampilelo: who needs the outer syntax data from # #)> anyway RhodiumToad: uh, lexical scope? lampilelo: the thing is it's passed as `(,proc ,@args) to eval anyway lampilelo: args being the inner list of syntax objects lampilelo: i wanted to change it to `(apply ,proc ',args) without passing args through syntax->datum but it produces some strange warnings i don't know the origin of *: civodul thinks we may have a problem with thread->sleep_pipe and fork lampilelo: how so? civodul: sorry, that's not related to what you were discussing civodul: but it looks like child processes can end up using the same sleep_pipe as their parent lampilelo: i know it's not related, just curious RhodiumToad: um, well, fork and threads have never worked well together apteryx: any clue how to make the following pattern work (is it possible?): (_ stem (field (field-type def ...) doc custom-serializer ...) ... (no-serialization ...)), where no-serialization should act as a present/absent toggle switch, rather than the catchall glob it seems to be currently behaving as RhodiumToad: you mean you want it to be a syntactic keyword? RhodiumToad: if so, you need to add it to the list of keywords in syntax-rules or syntax-case apteryx: hm, I'm not sure I want it to be a syntactic keyword; I want it to be provided by the user of the macro RhodiumToad: I mean, do you want the user to have to write literally (no-serialization whatever) apteryx: e.g. (define-configuration my-config (some-field (number 10)) (some-other-field (string)) (no-serialization)) RhodiumToad: ok, so that's a keyword RhodiumToad: because you're looking for the symbol no-serialization rather than some arbitrary (foo) apteryx: right! RhodiumToad: not sure about making it optional though RhodiumToad: rather than having two rules, one with it and one without apteryx: the macro body is rather complex and doesn't factorize out well (it makes use of with-syntax for example) RhodiumToad: a challenge! apteryx: it may be that my macro foo is too weak (it is!), but I couldn't make it work that way (via 2 patterns), short of copying most of the logic at both places apteryx: if you're up to the challenge, the task is to take this macro (define-configuration) here: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuration.scm#n122, and teach it to disable its serialization support via a syntactic keyword such as no-serialization. RhodiumToad: hm RhodiumToad: you want to omit the (serializer ...) clauses from the output if no-serialization is set? RhodiumToad: or is something like (serializer #f) sufficient? flatwhatson: sneek: later ask ludovic any chance you were seeing SIGABRT with "mmap(PROT_NONE) failed", not just warnings? that would be the same out-of-memory bug. i guess some guix infrastructure could legitimately hit this case due to memory pressure while running builds sneek: Got it. civodul: flatwhatson: oh right, it may have been SIGABRT actually civodul: like this one: https://issues.guix.gnu.org/40525 civodul: looking at https://issues.guix.gnu.org/40525#4 there could be a bug still lingering here flatwhatson: oh yep, that's exactly the bug. well, i have a patch for libgc 8.0.4: https://paste.gnome.org/pvaze9jpz civodul: looks like a workaround more than a fix though, no? flatwhatson: not really, mprotect(PROT_NONE) is as well documented as mmap(PROT_NONE). it's not clear why libgc would prefer mmap as the common case flatwhatson: latest master libgc actually expands that ifdef to cover AIX, HPUX and HAIKU which exhibit the same/similar problem lampilelo: i git-bisected guile and it seems that the incompatibility between geiser and guile started when (read) was replaced by (read-syntax) in language/scheme/spec.scm, i know too little about how stuff works internally to really understand the problem lampilelo: i assume the tests for repl are enabled and pass (otherwise someone would notice), is there something different between the test cases and geiser<->repl connection? it's faulty for both tcp and unix sockets lampilelo: maybe tests use the same stuff in both client and server, but the incompatibility lies in a changed spec? lampilelo: when talking with outside world, that is lampilelo: ok, i'm leaving it at that for now, just wanted to dump what i learned, maybe someone would know what's the matter, the breakage starts at commit is 03448b289d9804bb27b633b82e22cf7be55743c5 lampilelo: s/is// flatwhatson: geiser-guile has some magic around compilation & evaluation, problem is probably in here: https://gitlab.com/emacs-geiser/guile/-/blob/master/src/geiser/evaluation.scm lampilelo: so you say it's geiser that should adapt to the new way of doing things? i can add a ticket to their issue tracker tomorrow flatwhatson: hard to say who is at fault, but i would start looking there for the root cause of the bug lampilelo: geiser's code didn't change though lampilelo: ok, i'm going to bed, good night flatwhatson: libgc failures now reported upstream: https://github.com/ivmai/bdwgc/issues/353 daviid: lampilelo: you might wana talk about the geiser problem on #geiser, the author is jao, very nice and very responsive ... manumanumanu: rlb: I am not involved in any internal things, but I am playing a lot with data structures at the moment. I don't really see the need for expandable strings, at least not if it makes _every other operation_ more expensive. Representing strings as vectors of N-char bytevector chunks is probably a pretty nice compromise, though. If you allow for an offset you get shared substrings, decent random manumanumanu: access, and quick iteration with string cursors. as andy said: mutable strings in scheme is probably a bug in the spec :) manumanumanu: It is pretty compact as well: say you make each chunk 32 chars long, meaning each chunk is anywhere between 32 and (worst case) 128 bytes. One pointer per chunk. I don't know enough about the guile internals, but it sure is more compact than a vector of chars. dsmith-work: {appropriate time} Greetings, Guilers mwette: Guile != Scheme; see https://opensource.com/article/21/5/learn-lisp rlb: manumanumanu: right - it's certainly feasible. A plain utf-8 implementation has potentially better locality, and much better external compatibility (e.g. say we wanted to use libpcre). It might also have a performance advantage if there are cases where we can use more existing, heavily optimized code. But of course the persistent version you describe has other advantages (space in cases where the sharing works well, etc.). rlb: What got me thinking about it again lately, fwiw, was implementing clj's #"foo" regex support via libpcre. That's much more expensive right now because libpcre just doesn't support latin-1. But for that to be optimally efficient for guile extensions that only rely on the public api, we'd also have to support some way to use the internal utf-8 pointer (even if we never *promised* that it wouldn't be a copy). mwette: rlb, manumanumanu: you might be interested in vlists described in the manuall, as well as intsets and intmaps under (language cps) wingo: moo sneek: oom lampilelo: wingo: u broke geiser with this https://git.savannah.gnu.org/cgit/guile.git/commit/?id=03448b289d9804bb27b633b82e22cf7be55743c5 it seems wingo: how? :) leoprikler: probably because geiser doesn't understand read-syntax lampilelo: since read was switched to read-syntax in this commit, it feels like this is the only explanation wingo: but geiser doesn't call read-syntax wingo: does geiser call (language-reader (lookup-language 'scheme)) or something like that? lampilelo: doesn't call read either, i don't really know what's going on here dsmith-work: But that is where git-bisect landed? lampilelo: yes wingo: my guess is that geiser detects the current language and for some reason uses the current language's reader but also parses that read data for some reason wingo: which... the simple solution is that if the result of calling the current language's reader is a syntax object, to do syntax->datum on it. not so great for debugging info tho lampilelo: wingo: there's no lookup-language or language-reader anywhere in geiser's and geiser-guile's codebases wingo: i would think that geiser should rather do something more intelligent so as to preserve source locations for bare symbols, numbers, etc wingo: good luck debugging it, hope these pointers help :) daviid: it definitely parses the results, because, as an example, it would display guile-cv images (if proper setting to do so), not just return the result ... daviid: *geiser definitely parses the results ... lampilelo: geiser-guile has some magic around compilation & evaluation, lampilelo: problem is probably in here: lampilelo: https://gitlab.com/emacs-geiser/guile/-/blob/master/src/geiser/evaluation.scm lampilelo: i wish i knew more about the codebases, now i'm just passing the info around lampilelo: i told geiser's maintainer about the problem and put a ticket on their issue tracker lampilelo: so from what you're saying it's just solely geiser's problem wingo: well. i mean evidently something changed in guile from an interface pov. it's not the existence of read-syntax wingo: but rather that one part of the compiler calls it wingo: am a bit perplexed as to how that could break geiser's behavior wingo: if you could get a backtrace of the error that would be helpful :) dsmith-work: lampilelo: Is that broken with 3.0.6 or with master? (there have been several fixes in master since 3.0.6) lampilelo: i think i checked it with master too and it didn't work either, but i'm going to confirm lampilelo: wingo: and there's no backtrace because nothing really produces an error, it looks like geiser interprets what guile sent to it wrong lampilelo: returns garbage, but doesn't throw lampilelo: https://gitlab.com/emacs-geiser/guile/-/issues/9 wingo: hummmmmmmmmm wingo: you know, i bet i know what it is wingo: https://gitlab.com/emacs-geiser/guile/-/blob/master/src/geiser/emacs.scm#L35 wingo: there is some wizardry here to get the repl to read an expression in the current language and pass it as a datum to the repl command wingo: which, prolly it is not expecting a syntax object. humm lampilelo: i should've invited geiser's maintainer to #guile for this conversation dsmith-work: jao is/was usually here. dsmith-work: sneek: seen jao? sneek: jao?, pretty sure was seen in #guile 11 months ago, saying: i think geiser doesn't work with declarative modules. civodul was telling me the other day. aren't they a 3.x thing?. dsmith-work: sneek: botsnak dsmith-work: sneek: botsnack sneek: :) dsmith-work: Picky about them snacks civodul: Guix has a package cache: it's a .go file that evaluates to a big list, one item per package, where each item is a vector (with package name, version, etc.) civodul: generating this .go file has become CPU-intensive lately civodul: and it seems to be a case where we spend time doing bignum operations wingo: in slot allocation i guess? civodul: incidentally, Guix now has 17K packages, which i can't help but think is right above 16,384 :-) civodul: wingo: in truncate-bits civodul: called from the assembler wingo: funny :) civodul: https://web.fdn.fr/~lcourtes/pastebin/generate-package-cache-profile.html wingo: hilarious civodul: heh, we're pushing it to the limits! wingo: well. i mean it is perplexing in many ways wingo: but the easy solution is to just dispatch for 16, 32, and 64 bits, signed or unsigned wingo: to (<= 0 x #xffff) etc civodul: yes, that would avoid the expensive 'ash' and achieve the same i guess wingo: not sure if that's the expensive bit wingo: bc it's just ashing 1 by 16, 32, or 64, which is not enormous, but maybe that's enough wingo: like even the logand could be expensive, internally civodul: (1- (ash 1 64)) allocates a couple bignums civodul: yeah civodul: profile on 1.2.0, which had 15K packages: https://web.fdn.fr/~lcourtes/pastebin/generate-package-cache-profile-1.2.0.html civodul: veeerry different! civodul: fun civodul: x6 wingo: civodul: pushed a little patch wingo: so we should drop a 3.0.7 now, right? wingo: given the little bugs in 3.0.6 civodul: wingo: yes, sounds good! civodul: lemme see the patch civodul: wingo: ah clever, so it's all peval'd, right? wingo: yeah wingo: had to use define-syntax-rule to force inlining of the helper, but yeah civodul: cool civodul: i'll try to see how it performs wingo: yay civodul: i don't have a reduced test case so i'll disentangle the Guix bits wingo: so... what is our perspective on PROT_WRITE | PROT_EXEC wingo: we could be more rigorous in the JIT in that regard. would either waste memory or leave WRITE|EXEC half-filled pages wingo: or thrash about with mprotect wingo: on each jitted function civodul: wingo: verdict: 12s instead of 100s wall-clock \o/ civodul: thanks! wingo: what a hilarious fix civodul: yeah, those bignums can really hit harder than we might think wingo: i hate that :) civodul: yeah it's not intuitive! civodul: and we've learned & claimed that multiprecision is the one true way to do arithmetic without fear wingo: what if it's just our implementation? manumanumanu: This has been a funny discussion to follow. wingo: i mean would it change with mpn? civodul: it could be slightly less stressful for the GC wingo: in this concrete case i think specializing on the bit width makes sense fwiw civodul: yes civodul: regardless of the implementation, (1- (ash x 64)) is going to allocate civodul: and we're not wired to pay attention to that i think wingo: and there are only three afaics, we should have truncate-s16, truncate-u64, etc civodul: yeah civodul: with the compiler's help, we could make things like (1- (ash x 64)) allocate only one bignum and then operate in place maybe? *: wingo was wondering about jit protections as apparently apple silicon requires flipping page protections on each jit write civodul: ah yes civodul: so currently JIT pages remain writable? wingo: civodul: (1- (ash x 64)) is already optimized if the 64 is visible to the compiler fwiw. but yeah wingo: civodul: right now it's the wild west wingo: writable + executable, saddle up civodul: uh civodul: making them read-only sounds reasonable to me civodul: but i don't know what this entails in the code wingo: the issue is that the unit of jit compilation is typically smaller than the page size wingo: you wouldn't want a page per jitted function... wingo: anyway, somethign to think about civodul: oh, got it civodul: you could flip permissions each time you need to JIT, but it might be expensive apteryx: hello! Is there a way to specify 'zero or one' instead of 'zero or more' or 'one or more' when using (ice-9 match) ? apteryx: for a the last element in a list pattern leoprikler: apteryx (or () (x))? civodul: such patterns are not great because they lead to one code path where 'x' is bound and another where it's unbound leoprikler: right so you'd have (or (? null? x) (x)) leoprikler: or you could do it with two different patterns or use a submatch leoprikler: or call it (and (or () (x)) y), then y captures the match IIUC civodul: i'd use two different patterns apteryx: civodul: my gripe with the multiple pattern approach is that it leads to code duplication, no? apteryx: leoprikler: thanks for sharing leoprikler: you could factor that out into some lambda and then just call it twice civodul: apteryx: it depends, it could be that the two clauses have little in common or that there's another way to factorize common code apteryx: OK, I'll try something, thank you! lampilelo: lol there is a package with elisp bindings to zmq lampilelo: exactly 1 package on mepla uses it lampilelo: ah, wrong channel ;) lampilelo: hmmm... setting LD_LIBRARY_PATH from inside the scm file and then calling load-extension doesn't work for me with guile 3.0.6 lampilelo: it works when i set it from the shell before executing lampilelo: why wouldn't it work then? dustyweb: abralek: yay :) mwette: lampilelo: Lately I always use #!/bin/sh / set envs / exec guile $0 "$@" !# flatwhatson: Greetings, I've been digging into why test-out-of-memory fails on my system. flatwhatson: It seems like lazy creation of the finalizer thread is the culprit. Is there a way to block until the finalizer thread is started before continuing the test? flatwhatson: I guess the fact that we can't catch out-of-memory until that thread is running is a genuine bug? flatwhatson: Nope, red herring. The problem is mmap(PROT_NONE) failed in GC_unmap. flatwhatson: So... building with a libgc with --disable-munmap works, as does this patch: https://paste.gnome.org/pfwcjr60q flatwhatson: RFC on a patch for libgc which makes a failing GC_unmap non-fatal: https://paste.gnome.org/poz7ksfbv flatwhatson: This allows test-out-of-memory to pass, without crippling gc's unmapping in non-exhausted scenarios rlb: wingo: wondering (again) about whether it'd be worth the complexity to preserve mutable non-ascii strings in a utf-8 implementation, i.e. I think maybe the only time you could take advantage of it is when you know you're making changes that don't shift *any* character offsets, e.g. (string-set x 11 some-char-thats-the-same-length). Otherwise we just derive a new stringbuf. rlb: Currently inclining toward thinking it might not be worth the complexity. wingo: rlb: hard to say. actually i think maybe in a utf-8 world it can make sense to penalize string-set! in this way rlb: ...ascii strings are a different matter, i.e. might be a common enough case to be worth it, though I suppose it does create an algorithmic-complexity "cliff" that might be surprising if you don't know about it. wingo: mutable strings in scheme are a bug, of course :) rlb: heh, would certainly make my hacking easier if we didn't have all the flavors :) rlb: (atm I've kept the mutable flag, and have kept mutability in some cases where it was easy for ascii strings...) wingo: flatwhatson: why does the mmap(PROT_NONE) fail? wingo: rlb: yeah practically speaking we have to support mutable strings wingo: to not break user code, and to not break too much with the standards rlb: i.e. if you string-map!, it was an incoming ascii string, and the resulting char length is still equal to the byte length, we can just clobber the stringbuf contents... wingo: but if you were designing scheme now, you would not include mutable strings :) rlb: but to do that for a non-ascii string, we'd also have to check that the char sizes stayed the same, and that seems unlikely, and isn't free like it is for ascii. wingo: right rlb: (of course it *would* be less complex to just ignore the optimization for ascii too) flatwhatson: wingo: mmap fails with ENOMEM, which is frustrating as that call should actually *free* some space wingo: wow :) wingo: i can't think of a situation in which you would want that to be a fatal error fwiw *: rlb wonders if that might be one of the tests he's marked unreliable for the debian buildds, but will have to look later... flatwhatson: yeah I'm fairly sure that it is, though I'm not sure how long it's been failing and on what systems wingo: flatwhatson: what about seeing if upstream would take a patch that just does s/ABORT/WARN/ if that mmap(PROT_NONE) fails? flatwhatson: the problem is it flags that block as unmapped, and tries to remap it later which also aborts flatwhatson: hence my patch above which just leaves the block marked as mapped flatwhatson: replacing the mmap(PROT_NONE) with an munmap kinda worked, but would also fail later in GC_remap flatwhatson: anyway I guess it's pretty clearly an upstream problem, will gather my thoughts and hassle them instead :) wingo: flatwhatson: yeah sorry to not be more helpful :) libgc aborting guile is not a great situation! rlb: hmm, I suppose a better reason to consider never creating non-ascii mutable stringbufs is that by doing so, you avoid O(n) substring operations, while only giving up some unlikely optimizations... rlb: (O(n) when creating a substring of the mutable stringbuf) lampilelo: what's going on with geiser on guile 3.0.6? first it writes garbage to dbg buffer: lampilelo: While executing meta-command: lampilelo: Wrong type to apply: # lampilelo: scheme@(guile-user)> lampilelo: so i thought "let's update geiser" and now it shows it twice but prepending with additional "retort-syntax" lampilelo: when i write 'display to a buffer and use C-x C-e it evals it and then some, writing "Wrong number of arguments to #" lampilelo: can anyone confirm it's not just my issue? *: wingo is usually breaking his guile so is rarely able to test geiser lampilelo: i'm not sure if it broke after updating guile or my system packages lampilelo: maybe there was an abi break in one of them or something, i'll recompile to be sure lampilelo: yeah, it's still broken tohoyn: sneek: botsnack sneek: :) flatwhatson: huh, turns out that mprotect(PROT_NONE) works where mmap(PROT_NONE) fails! flatwhatson: there's already a code path used on CYGWIN32|AIX|HPUX|HAIKU... almost seems like it should really be the default lampilelo: wingo: did something related to repl change between versions? geiser works fine with 3.0.5 lampilelo: or more specifically to the repl server lloda: lampilelo: i've pushed your srfi-64 patch lampilelo: lloda: oh, thanks lampilelo: that's kinda unexpected since i didn't say anything, but very appreciated lampilelo: come to think of it, i did mention it but thought no one read it civodul: flatwhatson: those mmap(PROT_NONE) warnings are scary civodul: that's a libgc 8.x thing, and it's not clear when/why it happens flatwhatson: civodul: oh, I haven't seen those, I've just been chasing a failing test-out-of-memory, but possibly related? any more details? wingo: lampilelo: don't think so meo: if I have an array inside an immutable record, should I deep copy it and modify the copy and return it as a part of the derivative record? civodul: flatwhatson: not really; it's a thing we've seen occasionally in Guix, but it's not clear to me how to reproduce it civodul: it seemed to be a "new feature" of libgc 8.x lloda: there's zero source info when an error happens during autocompilation lloda: the workaround i have is to compile the file manually with compile-file taw10: meo: it depends on what you're doing. It's OK (in theory, at least) to have an immutable record which references mutable things, but it will probably be simpler to consider everything immutable and do what you said. meo: taw10: i'm trying, the result is I now have functions that modify values of individual fields and a function that does this for several fields and recurses over a list meo: i guess these are the wonders of functional programming meo: any reason not to use ice-9 poe? lampilelo: took me long enough but i confirmed geiser and guile 3.0.6 don't play well together, tested on a fresh ubuntu docker image abralek: dustyweb: In order to make 8sync work for me with fiber I had to CPed janneke's commits from master and also amend few of them. Those commits are for cross-compiling. Do you have any plans to merge the branch or something? dustyweb: abralek: hm I could probably do that dustyweb: abralek: but probably not today dustyweb: abralek: as in, it would be a good idea for me to do that ;) abralek: dustyweb: (<- dustyweb 'thanks) dustyweb: :) dustyweb: abralek: which janneke commits from master did you mean btw? abralek: 1dc3b6a * guix: Use guile-3.0. abralek: d06b7be * build: Support cross building. abralek: ac631e0 * build: Prepare for guile 3. abralek: He did more btw. wingo: lloda: is that a change relative to before? dsmith-work: UGT Greetings, Guilers dustyweb: abralek: where did you get the patches? abralek: dustyweb: ah, sorry, this is my amended fiber branch. abralek: d41139a * build: Support cross building. abralek: e94593c * build: Prepare for guile 3. dustyweb: abralek: maybe you could push the branch somewhere? abralek: dustyweb: https://gitlab.com/Levenson/8sync abralek: dustyweb: fibers branch lloda: wingo: the srfi-64 patch? lloda: it was applied upstream lloda: oh sorry lloda: you mean the lack of source info lloda: no I don't think there was ever source info for those errors lloda: afair manumanumanu: rlb, wingo : regarding strings: I have thought about something like a persistent vector for strings. Each leaf stores a bytevector of N characters, whereas the rest can use 32-way branching. That could give O(1)-ish string-set, pretty fast iteration, yet OK string-ref - while still being pretty compact. manumanumanu: with moderately efficient prepend, and o(1) append with transients. Together with the SRFI for string cursors it might actually not be completely awful as a string representation. manumanumanu: but maybe I'm just overthinking it... manumanumanu: the downside is that you get not all of the benefits of ropes, but with only some of the downsides. manumanumanu: but alas, it is overkill unless you want adjustable length. dustyweb: abralek: ty rlb: manumanumanu: ahh, right, I thought about some of that too, though I'd thought we were leaning in favor of wanting the internal representation to be utf-8. If not, then sure, could definitely do even fancier things. rlb: (...and I should stop poking at my current mess :) ) rlb: daviid: here's what I did, fwiw: https://git.sr.ht/~rlb/lokke/commit/e2039544af0e7988fead08a31a621b9447317ecb See in particular the changes to compat.scm. rlb: (commit message also has some rationale) daviid: rlb: wil look at it asap, tx daviid: i have another quiz, for autotools 'familiar' - g-golf (as an example) may be used with guile-2.0 >= 2.0.14, 2.2 (any version) and 3.0 >= 3.0.7 (which is the first version that will have the patch related to the module-use! 'target' functionality ...) so, till now i had GUILE_PKG([2.2 2.0]), GUILE_PROGS([2.0.14]) - how can we easily acheive this? dsmith: sneek: botsnack sneek: :) dsmith: !uptime sneek: up 5 minutes daviid: abralek: i see nobody answered your question, and i am not 8sync knowledgeable either, but fwiw, its author is dustyweb - who appeared a bit later to your post, maybe you may ping each other ... :) daviid: dsmith: it just occured to me that our bot commands such as !uptime ... use the same naming convention than g-golf accessors :) - probably the other way around though, g-golf accessors use the same naming convention as bots commands ... i see other bots do that to, in #git they have !situation, !paste ... :) is there some 'history/story' behind this notation, among bot writers ...? srandon111: anybody on a BSD here? daviid: wingo: I've answered my own quiz, in bug#47084, related to how to suppress warnings ... i think this bug may be closed now, all fixed, many thanks again abralek: daviid: I see, many thanks for letting me know. I sent an email to @guile-user yesterday, maybe I could ping him daviid: abralek: welcome! dsmith: daviid: Yes, I belive so. The old bot in #debian (dpkg ?) used ~ IIRC. dsmith: Probably just really easy and cheap to only listen to lines with the magic char as prefix. dsmith: The '!' is from bobot. The '{nick}' is from sarahbot. dsmith: srandon111: Almost. Just installed the recent fbsd 13 in vbox, with a mind to try Guile on it, but had other problems so I rm'ed it. dsmith: srandon111: RhodiumToad is a bsd user IIRC wingo: i keep reading "bsd" as "bad" wingo: should get my eyes checked *: davexunit did the same *: RhodiumToad is indeed a freebsd user dsmith-work: wingo: bsd is good! dsmith-work: Back when I was doing consulting, had a thinkpad with flakey hard drive. Would overheat and get read/write errors. dsmith-work: And Windows, Linux, and Fbsd installed. Was a real eye opener how they handled the drive errors. dsmith-work: Windows jus locked up. dsmith-work: Linux was hitting the HD often, and I could not run new procs, but I *could* run things already resident, like staring another Xterm. dsmith-work: FreeBSD didn't blink and eye. When I went to shutdown, it mentioned there were some block it was having a hard time with. dsmith-work: After a while, it apologized that it could *not* write those blocks, and shutdown. veltas: That is very interesting, I have intermittant issues with my hard drive's sata connection and I've seen what you saw on Windows and Linux veltas: But FreeBSD seems to handle that much better than either dsmith-work: Now, this was about 17 years ago. Things have probably changed. veltas: Yes possible they've factored that out, FreeBSD development philosophy and all veltas: Linux handles this gracefully enough, it's Windows that really drops the ball dsmith-work: But was also very impressed with the driver documentation. And how drivers/docs/userland are always in sync. dsmith-work: But I'm just too set in my ways to leave Debian package management. dsmith-work: My new car (haven't had my own car for about 5 years now) https://drive.google.com/file/d/1XrgnBSwAi_VST2h_GWvHStrVxfyY8SnG/view?usp=sharing RhodiumToad: see the "fsyncgate" stuff from a year or two back RhodiumToad: (short version: linux will forget that write errors happened) soda__hobart: holy crap... are there any tricks for catching when you've unintendedly put a variable inside some parens? RhodiumToad: (var) rather than var ? soda__hobart: yup RhodiumToad: obviously if the value of var is a thunk, (var) would be a normal thing to do soda__hobart: it took sooooo long to find it too RhodiumToad: and if it's not a thunk or some applicable object, then (var) would be an error, yes? soda__hobart: yes, "wrong type to apply" error soda__hobart: i need an erroneous pseudo-thunk highlighter i think, haha vbramselaar: Hi there is it possible to supress the auto-compile notes when running "guile -s"? vbramselaar: Im running guile 2.2 btw abralek: dustyweb: Thanks for the respond to my 8sync select issue. the fiber branch works flawlessly =) daviid: wingo: my appologies, commit 19f38a3 fully fixes bug#47084 - i mistakenly thought it didn't, because in my wip-3.0 branch, I forgot to revert my own temporary patch for the re-export-public-interface macro - and the good news is ... G-Golf now works with 3.0! daviid: wingo: this said, it triggers 'new' warnings - like WARNING: (guile-user): imported module (g-golf) overrides core binding `map', for-each' and `connect', i am not sure how to best deal with this problem - hints welcome daviid: so, wrt these 'new warnings' - no such warnings when using guile 2.2 - related to module-use! (you need guile >= 3.0.6.1-19f38a to try) that replace core binding(s), I don't see any possibility to 'prevent' them, and the only way to silent those is to call default-duplicate-binding-handler and remove warn-override-core and warn from the list daviid: here is an example, will paste in a min daviid: https://paste.debian.net/1196087/ wingo: daviid: glad things are working for you :) regarding the warnings, see "Add #:re-export-and-replace argument to `define-module'" in NEWS meo: any reason why I shouldn't override a constructor generated by sfri-9 define-record-type? meo: i have a record of foo bar baz cat, but baz and cat during initialization depend entirely on foo and bar rekado: meo: you can override them. What I normally do, though, is to leave the plain constructor be, don’t export it, and export a ‘smart’ constructor that wraps the plain constructor. *: wingo does the same meo: makes sense meo: is it the convention that record accessor names must mention full record type name? leoprikler: Indeed, that is the convention. leoprikler: but if you have a different convention there is nothing keeping you from using that instead meo: and how does one generally deal with deeply nested structures? my guess would be macros? rekado: for nested structures you may find guile-lens to be of interest rekado: https://gitlab.com/a-sassmannshausen/guile-lens meo: thanks! abralek: Hi, I am trying to test an actor I wrote with 8sync. I created another probe actor to send messages to the main one. A problem I am having is that when I want send a *cleanup* to the main actor (server) from the probe, I am getting a backtrace from 8sync/agenda.scm with (select (#) () () #f #f) abralek: Here is a snippet I wrote https://paste.debian.net/1196108/ abralek: And here the backtrace https://paste.debian.net/1196109/ abralek: Am I doing something wrong here or it's a bug? I kinda see that we not suppose to give closed files to select. abralek: How I could or should properly initiate a graceful shutdown? lampilelo: since streams can be infinite why do they cache all computed values? wouldn't it fill the memory eventually? lampilelo: in the spec there's only one period between words "infinite" and "cached" lampilelo: am i doing doing it wrong if i run into corner cases every time i try something new? leoprikler: lampilelo streams can still be infinite if you discard (and gc) the heads lampilelo: right, what a brainfart davexunit: it would be cool to see a stream implementation that kept the api the same but did some magic under the hood to avoid boxing every single value. too much overhead and garbage. leoprikler: don't you have that boxing as a part of delay/force though? leoprikler: or "pseudo-delay"/"pseudo-force" davexunit: yeah I dunno how to do it but as-is streams are mostly a fun toy that can't be used for anything that needs to perform well davexunit: I bet if you compared them to generators in other languages they wouldn't stack up too well dsmith-work: {appropriate time} Greetings, Guilers dustyweb: hi dustyweb: did (compile ...) disappear from the standard environment? dustyweb: where do I access it from these days? dustyweb: (compile '(+ 1 2) #:from 'scheme #:to 'tree-il) dustyweb: not workin' dustyweb: in 3.0.5 dustyweb: hm, found it through a source grep dustyweb: (use-modules (system base compile)) leoprikler: davexunit: come to think about it, how do they perform compared to generators in Guile? :P lampilelo: test-out-of-memory fails for me on guile 3.0.6, what's up with that? davexunit: dustyweb: try importing (system base compile) ? daviid: wingo: ok, thanks, I was aware of #:re-export-and-replace, but didn't think i had to use it in a module that calls module-use! (my mistake) ... but if i do that in foo, that module-use! (srfi srfi-1) - as an example - and say re==export-and-replace for-each, then a module or a file bar.scm that import foo and calls for-each 'stops' triggering the warning indeed daviid: wingo: the question is how to keep these modules def so users may either use 2.0, 2.2 or 3.0 ... dustyweb: davexunit: yeah, for whatever reason I thought it was in the default environment dustyweb: seems I was wrong ;P davexunit: dustyweb: it may have been. never used it. civodul: lampilelo: hi! test-out-of-memory fails in a non-deterministic fashion it seems civodul: we skip it in Guix for that reason lampilelo: civodul: yeah, it complained it can't finalize a thread or something because it has no memory so i disabled it too to check the rest lampilelo: i guess it's tricky to test memory limits because there's no memory for the test to recover civodul: lampilelo: yes, exactly civodul: well i didn't investigate much, but i suppose that's what happens lampilelo: thanks for confirming i'm not the only one having this issue civodul: wingo: you'll love that one: https://sourceware.org/pipermail/gdb-patches/2021-May/178438.html :-) civodul: wingo: and this one too https://issues.guix.gnu.org/48114#4 (unrelated) civodul: libunistring being too smart dsmith-work: Hey. Where'd the bot go. dsmith-work: Can anyone give me a time when the bot left? dsmith-work: (I don't have join/leave in my scrollback) pkill9: what's the name of the bot? lampilelo: sneek dsmith-work: Ah, sorry. Have a habit of saying "the bot" instead of the "sneek". So the bot doesn't mistake my command for a command. dsmith-work: s/instead of the/instead of the nick/ mrf: hi, can anyone give example on using vector-move-right! I cannot get it to work mrf: I do that and my function fail: mrf: (let ((v1 #(9 8 7 6)) mrf: (v2 #(10 20 30))) mrf: (vector-move-right! v2 0 2 v1 1) mrf: v1 mrf: ) nly: So, i wanna know how you setup a nginx front to a guile server. It's to serve static files. mrf: what wait, you setup web server with scripting language to serve static files? I don't know specifically how to do that but genreally you forward some proxy port of your guile server to nginx which will convert it to some part of your domain in 80 port or something lampilelo: mrf: in this example you're creating immutable vectors and then try to mutate one of them, what you need to do is create a vector not with #(1 2 3) syntax but with (vector 1 2 3) mrf: thinks lampilelo nly: nginx -> static files nly: guile -> the good stuff nly: my communications skills -> sucks :) meo: is it okay to override srfi-9 record constructors? meo: well it certainly does work ArneBab: wisp 1.0.5 released: the language implementation is now explicitly licensed under the expat license (lax license) to make it secure to embed wisp in guile-using games like those made with tsukundere by leoprikler: https://www.draketo.de/software/wisp#orga9852c8 ArneBab: s/secure/safe/ leoprikler: s/safe/legal outside of the GPL :P/ ArneBab: safe as in „you do not have to think about it“ leoprikler: fair enough leoprikler: I think we might want to update guile-wisp with that in mind, but I'll eat now. ArneBab: as long as they do not remove the copyright header from the wisp.scm and spec.scm file, they are safe. (point in case: a German startup recently got flak because they did that) ArneBab: Since they use Guile already, this still favors free licensing, but it removes a stumbling step. I conside that as a strategic step, because there are already many proprietary game engines in use. Replacing them by games that use Guile spreads free licensing. ArneBab: The only risk could be that someone ports wisp to an unfree Scheme implementation, or ports wisp and makes the port proprietary, but having even a single additional game written in wisp using Guile is worth that risk, I think. ArneBab: leoprikler: enjoy lunch :-) daviid: i thought wisp was using the same license as as guile lgpl - daviid: ArneBab: fwiw, i would not take such a risk ArneBab: daviid: the original wisp language implementation is the implementation for a SRFI, so it had to be expat-licensed. The changes since then are pretty small. The surrounding files are GPLv3+ (most of my work over the past years was on examples) ArneBab: daviid: but I well understand not taking that risk, I was also conflicted. ArneBab: daviid: in the ideal case for me, wisp would be included in Guile as a regular supported language, then it would be LGPL and there would be no issue for games that use Guile. Currently games must either add a second dependency or embed wisp. ArneBab: daviid: my previous attempts to get wisp included as supported language in Guile sadly failed, making the embedding of wisp as painless as possible is the second best option. ArneBab: s/is// daviid: yeah, i would not have made it srfi in the first place srfi 'forced' license is a problem, not a solution ... but ... leoprikler: daviid: When we compete against ren'py, I think that fear is probably not warranted. nly: (use-modules (json)) nly: ,apropos json nly: nothing nly: scm->json ;; procedurce stis: Hello guilers! sneek: stis, you have 1 message! sneek: stis, wingo says: tx for report, fixed :) stis: wingo: Great, this enables quite a speedup in python on guile! wingo: if you use prompts for non-local control flow like "break" etc there are quite a number of other optimizations that could be made wingo: like if you can identify an abort for a prompt and it's within the same function, we could wire the abort to the handler wingo: and if that's the case for all aborts for a prompt, the prompt can be elided wingo: etc wingo: haven't implemented those passes yet tho wingo: if we had that and a proper SSA/CPS conversion pass for mutable memory, then we would have a good compiler for more kinds of languages :) leoprikler: C++ in Scheme? wingo: well, anything with that flavor: js, python, c, etc stis: wingo: that would be great. I know that with current prompts we get the same speed in math loops as python and significantly faster without let/ec stis: so we know that those opptimisatoins make a difference for python on guile. Also manumanumanu and I have a tagbody implementation and thiese should be significantly faster with the right optimisatoin pass of the compiler stis: The final step towards getting native scheme speed would be to enable good optimisatoin of boxed variables in some way (python is littered with set! semantics) mwette: imperitive languages are going to hammer on escapes and set! a lot; in nyacc I have a generic module for language translation that is littered with "(primcall make-prompt-tag (const ,tag) ... (prompt #t ,tag ,body ,hdlr) manumanumanu: Well, stis says I have a tagbody implementation, but what he really means is I have a bit of steaming hot mess I wrote when I was still a puppy. I tried it back when we talked about it and it fails on nested tagbodies. avp_: Guile-INI 0.1.0 is out: https://lists.gnu.org/archive/html/guile-user/2021-05/msg00012.html wklew: does anyone know if there's a fix for cond-expand not expanding correctly inside define-library? wklew: https://www.mail-archive.com/bug-guile@gnu.org/msg10146.html wklew: I meant to ask if there's plans to release a fix, a patch was posted in the thread but I haven't tried rebuilding guile wklew: with it applied leoprikler: linas: I'm sure cogserver has a purpose, I just wanted to point you to something else so that you don't need to rely on it "just to have a REPL server". rekado: linas: I don’t understand the “telnet” comment. You don’t need to use telnet to talk to a REPL server. rekado: if you have a test case to demonstrate “crashy” we would be very interested in reproducing the problem. lampilelo: how to get a terminal width in guile when COLUMNS env var is not set? manumanumanu: zzappie: regarding your question: you are trying to display the syntax transformer from the match macro? zzappie: manumanumanu: hello! No actually It was a WAT moment when I was working with g-expressions and guix's shepherd services. Service I wrote was crashing. So I tried to find out whats going on there and noticed some spooky action zzappie: match was a syntax transformer zzappie: I could understand how it would possibly happen zzappie: *coudn't zzappie: same thing wihth response-code from (web response) module zzappie: I could't look code coumpiled by gexps (if its the right wording) because in this particular case I had to deal with .go files zzappie: I posted It here and not in #guix cause I though someone could have a clue ho such thing could happen in guile or maybe already had such experience zzappie: I eventually solved the problem by removing with-imported-modules form and using shepherd-service record's "modules" field. zzappie: but what happend remais a mystery to me zzappie: In short: no, I wanted to understand how (pk match) would possibly output (<#syntax transformer>) rather than throwing syntax error :) RhodiumToad: why would it be a syntax error? zzappie: RhodiumToad: I don't know the answer. But it was my experience with any macro zzappie: try running: guile -c "(begin (use-modules (ice-9 match)) (pk match))" RhodiumToad: yeah *: zzappie thought: shouldt here be a guile bot that evaluates expressions? zzappie: sneek: eval (+ 2 2) pls leoprikler: zzappie: (module-ref (resolve-module '(ice-9 match)) 'match), you're welcome zzappie: leoprikler: ((module-ref (resolve-module '(ice-9 match)) 'match) ...) is not the same as (match ...) right? leoprikler: there's probably a subtle difference zzappie: in case of ((module-ref (resolve-module '(ice-9 match)) 'match) (() 'nill) (_ 'rest)) it will try to evaluate subforms (is this the right word?) and yell at me because of () *: zzappie meant ((module-ref (resolve-module '(ice-9 match)) 'match) '() (() 'nil) (_ 'rest)) leoprikler: yeah, I thought so, because module-ref doesn't actually bind it as syntax zzappie: I guess it's a bug then RhodiumToad: module-ref is giving you the value bound to the symbol RhodiumToad: (which for a macro is a syntax transformer object) zzappie: I for some time thought that syntax if first class in scheme RhodiumToad: which is not the same thing as actually importing the macro into the current scope RhodiumToad: consider that macros have to be known at compile time zzappie: RhodiumToad: yeah: I meant its not guile bug, but guix bug manumanumanu: zzappie: match _is_ a syntax transformer. When used normally you sholdn't see it, but when you are doing macrobatics you can get that kind of thing. manumanumanu: guix g-expressions is probably level 5 macrobatics. manumanumanu: I don't know. I only go up to level 4, and only when intoxicated. zzappie: manumanumanu: haha manumanumanu: zzappie: did you ever see "peak syntax rules" by tailor Campbell? It is the syntactic parameters used by his foof loop implementation. The loop facility is rather WTF, but the syn params part is insane... manumanumanu: Taylor? manumanumanu: yes. Taylor R. Campbell. Amazing stuff. manumanumanu: zzappie: http://mumble.net/~campbell/tmp/foof-loop.scm zzappie: manumanumanu: wow.. I think Im not ready for that just yet :) But I'm adding it to my scheme stuff list avp_: Hello Guilers. Guile-SMC (Guile State Machine Compiler) version 0.1.0 is out: https://lists.gnu.org/archive/html/guile-user/2021-05/msg00000.html wingo: neat! avp_: I think one could implement C code generation from the Guile-SMC internal transition table in the future using this: https://github.com/zenhack/c-ast rlb: Say I need a data structure available during expansion/compilation that is consulted by, and adjusted by the compilation process, and I also need some of the info that was collected to be available at runtime. Is there a typical way to handle that? rlb: I think I know some ways to handle it, but didn't know if there was a common/preferable approach. leoprikler: rlb: syntax-case, just make sure you write whatever data you need into the runtime code leoprikler: it's probably a good idea to filter it mwette: nyacc has a routine `pretty-print-c99' that takes C AST in SXML and generates C code. It is fairly mature. And you can use parse-c99 to generate SXML ASTs from C code. rlb: The issue is that I need to accumulate info over multiple macro calls (calls which consult the accumulating info), and then have some of that info also be available at runtime. One approach perhaps, is to manipulate/consult the "global" data structure from the syntax expanders, and then also have the expansions include code to populate the relevant structure at runtime. avp_: Oh my. Thanks, mwette! rgherdt: hi all! Could some Guile maintainer please take a look at following bug (with solution) and possibly apply the changes? It would make R7RS's define-library work rgherdt: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40252 avp_: Currently I'm more interested in producing FSMs for Scheme world though, but in the future nyacc may come in handy. mwette: I hack on FSMs also, and keep it in Scheme, for the win. Have fun! nckx: Hullo #guilees! Minor quibble: the reversed line numbers add unnecessary surprise: https://paste.debian.net/plainh/0199a8db nckx: But it's such a Schemey thing that it made me laugh so kudos for that. daviid: rlb: what about (eval-when (expand load eval) ...)? civodul: nckx: i think i got used to it! "reverse packtrace notation" it's called rlb: daviid: right, I assume I'll be using eval-when variants as part of the process. *: civodul notes that nckx has a bunch of non-literal format strings at hand nckx: civodul: Don't we all? They're (info (G_ "~x")) calls. civodul: nckx: yes, we all do :-) civodul: i'm used to seeing that warning and it's perfectly legitimate in this case nckx: Sure. civodul: we'd need a way to annotate the thing so the compiler looks at the string inside civodul: or we could express it slightly differently nckx: That's what I was (extremely idly) poking around at when I got distracted by the reverse packtrace notation. 😉 civodul: no big deal though civodul: heh :-) nckx: I gather there's no existing annotation system? nckx: Then I see why everyone just gets used to the warnings. civodul: yeah mwette: What is bad about having non-literal format strings? I get that for C, but for Scheme type values are known at run-time. mwette: s/type values/value types/ wingo: mwette: often is a bug, consider (lambda (x) (format "~a" x)) wingo: also prevents checking that arguments conform to format string (-Wformat) civodul: in C it can be tragic; in Scheme it's a bad-looking run-time error mwette: I'd assume when format string is processed for say ~d you can check arg via (integer? arg). wingo: rgherdt: applied, tx for poke! sneek: Welcome back wingo, you have 1 message! sneek: wingo, civodul says: thanks for the super fast bug fixes! wingo: sneek: late tell stis tx for report, fixed :) sneek: stis, wingo says: tx for report, fixed :) wingo: ah you are here :) wingo: daviid: also fixed the (lambda ( . args) ...) thing, was a bug in the new read-syntax wingo: sneek: late tell stis tx for report, fixed :) rgherdt: wingo: awesome, many thanks sneek: stis, wingo says: tx for report, fixed :) wingo: weird, stis is not actually here afaics? wingo: odd behavior wingo: sneek: later tell stis tx for report, fixed :) sneek: Got it. wingo: ah just a typo on my side then RhodiumToad: wingo: did you get the mini-gmp thing? wingo: ah no not yet, tx for reminder *: wingo looks RhodiumToad: https://dpaste.org/kvZP RhodiumToad: without that it fails to compile if HAVE_CONFIG_H is defined wingo: RhodiumToad: i just tried the tarball and it just works here if i --enable-mini-gmp wingo: what could be the difference in our systems? RhodiumToad: HAVE_CONFIG_H wingo: you explicitly define HAVE_CONFIG_H in your cflags? RhodiumToad: no RhodiumToad: I'm on freebsd, presumably configure is setting it *: civodul built it with --enable-mini-gmp in Guix too civodul: wingo: i got around to fixing the -Wunbound-variable issue at https://issues.guix.gnu.org/47031 RhodiumToad: another possible difference is whether it's using the lib/unistd.h rather than the system one daviid: wingo: hello. did you read the feeback i posted here, wrt the fix for #47084, with a debian paste (that expired now ... i can posted again, answer #47084, or opening a 'new' bug report ... that was the feedback and following quiz ... wingo: daviid: sorry all i got out of it was the (lambda ( . args) ...) issue wingo: if there is another problem please let me know RhodiumToad: the error is #error "Please include config.h first." civodul: RhodiumToad: the change you pasted above makes sense to me civodul: otherwise there could be mismatches wingo: RhodiumToad: yeah i don't doubt that such a clause might be needed but i didn't know why it worked here civodul: like you include Gnulib's , but it thinks is needed RhodiumToad: every other file has that conditional block in it, it's just missing from mini-gmp wingo: ok great will add that then civodul: could be that on GNU/Linux we don't use much of Gnulib's header, so it doesn't make any difference RhodiumToad: does the lib/ stuff even get used on linux? civodul: some of it, but not much i guess wingo: RhodiumToad: fixed wingo: civodul: great! (re -Wunbound-variable issue) RhodiumToad: LGTM daviid: wingo: yes there is another problem: the fix fixes the example, the mdule (a) that is in #47084 - however, it doesn't fix dynamic expected functionality of module-use! - that is if the public interface of a module that has been module-used! evolve 'in time', those who module-use! don't see the new bindings, unlike 2.2 - let me paste again, in a few min, i need to reconstruct the paste (which expired) *: wingo zzz daviid: ok, good night daviid: wingo: if you catch this before to go to bed, so you dream about a solution :):) - https://paste.debian.net/1195962/ - this feeback depends on g-golf, but i'll build an example/snipset that doesn't and answer in #47084 - good night again daviid: i pulled the fixes, so now the error tells me where/what, i see the following raises the exception - (define (foo bar) (lambda ( . args) ... )) -> invalid argument list in subform args of args davexunit: I sort of have a basic tree shaker working. something is wrong, though. seems like there may be some things that are needed that don't show up when walking the module tree. davexunit: "Unbound variable: read-syntax" uh oh davexunit: the big issue though is "class not found " when loading goops. davexunit: not really sure how this magic happens. davexunit: the good news is that this approach seems promising. the resulting bundle is 41MB smaller than my original that includes everything. davexunit: a-ha, goops.c iterates over each smob and makes a class. the SCM_SMOBNAME macro fetches the name, so there's no explicit reference to dynamic-object here. davexunit: I'm curious what my bundle is missing that there is no dynamic object smob type flatwhatson: ./module/oop/goops.scm-3315-;; used to be a SMOB type, albeit not exported even to flatwhatson: ./module/oop/goops.scm-3316-;; C. However now it's a record type, though still private. Cross our flatwhatson: ./module/oop/goops.scm-3317-;; fingers that nobody is using it in anger! flatwhatson: ./module/oop/goops.scm:3318:(define flatwhatson: You must be shaking that tree a little too angrily? davexunit: I think I know the issue. davexunit: I think I've mixed things up between two different builds of guile that I have. davexunit: and that recent change around how the class is created is causing problems. davexunit: got it working. :) davexunit: a few quirks, but pretty cool. davexunit: bundle size reduced by 39MB. davexunit: tarball download size reduced by 8MB davexunit: I'm happy. jackhill: Pattern mathcing question: Using this match '(match '(quote ("a" "b" "c")) ((quote (a _ c) ...) (list a c)))' results in (("a") ("c")). jackhill: Instead, I would like the rusult ("a" "c"). What do I need to change? I feel like I'm missing something about how quoting or pattern matching work (or both!) jackhill: Aha! I get it: (match '(quote ("a" "b" "c") (d e f)) ((quote (a _ c) _ ...) (list a c))) is what I want jackhill: I think :) daviid: this is not allowed in 3.0.6 anymore - (define (foo bar) (lambda ( . args) (apply + args))) - just a tiny example to illustrate a similar, though 'real' and quite more complex 'need' in g-golf ... daviid: wingo: ^^ daviid: ah, i need to change the call for (define (foo bar) (lambda args (apply + args))), sorry for the noise ... daviid: wingo: quick feedback - commit 19f38a3 fixes the example given in #47084, as you probably did try, but here is a mini session https://paste.debian.net/1195743/ daviid: wingo: however, it does not solve the 'Fwiw: (a)', that is, the public interface of a module that has been 'module-used', in 3.0.6 (unlike 2.2) may not evolve in time (at the 'essence' of any GI dynamic binding) daviid: here is a concrete example daviid: wingo: here https://paste.debian.net/1195745/ daviid: this is to give you a quick feedback, it needs g-golf, but i will produce an example that does not depend on g-golf ... shall i answer #47084, or do you prefer to close it and reopen a more specific bug report for this ... lmk flatwhatson: Is this a sensible thing to do: flatwhatson: (define* (bytevector-slice bv start #:optional (count (- (bytevector-length bv) start))) flatwhatson: "Return a bytevector referencing COUNT bytes of BV from index START." flatwhatson: (pointer->bytevector (bytevector->pointer bv) count start)) flatwhatson: To avoid unnecessary copying of subsets of bytevectors? flatwhatson: Will the gc get confused if this is my only live reference to that buffer? manumanumanu: stis: hej! manumanumanu: flatwhatson: good question. You could probably try it in a repl... stis: manumanumanu: tjena! manumanumanu: flatwhatson: so, I created a bytevector, went through the pointer->bytevector dance, made sure the original bytevector wasn't reachable. generated a lot of garbage, ran the GC a couple of times. No use after free, at least :) manumanumanu: Whether it is more efficient than a copy is another matter. manumanumanu: stis: are there any problems with python-on-guile for 3.0.5? manumanumanu: I am getting weird errors with the guix packages stis: I think so, i'm on bleeding edge guile and needed to modify python on guile stis: manumanumanu: : ^^ manumanumanu: ah, ok. manumanumanu: Even so, I am getting some things running stis: ok cool manumanumanu: I am looking forward to seeing if I can help with the for macros! How would you go about getting the scheme output of a file? manumanumanu: compiling a .py -> .scm stis: ther is a python script ... stis: python file.py stis: should copile and run file.py stis: then there is an output file in log.txt stis: where you can find output code and for example clip int into a guile sesion and expand the macros stis: then you can try spot errors manumanumanu: great! manumanumanu: haha, the guix package shadows my python installation manumanumanu: nothing died yet! stis: yea we should so something about that stis: I use python for python on guile and python3 for Cpython3 manumanumanu: Just to non-humble-brag: I feel like a king! I have managed to morph something spiritually based on andy's fectors into something that just passed the first RRB-tree test! I can now drop elements in amortizied O(1) instead of O(n) like regular fectors. Next up is O(logN) concatenation and insertion :D manumanumanu: not only that, as long as you have done no splits or concatenations, these extra features have no cost stis: lovely allana: Hi Guile. I'm quite new to scheme and I am trying to learn some things here and there. I have a question, is this idiomatic scheme? https://paste.debian.net/1195759/ stis: allana: as a guile scheme itis ok I think! stis: be careful with define though stis: (define n (f n)) is not the same as (let ((n (f n))) ...) i think stis: that's bitten me a couple of times stis: in this case do not reuse n or use let allana: stis: thanks taw10: Might be able to make it a bit more succinct sing call-with-port? manumanumanu: allana: I would probably have use let* instead of (let (...) (define ...)) in that case. And the variable _ is generally not something I would use like that. I is mostly used as a marker for "ignore this" in macros and such taw10: using* manumanumanu: isn't call-with-port very new? How bout (with-input-from-file ...)? allana: manumanumanu: Thanks, this looks like what I would have liked to use. Coming from Python with-input-from-file sounds very familiar. allana: I'm mostly just poking around here and there in my free time. Thanks everyone! manumanumanu: allana: the ports system is something that takes some getting used to. (with-input-from-file path body ...) will bind (current-input-port) to the port pointing to the file at path. Any reading operation within "the dynamic extent" (meaning any code running in the body) that doesn't bother with changing (current-input-port) will read from the file manumanumanu: even functions called by functions called by the body in totally unrelated places. It just means "bind standard input to this file port for all the code in this code block". manumanumanu: allana: it is always nice to see people curious with scheme! allana: It's guix. I am bothered by the fact that I don't understand scheme well enough to fully customize my own machine. So now I am trying to learn guile/scheme and potentially start using it at work when it makes sense. leoprikler: allana: the python "with open()" statement is actually implemented as call-with-{input,output}-file allana: leoprikler: cool jlicht: I finally received my copy of "Software Design for Flexibility", anybody working through it in guile? davexunit: I got a working tree shaker prototype. in addition to including all of the modules in use, I had to also include a bunch of ice-9 source files that aren't modules that I wasn't expecting. davexunit: eval.scm, i18n.scm, posix.scm, psyntax-pp.scm, quasisyntax.scm, match.upstream.scm, networking.scm, r6rs-libraries.scm, and r7rs-libraries.scm davexunit: I guess there are still things I don't understand about how guile does things. civodul: davexunit: neat! that could be interesting for Guix too, for instance for the initrd davexunit: for instance, ice-9/match.scm is basically a shim and calls (include-from-path "ice-9/match.upstream.scm") civodul: (did you know? if you use Guix System, your initrd includes an elisp and an ecmascript frontend) davexunit: there is no associated .go file for this source file. davexunit: civodul: lol I have thought about this before civodul: ah yes, these can be hard to deal with davexunit: I wouldn't have expected the compiled module to need this source file davexunit: does the compiled file included the compiled version of match.upstream.scm? davexunit: I can't imagine we are evaling the pattern matcher every time we load it civodul: i don't know, it's weird that this file's needed civodul: i think we should be able to have configurations without source files, too davexunit: like binary only distribution? yes I agree civodul: yes, at least for cases where disk space matters (initrd, game jam, etc.) civodul: for match and other expansion-time modules, i'd also love to have R6-style phases davexunit: it's not a significant contributor to disk space in my case (3.9MB currently of 78MB) but it would be nice to slim down as much as possible. civodul: yeah davexunit: the compiled modules take up 37MB currently davexunit: but ditching the source would be nice davexunit: a more robust tree shaker would have to do static analysis to identify include-from-path calls, as well as @ and @@ usage. civodul: yeah davexunit: I got bit by an @ usage somewhere. it was in one of my own projects so I just changed the code to not use it. civodul: you can have a convention to not use it davexunit: buuuut if we had binary-only distribution we wouldn't need static analysis davexunit: for my own purposes I'm inclined to just live with these caveats. civodul: you still need to determine which .go files are needed? davexunit: civodul: yes, that *mostly* corresponds to which modules are loaded. except for ice-9, of course. ;) civodul: BTW, Guix has source-module-closure, which maybe is kinda similar to what you're doing? civodul: heh davexunit: I should check it out and compare davexunit: but here's another oddity with ice-9 that I don't yet understand. davexunit: there's posix.scm and posix.go, eval.scm and eval.go, but there's quasisyntax.scm but no quasisyntax.go davexunit: I had originally assumed that every .scm would have a corresponding .go but quasisyntax broke that assumption davexunit: I'm sure there's a reason but guile is a bit mysterious to me in its early boot state davexunit: but it's not a big deal to say "ice-9 is special" and add special accomodations for it since it's core stuff that everything needs. RhodiumToad: davexunit: some of the .scm files may be included into others rather than being a module unto themselves RhodiumToad: I noticed that with read.scm (which is just included into boot-9) davexunit: RhodiumToad: yes, that is what is happening. davexunit: I was just surprised that they were still needed when loading compiled modules davexunit: oops, somehow didn't notice that there was a libguile-3.0.a file hanging around. don't need that! that freed up 16MB right there. RhodiumToad: I guess that if x.scm includes y.scm, then checking whether x.go is current should check both .scm file dates RhodiumToad: (whether it does check or not I don't know) davexunit: yeah something like that. not sure the exact process. davexunit: my binary bundle is now 17MB compressed and 60MB uncompressed. big reduction from my initial version which was 29MB compressed and 120MB uncompressed. davexunit: need to stop now but this is promising. the tricky part is now turning this into a tool that can automate building the bundle. besides the tree shaking bit, I've been deleting files by hand to reach the minimal distribution. dsmith-work: Happy Friday, Guilers!! zzappie: hello! zzappie: Anyone has a clue in which situation (pk match) could ouput (<#syntax transfomer match>)?? linas: breakpoints/repl shells deep in scheme code? How? Deep inside my code, I'd like to just get a repl, poke around, hit ctrl-D and have it resume processing where it left off ... how? linas: I guess I could do a recursive (eval (read)) or something like that ... linas: this gives a hint of what I want to do: (define (break) linas: (let ((input (read))) linas: (unless (eq? '. input) linas: (eval input (interaction-environment)) linas: (break)))) linas: (define (do-stuff) linas: (define x 42) linas: (format #t "start\n") linas: (break) linas: (format #t "end\n")) linas: If I run (do-stuff) and the enter (format #t "It is ~A\n" x) I expect to see "It is 42" but I get "unbound variable" instead... linas: ahh ,mabye I should use `local-eval` and `the-environment`? Hmm. rekado_: linas: you could start a REPL server rekado_: I like to use call-with-error-handling from (system repl error-handling) to spawn a REPL on errors linas: and then telnet into it? linas: It's not that I have errors, its that I'm deep in some nested map/fold/filter and want to stop and poke around and see what's been set in that environment. .. and then continue processing... linas: FYI, I was able to crete what I needed but it needed some elbow grease. I'ts below. I'm surprised this is not a standard guile utility that search engines latch onto ... linas: (define (break env) linas: (let ((input (readline "yo duude> "))) linas: (unless (or (eq? '. input) (eof-object? input)) linas: (catch #t (lambda () linas: (define sexpr (call-with-input-string input read)) linas: (format #t "~A\n" (local-eval sexpr env))) linas: (lambda (key . args) linas: (format #t "Oh no, Mr. Bill: ~A ~A\n" key args) linas: *unspecified*)) linas: (break env)))) linas: (define (do-stuff) linas: (define x 42) linas: (format #t "start\n") linas: (define env (the-environment)) linas: (break env) linas: (format #t "end\n")) linas: (define (bogo) (define y 56) (do-stuff)) linas: with the above, both x and y at the prompt print the right thing. linas: and ctrl-D exits this pseudo-repl with execution resuming where it last left off. leoprikler: linas there are probably more elegant ways of spawning a repl, but yeah, that works linas: I'm a meatball coder. if there's some example web page or doc, tell me what search term to use leoprikler: I don't know how well it's documented, but there is start-repl and a repl server. linas: leoprikler the repl server is just a telnet server. It won't halt execution deep in the middle of some code, and let you poke around. leoprikler: that is correct, because the repl server is designed to run next to your code linas: (and worse, the guile repl server is crashy and slow; I have a super-whizzy telnet repl server that is super-fast and not crashy, and use that in production.) leoprikler: You might want to contribute your fast and not crashy telnet server to Guile at some point then :) linas: eh, its written in C++, with nasty ugly async i/o in it and a bunch of other weird custom stuff. linas: I could point you at it, but it would be a major chore to make it nice enough for ludo to not puke on it (its in github, opencog/cogserver repo) leoprikler: Hmm, I think for a purely guile-based repl-server there is a fiber variant, perhaps that works better? linas: right, I did hear about fibers; I have not tried them or anything built on them. linas: For generic repl, I cannot abandon the cogserver, since it needs to handle megabytes/second of s-expressions, most of which don't actually need to ever hit the guile evaluator. Like I said. it's weird. It also does python :-) for all the python lovers out there. zzappie: sneek: botsnack sneek: :) rekado_: I often wish match-lambda could deal with more than one argument rekado_: this would make fold + match-lambda possible, which is really nice for structured accumulators davexunit: rekado_: match-lambda* ? rekado_: … that exists? *: rekado_ checks davexunit: yup davexunit: (fold (match-lambda* ((n sum) (+ sum n))) 0 '(1 2 3)) rekado_: poifect! rekado_: just what I wanted! rekado_: thank you davexunit: np rekado_: (has this only recently been documented…?) davexunit: yeah davexunit: when I learned about them they weren't mentioned in the manual davexunit: I just happened to be perusing the source poww0wmus1c: Can you have output parameters in Guile/Lisp? RhodiumToad: no RhodiumToad: assuming I understand what you meant correctly poww0wmus1c: Like: (define (foo x y) ...) and I want to set x or y from within foo. RhodiumToad: you can mutate the things that were passed as x and y, if they are mutable (many things aren't), but you can't change what the caller's variables refer to OrangeShark: You can with srfi box RhodiumToad: the caller can pass a box, yes daviid: i think guile has parameters, iirc :), guile-cv uses them] OrangeShark: see srfi-111 for box RhodiumToad: basically, if the caller does (let ((x 123)) (foo x) x) the result will always be 123, assuming foo is a function and not a macro RhodiumToad: unless I'm badly misunderstanding something daviid: make-parameter, parameterize ... RhodiumToad: poww0wmus1c: so the real question is why do you want to do this? poww0wmus1c: I have an exception handler to which I'm passing variables that I want to reset to a good state. poww0wmus1c: I guess box could work RhodiumToad: that sounds like those variables maybe ought to be parameters? RhodiumToad: are they local? lampilelo: can't you redesign to use dynamic-wind or something? poww0wmus1c: RhodiumToad: practically, yeah RhodiumToad: parameters (and the fluids they are based on) are automatically reset on exceptions or other nonlocal control transfers poww0wmus1c: lampilelo: maybe, I'm not familiar with dynamic-wind. :) RhodiumToad: parameters are simpler poww0wmus1c: RhodiumToad: what if I need a more involved reset? Like one of the variables is an SDL window. I want to recreate it. RhodiumToad: confirmed that --enable-mini-gmp is broken - minigmp.c is missing its include of RhodiumToad: poww0wmus1c: wouldn't you usually define the exception handler inline such that it has access to the variables anyway? poww0wmus1c: I'm a very unusual programmer :P poww0wmus1c: But yes, maybe I'm solving the wrong problem here. I'm not sure these need to be parameters. RhodiumToad: sneek: botsnack sneek: :) RhodiumToad: sneek: later tell wingo, build fails with --enable-mini-gmp due to missing include in mini-gmp.c sneek: Got it. daviid: i just did git pull - which implies to merge the local patch of ice-9 boot-9 - then the autogen/configure/make/install danse, then guile version tells me 3.0.5.173-5b4a9 - i was expecting 3.0.6.xxx, did i kiss a step or 'something' daviid: *miss a step (sorry i miss typed k instead of m ...) daviid: the installed version has the ix duplicates handlers for interfaces that use interfaces patch though so i guess i am ok to try daviid: hum, i had a strange error report compiling g-golf, the (g-golg hl-api function) module, so i decided to clone a fresh master, run the autotool danse, installed, and checked the version is now correct, then did a clean and fresh attempt to compile g-golf, but it raises the same strange error, which paste daviid: wingo: after a fresh clone, attempt to compile g-golf raises an exception, but the report is so strange that i can't figure out what causes the exception in the first place - here is a paste, including the last bit of the configure step, so you see it picks guile-3.0, then compile a fair amount of the g-golf project, nearly to the end actually, but fails with this 'strange' error msg trying to compile (g-golf hl-api function) module - daviid: https://paste.debian.net/1195617/ wingo: daviid: fwiw there is an issue regarding syntax-error which civodul found overnight sneek: wingo, you have 1 message! sneek: wingo, RhodiumToad says: build fails with --enable-mini-gmp due to missing include in mini-gmp.c wingo: might have to re-roll a 3.0.7 daviid: ah ok daviid: i have to go to bed, it's been a very long day ... be baack tomorow ... daviid: tx wingo: civodul: re syntax-error, probably something that should make us roll a 3.0.7 soon wingo: wdyt manumanumanu: I am seeing no problems with 3.0.6. No slowdowns for compilation. One 50% speedup out of the blue, probably due to the compilation unit arity check thingie :) civodul: wingo: the fact that syntax-error exceptions show vectors instead of alists? sneek: civodul, you have 1 message! sneek: civodul, bone-baboon says: Thank you. Your questions and strace suggestion where enough to help me solve the error with reconfiguring. It was user error on my part. A typo in a file path that `with-input-from-file` was looking for. wingo: civodul: yeah civodul: yes, could be civodul: i wasn't sure if it was intended wingo: is an unintended change certainly civodul: for the record, here are the changes i needed to make: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=524c9800afb433cc474132185d8e37f72004adb3 civodul: for syntax-error + read-error civodul: also: https://issues.guix.gnu.org/48089 civodul: but yeah, the syntax-error change is user-visible wingo: if you send me some failing unit tests, i can fix the bugs :) civodul: alright! :-) vbramselaar: Hi there, would it be possible to run something like https://orgmode.org/worg/dev/org-element-api.html in guile without Emacs? for parsing org files? vbramselaar: I saw that guile has some elisp support zzappie: vbramselaar: From my experience org-mode code is very dependent on emacs envifonment vbramselaar: yhea it seems like it, does guile not translate things like: (current-buffer) or (set-buffer)? zzappie: vbramselaar: never tried it. But that would be cool manumanumanu: vbramselaar: the thing is, a lot of emacs is written in C. Even a lot of elisp functions. The work that was done on elisp was done with a clear intention of running guile together with emacs, and a lot of the functionality is simply not there when running it standalone manumanumanu: I remember trying to get this across to some guy who wrote the "guile elisp sucks" post that was making rounds a year ago or so. vbramselaar: manumanumanu: Yhea I understand it now. I was mostly looking around for possibilities for running elisp without Emacs. vbramselaar: like when you want to make a different application and parse org files vbramselaar: could write a parser yourself or use org-element zzappie: vbramselaar: I once stumbled upon org-mode parser in guile zzappie: I tried to look for it now but cannot find it. It was on github manumanumanu: What guile-emacs would have become (and it probably wont) would have been cool. Imagine having all the elisp runtime outside of emacs! The utilities one could write for org files, yet have it work exactly like emacs :D vbramselaar: zzappie: Thanks anyway for looking around vbramselaar: manumanumanu: yhea true, there a couple of other libraries for parsing org-mode, but would be nice to stay as close as possible to the creators of the org-mode standard ofcource. zzappie: emacs -Q --script do-things-with-org.el # is probably the best at the moment vbramselaar: but hey this is also a option: https://orgmode.org/tools.html vbramselaar: zzappie: yhea true, tbh I wanted to have a parser for on android to experiment with vbramselaar: zzappie: getting emacs on there seems hard zzappie: oh ah i see :) vbramselaar: but anyway thanks for the help guys zzappie: vbramselaar: i don't see any links in the topic but I think this channel encourages people to address people in gender neutral ways (people/guilers/yall/etc...). Just letting you know :) flatwhatson: vbramselaar: This is some recent discussion about an org grammar: https://lists.gnu.org/archive/html/emacs-orgmode/2021-04/msg00382.html flatwhatson: which references this: https://github.com/tgbugs/laundry civodul: oh nice civodul: we should steal it :-) civodul: wingo's Guile-Present has an Org parser, but maybe it's more limited wingo: it's reallllly old and prolly buggy civodul: heh leoprikler: w.r.t. Guile Elisp, I can understand that not all functions are implemented, but missing language features is ehhhhhhh civodul: take it as an invitation to fill the gaps :-) wingo: :) wingo: there was a branch that still needed to be merged, right? wingo: perhaps terpri will remember leoprikler: btw. did 45131 make it into 3.0.6? wingo: leoprikler: no but it should make 3.0.7 :) rekado: wingo: this one perhaps: https://git.elephly.net/?p=software/guile.git;a=shortlog;h=refs/heads/wip-elisp rekado: it’s the rebased wip-elisp branch rekado: it’s also far behind, but less so than the original wip-elisp branch :) stis: sneek: where is bugs stis: sneek: botsnack sneek: :) stis: sneek: where is debugs tohoyn: sneek: botsnack sneek: :) dsmith: Hey dsmith: sneek: bugs? sneek: I could be wrong, but bugs is Send reports to bug-guile@gnu.org, and see bug reports at https://bugs.gnu.org/guile dsmith: About the difference between emacs-lisp the language and emacs the application: dsmith: Consider javascript. Nodejs doesn't have all the functions and features that are in a browser, right? Like dom stuff? dsmith: I don't do js (much), so maybe I'm wrong. abcdw: Can I post to this channel? abcdw: Oh, seems, it works again) abcdw: Is there a way to get values of environment variables exported by a shell script? Something like source or . command in Bash. Something like (source-env "./bashrc") dsmith: abcdw: Are you asking can Guile parse and read shell syntax? abcdw: dsmith: yep, kind of. Or maybe run external shell process and read variables that it will export. dsmith: abcdw: Nope. not out-of-the-box anyway. If using an external process, the variables would only be in that other process (and child procs of it). zzappie: I think gash can do it. Or at leas it has --parse flag dsmith: Shell source and . must be in the current process. zzappie: it spits out sexpressions abcdw: zzappie: thank you for the idea! dsmith: zzappie: Ah cool zzappie: I didn't use it but I think its in (gash parser) flatwhatson: you could cobble something together to run your script, then run env, and parse that output flatwhatson: to be super fancy you could run env before and after to calculate the diff abcdw: flatwhatson: Yep, that's idea I got in my head, when I wrote a question, looks like a viable solution. Thank you. abcdw: Thank you everyone for help! *: zzappie finds himself exiting bash with ,q civodul: :-) lampilelo: lol brendyyn: i watch to match a value after a value in a lis but this says dotted tail is not allowed after ellipsis (match '(1 2 #:tests? bleh 3 4 5) [(a ... '#:tests? foo . z) foo] dsmith-work: Morning Greetings, Guilers davexunit: brendyyn: I don't think it's possible. you can't use a dotted tail after an ellipsis nor can you use multiple ellipsis patterns at the same level. using a loop and searching smaller and smaller lists would be my recommendation. zzappie: hey anyone knows is there a like (nested-ref '((a . (b . (c . hello!)))) 'a 'b 'c) ;; $1=hello! zzappie: already defined somewhere? zzappie: s/a like/something like/ davexunit: zzappie: not in guile core, no. I've had to write my own a few times. zzappie: davexunit: ha. It must be reimplemented in many programs dealing with json then :) leoprikler: oh, there is something akin to that in sxml leoprikler: but it might not suit your needs otherwise leoprikler: That reminds me, perhaps I ought to consider sxml as data storage for Tsukundere, would be fun. leoprikler: rewriting scenes using pre-post-order zzappie: problem with sxml is that you only remember about sxml when you dealing with xmls leoprikler: yep zzappie: but there is a lot of useful general purpose stuf like foldt leoprikler: I wish sneek had a "tell me in six months or so" function. dsmith-work: heh leoprikler: sneek later ask ArneBab with the new licensing changes, is there a way of constructing a "wisp-minimal" package, that is effectively expat-licensed? sneek: Okay. ArneBab: leoprikler: yes sneek: Welcome back ArneBab, you have 1 message! sneek: ArneBab, leoprikler says: with the new licensing changes, is there a way of constructing a "wisp-minimal" package, that is effectively expat-licensed? ArneBab: leoprikler: yes, I think it’s pretty easy to create a wisp that is expat licensed stis: hey wingo: did you see the compiler bug I found? wingo: heyoo leoprikler: ArneBab: Does wisp internally use invalidate-compilation-cache? davexunit: has anyone ever written a tree shaker for guile programs? until we get native executables, I'd like a way to create binary bundles that contain the minimal number of guile modules needed to run. leoprikler: Tree shaker? davexunit: leoprikler: "tree shaking is a dead code elimination technique" https://en.wikipedia.org/wiki/Tree_shaking leoprikler: Hmm, with guile being a reflective language, I think I can easily write code that shakes your tree shaker. davexunit: huh? leoprikler: shakes as in confused leoprikler: confuses davexunit: I'm not looking for a robust solution. simply booting the program and getting a list of all loaded modules will be sufficient. davexunit: I'm not sure if there's a public api for seeing all of the loaded modules, though. davexunit: haven't spotted one, yet. cybersyn: are native executeables on the guile roadmap? davexunit: yes. cybersyn: nice! that will be pretty sweet. davexunit: many enhancements over the years have been paving the way to eventually make it happen. leoprikler: ArneBab: please have a look at https://gitlab.com/leoprikler/tsukundere/-/tree/wisp-packaging from both a functional and a licensing side :) davexunit: JIT compilation is a big one leoprikler: davexunit: there is module-submodules leoprikler: so you only need to get the top module and then recurse down leoprikler: (assuming your app does not resolve-module at runtime) davexunit: I don't think module-submodules will cut it. leoprikler: well it would if you could access the root module leoprikler: but it seems you can't davexunit: guile is maintaining a list of everything that has been loaded somewhere leoprikler: look at resolve-module, that's where the magic happens wingo: davexunit: never done that. how would you deal with dependencies like libffi ? wingo: there is certainly an api for seeing all loaded modules, read in ice-9/boot-9.scm leoprikler: wingo, where exactly, i can't see it leoprikler: boot-9 can see all modules, but I don't think an outsider can wingo: hooo, everything in boot-9 is public api for better or for worse wingo: i mean we treat it that way when it comes to api / abi compat leoprikler: or to be more precise, I don't think anything but resolve-module can, can it? wingo: module-submodules wingo: ah you refer to "root" being in the closure of resolve-module wingo: humm! leoprikler: yep and resolve-module '() errors out davexunit: wingo: you mean C shared libraries? that's out of scope for what I'm doing. I know what libs I need. leoprikler: I think the abi-compatible way of handling that would be to hand out the root module when given the empty list, but that feels weird davexunit: I just want to slim down the bundle I'm shipping. the compiled guile modules and source files take up most of the space. davexunit: so if I had a way of confidently knowing which I can remove I'd end up with a much slimmer product. leoprikler: Hmm leoprikler: You could do the following: leoprikler: Start from your app module and go up the module-uses leoprikler: if it never appears in the uses chances are it's never used davexunit: wingo: like if I inspect some modules for their dependencies will I see the boot-9 module in there somewhere? leoprikler: That way you don't need to infer everything that's loaded davexunit: I'm surprised there isn't a global table of loaded modules. I mean maybe there is and it's just not accessible. leoprikler: No direct table and not accessible. leoprikler: it's similar to an fs-path really davexunit: yeah then trying this is just going to be a waste of time davexunit: if I can't answer "what modules are currently loaded?" then that's a blocker right there. civodul: davexunit: you can definitely do that via boot-9 APIs civodul: module-submodules, the "obarray", things like that civodul: it's probably not documented though :-) davexunit: maybe I'm just not caling module-submodules with the right args davexunit: I keep getting empty hash tables davexunit: for things I know include other modules civodul: at yes, this one: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/ui.scm#n272 civodul: it traverses currently loaded modules without loading anything more wingo: leoprikler: (resolve-module '() #f) davexunit: should have known there would be magic guix code for this davexunit: hell yeah (module-submodules (resolve-module '() #f #f #:ensure #f)) davexunit: thanks civodul civodul: yw! civodul: it's one of the rare parts of Guile that hasn't changed much since 1996 civodul: submodules did change a few years ago wingo: because it used to be that if you did (define-module (a)) (define b 42) you couldn't then (define-module (a b)) wingo: because bindings in a module and modules themselves shared a namespace wingo: turrible civodul: yes, that was a lot of fun civodul: thanks for fixing it :-) wingo: hehe :) davexunit: there's lots of modules like (#{ g114}#) that show up. davexunit: I guess those can just be ignored davexunit: anything that doesn't map to a file on guile's load path can be ignored civodul: right, you can check module-filename i think davexunit: yup davexunit: this is nice wingo: haha that is the reaction of someone with lowered standards ;) wingo: "this is nice, you just have to be really careful about what you ask for" ;-) davexunit: haha civodul: true :-) davexunit: I'm cool with it wingo: ok so we will roll a 3.0.7 soonish so if you have hotfixes you want in, commit them or poke a committer *: wingo zzz wingo: (do ask for feedback if you need it, of course) davexunit: did a bug happen in 3.0.6? RhodiumToad: at least two of them RhodiumToad: wingo: you saw the thing about mini-gmp? stis: wingo: checkout bug 48098, kind of annoying. Probably you can fix it quickly. ArneBab: leoprikler: I don’t think wisp uses invalidate-compilation-cache. Should it do that? ArneBab: leoprikler: from the licensing I’ll need to check what remains civodul: sneek: later tell wingo thanks for the super fast bug fixes! sneek: Got it. *: davexunit has a working module collector thingy davexunit: now to hook this up to bundle generation ArneBab: leoprikler: there are 4 changes aside from the emacs mode that are not by me (to the Makefile and the README). I’m checking whether these could be released under the expat license, too, to make embedding in Games easier (similar to gcc exceptions). lampilelo: i have two patches if anyone's willing to take a look: one for readline's filename completion (bug #45339) and the second one that got into upstream srfi-64 ref implementation and fixes some stuff i complained about recently ArneBab: leoprikler: how do you run your guix recipy? ArneBab: recipe? leoprikler: changing the last line to the package i want and running guix build -f leoprikler: ArneBab: 👆️ for wisp-minimal only that's "wisp-minimal" at the end of the file ArneBab: ah, with build ArneBab: I tried guix environment --load=guix.scm --ad-hoc, but that didn’t work cybersyn: heya guilers, anyone with experience with Go care to share how guile fibers sizes up? any significant dis/advantages? freeguy: hi freeguy: i have question freeguy: can i use guile(without c) for high performance software development. freeguy: please send me email freeguy: bye daviid: sneek: seen spk121 sneek: zzappie?, pretty sure was seen in #guile one day and 3 hours ago, saying: its pretty -- easy you can inherit package and specify patch file. wingo: guile 3.0.6 release is out -- https://www.gnu.org/software/guile/news/gnu-guile-306-released.html wingo: new docs: https://www.gnu.org/software/guile/manual/html_node/Foreign-Libraries.html wingo: https://www.gnu.org/software/guile/manual/html_node/Annotated-Scheme-Read.html leoprikler: wingo: typo in Foreign-Libraries, [#:rename-on-cygwin?=#t] is on an extra line wingo: tx :) terpri: read-syntax is really cool! the inherent limitations of source-properties always bugged me (more in theory than practice, of course) wingo: 3> wingo: er wingo: <3 :) ennoausberlin: Hello. I am trying to write a mron job using scheme. Can you tell me, how to debug these scripts. If I start mcron and something is wrong in the script I just get Cannot read files in your ~/.config/cron directory but no further output of the error itself ennoausberlin: I read the little schemer and I ran guix on some of my machines, but programming and especially debugging in scheme is still a challenge for me zzappie: ennoausberlin: I don't use mcron but I can give some tips on debugging in general. Probaby most common thing guilers do is (pk body). It will output value of body and the whole experssion evaluates to body's value as well. So you can wrap things there and there without changing program's logic leoprikler: call-with-trace is also useful zzappie: If the output is lost you can additionally wrap with (with-output-to-file "/file" ...) zzappie: I think there is also a posibility to start repl on error connect to a process with telnet or geiser zzappie: but I've never done it :) its in (system repl) or something like that zzappie: there you could use debugging metacommands (use ,help debug to find out more) zzappie: but in general I also find debugging in repl chalenging because stack trace gives me very vague idea where am I in the source code ennoausberlin: Thank you for your advice, but I guess mcron stops at parse time, not run-time. I probably have to start a repl and import all mcron related modules and somehow split my script into pieces and enter it line by line zzappie: oh! It says "source-location information for compiled code" is improved in the newest guile 3.0.6 release civodul: hello! ennoausberlin: I have difficulties to load the mcron modules using (use-modules (mcron base)) civodul: wingo: congrats on the release! \o/ zzappie: hello! +1 looking to see where all my sources are :) ennoausberlin: I installed mcron from git and I have some go files in /usr/local/lib/guile/3.0/site-ccache/mcron/ like base.go or core.go zzappie: *looking forward ennoausberlin: Do I have to add them to %load-path? civodul: ennoausberlin: yes, you need to make sure GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH include the right /usr/local subdirectories ennoausberlin: @civodul: Can I configure this as permanent change somewhere? civodul: yes, you can set environment variables in ~/.bash_profile or /etc/profile civodul: so that they'll be defined when you log in lloda: how about extending define so that (define a b (values 1 2)) works? like srfi-71 ennoausberlin: @civodul: Ah. Of course these are shell variables. My fault leoprikler: lloda: there is define-values IIRC lloda: leoprikler: i know ofc ennoausberlin: If I load the mcron file from the repl via (load "my_test_job.guile") I get back the output $1 = ((#< ... etc)). How can I investigate it further? ennoausberlin: what is the meaning of $1? zzappie: repl saves all evaulations in $number variables zzappie: you can us $1 as a varible in repl ennoausberlin: I understand zzappie: load procedure evaluets content of your file in your context. so if there are any definieitons they apperar in your context and (#< ... etc) i guiess means that you have job object as last expression in your file zzappie: *definitions ennoausberlin: Right. Can I inspect the job expression to see some of the let* bindings? zzappie: hmm... dont know. If job I a record you could acces it with job-* accessors. But I gues the job itself is a lambda -- I dont know how to access its contents other then running it... zzappie: *If job is a record ennoausberlin: The job function is part of the mcron modules and expects an vixiecron entry like ("0-59/5 * * * *") and a lambda zzappie: there is a job function an job record http://git.savannah.gnu.org/cgit/mcron.git/tree/src/mcron/base.scm#n48 zzappie: from #< notation I assume that you deal with job record. Maybe you could try to get (job:action yourjob) and run it? ennoausberlin: zzappie: That would be perfect. ennoausberlin: zzappie: I now store the resulting record in a toplevel named my-record. How can I access the fields like time-proc or action? I never used records so far. zzappie: hm you dont need to create a new record-type.. Maybe you could put the snippet to debianpaste? ennoausberlin: https://paste.debian.net/hidden/9367ee37 ennoausberlin: ennoausberlin: This is from the repl zzappie: aah. I got you now, I thought you defining new record type... yes job record is in (mcron base) module you cann import it and try (job:action my-record) zzappie: *job record type ennoausberlin: I did (use-modules (mcron base)) but then (job:action my-record) ennoausberlin: ;;; :27:0: warning: possibly unbound variable `job:action' ennoausberlin: ice-9/boot-9.scm:1669:16: In procedure raise-exception: ennoausberlin: Unbound variable: job:action ennoausberlin: rekado: these accessors are not exported. rekado: if you just want to play with this in the REPL I suggest entering the (mcron base) module rekado: ,m (mcron base) zzappie: yes didn't notice that, but then your local binging will be gone so you'll need to load your my_test_job.guile file again ennoausberlin: zzappie: I did this an I can now call the procedure. zzappie: s/will be gone/will not be in your context/ davexunit: I didn't realize that guile 3.0.6 introduced a new FFI API. curious how to upgrade to it while preserving compatibility with older versions of guile. ennoausberlin: Every time I stop by here I learn so much. I really appreciate this channel zzappie: its a nice place here :) ennoausberlin: By the way. The error was permission denied because I call mkdir from within the job if a certain dir is missing. Insufficient user rights was the problem. Hard to track down without any output dsmith-work: Hey Hi Howdy, Guilers dsmith-work: Wooo. Release! *: sneek dances civodul: woohoo! civodul: for the record, the GMP/GnuTLS issue is for Guile >= 2.2.7 or >= 3.0.1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964284#58 civodul: (NEWS says 2.0.4) zzappie: I'm trying to wrap with-exception-handler with with-output-to-file inside a macro but file ends up empty... zzappie: https://paste.debian.net/1195555/ zzappie: am I missing something obvious? lampilelo: zzappie: it may be that the ports are not flushed because you're exiting non-locally from the handler, try calling (force-output) after writing your error log zzappie: lampilelo! thanks. It works now lampilelo: glad to help lampilelo: zzappie: i think setting #:unwind argument for with-exception-handler would also work, although i'm not very familiar with exceptions in guile lampilelo: because if raise-exception didn't trigger with-output-to-file's unwind handler it means the port is still open zzappie: lampilelo: I already tried it with #:unwind? #t -- doesn't work that way. lampilelo: what about the outer with-exception-handler? the one that should catch (raise-exception) called from the handler? zzappie: I'm actually intentionally rasing an exception. This macro meant to work similar way to (pk) but also outputing error object if exceptions were rised and doesnt affect other exception handlers because zzappie: going to use it in difficult situations like debugging shepherd services to dump things to the root directory :) zzappie: s/exception handlers because/exception handlers because it reraises exception it got/ lampilelo: since it works, there's no much more to do, the gc will clean up the port eventually wingo: moo ArneBab: goo Noisytoot: goops RhodiumToad: oops wingo: daviid: i have good news for you :) wingo: see most recent commit and lmk how it works for you *: wingo zzz daviid: wingo: oh, very nice tx, i will try asap, and will let you know of course, it is just that right now I am busy on annoying 'admin' ... tx daviid: wingo: good night civodul: oh syntax-error exceptions now see a vector instead of a source location alist RhodiumToad: ice-9 read doesn't get a compiled .go file? RhodiumToad: aha, it's included into boot-9 RhodiumToad: hm. using --enable-mini-gmp failed to compile davexunit: rekado: guix pack would have made for a massive download davexunit: the binary bundle I threw together is admittedly just grabbing libraries from ubuntu + the guile deps that I built davexunit: it worked on the only other machine I could test on, but of course nothing is easy so it blows up in fun ways elsewhere :( civodul: wingo: the "guix build" command above ran to completion though Guix compilation was slow (i was missing the env var), and it triggered a couple of test failures in Guix having to do with source location that i'll have to investigate davexunit: rekado: since you have guix, that's the best way to do. ignore that bundle entirely. davexunit: way to go* rekado: heh, okay :) rekado: I thought it was a guix pack, so it was a surprise to see it fail rekado: I wonder if you could speed up the build of the patched Guile by adding Guile to the inputs, so that it doesn’t need to bootstrap. davexunit: rekado: oh maybe. I was also told of a way to skip building guile altogether. davexunit: haven't had time to implement it, though. davexunit: back to work this week and very busy zzappie: leoprikler: "Digital Deluxe Tarball $200 USD" :D daviid: can a pythonist tell me, out of curiosity, if the python default repl and raised exception printers truncate their outlput? like ny daviid: hum hit enter before ending my quiz ... daviid: but anyway, like numpy? zzappie: daviid: From my experience no... Only time I saw truncated output was outputing recursive structures eg "l = ["recursion->", 0]; l[1] = l" daviid: zzappie: so, you define a vector of 20 millions floats, it displays the 20 millions floats in the python repl zzappie: daviid: im dooing it righ now zzappie: ... 19999997, 19999998, 19999999] well yep zzappie: but it could easily do weird things that are not well documented in other cases... Im saying haven't came accros such feature as guile's ",set print" in python daviid: zzappie: ah tx - pythonist do not use emacs ... but still, it surprises me - i guess pythonist who daily work with large structures do configure the repl and raised exception printers to truncate though ... but don't worry, i was just curious daviid: fwiw, in guile, the backtrace printer(s) do(es) truncate (by default) ... it is just unfortunate our repl and raised excpetion printers don't do that by default as well ... zzappie: daviid: according to stats pythonistas are the most common emacs folk kind ;) zzappie: https://emacssurvey.org/2020/ daviid: zzappie: ah, then those emacs users do not use large structures ... ot there is an easy way to configure both the python repl, raised exception and backtrace printers to truncate ... daviid: zzappie: did you succeed in configuring guile for this matter? last thing i remember is you complained it was not working in geiser, which i responded it does ... then had to leave and forgot to follow ...? zzappie: daviid: yep! I got it working, but I already forgot what was the issue... zzappie: Ah now I remember. Setting it in .guile has no effect on geiser. But doing in geiser repl does daviid: zzappie: that is the symptom of another problem daviid: zzappie: did you patch (ice-9 boot-9), as recommended in guile-cv's manual? daviid: for the error printers i mean ... zzappie: daviid: no I didn't do that one, cause I generally dont get big error outut. I usually hang emacs by accidentally printing guixes operating-sysstem structures or guix derivation building outputs. zzappie: but I taken notes :) zzappie: thank you for pointing out daviid: zzappie: ok - because the guile-cv manual describes the steps to edit the file, but lloda wrote a patch, one for 2.2 and one for 3.0, so now it is quite easier daviid: quite easier then manually edit (ice-9 boot-9) i mean - but still very inconvinient, granted ... if you need help ping us, lloda may help as well ... daviid: zzappie: now, that a guile session 'in geiser' doesn't load your $HOME/.guile content is not normal - zzappie: I usually go through early cycle of emacs config complications and rewrite... Maybe I just misconfugured something daviid: does it loads the .guile file if you launch guile in a terminal (not emacs)? zzappie: daviid: yes daviid: ok, and what about in an emacs terminal, no geiser, just M-x shell, then guile zzappie: works daviid: ok, so M-x run-guile (which should start guile in geiser) fails? zzappie: Yep only geiser repl doesnt truncate daviid: hum, are you using repl-default-option-set! 'print ... daviid: or anotehr way maybe? zzappie: exactly: (repl-default-option-set! 'print (lambda (repl obj) (truncated-print obj) (newline))) daviid: zzappie: and you do import (use-modules (ice-9 pretty-print) (system repl common)) before that call right? daviid: in the .guile file i mean daviid: zzappie: in your .emacs, do you have (setq geiser-guile-load-init-file-p t) zzappie: yes, I do import (use-modules (ice-9 pretty-print) (system repl common)) but I didnt set this variable daviid: ok, please try that and restart an fresh emacs daviid: or execute in *scratch* zzappie: Works! but the repl is soo sloo now :) daviid: really? i never noticed it was slow zzappie: restarted emacs, same thing geiser-guile-load-init-file-p causes repl to take charecter per second zzappie: zero net game... daviid: when you type something? that does not make sence either daviid: :) daviid: here, the geiser session is a fast as it can be, instantaneous zzappie: just runned the profiler seems the reason for slownes is company-mode zzappie: wihout company mode its snappy again daviid: zzappie: ah, don't know what company mode is zzappie: its completion framework https://company-mode.github.io/ daviid: ok i see - well geiser completes for you anyway zzappie: i think geiser uses its backend to company mode if company mode is enabled daviid: maybe you can ask an emacs 'pro' how to disable that mode in geiser, and scheme eiditing files, but not in other buffers ... daviid: zzappie: fwiw, #geiser the author is jao, very nice and responsive ... daviid: not an emacs nor a geiser config expert ... but i am glad we solved your geiser loading .guile problem zzappie: daviid: Thank you for helping out! The time will come when Ill see <#operating-system # ...> in repl and wont have to restart emacs :) daviid: zzappie: welcome - whenever you have some time, you may patch guile for the raised exception printers ... daviid: zzappie: then you can even use guile-cv :):) daviid: which is in guix :) - but don't try it unless you patch the raised exception printers as well ... which i'm not sure how one does that in guix - maybe guix could offer a pre patched guile with lloda's patch zzappie: its pretty -- easy you can inherit package and specify patch file *: zzappie going to zzz daviid: ok good night rlb: wingo: do we promise that a SCM value can always make a safe round trip through a "void *" (via SCM_UNPACK/PACK)? leoprikler: Unless there's something in between, that should be the case. rlb: In between? rlb: You mean unless something messes with the void pointer? leoprikler: It probably just depends on the bits of the pointer, but I'm not too sure what happens if you mess with the SCM it was generated from leoprikler: Certainly, if you do get the messed SCM back, then expect that mess wingo: rlb: it is a good question :) two factors: aliasing and size. guile compiles with -fno-strict-aliasing so no problem there; i have never been sure about users but they should be less exposed to the internals of SCM, so less of a risk wingo: as far as size -- not sure. on mingw64, pointers are 32-bit, but we want to allow 64-bit fixnums wingo: but that part of the mingw patch hasn't landed yet i think wingo: fwiw SCM_UNPACK / SCM_PACK converts to scm_t_bits, the question is really about whether sizeof(void*) >= sizeof(scm_t_bits) rlb: wingo: ok, well if there's any question now (or wrt what we might want to do the future), then my answer is "no" :) wingo: :) rlb: And thanks. The reason I asked is because I could make some slightly more general (internal) helpers for utf8 if I could have a "void *data" argument to a C function (callback loop) that could be provided either an SCM or some C struct (to be interpreted by the provided callback). But I can always do "something else". Could either provide a pointer to a pointer to an SCM, or provide to flavors, or... rlb: "pointer to some C struct, or whatever" wingo: moo civodul: hey wingo! wingo: hi :) qrpnxz: howdy folks, trying to import a library i made with the r7rs syntax. Doing `(import (example library))` but guile doesn't seem to understand. What is the correct way? Thanks leoprikler: qrpnxz: i think (import) in this way is only legal inside a library form qrpnxz: so in guile if i want to import i have to put main in a library or smth? how does that work? leoprikler: oh, wait, it seems the repl eats it even without specifying r7rs qrpnxz: i'm running `guile --r7rs` is that helps qrpnxz: `guile --r7rs filename.scm` rather wingo: qrpnxz: is it a path issue? wingo: i assume you have an example/library.scm somewhere? qrpnxz: i import in the same file i define it, though i'd like to know how it searches for files as well qrpnxz: mm, i'll try that wingo: ah. for that i would think it would work if you define the module before using it wingo: but not otherwise leoprikler: -L . if you have it in your local tree at example/library.scm qrpnxz: it was able to import if i put it in such a file and used -L i think qrpnxz: though the lib itself didn't work, was trying to do smth like (define-library (qrpnxz func) (export (lambda func))) to rename lambda but no dice hahaha qrpnxz: define-syntax also didn't work for some reason qrpnxz: i'm not even able to (import (scheme base)) within a file so that's weird qrpnxz: no problem in the interpreter however wingo: sounds... weird :) qrpnxz: `import` is not bound when i run a file qrpnxz: define-syntax also works fine on interpreter qrpnxz: interesting! after doing define-library on the interpreter, i'm also not able to import anymore. On the prompt, "guile-user" is replaced with the library name qrpnxz: it's like it's doing some weird scoping thing idk qrpnxz: not sure what the "guile-user" is supposed to indicate, perhaps guile just doesn't allow other stuff in the same file as a define-library? idk wingo: don't you have to explicitly declare all imports in the define-library form? wingo: "import" is a purely syntactic thing in r7rs iirc, has to be in the define-library form wingo: if you want the macro version you have to import it from guile qrpnxz: the imports in the define-library are scoped in the library tho no? like it defines what stuff you can use within the definition of the library qrpnxz: import can be used outside in r7rs, that's how you use libraries wingo: only at the beginning of a program tho, right? wingo: like there are "programs" and "modules" wingo: libraries rather qrpnxz: don't think so since The Library Example in the standard has some libraries define and immediately after uses them wingo: and import is still just syntactic in programs iirc -- guile allows it anywhere in a program but that's an extension qrpnxz: see page 29 of https://small.r7rs.org/attachment/r7rs.pdf qrpnxz: import decl are on p25 qrpnxz: not sure what this is getting at: `unexpected syntax in form ()` i get it from qrpnxz: (define-library (func) qrpnxz: (export func) qrpnxz: (begin qrpnxz: (define-syntax func qrpnxz: (syntax-rules () qrpnxz: ((func args ...) (lambda args ...)))) qrpnxz: )) qrpnxz: from importing this that is qrpnxz: bruh it's telling me `begin` is not bound wtf? qrpnxz: lol i had to import (scheme base) for basic stuff like `define`, how unexpected qrpnxz: alright, works qrpnxz: well, using it right after on the same file doesn't work, but importing it and using it works qrpnxz: probably because of that weird context switch thing wingo: generally speaking multiple r6rs / r7rs modules in one file are not well supported -- see https://www.gnu.org/software/guile/manual/html_node/R6RS-Incompatibilities.html *: wingo notes a couple of updates to make to that page qrpnxz: it looks like guile doesn't support (begin) in libraries, instead what you do is define all your stuff at the beginning and then have a define-library at the end of the file qrpnxz: ah nice link thanks taw10: Is it possible to use Guile's Dynamic FFI for accessing C++? The stuff I want to use is idiomatic C++, not the C subset (i.e. I need to call at least one constructor with a double colon in its name). Or, should I just write a thin wrapper with libguile? taw10: My feeling from reading the manual is that it's possible under non-portable assumptions about what the actual symbol names in the C++ library are, and that it'd be better just to write the wrapper leoprikler: taw10 if you write a C header, you should be able to use everything as-is. Otherwise consider using something that's specific to C++ like Schmutz apteryx: any way to debug a .scm file not being prefered to a stale .go file? apteryx: I have this weird situation where a .scm file is newer than its corresponding .go file (which live in the same tree) doesn't prevail apteryx: s/ is// leoprikler: If you don't want to trace Guile's resolve-module, you could copypasta the code and instrument it. leoprikler: then call (my-resolve-module '(bad module)) leoprikler: of particular interest might be the file-is-newer? check apteryx: Thanks for the hints lloda: what's the deal with build-aux/config.rpath? It got updated with gnulib but it seems autogen writes over it. Should it just be removed from git? wingo: i don't recall wingo: if it was added recently and autogen writes it, it can be removed lloda: testing lloda: yeah looks like. Ok i'll remove it dsmith-work: UGT Greetings, Guilers manumanumanu: Can I use guix to build the current master of guile?? leoprikler: You need to add some additional inputs for the bootstrap, but yeah wingo: good evening :) *: wingo pokes guile release civodul: woohoo! daviid: wingo: any news on the #47084 'front'? wingo: no, haven't gotten to it yet daviid: ok lampilelo: how can I mark a bug report as having patch available on debbugs? i realized just now that i submitted a patch along with a bug report like 5 months ago and there wasn't any response lampilelo: ah, wait, it's been merged already lampilelo: i guess i don't understand debbugs lampilelo: shouldn't it be removed from the list then? lampilelo: ok, it seems i'm very confused, it hasn't been merged, i just have it applied locally lampilelo: it's late, don't judge cheim0: lampilelo: https://debbugs.gnu.org/server-control.html cheim0: specifically, the tags command lampilelo: do i need any special permissions? cheim0: not as far as I know. I closed a bug once and I haven't gotten in trouble yet ;) lampilelo: ok, thanks lampilelo: i'll try to use it tomorrow Ikosit: Hi guile! :) Ikosit: Is it possible to tell guix, that the character ; is just a normal symbol? Ikosit: s/guix/guile Ikosit: sry sometimes i confuse guix and guile :S leoprikler: Ikosit: '#{,}# leoprikler: s/,/;/ Ikosit: leoprikler: That wont work, since i need to write ; back as ; leoprikler: do something clever with symbol->string? Ikosit: leoprikler: And also '#{;}# doesn't work Ikosit: (It works with the r7rs syntax) leoprikler: it works for me inside a REPL, but I don't know your constraints rekado: do you want to write comments? lloda: you can do (string->symbol ";") ? lloda: but '#{;}# does work for mme p0a: hey all p0a: Has the Guile project considered providing a cmake module for guile? p0a: I'm thinking of attempting to submit a PR that does that. Since guile-config is available, it shouldn't be hrad p0a: s/hrad/hard lloda: I use https://github.com/stevengj/nlopt/blob/master/cmake/FindGuile.cmake lloda: is that what you mean? lloda: there are several versions floating around don't know which is the reference one lloda: it would be nice if that came with the package and you didn't have to search for it p0a: lloda: I was just reading the cmake tutorial on writing stuff like that and I can't tell you I completely understand what I'm looking at p0a: but the /opt/local/lib path makes me think this is unix only lloda: hmm p0a: although guile-config is used in that find module and /that/ should be OS-agnostic lloda: i have tested that on debian and mac os lloda: cannot say about windows p0a: "Search the paths specified by the HINTS option. These should be paths computed by system introspection, such as a hint provided by the location of another item already found. Hard-coded guesses should be specified with the PATHS option." p0a: So it appears that since it does not exist on Windows, it will simply be ignored. However, it still should be a PATHS not a HINTS. I agree it would be nice to have it included with Guile lloda: i think it should be included with cmake tbh p0a: someone told me it should be included with guile because cmake can't maintain those p0a: and guile is already doing maintanance of guile-config (which is the key ingredient) lloda: they only have to accept patches :-\ they already maintain other languages. Their call I suppose p0a: This has an OpenCog copyright with BSD license however. What does that mean in terms of me modifying it and submitting it as a PR? lloda: you keep their notice and you're good to go iiuc p0a: Gotcha, thanks lloda: i think it would work better if included with cmake since then it's enough for you to do find_package(Guile), that's it. If it comes with Guile then you still have to tell cmake where to find the module lloda: which defeats the purpose somewhat p0a: Guile would test if cmake is installed and if so install it in the right path, cmake provides a mechanism for libraries to do that p0a: according to what I've understood from conversations flatwhatson: It works basically like pkg-config, you just put your .cmake in the right location. flatwhatson: Though it's somewhat redundant if you're already supplying a .pc, calling pkg-config from cmake is trivial. flatwhatson: What would be really nice is adding cmake helper functions for compiling and installing Guile packages to the correct paths. p0a: flatwhatson: so cmake should have helper functions for libraries? Is that what you mean? flatwhatson: Here's mine from last time I played with it: https://paste.gnome.org/pnp7824i5 flatwhatson: Idea was to extend GNUInstallDirs with some guile-specific paths, GUILE_INSTALL_SITE_DIR and GUILE_INSTALL_SITE_CCACHE_DIR flatwhatson: These could be used with some guild incantations and cmake's install() to do the right thing p0a: flatwhatson: does this work on windows? p0a: I can't test because I don't have windows but I'm curious if you know p0a: For example (display (version)) ==> 3.0.1 but my guile is under guile/3.0/ p0a: seems to be an issue flatwhatson: No idea about Windows! It's only using (version) for the version check, (effective-version) is for the install path p0a: Oh yes, I missed it Ikosit: rekado: I want to extend the syntax of kmonad, which uses a lispy syntax Ikosit: (kmonad is a tool for remapping keys on linux) Ikosit: And its syntax uses a single ; for the key ; leoprikler: IOW you want to read kmonad files with Guile? chrislck: knomad uses haskell, not guile leoprikler: haskell-on-guile when? :P rekado: yale-haskell is a bit dated, but it’s implemented in a Scheme-like DSL on top of Common Lisp chrislck: who's raising their hand for lisp on lisp then leoprikler: See also: Lokke, Emacs Lisp in Guile Ikosit: chrislck: I know, my program is more also more like m4 Ikosit: chrislck: But i would really like to turn the lispy config syntax in guile :) dsmith-work: Morning Greetings, Guilers wingo: hey ppl that track perf-related things -- if you see anything weird over past week or two either in compile time or run time, do let me know (cc manumanumanu, lloda) *: wingo about to push a couple more things lloda: check wingo: compiled file size also dsmith-work: Ikosit: is kmonad related to Xmonad? Ikosit: dsmith-work: No Ikosit: The only similarity is that both are written in haskell dsmith-work: Ok. Was thinking it might be a companion app or something. (becaue both haskell) wingo: just took a look on the microbenchmarks and things are mostly neutral for the module call changes and even the cross-module inlining rekado: I’m a little bit disappointed to see that libfive was ported from Scheme to C++ to add Python bindings: https://news.ycombinator.com/item?id=26943176 rekado: whatever works for them, but I really liked that it was written in Scheme davexunit: rekado: that's a bummer :( leoprikler: rekado: The version that's packaged in Guix already has C++, did I miss something? wingo: yaaarrrrrrrgh, investigating a slowdown in a bignum-heavy benchmark -- of course it was the gmp malloc change that is causing the slowdown *: wingo was pulling hair looking for compiler slowdowns wingo: that was it wingo: added an environment variable :P civodul: wingo: oh! what sort? wingo: just that if you build against external gmp, anything that uses bignums gets slower civodul: d'oh, how come? it no longer defaults to custom allocators? wingo: right civodul: d'oh! civodul: i missed that wingo: it defaults to custom allocators iff using mini-gmp civodul: oh right, ok civodul: yes, that's the safe choice wingo: otherwise you can (when i push a patch) set GUILE_INSTALL_GMP_MEMORY_FUNCTIONS=1 in the env wingo: but, irritating. civodul: yeah, it's annoying that we have to make such a choice wingo: well, another reason to rewrite using mpn rather than mpz civodul: it's like: slower bignum allocations, or slower bignum operations civodul: yes civodul: or to just stick to small numbers :-) wingo: lol ;) *: civodul tries "guix build guix --with-input=guile@3.0.5=guile-next --with-branch=guile-next=master" *: wingo dissuades self from merging the cross-module inlining stuff.... for now :P wingo: night! civodul: heh, night wingo! davexunit: guile has some decent representation in the lisp game jam that just wrapped up. davexunit: https://itch.io/jam/spring-lisp-game-jam-2021/entries davexunit: dystopia.el, birb, and the test subject (mine) are all made with guile rekado: davexunit: I wanted to try “the test subject” but I get this: ./launch-game: line 10: /home/rekado/Downloads/the-test-subject/bin/guile: No such file or directory rekado: oh, I think I’ll need to install /lib64/ld-linux-x86-64.so.2 rekado: perhaps you could have used “guix pack -RR” rekado: hmm, even after creating the loader link I get errors: /home/rekado/Downloads/the-test-subject/bin/guile: error while loading shared libraries: libffi.so.7: cannot open shared object file: No such file or directory *: rekado notices all the comments there civodul: davexunit, leoprikler: neat! civodul: rekado: it's not a pack? zzappie: rekado: Speaking of guix pack --RR, I packaged birb with guix pack and it was like 700+ megs uncompressed zzappie: thats a lot :D leoprikler: that's twice the size of dystopia.el civodul: thumbs up to you too zzappie leoprikler: or wait, does "uncompressed" mean after unpacking the tarball? civodul: "guix size guile guile-chickadee | tail -1" says 258 MiB civodul: but i guess it depends on the additional dependencies you pull in zzappie: civodul: The game was written by my friend - torkut. I only helped with packging so far... zzappie: leoprikler: right, its 180mb compressed leoprikler: Phew civodul: zzappie: ah ok tohoyn: sneek: botsnack sneek: :) chrislck: Happy Sunday, all \o/ civodul: o/ sneek: Welcome back civodul, you have 1 message! sneek: civodul, apteryx says: lfam sorry about the hostname change on berlin, I meant to type 'host' to check its IP but apparently typed hostname :-) ArneBab: leoprikler: I tried using Shitsumon with Tsukundere installed via Guix, but I get "no code for module (shitsumon)" ArneBab: leoprikler: when I run shitsumon directly with guile --language=wisp shitsumon.w , I get Module named (tsukundere assets) has no public interface ArneBab: leoprikler: for install I changed tsukundere/guix.scm to return tsukundere/wisp leoprikler: Using tsukundere/wisp should do the right thing, but how did you invoke it? ArneBab: with tsukundere run -L $PWD -A $PWD -m shitsumon leoprikler: Inside the shitsumon directory? leoprikler: Hmm… ArneBab: yes … and I just updated tsukundere and now it works … ArneBab: git pull for the win … ArneBab: sorry … leoprikler: wait, what? ArneBab: must have been stuck on a broken commit (it was e97e170) leoprikler: I did not push anything, that is related to the module stuff recently ArneBab: now I’m on 042d81a and it runs leoprikler: That's strange, e97→042 is a completely unrelated change leoprikler: And I swear I tested with e97 before leoprikler: And even more so with c177b15c before it ssbnxx: hey can someone recommend a good .guile file for me to look at? I found this and I was wondering what else I could add https://gitlab.com/NalaGinrut/guile-colorized leoprikler: ssbnxx: The default .guile in Guix consists of (ice-9 colorized) and (ice-9 readline). I don't think much more customization is needed ssbnxx: leoprikler: okay, thank you ArneBab: leoprikler: I switched back and forth and now it breaks again ?? now with tsukundere/game/internals.scm:40:25: In procedure current-window: In procedure fluid-ref: unbound fluid: # leoprikler: hmm, tsukundere currently always runs in pseudo-interpreted mode, so the backtrace may not be fully usable, but can you check where that call comes from? ArneBab: leoprikler: to reproduce: cd ../tsukundere; echo tsukundere/wisp >> guix.scm; guix environment --ad-hoc -l guix.scm; (now inside environment: cd ../tsukundere-shitsumon/; tsukundere run -L $PWD -A $PWD -m shitsumon ArneBab: In tsukundere/game.scm: ArneBab: 63:22 1 (_ #f) ArneBab: In tsukundere/game/internals.scm: ArneBab: 40:25 0 (current-window) ArneBab: could this happen because I closed the window? leoprikler: Well, the game should exit normally if you close the window, but did you perhaps close it too quickly? ArneBab: possibly, yes ArneBab: but a previous run ArneBab: I wonder whether I have problems because I installed both tsukundere 0.2.3 (from regular guix) and 0.3.x (from the repo) ArneBab: removing tsukundere 0.2.3 now leoprikler: At the very least, I know that 0.2.3 and 0.3.0 are incompatible. rlb: wingo: one thing I noticed - libunistring has a number of functions (see the info pages for unicase.h) for case mapping strings with and without normalization and/or localization. I haven't delved yet, but wondered if we might be able to use those instead of the current per-char conversions. Though if they're all context sensitive (not sure), then perhaps not (given that I think we're not context sensitive now.) leoprikler: I'm trying to see, what tsukundere from Guix should produce on its own leoprikler: Yep, Tsukundere 0.2.3 produces "no code for module (shitsumon)" leoprikler: That's because multi-language support was added in 0.3.0 leoprikler: Similarly, 0.3.0 without linking against Wisp also produces that message leoprikler: or no, it produces an error, that Wisp doesn't exist ArneBab: I now used guix remove tsukundere, and I killed the ccache rm -rf ~/.cache/guile/ccache/ but I still get the error ArneBab: I’ll try installing directly via autotools now ArneBab: still unbound fluid ref at current-window. I’m uninstalling chickadee rlb: If I need to coerce a void* (that I know is an SCM) to SCM, is SCM_PACK() suitable? leoprikler: I think it's roughly Scheme eval, dlopen, string stuff and open patches in the ml rlb: lampilelo: not atm, and I'm pretty sure you wouldn't want to look at it yet. It's still strewn all over the floor. But if you're interested, I'll keep that in mind if/when I get a bit further and try to make something public sooner than I might have otherwise. Zelphir: Hi! Is there a way to make sxml->xml output prettified/indented XML strings? sneek: Zelphir, you have 1 message! sneek: Zelphir, leoprikler says: the manual only talks about languages implemented in Guile itself, not third party projects Zelphir: (I've looked at https://www.gnu.org/software/guile/manual/html_node/SXML.html but not found anything.) lampilelo: rlb: it's just plain curiosity, it's not like i depend on it mwette: Zelphir: Regarding formatted sxml->xml, I typically open a pipe to xmllint --format and output to that. Zelphir: mwette: Is that a command line tool? Piping from inside the Guile code? And: Do you happen to have an example anywhere : )? mwette: (define (open-xmllint-pipe filename) (open-output-pipe (string-append "xmllint --format --output " filename " -"))) mwette: then something akin to (sxml->xml sxml (open-xmllint-pipe "foo.xml")) stis: Hey guilers! do one need to specify compiller options to compile let/ec effektively? leoprikler: Zelphir other than that, you may want to adapt ice-9 pretty-print for your purposes mwette: leoprikler: I think he wants to pretty-print xml not sxml. mwette: The other approach is to re-write sxml->xml to do what "xmllint --format" does. chrislck: this would be a nice addition to the sxml family Zelphir: mwette: thanks! mwette: Zelphir: yw Zelphir: To be more clear: Yes, I do want to format the output of sxml->xml nicely, before it is send to the browser. However, I will also look at ice-9 pretty-print. Thank you Leo. rlb: I wonder if, in a utf-8 world, mutation sharing substrings maintain much of their value, particularly cost/complexity-wise in the code. I suppose as long as you stick to bulk operations, which you'll want to do anyway, they might still be useful. rlb: I also wondered what the requirements for some functions are, like string-trim, e.g. if there's nothing to trim, can it just return the original argument instead of a new string -- or perhaps only if the string isn't shared/mutable, or...? manumanumanu: stis: I don't think that is really a thing... However, looking at the scheme benchmarks, even using delimited continutations, guile is slower than many schemes in the continuation-limited benchmarks (like fibc, for example). manumanumanu: stis: one thing I have noticed giving quite a bit of overhead with continuations is the size of them (a large cons chain takes a lot longer time to escape and restore than, say, a loop with an accumulator), but I don't think that matters much with let/ec. stis: manumanumanu: for this case one could optimize to get super speedy. But this is not something guile seams to be doing (yet) stis: Also because I'm doing set! in python (yes python semantics means that) there is a loss of a factor of 3 if we assume the let/ec is optimized manumanumanu: stis: regarding loop, btw: I have not spent any time thinking about python (the less I spend the happier I become), but there must be some kind of subset of list comprehensions where you don't need set! manumanumanu: I am planning to download python on guile to try it out! It is such a nice project. I don't know enough python to be able to help though. manumanumanu: there is always this little required set! somewhere that just ruins all the fun :( stis: yes but that means a hairy lot of code, it is possible though to make it improve. For example if continue is not used we gain a factor of 2 and are 2x speedier than CPython manumanumanu: Do you have to rely on exceptions to signal iterator ends? manumanumanu: That seems expensive in guile as well stis: yes we need that and for loops doing very few runs it is expensive. Also there is a let/ec for the break notion manumanumanu: that shit would have been sooo much easier with a guile TAGBODY :) :) manumanumanu: but eww... stis: but the let/ec for the continue is for every loop run so to remove that is the most important step usually stis: yes it would, but a good optimizer for delimited continuation would mean that we can implement a tagbody in terms of delimeted continuations and then optimize the result so that it behaves as a tagbody stis: I have an tagbody implementation using delimited continuations actuially manumanumanu: so do I :) stis: so in principle we do not need to add a tagbody primitive stis: cool! manumanumanu: I had one with call/cc, which worked fine in chicken, but was slow as molasses for guile. I rewrote it for guile. I have some questions about nested use though, and I haven't put it online yet. stis: syntax-parameterize!! manumanumanu: stis: is the python-on-guile in guix up to date? manumanumanu: smart stis: no it is an older one and do not work on wingos state of the art guile manumanumanu: now, off to bed! stis: nighty! manumanumanu: I am looking forward to play with python-on-guile soon! manumanumanu: great job! stis: thx leoprikler: does Guile not explicitly state, that it only guarantees that the application doesn't crash, but doesn't guarantee garbage-freeness? ArneBab: leoprikler: If you want to make it easier for people to use tsukundere with wisp, you can simply include the parsed language/wisp.scm and language/wisp/spec.scm in the game. That’s what I do for dryads-wake: https://hg.sr.ht/~arnebab/dryads-wake/browse/language leoprikler: I'm somewhat opposed to bundling, but this raises an interesting question. ArneBab: (I only now saw the spring lisp game jam, and there’s nothing new from me except that dryads-wake now has fully working auto-saves) leoprikler: IIRC, Wisp itself is GPL3+, but this implementation seems Expat-licensed. Are there any notable differences between the two? ArneBab: yes, wisp under GPL3+ is more robust and supports adding procedure properties via literal arrays. But since I am the only author for the implementation (though jan wedekind improved the makefile), it would be easy to allow using it under LGPL. ArneBab: GPL3+ is the project ArneBab: the actual parser and reader are lax licensed: https://hg.sr.ht/~arnebab/wisp/browse/wisp-scheme.w?rev=tip ArneBab: https://hg.sr.ht/~arnebab/wisp/browse/wisp-reader.w?rev=tip ArneBab: (because that’s required for an SRFI) leoprikler: Hmm, so where exactly does the GPL apply? ArneBab: (I’ll have to doublecheck the reader-file, but since the readable stuff is mostly under MIT that should be unproblematic, too) ArneBab: in everything that does not have its own license header ArneBab: currently that’s the reader, but that is more of an oversight on my part leoprikler: oof, normally the GPL wants you to make that explicit by adding the header leoprikler: (hence why most everything in Tsukundere carries one) ArneBab: yes — in this case the wisp-scheme.w file came from the SRFI-implementation, and expat is GPL-compatible leoprikler: also I'm not sure if that's source hut, but isn't the language/ code missing? ArneBab: the examples are GPL, too ArneBab: the language/ code is generated by the bootstrap.sh script ArneBab: from wisp-scheme.w and wisp-reader.w leoprikler: Ahh, I see ArneBab: wisp-reader.w becomes language/wisp/spec.scm and wisp-scheme.w becomes language/wisp.scm ArneBab: there’s also wisp.scm (from wisp-guile.w) that can convert wisp files to regular scheme files leoprikler: apropos wisp.scm, I think there might be some problems with that ArneBab: wisp-guile.w uses string-parsing for that, though, and it has at least two known bugs, one with character literals and comments (i.e. #\;) and another one with comments. ArneBab: how so? ArneBab: (there are two wisp.scm: one in the repo-toplevel and one in language/wisp.scm) leoprikler: I've had source files (I can't recreate them on the top of my head, sorry), that would work fine with the wisp reader, but when asked to translate to scheme, it would be garbage in some way. leoprikler: ah, well, that'd be wisp2lisp, not wisp leoprikler: wisp is just a lazy guile wrapper :P ArneBab: yes, there are some edge cases I never got solved with the string-parsing approach (I wouldn’t have thought that parsing scheme is so hard). It’s why I switched to the reader. ArneBab: yes: it got so much easier when I decided to simply call (read) on any construct that’s not needed for specialized treatment :-) ArneBab: (people had told me to try for months and when I tried I found they were right) ArneBab: wisp2lisp has some edge-cases — it can happen that paren-adding ceases at some point. Typically there’s a character-literal at that point. I tend to work around those by replacing it with (string-ref "" 0) ArneBab: that’s very annoying to me, but I did not manage to fix it ArneBab: (I wish I could get wisp2lisp fully equivalent to wisp-scheme.w, but I already failed twice at getting rid of the last few edge cases) leoprikler: Joke's on you, even compiling down to Tree-IL and back doesn't save you. ArneBab: yes: using the reader I lose the comments ArneBab: so I cannot replace wisp2lisp by language/wisp.scm leoprikler: Well, comments are one thing, but I mean in terms of actual code. ArneBab: do you mean there’s a bug in the read-using implementation? ArneBab: If you can give me a test-case (wisp-code and scheme-code that should both become the same tree-il), that would be great! leoprikler: no, I mean much more, that it's possible to write Scheme, that can be "compiled to Tree-IL and back" and make perfect sense, but can't be compiled directly to bytecode ArneBab: do you have an example? leoprikler: I once stumbled on such a case when I debugged some funky macro with macroexpand. ArneBab: can that Scheme-code actually work? Is it valid Scheme? leoprikler: I think it's valid Scheme, but I vaguely recall it does weird things with identifiers. ArneBab: that sounds nasty :-) ArneBab: (and fun) leoprikler: I think the bug was, that Tree-IL correctly sees them as two different literals, but when compiled back to Scheme, they are one again (because that version of Guile undid the gensyms) leoprikler: If you compile that code again, there is no longer any macro expansion, so it just eats that. ArneBab: yikes! That means wisp2lisp will always have to stay a string-transformation implementation. ArneBab: So I might have to try my hand at fixing its remaining edge-cases again. leoprikler: I don't think that this is unsolvable per se, but the Tree-IL→Scheme back transformation certainly has its own edge cases to deal with. leoprikler: If you can live with gensyms, I think 3.0.5 might be fine. leoprikler: The Tree-IL I saw from that is a little on the verbose side ArneBab: wisp actually doesn’t do much in terms of complex processing: It just turns indentation-based code into the structure that repeated (read) would get from the equivalent scheme file. ArneBab: that’s also what’s checked in the tests: https://hg.sr.ht/~arnebab/wisp/browse/tests?rev=tip ArneBab: → https://hg.sr.ht/~arnebab/wisp/browse/tests/runtests-scheme-reader.sh?rev=tip leoprikler: okay, nope, no fancy identifiers in that ArneBab: I try to keep as simple and stupid as possible :-) ArneBab: (keep wisp as simple and stupid) leoprikler: btw. can wisp handle stuff like receive? ArneBab: here’s what wisp wants to guarantee: https://hg.sr.ht/~arnebab/wisp/browse/testrunner.w?rev=tip#L26 leoprikler: e.g. I'd want leoprikler: receive leoprikler: ____ proc leoprikler: __ body body* ... ArneBab: how do you call it in scheme? (with imports) leoprikler: it's inside (ice-9 receive), but I'm talking about the syntax here ArneBab: can you give a minimal example in Scheme? ArneBab: (with parens) leoprikler: (receive (car cdr) (car+cdr '(car . cdr) car) leoprikler: so it'd be receive : formal formal* ... actually leoprikler: ehh, paren closing leoprikler: (receive (car cdr) (car+cdr '(car . cdr)) car) ArneBab: my guile just complained :-) ArneBab: with Guile I get bad lambda in form car cdr: syntax error ArneBab: with ArneBab: ah, I closed the wrong paren leoprikler: (ice-9 receive) (srfi srfi-1) ArneBab: what should that give? leoprikler: the symbol 'car ArneBab: so this: ArneBab: (import (ice-9 receive) (srfi srfi-1)) ArneBab: (write (receive (car cdr) (car+cdr '(car . cdr)) car)) leoprikler: I tend not to like write in the repl, but yeah leoprikler: but the special trick here, is that the first 2 forms require extra indentation if they're not on the same line ArneBab: import (ice-9 receive) (srfi srfi-1) ArneBab: write ArneBab: receive : car cdr ArneBab: car+cdr '(car . cdr) ArneBab: . car leoprikler: so what I'd like to have is something, where I could indent car a bit less leoprikler: similarly: ArneBab: Wisp uses the prefix-dot to reach the same goal. leoprikler: I don't think you understand me correctly, I would want the dot with less indentation. ArneBab: I think I do, but while it might actually work, it’s not how wisp is specified leoprikler: fair enough ArneBab: You can actually do this: ArneBab: write ArneBab: _ receive : car cdr ArneBab: ___ car+cdr '(car . cdr) ArneBab: __ . car ArneBab: but it’s not guaranteed that it will keep working (since it’s not in the spec) ArneBab: and gives you this warning: ArneBab: ;;; WARNING:5: used lower but undefined indentation level (line 4 of the current chunk: (REPR-DOT-e749c73d-c826-47e2-a798-c16c13cb89dd car)). This makes refactoring much more error-prone, therefore it might become an error in a later version of Wisp. leoprikler: another case, where it might make sense to think about this though is define-public leoprikler: because functions with many arguments typically split them leoprikler: but doing so makes refactoring much more error-prone :) ArneBab: :-) ArneBab: with many arguments, I use ArneBab: define ArneBab: fun arg1 arg2 arg3 ArneBab: . arg4 arg5 ArneBab: . arg3 arg7 ArneBab: . #f leoprikler: yeah, but you can no longer define : fun ArneBab: yepp — that’s the limit of the inline-colon syntax leoprikler: That being said, I still feel like a genius for using arguments as initialization. ArneBab: the colon is intentionally limited: the reason why the colon exists as special syntax is that it can be used alone on a line: https://www.draketo.de/software/wisp#sec-4-2 ArneBab: can you give an example of that? ArneBab: (I’ve been looking at tsukundere but missed examples) leoprikler: https://gitlab.com/leoprikler/tsukundere-shitsumon/-/blob/master/shitsumon.w#L99-104 <- this function is only ever called without arguments ArneBab: wow, that looks awesome! ArneBab: and I seriously have to link it on the wisp-page (if you don’t mind) ArneBab: Do you already have a dedicated website I could link to? ArneBab: (I need to get to bed — I’ll see your reply tomorrow, if you can’t reply before I need to get AFK) leoprikler: For Tsukundere? I only generate docs, sadly. leoprikler: I think linking Shitsumon as-is *should* be fine, but it doesn't have a release mainly because I haven't yet coded the fancy main loop with credits stuff. leoprikler: That said proper credits should at least exist in the README ArneBab: I’ll think of a way tomorrow (when I’m not as dead-tired as right now — it’s half past one in the morning here :-) ) leoprikler: Oh yeah, my super exciting web page: https://leoprikler.gitlab.io/tsukundere/ rlb: leoprikler: if you were addressing my string questions, then right, I think we *might* be within the letter of the law, but if so, was still wondering about whether the difference was actually OK before I spend a lot more time on some of the function conversions. sneek: rlb, you have 1 message! sneek: rlb, zzappie says: not useful at this point of time but hey, I didn't know about lokke ArneBab: I already found that one — it could really benefit from a screenshot :-) (and yes, despite the smiley I really mean that — every game-website is stronger with a screenshot) leoprikler: Oh, sure, I just haven't written enough free games with it. leoprikler: It also needs a logo, of course. ArneBab: that’s my problem with enter-three-witches, too :-) — dryads-wake is the first that I hope to get actually playable leoprikler: Which means that next month I'll have some AI generate more anime faces. leoprikler: If we dedicated all our crypto mining GPUs to generating anime portraits, we'd still have the same emissions, but at least it'd be worth it. leoprikler: How do we solve this issue? By inventing a crypto currency with an anime portrait based proof of work scheme. ArneBab: do you mean something like this? https://www.thisfursonadoesnotexist.com/ ArneBab: https://thisanimedoesnotexist.ai/ ArneBab: → https://thisanimedoesnotexist.ai/downloads.html ArneBab: not to forget: https://www.thiswaifudoesnotexist.net/ leoprikler: needs to have a torrent option imo ArneBab: (I knew it would one day come in handy to keep these bookmarks around :-) ) ArneBab: ⇒ upload to a torrent tracker? It sounds like it’s legal. ArneBab: https://www.thiswaifudoesnotexist.net/ ArneBab: (wrong copy buffer — this one: https://www.obormot.net/demos/these-waifus-do-not-exist-v2-alt ) ArneBab: now I really need to sleep — I hope these help you! leoprikler: btw. I was originally referring to https://www.artbreeder.com/ since it comes with the clear restriction, that all images generated from it must be cc0 leoprikler: good night :) ArneBab: same to you! wingo: rlb: hooo good question (re: racing writes on shared mutable strings). i guess in general i don't mind making string-set! arbitrarily slow, but we should do all we can for string-ref -- requiring locks would be unfortunate! wingo: rlb: what happens to concurrent string-ref when string-set! needs to expand the stringbuf because the codepoint takes a different number of bytes? wingo: in the non-shared case rlb: The way I have things right now, strings only contain their char count and offset into the stringbuf, and the pointer to the stringbuf. stringbufs never resize in place (so byte offsets don't change for other internal operations). Given that, if it's mutable, and we're replacing chars of the same size, we may mutate them in place (as we used to), but otherwise we create a new stringbuf, copy the contents (while making the relevant rlb: changes), and then do a simple assignment to swap the stringbuf pointer in the shared string. No locks. rlb: So as per our docs, unrestricted concurrency could cause weirdness, but shouldn't crash anything (in theory). rlb: But it does mean that two operations can race to create the new adjusted stringbufs and "last one (swapped in) wins". rlb: Hence two competing string-set! operations on a shared mutable string could result in one of the updates being lost. rlb: (for example) rlb: string-ref is lockless too, and it's one index lookup followed by a search of up to "stride" chars to find the exact location. The stride depends on the string length, right now 16, 32, 64, or 128 (as an upper limit if the string is larger than 4GB). rlb: But don't spend too much time worrying about this unless you just want to. What I have now is unfinished, and has grown to be a good bit more work than I'd initially imagined. I do seem to keep working on it, but no idea if I'll actually finish it up well enough to have something worth proposing. rlb: (As mentioned mostly just wanted to make sure I wasn't doing something that already seemed clearly unacceptable.) lampilelo: if a user is calling string-set! on a shared string from different threads without any synchronization he's asking for trouble wingo: rlb: races for unlocked operations sound fine to me. (famous last words?) nly: is reactjs fine from a free software perspective? jlicht: nly: afaik, it seems to be perfectly fine free software jlicht: nly: I advise you to look into the patent situation, as I recall there being some potential issues nly: thanks dsmith-work: Happy Friday, Guilers!! mwette: hey all! zzappie: hellou rlb: wingo: ok, thanks, and of course I suspect in most cases, if we make this switch, string-set! and (bulk string-refs) will be best avoided (i.e. in favor of string-map/tabulate/for-each/etc.). rlb: (Internally, those won't use string-ref, etc. anymore.) lampilelo: rlb: is your wip code published somewhere? Noisytoot: What's the difference between use-modules and import? RhodiumToad: import is from RnRS, use-modules I believe is a guile-ism RhodiumToad: otherwise they should be compatible in the sense that any given module should be importable either way RhodiumToad: though I do recall some breakage with import from a while back RhodiumToad: oh yeah, it's (library) rather than (define-module) which is the issue, (library) was losing all source location info dsmith-work: import is more along the lines of C #include I think. It basically inserts the forms from the file at the point you call import. dsmith-work: use-modules is more like load. Happens at top level. But it also does a bunch of binding management. dsmith-work: (I've seen that use-modules calls load deep under the hood) RhodiumToad: last I looked, import was just syntax for use-modules dsmith-work: Oh! dsmith-work: was thinking of include, not import ! alextee[m]: is there a roadmap for the next guile release somewhere? dsmith-work: Ahh. yes. dsmith-work: daviid: Thanks rlb: ...been side tracked lately, so not much public progress there for a bit, though I have been working on potential defrecord/defprotocol support off and on. RhodiumToad: moo wingo: landed a little patch to elide arity checks when callee is known manumanumanu: wingo: cool! I have been thinking about what you said about how Cross-module inlining changes how we write code. I went back to some old guile 2.0 code, wrote some test benchmarks and started removing all the small tricks I used to make it run fast. It went from ugly code that used macros to inline things and a bunch of little ugly hacks to more or less standard scheme. Without sacrificing manumanumanu: performance. Meaning: If I wrote that code today, I would have spent a lot less time making the code ugly. At least that specific kind of ugly manumanumanu: wingo: did guile always check arities before? This seems like it could be a very nice addition in declarative modules... wingo: manumanumanu: before, for calls that didn't end up being contified or inlined, guile would always check arities, even if the callee was known (i.e. callk instead of call) wingo: now, if the compiler puts in a callk, it will later split the callee into two functions: one which checks the incoming arity and one that doesn't. the one that checks the arity tail-calls the one that doesn't. manumanumanu: now, I am not really up with the terminology, but contification is where several calls to one function returns to one place; (if x (f x) (f y)) manumanumanu: ? wingo: then it will update any callk with compatible arity to instead jump to the new unchecked entry wingo: yeah contification is if one function is always called with the same continuation. in that case it can be wired into the callee wingo: er wingo: caller :) manumanumanu: thanks. This seems like a wonderful little optimization addition then :) So, functions too large to be inlined, and uneligible for contification will become cheaper? manumanumanu: to call manumanumanu: How wonderful! zzappie: leoprikler: oh i didn't know this algo (fisher-yates) zzappie: daviid: thanks fo the tip! manumanumanu: is it the incremental shuffle? manumanumanu: zzappie ^ manumanumanu: daviid: I did not mean that in an insulting way. I was having to patch boot-9 of an installed guile that I meant as a hack. That is a sad way to have to go about it. zzappie: daviid: How your students were using guile? Did they use emacs? I'm asking because my friend started using guile and I found that for unprepeared people guile causes huge amount of frustration... rekado: “guile causes huge amount of frustration” or Emacs? rekado: I would agree that Emacs causes frustration, or at least learning Emacs while actually wanting to learn Guile. rekado: that’s the motivation behind guile-studio zzappie: If you not using emacs. And not used to search thing in info in emacs rekado: guile-studio aims to make Emacs more useful out of the box for hacking on Guile, while also configuring away some of its weirdest quirks. rekado: (it’s not 100% successful as some quirks still remain) rekado: here’s more information about guile-studio: https://elephly.net/guile-studio/ zzappie: rekado: Yeah I know about guile-studio It is great that you took time making it. But it still another editor with less quirks. :) People want to use their editor. rekado: it just occurred to me that it would be useful to discover any manual related to Guile and add it to the intro buffer on the right. rekado: oh, they *can* use their own editor. It just won’t have any integration at all. zzappie: manumanumanu: I don't know :) rekado: (Emacs is not strictly necessary to read Info manuals; there’s pinfo or just info, but they are inferior to the info reader in Emacs) manumanumanu: zzappie: if you ended up using guile's (random ...) you will need to seed it first, otherwise you will produce the same permutation every time you restart guile. zzappie: manumanumanu: ah its not necessay in my case it for maze generations zzappie: rekado: Yes. People need seacheable webpage with manual and lsp server today zzappie: This will greatly lower barier of entry zzappie: my friend was looking up racket manual because was lost in guile reference. manumanumanu: zzappie: I usually point people to the procedure index. manumanumanu: I always have a tab open: https://www.gnu.org/software/guile/manual/html_node/Procedure-Index.html#Procedure-Index zzappie: And btw Im telling it just to find what's guile folks think on this issue. If the people think that opting for modern style of tooling is not worth it cause most of guilers gnu+emacs hackers than Its completely fine. But I had the impression that guilers want to widen the community *: zzappie g2t afk for for few minutes wingo: a better web interface for info files would be really great leoprikler: I have yet to really integrate lsp-mode into my Emacs config, so yeah… leoprikler: btw. I can't seem to get this deterministic randomness, that people speak of leoprikler: okay, nvm I forgot I initialize it manumanumanu: leoprikler: start guile, do (random 100) a couple of times. Restart guile. Do it again leoprikler: leoprikler: okay, nvm I forgot I initialize it manumanumanu: I get 61 51 36 81 manumanumanu: oh manumanumanu: sorry, manumanumanu: I read "I forgot TO initialize it". leoprikler: heh leoprikler: I've copypasta'd the fisher-yates back and forth manumanumanu: I usually just read from /dev/urandom :) leoprikler: In some implementations, I do initialize it, because I want to have a new state on each startup, in others I want the determinism and thus don't initialize it. leoprikler: I confused one case for the other ;P zzappie: hey is there such thing as portable scheme code? Meaning that you can just run it with most of cheme implementations? Sticking with r5rs enough or its harder than that? manumanumanu: Sticking mostly to r6rs means guile and chez works just fine. zzappie: manumanumanu: cool! need to try that one day lampilelo: am i crazy or should (test-end) from srfi-64 not reset current test runner if it was installed globally? lampilelo: am i supposed to set the test runner before every test-group call? lampilelo: i think that's a bug, added by fixing another bug, in last august leoprikler: i think most suites won't see that bug, since they have one group per file, but it does sound like a bug lampilelo: srfi states that the runner should be removed in test-end if it was added by test-begin, but it removes it unconditionally manumanumanu: I don't like srfi-64. It does weird things. lampilelo: i think there's another bug: test-group expects the runner to be set, and errors out if it's not lampilelo: manumanumanu: what do you mean by weird things? maybe the implementation is just buggy manumanumanu: it is the reference implementation, more or less. leoprikler: it is also imperative and imperative = eww manumanumanu: I have met cases where the reference implementation does not conform to the spec (one was however a misunderstanding). Taylan rewrote large chunks of it because he got tired of it lampilelo: so what do you recommend? lampilelo: i mean instead of srfi-64 manumanumanu: for guile, nothing :( manumanumanu: If you need the flexibility of srfi-64 then srfi-64 it is. manumanumanu: other than that, I am going to implement (chibi test) on top of srfi-64 whenever I have the time. That does less, and does what most people do want. rekado: I used ggspec before I learned about srfi-64 rekado: https://github.com/yawaramin/ggspec/ chrislck: ah ggspec... written by yawaramin for gnucash and never used chrislck: he'd be proud to know it was actually used lampilelo: :D lampilelo: i think i'll stick to srfi-64 because less dependencies lampilelo: but i'll try to fix it first lloda: i'm sorry about the srfi-64 bug. I just applied the patch from upstream without giving it a second thought lampilelo: lloda: those buggers from upstream lampilelo: i think the proper fix would be to install a cleanup function in the newly created runner's on-group-end field, but since it's a reference implementation i wonder if i'm not misunderstanding the srfi lampilelo: why hasn't it been fixed already? abcdw: I get very strange behavior with my guile code: If I evaluate forms one by one, everything works as expected, if I evaluate the whole file it works differently. For purity extracted the code to separate file, still have the same issue. Can someone point out, what I did wrong?( abcdw: https://paste.sr.ht/~abcdw/8c1754cbe135b2f4505ca33254f3dd2b03dc892d lampilelo: abcdw: does it work the same if you restart your repl and try again? lampilelo: also why do you have the definitions wrapped inside a begin block? dsmith-work: Thursday Greetings, Guilers lampilelo: hi dsmith-work abcdw: lampilelo: yes, tried to restart repl. Because I was experimenting with evaluating 4 those forms at once, works the same as evaluating the whole file. Nothing changes without begin. abcdw: it's very strange, evaluating forms one by one produce different result from evaluating 4 forms at once using begin or C-c C-k. apteryx: could someone walk me through understanding the primitive-fork return value? It can return either the 0, meaning we are in the child thread; or a pid, which means we are in the parent and got the pid of the child process; what I don't understand is given this duplicity and single call; how are the two conditions 'visited' in the parent thread? does it implicitly calls primitive-fork a second time apteryx: when returning from the thread? civodul: apteryx: child *process*, not thread civodul: but yes, what you describe is correct civodul: fork(2) creates a child process that's a clone of its parent civodul: the only difference is that it returns 0 in the parent and the child's PID in the parent civodul: now, in Guile, it's often "safer" to avoid 'primitive-fork' and use 'open-pipe*' & co. apteryx: OK. I've seen this in the manual, but I need my open-pipe* to run with a specific user/group, and apparently we can't change the current process userid/groupid (that's in shepherd, probably because that process is PID 1?) apteryx: thank you for the explanation! civodul: in Shepherd you can use fork+exec-command apteryx: I also need to capture the output :-) civodul: now you're too demanding, what can i do :-) apteryx: hehe civodul: seriously though, we should have the whole gamut of process-fiddling procedures in a Guile module apteryx: there's #:log-file that I could set to a temp file, but I'd have to adjust that temp file's permissions for the specific user/group civodul: Gash has most of it too apteryx: yeah that'd make sense abcdw: civodul: Yep, it would be really cool to have a module with a bunch of helpers for running processes, capturing their outputs and so on. apteryx: even in a child process of shepherd, I don't have the permissions to use setgid and setuid; ideas? In procedure setgroups: Operation not permitted civodul: apteryx: you have to call setgroups before setgid and setuid apteryx: I mimicked what the shepherd does in its exec-command procedure: (setgroups #()) before the setgid call, but that still fails. mmh. apteryx: perhaps something to do with the CAP_SETGID capability apteryx: I'm testing the Shepherd service via the Guix system test framework rlb: lampilelo: not sure if it's the issue you were hitting, but wrt newer versions of our srfi-64 support, you might need something like this: https://git.sr.ht/~rlb/lokke/tree/main/item/mod/lokke/scm/test.scm#L9 to avoid a crash when trying to use the test status to determine an exit status. rlb: wingo: regarding the approach I've been toying around with for utf-8 strings. If stringbufs are immutable, and we still support shared mutable strings/substrings on top, and if we're going to atomically/locklessly swap the string stringbuf whenever there's a modification, then that means that competing string-set! calls (on strings that share the same mutable stringbuf) might lose updates? If so, is that "don't do that then", or a rlb: critical difference/problem with respect to the current behavior? lampilelo: no, that's not my issue, i've already submitted a patch to srfi's mailing list rlb: Ahh, ok. rlb: e.g. given competing (string-set! x 5 #\x) (string-set! y 11 #\y) calls, there's a read/update/write(swap) race. So #\x or #\y could be lost from the final stringbuf, etc. With the current code, of course, and assuming no "torn word writes", both should eventually "settle" thread-visibility-wise. rlb: (And also, of course, the performance of one-at-a-time string-set!s is going to be atrocious for non-ascii strings anyway, so eventually, you'd want to avoid that whenever you can...) nly: no ,doc ? wingo: should be wingo: not all functions have docstrings of course wingo: actually i wonder if ",doc" is broken somehow; ,d works wingo: good morning! cheim0: ,doc = ,describe? nly: morning :D nly: thanks BitPuffin: Are there any wlroots bindings for guile? If not, what's the best way to generate c bindings for guile, swig? rekado: BitPuffin: I had excellent result with the ffi-helper that’s part of nyacc BitPuffin: Oh, first time I hear of nyacc BitPuffin: Looks interesting! rekado: it made writing Guile bindings to DRMAA much easier rekado: all it takes to get started is define-ffi-module like here: https://git.elephly.net/?p=software/guile-drmaa.git;a=blob;f=drmaa/v1/ffi.ffi;h=4327926aef2aaa87097247051cbb68e360f82228;hb=HEAD rekado: when fed to the ffi-helper this results in a module that I’m importing here to provide more Scheme-like bindings: https://git.elephly.net/?p=software/guile-drmaa.git;a=blob;f=drmaa/v1/low.scm;h=4e9ac55096222969a2cb79ca74c6e5162de7ca4d;hb=HEAD flatwhatson: does that make nyacc a runtime dependency of your package? rekado: flatwhatson: the generated code depends on one module that nyacc provides. You can copy that module to avoid a runtime dependency on nyacc. rekado: that is what guile-libyaml does flatwhatson: ah, perfect! BitPuffin: rekado: so after you have the raw binding you make more scheme friendly abstractions on top? leoprikler: yep nly: how do i display favicon from guile web server? BitPuffin: nly: guile web server only gives you some very basics, you basically have to either load and serve it as bytes, or serve it with a reverse proxy in front of the web server like nginx BitPuffin: Afaik at least wingo: you could handle the favicon path and return a suitably-mime-typed bytevector wingo: but yeah i usually get nginx to handle the static things BitPuffin: Gotta be webscale leoprikler: render it ad-hoc with guile-picture-language :) BitPuffin: wingo: are there any more or less meaningless microbenchmarks of guile vs C out in space that you know about? BitPuffin: By space mean cyberspace nly: thanks dsmith-work: {appropriate time} Greetings, Guilers leoprikler: BitPuffin: you mean other than http://wingolog.org/archives/2019/06/26/fibs-lies-and-benchmarks ? BitPuffin: Oh, first time I'm seeing this BitPuffin: Was searching earlier but nothing cool came up BitPuffin: Will give it a read lampilelo: BitPuffin: this benchmark is for guile version < 3, guile became a bit faster since then: https://wingolog.org/pub/fosdem-2020-images/guile-3.0.0-vs-2.2.6-microbenchmarks.png BitPuffin: Ah yeah pretty sure I've seen this one, but it is guile vs old guile right? lampilelo: BitPuffin: yes ArneBab: BitPuffin: there is also Guile (3.0.4, current is 3.0.5) vs. Scheme-to-C-compilers by ecraven: https://ecraven.github.io/r7rs-benchmarks/ — gambit/gerbil compiles Scheme to C, Chez is crazy assembly-optimization, racket is Chez, then you get the Schemes that are roughly as fast as Guile 3. The benchmarks also show Guile 3 vs. Guile 2, so they can make older benchmarks somewhat comparable to Guile 3. zzappie: hello guilers! anyone knows function analogous to rackets shuffle in guile libs? zzappie: * shuffle: Returns a list with all elements from lst, randomly shuffled. wingo: woo, i have a pass to elide arity checks wingo: (good evening zzappie :)) wingo: zzappie: nothing in guile's libs i think zzappie: hello :) zzappie: already stolen it from racket wingo: great zzappie: only changed those square brackteers dsmith-work: silly rackettes, square brackets are for clojure (, and emacs-lisp) dsmith-work: rlb: what's your clojure thing called again? leoprikler: zzappie: I have manually implemented good ol fisher-yates daviid: and configure.ac daviid: zzappie: fwiw, patches and tips in guile-cv's manual sibling sections dedicated to 'configure guile for guile-cv', so repl and raised exceptions do truncate their output, work fine with geiser daviid: manumanumanu: it is not a hack, it is a nive and clean patch - the hack is to have to ask users to apply it, unfortunately daviid: *nice ...by lloda - we both, and any one of us working with large structures, depends on the patch, otherwise, guile is just unusable daviid: most users are dead scared to patch (ice-9 boot-9) themselves though, hence guile is unusable - form them,guile-cv users and any other users who have to manipulate large structures daviid: i stoped working on guile-cv, it was to teach yung adults and not so young adults :), but defiitely beginners for most of them, to use scheme and have fun doing so image processing ... even phd students didn't feel confortable to patch ... daviid: dsmith-work: lokke daviid: https://git.sr.ht/~rlb/lokke manumanumanu: Ahoy! wingo: moin :) rgherdt_: Moin! manumanumanu: Anyone here on 3.0.5? manumanumanu: can anyone tell me when I can have definitions in expression context? It doesn't seem to be allowed in cond clauses. terpri: manumanumanu, i'm on 3.0.5 and it appears to be permitted terpri: let me check cond in case 'define' is magic terpri: (cond (else (write 'o) (define k 'k) (write k)) prints "ok", seems to works fine terpri: work* manumanumanu: that expands to a simple (begin ...). try this: (define (a b) (cond ((= b 1) (define c (+ b 222)) c) (else 33))) manumanumanu: there seems to be some kind of limitation there. it's fine. I was just surprised. zzappie: hey does anyone has a tip how to prevent guile from pringing out huge records in repl? zzappie: *printing manumanumanu: it is possible, but I have forgotten how... manumanumanu: ah! https://www.gnu.org/software/guile-cv/manual/html_node/Configuring-Guile_0027s-repl_002dprint-procedure.html manumanumanu: the error printing is not afected iirc wingo: there is a repl option wingo: ,option on-error print wingo: or something like that manumanumanu: ",option on-error report" maybe manumanumanu: TIL lloda: i think the point isn't to replace debug/backtrace wholesale, just to fix how values are printed within those manumanumanu: well, the (system repl common) truncate-print trick works when there are no errors lloda: there's a sibling section in the guile-cv manual for truncate-printing in errors lloda: it's a hack tho manumanumanu: "The module we need to modify is (ice-9 boot-9)" ... :P manumanumanu: that must be the definition of a hack manumanumanu: are parameters available in boot-9? If that is the case, I could take it upon myself to patch it. Exceptions are, well, exceptions and having that kind of indirection wrt error printing shouldn't do much to performance. lloda: what that hack does is patch a function simple-format that is used in (ice-9 boot) in all the default exception printers lloda: if you can figure out a clean way to fix this issue that would be greatly appreciated lloda: imo a lot of this is kinda broken atm lloda: it cannot be the intention that errors print as lloda: 'Bad on-error value ~a; expected one of ~a ...' lloda: you see those format specifiers leak to the generated output all the time lloda: anyway i think the code where the error is printed isn't in the best position to decide how values should be printed. That should be delegated to the user who has to read them zzappie: ooh thank you this is what I was looking for zzappie: but truncation doesnt work in geiser for some reason lloda: There is an old bug for this https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29669 lloda: you can add that there zzappie lloda: likely it's bc of how geiser communicates with guile zzappie: only worked for (define tprint (lambda (repl obj) (truncated-print obj) (newline))) and then ,option print tprint zzappie: lloda: oh that was I just did yep :) define was redundant though dsmith-work: Morning Greetings, Guilers brendyyn: leoprikler: Do you consider it a bug that it just makes guile crash? brendyyn: Interesting. Chez crashes too but it says "out of memory" first. leoprikler: I'm not sure what Guile's OOM story is. leoprikler: the thing about OOM is that you can't guarantee you'll have enough memory for raising an error wingo: leoprikler: yeah it's a problem! rekado: leoprikler: perhaps the old sysadmin trick of reserving space (memory in this case) to be used for the OOM case is applicable here wingo: interesting idea. would have to be clever regarding mlock and such wingo: to make sure that freeing the memory would actually free some memory daviid: fleabag wingo: hm? :) daviid: sorry, wrong window... ArneBab: wingo: maybe creating the error at startup so it can still be given when nothing can be allocated anymore? flatwhatson: like keeping a pre-allocated sigstack around for segv handling chrislck: Monday greetings! dsmith-work: Monday Greetings, Guilers Noisytoot: wingo, By mlock do you mean ChanServ mlock, or something else? dsmith-work: Why does (myor1 #f) => #f but (myor2 #f) => () ? https://paste.debian.net/1194322/ dsmith-work: Guile is 3.0.4 ft: I think you want (apply myor2 (cdr args)) dsmith-work: Ahh dsmith-work: Indeed dsmith-work: ft: Thanks! RhodiumToad: (define (myor . args) (any identity args)) dsmith-work: RhodiumToad: Very nice hugo: Is there any Guile/Scheme game-dev channels on freenode? nebunez: hugo: #lispgames might be of interest to you zzappie: hugo: there is #lispgames lispmacs[work]: hi, I'm trying to remember what is the easiest way to generate a list of numbers in a range (0 .. n) lispmacs[work]: not that it would be hard to implement, but thought there might be an SRFI word for that or something lispmacs[work]: eh, well, just implemented it zzappie: lispmacs[work]: too late but there is (iota x)... :) lispmacs[work]: zzappie: thanks ft: lispmacs[work]: srfi-42 is the one you're looking for if iota is not good enough. lispmacs[work]: ft: thanks dsmith: sneek! dsmith: sneek: botsnack sneek: :) dsmith: goodbot dsmith: nckx: Thanks for the heads up. dsmith: sneek: later tell nckx Thanks for the heads up regarding the bot. sneek: Got it. lampilelo: sneek: later tell lampilelo foo sneek: Will do. lampilelo: foo sneek: Welcome back lampilelo, you have 1 message! sneek: lampilelo, lampilelo says: foo leoprikler: sneek tell lampilelo foo sneek: lampilelo, leoprikler says: foo lampilelo: didn't know about that command apteryx: is anything available in Guile as an alternative to shelling out to pgrep? leoprikler: you'd probably have to stitch it together using ffi calls civodul: or rather (scandir "/proc") :-) civodul: (guix scripts processes) has some stuff civodul: and (guix store roots) nckx: dsmith-work: Thank you for fixing it! chrislck: Small query about the schemified read() -- this slowdown is during compile only, right? if my code doesn't use eval, .go files will still be as lightning fast as ever? NathanSchmidt: Hello! I'm currently trying to figure out an error pertaining to the use of predicate checking in (ice-9 getopt-long). I'm using guile-2.2 on Debian 10. Currently getting a backtrace ending in "ERROR: Wrong type to apply: str->num?" whenever I run it with an option which does predicate checking (e.g. for --length-dmem 1024, but not with --help or NathanSchmidt: no options at all). The relevant part of my program is here: https://gitlab.com/schminak/tiny-machine/-/blob/master/tiny-machine.scm NathanSchmidt: According to the reference[0], "you may need to use quasiquotes to get it into grammar" pertaining to the predicate property. I'm not entirely sure of what that means. Perhaps that has something to do with it? NathanSchmidt: [0]https://www.gnu.org/software/guile/docs/docs-2.2/guile-ref/getopt_002dlong-Reference.html NathanSchmidt: The reference states that for (predicate func), func should be a function accepting a string and returning a bool - which it is. NathanSchmidt: (str->num? "42") returns '#t', for example. NathanSchmidt: Where str->num? is given as: NathanSchmidt: (define (str->num? s) (string-every char-set:digit s)) RhodiumToad: hm RhodiumToad: that sounds like it wants the actual procedure value to be in the form, not a symbol RhodiumToad: so the option-spec might need to be like RhodiumToad: `((help ...) (length-imem (value #t) (predicate ,str->num?)) ...) RhodiumToad: that would be what I'd try first, anyway NathanSchmidt: I've since tried that with the backtrace giving: NathanSchmidt: ERROR: Wrong type to apply: (unquote str->num?) NathanSchmidt: I do appreciate the suggestion, by the way. NathanSchmidt: I have come across something that leads me to believe the docs are inadequate. NathanSchmidt: http://wiki.call-cc.org/eggref/5/getopt-long NathanSchmidt: By using the docs for chicken, I have made progress, though I'm still working at getting the desired result from my program RhodiumToad: I don't get that error RhodiumToad: what exactly did you do? RhodiumToad: did you remember to change the ' to ` before the value? RhodiumToad: (because the error you got is the error you would get if you failed to do so) NathanSchmidt: I did not remember to change the ' to `. It is now working, it seems. NathanSchmidt: I greatly appreciate your help. Thank you. RhodiumToad: yw Zelphir: Hi! I have a question about organizing imports or modules. I often have modules in subdirectories and stuff. I see myself facing the following 3 ways of dealing with it: (1) add subdirectories to the load path when calling guile via the -L argument (2) adding the whole location of a module to its name, as in: (library (app lib mymodule) (export ...) (import ...)) or (define-module (app lib mymodule) ...) or (3) make use of (add-to-loadpath ...) Zelphir: stuff. Which one is the preferred way? Or is there yet another way? leoprikler: Zelphir, the preferred way is to have GUILE_LOAD_PATH point to the top of you module tree, e.g. /path/to/src/modules and construct load paths from there leoprikler: e.g. if you have /app/lib/mymodule.scm, you'd use that as (app lib mymodule) leoprikler: you may want to re-export stuff from (app lib mymodule) in a more top-level module leoprikler: for instance, in Tsukundere (a VN engine I'm developing), I use subdirectories for the implementation parts and export all functions, that should be publicly available from (tsukundere) leoprikler: (ice-9 peg) is also divided into parts, that are re-exported leoprikler: As are many things in the Guile source code itself. Zelphir: Ah, ok with re-export I could shorten that list of parts that identify a module. I will consider that in my case, thanks! Zelphir: I was also thinking about: "What if I need to move the module into another directory?" Then I would have to adapt the module identifying list again and all the places where I import it. But I guess that's normal? Like in any (most?) other languages, I would have to adapt at least the imports. leoprikler: Exactly, you need to rewrite your imports then. leoprikler: If lib is usable as its own outside the context of app, perhaps you should implement it separately (i.e. as (lib)), but other than that I see few issues Zelphir: Yep, that's what I try with fslib. Basically I don't want to have a copy in each project and then modify them all independently. If I can install them as dependency with guix, I should be able to reference it without adding manually to the load path or having a copy everywhere. leoprikler: Yep, you should go for a Guix package. leoprikler: Perhaps also provide an Automake setup for traditional distros if that's a concern. yoctocell: Is there a way to "apply" a macro? Let's say I had a list of booleans, and I wanted to "apply" the 'or' macro on the elements of the list. If 'or' was a procedure, I would do (apply or LIST-OF-BOOLS), but it is a macro so that won't work. lampilelo: yoctocell: (eval `(or ,@lst)) yoctocell: lampilelo: Works like a charm, Thank you! lampilelo: yoctocell: wait, what? i thought it was #emacs, this shouldn't work for guile, would work with primitive-eval lampilelo: people here don't take kindly to using eval, though chrislck: get the rope! lampilelo: last time i mentioned it someone added it to a ban list lampilelo: :D lampilelo: i think someone even mentioned "root of all evil" or something like that chrislck: eval is evil lampilelo: yoctocell: so the correct thing to do would be using "(any identity lst)" from srfi-1 lampilelo: because chrislck is watching Zelphir: :D *: chrislck stashes the rope now lampilelo: :D lampilelo: i think you meant "for now" Zelphir: You could also put ~or~ in a procedure and then apply the procedure using apply. Zelphir: Not sure this is entirely correct, but something like the following: Zelphir: (define myor Zelphir: (lambda (. args) Zelphir: (cond Zelphir: [(null? args) #f] Zelphir: [(car args) #t] Zelphir: [else Zelphir: (apply myor (cdr args))]))) chrislck: s/#t/=> identity Zelphir: Ah yes, that makes sense. You would not want to return only #t, if you got other things than booleans in that list of arguments. leoprikler: chrislck: What do you think about this use for eval? https://paste.gnome.org/p0ibmnjcf lampilelo: i think defmacro is also frowned upon :D leoprikler: This is Elisp. lampilelo: why? leoprikler: whynaut? lampilelo: idk, feels wrong to mix the two Zelphir: So it is Guile outputting Elisp? Zelphir: Or completely Elisp? lampilelo: it's elisp written for guile vm, it creates a binding to guile's define-peg-pattern so that it can be used from elisp lampilelo: guile can interpret elisp lampilelo: Zelphir: https://www.gnu.org/software/guile/manual/html_node/Other-Languages.html Zelphir: "Nil - A third boolean." -- That takes me back to database lectures :D leoprikler: Zelphir: It's Elisp evaling Scheme. leoprikler: @ is a real life-saver in our elisp bindings, it makes so many things possible rlb: (Also quite useful for clj dialects.) leoprikler: Is Clojure not a Scheme? Noisytoot: leoprikler, It's not a Scheme, but it is a Lisp leoprikler: Ahh, okay lampilelo: it's a scheme to close stuff rlb: It has a lot of similarities with Scheme, but among any number of other things, it's notably polymorphic by default (e.g. with respect to functions that operate on "sequences" rather than concrete types like vector, cons-pair, etc.). Also notable for being "persistent (immutable) by default", fwiw. wingo: here's a concept: $kfun whose clause is $kargs instead of $kclause. could denote a function that doesn't have to check number of incoming args wingo: could only be called via $callk, and requires caller to provide the right arity wingo: would be nice to unify with $kclause somehow such that body of $kclause could be one of these new $kfun's wingo: would allow eliding argument checks for calls within a compilation unit wingo: could allow some callees to avoid checking if stack space were available, if we had a red zone... rlb: Sounds interesting. Do we already support any kind of type-check elision? wingo: yes wingo: but only intra-procedural wingo: there is "global" (i.e. across basic blocks) type analysis wingo: can elide redundant type checks wingo: redundant == type check A dominates type check A' wingo: but interprocedural, there's nothing rlb: Ahh, ok. If it were feasible, I suppose interprocedural could give another advantage to scheme code over C implementations... cheim0: davexunit: for the multisampling capability check in chickadee, I'm gonna focus on adding a binding for SDL_GL_ExtensionSupported to guile-sdl2 Zelphir: https://www.gnu.org/software/guile/manual/html_node/Other-Languages.html Couldn't that "python-on-guile" be added there? leoprikler: sneek later tell Zelphir the manual only talks about languages implemented in Guile itself, not third party projects sneek: Okay. brendyyn: guile -c '(expt 2 999999999999999999)' segfaults and crashes guile for me. brendyyn: Would have thought it would just tried for ages or error somehow at least if its too big cybersyn: hiya guilers, i've been programming in racket for about a year, and started using guix in the fall, and through this realized I prefer guile, due to the built in ,apropos documentation, as well as the realization that the many amazing languages in racket tend to be different enough that they don't associate well with others. tons of great stuff there, but guix has become more important for me. so now its time to properly learn guile! cybersyn: (until now I've mostly figured it out as I go along). cybersyn: any suggested guile roadmap? cybersyn: also, while i did a first "tourist" pass of SICP over a couple months last year, i've started working more seriously on it and lockywolf's wonderful study of it has inspired me to get more focused. has anyone added implemented srfi-216 in guile? lampilelo: cybersyn: the one thing i would suggest is reading guile's info manual if you haven't done it already cybersyn: i've read up to the section with C, but after that it seems to take on a more reference manual form. i'm wondering if there is anything that gives more of tour of the culture (interesting ways people customize their .guile, and stuff like this), the ecosystem, things to be weary of, and the like leoprikler: sneek, later tell brendyyn the hard limit seems to be (expt 2 (expt 2 28)) and likely has to do with the amount of continuous memory you'd need to allocate for that sneek: Will do. zzappie: hey guilers! zzappie: Anyone has a link to a completed guile beginner tutorial? zzappie: want to share with my friend but only found half completed tutorials leoprikler: What would that look like (as opposed to a crash course on Scheme)? zzappie: leoprikler: which crashcourse you are refering to? leoprikler: for instance Guix' crash course on Scheme leoprikler: which you can find in the cookbook iirc zzappie: ah forgot about that one! leoprikler: Is that me or does the language reference for elisp choke on keywords? leoprikler: s/reference/spec nckx: dsmith-work: People are clamouring for sneek! Just in case you were unaware and not at w--oh. leoprikler: Is it possible to use Guile syntax transformers from Elisp? rlb: wingo: thanks regarding the general priorities. manumanumanu: I'm running the r7rs benchmarks just to compare 3.0.1 and 3.0.5. What happened with the tak benchmarks? :P manumanumanu: 2x-2.5x faster manumanumanu: ah what times to be alive! manumanumanu: let me try that again: what a time to be alive! manumanumanu: never mind. benchmarking is hard. Still faster, but nothing that dramatic. lampilelo: now let's implement io_uring interface for guile to have even faster io! mwette: here is the nyacc .ffi file for liburing: https://paste.debian.net/1194100/ lampilelo: i mean in the core as a backend for ports lampilelo: mwette: that's the first time i hear of nyacc civodul: mwette: impressive, again! manumanumanu: mwette: what is going on there? lampilelo: so it's a lalr(1) parser with a c parser implementation and a helper for generating bindings from c to guile? manumanumanu: nyacc is a lot more than that :) But that is indeed what seems to be going on. lampilelo: or is it a wrapper around bison? mwette: The ffi-helper will read include files and generate guile code using the guile's ffi front end and guile bytestructures. It's sort of a "get me started" approach to working with C libraries. mwette: Within nyacc, one generated the file posted and then executes "guild compile-ffi ffi/liburing.ffi". That generates a guile .scm file, 926 lines in this case. mwette: see output here: https://paste.debian.net/1194105/ lampilelo: nice, is it stable? lampilelo: ah, it's 5 years old already mwette: nyacc is lalr written in scheme from ground up, based on algorithms in the dragon book mwette: It uses a C parser (which parses comments, too) and then expands typedefs as necessary to provide SXML representations of the C declarations. Once that is done it converts the declarations to ffi interface code. mwette: The ffi-helper supports "use-ffi-module". For example, (ffi gobject) uses (ffi glib), ... and (ffi gtk+) uses (ffi gobject) (ffi pango) (ffi gdk) ... lampilelo: now i wonder how does it compare with swig lampilelo: afaik swig generates c code, doesn't use guile's dynamic ffi mwette: I think so. But I don't know how much work you have to put into a config file for swig. mwette: Oh. It looks like the ffi-helper failed on converting unions altogether. Not gonna work for liburing right now. mwette: The anonymous unions at least. lampilelo: try parsing c++ next :D mwette: haha. Not with a lalr parser. leoprikler: Do a peg parser then :P mwette: thought of it mwette: I have also thought of converting lalr to use CPS for parse and lex functions. pkill9: maybe there's a similarity between concepts of symbols in lisp, and the concept of words being actions, or maybe i'm just overhitnking pkill9: overthinking* *: wingo has a design for faster inter-module calls, whee tohoyn: sneek: botsnack sneek: :) dsmith-work: Happy Friday, Guilers!! dsmith-work: !uptime sneek: up 5 days, 20 hours, 27 minutes rlb: wingo: vague question (and "it depends") I know, but do you have any strong inclinations wrt string processing by making an extra pass so you can do a single precise allocation of the result (or final precursor of the result) vs using a stack buffer for the common, smaller case and realloc doubling when necessary? rlb: (Of course sometimes it's clearer, i.e. when it might be expensive to compute the result chars (e.g. string-map, string-tabulate).) rlb: If not, no worries, just wanted to keep any inclinations in mind. manumanumanu: So... I just found myself sorting a million bytes, and finally got to write a counting sort. It ended up being about 30x faster than regular sort :) manumanumanu: with expected benefits being much larger when I use actual data, which might be much larger. p0a: Hello p0a: I am a newcomer to Guile, I curious if it is possible to create a secure sandbox in it, with a set of functions that the user can use. p0a: I think this is related to `bindings', is that what allows this? dsmith-work: p0a: Ya, there are ways to start with an environment that has little or no bindings, and then you can add what you want. I've never messsed with that though. dsmith-work: p0a https://www.gnu.org/software/guile/manual/html_node/Sandboxed-Evaluation.html p0a: dsmith-work: before I read about the sandboxing, I should know what bindings are p0a: dsmith-work: do you know where I can read on the prerequisites? I know lisp but it's been a while dsmith-work: Well, A "binding" is basically having a name for a value you can use it. p0a: so a binding is an entry in the symbol table under the scope -- or however that is expressed? dsmith-work: s/value you/value so you/ p0a: are there predefined sets of bindings that are reasonable for safe evaluation? such as immutable/functional subsets of Guile p0a: I want the user to be able to do (+ 1 2) but I don't want to miss out on any math functions, or otherwise, that the user might need dsmith-work: p0a: That pages lists quite a few. p0a: `composite sets', got it! thanks. I looked at the page but did not understand it on a first read p0a: One more question: the API will include interactions with a DB. I don't want a time limit on certain bindings. Is that possible? p0a: (I'd prefer if the DB API timed out instead of Guile bluntly shutting down the computation) dsmith-work: p0a: Not sure. Never used that. But I would think you could adjust the sandbox timeout to be longer than your db timeout. p0a: dsmith-work: the problem would be if that info is not known to me p0a: or if I don't want other operations to have a long time-out, except for the db API... oh well p0a: That's not so important, thanks dsmith-work: I wonder if you could set a "none" timeout. Or maybe just a really long one. p0a: the server won't DDOS right? p0a: I'm guessing not. It really is a server for 1 user in my case. Or maybe 2-3, that's about it. I can't imagine several users using it wingo: rlb: no strong inclination. i guess if i had to say something it would be these priorities in descending order -- 1. avoiding buffer overflows / memory issues 2. simplicity 3. speed apteryx: Is it possible to forward declare a definition in a module? apteryx: so that it can be used before its actual definition lampilelo: apteryx: if it's not used before it's defined when you run the code it doesn't matter where you put the definition, you'll get warnings on compilation, but the code will work regardless apteryx: yeah, I'm trying to use it before it's defined lampilelo: in the runtime? apteryx: It's a huge sexp blob containing test data, I'd rather 'hide' it at the bottom of the module apteryx: ah, it's even used by syntax, so I guess there's no way around it lampilelo: you can always put it in a separate file and load it at the top of your module apteryx: true, although that doesn't seem to have been used in the code base so far. thanks for the ideas. apteryx: any pattern to load a module relative to the current module? apteryx: or not even a module but a source file containing the definition manumanumanu: (load "...")? manumanumanu: or (include ...) manumanumanu: include being the better choice. apteryx: manumanumanu: OK! And these will work no matter the CWD (e.g., they are relative to the source file it's run from?) manumanumanu: yes. manumanumanu: i believe so. p0a: no wait a moment p0a: I think it's relative to whatever the user has set up right? Before running the source file p0a: "If file-name is a relative path, it is searched for relative to the path that contains the file that the include form appears in. ", okay you are correct, sorry apteryx: thanks! dsmith-work: UGT Greetings, Guilers everstone: How can I use a list of arguments as arguments instead of as a the list it is? I'm trying to do: (format %my-list) zzappie: everstone: you can (apply format %my-list) everstone: zzappie: thank you! zzappie: also one thing I didn't know for a long time is that ((lambda x x) 'wrapped) will result in (wrapped), this way you can ignore arity of which is sometimes handy lampilelo: zzappie: can you give an example? ((lambda x x) 'foo) is functionally equivalent to (list 'foo) zzappie: lampilelo: I meant that I always wrote (lambda (args) body) and didnt know you can (lambda arglist body). There are times for example you need a function that accepts any number arguments so you can use this for for that, or even show that you dismiss args entirely and write (lambda _ body) *: zzappie *use this form for... lampilelo: ah, ok, it wasn't clear to me what you wanted to say yoctocell: Is there a way to split a string based on a string predicate? e.g. I want "AdelimBdelimCdelim" => '("A" "B" "C"), `string-split' only accepts a character predicate. dsmith-work: yoctocell: https://www.gnu.org/software/guile/manual/html_node/List_002fString-Conversion.html#index-string_002dsplit `char_pred` can be a char, a char-set, or a predicate procedure. dsmith-work: Ah yoctocell: dsmith-work: Ah, ok, thanks! dsmith-work: yoctocell: Unfortunately, that pred gets passed only one char at a time. And from back to front too. yoctocell: dsmith-work: I don't think that will be a problem, I can just filter out the empty strings. everstone: I'm really liking this first introduction to lisp so far! To be told syntax is illegal eventho I see it used in the sourcecode is annoying, but it encourages me to be creative :^) dsmith-work: Anyone know of any cheap (think rpi) ppc/ppc64 systems/boards? wingo: rlb: i think some degree of increased GC allocation is acceptable. sometimes it even makes things faster. and in future we'll probably have a generational gc which will make short-lived allocations even cheaper wingo: so, something to worry about, but not like a deciding factor to choose between different implementations dsmith-work: Wednesday Greetings, Guilers everstone: I sidestepped my issue from earlier via a translation table manumanumanu: why is the write-line that was just documented in a recent commit so badly named? :P wingo: would rather deprecate it tbh manumanumanu: seems like a decent idea. write-line uses display semantics :'( dsmith-work: Probably a mental echo of someting from a camelbacked language with impoverished identifiers. wingo: well racket has println wingo: or something like that, right? wingo: i mean the idea of "print this then make a newline" is not so uncomment wingo: omg wingo: uncommon manumanumanu: wingo: displayln *: wingo has working cross-module inlining, whee civodul: oh! wingo: is in wip-inlinable-exports wingo: some work remaining to do tho wingo: like, actually benchmark it :P wingo: & figure out what user expectations are wingo: but would allow us to make more first-class definitions across a module boundary without define-inlinable wingo: seems to compile guile fine & pass test suites, but guile's code is biased in that we know that modules are optimization boundaries and code around it wingo: ok zzz wingo: night :) rlb: wingo: thanks - I've ended up pursuing variants, e.g. sometimes preallocating a utf-32 array up front, populating that, traversing it to compute the final utf-8 size, allocating that sized string, and then filling it in via memcpy (e.g. string-tabulate), or using a dynamically resized (doubling as needed) array for either utf-32 or utf-8, and copying that to a properly-sized, indexed utf-8 string at the end. In the latter case, it rlb: starts optimistically with a stack buffer (currently 1024) so it only needs scm_gc_malloc_pointerless resizing when that's insufficient. rlb: (e.g. string-map, unfold, etc.) rlb: We could of course do the same thing(s) somewhat less efficiently in scheme by accumulating a list of fragments (possibly reversing it) and then (apply string-append items)... civodul: wingo: it looks like "dynamically-created" modules like https://git.savannah.gnu.org/cgit/guix.git/tree/gnu.scm#n40 don't play well with the new re-exports wingo: there are a few bugs regarding re-exports civodul: in this case, if you have a file that just does (use-modules (gnu)) (pk delete), it fails with "delete: unbound variable" civodul: where 'delete' is reexported by (gnu services) wingo: ! wingo: is (gnu) dynamically created? wingo: which module is dynamically created, here? civodul: (gnu) civodul: well, it's populated by calls to module-use! at run time civodul: and i think that's what causing troubles civodul: the (module-use! i (resolve-interface m)) bit above wingo: i guess this is related to daviid's issue nly: hi dsmith-work: Morning Greetings, Guilers kaletaa: hello - is there a way to retrieve the current module on the C side? sneek: kaletaa, you have 3 messages! sneek: kaletaa, mark_weaver says: run "guix package -i" as your normal user, not root. sneek: kaletaa, mark_weaver says: "guix package -i" installs the programs in the profile of whatever user ran that command sneek: kaletaa, mark_weaver says: to install packages in the "global" environment, which is only possible in GuixSD, add them to the 'packages' field of your OS configuration and re-run "guix system reconfigure ..." civodul: sneek: seen mark_weaver sneek: I think I remember mark_weaver in (here?) 3 months ago, saying: :). rlb: wingo: regarding re-exports, I ended up adding this https://git.sr.ht/~rlb/lokke/tree/main/item/mod/lokke/compat.scm to silence some warnings. rlb: since I couldn't re-export-and-replace in the define-module form. leoprikler: kaletaa: scm_current_module kaletaa: thanks kaletaa: not sure how i missed that, my bad rlb: wingo: I'm somewhat wondering about our current perf and/or bootstrapping expectations, i.e. there are some string functions that might be simpler (and safer) in scheme, and with utf-8, some of the perf advantages in C are gone, i.e. no *O(1)* string-set! and, we might end up needing to allocate a temp vector anyway (say in string-map). Though I suppose we still have no way (yet) to avoid/elide a lot of redundant type checking from the rlb: scheme side, and there might still be "more" garbage generated, even with some suitably crafted helpers. dsmith-work: I just saw an annoucement for powerpc64le-linux guix. Does the guile jit support that now? civodul: dsmith-work: not yet, and apparently it feels slow on that platform civodul: t'just a matter of writing the lightening backend :-) dsmith-work: Yes, the SMOP.. iv-so: afaik guile does not use gnu libjit, is there any particular reason? opfez: hey does anyone know if it's possible to get the terminal size dimensions in guile? opfez: can't find anything in the manual on it wingo: iv-so: dependency size and churn rate. i am sure you could get better codegen using an external jit library, but i don't have the bandwidth for the maintenance costs wingo: also, a desire to do AOT from scheme at some point dsmith-work: opfez: You could check to see if COLUMNS and LINES are set in the environment. dsmith-work: the resize program can set those. (is in the Debian xterm package) opfez: dsmith-work: oh, as shell environment variables? dsmith-work: I think it does some cursor movement and then reads back values. dsmith-work: opfez: Yes. Though to set the values, your shell must eval the output. ft: If the program is long running, a resizing terminal may pose problems with that approach. ft: In those cases, maybe guile-ncurses can help. dsmith-work: And there you would need to handle SIGWINCH opfez: ft: it's just for a tiny program ft: Indeed ft: Ah okay. opfez: the best would be a wrapper function for ioctl() so i could just get the info from there, isn't there anything like that in guile? opfez: but i'll try the env vars first dsmith-work: opfez: Note that they might not be set. opfez: dsmith-work: hey, they were! i can at least use this temporarily and find a more portable solution later, thanks! opfez: gtg,thanks again dsmith-work: opfez: Cool. glad to help dsmith-work: I very often use a serial console on some embedded device, usually from some (x)term through ser2net, and screen dimentions are always wrong. Unless I use something like resize. dsmith: !uptime sneek: up 1 day, 5 hours, 17 minutes everstone: How do I evaluate escapes? I have (string-append "\\x" %hex-string) rlb: wingo: is it feasible/sensible to replace C functions (say in srfi-13) with scheme functions, and/or how would that work? Some of them in my experiment, like string-tabulate, might be just about as efficient in scheme, but if so, would I put them in srfi-13.scm, or would they have to go in boot-9.scm or...? rlb: (Hmm, or maybe that's a bad example, maybe I can make it faster in C (we'll see).) wingo: rlb: yes it is certainly feasible and desirable!! wingo: decreasing the amount of C is a high priority goal imo, so that rewriting the GC is easier lemzwerg: [I'm new to freenode – not sure whether my previous message came through, thus repeating.] On the homepage of guile there is a list of applications that use guile. I suggest to add GNU LilyPond. wingo: hi! i think lilypond is there at https://www.gnu.org/software/guile/libraries/#apps, can you check ? lemzwerg: It is, thanks.  Then I suggest that you add a small line at the bottom of the 'Applications using Guile' section that  links to this list. lemzwerg: Of course, LilyPond is *not* a library, so the title of the link is misleading. g0d_shatter: hey all, curious if anyone knows what the status of guile-ncurses is? last release was a couple of years ago, does it work with guile-3 yet? or even worth using? lemzwerg: Regarding the https://www.gnu.org/software/guile/libraries/#apps link: The '#apps' tag doesn't exist. wingo: lemzwerg: if you send a mail to bug-guile@gnu.org with a description of the bug, that will make a ticket in our tracker wingo: which will be dealt with eventually. not always timely on these things but at least it will get done lemzwerg: @wingo: Done! wingo: tx :-) wingo: janneke: hey. can you remind me what the mingw64 status is janneke: wingo: i believe spk121 reviewed my wip-mingw branch and found all commits except two OK (please verify!) janneke: those two were the 64bit mingw and the fix for the absolute-file-name cross-compilation bug janneke: last thing i know was spk121 did an experiment to introduce a hash type and he said something like "i learned a lot" ... wingo: hehe janneke: so, i forgot whether it's a viable path and needs more, or not... wingo: janneke: just reviewed the first 9 patches on gitlab. the ones without comments lgtm wingo: (i hope the branch was up to date!) janneke: wingo: it is, thanks! janneke: so, feel free to push, but possibly align with spk121? wingo: feel free to push any of the first 9 patches that have no comments :) wingo: comments on the gitlab i mean janneke: eh wait, do i have push access? *: wingo checks sv wingo: you do now :) plz do ping on irc before pushing patches wingo: janneke: also feel free to use wip branches in the main repo janneke: wingo: that's great, sure; so OK to push up to the first DRAFT commit, right? wingo: janneke: there are comments on a number of those commits, right? janneke: ah, right -- now i git what you wrote -- any that have no comment wingo: :) *: janneke goes to push 7 commits to master, and create a new wip-mingw wingo: janneke: there are only 3 that don't have comments, right? janneke: oh my, /me goes to re-check *: janneke push a re-sorted wip-mingw janneke: *pushed janneke: wingo: hmm...on the new wip-mingw, there are no comments on the commits below janneke: f1d2460252 Add `scm_sigaction_for_thread' stub for MinGW. ? *: janneke breaks for lunch and will wait for full alignment here ;) wingo: you don't see one on https://gitlab.com/janneke/guile/-/commit/34cbe4eedcbab317b3fbbf127493e1b82a64ee9a ? wingo: if your commits get renumbered because of a rebase or whatever, you will lose gitlab comments; if you want persistent comments, make a PR janneke: wingo: ah, comments on gitlab! right...i didn't see those, sorry -- never worked with gitlab comments *: janneke was thinking/guessing: a remark in the commit message before the actual change log janneke: wingo: check, 3 commits "Document write-line.", "ice-9 ftw: Use 'absolute-file-name?' in 'nftw'.", and "Compile fix for x86_64-MinGW." ready to push janneke: i'll look into your remarks (thanks!) to push the other commits forward wingo: great! & tx for patches :-) wingo: perhaps you can hoodwink lloda into doing a gnulib update at the same revision, but adding the gethostname module :) janneke: yw, and thanks for the hand-holding :-) janneke: ah great -- i'll be checking if gethostname import fixes it apteryx: Any idea of how we can use parameterize as part as a syntax-case? This naive try doesn't have an effect: https://paste.debian.net/1193328/ apteryx: as part of* wingo: you want syntax parameters wingo: https://www.gnu.org/software/guile/manual/html_node/Syntax-Parameters.html apteryx: hey, thanks! I'll try it. dsmith-work: Hey Hi Howdy, Guilers apteryx: wingo: I tried, but I'm getting a syntax error (the same I had when trying with plain parameters, so probably unrelated): https://paste.debian.net/1193356/. wingo: perplexing apteryx: a more minimal example: https://paste.debian.net/1193363/ apteryx: I don't get what it doesn't like about the body, which *is* an expression, AFAICT. wingo: is it an expression? looks like a definition wingo: depends on the result of the expansion of define-configuration wingo: anyway, i think that is probably a bug in the expander. wingo: your code looked good to me fwiw. if you wanted to hack around it you could (syntax-parameterize ((...)) my-thing #t) wingo: though i wonder if it would treat those as local definitions... humm apteryx: the define-configuration called without the 'without-serialization item should expand to a (begin ...) that does a bunch of definitions apteryx: I'll try your suggestion, thank you :-) apteryx: it seems to get me passed this block! apteryx: although the syntax-parameterized %with-serialization value doesn't seem to stick in the final syntax; https://paste.debian.net/1193369/; It still generates serializer fields set to some (inexistant) procedure names. apteryx: anyway, I'll strip that 'without-serialization syntax sugar for now; it can at least work when using teh global plain parameter and a single case in define-configuration. Thanks for your help! apteryx: it works as long as its used as a global variable more than a parameter raghavgururajan: civodul: sneek is drunk. It delivered that last message too late. xD raghavgururajan: That too in a wrong channel. hmm. rlb: wingo: so say you have sparsely indexed utf-8strings, but (internally) for an operation you want to traverse the string to the end anyway, and you know how many *chars* it has, so you'd like yo avoid the cost of "finding the end, byte-wise". But u8_mbtoucr() requires you to specify how many valid bytes are remaining. So you either have to pay the cost, or lie to it, which seems questionable? rlb: (The cost of finding the end shouldn't be all that high, given the index, so could just accept it,but it's not *completely* trivial.) rlb: wingo: hmm, maybe in situations where it's OK to assume the string is valid, u8_next() might be plausible, i.e. even when the string's not null terminated, if we know that there's at least one more character. manumanumanu: rlb: there is a SRFI you might be interested in that has an implementation of immutable strings that has O(n)-ish access, but using bytevectors as a backend for efficient storage. manumanumanu: is it immutable texts? manumanumanu: I can't remember manumanumanu: it is based around the idea of string cursors and byte chunks of something like 128 bytes stis: Tja guilers! rlb: manumanumanu: right, thanks, I've seen it if it's the "texts" srfi, and iirc I'm toying with something not unrelated. rlb: Should a hypothetical scm_c_put_utf8_chars(const uint8_t *u8, ...) require the char_count, byte count, or both? yoctocell: Hi, I am trying to convert a bytevector to a string using 'utf-8->string', but I am getting an error: Throw to key `decoding-error' with args `("scm_from_utf8_stringn" "input locale conversion error" 0 #vu8(1 88 97 227 44 138 231 228 132 202 66 51 172 245 9 153 162 251 92 121))'. rlb: yoctocell: offhand, I'd guess the argument might not be valid utf-8. yoctocell: Never mind, I had to use 'bytevector->base16-string' from (guix base16), I was playing around with (guix openpgp). yoctocell: rlb: I don't really know much about utf-8, but thanks anyways :) rlb: certainly wingo: heyo rlb: wingo: should a hypothetical scm_c_put_utf8_chars(const uint8_t *utf8, ...) require the char_count, byte count, or both (if you have any firm opinion, offhand). And should it trust the content, or insist on trying to verify it? wingo: no real firm opinion. if we go by e.g. scm_from_utf8_string vs scm_from_utf8_stringn, there should be a "n" variant that takes a byte count wingo: i guess verification is cheap, right? if someone wanted to skip verification they could use a byte interface wingo: though i guess you don't get transcoding in that case rlb: depends? I mean it's a full extra pass over the string, one code-point at a time. wingo: right but what's the ns/byte for verification rlb: But of course I think you *can* make it very fast (even going as far as sse/avx/whatever if you like). But still more than doing nothing. wingo: right but compared to whatever the port is going to do, probably it's lost in the noise. dunno rlb: Part of the question here is related to internal vs external clients -- i.e. if the bytes are coming from a *string*, we know they're valid. But in other cases, I'm wondering how careful our api intends to be. *: wingo nod rlb: (Also in the case of internal uses, getting the byte_n is a bit more expensive, since we have to indirect through the index.) rlb: So possibly worth avoiding when we can. wingo: ah yeah indeed rlb: i.e. when we know we're going to have to traverse the string at least once anyway. rlb: (as part of the work) rlb: But on other cases, we can memcpy, if we know the byte_n, etc. rlb: Anyway, not critical, just wondered. rlb: (And can always have scm_c_put... anc scm_i_c_put... or whatever if we decide it's warranted.) wingo: whee https://wingolog.org/archives/2021/04/11/guiles-reader-in-guile ft: \o/ civodul: wingo: yay! lampilelo: oh, cool ArneBab: wingo: nice! Thank you for accompanying your great hacking with great writing! zzappie: great article! Does it mean that we are on the way to edebug style debugger? zzappie: wien it possible to retrieve source locations zzappie: *when *: zzappie zzz civodul: janneke: interesting civodul: i don't think Guix has troubles with it civodul: but it means there's an allocation going on? how can it be? leoprikler: There are only two build systems worth using in 2021: Autotools and GWL :) rekado: even I don’t use GWL as a build system … yet ;) iv-so: gwl? morganw: This, I think: https://www.guixwl.org/manual/gwl.pdf iv-so: oh, so it's a build system morganw: probably more a "process orchestrator" leoprikler: if GWL is a process orchestrator, then make is not even a scheduler everstone: How do I split a string on newlines? (string-split "foo:bar baz" #\:) works for colon, but guile says #\\n is wrong daviid: everstone: try #\newline everstone: daviid: Thank you, that worked! janneke: sneek: if you think this https://paste.debian.net/1193016/ is interesting then let me ping wingo ;) should i mail to bug-guile? sneek: Okay. janneke: sneek: botsnack sneek: :) lampilelo: i thought it was supposed to do it the new way because afaik inner defines are implemented in terms of letrec inside a function block, i didn't realize it was different before lampilelo: the info manual explains it that way, so i guess it's intentional (?) rekado: iv-so: the GWL is a workflow language extension for Guix. The intended audience is scientists who want to run reproducible computer-aided experiments in HPC environments. iv-so: too abstract explanation rekado: iv-so: if you prefer a video: https://fosdem.org/2021/schedule/event/guix_workflow/ rekado: there’s also a tutorial here: https://guixwl.org/tutorial iv-so: nah, I am fine with build system rekado: yeah, it’s not a build system iv-so: saw tutorial but understood nothing rekado: if you are not a scientist the GWL probably isn’t for you. rekado: not that it’s too complicated to use, just that you don’t have the kinds of problems that the GWL attempts to solve. iv-so: I played with this "reproducible research" thing a bit, but performance of emacs, org and giant postgres together killed all the fun and usefulness rekado: postgres? gagbo[m]: I wonder why pg as well tohoyn: sneek, botsnack sneek: :) iv-so: I was to investigate the reason why some rows in our DB were corrupted and fix them leoprikler: sounds not very reproducible to me janneke: lampilelo: ah yes, i forgot about that change *: janneke wasn't so thrilled of allowing duplicate identifiers there, but hey roptat: how can I prompt the user from a guile script? roptat: ha simply (read) mwette: roptat: or (use-modules (ice-9 readline)) (readline "$ ") mwette: [maybe requires (activate-readline)] -- see "Readline Support" section in the manual rlb: Anyone happen to know if we still need the lower(upper(x))? https://lists.nongnu.org/archive/html/guile-devel/2011-03/msg00111.html rlb: oh, wait, there's more in the thread. rlb: Right, looks like I can drop the extra call. rlb: Or maybe not - i.e. I think maybe that was saying that we could drop the extra call if we lowercased entire strings via libunistring and they were both the same encoding (here utf-8), in a call like compare_strings(). i.e. if we're still going char-by-char (for now), we might need the lower/upper. rlb: how do we pull in another gnulib function? i.e. I think I might want memcmp2 wingo: o/ stis: \o wingo: civodul: apparently glib uses gnulib under a meson build system https://gitlab.gnome.org/GNOME/glib/blob/d6092086558515ed6fa195b156cb9bdacc809f16/glib/gnulib/meson.build wingo: dunno how that works tho civodul: hi! civodul: wingo: i guess they maintain it themselves? wingo: yeah maybe wingo: probably they don't update often from upstream. not sure how gnulib would work without autotools civodul: BTW, Guix does not remove .la files (yet) civodul: probably poorly wingo: ah ok, i thought it did wingo: i guess guile transitively depends on python already for its build :P wingo: re: meson civodul: .la files are mostly useful for static linking since they tell the extra -l flags *: wingo not actively investigating this fwiw, just thinking about it civodul: are you saying you'd like to switch to Meson? civodul: ah ok wingo: i was just thinking, we could do autotools without libtool, but autoconf + libtool + automake kinda hang all together wingo: ~~synergy~~ wingo: so if you want to take libtool away, replacing the whole thing starts to become maybe interesting wingo: dunno wingo: sounds like hell civodul: yes, sounds like that :-) civodul: we could do without libtool, but that means doing the LD_LIBRARY_PATH dance, -rpath, relinking, and all that by ourselves wingo: yeah honestly i would think that probably you and guix folks have the most informed opinions about what would be a good idea wingo: & maybe staying with autotools is the least bad idea, dunno wingo: but, we already have to do a lot of workarounds via meta/uninstalled-env.in etc civodul: the rpath + relinking thing is striking: i think all build systems other than autotools get it wrong civodul: in Guix we have workarounds/tweaks for CMake and Meson, for sure civodul: CMake is the worst civodul: for Meson, we explicitly pass -Wl,-rpath because apparently it won't do it otherwise civodul: that trick works because we're building in a chroot, but if you did that with -Wl,-rpath=/usr/local/lib, you'd end up running the previously-installed code instead of the one you're building leoprikler: As someone who uses Guile+meson, I can't say I recommend it. With Guile+Autotools, I can put everything into one Makefile.am. Meson currently doesn't have such capabilities. lampilelo: for snarfing you have to use external command because there's no other way to obtain cflags directly in meson wingo: my ardour for action is cooling, fwiw :) terpri_: i can't even *build* bazel on guix. cmake's documentation seems very minimal and i end up spending far too much time finding a magic incantation to change some simple option. autotools have their problems, no doubt, but i've never found an alternative i prefer terpri_: redo & co. sound interesting on paper, but they're only 'make' alternatives terpri_: (i wonder how much of autotools's flexibility/longevity comes from being designed to build things automagically on random *nix systems...cf. systems like imake which iirc relied on a central database of system information) lampilelo: i guess there is a workaround for snarfing in meson because you can write modules, so you could probably access cflags from dependency objects or something, they're not exposed by default though lampilelo: my take on autotools, as a new user, is that they're hard to learn, the documentation is all over the place lampilelo: i use them for my new project because i thought it would be fun to learn, but no, it's not particularly fun lampilelo: but i have to agree, enabling and disabling features when you want to compile is super easy when everything is set up right leoprikler: I personally feel, that Guile's autotools integration could be better. leoprikler: People currently have to write their own .scm.go suffix rules and the way SOURCES are sometimes declared as merely "SOURCES" is also discouraging terpri_: meson looks fairly reasonable, just skimming their site, though i'd prefer not to have python etc. be fundamental dependencies for building things (which is probably a fringe preference) leoprikler: OTOH a guile module for meson would probably work better to get more users on board terpri_: and tbf some of autotools's advantage is probably from "tradition" (refined over decades) and doing something complicated might require knowledge of m4 and shell and make leoprikler: Yeah, autotools very much assumes you're at least familiar with shell and make. civodul: terpri_: the actual cmake documentation is non-free (a book) morganw: It is likely a biased source, but the Autotools book from 2019 states that adding new language support to Autotools is actually not too hard. And I imagine the existing support for Elisp probably has a similar compilation model to .go files. morganw: (I bought the book because I agree that knowing where to start with Autotools is difficult) terpri_: civodul, ah, that would explain why the official online docs seem so sparse :) epony: like the emacs manual page.. a bit lacking leoprikler: adding language support to autotools is really not hard, it's mostly just adding one suffix rule and you're done leoprikler: well, it depends on how hard the language makes it, I don't think the complicated entity, that is rust, can fully be described within a suffix rule, but you get my point :P civodul: terpri_: i know that because at work they regularly buy copies of that thing *sigh* rekado_: “regularly”? Oh my. lloda: wingo, civodul: ok to merge wip-gnulib-update? civodul: rekado: yes, because the copies unavoidably get lost in some drawer civodul: lloda: i'll defer to wingo :-) wingo: lloda: lgtm :) lloda: thnx, pushed roptat: hi! how do I use guile-cairo? I tried to create a surface with (cairo-image-surface-create 'CAIRO_FORMAT_ARGB32 100 100), but I get `(#f "Unknown enumerated value: ~S" (CAIRO_FORMAT_ARGB32) ())'. The manual doesn't seem to explain how to get a cairo-format-t rekado: I only have an example of generating a PDF file with guile-cairo here: https://git.elephly.net/gitweb.cgi?p=software/guile-picture-language.git;a=blob;f=pict.scm;h=b853c47d6302a4034dfea74487f850328455cb3d;hb=HEAD#l160 roptat: ha! 'argb32 roptat: thanks a lot :) rekado: guile-cairo/guile-cairo-enum-types.c gives you the mapping dsmith-work: Happy Friday, Guilers!! leoprikler: is it intended, that define* exists even without (ice-9 optargs)? Noisytoot: WHy is ice-9 called ice-9? dsmith-work: sneek: ice-9? sneek: ice-9 is "a nod to the fictional substance in Kurt Vonnegut's novel, Cat's Cradle, capable of acting as a seed crystal to crystallize the mass of software" dsmith-work: Noisytoot: ^^ rlb: I've gotten the impression that a lot of things may not handle cross compilation (and bootstrapping) nearly as well as autotools, if at all. Though that's more important for "closer to root" dependencies like gcc. Python, and guile to a lesser extent atm, also already present a common interface to some of the things autotools detects, and could provide more, i.e. endianness, type sizes, etc. civodul: "guild compile" has a --target switch dsmith-work: I had to cross-compile Python by hand for some embedded stuff. Was tedious. Thankfully, buildroot eventually added Python. ArneBab: are we actually trying to get rid of autotools? From all the runs through build systems I did since 2000, autotools was the only one that sufficed. Everthing else was worse — including cmake, scons, waf, the numpy-setup-hacks, and pip. ArneBab: oh, and maven and gradle and npm ArneBab: (though those actually do a bit more that is useless to guix users) ArneBab: Nowadays I think that the right way to provide a build system is to auto-generate a working autotools-setup with a init tool. janneke: pure-funcq on an inner function does not work with guile-3, is that expected? ArneBab: Sadly I’m too slow at pushing conf forward, which does that, but currently only for bash, python (though opinionated), latex, org-mode, and naturally wisp: https://hg.sr.ht/~arnebab/conf janneke: yeah, inner functions get a new address -- https://paste.debian.net/1193016/ janneke: bummer janneke: civodul: u sure we don't suffer from this in guix? *: janneke hasn't looked, but knows guix does some fancy memoizations leoprikler: and before you ask, yes, I did functional programming in m4 leoprikler: In about three years, the company I worked at will discover it and whoever happens to do read the code at that time will reach enlightenment. leoprikler: Or they'll curse me. Probably the latter. *: zzappie imagines "M4 functional programming" O'Reilly book cover dsmith: leoprikler: The "base case" for recursion was kinda funky, iirc. dsmith: At one time I was using some freebie Mororola supplied assemblers, with no macros. m4 filled in nicely! morganw: I recently m4'd a GitHub Actions config and would do it again (whilst the design of GitHub Actions remains fundamentally broken) leoprikler: Got any code for that? morganw: For GitHub Actions? It was pretty sparse, but if you are interested: https://github.com/adventuregamestudio/ags-manual/tree/master/.github/workflows morganw: I started to write a YAML renderer in it, but then though better of it leoprikler: that looks pretty nice leoprikler: a minor nuisance is that you have to manually expand job.m4 every time :P morganw: I think they have created a security problem which means they cannot use YAML aliases. And the job matrix outputs are static and overwrite each other, so unless you template the YAML there is just endless copying and pasting to duplicate everything manually. morganw: But it does seem reliable, which I cannot say for the others I've used. rlb: Imagine you know, but you can play some tricks with their matrix and the matrix var expansions to avoid some duplication... morganw: The problem is that the outputs are defined in the YAML key names, not the values. rlb: Ahh. morganw: And rather than combine multiple matrix outputs as an array for the return data, whichever job finishes last is the only return value you will see. rlb: (I've also used cirrus fwiw to add testing for freebsd to projects.) rlb: (But don't know much about cirrus otherwise.) morganw: Yes, I chose Cirrus too. I think it has a good design and didn't require me to start provisioning accounts to allow Docker containers to be cached. But I have had issues since with older containers not running, and also with restarted jobs interfering with artifact uploads. rlb: (Suppose you could do that on sourcehut too (and include a bunch of other platforms), but possibly not for free in the long run...) morganw: Lack of Windows support would be a problem too, since that is the primary platform for the project. rlb: Ahh. morganw: But I don't see Windows will exist in its current form in the near future, so this partly why I'm interested in Guile and where I can embed it, and whether that can be a game engine. leoprikler: Why embed Guile into your game engine, when you can write your game engine in Guile instead? :) leoprikler: Jokes aside, you should be able to embed Guile into your game engine. morganw: I saw Chickadee and it looked very interesting, although I'm a little worried about how to 'deploy' the final application in a way that is self-contained. mwette: several decades ago, I wrote a functional Makefile generator that used M4: https://paste.debian.net/1192684/ ; I had fun w/ M4. RhodiumToad: m4 is all very well but it easily becomes a complete mess dsmith: mwette: Wow. Looks really nice mwette: thx wingo: moin :) civodul: o/ lampilelo: hi rekado: morganw: you can deploy a self-contained archive with Guix. morganw: Does that run for someone who isn't using Guix? mbakke: morganw: yes, archives produced by 'guix pack' has no dependencies apart from the Linux kernel dsmith-work: UGT Greetings, Guilers lloda: what is the update process for gnulib? i saw other commits where it's done but it doesn't say. Only saw a couple old mentions in ChangeLog-2008. wingo: you "git pull" in a local checkout of gnulib. then run the command in lib/Makefile.am, adding any files that were added by the update wingo: the gnulib-update command i mean lloda: gnulib-tool --update i'm assuming lloda: giving it a try lloda: oh i can't read lloda: 'the command in lib/Makefile.am' lloda: building... lloda: everything looks alright. Ok to push? or should I push to a test branch and ask for people to test? I haven't done this before. lloda: ok pushed to wip-gnulib-update tatsumaru: hey guys, I am using arch linux and it only has guile 2.2.6 package for it. is it a lot different than 3.0.5 and can I use most of the current reference manual to learn guile on 2.2.6 or do i need to do a manual update? lloda: tatsumaru: There is a guile 2.2 manual at https://www.gnu.org/software/guile/docs/docs-2.2/guile-ref/ lloda: but if you are starting to learn there shouldn't be major differences lampilelo: tatsumaru: it's not that different but if you want to use guile 3 you can install it from aur lampilelo: today is the first anniversary of the last guile update on arch, lol lampilelo: yay rolling distro davexunit: slot-unbound is not very useful in goops :( davexunit: (slot-ref foo 'some-unbound-slot) calls slot-unbound with only foo as an arg, the name of the slot that was unbound is not included. dsmith: sneek: botsnack sneek: :) dsmith: goodbot daviid: davexunit: there are three methods, one of which specializes on the class, the istance and the slot-name daviid: davexunit: but you're sayig that one isn't called i guess, didn't try :) daviid: davexunit: in goops.scm, (slot-unbound class obj slot-name) is called within the core of the inner no-slot def, not within the core of the inner have-slot def, which seems like a bug to me davexunit: daviid: yeah it seems like a bug, but it could be as-designed? davexunit: if it is, I just don't like the design. :) daviid: davexunit: if you compare the def of solt-re and slot-set! in goops.scm, you can see that the no-slot inner def of slot-set! is correct, the one of slot-ref isn't, i think - then, the def of has-slot in slot-ref doesn't look right either daviid: *slot-ref daviid: *have-slot (not has-slot) davexunit: yeah, I noticed that davexunit: I don't feel like going down this rabbit hole but it does seem like something that could be improved. daviid: the other strange thing is that in this no-slot inner def in slot-ref, slot-missing is called as if it returns a value - and i can't find that it does :) in any of its methods davexunit: add that to the list of goops oddities davexunit: unrelated, but one of these days I'd like to try implementing CLOS's :before, :after, :around methods in goops. daviid: I just think you found a bug, and that slot-ref should be patched daviid: davexunit: that would be nice daviid: sneek: later tell davexunit here is a fix, could you try it - https://paste.debian.net/1192569/ sneek: Will do. daviid: wingo: could you look at this (oop goops) slot-ref fix - https://paste.debian.net/1192569/ - if ok, i'll file bug-report with a proper patch dsmith-work: {appropriate time} Greetings, Guilers pkill9: hi dsmith-work: Am I back? dsmith-work: Yes! lampilelo: or is he? dsmith-work: Maybe? lampilelo: so are you back or not? dsmith-work: Hope to be. connectivity issues abralek: Hi guile abralek: I am curious, is there any projects which use 8sync? leoprikler: At least not according to Guix: No dependents other than itself: guile-8sync@0.4.2 wingo: when do we get to remove libtool from our build system? :) *: wingo trolls dsmith-work: wingo: As soon as possible? wingo: is it actually a pain point for anyone? dsmith-work: wingo: I had some difficulties with it at one point. Nicely solved by just removing the .la file(s). dsmith-work: But then I was cross-compiling. dsmith-work: The .la file was pointing to the wrong places, IIRC. wingo: yeah afaiu all distros remove the .la files wingo: fedora, debian, even guix wingo: so we should just stop generating garbage :P wingo: ideally gnu would have replaced autotools at this point *: wingo grumble Noisytoot: What's wrong with autotools? civodul: wingo: it cannot just be "removed" tho, it has to be replaced civodul: saying this as a packager who's had occasions to wish Libtool had been used :-) civodul: to be fair, some of it can be plain removed, such as .la files civodul: (and support for AIX 5 and Tru64) zzappie: I am also curious. People seeem to devide to haters and lovers of autotool. And lovers are usually people who build package zzappie: Were there any atempts to reinvent it? :) morganw: I think the actual problem with autotools is that there looks to be an issue in finding people to work on them. One suggestion that has come up is for it to require GNU Make (since this is pretty much available everywhere) but I don't think anyone can agree on something to replace m4. daviid: davexunit: did you see my msg? i think i fixed slot-ref ... but wanted you to check ... civodul: zzappie: there's no shortage of free build systems these days, but most are broken in their own different ways civodul: :-) civodul: Meson seems to be doing better than the average civodul: that's going beyond the Libtool discussion though davexunit: daviid: no I missed it, sorry. sneek: davexunit, you have 1 message! sneek: davexunit, daviid says: here is a fix, could you try it - https://paste.debian.net/1192569/ zzappie: morganw: maybe define m4 language for guile and have option to write autoconf macros in scheme? :) davexunit: I'll try to find some time to fix it. need to get into a state where I build guile from source and try it out. davexunit: rather, to try the fix. daviid: davexunit: sure daviid: wingo, following a attempt to fix slot-ref, i also posted a msg here earlier today for you ... if you have a few min ... let me know what you think, tx morganw: zzappie: given there is already a GNU Make+Guile, plus all the build tooling for Guix that someone can point at, you would think it would be a logical candidate... daviid: davexunit: you may as well recompile just that proc on the fly ... and try it ... but as/when you wish/can of course, no problem leoprikler: fwiw I had an easier time using make plus handwritten m4 at a workplace, that felt too fancy for autotools rather than make+guile on pretty much any machine I had so far abcdw: Morning guile! What is the easiest way to expand a path with environment variables? "$HOME/tmp" -> "/home/user/tmp" wingo: good morning :) nly: abcdw: try ,apropos getenv nly: abcdw: yup, (getenv "HOME") abcdw: nly, thank you for the tip, but I would prefer something less manual, like (with-stdout-to-string (system (string-append "echo " path))), where path is a string, possibly with environment varibles. RhodiumToad: that sort of thing requires that you trust the path not to do anything strange nly: it's not strange if i have alias echo="rm" haha nly: sorry don't have a better answer RhodiumToad: the posix spec defines a wordexp() function, which guile seems not to provide a binding for RhodiumToad: that's intended to allow all the kinds of expansions done by shells, but the downside is that it generally works by spawning a shell, and many implementations have or had security bugs as a result RhodiumToad: the question with these things is what kinds of expansions do you want to allow? $HOME is easy, but what about ${HOME:-foo} or ${HOME+${HOME}/$(blah)} abcdw: RhodiumToad: wordexp is what I was looking for, but I took a look at the source code and it's a nightmare) abcdw: For my case I would probably go with very primitive approach using getenv, it's enough to expand only $HOME variable. abcdw: Thank you everyone for the help. nly: it works but i realize it's not satisfactory abcdw: Something like that: https://paste.debian.net/1192461/ leoprikler: abcdw: a better approach would be to detect $symbol as regexp and then use getenv abcdw: leoprikler: Yep, I thought about it, but I think for xdg-user-dirs it's enough to substitute only $HOME variable. leoprikler: oh, sure leoprikler: I think the correct way to code xdg user dirs doesn't even include "$HOME" as a string leoprikler: see the xdg-directory procedure in Guix leoprikler: fwiw if you're using this in guix home, you can just #:use-module (guix utils) to get it, noß leoprikler: s/ß/?/ abcdw: leoprikler: xdg-directory is cool, but it always add /guix at the end. The idea to use the XDG_DESKTOP_DIR variable instead of expanding the value myself is good, but won't work in many cases because those variables rarely declared in the environment, they mostly accessed via `xdg-user-dir DESKTOP`, which expands the value as I want, but it requires the invocation of external tool. abcdw: Seems that manual expansion of $HOME is optimal solution here. leoprikler: what exactly is your spec here? abcdw: leoprikler: I rely on `man user-dirs.dirs`, it says: VALUE must be of the form "$HOME/Path" or "/Path". leoprikler: ah, so you need to parse the user-dirs file? abcdw: Nope, I generate it for the `xdg-user-dir` utility and also ensures that all those dirs are created on `guix home reconfigure`. abcdw: https://paste.debian.net/1192463/ leoprikler: the easiest thing would be to silently add $HOME/ in the expanding code, no? abcdw: leoprikler: Not sure what you mean leoprikler: e.g. have desktop be "Desktop" and then expand that to $HOME/Desktop only when writing the user-dirs file leoprikler: and otherwise use (string-append (getenv "HOME") desktop) leoprikler: "/" desktop of course leoprikler: then you only need to detect some edge cases like leading slash or leading $HOME leoprikler: and tell the user that they shouldn't do that abcdw: I think that already implemented approach is good enough. The service configuration sticks to the original value format of xdg-dirs.dirs and expansion code is pretty simple. leoprikler: tbh I don't understand what "sticks to the original value" means in this context leoprikler: let alone whether that's a good thing abcdw: leoprikler: I use the same value format for home-xdg-user-directories-configuration as it in ~/.config/user-dirs.dirs abcdw: https://paste.debian.net/1192465/ leoprikler: hmm, fair enough wingo: moo mwette: wordexp using nyacc: https://paste.debian.net/1192485/ mwette: wordexp.ffi can be just this: (define-ffi-module (wordexp) #:include '("wordexp.h")) wingo: that module is auto-generated??? wingo: impressive mwette: Yes. You can control from which includes the definitions are generated, otherwise types are expanded. mwette: you can also #:use-ffi-module (other module) to work dependencies. Check examples/ffi/gtk2.ffi in the nyacc distribution dsmith-work: Tuesday Greetings, Guilers wingo: o/ Noisytoot: https://github.com/weinholt/hashing is not found manumanumanu: Noisytoot: https://gitlab.com/weinholt/hashing daviid: rekado_: do you happen to know/think if gnu solfege is still maintained? manumanumanu: wingo: _really_ nice work with the inlinable exports! It seems... nontrivial. :) rekado_: daviid: I don’t know, but it doesn’t look like there’s any development. wingo: manumanumanu: tx. has been trickier than i thought it would be :) wingo: i wired up the "inlinables" side. haven't done peval yet wingo: some tricky considerations regarding reproducibility -- because inlinables can themselves benefit from cross-module inlining, it's not clear when you reach a fixed point dsmith-work: Hey Hi Howdy, Guilers manumanumanu: wingo: "Inlining, how hard can it be?". Famous last words. wingo: :) manumanumanu: I don't know who I'm quoting, but it is a quote I know I have stolen from someone. I suspect it might be you: "Writing an inliner is like trying to restrain a rabid dog on a leash" wingo: dunno :) wingo: but yeah manumanumanu: wingo: I am a little bit curious. Have you measured any speedups? Cross module inlining is one of those things often talked about, but I don't really know about the benefits. wingo: manumanumanu: still not really working wingo: from looking at some diagnostics, generally will be no impact on guile. sometimes amazing tho wingo: one of those "whoa where did that 10x improvement come from" things wingo: but, it will allow us to write programs in different ways wingo: i.e. without considering module boundaries to be optimization boundaries wingo: so you can freely (define x 42) and know that users will inline as appropriate wingo: (nb, only for declarative modules and unassigned toplevels) wingo: er, declarative bindings in declarative modules rather wingo: anyeay wingo: *anyway wingo: in my branch, the "provider" side is done i think wingo: i.e. candidate values are written to the compilation units wingo: the "consumer" side is done for simple values like constants and such wingo: needs some help for lambdas tho. inlining a lambda introduces new lexicals in the source program, which peval wasn't expecting before civodul: neat sneek: Welcome back civodul, you have 1 message! sneek: civodul, raghavgururajan says: In c-u, glib-or-gtk-build-system doesn't trigger bootstrap. For example. try `guix build farstream --without-tests=gupnp-igd`. civodul: wingo: how can users retain control over ABI compatibility issues? civodul: as a module writer, sometimes there are things you explicitly don't want to be inlined manumanumanu: wingo: thanks! It will hopefully make something like define-inlinable mostly redundant manumanumanu: good night! dsmith-work: wingo: While you are messing about with cross module inlining, please have a think about https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47084 ArneBab: wingo: not having to worry about module-structure for optimizations sounds great! ArneBab: (not that I did that to date, but it would be great to never having to do it in hindsight) rlb: seems like we should rlb: support #:prefix and #:select in the same form. rlb: Or rather, might be nice. rlb: #:use-module ((foo bar) #:prefix bar/ #:select (x y)) rlb: I *think* right now it just ignores the #:select. rlb: Oh, unless the prefix applies to the selected names too. Hmm. rlb: (Not that it should necessarily influence guile, but used to that habit from clojure, i.e. there it's (:require [foo.bar :as bar :refer [x y]]) ArneBab: avp_: always the same problem in Free Software: We all already have cool projects we want to push forward :-) → http://www.draketo.de/english/users-fans-supporters ArneBab: “If you like what I do, why don’t you help me?” ArneBab: If anyone wants to have fun writing some guile-wisp, there’s now a wisp-page on rosetta code: https://www.rosettacode.org/wiki/Category:Wisp :-) (thanks to Greg who said “why don’t you …” :-) ) lampilelo: Ugh, no parens? It feels kinda inferior from the editing point of view: you can't just transpose sexps (etc.) and move efficiently through the code, or can you? I wonder what's the rationale behind it leoprikler: It's for people, who are afraid of parens, so yeah. leoprikler: that said, in wisp sexps correspond to 1+ lines, so it works fine just by transposing regions leoprikler: (that is unless you use fancy stuff like parens or the colon) lampilelo: i guess different strokes for different folks lampilelo: should the package maintainer be expected to have guile-snarf or should I distribute generated files? leoprikler: imo guile-snarf should be present at build time, same with guild rlb: Do we have any provisions for (or examples of) testing internal C functions? e.g. say I wanted to write independent tests for some normally static strings.c functions. rlb: (I suppose to really do that without including the code in a final install, we'd have to compile it twice one way or another...) rlb: Alternative I suppose might be to just accede to publishing them as scm_i_... functions and test those, but in this case, they really are internal functions, e.g. to sparsely reindex a utf-8 string, etc. Be nice to be able to test the corner cases there more directly. leoprikler: well, that goes against most testing wisdoms, but you can try looking those symbols up with ffi leoprikler: otherwise you'll have to find a way to test in C leoprikler: (which is possible, but not usually done) rlb: Oh, I'm fine testing in C (in fact that's what (for this purpose) would be easier), just didn't know if we already had some way. rlb: (And one reason this crossed my mind is that it may be difficult to even get guile to come up far enough to test strings.c from the scheme level, until it's mostly correct.) rlb: (Since "everything" depends on it.) rlb: (strings and symbols) leoprikler: see test-suite/standalone rlb: leoprikler: ahh, thanks, I'd forgotten about that. I'll take a look. rlb: leoprikler: yeah, that might work. Thanks again. rlb: And regarding standalone - not sure we'd want it, but I used the automake TAP driver for lokke, and that's worked out reasonably well, i.e. so a standalone test can, if it likes, report finer grain test information, and track multiple failures in one run (instead of only watching the exit status). rlb: i.e. https://www.gnu.org/software/automake/manual/html_node/Using-the-TAP-test-protocol.html rlb: Which functions do we require to have correct scm_remember calls in libguile? I assume that SCM_DEFINEd functions to, and any public scm_* or scm_c_* functions, but there are no expectations wrt scm_i_* functions? i.e. if you call those, you need to make sure to remember() defensively because they're allowed to do whatever they like? Or rather, you need to make sure to hold on to any arguments *for them* because they might not? rlb: "SCM_DEFINEd functions do" rlb: Meaning scm_foo (scm_i_bar (x)) wouldn't be correct by itself -- you'd need to break that up so you can scm_remember_upto_here_1 (x)? leoprikler: rlb: you use remember whenever you run in danger of using memory associated with a SCM, that might otherwise be GC'd leoprikler: e.g. if scm_i_bar does not return anything related to x, you don't need to remember it, but if it converts it to a void* or similar, you should probably remember it rlb: leoprikler: thanks, and right - so the "remember" responsibility is in the caller, and the call has to know whether or not the bits returned by the scm_i_ call are related to any given argument. rlb: "caller has to know" rlb: (wondering if I may have seen some missing calls in libguile, then -- will try to check later) leoprikler: rlb: garbage collection also has to be a real hazard, which I suppose is often not the case in guile stdlib leoprikler: e.g. you get a string, but you don't care if it's GC'd rlb: leoprikler: a more specific case I was thinking of is a scm_i_foo (x) that returns a new SCM derived from x (though in the end, fully independent). During the derivation, scm_i_foo uses internal bits of x in a way that *would* require a remember half-way through the work if it were a "public" function. So is scm_i_foo expected to include that remember, or allowed to assume that the caller must protect x since the caller can't know rlb: what scm_i_foo might do with it? rlb: i.e. do I always need to protect x in the caller (before the return) for a call like "return scm_i_foo(x)" to be sure x can't be lost half-way through scm_i_foo. rlb: e.g. "SCM result = scm_i_foo (x); scm_remember_upto_here_1 (x); return result;" leoprikler: I don't think you should write scm_i_foos in a way, that they require additional remembers rlb: Or is scm_i_foo required to make that unnecessary. rlb: So do I have to know how each scm_i_works, or do we have requirements? That's really what I'm trying to figure out. rlb: "scm_i_* works internally" leoprikler: my personal interpretation of scm_i_* is, that they're mostly quick and dirty functions, wherein such concerns don't apply rlb: (And if you "just have to know", perhaps we should note that in each one, so someone doesn't come along and rework the implementation in a way that violates the expectation...) rlb: I ask all this because strings.c has a lot of internal functions and some scm_i_ functions (and calls some), and I'm trying to understand what my constraints are. rlb: wrt toying with the sparsely indexed utf8 rearrangement. I suppose worst case I can just be very conservative, and then people can tell me where I've gone overboard wrt remembering -- just wanted to know whatever policies we had there. leoprikler: I don't have the code in front of me rn, but I'm pretty sure some of those are just fancy accessors. leoprikler: And that you need to remember the object if you plan on using their *return value*. leoprikler: never mind stuff done inside scm_i_* rlb: They were, but some things that were O(1) will become complicated, and some things that were complicated will be cached, and so O(1) i think. rlb: right leoprikler: that said, if you're adding stuff that's complicated and difficult to reason about, you should probably first ask yourself "Do I really want to do this?" rather than "Am I using correct scm_remember semantics?" rlb: Well, we already had issues like that because strings are shared, etc. and we take pointers into the underlying stringbuf, etc. rlb: That's the primary source of the issue, and it remains. rlb: (with the rework) leoprikler: w.r.t. remember the best answer I can give you, is that the return value is the contract rlb: Though some of that we might get around by recomputing the offsets all the time, i.e. avoid passing around raw internal pointers, but doesn't change the fact that you still have to remember the parent buffer object in all the right places. leoprikler: can the caller reasonably assume, that it needs to remember x to use the scm_i_* return value → no internal remember necessary rlb: Are you asking? Because that's what I was asking :) leoprikler: is the stuff I'm doing opaque as fuck? better remember the arguments rlb: i.e. if it's ok to omit the remembering in the _i_ functions and require the caller to handle it. rlb: that was my question "or do we have existing 'requirements'". rlb: "...and/or do we" leoprikler: As I said, the best answer I can give you, is "the return value is your contract". rlb: Anyway, thanks -- at the very least, it doesn't sound like we have any hard and fast rules there atm. leoprikler: even in public functions like scm_cdr you may need to remember post calling leoprikler: (if you don't want to GC the car) rlb: i.e. it might be ok for me to say that "for these scm_i_* string calls you need to remember these arguments" rlb: Though on the other hand, if the remember calls don't cost much (i.e. don't make an optimization mess or something), then why not just add the guards to the scm_i_ calls anyway. rlb: i.e. just avoid the question/requirement. rlb: Assuming they're not expensive(?) that's what I should probably do. leoprikler: I think the rule of thumb here, is if you need to document it to reason about it, it's probably stupid. leoprikler: + "don't add unnecessary requirements" leoprikler: but I have to go now and this is a little too abstract; if you have a more concrete MWE I'll look at it later rlb: Yeah, I think maybe I'll at least guard all the scm_i_ functions (and of course scm_*), and may or may not guard the internal static functions (internally). Thanks again for the discussion. ArneBab: lampilelo: you can move efficiently through the code, but the editor support still *is* inferior. That’s not an intrinsic problem, though, because the indentation+colon structure is an exact representation of the structure with parens. So the still existing limitation in editors is just because the work has not yet been done. The need is a bit smaller than with parens, because Emacs support for editing with indentation is pretty good. ArneBab: lampilelo: for the reasoning: » I love the syntax of Python, but crave the simplicity and power of Lisp.« — Guile gives me the capabilities I wish for, and replacing *outer* parens with indentation gives an appearance which is close to Python (which is a better fit to my mind). ArneBab: lampilelo: the deeper reason is that starting each procedure-call with a parenthesis makes visual recognition harder (until your mind starts to fade them out). I created a small presentation for the reasons, the first six slides of http://www.draketo.de/proj/wisp/why-wisp.html ArneBab: lampilelo: and longer reasoning: https://www.draketo.de/py2guile lle-bout: hello! does GNU Guile have a hotspot JIT compiler? ft: https://www.gnu.org/software/guile/docs/master/guile.html/Just_002dIn_002dTime-Native-Code.html ft: That's a pretty new thing though, introduced in 3.0, and only available on a few platforms. lle-bout: ft: Thanks, I know it exists but I didnt know if it was an 'hotspot' one or not. I will read that link in full, thank you. lle-bout: ft: seems like it's an hotspot one indeed: "The JIT compiler runs automatically, triggered by counters associated with each function. The counter increments when functions are called and during each loop iteration. Once a function’s counter passes a certain value, the function gets JIT-compiled. See Instrumentation Instructions, for full details." ft: Ah, okay. I'm not an expert on this at all. I thought that was the point JITs. :) ft: Why would one want a non-hotspot jit? lle-bout: ft: not sure lle-bout: ft: You could compile every function as they get run instead of compiling them only when they get run too often, e.g. LLVM Orc JIT does compile every function as they get run because there's no interpreter for C/C++. ft: lle-bout: I suppose that's true. Never thought about that. ft: Like I said, not an expert on compiler technology. :) lle-bout: Neither am I, but I got some culture at least ft: Hehe leoprikler: Not quite sure what a "hotspot" JIT is (sounds like a marketing term imo), but there are also tracing JITs, that use basic blocks rather than procedures as code units. lle-bout: leoprikler: as in functions that get run often become "hot" lle-bout: It's what GNU Guile implements it seems basically leoprikler: Ahh, so I was thinking about the right thing. lle-bout: AFAICT OpenJDK's JIT is called 'Hotspot' so maybe that's marketing but also V8 had such terminology not sure leoprikler: yeah, it makes sense, as GCC had "hot" and "cold" attributes I assume way before Java had a JIT. ft: Yeah, hot and cold to categorise codepaths isn't unusual. ArneBab: pkill9: lisp is like programming the language to be a better interface between programmer and machine. leoprikler: and in doing so maybe also solving the problem you originally sought out to solve ArneBab: *maybe* :-) — I just spent 2 hours improving my game code structure hiding that I’m not sure how I’ll continue the story :-) leoprikler: implementing new features? nah, let's refactor :) ArneBab: oh yes … :-) ArneBab: that reminds me that I wanted to add a FIXME: this is horrible :-) pkill9: what is the most straightforward linux desktop setup? pkill9: something that pretty much 'just works' the linux way ArneBab: I’d say just install Ubuntu and don’t change anything. ← sidestepping the question what’s the Linux way. ArneBab: I would hovewer choose Kubuntu instead :-) pkill9: i'm too far in to using guix system pkill9: so it needs to be the linux way ArneBab: I just use Gnome on Guix ArneBab: just works avp_: Hello Guilers! I released Guile-Deck 0.2.0: https://lists.gnu.org/archive/html/guile-user/2021-04/msg00005.html Noisytoot: pkill9, ArneBab: Ubuntu contains some nonfree software ArneBab: Noisytoot: yepp — the question was for "most straightforward", not for "best" Noisytoot: What about Debian? Noisytoot: That's quite straightforward ArneBab: quite yes, but not "most" ArneBab: avp_: does this support encrypted private messages? avp_: ArneBab: Likely not yet. But you may contribute. ;-) ArneBab: I’m already neckdeep in my own projects, but if it would have private messages, it would be a good candidate to create some minimal CLI interfaces just to talk to someone on matrix now and then avp_: In this release I improved the Texinfo documentation, most of the types/procedures are documented. ArneBab: nice! ArneBab: That’s still missing completely from my dryads-wake tools … avp_: ArneBab: I see. avp_: I'd like to build some kind of a equippment management Matrix bot for a local hackerspace using Guile-Deck. ArneBab: wow, that sounds cool avp_: And because of the same "neckdeepness" situation I probably won't be building any kind of a feature-rich user client with this any time soon. ;-) avp_: But it would be nice to include a toy client in Guile-Deck "examples" indeed. chrislck: Anyone knows why is guild named guild? chrislck: is it from the same vein "a guild of schemers/racketeers/guilers"? jackhill: chrislck: something like that "However we changed the name to guild, not only because it is pleasantly shorter and easier to read, but also because this tool will serve to bind Guile wizards together, by allowing hackers to share code with each other using a CPAN-like system." from https://www.gnu.org/software/guile/manual/html_node/Using-Guile-Tools.html#index-guild chrislck: nice but otherwise a bit obscure when called from other tools lol civodul: roptat: merged diff support in guile-git! civodul: pretty cool civodul: thanks for the tests :-) civodul: like i wrote there, might be worth providing 'diff-fold' roptat: civodul, I have one or two additional functions in other parts that I'd like to contribute, but I can't connect to gitlab roptat: also, thanks for merging :) roptat: here are additional functions I needed for gitile: https://git.lepiller.eu/gitile/tree/-/gitile/git.scm roptat: tree-entry-type and config-foreach civodul: roptat: yeah gitlab.com doesn't work in IceCat, go figure civodul: do you think you could contribute them "soon"? civodul: i'd like to have a Guile-Git release out before the Guix release roptat: yeah, I'll push the patches to my branch when they're ready (maybe in one or two hours) roptat: a new branch* roptat: then I can't create a MR because I can't connect, but I suppose you can still merge "manually"? civodul: roptat: sure, just ping me civodul: Epiphany works with gitlab.com, but it's even better to avoid it altogether roptat: civodul, I have my patches except one that adds config-entry. I think it should go to git/config.scm, but it's already used for configuration of guile-git itself roptat: what should I do? move config.scm to configuration.scm maybe? dsmith-work: Happy Friday, Guilers!! dsmith-work: /sudo::/etc/hosts pkill9: is lisp like programming the programmer instead of programming the machine? roptat: oh well, eolie doesn't work for me "ValueError: Namespace Handy not available" roptat: so, no gitlab and no MR dsmith-work: More like programming the language roptat: civodul, I pushed my changes here: https://gitlab.com/roptat/guile-git/-/tree/gitile-features civodul: roptat: nice! re renaming (git config), i'm not entirely sure, but maybe that's ok civodul: i don't think anyone has good reasons to use the current (git config), it's pretty useless civodul: so it should be backwards-compatible in practice civodul: we'll have to document it in NEWS, though civodul: roptat: other than that, could you add tests for the new (git config)? civodul: also, as for diff-foreach, it may make sense to provide tag-fold instead of/in addition to tag-foreach civodul: WDYT? roptat: sure, though I'm not sure what you mean by "implement diff-foreach in terms of diff-fold" roptat: libgit provides only diff-foreach, not fold roptat: so I'd implement diff-foreach in terms of diff-fold that I'd implement in terms of diff-foreach? I'm confused roptat: also, I already implemented tests for config: https://gitlab.com/roptat/guile-git/-/blob/gitile-features/tests/config.scm roptat: ouch, got a segfault when trying to implement config-fold roptat: mh, fixed civodul: roptat: git_diff_foreach takes a void pointer argument if i'm not mistaken, so that's enough to implement diff-fold civodul: then diff-foreach becomes a special case of diff-fold that returns *unspecified* roptat: oh, ok roptat: although, how do I create a pointer from an arbitrary guile object? tohoyn: sneek, botsnack sneek: :) leoprikler: roptat: scm->pointer? roptat: ah thanks :) roptat: wait, the callback needs to return 0, so I need to update the pointer in some way roptat: but I doubt I can do that roptat: or maybe I can make a double pointer roptat: so, I have a double pointer to an arbitrary object, and I need to make the second pointer point to a new arbitrary object, how can I do that? roptat: p1 -> p2 -> o1, I can't change the addresses pointed to by p1, so I want to change p2 with another pointer: p1 -> p2 -> o2 roptat: I guess I can dereference p1, but then how do I updatte p2 to point somewhere else? civodul: roptat: actually branch-fold & co. are not based on the C "foreach" function, but rather on iterators civodul: in case it's easier civodul: otherwise yes, you can have an extra pointer indirection like you wrote leoprikler: I think you'd typically have p2 as a bytevector and write arbitrary pointers into it :) civodul: p2 = (make-bytevector (sizeof '*)) wingo: good evening :) civodul: hey wingo roptat: so, I can transform a pointer to a bytevector? roptat: sounds scary, do I simply copy the address to the bytevector? leoprikler: yep, there's pointer->bytevector and bytevector->pointer leoprikler: for writing you need pointer-address and a number-writing func roptat: well, that's not what I want it seems, bytevector->pointer returns a new pointer to the bytevector, not a pointer that points to the address contained in the bytevector roptat: but I'll manage :) roptat: mh, actually I'll get different sizes of pointers, so how do I write an address (a number) to it? civodul: roptat: bytevector-uint-set! civodul: sorry for the bumps on the road, i didn't expect it to get tricky roptat: ok, I think I have all the elements I need now, thanks :) roptat: now I wonder if the garbage collector will play nicely roptat: I mean, in the callback, I create a new pointer to the new value of the payload, and put its address inside a bytevector... won't the GC be able to collect the payload? That could cause a segmentation fault, right? soda__hobart: you can use the tree *** matching syntax from ice-9 match on an alist, right? i am trying: (match '((#:a (#:b . 1) (#:c . 2))) ((p *** 1) p) (_ #f)) which gets me #f, but i must be messing something up, because i tried something similar the other day and got '(#:a #:b) for the output soda__hobart: well, actually it was like this: (match '((#:a . [(#:b . 1) (#:c . 2)])) ((p *** 1) p) (_ #f)) soda__hobart: this works: (match '(#:a (#:b 1) (#:c 2)) ((p *** 2) p) (_ #f)) jadedctrl: hey, does anyone know of a way to change site-dir? daviid: jadedctrl: you may decide where guile is installed, but not the fact that the site-dir is 'computed' based on guile's effective version, iiuc your question jadedctrl: daviid: alright, thanks daviid: jadedctrl: what are you trying to do? wingo: moin abcdw: Hi guile! Is there a function in guile similar to interpose in clojure? https://clojuredocs.org/clojure.core/interpose wingo: getting the details of inlinable exports right has been a pain and the pandemic is not helping! wingo: also the fsf board shenanigans are not helping :P leoprikler: abcdw: well, there is string-join, but I don't think that counts ;P zzappie: abcdw: if you are after transducers there is srfi-171 btw abcdw: leoprikler, zzappie: Thank you for tips, implemented it myself https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services-utils.scm#L192 zzappie: I also went for fold :) zzappie: https://paste.debian.net/1191963/ zzappie: oops it doesnt work with '() leoprikler: Same as string-join, but without join and string, so "-"? zzappie: leoprikler: didnt get you. I'd expect it return '() for '() input leoprikler: twas but a silly pun zzappie: ah I sometimes bad at parsing puns leoprikler: well, puns are context-sensitive, so LALR won't get you anywhere :) zzappie: leoprikler: well this was a nice one :D abcdw: zzappie: Your implementation is a good one! abcdw: leoprikler: (: Both puns are great) dsmith-work: UGT Greetings, Guilers civodul: roptat: hey! re , could you add tests? civodul: OrangeShark, mbakke: i'd like to make a Guile-Git release shortly, presumably 0.5.0 according to semver lampilelo: is having a global struct with data and then accessing, reading and writing to its fields from all over the place is common in c? omg i want pure functions lampilelo: i'm trying to extend a program but it's kinda difficult to understand this spaghetti code *: dsmith-work hands lampilelo a pasta-friendly comb lampilelo: i think i'll have to use it and redesign some stuff, at least it's not a big project lampilelo: straighten things, if you will dsmith-work: Back in the DOS days, I was using a bbs that had uucp capability (which is why I was messing with it). Was all globals everywhere. dsmith-work: Some functions were merely to set globals. dsmith-work: Was just about impossible to reason about. dsmith-work: The docs even said that the author breaks it all the time when touching it. lampilelo: wow, yeah, sounds like fun dsmith-work: Ugh dsmith-work: I thought I had successfully suppressed those memories. lampilelo: :D zzappie: I was given bunch of industrial electronic units to do factory process automation. Those things were programmed in STX language... zzappie: This is the last thing you want to learn. All tools are proprietary and terrible zzappie: In fact I found it so unusble that I coded up code generation in python for an enourmous state machine with bunch of globals zzappie: This might sound clever but boy it was my first coding job and that was a real monster :) zzappie: amazingly this thing still works roptat: civodul, sure :) spk121: . daviid: .. rlb: ... wingo: heyoo manumanumanu: ahoy! manumanumanu: Is there any b-tree implementation for guile? I need an ordered map, and my old b-tree implementation is lost to the sands of time (and my current Red-Black tree is for some odd reason very very slow. 2 seconds to add 10k elements is pretty bad). amirouche: in-memory or on-disk? amirouche: manumanumanu: ^ amirouche: anyway, I do not know on-disk b-tree implementation using scheme (I am very interested to find one!) amirouche: otherwise there is https://github.com/ar-nelson/schemepunk#schemepunk-btree amirouche: mit/scheme and SCM have a well balanced binary trees chrislck: how would one define a (define (xor a . rest) ...) recursively for an arbitrary number of arguments? Note logxor handles unlimited args. chrislck: something better than (define (xor . args) (not (zero? (apply logxor (map (lambda (elt) (if elt 1 0)) args))))) lloda: chrislck: lloda: (define odd? (compose not even?)) lloda: (import (srfi :1)) lloda: (define (xor . a) (odd? (count identity a))) lloda: I think? flatwhatson: (define (xor . args) flatwhatson: (let loop ((ls args) (res #f)) flatwhatson: (cond ((null? ls) flatwhatson: res) flatwhatson: ((and res (car ls)) flatwhatson: #f) flatwhatson: (else flatwhatson: (loop (cdr ls) (or res (car ls))))))) flatwhatson: chrislck: ^^ chrislck: cool. any takers, eg case-lambda magic? civodul: lloda: (negate even?) looks nicer than (compose not even?), and it's also a bit more efficient (one less procedure call) lloda: fair fair lloda: it's simple enough that i'd write (not (even? (count ...))) prolly lloda: but it's peculiar that even? is defined and odd? isn't civodul: it's odd, even civodul: actually odd? is defined civodul: or is that an R6 issue? lloda: oh it is lloda: i think i tried odd and not odd? and then I defined odd? which is odd lloda: ha lloda: they are in (guile) even chrislck: you're even then civodul: odd lloda: lol chrislck: flatwhatson: (logxor 1 0 1 0 1) -> 1, but your (xor #t #f #t #f #t) => #f flatwhatson: chrislck: Yeah I implemented "Exactly one of these things must be true" instead of "An odd number of these things must be true", it seemed sensible. lloda: logxor is 'A bit is set in the result if it is set in an odd number of arguments.' lloda: but i'd agree that makes more sense as 'exclusive or' lloda: then you could do (define (xor . a) (any identity a)) flatwhatson: Then you'd get (xor #t #t) => #t lloda: right :-/ lloda: (= 1 (count identity a)) then lloda: (logior) is 0 flatwhatson: Yes, but and/or return the last truthy input instead of #t, which is often useful. lloda: (import (ice-9 match) (srfi :1)) lloda: (define (xor . a) (match (find-tail identity a) (#f #f) ((x . rest) (and (not (any identity rest)) x)))) dsmith-work: Wednesday Greetings, Guilers flatwhatson: lloda: Nice! Now this one: flatwhatson: (define (xor . args) flatwhatson: (let loop ((ls args) (r #f) (n 0)) flatwhatson: (cond ((null? ls) (and (odd? n) r)) flatwhatson: ((car ls) (loop (cdr ls) (car ls) (1+ n))) flatwhatson: (else (loop (cdr ls) r n))))) rekado_: I would replace the car and cdrs with a match expression wingo: are we golfing? :) wingo: (use-modules (srfi srfi-1)) wingo: (define (xor . args) wingo: (fold (lambda (arg res) wingo: (if arg (not res) res)) wingo: #f wingo: args)) flatwhatson: Very neat, but it doesn't return the last truthy value wingo: ah indeed. wingo: i guess s/not res/if res #f arg/ chrislck: ah the master chrislck: we're O(small)ing chrislck: fold is underrated... chrislck: thanks boss! dsmith-work: I was going to suggest a fold. No really, I was.. lloda: fold always runs over the whole list. For xor = only one, you don't need that dsmith-work: So what should the value be with no args? One? Does that even make sense for XOR ? lloda: (logior) returns 0, so (xor) should return #f lloda: (or) returns #f which makes sense lloda: ie 'zero' != 'exactly one' so #f dsmith-work: s/One?/One arg?/ lloda: same as (or) lloda: sorry (xor a) = (or a) manumanumanu: amirouche: that one from adam is exactly what i'm looking for. Not on disk, as you might guess :) dsmith-work: Ok. lloda: i like the exactly one definition, wonder why logior is defined like that flatwhatson: The "odd" thing is because that's how (xor a (xor b c)) behaves manumanumanu: amirouche: it looks portable enough, and porting schemepunk to guile seems rather straightforward. dsmith-work: "schemepunk" sounds like a genra of fiction amirouche: I like the name manumanumanu: amirouche: and the srfi-166 implementation seems a lot more efficient than the reference implementation. basing it on generators seems like a generally good idea amirouche: (: amirouche: I never touched srfi-166, even if I like the idea. manumanumanu: srfi-166 is, hands down, the nicest string format utility I have ever used. manumanumanu: I had a compiler for it, that compiled the (ice-9 format) subset of it to more efficient scheme. it was lost in a fire though manumanumanu: I have thought about writing an implementation for it for guile. manumanumanu: not based on the reference implementation (which uses call/cc for the columnar formatting) manumanumanu: which schemepunk show does not. manumanumanu: but it uses it for some of the trimming formatters manumanumanu: which seems odd amirouche: Arthur published a Post Finalisation Note (PFN) SRFI-167 (okvs) and SRFI-168 (nstore), saying do not use them, among many problems those SRFI have, there is one I could not avoid: ALL okvs libraries made the same mistake sheeping the original BerkeleyDB design, I asked the maintainer why it was not possible to count the number of keys, they replied: it is a design mistake amirouche: => next iteration on okvs will have that procedure, that makes coding query optimizer much more easy. amirouche: That is why I need an on-disk b-tree (even if it will be slow) amirouche: at least the design will be correct, and *maybe* people will start adding the function in their C implementations. manumanumanu: Correction: the reference implementation stopped using call/cc for columnar formatting, and things look like they could be faster! amirouche: key count allows to implement key subspace statistics. amirouche: manumanumanu: some implementation have fast call/cc faster than Chez IIUC. amirouche: SRFI-180 should use make-coroutine-generator, it is much more readable. amirouche: the code without call/cc was a pain to write, and I guess a pain to read, it is manual CPS. amirouche: s/manual/explicit/ samplet: Does Guile offer a way to do locale-dependent character classification? samplet: SRFI 14 (char-sets) is locale-independent, and I don’t see anything in section 6.25 (Internationalization) of the manual. dongcarl: Hi all, if I have guile packages in my /usr/local prefix, is it enough to just do GUILE_LOAD_PATH=/usr/local/share/guile/site or do I have to do the full GUILE_LOAD_PATH=/usr/local/share/guile/site/2.2 ? manumanumanu: amirouche: the only implementations where call/cc is fast is cheney on the MTA based where call/cc is free. They are all slower than chez, though :D Anyway, the delimited continuations you can get in chez if you go under the hood are a lot faster than both call/cc and call/cc1 in chez. wingo: good evening amirouche: manumanumanu: by the way, why do you favor b-tree instead of a binary tree? manumanumanu: better cache locality manumanumanu: a left-leaning red black tree is simpler to implement, but whatever I hacked together a couple of days ago is too slow because I fudged something amirouche: I guess I will go with scheme punk b-tree, it will be less work. amirouche: the thing is that implementation will run in the browser, so i do not know how cache localit works in that setting. manumanumanu: if you have access to srfi-146, the non hashing one is a red-black tree leoprikler: samplet, what would locale-dependant classification look like? leoprikler: [also would it be impractical to first convert those characters to UTF-8 and classify them after the fact?] samplet: leoprikler: When I ask (for example) if a character is a digit, it should tell me the answer according to LC_CTYPE. leoprikler: I think there are some locale-dependent regular expressions somewhere (e.g. for detecting yes/no), but I forgot where and I don't think they do numbers leoprikler: See (guile)Accessing Locale Information leoprikler: jlicht: guile-json/guile-yaml come to mind, but on the high level you're on your own i fear wheeler: Having trouble following the examples from https://www.gnu.org/software/guile/manual/html_node/Symbol-Keys.html wheeler: In my REPL, I get an error for assq-set! wheeler: when running (assq-set! car1-properties 'seat-colour 'black) wheeler: Wrong type argument in position 1 (expecting mutable pair): (seat-colour . red) wheeler: Where did I go wrong? wheeler: Is this because I'm running v2.2.7 and not 3.0.X? wheeler: OK, it's not the version. Getting the same result in v3.0.5 wheeler: Am I missing an rnrs? flatwhatson: Seems to be picky about how the pairs are created. If you use assq-set! to add the initial value, and then to modify it, it seems to work? wheeler: flatwhatson: That's right. It works if I set values manually with assq-set! for initial value but not if I use define or set! for the whole alist. wheeler: strange wheeler: but the examples at https://www.gnu.org/software/guile/manual/html_node/Symbol-Keys.html *should* work.... or at least they seem very sensible :D flatwhatson: (define props '((foo . bar))) flatwhatson: (set! props (assq-set! props 'foo 'baz)) ; fails flatwhatson: (set-cdr! (assq 'foo props) 'baz) ; works wheeler: Sounds good -- I'll use set-cdr! and assq for now wheeler: Thanks, flatwhatson! flatwhatson: I agree the examples should work. Guess it's a bug? wheeler: Must be. wheeler: Perhaps the examples were from an older version daviid: wheeler: somewhere in guile's evoution, '(a . b) becomes immutable, as opposed to (cons 'a 'b), this is a manual bug - this will work daviid: just a min daviid: (define car1-properties `(,(cons 'colour 'red) ,(cons 'transmission 'manual))) daviid: (assq-set! car1-properties 'colour 'black) flatwhatson: But why does the set-cdr! version work? daviid: on a immutable pair, that soundfs like a bug, not sure this will work using 3.0 (i was testing the above using 2.2.7 flatwhatson: Above is from 3.0.5 wheeler: daviid: The quasi-quote example also worked in 3.0 daviid: flatwhatson: i meant to say i did test what i wrote using 2.2.7 flatwhatson: Interesting! Confirmed set-cdr! on immutable pair fails in 2.2.7, but doesn't fail on 3.0.5. flatwhatson: Weird thing is that assq-set! calls scm_set_cdr_x, which is aka set-cdr!. When called from C, it errors (correctly), but called from scheme, it works. leoprikler: flatwhatson: I believe in some of these cases the pair isn't actually immutable (that immutability is gained through compilation) dsmith-work: Tuesday Greetings, Guilers lloda: RhodiumToad: thx re primitive-exit MeRaZi: greetings everybody leoprikler: avp_: You can document generics (including accessors) in the code itself and snarf it, but for slots you'll have to manually write them (assuming you use slots without accessors) leoprikler: Also have a look at (texinfo reflection) soda__hobart: with ice-9 match, what is the argument for the predicate func in the (? predicate pat_1 ... pat_n) pattern? is it each item or the entire list? leoprikler: (match '(a b c) ((? pair? (a b c)) a)) leoprikler: I hope this answers your question :) leoprikler: Interstingly, you can also do (= pair? a) to get #t :) soda__hobart: hmm ft: Also, maybe: (match '(a b c) ((? (lambda (x) (format #t "-> ~a~%" x) #t) (a b c)) a)) leoprikler: the predicate is evaluated on the entire things leoprikler: thing* leoprikler: that's why you have to write cute to smuggle other stuff in :P soda__hobart: bluh, i had this figured out before and i forgot haha soda__hobart: i have some relations with logic variables that start with a "?" and i'm trying to pick them out leoprikler: leading question marks sound like your asking for trouble (and make it double) soda__hobart: haha yeah, they're just strings though soda__hobart: it's all just strings at the end of the day, and they're all going to the same place leoprikler: now you've lost me soda__hobart: it's a bad joke, but i mean binary is just string operations, basically, right? leoprikler: if you mean, that you can implement a binary turing machine in terms of label rewriting systems, then yeah, but I think you might be going for something else? soda__hobart: mathematical formalism or something? leoprikler: explain what you mean when you say "binary is just string operations" soda__hobart: like at low-level, the instructions and data and stuff are arrays of bits or whatever, which is like a string? leoprikler: well, at the lowest level, binary can be just a single bit, which a string can't soda__hobart: what about a string in the abstract sense of the term? soda__hobart: it can't be a single piece of information? leoprikler: well, by its very nature, a string is more than a single piece of information leoprikler: it is at least two: where to start, and where to end leoprikler: although where to end can sometimes be confusing :P soda__hobart: haha yeah i'm gonna have to go read gödel or wittgenstein or something leoprikler: Well, Gödel talks about numbers at great lengths, you can even reduce strings to numbers if you really want to. soda__hobart: yeah, i was helping my roommate study for a placement exam the other day and we were reviewing factoring polynomials and i guess it is a string operation basically leoprikler: back to the original question, what is "just a string" in your context? the variable name? soda__hobart: oh yeah, i have an alist with bindings in it, and the keys are strings leoprikler: "bindings" as in procedures generated through FFI/Schmutz/what have you? soda__hobart: no, bindings just as in bound variables soda__hobart: i'm evaluating each term in a clause, like it's a really simple prolog-style rule language leoprikler: so you have rules like "string-operation BINARY_ARITHMETIC." leoprikler: "string-operation INTEGER_FACTORIZATION" leoprikler: oops, missing the dot leoprikler: "string-operation HALT." soda__hobart: no, i suppose i could, but my domain doesn't really require those soda__hobart: it is not quite a life-or-death thing, i'm just trying to make a crude framework for using an equally crude clausal language for making 2d games... but i've been reading a lot of cool books like norvig's PAIP and this algorithms textbook wingo: o/ civodul: hey wingo dsmith-work: Monday Greetings, Guilers lloda: remind me how to exit the Guile repl from any number of nested prompts other than exiting from each one in sequence RhodiumToad: exit the repl, or the whole process? RhodiumToad: (primitive-exit) works to exit the process, but I think everything else is caught and only unwinds one level leoprikler: raghavgururajan: I have great trouble parsing your table. It looks like everything is up-to-date? :D raghavgururajan: leoprikler: Its a navigation list for where to start and where to end. srandon111: hello guilers! stis: tja guilers! wingo: heyyyyyy jlicht: Seeing as OpenAPI/Swagger is hip and happening, does anyone here know of ways to create and/or consume specs for it in guile? lle-bout: hello has behavior changed in incompatible ways between Guile 3.0.2 and 3.0.5? dsmith-work: lle-bout: Look in the NEWS file. Changes are documented there. dsmith-work: Sure would nice if the NEWS file dsmith-work: "Changes in xxx (since yyy)" had the top level *. dsmith-work: Then it would be much nicer to view with org-mode lle-bout: dsmith-work: thanks but does it mean major versions of GNU Guile can introduce incompatible changes? dsmith-work: lle-bout: I belive that's the goal, but sometimes mistakes happen. And other times there is no other way to fix something. dsmith-work: lle-bout: I'm sure the devs try very hard not to let that happen. lle-bout: dsmith-work: basically GNU Shepherd with GNU Guile 3.0.5 doesnt work and I'm trying to fix it dsmith-work: Well, the only onces I see are: dsmith-work: `call-with-output-string' closes port on normal exit dsmith-work: `copy' read-option removed dsmith-work: lle-bout: What doesn't work? lle-bout: dsmith-work: the test suite, here's logs: https://paste.debian.net/plain/1191601 - I don't know GNU Guile's Scheme much.. lle-bout: I verified that with GNU Guile 3.0.2 it works, but not 3.0.5 lle-bout: raghavgururajan: about to rebase, so next time git pull --rebase lle-bout: raghavgururajan: no big deal it's just the commit is the same now I guess, don't know if you rebased or cherry-picked lle-bout: raghavgururajan: looking at shepherd btw lle-bout: oops sorry wrong channel leoprikler: Is there a way to determine the RTD of a record (assuming it's not opaque)? janneke: maybe struct-vtable, struct-ref? avp_: Hello, Guilers! Is there any good examples of how GOOPS classes are documented in Texinfo format? I mean I surely can write the docs on my own but I'd love to learn from the masters. ;-) stis: Hello guilers! roptat: probably a stupid question, but how do I fully expand something like @datarootdir@ with autoconf? I have a conf.scm.in file where I use that, but it get expanded to a string that contains "${prefix}", so that doesn't work as expected janneke: roptat: you can use make to create conf.scm from conf.in using sed -e 's,[@]datarootdir[@],$(datarootdir),g' ... roptat: ok, thanks morganw: I think technically you only need one [@] as it only needs to break the original pattern match chrislck: guix's guile-next's guile --version is UNKNOWN lol dsmith-work: Happy Friday, Guilers!! BitPuffin: Happy fri cheim0: rlb: cheim0: to close bug 34457 on the bug tracker, is access to the server control at debbugs.gnu.org restricted to lead developers? Or is it unrestricted, allowing any user to tag or close a bug? apteryx: cheim0: unrestricted cheim0: thanks manumanumanu: ahoy hoy! wingo: hey hey :) manumanumanu: wingo: I don't know if you are subscribed to srfi-announce, but immutable integer mappings just got a SRFI draft. They seemed an awful lot like intmaps, so I am digging through the intmap source to see if I can implement that srfi on top of intmaps. wingo: neat stis: hey guilers! dsmith-work: UGT Greetings, Guilers wingo: hej :) lle-bout: this backtrace is showing quite unhelpful because it trims strings: https://paste.debian.net/plain/1190976 wingo: something to fix for 3.0.7, yeah wingo: i mean it's been like that for a while but we need to fix it lle-bout: thanks wingo! manumanumanu: hej stis! how is python coming along for you? It is a project that fills me with awe, while making me disappointed with myself because I can't stand python :P daviid: lle-bout: can you try ,bt [#:full? #f] #:width 1000 lle-bout: daviid: in that scenario I cannot because the error is issued by GNU Guix where I have no control over GNU Guile options daviid: lle-bout: hum, i thought it was possible to do 'something', even though ... like export COLUMN=1000 before to run your guix script - https://lists.gnu.org/archive/html/guile-user/2019-03/msg00007.html lle-bout: daviid: interesting will try next time! lle-bout: thanks stis: manumanumanu: it's moving slowly forward, a lot of things works well, especially the parser which can handle a big chunk of python 3.6 code stis: currently I'm working to get the typing working manumanumanu: stis: like a proper type checker?? stis: just making sure that you can quiry type information for variables in classes stis: I need it for dataclasses which i am implementing stis: manumanumanu: ^^ manumanumanu: that shit go way beyond me. I am trying to implement a red-black-tree, and it is very slow. Creating 10000 integer mappings takes 2.5 seconds... manumanumanu: what are python dataclasses? stis: structs with inherritance but interoperates with python normal classes soda__hobart: ok, my "delete-my-struct" function does not appear to be actually freeing any memory soda__hobart: like if i allocated 500mb, and i see the memory usage in htop tick up by 500mb, and then i call my delete function on all those structs i just made, i should be able to see the memory usage drop in htop, right? leoprikler: Not necessarily. The operating system can let you keep that memory if it feels you're just going to use it again anyway. leoprikler: you should really do a valgrind there soda__hobart: yeah, i think valgrind will help me get to the bottom of it leoprikler: [that said, 500mb feels large and the operating system would likely want that memory back if you're not using it] soda__hobart: bluh... i think the problem is because i make this lcrs binary tree recursively, and then flatten it into an array so it can be serialized, but it looks like i'm only freeing the root node of the original tree soda__hobart: yay, it worked! i'm still leaking memory, but a lot less now :] wingo: o/ rekado_: I’ve got a little server here that produces a long stream of binary data rekado_: https://elephly.net/paste/1616572710.html rekado_: the client uses “echo '"something"' | nc ip 2904 > foo” to receive the stream rekado_: I notice that the data stream is always truncated on the receiver rekado_: a couple dozen trailing bytes are missing rekado_: I got closer to the full data stream by disabling buffering rekado_: my guess is that the server kills the connection before everything has been sent. rekado_: shouldn’t “(force-output client)” do the right thing here? rekado_: or is it perhaps buffering in the command that generates the data stream…? rekado_: (the actual code doesn’t use “display” but the Guix API) ArneBab: does someone have a package for wrk? wingo: rekado_: do you need to read the newline off the input or something? wingo: is there some kind of nagle algorithm in effect? *: rekado_ doesn’t know rekado_: I note that on the same host everything is received rekado_: across the network the last bytes are missing rekado_: it’s not always the same amount that’s missing wingo: weird rekado_: wingo: setting TCP_NODELAY on the socket seems to have fixed it, so it seems that your nagle algorithm guess was spot on rekado_: thanks! wingo: yay wingo: oddly guile's core web server doesn't set that flag but the fibers one does wingo: :unicode_shrug: ArneBab: wingo: are you looking into the fibers server right now? ArneBab: (if not, please just say no — I don’t want to clobber your context, it’s just that I have some longstanding questions about small parts of it) lle-bout: hey, is there a way to speed up GNU Guile checking for .go files? lle-bout: All these stat calls on startup dsmith-work: UGT Greetings, Guilers civodul: lle-bout: you can read at issues.guix.gnu.org what i did for the 'guix' command produced by "guix pull" civodul: in the future we could imagine a mechanism similar to ld.so.cache lle-bout: civodul: thanks will look! soda__hobart: in C, how can i look up a procedure that i loaded and evaluated with scm_c_primitive_load? i have a little test func: (define (say-hi) (display "hi\n")). i tried using scm_c_lookup ("say-hi"), but when i try to use scm_call_0 using the output of scm_c_lookup, i get this error: Wrong type to apply: #> RhodiumToad: so as I understand it, scm_c_lookup returns the variable, not the value RhodiumToad: scm_c_private_ref or scm_c_public_ref might be better? dsmith-work: ISTR using SCM_VARIABLE_REF soda__hobart: oh, that makes sense... i don't see SCM_VARIABLE_REF in the procedure index (dunno if i could use it runtime anyways?)... but for scm_c_public_ref, what would be my module name? is it strictly necessary to define a module or can i just use the evaluation environment created with scm_init_guile? RhodiumToad: you could use scm_public_ref(scm_current_module(), scm_from_utf8_symbol(name)) to look up in the current module soda__hobart: oh cool. looks like scm_variable_ref (scm_c_lookup ("say-hi")) worked too RhodiumToad: yes, that's the same thing under the hood soda__hobart: well thanks! i would have been running around in circles for a while dsmith-work: SCM_VARIABLE_REF is a macro. No error checking like in the scm_*_ref functions. soda__hobart: IM_NOT_YELLING_THIS_IS_A_MACRO stis: hey guilers! stis: just got python 3.10 match statement working stis: in guile prolog *: stis is a match fan stis: in guile python it should be dsmith-work: stis: Is the new Python match anywhere near close to the match in Rust? stis: not so familar with rust. but it is a wecomed addition to python. probably there will be a lot of improvemets to it in the nextreleases stis: took me a day to implement it stis: it has ... or,and sequence and mapping and class matching stis: not =,? stis: a guard as well stis: not =,? is missing in ice-9 mtch lingo stis: much cleaner code in many instances already soda__hobart: there's guile prolog? stis: soda__hobart: yes stis: pretty big and targetting swi-prolog compability but with fun extensions dustyweb: pkill9: I'm not sure what you mean by list metadata pkill9: eg list in the metadata pkill9: like you have title, date pkill9: one of those but instead of a string, a list chrislck: have a list of records instead of strings rekado_: pkill9: a common way to annotate lists is to use keyword lists rekado_: e.g. '(#:title "My Title" #:date (current-time) #:text "Once upon a time…") rekado_: sorry, needs quasiquoting: `(#:title "My Title" #:date ,(current-time) #:text "Once upon a time…") pkill9: oh nice pkill9: so how would you use that? leoprikler: depends on what you're planning to do in the end leoprikler: e.g. format, write to sxml, … nly: hi dsmith-work: Tuesday Greetings, Guilers ArneBab: wingo: is there a way for the lilypond folks to change the optimization level (to maybe benefit from the baseline compiler)? it looks like they are using compile-bytecode from module/language/tree-il/compile-bytecode.scm Bumblehorse: Is there a function for adding up a list of integers? Right now I am doing something like this: (fold + 0 '(1 2 3)) which returns 6. RhodiumToad: (apply + '(1 2 3)) Bumblehorse: Oh geez, I thought that worked like map. Thank you RhodiumToad: + takes any number of args and returns the sum lle-bout: hello! how can I get more precise line information for syntax errors? lle-bout: I get something like this: https://bpa.st/raw/QHPA lle-bout: I am unable to find the error manually stis: sometimes you are left with commenting out stuff in the scm file stis: guile is lacking sometimes whenerror reporting janneke: to state the obvious...sometimes git diff helps stis: yes all these debugging skills are useful when the tool is not supporting you lle-bout: janneke: I have been using git diff to find it for hours already :-S lle-bout: I can't comment stuff there's too much janneke: lle-bout: oh, that's terrible lle-bout: I would need something like bisect but for individual patch hunks lle-bout: janneke: going to commit everything and bisect lle-bout: commit everything as individual commits lle-bout: what a rough day janneke: lle-bout: sometimes it's just that way, good luck wingo: evening lle-bout: wingo: hello! :-D wingo: hi :) *: wingo pokes at cross-module inlining RhodiumToad: I see that FSF can't resist playing with the foot-howitzer again wingo: it's amazing isn't it pinoaffe: RhodiumToad: if it wasn't oh so deeply saddening I would be laughing right now lle-bout: wingo: in JIT? wingo: lle-bout: no, AOT zzappie: RhodiumToad: Im too curious not to ask what are you refering too wingo: for a subset of declarative definitions davexunit: RhodiumToad: yup, the board is hopelessly out of touch. I feel bad for the staff. wingo: zzappie: apparently rms is back on the fsf board of directors. a bit of a confusing situation, with no official communication from the fsf afaik, but private communications that appear to confirm this is the case lle-bout: janneke: weirdly after committing it seems the error has disappeared wingo: there is a fair amount of organizing about it, cf https://rms-open-letter.github.io/ lle-bout: I discarded some commits that didnt apply though.. davexunit: my experience is from 6 years ago now, but working at the fsf was eye opening in an unfortunately bad way. lle-bout: I mean, did apply in the patch sense but were incorrect zzappie: wingo: oh! Wow this is unexpected. At least for me davexunit: fsf staff are unionized but there's no power there. it basically just kept rms from arbitrarily firing people when he was president. janneke: lle-bout: good :) lle-bout: janneke: my wrist hurts lle-bout: GNU Guile lack of error reporting caused actual physical pain, I have at least one documented case janneke: well... wingo: lle-bout: apologies! we should make a point release that focusses on improving errors :) lle-bout: janneke, wingo: it was a it of a joke heh do as good as you can but better error reporting welcome :-) wingo: :) lle-bout: wingo: I wonder what the tooling is for inline documentation in GNU Guile code, I feel like that's the best way to maintain documentation, e.g. how Rust communities do it lle-bout: It would be awesome if we got self-documented GNU Guix core if not package code janneke: lle-bout: yes, i got that...and i know the experience of feeling glued to the computer until it's fixed janneke: i feel a lot better, though, when i manage to break such a streak and take a break in time lle-bout: I mean I got my wrist hurting due to making so many commits manually to use bisect lle-bout: hands moving around in repetition lle-bout: 117 commits janneke: wow daviid: janneke: I have a copy of define-method*, slightly changed, it was written by Mark ... daviid: changed to use receive, not let-values, which unlike others :),I do find much better then any other *values forms ... daviid: janneke: here https://git.savannah.nongnu.org/cgit/grip.git/tree/grip/goops.scm#n62 (a comment to credit Mark at the beginning of the file, line 26 ... daviid: i should add this and other goops utilities to guile-lib really ... one day i will janneke: daviid: thanks, yes that't it! janneke: fwiw, i also liked receive best until i discovered srfi-71 ;) janneke: iwbn to have this in goops daviid: janneke: Mark was a maintgainer when he wrote it, I think that it is because it is not part of the (clos) protocol, that he didn't want to add it in guile 'proper', don't know mbakke: srfi-71 changed all my scripts overnight :P leoprikler: lle-bout: there are a few ways of leveraging texinfo to do your formatted/unformatted inline documentation soda__hobart: ok, i have a guile procedure defined in C/C++ where i allocate some memory on the heap to initialize a struct, and return a SCM pointer object using `scm_from_pointer`... i do some stuff with it (serializing to bytevector and sending thru socket), then i call another guile procedure (also defined in C/C++) where i call scm_to_pointer on the SCM pointer obj, and then free this pointer and return SCM_UNDEFINED. soda__hobart: am i leaking memory there? it seems that i am soda__hobart: i initialized the struct with regular malloc, not scm_gc_malloc leoprikler: I think in that way it should be safe, but you ought to think about non-local exits. leoprikler: I.e. if you go the full way of malloc → scm_from_pointer → scm_to_pointer → free, there should not be a leak, but note, that the second half seems to be manual in your case (which we don't really like here in garbage collector land) leoprikler: also I'm assuming here, that "free" is an appropriate way of deallocating all the resources acquired by your struct soda__hobart: i think it is, but i need to do more research on that soda__hobart: i have a char* data element, but just using htop, it looks like i'm leaking even when i don't initialize that member soda__hobart: however, for the C/C++ program that receives that data, i know from using valgrind that i'm leaking memory leoprikler: I think you have two potential leak sources here and you should focus on each individually leoprikler: First, check the malloc to free route on its own, then do the socket stuff extra. soda__hobart: yeah, i think that is a good idea leoprikler: also manually invoking (gc) might help detect cases in which the memory is only growing because you're too lazy to recall it :P Formbi: hi Formbi: why isn't the default map tail-recursive? civodul: Formbi: mostly because it's unnecessary with expansible stacks civodul: they achieve the same thing as having an explicit accumulator civodul: the downside is that backtraces with 'map1' are a bit ugly Formbi: doesn't it use more memory? chrislck: more memory in the stack, less memory in accumulator chrislck: accumulator also uses memory Formbi: hmm, I think the memory consumptions should be compared chrislck: plus, the accumulator will need to be reversed when completed. not so when using the stack. wingo: good morning civodul: o/ janneke: \o lampilelo: \o/ chrislck: /o\ mbakke: o7 *: wingo has a design for cross-module inlining, whee davexunit: wingo: exciting! sneek: Welcome back davexunit, you have 1 message! sneek: davexunit, manumanumanu says: I have been working on a wrapper around srfi-64 that implements a large chunk of (chibi test)... dsmith-work: Hey Hi Howdy, Guilers leoprikler: Am I the only one, who finds it funny, that the reference implementation of SRFI 223 contains exactly the kind of bug they were supposed to defend against? davexunit: oopsy daisy Aurora_v_kosmose: rip manumanumanu: leoprikler: which one? leoprikler: (low + high) / 2 rlb: I'm wondering why something like string-append has to scm_remember_upto_here_1 the individual strings, i.e. how could we lose track of them if they're in the argument rest list? rlb: (Asking because preserving that wrt utf8 strings might be a little more work.) manumanumanu: leoprikler: It has been a long time since I implemented a binary tree (I have two implementations I wrote about 11 years ago; one functional and one imperative). Should it floor? Shold it add 1? I don't remember. leoprikler: manumanumanu: (low + high) can overflow. This is typically not an issue in Scheme, because it just gets promoted to bignum, but the key is, that it shouldn't need to be promoted leoprikler: rlb: the rest list itself – or at least parts of it – could be discarded as you iterate manumanumanu: oh, but for a reference implementation clarity is king. rlb: I thought anything that was a C side argument was preserved throughout the call. rlb: i.e. if we have foo (SCM x) { ... } anything referred to by x will persist until foo returns? rlb: And since it's a rest list, no one should be able to destructively modify it to drop refs? leoprikler: uhm, no? leoprikler: you can drop x if it's no longer on the stack at any point leoprikler: the C optimizer can do that rlb: At least in our docs: "Guile's garbage collector will automatically discover references to 'SCM' objects that originate in global variables, static data sections, function arguments or local variables on the C and Scheme stacks, and values in machine registers." leoprikler: *on the C stack* is important here rlb: SCM is "function argument" in this case. leoprikler: if you pass arguments through registers and the compiler decides that the argument is no longer used → boom leoprikler: arguments on the stack is a full sentence :) leoprikler: why else would the example have scm_remember_upto_here_1 (file); // file is an argument leoprikler: the manual explicitly tells you, that this can happen RhodiumToad: personally I'm not convinced that the gc can actually operate correctly in all cases, given the amount of freedom the compiler has RhodiumToad: in particular the compiler can (and modern optimizers actually do) represent a pointer value by means of some offset rlb: Yeah, I wasn't looking at that page -- and clearly I've misremembered part of the requirements. Though I still wonder about a rest list to a SCM_DEFINE, i.e. I'd have assumed that pointer is held on to throughout the call by the caller. rlb: i.e. the code that constructed the rest list, but that might also just have been a vague incorrect guess. rlb: Is it at least a safe assumption that a rest list can't be modified (from outside) during a call? rlb: (I *think* that's probably true?) RhodiumToad: why are you bothering about this? RhodiumToad: you should probably assume that the compiler and optimizer will actively break things, and be as defensive as possible about it rlb: because with utf8 strings, it'd be more efficient if we can compute the strinbuf offsets (start and end) for each string as we make the first pass in string-append and then use those to build the final result, than if we have to do that twice (if we can't assume things won't change) rlb: (we have to compute the offsets in the first pass to get the total byte count -- similar to the approach for current strings) leoprikler: how can you be sure that the strings themselves won't change between computing the offset and concatenating the strings? leoprikler: [in an MT environment] rlb: Yeah, that's what I'm working on -- one option I was thinking of was to capture the stringbufs and offsets up front, and then traverse that. Since the stringbufs are immutable. rlb: Of course if I do that, then some aspects of my other questions don't matter. pkill9: dustyweb: how can I add a list metadata? with a quote? e.g. '("listitem1" "listitem2") ? pkill9: hmm actually the nicest would be yaml mwette: /quit dustyweb: pkill9: hm, I haven't actually demonstrated it anywhere in my own stuff... I've been putting tags in the markdown files but not actually exposing them dustyweb: so... not really :) dustyweb: but I know Haunt does recognize them chrislck: are the mingw hackers targetting mingw-w64 by any chance? spk121: chrislck: there's a patch on guile-devel we're working on for mingw-64. If you want to see how it is going, or try it out janneke: spk121: i can't find a link to it, but wingo suggested instead of janneke: > 813 - unsigned long bit_count; janneke: > 813 + scm_t_unum bit_count; janneke: in arrays.c, to use [s]size_t (and not uintptr_t) janneke: which makes sense, i think janneke: while doing such a big change, iwbn to get it right, and not have to change it again ;-) fnstudio: hi, i'm taking the first steps into the world of design for flexibility and i have a question around "(lambda (args) ..." vs "(lambda args ..." fnstudio: minimum example: https://paste.debian.net/1190238/ (it's a simple example, no spoiler alert needed with regard to the book's exercises) fnstudio: i suppose that "lambda args" may be preferred in so far it gives more flexibility with regard to the number of arguments? whereas with "(args)" then args has to be exactly one value? stis: Hi guilers! rekado: fnstudio: yes, (lambda (args) …) requires exactly one value, wherease (lambda args …) binds the argument list (even if it is empty) to “args”. fnstudio: rekado: i see... thanks, yes i think i can see it more clearly now, and "args" probably makes things a bit easier down the line fnstudio: also explained very well here: https://www.gnu.org/software/guile/manual/html_node/Lambda.html fnstudio: "formals" can be "(arg1 ...)", "args", or "(arg1 ... argn . argn+1)" spk121: janneke: yeah, size_t there makes sense,. That's what that array macro returns janneke: i'll change that janneke: spk121: but now i'm wondering about the laest: scm_i_inum => intptr_t, unsigned long long => uintptr_t janneke: shall we use size_t and ssize_t instead? spk121: what are your thoughts? spk121: If one were to try to take advantage of the implied meaning of the C types, intptr_t would be held specifically for integers that might contain pointers, while size_t would be only for indicating the memory size or count of things. janneke: ah, yes -- seen that way, intptr_t makes more sense spk121: For those things that were neither integers-holding-pointers, nor the memory size of things, it should really be long, long long, int64_t, or whatever spk121: Theoretically, if we janneke: yes, i agree spk121: have disambiguated everything into int-holding-pointer, size, or "regular" integer, it should not be a problem to keep the "regular integer" longs in most cases. It is just that, from my point of view, doing that disambiguation is rather tricky janneke: yes janneke: changing some intptr_t back to long is going to be somewhat tricky, we'd have to be very careful not to truncate on mingw 64bit spk121: For 32-bit platforms, those longs do work. I still build guile on at least one 32-bit platform. It is the truncation of integers that is a problem, as you say spk121: Can we get a compiler to do the hard work of detecting improper casts of integer size? Some combination of warning flags? leoprikler: w.r.t. cross-compiling Guile libraries, how does detection of $(host) work? leoprikler: i.e. for guild compile --target janneke: in an autoconf setup, configure just picks up --host janneke: then you do something like janneke: if test "$cross_compiling" != no; then janneke: GUILE_TARGET="--target=$host_alias" janneke: AC_SUBST([GUILE_TARGET]) janneke: fi janneke: and use something like guild compile $(GUILE_TARGET) ... spk121: janneke: so here I am digging into gcc options, and I came across one called "-mlong64" which forces longs to be 64 bits janneke: spk121: that's interesting... leoprikler: hmm, I just figured, I'd always get $(host) set if I use AC_CANONICAL_HOST janneke: regtur asked me about that, and i dismissed him saying that all system headers/libraries would be incompatible with the rest of mingw/windows then, but... leoprikler: just compile all of it with -mlong64 and it's fine :) leoprikler: inb4 short long leoprikler: alias long short janneke: yeah, it may just work janneke: but makes you wonder, if there's such an easy and obvious solution, why would gcc not have that option on by default spk121: doh! Looks like it is MIPS only janneke: there surly must be a strong case (use case) for th long=4bytes thing janneke: ah janneke: yeah, i mean it's extra work for the gcc folks to make long=4bytes on mingw tohoyn: janneke, leoprikler: may be you should see dpkg-architecture janneke: they cant' be all totally mad? leoprikler: I think "long"=32 bits is historical, since back then int=16 bits spk121: 32-bit long will still be allowed by the upcoming C23 standards janneke: leoprikler: yes, you can probably use --target=$(host) leoprikler: Well, the C++ committee can't really single-handedly decide Microsoft to be stupid, when Microsoft sits in the committee :) leoprikler: hmm leoprikler: would be funny if someone invented a programming language, where all data types are just bit fields of size 2^N. leoprikler: N defaults to 32 and you double it by declaring something "long" and halve it by declaring it "short". leoprikler: but you have to declare at least one :) leoprikler: so to have a default int you'd have to write "long short foo" *: janneke puts up arrays.c change for wingo https://gitlab.com/janneke/guile/-/commit/b587e04e6b0e0fe37cb8774609a51ac7e04127a5, also mailing v3 fnstudio: hi, is there any particular channel that's being used for discussing and "socialising around" the new book "software design for flexibility"? spk121: ok, new plan. Let's re-write Guile in ADA. janneke: oh great! be sure to also write an ADA compiler that can be bootstrapped, so that we can have the new Guile in Guix ;) spk121: no problem! fnstudio: what's the difference between define and let when locally defining a procedure within another one, eg in this example https://paste.debian.net/1190256/ fnstudio: i thought i have some background on what the difference is, at a general level fnstudio: but then i found a snippet where "define" is used where i'd have used a "let" instead leoprikler: local defines are equivalent to letrec with less indentation fnstudio: leoprikler: oh ok, great, thanks, so no differences in terms of scope for instance, etc; would it be sensible to say that one is syntactic sugar for the other? leoprikler: pretty much, yeah leoprikler: if you observe anything else, that's a bug fnstudio: leoprikler: i see, fantastic, tx! fnstudio: (oh today i learned mit/gnu scheme is not guile, how naive of me) roptat: any idea where this guile.am comes from? It seems to be copied from project to project, but there's no copyright/license information: https://github.com/wingo/fibers/blob/master/build-aux/guile.am leoprikler: reverse git search ;P civodul: roptat: probably from 'am/guilec' in Guile civodul: there's little originality in this file though (the main criterion to decide whether it's copyrightable) roptat: ah right, I recognize some of it, slightly modified roptat: I just watched the talk about reuse this morning at libreplanet, and they were copyrighting even .gitignore rlb: Right now a "shared" string has a start index, and that start index has to be added to the underlying shared string's index to compute the real offset in the underlying buffer, but can those indexes (offsets) ever change? If not, I thought I might just add them when creating the shared string, so we don't have to repeat the computation all the time. i.e. shared strings would have an absolute index into the (indirectly) underlying rlb: stringbuf. *: stis is improving the guile python repository. Bug after bug after bug .... *: janneke may have fixed the "Fix 'absolute-file-name?' and others..." spk121: I'm not sold on the idea that we have different 32-bit and 64-bit representations of a hash. (actually 30 and 62 bit). Either 30 bits is enough, or it isn't RhodiumToad: it usually isn't janneke: i wondered about that too janneke: i tried without patchin hash.c, but that "didn't work" janneke: i figured that it may have to do with the sizes of fixnum having to be equal to the hash size, for some reason, but i don't know janneke: it's "interesting" that "long" was used before, and not "int", if 30 bits are always ok? spk121: anyway, when guessing semantic meaning to the various integers in Guile that appear in your patch, one big category is 'hash value' which apparently needs to be scm_t_inum sized. It is inum sized when created by JENKINS_LOOKUP3_HASHWORD2 spk121: or rather it is *intended* to be scm_t_inum sized, but is actually unsigned long size when passed around janneke: hmm; it has this janneke: janneke: if (sizeof (ret) == 8) ret = (((uintptr_t) c) << 32) | b; janneke: and if there isn't uintptr_t, but long, shift is problematic spk121: yeah janneke: but possibly we can change the caller, i.e. "ret"? janneke: hmm, that's only narrow_string_hash and wide_string_hash janneke: and it's a whole chain... janneke: could it be that (something like) this: janneke: case scm_tc7_pointer: janneke: return scm_raw_ihashq ((uintptr_t) SCM_POINTER_VALUE (obj)); janneke: is why we need the hash bits to be pointer-sized? spk121: I think, for symbols, it is because it gets packed into an scm_t_bits size word in scm_double_cell in scm_i_make_symbol spk121: for scm_tc7_symbol janneke: ah, that makes sense spk121: So there are two hashers. JENKINS for string-like things, scm_raw_ihashq for everything else. Both return unsigned long intending to an scm_t_inum spk121: I think, just for fun, I'll see what happens if I make an scm_t_hashval type and trace it through the code janneke: that's great, thanks for looking into this! wingo: o/ janneke: \o stis: \o/ wingo: haha, just realized that all the tree-il accessors are procedures-with-setters wingo: that's special :) wingo: hooo, it seems that the accessors also don't check the type of their operand wingo: yolo janneke: initially, mes didn't check anything, not even the if the parameter count to procedures matched janneke: i would test everything by running it on guile anyway, right? janneke: that was one on the worst decisions and it cost me a lot of time until i corrected that ;-) spk121: fun fact. in weak-table.c, hash values are converted to buckets by using modulo. In cache-internal.h hash values are converted to buckets by using a mask of the low bits *: wingo writes a tree-il codec wingo: yaaargh, i managed to unify three record type representations in guile (conditions, r6rs records, core records) but not (system base syntax) records wingo: gah wingo: ah no it's that the "core vtables" mechanism doesn't produce vtables of the right shape... wingo: yarr rlb: wingo: and goops instances? *: rlb still hopes to unify records and class instances wrt method specializations. wingo: goops instances are not unified right now rlb: progress at least, perhaps. rlb: I imagine we're not changing the long/intptr_t/etc. stuff in any public apis, or that'll just go into 3.2 or 4.0? wingo: yeah at least going in the right direction. goops is so peculiar that it would be nice if it could somehow absorb records -- i.e. treat a record type as a class in all places -- but without forcing the class representation down into core records. but i don't know what would be needed. wingo: rlb: yeah exactly janneke: no public apis are changed rlb: cool rlb: wrt classes, yeah, I'm not very knowledgeable there yet, just mostly experienced that bit from the end-user perspective. janneke: i believe i saw a patch that added keyword parameters to methods, any ideas where that might be or who wrote that? janneke: spk121: just a heads-up, my latest patch doesn't compile on mingw, mini-gmp.c needs to include stdint.h explicitly *: janneke pushes a fix and starts another guile-patched,guile-mingw build janneke: fun, i was attempting to test my absolute-file-name? fix spk121: janneke: sadly, I've run out of time for this for now, but, I've learned a lot about guile's hashes and hash tables today janneke: spk121: while it would be nice to have this in 3.0.6, i'm not at all in any hurry janneke: thanks a lot for looking into this, there is time *: janneke -> zZzz alextee[m]: im reading guile's website and it says: In addition to Scheme, Guile includes compiler front-ends for ECMAScript alextee[m]: is this like javascript? alextee[m]: and does this mean that if my C code supports running Guile scheme I can also pass it a piece of javascript code and it will run as well? alextee[m]: also "support is underway for Lua" this sounds great too but same question alextee[m]: my code basically does scm_call_0() on a function returned by scm_c_lookup() daviid: alextee[m]: ECMAScript - https://en.wikipedia.org/wiki/ECMAScript alextee[m]: heh, was just reading that alextee[m]: so is it like scheme so that if you define a function in ECMAscript like "myfunction" then scm_c_lookup() on "myfunction" and scm_call_0() will work? daviid: alextee[m]: no idea, others will shime in hopefully ... rlb: alextee[m]: I'm not sure how easy it'll be to do whatever specific thing you have in mind, but yes, guile does support different dialects, including elisp and "javascript", though I suspect the dialects vary in features/completenes. In case you hadn't seen, you can switch languages at the repl:. rlb: $ guile rlb: ... rlb: scheme@(guile-user)> ,L ecmascript rlb: Happy hacking with ECMAScript! To switch back, type `,L scheme'. rlb: ecmascript@(guile-user)> rlb: ecmascript@(guile-user)> 2 + 2; rlb: $2 = 4 rlb: alextee[m]: I see rlb: Of course integrating that with whatever else you're doing may require more. alextee[m]: well I'm mostly interested in extensibility for my app using user scripts rlb: I'm familiar with some of it since I've been working on a clj dialect, but I don't know much about the ecmascript support. alextee[m]: i already support scripts written in scheme and it seems to work pretty well rlb: Right, that should "just work". alextee[m]: but is the scm_call_*() api targeted at only scheme? or is it supposed to work with user scripts in other languages like ECMAscript? rlb: Not sure for js -- for my dialect, it'll work perfectly. rlb: i.e. the way I arranged things, a clojure namespace *is* a guile module. alextee[m]: yeah I'd assume if this worked you'd have to write the code in a specific way to mimic modules and stuff rlb: And there's no difference atm between a clojure defined function and a scheme defined function in terms of binding, invocation, etc. They just do different things when called. alextee[m]: would be nice to have example scripts somewhere in various languages rlb: There might be, just don't know too much about the js side. rlb: atm rlb: But you could also probably use the "language tower" functions, but I'll have to go look that up for you, and might not get to it until later, but feel free to ping me if I don't get back to you in a day or so (assuming someone else doesn't). rlb: Oh, and if the js side just binds the js functions in a guile module, then the call functions might work fine, plus or minus getting the right data types for args (if any of those are special). rlb: (after you get the fn ref from the right module) rlb: alextee[m]: bits in the general area: https://git.savannah.gnu.org/cgit/guile.git/tree/test-suite/standalone/test-language?id=de5d1a7f99b8e952b115237ebc29633062f99bb https://git.savannah.gnu.org/cgit/guile.git/tree/test-suite/tests/ecmascript.test?id=de5d1a7f99b8e952b115237ebc29633062f99bb rlb: And the implementation is here, which might or might not be useful: https://git.savannah.gnu.org/cgit/guile.git/tree/module/language/ecmascript?id=de5d1a7f99b8e952b115237ebc29633062f99bb rlb: But yes, completely agree we could do with more elaborate documentation on that front. alextee[m]: rlb: these give some clues, thanks! rlb: also definitely https://www.gnu.org/software/guile/manual/html_node/Using-Other-Languages.html alextee[m]: my idea of guile (at least from the website and GNU pushing it as an extensions language) is that it's main purpose is for extending programs so yeah it would make sense to have some more docs on that front rlb: And note that guile can compile not just to a file (for future execution), but also to an actual "live" function, etc. that you can call. I believe that's mentioned in the info pages somewhere too. rlb: alextee[m]: yeah, as a simple example, this works: rlb: scheme@(guile-user)> (use-modules ((language ecmascript parse) #:select (read-ecmascript))) rlb: scheme@(guile-user)> (compile (call-with-input-string "2 + 3;" read-ecmascript) #:from 'ecmascript #:to 'value) rlb: $1 = 5 rlb: rlb: Basically just a distilled version of what ecmascript.test is doing, but perhaps gives you a general idea. alextee[m]: ah, maybe i could just wrap scripts written in ecmascript in a guile script that does that with the string.. rlb: ...worst case, you could perhaps do a read-compile-eval loop on the input file, but there might be a better way. rlb: rather read/compile/call or whatever. rlb: But assuming js supports it (and it may), you could also compile to files first (timestamp based or wahtever as scheme and the clj dialect do), and then load the compiled code. That'll be more efficient for static files of course, if it suits. rlb: alextee[m]: here's how lokke does that (in a very hacked up way) right now: https://git.sr.ht/~rlb/lokke/tree/main/item/mod/lokke/ns.scm#L170 rlb: The real work happens, after the timmestamp checking, in "compile-it". alextee[m]: interesting, i'll dig around a bit more, thanks! rlb: certainly apteryx: daviid: hi! by the way, what was the reason you didn't like this patch? https://mail.gnu.org/archive/html/guile-devel/2021-03/msg00009.html apteryx: that change was catering to Guix, which is more demanding in terms of Guile path installation customization: it uses a versioned site dir (e.g.: share/guile/site/3.0) that is non-standard apteryx: interesting this gets it right without any configuration, even on Guix: https://github.com/aconchillo/guile-redis/blob/master/configure.ac apteryx: it relies on pkg-config apteryx: with guile-lib, I don't currently have a mean to configure it for Guix without resorting to hacking the build system files; out of the box it installs the souces to the non-versioned $datadir/guile-lib; when using --with-guile-site=yes it tries to install to Guile's own location, which fails on Guix as packages are individually prefixed and not writable apteryx: anyway, I'm happy with the release, but I thought I'd try to explain the rationale behind the patch 6 linked above apteryx: thank you! daviid: apteryx: did you read the commit message and comment about the changes introduced in 0.2.6? apteryx: Yes I've done so before writing the above; perhaps I've missed an important bit? apteryx: it's late here... daviid: apteryx: hum, the reason, I was hoping, for the changes i introduced in 0.2.6, based on a few valid users claims, fix the situation, which your patch would bring us back to, which for me, is a severe gregression daviid: apteryx: *regression apteryx: the patch didn't change the default behavior of the configure script but provided more knobs to tweak, or at least that was the idea daviid: apteryx: the problem is, in the absence of any configure option, that the package isntalls itself following the gnu coding standard, that is outside guile's tree and in $prefix blabla, all this is weel explained in the commit, the release and in the daviid: INSTALL file apteryx: I agree that the default when not specifying any configure flag should following the GNU standards, but unless I'm missing something the patch was not touching that default *: apteryx checks daviid: apteryx: there is no need to patch guile-lib wrt to all this daviid: it is perfect as it is - the only discussion we may have is about the versioninng or none versioning location when the option is given, i think any guile scheme code that is agnostic must be installed in the guile's global site dir, hence what i did apteryx: OK; I see flexibility as a win, but perhaps the added complexity was not worth it if Guix is the only user, this I can understand. apteryx: We'll have to keep a simple patch in Guix, that's all. apteryx: thanks for the discussion daviid: apteryx: let's agree to disagree, and hack on more important things, but thanks for the patch - on the form though i thought it wuld have been nice if you did talk to me or us here, it would also have saved a of your pressious time ... apteryx: sure, I can check here before writing something new in the future, to gage the interest/pertinence of it. apteryx: bed time here :-) apteryx: o/ daviid: apteryx: tx, talk to you later... daviid: good night manumanumanu: sneek: later tell davexunit I have been working on a wrapper around srfi-64 that implements a large chunk of (chibi test)... sneek: Got it. apteryx: daviid: I've made one last check with a fresh mind, to make ensure what I said yesterday is accurate, and it seems to be: the default install directory is unchanged with patch 6: https://paste.debian.net/1190139/; so even withouth the new switches, at least you may want to drop the m4/guile-ext.m4 file, which appears redundant with guile.m4. mwette: apteryx: I have some examples of running multiple lang's in guile. git://git.savannah.nongnu.org/nyacc.git or https://download.savannah.gnu.org/releases/nyacc/ mwette: apteryx: unpack, cd examples; source env.sh; then start guile; ,L nx-javascript or ,L nx-mlang or ,L nx-tcl ; mwette: apteryx: I also have an old patch to support loading files in different languages: https://github.com/mwette/guile-contrib/patch-2.2.4/load.patch yoctocell: Hi, has anyone had exprience with guile-wm? I looks like a cool project but doesn't seem to be maintained anymore :( mwette: yoctocell: yea looks cool, but also requires xcb, which looks cool too mwette: and guile-xcb has xcb/xml/sample/tiny-wm.scm which is a sample WM yoctocell: mwette: Nice, are you running it? mwette: no, just took a look inspired by you mentioning it yoctocell: ah, ok stis: ' stis: Hi guilers! stis: Hi prologurs! spk121: hello janneke spk121: janneke: I'm about to pull these patches, and I wonder if the mingw patch might be simpler if scm_t_inum -> intptr_t spk121: although I guess a lot of these functions are SCM_API, so that would be a theoretical, (but not real) API break spk121: I take that back. You didn't change any SCM_API functions, so that makes it simpler daviid: apteryx: i won't remove guile-ext.m4, which holds aditional defs that are not in guile.m4 ... gurjeet: Any guile + Nix[OS] experts, can you please take a look at this issue I'm experiencing. https://github.com/NixOS/nixpkgs/issues/117042 gurjeet: ^^ I'm essentially trying to build GnuTLS _with_ Guile bindings, but the build command fails. spk121: gurjeet: this is a known problem with 3.0.5, and there is a patch for it in the soon-to-be-released 3.0.6 mwette: gurjeet: I had issues w/ gnutls --enable-guile on macos. I ended up needing to first build/install w/o --enable-guile then redo w/ --enable-guile. I think when libgnutls.so is in the build dir the guile module does not see it. gurjeet: spk121, the latest in nixpkgs is 2.2, I believe. Even if it is some other version, I am explicitly asking for 2.2 to be used in my patch to Nixpkgs. spk121: gurjeet: oh, sorry. I've got no idea then mwette: IIRC gurjeet: mwette, thanks for the hint. Given that nix-env command tries to build in a clean environment, so I don't know how to make the second invocation of nix-env command to use the output of the first invocation. apteryx: mwette: thank you for the multiple lang examples! apteryx: daviid: OK! mwette: gurjeet: Can you maybe update appropriate env vars (e.g., LD_LIBRARY_PATH) to point to where the file is built prior to install? mwette: apteryx: yw gurjeet: spk121, sorry I misunderstood your message. I'm trying to use _Guile_ version 2.2. The GnuTLS version being built is 3.6.15. gurjeet: Did you mean to say 3.0.5 has a known issue. Did you mean to say 3.5? Which latest version of GnuTLS is known to produce Guile bindings? I'll try to use that specific version of GnuTLS. apteryx: daviid: guile-ext.m4 provides these two macros: GUILE_GLOBAL_SITE_DIR and GUILE_SITE_CCACHE_DIR; the first one can be replaced by GUILE_SITE_DIR from guile.m4, and the second one by GUILE_SITE_CCACHE from guile.m4. Seems we're covered? apteryx: the only difference is in how they are implemented; guile-ext.m4 queries guile itself, while guile.m4 uses pkg-config lispmacs: hi, I was looking for an easy way to plot 3d plots of complex functions of time lispmacs: I was wondering if anybody had any ideas with guile or some other tool lispmacs: I was checking with the maxima guys in another channel lispmacs: like f(t) = e^(st) where s is a complex number rlb: lispmacs: no idea specifically, but of course there's gnuplot, matplotlib, and the whole python/jupiter notebook world. rlb: ...wrt to "jupiter" that might be https://jupyter.org though I think it may have become somewhat of a more generic term. lispmacs: lispmacs: lispmacs: durned kids lispmacs: kl dfs wingo: :) *: wingo grumbles that gitlab seems to prohibit icecat users civodul: wingo: oh yeah, i noticed that too heloaoba1: is there an equivalent in scheme/guile to python's os.path.join for safely joining path components? wingo: apparently installing a user-agent-switching extension and pretending to be firefox 82 or 83 rather than 78 is enough to get by civodul: good to know! janneke: spk121: if intptr_t makes it simpler, then by all means wingo: janneke: do you mind if i review your patch on gitlab? janneke: wingo: i'm not sure how that works, i think i would prefer emacs/email; i'm a bit clumsy with webby clicky things; but please do what works for you! janneke: wingo: also, please feel free to "just change things" as you like, if that makes it easier for us janneke: i'm primarily happy that i found a way that works wingo: ok. well i guess a first-order feedback would be that when converting SCM inums to C integers, intptr_t is the good type i think wingo: civodul: does that sound ok with you? janneke: sure, i doubted between long long and intptr_t janneke: it seems sometimes "long" means: an int where a void* (or int*) fits, and on other times it seems to mean: the largest integer type (something like: long long) wingo: yeah what a mess janneke: on the one hand, the extra types do not help, on the other hand i liked having a signed and unsigned pair wingo: there is uintptr_t fwiw janneke: (unsigned long long) => scm_t_unum, (long long) => scm_t_inum janneke: okay...yeah janneke: so yuck in a way to scm_t_inum,/unum; nice in an other way... yes, a mess wingo: :) wingo: fwiw i think unum is probably not a good name because of https://en.wikipedia.org/wiki/Unum_(number_format) janneke: and then we also have scm_t_bits and scm_t_signed_bits! wingo: :) janneke: ah...hmm wingo: i guess i am generally hoping that stdint.h types can satisfy our needs. it's hard enough doing C integers without introducing new types whose definition isn't obvious janneke: yes, i agree janneke: so, we go for scm_t_inum => intptr_t, and scm_t_unum => uintptr_t civodul: wingo: fixnums to intptr_t sounds good to me wingo: janneke: sounds like a plan! janneke: great, i'll do that first and see how that goes! janneke: i'm kind of happy that we don't have to introduce new types, feels a lot better if that works janneke: thanks! *: janneke wonders whether that will also work for mini-gmp, intptr_t and uintptr_t; guess i'll try to do it there too pkill9: dustyweb: do you have an example of how to organise pages into categories and/or tags in haunt? daviid: apteryx: there is no need to change anything there, and certainly not removing guile-ext.m4, i told you yesterday, please move on to something else, tx janneke: wingo, spk121: updated patch, sent v2 to guile-devel spk121: janneke: of the patches, the only one I don't think could be pushed is "Fix 'absolute-file-name?' and others for cross-build" There some sort of order dependency. If I modify boot-9 after and rebuild, it fails. The rest could go, after pulling out _mingw_debug_p. I'm so glad you took the time to work on this sad errand. spk121: You're amazing spk121: Building on MinGW is slow, so testing the patches took forever... janneke: spk121: yes, i just found that "Fix 'absolute-file-name?' " is broken, at least partially janneke: i'm pretty sure it worked it the mingw cross build, but i could have fooled myself there... janneke: maybe it only breaks while BOOTSTRAP'ping? janneke: before, i had this "HACK boot-9.scm: hard-code absolute-file-name? ..."; i was so glad i thought i fixed it properly...oh well :) spk121: janneke: it would not surprise me if it were different in bootstrap janneke: yeah, i only tested it out-of-band, in a foo.scm file spk121: But let's get the rest of patches is master. I'll try it all again after dinner. janneke: lovely, thanks janneke: enjoy your dinner, ... *: janneke -> zZzzz stis: sneek later tell manumanumanu: https://gitlab.com/guile-scsh/guile-scsh sneek: Okay. stis: \me is working on guile python again, trying to find bugs and follow spec as close as possible stis: wondreing if I shall use type hints to improve speed as well apteryx: is this a valid let*? https://git.savannah.gnu.org/cgit/guix.git/tree/guix/import/utils.scm#n454 apteryx: seems to me like it should have been a let*-values or something daviid: apteryx: the module uses srfi-71 ... manumanumanu: ahoy sneek: Welcome back manumanumanu, you have 1 message! sneek: manumanumanu, stis says: https://gitlab.com/guile-scsh/guile-scsh manumanumanu: ooh manumanumanu: apteryx: you should have a look at srfi-71. It is really neat. manumanumanu: nd it is included by default janneke: spk121: ah good, this year's potluck is looking very nice *: janneke is testing 2.2 compatibility... janneke: hmm...no code for module (ice-9 copy-tree) janneke: guess i'll have to patch it out for 2.2 wingo: there is copy-tree in 2.2 in default env wingo: iirc wingo: 3.0 as well fwiw janneke: yeah, upgrading to 3.0 gives a warning; so i blinly added a use-module janneke: this 3.0 upgrade has been pretty smooth, considering how much has changed janneke: and a factor 2 better performance for time-consuming scenarios, "for free", just terrific wingo: yassss spk121: wingo: did you check out janneke's mingw patch replacing all longs with scm_t_inum? should it be pushed? apteryx: daviid: ah, I see, thank you! apteryx: manumanumanu, civodul: I've now read srfi-71. It's great! Thanks for the pointers. talin: hello. i am trying to figure out what are the main practical differences between guile and racket talin: whether either of them have any particular limitations and such davexunit: I'm not a racket user, but what I've observed is that racket has a bigger userbase, more libraries, and their own IDE. talin: thank you davexunit davexunit: that said I still like Guile more, personally. davexunit: it has more of a minimalist vibe and we have the Guix project which is amazing. dsmith-work: Happy Friday, Guilers!! davexunit: both seem to have friendly communities. civodul: wingo: i've just pushed two minor improvements to (web client), taken from Guix wingo: civodul: great. now do NEWS :) wingo: no good deed goes unpunished, etc ;) civodul: wingo: heh :-) it's not even NEWS-worthy though, it's not "user-visible" wingo: fair enough :) civodul: pffeww ;-) davexunit: does anyone know how to reliably integrate srfi-64 tests with automake? I'm updating an old project written during the guile 2.0 days and what used to work no longer does. the tests themselves are fine, it's the exiting with a proper status code to tell automake if the tests passed/failed that is unreliable. wingo: spk121: haven't looked at it yet, but i would like to :) civodul: davexunit: you can take the "test driver" from build-aux/ in Guix wingo: davexunit: did you see that somethign changed in 3.0.5 ? civodul: apteryx tweaked it recently and it's become pretty flexible davexunit: I can get 'make check' and 'make distcheck' to pass locally, but then I tried building in guix and 'make check' fails because of an exception that is unrelated to the tests themselves. like srfi-64 is behaving differently for some reason. wingo: there was a fix to make the test runner comply with the spec which sadly broke lots of users wingo: davexunit: do a git log and grep for srfi-64, you'll find it davexunit: wingo: was it commit de5d1a7f99b8e952b115237ebc29633062f99bb9 davexunit: I was looking at it yesterdsay davexunit: "Fix bug #42713: srfi-64: Reset test-runner-current if done" apteryx: daviid: congrats for the guile-lib release! davexunit: I used to rely on calling (test-runner-current) after (test-end "foo") to get the results, but now that returns #f. then I discovered that test-end returns the test runner, so I wrote a test-end* that calls test-end and then exits with status code 0 if the tests passed. that works locally. davexunit: but when guix runs make check, test-end returns unspecified and all the tests fail as a result. davexunit: civodul: I looked at that test runner but it was quite complex civodul: davexunit: true, but consider it a black box ;-) *: civodul isn't used to giving that type of advice davexunit: I didn't really understand everything it was doing so I didn't want to add more confusion on top of my existing confusion. davexunit: I'm having trouble finding the right way to check test runner results once all tests have been completed. davexunit: every way I try breaks in a different context for mysterious (to me) reasons davexunit: here I was thinking I was making a quick update to an old project ;) apteryx: davexunit: I've already swaped out lots of details, but if you need to inspect test results post test run, perhaps you could look into the .trs files? apteryx: that's what Automake post-processes davexunit: apteryx: that seems like the wrong layer. I want to inspect the srfi-64 test runner within guile so I can return 0 upon success or 1 on failure. apteryx: Then you have to do so before calling test-end, persist that value, and return it post test-end apteryx: I had to do something like this for some guile library, I forgot which one, let me try to find it out apteryx: ah, perhaps guile-ssh apteryx: this: https://github.com/artyom-poptsov/guile-ssh/pull/27 tohoyn: talin: IMHO GOOPS is better than Racket's object system davexunit: apteryx: so that's what I thought I had to do, but it doesn't work in all contexts as far as I can tell davexunit: but if it's working for guile-ssh then maybe something else is wrong davexunit: apteryx: a-ha! I found the issue. thank you for showing me that this strategy works. apteryx: great! davexunit: it was an issue in something completely unrelated that wasn't obvious in the error messages I was seeing davexunit: I forgot to include my test wrapper script in the release tarball -_- apteryx: hehe talin: tohoyn: i see. thank you apteryx: does wrapping a multi values returing procedure with lambda* transparently passes on these values? Seems not. davexunit: nope. tohoyn: why is it so that a lambda in tree-il has to consist of lambda-case definitions? davexunit: lambda* is for optional args and keyword args, it doesn't do anything special with multiple return values. call-with-values and let-values are your friends for this. tohoyn: would it be more efficient if lambda consisted only of a single procedure body? apteryx: davexunit: thank you davexunit: apteryx: feel free to share example code and I can take a look if you're still stuck wingo: tohoyn: in terms of compuied code? doesn't matter a whole lot with guile's current compilation strategy. a procedure needs to check its arg count, and if the count is unexpected, jumping to the next case is just as cheap as throwing an error tohoyn: wingo: ok wingo: but it would be nice if we could skip arg count checks in many cases. unless a function is contified, we don't do that right now tohoyn: wingo: yes, I meant the efficiency of compiled code apteryx: davexunit: I believe this will do, but it's a bit verbose for just wanting to specialize a multi-valued procedure: https://paste.debian.net/1190010/ davexunit: let-values may read a bit nicer than receive lloda: with srfi-71 it almost always reads cleaner than either let-values or receive lloda: only with a rest arg (let (((values a . b) f) ...)) looks worse lloda: also apologies for the srfi-64 breakage :-/ lloda: what i do myself is (define error-count (test-runner-fail-count (test-runner-current))) lloda: before (test-end) lloda: then return error-count lloda: crude i suppose but it works davexunit: that's essentially what I'm doing davexunit: srfi-64 to me feels like low-level infrastructure that needs a friendly wrapper davexunit: I wish it was Schemier. like a set of combinators that can be composed to form a test suite that you then pass to a test runner. davexunit: and the return value is the results lloda: yeah agreed apteryx: is there no non-capturing group support in libc (Guile)'s implementation of regexp? such as (?:something|something-else) dsmith-work: apteryx: Guile's regex is the C libs regex dsmith-work: apteryx: So, No. apteryx: thank you dsmith-work: apteryx: I think irregex does: http://synthcode.com/scheme/irregex#SECTION_3.3 rlb: davexunit: sounds like you may have gotten it sorted? Here's what I did fwiw: https://git.sr.ht/~rlb/lokke/tree/main/item/mod/lokke/scm/test.scm#L9-15 And then just used that at the end of each file instead of test-end: https://git.sr.ht/~rlb/lokke/tree/main/item/test/lokke-scm-atom#L90 davexunit: rlb: that's essentially what I did. I've now seen at least 3 different versions of this same concept. :) davexunit: as if I needed another project (can't even maintain the ones I already have properly), I want to make a testing library that is actually good. jlicht: davexunit: you are an amazing maintainer! We just need there to be 6 of you :) apteryx: dsmith-work: thanks about irregex, didn't know about it davexunit: jlicht: heh, thanks. :) davexunit: I've been pretty burnt out for the last couple of years jlicht: sorry to hear that mwette: lispmacs: tree-fold, as in (sxml fold) and https://wingolog.org/pub/fold-and-xml-transformation.pdf wingo: rlb: looking at it again -- what happens now if you write a wide char into a narrow SH_STRING ? wingo: am wondering how all views onto that stringbuf would get updated janneke: hmm, my guile-websocket make check fails with 3.0.5 wingo: rlb: evidently it works tho :) wingo: ah no, i am mistaken. seems (substring/shared s 0) just returns s, as an "optimization" i guess? wtf janneke: how do i run one srfi-64 test? janneke: hmm, or even find out which one fails? *: wingo does not know *: janneke goes to bisect janneke: the backtrace is probably better if the test were compiled janneke: hmm, it seems that this doesn't work anymore in 3.0.5 janneke: (exit (= (test-runner-fail-count (warn "current"(test-runner-current))) 0)) janneke: hmm...it was a feature janneke: Fix bug #42713: srfi-64: Reset test-runner-current if done civodul: i disovered Gitile by roptat -> https://git.lepiller.eu/ civodul: the ultimate thing for those who want all-Guile services :-) *: janneke resets wip-mingw again with nicer fix for cross-compile bug wingo: janneke: yeah that one should have had more NEWS noise wingo: civodul: nice!! janneke: wingo: np, it was easy to fix -- i still need to become friends with srfi-64 ;-) wingo: rlb: ah yeah, SH_STRINGs already point to another string. ok, no problem wingo: rlb: so relative to current status -- stringbufs would have the byte indices. strings themselves stay the same i think relative to current status -- SH_STRING or normal string. is that right? wingo: and stringbufs would hold total byte count and have an index appended (one byte per each N codepoints or so indicating how many bytes that segment takes) wingo: where N is i guess floor(256/6) or so. could make the index be a uint16_t, maybe; dunno if dividing by 42 can be optimized to a multiplication :P wingo: could have a multi-level index for big big strings. but that would be an optimization that could come later rekado_: oh, gitile is written in Guile, I didn’t realize when I first heard of it. *: rekado_ goes to replace the default perl thing on git.elephly.net janneke: ugh, 8sync has the same srfi-64 problem rekado_: janneke: I had to remove that line in at least one package when building with Guile 3.0.5 (guile-commonmark, it’s already fixed in the upstream repo) janneke: rekado_: yeah, i'm moving (test-exit) inside/before (test-end) for 8sync manumanumanu: ahoy hoy! ArneBab: wingo: from Lilypond there’s te question whether it would be viable to make the reader-rewrite reason to move to 3.2 — what do you think? wingo: there's always a tradeoff for changes within a stable branch vs starting a dev branch. what is the argument? wingo: if we start a dev branch, then i do no more work on 3.0 wingo: i can't do both wingo: as there is no incompatibility, afaiu, i see the balance as favoring continuing to work in 3.0 as long as possible ArneBab: Just found: https://idiomdrottning.org/fancy-defines — I didn’t know about (define ((add a) b) (+ a b)) (map (add 3) '(1 3 6)) ArneBab: wingo: the argument is worries about stabilitiy, my answer was that as long as there’s full compatibility, we need no new minor release. Only if there should be a reason to favor 3.0.6 over 3.0.7. manumanumanu: ArneBab: there was a SRFI released about that recently, iirc. manumanumanu: 219 manumanumanu: the srfi source is amazing. A three-clause syntax-rules macro. *: janneke found a GOOPs problem trying to upgrade 8sync to guile-3.0 jlicht: Does anyone know of a guile/scheme library similar to clojure's garden? I would describe it inaccurately as sxml-for-css davexunit: jlicht: I don't think so. I've looked for something like that before and even thought about building it myself but never did. janneke: davexunit: i have some patches for guile-websocket over at https://gitlab.com/janneke/guile-websocket, just updated for guile-3 davexunit: it's an interesting topic. I've been working on a set of exercises from a book about creating a combinator language and compiler for regular expressions. writing something for CSS would be like a much bigger version of this. :) davexunit: janneke: neat. thanks. davexunit: I haven't looked at this library in a long time. davexunit: janneke: pushed all your patches to my repo. thanks again! dsmith-work: UGT Greetings, Guilers janneke: davexunit: oh great, thanks :-) roptat: rekado_, :) davexunit: janneke: what do you use this for? I wrote this library for fun many years ago but never did a proper release or anything. davexunit: I didn't expect people to actually use it ;) roptat: rekado_, if you really want to use it, I have a service definition: https://git.lepiller.eu/system-configuration/tree/-/modules/services/gitile.scm davexunit: perusing the code again and I'm quite pleased with myself. pretty clean with good references to the spec! lol janneke: davexunit: i'm playing/test with 8sync atm jlicht: davexunit: tbf, I would mostly want to manipulate s-expressions instead of mucking around with SASS/LESS, so a 'proper' library might even be overkill. Which book do you happen to be reading? davexunit: jlicht: software design for flexibility. new book from one of the SICP co-authors. civodul: jlicht: there's https://nongnu.org/scss/ (i haven't tried) davexunit: ooooh civodul: roptat: could you contribute that service definition to Guix? :-) ArneBab: wingo: some time ago you made it posssible to do definitions after expressions in functions. Could that also be done inside non-function defines? ⇒ (define (foo x) (display x)(define 'bar) bar) works. Can we get (define foo (newline)(define 'bar) bar)? Would that then be compile-time execution? davexunit: civodul: looks pretty basic, which is still more than I knew was available. jlicht: civodul: the documentation is a bit terse, but it might do the trick! Thanks :-) davexunit: sass/less are their own languages that add some significant improvements for the humans writing stylesheets. davexunit: a good s-expression -> css translator should cover up the warts of css and allow for easier abstraction roptat: civodul, at some point :) janneke: davexunit: in 8sync, we wrote some more frame fragment handling code, sending/receiving fragmented frames davexunit: janneke: if anyone wants to incorporate that into the websockets library directly, I would gladly accept such a patch :) janneke: davexunit: right! roptat: OrangeShark, ping :) I have a MR for guile-git (sorry for the noise if you received a notification for each change I made, I think it's stable now ^^') davexunit: websockets are fun. wish I had a use-case to use them more. I can't even remember why I wrote the library in the first place... davexunit: hmm... I think they were rather new at the time and I was using them for a project at work. janneke: yes, it's fun to play with guile and a browser using websockets davexunit: then somehow I looked at the spec, which was well written, and realized it wasn't all that complex. pkill9: cool civodul pkill9: that would be good with huant pkill9: haunt* pkill9: my blog has an scss file pkill9: I'm not sure how to have haunt call an external file on rebuild so I can generate the css file each time pkill9: but a native solution would be even better roptat: pkill9, I think you just need a builder for that css file roptat: which for haunt is a function that takes some arguments (I don't remember which exactly, but I think it's documented, or at least not too difficult to find out from existing builders) davexunit: I don't remember either, but if it's not documented I'd sure accept a patch to document it ;) davexunit: another one of my projects I haven't give much attention to in a long time davexunit: I have patches sent to me going back to 2019 :| oopsies davexunit: I will put out a haunt release... eventually pkill9: the builders return something produced by make-page, I'm wondering how it decides where to place these pages *: civodul cheers davexunit davexunit: pkill9: pages have a file-name field that says where they go davexunit: so they're pretty low level. pkill9: so i assume that the builders use a record davexunit: builders are just procedures, actually davexunit: they take 2 arguments: a object (the thing that has all the site-wide config), and a list of posts pkill9: ah ok, so builders arne't what I would need for this pkill9: seems builders are tied to pages pkill9: there's a procedure for static files davexunit: builders aren't tied to pages davexunit: builders return pages or assets pkill9: but if they take a list of posts, then how can you use them for non-post objects? pkill9: ok davexunit: pages and/or assets, I should say. davexunit: those are the 2 primitive, low-level data types davexunit: an asset is just a file on disk that will be copied verbatim davexunit: a page is something that is programatically generated and serialized to a file on disk pkill9: ahh there is a make-asset procedure pkill9: which you can use to specify source and destination davexunit: yup, that's all there is to that. davexunit: use it for images and stuff pkill9: so i could make a procedure that calls sass or whatever and outputs to /tmp, then calls make-asset using that /tmp/css file davexunit: I wouldn't recommend that. davexunit: assets are for files that need no processing davexunit: it's a bit hacky, but pages would be more appropriate for this. pkill9: but the CSS file is an asset, not apage davexunit: but the css file isn't being copied verbatim, right? pkill9: it will be, after I call scss to the scss file pkill9: which will generate a css file, which then gets copied verbatim davexunit: I wouldn't consider that an asset davexunit: because it's a derivative of another file pkill9: hmm ok pkill9: I suppose it makes more sense of rnow just to generate it outside of haunt pkill9: for now* davexunit: haunt should be the thing taking care of processing something and writing it to the proper destination davexunit: I generate all of my site's code with scheme, not external tools, so there isn't a ready-to-use solution here. davexunit: but the concept of a page fits the bill, if in a sort of hacky way. davexunit: the "contents" of a page could be simply the name of the .scss file. pkill9: but why would it generate a css file? pkill9: if it's a page davexunit: and the "writer" procedure could arrange for opening a pipe to sass via (ice-9 popen) and redirecting the output stream to the output port that the writer procedure receives. pkill9: oh i see i think davexunit: the "page" metaphor kind of falls apart here, which is why I'm saying it's hacky. davexunit: but essentially all a page is doing is taking some scheme data and applying a procedure to it, with the expectation that the procedure will use the output port it has been given to populate the destination file. jlicht: so page means computed-asset, in most cases? davexunit: in haunt an asset means a file copied verbatim, so I would say no. davexunit: a page is a programatically generated file wingo: ArneBab: cost of a minor release is very low fwiw. if there is a bug in 3.0.6, we'll just make a 3.0.7, no prob davexunit: it represents a single file that has an arbitrary program generate its contents davexunit: perhaps a future version of haunt could change the name "page" to something more generic, and have all the plumbing for applying an external program and writing the output to the destination file. jlicht: haunt-contrib ftw, I guess :-) davexunit: I'm just making this shit up as I go ;) pkill9: maybe split the the raw-file concept of the 'page' into it's own thing, and rebuild the 'page' to use that pkill9: idk pkill9: also, that SCSS module is confusing, because it means "Scheme CSS", it's not a reference to the extended css type "scss" pkill9: this https://sass-lang.com/documentation/syntax pkill9: that said, all the functionality of sass is provided by scheme jlicht: It predates scss pkill9: it's just amore programmatic form of CSS pkill9: ok pkill9: you could have an importer of scss (SASS) into scss (Scheme CSS) davexunit: pkill9: here's an untested example of what I mean: https://gist.github.com/davexunit/a4d8011b09e0b9c7afc95bc17f14abbb davexunit: if sass can't dump the generated css to stdout, then yeah you could use a temp file, but the important thing would be that you had some abstraction that makes all these gross details transparent davexunit: I guess transparent isn't the right word, but you get what I mean ;) davexunit: and would probably make more sense as generalized low-level data types. *: davexunit is getting lots of ideas :) pkill9: it can dump to stdout pkill9: i think actually it only dumps to stdout pkill9: you have to redirect it to a file i think davexunit: ah okay davexunit: well then the code I provided should be kind of what you'd want manumanumanu: Is there anything other than the process redirection language that people miss from SCSH? manumanumanu: There is a pretty complete implementation of that for chicken that could be ported to guile with ... moderate effort davexunit: I've never used it so dunno manumanumanu: the egg in question: http://wiki.call-cc.org/eggref/5/scsh-process manumanumanu: the repo is here: https://code.more-magic.net/scsh-process rlb: wingo: yeah, that's right, though at least at the moment the index "width" is set up to be dynamic, based on the length of the string, i.e. < 256 has a byte width index, < 2^16 has a uint16_t index, < 2^32 has a uint32_t index, etc. And the "stride" is also dynamic, i.e. we'd currently skip 16 chars between offsets for < 256, 32 chars for < 2^16, 64 for 2^32, etc. rlb: That allows us to maintain roughly the same index overhead for all strings if we like. wingo: coo coo civodul: manumanumanu: never used scsh either but Gash provides a bunch of niceties in this area: https://savannah.nongnu.org/projects/gash/ davexunit: this scsh-process thing is making me wonder: I have chickens, but I don't use chicken scheme nor do the chickens. davexunit: something doesn't add up! pkill9: davexunit: thanks, that works, how do i output that to the assets subdirectory? pkill9: nevermind, i have an example davexunit: pkill9: just in case it helps: the first arg is the output file name *: pkill9 wants to make a service similar in goals to wordpress but using haunt pkill9: not really sure who would use it though, just would like that to exist davexunit: are there any static-websites-as-a-service services out there? I've never looked pkill9: there is write.as, not sure of any others davexunit: the reason I don't use wordpress or similar is because it's a dynamic web application full of issues pkill9: I don't know of any others, that one, and possibly another i heard of, is focused around just content though pkill9: yea, heard about it's problems pkill9: what I want is something that lets you theme and edit your blog, but produces a static site davexunit: static site generators tend to have the drawback that they are for a more technical audience, and haunt is no different. davexunit: a friendly UI for one would be cool pkill9: yea, I'm not really even sure I'd use it when I can just generate the site and host it myself, I just think it would be cool to have pkill9: and I'd make it easy to download/upload the markdown files pkill9: wordpress requires a plugin just to export as markdown davexunit: a service that separates the task of editing and publishing (dynamic) with the finished product (static) would be good. surely there's something like that already out there. pkill9: yea pkill9: oh yea this looks like it does that https://getpublii.com/ davexunit: nice pkill9: oh it's a desktop application pkill9: here's one i think online https://www.siteleaf.com/ davexunit: good. now I can happily stay in my niche of "scheme programmers with blogs" knowing that there's more user friendly tools for other people. *: janneke stumbles upon another guile-3.0 thingy dsmith-work: sneek: botsnack sneek: :) dsmith-work: goodbot apteryx: daviid: by the way, if you need a hand with anything for the next guile-lib release, let me know! manumanumanu: civodul: Well, I just think this kind of process handling should be available more easily in guile. Whether it is using EPF from SCSH or something else. It is something that is hard to get right, and that many people want - especially when writing quick scripts. manumanumanu: EPF might not be the best idea (I reluctantly admit, since I have used it quite a bit), but something that allows for the power of scsh redirections and process notation would be amazing. I will have a look at gash and see if I can maybe use it as a starting point. civodul: manumanumanu: i agree; Rutger contributed 'pipeline' in (ice-9 popen) some time ago civodul: i think we could have more of those manumanumanu: I saw that and was very happy! manumanumanu: I will give porting SCSH-process a try... I will have to make some small changes to the syntax, since it will collide with some other syntax (r6rs | I believe), but most things should be possible to keep intact. *: davexunit figured out how to redirect external program output into an output port davexunit: specifically, an output port connected to a file davexunit: primitive-fork, then in the child process (close 1) (dup2 (fileno port) 1) (execlp "the-program") manumanumanu: had you asked your chickens they would have told you to install the scsh-process egg :) manumanumanu: These things are just horrible to debug though. If it doesn't work, at best it just hangs and produces no output. manumanumanu: giving you no help whatsoever manumanumanu: I remember trying to imlement the pipeline just added to (ice-9 popen) in pure scheme about 8 years ago. I had to give up. rekado_: sometimes I want to generate inline JavaScript in SXML, but the entity encoding gets in the way. Is there a way to inject text without having the (web server) machinery change it? wingo: yeah somehow. you want cdata i think wingo: hmm wingo: rekado_: this is what i use https://github.com/wingo/tekuti/blob/master/tekuti/page-helpers.scm#L153 wingo: NB, produces html, not xml wingo: i looked at the living html spec when i wrote that, fwiw rekado_: thank you! apteryx: seems I'm misunderstanding call-with-values: (define p (lambda (x y) (format #f "~a, ~a" x y))) (call-with-values (values (cons (list 'a "v1.0.2") '()) '()) p) -> Wrong type to apply: ((a "v1.0.2")). Ideas? apteryx: ah, the first arg is supposed to be a procedure, not the application of the procedure (or its result) apteryx: this works: (call-with-values (lambda _ (values (cons (list 'a "v1.0.2") '()) '())) $17) RhodiumToad: right. call-with-values is a bit low-level, the other mechanisms for it are usually preferable apteryx: right; the name mislead me :-) This is indeed clearer in this case: (receive (x y) (values (cons (list 'a "v1.0.2") '()) '()) (p x y)) wingo: define-values is also a good option wingo: (define-values (x y) (values 1 2)) apteryx: neat! civodul: or srfi-71 for 'let' bindings RhodiumToad: does the fact that define-values expands into something that does set! cause any issues? wingo: RhodiumToad: not sure tbh. without heroics from the compiler i can imagine the result is suboptimal wingo: we should have a better implementation i reckon RhodiumToad: hm. maybe I misread how it expands wingo: racket has values-defining forms as primitives afair RhodiumToad: it looks like it does a (define t-blahblah ...) that gets a list of values, then a series of (define a (car t-blahblah)) (set! t-blahblah (cdr t-blahblah)) RhodiumToad: so at least it doesn't do set! on the things it's supposed to be defining, only on the temporary variable wingo: yeah exactly. not pretty tho wingo: the optimizer could optimize out the vector in (define t (call-with-values (lambda () expr) (lambda (a b c) (vector a b c)))) (define a (vector-ref t 0)) (define b (vector-ref t 1)) (define c (vector-ref t 2)) ...) wingo: but that happens late; not available at peval time civodul: if it can optimize it out, that'd be a nice option wingo: pretty sure that optimizes out; i remember checking (match (vector a b) ((a b) (+ a b))) and it folded as expected wingo: er #(a b) for the pattern, rather wingo: yeah that optimizes civodul: really nice wingo: janneke: hey :) what's the mingw64 timeline? wingo: i.e. if patches ready for review by monday i would wait for it before making 3.0.6 wingo: assuming review and landing will take a week wingo: otherwise i would release 3.0.6 sooner and follow up sooner after wingo: heh, unclear wording wingo: anyway i just mean we can make a 3.0.7 within another 4 weeks or so if we want wingo: lloda: regarding autocompiling and no source locations -- is that a change relative to 3.0.5 ? wingo: davexunit: hey where was your goops patch wingo: sorry i keep forgetting things daviid: wingo: here https://lists.gnu.org/archive/html/bug-guile/2021-01/msg00028.html daviid: apteryx: no need, tx alextee[m]: Will the new release finally work with mingw64? \o/ *: alextee[m] is patiently waiting for an msys2 package for libguile janneke: wingo: i posted to guile-devel this afternoon wingo: great tx janneke: i'll be sure to ping you here next time ;) *: janneke had a very busy day doing all kinds of guile-3 package updates janneke: also, i was hoping that spk121 would glance through my other mingw patches/fixes and cherry-pick some of them davexunit: daviid: thanks for sending wingo the link. I was afk daviid: davexunit: np, iwas here and with the link in my browser still ... ArneBab: did you receive my email-forwards from Lilypond to guile-devel? spk121: janneke: this weekend, after I finally get to Potluck, I should have time to work MinGW. In real life, these have been a crazy busy couple of weeks, phew *: spk121 wonders how life can be busy whilst in a quarantine flatwhatson: did anyone make progress rebasing the wip-elisp branch to 2.2.x or beyond? rekado_: flatwhatson: here’s my stalled attempt: https://git.elephly.net/?p=software/guile.git;a=shortlog;h=refs/heads/wip-elisp *: janneke -> zZzz flatwhatson: rekado_: thanks, do you recall any of the challenges around it? rekado_: flatwhatson: when the rebased Guile Emacs uses it there’s a segfault. rekado_: flatwhatson: I’m not sure if it’s because of changes to wip-elisp or Guile Emacs *: rekado_ –> zzzZ davexunit: daviid: the bug has been filed and the patch is included: https://lists.gnu.org/archive/html/bug-guile/2021-01/msg00028.html daviid: davexunit: oh great, sorry for the noise, tx davexunit: np :) davexunit: I don't know if anyone is going to merge it before the release but we'll see daviid: davexunit: yes, we'll see :) ... this 'noise' of mine might serve as a gentle ping after all :) ... davexunit: ;) *: davexunit gets back to working on exercises in "software development for flexibility" davexunit: er, I mean "software design for flexibility" lispmacs: in guile-sdl2, there is keyboard input procedure (key-pressed? key) lispmacs: but I'm having trouble figuring out what is the format of KEY lispmacs: simply passing in the ASCII doesn't work, and I tried passing the name of the SDL constant davexunit: lispmacs: it's a symbol. 'a, 'b, 'c, etc. davexunit: lispmacs: see https://git.dthompson.us/guile-sdl2.git/tree/sdl2/input/keyboard.scm#n36 for the mapping of scheme symbols to sdl2 key constants lispmacs: davexunit: I'm expect (while (not (key-pressed? 'q)) '()) to block until the letter q is pressed, but this doesn't seem to work davexunit: lispmacs: it doesn't block. it simply returns the state of the key at the time of the call. davexunit: if you want to be notified of key presses, you'll want to poll for input events instead. lispmacs: davexunit: right, but just for understanding: if I have a while loop that does nothing until (key-pressed? 'q) returns true, shouldn't my program block until the letter q is pressed? lispmacs: or held down flatwhatson: you would need some theoretical "wait for something to happen" function inside that loop flatwhatson: aka. polling for events davexunit: lispmacs: it will block in the sense that it will loop as fast as possible, doing nothing but burning cpu davexunit: (while (key-released? 'q) #t) would create a loop that would use 100% of a CPU doing nothing until the Q key is pressed lispmacs: davexunit: makes sense, but it doesn't. davexunit: then your code is wrong davexunit: ah, hold on davexunit: I see the confusion. davexunit: so, SDL2 doesn't update input state unless you ask it to lispmacs: ah davexunit: so if you're stuck in a loop nothing will ever change lispmacs: which procedure does that? davexunit: poll-event in (sdl2 events) lispmacs: there we go davexunit: I recommend reading sdl2 tutorials to get a hang of the basics and then translate the C code to scheme. guile-sdl2 tries its best to provide a 1 to 1 mapping from the C API to Scheme procedures. davexunit: poll-event will return #f when there are no more events left to process. you will want to call poll-event in a loop every so often until it returns #f lispmacs: davexunit: i tried that but got bored way too quickly. and I've already got 200 lines of scheme code lispmacs: anyway, thanks davexunit: np davexunit: and now that you're polling for events, you can replace a loop that would burn 100% of a CPU with an event callback :) ArneBab: Can you estimate whether it would be viable to get a guix.scm package-dependency-resolver that usess guildhall under the hood for pure Scheme dependencies when the user has no Guix installed? janneke: spk121: okay, finally got the new mini-mpz approach to work; now to clean-up the patch set janneke: in order to get it to work, /me probably changed too many instances of long => scm_t_inum and such... wingo: janneke: would be happy to review the patch on gitlab btw *: wingo likes the clicky web patch review things janneke: wingo: great, i'll let you know once i cleaned it up a bit wingo: thumbs up *: janneke missed "typedef long SCM_STACKITEM;" all night yesterday, and this morning until just now... janneke: that was probably it wingo: humm, is that a problem? wingo: ah pointers are 64-bit wingo: ok :) wingo: yes that sounds like a problem :) janneke: yeah, i went to eradicate all instances of "long", just to be sure; i hope most of that can be reverted rekado: ArneBab: I’m not sure I understand. Do you want to extend a “guix.scm” file containing a Guix package definition, so that it can be used to install the package when used without Guix? How would that be used? ArneBab: rekado: I’d like to have some dependency mapping, so guildhall can check whether it has packages matching the guix packages. wingo: sounds excruciating, janneke. highfives for doing the work ArneBab: rekado: that would allow me to just provide a guix.scm file with dependencies, and for all plain Scheme dependencies just tell people "if you don’t run guix, just use guildhall [some way …] to install dependencies" ArneBab: that would provide a single point of dependency information janneke: wingo: thanks, ... i'm at least somewhat ambivalent about this work wingo: janneke: why do you say that? you think we are taking the wrong strategy by making 64-bit fixnums on mingw64 ? janneke: wingo: ah no, this is the right approach; it's just, throwing good enegry towards supporting something as stupid as windows, that needs to die ;-) wingo: haha yeah wingo: ~ users ~ wingo: you are doing $deity's work tho :) janneke: yeah thanks---just hoping it may inspire some people leave that all behind wingo: need to get it working on wine eventually for it to not bitrot dsmith-work: Wednesday Greetings, Guilers lloda: when there is an error while autocompiling there is no source info printed out lloda: i have to resort to (compile-file ...) by hand to see that lispmacs: did somebody have a procedure that is the same as `map', but that works on lists with arbitrary nesting? I.e., applies the procedure to the non-list elements? tohoyn: lispmacs: see https://paste.debian.net/1189759/ (the procedure is not my own) dsmith-work: tohoyn: ISTR the ssax stuff having something like that. Not sure.. rlb: wingo: OK, so if we switch stringbufs to be say ~6% index or whatever (i.e. sparse byte offset index followed by the chars), that means that we can swap the entire content by swapping the stringbuf (pointer), and I *think* that also means that we'll still want shared strings as a separate type that points to another string, so we can swap that other string's stringbuf to affect them all. Sound vaguely plausible offhand? rlb: (I've gotten some of that roughed in and then got around to the shared string bits.) daviid: davexunit: great, is this part of chickadee? apteryx: wingo: hey, I had somehow missed your message about now having the OK to push patches to guile-lib at my leisure ;-). Sounds good! I'll take the opportunity to merge the recent changes I proposed. Thank you. daviid: apteryx: please don't, i am worji daviid: i am working on those, in devel, and almost ready to release daviid: but have a problem with the web pages ... daviid: I would also ask you (or any one else) to send parches to guile-devel for review first - tx apteryx: daviid: OK, no worries flatwhatson: is there an easy way to run a unit test under gdb? apteryx: also OK to send any new patches I make for guile-lib to guile-devel for review first apteryx: thank you for working on a new release! daviid: apteryx: ok great, tx - I think it is important to give us (all) a 'window' for review(s), but we could agree on somehting like if no answers in say, 2 weeks (just like in/for guix iiuc), then ok to push ... daviid: apteryx: fwiw, and as an example, i disagre with your patch-6 :), but didn't have time to write about this yet, because i first wanted to work on a release including all other patches, especially the long awaited htmlprag fixes ... daviid: it seems savannah gnu/nongnu git servers are unaccessible at this time apteryx: I'm having the same problem daviid: ok, tx for the confirmation apteryx: I'll let you work through it and comment on any email feedback you may have; just make sure I'm CC'd on your replies so that I don't miss them. daviid: apteryx: I am the release prep final steps, as soon as this is done ... wingo: moin janneke: o/ civodul: hi there! janneke: so, i got 64bit mingw running yesterday on guile master :-) janneke: not sure yet how correct it is, or even if it's what we want, how we want it spk121: janneke: that's awesome janneke: spk121: thanks :) spk121: janneke: is it still that wip-mingw branch? janneke: spk121: yes, i reset https://gitlab.com/janneke/guile/-/tree/wip-mingw janneke: and rebased on your jit (wow!) -- didn't test that here just yet spk121: janneke: since the "Support for x86_64-w64-mingw32" patch is a bit serious, I guess the next step would to get wingo or civodul to ponder https://gitlab.com/janneke/guile/-/commit/b54432212aa8f8e957c670bb6df6fe7266842dd0 janneke: yes sure, i merely said "it works"... wingo: why wouldn't we want uintptr_t fixnums ? janneke: also, i haven't attempted running the test suite yet janneke: hmm, i must have had a wine hack/setup for wip-mingw-guile-2.2, thanks for listening spk121: wingo: because GMP works on long? wingo: does gmp work on long even on mingw64 ?? wingo: dunno why they wouldn't define a word-sized digit type janneke: i think the comment in numbers.h hints to that and it seems to be the case wingo: but in guile #define SCM_T_SIGNED_BITS_MIN INTPTR_MIN wingo: and #define SCM_T_SIGNED_BITS_MAX INTPTR_MAX janneke: yes, that makes more sense wingo: how about typedef intptr_t scm_t_inum on mingw64 wingo: ah mpz. hummm wingo: sorry, this is the denial,anger,acceptance thing wingo: mingw64 grief is a process :P janneke: yeah, tell me! janneke: why don't you just run wsl, if you must have an insecure backdoored, proprietary platform? wingo: janneke: ok here's a bonkers idea, what about on mingw64 we require minigmp and define MINI_GMP_LIMB_TYPE spk121: wingo: I was actually just about to go there, too janneke: wingo: that's a nice idea wingo: hehe wingo: nice to commiserate with friends ;) *: janneke likes this janneke: too bad we're too late for the potluck :) wingo: haha wingo: leftovers :) janneke: hehe spk121: so it would just be some configure stuff and then setting MINI_GMP_LIMB_TYPE to long long for __MINGW64__ I guess? wingo: yeah i think so. could add '-DMINI_GMP_LIMB_TYPE=long long' in configure, that way source needs no changes wingo: and we eliminate that source of potential bugs (different mini-gmp users defining or not that definition) janneke: and then change instances of "long" to some typedef MINI_GMP_LIMB_TYPE some_gmp_type? wingo: which instances of long ? wingo: in numbers.c you mean? wingo: i guess you would change any long which is a GMP digit to mp_limb_t wingo: humm wingo: but in numbers.h wingo: i think you could just use intptr_t and somewhere we make a compile-time assert that the size of mp_limb_t is the same as the size of intptr_t wingo: wdyt? wingo: just an idea janneke: ah yes janneke: i was wondering about things like hash.c, e.g. unsigned long scm_ihashq (SCM obj, unsigned long n) janneke: spk121: couldn't you recycle scm_t_inum instead of creating a new mp_limb_t type? Is there a meaningful difference between those terms spk121: nevermind, I see where mp_limb_t lives wingo: janneke: for scm_ihashq or anything that returns something that should be an inum, i guess scm_t_inum would not be a bad choice wingo: note though that scm_ihashq could continue to return a long on mingw64 wingo: just wouldn't be optimal wingo: so it probably makes sense to separate necessary changes from optimizations janneke: okay, thanks spk121: OK, so it is just, (1) -DMINI_GMP_LIMB_TYPE=long long for mingw64 (2) make scm_t_inum and mp_limb_t the same type (3) assert that sizeof(void *) == sizeof(mp_limb_t) == sizeof(scm_t_inum) spk121: ? wingo: (2) make scm_t_inum be scm_t_signed bits i guess wingo: because with mini-gmp, users won't have access to mp_limb_t spk121: what about #ifdef MINI_GMP_LIMB_TYPE / typedef MINI_GMP_LIMB_TYPE scm_t_inum; #else typedef long scm_t_inum. spk121: oh right, numbers.h is a public header. janneke: hmm, the new locale check fails for me wingo: janneke: yeah me too, will look at it janneke: wingo: ah "good", thanks wingo: :) *: janneke does another round of builing x86_64-w64-mingw32 jonsger: :) davexunit: daviid: to answer your question from yesterday: no it's not part of chickadee. chickadee is more low-level and doesn't use goops. civodul: i suppose one can test with: guix build guile-next --with-branch=guile-next=master --target=x86_64-w64-mingw32 davexunit: I'm doing some more experimental work with high-level "game engine" style abstractions in an unpublished project and I use goops there. civodul: my modest contribution :-) janneke: hmm, what's a mp_limb_t janneke: janneke: oh, that should be our MINI_GMP_LIMB_TYPE janneke: hmm *: janneke uses --keep-failed to heat-up their laptop a bit civodul: :-) dsmith-work: UGT Greetings, Guilers janneke: hello dsmith-work janneke: spk121: hmm, --enable-jit segfaults for me, at least in combination with the new approach for x86_64-w64-mingw32 spk121: janneke: pity. It definitely isn't well tested. I'm not even sure what a proper JIT test should look like janneke: well, without JIT i get a familiar error with the new approach: unexpected syntax in form ((@ (ice-9 control) %) spk121: janneke: did you rebuild your *.go now that they should be identical to the linx x64 *.go files? spk121: (well, not so sure about identical, but, more similar?) *: spk121 is off to work spk121: good luck janneke: thanks! janneke: yeah, i use guix to rebuild everything *: janneke goes to check .go equivalence dsmith-work: spk121: Upstream lightening has some tests: https://gitlab.com/wingo/lightening/-/tree/main/tests wingo: upstream lightening even has ci :) dsmith-work: On multiple archs too! rlb: ...I'd pondered pushing here for some extra testing (even if I just did it for myself), fwiw: https://man.sr.ht/builds.sr.ht/compatibility.md If I got that working, I suppose we might be able to set up some kind of mirroring from savannah if that were feasible/desirable. rlb: Though I haven't really tried the CI there yet much myself, so was just contemplating. janneke: hmm, mini-gmp uses long and unsigned long in signatures, wondering if that's a problem janneke: e.g.: int mpz_cmp_ui (const mpz_t, unsigned long); manumanumanu: ahoy hoy! 3.0.6 looks like it is going to be a fine release whenever it is ready! manumanumanu: and from what I can see there is some work done towards working under cygwin manumanumanu: What was it Andy said? Mike for president? davexunit: would be cool if my goops patch could be included in 3.0.6 :D manumanumanu: davexunit: which one? davexunit: manumanumanu: fixes an issue with redefinable classes. it's the only bug I have open in the bug tracker davexunit: manumanumanu: https://lists.gnu.org/archive/html/bug-guile/2021-01/msg00028.html daviid: davexunit: ah ok, i asked because i was interested to look at your solution/the code, whenever it becomes public, let me know ... wingo: janneke: are there many of those cases? (using long to indicate an immediate int) janneke: wingo: yes, it seems long is taken to be == MINI_GMP_LIMB_TYPE, if i understand the code correctly; of which i'm not entirely sure manumanumanu: davexunit: thanks! goops is a powerful beast... I mostly use a home-rolled predicate-based system, which is faster for my use case (dispatching on a few elements, with a few methods). I lose specialisation, but gain that in lines of code janneke: i tried replacing long and long int with xlong and then #define xlong long long for mingw, which did not make any difference wrt the "unexpected syntax in form ((@ (ice-9 control) %)" problem janneke: so, i'm kinda lost with this new approach atm janneke: the fixnum patch seems more attractive atm, as "it works" ;-) wingo: civodul: i18.test:282 or so, testing "STRASSE" etc. are we failing to pass the de locale parameter to the comparator? *: wingo fixed the i18n test probs that he introduced; "yay" janneke: \o/ wingo: zzz civodul: wingo: indeed, the Straße example lacks the 3rd arg to string-locale-ci=? davexunit: daviid: the project is unpublished, but the code is available. here's the relevant section: https://git.dthompson.us/starling.git/tree/starling/node.scm#n65 davexunit: context: is the base class for all objects in a game. is 's metaclass. an "asset" represents anything loaded from disk like an image or audio file. janneke: hmm, long2big, ulong2big all need to do inum2big, unum2big i guess janneke: and the mpz_set_si, the mpz_set_ui probably need to take similar custom types daviid: davexunit: oh, tx *: janneke introduces mp_long and mp_ulong for mini-gmp daviid: davexunit: beautifully written, congrat! daviid: davexunit: I think you should file a bug report with your patch for (compute-slots (class )), so the fix might make it to 3.0.6 - unless andy tells us it's not a bug but i don't think so rlb: wingo: another option - I could take part of what I'd be contemplating wrt immutable texts, i.e. we could have "sparsely indexed stringbufs", which would allow us to swap atomically, and would help with other indexing operations. e.g. we could keep an array of sparse char offsets in the stringbuf, say every 32nd char or something. Then strings would go back to just using char offsets (not also byte offsets). rlb: We'd have to hunt though about half the sparseness on average to find a char offset, but that's way better than the whole string for arbitrary stringrefs, etc., and maybe it's good enough for the normal, most common, string operations. They won't be as fast as an exact offset, but pretty fast. rlb: I also imagine we *could* heavily optimize utf8 operations if we wanted to (if libunistring doesn't), i.e. tricks with wider ints, or even gcc/llvm intrinsics or vector ops, etc. rlb: i.e. the "finding part" rlb: We could even have more than one flavor, i.e. a uint8 offset index for shorter strings, uint32 or 64 for longer ones, etc. rlb: I wonder just what fraction of strings is typically < 256 bytes, utf-8 encoded (and isn't ascii). davexunit: goops woe: it's easy enough to define a custom setter for a slot accessor, but since each class defines getter/setter methods for all of its slots, there's no way to define a setter method for a superclass that also applies to the subclasses. sneek: Welcome back davexunit, you have 1 message! sneek: davexunit, wingo says: that's like racket's "prefab" structs. would be nice to support that davexunit: I think I remember the context for this... neat. davexunit: back to the goops thing: it feels reasonable to want to hook into a slot setter method to add custom behavior, but maybe I'm thinking about it wrong. davexunit: one solution is to define a new method entirely for this purpose, but it feels better to have the code look the same as any other slot modification. daviid: davexunit: fwiw, slot-set! is procedure, the only situation where you can customize slot-set! is for virtual slots, afaiu davexunit: yes I know but I'm talking about (set! (foo obj) bar) davexunit: using slot accessors and the generalized set! syntax davexunit: my current path of exploration is to use some metaclass magic to add a new slot option that specifies a post-set! callback method. davexunit: compute-setter-method can detect that and generate a special instance. daviid: right, i don't think it is possible to customize the 'default' accessor(s), except as you said, using the mop or simply defining a method ... davexunit: I want the post-set! stuff to be transparent. I want the code to read like any other set! call daviid: davexunit: then i'd use the mop, and define a new slot-type daviid: a new slot allocation type i meant davexunit: I think a custom slot option will suffice davexunit: I tried messing with allocation types and it gets real hairy real fast davexunit: goops doesn't publicly export the procedures that allow you to get the struct field index for a slot, so implementing an allocation type that uses instance level storage is not possible without hacks. daviid: yes, it's not exactly 'a piece of cake' (to answer your previous sentence) - maybe a slot option would be enough, never tried, i use the mop and allocation type (in g-golf) davexunit: does your allocation type store data on the instances of that class? daviid: no, all are precisely not allocating, but using/refering to GObject properties davexunit: got it davexunit: yeah a new allocation type makes perfect sense there davexunit: for my case, I want to use the #:instance allocation type, but decorate the accessor methods davexunit: well, that's enough playing around for one night. thanks daviid. byeeee daviid: davexunit: right, I think the best route is to define a metaclass and detect treat the new allocation type in a customized compute-slots methods, then decorate slot-set! (note that you would not decorate the accessor method(s), but slot-set!) rlb: wingo: do you happen to know if we have many/any free bits in the stringbuf tag field (cell_0)? tohoyn: hello tohoyn: what's the status of Guile Potluck? manumanumanu: ahoy! wingo: o/ wingo: janneke: why does mes need a gc? would a bump-pointer allocator that never reclaims memory be sufficient? wingo: i guess it means bootstrap allocates lots of memory :) janneke: wingo: yes, i even tried it without, initially; minding the remarks in SICP about memory janneke: wingo: also, bootstrap is x86, 32bit wingo: ah yeah. ArneBab: rlb: that sounds like a useful fix: O(1 + something-32-chars) would be great. davexunit: daviid: just fyi, what worked for me was adding a new slot option #:watch? that my metaclass knows how to handle. any slot with #:watch? #t has a special setter that calls an on-change method when a new value is set. davexunit: for example, I have a class that draws text on screen. by watching for changes to the slot that contains the string, I can now automatically recalculate text alignment based on the new dimensions of the text. wingo: heya davexunit davexunit: hi wingo leoprikler: Yeah, GOOPS has some nice features like that. leoprikler: If you deal with raw records, things can get ugly pretty fast. spk121: wingo: w.r.t JIT. Yeah I set the threshold=0 and ran it on MinGW. Seems OK. wingo: grand davexunit: spk121: jit on mingw? that rules! davexunit: now, do threads work? am I asking for miracles? ;) spk121: davexunit: maybe? building with threads enabled does succeed and the test suite does run. I haven't hit it enough to check if threads are actually working or if it will hang eventually like before davexunit: well that's promising, at least. davexunit: I'll have to revive my guix mingw code sometime spk121: the last remaining huge hurdle is disambiguating sizeof(long) vs sizeof(void *) in the VM and in numbers.c spk121: (or alternately rewriting VM an numbers.c to use uint64_t for long) chrislck_: spk121: :-O janneke: spk121: sounds awfully related to the x86_64 work janneke: i've been trying to port my 2.2 patches this weekend spk121: janneke: I do mean the work you're doing, of course. I did peek at your tree to see what you've done janneke: great! janneke: https://gitlab.com/janneke/guile.git @ wip-mingw now cross-builds on guix, janneke: but running it fails in an interesting way janneke: unknown location: unexpected syntax in form ((@ (ice-9 control) %) (begin ((@@ (ice-9 command-line) eval-string/lang) "(display \"hello\\n\")") (quit))) janneke: not sure how to go about that spk121: janneke: are you running on wine? davexunit: I had issues back in the day where the resulting exe would fail on wine but work on windows spk121: yeah, I can't get it to run on wine, but, my understanding of how to use wine is rudimentary janneke: spk121: yeah, i do my testing on wine civodul: looking at the Guile code, i'm wondering how one can get: Wrong type (expecting finalized smob): # civodul: (from ) civodul: looks like finalized_smob_tc16 is private, never used anywhere in type checks civodul: what am i missing? wingo: civodul: ot wingo: it's the first smob type and has value 0 wingo: when a smob is finalized, its smobnum is reset to 0 wingo: see clear_smobnum wingo: civodul: if you get "expecting finalized smob", that means that somehow the scm_assert_smob_type is getting passed 0 as the smobnum wingo: hum, i wonder if you have somehow hit the smob limit wingo: more than 255 smob types defined, overflow to 0 civodul: and tags would wrap and you'd get a zero tag? civodul: uh wingo: i mean i would expect there to be an error wingo: but it's a way i could see that to happen civodul: though memory corruption may be more likely in this case wingo: yeah that is what i am thinking wingo: weird to think it though :P civodul: i'll see if i can reproduce *: civodul feels like a fire fighter these days :-) wingo: or somehow something overwrote that tc16 value with a value for which (v & 0xff00) == 0 civodul: yeah, so many possibilities jackhill: , jackhill: oops, soory jackhill: civodul: thanks for looking at that bug. Somehow I have a nack for turning up wierd errors :) [-_-]: hello [-_-]: http://ix.io/2SWp [-_-]: Can someone tell me what those display statements doing in that file? [-_-]: i can't understad what to expect [-_-]: This is where i got the file [-_-]: https://www.nongnu.org/xbindkeys/xbindkeysrc-combo.scm.html rekado: [-_-]: “display” prints a string to a port rekado: if no port is given it prints to stdout tohoyn: [- -]: the display statements seem to be some debug output to the console rekado: or it could be called within a (parameterize ((current-output-port …)) …) context and write these things to a file [-_-]: oh... rekado thank you for explaining rlb: wingo: I roughed in the indexing approach, so far it looks promising, if the (tunable at powers of 2) index overhead is acceptable, i.e. say ~6% size and the cost to regenerate it after changes (plus the code complexity). And wrt your more general utf8 question, another thing I imagine we might get with utf8 is much more heavily optimized paths for things like memchr, etc. rlb: wingo: for now I packed the index inline in front of the string bytes, but we could do "something else". rlb: ...and I also set up dynamic "widths", i.e. one-byte index entries for strings < 256 chars, two-bytes for < 2^16, etc. For now I didn't cover the case of size_t > 64-bit :) rlb: (and the index skip-factor is also dynamic -- larger for longer strings) *: rlb shrugs, not sure, and only roughed in the creation -- haven't touched the rest of the code yet, so there'd sill be a lot to do... davexunit: random note: I started reading "software design for flexibility" and I encountered examples code that looked like (define ((iterate n) f) ...). this syntax appears to be mit/gnu scheme's way to create curried procedures. anyone ever implement this for guile? davexunit: example* davexunit: to work with the example code in guile I've just been manually expanding like (define (iterate n) (lambda (f) ...)) so I can keep my focus on the book itself leoprikler: ice-9 curried-definitions IIRC dsmith-work: Monday Greetings, Guilers sneek: It's the 15th of March. Look out for ides dsmith-work: davexunit: Guile used to have curried definitions by default. Removed in 2.0. davexunit: leoprikler: will check there, thanks. davexunit: dsmith-work: do you remember any context around why it was removed? leoprikler: It was not removed it was simply made non-default. leoprikler: So you need to explicitly say that you want them now. dsmith-work: Nope. It's in the NEWS file. I noticed becuse scwm used that in some places. dsmith-work: The NEWS doesn't say why. davexunit: so I guess there's no scheme standard that includes them janneke: WINEPREFIX=~/.wine64 wine64 cmd /c guile.cmd -c '(display "hello\n")' janneke: hello janneke: \o/ leoprikler: nice janneke: yeah -- i was about to give up, and of course, more interesting tests fail janneke: oh wait, my scripts have 2.2 hardcoded, it's not that bad wingo: moo lampilelo: so arch still didn't upgrade to guile 3 wingo: lampilelo: is it because it just didn't happen yet, or was there a reason? lampilelo: wingo: i don't think there's an actual reason, probably just because there's not much push for it from the community fnstudio: hi, sorry, i suppose there's no way around this but just in case... in terms of the shebang string at the start of my guile script... /usr/local/bin/guile doesn't seem to do it (guix on a foreign distro here and guile is elsewhere) lampilelo: or maybe the fact that autogen, a dependency of gnutls, doesn't compile with guile3 because the version in the repos is from 2018 and it has a hardcoded check for guile version fnstudio: i wouldn't be very keen to hardcode my home path, on the other hand i suppose there's no other option that maintains generality fnstudio: (generality = a standard path like the one in /usr) fnstudio: unless i create a symlink which also doesn't look clean fnstudio: yeah there must be no alternative i guess lampilelo: fnstudio: does '#!/usr/bin/env guile' work? fnstudio: lampilelo: brilliant, that works :) although i had to get rid of the "-e main -s" bit fnstudio: but there might be a way of putting it back if i escape things properly fnstudio: also i don't think i need -e main -s now fnstudio: lampilelo: so that works brilliantly for me, thanks! :) wingo: fnstudio: if you want to preserve the ability to load the file and not "run" it, you can end the file in (when (batch-mode?) (apply main (program-arguments))) lampilelo: fnstudio: no problem wingo: batch-mode? returns true when you would want to run main lampilelo: wingo: i think it's just too much work for the maintainer, and my guess is it's the autogen problem, they use a version from the website, which didn't get any updates since a long time, they release new versions only on savannah lampilelo: i marked autogen as out of date some time ago but i see that the flag was removed lampilelo: i have no idea how to make this happen lampilelo: probably write and email to maintainers lampilelo: an* wingo: sounds frustrating lampilelo: maybe i'll get around to doing that if i ever get tired of compiling guile and gnutls by hand ;) wingo: :) wingo: rlb: scheme@(guile-user)> (use-modules (ice-9 i18n)) wingo: scheme@(guile-user)> (list "⇒a" "⇒b") wingo: $1 = ("⇒a" "⇒b") wingo: scheme@(guile-user)> (map (lambda (s) (substring/shared s 0 1)) $1) wingo: $2 = ("⇒" "⇒") wingo: scheme@(guile-user)> (apply string-locale-ci=? $2) wingo: $3 = #f wingo: you found a nice bug :) civodul: does string-locale-ci=? compare beyond the end of string? wingo: yep civodul: compares the stringbuf instead of the string or something wingo: because it uses u32_strlen civodul: uh wingo: so could read anything civodul: woow, good catch wingo: very exciting stuff :P civodul: yup civodul: does string-take use substring/shared actually? civodul: seems not civodul: if we had immutable strings, it could, and that'd be nice... wingo: related bugs in string-locale=? and friends civodul: ouch wingo: but that's the extent of it afaiu wingo: rlb: regarding use of u32_strcoll which doesn't have a variant that takes a number of codepoints -- wingo: i wonder if u32_normcoll could substitute wingo: i don't know much about normalization tho wingo: maybe that doesn't work, normcoll has a different interface wingo: interestingly the implementation of u32_strcoll just converts to the locale encoding and calls strcoll wingo: so i suppose we should do that. rlb: is there a strncoll or something? rlb: Oh, though I guess if we're converting it doesn't matter. rlb: i.e. we can null terminate, unless we're supposed to dtrt even with embedded nulls? rlb: i.e. unicode null is a thing. rlb: U+0000 *: rlb has had to deal with that before, elsewhere. rlb: (in json contexts -- pg does *not* support it, but unicode does) rlb: pg -> postgresql rlb: hah "(This is really a POSIX/C problem, but that doesn't mean we can't solve it out-of-spec) It would be nice if there were a variant of strcoll() that took a length, "strncoll()", or didn't use null-termination at all. Then PostgreSQL wouldn't have to allocate extra copies of strings just to call strcoll() in some scenarios where it has a non-NT string. ICU can do this." rlb: -- https://wiki.postgresql.org/wiki/FreeBSD *: wingo nod rlb: I'm a little surprised glibc doesn't have something like strncoll... wingo: so many layers of bad rlb: :) wingo: hum i wonder why the test i added fails ArneBab: on building community and momentum (a view on Clojure by a former user): https://gist.github.com/wildermuthn/c783ed4f6735fa66c4e7ad34830b3977 flatwhatson: re: Guile 3 on archlinux, I think a number of people are using Guix for this flatwhatson: it's not so different to using rustup or nvm/npm or pyenv etc. (if you squint) leoprikler: Except you can install Guile without Guix and (partially) use Guix as replacement for rustup, npm and pyenv :) leoprikler: Arch folk ditching pkgbuilds for Guix sounds kinda out of character as well. Where's the fun in breaking your system if you can trivially recover? flatwhatson: Arch folks playing with shiny toys is perfectly in character :P spk121: does anyone know a way to test if the JIT is working correctly? I'm trying to figure out if my MinGW JIT hack is running right civodul: spk121: you can set GUILE_JIT_THRESHOLD=0 to force jitting everything spk121: civodul: so if I to that and run ./check-guile and it passes, does that mean that JIT is working? civodul: yup, i think so! *: civodul -> zZz civodul: happy hacking! :-) spk121: huh. I did not expect to be able to get that working civodul: well done rlb: Is the 'h' in scm_struct_init documented anywhere? (Maybe I missed it.) fnstudio: hi, suppose i want to glue a few strings together into a url, eg "://://" fnstudio: is there a guile-y way of doing this? fnstudio: i'd like to avoid string-append since a few bits are sort of scaffolding that'd make the use of string-append very verbose rekado: fnstudio: (web uri) has build-uri to build URIs fnstudio: rekado: oh great, i'll look at that then, thanks! fnstudio: hi, i'm struggling with a http-post request: https://paste.debian.net/1189371/ fnstudio: there's a header that i'm supposed to add to the request that doesn't seem to be recognised/accepted fnstudio: and the request generates a "Bad value for header" error mdevos: fnstudio: maybe replace the symbol test with the string "test"? mdevos: I dunno fnstudio: mdevos: hey thanks, i'd actually tried that but it didn't help, but thanks for suggesting it mdevos: I found something relevant, let me post a link ... mdevos: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/publish.scm#n665 fnstudio: let me see mdevos: --> declare-header! fnstudio: mdevos: hm true, it must be that fnstudio: although i've just tried with "declare-opaque-header!" and that didn't work, i'm going to try with "declare-header!" but that means i need to dig a little bit deeper and get a grasp of what the parser/validator/writer should be fnstudio: thanks a lot, that's definitely put me on a good track iv-so: what is current state of elisp in guile? fnstudio: mdevos: this seems to work now https://paste.debian.net/1189380/ fnstudio: i can see the request to be generated and sent to the server fnstudio: so i'm now past that error fnstudio: although i got into another one immediately downstream of that fnstudio: the server doesn't seem to like the request and the connection is closed straightaway fnstudio: with a 401 fnstudio: it works with curl fnstudio: this is no longer about guile though, it might be that i'm missing a header or something ArneBab: fnstudio: can you watch the network with wireshark? fnstudio: ArneBab: yes, that's what i did, i was able to compare the two requests, curl vs guile fnstudio: that gave me a hint fnstudio: as the curl one contained a authorization header fnstudio: i thought that guile would transform the userinfo argument into a auth header (by calculating the hash of username + password) fnstudio: (or whatever... i might have misphrased the above, but you get what i mean) fnstudio: but i was wrong fnstudio: and i can actually read: "But since passwords do not belong in URIs, the RFC does not want to condone this practice" fnstudio: (https://www.gnu.org/software/guile/manual/html_node/URIs.html) fnstudio: so the userinfo is actually just the username fnstudio: so i added the auth header "manually" and that... did the trick! fnstudio: so i now have a working request, filed under small wins :) fnstudio: i actually copied the authorization header over from the curl tcpdump fnstudio: as a test fnstudio: so i now need to actually build it programmatically in guile wingo: good evening wingo: spk121: nice work getting jit enabled on mingw!!!! wingo: works with GUILE_JIT_THRESHOLD=0 then ? ArneBab: wingo: do you know offhand how the Lilypond-folks could switch between optimization levels? On the lilypond list there are now benchmarks of Guile 1.8 vs. 2.2 vs. 3.0.6 that do not look all bad — 3.0.6 is still slower for them than 1.8, but less so than 2.2 wingo: ArneBab: these benchmarks, i guess they are about time to load a file from source and then read and local-eval some expressions, is that right? ArneBab: https://lists.gnu.org/archive/html/lilypond-devel/2021-03/msg00054.html wingo: i assume that compile time is not part of the benchmarks ArneBab: https://lists.gnu.org/archive/html/lilypond-devel/2021-03/msg00049.html ArneBab: I’m not sure — it could well be, because Lilypond has lots of code embedded in ly-files. wingo: right. so what is happening here is a few things at once. it would not appear that the change to the reader is significant. the biggest difference between 1.8 and 2.x/3.x is that we run psyntax eagerly on the input, then eval, instead of just starting eval directly. and in 1.8 eval is in C, and 2.x/3.x it is in scheme mdevos: wingo: have you received my mail on a (fixed) wait-until-port-readable/writable patch for guile-fibers? (I don't need a response to it yet, just checking :-) as some people have inboxes with >4K unread mails). ArneBab: But 3.x is much faster than 2.2 again ArneBab: It’s just not yet at the level of 1.8 again wingo: depending on whether eval is called from c or scheme will affect lilypond's experience; calls from scheme faster than calls from c rlb: Hmm, I'm likely misunderstanding something, but i18n.c's SCM_STRING_TO_U32_BUF uses scm_i_string_wide_chars which strings.h says doesn't guarantee null termination, but it then calls u32_strcoll, which requires null termination? rlb: s/requires/depends on/ wingo: ArneBab: anyway i guess good that 3.0 on the same order as 1.8, and good to know reader isn't big issue. might make sense to think about time-to-eval in future but no significant perf regressions in 3.0.6 afaiu for lilypond wingo: though i guess they don't test 3.0.5, so i can also assume that our general direction towards better perf will be fine for them, given that they don't track it on the day-to-day ArneBab: it’s still not back at the performance of 1.8, but I think we’re getting closer to enabling them to switch. wingo: hard to beat the latency of a pure-C interpreter with lazy macros wingo: lazy macros. what a bonkers thing ArneBab: 3.0.5.116-85433 "eating a little more memory than with guile-1.8.8 but far less than guile-2.2.6" fnstudio: (any obvious module for base64-encoding/decoding?) wingo: fnstudio: there is one in guile-lib ArneBab: fnstudio: I only have some base32 encoding wingo: ~/src/guile-1.8$ ./pre-inst-guile wingo: guile> ((if 42 if list) #f 10 'hey) wingo: hey *: wingo shakes head fnstudio: wingo: excellent, thanks, looking that up in guile-lib now civodul: wingo: wat?! wingo: civodul: :) mdevos: wingo: likewise?! wingo: the good old days weren't so good! civodul: what if, in fact, this captured the essence of programming?... civodul: fnstudio: guile-gcrypt has base32 and base64 ArneBab: civodul: I didn’t know … fnstudio: civodul: super, i'll give that a try immediately, thanks wingo: incidentally john shutt of the kernel language died recently. i always thought fexprs were bonkers but enjoyed reading him in the golden days of lambda-the-ultimate civodul: oh wingo: yeah. fellow traveller of weird languages; things are more boring without him wingo: mdevos: no attachment on that mail? rlb: wrt i18n.c and u32_strcoll, fundamentally I'm wondering if we might have a potential buffer overrun there. wingo: rlb: humm i think we probably do wingo: i agree with your reasoning rlb: OK, and I don't see any way to fix it (trivially) with libunistring -- don't think they have non-null-terminated versions. wingo: really! wingo: that's weird wingo: anyway, ok. wingo: i guess we mangle SCM_STRING_TO_U32_BUF then wingo: are you on it? :) rlb: (As an aside, I ended up fully converting strings.c to utf-8 -- in a very blunt manner (would need clean up), and saw that when I started working on the other code that calls into strings.h.) wingo: !!! rlb: I'm not, but I could be -- obviously a very expensive approach would be to just duplicate the wide strings and null terminate them. wingo: yeah but it's reasonable imo rlb: Another would be to put a secret null at the end of all wide strings? Could we get away with that? wingo: i.e. it fixes the problem. for latin1 strings it's already like that rlb: i.e. just stop not null-terminating strings. wingo: can't put a secret null in, doesn't work for shared substrings rlb: ooooooooooooooooooooooooooh rlb: :) rlb: of course -- I should know better. rlb: been staring at that code off and on for days, of course. wingo: :) wingo: how do you see the latin1 / utf-32 / utf-8 tradeoffs? rlb: Oh, and not sure if this is OK either (and could be changed), but I got rid of SH_STRINGs, i.e. strings just point into their buffers, and always know their fully computed offset. wingo: i.e. is utf-8 a clear winner for you? rlb: Well, I think it's a good bit easier to deal with in some ways, since I changed it to have ascii and non-ascii strings, the former are fixed-with, but *all* bytes are utf8. rlb: i.e. we can pass the string bytes from either string to the u8_... functions. rlb: The biggest cost I've seen so far is (unsurprisingly) any use of set_x rlb: or ref rlb: say in a loop. wingo: yeah rlb: Code like that will need to change (where possible) to use traversals/transformers/folders of various sorts. rlb: and sorry, didn't get rid of shared strings, just changed them to hold a pointer to the original *string* not the string's buffer since non-ascii strings now have byte-start and byte-length memebers. fnstudio: (thanks civodul, gcrypt did it!) rlb: That's a trade off I made for perf in the common cases, i.e. non-ascii strings keep the computed byte offsets too. rlb: (into the buffers) rlb: And of course, imagine it's all buggy -- can't run any of it yet, and need to review for remember_upto_here use (once I remember the rules), etc. wingo: sounds tricky from a threadsafety POV wrt string-set! rlb: yeah, I'm not even sure I understand what our expectations are there yet, and/or what we promised before. rlb: unless it's an ascii string and an ascii char, then you have to just copy/rewrite it. wingo: races are possible, crashes are not, is the basic thing. means that if you need to change the "shape" of a shared mutable string, you need to be able to allocate a new one and atomically swap it in; from that POV, any byte offset would be invalidated rlb: wingo: I think maybe any of the libunistring functions with "str" in the name require null termination, so this could find other places we might want to review: git grep -E 'u[138][^_]+_.*str' wingo: logic is in scm_i_string_ensure_mutable_x rlb: Hmm, I'll have to think about what that might mean for sharing -- i.e. we can't update all that atomically the way I have it when there's sharing? Not sure. I'll think about it. wingo: yeah something to mull over rlb: Maybe we can't do that without an immutable "shared offset" table or something? rlb: that we can swap in atomically, i.e. one pointer would have to cover both the stringbuf and all the shared offsets rlb: or we'll have to "do something else" wingo: generally speaking character offsets can persist; byte offsets are tricky rlb: shared strings and multibyte... wingo: for utf8 rlb: right I meant the byte offsets wingo: so if you can detect that the underlying object changed, you can invalidate a byte offset rlb: but if we don't cache those, it's going to be much uglier perf-wise. rlb: hmm, yeah, maybe that's better -- come up with a lazy approach wingo: and if you need to make an atomic change that might alter the byte size of a character, either you realloc or serialize through a mutex rlb: but may still have some tricky data races if we're not careful... rlb: mutex would make it much easier (of course) wingo: but tricky without string buffers as an indirection wingo: nb, i am not arguing for string buffers civodul: fnstudio: actually weinholt is the original author of the base64 module and the one to thank :-) rlb: oh, I kept string buffers. wingo: just pointing out an aspect of the current arrangement wingo: rlb: mutation-sharing substrings are not an important perf case -- imo anyway wingo: so simple and correct >>> complicated and faster wingo: in that regard rlb: suppose we could just use more of a sledgehammer for the first version then, and optimize later if it turns out to be worth it. rlb: i.e. think that's roughly what you said. wingo: sure. as long as we can avoid a mutex for most instances of string-set! fnstudio: right, thank you civodul for the tip and weinholt for a library that's just been extremely useful (gcrypt) wingo: or maybe that's not even a requirement, dunno rlb: (...looks like most of the cases that might involve null termination questions are in vasnprintf.c and i18n.c) rlb: well in any case, ascii strings don't have that problem, so that's another chunk of the time we won't be affected either way. wingo: well, goldurnit, should probably fix that before 3.0.6 wingo: but is my only current blocker in that regard fwiw wingo: the null-termination issue i mea wingo: n rlb: well, it's been that way for a *long* time. rlb: I'd guess. wingo: yeah sure but now that i know it, i hate it :P rlb: Heh - I might be able to help, but depends on the timetable - I might or might not have time in the much shorter term. rlb: Anyway, and wrt the utf8 stuff it's all so far a *hack* - I just clobbered code freely (deleting, rearranging, reformatting), in ways that might be pretty eyebrow-raising for an upstream submission, so aside from actually getting it working, I might also have to do a *lot* of clean up, deprecations, properly documented removals, etc. rlb: (So still might not go anywhere...) wingo: yeah regarding utf8, is definitely in the 3.2 category wingo: not a 3.0 thing rlb: Oh, *no doubt* :) wingo: :) rlb: btw, I'd started using utf8_t* for the bytes (as does libunistring), but of course a lot of apis have char* -- in terms of the public strings.h api, would we stick with char* and coercions, or...? wingo: good question :P wingo: publicly, no change IMO wingo: there is very little good that would come from change to the string C API :P wingo: (initial reaction, obvs) wingo: internally -- hoo dunno. initial reaction is uint8_t* is sufficient, not char*, but not sure about utf8_t*; though note that FOO_t is reserved by the c standard wingo: so would hesitate to define one locally *: wingo zzz rlb: we already get one via libunistring. stis: hello guilers! tohoyn: stis: hej allan[m]: stis: hello! spk121: I wonder if anyone ever uses Guile on Cygwin? I'm expecting Cygwin to die off because of WSL, even though it is still actively maintained for now spk121: It is telling that there a like a half-dozen different ways to deal with how non-POSIX windows is, and how each one has its adherents. A maintenance nightmare rlb: Is the comment above SCM_MAKE_CHAR in chars.h really just noting the behavior for negative values? i.e. latin-1 is a subset of unicode? spk121: rlb: it is trying to handle casting signed char, unsigned char, and uint32_t into codepoint values rlb: right - just wanted to make sure that the "latin-1" bit wasn't particularly relevant. rlb: i.e. every latin-1 code point value is the same utf-32 code point value rlb: so it's mostly just worried about < 0, I think? spk121: true rlb: And thanks. rlb: wingo: yes, wrt utf8 and say pcre, though the main issue there is actually latin-1, not utf-32, fwiw, i.e. pcre doesn't do latin-1, only unicode or raw bytes iirc. rlb: i.e. it only does bytes and utf-{8,16,32} rlb: so latin-1 is expensive rlb: (also have to compile matchers per-encoding, so having a single encoding is more efficient and easier) lispmacs: hi, my Guile skills are a bit rusty. When I am in the interpreter, how do I load in a file from the cwd? mdevos: lispmacs: (load "stuff.scm") mdevos: or (include "stuff.scm") (semantics are somewhat different) lispmacs: thx Noisytoot: mdevos: What are the differences? rlb: If it were feasible, and unless scheme regex's are likely to have competitive performance, I'd also love to have an easy "standard" option for regexps. Were I to do it, that might mean built-in support for maybe pcre. (And if there's interest, I'd be happy to try to help there -- already did it for lokke.) rlb: flatwhatson: plese let me know if you figure anything further out wrt the gnutls issues -- debian's next freeze level begins on the 12th, so much easier to get a fix in now if we need it, than after... flatwhatson: 12th of March? rlb: yep :/ rlb: https://release.debian.org/bullseye/freeze_policy.html#hard rlb: wingo: fwiw, this might well not actually go anywhere, but for no good reason I can discern, I'm still poking at utf-8 strings, and have made non-trivial progress reworking strings.c, etc. i.e. I might not finish, but if I do I'll shout... flatwhatson: rlb, wingo: I have a fix! https://paste.gnome.org/pjara0uwz flatwhatson: setting scm_install_gmp_memory_functions = 0 *does* work, but only if you don't later set it to 1 rlb: doh!? *: rlb contemplates warming up sbuild daviid: dsmith-work: done, see bug#47084 spk121: janneke: in guile spk121: janneke: in guile's master branch, I've checked in a lot of the 32-bit mingw patches from that guile 2.2 branch. It would be cool if you could adapt your 64-bit mingw patch for master janneke: spk121: great, i'll have a look wingo: flatwhatson: !!!!!!! wingo: wow :) wingo: must be why my tests didn't show changing it to have any perf impact wingo: rlb: in any case i would think that utf8 strings would be useful for possibly adopting external regexp libraries wingo: spk121: haha that mingw libpath thing is horrible :) wingo: ah well civodul: hi there! civodul: i'm looking for testers of https://notabug.org/guile-zlib/guile-zlib on a non-Guix distro; any takers? :-) civodul: basically building and running "make check" mdevos: how can I run a single test of guile's test suite? mdevos: (make check TESTS=tests/$THE_TEST.test recurses into test-suite/test-suite, which doesn't have the test) mdevos: civodul: will do in my Debian VM wingo: mdevos: ./check-guile foo.test wingo: or are you trying to run one of the standalone tests mdevos: wingo: no, a Scheme test wingo: spk121: would be interested to hear about the read-line changes fwiw spk121: wingo: yeah, that is the sort of controversial one< I guess spk121: I started out just wanted it to handle CRLF as well as just LF spk121: And while I was there, I threw in the Unicode line endings that almost no one uses for pedantry's sake wingo: what would be the disadvantage of ending lines at CR ? wingo: and then slurping a LF if the delimiter was CR wingo: just wondering how to get back the perf advantages of port-fold-chars spk121: Well that's the way it had been. The disadvantage could be seen in reading web headers, which expectes CRLF, which is where you'd actually done exactly that spk121: I guess it is a matter of expectation. If you are reading a utf-8-unix file and do read-line, you get a line. If you are reading a utf-8-dos file, you don't get a line. You get a line + return, which is neither a line nor a line + terminator spk121: If I wanted to appeal to authority rhetorically, I could point to https://www.unicode.org/reports/tr14/#BreakingRules , but, I didn't really follow those rules exactly either, because literally nobody uses NEL spk121: But OTOH, it isn't a need for Guile on MinGW to work, and reverting it is not a problem wingo: just for info, did you do any perf testing of those functions? wingo: i guess if we really want to have \r not followed by \n as part of a line and not a delimiter, i would be more inclined to keep %read-line be a bit dumber, and make read-line do a read-delimited of "\n\r", and possibly repeat if \r not followed by \n wingo: you know, string-append and recurse, etc wingo: but, am interested in any thoughts you had there spk121: wingo: the lack of benchmarking is definitely a valid criticism. I could try to put something together. spk121: But, if I were at work, I would probably say that first we need to decide what are the actual requirements of 'read-line' and do we meet those requirements. And then afterward meeting the requirements, one would work on optimization spk121: So what are the requirements of a 'read-line'? spk121: But I do want to stress how *mild* any argument I'm making right now is, and how I'd be happy to go with whatever wingo: for me the requirements are: as good perf as possible. allows further port optimizations. keep compatibility with old code. wingo: reads \r\n is a nice-to-have, but it can conflict with compatibility wingo: like people could have code out there that relies on the old behavior. dunno how to mitigate that wingo: i am on board with reading \r\n but i just wonder about compat. perhaps less of an issue considering how sub-par guile's windows story is atm wingo: would be good to see what read-line has done in the past, if it always just read to \n spk121: wingo: read-line has always just be \n or . I don't know if you open file ports in text mode if they do any CRLF chomping spk121: I tried to come up with a benchmark. As near as I can tell, the performance before/after seems in the noise spk121: if I've done it correctly spk121: https://paste.debian.net/1189001/ wingo: yeah perf looks good, tx *: wingo still wants to improve the suspendable-ports results... wingo: but that concern is from before :P spk121: well, we could punt on this and revisit for version 3.2.x, if there is the possibility of code out there actually parsing CRLF with read-line and depending on old behavior. I'm not sure how likely that is, but, who knows? spk121: if you revert it in git, the patch will still remain in tree for posterity, so it can be reintroduced later mdevos: sneek: later tell civodul: guile-hall is not packaged for Debian, so you might run into trouble there sneek: Got it. mdevos: sneek: later tell civodul: never mind, I see configure.ac & Makefile.am exist sneek: Will do. stis: Hi guilers! mdevos: sneek: later tell civodul: "make check" fails with guile-2.2 (I opened a bug) sneek: Will do. mdevos: sneek: tell mdevos: feed me sneek: mdevos:, mdevos says: feed me mdevos: sneek: botsnack sneek: :) civodul: mdevos: thanks! sneek: civodul, you have 3 messages! sneek: civodul, mdevos says: guile-hall is not packaged for Debian, so you might run into trouble there sneek: civodul, mdevos says: never mind, I see configure.ac & Makefile.am exist sneek: civodul, mdevos says: "make check" fails with guile-2.2 (I opened a bug) civodul: spk121: a possibly useful tool is "./benchmark-guile read.bm" (or similar) manumanumanu: stis: Tjenare! What are you up to? mdevos: quick status update: fchmodat, renameat, mkdirat & symlinkat have been defined and readlink, chdir & utime accept file ports now! To be continued civodul: mdevos: guile-zlib should be fixed now, thanks! civodul: mdevos: re *at, nice! mdevos: I'm wondering, should I define a rmdirat even though it doesn't exist in C? The (rmdirat dir name) would actually be implemented as (unlinkat dir name AT_REMOVEDIR) mdevos: I dunno why rmdirat doesn't exist and folks decided for AT_REMOVEDIR instead civodul: i'd say stick to POSIX, so provide unlinkat and AT_REMOVEDIR but not rmdirat mdevos: I would prefer defining a rmdirat, but whatever. I'll add a comment to rmdir explaining there's no rmdirat civodul: ok mdevos: (I see no reason to stick exactly to POSIX, as long as the POSIX<->Guile mapping remains clear) civodul: yeah well civodul: i think we can have POSIX at one layer, and possibly higher-level interface on top of that civodul: but "rmdirat" looks like POSIX, but it's not POSIX civodul: dunno, i'm nitpicking i guess :-) mdevos: Counter-nitpick: The procedure "open" isn't exactly POSIX either, as it returns a port (POSIX equivalent: FILE *) and not a file descriptor. mdevos: But we can always define a new bike shed later :-) civodul: true :-) mdevos: but does anyone have an idea why there isn't a rmdirat? RhodiumToad: the SUS rationale section doesn't say RhodiumToad: probably someone just didn't want to add another function dsmith-work: Happy Friday, Guilers!! civodul: Happy Friday! civodul: mdevos: could you "git pull" guile-zlib and retry "make check" (on Debian)? mdevos: civodul: will restart the VM civodul: ah, sorry for the extra work mdevos: ... apparently closing GNOME boxes doesn't stop the VM, it just suspends it civodul: handy, i guess mdevos: the clock is an hour behind now. mdevos: Also, something I noticed: you can 'unsuspend' a suspended VM even after the host system rebooted mdevos: PASS: tests/zlib.scm civodul: yay! civodul: thanks, mdevos! mwette: civodul: re guile-zlib, I forgot how to generate configure. autoreconf? sneek: mwette, you have 1 message! sneek: mwette, nly says: ill be more than happy to test guile libfuse mwette: sneek: later tell nly: lost track re libfuse, here is the ffi file: https://paste.debian.net/1189035/, you just get nyacc and type "guild compile-ffi ffi/fuse.ffi" sneek: Will do. mwette: civodul: I get a configure error: syntax error near unexpected token '3.0' , for 'GUILE_PKG(3.0 2.2 2.0)' mwette: civodul: I used 'autoreconf -vif' before configure civodul: mwette: hi! that means you're missing guile.m4 (provided by Guile) in ACLOCAL_PATH civodul: if you installed Guile under /usr/local, you probably need something like: ACLOCAL_PATH=/usr/local/share/aclocal mdevos: mwette: I think I had to "apt-get install guile-2.2-dev" civodul: ah right mwette: ah, I have my own guile installed, no apt, and build process is not happy. I did fix ACLOCAL_PATH nd see that guile.m4 is there mwette: now getting "configure error: No Guile development packages were found." mwette: oh: PKG_CONFIG_PATH -- lemme try that mwette: OK. That works now. all pass mwette: ubuntu 2.10 x86_64 dsmith-work: daviid: Closed civodul: mwette: yay, thank you! civodul: i guess we should at least improve the build instructions... mwette: civodul: yw dsmith-work: Ok, cool hack of the day. Non-guile though. Got a long-running process on another machine I'm not looking at. (a build or a dd or something) dsmith-work: Have a script there with: echo "$*" | nc -u -w 0 -b 192.168.1.255 7478 dsmith-work: And on the machine I'm looking at: dsmith-work: while true; do notify-send -t 0 -u critical -- "$(nc -l -u -p 7478 -W 1)"; done dsmith-work: Sends a upd packet with netcat and does a notiification. mdevos: Would a ‘statat’ binding need a ‘exception-on-error’ argument? 'stat' has one, but ‘lstat’ doesn't. wingo: heyyy wingo: spk121: would you be ok if i reverted the read-line things for the moment? spk121: go for it wingo: how much does it affect mingw usage? wingo: like if you run on mingw, without that patch, do tests start failing or something, or do "normal" uses not work? spk121: It only matter for people using Guile on native windows that want to parse text files. It doesn't affect the test suite or the build, I think spk121: Also, the test suite still has 20 ish failing tests, so it was never going to be perfect for this build anyway wingo: i guess the impact would be having a trailing \r on returned lines for ports not opened in text mode wingo: (apparently O_TEXT eliminates the \r, fwiw) spk121: wingo: yeah O_TEXT is supposed to have that effect. Don't think I've ever tried it, though wingo: so many moving parts :P spk121: Guile could use some better CI/CD. The old hydra.nixos would build guile on a bunch of platforms / OS's wingo: yeah agreed wingo: we have a lot of great synergies with guix but moving closer to guix has moved us a bit farther away from many platforms common with users wingo: no complaints, nb, just a note, and a thing to work on in future civodul: there's also been a lot happening on Debian civodul: and Aleix working on Homebrew civodul: overall, i think Guile packaging has gotten much better over the last couple of years civodul: even for those not using Guix :-) civodul: (not that it helps for MinGW tho) wingo: good points! spk121: for a bit I was trying to build Guile on MinGW as a step in trying to build Guile-GI on MinGW. This was on Github/Azure, so it is many different levels of non-free badness wingo: apteryx: welcome to guile-lib wingo: plz push whatever patches you see fit :) if you need feedback, me civodul daviid and rotty are project admins and would be happy to give feedback wingo: careful, if you make too many good patches, you too will be admin & release manager rgherdt: good evening! I opened a bug report and submitted a patch 284 days ago, due to an implementation error in hash-table-merge! (currently it basically "merges" the first ht with itself, ignoring the other one) rgherdt: Here the ticket: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41131 rgherdt: Could someone please take a look at it? wingo: good evening :) wingo: rgherdt: applied, tx for ping :) rgherdt: wingo: thanks, you're welcome wingo: i wonder what kevin ryde is doing these days wingo: he did great guile maintenance in the 1.6 times *: wingo zzz wingo: night! daviid: dsmith-work: if you don't mind, we should close bug#43025 - the bug msg is inadequate, and the answers gives the impressinon it is a 'problem', instead of a high severity bug, a regression imo, related to a guile core supported functionality that somewhere somehow, got 'broken' susequently to module and/or compiler changes - i'd re-open it with a proper message and the above snipset to reproduce ... wdyt? rlb: wingo: don't know if this is interesting, but thought I'd point it out to you in case it is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977223#22 rlb: sneek: later tell civodul guile-3.0 3.0.5-3 is in debian unstable now, with the gmp fix -- thanks again sneek: Got it. akira121: Hello, how can I split my code in multiple files? I've been trying to `define-module` and `use-modules` but it says `no code for module (prefix)`. flatwhatson: Hi, I saw recently a fix was pushed regarding Guile vs GnuTLS vs GMP corruption. I have some code which is affected by this bug: https://github.com/flatwhatson/guile-gemini flatwhatson: Problem is, I'm still seeing the corruption occurring with the latest guile from git. Likewise if I build 3.0.5 patched with scm_install_gmp_memory_functions = 0 flatwhatson: Running with guile 3.0.0, everything works correctly. So I'm not sure the current fix is sufficient? wingo: flatwhatson: that's... odd! wingo: flatwhatson: what about guile 3.0.4 ? wingo: i don't really know how to isolate this issue without bisecting wingo: unless you want to record in RR, set a hardware watchpoint on the bad address, and then run backwards flatwhatson: Ah sure, I can test against other release builds, I'll get back in a few hours. flatwhatson: I don't understand "record in RR", happy to try to pin things down in gdb but I'll need some hand holding. ArneBab: daviid: ah, it’s been reported already — sorry. civodul: hey there! civodul: rlb: thanks for the Debian upload with the GMP fix! wingo: ArneBab: not a bug -- gperf is only used if you are building from git wingo: the output of gperf is included in tarballs wingo: in the same way we don't have a way to check for e.g. autoconf wingo: so, if you build from git, you'll need gperf, is all ArneBab: wingo: would a patch be accepted that checks in configure whether we are building from git? ArneBab: (and if yes, checks for gperf) ArneBab: the shortest version: we need at least one of .tarball-version and gperf wingo: i would not add a check in configure, fwiw civodul: perhaps we can use AM_MISSING_PROG or whatever it's called for gperf wingo: but it's not needed when configure is run wingo: or does that make autoconf itself check for gperf? wingo: anyway to me is a non-problem RhodiumToad: for comparison, what postgres does for bison/flex is check for them in autoconf, but if they're not found, it just gives a warning about how you only need them if building from git or modifying the grammar civodul: wingo: yeah i agree it's a non-issue civodul: AM_MISSING_PROG is just to display a nice message in case the thing is not found lloda: now in Guile every error gets reported as lloda: "ice-9/boot-9.scm":1686:16: In procedure raise-exception: lloda: ... lloda: no matter where it happens lloda: i don't remember when the change happened, I think 3.0? but it was different before lloda: it would tell you where the error actually happened civodul: lloda: the backtrace should have more info though, no? lloda: sure, but before you'd know where the error happened without needing to look at the bt lloda: i mean that line is always the same boot-9.scm point lloda: it doesn't say anything useful civodul: right civodul: we could cut the last frame or so flatwhatson: re: gnutls, i've confirmed that 3.0.1 and 3.0.4 are also showing the bug flatwhatson: was struggling to reproduce, but remembered i'd turned off gnutls debug logging flatwhatson: all the extra garbage from printing gnutls logs makes that error apper much sooner lloda: i've lost track a bit of the different kinds of exceptions there are now tbh lloda: i just use throw and catch RhodiumToad: in 3.x there's only one kind of exception now, iirc? lloda: i need to do some reading then lloda: i'm used to just throwing symbols lloda: if throw/catch are out and raise-exception/with-exception-handler are in, i'd say we've lost something in quality of naming RhodiumToad: they're both now variants of the same thing, no? lloda: the manual seems clear, i just never looked at this section before lloda: i'd say there's some redundancy? if you were doing this from scratch, you probably wouldn't have so many functions RhodiumToad: well yeah tohoyn: lloda: there is also the guard form you can use instead of with-exception-handler flatwhatson: is there some trick to using rr with guile? flatwhatson: replay fails with "Assertion `ticks_now == trace_ticks' failed to hold. ticks mismatch for 'SYSCALL: mmap'" wingo: flatwhatson: when i have used it it works for me fwiw wingo: no tricks wingo: flatwhatson: are you on amd, perhaps? wingo: i assume you're on amd64 but wondering if you are on intel or amd hardware wingo: lloda: yeah the exception situation is a bit of a mess wingo: maybe that can be part of 3.0.7, to improve a number of specific errors, and possibly to switch more things to structured exceptions wingo: while still guaranteeing throw/catch compat wingo: but still the source location should be fixed, i agree wingo: flatwhatson: if you run with GUILE_JIT_THRESHOLD=-1, does the problem still show up? wingo: flatwhatson: i wonder if possibly you are running into section 3.4 of http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.10.4159&rep=rep1&type=pdf flatwhatson: wingo: i'm on intel, using guix environments for testing flatwhatson: do you specify something for --syscall-buffer-sig? wingo: i don't, no flatwhatson: "Tracee is using the syscallbuf signal (SIGPWR)" "Try recording with --syscall-buffer-sig=" wingo: could be i haven't used rr in a while wingo: in that case yeah you might have to choose another signal, as libgc is using SIGPWR i think flatwhatson: it's happy with --syscall-buffer-sig=12 (USR2) wingo: same thing as https://github.com/rr-debugger/rr/issues/2294 i guess flatwhatson: then on replay it bombs out with this: https://paste.gnome.org/ptjwtfqgn flatwhatson: attaching gdb gives backtrace: https://paste.gnome.org/pvtbkyzlz flatwhatson: seems there have been a few similar-looking issues on rr, i probably just need to report it wingo: sounds like a frustrating experience civodul: flatwhatson: FWIW i have to pass -n to "rr record" flatwhatson: on the bisection front, 3.0.0 works and 3.0.1 doesn't flatwhatson: patching 3.0.1 with scm_install_gmp_memory_functions = 0 doesn't work flatwhatson: completely reverting 00fbdfa7 works! flatwhatson: looks like scm_install_gmp_memory_functions actually only controls installation of a finalizer, and not installation of the custom gmp allocation routines flatwhatson: oh, derp, it does control installation of those routines... wingo: but probably if !scm_install_gmp_memory_functions, we should allocate pointerless data... wingo: humm wingo: i wonder if scm_i_clonebig needs a scm_remember_upto_here_1 wingo: of src_big wingo: flatwhatson: try that? flatwhatson: wingo: tried this, doesn't work: https://paste.gnome.org/p6twdtev8 flatwhatson: also tried 3.0.0 with scm_install_gmp_memory_functions = 0 and that *does* work flatwhatson: struggling to see what the difference between that and the patch i linked would be... wingo: flatwhatson: the problem exhibits itself with stock gnutls ? wingo: i.e. just with guile-gnutls? wingo: flatwhatson: regarding scm_install_gmp_memory_functions = 0 or not, perhaps try using scm_gc_malloc_pointerless instead of scm_gc_malloc if !scm_install_gmp_memory_functions flatwhatson: wingo: isn't that this patch? https://paste.gnome.org/p6twdtev8 wingo: ah yes sorry wingo: i thought you tried adding scm_remember_upto_here_1 (src_big) to scm_i_clonebig flatwhatson: and yes, I get the problem running under guix environment --pure guile gnutls guile-fibers wingo: --ad-hoc i guess flatwhatson: ah yep! flatwhatson: that's since evolved into a manifest with various versions & patches of guile wingo: yeah dsmith-work: Hey Hi Howdy, Guilers dsmith-work: daviid: Sounds good to me flatwhatson: civodul: that works!! rr record --no-syscall-buffer --syscall-buffer-sig=12 guile path/to/script.scm ... flatwhatson: then rr replay seems to be quite happy! civodul: \o/ daviid: dsmith-work: ok, could you close it then, then i'll re-open a 'more specific' bug report, tx! dsmith-work: Ur? Did I open that? Sure. dsmith-work: daviid: If you open a more-specifc report first, I could reference that. daviid: dsmith-work: ah ok, let's do that indeed, will ping you, have to go afk for 1h or so ... bbl dsmith-work: daviid: Er, what bug was that again? dsmith-work: Ah, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43025 manumanumanu: Good evening! mdevos: Why are directory streams called "directory port" in filesys.h mdevos: (SCM_VALIDATE_DIR) even though they aren't ports? (port? (opendir mdevos: "/")) --> #f manumanumanu: cruft? :D civodul: mdevos: probably no good reason :-) wingo: ~~ spk121 for president ~~ wingo: ahaahahahahahahahaha gnutls.scm ends with ";;; arch-tag: 3394732c-d9fa-48dd-a093-9fba3a325b8b" wingo: appendarchitis civodul: souvenirs :-) manumanumanu: explain it like i'm 5 wingo: imagine ";; this file ends here", but including the name of the file to "help" your version control system manumanumanu: which VCS then? wingo: TLA wingo: 2003 was wild spk121: dude. I remember arch. That was crazy wingo: what is the largest .c file in guile, if you had to guess? *: wingo looked fwiw, but maybe people want to guess manumanumanu: unicode codepoints? manumanumanu: I don't know C, but that doesn't seem completely unreasonable wingo: in terms of bytes, it's numbers.c, almost twice as big as jit.c leoprikler: Fools, it's guile.h post macro-expansion :P wingo: :) manumanumanu: why is that? Noisytoot: wingo: What's ";;; arch-tag: 3394732c-d9fa-48dd-a093-9fba3a325b8b" for? wingo: lots of different kinds of numbers, a bit of combinator explosion of interactions civodul: numbers.c is crazy wingo: the right thing for bignums is really the MPN API and inline digits; but it's distressing to think about implementing wingo: i had a hand in causing some fun security bugs in firefox implementing similar things there wingo: aaah distressing *: wingo averts gaze wingo: i am missing a kind of prioritization effort for guile i think. like where are we going. lots of fun things to do, lots of unglamorous maintenance, dunno what next tho spk121: wingo: next could a proper ci/cd over GNU/Linux/BSD and the various configure flags. Unglamourous, as you say spk121: but of course, srfi-14 in scheme would be a fun project for someone wingo: scope sets, new garbage collector, AOT compilation, register allocation, fixing the compilation-time cliff when you have more than fixnum bits of live locals, mpn, identifying ways to be closer to racket wingo: inline caches for top-level calls, perhaps spk121: maybe there is some sort of wishlist ranking webform someone could whip up RhodiumToad: what's the deal with the module issue that daviid is always complaining about? spk121: High on my wishlist would be linking the core *.go files into single *.a file to improve embeddability wingo: the re-export-modules thing? need to look at that i guess wingo: there does appear to be a user-space workaround tho on the bug https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43025 wingo: spk121: yeah that would be fun wingo: dunno how much to double down on system-specific linkers, or whether to implement a multi-.go packer in scheme wingo: with corresponding loader changes too wingo: or what. luajit seems to manage to get their bytecode into .a files portably, so perhaps there is a simple option wingo: ... converting exceptions to structured exceptions... wingo: optimizations to prompts so you can contify them away wingo: cross-module inlining (https://lists.gnu.org/archive/html/guile-devel/2016-03/msg00026.html) dsmith-work: Moving from libc regex to a Scheme regex? spk121: I apologize in advance for the libpath commit I'm about to make. If anyone knows a better way, please fix it wingo: dsmith-work: yeah that would be good. regexp literals also. and struct literals wingo: having some kind of interface in a running guile process that can allow you to profile as you go wingo: like generating timelines in the format that chrome's devtools can read dsmith-work: So sexp regex and working with scheme strings (instead of C strings) RhodiumToad: is the ssax fix incorporated yet? wingo: RhodiumToad: no, which one? :) RhodiumToad: the one for > in CDATA wingo: i think i haven't seen it wingo: if you would like to help getting obvious patches in, it would be very welcome :) wingo: needs an eye for detail which i think you have dsmith-work: I don't know what's involved: Adding the debugging features needed to allow geiser to be as awesome as slime. Or just be able to do slime with Guile. RhodiumToad: ssax author did post a new version on their site but iirc no changelog or announcement, so now I can't find it at all RhodiumToad: here's the racket version: https://github.com/jbclements/sxml/issues/7 RhodiumToad: that has links to guile-devel post and also to upstream version wingo: first bug in ssax in a decade or so! dsmith-work: Well, that says something! *: RhodiumToad is good at finding ancient bugs dsmith-work: (people don't use xml anymore?) RhodiumToad: most people probably wouldn't notice corruption of > inside cdata RhodiumToad: I think the oldest bug I found is one in the BSD pom(6) program from the '80s manumanumanu: RhodiumToad: it is in upstream RhodiumToad: yes manumanumanu: dsmith-work: there is a pretty nifty SRFI for scheme regular expressions. That, and srfi-166 manumanumanu: Ashinn is a saint! dsmith-work: manumanumanu: irregex? manumanumanu: yes dsmith-work: http://synthcode.com/scheme/irregex This is what I was thinking of. manumanumanu: dsmith-work: it is codified in a srfi now manumanumanu: and, even better, "show" is now srfi-166. manumanumanu: I had a half-finished compiler for srfi-166 uvw manumanumanu: until lightning killed my computer and my local backup manumanumanu: with the goal of making the subset of srfi-166 that implements the features of ice-9 format as fast as ice-9 format. manumanumanu: I was making good progress, but I lost some steam when my drive became charcoal. manumanumanu: imagine: a powerful, user-extensible formatter. dsmith-work: Ah!, srfi-115 manumanumanu: srfi-115 is easily portable. Getting something like the reference implementation of srfi-166 to work means implementing something like 5 other SRFIs. manumanumanu: oh, look at the time! ArneBab: wingo: for me the gperf thing is a problem, because it just costed someone half an hour to figure out who tried to test whether there are regressions for Lilypond. If there hadn’t been a quick reply on the mailing list, that could have well ended that check. And if that happened once where I saw it, we can be sure that it already happened many times where I did not see it. ArneBab: wingo, civodul: What I would like to do is to check at configure time whether the things in the tarball are available, and only to check for gperf if they are not. civodul: ArneBab: typically "configure" does things when building from a tarball civodul: when building from a checkout, it's expected that there are additional dependencies civodul: we should document it, but it's not something "configure" should check for civodul: since forever you also need Flex when building from a checkout, and Autoconf, etc. ArneBab: I didn’t expect that the configure generated from git doesn’t do the checks needed to build ArneBab: I need autoreconf, and it tells me what else I need ArneBab: and the person who tried to check whether there are regressions from guile 3.0.6 for lilypond didn’t expect it either. lispmacs: hi, I'm trying to relearn how to use cooperative repl servers (in 3.0.5) after a year or two away. Something I'm trying to figure out: if I don't connect to the coop-repl-server, and just exit my application, the port is left bound for a while at least. lispmacs: but it isn't obvious to me from the documentation how to properly close a coop-repl-server without connecting to it and running (exit) lispmacs: My system: https://bpa.st/XUPA lispmacs: does David Thompson still haunt this channel? lispmacs: had a Chickadee question. Probably in bed ArneBab: wingo: ah! Nice :-) terpri_: sneek, seen davexunit sneek: I last saw davexunit in #guix 7 days ago, saying: figured it out but boy is the solution ugly. terpri_: lispmacs, ^ ArneBab: manumanumanu: would it help you to get write access to https://hg.sr.ht/~arnebab/wispwot/ ? dsmith-work: lispmacs: Could be becuse of not using SO_REUSE* socket option dsmith-work: ? lispmacs: dsmith-work: okay, I'll look into that, thanks roptat: is there a way to prevent regexps from reading the whole string after the first match? pkill9: roptat: look up lazy vs greedy regex, might be what you're looking ofr pkill9: for* roptat: I mean, (string-match "a+" (string-append "aa" (make-string 500000000 #\b))) should return the first "aa", and I don't care if there are matches after that roptat: (the regexp is taking a few seconds to match that) roptat: (not counting the time it takes to create the string) roptat: to explain, I'm trying to write a lexer, and I use regexps as a simple way to express what it should match. But with big source codes, I have to run regexps multiple times on big strings, which makes it very slow taw10: roptat: You mean you want the first substring? Wrap your expression in (match:substring ..... 0) and it does what you want roptat: (define s (string-append "aa" (make-string 500000000 #\b))) (match:substring (string-match "a+?" s)) is slow, how to make it fast? :D taw10: (tip: reduce the number 500000000 for testing :) roptat: below that number it's hard to see it's slow roptat: my code works well on small files, but it's just taking ages on bigger files taw10: Ah, then I misunderstood the question. Afraid I don't have any suggestion of how to make it faster, except perhaps not using a regex matcher roptat: so, I think it's trying to get every possible matches in the string, and not only the first one, so it goes through all the bs. for what I want, executing the regex would just go through the as, fail at the first b and return the match roptat: no reading an absurd amount of garbage :) roptat: so should I just come up with my own implementation of regexps for that? dsmith-work: roptat: You probably want to write your own lexer instead. wingo: spk121: the posix-w32.h patch described in recent commit wasn't part of the changeset, fyi *: wingo added mkstemp, finally spk121: hmm spk121: oh, since I was pulling in from different PC's that commit was already included from fedb65b98. I could 'force' the commit to remove that, if you want, or just let it go wingo: nah, all fine wingo: just fyi in case you forgot to add something that you wanted to add *: wingo grumbles at gnu copyright assignment procedure civodul: wingo: i reported the -Wunbound-variable issue at https://issues.guix.gnu.org/47031 but haven't yet taken the time to investigate manumanumanu: daviid: I don't have a mouse, and haven't set up my computer for mousle-less navigation, what is the expansion of the macro? manumanumanu: of the bug manumanumanu: the big unanswered question is "what is the use-list of a module?". Why did module-use! re-export the bindings in 2.2 but not in 3. The expansion is not the problem. manumanumanu: now good night again ArneBab: First result from the Lilypond folks testing Guile 3.0.6: The error about the missing gperf command comes during make instead of during ./configure. Could someone check whether the check for gperf is missing from configure.ac? daviid: manumanumanu: forget bout the macro, the macro is fine :) - it is there only to allow users not to have to quote each module name(s) ... the problem is deep downin the module system (the changes that has(ve) been made in 3.0, and/or the compiler, which breaks module-use! daviid: ArneBab: tell them when build from source, they need ti install gperf daviid: the gperf and/or gperf-dev module i don't remember ArneBab: They already found that and are retrying. The point is just that the error should be thrown during configure, not during make. daviid: no, because the cinfigure from the tarball works fine ... daviid: works fine without gperf ArneBab: can we do that check during autoreconf? daviid: manumanumanu: let me paste a smaller example daviid: ArneBab: you'd have to talk to our maintainers, who are aware of this, it's been reported here a couple of times already ... but i don't think it is important enough that they will do something about this 'now' - maybe they'd accept an autoreconf (bootstrap/autogen.sh) patch though, i don't know - but i'd rather have them solve the module-use! bug, which imo is a regression, and/or any other bug(s), 'spurious warnings' ... then work on daviid: 'this' minor problem, not even a bug ... daviid: manumanumanu: here https://paste.debian.net/1188771/ daviid: wingo: here is a much 'better' snipset/report for bug#43025 - https://paste.debian.net/1188771/ daviid: in the above, the define map-a is totally useless, and does not even use the srfi-1 map 'extension', just there to have a define in (a) - the important thing is module-use! is 'broken' in 3.0 daviid: apteryx: the htmlprag patch, did you write it 'alone' or were you also helped by others? asking to mention their name if ... i kind of remember others did propose at least part of the solution, but i am not sure ... chrislck: if anyone can assist -- how exactly do I use srfi-180 reference implementation in guile? it's written as .sld chrislck: is there a magic (enable-sld-read #t) mode? roptat: mh, I'm having troubles with a regexp: (string-match "[^()\\[\\]]+" "text") doesn't match anything roptat: (with or without "\\" roptat: I'm trying to match anything that is not a parenthesis or square bracket apteryx: daviid: for the htmlprag patch, I wrote it alone, but tweaking the parent-constraints idea was suggested by Ricardo Wurmus and authored in Guix as commit 7854bbeb3f88ad4747b0a4ca01021ef2741f7b4e by Ludovic (as a very localized hotfix) daviid: apteryx: ok, I will mention their contribution then, thanks apteryx: thank you! cousin_itt_: Is there a procedure call that you can put in source code that will cause you to enter the "backtrace" environment? I suppose I could type something silly like "(sqrt)" ... but is there some more elegant thing I could do? cousin_itt_: Is there a procedure call that you can put in source code that will cause you to enter the "backtrace" environment? I suppose I could type something silly like "(sqrt)" ... but is there some more elegant thing I could do? dsmith: roptat: Try "[^][()]+" See: man 7 regex. The key to get a ] in a character class is have it first or right after ^ dsmith: scheme@(guile-user)> (string-match "[^][()]+" "text") dsmith: $1 = #("text" (0 . 4)) dsmith: scheme@(guile-user)> (string-match "[^][()]+" "[(text)]") dsmith: $2 = #("[(text)]" (2 . 6)) spk121: dsmith-work: fixed dsmith: spk121: Nice! mdevos: Is it posible to define keyword argument functions in C? I can't find the documentation sneek: Welcome back mdevos, you have 1 message! sneek: mdevos, lloda says: one thing I do when editing Guile code is disable trailing whitespace removal. Unfortunately Guile code has a lot of that and if you have autoremoval on, the diffs will be very dirty. civodul: mdevos: i think you'd have to manually fiddle with rest arguments civodul: anyhow, i recommend doing the heavy lifting in Scheme civodul: keeping as little as possible in C civodul: as a rule of thumb :-) roptat: dsmith-work, thanks a lot! mdevos: Problem is, I'm trying to bring openat, fchmodat, ... to guile, and my plan is to introduce a ‘file-in-directory object’ (essentially a directory port + name pair), and the constructor would take keyword arguments mdevos: like this: (make-file-in-directory DIR NAME #:follow? #t/#f) mdevos: I guess I could define the 'file-in-directory object' & constructor in Scheme in boot-9.scm (or something included from there) mdevos: and define a C function for C users that's less keywordy and just calls the Scheme procedure? civodul: dunno, you could omit the C function civodul: as another rule of thumb, for POSIX bindings, i recommend first providing functions that are a 1-to-1 mapping to the C function civodul: before building abstractions on top of it mdevos: civodul: I suppose I could do that mdevos: I'll write binding to openat, fchmodat, fchownat, utimensat, readlinkat, fstatat and fchdir. Any requests? civodul: sounds good! civodul: wingo: looks like custom binary input ports are buffered by default; perhaps a mistake? mdevos: btw, I've written a patch for O_NOFOLLOW and others: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46220 dsmith-work: UGT Greetings, Guilers wingo: civodul: why a mistake? civodul: wingo: i was expecting it to be unbuffered by default since it's a "user port" civodul: but i think it's always been this way anyway wingo: that doesn't follow, for me civodul: ok civodul: another question: looks like 'drain-input' doesn't clear the putback buffer, amiright? wingo: humm, not sure wingo: appears to clear the putback buffer, for me mdevos: civodul: may the "chdir" / "scm_open" procedure be extended to allow ports as well? That's technically not a 1-to-1 mapping from C<->Scheme, but there's precedent with "chmod" and "chown" wingo: ah interesting civodul: mdevos: yes, probably wingo: no, seems to work properly for me wingo: scheme@(guile-user)> (open-input-string "bc") wingo: $8 = # wingo: scheme@(guile-user)> (read-char $8) wingo: $9 = #\b wingo: scheme@(guile-user)> (unread-char #\a $8) wingo: $10 = #\a wingo: scheme@(guile-user)> (drain-input $8) wingo: $11 = "ac" civodul: hmm wingo: basically drain-input collects and returns buffered input. but having a mental model on what's buffered is a little tricky wingo: buffered input includes the putback buffer and may include a portion of a read buffer wingo: afair wingo: (but drain-input is a funny procedure, i can't think of many ways to use it correctly) civodul: yeah it's only useful to ensure there's no buffered input IME wingo: why would you want to ensure that? :) civodul: in cases where i then pass the underlying file descriptor to some other piece of code civodul: usually not a great situation to be in, but that happens :-) wingo: ah indeed wingo: yep :) civodul: https://notabug.org/guile-zlib/guile-zlib/src/master/zlib.scm#L157 civodul: anyway i'm fighting with a situation along these lines, looking for extra buffering in a maze of ports :-) wingo: civodul: is it necessary to buffer on the zlib side? i guess so, given that you don't know how much input corresponds to how much output wingo: ideally you buffer only on the guile side fwiw wingo: when guile needs more it will call the read function with the number of bytes it can take mdevos: how can I verify whether an object is an open input port with a file descriptor from C? I don't quite understand the "object = SCM_COERCE_OUTPORT (...)" assignement in scm_stat and I would rather not cargo cult copy wingo: SCM_VALIDATE_OPFPORT (SCM_ARG1, port); mdevos: (I also need the fd, would SCM_FPORT_FDES on the port itself work?) mdevos: wingo: I'll just use that, though I wonder what SCM_COERCE_OUTPORT is supposed to do in scm_stat wingo: right, so that is a strange thing that is not well tested -- there is a thing called a "port with a print state" wingo: which is a little object that wraps a port and includes a hash table of what's been written wingo: to allow circular data structures, i think wingo: but i have rarely had to touch that wingo: anyway sometimes you can pass these to port-using procedures, and SCM_COERCE_OUTPORT can take either a port or a port-with-print-state, and returns just the port wingo: i don't think scm_stat needs to do that fwiw wingo: and i don't think mkdir would need to do so either wingo: a crufty thing from days of yore :P civodul: wingo: guile-zlib doesn't actually buffer; it makes sure the user's port is unbuffered before passing the underlying FD to zlib mdevos: To check whether readlinkat is supported (and work around some platform-specific bugs), I thought of using gnulib's readlinkat module at first, but it's GPL and Guile is LGPL mdevos: any particular reason it's not just GPL? leoprikler: if Guile was GPL, all Scheme code written in Guile would need to be GPL as well, which is not very feasible civodul: "not very feasible"? :-) mdevos: leoprikler: do you know any such code? leoprikler: SRFIs? leoprikler: civodul: "not very feasible" is my personal way of saying infeasible. leoprikler: feasibility gets casted to a C boolean :) civodul: it's not about feasibility, it's about choice civodul: it's a choice some may not like, but it's entirely "feasible" mdevos: leoprikler: all SRFI's implemented in Guile are LGPL or GPL, or compatible, I hope civodul: (not saying we should do it) leoprikler: mdevos: they're at least LGPL/GPL-compatible, but if you write your reference implementation in Guile, you need to license that under the SRFI license, which is the same as Expat IIRC taw10: A GPL Guile wouldn't require all Scheme code to be GPL - that's total rubbish. See https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL taw10: Think about it: would all the code in SICP suddenly need to be GPL just because it can be run with Guile? leoprikler: "When the interpreter just interprets a language" mdevos: Guile is more than an interpreter for a language, it also comes with a few libraries of procedures leoprikler: If you use any of Guile's own facilities not specified by RnRS, e.g. its module system, you're effectively in GPL enforcement territory. mdevos: What I was originally asking for, was there any particular reason for using the LGPL instead of GPL for Guile in? (And would there be compatibility problems if guile would switch to GPL) civodul: mdevos: it dates back to 25+ years ago, so we can't say for sure, but it's probably the same reasoning as for making libc LGPL mdevos: (I haven't ever heard of propietary applications build on guile. I don't care about those, they can find another Scheme interpreter/compiler + library implementation.) mdevos: I don't think the same reasoning applies to Guile (I didn't find the original reasoning; I'm basing mysef upon ) leoprikler: Well, there are more Scheme implementations than C libraries, so a naive interpretation of that statement would hold. mdevos: Hmm, all the *at gnulib modules are all GPL: readlinkat, chmodat, chownat, faccessat, fchmodat, fchownat, fstatat, linkat, mkdirat, mkfifoat, openat, opendirat, renameat, statat, symlinkat, unlinkat, utimensat mdevos: (except careadlinkat) mdevos: Would it be possible somehow to only import m4/readlinkat.m4 from gnulib, but not gnulib's C replacement / wrapper, without messing up the build system? mdevos: (make dist & future gnulib-tool --add-import) mdevos: (m4/readlinkat.m4 itself has a permissive license) dsmith-work: In ages past, Guile was GPL, with a special permission/exception/something. This is from before there was a LGPL. dsmith-work: It was to promote using Guile everywhere. mdevos: ... that didn't actually happen (Guile everywhere). The only propietary software I've seen it in were personal pet projects, and all the free software I've seen it in are GPL or compatible dsmith-work: Yep mdevos: (LilyPond, TeXmacs, GnuCash, some librariesà leoprikler: "All the free software are GPL or compatible." Because people don't really want to make GPL-incompatible software? leoprikler: GPL-incompatible free software. mdevos: leoprkler: in case I wasn't clear: ‘All the free software **I've seen it(Guile) in** are GPL-compatible’. dsmith-work: https://mail.gnu.org/archive/html/guile-user/2002-06/msg00011.html leoprikler: Most people, who write non-GPL free software, choose a more permissive license (e.g. Expat). mdevos: I guess my argument is (1) switching to GPL wouldn't cause trouble for anyone and (2) it's convenient to be able to use GPL modules from gnulib *: mdevos afk rlb: If I'm reading it right, I'm wondering why/if shared mutable substrings really need to keep the extra indirection through the source string, i.e. could they just point directly to the source string's buffer... taw10: Hmm, any other examples of the license status of a program depending on which extensions you use in that language? Because I don't think it works that way. e.g. the GPL FAQ I linked to doesn't say "... as long as the interpreted program only uses some standard-compliant subset". Do your programs need to be GPL because you used a GCC extension, for example? On a quick look, the GCC manual doesn't warn taw10: that using certain extensions come with strings attached. I'm not talking about the GCC runtime exception - that's different because it's about code actually getting copied into your executable taw10: What I do agree with, however, is that making non-GPL *extensions* to Guile (i.e. linking against libguile) would be impossible if it were GPL, which could be regarded as a bad thing. leoprikler: That does not apply here, because you can execute a GPL program to do anything. leoprikler: If you only used Guile to compile to Guile bytecode and then ran your Guile program on your own proprietary Guile VM, you wouldn't violate the GPL. taw10: Of course, what you do in private is irrelevant. I'm reading all of this under the assumption that we're talking about publishing an "interpreted program" under a proprietary license leoprikler: I meant that as in "if you published your proprietary Guile VM and used standard Guile to compile your proprietary Guile code". leoprikler: … which you also published but only the output. taw10: Your logic seems to be that using Guile-specific features makes your "interpreted program" become a "derivative work" of Guile. Did I misunderstand that part? taw10: If I did misunderstand, then I don't follow where the GPL requirement for the "interpreted program" comes from taw10: If I didn't, then I don't understand why publishing a proprietary program running on a proprietary VM would be OK civodul: a GPL'd Guile would be like Emacs: one can publish non-GPL code (in practice, extensions or users of Guile-provided modules), but it must be GPL-compatible and the combination is GPL civodul: that said, i think this so-far theoretical discussion is going a bit far :-) leoprikler: which is different from LGPL, which lets you publish derivative work under any license (without limitations to compatibility and combination) mdevos: unless Guile's LGPL / GPL situation changes, I'll just copy m4/readlinkat.m4 and use that (that's under a permissive license) & #ifdef HAVE_READLINKAT, and ignore gnulib's replacement functions *: mdevos pretends to be afk again leoprikler: that should be possible since we're already in the posix-specific part mdevos: leoprikler: I don't follow? leoprikler: Guile's filesystem stuff has two versions depending on whether you have the 'posix feature. mdevos: leoprikler: I follow even less know. scm_readlink is in filesys.c, not posix.c -- and now I see _POSIX_C_SOURCE is not always defined due to reasons (stime.c). grrr incompatibility dsmith-work: I think "posix" stuff in Guile is legacy from SCM: https://people.csail.mit.edu/jaffer/scm/Posix-Extensions.html#Posix-Extensions wingo: good evening :) ArneBab: mdevos: from my perspective, now running Guix, Guile is pretty much everywhere I look :-) wingo: g.r.e.a.m. ArneBab: gream? wingo: https://en.wikipedia.org/wiki/C.R.E.A.M. manumanumanu: wingo: saw you merged the patch. I should really update my name in my git config. Even I react when I see my first name in a commit log manumanumanu: :D wingo: :) wingo: tx for patch! manumanumanu: did you see my other comment? That the two (map ...)s of rnrs base and (ice-9 boot-9) do the same? manumanumanu: The r6rs one is much nicer, but slightly slower (because of being pure gulie. Not by much, though. manumanumanu: The question was, do we really need two of them? manumanumanu: anyway, I have to drill things tomorrow. The heavy responsibility of owning a house and all that. Good night! wingo: manumanumanu: is the r6rs one the same? wingo: i didn't see the other comment btw wingo: anyway we can follow up later :) manumanumanu: yup. same constraints and everything. the one in (r6rs base) has better error reporting and is much nicer manumanumanu: but ever so slightly slower manumanumanu: if you pass the boot-9 one an non-proper list you get an error in (length ...), whereas (rnrs base)-map has a correct error message and everything. Regarding the speed: my test was a simple repl test: ,time (rnrs:map 1+ a-long-list-from-iota). manumanumanu: wingo: but today the map from rnrs base is faster on that benchmark of a 10000000 element list manumanumanu: i might have been wrong. if so: the map from (rnrs base) is sliiigtly faster and produces better error messages. wingo: map benchmarks are squirrely, depends on heap size, whether a collect happens or not, etc manumanumanu: It seems boot-9 map has a wider run time (0.32-0.7s), but averages lower than rnrs:map, which consistently scores 0.43-0.45s manumanumanu: anyway: they are functionally the same manumanumanu: boot-9 map transverses the list more times (doing more or less (= (length l1) (length l2) ...) which conveniently errors on improper lists), whereas (rnrs base)-map is more elegant manumanumanu: now, good night! wingo: hummmmmmm wingo: civodul: my release to-do is currently just mkstemp, and preparing for mkstemp! deprecation (not yet tho as not enough time) wingo: everything else done, except any mingw things that spk121 would like to land civodul: wingo: ah great! civodul: i'd need to look at that -Wunbound-variable thing now wingo: what is that? :) wingo: anyway i look forward to the patch ;) civodul: it's about false positives civodul: new in 3.0.5 daviid: wingo: what about bug#43025? civodul: re -Wunbound-variable: https://issues.guix.gnu.org/47031 avp_: Hello Guilers! logs.guix.gnu.org/guile gives "Resource not found: http://127.0.0.1:3333/guile/search" when I try to perform a search. tohoyn: avp_: are you sure IP address 127.0.0.1 is correct? avp_: I'm using the search form located on the top of the page http://logs.guix.gnu.org/guile/ tohoyn: avp: could you check if URL http://logs.guix.gnu.org/guile/search?query=nick%3Atohoyn works for you? rekado: avp_: the problem is a wrong redirect rekado: you will see that it redirects you to http://logs.guix.gnu.org/guile/guile/search?query=foo instead of http://logs.guix.gnu.org/guile/search?query=foo rekado: remove the extra /guile and it should be fine avp_: tohoyn: This URL works. rekado: I’ve been meaning to fix this, but there’s always something else to be done… rekado: maybe today wingo: moo manumanumanu: apteryx: if that approach becomes a bottleneck, you could try transducers. They merge (remove (map (filter ...))) into one pass over the list, which - if the list is large - might become expensive. (list-transduce (compose (tremove string-null?) (tmap string-trim-both) (tfilter (node-typeof? '*text*))) rcons (cdr node)). It is included in guile-3 as (srfi srfi-171). manumanumanu: the overhead is pretty small, and even on "cheap" lists of things like chars or integers it is usually beneficeal to use transducers if you have more than one step, ie: replacing (map ... (filter ....)) means faster code. Replacing a single (map ...) is not. manumanumanu: apteryx: the caveat is that some transducers have hidden mutable state where the