<jackhill>rekado: thanks, that does help me get started. <jackhill>RhodiumToad: yep! I didn't spend to long on catamorphisms <rekado>I’ve been trying to speed up processing of large Debbugs files that contain raw emails separated by a bunch of different control characters. <rekado>the files also contain attachments, so sometimes I have to read through 10+MB of stuff before I find a mail separator <rekado>I initially wrote this with (ice-9 rdelim) to read the file line by line, because the control characters are always on a line on their own <rekado>then I thought I probably shouldn’t be using a string API and work with the bytevector directly <rekado>but I only managed to make everything much slower <rekado>do you have any hints for working with files as bytevectors? <rekado>the rdelim version takes 14 seconds on a 31MB file <rekado>the bytevector version (where I read byte for byte) takes 26 seconds on the same file. <rekado>I noticed no difference when I read the whole file into memory with get-bytevector-all and then operated on it byte for byte through a port opened with open-bytevector-input-port. <rekado>naively by get-u8 from the bytevector and comparing it with = the desired delimiter octet <rekado>if it doesn’t match: unget and move on to the next byte <rekado>I thought this would become faster when I do this on a bytevector that’s already in memory <daviid>sneek: later tell tohoyn I pushed a fix for gtk-tree-store-set-value, please pull, make, try ... tx for the report <mwette>(On the long term) I wonder if mmap() would help. I have worked on/off on mmap port for Guile, but that is not done. <mwette>How about a procedure (mmap-file "abc") => bytevector ? <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") ***catonano_ is now known as catonano
***jonsger1 is now known as jonsger
<sneek>tohoyn, daviid says: I pushed a fix for gtk-tree-store-set-value, please pull, make, try ... tx for the report <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: when possible, using sfri-4 <daviid>afaict all are sfri-4, when allocated by g-golf <tohoyn>daviid: if an argument type is byte-array can I pass a bytevector to it? <daviid>tohoyn: not all types are covered, when you find a missing type, let me know - it's just a matter of time and occurrences so we caover them all ... <daviid>tohoyn: i probably not 'just like this - the machinery needs to follow the GI protocol ... just paste a snipset and i'll fix the missing type <daviid>tohoyn: what is the function? it's difficult to answer 'in the dark', and example is _always_ better ... <tohoyn>daviid: no particular function. I'm just implementing Theme-D interface to G-Golf. <tohoyn>daviid: how is ptr-array implemented in G-Golf? <daviid>tohoyn: as a user, you shouldn't have to buid an array of pointers yourself <daviid>tohoyn: because usually, they are the are built from scheme lists of ... <daviid>and therefore, the scheme procedure that iplements a GI function expect a lst ... <daviid>tohoyn: wrt gtk-radio-menu-item-new-with-label, when you a re creating a new group, you should pass #f as the first arg, not '() <daviid>(gtk-radio-menu-item-new-with-label #f "Item") <tohoyn>daviid: so ptr-arrays are implemented as lists in guile? <daviid>tohoyn: this said, could you make an example for me that use an existing group - I'm not sure what the scheme arg should look like in that case <daviid>tohoyn: is a radio button considered a group ? I don't know because i (a long time ago) built those using glade ... <tohoyn>daviid: IMHO a group is a list of radio buttons <daviid>tohoyn: ok, it appears it is not the recommended way of doing things, see the documentation for gtk_radio_menu_item_join_group <daviid>(gtk-radio-menu-item-new-with-label #f "Item 1") -| $10 = #<<gtk-radio-menu-item> 5570666d3ca0> || (gtk-radio-menu-item-new-with-label #f "Item 2") -| $11 = #<<gtk-radio-menu-item> 557066893b80>, then (gtk-radio-menu-item-join-group $10 $11) <tohoyn>daviid: the first argument of procedure g-variant-parse-error-print-context has type-tag and type-desc "error" <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 <manumanumanu>lampilelo: I haven't really embedded guile in multithreaded applications (nor am I very good at C). davexunit has done some things down that path <lampilelo>hmm, i have more fundamental problem than that - it seems like i don't know how to invoke scm_call correctly so i'll work on that first <lampilelo>manumanumanu: i'll take a look at it, thanks <tohoyn>daviid: is it so that GValues should not be used by ordinary users of G-Golf? If so, could you check function gtk-container-child-get-property. <lampilelo>manumanumanu: this article talks about spawning threads from inside of guile, that's not what i want, i want to hook it up to existing threads, but thanks anyways <lampilelo>ok, it seems that it works in multiple threads after loading it from the main one <lampilelo>the problem was me not knowing how modules work <lampilelo>FYI i'm trying to extend moc player with guile <lampilelo>first thing on the list is custom loading mechanism for lyrics <laurus>Where can I find a list of the functions that are implemented for ELisp in Guile? <laurus>(Or any documentation of the ELisp in Guile for that matter, beyond the description of what it is that I see in the Guile manual.) <lampilelo>laurus: there is a README file in guile/module/language/elisp/ in the guile source tree, but not everything is listed there, so i think you'd have to look at the code <laurus>lampilelo: For example, I put this into a file called mytest.el: (prin1 (+ 1 2)) <laurus>Then, I ran: guile --language=elisp mytest.el <laurus>But I get: ice-9/boot-9.scm:752:25: In procedure dispatch-exception: In procedure public-lookup: No variable bound to prin1 in module (language elisp runtime function-slot) <laurus>lampilelo: how can it not be, this is one of the most basic ELisp functions <lampilelo>don't ask me, i never tried to use elisp in guile <laurus>One of the release updates a few years ago said "Guile's Elisp implementation is now fully Emacs-compatible" <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 <laurus>lampilelo: yeah I guess that's right. <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." <ATuin>mmm I'm trying to set to false the test-log-to-file for srfi-64 but seems that it always ends up saving the output into a file <ATuin>any idea on how to stop loggin into a file? <reepca>is guile's gc smart enough to not collect foreign pointer objects when only the result of pointer-address is still live? <mwette>ATuin: The symptom you see is a known bug in guile-3.0.0 through 3.0.2. Fixed in commit 2b4e45ca1b89a942200b7b9f46060dddc44d2876. <mwette>The fix is to add `#:declarative? #f' to define-module in srfi/srfi-64.scm ***rekado_ is now known as rekado
<rekado>laurus: prin1 is defined in ./module/language/elisp/boot.el <laurus>rekado: Really! How did you know that? <rekado>but it does look like there have been a few regressions <laurus>rekado: I don't seem to even have that "module" <rekado>I have been trying to upgrade the wip-elisp branch since Guile Emacs can’t be built at this point <laurus>(I'm very unfamiliar with Guile, perhaps I need to install that module?) <rekado>probably in the wip-elisp branch only <rekado>so I guess Guile still does support Elisp, but it currently doesn’t include what you could consider the standard library <laurus>rekado: I see, thank you that's helpful. How do I get that elisp module installed? <rekado>I think you would build Guile from the wip-elisp branch <rekado>but I don’t recommend doing that now; not before the regressions have been addressed. <rekado>interest in elisp on Guile has been surprisingly low, so I think it’s no wonder that it has atrophied somewhat since it got first introduced. <laurus>rekado: so I have a couple things I'd like to ask you about briefly <laurus>rekado: one is, how does Guile choose which functions from Elisp to implement? <rekado>oh, I’m the wrong person to ask. I’m just a janitor. <laurus>For example, we have the "GNU Emacs Lisp Reference Manual" which documents all these functions. But, we don't have a language spec for implementations of Elisp (like that in Guile) <laurus>rekado: no that's okay, you're very knowledgable <laurus>rekado: like, what's your opinion on this? I mean if it were you, how would you decide what to implement? <rekado>from what I can tell very little is implemented in Guile itself <rekado>even boot.el is written in Elisp <laurus>rekado: from my understanding, some of these commonly used Elisp functions are written in C <rekado>so it’s just a bunch of primitives that are sufficient to load boot.el, and that should be enough to load all the other Elisp code. <laurus>rekado: what would happen to those, on a Guile VM-based implementation? <rekado>I suppose they would be reimplemented in Elisp <laurus>rekado: I see. For example, prin1 is in C in Emacs, so someone actually wrote an Elisp version of it and put it into Guile. Very cool. <rekado>even something like “defun” is implemented in Elisp on top of primitives defined in (language elisp runtime) <laurus>rekado: That is completely incredible! <laurus>rekado: So that's why the release notes said that Guile VM-based Elisp is working just as the Elisp in Emacs, or whatever the exact wording was <laurus>rekado: What is the issue with the build right now, I mean, what does your patch do? <rekado>wip-elisp is currently based on a version of Guile before the 2.2 release <rekado>so the first step is to rebase it on 2.2 and fix broken tests <rekado>(there are quite a few that fail) <laurus>I see. And then upgrade it to 3.0? <rekado>once that works, yes, upgrade to 3.0 <laurus>Wow. Is that going to be a lot of effort? <rekado>but before then I’d like to see if we can build guile-emacs again <laurus>I am quite unfamiliar with Guile and I don't know how much changes, etc. <laurus>rekado: doesn't building guile-emacs depend on the elisp implementation working? <rekado>because right now it is so terribly slow that the compilation takes forever <rekado>so I hope that rebasing on top of 2.2 and fixing a few bugs will restore that functionality <laurus>rekado: this is all so encouraging and inspiring! My initial goal is just to program command-line scripts in Elisp and run them using the Guile VM <rekado>the diff between 2.1.x and 2.2 is much smaller than that needed to upgrade to 3.0, so I want to be sure I’m doing something that actually yields results <laurus>rekado: Do you think Guile Emacs could eventually take advantage of Guile's facilities to improve the core of Emacs that is "crufty"? <rekado>Doing so would mean to diverge from Emacs <laurus>Well, if Guile Emacs was working amazingly well, maybe the GNU Emacs people would start liking a collaboration <rekado>since the Emacs developers are not convinced Guile Emacs is worth the trouble, diverging from Emacs would just make future work on Guile Emacs more difficult to keep in sync. <laurus>rekado: is there a way to donate to you somehow for the work you're going to do on this? <laurus>Well I appreciate the work you're going to be doing <rekado>other people have done all the work; I’m just an enthusiast who would like to prevent their work from rotting <laurus>why is it called wip-elisp by the way? <rekado>I guess the “elisp” part is obvious ;) <laurus>Right, but I don't even have an "elisp" module at all in my Guile install <laurus>Yet, I can use ",language elisp". So I'm wondering why all the key stuff seems to be separated out <rekado>wip-elisp includes a few commits that are, well, non-committal. <rekado>this would need to be cleaned up before merging it into the master branch <laurus>Well I will definitely look forward to this, I'm quite inspired by it. <rekado>it made me open up the directory again and look at the test failures <laurus>I'm maybe an unusual user of this in that I'm more interested in Elisp than Scheme, simply because I know more of it <laurus>I also have an interest in Emacs as a platform for applications (stuff like mu4e for example) <laurus>So I'm more interested in the fact that Guile has this VM capability, than Guile Scheme itself <laurus>You're welcome, glad to hear that :) <rekado>the Guile VM and compiler tower are very cool. <laurus>I think regarding Elisp that despite its issues or being a worse language than Scheme or whatever, it is in use and a lot of very useful stuff for a lot of people has been built on it <rekado>one style of writing libraries for Guile includes writing a compiler layer <laurus>And Emacs the program is useful not only as a text editor but as an application platform for some of those applications <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>Welcome back dsmith, you have 1 message! <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>Like buffer-local variables? Nope <laurus>dsmith: so "find-file" doesn't work in Guile Elisp? <laurus>Or, for example, "write-region"? <dsmith>That would all live in emacs. Those are emacs functions. <laurus>dsmith: But, how then would someone write a text-processing script in Guile Elisp? <dsmith>I suspect the intent was more to get Guile into emacs than provide emacs functionality into Guile. <laurus>dsmith: But "buffer" surely must exist somehow, otherwise how could Guile Emacs even run? <laurus>Or is it just like, that's implemented in C and stands apart from the stuff running on the Guile VM? <dsmith>Oh, that all exists inside of emacs. bipt did a whole lot of work there Two Google Summers of Code worth. <laurus>You mean to bridge the two systems <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>As Richard Stallman said (quoted in an e-mail from Thomas Lord to the Guile mailing list in 2010): "If it only supports something like Emacs Lisp then it is not much of an advance. Guile supports Scheme and Javascript as well as Emacs Lisp. It also supports multithreading, which IMHO is a big deal as well, perhaps more important than bignums.\n\n I think the support for multiple languages is the biggest advance." <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. <RhodiumToad>much as I'm getting to like scheme (and have always liked lisps in general), I think it's less accessible as a language to most users <janneke>RhodiumToad: English is also pretty hard, I don't think it will ever take off <RhodiumToad>if it hadn't become dominant for reasons unrelated to its ease or difficulty, it probably would not have <gagbo_>and english is pretty easy grammar wise <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 :/ ) <sneek>Its been said that sneek is a good bot <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 <lampilelo>if i tell the moc developers they'll probably say "what? scheme? :/" because moc is more vim-like <justin_smith>some acquaintances of mine made a very small lisp (mostly clojure flavored) in lua, which runs in the nvim native lua engine <lampilelo>the only lisp i know that is related to lua is fennel <justin_smith>neovim uses a lua runtime, and this code lets it load fennel directly <lampilelo>i learned about it like a week ago (i know about it, i don't know it) <dsmith>At one time, someone was working on a lua for Guile. <justin_smith>yeah, it exists, but sadly doesn't even try to be compatible <justin_smith>so it's really "a minimal lua-like-language" implemented on guile <manumanumanu>justin_smith, dsmith : that would be nalaginrut's work. IIRC it got actually quite close <justin_smith>manumanumanu: right - it's not that it's incomplete, it is that it intentionally diverges from the lua spec <dsmith>lua is really nice for embeddeding all on it's own. I think a lua-on-guile would be pretty hard to compete wth that. <manumanumanu>If laurus ever returns, I think we could tell him/her that guile-emacs just deferred a lot of the elisp runtime to use whateve C procedures emacs has. <reepca>so I'm trying to use the ffi to access the "environ" global variable, but it doesn't seem to be working <reepca>ah, I have to dereference it, of course <manumanumanu>Forgive my ignorance, but I am comparing the following two ,time outputs: <manumanumanu>;; 2.009149s real time, 2.395014s run time. 0.586440s spent in GC. <manumanumanu>;; 1.763346s real time, 1.791048s run time. 0.093789s spent in GC. <manumanumanu>The runtime is pretty comparable, but what is going on with the first one? 2.39s run time? What does the difference to the second one mean in practice <manumanumanu>I am code-golfing a json library trying to make it faster. Mine is the second one, on a 24mb json file. <dsmith>ok. Wonding if that was why. How can the "run" time be longer than the "real" time? <manumanumanu>The second piece of code started as the first piece of code and got a lot of optimizations that were then merged back into code 1. <lampilelo>these guile-based parsers are not overly fast, i wrote a basic libxml wrapper for guile some time ago and it's a lot faster than the parser in the sxml module <manumanumanu>libxml is pretty fast, and is written in a language where no operation has any real overhead <reepca>anyone else having autodoc issues with geiser with guile 3.0? <reepca>sometimes the autodoc hints appear, sometimes not - for example, they don't appear for 'write', but they do for call-with-output-string <lampilelo>manumanumanu: sure, but it makes me think we should have c-based solutions in the guile's core; sxml simple is pretty much a reference implementation for sxml <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? <lampilelo>manumanumanu: yeah, i guess it would be a pain to implement properly <manumanumanu>i wouldn't parse XML in C, but evn I could write a json parser without too many RCEs in C :D <manumanumanu>but I don't think I could write one using SSE, which means it wouldn't be stellar <RhodiumToad>manumanumanu: regarding runtime, the GC runs in its own thread