<kamen>Has anyone managed to get Geiser to connect to a remote Guile REPL over SSH? I'm trying to do it with an Rpi I have that's running guile --listen, and I have an SSH tunnel into it, TRAMP works fine, but Geiser won't connect to it. 'Connection refused'. <kamen>(Or do I need to install guile-ssh and use that on the remote REPL?) <pkill9>does anyone know of a web service that provides most functionality of wordpress, but creates static sites and uses markdown files? <kamen>Ok, it seems like when I do C-c C-z from a remote Guile buffer, it *does* fire up a remote REPL. Good, good. So now I just need to work out how to connect to an existing remote REPL. <kamen>Holly Molly, no, Geiser actually connected to the already running 'guile --listen' on the remote machine. Just like that. Happiness and beaty all round. \o/ <pkill9>does haunt store the metadata of the directories posts were found in? ***karlosz_ is now known as karlosz
<contrapunctus>I cloned the Guile repo from Savannah, and the file HACKING links to guile-devel, which 404s. <contrapunctus>Also, can anyone extend getopt-long to contain docstrings and create a function to generate help text from that? That way there won't be two option specifications in the code which the developer will have to remember to keep in sync. (This is what I cloned the repo for, but I don't think I'll get the time to do it.) ***sneek_ is now known as sneek
***efraim_ is now known as efraim
***apteryx is now known as Guest66400
***apteryx_ is now known as apteryx
<mdevos>I've encountered some odd behaviour involving #:re-export and syntax transformers, and I'm not sure whether it's a bug: ... <mdevos>(define-module (test) #:re-export ((or . or/scheme))) <mdevos>Now try ((@ (test) or/scheme) #f #t) <mdevos>Apparently or/scheme isn't exported as syntax <mdevos>(@ (test) or/scheme) returns #<syntax-transformer or> <RhodiumToad>right, but that's the _value_ of (@ ...), there is no syntax for it in scope <mdevos>RhodiumToad: I don't understand your response? If I can export the syntax defined with define-syntax, why can't I simply re-export syntax from (guile) under a somewhat different name? <mdevos>What I want to do is import (test) from another module and use (or/scheme X Y) <mdevos>(or and or/scheme are placeholders here. What I'm actually trying to do is exporting a Common Lisp "case" syntax as 'case, and the ‘old’ Scheme 'case as 'case/scheme) <RhodiumToad>you can export it, but I don't think you can reference it with (@ ...) <RhodiumToad>at least you can't use (@ ...) as though it was itself the syntax in question <mdevos>I'l use (define-syntax-rule (case/scheme . rest) (case . rest)) in (test) and export case/scheme from test (using #:export) for now until this has been figured out <mdevos>RhodiumToad: nope. I'll prepare a minimal test case ... <RhodiumToad>i.e. I did a module that had just your re-export in it, and imported it in the repl, and it worked as expected <mdevos>what's the guile version? Mine is 3.0.5 <mdevos>RhodiumToad: well, that is interesting. Now I wonder what's the technical difference between (@ (test) or/scheme) and (@ (guile) or), and why the latter results in "source expression failed to match any pattern in form or" and why the former results in #<syntax-transformer or>. <mdevos>In any case, I wasn't actually using (@ ...) in the code I was trying to debug. <mdevos>No, it's not pointless. I thought it didn't matter whether I used (@ ...) or #:use-module, so I used the former for a smaller test case <mdevos>Btw, using import & #:re-export ((case . case/scheme)) works without trouble, but I'm using some other constructs as well. I'll be back ... <RhodiumToad>so... I tried a module that has #:replace ((case/mymodule . case)) #:re-export ((case . case/scheme))) <RhodiumToad>(replace rather than export to silence the warning about overriding a core binding) <RhodiumToad>the module has a (define-syntax case/mymodule ...) in it <RhodiumToad>i.e. after importing it, (case ...) got the module version, while (case/scheme ...) got the original guile version <mdevos>RhodiumToad: that's also the case for me. But I still have weird syntax errors ... <RhodiumToad>I'm betting those are real mistakes on your part :-) <mdevos>RhodiumToad: I found a defun that, if I comment it out, all the code compiles, and if I copy it to the beginning of the source file (well, after (define-module (...) #:use-module ...) and comment out the original, the code still compiles, but if I don't comment the original out, then I get a syntax error. <RhodiumToad>and does the body of this function refer to any syntax defined in the file? <mdevos>(Yes, it's a defun and not a define. I'm porting some CL code to Scheme and I have defined some syntax code) <mdevos>RhodiumToad: that's a good question ... Will be back later <mdevos> RhodiumToad: yep, something like that is the case. The use of case (case/common-lisp) is correct, but the expressions inside have some issues. *mdevos adds line to $PROJECT/THANKS ***chrislck1 is now known as chrislck
***terpri_ is now known as terpri
<leoprikler>people usually do debian paste, but gnome paste and some others are also accepted <manumanumanu>replacing (abort-to-prompt-tag tag stuff) with (receive vals (abort-to-prompt-tag tag stuff) (apply values vals)) does not work <manumanumanu>The issue is more involved. I will try to make a minimal viable example. <manumanumanu>Damn. My bad. I was returning a value to a continuation that expected none. <manumanumanu>It was such an elegant solution to a problem I didn't have. <leoprikler>mv prompts are fine and dandy but I like prompt thunks harder somehow ***rubdos_ is now known as rubdos
<civodul>would be nice if hashq could be inlined in Scheme, somehow <civodul>maybe not actually inline since that would make it harder to change it, but rather a VM instruction? <wingo>why do you want that tho? i doubt it would change much <wingo>i guess you could make it give an unboxed number <wingo>but hash codes are known to be fixnums anyway <wingo>fwiw the table-switch optimization does effectively inline some aspects of symbol hashq <wingo>wdyt about the read-syntax thing <civodul>the reason i think it'd make sense is that i have vhash-based caches that are probed very often <civodul>which is quite some overhead for a just a few bit-twiddling instructions in the end <mdevos>The Scheme implementation of "read" seems useful beyond read-syntax to me <mdevos>(Fiber suspension on blocking I/O from a socket in guile-fibers, for example <wingo>re: hashq, i am not sure if it's an important speedup. but maybe so! if so, an intrinsitc <wingo>civodul: i made (language scheme spec) use (ice-9 read)'s read-syntax <wingo>which returns a tree of syntax objects with no scope information but with source locations <civodul>so read-syntax returns a syntax object right away, right? <wingo>it is a little slower -- because it has more source information. <wingo>i.e. for symbols, numbers, strings, etc <civodul>did you measure the run time and GC impact of this? <wingo>compiled file sizes slightly larger because more source info, and because syntax objects now have a source location info field <wingo>i measured run time for a read benchmark. about 60% as fast as the C reader <wingo>with a slightly higher GC load. i don't have e.g. bootstrap time differences tho <civodul>i guess it uses a bit more memory, but maybe not that much since the source property table isn't that big either <wingo>yeah dunno. probably some more tweaks to make <wingo>but, it bootstraps in what seems to be a reasonable time. i should probably measure <civodul>i mean that the source property is quite sparse <wingo>and you end up with more location info in the compiled code, which is good at least <wingo>well, please do run through the commits, at least the descriptions, and see if there's anything that sounds off to you <rlb>i.e. convert it to the "packed" representation when possible <wingo>rlb: ah yeah that sounds useful!!! <rlb>OK, had just been waiting to see if anyone found any trouble, and/or if we thought it needed any additional tests. <wingo>rlb: incidentally, i found that just consing up a list of characters was faster than a string port *civodul looks at the commits <wingo>i think i found the same when implementing read-delimited in (ice-9 rdelim) <rlb>Hmm, not good news for my parser :) <civodul>wingo: using vectors instead of alists is a good idea! <rlb>Seems like it should be possible to do better than consing chars, given how big that is memory-wise atm, if I'm thinking straight. <civodul>i think eventually we could come up with an even more compact representation, with a side table <rlb>i.e. amortized string growth should potentially be better? <civodul>wingo: is it safe to change the prototype of datum->syntax in 3.0? <wingo>civodul: if it's a compatible change (e.g. adding keywords, expanding domain of arguments, etc) then yes <rlb>(Only semi-related, I've wondered how hard it'd be to add utf-8 as a storage format, or maybe we'd just want a wholesale replacement, were we to head that way.) <wingo>rlb: asymptotically probably yes. but what is 95th percentile identifier / string length? <wingo>i think probably less than 20 <wingo>rlb: re: utf-8 -- is a long discussion but i think we agreed at one point that it is the right thing. but would take lots of careful work <rlb>Sure, but even there, that's ~20bytes in most cases if/when we support utf-8? And we could always start off with a min ubffer size? <rlb>And 20 cons pairs is a lot bigger? <wingo>i was just thinking that for low N, constant factors dominate <rlb>I also wondered if there might be a chance we could add utf-8 incrementally (and would that help at all), i.e. make it a new storage format, and expand it outward... <rlb>But was just idle musing. <wingo>yeah is a good question for musing :) <rlb>Also wondered how/if the immutable string srfi might fit in to the eventual plan... <rlb>(i.e. if that allowed us to provide a way to maintain "O(1)' indexing, etc. when important, with some extra overhead -- of course might also be plausible to add the srfi, and worry about anything fancier on that front later on) ***Noisytoot is now known as [[
***[[ is now known as Noisytoot
<rlb>and yeah, as mentioned, utf-8 would have been a lot better for my interop with pcre2, for example. <mdevos>Would it be complicated to support immutable pairs? Or perhaps that would cause slow-downs due to extra type-checking, as pair? wouldn't imply that set-car! can be used anymore? <rlb>(In theory I'd wanted that for lokke, and/or built-in support for immutable goops classes.) <wingo>mdevos: i think it would be hard :) <mdevos>(I'm feeling somewhat inspired by the paper on the lambda calculus as a security kernel. A lack of immutable pairs isn't insurmountable (‘just’ redefine pair?, cons & co), but is sometimes irritating) <wingo>basically i think we would follow in racket's path in that regard <rlb>wingo: can't recall if I mentioned it do you, but one thing I've also thought I wanted is record/goops-class unification. i.e. could we have records "work fine" as define-method specializers. <wingo>rlb: i have wanted that for a long time too <rlb>(define <foo> (class-of some-record)) seems to work, but is at best awkward... <rlb>(class-of (make-dummy-record-instance)) I mean. <wingo>looked at it off and on but never managed to really sketch a solution <rlb>I assumed friendly support immutable classes would be a lot easier than immutable pairs :) <rlb>(immutable class instances, I mean) <rlb>For now, you just don't have access to slot-set! (trivially) on the clojure side, and we're done? :) <mdevos>If I write (quote (list stuff)) in a source file that is computed, would it be possible for the pair to end up in a read-only section (or whatever's the terminology)? <mdevos>You would need install a signal handler for SIGSEGV though <wingo>mdevos: depends :) '(1) goes in the read-only section because it's a pair of (1 . ()), and both 1 and () are immediates and thus need no run-time relocation <mdevos>(I vaguely recall causing guile to crash by using set-car! or set-cdr! on an pair from a compiled something) <wingo>but (1 2) is different -- it's (1 . _) and (2 . ()) <rlb>...hmm, well I guess it's pretty trivial (guile.oop.goops/slot-set! ...). Don't do that then? <manumanumanu>civodul: To be frank, I think the equality of the hash table should not be a thing for the accessor at all. srfi-69 is so much nicer to work with. Associating an equality with the hash table at creation is probably the best way to go about it. I have never wanted to suddenly use another eq?, but I have been bitten by guile's default behaviour about 10 times. <wingo>the latter goes in read-only, and the former's cdr gets patched up at load-time to point to the latter <wingo>so the former bit can't be in read-only memory <wingo>rlb: i think there are a lot of things like that fwiw <wingo>there are quite a number of unsafe capabilities like struct-set! that don't compose with encapsulation boundaries <mdevos>wingo: thank you! I can cause guile to crash with a "Segmentation fault" again now! <wingo>mdevos: doh :) for set-cdr! / set-car! there should be a mutability check <wingo>if that's not the case, there is a bug somewhere <mdevos>(Should ideally be caught with a SIGSEGV handler that throws a guile exception when it's caused by modifying read-only pairs) <rlb>wingo: yeah. In the docs I just said "For now, types are implemented via GOOPS which means that you can actually modify them via slot-set!. We may eventually pursue immutable GOOPS classes in Guile, but of course you can modify anything on the JVM too, if you really set your mind to it." <rlb>(i.e. I believe via reflection on the jvm, if you have access to it) <wingo>mdevos: see scm_is_mutable_pair in pairs.h <rlb>Though I also believe they do have security boundaries, etc. <wingo>mdevos: tho i think a SIGSEGV handler would be a nice solution fwiw <civodul>manumanumanu: re hash table, agreed! <mdevos>do I need to formally submit a bug report for the segfault? <civodul>manumanumanu: i was looking at vhashes, which are in Scheme, and thus call 'hashq' from Scheme <leoprikler>vhashes and hashqs are not the same tho (at least not in Guile) <civodul>leoprikler: i'm referring to the procedure called 'hashq' <leoprikler>using internals sounds like hash tables actually need to be recomputed on GC? <manumanumanu>civodul: ah, sorry. That is one interesting corner of guile! <manumanumanu>How much slower would hashq be in scheme? :D That, and define-inlinable and you are set... <rlb>leoprikler: yeah, you can modify goops object fields, even if no accessor has been defined. <rlb>i.e. field set! for goops objects. <leoprikler>rlb: yeah, you can do the same with jvm bytecode, reflections are just much more verbose