IRC channel logs
2020-02-09.log
back to list of logs
<rlb>Any suggestions for the fastest way to track that down? As you can see it appears to be failing when trying to build guile-procedures.texi, but assuming guild runs guile itself, I'd guess it's a more general guile issue. <rlb>(And this seems vaguely familiar...) <rlb>Apparently not there it doesn't, though :) <rlb>I'm trying a "plain" upstream build now (see if it might be any of the debian mess I've made). <rlb>hmm, still fails -- gdb suggests it's a corrupt stack. <rlb>"previous frame identical to this frame" <dsmith>rlb: Yeah, I belive building guile-procedures.texi is the very first time the freshly build guile runs anything. <oni-on-ion>i hope someday for guile-emacs . exwm is real nice. <drakonis>i think it extends to the whole compiler tower, not just guile lang <drakonis>guile studio could see a lot of improvement <davidl>is there a way to make functions in pip packages available to guile, or to at least wrap them in a python module and then use python-on-guile to have them accessible? The problem is I can't write a pycodetoguile.scm which has a import mypippackage statement in it and use anything from that package. <davidl>pycodetoguile.py* file and then mypycode.scm with (load-compiled "pycodetoguile.go") <janneke>hmm, how do i get comments in markdown for haunt? <janneke>the interwebs have all types of ideas and that don't seem to work <dustyweb>janneke: hm you'd need a separate service <janneke>dustyweb: tnx, i put comments out-of-band -- terrible :-( <dustyweb>janneke: comments are often a headache to manage these days due to spam :\ <janneke>dustyweb: oh, no -- i mean just like % in latex -- static writer's comments <dustyweb>some markdown parsers use <!-- --> which is ugly <janneke>it seems there are all kinds of nice dialects for that <janneke>yeah -- i have tried to avoid markdown, but this helps to really hate it :-/ <janneke>dustyweb: ah, that sounds nice -- i'll check it out! <roptat>is there an equivalent of call-with-output-file that appends to the file? <jcowan>roptat: You can use open-output-file with the nonstandard file-options symbol append, and then use call-with-port. <stis>utf8? the ascii chars are the same for utf8 and ascii <bricewge>How can I get the number of arguments a procedure is expecting? <bricewge>stis: Thanks! But why can't I find it in the manual? Where should I look for such a things? <oni-on-ion>how do i rebuild "info" pages? guile is not showing up, but everything is in /usr/local/share/info <bricewge>stis: Yes I skimmed through it, before asking, but didn't thought much of it because it was for programs instead of procedures. <stis>the program structure is whats make a procedure work <stis>(use-modules (system vm program)) <stis>scheme@(guile-user)> (program? +) <oni-on-ion>curious - where does the term "ice-9" come from? <oni-on-ion>ohh, interesting! thanks =) my search ended up with 'ice 9' song by some guitar dude *RhodiumToad still curious about the next-method problem. <stis>what do you think about bug#39315 <stis>I can code around it but it's a bit uggly <daviid>RhodiumToad: you can call next-method without arg or with an instance and a list of initargs <stis>also it wold be nice to discuss gc properies of continuations (I think the stored stack may lead to possible gc leaks as things are stored untagged) <daviid>for example, (next-method), (next-method self #:port port) or (next-method self '()) *RhodiumToad goes off to try <wingo>stis: better to code around it imo, is the short answer. i will try to make a long answer on the list <stis>Then we need to go through the guile sources as well to code around it as well. As it is now, variables exposed in the intefaces has no effect unless you are lucky and can use set-cdr <rlb>stis: sure for utf-8, but not for some other encodings. That's what I was trying to verify -- whether the existing reader code assumes some minimum ascii compatibility when it's reading, checking the raw bytes. Seems like it may, but wanted to double-check. <stis>I managed to code around it by simply redefineig the whole interfce of the module lol <rlb>wingo: any current sense about <applicable-struct> e.g. whether it's likely to stick around or not? <rlb>It'd be handy for some things I might want to do, but didn't know if it was reasonable to rely on it in at least the medium-term... <stis>see warning var in system/base/message <stis>I do hope that it will remain, use it for python (for guile) objects and classes <rlb>stis: you mean wrt <applicable-struct>? <stis>you call a python class to get a python object <rlb>Ahh, interesting -- ok, well that at least tells me I wouldn't be the only one :) <stis>rlb, my memory is weak but wasn't guile using utf-8 internally for strings <rlb>Think now it may be hybrid, but the bit I was mentioning (I think) may be at the level of reading raw bytes from a port, i.e. no locale/encoding/decoding involved yet. <stis>hmm, lot of legacy in the reader who knows you may have spotted a bug. <wingo>stis: yes using a mutable data structure (e.g. (make-variable ...)) is a good option