<ArneBab>nalaginrut: it might be possible to reuse code from gtk-gnutella - but that’s GPL, not LGPL. <davexunit>guest`: thanks for catching the typo! I didn't know that anyone even read it! <dunsmoreb>If I use `scm_gc_malloc' instead of `malloc' for strings that are passed between Scheme and C, then those strings will be freed when a sweep occurs. Correct? <mark_weaver>dunsmoreb: when there are no more references to it, yes. <dunsmoreb>Okay, because the docs made it sound like creating a SMOB was necessary to get garbage collection. <dunsmoreb>A SMOB is just a new type, similar to a struct, correct? <mark_weaver>it might have been necessary in 1.8, I don't know. I only know about Guile 2 and beyond, where we use the Boehm garbage collector. <mark_weaver>another thing I'm not sure of. if you allocate something with scm_gc_malloc, you have to make sure that the GC can see a pointer to it as long as it needs to be kept. <mark_weaver>I don't know off hand the full list of places that the GC scans. <dunsmoreb>How do you make sure the GC can see a pointer to it? <mark_weaver>can you ask on guile-user? someone who knows more about this can answer. <dunsmoreb>I'm not sure I understand the bigger picture yet. <dunsmoreb>guest`, sorry if I'm trying to force these similes, but a SMOB would be more like a typedef then with a little extra data? <dunsmoreb>guest`, one more question. How would you recommend that a c-style structure be implemented? I didn't read of any specific method in the manual. I'm imagining that you could use the CPP to write a macro that creates a slew of getters and setters. <guest`>mark_weaver: I think he meant in scheme, not using c. I'm sure there's a good example in guix, but I'm searching <dunsmoreb>guest`, I meant in C. I'm rereading the section again. <dunsmoreb>guest`, thank you. I think I'm starting to get it now that I'm rereading it. <dunsmoreb>Question though, what purpose does the `const char *what' serve on the `scm_gc_*' functions? <dunsmoreb>`scm_gc_malloc' is defined in libguile/gc-malloc.c and calls `do_gc_malloc'. <dunsmoreb>return GC_MALLOC (size ? size : sizeof (void *)); <zRecursive>After `git pull`, how can i only see the modified parts ? <wleslie>I usually use gitk to have a look at the commits after the last head ***sneek_ is now known as sneek
<lloda>impressive changelog for 2.2 <lloda>is there a style guide for the online help? <wingo>not really; but i think the gnu coding standards have something to say about docstrings <wingo>a more formal style guide might be a good idea <lloda>yes, and some examples might be good. I get for example <lloda>scheme@(guile-user)> (help call-with-output-file) <lloda>`call-with-output-file' is a procedure in the (guile) module. <lloda>PROC should be a procedure of one argument, and FILE should be a <lloda>and I think PROC? FILE? what PROC? <lloda>scheme@(guile-user)> call-with-output-file <lloda>$2 = #<procedure call-with-output-file (file proc #:key binary encoding)> <lloda>you do get the arglist. Maybe this should be printed automatically with (help ...) <wingo>the first line is printed out by the doc system <wingo>if you (use-modules (texinfo reflection) that installs a different system that does print out the arguments <wingo>i think we would like to enable that texinfo thing by default, probably... <civodul>lloda: when using C-c C-d d in Geiser it all gets beautifully printed <wingo>civodul: we should provide nice facilities in the console tho :) <wingo>and geiser doesn't render texinfo <civodul>but officially docstrings are still plain text <civodul>i agree that eventually it should be Texinfo <civodul>'help' & co. would have to handle that <wingo>yeah, and right now ,d and help are different (argh) <wingo>civodul: help does handle texinfo! <wingo>civodul: (use-modules (texinfo reflection)) <wingo>then try (help foo) where foo has a texinfo docstring <lloda>thx for the (texinfo reflection) tip, it does format nicely <wingo>like (use-modules (ice-9 popen) (texinfo reflection)) (help open-pipe*) <lloda>it's still the same info though <wingo>lloda: it does print the arguments, no? <civodul>so loading (texinfo reflection) installs the right thing for help as a side effect? <lloda>ah right, I hadn't seen that <lloda>- Function: call-with-output-file file proc [#:binary] [#:encoding] <wingo>it can also make help for modules; (help (ice-9 popen)) for example <lloda>1 vote for making this the default <wingo>the overview section comes from the commentary <wingo>which that module apparently doesn't have; oh wells <wingo>it's an easy thing to turn on <civodul>it would be ideal if it were autoloaded <wingo>it's an easy thing to auto-load too <lloda>I've put it in my .guile already <civodul>instead of having (texinfo reflection) register itself, (ice-9 session) would load it as needed <wingo>i wrote that code, um, 10 years ago i think ;) <wingo>only merged into guile with 2.0 tho <jmd>What is the guile equivalent of find? <civodul>jmd: for the find(1) command, these closes thing is file-system-fold or scandir in (ice-9 ftw) <jmd>Using set! I always get ERROR: Wrong type argument in position 1 (expecting empty list) <jmd>Unless I pass it '() <jmd>What is the point of an argument which can only be constant? <taylanub>jmd: `set!' ? Normally that's just (set! variable expr) which mutates variable's binding to bind it to the evaluation result of expr. Did you do something funny with your Guile session ? <civodul>after that we should think about 2.1 i think <civodul>mark_weaver has been taking care of 2.0 ;-) <wingo>yeah i wish i could be there! <wingo>and yeah, mark_weaver is doing great stuff :) *wingo finally looking at lloda's patches now, whee <civodul>the big NEWS has hit my guile-commits folder :-) <mark_weaver>thanks. you too! I appreciate the precise stack marking! :) <wingo>so my todo list only has a few things on it as far as the vm goes -- at least things that need to be done <wingo>i need to do something about shuffling arguments for functions with lots of live variables <wingo>and i would like to do some sort of local variable information, for ,locals <wingo>but i haven't figured out a nice way to do that that's not terribly expensive in terms of space <wingo>mark_weaver: should work, but you don't get ,locals, and there is no procedure-module currently <wingo>there is some bug with tracing that i need to track down; sometimes the trace ends early <wingo>the final thing is the GC_MARKERS issue <mark_weaver>also, master still doesn't work on most platforms, including MIPS, because of the page size issue. <wingo>but we can hack around that one for now, disabling parallel marking <wingo>still i think we're generally in good shape for a prerelease <wingo>knowing that nothing is perfect and we'll have maybe even a dozen prereleases :P <wingo>it would be nice to make compilation faster, but it's not a requirement <mark_weaver>yeah, a prerelease sounds good to me, as long as it's clear that lots of things may still change before 2.2. <mark_weaver>I'm still hoping to get UTF-8 strings in, fixing-letrec-reloaded (generalized for efficient letrec*-values), changing add1/sub1 to add-immediate, more VM instructions for fixnum/flonum ops, and maybe a few other things. <mark_weaver>also, we need to replace our awful regexp stuff. I'm looking forward to SRFI-115, based on irregex. <mark_weaver>to my mind, what I think is most important in a new major release is making changes to the API and ABI that cannot be done within a stable release series. <wingo>mark_weaver, civodul: i have a silly idea <wingo>i want to remove tail arrays, but that is a hard problem -- the tail array size is embedded in make-struct <wingo>so i was thinking about deprecating make-struct in 2.0 <wingo>make-struct uses should be make-struct/no-tail <wingo>and there would be new C functions <wingo>then in 2.2 we remove make-struct and those c functions <wingo>and then in 3.0 or whatever we add back in make-struct, without the tail arg <civodul>can't we just issue a deprecation warning when make-struct is passed a tail array arg? <mark_weaver>hmm. I think it might be a bit late to deprecate in 2.0 and remove in 2.2. <wingo>no, unfortunately -- it's (make-struct vtable tail-len init0 init1 ...) <mark_weaver>I don't think enough people will see the deprecation warning before 2.2 is out. <wingo>mark_weaver: yeah, but otoh make-struct probably doesn't have many users, and likewise for the c interface <wingo>and there's no possibility for confusion in 2.2 as the thing would be gone entirely <wingo>i agree it is a bit aggressive ;) <civodul>that said, the manual already recommends against tail arrays <wingo>yes, but there are no deprecation warnings currently <wingo>dunno, we could do it the other way, but it might take forever <wingo>i.e. deprecate in 2.2, remove in 2.4/3.0, re-add later... <civodul>well, let's first deprecate it in 2.0, i think that's not controversial <wingo>it would shorten the length of time that we have to think about tail arrays :) <mark_weaver>my gut feeling is that we should deprecate in 2.0/2.2 and remove in 2.4. but then, I'm not the one who feels the pain of having to think about tail arrays, so it's easy for me to say :) <mark_weaver>I just worry that we already have a reputation of being cavalier about backward compatibility issues, and I don't want to aggravate that. <civodul>deprecate in 2.0.10, then rediscuss before 2.2.0 comes out <wingo>civodul: i'll get in the patch later this week <dsmith-work>Just looking at srfi-115. Using | for "or" really is ugly: |\\|| <mark_weaver>it would also be swell if we could make allocation faster, using per-thread allocation pools, or whatever it is that bdwgc now supports. <mark_weaver>but I suppose that could happen anytime; I don't think it has ABI implications, does it? <wingo>yeah i wanted to do that too <wingo>dunno about abi tho, there is time <wingo>anyway, /me -> z. happy hacking :) <civodul>mark_weaver: my recollection is that GC_MALLOC first tries the per-thread pool, no? <mark_weaver>I have no idea. All I know is that wingo posted this as an idea recently to guile-devel. <civodul>ok i thought it was already doing it internally <unknown_lamer>I bet it would be more fun to fix the ES compiler for guile than to bind ancient C++ <mark_weaver>if we have to grab a mutex every time we allocate, that's bad. <mark_weaver>we really need allocation to be as cheap as we can possibly make it, I think.