IRC channel logs


back to list of logs

<str1ngs>sneek: later tell nly. were you going to use libchop with resonance?
<sneek>Got it.
***catonano_ is now known as catonano
<daviid>str1ngs: welcome!
<sneek>nly, you have 2 messages.
<sneek>nly, str1ngs says: this looks really interesting
<sneek>nly, str1ngs says: were you going to use libchop with resonance?
<nly>sneek help
<nly>sneek later tell str1ngs probably, yes
<sneek>Will do.
<str1ngs>nly: ipfs might be useful here as I mentioned before. since I believe some work is being done to support ipfs in guix. Assuming you are using guix store
<sneek>str1ngs, you have 1 message.
<sneek>str1ngs, nly says: probably, yes
<str1ngs>nly: based on your current state of work. it would be nice if after saving you can diff the tree against the save state. I'm assuming this content aware like git?
<nly>str1ngs: diffs would be nice.
<nly>thanks for the suggestion
<nly>it's not really content aware yet
<str1ngs>gotcha, and I think you are using libchop for merkle tree's right?
<nly>nope, i am not using it yet
<str1ngs>but that would be the reasoning for using libchop?
<nly>i want to use it for storing compressed or encrypted content
<nly>but idk
<str1ngs>gotcha, I might have misunderstood the need for libchop then :)
***apteryx_ is now known as apteryx
<wingo>civodul: fyi a bit of a recap on what i'm working on --
<wingo>i want a --r7rs option to guile, to complement --r6rs
<wingo>i have imported weinholt's work to guile but i would prefer to mostly layer r7rs on top of guile, instead of on r6rs
<wingo>but for exceptions, it's tricky. the guile r6rs code already does a fair amount of mostly-ok impedance matching between throw/catch/with-throw-handler and with-exception-handler/raise
<wingo>and i wouldn't really want to duplicate that
<wingo>at the same time, guile's error handling is historically something of a disaster
<wingo>like, i never know what the arguments to scm-error really mean :P
<wingo>so it would be better if possible to rebase guile's error handling on top of more structured exceptions
<wingo>i have a branch that rebases throw/catch on top of raise/with-exception-handler
<wingo>of course raise has to be called raise-exception because guile binds "raise" to the syscall ;)
<wingo>so far so good -- but then there are some more exciting problems
<wingo>like, most schemes allow for subtyping among exceptions
<wingo>and we've never supported subtyping of records
<wingo>turns out there is a reasonable O(1) way of doing subtyping, so i am now fixing guile's records to allow subtyping, and also to be able to mark some types as final so that they don't incur any additional overhead
<wingo>types are currently marked final by default
<wingo>so once i get subtypable records, i will work on defining specific exception types for guile, mostly following what's already defined in boot-9 in the set-exception-printer! code
<wingo>once that's done, i'll add with-exception-handler and raise-exception, somewhat in parallel, then migrate uses in libguile over to raise exceptions instead of calling throw
<wingo>once that's done, then throw/catch sits on top of exceptions. exceptions that originate in guile can round-trip perfectly between key+args and an exception object, so it doesn't matter which you use
<wingo>"generic" exceptions will be represented as key=%exception, args=(val)
<wingo>i.e. exceptions that didn't originate in throw and which isn't a "known" type
<civodul>hey wingo!
*civodul reads
<wingo>"generic" exceptions will be represented as key=%exception, args=(val), for the purposes of throw/catch
<wingo>braindump done. wdyt? :)
<civodul>so... :-)
<civodul>re rebasing exceptions on top of structured exceptions: i think that's a good idea
<civodul>my concern would be the cost of converting back and forth to key+args
<civodul>and also making sure that we really are compatible
*wingo nod
<civodul>i think it's quite common to write things like (catch 'system-error (lambda () xxx) (const #f))
<civodul>so this would have to remain as fast as it is
<civodul>well i guess it's faster in 3.0 anyway, but still ;-)
<wingo>that's not as fast as it could be of course :)
<civodul>re record subtyping, that's great!
<civodul>we could even have SRFI-99 (?) then
<wingo>i mean that particular catch idiom
<civodul>ah yes
<civodul>hence the 'stat' 2n argument
<civodul>but there are still many cases where we have no other options but to catch the thing
<civodul>you're planning on adding record subtyping directly at the level of structs, right?
<wingo>fwiw probably that case would be (with-exception-handler (lambda (exn) #f) (lambda () ...) #:unwind? #t #:unwind-for-type system-error?)
<wingo>there are some details
<wingo>the r6/r7 system defines exception handlers that run in the context of the error
<wingo>it's a pre-unwind system
<wingo>but in some emergency contexts in guile we can't run code there
<wingo>like stack-overflow in a hard limit case, or out-of-memory
<wingo>so we need the ability to annotate the stack of exception handlers with data indicating what they might handle, as an optimization
<civodul>as in what exception data type they might handle?
<wingo>i.e. if this handler handles everything and is going to unwind the stack, we mark it as such, and unwind before calling the handler
<wingo>or if this handler handles all 'system-error exceptions and unwinds, same thign
<wingo>i think symbolic exception types would have to be a part of the system for the forseeable future, to be able to make this kind of check
<wingo>so my example should have been #:unwind-for-type 'system-error fwiw
<civodul>how does this play with "compound exceptions" à la srfi-35?
<civodul>also, in srfi-34 you can specify several handlers in one 'guard' clause, and i think that's pretty neat (better than 'catch')
<wingo>so e.g. (catch T THUNK HANDLER) => (with-exception-handler (lambda (exn) (apply HANDLER (exn-key exn) (exn-args exn))) THUNK #:unwind? #t #:unwind-for-type T)
<wingo>so there are multiple options there
<wingo>as you might recall i think srfi-34 guard is bonkers with respect to continuations -- jumping down to run the guard code then back into the context of the exception to continue dispatching... bonkers
<wingo>but i shouldn't have said that, it's a distraction
<wingo>i think you can build anything you like in terms of with-exception-handler and raise-exception (and raise-continuable)
<wingo>guard is built on top, as are anything related to inspecting exceptions, compound or otherwise
<wingo>the real question would be more like "should guile use compound exceptions"
<civodul>when you say with-exception-handler and raise-exception, these are r7?
<wingo>yes but they are very similar in r6 and in racket
<civodul>"should guile use compound exceptions" is a good question
<civodul>i think key+args has been used as compound exceptions: &message + a specific exception
<civodul>that's definitely the case for 'system-error
<civodul>there's data, and there's human-readable message
<civodul>i think it's a useful feature
<wingo>yeah, but you could see it as subtyping also. compound exceptions are more flexible but most of guile's exception types in practice are a DAG forest, given that we represent the data as a list
<davexunit>all the error throwing code I write sucks because I don't know what I'm actually supposed to do. so I just use 'error' and I know that's not great.
<wingo>davexunit: hoo me too yo
<wingo>fwiw racket appears to have an exception hierarchy for use internally; they don't appear to use compound exceptions
<wingo>internally anyway
<civodul>wingo: it would seem "weird" for &system-error to be a subtype of &message, though
<civodul>i guess i got very much used to the SRFI-35 way :-)
<wingo>yeah but if it were a subtype of &guile-exception-with-message it would be 'normal' :)
<civodul>ah sure :-)
<civodul>well dunno, no strong opinion
<wingo>so i actually don't have much experience here with structured exceptions
<wingo>so i probably have not-great instincts
<civodul>R6 does more or less the same as srfi-35, right?
<wingo>is this something you'd want to have a poke at? i can lay down a draft that can change; i think once the adapters are all there and throw/catch works as it does now, the concrete representation of guile exceptions can change until 3.0
<wingo>civodul: afaiu yes though there are tie-ins with the r6 record system
<civodul>i can have a look and i'm happy to be in the loop, but i prefer not to commit to a specific timeline
*wingo nod
<civodul>in Guix i've been using compound exceptions more lately, mostly to have a user message + structured exception
<wingo>you ok with me working in this area?
<civodul>yes, sure
<civodul>so re subtyping, this is something you'd add at the level of structs?
<wingo>civodul: no, at the level of records
<civodul>records... as in boot-9.scm, right? :-)
<civodul>there's no shortage of records out there ;-)
<wingo>i am trying to unify them :)
<civodul>cool :-)
<civodul>it's not that bad actually
<wingo>i keep thinking that we should have some kind of basic define-record facility in boot-9 that is expressive enough for others to build off of
<wingo>dunno if it's possible
<civodul>i was going to suggest simply using srfi-35 or r6 exceptions as-is, not sure if that makes sense
<civodul>that would decorelate the exception work and the record work
<civodul>("de-correlate" maybe?)
<wingo>but re subtyping, with goops supporting multiple supertypes, i don't want to preclude that nor push it into core
<wingo>right but there are bootstrap considerations, and r6 pulls in a lot more
<civodul>ah yes
<wingo>i would rather do a kind of rebase -i to get needed things from r6rs exceptions into core, and make the r6rs exceptions layer lighter
<civodul>so you'd need to isolate the relevant r6 bits
<civodul>ok, sounds reasonable
<civodul>then we should also arrange so that srfi-35 and r6 have a direct low-overhead mapping to the new exception type
<wingo>yes exactly
<civodul>ideally they'd be just syntactic sugar above that new exception type
<wingo>ideally, but in the case of r6 there are again those other record considerations, so more impedance matching might be needed
<civodul>arf, yes
<wingo>srfi-35 doesn't specify any tie-ins with e.g. srfi-9 so that's easier to rebase
<wingo>(although already core records and srfi-9 are compatible)
<civodul>well anyway, exceptions are supposed to be... exceptional? :-)
<wingo>in terms of how they represent the record type objects internally i mean
<wingo>hah :)
<wingo>fwiw raise-exception takes any value :)
<wingo>doesn't have to be an exception
<wingo>fun times
<civodul>like throw
<wingo>yeah but at least the key has to be a symbol
<civodul>i'm sure there are people out there using throw for non-local exits but not-quite exceptions
<wingo>they should of course be doing let/ec, it's cheaper :)
<civodul>i think you can do (throw 42) provided you handle it correctly?
<civodul>yes, but that's another compat consideration
<wingo>civodul: nope, throw checks that the key is a symbol
<civodul>ah ok, good :-)
<wingo>i think we've had let/ec since 2.0 or so fwiw, so pretty good there
<dsmith-work>Hey Hi Howdy, Guilers
<civodul>howdy dsmith-work!
<wingo>civodul: landed subtypable records fwiw
*wingo back to what i should be working on :P
<nly>are lists as fast as arrays in guile?
<dsmith-work>wingo: Wow, that was quick!
<wingo>well, been thinking about it for a while :P
<wingo>nly: depends... generally vectors are faster but you should look at your use case :)
<chrislck>are srfi-9 records so much faster than record-constructor then?
<wingo>chrislck: there are a few things going on there; srfi-9 records are faster because they do more at syntax expansion time and make more interesting info available to the optimizer
<wingo>record-constructor is fine but the version that took two arguments was excruciatingly slow
<wingo>and not used in guile
<wingo>does gnucash use the two-arg record-constructor ?
<chrislck>ooh plenty :)
<wingo>fun :)
*chrislck will get busay
<wingo>perhaps i will have to undeprecate if it's really important but i think you will be happier with the one-arg version (that makes a constructor that takes all fields as args)
<wingo>lmk how it goes
<chrislck>tagging gjanssens so he knows why I'll continue srfi-9 conversions
<chrislck>no issues expected for the next 5 years at least, when the distros start shipping 3.0
<chrislck>actually not that bad, most are 1-arg
<nly>thanks wingo
<gjanssens>chrislck: right, thanks for the heads up
<amz3>sneek: later tell soda__hobart I reported the bug against guile-redis regarding pub/sub at
<sneek>Got it.
<heisenberg-25>Hi, does setting GC_INITIAL_HEAP_SIZE env variable affect the guile gc?