<jackhill>Hi Guix! I'd like to learn about streaming in Guile. Something like conduit or pipes in Haskell or transducers in Clojure. Advice on where I should look? <daviid>jackhill: guile has just 'win' a transducer module, but i don't remember who wrote it and where it is :) <jackhill>daviid: thanks. I'm currently looking at SRFI-41 <daviid>jackhill: I hope someone that 'really knows' can help ... <jackhill>an and SRFI-171. The internet searching is going better today than it usually does :) <tohoyn>daviid: I get the following error from configure when I have Guile 3.0, 2.2, and 2.0 installed: configure: error: found development files for Guile 3.0, but /usr/bin/guile-2.0 has effective version 2.0 <tohoyn>daviid: It doesn't work even if I remove 2.0 from configure.ac <tohoyn>daviid: I have both guile 3.0 and 2.2 installed and I would like to use 2.2 <daviid>tohoyn: not sure, maybe you could try to remove 3.0, use GUILE_PKG([2.2 2.0]), or even GUILE_PKG([2.2])? <tohoyn>daviid: I changed the argument of GUILE_PKG to [2.2]. It doesn't work if the development files of both guile 3.0 and 2.2 are installed. <daviid>tohoyn: hum, that is a guile parallel install 'error', not a g-golf error, I wish I could help but I am 'idea less', I hope soene used to these config can jump'in and help ... <daviid>what is the error whe yu only keep 2.2? <daviid>only keep GUILE_PKG([2.2]) in g-golf configure.ac file I mean ... <tohoyn>daviid: configure: error: found development files for Guile 2.2, but /usr/bin/guile has effective version 3.0 <tohoyn>daviid: seems to work when i used update-alternartives --config guile <daviid>tohoyn: this is a debian guile parallel install problem, I think <tohoyn>daviid: Theme-D works fine there <tohoyn>daviid: having development files for both 3.0 and 2.2 installed <daviid>the configure output should show what it finds for guile, guld, gule-config, then variables, site, site-ccache ... <tohoyn>the problem is that configure.ac reports an error when it finds out the the version of /usr/bin/guile is 3.0 <daviid>but it first tried other, like guile-2.0, guile2.0 <daviid>which is a debian problem I think <tohoyn>daviid: configure.ac contains line GUILE_PROGS([2.0.14]) <daviid>that's ok, it only ther to tll the minimum version with which it should be happy <daviid>but it should finf guile, guild and guile-config all for 2.2.x <tohoyn>daviid: anyway, bytecodes are wrong even though configure and make work <tohoyn>daviid: ,use (g-golf) doesn't work <daviid>tohoyn: if configure fails, obviously make will fail, so will fail ,use (g-golf) <tohoyn>daviid: the problem is that am/guile.mk uses command "guild". it should use "guild-VERSION" (which doesn't work for guile 2.0) <tohoyn>daviid: configure and make work after update-alternatives <daviid>i can patch guile.mk, it still does not explain why configure fails though <daviid>and most istallation will keep guild and guile-config <daviid>tohoyn: ok, I changed t to $(GUILD) - though in yur case, it should still fail earlier <daviid>tohoyn: I pushed the fix, so guile.mk uses $(GUILD), not guild <daviid>which is better, but it won't solve your/debain configure problem <tohoyn>daviid: the value of GUILD is wrong. it is /usr/bin/guild. <daviid>as i told you, it is a debian problem <daviid>tohoyn: the debian guile's maintainer is often herem alhtough not now, hi nicj is rlb, try to ping him when he's around ... <tohoyn>daviid: I disagree. if you use guild-VERSION and guile-version it works fine. <daviid>tohoyn: it's a debin proble if you use debian packages of course, if you manually installled, that's another problem <tohoyn>daviid: I've got guild-3.0 and guild-2.2 <daviid>tohoyn: you report a configure problem, at that time, guild is not used <daviid>it is the configure step that sets the GUILD variable <daviid>ok, for some rason I don't know, it's not working for you <daviid>or someone else that knows is welcome to help of course ... ***wxie1 is now known as wxie
***rekado_ is now known as rekado
***sputny1 is now known as sputny
<tohoyn>is it possible to have warnings as errors when compiling guile code? <tohoyn>it would be useful especially for --warn=unbound-variable <civodul>tohoyn: it's not implemented currently but i agree it'd be nice <tohoyn>FYI: A new version of programming language Theme-D is released. It supports both guile 2.2 and guile 3.0 as target platforms. <tohoyn>FYI: A new version of software library Theme-D-Gnome has been released. (no support for Guile 3.0 yet) <tohoyn>daviid: It would be nice if gslist would work as a g-golf return type. I need it for procedure gtk-radio-menu-item-get-group. <tohoyn>daviid: function gtk-radio-menu-item-new-with-label gives the following warning: Unimplemented type: gslist <lloda>what's the trick to use ssh for cvs commit <lloda>it keeps asking me for a password <lloda>I did it two years ago but I don't remember how :-( <lloda>no, i've got conflicts. I think it's ok to force for www-commit, right? <lloda>nikita`: thx, yes that's what I did <lloda>and set CVSROOT with username and remove the baked in -d line <nikita`>it doesn't work in my experience. resolve conflicts locally and then commit? <lloda>the only thing i've ever used cvs for is the guile-cairo website <nikita`>NetBSD is working on moving away from CVS but it's a long road, that's why I'm still using CVS for many projects <lloda>ok i'll look into how to do that... <nikita`>old repository with many roadbumps in commits. last i heard we're close to migrating <lloda>yeah that was my fault, I had a separate checkout of the website but I forgot about it and I foolishly used make www-commit from the guile-cairo source *lloda has to be more diligent keeping notes <nikita`>nothing finished so far, so nothing official i guess. <lloda>civodul: can/should we have a debuggs component for guile-cairo? or should we direct guile-cairo bugs to just guile <civodul>lloda: dunno, i'm not involved in guile-cairo nor debbugs :-) <lloda>well odd version in case I messed something up <lloda>mostly to regen the doc in the website <civodul>if it's good enough for you, Savannah has an old-style web-based issue tracker <lloda>I ask you b/c wingo told me you would know <civodul>yes, to request a debbugs entry, just email help-debbugs@gnu.org <wingo>hehe apologies for my ignorance <lloda>RhodiumToad: wingo added a couple extra bindings <lloda>There are no standing bugs as of now <mwette>sneek: later tell tohoyn, daved rlb knows about the missing guild-2.2; I ran into the same problem <civodul>yay, happy Friday dsmith-work & all! <janneke>...welcome new contributor's day ;)? *janneke ...trying to gently nudge "someone" to say something about regtur's fsf paperwork and/or new PEG patch <civodul>i'll push the 'pipeline' patch hopefully soonish *janneke often very much likes a: "i've seen you" -- even if a real reply takes longer and more effort <civodul>but yeah, sorry for not showing any signs of life! <stis>python's ctypes are nice, trying to build something for <stis>I'm trying to build it with guile's ffi <mwette>stis: Do you know about scheme-bytestructures and nyacc's ffi-helper? <daviid>tohoyn: can you provide a snipset with a minimal example of radio-menu item/group, tx <daviid>tohoyn: please use the 'template' we've used for list-store ... using gtk-main (not a <gtk-application> and doesn't use g-application-run ...) tx <daviid>for those debugging snipset ... unless the bug/missing type is related to <gtk-application> and/or g-application-run of course ... <tohoyn>daviid: do you need a C snipset or Scheme? <sneek>Welcome back tohoyn, you have 1 message! <sneek>tohoyn, mwette says: daved rlb knows about the missing guild-2.2; I ran into the same problem <daviid>mwette: is this a guile.m4 problem maybe? <daviid>it's been patched very recently, didn't grab the latest, g-golf keeps a copy (to avoid ACLOCAL problems and nice r messages if guile itself cant be find ...) <mwette>daviid: I don't know; guile-dev provides guile-2.2 but not guild-2.2 IIRC; I've also have problems if guile is 3.0, there is no guile-3.0 but guile-2.2 exists. I ended up tossing out guile.m4 and hacking up configure.ac for my app (nyacc) <daviid>yes, it's ok, will look into this asap, let you know when fixed, tx <daviid>mwette: I think rlb mentioned here he did solve those problems, with the new 3.0.x package he worked on for unstable (or is it in testing already?) ... that is very recently, not sure but i <mwette>daviid: yes, I brought this up to him several weeks ago, I referenced a ubuntu bug report I filed <bsima>this code never completes reading from the port, is there something I'm missing? <bsima> (let ((port (popen/open-pipe "pandoc -f markdown -t html -o -" OPEN_BOTH))) <bsima> (read-delimited "" port 'concat) <RhodiumToad>trying to read and write pipes to the same subprocess from the same thread is a recipe for deadlock <RhodiumToad>there's no guarantee that the subprocess will flush its output in a timely manner <bsima>oh, deadlock. how can I pipe to/from a subprocess then? <RhodiumToad>there are two issues: the subprocess might not flush output, and that the subprocess might emit enough output to block writing its output pipe, causing you to block writing to its input pipe, resulting in your never getting to read the output to unblock it <RhodiumToad>to make it work reliably, you need to desynchronize the input and output somehow - whether by doing things in a nonblocking fashion or doing them from different threads <RhodiumToad>in the example of passing a short string through a text filter, the subprocess probably isn't going to write anything until it sees EOF on the input or has at least a buffer's worth of output lined up <bsima>when i ^C then ,bt it looks like guile is waiting for something from pandoc <RhodiumToad>pandoc hasn't seen an EOF on the input, doesn't have enough output yet to be worth writing, so it's waiting for more input <bsima>(display "EOF" port) doesn't work <RhodiumToad>you have to close the writing direction of the pipe, yes - haven't looked at how you would do this in guile <bsima>hm, should I use 2 ports? one for writing, one for reading? <bsima>seems like that just closes the port though, i think i need two ports <justin_smith>my assumption was that "close-output-port" would close the out aspect, leaving in open for reading, maybe that was optimistic <bsima>yeah, unfortunately it just closes the entire thing <bsima>maybe i could just port that to guile <RhodiumToad>looking at popen.scm, the bidirectional pipe implementation is just not usable <RhodiumToad>precisely because it does not implement one-way closing <bsima>there's an interesting patch from last month on the guile-devel mailing list that implements 'pipeline' and 'piped-process' procedures <RhodiumToad>it even hides the read and write ports inside a closure so there's no way to get at them <RhodiumToad>being able to close the write direction of a bidirectional port while still being able to read the read direction is a fundamentally necessary feature <bsima>i think that would solve my problem <bsima>until it's merged i'll just write to/from tmpfiles <bsima> ((@@ (ice-9 popen) open-process ) OPEN_BOTH "pandoc") <bsima> (display "*bold*" to) (close to) <bsima> (display (read-string from)) (newline)) <bsima>after studying the code in the patch this is what i came up with. I guess the special @@ syntax is necessary for getting that open-process function <justin_smith>like all monkey patching, it's too bad you have to but very nice that you can <bsima>oh i see open-process defined in C and completely undocumented <ATuin>when using geiser and emacs evaluating a guile expression (inside a module file) it's not defining it in the REPL buffer, is that normal? <ATuin>it works if I do it in a buffer that it's not a module <bsima>ATuin: depends on what module the REPL is in i think <ATuin>bsima: yes, it worked thanks <ATuin>does srfi-9 provide a way of getting a default value when using a getter for a field? or do i need to use goop for that kind of feature? <manumanumanu>ATuin: I would hide the constructor and roll my own (make-[record] ...) that adds default values <manumanumanu>hide the constructor as in call it %make-blahblah and (define (make-blahblah ...)) that solves the default argument stuff <manumanumanu>and if it is in a module, just don't export the %make-blahblah <ATuin>I create a record inside a module and that's defined in another module. When i recompile the module defining the record the predicte (my-record? r) returns #f :D <ATuin>I guess it's because it's a different struct at that point internally ***daviid is now known as Guest38350
***Guest38350 is now known as daviid
<jackhill>I would have thought that second two examples would work based on the manual "matching of SXML attributes (within an element) is under-ordered…" and "…the element being matched may include additional attributes not specified in the pattern" <jackhill>Is it that I don't know XML well enough and those only the (@ (…)) are attibutes? <RhodiumToad>(example (bar "bar") (foo "foo")) means <example><bar>bar</bar><foo>foo</foo></example> <RhodiumToad>and obviously putting the (foo) and (bar) elements in the other order changes the meaning <RhodiumToad>if you meant <example foo="foo" bar="bar" /> where the order doesn't matter, that would be (example (@ (bar "bar") (foo "foo"))) <jackhill>okay, yeah, I think I just don't understant the semantics of XML :) <jackhill>the xml I'm dealing with really is the former. Unfortunately, not every <example> element has all the same subelements (although, they are at least in the right order). I only care about pulling some of them out, but it looks like I'll have to be use something more clever than sxml-match. <RhodiumToad>pretty sure sxml-match can do what you need. but you may have to use catamorphisms <RhodiumToad>an <example> might contain, say, a <foo> and a <baz> that you want to extract, and possibly an optional <bar> in between? something like that?