IRC channel logs


back to list of logs

<bandrami>Is there an equivalent to PEG that uses local scope rather than defining top-level variables?
<chrislck>just throwing question out there -- (sxml sxpath) seems to be an underdeveloped (ie incomplete xpath spec) and underdocumented module, no?
<rekado_>underdocumented: yes.
<rekado_>chrislck: what version of Guile do you use?
<rekado_>recent versions have more comprehensive sxpath documentation.
<chrislck> ?
<chrislck>i've been trawling the nets for good example codes and it's a shame they're all from sxpath-old.scm :-)
<rekado_>heh, yes.
<rekado_>what would you like to know about sxpath that’s not in the manual?
<chrislck>basically a 1-to-1 mapping of w3 xpath and sxpath would be good... as well as limitations eg /books/book[last()] seems fine '(books (book -1)), however /books/book[position()<3] is probably out of scope
<chrislck>if i understood correctly
<chrislck>racket has txpath which acceps string directly as well, unlike guile
<amz3>chrislck: yes, string->sxpath would nice to have, but there none yet
<amz3>chrislck: if you have an example xml and an xpath, I can make the sxpath
<amz3>chrislck: ah you already know how to use it
<mwette>the original sxpath allowed strings (read Oleg's papers); and racket has it
<amz3>the reasoned schemer for microkanren is coming:
<dustyweb>amz3: oh cool
<manumanumanu>Ahoy hoy!
<manumanumanu>What's cooking in guile-land?
<ennoausberlin>I need some advice to figure out scope in guile
<manumanumanu>ennoausberlin: sure thing. what is your question
<ennoausberlin>There is a function called (job ... ...) which takes two lambdas as arguments. In the first lambda I just read some values from a config file and store them via let. In the second lambda I need some of the values from the first lambda but they are not visible. I have to reread the values from the config file to use them. I guess there is a better approach
<ennoausberlin>This is related to
<manumanumanu>Why aren't you reading them before you run job? Or create the lambdas in a closure where both have access to the config content?
<ennoausberlin>job is the only function that runs in an mcron file, I think
<ennoausberlin>mcron is a guile based cron scheduler. It expects a file named foo.guile in his working dir and there should be a (job ... ...) specifier which describes when and what to run.
<ennoausberlin>I compute the when-interval from values of my config file
<manumanumanu>is there an error to have any other code?
<ennoausberlin>I did not try it yet
<ennoausberlin>It might work, but I was curious how to deal with such cases
<manumanumanu>Sort of a special thing. I would probably use a closure or maybe set! for small scripts, but that isn't appliccable here since I don't know how guile evaluates arguments
<ennoausberlin>For now I will try to insert the extra code outside the job specifier. Thank you
<manumanumanu>mcron is nice
<ennoausberlin>Code before (job ... ...) is executed so I dont need to read the config values twice. Great. I am still a guile newbie
<manumanumanu>Kein problem! Just ask. we might be slow to respond, so give us some time :)
<manumanumanu>ennoausberlin: the question is: is the code re-evaluated each time, or only once? So, if you change the config file, it is reloaded by mcron, or if it is read once and then static until you restart
<ennoausberlin>config is only read at startup I guess. If you change the foo.guile cron file while mcron is already running it will not change anything
<manumanumanu>Then you should probably read the config file every time you execut the cron job :)
<ennoausberlin>config file does not change often. I can just kill and restart mcron. Another problem I ran into was time out. I can not specify a job with a given timeout.
<manumanumanu>like what?
<manumanumanu>Do you want a file to be run until a certain date, or do you want to kill a job if it takes too much time?
<ennoausberlin>I want to kill the job if it takes to long
<manumanumanu>there must be some code for that written for guixSD
<manumanumanu>i'll look into it
<ennoausberlin>Well, I discovered mcrom while using GuixSD :)
<manumanumanu>ennoausberlin: I have the solution for you :D
<manumanumanu>You can manually run the process using (@@ (ice-9 popen) open-process) and then wait the amount of time
<manumanumanu>and kill if it hasn't finished
<manumanumanu>It is non-trivial though
<manumanumanu>and will include threads and shit
<manumanumanu>or would it? no
<manumanumanu>yeah, it is trivial. You need to (define open-process (@@ (ice-9 popen) open-process))
<manumanumanu>run the process using (open-process OPEN_BOTH "name" "args") That will return pid, read-pipe and write-pipe
<manumanumanu>wait the desired length, and then check if the program is still running
<manumanumanu>(when the program closes, the output port will be closed)
<manumanumanu>otherwise use kill on the pid
<manumanumanu>The downside is that the command will always take TIMEOUT
<manumanumanu>but since it's cron, that might be ok
<ennoausberlin>I have to check the manual for @@ syntax. Dont know what it is yet, but I will try it out
<manumanumanu>@@ means accessing un-exported library definitions
<manumanumanu>popen for some reason doesn't export open-process (which is the most sensible way to talk to linux processes)
<manumanumanu>(@@ (ice-9 popen) open-process) means the open-process function in (ice-9 popen) regardless of whether it is expported by the module or not
<ennoausberlin>I use (status:exit-val (system (... at the moment but I read a little about popen before
<ennoausberlin>Thank you for the pointer. There is even a linux timeout command but somehow it does not work inside mcron. I tried that before.
<manumanumanu>but open-process has nothing to do with open-pipe. it simply returns 3 arguments: an output port, an input port and a PID
<manumanumanu>ennoausberlin: remember open-process. That is the best way to do things
<ennoausberlin>I'll do. You are of great help
<rlb>wingo: looks like I may have found the build hang too -- I just ran "make -j 5 check" here in a loop, and it eventually blocked on sandbox.test with the cpu pegged. Think it's ok to mark that one as unresolved too for now? (I may investigate both issues later, but in the short term, if it's not a significant risk, that might allow us to get 2.2 back in to debian testing.)
<rlb>wingo: and I'll plan to file bugs for both cases (the test-out-of-memory and sandbox.test sporadic failures).
<rlb>...also, if the log was completely flushed, looks like sandbox.test hung on the "1e6 alloc loop" test.