***ft_ is now known as ft
*nalaginrut realized (system vm assembler) is to assemble cps to bytecode, not native code <nalaginrut>oops, (system vm assembler) is a generic assembler framework, could be used for any binary code generation <nalaginrut>hmm...maybe not so generic at present, I saw guile-compose rewrite an assembler based on it <nalaginrut>it's amazing that guile-compost reached a very high performance for code execution, it's reasonable to expect the future AOT compiler will make Artanis a real 'fastest' framework in Scheme land... *wingo changes details about cps yet again <ArneBab>wingo: good that it’s not yet released so no one started relying on details? <wingo>we could have a prerelease already; just that i keep getting distracted by optimizations, and frustrated with compiler slowness :P <wingo>just a couple of things that really need to get done, but the language need to change in order to support closure optimizations <taylanub>civodul: WDYT about the thread initialization topic; can we really guarantee that thread initialization (stuff happening after a successful pthread_create) will always succeed ? (Ignoring extreme cases like out-of-memory.) <taylanub>(After removing the pipe2() there, that is.) <ArneBab>wingo: I wouldn’t think of complaining ☺ <ArneBab>Sidenote: found his first *productive* use of wisp today (productive as in I use it for my PhD): Using it as the lowest typing overhead set matcher I can think of: <ArneBab>checksites sites2010 ' : bkt bme bmw bra brw <ArneBab>this just checks which of the 3-letter-acronyms match observation sites I want to assimilate. <ArneBab>but I think I never managed to create anything in a real programming language which has lower syntax-overhead. <ArneBab>(and checking the next batch is just a matter of pressing the up arrow and typing in the next acronyms. <ArneBab>all this in the REPL - thanks to the extensibility of Guiles reader <ArneBab>thank you all for helping me to get this working! <taylanub>Hrm, I thought the reader doesn't use string->number, apparently it does; this could simplify the test-suite a bit. <civodul>taylanub: we can't guarantee that, and i agree that it sucks to abort <civodul>wingo: great that you removed mark/free functions <didi>jcca: Your test case return 128? <taylanub>jcca: tip: Scheme conventionally doesn't use camelCaps, but instead dashed-names <jcca>didi: yes. I want to know if it is possible to write it in less lines <didi>jcca: Maybe. I'm trying to understand the algorithm. <jcca>Thanks. I'm not sure if I wrote well. <taylanub>jcca: A somewhat more idiomatic version would 1) probably use vectors, not lists (lists aren't like arrays), 2) use a "named-let" or other functional looping construct instead of a `for-each' that `set!'s a value. http://sprunge.us/KAFG <taylanub>jcca: You generally don't use `set!' in Scheme. <taylanub>(Maybe "generally" is exaggerating it, but you certainly use it less often than in mostly-imperative languages.) <didi>jcca: Is this the sequence of js?: 5, 0, 1, 2, 3, 4? *taylanub didn't really pay attention to the algo, just rewrote it to typical Scheme, checked whether it still gives the same result :P <jcca>I am new in scheme, so I am trying to understand <wingo>civodul: there are still some free functions left, but that at least is more sensible than mark functions *taylanub is trying to find out why (string->number "#i1@-0") would eval to 1.0+0.0i (instead of 1.0-0.0i) .. string->number doesn't seem to be actually using GNU MP ? <didi>Can I take docstrings out of syntax like I can with `procedure-documentation' in procedures? <didi>Hum, I guess (procedure-documentation (macro-transformer (module-ref (current-module) 'case))) is a way. <didi>Hum, `procedure-documentation' is returning #f for every procedure I try. *didi .oO( something is not right ) <ijp>didi: try object-documentation <ijp>there is a difference, but don't ask me what it is <didi>ijp@: I don't have `object-documentation', but I found procedures which return documentations, so I guess it's just that some of them have any, like + or -. <didi>(procedure-documentation +) => #f <ijp>(ice-9 documentation) <didi>I would say, "let's document it", but you know it already. <mark_weaver>I think the better solution is to make 'procedure-documentation' work properly. <mark_weaver>our built-in documentation system is in need of love <taylanub>mark_weaver: While you're here, let me ask you: do I need to synchronize two threads when they're merely reading the fields of some struct ? <mark_weaver>you must establish a "happens-before" relationship between the writes to those locations and the reads. <mark_weaver>multiple readers from the same location are not any more of a problem than single readers are. <ijp>mark_weaver: is it possible for a variable to have a value other than the value before/after a set? <ijp>so if you have a=10, and in thread 1 you read a, and in thread 2 you (set! a 20), can you always guarantee, without locking, that a is 10 or 20 ? <ijp>I didn't think so, but I am no expert on these matters <ijp>right now my mind is focussed on juggling 5 balls rather than threading <taylanub>In my case, one thread only reads while it holds the lock; the other only writes while it holds the lock, and sometimes reads without holding the lock. If I get it right this is fine. <mark_weaver>as I said, you must establish a "happens-before" relationship between the write and the read. <mark_weaver>unless you can prove that the write happens in the same thread as the read, that means you need all reads to happen within a lock as well. <mark_weaver>(or use barriers, but we don't expose those to Scheme, and they have only been standardized in C11) <mark_weaver>and anyway, you'd still need to use barriers before the reads. <taylanub>I might've been unclear: there is only one thread ever writing to the field, and that's also the only thread that reads without locking. It writes via locking, and others read via locking. <mark_weaver>I'd love to win a free novena laptop, but I suspect that my chances of winning the contest are sufficiently low that I'll spend my time elsewhere :) *mark_weaver suspects that anyone with an FPGA will have a significant advantage over anyone who doesn't. <mark_weaver>(assuming equal knowledge of the relevant algorithms)