IRC channel logs
2025-11-06.log
back to list of logs
<old>I don't understand why I get a warning when putting one of my match clause in a `or` clause <euouae>sneek tel later ekaitz I probably won't read the JS article because I don't use JS :P <euouae>sneek tell later ekaitz I probably won't read the JS article because I don't use JS :P <sneek>later, euouae says: ekaitz I probably won't read the JS article because I don't use JS :P <euouae>sneek later tell ekaitz I probably won't read the JS article because I don't use JS :P <Arsen>dsmith: I worked on coroutines and some bits of the standard library, as well as freestanding c++ <civodul>just saw your messages in the backlog <civodul>rlb: re weak hash tables: do not mix weak hash tables and guardians, as a rule of thumb <civodul>they both use finalizers under the hood, so chances are it won’t do what you expect <civodul>more generally, beware of finalizers :-) <euouae>The part that is automated like the bytestructs you spoke of -- except I wrote my own little macro <euouae>The library is complete now, I'm finishing up the docs and then I'll publish it and add some details in Guix on the ELF parser; though apteryx said he already dealt with the problem by using mmap. <civodul>euouae: that looks nice! the fields are nameless though, in ‘make-elf32-symbol’ etc.? <civodul>sorry to come up with more questions :-) <euouae>civodul: yes the record constructor is decoupled from the parser macro; endianness is taken care of <euouae>scheme-bytestructures is a bit fancier, it keeps the record constructor coupled with the byte spec <apteryx>euouae: nice! Yes, for Guix the mmap solution + (system vm elf) seems to be working OK in https://codeberg.org/guix/guix/pulls/3666 (I still need to add some final touch ups to the mmap bindings and remove the manual munmap calls, and also account for different flag values on the Hurd) <euouae>autotools cannot guarantee strictly greater timestamps (without sleep at least) and probably a lot of current autotools projects will break <civodul>euouae: yeah feel free to comment further on this patch <euouae>I don't see your comment, where is it? <euouae>civodul: thanks, it's nice. but you have to realize that ELF structures have different order of fields depending on the architecture <euouae>not all ELF structures, but some do <civodul>ah yes, not as simple as the cases i showed <civodul>Poke has a notion of conditional fields IIRC, but then it becomes gnarly <euouae>There is no reason to do any of that <civodul>a purely declarative approach is nice because it’s more readable, less error-prone, and easier to maintain <euouae>Obviously for any project I can continue coming up with r6rs-blahblah extra stuff to do. In fact for the ELF parser I briefly considered writing an AVL tree implementation in R6RS but then decided against it <euouae>I realized that O(n) memory temporarily is OK compared to O(nlogn) time O(1) memory + my sanity for writing an AVL tree impl in R6RS <civodul>the goal here is to parse ELF, not to define a new bytestructure-like language :-) <euouae>It's all tradeoffs and I have to protect my sanity :P <civodul>BTW, the linker and assembler in Guile hold entire ELF representations in memory <euouae>Hm. If we use my library we can avoid that! <euouae>I'll keep it in mind. I'm currently on a journey to fix some Guile bugs that occur at the VM level. I've been studying Tree-IL/CPS/VM bytecode but soon I'll have to peek into the actual source files too. <dpk>if i submit a patch that rewrites a C procedure in Scheme (for the purpose of removing an accidental continuation barrier, among other things) i assume i should keep the C interface in place by writing a wrapper that simply calls the new Scheme version? <euouae>dpk: unless you're aiming for a major bump (i.e. Guile 4) <euouae>because removing the C function will break code of users of libguile.h <dpk>right, that’s the point of my question :-) <euouae>I think adding C as wrapper is good because if in the future it is decided that "now is time to prune the C footprint" it should be easy to find those wrappers and remove them. <euouae>s/adding C/adding the C function/ <sneek>Welcome back ekaitz, you have 1 message! <sneek>ekaitz, euouae says: I probably won't read the JS article because I don't use JS :P <ArneBab>ekaitz: thank you for the article! It’s on my reading list :-) -- I consider Javascript at the same time as horrible and awesome: horrible for its number of footguns and awesome for managing to stay compatible and for working fast with the requirement to start right away from source code and switch to partially compiled performance ASAP. <ArneBab>ekaitz: that was a nice read. Thank you again! <bootchk>g-golf example helloWorld using gtk doesn't seem to work on Ubuntu25.04, Guile 3.0.10: oop/goops.scm:1585:2: No applicable method for #<<generic> run (5)> in call (run #<<gtk-application> 7f34ac321760> 0 ()) <sneek>bootchk, you have 4 messages! <sneek>bootchk, daviid says: wrt to your last sentence, you can't make C made GObject instances 'visible' to g-golf, because GLib/GObject is based on a dynamic type system: the GType that the C code refers to when making instances, will likely almost always be different then the GType of the same class in g-golf (except for the GObject class itself) - you can write a plugin if the scheme code creats and manipulates its own itstances ... <sneek>bootchk, daviid says: so what you've tried so far may (have) work(ed), but i that is likely 'out of luck' (so to speak) <sneek>bootchk, daviid says: this behing said, let me look at the GimpRunImageFunc definition and the GimpValueArray api ... assuming those who wrote these apis know what I just said, maybe there is a way to make this work ... Last, I am not familiar with the Gimp namespace, nor gimp itself (or so little that that doesn't count ...), so take what I write with 'reserve' <sneek>bootchk, daviid says: i've just slightly patched gi-array->scm to get a better error message, could you either clone, checkout the devel branch or replace the gi-array->scm in the (g-golf gi utils) module with this version https://paste.debian.net/1404588/ - then run the configure/make/make install danse, run your plugin and paste the 'complete' error message - tx <bootchk>daviid: responding to your earlier request for error message from my script using your revized utils.scm: Unimplemented array interface: (object <gimp-drawable> #<<gobject-class> <gimp-drawable> 706e6a1c63c0> 109052915545360) <bootchk>daviid: another issue is method resolution (multiple dispatch) seems to fail. See my post here about helloWorld failing to resolve gtk-application.run method. In my case, it fails to resolve GimpImageProcedure.new-return-values (in superclass GimpProcedure.new-return-values.) <bootchk>As you said, take what I say in reserve (with grain of salt) since I am not that familiar with Guile and G-Golf like you aren't familiar with Gimp API. <daviid>bootchk: ok, i'll fix gi-array->scm and ping you prob later today ... <daviid>bootchk: wrt method resolution fails, that is highly improbable, and the hello world works fine ever since written - what is the hello-world error you are refering to? <daviid>bootchk: what is tha call you place that leads to the error, and what is the exact error msg (use a paste ...) <dariqq>mra: custom_target in meson git has a build_subdir option which completely fixes the annoyance of recursive meson just to compile scm files. I also found a way to snarf manually by copying the sed expression from guile-snarf <daviid>bootchk: probably because you call (new-return-values the-proc-inst 'success gerror) and you should not pass the GError, it is done by g-golf, so a typicall call would be (new-return-values the-proc-inst 'success) <daviid>GError arg are automatically added and handled to raise an exception if after the call they are not NULL ... so you know for other such calls ... <bootchk>daviid: g-golf example helloWorld using gtk doesn't seem to work on Ubuntu25.04, Guile 3.0.10: oop/goops.scm:1585:2: No applicable method for #<<generic> run (5)> in call (run #<<gtk-application> 7f34ac321760> 0 ()) <bootchk>I more or less copied into a REPL, with prior config of duplicate-merging. Of course I could have done something wrong. <bootchk>daviid: actually I was calling (new-return-values procedure 3) I substituted an integer for 'success since that is the enum value from PDBStatusType that doesn't import without much work. Anyway, I think I can work around that. <daviid>bootchk: PDBStatusType are imported, i did post how to retreive them you must have missed that, let me paste again <daviid>bootchk: you must pass a valid symbol for enum args and a list of valid symbols (possibly empty) for flags args - anything else will raise an exception <daviid>bootchk: where did you copy that call, the proper call is (run app '()) <daviid>bootchk: you are not running the example from the distro? look at the code in <your-g-golf-dir>/examples/gtk-4/hello-world <daviid>bootchk: maybe you copy/pasted that code from the doc, which was 'lagging behind and I recently patched the doc to fix this ... <daviid>or make install-info or make install-pdf according to your prefs ... <ekaitz>ArneBab: re the js article: i love the article. I'm happy that you also enjoy that kind of texts