<taylan>pretty sure I still used to drink human milk back then ***tophullyte is now known as help
***help is now known as Guest7386
***apteryx is now known as Guest89099
***apteryx_ is now known as apteryx
<flatwhatson>i'm not sure i understood the suggestion about taking address as a fixnum, should it support passing a numeric value as the pointer arg? <taylan>but yes, passing a numeric value instead of a pointer object would be preferable, since pointer objects are allocated on the heap. <taylan>flatwhatson: looks pretty good to me except that I'd also allow the pointer arg to be a number. though if pointers were made into "immediate" objects like civodul suggested, that would become unnecessary... <taylan>and wingo said he's not a fan because the compiler could do it. if the compiler really could avoid bytevector/pointer allocations a lot of the time then I guess it would be mostly unnecessary, though IMO it's good to also have an API to accesses memory without the bytevector abstraction in between. <taylan>because if I know I want a uint64 at memory location 0xDEADBEEF then it seems excessive (conceptually) to create a bytevector of size 4 referring to that memory location just to get that uint64. <taylan>if you have structs, unions, etc., bytestructures takes care of that whole layer of logic. no need for bytevectors there either. <flatwhatson>how can pointers be made immediate if SCM are uintptr_t, we need some bits for the tag too? <wingo>flatwhatson: either unboxing, if the whole lifetime of the pointer is visible to the compiler <wingo>or tagging, if the pointer has suitable alignment (e.g. if it's 8-byte aligned, then the bottom 3 bits are 0) <wingo>or tagging, if address space size is less than the word size -- is the case for all 64-bit systems currently <wingo>fwiw we also need to consider improvements to the gc. maybe if we have a bump-pointer generational gc, then the cost of allocating a could words might be insignificant <flatwhatson>re: generational gc, would that mean replacing bdw-gc with something else, or writing one bespoke? <wingo>yeah replacing bdw-gc with something internal to guile <taylan>wingo: not to rush but did you have a chance to look at the R6/R7 SRFI module names patch? it's a pretty straightforward improvement IMO and will significantly improve R7RS compatibility. *wingo has not done so yet <taylan>ok, happy to hear feedback whenever you have time :) <mwette>Some other issues with the FFI are lack support for variadic args and unions. And maybe the pointer->procedure spec's for arg types. I'm working on how to handle structs and unions better, but varargs is a kludge: every call to the function generates a pointer->procedure call. <davexunit>a first-class API for creating/parsing C structs would be a huge quality of life improvement <davexunit>I know guile-bytestructures exists, but it's hard to justify the additional dependency when I can hack together something specialized that works for my specific case when I need to. <taylan>mwette: isn't bytestructures sufficient to handle unions? <taylan>davexunit: hmm, I've been thinking a bit whether it would be welcome to include bytestructures in Guile proper. any opinion on that? it's pretty small after all. <davexunit>taylan: other languages have FFIs that include this functionality, so yes I think it should be in Guile core. <davexunit>anyone that has tried to wrap a C function that doesn't use only primitive types has been burned by the lack of good struct support <davexunit>I've wrapped many libraries at this point and each time I wish guile had something built-in for handling structs. <mwette>taylan: pointer->procedure and the underlying libffi API doesn't do unions. So I'm approaching with (struct-covering <union>) -> struct; and if a vector is inside a struct/union then I need to do (list int int int ...) (equiv (make-list N int)) <taylan>mwette: oh, you mean like when a function directly takes a union by-value instead of a pointer to it, right? <davexunit>any function that uses structs by value are a pain to wrap in guile <taylan>davexunit: have you looked into the bytestructures API to see whether it would solve your problems nicely, by the way? I don't even really use the library myself (!) so I need external feedback to make sure it's actually practical and useful, and not just nice in theory :P <taylan>it all just started as an academic exercise; I don't even remember what sparked the idea to make something like it. didn't even realize it would be useful for FFI until someone made me aware! <mwette>taylan: yes; structs by-value are handled but not unions by-value; so my approach will be to figure out the size+alignment and make a list that size; but i have to understand how the compiler will deal with floats <mwette>pointer->procedure does not accept bytestructure (descriptors), so nyacc's ffi-helper has code to convert bytestructures to (list ...) <taylan>wait, I could swear I've written a transformer for that <taylan>or... I saw yours and wanted to adopt it but didn't because unions couldn't be handled? been years that I seriously on this project. :\ <taylan>mwette: ^ you're aware of that module? <mwette>yes: I remember looking at it, but not the details <davexunit>taylan: I haven't used it. I should try it out. <mwette>the ffi-helper will parse structs from C headers and generate scheme code for bytestructure API and for the pointer->procedure API <taylan>hmm, not sure how to feel about (equal? '(1 . ()) '(1 . #nil)) => #false. I guess it has to be. <taylan>on the flip side, (syntax-rules () ((_ #nil) ...)) will match () and I'm not sure how to feel about that either <terpri>after hearing that #nil was being used by the API of some json library, my first thought was that we should make that value much more difficult to access from ordinary programs <terpri>almost the *entire* utility of it depends on both scheme and lisp programs' ignorance of its existence <terpri>like, possibly it shouldn't even be accessible or (read)able outside of module/language/elisp and a few other places <terpri>it's possible to misuse it, simply difficult under ordinary circumstances, but something "more correct" would likely require heavy-duty capability-security tricks that divide guile into multiple "worlds" <terpri>and finding a clever but technically slightly-incorrect solution that works in nearly all real-world use cases is very much in the lisp tradition, if one has read the rrrs-authors archives or maclisp news files... <terpri>actually, i'm going to track down that json library author and give them a stern talking-to^W^Wfriendly explanation about why guile has #nil in the first place, which i ought've done years ago <terpri>taylan, btw, are you working on elisp stuff or just tinkering? <terpri>seeing native-comp progress in emacs -- in a way that was not encouraged for guile-emacs -- has motivated me to engage in some friendly, ahem, socialist emulation when i get the time to commit to it <terpri>i'm a bit annoyed by the different treatment and would really quite like to make guile-emacs superior to native-comp in both performance and compatibility (guile-emacs would have far better performance if it hadn't been designed for 100% compatibility) <terpri>$work is taking up too much time as usual but will be winding down soonish, enough to do other *real* work <terpri>and i'm quite willing to fork emacs if that's what it takes, and go for the egcs approach (ecgs was a much-improved gcc fork that quietly replaced the original gcc in 1999) <terpri>(furthermore, my odd mixture of roles at $work is actually fairly good preparation for a guile-emacs revival, as i have to do quite a lot of things i used to be not very good at) <terpri>(not to mention my fairly extensive JIT-related work with wingo at igalia) <terpri>it remains a big project (i only finished the *first* 90%...) but years later, i still have a good grasp on what remained to be done <terpri>perhaps i'm tilting at windmills, but perhaps some windmills need tilting-at, and i'm too stubborn to simply give up and let the project die a quiet death. to quote angela davis, "you have to act as if it were possible to radically transform the world, and you have to do it all the time" <taylan>terpri: I'd like to work on elisp stuff more seriously but my knowledge of lower-level stuff is not good, such as the VM, the whole compiler stack, etc. I'm confident I could get good at it but I lack time, and a mentor who in turn has time for me :) <taylan>I'm in the second week of a two-week vacation so I'll probably return back to being mostly inactive again very soon, though I think I can restart allocating some time to free software on evenings and weekends, like I used to a couple years ago. <terpri>taylan, you were a top-notch contributor to guile-emacs all those years ago, second to none, and i was (and am) very grateful for your help; i should have told you that years ago if i haven't already <taylan>terpri: thanks for the kind words! I wish I had been able to do more actual programming though. what I did was mostly just talk, to put it bluntly. <taylan>I guess one could call it "awareness raising" :) <terpri>i also have to admit that i was a really mediocre maintainer, in terms of all the responsibilities of maintainership beyond cranking out a great deal of code; but it was also my first big project, and i'd like to think i've learned a bit in the intervening years <taylan>terpri: wait a minute, I have to sheepishly ask now, you're bipt?.. <terpri>taylan, yeah, i changed my nick a few years ago (changed first name to robin, so the initials didn't match). no need for sheepishness, i remember the guile GSoC folks were confused too since i didn't actually announce it anywhere ;) <taylan>terpri: ahh ok, good to see you again then :D you did *amazing* work IMO, would love to collaborate more on the code-level if we both find the time. <terpri>to be clear on the timeline, the startup i'm working at is promising but has a...short runway, so it could be 3-6 months before i can really attempt a revival (working full-time off of savings, working half-time at this startup or another (which would be allowed here at least), that sort of thing) <dsmith-work>terpri: Something that has come up here a few times, is the difference between emacs-lisp the language, and emacs the application. <terpri>maybe with crowdfunding or an altruistic angel "investor", maybe not, lots of details and not a lot of certainty at the moment <terpri>dsmith-work, yeah, there've been some discussions in emacs fora. i'll file it away as a topic for a future blog post :) <terpri>guile-elisp provides exactly enough of the language to bootstrap emacs by itself. as bits and pieces of emacs are rewritten in scheme or elisp, guile should have access to more emacs "application" functionality one way or another <terpri>it hasn't escaped by attention that emacs has added *some* highly-visible guile-emacs features like bignums, so i'd also have to provide new motivations for it <terpri>but, eventually creating a (fast, powerful) lisp machine atop linux is a decent one; i bet you could do some cool things with guile-emacs + guix + spritely-goblins (an object-capability based library for distributed scheme programming), for instance <terpri>lisp was prominently mentioned in the gnu manifesto for a reason ;) <terpri>heck, just providing secure, networked, distributed programming amongst emacs instances via spritely goblins would be nifty <terpri>quite possibly you could use it *within* emacs to bypass the "M-x gnus is slow" problem, with preemptive multitasking/real threads, but that's just speculation <manumanumanu>now, I have to admit I am not too keen on the actor model, but "transactional", "actor model", and "distributed" _does_ tickle the right places. <taylan>terpri: didn't Emacs add support for real threads also? TBH I find it really neat how they added a bunch of nice stuff to Elisp... as in, I'm happy that Emacs's Elisp got all these nice features in the short term, even if it means less motivation for Guile-Emacs in the long term... <nojr_>how is everyone :). I've tried joining this chat for over a year now I have acquired enough technical skills to do so:)) <nojr_>that's why I'm happy. Anyway, I have a question I keep getting this error when I run guile in a terminal or in Geiser Emacs <nojr_>guile: warning: failed to install locale <terpri>manumanumanu, agreed, i like CLOS a lot <nojr_>warning: failed to install locale: Invalid argument <terpri>taylan, and i'm happy to see emacs' progress too. i *think* they only have cooperative concurrency though <manumanumanu>ah, you need to install glibc-locales (or whatever it is called) <manumanumanu>or, if you are one of the lucky few, you can install the small bundle of utf-8 locales <nojr_>thanks everyone! I'm installing glibc-locales right now. I have a question: I really want to learn Guile but how do I start? <terpri>also, it's Top Secret(TM) but i've been *slowly* implementing CL for Guile, so you might eventually be able to do absolutely bonkers things like running maxima *inside of emacs* <nojr_>manumanumanu: wow that solved it, was very easy! <manumanumanu>nojr_: I don't think there is a very good on-boarding story for scheme. TSPL is dense (and r6rs only, which is fine for guile). <terpri>so i can come up with motivations, and in fact we don't even have real benchmarks for emacs-native-comp vs. guile-elisp, so "it runs faster" might still be one (or "its performance profile is better for interactive use", etc.) <manumanumanu>nojr_: SICP is fine if you are willing to spend some time thinking (if you are stupid like I am). HTDP is actually very good imho, but is more tailored to racket. <nojr_>manumanumanu: I think there is a way to improve that. I looked at artanis as a good project to base a small website tutorial to get started <nojr_>maybe building a small CRUD app with it to get used to Guile <manumanumanu>terpri: I can't imagine a better argument than being able to work on things like ORG without a full emacs session. <nojr_>that's how many people learn to program today with CRUD apps, it's most familiar to lots of young devs at the moment <nojr_>manumanumanu: I have tried SICP like three years ago but I am very dumb. That's why I thought maybe I could tinker with artanis, build a small app and write a blog entry?? <terpri>manumanumanu, that should eventually be possible! it'd take some serious emacs refactoring, but that's on the long-term TODO list anyway (necessary for rewriting chunks of emacs in guile, almost certainly) <manumanumanu>nojr_: That seems like a fine idea. I don't know about your previous experience, but I can say that python programmers usually spend a month or two writing quite slow and icky code - and that's fine! <terpri>someday: (use-modules (emacs org)) :D <nojr_>manumanumanu: I'll try writing down my progress. I hope that maybe I'd be useful in the future for other beginners like me <nojr_>manumanumanu: I'm not much of a beginner since I know Python already but I'm not an expert either, I've only been doing this on my freetime for two years now <manumanumanu>nojr_: the main thing is that the main data structure (cons cells/linked lists) don't have fast random access. Going front to back is fine, but programming with them as a python list will be an awful experience and lead to very slow code. <manumanumanu>nojr_: jokes aside. If I am not AFK I can always help with feedback. <terpri>but to clarify, the #1 priority is to make a better emacs than emacs, whatever that entails, and there will be plenty of time for pie-in-the-sky projects down the road <terpri>and since i also got a privmsg, yes, i'm robin templeton/bpt/bipt (should probably change that hexchat "realname" default) <taylan>terpri: btw any opinion on (equal? #nil '()) ? <taylan>having (equal? '(1 . #nil) '(1 . ())) => #false feels very wrong to me at least <lampilelo>i don't think emacs and real threading is possible, nothing in it is thread safe, fake, js-like threads are good enough to make non-blocking stuff <terpri>taylan, yeah, that seems...odd. i'd have to check the original #nil proposal to be sure, but they're supposed to be difficult to distinguish... <terpri>might have to dig up an ancient version of guile to see if the behavior changed <terpri>iirc the bit-level representation of #nil was designed to make ()-or-#nil tests cheap <taylan>yeah there's some special magic in scm.h and pairs.h <terpri>lampilelo, difficult, but i wouldn't say impossible. imagine, for example, independent buffer groups that can only communicate with other such groups in special ways, or maybe "rejoin" other groups when a task is done <terpri>but if cooperative threading is good enough for elisp programmers, that's fine too, and means less work <terpri>although you could also create a pure-guile "real" thread that can only "talk" to emacs via erlang-style messages, something like that <terpri>and really if emacs remains unithreaded indefinitely, and can only use threads via calling out to guile, that should be fine as long as the guile side of things doesn't mess around with the main emacs thread, and still might enable some neat demos <lampilelo>terpri: what about the global, mutable environment, dynamic context, an idea of (current-buffer) etc.? you'd have to restrict the access to most things on secondary threads or do a major rewrite of the core <terpri>emacs will use guile variables, guile fluids and quite possible delimited continuations for buffer-local variables, unless the latter are too slow <terpri>but there's definitely C-level structures that threading would break, so it would be either pretty limited and/or a long-term goal <lampilelo>oh, i was thinking about threading in emacs, not guile-emacs <terpri>ah, yeah. one of them is very slightly easier :) <terpri>guile-emacs would still have to be extremely cautious about threading, of course. you could do weird things like stuffing a buffer in a dynamic variable and using FFI to mutate it from another thread, which would almost certainly be a bad idea <lampilelo>i'm sure package developers would find simpler ways to do bad stuff with threads <terpri>well, also elisp can be blocked from guile access, it just exists for fun and demos atm <lampilelo>for some reason i like guile more than elisp, if we had emacs' "standard library" exposed to guile i'd be in heaven <terpri>reconciling lisp-1 and lisp-n is the tricky part there. but we could always do heuristics, or some kind of lispm-style elisp:::(+ 2 2) syntax <terpri>kent m. pitman had some notes on just that topic, called lisp-omega i think, which i have yet to review <terpri>guile-emacs currently is supposed to store emacs variables and functions in guile modules, which makes .emacs.scm not terribly painful. i don't know if it will stay that way or not <terpri>i believe i had to turn it off for "production" because of my old nemesis, buffer-local variables. guile quite reasonably can't (or couldn't) capture bits of the C stack in a delimited continuation, which broke BLVs <terpri>but they can be implemented inelegantly *shrugs* <terpri>(to clarify: you can implement dynamic binding with delimited continuations, and in fact customizable dynamic binding, which is what i initially tried to do for BLVs. using some kind of magic fluid is probably more practical)