IRC channel logs
2025-11-24.log
back to list of logs
<mwette>daviid: You mean GDBus, I guess. That's the gio/gobject wrapper for dbus? <mwette>nyacc's FFI helper can convert gio to guile-ffi. <mwette>Does gi preclude going around libgirepository? <daviid>mwette: i don't understand your question <mwette>I have no depth on the GI. Was wondering if they need the GI to deal with GDBus in an app written using the GI. <daviid>mwette: i still do not understand: you use g-golf, once I provide proper support for GVariant (another total nightmare), I can provide proper support to GDBus <daviid>mwette: an 'app' is never written using GI, it is written in a lang that implemented GI bindings ... <mwette>The app is written to the GI-based API, is it not? The GI provides its own typesystem. <daviid>it is written to the upstream api <daviid>in this case, the upstream lib is GLib, and lang bindings must provide proper suppport for GVariant, then they can write GDBus based app using the GDBus upstream api ... <daviid>there is no 'GI-based api", GI is an annotation system so lang binding can 'easily' provide upstream lib api's <daviid>*in this case, the upstream lib is Gio, but the GDBus api requires proper implementation of the GLib GVariant api, which currently g-golf is missing ... <mwette>OK. It's GObject that is has it's own type system. Somewhere gint turned into a "handle" for other languages to deal with. g_list_length() returns a gint, which in C is "int" but in other languages has to be some sort of handle or language specific type of integer. <daviid>mwette: GLIb and GObject - GLib is a general-purpose, portable utility library, which provides many useful data types, macros, type conversions, string utilities, file utilities, a mainloop abstraction, and so on. GObject The base type system and object class <tohoyn>daviid: as regards G-Golf GVariant support, does it have some other problems than g-variant-new-tuple? <sneek>Welcome back tohoyn, you have 1 message! <sneek>tohoyn, daviid says: wrt g-variant-new-tuple, and any other g-variant interfaces, it currently won't work, g-golf has extremelly limited support for GVariant. I patched that procedure to raise an excpetion, with this msg "Array of GVariant are curently not supported". I reverted the previous change, so DBus struct are (still) considered opaque (and now I remeber, it is precisly because DBus expect GVariant, which g-golf doesn't <tohoyn>daviid: in the server the variants worked fine except g-variant-new-tuple <lechner>Hi, does Guile have multi-dimensional hash tables? <identity>i doubt Guile has that and i struggle to imagine a use-case <ArneBab_>lechner: do you mean like multiple key access in SQL? <ArneBab_>lechner: can’t you use a regular hash table on pairs and change the equal and hash procedure to use to check both elements in the pair? <lechner>ArneBab_ / thanks! indeed i do not need partial searches. the keys can be any scheme expression? <ArneBab_>AFAIK the keys can be any expression that the = and hash function you pass accepts <shawnw>Just the basic equal? based ones should work for lists of keys, no need for hashx's custom equality and hash functions. (hash-ref table '(a b 1 2 3)) etc. <ArneBab_>(I’m not sure whether we have good hashes for everything) <lechner>Hi, is there a way to "read" records? <tohoyn>lechner: do you mean reading Guile records from a file? <identity>lechner: you could serialize them into an alist, write them out, read them in, deserialize back into a record <tohoyn>lechner, identity: or store the list or alist using write <tohoyn>lechner, identity: forget the last comment <lechner>identity / i'd like to have some validation of field names but without using guile-syrup <identity>lechner: what do you mean by «validation of field names»? <lechner>in an alist, values are only identified by their position <lechner>what I meant was, does anyone have an example for how to modify current-reader so that "read" can read what "write" wrote? <old>what are you trying to do lechner? <lechner>basic persistence without sqlite, for bootstrapping. performance is not a concern <old>so serialization to disk? <lechner>no, i can use (hash-table->alist) for the categories but would like to use something more robust than alists for the properties <lechner>more robust and also more meaningful when inspected by someone like me <old>so, you want to serialize list of key-value pair? <old>if you have an example so I can understand your problem domain by hand that would be great <lechner>"prerequisites" there refers to what must be built before a recipe is called <old>is there a reason why sqlite3 was used in the first place? <old>was this for performance reason or just for persistance? <old>well tbh, I don't see why alist would not be a good fit then <lechner>an alist is probably okay here. i'll use filesystem folders to differentiate by selectors. then the alists only have two entries. my question was more general, however. how may I read records written by "write" <old>like srfi-9 recordS? <mwette>Underneath srfi-9 records are structs, so you could potentially use vtable methods to write one printer for all. If you have fields that are non-printable, e.g., regex's, then you have more problems to deal with. <old>lechner: so the way I do that for BLUE (I use GOOPS and not records) <old>is to register the module definition where a type is defined using object property <old>I can then call `make' using that type and the data I need to provide <old>basically re-making the object at runtime <old>this looks like this on the file-system: <old>so you could do the same with basic record <old>you just need find which module define the constructor and the order of the slots to pass to it <old>GOOPS is easier on that aspect <old>and to find the module where a type is defined, I use object-property for this <old>Wrap this in a macro and you can add the propety when defining the type <lechner>old / thank you for your pointers! as we discussed on another occasion, i personally dislike the object paradigm (remember the video?) but i'll look at what you did. I especially appreciate your help since BLUE potentially competes with guile-make. thanks for being such a steadfast friend! <old>civodul: sure! extensively ! <old>I've added static-check at expansion time for slots with GOOPS :-) very powerful that meta-protocol also <old>lechner: well the OOP in GOOPS does not need to be OOP like Java and C++! <old>In BLUE, there are no mutable state. It's almost all purely functionnal <old>The reason why I choose GOOPS is: <old>1. I can hide thing in the meta protocol <old>2. Users can extend the methods if they dislike what the provied one does <old>In my mind, a user that find a bug in their build-system do not need to wait for the next patch release to get the fix <old>they can just write the fix, push it to Codeberg so I can merge it but they can already use it by defining new methods/types ! <civodul>oh yes, very convenient in that respect <old>lechner: one good example of hiding the details is for delayed computation. In BLUE, any slots of an instance can be delayed using a #%~ form <old>For example: #%~(string-append #%?bindir "/foo.scm") will yield the concatenation of the state `bindir' and the string "/foo.scm" <old>but only when the slot is accessed. <old>This allows to dynamically change the states (reader monad) and remove all mutations in such cases <old>lechner: is the goal to use guile-make in the boostrap of Guix <daviid>tohoyn: ok, I 'll patch scm->gi-array and gi-array->scm so they work fine with array of GVaraint, if not latewr today, tomorrow ... will let you know - I still will mark DBus struct as semi-opaque, but at least you should be able to write your own 'little api' to make those structures and experiment with GDBus ... <tohoyn>daviid: if you want, I can try to fix G-Golf myself if I encounter some problems with it <tohoyn_>daviid: the problem is not just GVariant as an array type but all opaque or semi-opaque structs. I suspect that scm->gi-struct should accept <pointer> as a scheme value, not just a list of field values. <mwette>lechner: What's a .nyacc file? Is the former mach.scm files? <lechner>mwette / Hi, I renamed the *.ffi extensions because I use Guile's FFI mainly to run executable bytevectors. (They are derived from inline assembly.) To be sure, I do so very sparingly. As you know, my goal is to get rid of prerequisites, including Glibc, but some assembly stubs are needed, for example for syscalls. So in my case FFI is a misnomer: It is actually more "native" than anything else I do...