IRC channel logs

2020-12-09.log

back to list of logs

<daviid>sneek: later tell tohoyn I will provide you with a binding to g_set_prgname and g-set-prgname asap -
<sneek>Okay.
<daviid>sneek later tell tohoyn G-Golf won't let users gi-import GLib, nor GObject, by design - these are manually binded for what G-Golf - and users, upon request if something is missing - needs, for boostrap reasons ... to allow users to 'later import' those using g-golf itself would give me far to much work (mostly unecessary) to put the right barriers in the right place to avoid conflict with the boostrap manual bindings ...
<sneek>Will do.
<ane>civodul: ok. I have a patch sitting in guile-devel, I should probably send it to bug-guile
***leoprikler_ is now known as leoprikler
<daviid>sneek later tell tohoyn I pushed a patch (to the devel branch) with the two new interfaces, g-get-prgname, g-set-prgname, documentation and tests
<sneek>Got it.
<tohoyn>sneek, botsnack
<sneek>tohoyn, you have 3 messages!
<sneek>tohoyn, daviid says: I will provide you with a binding to g_set_prgname and g-set-prgname asap -
<sneek>tohoyn, daviid says: G-Golf won't let users gi-import GLib, nor GObject, by design - these are manually binded for what G-Golf - and users, upon request if something is missing - needs, for boostrap reasons ... to allow users to 'later import' those using g-golf itself would give me far to much work (mostly unecessary) to put the right barriers in the right place to avoid conflict with the boostrap manual bindings ...
<sneek>tohoyn, daviid says: I pushed a patch (to the devel branch) with the two new interfaces, g-get-prgname, g-set-prgname, documentation and tests
<sneek>:)
<tohoyn>str1ngs: If you are there I could send you the G-Golf debianization files as DCC SEND
<ArneBab>ecraven: chez is a compiler?
<ArneBab>ecraven: I thought that chez runs code interractively
<ArneBab>(with compiler I meant: creates C that gets compiled non-interactively)
<ArneBab>ecraven: besides: thank you for keeping your benchmarks up-to-date!
<fnstudio>hi, i have a list of values and need to see whether any of them is true, should i concoct something with reduce+or?
<fnstudio>i thought of something along the lines of `(reduce (lambda (x y) (or x y)) #f '(#f #t))`
<wingo>(or-map identity ls)
<fnstudio>but it feels terribly complicated
<fnstudio>wingo: oh great
<fnstudio>that seems better
<fnstudio>thanks!
<ecraven>ArneBab: chez compiles to machine code, it is one of the fastest compilers I know (and it also produces really fast code)
<RhodiumToad>or-map?
<ecraven>it does *not* go through C (which is not related to whether it is a compiler or not anyway)
<ecraven>sorry about not updating the benchmarks in the last few months, I don't have access to that machine any more, I need to find a good way to run them now ;)
<fnstudio>RhodiumToad: yes, thanks, super - or-map is what i was looking for
<RhodiumToad>didn't find that in the docs
<RhodiumToad>yes, it does look like what you need
<RhodiumToad>but it is notably absent from the docs
***chrislck_ is now known as chrislck
<chrislck>civodul: good news, we managed to modularise gnucash code properly, removing all traces of load-from-path... https://github.com/Gnucash/gnucash/pull/831
<chrislck>no more unbound-variable warnings
<chrislck>next question: if rnrs is the future, would it be wise, or premature, to change use-modules to import?
<chrislck>(is rnrs the future??)
<lloda>i've been using import for years, you don't even need rnrs for that
<lloda>i don't think there's anything use-modules can do that import cannot but i might be wrong
<RhodiumToad>I recall some issue with using import
<RhodiumToad>let me check logs
<lloda>i did have problems with library so i still use define-module tho
<RhodiumToad>right, the thing I was recalling is that (library) loses all source location info from the library body
<RhodiumToad>so in the event of an error, it's impossible to track down where the error was
<tohoyn>fnstudio: I suggest using 'exists' instead of 'or-map'. 'exists' is defined by R6RS.
<tohoyn>fnstudio: similarly 'for-all' instead of 'and-map'
<lloda>still define-module & import work fine together, i haven't had any issues with that
<leoprikler>SRFI 1 also has "any" and "every"
<chrislck>lloda thx the idea is to be more future-proof/standard-oriented
<leoprikler>define-module will always be future-proof
<leoprikler>[in guile]
<civodul>ane: just saw https://ane.github.io/programming/lisp/goops-virtual-slots-and-ffi.html (from you, right?)
<civodul>looks pretty cool!
<civodul>are the bindings part of recutils proper?
<civodul>when using the C API, you'd generally use "foreign objects" (or SMOBs, for the old style) rather than pointer objects and define-wrapped-pointer-type (which are rather for the FFI)
<wklew>does anyone know if the pfds (purely functional data structures) package has a maintainer? the canonical github repo at https://github.com/ijp/pfds has a breaking bug and hasnt been updated in 6 years
<wklew>its a shame because its a really important package
<wklew>implements a lot of common functional data structures like finger trees, HAMTs, etc
<civodul>wklew: hi! ijp hasn't stopped by this channel for a while already
<civodul>so it may be unmaintained
<civodul>sneek: seen ijp
<sneek>I think I remember ijp in (here?) 9 months ago, saying: CherryMan: slots are the fields in foreign objects.
<civodul>ah well, i thought it had been more time
<civodul>perhaps you can get in touch with them and see if they're interested in handing it over?
<wklew>civodul: thanks that's helpful, wasn't aware he visited here
<wklew>er, they
<wklew>i actually did send them an email asking if they were looking for a maintainer, havent heard back yet
<civodul>in the meantime you can always have your branch containing the fixes
<civodul>surely others will be interested in using it :)
<wklew>there is a github fork which fixes it, and I believe the guix package recipe also includes a patch
<wklew>unfortunately that github repo is still referenced in most places
<civodul>it sounds suboptimal
<wklew>i have been thinking about reimplementing some parts of it in more modern guile, so maybe I will take a stab at that soon
<wklew>it is still a shame to see it succumb to bitrot though
<leoprikler>some bits rot quicker than others, sadly
<wklew>and sadly it isnt always the least significant ones :p
<leoprikler>Bit 13 tends to get hammered quite quickly.
<ane>civodul: yes
<ane>civodul: still being worked on, but it's going to ship with recutils
<ane>civodul: I'm not sure about foreign objects, given that librec only exposes opaque pointer types ... one interacts with the C structs only using the functions and pointers
<manumanumanu>wklew: and the data structures in pdfs are not very fast, at least not the general ones (like fectors). Andy wrote a fector library which I have planned to develop further, but I am easily distracted. His source can be found here: https://hg.sr.ht/%7Ebjoli/guile-fector (he gave me permission to do this). note that this is a mercurial repo that hasn't been moved to git yet
<wklew>manumanumanu: thanks, I will check that out
<wklew>speed is important in this case
<wklew>OTOH I've made heavy use of the sequences and hamts in pfds to good results, and have no knowledge of alternatives
<manumanumanu>Andy's fectors are just like the ones in clojure. I wanted to add a small constant overhead and make RRB-fectors with support for fast inserts, splits and joins, but my brain seems to work extra slow when trying to think about how :P
<manumanumanu>Anyway, I ended up with that repo after benchmarking andy-fectors against my own, and found that the overhead was A LOT lower. almost 30%.
<manumanumanu>now, sleep! Todays
<manumanumanu>mental exercise was to add skip-wheels to https://git.sr.ht/~bjoli/wheel-utils (not in the readme yet). Nothing big, but fun anyway.
***m`wleslie` is now known as wleslie
<ane>civodul: actually I think I will just do without the wrapped pointers, since I can just hide the raw pointer object in a slot