IRC channel logs


back to list of logs

<chrislck>dsmith-work: SWIG-4 is out, no?
<dsmith-work>Hmm. Supports guile 2.0 anyway.
<mwette>swig-4 suggests running with --no-auto-compile
<mwette>I'm currently working on nyacc's ffi-helper now. Right now the typedef expander and constant expression compiler (e.g., enum { A = sizeof(foo_t) };). It currently only generate guile source. Would C wrapper code be useful?
<mwette>Last two sentences were about the ffi-helper itself.
<chrislck>maybe need to see how c+swig+guile generates assembly :(
<alextee[m]>mwette: i'd personally prefer having the C wrapper code, but not sure how useful it would be, i just like C :P
<alextee[m]>i'll try nyacc tomorrow, hopefully it works for my project
<alextee[m]>mwette: i read the whole guide btw, though i have a question. does the ffi-helper work for binaries?
<alextee[m]>or would i have to create a library as an intermediate step?
<roptat>is there a simple way to convert from hexadecimal to decimal in guile?
<dsmith-work>roptat: number->string I think.
<dsmith-work>scheme@(guile-user)> (number->string 255 16)
<dsmith-work>$1 = "ff"
<roptat>oh thanks!
<dsmith-work>Of course, you can also fire up the mighty (format)
<dsmith-work>Which is kind of like printf
<brendyyn>guix also has (guix base16) for turning it into a bytevector if needed, but it only works with hexadecimals padded to even numbers of digits
<roptat>nah it's fine, I wanted to do (string->number) anyway :)
<roptat>I didn't know you could add a base
<mwette>alextee[m]: not sure what you mean. The FH assumes you have a shared object library (e.g., and an associated header file (e.g., cairo.h).
<mwette>alextee[m]: I get it. You are writing C code and want to interface. You'll need to compile it and load via dynamic-link. So having C wrapper may be better. Making the FH compile to scheme or C means I need two back ends, so that would be a project.
<dsmith-work>wingo: regarding , yeah, that just might be it.
<dsmith-work>wingo: emit_veneer yep. That's the code that's failing.
<dsmith-work>sneek: later tell wingo Yep, is probably what I'm seeing.
<dsmith-work>sneek: botsnack
*sneek wags
<dsmith-work>So why isn't this failing for me on by beaglbone? Because it was native compiled?
<dsmith-work>I don't think this part of the lightening code changed between 3.0.0 and 3.0.2
<alextee[m]>mwette: ah I see, thanks. in that case it does sound more appropriate to have a C wrapper
<daviid>jcowan: tx - pleased to learn its 'secondary meaning' - I sort of thought that weasel (2dary meaning) meant 'good thing(s)', because the word, to my ears, sounds very beautifully - which how mistaken we can be when we just don't know ...
<daviid>*which show how ...
<sneek>wingo, you have 1 message!
<sneek>wingo, dsmith-work says: Yep, is probably what I'm seeing.
<mbakke>I'm trying to concatenate two sexps with (append ...), but need to add a single ')' in between due to pattern matching shenanigans. Any ideas how? Creating a one-element list containing #\) just inserts the #\).
<RhodiumToad>what exactly do the input and desired output look like?
<civodul>mbakke: an sexp is necessarily well-balanced
<civodul>do you have an example?
***rekado_ is now known as rekado
*rekado looks at guile-for-guile-emacs
*civodul .oO( do we have guile-studio-for-guile-for-guile-emacs? )
*rekado tries to find the latest version of the code
<rekado>there’s git://, and then there is wip-elisp and wip-bpt-elisp in the official repository
<rekado>looks like wip-elisp in the official Guile repo is the correct one.
<civodul>it's even more of a maze than the Hurd repos, no? ;-)
<rekado>hah, close call!
<mwette>I think he wants (a b c) + (d e f) => (a b c (d e f))
<mbakke>civodul: the problem is that the first sexp is produced by pattern matching another sexp, and the opening token is stripped off. The result is then spliced into another sexp that has the desired opening...
<mbakke>there is an extremely contrived example here that depends on some Guix internals:
<mbakke>I guess I need include the outer parens in the initial match pattern and strip off the unwanted parts later
*rekado doesn’t understand the diff
<mbakke>rekado: the intention is to inherit a (modify-phases body), but strip out a single phase.
<mbakke>it's further complicated because the modify-phases body we inherit are already using substitute-keyword-arguments, and thus contains multiple (modify-phases ...) layers.
<mbakke>"original" in the diff are the phases from Python 2, while "added" are the phases from Python 3.
<civodul>mbakke: perhaps i'm missing something, but i think it doesn't have to be this complicated
<rekado>modify-phases is a macro that returns … an alist of symbols to procedures(?). Can you work on the expanded code?
<rekado>oh, no, you can’t.
<civodul>in python-boot0, just do `(modify-phases ,phases (delete 'phase-that-patches) ...)
<civodul>does that make sense?
<mbakke>civodul: that's the obvious solution, but it runs at "build time" and thus produces a different derivation.
<mbakke>i.e. the build script will be (modify-phases all-the-phases-including-that-we-dont-want (delete 'that-unwanted-phase).
<civodul>ah oh!
<civodul>i see
<rekado>I hope that getting started with Guile’s elisp implementation is the hardest part.
<rekado>so far I don’t know how to load an elisp file yet, because “load” is undefined in (elisp-functions)
<mwette>sorry, got nerdsniped: I reformatted the + from the diff and added one simplification in
<mwette>the lower form uses match to root out the apply-alignment-patch forms
<mwette>and do you want that form to return result rather than '() ?
<dsmith-work>UGT Greetings, Guilers
<mbakke>mwette: thanks for the improvement, I'm about to try a hopefully simpler approach from a suggestion over at #guix :-)
<guix-vits>Hi there.
*guix-vits afk
<guix-vits>Can someone, please, point me to readings about how to: "scheme@(guile-user)> " ---> "io-ho-ho@(guser)> "?
<rekado>guix-vits: ,option prompt "io-ho-ho@(guser)> "
<guix-vits>thanks, rekado.
<rekado>it won’t change the module name, though, as you enter other modules
<rekado>it’s just a string
<rekado>you can do this, though: ,option prompt (lambda () (format #f "io-ho-ho@~a> " (module-name (current-module))))
<guix-vits>wow. thanks rekado.
<wingo>civodul: do you have a reproducer for that guix graft bug
<manumanumanu>RhodiumToad: I wrote oleg and told him about the error, so let's see if he's feeling nice.
<manumanumanu>BTW: I have been thinking about implementing better string searching for guile. I have had some luck with srfi-135's boyer-moore-horspool algorithm (being faster than the C-based naive search in guile for long strings). Are there any libraries for guile for string searhcing?
<lfam>It would be great to have a boyers-moore implementation in Guile. There is actually an implementation in Guix but it's limited to one part of the code and not avaiable for use throughout Guix
<jcowan>What about the license?
<jcowan>(all SRFIs are MIT, unless you reimplement from scratch, which is possible of course)
<manumanumanu>jcowan: I haven't released anything yet, and if I do and MIT is not the license I chose, MIT is sublicenseable (iirc?)
<jcowan>Yes, it is. That's unusual now.
<jcowan>(MIT says it does not grant a patent license, but several IP lawyers have opined that the use of patent-grant verbs like "use" and "sublicense" implicitly does so.)
<lfam>The Guix implementaiton is in here:
<lfam>Specifically in the replace-store-references procedure
<manumanumanu>I just like to have it as a baseline. The implementation from srfi-135 performs better than the KMP one from srfi-13 under guile, and I managed to tweak it some more. That makes it a good baseline
<manumanumanu>Found a max-shift boyer moore paper that seemed simple enough, with pretty astonishing claims of performance improvement over regular boyer-moore and also over the BMH algorithm.
<manumanumanu>"astonishing" was maybe the wrong word: "an incremental speed improvement almost across the board" would be more suiting. I don't know how they crafted the needles though.
<civodul>hey wingo!
<civodul>my own reproducer no longer reproduced the bug
<civodul>but there's a new bug report
<civodul>lemme see
<civodul>this bug was for the short window during which we used Guile 3.0.2 for grafting
<civodul>so i suppose one could try: guix pull --commit=735a8d997a92518d7d19926e1c8a1e385a98fdce && guix build java-jwt
<civodul>i'll see if i can reproduce it in a simpler context
<str1ngs>sneek later tell daviid. can you confirm for me that changing the test 'test-g-value-get-pointer to use /dev/null is okay. guix build environement does not have /dev/tty. I'm pretty confident /dev/null is okay WDYT? I can substitute this so no need to change it.
<alextee[m]>guild: unknown script "compile-ffi"
<alextee[m]>do i need guile 3?
<civodul>i think "compile-ffi" is part of nyacc, no?
<alextee[m]>i would think so, but this page executes `guild`
<alextee[m]>i thought guild was something shipped with guile, but maybe it allows you to extend it, idk
<civodul>"guix environment --ad-hoc guile@2 nyacc -- guild compile-ffi --help" does the trick
<civodul>right, nyacc extends the "guild" command here
<alextee[m]>ah i see, i just installed nyacc and now the command is there
<alextee[m]>thanks :)
*spk121 is finally writing a GTK3 program in Guile for real
<str1ngs>spk121: I added vte aka terminal-mode to nomad :)
<str1ngs>nomad is about 97% scheme now.
<spk121>str1ngs: sweet. I've seen all the talk about the tech details of nomad, but, what is the "elevator pitch"
<spk121>(Is "elevator pitch" a phrase people know, or is it a California thing?)
<str1ngs>spk121: nomad is an extensible web browser using guile scheme. think emacs for the web. though it's becoming more like emacs.
<spk121>str1ngs: neat!
<alextee[m]>i'm trying to follow the nyacc example and i'm getting this when i compile the ffi file with nyacc: ERROR: In procedure dynamic-link:
<alextee[m]>In procedure dynamic-link: file: "libcairo", message: "file not found"
<str1ngs>most the of the heaving lifting is done by emacsy. keybinds, buffers, windows echo-area and modeline. you get the idea.
<str1ngs>alextee[m]: you are using guix?
<alextee[m]>str1ngs: yep
<str1ngs>also I assume this is guile-cairo?
<str1ngs>alextee[m]: do you install guile-cairo manually?
<alextee[m]>no just this (define-ffi-module (ffi cairo)
<alextee[m]> #:pkg-config "cairo"
<alextee[m]> #:include '("cairo.h" "cairo-pdf.h" "cairo-svg.h"))
<alextee[m]>why would i need guile-cairo? i thought the point of this was to run the c library directly from scheme
<str1ngs>oh this is when using nyacc?
<str1ngs>either way because you are on guix you need to substitute the full path of the library
<alextee[m]>it seems to write the .scm file successfully but fails during compilation
<spk121>alextee[m]: you don't need for what you are trying to do. It is just that a couple of days ago there was talk of the guile-cairo project
<str1ngs>IMHO as spk121 is saying its best to just use guile-cairo. since this work as been done already.
<alextee[m]>str1ngs: are you sure? i would imagine since im passing a pkg-config name it would know the paths
<spk121>Nah, man. Do whatever makes you energized.
<alextee[m]>str1ngs: im trying to see how this works so i can generate a scheme library for my project also, just trying to follow the example for now :-)
<catonano>Hi 😁️
<catonano>I mean
<catonano>Hi, hexteex:
<civodul>alextee[m]: unless your goal is to play with nyacc's FFI support, you should really consider using Guile-Cairo
<alextee[m]>i have no need for guile-cairo, i want the ffi support though to generate scheme code for my C code
<str1ngs>alextee[m]: dynamic-link works like glibc . it searches assumed paths. should not have much to do with pkg-config. you can set LD_LIBRARY_PATH though. but for guix that's not recommended. though I have not used nyacc myself.
<str1ngs>alextee[m]: what's the point of generating scheme code to use in C code. in such case you can use C directly
<str1ngs>and why generate scheme code, when a scheme binding exists. see what we are saying here?
<alextee[m]>str1ngs: let me show you what im trying to do
<spk121>nyacc is the bomb. I wish I had some reason to write a new language so I could do something with it.
*alextee[m] uploaded an image: Screenshot from 2020-04-02 21-56-10.png (161KB) < >
<alextee[m]>this is zrythm, a software for making music, and i want to expose a scripting interface in that window where you execute script commands, for example to generate some midi notes
<str1ngs>right gotcah
<str1ngs>looks cool btw :)
<alextee[m]>thanks! cooler with scheme :D
<str1ngs>alextee[m]: I'm assuming this is written mostly in C?
<alextee[m]>str1ngs: 100% C
<alextee[m]>nice, i managed to compile the ffi example now
<alextee[m]>str1ngs: i was planning to do everything manually like so:
<alextee[m]>until someone mentioned the ffi thing
<alextee[m]>i mean, i don't really have to expose everything, just the relevant/useful things
<str1ngs>alextee[m]: right for cairo just have C do the cairo bits. and expose the SCM_DEFINES
<str1ngs>alextee[m]: unless you want to auto generate your scheme from you C?
<alextee[m]>with nyacc's ffi?
<alextee[m]>i don't know. what would be better? i personally like doing it manually because i have full control over the docs and what to expose and whatnot, but the ffi generator would save me time
<alextee[m]>it looks like you can filter what to generate with the ffi helper so that could do it
<str1ngs>SCM_DEFINES with snarfing is pretty good. but personally I would use guile extention. since you can then use the code from a REPL etc.
<str1ngs>for nomad I use a custom type lib. so that things like guile-gi and g-golf can use the functions via scheme. GI does the exposing.
<str1ngs>alextee[m]: see all these are exposed to scheme. eg. nomad_spawn_terminal is now 'nomad-spawn-terminal
<str1ngs>those it hard to pass SCM types this way.
<alextee[m]>str1ngs: where exactly are you exposing them? for example nomad_app_run_javascript ()
<str1ngs>alextee[m]: before this though I wrote nomad as a guile extention. which might work well for you use case.
<str1ngs>alextee[m]: it's exposed to scheme. well anything that has GI bindings. would work in python as well
<alextee[m]>oh you're using g object introspection
<alextee[m]>and guile-gi converts that to guile somehow?
<str1ngs>that's correct. what GUI tookit are you using?
<str1ngs>it does not convert. GI tells guile how to FFI the library.
<alextee[m]>i use gtk+3, but i don't really plan to expose any UI related things, and i don't use gobject's for anything, just plain old C structs
<str1ngs>in that case I would write libzrythm as a guile extention
<alextee[m]>i see. not really sure i'm understanding what a guile extension is though
<str1ngs>and just manually use SCM_DEFINE. if you need to use cairo just wrap it in an expose SCM_DEFINE using C
<spk121>alextee[m]: there's more than one way to do a thing. i've done Gtk+3 C applications with Guile script bits before. It works fine.
<alextee[m]>so i guess i'll just continue SCM_DEFINE'ing things little by little
<str1ngs>alextee[m]: btw you can also use SCM_DEFINE_PUBLIC
<alextee[m]>i already have the execution of the script working. when you click the execute button it executes it and prints the output in a label there
<alextee[m]>btw, i also want to print the guile errors, is that possible?
<str1ngs>alextee[m]: also I would snarf so you don't manually have to maintain.
<alextee[m]>str1ngs: yeah i am already generating the .x files, even snarfing docs. i had some problems when including the x files though that i haven't figured out yet
<str1ngs>alextee[m]: here on the master branch of nomad I use a guile extention with snarfing. maybe this can help you. see
<alextee[m]>i can't find SCM_DEFINE_PUBLIC in the guile docs str1ngs
<str1ngs>alextee[m]: this model is more like what you are using now. before I switched to GI
<alextee[m]>nice, thanks!
<str1ngs>alextee[m]: I also used modules in C. but that might be overkill for you
<alextee[m]>yes it would. this is nice example code though, thanks!
<str1ngs>no problem. I find GI easier to use now. but for your current model this should work for you.
<str1ngs>you might need to translate to meson of course.
<alextee[m]>using GI means you have to convert your structs into GObject's right?
<alextee[m]>i'm concerned about bloat and loss of performance if i use it on audio-related structs, so i went with plain C structs, but i'll investigate that too
<str1ngs>alextee[m] potentially yes, mostyly you would just BOX your type as private GObject. for me I'm using GTK classes etc anyways. does not matter. my core types are already scheme.
<ThomasAlbers>one question, could anyone help me with POSIX pipes?
<spk121>ThomasAlbers: ask away. maybe someone will know
<str1ngs>alextee[m]: I would use scm_from_pointer to move your types from C to scheme anyways. and then scm_from_pointer to get it back in C
<ThomasAlbers>i'm trying to use dmenu from guile, but i don't know how to separate stdin from stdout
<ThomasAlbers>i need to send a end of file through stdin keeping stdout accesible
<alextee[m]>str1ngs: i'm not really sure what the difference between that and a foreign object is, even after reading the docs :-) foreign object seemed to work best in the things i tried
<str1ngs>alextee[m]: I think I had those reversed. you get the idea though
<str1ngs>alextee[m]: I have not use foreign objects. maybe I should lol
<alextee[m]>i'm looking at text.c, maybe it's easier to use pointers. with foreign objects for some reason you need to encapsulate the pointer in a list of size 1, which didn't make much sense to me. i'll give pointers a try
<str1ngs>alextee[m]: I think most of this code is okay. when I first started writing this I had not use guile befoer.
<str1ngs>alextee[m]: but I think this is very close to your current model.
<alextee[m]>yeah it looks like it's similar
<jcowan>ThomasAlbers: "Sending an end of file" means "closing the output side of the pipe".
<ThomasAlbers>if i understand it correctly
<jcowan>You do.
<ThomasAlbers>what i'm trying to archieve is something like var=$(echo foo | cat) in bash
<ThomasAlbers>where foo is a scheme string
<jcowan>Okay, so when echo terminates it closes its stdout, cat sees that as EOF, and bash reads the stdout of cat and inserts it into the command line
<ThomasAlbers>and by using (open-pipe* OPEN_WRITE) i can get the first part to work, but i don't know how to get the program's output
<ThomasAlbers>I thought it would be as easy as using "with-output-to-string" or someting similar
<ThomasAlbers>because the documentation says the process has the same "current-output-port"
<jcowan>You want to call it with OPEN_READ, because you are going to read from the pipe
<jcowan>what that returns is an ordinary input port to which you can apply read-char or read-string or read or whatever you want.
<ThomasAlbers>but then i dont have how to give it the input
<jcowan>the names READ and WRITE are from the perspective of the parent.
<ThomasAlbers>but if i use OPEN_READ can pipe input into "cat" without using a shell (open-pipe)
<alextee[m]>before I run my procedure in C, i do scm_set_current_output_port() and scm_set_current_error_port(), then run the procedure, and afterwards do scm_get_output_string() on the ports followed by scm_to_locale_string(). This seems to work for output produced by the procedure, but i also want to get guile's compilation output, like it prints in my terminal: "madvise failed: Invalid argument"
<alextee[m]>i want to display that to the user, so is there any way to receive such errors as C strings?