***jao`` is now known as jao
<nalaginrut>ArneBab: IIRC you wrote your slide with org-mode? ;-) <Fuuzetsu>are there any Guile extensions which let me use pattern matching? <mark_weaver>it's "a nod to the fictional substance in Kurt Vonnegut's novel, Cat's Cradle, capable of acting as a seed crystal to crystallize the mass of software." <nalaginrut>Is it correct if I use eq? to compare keywords? I can't confirm it in the manual? <Molkolev_Zed>I have to say, as far as dynamic typing scripting languages go, Scheme does take the crown for all its faults. <Fuuzetsu>What's the difference between (lambda (x) x) and (lambda x x)? <mark_weaver>(lambda (x) x) accepts exactly one argument x. (lambda x x) accepts any number of arguments, and x is bound to the list of arguments. <Molkolev_Zed>Fuuzetsu, you can also do (lambda (x y . z) <body>) by the way <Molkolev_Zed>in which case the first argument gets bound to x, the second to y, and the remaining ones to z as a list. <nalaginrut>ArneBab: I tried S5 last night, but it always failed, what's your choice? maybe you don't use S5 <Molkolev_Zed>(case-lambda ((x) "one argument") ((x y) "two arguments") (x "More than two arguments")) does what you expect <Fuuzetsu>sounds like that makes composing properly (amongst other operations) pretty much impossible on such functions <ArneBab>nalaginrut: you have to drop in the supporting stuff for s5 <wingo>it has been 5 years, indeed :) <ArneBab>wingo: “internationalization has to be added again yet” ⇒ was added again in 2.0 <nalaginrut>you generate all the html with org-mode? or call org-export-as-s5 alone? <ArneBab>I generate all the html with org-mode: C-c C-e s h or so <ArneBab>that’s the equivalent of calling org-export-as-s5, though <ArneBab>nalaginrut: what’s the error you get? <nalaginrut>ArneBab: can not open load file: org-html (I think it's very strange) <ArneBab>(require 'ox-html) and (require 'ox-s5) (or so) <ArneBab>s5 was a bit of a hassle to get to work… <ArneBab>hm, (require 'ox-s5) seems to have worked right away here. Does exporting to html work? <ArneBab>and in which file is org-s5-export-as-html <ArneBab>nalaginrut: I think that’s the actual function I call <ArneBab>nalaginrut: maybe you have a leftover of an old org-mode installation <nalaginrut>well, I loaded ox-s5 and ox-html, but C-c C-e h h exported a file without adding the necessary js/css for slide <nalaginrut>maybe there's an old version, I've ever installed org-mode from Emacs <janneke>is building g-wrap with guile master supported? *janneke gets a core dump <wingo>janneke: haven't tried with master, should work tho... <wingo>dunno if it would pick up the right headers though, it probably just checks for guile-2.0 <mark_weaver>I'm trying to rewrite SCM_I_INUM to avoid undefined behavior, and I can't see how to do it without introducing a conditional. <mark_weaver>I can only hope that compilers are smart enough to notice that both arms of the conditional can be combined into a single operation on virtually all machines. <mark_weaver>it would be nice to not have to add -fwrapv to the compile flags in 2.0.10 <mark_weaver>the signed right shift isn't so bad, but the conversion from unsigned integer to signed integer is a problem. <mark_weaver>signed right shift is not "undefined behavior", but rather "implementation defined", and most of the compilers we care about define it as doing what we want (and we can test for that with the preprocessor). <mark_weaver>but converting from scm_t_bits to scm_t_signed_bits, as we currently do in SCM_I_INUM, should really be fixed. <mark_weaver>(I suspect that this is why the clang build failed in strange ways until I added -fwrapv; technically, it's allowed to assume that inums are non-negative) ***cluck` is now known as cluck
<wingo>mark_weaver: what about ((scm_t_signed_bits) x) / 4 <wingo>what's the problem, precisely? <mark_weaver>there's no standard way to convert that into a signed integer without a conditional. <wingo>we can cast SCM to scm_t_bits or scm_t_signed_bits, afaiu, because -fno-strict-aliasing <wingo>you can't cast unsigned to signed? <mark_weaver>not unless the value in the unsigned is represented in the signed type. <mark_weaver>i.e. it has to be non-negative and <= max of the signed type. <mark_weaver>my only hope is to construct a conditional that can be optimized by virtually any modern compiler. <wingo>except guile's, of course ;-) <mark_weaver>I'll figure it out by experiment, I suppose, testing on gcc and clang. <wingo>c++ is much better in this regard <wingo>the c++ used in web browsers, which is surely a reasonably portable c++ <wingo>yes there is a cast saying "treat this bit pattern as this other bit pattern" <wingo>they have the whole panoply of static_cast, reinterpret_cast, etc <mark_weaver>the big web browsers are pretty much just targetting intel. <wingo>mips has ports of spidermonkey, v8, and jsc <wingo>at least that i have seen upstream <wingo>and their portability issues are usually related to the native code generation and platform abi more than the c++ runtime code <wingo>mark_weaver: which section of c11 specifies that you can't (int) (unsigned) -1 <wingo>does gcc and llvm define the result of this cast? <wingo>it actually says that it's implementation-defined <mark_weaver>for my purposes, I've not cared much about that distinction, because it seems to me we have to avoid both. <mark_weaver>unless we want to limit guile to only working on some fixed set of compilers. <wingo>depends on the tradeoffs i guess :) <mark_weaver>if modern web browsers work properly on N32 MIPS, I'll be very glad. last I checked, that was not the case. <mark_weaver>but debian uses O32, which is ancient and slow, and doesn't take advantage of 64-bit registers at all. <wingo>yeah i dunno about n32, but spidermonkey is getting mips work now for 32 and 64 bits i think <tupi>wingo, mark_weaver, wrt gobject introspection, did[do] you have in mind parsing gir xml files or .typelib ? <mark_weaver>but if we wanted to parse the xml files, sxml would be the thing to use. <didi>They recommend using .typelib. <mark_weaver>well, a generic recommendation may not be a good fit for us. <mark_weaver>having skimmed some things, I get the impression that typelib has the same info as the xml, but in a binary format. is that right? <didi>Sure. Just add this bit of information when making the decision. <didi>mark_weaver: That's correct. <tupi>didi: i guess that is a recommendation for people using C to parse, but [not knowing yet very much about the all thing either] afaiu, we would parse to produce scheme files that use either our ffi or dynamic ffi <didi>mark_weaver: You don't play with the binary yourself tho, but use a library. <mark_weaver>the thing is, I suspect it will be better for us to generate scheme code for the bindings and compile them to bytecode. <didi>tupi: I would use the library provided with FFI. <mark_weaver>my gut feeling is that the xml will be a better fit for us, since we have a nice way to convert it into s-expressions that are easy for us to deal with. <tupi>mark_weaver: agreed, that's what i thought as well <mark_weaver>and we only have to use them when updating the bindings, so there's no efficiency issue. <mark_weaver>most languages can't work with xml particularly easily: they need to use some kind of C library to do that anyway, so they might as well use typelib instead. <mark_weaver>whereas xml is actually a pretty good fit for a language like scheme. <mark_weaver>we can use it well without using any C library at all. <didi>Well, the end goal is to use FFI and C libraries, but I understand what you are saying. <mark_weaver>right, but it's one less dependency on a C library, which we'd have to write a binding for. <mark_weaver>wingo: do you have an opinion on this? (parse the gir xml files vs .typelib (binary format)) ? <wingo>didi: fwiw the ideal world probably has both things -- one generic dynamic lib you can use if you need some unwrapped lib, and one binding generated using the dynamic tool, with full docs <wingo>mark_weaver: dunno tbh -- but i would lean heavily towards something that generates a static binding that doesn't need gir runtime support, because those packages are a mess <wingo>the gobject stuff would stay as it is in guile-gnome of course... <mark_weaver>I wonder about making this pure scheme, but maybe that's not worth it, dunno. <wingo>you could generate c beforehand, or have the binding look them up dynamically <wingo>but the set of functions and types that are bound in a module should be known at build-time, for a quality binding <wingo>a binding you could document <mark_weaver>I certainly agree that the way gobject stuff is blended with goops is very nice, and should be kept. <mark_weaver>I'm just thinking that it would be nice if guile-gnome could be distributed a pure scheme, so that we don't have to work to get guile-gnome compiled and bundled into all the distros (always a struggle) <tupi>i was assuming that it was our goal <tupi>so parsing gir xml and generate scheme files [only, no C] <mark_weaver>anyway, I'm just putting out ideas here. wingo is vastly more knowledgable about gnome, guile-gnome, and the issues around that, so I'll defer to his judgment on this. <wingo>mark_weaver: regarding standards and such, did you see 6.3.2.3.6 :) <didi>AFAIU the goal of gobject introspection is to build a binding only from the XML/.typelib files. They should contain every piece of information you need. Also, stating some translation rules, you shouldn't need to write your own documentation because the original one is sufficient. <mark_weaver>didi: well, wingo already did a bunch of great work on translating the docs, and I find it much nicer to read them than the original ones. <mark_weaver>but I agree that it's not strictly needed, just a nicety. <wingo>it's already there, seems a shame to throw it away <tupi>didi: that is what i understand so far as well. for the doc, mark is right and i see no reason why we could not use what wingo already did. right now my questions are to orient my readings to get more info and knowedge... ***cluck` is now known as cluck