<mark_weaver>Wow, best one-liner ever. Can anyone here tell me what this program does by visual inspection only? <mark_weaver>main() { printf(&unix["\\021%six\\012\\0"],(unix)["have"]+"fun"-0x60);} <Chaos`Eternal>main() { printf(&1["\\021%six\\012\\0"],(1)["have"]+"fun"-0x60);} <nalaginrut>mark_weaver: I think I got what you mean for 'format', maybe you're suggesting me use irregex-replace for the directly? <mark_weaver>I would avoid format for this job, but having thought more on it, using irregex-replace every time the template is instantiated is suboptimal as well. <mark_weaver>the best thing would be to use only 'string-concatenate' each time the template is instantiated. <mark_weaver>so the one-time preparation, 'make-string-template' is called, would have to produce a list of the things to be concatenated: a mixture of constant strings (the parts of the template between variable references, and with $$ converted to $) and the variable references themselves. <mark_weaver>s/'make-string-template' is called/when 'make-string-template' is called/ <mark_weaver>e.g. "${name1}, $$ I'm ${name2}" would be converted to something like the list (name1 ", $ I'm " name2) <mark_weaver>and then, when the template is instantiated, that list would be map'd (with keywords looked up and substituted; strings left alone) and then the result of 'map' would simply be passed to string-concatenate, which is very efficient in Guile. <nalaginrut>mark_weaver: yes, that scheme is better, but a bit of complicated to split the pattern <ijp>that one-liner is weird <ijp>&unix is something defined in the program already, and not some weird C thing? <mark_weaver>it's a predefined C preprocessor macro, typically defined to be 1 on unix-like systems. <ijp>well, then the "obvious" guess would be that it is printing a certain part of its own exectuable <ijp>I'm guessing the statically allocated part which contains "have fun" <mark_weaver>the key to understanding this code is to know precisely what the C array-indexing operator does. <ijp>I really have no desire to understand this code :) <ijp>nalaginrut: when I wrote a dump templater, I did the compile->template, fill-in-template-and-concatenate route <ijp>not a proper library, because $stuff_happened <nalaginrut>alright, I don't think Scheme suit for obfuscated contest, since all the stuff will be continuation trick ;-P <ijp>hmm, that's not all pure r6rs because for some reason I used define* <ijp>nalaginrut: I wrote that one <ijp>hmm, apparently I wrote that July 2012 <ijp>sigh, yes, lots of people "think" that, few people "know" anything <ijp>nalaginrut: you realise of course that the r5rs cannot work with files robustly? <nalaginrut>ijp: ok, I see what you did, it's actually 'read-delimited/string' or some proper name <ijp>oh look that file doesn't exist, better let you handle that gracefully, oh wait I can't <nalaginrut>ijp: yes, I know the file stuff, so I write pred before file handler <mark_weaver>FWIW, I used to agree with nalaginrut, but I've come to think that R6RS is by far the best thing we have now in the Scheme world for making practical portable programs. <nalaginrut>mark_weaver: yes, for portable purpose, r5rs is suck <ijp>anyway, this conversation never leads anywhere good <mark_weaver>If any other language had as many good implementations as R6RS does, it would be considered more than enough. <nalaginrut>OK guys, it's not a good beginning of talking rnrs ;-P <weinholt>(let((* .(`'((unquote .(+ .[])).()))).())((caadr .(* .())).(#o-7 .[#E#x93/3])).[]) <ijp>pessoa: good thing you have an informed opinion, and are not just repeating something you heard from someone who heard from someone who heard from an implementor of a scheme that prior to r6rs did not have a module system, likes so many others... <pessoa>fexprs allow for implementing flexible module systems <ijp>those [] thre me off <ijp>it doesn't help that we have a very complicated number representation <ijp>nalaginrut: runtime macros (roughly) <ijp>a lot of hassle for little benefit <ijp>modules, as mentioned, are about the only useful use case I know of that can't be done with macros <ijp>(though chez scheme would disagree with the latter) <ijp>(a b c) = (a . (b . (c . ()))) <ijp>that really doesn't matter there <ijp>on the other side, it might matter, because then the . could be part of the identifier name <ijp>well, ((foo . bar) (baz . quux)) is common enough <ijp>the interesting one is `(1 unquote 3) => (1 . 3) <ijp>because then you start to wonder about `#(1 unquote 3) does, and you find a broken quasiquote macro :) <ijp>it's a really common bug <ijp>guile gets it right though <ijp>it's only for number literals <ijp>similarly there is #i for inexact <ijp># is so cramped, it's rather silly <ijp>I wonder if anyone has ever actually used #d <ijp>maybe just to make someone go "wtf" *ijp goes to file a bug against racket for that unquote behaviour ***sneek_ is now known as sneek
***ijp is now known as taylanub`
***taylanub` is now known as ijp
<pessoa>rudybot: graphics can be done as well in postscript, can't it? <civodul>the schedule was slightly packed, though <wingo>well, that's a nice problem i guess <civodul>i think videos will be on-line real soon <wingo>i owe a series of blog posts :) <civodul>the "private session" at the end was surprisingly quiet <wingo>i'll have a little more time in a month <civodul>BTW, there'll be a GNU birthday party in Paris on Sep. 21st <civodul>oh, and i met with a TeXmacs hacker, so we discussed 1.8 -> 2.0 migration <civodul>and he gave it a try already, and it seems that should be doable <wingo>will you be at the paris thing? <civodul>not sure, because i also need to travel for work <wingo>dunno myself either, travelling the weekend before <civodul>there'll be at least José, Luca, etc. <pessoa>it's time to improve skribilo in a way that allows it to be distributed along with guile <civodul>pessoa: i think it's better to have it maintained separately currently <civodul>but then, just like Racket uses Scribble, it'd be nice to have something better integrated than raw Texinfo in Guile <pessoa>bigloo never got skribe integrated, did it? <pessoa>even racket had gone a long way. Years ago, mzscheme came with tex2page instead, which is kind of latex with scheme embedded <ijp>racket 3 had a horrible doc viewer <ijp>(if you'll excuse the anachronistic naming) <ijp>hmm, can geiser connect on a local socket? <ijp>hmm, must have to update geiser then <civodul>mark_weaver: would it be OK to have a deterministic syntax-session-id? <jmd>Have you ever hurd of a gnu with a lisp? <taylanub>That should be the motto/slogan while advertising some delicious GNU Guix/Hurd distro! ***ijp is now known as ijp2
***ijp2 is now known as ijp
<ijp>sigh, working with hooks is a little problematic when you want to change the function <ijp>(remove-hook! h f) (define f ...) (add-hook! h f) <civodul>you can have 'f' call some other top-level proc <wingo>redefinition and functions-as-values is hard; you need an indirection somewhere <taylanub>That's a neat thing with old Lisps that just put functions into the slot of a symbol, so the indirection is always there. <taylanub>(Putting functions into symbols and allowing reflection probably dwarfs some optimizations, I imagine, while the permanent indirection helps with modularity.) <mark_weaver>civodul: I assume your 'syntax-session-id' question relates to Guix/Nix, right? Would it suit your purposes for 'syntax-session-id' to be derived from the hash of the inputs of the thing currently being built? I think that would be fine. <civodul>mark_weaver: yes that related to Guix <civodul>actually i'd like guile -c '(pk ((@@ (system syntax) syntax-session-id)))' to always return the same thing <mark_weaver>it's been a while since I thought about this, but I think that won't work properly in the general case. <mark_weaver>the issue is that some of the gensyms that are created during macro expansion need to be globally unique. <civodul>IOW, instead of using /dev/urandom directly, it'd use random(3) with always the same seed <wingo>i guess you'd have to start from a problem and not a solution <wingo>the solution sounds wrong to me, but i don't remember either <civodul>wingo: problem is: builds are not reproducible, because .go files include random strings <pessoa> sneek doesn't know a solution, but he admires the problem <mark_weaver>i.e., if two compiled macros are used together in the same compilation unit, we must ensure that the gensyms that are embedded in the macros never conflict with each other. <mark_weaver>in general, these macros could have been created by different guile sessions. <civodul>what if we used (say) the source file name as a seed? <wingo>why don't you seed it manually if you want a reproducible build? <mark_weaver>yeah, I don't see why it wouldn't be good enough to use the hash that Guix already has. <wingo>you could add a command line argument to guild compile <mark_weaver>hmm. well, that's not quite good enough either. because guile will be run multiple times in a given build. <ijp>that would have been my next question <jmd>How do I represent the space character ? <mark_weaver>so maybe we'd need a counter added in there as well. <wingo>jmd search the manual for space <ijp>#\\(space-character) actually works as well <civodul>mark_weaver: i guess all that deserves more thought :-) <ijp>though outside of an obfuscated scheme contest, I wouldn't recommend it <wingo>mark_weaver: given that guile run at build-time is run once per module, i don't think using the same session id presents a problem, does it? <ijp>seed+module id might be enough <mark_weaver>wingo: I think it might be a problem, yes, because the same gensyms will be produced in each session. <wingo>module id is already implicitly there <wingo>gensyms are only resolved relative to a particular toplevel *wingo could be totally wrong here <mark_weaver>I think marks may have been the case where global uniqueness is needed. <wingo>perhaps the seed could simply be the relative path to the file :) <wingo>earlier today i did "var evil = eval" <civodul>i guess there's something to do with source file names here <civodul>we just need to come up with a definition of the property that session-ids are meant to provide :-) <wingo>did you see the "tor deterministic build" thing? was pretty interesting <mark_weaver>I'm very interested in deterministic builds, btw.. and my interest is to allow independent verifications of builds (same reason the tor folks are interested). <mark_weaver>so I can certainly sympathize with what civodul's asking for. <ijp>that's one hell of a title <civodul>mark_weaver: we were discussing this with grothoff at the GHM <civodul>and we're in a good position to support that <wingo>yeah, nix is super in that regard <mark_weaver>unfortunately, the design of the 'syntax-case' system, notably the API for 'datum->syntax' seems to require globally-unique gensyms. <civodul>mark_weaver: please define "globally" :-) <mark_weaver>personally, I really don't like the design of 'datum->syntax'. it's very convenient to use, but it's too general and causes some serious problems. <mark_weaver>in this case, "globally" means that no two pre-compiled macros that are ever used together in the same compilation unit should ever have embedded gensyms that collide. <mark_weaver>civodul: how about this: a command-line argument to 'guild compile' that is a hash, derived from the inputs of the derivation currently being built, plus the relative pathname of the module currently being compiled. would that be good enough? <civodul>mark_weaver: would work, but what about a generic solution? <civodul>i mean, if we can get this property regardless of whether Guix is used, that's even better <mark_weaver>civodul: understood. I just don't know how to do it. <mark_weaver>of course, one solution that would solve _several_ problems would be to avoid AOT compilation all-together, and switch to incremental compilation only. that would also solve the "macro dependency" problem, and the "top-level gensyms" problem as well. <mark_weaver>but somehow I guess that this proposed solution will be blocked, heh. <civodul>just wait until the TeXmacs people are done with porting, and then announce that 2.2 = 1.8 ;-) <pessoa> is incremental compilation the same as dumping a memory image? <mark_weaver>pessoa: incremental compilation means that no compiled code is ever stored to disk. instead, a given guile process starts with source code only, and compiles the hot code on-the-fly. <mark_weaver>I don't know that it does differ, but I'm not clear on the precise definition of these terms. <mark_weaver>well, core guile could be precompiled without causing any problems. ***sneek_ is now known as sneek
<wingo>weinholt: that's nice code, though i'm still terrified about constant-time things <dsmith-work>mark_weaver: pessoa used to hang in here a LONG time ago. He created the channel I think. <ijp>hehe, that http-post patch operated on the "one out one in" principle of bug fixes <mark_weaver>I don't see why we should prohibit a transfer encoding for a body of length 0. <mark_weaver>a body of length 0 is still valid data, just like "" is a valid string. *ijp goes to see who gets the 'git blame' <ijp>looks like it was wingo :) <ijp>wingo: I don't suppose you remember your rationale from way back in january? <wingo>can't page it in atm, ask again tomorrow :) <mark_weaver>what is the meaning of (request-content-length request) => #f ? <ijp>no content-length header, I believe <mark_weaver>does that imply that there will be no body? or could it simply mean that the body is sent in a chunked fashion and the length is not known at the beginning? <mark_weaver>ah, well, this is in the (not body) case, which I guess means that there will be no body. <ijp>for requests, no content length and no transfer encoding header imply no body <ijp>in the latter case, with chunked encoding, you could just send the final chunk, AFAICT <mark_weaver>I guess the idea of wingo's code is that (not body) could mean either "no body" or "an empty body". but (not (request-content-length request)) definitely means "no body" and that in that case, a transfer-encoding header is prohibited. <mark_weaver>I'm not sure if this is sensible, but it's the most sensible rationale I can come up with for why this code was written this way. <ijp>as an aside, I could work up a patch for application/x-www-form-urlencoded, since I already wrote it for a separate application. The only thing left to do is hair-split on the name :) <ijp>hmm, what would be the fsf position on. $developer writes and publishes code $foo. Submits $foo for $project for which $developer has assigned copyright to the fsf. <ijp>would $developer need to go back and change the $other_project to mention the copyright assignment in $project? <YoungFrog>I guess he doesn't have the right to assign copyright to fsf for an already published code ? <mark_weaver>ianal, but my understanding is that two copies of the same data can have different copyrights. for example, there are works that have passed into the public domain, and yet publishers are printing copyrighted copies of the exact same work. <mark_weaver>and so we have to do things like find an old copy of the work, to avoid using the copy that's copyrighted. <YoungFrog>I think i'm even less of a lawyer than you ; I was just throwing in a wild guess based on nothing <mark_weaver>ijp: I'm not 100% sure, but I guess that you wouldn't have to mention the copyright assignment in $other_project. <ijp>It wouldn't really bother me either way, it's just a weird question <mark_weaver>it seems to me that what FSF cares about is that (A) no one else is going to challenge FSF's right to distribute the code in Guile, and (B) that the FSF has legal grounds to enforce the LGPL on Guile's code. <mark_weaver>and (C) that the FSF can change the license of the code in Guile to GPLv4-or-later in the future. <mark_weaver>s/challenge FSF's right/challenge the right of any user who complies with the LGPL/ <mark_weaver>I don't see how the other copy of the code in $other_project would affect any of those things. <ijp>I suppose I could compare it to a question of: what would happen if I decided to privately fork guile <ijp>I'd assume I'd be able to claim copyright on any new additions I made <ijp>actually, I think there was a similar thread on the emacs ml a while back <mark_weaver>yes, you'd be able to add your own name to the copyright, when you make changes. but you wouldn't be able to remove FSF's copyright. <ijp>right, that goes without saying <mark_weaver>my understanding is that if you have your own copy of the code that was not derived from the copy in Guile, then your copy wouldn't need the FSF copyright, even though the copy of the code in Guile has been assigned to the FSF. <mark_weaver>however, if the copy in guile gets improved, you wouldn't be allowed to copy those improvements into your separate copy in $other_project without adding FSF copyright to the copy in $other_project. <mark_weaver>in other words, copyright ownership is a property of a particular copy of a work. <mark_weaver>and propagates according to the 'derived from' relationship. that's my understanding, anyway, but as I said, IANAL. <ijp>that was the thread I was thinking of, but, while as mean-spirited as I remember, it was less relevant than I'd thought <ijp>mark_weaver: I think this is the right interpretation <ijp>I just find the whole thing rather quaint, and unusual <mark_weaver>it makes me curious about the nature of his "disagreements" with the Orgmode maintainer and "community in general". <dsmith-work>Sounds like some kind of protest about who is maintainer, or how they do that job. <shanecelis>Interesting thread. What was Jambunathan's issue? <stis>guily eveningly greetings to you all! *stis is playing with pattern matchers implementation with ck macros <mark_weaver>stis: cool! I've often thought that implementations of things like 'match' and 'foof-loop' would be much nicer if they used 'ck'. I'd think it would allow much nicer extensibility interfaces as well. <ijp>it'd still leak an implementation detail, but it would be better <stis>yep,it feels quite nice, I'll let you know how it goes later. <stis>ijp: can't you hide that implementation detail with custom difine-syntax macros? *stis fired up emacs in jslinux and tride to evaluate some emacs lisp <stis>cool, really what is it? <mark_weaver>too bad he's withholding the source code of the JS PC emulator. <mark_weaver>stis: it's a hardware-level PC emulator implemented entirely in Javascript. <mark_weaver>when you load that page, Linux is booting entirely within your web browser. <mark_weaver>stis: I don't think that's GNU emacs in there. I think it's probably his own "QEmacs" <shanecelis>I played with the QEmacs a little bit (did a prototype iPhone QEmacs thing). The code is pretty nice. <mark_weaver>I don't doubt it, though it lacks Emacs' most important feature IMO, namely its easy extensibility. <shanecelis>mark_weaver: Indeed. QEmacs extensible language is C. <ota>Mark, Thanks for the link to jslinux, I hadn't seen that before. <ijp>how can so many people not have seen it? <ota>My son says he told me about it, so probably I just forgot. I was using an old Firefox in those days and couldn't run it. so maybe that explains it... ***ijp` is now known as ijp
***ijp` is now known as ijp
***ijp` is now known as ijp
***ijp```` is now known as ijp
***dsmith-w` is now known as dsmith-work
***ijp` is now known as ijp