<rlb>mark_weaver: it still appears to block until you hit enter if you try the snippets there. <rlb>mark_weaver: no tangible progress wrt guile-cairo -- just chatted with wingo long enough to realize that we might need to shift to versioning all the guile add-on's, i.e. guile-2.0-cairo. <mark_weaver>rlb: I can reproduce the problem on my i686 Guix system, but it consistently works correctly on my mips64el Guix system. <rlb>I only tested current debian amd64 <mark_weaver>anyway, it's true that our signal handling isn't very good. <rlb>np -- I was just trying to determine if I should let that bug die with 1.6 or clone/reassign, and it sounds like the latter for now. <rlb>not a big deal -- thanks <mark_weaver>at while ago I looked closely at our signal handling and how to improve it, and ultimately got stuck on how little can be done portably in posix especially in multithreaded programs. *rlb is not at all surprised <rlb>issues like that likely help explain why the jvm is sometimes *so* LCD. <rlb>though I still think they should (have) take(en) the python route and have optional support in separate modules, i.e. "import os", etc. *rlb is glaring at symlinks (which are finally supported iirc), unix domain sockets, etc... <turbofail>seems to be an apt description of java's OS integration *dsmith-work was stuck at Liquid Crystal Display <rlb>there's debian kfreebsd... <rlb>passes all the tests there at least <rlb>(and hurd for that matter) <bipt>dsmith-work, taylanub has built guile on openbsd <zacts>mark_weaver: well, someone finished where I left off on FreeBSD <zacts>it is now an official FreeBSD port <zacts>the only thing I don't like about guile2 is that it relies upon having boehm-gc <zacts>also, I need to test if guile2 will build with the musl C library <zacts>other than that, I think that it's great that you guys have improved guile to be so portable and awesome <zacts>and guilemacs / guile-wm / etc.. these things are great too <zacts>so one suggestion(?) I have for guile devs is to consider letting the user build with an alternative garbage collector? If that is a possibility? <zacts>hm.. perhaps I have an uneducated bias, but the last MIT SICP lecture Sussman mentions about garbage collectors <zacts>and he recommends against having a large gc <zacts>boehm-gc has caused problems for me with porting, and it seems to be a bit bloated. <davexunit>I know of no other gc that can do what boehm-gc does. <zacts>sure, I will have to educate myself more on boehm-gc, so take my request for gc with a grain of salt, so to speak <zacts>fwiw, I believe that CHICKEN scheme and chibi scheme provide their own garbage collectors as an option. <zacts>but afaik they also allow you to use boehm-gc as an option <zacts>let me double check this, but that's from what I remember <zacts>but the musl c library + guile I can heavily recommend trying <mark_weaver>currently, boehm gc doesn't work properly with musl. <zacts>ah ok, well perhaps that would be an idea for wanting the possibility to build guile with a different gc <mark_weaver>I like the idea of supporting a moving GC as an option, but Boehm GC is unique in supporting arbitrary existing C code, which is a key goal for guile. <zacts>hm.. what about implementing a specific GC for guile which meets these same goals? <mark_weaver>any other GC option we provided would severely limit the C libraries that you could link with. <mark_weaver>and if we made another GC that met the same goals, it's unlikely that we could do any better (or even as well) as boehm GC does. <zacts>ah ok. yeah duplicated effort would be a waste, I guess. <mark_weaver>the limitations of boehm GC are a direct result of the severe limitations imposed on it by trying to support existing C code. <mark_weaver>zacts: what's wrong with Boehm GC? if there are problems that can be fixed, it makes sense to try to engage with that community to improve them. <zacts>mark_weaver: I need to truly educate myself on Boehm GC and GC, but my feeling is that it may be bloated code in comparison to other GC? Also, as you pointed out it doesn't currently build with musl. <mark_weaver>from my perspective, what I'd really like to see is an option to make allocation *much* cheaper, preferably just moving a per-thread allocation pointer. <zacts>but if boehm could be improved for musl, I would be happy. <mark_weaver>but that requires a moving GC, which requires precise GC which means that all C code needs to cooperate explicitly with the garbage collector. <bipt>(i'm not sure if the implementation ever reached production-quality; it's more interesting research than anything that could be practically adopted now, afaict) <zacts>mark_weaver: mainly this - 0) I need to educate myself on GC 1) I would like to see guile support musl. <mark_weaver>zacts: if you'd like to help with that, the best way to do so is to try to get boehm gc working with musl. currently, it fails its test suite, so it's easy to see the problems. <mark_weaver>specifically, we discovered that boehm GC wasn't able to find the C global variables. <zacts>I'll put that on my list of projects to do this semester <zacts>ok, about to head out for dinner, but yeah I'll see what I can do about testing boehm-gc + musl. <mark_weaver>zacts: okay, well, there you go! you have some patches to try out. I don't have a musl system on which to test. ***rlb` is now known as rlb
<mark_weaver>wingo: invoking a partial continuation should restore the dynamic environment (e.g. fluid values) that was in place when it was created (by abort-to-prompt), right? or am I mistaken? <civodul>actually maybe not because that would defeat composability <mark_weaver>would it? I guess it depends what you mean by "composability". <mark_weaver>you could still compose partial continuations, even if they restored their dynamic environments. <mark_weaver>anyway, what I'm really curious about is whether the existing literature on partial continuations has anything to say on this matter. <mark_weaver>I could read some papers to find out the answer, but I figured that wingo was already steeped in all of this, so maybe he could provide a quick and confident answer. <wingo>mark_weaver: it actually doesn't restore the same environment <wingo>it composes the bindings that were made in the continuation with the current dynamic environment <wingo>there is an excellent paper by matthew flatt on this topic <wingo>the delimited dynamic binding paper is also quite good <wingo>basically there are a number of possible things to do with dynamic bindings, but those authors argue for one approach, and that's the one that guile uses <mark_weaver>okay, thanks. does 'abort-to-prompt' unwind to the prompt? (invoking the exit thunks of dynamic winds) ? <wingo>flatt's paper is the one you want if you want info on dynamic-wind <wingo>kiselyov's paper is better for dynamic bindings <mark_weaver>is there an easy way to restore the dynamic environment when reinvoking a delimited continuation? <mark_weaver>i.e. if you really want to resume the computation where it was aborted, complete with its dynamic environment <wingo>are you just trying to avoid running dynamic-wind handlers? <mark_weaver>no, I'm wondering how to restart an aborted computation <wingo>yeah, not sure where you're going with this -- sounds like you want something more like threads and waiting? <wingo>i mean, not invoking dynamic-wind exit handlers introduces a form of concurrency in a program <mark_weaver>well, I'll read the papers rather than waste more of your time now. I should know this stuff anyway, and I know you're busy. thanks for the pointers! <mark_weaver>wingo: I understand now. This was an embarrassing gap in my knowledge, so I'm glad to have filled it in. <wingo>cool, always glad to share papers like those two :) <wingo>so one operator we might be missing would be a "capture a partial continuation without aborting" operator <wingo>that way you could avoid trampolining down to the prompt and thus avoid running dynamic-wind handlers <wingo>kiselyov likes to pretend dynamic-wind doesn't exist and i don't blame him ;) <mark_weaver>yes, that sounds like it might be worthwhile. do you have a use case? <wingo>it would be useful for green threads -- where you want to create a user-space concurrency model <wingo>that way you could have multiple threads of execution in one kernel thread... but tbh it's nebulous thoughts on my part <mark_weaver>well, it's worth thinking about, but right now I must sleep. I should have slept hours ago. <wingo>rest well & see you tomorrow :) <wingo>not sure where to fix that one <lloda>i'm worried about the compiler not being tested well enough though <civodul>lloda: we should start the 2.1 pre-release series to get more testing <wingo>probably we need something in the tree-il->cps pass to ensure that all primcalls are of an expected arity <civodul>but i think there were other big changes pending, potentially <wingo>i want the cps world to have no variadic primcalls <saul>FWIW, implementing cute as a procedure avoids the problem in that bug report. <saul>At least I think it would; I don't have -master installed to test. ***paroneay` is now known as paronayea
***paronayea is now known as paroneayea
<_wiz_>I'm trying to build guile-2.0.11 on NetBSD-7.99.1/x86_64, but it dumps core when generating the documentation. <_wiz_>[1] Broken pipe cat alist.doc ar... | <_wiz_> Abort trap (core dumped) GUILE_INSTALL_LO... <paroneayea>not urgent, but: is there a way in guile to do a "mock" procedure? <paroneayea>eg, where you temporarily override a function or gobal's definition for *all* modules, while a unit test is running or whatever, then set it back? <paroneayea>I'm guessing dynamic-unwind can handle the setting and setting back <paroneayea>but the "for all modules" is I guess the other question <taylanub>paroneayea: if it's a top-level, `module-set!' and such can do <taylanub>er, not sure if there's exactly `module-set!', but something in those lines <davexunit>paroneayea: I have a code snippet for you, one sec <davexunit>a primitive mock macro that I wrote for a guix test <davexunit>I would like to extend that in the future and perhaps make a library out of it. <davexunit>first I want to extend the macro so that you can mock many procedures in one form <davexunit>and then extend it to specify the acceptable input args and their associated return value(s) <_wiz_>I guess this is the first time the built guile is actually run. <dsmith-work>_wiz_: Generating the docs is the first time the just built guile is executed. <dsmith-work>_wiz_: I was just wondering about that a few hours ago. <civodul>_wiz_: does libgc's "make check" pass? <_wiz_>civodul: boehm-gc runs 10 self tests which succeed. "The test appears to have succeeded. <_wiz_>actually, there's more tests, that is just the last success message that's printed. <civodul>_wiz_: but the GC_is_visible abort hints at a libgc bug <civodul>if you look at libguile/gc.c:632, it just makes sure that a global variable is visible to the GC <civodul>and if it's not, things will go wrong <civodul>could you try a simple C program that does something similar, and see if it fails? <_wiz_>which of the GC_* calls before that do I need? <_wiz_>what variable type should I use as argument for GC_is_visible, is int fine? <civodul>it's an SCM (so a void *) in libguile, but that shouldn't make a difference <civodul>then you could try to make it more and more like what happens with libguile <civodul>so you could turn it into a shared library, etc. <_wiz_>same program with void * works fine too. <civodul>or you could try building Guile with --disable-shared <_wiz_>with --disable-shared, I get a step further <_wiz_>that's the error after --disable-shared. <_wiz_>do you want the older one as well? <_wiz_>the important ones are --without-threads --disable-shared <_wiz_>(there's also --prefix=/usr/pkg --build=x86_64--netbsd --host=x86_64--netbsd --mandir=/usr/pkg/man) <mark_weaver>it doesn't like the specified target, which maybe you provided explicitly. in particular, it doesn't like the empty string between the two dashes in your target triplet. <mark_weaver>_wiz_: have you tried simply not specifying the --build and --host arguments, and seeing what config.guess comes up with on your system? <_wiz_>I'm building inside pkgsrc, and this is what all GNU configure scripts get, but I can try without, let's see... <mark_weaver>it may be that we are stricter than we need to be in our target checks. <_wiz_>config.guess is stupid here :) 7.99.1 is too much. <mark_weaver>okay, I guess you should put 'unknown' in the middle <_wiz_>just FYI: having nothing in between worked with guile 1.6 and 1.8. <_wiz_>hm, build is now at "GUILEC ice-9/psyntax-pp.go" and takes a long time, with 7 guile processes eating 100% cpu each <mark_weaver>*nod* we have a compiler now that supports cross-compilation, so we need our own logic to comprehend the target triplet. <_wiz_>make that 8, and I'm building with -j 8. <mark_weaver>the first few modules take a long time to compile, because the compiler has not yet been compiled, so it's slowly interpreting the compiler to compile itself. <_wiz_>that sounds like parallel builds are not good? <mark_weaver>yeah, near the beginning especially, it's probably wasteful of cpu cycles to build in parallel. <_wiz_>that sounds like a dependency in the Makefile where all guile-compiled files depend on one big one that causes most of the compiler to be compiled would help <mark_weaver>well, the compiler is made up of a large number of modules, so we couldn't just add a single dependency. there would have to be lots of them. and then that has the unfortunate side effect of doing unnecessary rebuilds of many modules when you change others. <mark_weaver>I don't know if make has some nicer way to express this <_wiz_>can you explicitly make the compiler compile itself? <_wiz_>btw, I got redefinition warnings for LC_CTYPE_MASK, LC_COLLATE_MASK, LC_MESSAGES_MASK, LC_MONETARY_MASK, LC_NUMERIC_MASK, LC_TIME_MASK, and LC_TIME_MASK (i18n.c vs. /usr/include/locale.h) <mark_weaver>I guess you're suggesting that we reimplement make in guile? <_wiz_>I guess I probably don't know enough about this and am not making useful suggestions. ignore me :) <_wiz_>memoize.c:515:***Mismatching FUNC_NAME. Should be: `#define FUNC_NAME s_"@prompt"' <_wiz_>it finished compilation, now let's run 'make check'. <_wiz_>many UNRESOLVED, quite a few FAIL <_wiz_>30 failures, 49 unresolved, 1 untested, 16 unsupported <mark_weaver>can you paste the failures and unresolved tests somewhere? <_wiz_>the parts above that are all fine <mark_weaver>_wiz_: you could problem fix most of this by using GNU libiconv <mark_weaver>and maybe building libunistring against GNU libiconv as well <_wiz_>ok. are these critical or just nice-to-have? <mark_weaver>I think this guile won't work very well for non-ASCII locales <_wiz_>ok, I'll try again with GNU libiconv. <mark_weaver>it will probably be important for libunistring to also be built against GNU libiconv. <_wiz_>can you, from looking at the paste, say which areas of libiconv need more work? <mark_weaver>_wiz_: the number of test failures related to iconv is rather overwhelming. it will require some investigation. <mark_weaver>I seem to recall a few problems with freebsd iconv, but nowhere near so many. <mark_weaver>_wiz_: regarding UNRESOLVED, a lot of those are because of tests that rely on the use of threads to perform the test <mark_weaver>_wiz_: it may be that your iconv doesn't report encoding errors properly, or perhaps there's some other problem that's preventing guile from reading the test suite's own UTF-8-encoded source files properly. <mark_weaver>or maybe we're making unportable assumptions about iconv. <_wiz_> /usr/obj/wip/guile2/work/guile-2.0.11/libguile/.libs/libguile-2.0.so: undefined reference to `uselocale' <_wiz_>oatch I'm using for that is at <_wiz_>huh? GC_is_visible test failed <_wiz_>yes, I see it in the config.log: <_wiz_> $ ./configure --prefix=/usr/pkg --mandir=/usr/pkg/man --infodir=/usr/pkg/info --disable-shared --without-threads <mark_weaver>what version of libgc are you using? it seems to be broken on your platform. <_wiz_>7.4.2. its self tests are happy. <mark_weaver>well, that message indicates that libgc is unable to see (and therefore won't mark) a C static variable. <mark_weaver>so it seems that libgc is not reliably able to find the DATA/BSS sections <mark_weaver>search for "GC_is_visible" in libguile/gc.c to see the test. <_wiz_>yes. I wrote a small program to test it outside of guile, on civodul's prompting. <_wiz_>this works consistently fine and exits 0. <mark_weaver>and no doubt the libgc test suite does something similar, so sometimes it works, but it's not working reliably. <mark_weaver>if you look at the sanity check we do, it's hard to see how that could be a guile problem. <_wiz_>I must confess I'm a bit discouraged now, because it worked and now it doesn't again. <_wiz_>anyway, when I'm motivated again I'll try talking to gc. <civodul>yeah i browse HN via Gwene and i was surprised to see that ;-) <paroneayea>hm, I think writing documents in sexps is not for me. <davexunit>yeah, I'm unsure about it, but I should give it a shot first. <paroneayea>I think when it comes to plaintext with things to read, I like the "text with embedded expressions" rather than "expressions with embedded text" route <paroneayea>might be cool to write things that transform to skriblio though as a median language <civodul>or Texinfo with Guile's texinfo modules *tadni_ still heeds to play with skribilo, seems like a really interesting concept. <pecg>I want to know if guile is suitable to write dynamic web programs with normal SQL database access <davexunit>pecg: yeah, some of us have done that sort of thing. <davexunit>guile has some built-in http modules, for https there's guile bindings for gnutls. <davexunit>for rendering HTML, guile comes with sxml modules <davexunit>there's a third-party library called guile-json for (de)serialization of JSON <davexunit>guile doesn't have the plethora of web development libraries that ruby/python/php has, but the essentials are there. <pecg>davexunit: So it is possible to write a program that queries some postgres database and then insert things and all that stuff. <pecg>I'm asking this, because I want to generate HTML without writing awful tags <davexunit>look up the SXML procedures in the guile manual. <pecg>I read in the Reference Manual that there is a built in http-server, and I wonder if it supports scheme directly <pecg>As nginx supports php and so on <pecg>I know common lisp implementations have some more wide software to choose from, but I prefer scheme implementations because of minimalism and other things.. <pecg>I picked up guile because of scheme and its power to be extensible. <pecg>It is also the official gnu language for extensions <pecg>Great. Think I'll fork it in some days <pecg>Since I'm newbie in this scheme new world, and I certainly feel amazed by it, I wonder if I can compile directly to and executable using only *.scm files with guile's compiler <pecg>So I can build portable programs for the desktop too. <pecg>davexunit: But I can compile to C, right? Like Chicken (another scheme implementation) does <pecg>(generating C code is not compiling, my mistake) <pecg>And of course that the Guile's VM is portable <pecg>You've been very helpful <mark_weaver>generating C from Scheme actually _would_ be called "compiling". Compiling is appropriate whenever you convert from one language to another. <pecg>I thought compiling is the process of converting source (human readable) code into binaries <pecg>mark_weaver: So what is parsing? <mark_weaver>well, as I recall, the so-called "dragon book" by Aho, Sethi and Ullman, which was the classic textbook about writing compilers from over 20 years ago, defined it more-or-less that way. <mark_weaver>if you look around, you'll see the term "compiler" used to describe many programs that generate portable C. <mark_weaver>anyway, it's not important. I'm sorry if I came across as snippy, I didn't mean to. just clarifying. <pecg>mark_weaver: It's ok man, thanks for clarifying, but take it easy this is not an inquisition or ditactorship <pecg>Everyone is free to comment and help others. <mark_weaver>if we were talking in person, you'd see that it was just a friendly comment, but sometimes it's harder to read the tone in text-only. <pecg>mark_weaver: It's ok, I'm very used to IRC conversations.. <pecg>I think people who easily get offended have problems, real ones inside of themselves <mark_weaver>but take Chicken Scheme or Gambit C as two examples that describe themselves as compilers even though they generate C. <pecg>davexunit, mark_weaver: Do you know if SICP book is a goof way for learning scheme, at least for starting the path <pecg>mark_weaver: I think you are right <davexunit>pecg: "the little schemer" might be a better first book <pecg>mark_weaver: That seems completely logical to me know <mark_weaver>SICP is a great book and highly recommended, but just keep in mind that it uses a very old version of scheme that lacks many of the features we like to use today. <pecg>davexunit: Consider I already know how to program <paroneayea>"the little schemer" is great, though really more interested in learning recursion/scheme minimalism in some ways than learning a modern scheme <paroneayea>and if you want to get going doing Real Things fast, it's probably not the right book (though a book worth doing anyway!) <mark_weaver>pecg: fwiw, I read SICP after having been a professional programmer for about 15 years, and it made a huge impression on me. really changed the way I think about programming forever. <pecg>mark_weaver: Hahahahah ok <pecg>mark_weaver: I'm a very nostalgic person, and I want to feel scheme evolving in my head, that's the reason I want to read SICP, for getting the feeling of being in the 80's <mark_weaver>one of my computers has a UK keyboard with a layout different than I'm used to, and now when I try to type on a US keyboard I often hit the enter key while I'm going for double quote. <mark_weaver>pecg: and if you watch the accompanying SICP video lectures from the 80s, you'll see them occasionally using a computer that looks like it belongs in a museum :) <davexunit>mark_weaver: that x60 UK keyboard layout is maddening <mark_weaver>one thing about SICP: it's aimed at MIT freshmen engineering students, so among other things it assumes you are comfortable with calculus. <pecg>davexunit: The US version of the x60 is better in that sense <davexunit>I was given one to use during my interview at the FSF <pecg>mark_weaver: Going to have to refresh knowledge in math <pecg>After all most of the early programmers were mathematicians <pecg>davexunit: Do you work at FSF? <tadni_>pecg: Do you have a background in programming, or would Scheme be your first lang? <paroneayea>I think my biggest restriction as a programmer is how my math education got cut short :\\ <paroneayea>maybe it's time to retake calculus in some night classes or something. <tadni_>paroneayea: What did you take? My UNI does up to calc3, psychics 2, etc. <paroneayea>tadni_: I was on calc 2, but then some really bad events in my life happened, and I dropped out due to depression <paroneayea>the larger university that bought my smaller college shut it down, and I had worked very hard as an activist to keep it open. I was very depressed. <tadni_>Yeah, if you feel it is a limiting factor -- I'd probably try nightclasses or something. <taylanub>paroneayea: I think any motivated person can self-educate well enough on such abstract fields where you have the world literature on your monitor and need no other tools. one can ask IRC too on many things. AFAIK ##math is OK. <paroneayea>taylanub: yeah, I have taught myself most subjects as I've needed them <paroneayea>but it kind of builds up an imposter syndrome feeling <paroneayea>emacs calc has helped a lot! I love playing with numbers in it. <pecg>tadni_: I have a background in C and C++ (object-oriented) and some php. <mark_weaver>there's plenty of programming that can be done quite competently without much knowledge of math <pecg>mark_weaver: But I think math gives the sense of the magic that means programming <mark_weaver>(I speak as someone who is fairly strong at math, strong enough to have write access to the maxima git repo) <pecg>mark_weaver: A long time ago, I wanted to learn lisp, and decided to start with something simple emacs-lisp <pecg>Emacs lisp is great for beginners, because you can learn running code inside of Emacs <pecg>I'm learning general list concepts by reading books. <pecg>paroneayea: Emacs is awesome.. <pecg>paroneayea: With it you can mostly do whatever you want, except threading, but I read somewhere that the plan is to replace elisp with guile <paroneayea>I heard there was some thread about that recently! ;) <pecg>I actually learn by reading books, and reference manual... <pecg>I started watching the SICP videos from ~1986 and I can firmly say that someone without knowing anything about programming, can learn lisp that way <pecg>Or maybe reading 'An Introduction to Programming in Emacs Lisp' would be a better way <pecg>paroneayea: They are old, but who doesn't love old stuff <pecg>(I would love to put my hands in a PDP <pecg>I like how Hal talks about computer science is not a science at all, and how to abstract processes <pecg>paroneayea: I can assure you that you will learn a lot by watching those guys talk. <pecg>What I like about mathematics is that they are so closely related to philosophy that you almost can form a theory of anything with math theorems <taylanub>pecg: I maintain this very brief and "bottom-up" Scheme/Lisp intro for people who are already programmers but know nothing of lisp: http://taylanub.github.io/doc/lisp-rundown.txt I really don't know how good it is; the "bottom up" approach might be bad. if you want to try it out, comments welcome. <pecg>taylanub: I can suggest you not to use github, since it requires proprietary js <taylanub>pecg: I use Gitorious for source code, but the "GitHub Pages" features is neat, allowing me to host arbitrary static HTML and other files <tadni_`>taylanub: Yeah, the "github pages" thing is the only reason I'm currently on github. <pecg>tadni_`, taylanub: But you can do the same thing in savannah <tadni_`>By the beginning of next year though, I plan on just hosting my own linode instance of gitlab and running a proper webserver for a blog though. <tadni_`>pecg: Savannah is a horribly ugly mess to work with though. <pecg>tadni_`: I plan to do that too, but I want to get a computer to self-host my sites <tadni_`>Whatever happened to that french guy, working on the savannah rewrite...? <davexunit>upgrading savannah is going to be a nightmare not only technically, but politically <tadni_`>davexunit: I mean, assuming it supports all the features of current savane, why does it matter really? <davexunit>some of the people that weigh in are convinced that savannah is just fine <davexunit>and that there's no alternative because nothing has all the features <tadni_`>That seems like a fun project, to mess with, at some point. <tadni_`>davexunit: I mean, working on a modern clone. <tadni_`>Someone was, like I said, a few years back, some french guy, can't remember his nick. <davexunit>I would rather switch to something that had less features, but was actively maintained. <pecg>tadni_`: Maybe we need a more polished interface, among other things <davexunit>something that makes people think that GNU isn't a relic from the 90s. <tadni_`>pecg: Well, I would group an improved interface into a base feature of a "modren clone". <tadni_`>Clone in the sense of function, not actual usabiltiy 1:1. <pecg>I think that's the reason some people is using gitorious... <davexunit>but opinions are strong, and thus progress moves at the speed of molasses. <pecg>Savannah doesn't seem great at the moment <pecg>I would prefer mercurial over git though <tadni_`>pecg: For personal projects, I would not even really consider using nongnu.org's instance for anything. <davexunit>I use gitorious, but I'm tempted to host my own gitlab