<fangism>hi all, i have a user reporting build issues with __scm.h on xcode 5, with a proposed patch here http://pastebin.com/71LVmfYy . Does that look safe? What is the impact of blanking SCM_NORETURN? <fangism>$user (howarth) reports that that patch lets guile20 and autogen-5.18.2 build on xcode 4.6+ on 10.7+ (clang 3.3+) <alexei>clang 2.9 < 3.3 but your ifdef thiks otherwise. See SCM_GNUC_PREREQ(maj, min) <fangism>alexei: maybe we need something for SCM_CLANG_PREREQ? <alexei>that would be a proper way to compare versions, yes. But if it already works for you ... <fangism>unfortunately, apple decided to give its own clang version numbering, since they release on their own schedule, so you'd also probably want to define SCM_APPLE_CLANG_PREREQ. Yuck. <fangism>and also that clang pretends to be gcc 4.2 (defining __GNUC__ and __GNUC_MINOR__) <mark_weaver>fangism: I'm confused by that proposed patch. Does clang define __GNUC__ but fail to support __attribute__ ((noreturn)) ? <fangism>I think what happened was that noreturn was #defined to something else, which broke compilation <fangism>in a header like noreturn.h, provided by clang <mark_weaver>I also really don't understand the logic of those version comparisons. <mark_weaver>why is __apple_build_version__ relevant to comparing the version numbers? <mark_weaver>and why is __clang_minor__ being checked at all if __clang_major__ is less than 3? <fangism>starting with clang 3.3, clang provides include/stdnoreturn.h <mark_weaver>I could understand something like ((__clang_major__ < 3) || ((__clang_major__ == 3) && (__clang_minor__ < 3))) <fangism>maybe we don't need apple's versioning after all? apple tends to release clang between upstream version releases <mark_weaver>anyway, if it's really needed, I think a better solution would be to add an autoconf test. <mark_weaver>this version comparison stuff, especially when the version depends on whether it's an apple build, is not a good solution. <fangism>i completely agree with autoconf detection <mark_weaver>maybe we can solve this by including that gnulib module and using it to specify the noreturn attribute somehow. <alexei>it is a prefix tough. and "noreturn" should only be defined if one #include <stdnoreturn.h>. Why does clang #define it? <fangism>it finds that header somewhere in the compilation chain <mark_weaver>looking at the GCC docs, it appears that we could use __noreturn__ instead of noreturn. <fangism>mark_weaver: why rename the attribute to __noreturn__? does that actually work for gcc? <fangism>i have a configure test for __attribute__((noreturn)), nothing for __noreturn__ <mark_weaver>fangism: the GCC docs say that any function attribute can be used with two underscores before and after. they even give __noreturn__ as an example. <mark_weaver>so I think there's probably no need for the configure test. <mark_weaver>actually, this is better anyway, because it means that old clang will continue to be told that these functions don't return, whereas both the proposed patch and the configure test would result in those noreturn attributes simply being omitted. <fangism>mark_weaver: ok, i never knew about the extra underscores. <dje42>The extra underscores are there because __foo is in the reserved namespace for compilers. I can legitimately have #define noreturn 42 in my program, but I can't legitimately have #define __noreturn__ 42. <b4283>nalaginrut: i could define it and retrieve the value <b4283>nalaginrut: sorry, i misunderstood <mark_weaver>b4283: yes, you can define it, but if you do so you are outside of the realm of defined behavior. <b4283>what i did was (define __asm__ 1) <nalaginrut>if it's a var, maybe cause interfere, but for special compiler defined symbol, maybe cause error ***Shozan is now known as SHODAN
<TaylanUB>Help me understand psyntax.scm .. is this basically a translator from syntax-case-supporting Scheme to more primitive Scheme ? It's part of the Scheme implementation and could be written in any other language ? <wingo>sorta; the output of macro-expansion isn't quite scheme <wingo>see "the scheme compiler" in the manual <TaylanUB>Oh, so it's psyntax that outputs tree-il, meaning it's *the* topmost component of our Scheme front-end ? <TaylanUB>I always thought it's something "on the side", adding syntax-case support. <wingo>is that a question? i think i just answered it :) <TaylanUB>Well (info "(guile) The Scheme Compiler") doesn't mention psyntax, but I see it's kind of implied that it's psyntax. <wingo>why would it mention psyntax? <wingo>i recommend you read boot-9.scm <TaylanUB>Isn't psyntax.scm basically *the* Scheme->Tree-IL compiler that's being talked about in that Info node ?.. <stis>nice work wingo: and thx for another nice writeup on your blog! <stis>so will we just stabilize the current rtl codebase and relese a new version, what is remaining? <wingo>about 35 failing tests out of the 40000 <stis>Cool!, ok! sounds like a goodd plan! <wingo>once all is fixed, commit to master, start removing the old stuff <wingo>updating docs, tweaking things, etc <mark_weaver>fwiw, I'd like to get a few other things in before 2.2 is released. <stis>Hmm, can you may point to a repo and I could test it out with guile-log etc, or are there still some shjow stoppers? <mark_weaver>we're only able to make ABI changes once every several years, and it would be good to take advantage of that. <wingo>mark_weaver: yes there's time <wingo>i expect we have the usual dozen prereleases... <wingo>stis: wip-rtl-halloween in git <ijp>is it possible for there to be a circular syntax object? <wingo>ijp: the datum can be circular, yes <wingo>istr that from a dybvig comment or paper or something <ijp>I suppose if we have circular literals, we must do <mark_weaver>I think we don't yet support circular read syntax, although there's no reason we couldn't. <ijp>well, I was just thinking about my define-macro change, and I know I need to handle circulars in the output of define-macro (because arbitrary code), and was wanting to doublecheck input <mark_weaver>I don't know how our current psyntax would cope with circular datums, or worse, circular code. <ijp>I have no idea either <wingo>dunno; it was designed to work with circular datums tho <mark_weaver>that's good. so even if some of the local changes we've made since Dybvig don't handle circular datums properly, at least the core algorithms should work. *stis is compiling the srfis with wip-rtl-halloween <wingo>the assembler emits too many labels <wingo>and does so with n^2 algorithms <wingo>that's the majority of the compilation slowness, amusingly <wingo>and they all get written into the .go i think <wingo>anyway, lots of low-hanging fruit <stis>yae, usually at this stage I would suspect that oneneed to clean up the low hanging fruits <ijp><fsbot> muahahahahah muhahah hahahah haha <wingo>ijp: you have not shared the definition of that repl command! <stis>guile-syntax-parse compiles just fine <stis>Hmm the racket matcher takes really really long time to compile, 30s at the moment <wingo>yeah that's the labels n^2 thing i was talking about <wingo>i want to add some debugging printouts if you have an env var set to show which parts of compilation are taking what amount of time <stis>racket matcher compiled! <wingo>so that we see the numbers and can improve them <stis>The racket match go file is no 1.3M in stead to 500k <wingo>yes they will be slightly larger, though i think we should be able to improve a bit <wingo>still, unlike the old vm most is not loaded <wingo>and it includes some space for things that would be on the heap in 2.0 <stis>when compiled it loads emediately <stis>looks like you are right there <stis>no that's the same, but the compile just take 2-5 seconds. <wingo>yeah that needs to get better <stis>wingo: will it install in guile-2.2 ? <wingo>stis: yes; though the binary is still called "guile" <wingo>the binary and the info file conflict <wingo>everything else is parallel installable <wingo>also mem usage is a bit high right now because of the stack, which is larger than in 2.0, but mallocated instead of mmaped <wingo>but don't benchmark memory right now <wingo>i had to expand it because of some recursive cps traversals; will fix somehow eventually <stis>It does about 50M iterations on a simple loop <wingo>and will change to mmap instead of malloc <wingo>iterations of what, in what time? <stis>(define (f n) (let lp ((x n) (s 0)) (if (> x 0) (lp (- x 1) (+ x s)) s))) <stis>It can be a little more efficient looging at the assembler <stis>But sure this is for 2.2.1-x <wingo>perhaps my machine is slower <wingo>yes with better register allocation and rotating the loop so the conditional branch is at the end i guess we could get 150M or so <stis>I doubled checked, yea my takes 1 sec and I'm on a workstation <wingo>then with naive native compilation i think 700M or so is reasonable <wingo>ah yes, i have an -O0 compile atm :) <wingo>i think probably there are things that can be done in the vm also <wingo>also i was running a normal repl, which has hooks at every instruction <wingo>run with --no-debug to avoid that <stis>yes 2x is well explained by that from my experience. <wingo>if at some point we can do a silly loop like in 1e9 iterations per second we can call our work finished :) <wingo>so right now we do 5e7, good to know <stis>Yeah and relax on type unboxing JIT etc and just say that we are fast and point to that ;-) <wingo>actually with --no-debug here it is 6.5e7 iterations/s <stis>hmm I would say that our first version of native will reach 200-300M and if we do good register allocation 500M <stis>the rest needs number unboxing to reach 1G <stis>then we can boost the compiler to use n(n+1)/2 and we will go to warp 100. <wingo>34 failures, 1 upass, 3 errors *dsmith-work cheers wingo on *ijp dresses up in a giant gnu costume, and starts pumping the audience up *tupi is dreaming about delivering executables [Kisê, and many others ...] <wingo>tupi: it's possible to think about; bundle the guile version + bundle-o-scheme-files-linked-together <wingo>would be nice to get .go bundling in guile, to avoid the stat penalty on startup <wingo>that would also relieve some pressure to shunt everything into boot-9 <wingo>startup right now is 7 ms or so on this machine, fwiw <tupi>wingo: that will alow us to 'copete' with other languages. of course it will include guile-gnome, guile-clutter ... but the executable size is not a problem [as far as i am concerned] <wingo>shared libraries are a problem in that context, but there are many possible solutions <wingo>anyway i would like to be able to ship executables, and elf helps there <wingo>but there is still some work to be done :) <wingo>btw tupi have you done a copyright assignment with the fsf? <wingo>i was going to add you to guile-gnome the other day (jeez, a long time ago) but i didn't find the assignment on file <tupi>wingo: no, but of course I can [i should] <wingo>yes let me send you the thing <tupi>[still work to do...] sure, but the dream is even better knowing that it will turn real some day .. <tupi>mark_weaver: any progress on popen thread safe issue ? <tupi>i have ask our client to allow remote access through 3g, hope it will be accepted [i really need it too...] if that is the case, i will create an account [you'll send me your shh public key] and ... it should help you greatly to test your thought ... and solution to the problem <wingo>i have been ignoring my personal email for like 3 months now <wingo>it is a terrible, terrible thing <wingo>the guile 2.2 compiler made everything else swap out <tupi>wingo: it's ok, i think. i really would lke a guile-gnome [gtk3] and ... but i am patient <tupi>i have to write a gui prototype [the lower level stuff now runs fine [when the thread safe bug ...] and since we don't have guile-clutter-gtk yet, i think i will try to make to guile instances [guile-gnome and another guile-clutter] talk to each other, a la geiser' ... <tupi>wingo: did you send a 'private' email? i did not receive anything [yet] <wingo>i think i sent a private mail, yes <tupi>wingo: sorry to bother you, but better ask: do i have to mention kisê: [a] all files are fsf copyright and [b] i did copy some sentences from the guile manual for its [wip] manual ... <wingo>tupi: regarding kisê, actually they are only fsf copyright if either they are derived from some other fsf-copyright source, or you submit kisê as a gnu project <wingo>but anyway, that is irrelevant in this case <wingo>this case is, did you incorporate any external copyrights into your changes to guile-gnome <wingo>and i think that answer is no <wingo>because you have copyright on kisê, and you didn't incorporate anything else into guile or guile-gnome <tupi>actually i wrote that the copyright is fsf, in each file [and not myself] because i was hoping to make it a gnu project ... i still want it a gnu... but it takes time ... i was not sure [and still not] what to do <ijp>tupi: not all gnu projects need an fsf copyright assignment, only the ones started by an fsf member <tupi>should I change the copyright to myself then ? <ijp>well, you never actually assigned it... <tupi>and never be an employee [fsf] <tupi>but i thought the copyright was 'who can attack/defend in case of license infrigment... <mark_weaver>well, having the FSF own the copyright is beneficial for GPL enforcement, and for upgrading to the latest version of the GNU GPL if the original authors are no longer reachable. <tupi>mark_weaver: kisê is GPL v3 and i'd rather let the copyright be fsf <mark_weaver>fwiw, there's no other organization I would trust with such a thing, but I'd trust the FSF, especially since the FSF makes a lot of promises in the copyright assignment contract. <wingo>right, it's your choice; fsf is a fine choice but it is a choice <tupi>ok then i prefer that choice :) how nbice i agree with myself <tupi>because of course Kisê will soon be used by millions of users and then it's better be defended by the fsf itself :) :) <mark_weaver>tupi: btw, there's no need for me to have direct access to your client's machine. <tupi>mark_weaver: ok, but it is a possibility, in case we/you need it ... <wingo>stis: fixed a thing, compiles should be faster (though still there are many things to optimize) <stis>wingo: I just pulled and are compiling right now! <stis>and compiling the racket matcher takes 16s <stis>yeah, that's acceptable, please ship it ;-) <tupi>have to go, but it is really nice and quite incentive to see such good work: guile rocks and its people too! great great... bbl <wingo>> (program-sources (compile '(lambda (x) x))) <stis>(program-sources (compile '(lambda (x) x))) <wingo>stis: yes, you have to ,o interp #t first <wingo>probably because (compile 'foo) itself gets compiled <wingo>and so foo loses its source info <wingo>perhaps we could fix that eventually <stis>I noticed also that ,help does not work <stis>wingo: no. ,help still does not work, was this a fix for program-source? <wingo>stis: you will have to recompile everything also <wingo>touch eval.scm and then make -j4 <wingo>should be done in a couple minutes <stis>muahahahahaha is hummingly escaping from the cellar! <stis>yeah, this is a much much faster compile! <wingo>meanwhile i had some strange compile error <stis>hmm basic guile-log compiles <stis>no rtl issues just some porting som minor stuff <stis>compilation is pretty fast <stis>wingo: hmm my test suit for guile log does not show any significant problems <stis>wingo: benchmarking reveal that the logic code is slightly slower than the old vm <stis>Properties 1. calls a lot of C-functions <stis>2. multiple values returns is common <stis>4. functions call everywhere <stis>any of those is my guess. Anyhow got to sleep cheers! <alexei>is there already something established for (let-env (("TEMP" directory) ...) (subprocess goes here)) pattern for literal (posix) setenv? <ijp>no, but this could be a reasonable use of dynamic-wind <ijp>well, slight race condition possible, but not very likely in practice *TaylanUB realizes ey has no idea how env vars and threads generally interact. <ijp>(let ((x (getenv))) (setenv)) <- that one <ijp>if someone did a setenv in between your getenv and a setenv, then your restored value would no longer be accurate <ijp>of course, as you said, this only matters in a threaded program <ijp>the correct thing to do is the version of system that lets you set an evn <alexei>hm there is a proper solution, just not on the scheme level ... <ijp>probably, the subprocess stuff is kinda terrible <alexei>thanks for feedback, I thought it would be something trivial. Then I'll just do the buggy version. <ijp>the correct thing is to come up with a new version of (ice-9 popen) <ijp>which we've been saying for far too long, alas <gzg>Are there any interfaces for manipulating midi streams? <gzg>dsmith-work: Ba-dum *Tish* *ijp smacks taylanub upside the haid <gzg>dsmith-work: I've been playing around with the idea of a midi sequencerish environment, with an associative Emacs-mode. <alexei>what is wrong with (ice-9 popen)?