<civodul>bytevectors have an indirection to make that possible
<mwette>So mmap is a bit of a kitchen sink, and there is a windows version. Better to make low-level interface in C (e.g., mmap) and make Scheme helpers (e.g., mmap-file, mmap-anon) or just make higher-level procedures in C (e.g., (mmap-file "foo.dat" "rw") ? <= Where "r" maps to PROT_READ|PROT_WRITE.
<mwette>I'm going with user-friendly high level interface (map-file "foo.dat" "rw")
<daviid>tohoyn: great, i'll fix the glist problem a well, wii let you know
<daviid>lloda: fwiw, savannah nongnu projects may also have/open mailing lists, but this must be done by the project admin - login, then Main->Features, the activate the 'Mailing Lists' checkbox, which will provide a menu entry on the main project page, then you (the project admin) may start new ML(s), which one of them can be bug-guile-cairo ... which uses debbugs, just like for bug-guile ...
<tohoyn>daviid: is byte-array implemented as Scheme bytevector?
<daviid>tohoyn: g-variant are not implemented, i think
***apteryx is now known as Guest35258
***apteryx_ is now known as apteryx
***jao is now known as Guest6704
<lampilelo>when hooking guile to an existing program, if I want to load an scm user config file, do I have to load it for every thread or can I load it just in the main thread when initializing? will the stuff from the file be available to other threads?
<lampilelo>i'm not putting threads into guile mode, just call scm_with_guile at certain places
<lampilelo>it doesn't seem to work so I'm assuming that every thread has it's own, isolated environment
<manumanumanu>lampilelo: what exacttly do you want to do? I am not quite following
<lampilelo>i want the user to have his config.scm file that will be loaded when he starts a C app and the code from inside that app to be able to call functions defined in that file
<pinoaffe>laurus: there is an elisp compiler built on top of guile, which should be fully compatible, and then that's starting to allow for emacs to be scripted in guile, but that part is far from finished
<laurus>pinoaffe: my conclusion is that only the most basic aspects of Elisp are implemented in Guile, but a person who has programmed Elisp in its traditional environment and tries to do almost anything (like print something out as I just tried) in the Guile version can't really get anywhere.
<ATuin>tohoyn: scheme with static types, interesting
<laurus>lampilelo, pinoaffe: this is extremely annoying because Elisp itself is very well documented in a large reference manual (as I'm sure you're aware).
<laurus>so anyone who actually takes Elisp seriously based on what's in its _official_ manual and goes into Guile and tries to program even the most basic thing will come away annoyed and bothered
<lampilelo>laurus: you can write scripts in elisp using emacs batch mode if you want, why use guile for that?
<lampilelo>if you don't want to use guile proper, that is
<laurus>lampilelo: I thought one of the selling points of Guile is that it's a multi-language VM for the GNU system.
<laurus>Every single time I come back to this I get annoyed and feel like I've wasted time.
<lampilelo>gnu is just a bunch of volunteers, it seems like there's not that much people that care about the multi-language thing to implement it
<pinoaffe>laurus: yes, it's a multi-language VM for the GNU system, but the documentation is pretty bad
<laurus>pinoaffe: well, it seems like there is close to zero coordination going on
<laurus>I mean, Guile apparently has Elisp, but it seems like no one between the "GNU Emacs Lisp" people and the "Guile version of Elisp" people have gotten together to even confirm what the spec itself should be for "implementations of Elisp outside the Emacs editor."
<dsmith>laurus: At the core, Scheme and elisp are incompatible. '() nil t #t #f mean different things. The "compatability" that was added was a way to allow those differences to co-exist. (my understanding anyway)
<sneek>dsmith, wingo says: turns on i made a mistake that resulted in all optimizations being on, also for bootstrap :P things a little better now.
<laurus>So having a future for Emacs that is on this very solid VM and platform is quite important
<laurus>dsmith: Yeah, I know that from Tom Lord's warnings about trying to bridge the two, in an email to one of the lists a long time ago :)
<laurus>rekado: and of course if people are using Emacs for those applications, extending them, etc., then the ability to write Elisp programs that do stuff outside of Emacs allows them to use that knowledge more generally, hence the importance of being able to run Elisp on Guile VM from the command line rather than emacs editor batch mode
<mwette>I believe another big incompatibility between scheme and elisp is lexical vs dynamic scoping.
<laurus>I also think there's a role for standardization in all this
<laurus>I.e., what gets implemented and how. For example, how is the concept of "buffer" implemented on Guile VM.
<laurus>Do you happen to know the answer to that (regarding buffer specifically)?
<dsmith>Also is that scheme is a lisp-1 and elisp is lisp-2
<dsmith>So there right now, the only place elisp is implemented is in emacs itself. There is not much separation beteen elisp the language and emacs the application. What would a separate implementation of elisp look like? What functions would be avilable in it's core? What functions are specific to emacs the applicaiton? It's all mixed together right now.
<laurus>dsmith: Well didn't we just discuss that there is a lot of Elisp implemented in wip-elisp?
<dsmith>I believe the main focus of the emacs support in guile was to specifcally be able to extend emacs with guile as the Elisp and Scheme languages.
<dsmith>Again, personal opinion. As an outside observer.
<laurus>dsmith: Right. I'm saying that there are these other benefits of the work that was done
<laurus>And moving into the future it might be good to be paying attention to these other aspects
<dsmith>There are other languages on top of guile. Most of them are not very usable either. They do not get much love.
<dsmith>Why would they, when you can code in Scheme instead? ;^}
<laurus>dsmith: because of all the reasons I just mentioned
<laurus>(sorry, it was to the emacs-devel mailing list, not the Guile mailing list)
<dsmith>I would really like to see Guile in Emacs. I think it's a great idea. There are not to many emacs devs on board with it though. Unfortunately.
<dsmith>A long long time ago, when Gnome was first starting out, Guile was to be the offical scripting language for automating apps.
<gagbo_>I would be endlessly confused by having guile and elisp code in the sources though, it would not be fun times with the devs I think... Part of the reason I chose Guile for my pet project was to see what (bad) Guile looks like
<gagbo_>and now I can't help people anymore in elisp because I can only remember Guile functions
<gagbo_>(I know Guile Emacs wasn't about mixing Scheme and Elisp in configurations, but hacking the VM where you're handling elisp code in scheme looks not that fun :/ )
<jackhill>rekado, RhodiumToad: Thanks for your advice yesterday on sxml. I accomplished what I needed to …
<jackhill>… inefficiently, but hey, it works, and now I have something I can iterate on at my leasure.
<lampilelo>omg, at last! i put guile inside the moc player and now i can have lyrics stored in any place i want! i can implement automatic downloading of lyrics and other stuff i can come up with, without redesigning much of the c code
<manumanumanu>lampilelo: i somewhat agree, but best would of course be if guile could provide enough speed to make native guile modules compelling enough :D Reading json at 13mb/s isn't bad for a dynamic language.
<manumanumanu>it isn't stellar either. comparing to languages that use C it is not great :) :)
<manumanumanu>my json library is less than half as fast as racket's json library, which is probably the fastest one running on chez scheme, which means I am doing fine
<manumanumanu>being guile native means playing well with delimited continuations
<reepca>how would one query which module is used for a certain binding?