IRC channel logs
2026-03-03.log
back to list of logs
<janneke>is it possible to to inject raw html (say: <a name="#0"> for a footnote) in a haunt .md post? <janneke>err, that would probably be name="0" -- but yeah <Codeko>I'd like to attach text properties to Guile's strings, similar to what elisp can do, is this possible without modifying Guile's source code and recompiling ? <identity>Codeko: why not just wrap the string in a record type that stores the properties? <old>Codeko: I often used object properties like ekaiktz proposed. It's is transparent to all your code, except the part that need the properties <old>So a string stay a string and can be used anywhere a string is expected, but you can extract more metadata if needed <old>In Software Design for Flexibility, they call this "layering" and allow for interesting patterns to emerge <Codeko>My first thought was also object properties, but I don't think it's sufficient for this kind of thing: (minibuffer-message (propertize "Hello" 'face 'error)). With the object properties approach I'm forced to bind the string to a variable, but I might be wrong. <JohnCowan>That would be identifier properties, not object properties: object props are a key-value store attached to any object that do not conceal its type. <JohnCowan>They can be implemented using a global weak hash table that maps the objects-with-props to the props <Codeko>I see, it should be doable, I should probably cache string object pointers and store metadata for them, or something like that. <wehlutyk>I'm trying to have parallel processing of one large table (just a 4K picture), repeated every few milliseconds if possible <wehlutyk>- ice-9 threads seem to not give much benefit because of data transfer between the CPUs (or that's the problem I guess, which might be wrong), and due to later steps not being so predictably parallelisable <wehlutyk>I think fibers would solve that second challenge, but I'm now wondering if it would be possible to have memory pools with fibers, to not be re-allocating all the time? <wehlutyk>sorry if all this sounds messy -- I'm trying to clarify the problem by just describing it ... :p <ekaitz>wehlutyk: what do you mean by memory pools? <janneke>is it possible to to inject raw html (say: <a name="0"> for a footnote) in a haunt .md post? <ekaitz>janneke: commonmark supports html, doesn't it? <dthompson>unfortunately the official guile-commonmark repo doesn't and has been abandoned <dthompson>and I just checked... the spritely fork is now used for the guile-commonmark package in guix <mange>Can you use a . like that? My understanding is that . is special syntax for a bare cons, so either #`(lambda #,(or rest #'())) or #`(lambda (other args . #,(or rest #'()))) might work. <ieure>mange, Yes. ((lambda (a . bs) bs) 'a 'b 'c 'd) ; -> (b c d) <ieure>From `(guile)Lambda', "If a space-delimited period precedes the last variable, then the procedure takes N or more variables where N is the number of formal arguments before the period." <mange>Yeah, but look at the linked code. (. x) is a bit weird. I think it's just equivalent to x, right? <ieure>mange, Ah, yeah. (lambda x ...) is how you write a purely varargs lambda. <rgherdt>mange: another option: (lambda* (x #:rest args) <...>) <mange>Sure, but I was trying to stay closer to graywolf's code. <ieure>Yes, but it's probably easier to express what they want with lambda*. <ieure>Anyway, options given, up to their judgement now. <mange>To be honest, I didn't expect quite so much criticism for my suggestion. <ieure>mange, Wasn't intended to be critical, sorry. <graywolf>Thanks for the suggestions, the #:rest looks like the way (I can just pick using #,(if rest #'lambda* #'lambda). <graywolf>(My understanding is that lambda* is slower than lambda, same way define* is compared to define) <mange>I wouldn't expect it to be slower if you're just using #:rest, because it doesn't need to do more work. #:optional and #:key require some extra processing, though. <graywolf>I think define* is slower even when no extra features are used, did not check with lambda*, true. Will benchmark. <ieure>Is it slower to define a lambda*, slower to evaluate one, or both? <graywolf>Some time back I benchmarked invocation of a procedure defined using define* and define, and define* was measurably slower, even when not using #:optional, #:keyword or #:rest. Maybe the benchmark was flawed? <mange>Using ,disassemble on (lambda (x . y) (list x y)) and (lambda* (x #:rest y) (list x y)) yields identical code. <ieure>mange, Genuinely love how Lisps let you go deep like that so easily. <graywolf>Oh, ,exp suggests that lambda* actually just expands to lambda when #:optional is not used. Neat. Maybe this changed since 3.0.9?