IRC channel logs


back to list of logs

<dsmith>sneek: seen taylan
<sneek>I think I remember taylan in #guile 6 hours ago, saying: there's an unresolved, trivial, 8 year-old bug about it :D.
<dsmith>sneek: botsnack
<dsmith>RhodiumToad: Do you of any decent cheap mips boxes that run netbsd? I ha{ve,d} a cobalt qube, but that doesn't seem to be viable any more.
<dsmith>RhodiumToad: (it's where sneek used to live)
<dsmith>Oh! Maybe it is still supported
*RhodiumToad has no experience of netbsd
*RhodiumToad also hasn't touched any mips systems for, oh, 25 years? more?
<dsmith>RhodiumToad: Ahh. Sorry about that. Thought we were talking about netbsd before. Maybe it was freebsd instead.
*RhodiumToad only does freebsd
*dsmith makes a mental note
<lampilelo>how would you debug a segfault on scm_flush_all_ports()? one port has NULL write_buf but how can this happen?
<wingo>i would imagine that is memory corruption, tho who knows
<wingo>use rr, set a hardware watchpoint on the addr of write_buf, and reverse-cont
<lampilelo>i'll do that, i have a feeling this is a pipe created by open-pipe from a thread
<lampilelo>something definitely amiss with that because sometimes it errors out inside close-pipe on waitpid, saying there's no child process (just throwing, not segfaulting in that case)
<wingo>lampilelo: i wonder if you might be hitting bug 10836...
<wingo>bc there is a guardian for pipes and also there is the global weak port table
<taylan>cat on keyboard? :D
<lampilelo>the cheat code for money was klapaucius, not 7gggguymn/"
<lampilelo>wingo: does rr need some special settings for guile?
<taylan>lampilelo: what is rr?
<lampilelo>dumb name btw, try to search for it
<lampilelo>i wanted to check if it's in my distro's repository and it yielded 231 results
<taylan>heh, I guess it might be good to give it a canonical name like "rr-debug" or "rr-dbg" or something in package databases and the like.
<liltechdude>Hello! It's possible to use non-english characters in guile-chickadee? (draw-text "Шла саша по шоссе и сосала сушку.\n\nА я нет." #v(140.0 240.0)) This is rendered to ? mark instead of normie characters. May be I something
<liltechdude>missing in info manual?
<lampilelo>does the font you're using support cyrillic? or maybe it's a locale problem, in that case check if setlocale(LC_ALL, "") fixes it
<lampilelo>note that i'm guessing here, i'm not that familiar with chickadee
<meo>hey chickadee is cool
<stis>Howdy guilers!
<taylan>heya :)
*wingo poking at webassembly compilation...
<opfez>on the guile homepage it says guile has compiler frontends for elisp, is this what is used in GuileEmacs?
<opfez>(or can i use it to write extensions/config in normal emacs?)
<lloda>I've pushed
<lloda>how is it with master/main wingo? are we dropping the old one?
<wingo>humm, i am thinking we should reset master back to v3.0.7, and continue with main
<wingo>eventually we can remove master but i don't want to cause ppl problems
<lloda>i think i prefer a quick break rather than having to keep both branches updated but just mo
<wingo>yeah i mean let's not update master any more
<wingo>like reset it back to v3.0.7 and then don't move it forward any more
<wingo>we could remove it of course, or replace the tree with checkout-main-plz.txt or something
<mwette>taylan: For undeclared data size issues I'm thinking of using bytevector-unwrap* to force the user to define a descriptor on a case-by-case basis based on provided offset. WDYT?
<justin_smith>rlb: yeah I worded that imprecisely, of course nil is treated as false, but the only "false" that is actually false is Boolean/FALSE and a freshly constructed one like (Boolean. "false") is treated as true
<justin_smith>ser=> (let [f (Boolean. "false")] (prn "equal to false?" (= false f) "false?" (false? f) "falsey?" (if f "not-falsey" "falsey")))
<justin_smith>"equal to false?" true "false?" false "falsey?" "not-falsey"
<dsmith-work>Tuesday Greetings, Guilers
<leoprikler>opfez: guile-emacs uses a known-good commit of guile, that has nothing to do with Guile 2.2 or Guile 3.0
<leoprikler>that said Guile Elisp is somewhat usable, albeit a bit lacking in certain aspects
<opfez>ah, so there's no way to use like `guile --language=elisp <src.scm>` for vanilla emacs?
***dongcarl7 is now known as dongcarl
<leoprikler>Depends on your Vanilla Emacs more or less.
<leoprikler>You obviously won't be able to use any of the buffer stuff, but even disregarding that, the runtime is somewhat limited.
<leoprikler>e.g. no setf, keywords are buggy, ..., there certainly is room for improvement
<opfez>i see. thanks for the explanation :)
<leoprikler>also (make-symbol ) does not work for macros, you have to use gensym.
<rlb>justin_smith: ahh, right -
<tohoyn>sneek: botsnack
<apteryx>interesting, raising an error in a forked process bubbles up to the parent process -- I didn't expect so, but it is a nice property.
<RhodiumToad>are you sure?
<apteryx>mmh. Not so much anymore, but I'll comment if I can straighten my understanding up :-)
<apteryx>I don't think that should be possible, so most probably I got confused by the output of the program
<taylan>hmm it would sure be great if someone reviewed all my patches :P
<apteryx>funny exception message on (getgr "does-not-exist") -> In procedure raise-exception: In procedure getgr: Success
<taylan>apteryx: that seems to be a common theme. I wonder what causes it. a similar error message can be seen while booting Guix, and this bug report mentions one too:
<taylan>apteryx: actually, I'd love to debug this. what's "getgr"?
<apteryx>it's part of guile proper
<taylan>oh, nice
<taylan>in this case it seems to be because Guile calls strerror on 0 due to a small bug: when getgrgid or getgrnam return NULL, Guile assumes errno will be set, even though NULL can also mean "entry not found" without an error having happened
<taylan>yay, another thing to patch :D
<apteryx>thanks for looking into it!
<apteryx>is there an easy way to connect a forked process stdout/stderr to the stdout/stderr of the parent process?
<RhodiumToad>that's the default?
<apteryx>eh, really? That's great. Then my child is exiting way earlier than I expected; and I can confirm that exceptions do *not* bubble up to the parent process.
<manumanumanu>apteryx: exceptions no. but stderr yes
<RhodiumToad>at the OS level, fork doesn't change any file descriptor, so all open files are still open, stdin/out/err point to the same place as before, etc.
<apteryx>then perhaps something weird in Shepherd, because in my forked process I don't see pk messages even if they're the first instruction run
<RhodiumToad>however, note that fork can be quite disruptive
<RhodiumToad>there are issues of buffering, threads, locking, etc. that can all cause havoc
<RhodiumToad>how are you forking it?
<RhodiumToad>so that's the OS level fork, with all the chaos that implies
<RhodiumToad>are you then doing an exec of some kind?
<apteryx>RhodiumToad: the start slot is set to this Guix G-Expression:
<RhodiumToad>so what's happening in between the primitive-fork and that?
<apteryx>I'm not sure I understand the question; the execution goes like: Shepherd starts, calling the corresponding procedure; does some cleanup, forks a first process, then forks again via primitive-fork and enters the child process to run the remaining instructions (that communications with the earlier process via dbus to finalize the setup)
<apteryx>that communicates*
<apteryx>currently I'm totally blind as to what happens in the child process created via the primitive-fork call (it strangely doesn't output anything).
<RhodiumToad>does the primitive-fork itself cause a warning message to be output?
<apteryx>this is the output I see from the corresponding test, which exercises the start/stop/restart actions of the service and checks for expected files:
<RhodiumToad>iirc, pk outputs to stdout not stderr, is it possible/likely that stdout has been redirected?
<apteryx>we should at least see the backtrace caused by '(error 'exit-fork-with-error)' then?
<RhodiumToad>maybe try (format (current-error-port) "some string")
<RhodiumToad>make sure to include a newline in the string
<apteryx>RhodiumToad: OK, I can see stderr :-)
<RhodiumToad>so possibly stdout has been redirected elsewhere, not too unusual
<soda__hobart>alright, so i'm flailing wildly trying to figure out how calling scm_init_guile changes some environment variables that have to do with C strings. I think it has something to do with whether the strings are null-terminated or not?
<soda__hobart>this is basically what I'm trying to do:
<soda__hobart>the input data for the program is produced by this procedure and sent over the local network:
<RhodiumToad>so nothing in the environment can affect whether strings are null-terminated or the result of strcmp()
<soda__hobart>ok that's good to know
<RhodiumToad>how do you know that msg->child->data is null-terminated? your code is incorrect if it is not
<RhodiumToad>i.e. how did you create that value?
<soda__hobart>like this: `(string->bytevector (string-append msg "\0")`
<soda__hobart>or, actually: `(string->bytevector (string-append msg "\0") "ascii")`
<soda__hobart>and i've tried "utf8" instead of ascii too
<soda__hobart>the string-append thing doesn't seem to do anything, though. it works as expected, like with strcmp and everything, if I literally type in (my-send-msg-func "quit\0") though
<RhodiumToad>no, I mean in the code that calls strcmp in your first paste
<soda__hobart>otherwise, the value I get after casting the void pointer to char* will be somehting like "quit3y"
<RhodiumToad>what stores the value in msg->child->data and how?
<soda__hobart>it's a void pointer
<soda__hobart>I would assume that it is not null-terminated unless I went in and added a null byte to the end, right?
<soda__hobart>the `msg` struct is initialized on the heap using malloc
<lampilelo>so how did the bytevector find it's way into this struct?
<RhodiumToad>soda__hobart: allocating msg doesn't allocate space for either msg->child or msg->child->data
<RhodiumToad>soda__hobart: so show us the code that stores those values
<soda__hobart>like this:
<soda__hobart>what's weird is that it works if I don't call scm_init_guile in my main loop
<RhodiumToad>it works by pure chance
<soda__hobart>I was wondering if that was the case
<RhodiumToad>if you ran it under valgrind or with memory sanitation you would likely see the error
<RhodiumToad>you're allocating and copying only "size" bytes of data, not adding any terminating null yourself
<RhodiumToad>if meta.size isn't expected to count the null terminator, as appears to be the case, this means that the subsequent use of strcmp on that pointer is forbidden
<RhodiumToad>you should probably be allocating meta.size+1 and adding a proper terminating 0 yourself
<soda__hobart>ah, ok. so the C code should be responsible for adding that terminator?
<RhodiumToad>that all depends on where this data is coming from and what the specification for that source is
<RhodiumToad>but in general yes
<soda__hobart>yeah, the data is coming from a client process, so I feel that it would make sense to to require the client to do all that validation, especially when there could be different flavors of clients.
<soda__hobart>i mean not require the client to do it
<lampilelo>malloc in c++, the dread...
<RhodiumToad>well, yes, leaving aside questions of c++ style
<soda__hobart>haha I make Bjarne cry
<lampilelo>it's like you just pasted c code into a c++ file
<dsmith-work>soda__hobart: Yeah, if your app data is using counted strings, you gotta NUL terminate them if you are going to call any stdlib string functions.
<soda__hobart>cool, yeah it is working now, thanks to everybody for the help!