***impaktor is now known as Hodor
***Hodor is now known as impaktor
<alezost>hi guys, could someone explain why (let ((ls '(1))) (set-cdr! ls '(2)) (cdr ls)) returns `()' and not `(2)'? <alezost>I mean is it normal? As (let ((ls '(1))) (set-cdr! ls '(2)) ls) returns `(1 2)' as expected <mark_weaver>ideally, we would detect that and raise an error, but currently we don't. however, the compiler assumes that you won't do this. <mark_weaver>change '(1) to (list 1) and then the code is legal and should work. <alezost>mark_weaver: thank you very much, now I understand <mark_weaver>np! I think it might be the case that we detect this error in guile 2.2. <nalaginrut>oh, my, it's so hard to eliminate all reduce/reduce conflicts... <wingo>,locals works in master now! <affds>wingo: I've just implemented the fold I was asking about yesterday. If you care, I can share. <affds>okay, will paste in a second. <wingo>you might want to use lset-adjoin instead of cons, if you want to avoid delete-duplicates <wingo>ahh, so much better to debug with a working ,locals *wingo building a test version of guile that doesn't preserve the closure and argument slots <stis>wingo: \\o/ great news, re ,locals! <ArneBab>ijp: IIRC you said that GOOPS is not quite the OOP system you would like to have. So, would you be interested in writing one or two paragraphs on implementing OOP systems in guile? (for py2guile “beyond Python”: http://draketo.de/proj/py2guile/#sec-6 ) <ArneBab>ijp: IIRC you said that GOOPS is not quite the OOP system you would like to have. So, would you be interested in writing one or two paragraphs on implementing OOP systems in guile? (for py2guile “beyond Python”: http://draketo.de/proj/py2guile/#sec-6 ) <didi>ArneBab: ijp is not here. <wingo>ok, so guile master no longer keeps the closure slot nor the arguments alive if not needed <wingo>it freely reallocates those slots to other things <wingo>i reckon it's the right thing, though i always fought it on debugging grounds <wingo>but now that we have local var information we can at least know when an argument is still live and when it isn't <mark_weaver>nice! does it also prevent the garbage collector from marking those slots if they are dead? <wingo>mark_weaver: it does if they aren't the top call-frame <wingo>i mean, any frame that is not the top frame is waiting for a return <wingo>and there are few of those points <wingo>and guile already serializes a "live slot map" for those points <wingo>but before it would always treat the closure and argument slots as live <mark_weaver>hmm, interesting. does "top frame" mean the first frame since the <wingo>"top" is "most recently pushed" <wingo>well it's easy to confuse, what with the different conventions :) <mark_weaver>well, I think this is the right thing. for example, it presumably means that recursive 'map' and 'for-each' doesn't keep the start of the input list alive, right? <wingo>yeah that's a happy thing :) <mark_weaver>you've been on quite a roll lately! I really should shift my focus to master very soon :) <wingo>i will switch over the map implementation to be recursive soon, as the perf is pretty good -- still marginally slower on this machine because marking the stack is the biggest time, and that is serial -- at least for big lists <wingo>so you don't get the parallel marking advantages <wingo>just iterating to a fixed point :) <wingo>the only remaining TODO would be functions with more than N live locals <wingo>where N is dependent on what you are doing <wingo>need to implement shuffling in that case <wingo>but tbh except for the (vector ...) and (list ...) cases i haven't run into it <mark_weaver>I can't make sense of that without knowing what N is. <wingo>wondering how to test that properly <wingo>mark_weaver: like if there's a VM op that has one arg that only has 8 bits allocated to it <wingo>currently with the compiler compiled, compiling stable-2.0's boot-9.scm with stable-2.0's compiler takes 2.29s for me, and compiling master's boot-9 with master takes 3.25s <wingo>i would hope for something better but in the end the compiler is doing more work :/ <wingo>i guess we put off the win until native compilation <mark_weaver>most users will get a precompiled guile from their distro anyway. <wingo>that's probably good advice, though it still bothers me :) <mark_weaver>on the other end, those who build from 'git' rarely have to build from scratch. <mark_weaver>on the other end of the spectrum, those who build from 'git' rarely have to build from scratch. <mark_weaver>and we could always distribute precompiled .go files in a separate tarball if there's enough demand for it. <taylanub>a compiled compiler only takes 3 seconds to build what takes about 20 minutes otherwise, did I get that right ? <wingo>taylanub: that's just compiling one file <taylanub>oh yeah, though I reckon boot-9 is one of the longer taking files, no ? IIRC psyntax was the longest <wingo>psyntax is not the longest any more; for some reason (system vm assembler) takes a terrible long time <taylanub>ok .. in any case I think it would be neat to ship something precompiled if it will make the compilation that much faster. recompiling everything might be rare but when it happens it's a total PITA :( <mark_weaver>wingo: we still need to deal with the page size issue. we could either maintain some database of maximum architectural page sizes for different platforms, or we could just use 64K uniformly for now. WDYT? <wingo>mark_weaver: 64k is fine with me fwiw <wingo>we can refine later if needed <tupi>wingo: clutter-support.c lines 150 -> 153 use scm_to_uint8, should it not be scm_to_double ? <wingo>tupi: indeed! please commit to fix :) <tupi>git [sometimes] gives me false changes. here is an example http://paste.lisp.org/display/142062 where I only performedchanged the original file according to the last diff reported changes [ @@ -146,11 +146,11 @@ ClutterMargin* ]: any idea why? <tupi>i guess it's this emacs setting: (add-hook 'before-save-hook 'delete-trailing-whitespace), don't you also have this setting ? <tupi>git diff --ignore-space-change ... now I need to find how to make this a global git setting <tupi>I can't find a way to globably configure git so it --ignore-space-change, any idea? <mark_weaver>tupi: even if you configured 'git diff' to ignore space changes, it wouldn't change the fact that you'd be checking in a new copy with space changes, and other people using git would see those changes. <mark_weaver>tupi: I think most of us do not have that emacs setting, and you should find a way to disable it when working on upstream projects. <davexunit>tupi: I work with this setting since it's what I want most of the time, but when working with upstream projects, I am careful to make sure such things don't make it into my patches. <mark_weaver>the problem with setting that option globally is that it might lead to large whitespaces changes being committed to the upstream without tupi realizing it. <mark_weaver>iirc, ttn suggested doing a massive set of changes to guile long ago to make all the whitespace consistent, and the idea was rejected. <mark_weaver>I'm not necessarily opposed to the ttn's idea, but it should at least be discussed again before we start making large whitespace-change commits. <mark_weaver>tupi: if you want to discuss it on the list, that's fine with me, but please don't commit large whitespace changes to the repo without asking first. therefore, you shouldn't configure git to hide these whitespace changes from you by default. <tupi>reading now all answers, tx all <tupi>mark_weaver: I am happy to conform to what you guys do (and would not have commited even a single white-space-change only, this is why I'm asking). I did configure emacs because like davexunit, that's what i want for my projects. It really sounds strange to me though that we can't globally ask git not to consider white space changes: I don't know how to ask emacs not to apply this setting for upstream projects <tupi>davexunit: how do handle the problem then? <tupi>how do you " careful to make sure such things don't make it into my patches" ? <davexunit>tupi: in a very dumb way. I use magit and selectively choose what parts of a diff to commit and revert the whitespace changes. <davexunit>what I should do is remove the hook under certain conditions. <tupi>yes, the latter is what I'm looking for, any idea? a list of directories maybe? <dfddd>Is there a flag that would warn me about unused imports? <wingo>you mean modules you have imported but not used?