IRC channel logs
2023-03-03.log
back to list of logs
<mwette>nope: just saw Mar 3 page pop up <cow_2001>how do i wait on an (open-popen* OPEN_READ …) to close and only then read its port? <cow_2001>oh, alright. this port blocks until process is closed? <flatwhatson>cow_2001: what are you trying to do? you can't read from a process which has finished, but you can capture all its output into a string and read *that* after it's finished <cow_2001>flatwhatson: i'm trying to do the second thing, so everything's fine. <cow_2001>i was afraid of reading only partial output <flatwhatson>just (get-string-all port) should do, it will keep reading until EOF (ie. when the process ends) <cow_2001>but it reading the port would wait until process is kaput or it got what it wanted (as in the case of get-line) <cow_2001>get-string-all waits until it is kaput, that is <cow_2001>so what about that n in (mknod 'fifo #o600 n)? reference says it is the file it will read? is that an inode? <cow_2001>huh, `dict inode` says exactly what it is <flatwhatson>cow_2001: re: mknod, it should probably be (mknod "/path/to/file" 'fifo 0) <flatwhatson>i think the dev argument isn't relevant for fifo and should be 0 <flatwhatson>apparently we don't have mkfifo in guile, that would be a better option <cow_2001>from man 2 mknod: POSIX.1-2001 says: "The only portable use of mknod() is to create a FIFO-special file. If mode is not S_IFIFO or dev is not 0, the behavior of mknod() is unspecified." However, nowadays one should never use mknod() for this purpose; one should use mkfifo(3), a function especially defined for this purpose. <flatwhatson>add it to libguile/posix.c libguile/posix.h and doc/ref/posix.texi <mwette>or wrap some converters around foreign-library-function <flatwhatson>for the C approach, there might be some gnulib portability wrapper needed <cow_2001>hmm... anyone knows how do i get a clean development environment for guile using guix? i'm new to guix <cow_2001>(and i'm not really a C dev and so i should probably stop before i introduce one of those bugs you only see after it tears a huge security hole somewhere unexpected) <cow_2001>already cloned, so it's just a matter of guix shell <cow_2001>mwette: somehow it complains foreign-library-function doesn't exist <Keele>hello! I'm trying to learn g-golf. so far, it has been a blast! excellent technology. however, now I'm trying to get ListView to work and I'm stuck. It doesn't display anything. I rewrote an example I found written in C in guile and g-golf. are there known issues with ListView in g-golf? <mwette>cow_2001: it's in another module, then. Check the manual -- ah system foreign-library. Also, think about how to avoid exception on system which does not have that. <mwette>"that" being the mkfifo function <old>Is the author of guile-plotutils here? <jpoiret>cow_2001: from a git checkout you also need to use ./autogen.sh iirc <mirai>what's the difference between execl and system* ? <daviid>lloda: right, ... --prefix-... i didn't mean to imply that this the location where to search ... as you know, i know quite well (though not an expert) the autotool system - but i think not finding libguile.h is a bug in the guile-cairo autotool 'code' <BrokenClutch>daviid: I used my own cairo ffi module, guile-cairo doesn't seem to work with the pointer returned from gtk_snapshot_append_cairo, maybe because guile-cairo uses a goops <cairot> <jpoiret>mirai: the same difference as the usual libc one <jpoiret>execl replaces the currently running process, while system* starts one as a child process <lloda>daviid: ok, sorry about that. How are you pointing to your guile install then? Where do you think the bug is? <daviid>BrokenClutch: congrat - i published a template here yesterday, using guile-cairo ,,, maybe you've seen it (?) but i am glad you succeeded on your side - it shouldn't be difficult to make things so one can use guile-cairo, let's see - i just ned to find where guile-cairo defines its own type, i had a very quick look and couldn't find an obvious location in its tree, then asked here for help ... <lloda>re: the cairo-context obj, that's true, guile-cairo uses a smob to wrap the context, there'll be a type mismatch if you pass a raw pointer <BrokenClutch>daviid: I didn't saw, I did everything today when I woke up. But it was good, learned about gobjects and stuff like that. Thanks <BrokenClutch>lloda: yeah, if there was a (make <cairothing> ptr) it would be cool <BrokenClutch>guile ffi is so good that I'm not missing guile-cairo much <daviid>lloda: where are those smobs defined? there are just a few if i am not mistaken - then, we could add one (or a few) api to make a guile-cairo context, and then obtain its surface from it ... and maube a few other things, but if you could help me writing the make-cairo-from-cr proc, i'd be very happy :) <lloda>i think guile-cairo was written before there even was an ffi <daviid>and meanwile is partially introspectable, but the all situation is a bit of a mess <lloda>we could add a wrapper/unwrapper in scheme but those would be unsafe <lloda>it would be better if gtk and guile-cairo used the same scheme wrapper for the context <lloda>or maybe it's time to replace guile-cairo with a pure ffi wrapper and have gtk use that or something <daviid>lloda: hum, not sure i understand(agree) - my intention is to wrap the gtk cr pointer into a type that guile-cairo is happy with, but from a cairo lib pov, there are the same cr ofc - otherwise it would not work) <lloda>the smobs are in guile-cairo/guile-cairo-smob-types.c fwiw <lloda>yeah writing those wrappers is trivial, but ofc if you pass it the wrong pointer then bad things happen <daviid>yes, a pure ffi wrapper, but how long will it take to get 'there' ... if we have just one proc that builds a <Cairo-context>, then also let's us get the <cairo-surface> (querying cairo lib using its cr i guess), then we are good to go, then we can slowly think and implement a ffi based module ... <daviid>lloda: guile-gnome and guile-clutter does that to, but unfortunately, i can' t reuse their code because they use g-wrap :) <lloda>BrokenClutch: cairo is a standalone library <lloda>more or less, not gnome anyway <BrokenClutch>then why care about it? I'm being honest. Like, it would be cool, but I think that's a guile-cairo problem <BrokenClutch>but I'm not a programmer, neither a lib mantainer, so I'm probably wrong <lloda>well daviid wants to create a context on gtk and pass it to guile-cairo so <daviid>lloda: could you write this simplem first make-cairo-from-cr [or what ever better name that would be], then i can try a few things - there is no way to error about the cr, we receive it from gtk4 <daviid>BrokenClutch: yes, there a re seperate libs, and we should use guile-cairo, then enhance/re-write guile-cairo, but for now we should use it <lloda>i can do that, but it'll probably be faster if you send a patch tbh <daviid>lloda: wrt finding libguile.h, i think guile-cairo autotool should query 'itself' pkg-config, as the configure step reports it finds guile, it knows (should easily know) where the gule libs and include files are - a lambda user, as myself in this case, manually installing guile in a weird place, but configure finds it, shouldn't to have to do anything to configure/make guile-cairo <daviid>lloda: problm is i do not know libguile ... and nor do i know the current guile-cairo smobm objects defs ... but i'll lokat your code and learn/test/improve ... <lloda>actually the wrappers are already written in C, they're called scm_from_cairo and scm_to_cairo in guile-cairo-smob-types.c, i think all you have to do is make the symbols public so you can call them with the ffi <lloda>i can do this but i just cannot commit to when since it's of no use to me <lloda>re: the autotools issue, i don't see this issue myself, so you'll have to be more specific as to where the bug is <daviid>lloda: ok, i'll fix the libguile.h 'problem - let's focus a bit on this api we need to make a guile-cairo context... <daviid>lloda: couldn't you create a branch - then we play test ... till we are happy but i think 'in the end', those api should become public and part of guile-cairo <daviid>mwette: cool - how difficult would it be to schemefy the names? i'll try to find the time to look at this approach as well, but right now, i just wish to be able to call guile-cairo ... <lloda>i think you don't schemify the names but you provide an interface with scheme types on top of the raw ffi bindings <lloda>that interface could be the one guile-cairo provides, so it'd be like rebasing guile-cairo on top of the ffi bindings <daviid>lloda: when introspecting, we generate the 'good names' form the typelib, i see no reason not to do that 'immediately' from the headers ... but anyway, you could branch guile-cairo, and add one api, from-cairo seems to be 'your' favorite name', i'd be happy to try it, but it should be part of guile-cairo, so users do (from-cairo (append-cairo snapshot ...)) <daviid>lloda: i just don't know how to patch guile-cairo so scm_from_cairo 'becomes' available in scheme as from-cairo <daviid>wrt ffi-helper, ofc you have to have a low level api that binds the cairo symbols 'as is', but i wanted to ask mwette if the ffi-helper has an option to 'schemefying' the names ... <dsmith>daviid: It's pretty easy. That was the whole point of guile, making c<->scheme interfaces easy. <dsmith>daviid: Look at all the SCM_DEFINE_PUBLIC's in guile-cairo/guile-cairo.c <old>How can I correctly make a string that has utf-8 character such as ± <old>I get "\ufffd\ufffd" instead <mwette>the ffi-helper has a #renamer key but I have not tried it IIRC <daviid>dsmith: tx, i'll look at guile-cairo examples for now, and try to patch locxally <daviid>lloda: i didnj't understand this 'i can't push the commit ...' why would guile-cairo not accept an 'inoffensice patch' that mke it usable with gdk4/gsk4/gtk4, a patch that would actually use an already defined but unpublished api ... ? <daviid>dsmith: to make it public, should i patch guile-cairo/guile-cairo.c or guile-cairo/guile-cairo-smob-types.c ? <daviid>mwette: perfect, where is the code that one wuld call to generate, and what option needs to be changed to get scheme names? so not now, but asap i could try ... tx <daviid>mwette: nyacc/ffi-helper is very impressive! <lloda>daviid: i didn't say that. If you send a patch and i have no problem merging it, i just can't commit to making the patch for you <daviid>lloda: ah ok, sorry i missunderstood <daviid>lloda: should the SCM_DEFINE_PUBLIC from-cairo be in guile-cairo.c or in guile-cairo-vector-types.c? <daviid>see, not enough C and zero libguile exp ... gona take days for me to patch one line <daviid> guile-cairo.c doesn't seem to include guile-cairo-smob-types.h <daviid>i meant to write in guile-cairo-smob-types.c, not guile-cairo-vector-types ofc ... <dsmith>I haven't looked close enough. Probably best to use the SCM_DEFINE in the same file where the C dunc is defined. There does need to be an #include thisfile.x in the init func. And it is there. <dsmith>(just had a power glitch. Seems the bot is offline.) <sneek>I've been running for 38 seconds <sneek>This system has been up 1 minute <daviid>dsmith: i'll try tx - i actually need to fix the guile-cairo autotool config bug first <dsmith>Actually, guile-cairo is the project usually pointed to as an example of using smobs and wrapping a C library with the snafer machinery. <daviid>yes, but it misses te GUILE_CFLAGS, then the snafer fails to find libguile.h :) <dsmith>bitrot bitrot, how I detest thee <daviid>guile-snarf -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I. -Wall -Werror -I/usr/local/include/guile/3.0 -I/usr/local/include/guile/3.0 guile-cairo.c > guile-cairo.x \ <daviid>but in my config, pkgconf --cflags guile-3.0 => -I/usr/local/include/guile/3.0, as also defined in GUILE_CFLAGS, but guile-cair doesn't uses it5 ... <dsmith>And where exactly *is* libguile.h ? <daviid>that should always be asked to guile itself, either GUILE_CFLAGS <daviid>(when configure.ac calls GUILE_FLAGS), or calling pkgconf --cflags guile-3.0 'directly' <dsmith>I'l try and build it here after I get "home". <daviid>lechner: sure, the problkem isn't where the file is, the problem is guile-cairo doesn't include the installed guile location in its search path ... <dsmith>I was just curious the difference of where it *is*, and where the auto/config stuff thinks it is. <daviid>dsmith: to reproduce you first need to manually build and install guile in a unusual location <lechner>Hi, is it possible that Guile's SXML implementation decodes HTML titles differently when the <meta> tag with the charset appear after the <title> tag? <daviid>dsmith: right in your home dir for example <daviid>anywhere but the usual default $prefix location <daviid>then guile-cairo will configure but immediately fail to make, with the above messge ... <daviid>now, the configure.ac calls GUILE_FLAGS, so i should be able to just add it to the ./guile-cairo/Makefle.a, which i do <daviid>guile-snarf $(GUILE_SNARF_CFLAGS) $(GUILE_CFLAGS) $< > $@ \ ... but that still fails <dsmith>Anyone use github actions? And if so, is gcc in the ubuntu-whtever images? The docs only seem to list C++. <dsmith>I wonder if it's using a cached .m4 file instead of one guile installs? <dsmith>Been a while since I messed with auto*. And we never did get along. <lloda>i cannot test it bc i don't know what type you're getting from gtk <daviid>dsmith: i locally installed the latest guile.m4 file, and the configure.ac already calls AC_CONFIG_MACRO_DIR([m4]) <lloda>cairo-pointer->context expects a #<pointer ...> type <lloda>should return a #<cairo-context> <daviid>lloda: many thanks, i am trying to get guile-cairo to locally compile, still 'struggle', but will try tht as i solve the locl build <daviid>lloda: tx - not sure why this fix does not work, would happen to know? i patched one line in guile-cairo/Makefile.am, line 51, it now is guile-snarf $(GUILE_SNARF_CFLAGS) $(GUILE_CFLAGS) $< > $@ \ [added the $(GUILE_CFLAGS)] but it still fails ... <lloda>it works in both my boxes without that <daviid>it's seems there is a bug in the guile-3.0.pc file itself, i do not have any guile pkg installed 'by distro', and i recently compiled it, using --prefix=/opt3, but here is what the file content is like - https://paste.debian.net/1272876/ <daviid>terrible -theonly correct line is line 25 <daviid>what could possibly cause such a totally wrong content? <daviid>then ofc adding $(GUILE_CFLAGS) didn't solve, its content is wrong ?? <daviid>lloda: i m gona check the last build ctent in the tree <daviid>the local built file is completely wrong, a built from Jan 27, fresh clone, then cherry-picked and applied your wip-truncate patch <daviid>gona git clean -dxf and compile again <daviid>ok, now the file is correct - no idea what happened in my last build ... must have done something wrong, but what, i am curious <daviid>i lost a day because of this, but i am glad i found the 'culprit' ... need to wait it compiles .. back in 50' or so ... <daviid>lloda: in guile-cairo, i locally patched guile.m4, just copied the file from the latest guile, maybe you wna do that and push a 'fix' <daviid>so guile-cairo has the latest guile.m4, which fixes some nug(s) <daviid>ok, compiled, installed, pkgconf --cflags guile-3.0 => -I/opt3/include/guile/3.0 which is correct - and now of course guile-cairo builds fine! <daviid>i did patrch, let's test cairo-pointer->context now