<fangism1>is snarf-check-and-output-texi heavily dependent on preprocessor behavior? has it been tested against clang's preprocessor? ***apb is now known as Guest35136
<mark_weaver>fangism1: we had problems with clang 3.4's preprocessor before 2.0.11, and the fixes are not yet on the master branch either. <fangism1>mark_weaver: ok, good to know "it's not just us" :) <mark_weaver>there are several other clang-related fixes as well, all committed to the stable-2.0 branch just before 2.0.11 was released. <fangism1>some users are even still building guile-1.8.8 on newer OS Xs <fangism1>i'll look into updating to 2.0.11 and see what the state of things are there <mark_weaver>we no longer support guile-1.8. you can try to backport the fixes if you like, but you're on your own. <mark_weaver>I should also note that there's still a problem with clang on 32-bit systems that's still not fixed in our tree, but I can give you a fix that will work for you in the meantime, if you need it. <fangism1>i haven't been building with clang outside of x86_64 yet <fangism1>I do kind of maintain a clang port for darwin8-10, which does cover i386 and ppc, but i've been bandwidth limited this month to test more of it <fangism1>if i ever get the powerpc-darwin8 port 100% working, guile will be among the subjects in the "final exam" <mark_weaver>it's not yet in git because it would break the build on some obscure compilers. <adhoc>mark_weaver: the primary compiler being ... ? <mark_weaver>the issue is that there's no portable way to specify the alignment of static variables before C11. <mark_weaver>So we have cases for GNU C (implemented by GCC and Clang at least), Intel CC, and Sun Pro. <fangism1>does that mean having to detect that in autoconf? <mark_weaver>well, we'll probably have to detect whether C11 _Alignas works on autoconf, yes, and also handle compilers where we don't know how to specify the alignment by avoiding static allocation in that case. <mark_weaver>which is a bit of a pain, so I haven't yet gotten around to it. <adhoc>mark_weaver: so how did this used to be done? <mark_weaver>well, the existing guile-2.0 code puts a 64-bit integer at the beginning of the struct, in the hopes that it will force 64-bit alignment. we didn't receive any problem reports on this until clang 3.4 on 32-bit systems. <mark_weaver>a number of problems arose in clang 3.4 that we had never seen before. <adhoc>mark_weaver: are there other compilers that implement c11 ? <zRecursive>In fact i ony use gcc/gdb in the past, but freebsd forces us to touch clang ... <mark_weaver>well, we'll continue to support the existing non-portable alignment specifiers for GNU C, Intel CC, and Sun Pro, but we need to also add C11 as another possible case, as well as a fallback case when none of the above apply. <mark_weaver>the patch I referenced above will work for any GCC, Clang, Intel C, or Sun Pro. <mark_weaver>but will likely break the build for any other compiler that doesn't emulate one of the above. <mark_weaver>hmm, actually I see that gnulib has a 'stdalign' module. that should make things easier. <mark_weaver>although we still need to handle the case where gnulib doesn't know how to tell the compiler to specify alignment. sometimes there might simply be no way to do it. <didi>Is there a place in the manual which describes which characters are valid for a symbol? <b4283>didi: you can refer to the R6Rs standard <b4283>there's one section about datum <mark_weaver>didi: right now guile is very lax about what can be in an unquoted symbol, but we are likely to reduce the set of legal characters over time, so I'd be careful about relying on that too much. It's a good idea to restrict yourself to what R6RS specifies. <didi>mark_weaver: Just trying to understand the language. <didi>I would love if Guile's manual had this kind of information. <nalaginrut>Well, it's April fool today, there should be a news about guile-emacs released <cluck>the boy who called wolf would likely advise against that <ijp>nalaginrut: I've been thinking it over, and I think the problem is the definition of "reset" <ijp>in racket, reset and prompt are the same (I believe) <ijp>this is not true in guile <nalaginrut>ijp: btw, do you think the mix usage has potential problem? (abort and reset/shift) <ijp>(reset (list (shift k (abort 10)))) in racket gives 10 <ijp>in guile, that will error <nalaginrut>I guess maybe the mix is implementation defined, so I can't rely on it <ijp>I'm still not 100% on why the part of the body is captured, but I have an inkling <nalaginrut>I thought shift/reset can be replaced by abort/prompt safely, in principle <ijp>but, if you look at the error thrown above you'll see it is because 10 is not a function <ijp>however, when you use abort, it is with a partial continuation, which *is* callable <nalaginrut>then I thought it's reasonable to mix them, well it seems a big mistake <nalaginrut>yes, abort returns partial-continuation in Guile, but it return the value you specified only in Racket <ijp>look at the error above <ijp>scheme@(guile-user)> (reset (abort 10)) <ijp>ERROR: In procedure 10: ERROR: Wrong type to apply: 10 <ijp>,bt 0 (10 #<partial-continuation 9634eb0>) <ijp>so, k is being called with the continuation of the abort <ijp>i.e. the semantics of abort in racket and guile are completely different <nalaginrut>hmm...I think there'd be a handler to make it correct order <ijp>in racket, abort just returns the value <nalaginrut>but reset doesn't provide the handler, it's in prompt <ijp>in guile, because of the way reset is implemented, it calls the aborted value with the continuation <ijp>so it is not safe to mix them, as currently implemented <nalaginrut>doen't the paper define the expected return value of abort? <ijp>nalaginrut: abort is not used with reset, but with prompt <ijp>I think we call it % <nalaginrut>anyway, it's my mistake to mix them, (shift k k) is enough for my case <ijp>in theory, we should be able to mix them, but it will require more thought than has currently been given to it <ijp>it may be an idea to make a bugreport about this, but it's probably going to be a "wishlist" item for the near future <nalaginrut>anyway, if it's not promised by the principle, I think it's not need to fix it intended <nalaginrut>ijp: thanks for explaining, I'll choose to not to mix them <ijp>I've probably asked this and subsequently forgotten the answer, but are there inotify bindings? <nalaginrut>anyone remind me the print procedure to print the exception? <nalaginrut>civodul: cool~I think js/lua needs love when there's need for them ;-) *nalaginrut realized there's runq module in the core, which could reduce his time for green-thread scheduler <ArneBab>civodul: I actually do not know Javascript (more than the bare basics) <taylanub>ArneBab: It's basically Scheme + Self, with C syntax, and many nasty anti-features like var hoisting, automatic type-conversion, etc. <ArneBab>I also know that the first time I tried to write some, I had already incurrred nasty security holes for the user… <ArneBab>(I wrote that by googling for the solutions…) <taylanub>wohoo, after 39 years of their inception (almost twice my age), Java has also implemented first-class closures! <ArneBab>isn’t there a quote that any language will implement half of common lisp in a worse way? <civodul>nalaginrut: someone is working on Guix for Hurd (will be a GSoC) <nalaginrut>if it's done, I think there won't be only debian/Hurd ;-) <civodul>taylanub: yeah it's funny to see Java and C++ do more functional stuff <taylanub>ArneBab: Right, Greenspun's tenth rule of programming <taylanub>"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." Well it's about programs and not languages <ArneBab>taylanub: it seems to be true for languages, too, if you consider libraries as part of the language <ArneBab>civodul: I should have grown suspicious when you showed installing vim ☺