IRC channel logs


back to list of logs

<apteryx>mwette: do you still have that program parsing gnu/packages definitions and generating a dependency dictionary? I'd be curious to graph it
<apteryx>would it be possible for guile to produce a warning when it detects a circular module dependency? (we'd have to track modules being loaded and when a symbol couldn't be found warn that it wasn't finished loading and got accessed from Y)
<apteryx>that'd help a lot with troubleshooting such problem
<mwette>I was going to send but rejects; know of another?
<mwette>daviid: thanks
<daviid>fwiw, this is a cool one as well api from the cmd line - and a webform - no ceremony [ no (huge) header, no register ... ] - you're responsible to delete your paste(s)
<daviid>there are tons 'out there', most are terrible (tracking, none free js ...) - there are other cool ones though, we should make a list and ask our bot to remember ...
<apteryx>mwette: thank you!
<haugh> is cli-oriented and EUPL
<apteryx>a procedure's default arguments are evaluated at the top level, right?
<haugh>(define* (foo #:optional (bar (display "NOPE\n"))) bar) (foo) (foo)
<haugh>but you can use let over lamba*
<haugh>that is, lambda*
<apteryx>interesting, thanks
<apteryx>so the default arguments are only evaluated at the time the procedure is called?
<haugh>I wouldn't have it any other way! Closure (let over lambda) is the general mechanism for pre-evaluation.
<apteryx>I think Python does this weird optimization hack of evaluating the default arguments when the module is loaded
<apteryx>or allocates them once and they are reused across calls
<apteryx>which was surprising
<apteryx>so if you have def myproc(mylist = []): mylist.append(1); return mylist -> myproc() -> [1], myproc() -> [1, 1], ...
<apteryx>the default argument is mutated ^^'
<haugh>apteryx, thanks, I added that to my list of reasons why I won't "just use Python"
<Arsen>that's not really an optimization, though
<apteryx>I should have put (?) next to that statement of mine
<Arsen>it's an obvious result of how functions work, where they're constructed once with their default arguments and then can be called from that
<apteryx>they could have been constructed with their arguments delayed, no, to be evaluated on each call, like Scheme does?
<apteryx>So it seems a design choice for avoiding recomputing default argument values
<haugh>actually I just noticed that I misinterpreted your original question, apteryx. The defaults are evaluated on call, not definition, but they are evaluated "at the top level" in the sense that they have access only to the top level environment; you can't cheese it with a new lexical environment
<apteryx>OK, that was bad wording on my part, you answered what I wanted to know :-)
<haugh>okay just making sure
<haugh>Also I just learned about dynamic scope which might be useful to you here; check out the index for make-parameter
<rlb>fwiw wrt python "may be ongoing":
<haugh>I forgot how salty those mailing lists get
<daviid>RhodiumToad: for info, i pushed the adw1-demo port from 1.2.2 to 1.4.0
<RhodiumToad>I got some amount of GAction stuff working even without GVariant, though it's a bit limiting
<RhodiumToad>actions with target values can be defined in UI widget definitions but not from scheme, and GPropertyAction can be used to get state values for such actions
<daviid>RhodiumToad: worth mentionning that - to correct my recent 'complexity' related comment - this version is one order of magnitude simpler, my comment was mostly due to the previous use of the (overly complicated) AdwLeaflet classes, properties and methods ... so things got 'back to normal' i would say, thanks to the newly added AdwNavigationSplitView, AdwNavigationPage ... those interested, just look at the adw1-demo 1.4.0 ui files and
<daviid>code, clean, simple and somewhat beautiful
<daviid>right, such action with target i the just added navigation view pages - GVariant full support will no happen anytime soon, on the list, but far from the top ...
<daviid>i never used GPropertyAction, but i hope you will publish your code at some point, so one can look at a real example ...
<RhodiumToad>btw, I found defining a macro or two helped simplify the sxml quite a lot
<daviid>oh nice
<RhodiumToad> <-- a small sample, though I haven't worked out what to do about (child (@ (type x)) y) yet
<RhodiumToad>also that shows my attempt at cutting down the amount of boilerplate for selective import
<graywolf>Are there reasons to prefer either (ice-9 exceptions) or (srfi srfi-35)? I like make-exception-with-irritants, and it seems more complete (type hyerarchy), but for example Guix seems to use srfi-35. Is there any write up which one I should prefer and when?
<haugh>Good question. I'm new to exception objects and I'd like to hear thoughts on this. For me, the type hierarchy is vital, because it helps me "roll up" related errors as I fail my way back to a safe loop. A built-in example with (ice-9 exceptions) is (programming-error? (make-lexical-error)), but this also applies to user-defined exception types. AFAIK there's no equivalent feature in SRFI-35
<graywolf>My (limited, that is why I am asking in the first place :) ) undertanding is that under srfi-35 you are supposed to create the hierarchy yourself. Technically there already is a hierarchy present, but just of 3 types.
<graywolf>(&condition, &serious, and &error)
<haugh>oops, I'm wrong: (define-condition-type f &condition f?) (define-condition-type g f g?) (f? (condition (g)))
<haugh>Very interesting ecosystem. Seems quirky in that "historical" way. Almost like (ice-9 exceptions) is a descendent of RNRS 6 and SRFI ideas, some of which are part of core guile
<RhodiumToad>at least in 3.0, &condition, &serious, &error just correspond to (ice-9 exceptions) &exception, &error, &external-error
<haugh>I think &exception and &error are in the core (as well as &compound-exception, &exception-with-kind-and-args, &non-continuable, &programming-error, and &quit-exception (?))
<haugh>but &warning, &message, &irritants, &origin, &external-error, and the &programming-error subtypes are in (ice-9 exceptions)
<haugh>very complex
<haugh>much obfuscation
<RhodiumToad>some of the types are in core because core can throw them
<haugh>good point
<haugh>" In Guile, SRFI-34, SRFI-35, and R6RS exception handling are all built on the same core facilities, and so are interoperable."
<haugh>"Guile’s R6RS layer uses core exception types from the (ice-9 exceptions) module as the basis for its R6RS condition system. Guile prefers to use the term “exception object” and “exception type” rather than “condition” or “condition type”, but that’s just a naming difference. "
<haugh>Historical quirkiness confirmed
<haugh>These are the breaks with a 30 y/o lang
<haugh>Like how there's eight different ways to check string equality in Bash
<graywolf>It is nice that they are interoperable, but that does not help me much with what I should use when writing a new code (in vacuum, without dependencies) :)
<haugh>I hear ya, but I'm just gonna keep using (ice-9 exceptions) and linking the above to anyone who complains
<haugh>Thanks for the diversion, I was in a syntax hole
<waaay2meo4u>i am trying to run web requests to a particularly nasty server that requires a TLS rehandshake which if I understand correctly is not implemented in (web request) and possibly not in guile-gnutls either
<waaay2meo4u>anyone has suggestions before i dive into the libraries?
<graywolf>shell out to curl ^_^
<waaay2meo4u>i already did
<ulfvonbelow>is there a good way to tell whether a fdes finalizer is being run synchronously (e.g. as a result of close-port) or asynchronously (e.g. as a result of GC)?
<mwette>rlb: utf8 302.73/0.85; 3.0.9 374.89/0.88; main 371.01/0.95
<civodul>ulfvonbelow: i don’t think so
<rlb>mwette: interesting, and thanks again.
<rlb>I may try this, when I get time, and if I can get it to work. Though if anyone else wants to instead -- by all means :)
<dsmith>sneek, benchmarks?
<sneek>benchmarks is at
<dsmith>sneek, botsnack
<graywolf>ArneBab: I sent the patch extending the documentation of (ice-9 match) as you asked: ; Do I need to do anything else or will someone notice the patch in due time?
<ArneBab>graywolf: nice! Thank you! People will usually react to the patch in due time — it’s just that all are volunteers, so they need to wait until they can make time.
<graywolf>Sure, no problem :) Just wanted to make sure I did not miss anything process-wise
<ecraven>rlb: if you have problems, ping me
<ulfvonbelow>if a file descriptor is closed as a result of a port being garbage collected, and that causes a file descriptor finalizer to run, does the port still exist while the file descriptor is running (for example, if it were stored in a weak vector accessible to the finalizer)?
<ulfvonbelow>s/while the file descriptor is running/while the finalizer is running/
<graywolf>Hm, is there elegant way to write (cut eq? (channel-name <>) 'guix)?