<taylan>roptat: but yeah, creating an extension is also an option <roptat>I think that's my question: how do I create an extension? I've seen examples of function that manipulate numbers, but what about a C structure and pointers? <daviid>roptat: look for make-c-struct and parse-c-struct in the manual <daviid>roptat: guix has some magic to acheive this at compile time <taylan>(didn't test but I think it should be correct) <taylan>I'm the author of bytestructures so if you decide to use it I'm happy to offer assistance. for now AFK though (zzzz) <mwette>Do you want access to struct elements from scheme or just want to pass pointers ***catonano_ is now known as catonano
<daviid>rlb: looking at your lokke re-export-and-replace!, and have a few quiz :) <daviid>rlb: in (lokke boot), you call (re-export-and-replace! '(clj-quote . quote)), but i am confused, should it not be (re-export-and-replace! '((clj-quote . quote))) or (re-export-and-replace! '(clj-quote quote)) if these are two seperate names .. . jusdt curious how that lands in the module-re-export! call <daviid>also, any particular reason why you didn't make it a syntax? <daviid>i mean the re-export-and-replace! definition itself <daviid>rlb: in the re-export-and-replace! code, as you do not have a guile-2 entry, why not 'just' (cond-expand (guile-2.2 (module-re-export! (current-module) names)) (else (module-re-export! (current-module) names #:replace? #t))) ? maybe i a missing something ... <daviid>rlb: got the answer to the first quiz, (define (re-export-and-replace! . names) ... - i didn't see the . names ***apteryx_ is now known as apteryx
<chrislck>running statprof #:display-style 'anomalies has caused error <chrislck>"In procedure =: Wrong type argument in position 1: #f" ***bjoli is now known as manumanumanu
<rlb>daviid: wrt re-export-and-replace!, I wanted at least a function, so I started there (similar to module-use!, etc.), but of course could create a syntax (wrapper) too later. Ideally, I'd eventually like to just have support for that in define-module. <rlb>And regarding the versioning - at the time I just added the supported versions, but I suppose I could change it to assume any newer versions might work with the 3.0 approach. Didn't think about it too hard at the time, was mostly busy being surprised at the way cond-expand works :) <rlb>(and as I think mentioned, then perhaps libguile/scm.h) <rlb>terpri: fwiw, the current #nil handling was *very* helpful with respect to creating lokke https://git.sr.ht/~rlb/lokke/ So if we make changes, it'd (selfishly) be nice if we could preserve the relevant bits. Right now at least, the clj and scheme side are *very* close, i.e. easy to write any given module in scm or clj, and many things have direct mappings. I also wonder if the way clj dynamic vars are handled might have some <rlb>similarities to what you were suggesting (cf. magic fluid). <rlb>terpri: and I'd imagined that an emacs that supported elisp, scheme, and clojure more or less directly might also be fairly interesting to the clojure world (since emacs is still one of the primary tools there - interactive code excution, etc.). <taylan>rlb: I wrote a few patches recently that affect the behavior of #nil. One is to make it equal? to (), another to make lists ending in #nil be written as (foo bar . #nil) instead of (foo bar). <taylan>rlb: would either of those be undesirable for your purposes? <taylan>also... nice project! :D let's implement ALL lisps in Guile :P <rlb>Hmm, I'd have to think about that, and perhaps test the patches, but might not matter? i.e. lokke likely doesn't care about the scm written representation in any critical way, but the latter might be a problem. Not sure, and also not sure if it is a problem, if it'd be expensive to accommodate. I'll have to think about it. <rlb>And at least right now, I've just let scheme lists pun as clojure sequences, so scheme '() currently works just fine anywhere clj's "persistent empty list" should work. <rlb>(well, proper lists -- lokke will *not* like improper lists in many places) <rlb>It might also be that I can just rework clj equality to handle that. I'm just a bit concerned that there might be a bunch of places where there are implicit assumptions that might be hard to track down or expensive (at runtime) to adapt. <rlb>taylan: in any case, if it ends up looking like something we're likely to pursue, could you ping me and if/when I can get some time, I'll try to figure it out in more detail (and/or test the change). <leoprikler>iirc the rationale is to use if for #f or nil and null? for '() or nil <rlb>fwiw, from the clj side, empty "collections" are intentionally not false. <rlb>(empty, possibly lazy, collections) <rlb>You have to call (seq x) on them to find out if they're actually empty. <taylan>rlb: does that mean clj's "if" is not the primitive "if" since it has to interpret #nil as true? <rlb>#nil isn't true, it's false in clojure <rlb>i.e. clj works somewhat like elisp <taylan>oh, I assumed that "empty collections" includes #nil <rlb>which is why our current elisp support made things easier - clj has nil and () <rlb>taylan: clojure has a broader "collections" abstraction, i.e. cons works on anything that's a collection, including lists, vectors, sets, etc. <rlb>so as far as clj is concerned, in some senses (), [], and #{} are the same (empty list, empty vector, empty set). <rlb>(And map, for, filter, remove, drop-while, reduce, ... work on any collection too -- anything that's "seqable".) <rlb>taylan: I suppose another question might be what "level" of release a change like that might require, i.e. X, Y, or Z...