<zv>how ejust out of curiosity, is guile entirely created by volunteer devs or are there any developers pay by existing organizations? <galex-713>do guile free data only doing gc continuously or can it also free things like when exiting of a scope? ***karswell` is now known as karswell
<daviid>mark_weaver: heya! wrt your comments, first I think with-typelib is a good abstraction, because, like call-with-input-file [for example] will close the port for the user, 'with-typelib' calls gbank-tl-free, which is a user responsibilty. I could actually call it 'call-with-input-typelib' <daviid>but then your other comment makes me think my implementation is not good enough? <daviid>?var won't be alive outisde the syntax, and once ?body is finished, we can and must call must call gbank-tl-free, which is what I am doing so I'm not quite sure what you ment: maybe you mean I should set! ?var as the first dynamic-wind lambda expr? <daviid>1 'must call' is enough, w're not in the army here :) <daviid>mark_weaver: maybe you ment I should not use dynamic-wind, I now see call-with-port doesn't either? <daviid>mark_weaver: in terms of design, I believe I should provide the same interfaces as we do for input file: (a) call-with-input-typelib [would not free the typelib if proc does not return], and (b) with-input-from-typelib [which would use dynamic-wind, as does with-input-from-port, and free typelib. <zv>you guys do a great job :) <daviid>mark_weaver: wrt your mem allocation comment, of course. the glib, gobject and GI manuals are really excellent with that respect and tell us when a mem block must be free'd by the user, and when the 'system' does it for us, so it comes down to very carefully read the doc of course. <daviid>the comment I made about bytevector->pointer was more out of curiosity, because I now use glib to allocate the mem block GI ask me to allocate, which of course does not segfault when the 'system' calls g_free, or I do through the GI api, such as gbank-tl-free ... <daviid>mark_weaver: the curiosity was 'why/how' could a bytevector->pointer be good for all GI functiona but g_typelib_free. maybe I'll post somethig about that later, but for ow I'm ok with the new approach <daviid>my battery is empty, i'll go abruptly any time soon sorr, bbl <marusich>Is there any fancy way in emacs (perhaps using guile?) to make it so that when a variable is under point, it is also highlighted everywhere else in my buffer? <marusich>by "everywhere else" I mean the part i can see in my buffer <marusich>and by "perhaps using guile" I meant "perhaps using geiser" <ijp>give me a sec, I know I have this in my config <marusich>I know I can search for it manually, but a small thing like this makes it a little bit easier to read code. It's a feature of IntelliJ, for example, that I like <marusich>especially if emacs/guile can correctly highlight just those other occurrences that actually correspond to the variable, rather than those which are just strings matching the variable name <ijp>I think what I have is idle-highlight <galex-713>Is there a way to use the *system* guile compiler to compile guile? in order to do it quickly <galex-713>like, I’ve the debian’s /usr/bin/guile, which is already here and compiled etc., and I’d like to use it to speed up the bootstrap, is it possible? <ijp>Yes, AFAIK, but I don't know the details <ijp>I'd search the mailing list <galex-713>marusich: are you sure IntelliJ doesn’t highlight matching strings? <mejja>Great talk on what it takes to support editing features like that.. <galex-713>what if any OS were like emacs where any function is accessible from all others? <galex-713>and that any compiler feature were usable anywhere else <ijp>no OS would ever do that <marusich>galex-713, yes, it shows me the variable uses, not other strings with the same name as the variable <galex-713>marusich: maybe it’s a complex regexp which match a bit of the syntax, try to use “let” and weird scoping stuff to see if that still works <galex-713>ijp: I mean OS in a large meaning, like, “shell” <galex-713>like an-emacs-made-with-guile-implementing-native-compilation <ijp>marusich: doing it for just the variable is possible, but it requires more compiler integration than emacs is going to want to allow <galex-713>where I think theorically the compiler/parser/etc. would be accessible to do other things than compiling/interpreting <ijp>for guile, maybe we could do it with the elf stuff wingo was hacking on, but idk. <ijp>you can't work it out from the source directly due to arbitrary code in macros <marusich>Sounds like I probably can't get integration (yet?) in emacs for Guile that exists for Java in IntelliJ, but one can dream <marusich>Thanks for the interesting links and comments <marusich>I don't know how IntelliJ does its tricks, but I'm pretty sure it's not just a bunch of regexes. <ijp>I presume intellij parses the java file, and uses that to generate the info it needs <marusich>I think that there are APIs that let you directly introspect and even manipulate the Java language syntax being used. Lombok, for example, uses the javac APIs to automatically create boilerplate code. <marusich>I imagine that IntelliJ does something similar when it introspects the code? <marusich>Isn't that feasible with languages like Guile, too? <galex-713>ok, bootstraping the quickndirty way: for file in *.scm ; do guild compile $file -o ${file%.scm}.go & done <galex-713>works in most of the case, make will do the rest I guess <wingo>preparing a release, making soup :) <mark_weaver>galex-713: you can only safely bootstrap guile using the exact same version of guile. it might work in some other cases, but we don't guarantee it, and you're on your own there if you try. <mark_weaver>wingo: it would be great if 'master' could work on some computer that I own. i686, armhf, or mips64el, take your pick :) <mark_weaver>for a time, I thought that perhaps I was being lame to not have a working 64-bit intel machine. maybe I should prioritize getting my broken X200 fixed. but now I think that there's some value in me not having one of those. too much software these days won't work on anything other than 64-bit intel, and I want to have that in my face, so that I'm motivated to work against the 64-bit intel near-monopoly that seems to be developing. <mark_weaver>so, I've been unable to work on guile at all for months now. <mark_weaver>I would fix it myself, but honestly it's beyond my abilities. I don't even know where to start. My best guess is that it's probably some subtle code generation bug in the new compiler code. <mark_weaver>I look at that backtrace, and am filled with despair. <mark_weaver>I imagine it would have that effect on anyone, even the author of the relevant code. <mark_weaver>so I'm sympathetic to wanting to work on more fun things instead, but we're leaving people behind. <wleslie> that's a delightful policy, I think. I wish I had that gusto. I'm a big IA64 geek, and I can't bring myself to spend money on one, because there's other stuff I should be working on. <wingo>mark_weaver: 32-bit is one blocker; janneke's patch about .go files in 2.0 and 2.2 is the other <wingo>will work on 32-bit after landing a couple patches <wingo>it is somehow a miscompilation bug <wingo>it reminds me of a bug i had where i did (intmap-map foo map) <wingo>and intmap-map was defined as (intmap-fold (lambda (k v seed) (intmap-replace! seed k (f v))) map map) <wingo>but if map was a "transient" map to start out with, that would mutate the "map" argument! <wingo>and i did what i thought was an exhaustive search for other cases like that but didn't find anything <wingo>there is one difference between 64- and 32-bits in intsets, for a branching factor <wingo>but i changed that locally to be the same (to use the 32-bit branching factor) and rebuilt the whole thing, full rebootstrap, but i didn't see the bug <wingo>so i have to build on 32-bit then. <wingo>regarding whining though i feel your pain but also i feel the burden of this work <wleslie>a 32-bit chroot is a good thing to have in your toolbox <wingo>i will have such a thing via guix <mark_weaver>I wonder if it would make sense to compile the intset code on guile-2.0.x, and try to reproduce the same bug there. <mark_weaver>to help determine whether the bug is in the intset code itself, or in the new compiler. <wingo>it could be in the intset code or in any of the uses... <wingo>one thing we could do is to map all the e.g. intset-add! to intset-add <wingo>the semantics should be the same, though the performance would be worse of course <mark_weaver>ah right, the backtrace is actually for intmap, not intset <wingo>right but that doesn't necessarily mean anything <wingo>with miscompilation anything is possible <kristofer>amz3`, nice! I've been building something similar with gdbm :) <kristofer>I think a list message you sent inspired me actually. Some of your notes have been really valuable too <kristofer>amz3`, nice work! I've been working on something similar with gdbm. Unfortunately guile-gdbm won't store an arbitrary datum, it must be a string. It would be super nice to be able to (write) scheme records as values in the store. <kristofer>I should really modify the gdbm module to work with any arbitrary datum, but instead I've been tinkering with the json module as an ORM ***Baldtoenails is now known as Lennart_cucks
<amz3>kristofer: you can `write' the scheme value to string and store that value in gdbm <kristofer>yeah I saw you use write, and am trying to figure that out amz3 ! <kristofer>why can't the record be read back into the environment? <ijp>it's not impossible in principal, although it would generally break with recompilation <mark_weaver>there are some deep problems with allowing the system standard 'read' to read arbitrary records back in <mark_weaver>there's only one system 'read' in guile, and 'read-hash-extend' mutates the behavior of that reader <mark_weaver>this causes lots of problems, where some module you load in changes the behavior of other unrelated code <kristofer>if I were to use (set-record-type-printer!) for modules I'd like to read might that work? <mark_weaver>it means that you may not be able to combine two modules into the same program if their reader extensions conflict with each other <mark_weaver>my recommendation would be to write some procedures that convert your record into a standard scheme s-expression before writing it, and then converting the other way after reading <mark_weaver>another deep problem is that it may pose a security risk for 'read' to be able to create arbitrary objects <mark_weaver>in the old days, schemers used s-expressions to represent all data. instead of using records, we would just use lists and symbols, typically with the first symbol in the list as the 'tag' <mark_weaver>that way had a lot going for it, but modern day schemers don't seem to want that anymore <kristofer>records seem to offer a sense of type-safety I guess <mark_weaver>so, just write your own serializer/deserializer, like you would do in most other languages <mark_weaver>standard scheme 'read' is for s-expressions. it's not intended to be extensible. <mark_weaver>it's extensible in guile, but IMO it's a bad idea to do so <mark_weaver>R6RS actually goes so far as to explicitly prohibit any extensions beyond the precise lexical syntax in the standard. <mark_weaver>which maybe is going too far, but I sympathize with that sentiment, because extending 'read' tends to be problematic <mark_weaver>what we should probably do instead is to provide easy ways to make new reader procedures <mark_weaver>which is what 'guile-reader' is for, although I confess I've never looked at it <ijp>I am also against reader modification in general <ijp>mark_weaver: for the purposes of creating a standard, that prohibition is perfectly reasonable <ijp>random-nick: depends on what you mean by label <ijp>but even as an approximation of implementation, it doesn't necessarily capture how they are used in practice <ijp>I have written lots of code that does not export the "real" record constructor, but one that enforces various invariants <ijp>procedural records open up a bunch of interesting issues ***karswell` is now known as karswell
<wingo>quick note -- i can reproduce the bug! <Lennart_cucks>So how well does guile run outside of GNU? in particular using another libc than glibc with it. <Lennart_cucks>Excellent, I need to use an overlay because the normal one is at 2.0.9 or something I thnk <Lennart_cucks>I had to copy the 2.0.11 in the lisp overlay to a local one becuse it got the slot wrong even <ArneBab_>I’ve been writing from time to time in that bug report in the hope that someone with the sufficient access rights and ebuild-experience would take it up… <Lennart_cucks>ArneBab_, ahh, you encountered the sale slot problem where it couldn't merge after a 15 minute compilation because the the package it was supposed to replace claimed the files which it didn't replace because of the wrong slotting/ <ArneBab_>Lennart_cucks: I encountered “info files not slotted, therefore I won’t merge” <ArneBab_>(after seeing that it doesn’t actually hit something important) <Lennart_cucks>The lisp/dev-scheme/guile/guile-2.0.11.ebuild here has SLOT=0 <fitzgen>Hi, I'm having trouble building Guile on OSX. The README mentions an INSTALL file that does not seem to exist, and the HACKING file just has general advice without a specific set of commands to run in order to build Guile. Can anyone help me out?