IRC channel logs

2021-02-07.log

back to list of logs

<rlb>wingo: I recall hitting some thing surprising wrt keyword syntax and modules -- but might be orthogonal to your reader work (and might have been intentional), I'll try to remember what it was, but maybe it was that the syntax doesn't reset at the end of a module?
<rlb>Not sure. At the time I was trying to set it to 'prefix before the define-module in a file so I could use :use-module etc.
<rlb>But then iirc it stayed 'prefix even after that module was loaded...
<rlb>(which did not end well :) )
<daviid>rlb: I think setting 'prefix is global, always has been I think
<rlb>Guess that means you can't easily use it in that situation since you'd need to capture the current setting to restore at the end, and you'd need to capture/change the value outside the define-module...
<rlb>Dpesm
<rlb>In any case, I just stopped trying to use prefixed keywords.
<daviid>rlb: i did use it a very log time ago, a little, but because of the above, stopped, because if you use it, then you also force your users to have to use it as well, there is no way to us it in say, g-golf, and not in a g-golf user module ... fwiw, not a critic to guile or maintainers, just it is the way it is
<rlb>Ahh, right, it also affected the reader for all the :use-module loads.
<rlb>which I definitely didn't want.
<daviid>exactly
<rlb>Seems like it might be more useful if it were a per-module setting.
<rlb>but haven't really thought it through all that carefully
<daviid>it surely would, but i never dig in the reader to offer contributrion, so i kept 'silent'
<rlb>Yeah, I just thought of it given wingo's recent work...
<daviid>sure
<daviid>spk121: tx! i may report, or wait - having a tiny shared lib produced by autotools, i guess i am not the only one on bullseye doing this ... and any other will have more knowledge then muself to report and follow ... but if in afew days nothing popo-up as a solution, i will report - tx anyway
<roptat>what's the file containing guile history when using (ice-9 readline)?
<roptat>ah found it :)
***apteryx_ is now known as apteryx
<roelj>Sometimes I wish Scheme had multi-line string support like Java and Python. (with """, and the automatic prefix whitespace removal so that code indenting can be done as one expects),
<wingo>hungry-eol-escapes reader option seems close to what you want
<wingo>that is part of r6rs string syntax
<leoprikler>Well, at least Scheme strings are multiline by default :)
<tohoyn>roelj: I prefer string-append to multiline string constants
<roelj>Is there a compile-time equivalent for string-append (for when the arguments passed to string-append are all constants)?
<tohoyn>roelj: probably not, but that would be convenient
<roelj>the hungry-eol-escapes reader option looks fairly close indeed! :) But I don't know how to enable it when compiling Guile modules
<wingo>roelj: #!r6rs in your file will enable it
<wingo>and not set the global reader option
<roelj>wingo: Thanks. Does that work per file/module?
<wingo>per port
<wingo>which usually maps to per file
<roelj>I'll just have to try I guess :)
<roelj>wingo: I enjoyed the WASM talk today. I was wondering.. can we already execute Guile code in the browser to manipulate the DOM like one would with JavaScript?
<wingo>tx :) no, guile doesn't really have a good web story right now
<wingo>TIL that (call-with-input-string "#\\ " read) => #\space
<ArneBab>wingo: I missed the talk :-( — do we have Guile→wasm compilation now?
<roelj>wingo: Hah, I had to try this in the REPL as well. Interesting
<wingo>ArneBab: no :) was more a talk about wasm than about guile, fwiw
<ArneBab>ok :-) — still I hope it will be online as recording, soon. I want to share it in the company :-)
<rlb>wingo: wondered if it could make any sense to have some way to set reader opts just for the current module (e.g. keyword style, etc.)? Though not sure how we'd want do to that (and no longer all that important for me at least right now).
<ArneBab>(since I’m doing Javascript dev at work now (and Java), and looking for good ways to use wasm is clearly interesting — and be it only to preserve memory; I’ve killed quite a few browser tabs already when testing the limits of what we can do :-) )
<rlb>wingo: also on the parsing front, it's perhaps not pretty, but https://github.com/rlbdv/lokke/blob/edn/mod/lokke/scm/edn.scm https://github.com/rlbdv/lokke/blob/edn/test/lokke-scm-edn
<wingo>rlb: i think it can make sense but also is a low priority for me
<rlb>Just got that working, and I'd be happy to contribute it to guile if it becomes interesting.
<rlb>"is or becomes"
<wingo>neat
<rlb>I'm going to see how it compares to my existing lokke-reader.c (derived directly from guile's reader), and will likely switch if I can.
<rlb>But that module is completely clojure-independent, i.e. scheme only, almost rnrs only.
<wingo>fwiw eqv? will be faster than char=?
<rlb>So could go in guile if we want an edn reader.
<rlb>orly? :)
<wingo>when comparing to a literal character
<rlb>thanks
<wingo>yeah guile's optimizer doesn't know anything about char=?
<rlb>I also didn't know if the char set operations for the smaller sets (contains?) would be comparable to a big case or memv...
<wingo>no idea there
<RhodiumToad>char=? has to worry about throwing errors for wrong types, eqv? doesn't
<rlb>For now I used sets, but could easily rewrite as a case or memv.
<RhodiumToad>I'd expect sets to win in most contexts
<RhodiumToad>bicbw
<rlb>I also matched the jvm reader in some cases where the standard wasn't clear or in one case where the jvm contradicted the standard (since I'm sure the jvm reader is by far the most common one).
<rlb>RhodiumToad: ok, thanks
<rlb>(Aside from anything else, personally, find edn a bit nicer as a config file syntax than say json, or even plain sexps...)
<spk121>rlb: the char-sets are stored internally as a set of ranges lo..hi lo..hi. So the efficiency of char-set gets worse for higher codepoint values, since it scans those ranges numerically. For text that is usually ascii, it is quite performant
<spk121>but I don't know how it compares to memv or whatever
<rlb>spk121: thanks -- I also figured I'd perf test and/or profile at some point and see what's going on, but likely not today :) I did pull out the "guessing likely chars": https://github.com/rlbdv/lokke/blob/edn/mod/lokke/scm/edn.scm#L83-L86
<rlb>i.e. so we didn't match againt the entire unicode letter set in the (maybe) common case.
<spk121>rlb: if you get curious about how char-sets are represented internally, there is a %char-set-dump procedure
<rlb>Interesting.
<rlb>The reader's also configurable wrt what kind of containers you get for the various collection literals (vectors, sets, maps, lists). For scheme it defaults to vector, deduplicated-list, alist, and list, fwiw.
<rlb>(because of course I need "something else" for clj)
<rlb>I'll probably also add #inst (instant) and #uuid support at some point, either via goops classes if that's acceptable for the scheme side, or srfi-9 records if not -- fine either way if there's a strong preference.
<rlb>(What I already have for the clojure side uses goops https://github.com/lokke-org/lokke/blob/main/mod/lokke/time.scm#L25 )
<rlb>Hmm, not critical, but just noticed and I'm curious -- what determines the bulk of the size of our .go files? Or even just the minimum, or example, looks like there's an approximately 70kb base here for a module with just a few trivial defines in it.
<spk121>rlb: objdump -x works on *.go files, mostly
<rlb>oh, right, thanks.
<wingo>rlb: page alignment between read-only versus read-write pages
<wingo>minimum is 64kB
<wingo>binutils manages to avoid having so many zeroes (that aren't paged in in any case) with they way it does it; perhaps there is an improvement to make
<RhodiumToad>where does that requirement come from?
<rlb>Ahh, ok - thanks, and in any case, happy to have noticed. Not a big deal, but might nudge some of decisions regarding granularity.
*rlb forgot 2.2 rejects #:declarative?...
<rlb>Is there some way conditionally specify #:declarative? i.e. I'd use cond-expand, but it doesn't seem like that's allowed inside a define-module...
<rlb>I imagine I can just duplicate the whole define-module in two cond-expand arms, but be nice to have something better at some point...
<manumanumanu>rlb: sorry, I haven't been following the discussion: but where do you want to turn off #:declarative?
<rlb>I want to include it with guile-3.0+ and omit it for guile-2.2.
<manumanumanu>But do you want #:declarative? #f
<rlb>guile-2.0 chokes on #:declarative
<rlb>2.2
<manumanumanu>Yes, but why do you want to turn it off in guile3?
<rlb>I want it set to #t in 3.0+
<manumanumanu>it is #t by default
<rlb>but I thought the default was #f?
<rlb>Hmm...
<rlb>If so, then nevermind...
<rlb>(and thanks)
<manumanumanu>I suspected you were trying to do that, and if that was not the case, you can actually work around it by abstracting whatever you want to set! away
<rlb>OK, yeah, I just misremembered the default...
<manumanumanu>with boxer or whatnot
<manumanumanu>boxes
<rlb>Thanks again.
<manumanumanu>I am in the middle of moving currently, so I am not here very often. I really think you are doing a noble thing! I hope to be able to help you more in the future, but I probably wont have _any_ computer time until march :(
<rlb>No worries, I'm not intending to go anywhere anytime soon :) And good luck with the move.
<manumanumanu>rlb: are there any problems with lokke you haven't figured out how to solve? Or is there anything you want to solve better?
<rlb>All kinds of things -- some are listed in the README and DESIGN, and also "git grep FIXME" might or might not be interesting... If you decide to attempt something more ambitious, suggest badgering me first on the list, or in #lokke, or... so we don't duplicate efforts.
<rlb>(the section in DESIGN might be more interesting than the README there I suppose, looking back at it...)
<manumanumanu>rlb: I am the author of srfi-171, btw. The design is based on the information I could find about clojure's transducers
<rlb>...nontrivial things are still missing like (clj) records, protocols, agents, refs, any number of functions, and/or data structures like sorted-set, and I'd imagine there are performance and/or concurrency issues we'll eventually notice.
<manumanumanu>They are implemented the same.
<rlb>hah, or that -- no support for transducers at all yet.
<rlb>(or "chunked sequences", etc.)
<rlb>e.g. I just short-circuited some of that in the code borrowed from clj/jvm (most of the code is ours, but some is from upstream (with a different license of course))
<rlb>cf. (lokke ns clojure core epl)
<manumanumanu>The difference is that where clojure's mutable state is often implemented as atomics (or "volatile"), the ones in srfi-171 are all just (set! ...). I couldn't understand the reasoning behind the volatile thingies, but I suspect it is probably the most comfortable way to do mutation in clojure
<manumanumanu>I'll join #lokke :)
<rlb>Another random technical thing that'd likely require changes to guile/goops to improve is the performance impact of support for "applicable types". We *might* be able to support vectors/sets/maps just using guile's existing applicable-struct feature, but clj also requires that say *keywords* behave like functions, e.g. (filter :valid? some-collection)
<wingo>this is exciting: (call-with-input-string "#t1" read) => #t
<wingo>i.e. no delimiter needed
<manumanumanu>This is the second read error I see you talking about here, and I have been here a total of 15 minutes over the last three weeks
<rlb>For now, lokke just wraps *all* procedure applications during compilation, i.e. (foo ...) turns into (invoke foo ...) at the tree-il level, but it'd be nice if we could avoid paying that penalty all the time (if there's some better approach).
<wingo>rlb: yeah that is a really good question how to do that
<rlb>hah, I'd planned to sneak that one in front of you more carefully at some point :)
<rlb>wingo: and wrt the reader, interesting, and of course I hit the same bit wrt edn. I just handled it via lookahead-char for now: https://github.com/lokke-org/lokke/blob/main/mod/lokke/scm/edn.scm#L99-L104
<wingo>i am not sure how (#t1) should read
<wingo>looking at the r5rs anyway
<wingo>maybe it should read as '(#t 1)
<wingo>which is what guile does
<rlb>Yeah, edn's specific there I think (and/or I just see what the jvm does :) ).
<wingo>:)
<rlb>Suspect at least for now, you might need to mostly just match read.c...
<rlb>Unless this is going in to a guile-4?
<wingo>oh yes certainly
<rlb>not sure...
<wingo>this is a behavior of read.c
<rlb>I guess we could have a "strict reader" option or something.
<wingo>all these weird things i find are read.c things
<rlb>if we end up wanting/needing it
<wingo>dunno, nobody will enable any non-default read option
<wingo>to a first approximation anyway
<rlb>yeah, I just remembered to remove || symbol support (not something you'd expect/want to work in clj :) )
<wingo>better not to muck with lexical syntax
<wingo>i.e. lexical syntax for which there are many unknown productions out there
<rlb>(remove it from lokke's version) If the perf holds up, I'll probably just broaden (lokke scm edn) to replace the C version.
<rlb>wrt the (:foo something) support I wondered if there might be some way to add that to goops (perhaps opt-in if that helps), such that it'd be more efficient than the global wrapper...
<rlb>i.e. (define-method (invoke (x <keyword>) ...) ...) or something
<rlb>where "invoke" was some special method we support...
<wingo>yeah i don't know. there are a lot of missing MOP pieces for generic application
<spk121>I wonder if we fuzzed the reader, we could make it crash
*rlb would guess so
<wingo>rlb: on the lower level what you need is a function from non-procedure to procedure
<manumanumanu>spk121: I have crashed the reader back in goile 2.0, but I didn't report it because I was a n00b
<wingo>(procedure in the tc7 program sense)
<rlb>Of course I don't actually know how much the current invocation wrapper costs -- maybe it's not all that bad...
<wingo>ideally with some kind of cache, probably per instruction site
<manumanumanu>rlb: guile has applicable structs???
<wingo>guile has applicable structs!
<rlb>I figured it might be more palatable if it could be opt-in, and for my purposes, goops only would be fine.
<manumanumanu>OMG
<rlb>yeah, I got them working for hash-map, hash-set, etc., but wasn't useful because I still had to have the wrapper for other things i.e. keywords
<manumanumanu>where is that documented?
<spk121>manumanumanu: yeah. it happens. I find bugs I don't report because I don't have the energy to diagnose make a minimal test case.
<manumanumanu>rlb: does clojure still dispatch on something like (define a #:a) (a hash-map) ? That seems like a great source of confusion
<wingo>hopefully if we manage to switch to a reader in scheme, we won't be able to segv the reader
<rlb>wingo: I also wondered about the awkwardness between records/structs and goops classes, i.e. you have to (define foo-class (class-of <foo-record>)) in order to be able to (define-method bar (x foo-class) ...).
<rlb>heh
<rlb>manumanumanu: in clojure a number of things like keywords, vectors, sets, maps, ... also act as functions.
<spk121>guile's analog of SEGV is any backtrace that has psyntax in it. ;-)
<manumanumanu>rlb: I only thought the keyword thing was for literal keywords
<rlb>It's quite handy (though I can see why it could be viewed as "too clever") for some constricts -- composes nicely with various other operations.
<wingo>hehe spk121 :)
<rlb> $ clojure -e '(def a :a) (a {:x 1 :a 2})'
<rlb> #'user/a
<rlb> 2
<rlb>
<wingo>scheme@(guile-user)> (call-with-input-string "(#true)" read)
<wingo>$1 = (#t)
<wingo>scheme@(guile-user)> (call-with-input-string "(#truf)" read)
<wingo>$2 = (#t ruf)
<rlb>oww quit it :)
*rlb did a very hacky thing to parse the literals...
<manumanumanu>Where can I find info about applicable structs? I thought local-eval was peak fun for me, but now I am not so sure.
<rlb>manumanumanu: I had to dig around in the source tree iirc, and mirror what guile does in a place or two -- not sure I found much documentation.
<spk121>wingo: I actually have a tool that may be of use to you. https://github.com/spk121/token-io-test
<rlb>manumanumanu: if I get a minute later, I'll see if I can find the code, if I kept it.
<RhodiumToad>I found exactly no documentation of applicable structs, other than a mention that they existed
<manumanumanu>rlb: if you can, please PM me. I am going to bed now.
<RhodiumToad>they're not hard to use in GOOPS
<ArneBab>how can I use them?
<wingo>spk121: noted, thanks!
<rlb>manumanumanu: found it -- I'll either put it somewhere in a bit, or if I forget, just ping when you're back.
<RhodiumToad>in goops you can just define a class as being a subclass of <applicable-struct> or <applicable-struct-with-setter>
<manumanumanu>Thanks! Good night everyone.
<wingo>manumanumanu: ,apropos applicable -- then search for uses of those identifiers
<wingo>yeah
<wingo>night manumanumanu :)
<ArneBab>RhodiumToad: does it also work without GOOPS?
*wingo zzz also
<ArneBab>manumanumanu: sleep well :-)
<ArneBab>you both :-)
<RhodiumToad>I believe it does, though I've not tried it
<RhodiumToad>one thing that seems slightly weird is that the procedure of an applicable struct is not passed the struct, though the procedure of an applicable SMOB _is_
<RhodiumToad>I assume this is for weird historical reasons
<rlb>yeah, that was a problem too...
<rlb>I forget how I dealt with it...
<RhodiumToad>well the obvious thing is for the procedure to be a closure over the struct
<rlb>Yeah, I think that's probably what I did.
<RhodiumToad>one can do a goops class that just invokes a specific method from the procedure, and then use that as a parent of other classes
<rlb>Yeah, though at least for my current purposes, I need it to work on built in <keyword>s etc.
<leoprikler>wingo: please keep #t1 that way, it's useful for golfing ;)
<mwette>wingo: Any notes on how to add port (e.g., riscv) to lightening? I did the trivial part of cp lightning/* lightening/* now running into jit_node_t gone. (I have riscv-gcc and looking at emulators -- so many of them.)