IRC channel logs

2020-04-01.log

back to list of logs

<alextee[m]>so i was thinking to write a snarfer that reads doxygen docs and gathers C functions and auto-generates the "glue code" in C for exposing them into guile, and also the glue code for the structs that are used. it shouldn't be TOO hard to do for my project because my sources all follow specific patterns. Before I start working on such a thing, is there something like this already available somewhere? i believe i would need
<alextee[m]>something like a C analyzer to extract the info, and then after that it's mostly a piece of cake to generate the glue code
<alextee[m]>also, im curious, let's say i have a C function that takes in a GTK widget (in C). if i use guile to create a gtk widget and pass that to my c function, will it work?
<jackhill>alextee[m]: as far as automatic bindgin generation goes, perhaps https://www.nongnu.org/nyacc/nyacc-fh-ug.html is informative.
<jackhill>I know there are others here who know more about GTK :)
<alextee[m]>jackhill: thanks! oh i had this bookmarked
<hugo>Is there any way to get hygienic macros to leak the environment from where they are called?
<hugo>I want to use (current-module) to find where a macro was used
<mwette>hugo: try object properties; see make-object-property in the ref guide. You could add (current-module) to some object you create in that macro.
<chrislck>small question about guile's VM: does it inherently use multithreading to work?
<hugo>mwette: Do you mean something along the lines of (with-syntax ((mod ...)) (set! (calling-module mod) (current-module)) #'mod)
<mwette>hugo: hmm. Somehow you need to have a global or per-module object-property; call it foo. Then say your macro defines a expression `expr'. Your macro would do (let ((expr (...))) (set! (foo expr) (current-module)) expr).
<mwette>you may need to replace foo with (@ (my debug module) foo)
<mwette>but you have take care where (current-module) is evaluated. You might need eval-when
<hugo>mwette: I tried (let ((x #f)) (set! ((@@ (util config) curmod) x) (eval-when '(compile)
<hugo> (current-module)))
<hugo> x
<hugo> ), but with the error "invalid situation in subform ..."
<hugo>I might just settle with a carefully written define-macro. I hoped for an easy `with-leak', or similar
*mwette is out for a bit
<daviid>hello guilers
<daviid>english quiz: in a debian page somewhere i read "For reasons that weasel no longer is sure actually still apply nowadays .." and wish to understand what weasel refers to in this s/w and/or sysadmin context? I know the animal, called a furet in french ..
<terpri_>daviid, a person named weasel :) probably Peter Palfrader <weasel@debian.org>
<daviid>terpri_: ah ok, i thought it might be a 'wizard' sort of word ... tx
<daviid>or fictional character ...
<daviid>with, in this context, a double meaning ... tx
***rekado_ is now known as rekado
<rlb>with open-pipe* how do you control the port encodings for the open-pipe* ports?
<rlb>i.e. the child out, err, and in?
<daviid>str1ngs: np! glad you found where this 'lack of proper' (oop goops), (g-golf) #:duplicate config was 'hidding itself' ... such proper config is _mandatory_ for any G-Golf use/lib/æpp (it is, I think, described in the manual, but if you think it is not clear or well described enough, let me know ...)
<rlb>And is there a straightforward way to safely specify the environment for an open-pipe* subprocess when it differs?
***apteryx_ is now known as apteryx
<guix-vits>Hi there.
<str1ngs>daviid`: my understanding is much better now. unfortunately I rarely use the main script it tiny part the program. all is working nicely now.
***apteryx is now known as Guest44796
***apteryx_ is now known as apteryx
<spk121>rlb: open-pipe remaps stdin/stdout for its subprocesses. You can set the encoding explicitly for stdin/stdout in those subprocesses with set-port-encoding!
<rlb>spk121: not sure I follow -- I was wondering how to tell guile to set the port encoding for the bytes I'm getting back from the subprocess fd to say utf-8 and the encoding for the strings I'm writing to the pipe fd as latin-1. i.e. if I say (display "whatever" pipe) I'd like guile to encode that via latin-1 when guile writes it to the underlying fd, and I'd like for it to interpret the bytes coming back from the pipe as utf-8 (as
<rlb>examples).
<spk121>rlb: wouldn't that just then be (set-port-encoding! (current-input-port) "iso-8859-1")
<spk121>and then something similar for the subprocess?
<rlb>Maybe I'm just confused, but open-pipe* returns a bidirectional port, and so I'd need to be able to set an input and output encoding for it?
***sneek_ is now known as sneek
<spk121>rlb: so you've set a pipe to receive info from a subprocess, so your pipe is either OPEN_READ or OPEN_BOTH. If your subprocess is sending you back latin-1, you can set the encoding of the current-input-port to latin-1 so when you read, it works
<rlb>And when I write and want my string to be encoded as utf-8?
<rlb>Oh, hmm.
<spk121>(set-port-encoding! (current-output-port) "utf-8")
<rlb>I'm really not following. I've called open-pipe! and now I have a bidirectional port. What does that have to do with current-output-port and current-input port?
<rlb>s/open-pipe!/open-pipe*/
<spk121>lemme make an example, gimme a sec
<rlb>wrt your initial comment, I don't have control over the subprocess.
<rlb>i.e. if you're suggesting that the subprocess is a guile program too where I can change the encodings on *its* current-input/output-port, that's not the situation I'm wondering about.
<spk121>so your subprocess has a given locale, right? and that subprocess expects its input and output to be in that locale?
<rlb>No, let's assume that the subprocess might have different encodings for it's input and its output, and that it might even change them while its running in ways we can predict.
<rlb>s/it's/its/
<rlb>i.e. it's not sufficient to just set a single locale anywhere
<rlb>And the input and output we send to and receive from the subprocess might need to vary wrt encoding in either direction.
<spk121>so in that case, it is correct to say that your subprocess has no locale whatsoever, but, it instead sending out 8-bit clean data
<spk121>since if it changes locale at random, it can't be said to have a locale, really
<rlb>But even in the simpler case, the subprocess itself doesn't have a locale, but it's ports do.
<rlb>(or rather say they have a fixed encoding)
<rlb>More generally, the locale isn't relevant -- it's just the encoding.
<rlb>Basically, I was wondering if as it stands maybe guile just doesn't treat the input and output encoding of a bidirectional port separately?
<rlb>(that was my original question I suppose)
<rlb>e.g. in the java world, the encoding is "per direction" because you can wrap any binary port (input or output) with a "decoder" for a given encoding, so you can wrap the input port with utf-8 and the output port with utf-32.
<rlb>(as an example)
<spk121>in your specific case, are you opening a bidirectional pipe to a subprocess, or a read-only pipe
<rlb>And I was trying to figure out if guile had some way to do that for the "halves" of the pipe port, or maybe it just can't do that right now.
<rlb>bidirectiona
<rlb>"or if maybe"
<spk121>the docs say that for a bidirectional pipe, the subprocess's stdin and stdout will be inherited from guile (current-input-port) and (current-output-port)
<spk121>and you can set the encoding on the guile side of the current input and current output port independently using set-port-encoding!
<spk121>so if you wanted to write to a process that expected CP437 and returned UTF32 you'd set the encoding of current-input and current-output respectively before reading and writing to the subprocess
<spk121>gimme a sec
<rlb>Hmm, I suspect it'll inherit the underlying fds, but not the encoders since it's not a guile program
<rlb>And even a guile subprogram would "start over" when it execed, i.e. don't think it'd have the encoders/decoders either.
<spk121>OK. I guess I don't understand how your case could exist. But as a failsafe, if you set the encoding on your pipe to iso-8859-1, you can treat everything as 8-bit clean
<rlb>Perhaps a program that expects binary data on stdin, but reports status as utf-8 on stdout, for example. But right, I can just set the pipe to iso-8859-1 or similar, as you say, and handle everything manually, just wondered if there was a built-in way.
<rlb>In any case, thanks for the help.
<wingo>o/
<chrislck>anyone is intimately familiar with SWIG<->guile? after (let ((results (call-C-function))) (process results)), if results is a newly-allocated object, does SWIG reliably call the %typemap(newfree) when result is out of scope?
<dsmith-work>Wednesday Greetings, Guilers
<mwette>Same!
<dsmith-work>wingo: So what's with guile 3 jit on arm?
<dsmith-work>I haven't been paying close attention.
<dsmith-work>32bit arm
<dsmith-work>Cross compiling with buildroot doesn't segfault with --enable-jit=no
<jcowan>daviid: Weaseling is escaping one's obligations (legal, professional, moral) by clever or devious means, and a weasel is someone who makes a habit of this.
<dsmith-work>wingo: Got any advice on debugging an "Illegal instruction" with jit enabled on arm?
<dsmith-work>chrislck: Has swig been keeping up with guile? I got the impression it had bitrotted long ago.
<wingo>dsmith-work: is it https://gitlab.com/wingo/lightening/-/issues/12 ?
<dsmith-work>wingo: Not at all sure. Currently just trying to get a handle on too many things at once. ;^}
<wingo>:)
<wingo>run with GUILE_JIT_THRESHOLD=-1 if you are not sure
<dsmith-work>IF I run guile with GUILE_JIT_LOG=4, Is "mcode" machine code?
<dsmith-work>As in
<dsmith-work>jit: mcode: 0x74edb080,+200
<dsmith-work>jit: created /tmp/perf-252.map
<dsmith-work>jit: entering mcode: 0x74edb080
<wingo>mcode is machine code, yes
<wingo>i assume you have hardfp?
<dsmith-work>And then should disassemble /r 0x74edb080,+200 in gdb show that code?
<wingo>yes
<dsmith-work>hardfp? Not sure. rpi3 BR2_ARM_EABIHF=y
*wingo nod
<dsmith-work>and BR2_ARM_FPU_NEON_VFPV4=y
<dsmith-work>So probably yes
<dsmith-work>So that disassembly looks wack to me. Not familar with arm, but it looks totally bogus.
<dsmith-work>sneek: paste?
<sneek>Someone once said paste is https://paste.debian.net
<dsmith-work>disassemble out https://paste.debian.net/1137872/
<dsmith-work>The => is at the
<dsmith-work>Thread 1 "guile" received signal SIGILL, Illegal instruction.
<dsmith-work>0x74edb130 in ?? ()
<dsmith-work>With GUILE_JIT_THRESHOLD=-1 guile seems happy
<wingo>perhaps the address needed to be tagged with 0x1
<wingo>i don't recall how this works on arm
<dsmith-work>Do those look like thunmb opcodes?
<dsmith-work>A whole lot of UNDEFINED in there.
<dsmith-work>Oooo
<dsmith-work>Looks better!
<dsmith-work>Thanks!
<dsmith-work>Here is the dis asm ored with 0x1: https://paste.debian.net/1137874/
<wingo>lightening only emits thumb
<dsmith-work>Ahh
<dsmith-work>So the failing instruction and the one before it:
<dsmith-work> 0x74edb12f: be 00 bkpt 0x0000
<dsmith-work> 0x74edb131: 4f bf ldr r7, [pc, #0] ; (0x74edb134)
<dsmith-work>Breakpoint ?
<dsmith-work>This is set to thumb mode: https://paste.debian.net/1137875/
<wingo>guile does emit breakpoints in some unreachable code (see invocations of jit_breakpoint)
<dsmith-work>Could that 0x0000 just be a filler to get the next location to a 4 byte boundary?
<dsmith-work>That next location (the "Illegal instruction) is the target of a branch. From 0x74edb09c
<dsmith-work>Well, I assume "blx 0x74edb130" is some kind of branch.
<dsmith-work>The stuff at 0x134, 0x13c, and 0x144 look like addresses that are loaded into the pc through r7
<dsmith-work>wingo: emit_veneer() in libguile/lightening/lightening/arm-cpu.c looks like the emitter for that "illegal instruction".
<dsmith-work>To my eyes, the generated code *looks* right.
<dsmith-work>btw: working fine on my 64bit arm device.
<dsmith-work>Ahh, that BLX changes to ARM.
<dsmith-work>Maybe that's the problem? Because it's branching to thumb code?