IRC channel logs

2014-01-27.log

back to list of logs

<ArneBab>nalaginrut: nay, Gnutella is an open standard. gtk-gnutella would likely the best starting point: http://gtk-gnutella.sourceforge.net/
<ArneBab>nalaginrut: it might be possible to reuse code from gtk-gnutella - but that’s GPL, not LGPL.
<guest`>davexunit: in http://dthompson.us/a-cooperative-repl-server-for-guile-2010.html, it refers to spawn-coop-server, but seems spawn-coop-repl-server is meant
<davexunit>guest`: thanks for catching the typo! I didn't know that anyone even read it!
<davexunit>guest`: fixed! thanks.
<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.
<dunsmoreb>Thanks.
<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.
<mark_weaver>guile-user@gnu.org that is.
<dunsmoreb>Yeah, let me read up on it more though.
<dunsmoreb>I'm not sure I understand the bigger picture yet.
<guest`>dunsmoreb: SMOBs are 'quite limited in size', http://www.gnu.org/software/guile/manual/html_node/Defining-New-Types-_0028Smobs_0029.html#Defining-New-Types-_0028Smobs_0029 and the dynamic typing has different implications than structs
<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?
<guest`>dunsmoreb: you can see that way, but the extra data has some meaning and there are standard procedures to read this data, see http://en.wikipedia.org/wiki/Type_introspection
<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.
<mark_weaver>Well, that's what SMOBs are for.
<mark_weaver>See http://www.gnu.org/software/guile/manual/html_node/Defining-New-Types-_0028Smobs_0029.html
<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.
<guest`>dunsmoreb: maybe playing with it is better, http://git.savannah.gnu.org/gitweb/?p=guile.git;a=tree;f=doc/example-smob;h=b38dc229b681a53644cc3728b2744f3d3b7517eb;hb=HEAD
<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?
<guest`>dunsmoreb: from http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=libguile/gc.h;h=61fc9a2d5b2902aa9686cdab8c79a6c2b9f5e98a;hb=HEAD, lines 183, 190 and 191, this seems to tell if it is typed or not
<dunsmoreb>guest`, I don't think it does anything.
<dunsmoreb>`scm_gc_malloc' is defined in libguile/gc-malloc.c and calls `do_gc_malloc'.
<dunsmoreb>This is the body of `do_gc_malloc':
<dunsmoreb>return GC_MALLOC (size ? size : sizeof (void *));
<guest`>dunsmoreb: it can be an anachronism, in http://www.gnu.org/software/guile/manual/html_node/Creating-Smob-Instances.html#Creating-Smob-Instances, it seems to be declare the type too
<nalaginrut>morning guilers
<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
<zRecursive>how about command line ?
<nalaginrut>git log -p
<zRecursive>nalaginrut: thx
<nalaginrut>ZombieChicken: np ;-)
<civodul>Hello Guilers!
<nalaginrut>heya
***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> http://www.gnu.org/prep/standards/html_node/Doc-Strings-and-Manuals.html#Doc-Strings-and-Manuals
<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>
<lloda>PROC should be a procedure of one argument, and FILE should be a
<lloda>...
<lloda>and I think PROC? FILE? what PROC?
<lloda>of course if you do
<lloda>scheme@(guile-user)> call-with-output-file
<lloda>$2 = #<procedure call-with-output-file (file proc #:key binary encoding)>
<lloda>
<lloda>you do get the arglist. Maybe this should be printed automatically with (help ...)
<wingo>right
<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>s/reflection)/reflection))/
<wingo>i think we would like to enable that texinfo thing by default, probably...
<wingo>dunno
<civodul>lloda: when using C-c C-d d in Geiser it all gets beautifully printed
<civodul>you see the argument names, etc.
<wingo>civodul: we should provide nice facilities in the console tho :)
<wingo>and geiser doesn't render texinfo
<civodul>right
<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
<civodul>oh really?
<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
<civodul>wingo: oooh!
<wingo>lloda: it does print the arguments, no?
<civodul>so loading (texinfo reflection) installs the right thing for help as a side effect?
<civodul>didn't know that
<lloda>ah right, I hadn't seen that
<civodul>wonderful
<civodul>:-)
<wingo>civodul: right
<lloda>- Function: call-with-output-file file proc [#:binary] [#:encoding]
<lloda>
<lloda>great
<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
<lloda>module help is great
<lloda>another vote
<wingo>heh, ok :)
<wingo>it's an easy thing to turn on
<civodul>it would be ideal if it were autoloaded
<wingo>right
<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
<civodul>damn :-)
<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)
<civodul>in Guix there's 'find-files'
<jmd>Thanks ludo.
<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 ?
<jmd>Very likely.
<jemarch>hi
<wingo>meep meep
<civodul>hey hey!
<wingo>how goes? :)
<civodul>good good
<civodul>hacking guix, preparing for FOSDEM
<civodul>after that we should think about 2.1 i think
<davexunit>wingo aka roadrunner
<civodul>mark_weaver has been taking care of 2.0 ;-)
<civodul>heh
<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>yeah!
<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
<mark_weaver>what's the status of debugging in master?
<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>anyway, will do that
<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>yes that too
<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.
<wingo>yep
<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.
<civodul>mark_weaver: toooo much! :-)
<mark_weaver>heh, yeah, we'll see how much energy I have.
<wingo>:)
<wingo>utf8 strings would be swell
<mark_weaver>also, we need to replace our awful regexp stuff. I'm looking forward to SRFI-115, based on irregex.
<wingo>yeah!
<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.
<davexunit>whoa, srfi-115 looks really cool.
<wingo>mark_weaver, civodul: i have a silly idea
<civodul>go ahead :-)
<wingo>i want to remove tail arrays, but that is a hard problem -- the tail array size is embedded in make-struct
<mark_weaver>wingo: hmm ?
<wingo>so i was thinking about deprecating make-struct in 2.0
<wingo>and associated c functions
<civodul>hm!
<wingo>make-struct uses should be make-struct/no-tail
<wingo>and there would be new C functions
<civodul>aah
<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
<wingo>wdyt?
<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.
<civodul>yeah, that's a problem
<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
<mark_weaver>what would it buy us?
<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 :)
<civodul>which is a good thing, indeed ;-)
<wingo>heya bipt :)
<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 :)
<civodul>yeah
<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>okeydoke
<wingo>civodul: i'll get in the patch later this week
<civodul>ok!
<dsmith-work>Just looking at srfi-115. Using | for "or" really is ugly: |\\||
<mark_weaver>yeah, so use 'or' instead :)
<dsmith-work>Yep
<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 :)
<mark_weaver>okay, good night!
<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.
<mark_weaver>let me find the link.
<mark_weaver>civodul: http://lists.gnu.org/archive/html/guile-devel/2013-11/msg00056.html
<mark_weaver>I never looked into it, so I can't say more.
<unknown_lamer>ooo cassowary was ported from c++ to javascript
<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.
<dsmith-work>unknown_lamer: Interesting!