<daviid>i can't find that page i tought i did read and [dreamed ?] it says i could assign (C) FSF any of my work, hum i dod that not to loose a second about these issues, now have to loose the time to correct, too bad. maybe i can change all to (C) myself then, could be easier <daviid>(C) myself does not make sence, there is no way i can enforce a GPL infringment anyway, no time, no money, no structure, no knowledge, no lawer ... <paroneayea>daviid: it's true that you're probably best off assigning copyright to an organization that's a steward, but even low on resources it's not impossible for enforcement to happen. Most happens out of court, and the conservancy linux cases going on are good examples of enforcement happening with the assistant of another org but no assignment <daviid>i'd rather keep (C) FSF , i'll send an email ***cluck` is now known as cluck
***michel_mno_afk is now known as michel_mno
<paroneayea>makes me think even more that typed guile is probably desirable! <zacts>I guess one criticism is that the fly would go mad due to sensory deprivation <paroneayea>also, the world's most hilarious programmer UI in there <paroneayea>one window per neuron, tiled precisely onto the screen, with textboxes for each value <artyom-poptsov>Every time I see a "~" at the end of an IRC message I recall "~%" from the Guile's (ice-9 format) specification. <zacts>~% reminds me of a common lisp newline *ArneBab_ hit a typo (nalaginrut: mein means my, moin means good morning *ducks*) <lloda>scheme@(guile-user)> (import (ice-9 match) (srfi srfi-9)) (define-record-type <type> (make-type) type?) (match (make-type) (($ <type>) 'yes)) <lloda>scheme@(guile-user)> (define $ list) <lloda>scheme@(guile-user)> (import (ice-9 match) (srfi srfi-9)) (define-record-type <type> (make-type) type?) (match (make-type) (($ <type>) 'yes)) <lloda><unnamed port>:2:83: In procedure #<<type>>: <lloda><unnamed port>:2:83: Throw to key `match-error' with args `("match" "no matching pattern" #<<type>>)'. <lloda>why is (match) affected by $ defined above? <taylanub>lloda: hygienic macros are supposed to work through the *binding* of the "literals" in the syntax rules and such, and not the plain symbol, so changing the binding of $ makes match stop recognizing it. <taylanub>AFAIK many Scheme implementations (including Guile, maybe except the 2.2 branch?) give it some leeway and keep working in such cases most of the time, but the standard is actually pretty clear on it in the definition of 'syntax-rules'. it's a shame that no "unhygienic" matching of symbols is supported at all with 'syntax-rules'. <taylanub>lloda: in fact, for this reason, some people recommend always binding "auxiliary syntax" such as the 'else' in cond and, in this case, the '$' of match, so that one can rename it while importing <civodul>in 2.0, literals are "literally-matched", so defining $ doesn't cause this problem <taylanub>AFAIK in 2.0 it also only works with globals, i.e. let-binding $ would also "break" match. IIRC this is upstream psyntax behavior or so. <civodul>so 2.1 just extends the semantics to global variables <lloda>if I need to worry about the environment where I *use* a macro, then I don't understand what 'hygiene' is doing for me here :-/ <civodul>on one hand, extending hygiene to top-level bindings is The Right Thing <civodul>on the other, it has many potential drawbacks <civodul>namely the fact that people have been used to using short identifiers for literals <lloda>how come else in cond doesn't have this problem? isn't else a literal here? <taylanub>if you (define else blah) I think cond should "break" too <taylanub>well, under the scope of that definition. doesn't it? *taylanub doesn't have 2.1 installed; can't test <lloda>ah, you're right. cond also breaks :-( <lloda>this really looks terrible to me <taylanub>I wonder if syntax-rules could be extended backwards-compatibly to allow a second literals list whose members should be matched "unhygienically" (by symbol name). would need rewriting some macros to use it that way, but wouldn't break standards compliance. or one could be radical and break compliance because unhygienic matching is preferred much more commonly in syntax-rules literals... <taylanub>so far the only macro I heard of which really intends to match the identifier of an existing procedure is an implementation of `delay' that auto-detects the (delay (force ...)) pattern and turns it into the `lazy' equivalent. OTOH stuff like match, irregex, cond, etc. really want unhygienic matching. so I agree the pedantic hygienism is pretty terrible here. <lloda>it beats me how a macro taking the meaning of its literals from the use site can be considered 'hygienic', looks like a perverse use of the term <taylanub>lloda: well it's kind of like module A: (define token (cons 'x 'y)) (define (match-token? obj) (eqv? obj token)) module B: (import A) (define token (cons 'x 'y)) (match-token? token) => #f ;hygiene preserved <lloda>but there're no literals there <taylanub>the macro system works purely with abstract "binding" entities, for which identifiers are our method of expressing the bindings to the macro system. so when you bind $, it gets a new "binding value" and you lose your reference to the "binding value" which was in effect at the definition of 'match'. when you pass your $ to match, it doesn't recognize it because it has a different binding... hard <taylanub>to explain, not sure if I'm making sense :\\ <lloda>I see how that works... but then these macros match, cond, etc should avoid that mechanism for their 'literals' <taylanub>I don't know if this has been discussed on the ML yet. maybe worth bringing up. <lloda>i.e. exporting the bindings for the literals, which Guile doesn't do <lloda>that would be better than the current situation <taylanub>yeah, binding the literals beforehand and exporting those bindings at least allows importers to import renamed ones, but it's pretty ugly having to use e.g. match:$, match:?, etc. (and ideally e.g. match:=, because it would be weird to use the actual = binding, and inconsistent with the prefixed ones.) barely acceptable as a work-around IMO. <lloda>i'd prefer matching-as-actual-literal, yes <taylanub>FWIW `syntax-parse' from Racket seems to support both flavors of literals. that thing can probably deprecate syntax-rules really. <taylanub>well, it's procedural, so gains some verbosity. OTOH supporting SRFI-72 style (define-syntax (macro . args) ...) reduces the lambda noise so synax-case and syntax-parse could really replace syntax-rules already <lloda>racket seems to export the literals a la r6rs, they don't use #:datum-literal for their else in cond (is that it?) <taylanub>oh, I didn't check that, just saw that sytnax-parse supports #:datum-literals <taylanub> http://sprunge.us/cIcL one might just stop using syntax-rules altogether given SRFI-72 support. syntax-rules kinda loses its aesthetic edge over the others. <lloda>"Scheme uses referential equality for macro “literals lists” (used to recognize auxiliary identifiers). Unfortunately, it allows literals that don’t refer to any binding, creating another kind of ghostly identifier interpretation: it collides with nothing but can be overridden by any other binding that comes along." <taylanub>yeah, though disallowing that doesn't solve the larger issue. in fact allowing it can actually be nice because two macros from different modules can both use the "unbound" identifier `foo' and they won't clash with each other; IOW "unbound" bindings work like magic global bindings, though they cannot be renamed. <taylanub>(OTOH using datum-literals is clearly the way to go; one doesn't need these global magic bindings anyway in that case) <remi`bd>Hi! How do you handle the “char” type when writing bindings with dynamic FFIs? It could be either int8 or uint8, depending on the C compiler used. ***michel_mno is now known as michel_mno_afk
<dft>Hi, anyone know how SRFI9 structs can be created and accessed from C? <dft>civodul: Oh I see... what about records? <jmd>I'm getting this error which I'm finding hard to track down: <jmd>ERROR: In procedure simple-format: <jmd>ERROR: Throw to key `encoding-error' with args `("iprin1" "cannot convert to output locale" 84 #<output: string 80eab4 <dft>Oh, that's how it is. Thanks a lot! :D ***karswell` is now known as karswell
<civodul>jmd: the string passed to 'format' cannot be converted to the port's encoding <civodul>for instance because the port is ASCII whereas the string contains non-ASCII characters <jmd>That would make sense. <jmd>How can I find out what the string is? <civodul>at the REPL you would get a "recursive REPL" where you can query local variables, etc. <jmd>Unfortunately I'm not working from a REPL. This is a C program with some calls to scm_c_define_gsubr <civodul>jmd: do you have an idea where that 'format' call is made? <jmd>I suspect its a bad call to gettext <jmd>Yeah. I reckon it is probably a problem with the expression (format #f (_ "_~a") 8) <jmd>where _ is bound to gettext <ijp>reader extensions, naughty, naughty <civodul>i avoid reader extensions, but here it makes a real difference <ijp>well, my main issue with them wouldn't apply to guix anyway <civodul>the current-reader fluids was meant to mitigate that <ijp>davexunit: as in joe bloggs, turns on :foo style symbols, and breaks my libraries <ijp>it doesn't matter for self contained software because, well, it's self contained <jmd>civodul: The string is UTF-8 I thought the port's encoding was also UTF8. How can I find out for sure? <civodul>a string is a sequence of unicode code points, it's not "utf-8" :-) <civodul>you can call (port-encoding the-port) <jmd>Actually, the port in this instance is #f <jmd>Isn't that supposed to accept anything? <civodul>#f is equivalent to (current-output-port) <civodul>its encoding is ISO-8859-1, unless the program calls 'setlocale' <civodul>in which case its encoding is the locale encoding <civodul>alternately, could you try GUILE_INSTALL_LOCALE=1 ? <jmd>Well its a gtk program so it indirectly calls setlocale <civodul>yes, one has to call scm_setlocale, not just setlocale(3) <civodul>setting GUILE_INSTALL_LOCALE=1 will do that automatically <jmd>GUILE_INSTALL_LOCALE=1 makes no difference. So I guess scm_setlocale is already called somewhere <civodul>jmd: and what does (port-encoding (current-output-port)) say? <civodul>you could force it with (set-port-encoding! (current-output-port) "UTF-8") <jmd>Hmm. It says ISO-8859-1 <jmd>But I wonder how any non-ascii strings get properly printed? <jmd>Even if I call scm_setlocale (LC_ALL, ""); it still shows ISO-8859-1 <paroneayea>bipt (and wingo?) I think talked at some point on the emacs devel list saying they might be open to switching guile's encoding default to utf-8 <paroneayea>it seems like a good idea to me for a 2.X release since the rest of the world does as such <jmd>Using (set-port-encoding! (current-output-port) "UTF-8") causes (port-encoding (current-output-port)) to return "UTF-8" <jmd>However it doesn't fix the problem. <jmd>simple-format still throws the exception. <jmd>civodul: I got it working. <jmd>I have to call scm_setlocale immediately before EVERY call to format. <jmd>calling it once at the start of the program is not enough. <civodul>jmd: is the C program repeatedly entering and leaving "guile mode"? <jmd>civodul: Yes. I think it is. <civodul>that's probably the reason, then :-/ <jmd>civodul: Actually what do you mean by "guile mode". <jmd>I'm calling scm_primitive_load in order to process a file. <bipt>the other issue is allowing extensions to unicode (i.e. codepoints over 2^21) and providing a encoding for binary data. guile needs the latter anyway, for posix filenames and other text without a specific encoding <ijp>paroneayea: I live my life by a simple philosophy : UTF-8 or GTFO <paroneayea>#guile people worry it seems about the lilypond stuff, but hey <paroneayea>python 2 -> 3 has been an enormously difficult thing <paroneayea>but interesting to watch every language community deal with this stufff......