IRC channel logs

2019-11-19.log

back to list of logs

***Guest95982 is now known as daviid
<chrislck>daviid: isn't manumanumanu's flatten more efficient because it omits reverse! and append?
<daviid>chrislck: long time written, but does it solve the same 'class' of problems? like 'deep nested' lists
***Guest67735 is now known as jao
<ober>can the elisp support be used to say use the org-mode stuff directly in guile?
<amz3>idk
<amz3>elisp support is like one the most requested feature on this channel.
<amz3>wingo: I could not find the crawler I wrote about previously. I will need it, anyway, so I can do it today?
<zigzag>back
<zigzag>under a new nick (that does not look like a war game handle)
<wingo>RhodiumToad: regarding ssax bugs, in practice there is no ssax upstream, so we're all left to handle things as we see fit
<wingo>in guile we can fix ssax directly if appropriate. send a mail to bug-guile@gnu.org
<wingo>i had totally forgotten about mark's r7rs-wip branch from 5 years ago
<wingo>i wonder why things from there didn't make it in
<civodul>hello wingo!
<civodul>wingo: i'm guessing it fell through the cracks :-/
<wingo>ah well
<chrislck>daviid: yes manumanumanu's https://pastebin.com/gX2vZM8A flattens arbitrarily deep nested lists
<chrislck>thanks manumanumanu... https://github.com/Gnucash/gnucash/commit/fbc7c902
<roptat>how do you write a procedure that has side effects? like (define (add-1! a) (set! a (+ a 1)))
<roptat>if I have (define b 1) (add-1! b) I'd like b to be 2 now
<wingo>it needs to be a macro in that case
<RhodiumToad>ok, sent mail about the bug
<roptat>oh, ok
<wingo>hoo, the srfi-99 rationale is tedious
<jcowan>srfi-99 was highly political
***daviid is now known as Guest4493
***Guest4493 is now known as daviid
<str1ngs>on the topic of records is there a srfi that provides features like guix's define-record-type* ? basically it provides syntax constructors with named fields
***sneek_ is now known as sneek
<wingo>$ meta/guile
<wingo>GNU Guile UNKNOWN
<wingo>'doh
<jcowan>str1ngs: Not that I know of, no.
<str1ngs>jcowan: okay, thank you
<pinoaffe>I was unable to find a base set of utility functions for working with SXML (eg, a function to get an attribute given a tag, or something to find all tags matching a predicate) - do these exist somewhere?
<pinoaffe>I kinda feel like i'm reinventing the wheel
<zigzag>that is kinda scheme spirit :)
<zigzag>seriously, to work with xml, you need to work with sxml, that is, scheme lists.
<zigzag>if you need to traverse a (s)xml document, you can rely on sxpath.
<zigzag>pinoaffe: a snippet might help give a better answer.
<zigzag>"something to find all tags matching a predicate" I know no API that allows to do that without actually getting all attributes and apply a filter.
<RhodiumToad>sxpath allows predicates, no?
<zigzag>prolly, my guess is that it can. I never used that feature.
***zigzag is now known as zig
<RhodiumToad>the documentation isn't all that amazing
<RhodiumToad>(sxpath '(// (* (@ id)))) seems to work for "return all nodes that have id tags"
<zig>ack'ed.
<RhodiumToad>(sxpath '(// (* (@ (equal? (id "zzz")))))) seems to find a node with id "zzz", though I'd need to test that more
<RhodiumToad>pinoaffe: is this helping you any?
<pinoaffe>RhodiumToad: ah that seems to do (part of?) what I want, I guess I must've misunderstood the docs :)
<RhodiumToad>I only recently started playing with this myself, wasn't too impressed with the docs
<RhodiumToad>resorted to reading the sources instead, and immediately found an obvious bug
***apteryx_ is now known as apteryx
*RhodiumToad still thinking about the best way to parse xml without losing the namespace info he wants to keep
<pinoaffe>RhodiumToad: the code is indeed quite a bit clearer than the docs, node-closure does at least one of the things I need
<pinoaffe>so I can replace my own, buggy implementation with a probably way more sensible one ;)
<RhodiumToad>I think omitting namespace declarations from the generated sxml is a design error, but I'm not sure if it's easily worked around
<jcowan>Where a namespace declaration is and what the namespace prefix is, are really surfacey matters that shouldn't appear in the SXML.
<jcowan>The original design of namespaces required them to all appear uniquely at the beginning of the document, but people said "What if a component wants to generate elements in its own namespace that the outer components know nothing about?" So for that very very limited use case we are stuck with the baroque namespace machinery.
<jcowan>I think it's best practice to declare them on the root and only on the root..
<jcowan>Definitely using two prefixes for the same namespace is a bad idea, and using the same prefix for two namespaces (in different scopes) is a REALLY bad idea.
<RhodiumToad>maybe so, but the existing sxml library just throws them away after qualifying the tag and attribute names
<jcowan>Because that's what the various data models say is the Right Thing.
<RhodiumToad>right now, if you just want to simply read in a document and write it out again, you have to manually trawl the sxml to find all the namespaces, synthesize prefixes for them all, rewrite the document to use them and then output it
<RhodiumToad>and really I'd like to preserve the original document's choices of prefixes and, importantly, its choice of default namespace
<RhodiumToad>(preserving the prefixes is just a "nice to have", but preserving the choice of default is more or less required)
<RhodiumToad>moving all the namespace declarations to the root node is acceptable
<RhodiumToad>I do wonder at the thought processes of someone who writes a library in which something as simple as (sxml->xml (xml->sxml blah)) fails
<ArneBab_>ober: see guile-emacs; in guix: guix install guile-emacs — slow due to missing optimizations but works.
<mange>Has anyone here used fibers within geiser? I'm struggling to figure out how to call run-fibers without blocking my REPL. I'm using the 1.0.0 release packaged in Guix. The ,spawn-fiber metacommand seems close to what I want, but the fibers get stuck "suspended" as soon as I run another command in the REPL.