IRC channel logs


back to list of logs

<mwette>logger has died methinks
<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>hmm.. wait
<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>if i (mknod 'fifo #o600 n), what is n?
<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>s/it reading/reading/
<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>whatever inode is
<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>er, (mknod "/path/to/file" 'fifo #o600 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.
<cow_2001>oh, right
<cow_2001>you've just said it
<cow_2001>how does one go about writing a mkfifo?
<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)
<flatwhatson>cow_2001: git clone; cd guile; guix shell; ./configure && make -j8
<cow_2001>already cloned, so it's just a matter of guix shell
<cow_2001>mwette: owo
<cow_2001>flatwhatson: there's only confi.rpath
<cow_2001>jeez. of course there's an HACKING file
<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 ./ iirc
<BrokenClutch>daviid: IT WORKED, man, I'm so proud of myself
<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>yes, far befrore ..
<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 ...
<BrokenClutch>isn't this too much for g-golf? is cairo gnome stuff?
<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
<BrokenClutch>daviid: got 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
<mwette>I've been using ffi for guile cairo also, because years ago when I started doing this guile-cairo was not ported to 3.0. I generated from nyacc ffi-helper. Example:
<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>or something like that
<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
<dsmith>daviid: For another example, I humbly submit This is the sqlite (2 not 3) interface the bot uses.
<daviid>be right back ...
<mwette>if you want to see the generated ffi code for ffi/cairo.ffi it's here:
<daviid>mwette: tx will look at it yes
<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
<lloda>s/patch and i/patch i
<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>sneek: botsnack
<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.)
<dsmith>sneek: botsnack
<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.
<dsmith>And with autotool magick
<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>|| { rm guile-cairo.x; false; }
<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 calls GUILE_FLAGS), or calling pkgconf --cflags guile-3.0 'directly'
<lechner>on guix, libguile.h is in include/guile/3.0/
<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>(working from home mostly now)
<lechner>sorry, just trying to help
<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
<dsmith>As in not /usr/local ?
<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>or /opt-9 :)
<dsmith>Heh. /opt-9 is cute
<daviid>anywhere but the usual default $prefix location
<dsmith>I'll give it a go later
<daviid>then guile-cairo will configure but immediately fail to make, with the above messge ...
<daviid>now, the 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>if you don't have it already try this
<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 already calls AC_CONFIG_MACRO_DIR([m4])
<lloda>cairo-pointer->context expects a #<pointer ...> type
<lloda>should return a #<cairo-context>
<lloda>^ daviid
<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
<lloda>good luck
<daviid>lloda: tx - not sure why this fix does not work, would happen to know? i patched one line in guile-cairo/, line 51, it now is guile-snarf $(GUILE_SNARF_CFLAGS) $(GUILE_CFLAGS) $< > $@ \ [added the $(GUILE_CFLAGS)] but it still fails ...
<lloda>no idea
<lloda>it works in both my boxes without that
<daviid>hum, d', not found
<daviid>david@aicha:/opt3 19 $
<daviid>sorry wrong paste
<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 -
<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 ??
<lloda>hmm reinstall guile?!
<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