<str1ngs>sneek: later tell nly. were you going to use libchop with resonance? ***catonano_ is now known as catonano
<sneek>nly, str1ngs says: this looks really interesting <sneek>nly, str1ngs says: were you going to use libchop with resonance? <nly>sneek later tell str1ngs probably, yes <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 <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 <wingo>"generic" exceptions will be represented as key=%exception, args=(val), for the purposes of throw/catch <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 <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 :) <wingo>i mean that particular catch idiom <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>the r6/r7 system defines exception handlers that run in the context of the error <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 <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>fwiw racket appears to have an exception hierarchy for use internally; they don't appear to use compound exceptions <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' :) <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 <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>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 :) <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 <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 <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 <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>then we should also arrange so that srfi-35 and r6 have a direct low-overhead mapping to the new exception type <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 <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>fwiw raise-exception takes any value :) <wingo>doesn't have to be an exception <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 <wingo>i think we've had let/ec since 2.0 or so fwiw, so pretty good there <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? <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>does gnucash use the two-arg record-constructor ? <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) <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 <heisenberg-25>Hi, does setting GC_INITIAL_HEAP_SIZE env variable affect the guile gc?