00:00:27 mbohun [~mbohun@202.124.75.252] has joined #scheme 00:03:22 Riastradh [~riastradh@fsf/member/riastradh] has joined #scheme 00:03:35 xissburg [~chatzilla@187.3.136.142] has joined #scheme 00:03:50 there's no such thing as named let*? 00:04:04 Not built-in to Scheme. 00:04:04 Riastradh, memo from klutometis: meh; it's only missing existential `to be' which, unlike, say, the veridical or predicative ones, is superfluous. 00:04:19 leppie [~lolcow@196-215-36-144.dynamic.isadsl.co.za] has joined #scheme 00:05:08 Where has arcfide been? 00:06:16 :/ 00:06:30 xissburg, why don't you just use LET* and then named LET? 00:07:17 Riastradh: because I want to make a loop 00:07:30 Yes...? 00:07:34 you can use LET to loop 00:07:39 yes 00:07:53 but I need to bind the variables in sequence 00:08:25 The sequential binding of the variables matters only for the initial application. That's why I suggested LET* and then named LET: (let* ((a (f)) (b (g a))) (let loop ((a a) (b a)) ...)) 00:08:51 xissburg pasted "untitled" at http://paste.lisp.org/display/112410 00:09:04 -!- bzzbzz [~franco@modemcable240.34-83-70.mc.videotron.ca] has quit [Quit: leaving] 00:09:05 http://paste.lisp.org/display/112410 00:09:16 ah it's because you're trying to make the program fit in the smallest space possible 00:09:36 [obs I still dont know if that code works :p) 00:10:04 hm Riastradh , I think that's the way to go 00:11:24 (let ((s* (string-copy s))) (do ((i 0 (+ i 1))) ((>= i (string-length s))) (let ((j (random-integer (+ i 1)))) (string-set! s* i (string-ref s j)) (string-set! s* j (string-ref s i] 00:13:16 dfeuer [~dfeuer@wikimedia/Dfeuer] has joined #scheme 00:13:23 adu [~ajr@softbank220043139062.bbtec.net] has joined #scheme 00:14:16 Riastradh: what is that? a shuffle-string thingy? 00:14:26 davazp [~user@83.55.180.105] has joined #scheme 00:14:32 Try it and find out! 00:14:46 what if random-integer returns the same number twice? 00:14:59 Well, what if it does/ 00:14:59 ? 00:15:14 will there still be a permutation? 00:15:23 no 00:15:47 that's what I'm worried about 00:15:58 why? 00:16:03 make a bucket 00:16:07 I want to shuffle a string 00:16:28 Why would there be a problem if RANDOM-INTEGER returns the same number twice, xissburg? 00:16:29 a random permutation 00:17:00 xissburg: just skip over conflicts 00:17:22 xissburg: or make nearly-identical buckets (if this is in memory) 00:17:30 buckets? 00:17:34 buckets 00:17:52 a list where a put the already found numbers? 00:17:58 http://en.wikipedia.org/wiki/Hash_table 00:18:02 uh 00:18:05 adu, please make sense. 00:18:11 lol 00:18:18 ok 00:18:31 I am 00:18:35 -!- homie [~user@xdsl-78-34-200-129.netcologne.de] has quit [Ping timeout: 265 seconds] 00:19:01 Let's look at the cardinalities, xissburg. How many possible values can (random-integer (+ i 1)) return? 00:19:40 (+ i 1) 00:20:25 OK. So how many different possible configurations of return values of RANDOM-INTEGER are there? We set i = 0, i = 1, ..., i = n - 1. 00:20:27 ooh 00:20:41 I see now, you are swapping chars 00:20:45 . . . 00:20:58 then it will be a permutation anyway 00:22:10 OK. 00:22:19 Time for dinner. 00:22:48 i just had breakfast 00:24:07 It's lunch time here. 00:24:16 Time has no meaning on IRC. 00:25:01 gmt -3 00:25:26 +9 00:26:00 wow 00:26:19 you are at the other side of earth 00:26:23 yes 00:27:32 to talk over cans-and-string, we would need a cord 12 Mm long 00:28:01 yacobh [~yacobh@190.74.77.11] has joined #scheme 00:28:40 if it goes through the core of the earth 00:28:59 on the surface we would need like 20000km 00:29:15 I think 00:29:36 half of a geodesic :D 00:29:50 or something 00:30:44 incubot 00:30:56 incubot: (define shuffle-string 00:30:57 (lambda (s) 00:30:59 (let ((s* (string-copy s))) 00:31:00 (do ((i 0 (+ i 1))) 00:31:01 checked that part. what i'm more interested in is define-syntax, defmacro and all those are not standard? or are they de-facto standard ? 00:31:02 ((>= i (string-length s)) s*) 00:31:04 (let ((j (random (+ i 1)))) 00:31:05 (string-set! s* i (string-ref s j)) 00:31:06 (string-set! s* j (string-ref s i))))))) 00:31:13 ... 00:31:34 I just would like to say that this code is not working 00:31:48 correclty 00:33:44 xissburgm 00:33:46 xissburg, 00:33:51 Don't write this: 00:33:58 (string-set! s* i (string-ref s j)) (string-set! s* j (string-ref s i)) 00:34:10 instead, you should define a procedure string-swap! s i j 00:34:29 why? 00:34:48 the code is not guaranteed to execute in that order? 00:36:56 makes no difference 00:37:07 to you it makes no difference 00:37:30 -!- fradgers- [~fradgers-@5adb10a1.bb.sky.com] has left #scheme 00:37:39 lisppaste: url 00:37:39 To use the lisppaste bot, visit http://paste.lisp.org/new/scheme and enter your paste. 00:37:43 Also, use lisppaste for anything over four lines. 00:38:03 xissburg, you're right: I made a mistake in the code. 00:38:08 It really should be a swap. 00:38:38 sorry, I thought incubot would run that code so that we could play here 00:38:56 xissburg 00:40:36 This is Knuth shuffle? 00:41:17 It should, indeed, be (let ((t (string-ref s* i))) (string-set! s* i (string-ref s* j)) (string-set! s* j t)) 00:42:23 soupdragon: it is Riastradh shuffle 00:42:55 The algorithm that I meant to write code to implement is the Knuth-Fisher-Yates shuffle. 00:44:14 if you count the number of possible executions of this algorithm it is n!, and if you notice that each possibility happens exactly once it becomes clear that the probability is fair 00:45:09 yz ~> [yz] [zy], xyz ~> [xyz] [xzy] [yxz] [zxy] [yzx] [zyx], ... 00:45:59 Riastradh: I don;t know exactly why, but now it works 00:46:08 Magic, obviously. 00:50:08 :/ 00:50:47 let me see your code 00:51:11 nowhere_man [~pierre@AStrasbourg-551-1-76-104.w81-51.abo.wanadoo.fr] has joined #scheme 00:51:12 -!- kephas [~pierre@AStrasbourg-551-1-24-12.w86-213.abo.wanadoo.fr] has quit [Ping timeout: 258 seconds] 00:51:26 -!- aidalgol [~user@202.36.179.65] has quit [Ping timeout: 246 seconds] 00:53:20 xissburg pasted "untitled" at http://paste.lisp.org/display/112411 00:54:23 actually I don't understand why the first version gives incorrect results 00:54:37 soup annotated #112411 "swap" at http://paste.lisp.org/display/112411#1 00:54:49 this subroutine will help you 00:55:13 use it in place of your code 00:55:47 I see but this code swaps in the same string 00:56:00 yea, it works without the need for a copy 00:56:12 Now it's really time for dinner. 00:56:34 but why the first version doesn't work if it copies from one string to another 00:56:57 soup annotated #112411 "symmetric" at http://paste.lisp.org/display/112411#2 00:57:10 here is another way (which I prefer 00:58:17 -!- acarrico [~acarrico@pppoe-68-142-61-242.gmavt.net] has quit [Ping timeout: 265 seconds] 00:59:20 coool 00:59:43 -!- Komi [Komi@62.32.155.126] has quit [] 01:01:02 -!- yacobh [~yacobh@190.74.77.11] has quit [Quit: Saliendo] 01:04:40 JoelMcCracken [~joelmccra@pool-96-236-166-183.pitbpa.east.verizon.net] has joined #scheme 01:06:37 don't you want to use this subroutine? 01:10:18 -!- tizoc [~user@unaffiliated/tizoc] has left #scheme 01:10:28 tizoc [~user@unaffiliated/tizoc] has joined #scheme 01:14:04 How would you schemers do a predictive text input algo? 01:14:29 bad form... "you schemers"? 01:15:05 *schemer 01:15:20 csmrfx: if you want better results, i would ask "how would you ... in Scheme" 01:15:51 csmrfx: most people who use Scheme know at least 3 other languages, so they're not just "schemers" 01:16:04 lolol 01:16:26 you know, languages like lisp, elisp, clisp, etc ;) 01:16:26 * What is predictive text 01:16:31 how would a schemeriate actualize an predictive text input algo for maximal pleasure? 01:16:41 adu what about alisp and blisp?? 01:16:54 soupdragon: sure, whatever 01:16:55 soupdragon suppose you have a dictionary. predictive text 01:16:59 ? 01:17:05 explain the algorithm in detail 01:17:20 +*proposes suitable words for the initial input letters 01:17:26 csmrfx: are you just talking about tab-completion? 01:17:34 so if I type half a word, it generates a list of possible completions? 01:17:49 Hm, its not quite tab-completion what I mean. 01:17:49 for example if I type "ele" it will say ("phant" "vator" ...) 01:17:54 is that correct? 01:18:08 It generates a list of possible completions, unless theres only one. 01:18:12 or none. 01:18:22 soupdragon: yea kinda 01:18:27 kinda means that I am wrong 01:18:32 what is missing 01:18:32 I dont know. I've never made one. 01:18:37 made one what? 01:18:45 It means I dont know *exactly* how it would work. 01:18:49 nicktick [debian-tor@gateway/tor-sasl/nicktick] has joined #scheme 01:18:53 you can't just say "how do I do a bizzle booba algorithm" 01:18:55 Just had a funny idea of trying to make pone. 01:19:00 *one 01:19:17 soupdragon: regardless you nailed it 95% or so 01:19:18 it's unclear 01:19:27 yes but I am asking what 5% is there? 01:19:41 unclear as to "what coolness there could be to make it more fun" 01:19:53 I don't think this is any fun at all 01:20:14 soupdragon: I dont think I have *ever* made a program when I knew the full 100% of features etc 01:20:35 *csmrfx* engineering types please refrain from participating 01:20:39 that's an alien concept to me 01:20:49 lol 01:20:58 Making it up as you go? 01:21:18 soupdragon: you are missing out on the best features of your brain 01:21:49 hm 01:21:56 hm, its not like I proposed a business venture 01:21:58 how can I try using this 01:22:02 ? 01:22:15 for learning scheme? 01:22:25 not necessarily 01:22:36 for... code completion in your scheme-editor coded in scheme 01:22:47 csmrfx: If you ask "engineering types" to refrain from participating, you won't get anyone who knows how to answer your question to actually answer it. 01:23:13 I dont agree. 01:23:25 I actually know how to answer this question 01:23:41 Is this a pop quiz? I didn't realize we were being graded. 01:23:43 I just thought it might be interesting to see if anyone on this channel has any creative input on this 01:23:52 I don't have anything creative to add 01:23:57 looks like its more or less bored old geeks 01:24:04 *csmrfx* schoo 01:24:06 acarrico [~acarrico@pppoe-68-142-61-242.gmavt.net] has joined #scheme 01:24:12 whatsup 01:24:16 what you are talking about is a data structure that people learn very early on 01:24:42 uhhuh 01:24:56 (that *some* people learn) 01:25:00 If I understand you general question, I'd suggest looking at a trie structure, which is the canonical structure for a prefix word completion algorithm. 01:25:22 trolling? 01:25:29 Er, "your". 01:26:22 The original question was actually "how would a schemeriate actualize an predictive text input algo for maximal pleasure"? 01:26:34 So, you didnt understand, alas 01:27:28 I think it's time that I point out where the door is. 01:27:32 It's over there. --> 01:27:35 Do you see it now? 01:27:52 Yes, go out of it and return once questions like mine seem like fun again. 01:28:07 ;) 01:28:26 -!- adu [~ajr@softbank220043139062.bbtec.net] has quit [Quit: adu] 01:28:29 Did I or did I not answer your original question? 01:29:05 Hm, not really. You sort of nitpicked on the question set and then implied where one might find the answer. 01:29:18 I did? 01:29:47 Yes and then made threatening innuendo thats sure to kill any creativity in this channel. 01:30:18 csmrfx: how about less metadiscussion and back to the predictive text/ 01:30:20 ? 01:30:31 now youre talking 01:30:38 I'm going to make a diagram to show you 01:30:38 I was "creatively" pointing out that your response to my suggestion was, uh, not very helpful. 01:30:50 Can you provide a more useful comment on my suggestion? 01:31:05 xwl_ [~user@esprx01x.nokia.com] has joined #scheme 01:32:02 br1 [~Bruno@r190-135-20-81.dialup.adsl.anteldata.net.uy] has joined #scheme 01:32:11 csmrfx, http://pastie.org/1041859.txt 01:32:32 chandler cant help it if this is too simple a problem for you cs types. 01:32:43 ? 01:33:07 soupdragon: hm, dont quite get it 01:33:38 csmrfx, well trace along the tree to find the word cathode ? 01:33:53 I'm sorry, but I'm baffled. You asked how to implement a predictive text algorithm, and I suggested using a trie (the operations of which naturally lend itself to the problem). So far I've just received abuse in response to this suggestion. 01:34:16 the ... stuff just means I couldnt' be bothered adding that many examples 01:34:38 jcowan [~John@cpe-98-14-172-204.nyc.res.rr.com] has joined #scheme 01:34:38 soupdragon: ok, yes, thats the... idea 01:34:46 what? 01:35:33 well not sure if your pastie represents a dictionary or? 01:35:47 well it's made from a list of words 01:36:17 hm, lemme whip up a dict 01:36:18 but it's a tree -- the idea is that if you have an initial segment of a word, you can follow the path it labels along this tree -- and what's infront of you is a list of words 01:36:25 jonrafkind [~jon@c-67-172-254-235.hsd1.ut.comcast.net] has joined #scheme 01:36:57 csmrfx: In case a link would be more useful to you, have a look at http://en.wikipedia.org/wiki/Trie 01:37:43 Thanks, I already learned about trie in.. cs304 or something 01:37:59 -!- Jafet [~Jafet@unaffiliated/jafet] has quit [Ping timeout: 252 seconds] 01:37:59 SEE 01:38:01 I told you1 01:39:03 I don't get it. What, exactly, are you looking for at this point? Confirmation that it's a good structure to use? Help figuring out how to apply it? Someone to write the code for you? 01:39:49 relax dude 01:40:17 Don't project emotional state onto my questions. 01:41:17 is there an online repl btw? 01:41:22 csmrfx: It's inadvisable to address the master of your (immediate) destiny in such a fashion. 01:41:49 Now now, jcowan. I'm not playing the authority card right now. 01:41:57 I'm honestly just baffled. 01:41:57 somethings wrong with you guys 01:42:09 csmrfx: does that include me? 01:42:16 not really, no 01:42:16 Can you please just provide a straightforward answer to my question? 01:42:27 I will once I get the dict together and pasted 01:43:13 you guys like monty python? 01:45:34 (I still don't understand why you asked the question if you don't know what you were looking for, but: *whatever*.) 01:45:36 ur a good troll 01:45:47 xissburg: Please don't do that. 01:46:15 he is getting you guys into the his game 01:46:21 xissburg: so are you using that subroutine I wrote? 01:46:35 yes, its a good one, soupdragon 01:46:59 I like the idea about writing lots of small functions instead of a few big ones 01:47:10 they can be reused and its easier to test 01:47:22 xissburg: If he's trolling, I can handle it. I've been doing this for a *long* time. 01:47:32 nice :) 01:47:40 if you practice it for a while, you will find that there is much more value to it than currently apparent 01:47:42 jcowan: Oh, and hallo. How goes the battle? 01:48:41 Which of my various battles-in-progress are you interested in? I am once again employed, but Chibi still doesn't build on Cygwin, to pick just two. 01:49:08 yea, I want to practice more of this functional programming stuff, it makes one a better programmer 01:49:49 jcowan: Those two and WG[n] would come to mind. Congratulations on the employment. Is it interesting work? 01:49:50 I call it procedural programming btw 01:50:07 not sure if that's standard yet 01:50:37 Alas, I don't know yet, as I haven't done any. I've only bumped up against config problems out of my control that, seemingly, can only be fixed by people currently on vacation. 01:51:13 My current project involves designing a more intelligent schema for a large body of existing documents which are only minimally marked up. 01:51:31 WG1 has been in the doldrums lately, and WG2 is in hibernation. 01:51:32 Ah. Sounds at least plausibly interesting. 01:52:11 (The job, that is, not the state of the WGs.) 01:54:17 -!- proq [~user@unaffiliated/proqesi] has quit [Ping timeout: 265 seconds] 01:55:27 -!- curi_ [~curi@adsl-99-114-139-86.dsl.pltn13.sbcglobal.net] has quit [Quit: This computer has gone to sleep] 01:55:37 foof says that the priority is to get VC++ building working (he currently has only MinGW), and I have to agree in general. 01:55:56 But I'm surely not the Last Cygwin User Standing. 01:56:26 Honestly, I'm more interested in VC++ myself. 01:56:32 Jafet [~Jafet@unaffiliated/jafet] has joined #scheme 01:59:37 -!- xwl_ [~user@esprx01x.nokia.com] has quit [Remote host closed the connection] 02:00:15 xwl_ [~user@esprx01x.nokia.com] has joined #scheme 02:03:37 -!- xwl_ [~user@esprx01x.nokia.com] has quit [Remote host closed the connection] 02:04:10 xwl_ [~user@esprx01x.nokia.com] has joined #scheme 02:09:21 jcowan: if you want to try something, change the heap alignment to 5 bits 02:10:49 Okay. I've had the same result on 64 and 32-bit Windows, though. 02:14:00 -!- jmcphers [~jmcphers@218.185.108.156] has quit [Ping timeout: 260 seconds] 02:15:29 Well, waddaya know. Cygwin is 32-bit even on Win64. 02:15:56 Or maybe that's just because Windows is LLP64 instead of LP64? 02:16:16 -!- br1 [~Bruno@r190-135-20-81.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] 02:16:38 Is there even a 64-bit gcc for Windows yet? 02:17:26 Ah, yes, there is. Apparently I had some thought that there was an issue with that. 02:17:31 BTW, I currently have only VC++. 02:17:41 jmcphers [~jmcphers@218.185.108.156] has joined #scheme 02:17:53 I did a quick cygwin install before going to work this morning, but I don't think it even included gcc. 02:19:05 A default install does not. 02:19:17 RageOfThou [~RageOfTho@users-55-120.vinet.ba] has joined #scheme 02:19:41 I'm running over VMware though, so everything is slow and annoying and I'm going mad from all the popups and notices and restarts and OH PLEASE GOD MAKE IT STOP!!!! 02:19:42 -!- MrFahrenheit [~RageOfTho@users-55-120.vinet.ba] has quit [Read error: No route to host] 02:20:43 Gcc is not installed by default. Just rerun the program and click on the various GCC packages so they say Install rather than Skip. Or just click on All, which will create a full install (it takes time for the click to be effective, so don't do more than one) 02:23:16 It's funny, VC++ thinks it knows how to just build anything by default, and the secret to getting it working is to tell it _not_ to build individual files. 02:24:29 aidalgol [~user@202.36.179.65] has joined #scheme 02:29:23 The other thing is if boehm is packaged with cygwin to try that. 02:30:22 sunnyps [~sunny@95.snat-111-91-127.hns.net.in] has joined #scheme 02:31:40 *jcowan* nods. 02:31:54 I'd think the precise GC would be more likely to work, though. 02:32:47 Any line on the hang yet? 02:44:41 Haven't had a chance to look at it yet, will try tonight when I get home from work. 02:44:56 What's the real difference between the following (define (local [(define (f x) x)] ...)) (define (define (f x x) ....) ? 02:45:24 ) 02:45:51 I'm trying to track down the mysterious "array subscript is a char" message. Oddly, it happens in only two of three places where that variable (which is *not* a char) is used as a subscript. 02:48:27 probably just need to cast to unsigned char 02:51:06 No, the problem is that you are passing a char to isalpha() and tolower(), but because they are macros rather than functions, the usual arithmetic conversions aren't done. So it needs to be isalpha((int)arg[len-1]). 02:51:22 The array in question is the array to which isalpha() and tolower() pass their arguments. 02:51:41 So evidently this works in glibc but not in newlib. 02:54:03 It's just a warning to remind you that char may be signed, causing a negative array index. I'm sure if you use unsigned char instead of int it would get rid of the warning (and possibly an explicit "signed char" would work too). 02:56:08 However, the man pages document that an int is expected. 02:56:28 That's so you can pass EOF, which is -1, to these macros. 02:56:54 Yes, but if isalpha was implemented as a function, the char would be implicitly promoted to int. I think the macro implementation needs to do the cast internally. 02:57:03 In other words, I think this is a bug in the C library. 02:57:20 Fair enough, which would explain why it surfaces only in Cygwin. 02:57:59 However, it will take donkey's years to get fixed: I have to file a newlib bug, which the newlib maintainers have to fix, and then persuade the Cygwin maintainers to incorporate the newlib patch. 02:58:03 I have seen this in other operating systems. 02:58:13 I don't remember which, but probably either Mac OS X or NetBSD. 02:59:14 waltermai [~walt@99-12-124-66.lightspeed.brhmal.sbcglobal.net] has joined #scheme 02:59:30 With -Wall, GCC flags a warning when passing a char to isalpha under NetBSD. 03:00:39 Not GCC 4.4.4 under GNU/Linux (some flavour of Fedora), though, not even with -Wextra. 03:01:19 ctype.h on this GNU/Linux system has an explicit cast to int. 03:02:03 So I figured. So defensive programming demands that you stick to the spec and pass only int-typed expressions. 03:02:21 Oh good, then you can pass it anything without a warning! 03:02:34 On Linux, yes. 03:02:59 Well, any scalar. 03:03:15 So apparently glibc and msclib have internal defenses, but BSD libc and newlib do not. 03:03:29 Pass it only int-typed expressions that either are representible as unsigned char or are EOF. 03:03:39 We're only talking 4 places in the code base, foof. 03:03:51 Quite so, otherwise you get undefined results. 03:03:57 er, undefined effect, I mean. 03:04:21 jcowan: It's not so much a matter of "defenses", but whether the macro definition of the function is required to promote its arguments as a function call would. 03:05:05 I'm not sure C99 actually speaks to that. 03:05:19 Suppose that it did promote its arguments, chandler. Passing a signed char is still dangerous, then, because some values, namely the negative ones, are not representible as unsigned char. 03:05:39 Of course, the same is true of passing signed ints... 03:05:44 (and unsigned ints) 03:06:00 of course, the best isalpha doesn't use a table 03:06:35 -!- luz [~davids@189.60.69.82] has quit [Quit: Client exiting] 03:06:44 #define ISALPHA(c) (((c) | 32) - 'a' + 0U <= 'z' - 'a' + 0U) 03:07:00 Indeed. I'm merely suggesting that the macro ought to promote anyway to ensure consistent behavior between the function version and the macro version. 03:07:24 I think the behaviour is consistent, chandler, except for the compiler warning. 03:07:56 That's actually the behavior I was thinking of. :-) 03:08:57 warning: foo.c:1:1: you have written a program in C. Expect demonic olfactory emanations. 03:10:25 Aw shucks. That'll throw a spanner into my habit of using -Wall -Werror. 03:10:32 (I'm not arguing; I'm just (poorly attempting) advocating for Mr Lucifer, who, after all, needs to put his demons to some use.) 03:12:36 -!- leppie [~lolcow@196-215-36-144.dynamic.isadsl.co.za] has quit [Read error: Connection reset by peer] 03:13:14 leppie [~lolcow@196-215-36-144.dynamic.isadsl.co.za] has joined #scheme 03:13:36 -!- bgs100 [~ian@unaffiliated/bgs100] has quit [Quit: Leaving] 03:14:17 Good thing Cyrano de Bergerac wasn't a C programmer. 03:14:50 foof: Uhh, wtf? 03:16:11 Posix says "shall be functions and may also be provided as macros." Considering that this is by no means the inside loop, you could just #undef isalpha and tolower. 03:16:52 But...but then my characterwise case conversions wouldn't run blazingly fast, jcowan! 03:18:48 The problematic instances are in the -h option, which sets the heap size in K/k or M/m, and in parsing #xnnnn datum values. 03:18:49 jcowan: You could equally call it as (isalpha)(c), I think. 03:20:35 True. 03:21:10 Or just take the easy way out and cast at the call site. :-) 03:22:02 Yes, the (isalpha) gimmick works nicely. 03:22:12 And it's not global, unlike #undef. 03:24:27 -!- JoelMcCracken [~joelmccra@pool-96-236-166-183.pitbpa.east.verizon.net] has quit [Quit: Leaving] 03:28:04 -!- twobitsprite [~isaac@li24-165.members.linode.com] has left #scheme 03:29:32 drwho [~drwho@c-76-124-164-157.hsd1.pa.comcast.net] has joined #scheme 03:34:00 hohoho [~hohoho@p4ae269.tokynt01.ap.so-net.ne.jp] has joined #scheme 03:37:08 -!- MononcQc [~Ferd@modemcable062.225-20-96.mc.videotron.ca] has quit [Quit: Leaving] 03:37:44 -!- waltermai [~walt@99-12-124-66.lightspeed.brhmal.sbcglobal.net] has quit [Quit: Leaving] 03:49:27 -!- MichaelRaskin [~MichaelRa@195.91.224.225] has quit [Remote host closed the connection] 03:51:42 waltermai [~user@99-12-124-66.lightspeed.hstntx.sbcglobal.net] has joined #scheme 04:04:09 -!- hohoho [~hohoho@p4ae269.tokynt01.ap.so-net.ne.jp] has quit [Quit: Leaving...] 04:10:06 -!- xissburg [~chatzilla@187.3.136.142] has quit [Quit: lawl] 04:24:20 MichaelRaskin [~MichaelRa@pantagruel.mccme.ru] has joined #scheme 04:28:14 -!- jcowan [~John@cpe-98-14-172-204.nyc.res.rr.com] has quit [Quit: Leaving] 04:28:17 hohoho [~hohoho@p4ae269.tokynt01.ap.so-net.ne.jp] has joined #scheme 04:31:07 -!- eno [~eno@nslu2-linux/eno] has quit [Read error: Connection reset by peer] 04:33:26 eno [~eno@nslu2-linux/eno] has joined #scheme 04:37:48 -!- TR2N [email@89.180.161.235] has left #scheme 04:40:15 joshcryer [~g@unaffiliated/joshcryer] has joined #scheme 04:49:08 -!- nicktick [debian-tor@gateway/tor-sasl/nicktick] has quit [Remote host closed the connection] 05:00:16 -!- adadglgmut [~adadgltmu@cpe-174-100-207-183.neo.res.rr.com] has quit [Max SendQ exceeded] 05:00:42 adadglgmut [~adadgltmu@cpe-174-100-207-183.neo.res.rr.com] has joined #scheme 05:01:57 -!- aidalgol [~user@202.36.179.65] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 05:02:12 -!- davazp [~user@83.55.180.105] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 05:05:45 -!- Obfuscate [~keii@ip98-176-17-38.sd.sd.cox.net] has quit [Ping timeout: 240 seconds] 05:06:19 -!- rwhetsel [~fourtytwo@173-8-31-81-WashingtonDC.hfc.comcastbusiness.net] has quit [Quit: Leaving.] 05:17:15 -!- drwho [~drwho@c-76-124-164-157.hsd1.pa.comcast.net] has quit [Quit: A known mistake is better than an unknown truth.] 05:28:08 rtra [~rtra@unaffiliated/rtra] has joined #scheme 05:32:45 -!- RageOfThou [~RageOfTho@users-55-120.vinet.ba] has quit [Ping timeout: 265 seconds] 05:41:00 -!- soupdragon [~quantum@unaffiliated/fax] has quit [Quit: soupdragon] 05:49:31 bombshelter13b [~bombshelt@76-10-149-209.dsl.teksavvy.com] has joined #scheme 05:51:46 -!- kniu [~kniu@pool-71-105-64-193.lsanca.dsl-w.verizon.net] has quit [Quit: Leaving] 06:03:00 nicktick [debian-tor@gateway/tor-sasl/nicktick] has joined #scheme 06:03:04 -!- rtra [~rtra@unaffiliated/rtra] has quit [Quit: bye] 06:04:28 kniu [~kniu@pool-71-105-64-193.lsanca.dsl-w.verizon.net] has joined #scheme 06:22:33 -!- jonrafkind [~jon@c-67-172-254-235.hsd1.ut.comcast.net] has quit [Ping timeout: 240 seconds] 06:31:38 alexsuraci [~alexsurac@pool-71-188-133-67.aubnin.fios.verizon.net] has joined #scheme 06:51:43 -!- ASau [~user@83.69.227.32] has quit [Ping timeout: 260 seconds] 06:52:30 -!- bombshelter13b [~bombshelt@76-10-149-209.dsl.teksavvy.com] has quit [Quit: bombshelter13b] 06:53:37 -!- leppie [~lolcow@196-215-36-144.dynamic.isadsl.co.za] has quit [Read error: Connection reset by peer] 06:54:15 leppie [~lolcow@196-215-36-144.dynamic.isadsl.co.za] has joined #scheme 06:59:33 mmc [~michal@host3-82-static.28-87-b.business.telecomitalia.it] has joined #scheme 07:11:28 -!- sladegen [~nemo@unaffiliated/sladegen] has quit [Ping timeout: 258 seconds] 07:11:30 -!- waltermai [~user@99-12-124-66.lightspeed.hstntx.sbcglobal.net] has quit [Remote host closed the connection] 07:14:32 pdelgallego [~pdelgalle@1503031474.dhcp.dbnet.dk] has joined #scheme 07:15:54 -!- katesmith [~katesmith@unaffiliated/costume] has quit [Quit: Leaving] 07:16:40 -!- xwl_ [~user@esprx01x.nokia.com] has quit [Remote host closed the connection] 07:17:19 sladegen [~nemo@unaffiliated/sladegen] has joined #scheme 07:17:45 xwl_ [~user@esprx01x.nokia.com] has joined #scheme 07:55:37 -!- xwl_ [~user@esprx01x.nokia.com] has quit [Remote host closed the connection] 07:56:06 xwl_ [~user@esprx01x.nokia.com] has joined #scheme 07:56:14 -!- xwl_ [~user@esprx01x.nokia.com] has quit [Remote host closed the connection] 07:56:46 xwl_ [~user@esprx01x.nokia.com] has joined #scheme 07:57:29 -!- mmc [~michal@host3-82-static.28-87-b.business.telecomitalia.it] has quit [Quit: Leaving.] 07:57:36 dammit, does anyone have a mnemonic for remembering the order of arguments to KONS in FOLD? 07:58:06 yeah, it's the same as cons :) 07:58:08 i end up testing anew a couple times a week whether its ELEMENT followed by ACCUMULATE or vice versa 07:58:18 sjamaan: oh, shit; that's fantastic. 07:58:26 haha 07:58:54 it reminds me of the mnemonic that `ls' is like `cp'. 07:59:03 s/ls/ln/ 07:59:29 my trouble stems from those trolls at the R project, i think, who reversed the order for Reduce. 07:59:33 yeah, I keep forgetting that one too, but that mnemonic helps (if I remember it) 08:01:24 thanks, man; you saved me a lot of trouble. i felt like sviatoslav richter who claimed, for the life of him, that he could not (under any circumstances) memorize mozart. 08:01:33 kons is slightly less grandiose, of course. 08:02:44 :) 08:02:49 you're most welcome 08:12:15 ineiros [~itniemin@james.ics.hut.fi] has joined #scheme 08:18:12 -!- nicktick [debian-tor@gateway/tor-sasl/nicktick] has quit [Ping timeout: 245 seconds] 08:22:03 nicktick [debian-tor@gateway/tor-sasl/nicktick] has joined #scheme 08:31:06 klutometis : some people reverse the order for `fold-left's (which kinda makes sense) 08:32:21 (fold-left snok nil (list a b c d)) 08:32:21 = (snok (snoc (snoc (snoc nil a) b) c) d) 08:34:28 *ski* notes that Haskell does this, but neither SML nor OCaml .. the latter swaps the order of `nil' and the list in `foldr_right', though .. 08:48:22 ski: oh, fascinating 08:48:34 chittoor [~chittoor@listertech.in] has joined #scheme 08:52:14 masm [~masm@2.80.136.217] has joined #scheme 08:53:03 -!- Intensity [gnjnSDjgDl@unaffiliated/intensity] has quit [Ping timeout: 258 seconds] 08:53:19 gravicappa [~gravicapp@80.90.116.82] has joined #scheme 09:05:52 lvillani [~lvillani@fedora/lvillani] has joined #scheme 09:07:22 R3cur51v3 [~Recursive@rrcs-97-77-55-38.sw.biz.rr.com] has joined #scheme 09:09:34 wow, "higher order perl" is crap 09:11:55 "3.1 Caching Fixes Recursion" 09:16:39 -!- chemuduguntar [~ravi@219-89-49-140.dialup.xtra.co.nz] has quit [Quit: Leaving] 09:18:30 I didn't know recursion was broken 09:19:33 .. surely "Fixes" must refer to (least ?) fixed-points ? 09:21:18 jgracin [~jgracin@dh111-186.xnet.hr] has joined #scheme 09:23:20 Komi [Komi@62.32.130.35] has joined #scheme 09:23:32 hi 09:26:41 -!- jao [~user@83.43.34.249] has quit [Ping timeout: 265 seconds] 09:35:40 katesmith [~katesmith@unaffiliated/costume] has joined #scheme 09:43:15 -!- R3cur51v3 [~Recursive@rrcs-97-77-55-38.sw.biz.rr.com] has quit [Ping timeout: 240 seconds] 09:53:59 IJP_ [~Ian@host86-174-102-240.range86-174.btcentralplus.com] has joined #scheme 09:55:58 -!- IJP [~Ian@host86-174-204-139.range86-174.btcentralplus.com] has quit [Ping timeout: 276 seconds] 09:57:09 -!- nicktick [debian-tor@gateway/tor-sasl/nicktick] has quit [Remote host closed the connection] 09:59:24 alvatar [~alvatar@59.127.222.87.dynamic.jazztel.es] has joined #scheme 10:03:14 Any idea if X-less distribution is supported after that "racquet rebranding"? 10:03:51 I can use mzscheme fine without X 10:04:27 -!- IJP_ [~Ian@host86-174-102-240.range86-174.btcentralplus.com] has quit [Ping timeout: 240 seconds] 10:06:15 -!- mbohun [~mbohun@202.124.75.252] has quit [Quit: Leaving] 10:06:35 IJP [~Ian@host86-185-165-92.range86-185.btcentralplus.com] has joined #scheme 10:09:13 ASau``: racket-textual 10:09:27 Thanks! 10:10:02 -!- jmcphers [~jmcphers@218.185.108.156] has quit [Remote host closed the connection] 10:10:20 http://download.racket-lang.org/installers/5.0/racket-textual/ 10:11:05 Yeah, got it. 10:12:39 jao [~user@74.Red-80-24-4.staticIP.rima-tde.net] has joined #scheme 10:14:25 It's also included in the full distribution, so you can get the whole thing and run only the racket repl when outside X too. 10:16:35 -!- leppie [~lolcow@196-215-36-144.dynamic.isadsl.co.za] has quit [Read error: Connection reset by peer] 10:17:12 leppie [~lolcow@196-215-36-144.dynamic.isadsl.co.za] has joined #scheme 10:18:40 -!- kilimanjaro [~kilimanja@unaffiliated/kilimanjaro] has quit [Quit: Leaving] 10:24:55 HG` [~HG@xdsl-92-252-110-117.dip.osnanet.de] has joined #scheme 10:28:12 -!- joshcryer [~g@unaffiliated/joshcryer] has quit [Ping timeout: 260 seconds] 10:33:17 rudybot: eval (quotient/remainder pi (atan 1)) 10:33:18 ski: error: quotient/remainder: expects type as 1st argument, given: 3.141592653589793; other arguments were: 0.7853981633974483 10:35:21 rudybot: eval (quotient/remainder (/ 120 17) (/ 18 7)) ; presumably this doesn't work either, then 10:35:21 ski: error: quotient/remainder: expects type as 1st argument, given: 120/17; other arguments were: 18/7 10:42:34 schmir [~schmir@mail.brainbot.com] has joined #scheme 10:52:12 Obfuscate [~keii@ip98-176-17-38.sd.sd.cox.net] has joined #scheme 10:54:57 stis [~stis@1-1-1-39a.veo.vs.bostream.se] has joined #scheme 10:59:15 -!- kniu [~kniu@pool-71-105-64-193.lsanca.dsl-w.verizon.net] has quit [Ping timeout: 240 seconds] 11:03:16 kniu [~kniu@pool-71-105-64-193.lsanca.dsl-w.verizon.net] has joined #scheme 11:03:21 homie [~user@xdsl-78-34-235-241.netcologne.de] has joined #scheme 11:04:52 foof` [~user@lain.inunome.com] has joined #scheme 11:06:28 -!- foof [~user@lain.inunome.com] has quit [Ping timeout: 260 seconds] 11:10:24 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #scheme 11:10:31 -!- kniu [~kniu@pool-71-105-64-193.lsanca.dsl-w.verizon.net] has quit [Ping timeout: 276 seconds] 11:11:30 kniu [~kniu@pool-71-105-64-193.lsanca.dsl-w.verizon.net] has joined #scheme 11:28:38 -!- schmir [~schmir@mail.brainbot.com] has quit [Remote host closed the connection] 11:29:02 schmir [~schmir@mail.brainbot.com] has joined #scheme 11:41:10 fradgers- [~fradgers-@5adb10a1.bb.sky.com] has joined #scheme 12:05:34 -!- stis [~stis@1-1-1-39a.veo.vs.bostream.se] has quit [Read error: Connection reset by peer] 12:07:30 nicktick [debian-tor@gateway/tor-sasl/nicktick] has joined #scheme 12:09:59 Intensity [NTn3PruECG@unaffiliated/intensity] has joined #scheme 12:12:41 nataraj [~nataraj@122.165.223.135] has joined #scheme 12:13:14 is there a scheme optimised for Arm-linux ? 12:14:02 -!- xwl_ [~user@esprx01x.nokia.com] has quit [Remote host closed the connection] 12:14:36 xwl_ [~user@esprx01x.nokia.com] has joined #scheme 12:16:28 -!- paint [~paint@unaffiliated/paint] has quit [Quit: IRC is just a multiplayer Notepad] 12:19:29 paint [~paint@unaffiliated/paint] has joined #scheme 12:25:23 -!- hohoho [~hohoho@p4ae269.tokynt01.ap.so-net.ne.jp] has quit [Ping timeout: 260 seconds] 12:31:05 -!- Komi [Komi@62.32.130.35] has quit [Ping timeout: 246 seconds] 12:57:36 -!- alvatar [~alvatar@59.127.222.87.dynamic.jazztel.es] has quit [Quit: leaving] 12:57:40 alvatar [~alvatar@59.127.222.87.dynamic.jazztel.es] has joined #scheme 13:02:23 -!- foof` is now known as goof 13:02:28 -!- goof is now known as foof 13:03:23 -!- nataraj [~nataraj@122.165.223.135] has quit [Quit: Leaving] 13:10:27 -!- homie [~user@xdsl-78-34-235-241.netcologne.de] has quit [Ping timeout: 240 seconds] 13:18:17 bgs100 [~ian@unaffiliated/bgs100] has joined #scheme 13:24:13 -!- jgracin [~jgracin@dh111-186.xnet.hr] has quit [Quit: Ex-Chat] 13:43:24 adu [~ajr@softbank220043139062.bbtec.net] has joined #scheme 13:48:24 xwl [~user@123.115.120.111] has joined #scheme 13:56:09 mmc [~michal@109.112.23.225] has joined #scheme 13:58:16 hohoho [~hohoho@ntkngw227224.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 14:00:06 dzhus [~sphinx@89-178-249-129.broadband.corbina.ru] has joined #scheme 14:00:35 -!- hohoho [~hohoho@ntkngw227224.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Remote host closed the connection] 14:05:20 homie [~user@xdsl-78-34-218-138.netcologne.de] has joined #scheme 14:07:23 -!- homie [~user@xdsl-78-34-218-138.netcologne.de] has quit [Client Quit] 14:07:41 -!- mmc [~michal@109.112.23.225] has quit [Ping timeout: 246 seconds] 14:09:37 -!- HG` [~HG@xdsl-92-252-110-117.dip.osnanet.de] has quit [Ping timeout: 264 seconds] 14:12:26 davazp [~user@83.55.180.105] has joined #scheme 14:14:32 davazp` [~user@83.55.180.105] has joined #scheme 14:15:09 -!- davazp` [~user@83.55.180.105] has quit [Remote host closed the connection] 14:15:20 -!- davazp [~user@83.55.180.105] has quit [Client Quit] 14:15:45 MrFahrenheit [~RageOfTho@users-55-120.vinet.ba] has joined #scheme 14:16:15 homie [~user@xdsl-78-34-218-138.netcologne.de] has joined #scheme 14:27:16 mmc [~michal@109.116.134.129] has joined #scheme 14:35:43 -!- MichaelRaskin [~MichaelRa@pantagruel.mccme.ru] has quit [Remote host closed the connection] 14:38:18 -!- schmir [~schmir@mail.brainbot.com] has quit [Ping timeout: 248 seconds] 14:38:36 bombshelter13b [~bombshelt@76-10-149-209.dsl.teksavvy.com] has joined #scheme 14:38:52 -!- MrFahrenheit [~RageOfTho@users-55-120.vinet.ba] has quit [Read error: No route to host] 14:39:06 MrFahrenheit [~RageOfTho@users-55-120.vinet.ba] has joined #scheme 14:39:08 JoelMcCracken [~joelmccra@66.37.58.254] has joined #scheme 14:48:11 HG` [~HG@xdsl-92-252-82-5.dip.osnanet.de] has joined #scheme 14:55:18 -!- sladegen [~nemo@unaffiliated/sladegen] has quit [Ping timeout: 258 seconds] 14:56:27 -!- mmc [~michal@109.116.134.129] has quit [Ping timeout: 258 seconds] 14:57:18 Zot! 14:58:09 Blargh! 14:58:19 Crazy folks :-) 14:59:32 -!- xwl [~user@123.115.120.111] has quit [Remote host closed the connection] 15:00:15 -!- HG` [~HG@xdsl-92-252-82-5.dip.osnanet.de] has quit [Ping timeout: 265 seconds] 15:02:20 Znort 15:02:33 Oh, and Frotz. 15:04:48 Plugh! 15:09:29 luz [~davids@189.60.69.82] has joined #scheme 15:11:46 schmir [~schmir@mail.brainbot.com] has joined #scheme 15:12:00 I have been persuaded that continuation barriers are useful, because they allow one to report re-entrance errors safely. 15:13:57 Specifically, if, from a dynamic context D, one tries to re-enter an extent in a dynamic context D' protected by a continuation barrier, the error is reported in D, so that it is handled by a handler in D and stack may be unwound from D. Using DYNAMIC-WIND and ERROR causes the error to be handled in D', and may cause D' to unwind, triggering the release of resources that the previous entrance of D' needed. 15:14:34 And this requires cooperation from CWCC; it can't be expressed in terms of the existing CWCC and DYNAMIC-WIND. 15:17:54 Discuss! 15:19:26 *offby1* talks about mining 15:19:48 -!- gravicappa [~gravicapp@80.90.116.82] has quit [Ping timeout: 260 seconds] 15:21:13 Riastradh, when you express it that way, it actually does sound like a good idea. Moreover, it sounds like the option to be able to handle errors in either context is useful, and it looks like the addition of continuation barriers lets authors make that fine-grained choice. Nice! 15:24:50 That said, I wonder whether it would be better for DYNAMIC-WIND to prohibit simultaneous use in multiple threads, and to introduce a variant of DYNAMIC-WIND that should be used only when it is known that the effects are thread-local. 15:25:10 so I try to deploy an application having two scheme files and an egg. How would you do that? 15:25:35 -!- nicktick [debian-tor@gateway/tor-sasl/nicktick] has quit [Remote host closed the connection] 15:27:17 Suddenly I am having some trouble constructing an example in which DYNAMIC-WIND and ERROR cause the class of problem I described. 15:28:21 In particular, I wrote (dynamic-wind set-cruft-up (lambda () (with-continuation-barrier ...)) tear-cruft-down). But this doesn't protect against multiple invocations of SET-CRUFT-UP. 15:28:49 sepisultrum: I wish I knew 15:28:55 If I invert the DYNAMIC-WIND and WITH-CONTINUATION-BARRIER, then the problem also goes away, because there is no danger of tearing cruft down even if WITH-CONTINUATION-BARRIER is defined in terms of DYNAMIC-WIND 15:28:59 . 15:30:19 Can anyone help me to construct an example that loses here? 15:33:00 I suppose it would be helpful for the purpose of debugging to see in the stack trace where the re-entering continuation was invoked, but that information is actually available in, say, Scheme48 and MIT Scheme. 15:34:40 offby1: damn 15:44:04 davazp [~user@83.55.180.105] has joined #scheme 15:45:13 kar8nga [~kar8nga@k-220.vc-graz.ac.at] has joined #scheme 15:46:17 I thought that continuation barriers would be useful when running 'untrusted' code (eg, in some kind of sandbox) 15:46:51 If you call a callback into some sandbox and it keeps a continuation, then you call again later and it invokes that stored continuation, then it can mess with *your* flow of control, with potentially dangerous results 15:47:32 In Chicken, people sometimes mess with call/cc at the repl and are surprised when they re-invoke a stored continuation from previously entered expression, and thereby wind the *repl* back to its earlier state 15:47:44 ...which is related. 15:49:59 Continuation delimiters or evaluating each expression in its own thread would help with that. Continuation barriers would just wedge your REPL and render it unusable! 15:57:03 -!- kar8nga [~kar8nga@k-220.vc-graz.ac.at] has quit [Read error: Connection reset by peer] 15:59:05 Blkt [~user@dynamic-adsl-78-13-252-73.clienti.tiscali.it] has joined #scheme 16:01:56 jonrafkind [~jon@crystalis.cs.utah.edu] has joined #scheme 16:06:29 -!- jonrafkind [~jon@crystalis.cs.utah.edu] has quit [Read error: Connection reset by peer] 16:07:10 jonrafkind [~jon@crystalis.cs.utah.edu] has joined #scheme 16:07:16 mmc [~michal@109.116.194.105] has joined #scheme 16:08:36 nowhereman [~pierre@AStrasbourg-551-1-17-210.w86-213.abo.wanadoo.fr] has joined #scheme 16:09:23 -!- nowhere_man [~pierre@AStrasbourg-551-1-76-104.w81-51.abo.wanadoo.fr] has quit [Ping timeout: 260 seconds] 16:11:50 curi_ [~curi@adsl-99-114-139-86.dsl.pltn13.sbcglobal.net] has joined #scheme 16:14:13 jewel [~jewel@196-210-134-12.dynamic.isadsl.co.za] has joined #scheme 16:16:11 -!- schmir [~schmir@mail.brainbot.com] has quit [Remote host closed the connection] 16:18:29 -!- mmc [~michal@109.116.194.105] has quit [Ping timeout: 258 seconds] 16:18:35 Fabse [~mightyfid@wikipedia/Track-n-Field] has joined #scheme 16:18:54 -!- lvillani [~lvillani@fedora/lvillani] has quit [Quit: Leaving] 16:19:26 -!- jao [~user@74.Red-80-24-4.staticIP.rima-tde.net] has quit [Ping timeout: 265 seconds] 16:24:19 -!- adu [~ajr@softbank220043139062.bbtec.net] has quit [Quit: adu] 16:24:45 stis [~stis@1-1-1-39a.veo.vs.bostream.se] has joined #scheme 16:27:10 -!- sunnyps [~sunny@95.snat-111-91-127.hns.net.in] has quit [Ping timeout: 265 seconds] 16:29:22 That depends what one means by barriers or delimiters... I presumed a barrier would error when trying to invoke a continuation that would jump into a barrier-protected region other than from within that region, from "if, from a dynamic context D, one tries to re-enter an extent in a dynamic context D' protected by a continuation barrier, the error is reported in D"? 16:29:37 So the REPL would report this error when you tried to invoke that stored continuation 16:30:05 It would say "Ha, you asked me to do something that would involve altering my own perception of time, and that's confusing for you (if not for me). So don't!", or words to that effect. 16:30:09 Think (define (with-continuation-barrier p) (dynamic-wind (let ((d? #f)) (lambda () (if d? (error)) (set! d? #t))) p (lambda () 0))) 16:30:45 Aye 16:30:53 The difference is that the error is signalled in the dynamic context of the continuation's invocation, not of the DYNAMIC-WIND. 16:31:08 That is, the difference between this definition and the real WITH-CONTINUATION-BARRIER. 16:31:10 alaricsp, I would love to have a repl which reacted with error messages precisely like that, or at least with error messages which included a verbose component like that. 16:31:25 gnomon: It's odd that there's a well-entrenched culture of terse error messages 16:31:46 Continuation delimiters are unrelated beasts. 16:32:15 gnomon: As part of a distributed system I wrote, I produced an error that reads ""We have received a message with a sequence number *less* than the one w 16:32:15 e believe we're complete up to. This is probably because we skipped ahead in the past because w 16:32:15 e believed a message was lost for good. The sequence number we believe we've seen everything up 16:32:15 to is %u, and the one we just received is %u." 16:32:23 Ugh, wrapping, sorry 16:33:11 People stare in awe when they see it, and deride my verbosity. I then ask them how else to phrase that (rare) error message so that it will make sense to people... 16:33:19 alaricsp, nice! That's very informative, and even provides a hint about the most likely source of the error! 16:33:35 gnomon: That this is considered "surprising" says bad things about the software industry ;-) 16:35:55 Riastradh: Continuation delimiting seems to be what I otherwise know of as a partial continuation, right? Yes, unrelated. 16:35:57 If you had (print (with-continuation-barrier (let ((input (read))) (lambda () (eval input env))))), and the input expression exited, you would never be able to return to the REPL; it would be lost and gone forever. 16:36:28 Yes, alaricsp -- `delimited', `partial', and `composable continuation' are different names for a common concept. 16:36:46 nicktick [debian-tor@gateway/tor-sasl/nicktick] has joined #scheme 16:36:52 *nod* 16:37:44 Riastradh: Yeah, but REPLs tend to have a top-level capture-all-errors handler that prints the error and restarts the REPL; I'd assumed the barrier would be placed within that, so a barrier violation was caught and reported, and the REPL restarted with a new (read), right? 16:38:34 I've been meaning to look into compact serialisaton of partial continuations, to make "properly" continuation-based web frameworks more practical 16:38:51 No, that's just the trouble. If you naively use DYNAMIC-WIND, you may return to an earlier REPL state. If you use real continuation barriers, you can't ever enter the REPL again! 16:39:16 (those being ones that actually serialise (and sign!) the continuation and send it back to the browser to be fed back to the server in a URL or form field) 16:39:25 -!- eno [~eno@nslu2-linux/eno] has quit [Read error: Connection reset by peer] 16:39:39 mmc [~michal@109.116.137.123] has joined #scheme 16:39:53 (which are currently not very practical as continuations tend to be large, but a lot of that will be a load of context from your web app framework and other such stuff that really needn't be there, thus the interest in partial continuations) 16:40:06 hhomar [~hhomar@92.26.74.102] has joined #scheme 16:41:02 Well, that's not quite true. If all you do is save a continuation in one REPL input, and invoke it in another, then continuation barriers will work to make sure the REPL stays OK. But you can do worse things that continuation barriers won't help. 16:41:37 Riastradh: Hrm... I'll have to draw myself a diagram to see what the problem is, I think. And look up what dynamic environment the thunks of dynamic-wind are supposed to run in... 16:41:38 Ah, right 16:41:44 What are the Worse Things? 16:42:03 Example: spawn a thread, and save a continuation in the thread. Then in the next REPL input, invoke the continuation you saved from the thread. Now you've exited and can't get back into the REPL. 16:42:10 (I have a sick fascination for extreme continuation knitting) 16:42:46 *alaricsp* thinks about that 16:42:55 (define placeholder (make-placeholder)) (spawn (lambda () (call-with-current-continuation (lambda (k) (placeholder-set! placeholder k) (suspend))))) ((placeholder-value k)) 16:43:02 ...er, ((placeholder-value placeholder)) 16:44:13 eno [~eno@nslu2-linux/eno] has joined #scheme 16:44:45 A placeholder is just a thread-safe mutable cell, right? 16:45:07 It's a single-write cell on which readers block until it is written to. 16:45:21 And (suspend) is... some eternal sleep so the thread doesn't terminate? 16:45:31 Actually, (suspend) is a red herring; forget about it. 16:45:41 The thread can terminate; it has no further reason to exist. 16:45:47 *alaricsp* nods 16:46:52 -!- homie [~user@xdsl-78-34-218-138.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 16:50:08 (This example works, by the way, only in Scheme systems whose threads do not inherit the dynamic context of their spawners.) 16:50:17 sladegen [~nemo@unaffiliated/sladegen] has joined #scheme 16:50:19 (or rather, it successfully demonstrates failure) 16:50:34 *alaricsp* goes and checks the SRFI-18 paragraphs on dynamic environments again 16:50:44 R3cur51v3 [~Recursive@97.77.55.38] has joined #scheme 16:52:11 Yes, as I thought. SRFI-18 requires that thread transfers are done with Special Magic Continuations that don't attract the attention of dynamic-wind 16:52:18 Right, back to the problem at hand... 16:54:16 Recur51v3 [~Recursive@rrcs-97-77-55-38.sw.biz.rr.com] has joined #scheme 16:54:43 IJP_ [~Ian@host86-135-143-76.range86-135.btcentralplus.com] has joined #scheme 16:55:13 Yes, if a thread starts in a 'fresh' dynamic context, then there's a way for some "sandboxed" code to create "non-sandboxed" continuations. However, I suppose that continuation then can't reference the REPL's continuation any more, so there's no winding-back-time issue there. However, our ((placeholder-value placeholder)) call will take us to a continuation from outside that REPL's eval, being from the thread (which might be picked up with careful 16:55:14 use of dynamic-wind, although that may be bypassable) 16:56:32 -!- IJP [~Ian@host86-185-165-92.range86-185.btcentralplus.com] has quit [Ping timeout: 245 seconds] 16:56:53 -!- Recur51v3 [~Recursive@rrcs-97-77-55-38.sw.biz.rr.com] has quit [Client Quit] 16:57:49 -!- mmc [~michal@109.116.137.123] has quit [Ping timeout: 276 seconds] 16:59:11 Although it isn't a continuation that lets you do anything you couldn't otherwise, I suppose. I suppose one could just call (suspend) or explicitly terminate the thread (if falling off the end of spawn terminates the thread) in the REPL anyway. 16:59:51 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Quit: Leaving] 17:00:55 -!- alvatar [~alvatar@59.127.222.87.dynamic.jazztel.es] has quit [Quit: leaving] 17:02:36 homie [~user@xdsl-78-34-218-138.netcologne.de] has joined #scheme 17:03:09 One could have a dynamic-wind that wraps an untrusted thunk by catching conditions it signals, and returning (cons 'signal . condition); handling normal returns, and returning (cons 'ok . value); and in both cases setting a flag (initialised to false); then the exit thunk of the dynamic-wind checks the flag, and if it's not true (eg, an attempted escape into a different dynamic context), invokes a stowed continuation that makes us return 'attempte 17:03:09 d-to-escape instead 17:04:28 Would that be bulletproof? It'd catch attempts to jump OUT of a context, rather than attempts to jump BACK IN 17:05:01 ...which might be considered more important (I gave you this thread of control, and I'd like it back one day by calling this normal continuation I give you, or this error continuation I shove in the dynamic environment for you, please). 17:06:32 -!- jewel [~jewel@196-210-134-12.dynamic.isadsl.co.za] has quit [Ping timeout: 245 seconds] 17:06:57 -!- R3cur51v3 [~Recursive@97.77.55.38] has quit [Quit: This system is going down for poweroff RIGHT FREAKING NOW!!!] 17:08:19 However, this is making me suspect that, as SRFI-18 states, new threads should have an empty dynamic-wind stack... I'm not sure if this is fatally inconsistent with my desire for them to inherit parameter bindings from the parent :-) 17:10:38 -!- alexsuraci [~alexsurac@pool-71-188-133-67.aubnin.fios.verizon.net] has quit [Remote host closed the connection] 17:11:46 MichaelRaskin [~MichaelRa@195.91.224.225] has joined #scheme 17:12:26 Komi [Komi@83.231.94.66] has joined #scheme 17:12:30 hi 17:14:39 proq [~user@unaffiliated/proqesi] has joined #scheme 17:15:39 *alaricsp* leaves 17:18:19 mmc [~michal@109.116.132.122] has joined #scheme 17:21:02 R3cur51v3 [~Recursive@rrcs-97-77-55-38.sw.biz.rr.com] has joined #scheme 17:22:45 kephas [~pierre@AStrasbourg-551-1-17-210.w86-213.abo.wanadoo.fr] has joined #scheme 17:24:20 -!- nowhereman [~pierre@AStrasbourg-551-1-17-210.w86-213.abo.wanadoo.fr] has quit [Remote host closed the connection] 17:39:20 alvatar [~alvatar@59.127.222.87.dynamic.jazztel.es] has joined #scheme 17:39:57 gravicappa [~gravicapp@ppp85-140-117-52.pppoe.mtu-net.ru] has joined #scheme 17:41:08 -!- chittoor [~chittoor@listertech.in] has quit [Quit: Leaving] 17:47:51 -!- Jafet [~Jafet@unaffiliated/jafet] has quit [Quit: Leaving.] 17:53:04 kilimanjaro [~kilimanja@unaffiliated/kilimanjaro] has joined #scheme 17:54:10 -!- R3cur51v3 [~Recursive@rrcs-97-77-55-38.sw.biz.rr.com] has quit [Ping timeout: 276 seconds] 17:56:32 -!- nicktick [debian-tor@gateway/tor-sasl/nicktick] has quit [Ping timeout: 245 seconds] 17:57:55 alexsuraci [~alexsurac@pool-71-188-133-67.aubnin.fios.verizon.net] has joined #scheme 17:58:56 alaricsp, in SRFI 18, the thread returned by MAKE-THREAD inherits the dynamic context of its creator. 17:59:10 I posit that this is a Bad Idea. 17:59:39 Example: (cwcc (lambda (k) (dynamic-wind setup (lambda () ... (make-thread (lambda () ... (k) ...)) ...) teardown] 18:00:10 In this fragment, calling K triggers a call to TEARDOWN. 18:00:32 -!- Komi [Komi@83.231.94.66] has quit [Ping timeout: 265 seconds] 18:01:00 So does a normal return, in the original thread, from the body of the DYNAMIC-WIND. 18:01:21 foof, have I listed that as a criticism of SRFI 18? If not, let it be listed. 18:03:01 Jafet [~Jafet@unaffiliated/jafet] has joined #scheme 18:04:10 I think that it should not be possible for a DYNAMIC-WIND exit procedure to be applied more times than the corresponding entrance procedure, and, more specifically, for an exit procedure to be applied in a thread without having applied the entrance procedure in the same thread. 18:05:56 Justification: I can think of examples where this wreaks havoc upon a program to apply an exit procedure in a thread without having applied the entrance procedure in the same thread, but I have no examples of a legitimate use for this. 18:07:03 nicktick [debian-tor@gateway/tor-sasl/nicktick] has joined #scheme 18:09:07 -!- mmc [~michal@109.116.132.122] has quit [Ping timeout: 276 seconds] 18:09:54 -!- davazp [~user@83.55.180.105] has quit [Read error: Connection reset by peer] 18:13:39 MIT Scheme exhibits...interesting semantics there. 18:14:54 -!- Fabse [~mightyfid@wikipedia/Track-n-Field] has quit [] 18:15:06 -!- JoelMcCracken [~joelmccra@66.37.58.254] has quit [Quit: Leaving] 18:17:02 metasyntax` [~taylor@12.132.219.7] has joined #scheme 18:26:17 Well, MIT Scheme guarantees that entrance and exit procedures are called in pairs...just not necessarily in the same thread. 18:29:45 Komi [Komi@62.32.148.111] has joined #scheme 18:29:52 -!- nicktick [debian-tor@gateway/tor-sasl/nicktick] has quit [Ping timeout: 245 seconds] 18:33:38 wingo [~wingo@83.44.191.132] has joined #scheme 18:34:06 yo 18:35:05 G'day, wingo! 18:35:10 Hi. 18:36:03 wingo, what happens in Guile when you do this? ((cwcc (lambda (k) (d-w (lambda () (pp 'enter)) (lambda () (spawn (lambda () (k (lambda () (pp 0) (terminate-current-thread)))))) (lambda () (pp 'exit] 18:36:14 Sorry, I forgot to put (lambda () 'done) inside the body of the DYNAMIC-WIND. 18:36:22 -!- hhomar [~hhomar@92.26.74.102] has quit [Quit: WeeChat 0.3.2] 18:36:37 (Without that you'll get an error at the very end about trying to apply a thread as a procedure.) 18:39:01 -!- MrFahrenheit [~RageOfTho@users-55-120.vinet.ba] has quit [Ping timeout: 276 seconds] 18:41:24 what is spawn? 18:41:31 actually i don't understand the example 18:42:01 It spawns a thread. 18:42:41 wingo pasted "spawn quoi" at http://paste.lisp.org/display/112436 18:43:14 (You're supposed to replace those by the appropriate operations in Guile.) 18:43:33 ah :) 18:43:43 (But I don't know how to spell `spawn' or `terminate the current thread, please' in Guilese.) 18:45:50 quite a messy printout actually 18:46:18 That's because you translated it not quite right. 18:46:20 wingo annotated #112436 "guilese" at http://paste.lisp.org/display/112436#1 18:46:22 R3cur51v3 [~Recursive@rrcs-97-77-55-38.sw.biz.rr.com] has joined #scheme 18:46:34 *alaricsp* returns 18:46:35 Here's what the D-W during procedure should be: (lambda () (spawn (lambda () (k (lambda () (pp 0) (terminate-current-thread))))) (lambda () 'done)) 18:47:06 Riastradh: SRFI-18 says (under make-thread) "The thread's execution consists of a call to thunk with the "initial continuation". [...] The dynamic-wind stack of the initial continuation is empty." 18:47:47 in any case the error will be similar 18:47:52 That's interesting, alaricsp. 18:48:06 It *also* says: `The thread inherits the dynamic environment from the current thread.' 18:48:07 you can't invoke a continuation in a thread other than the capturing one 18:48:19 perhaps when we delimit call/cc that restriction will be lifted 18:48:33 wingo, I see. I suppose that's another way to solve the problem. 18:48:34 Yeah, it seems to differentiate the dynamic-wind stack from the "other" dynamic environment 18:49:45 Riastradh: it's a question of where is the computation delimited i think -- does it include the exit of the current thread or not 18:50:03 A differentiation which I have (on the one hand) a gut feeling is sensible for the reasons you suggest and (on the other hand) an instinctive fear of: why this subtle distinction? Why not generalise it and make "inherited" and "non-inherited" parameters or something? 18:50:04 in guile the continuation includes the control of the thread in which it was captured 18:50:05 wingo, well, sure. Otherwise, where does control proceed? 18:50:14 ASau``: "racquet": hilarious; that would be country-club-scheme as opposed to mafia-scheme. 18:50:16 It can't walk off the end of the sidewalk and keep going! 18:50:30 :) 18:50:54 like i say, it will be nice when we can set that limit at arbitrary points in your program... 18:51:01 -!- homie [~user@xdsl-78-34-218-138.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 18:51:30 wingo: I always felt (intuitively) that calling a continuation "from another thread" should be fine; but if that continuation ends up invoking the other thread's 'initial continuation' (that terminates the thread), it gets a little more interesting. I guess terminating the *calling* thread, not the *originating* thread, would make sense. But there may be other implications of inter-thread continuation calling that I've not yet discovered... 18:54:48 wingo, anyway, why do you need delimited continuations to lift the restriction? 18:55:55 -!- R3cur51v3 [~Recursive@rrcs-97-77-55-38.sw.biz.rr.com] has quit [Ping timeout: 276 seconds] 18:56:07 -!- askhader [~askhader@taurine.csclub.uwaterloo.ca] has quit [Ping timeout: 276 seconds] 18:56:35 Riastradh: perhaps i miscommunicated; i don't mean you need the shift/reset kind of continuations (partial continuations, or composable continuations) 18:56:56 i mean that you should be able to delimit the extent of a non-composable (call/cc) continuation 18:57:06 Why do you need to do that? 18:57:12 and that when that's done we'll get serialization and thread migration for free 18:57:35 That is, why have you imposed the restriction that a continuation created in one thread not be invoked in another thread? 18:57:45 hysterical raisins 18:57:48 What would happen if you lifted the restriction right now by omitting the relevant call to WITH-CONTINUATION-BARRIER? 18:58:07 you could not, because part of guile's current continuations includes the c stack 18:58:20 something to change for 2.2 i think 18:58:55 How do you switch threads, then? 18:59:22 SRFI-18's requirement that thread switches don't unwind/rewind mandates that there be a Magic Mechanism for swapping *those* continuations about 18:59:38 Yes, of course, alaricsp; every Scheme works that way. 18:59:44 Aye 19:00:10 neilv [~user@dsl092-071-029.bos1.dsl.speakeasy.net] has joined #scheme 19:01:16 what do you mean "switch threads" ? 19:01:30 guile uses pthreads if that is your question 19:01:35 Oh. 19:01:40 So Guile threads don't scale. 19:01:45 haha 19:01:49 perhaps not :) 19:01:59 or, they scale in certain ways? 19:02:15 I'm not sure what Chicken's take on inter-thread continuations is 19:02:17 delimited call/cc will allow for the termite-style scaling 19:02:37 Chicken threads work without native threads 19:02:45 Try my example program and find out, alaricsp. 19:02:51 Which means guile will be able to use more cores with one process 19:03:09 In Scheme48 the output will involve two enters and exits. 19:03:20 Riastradh: It is tempting. But, for now, I shall feed my daughter and put her to bed - tomorrow's a school day! 19:03:31 alaricsp, possibly so. There are interpreters out there, though, that can't, even though they use pthreads. Example: Python, Ruby. 19:03:44 Yeah, too much locking 19:03:45 Why? A global interpreter lock that prevents multiple concurrent instances of the interpreter! 19:03:50 I wish I were joking. 19:04:03 I know you're not :-) 19:04:10 Don't get me started on locks. Bane of my life, they are. 19:04:14 asarch [~asarch@187.132.134.6] has joined #scheme 19:04:25 *alaricsp* implements databases for a living 19:04:55 heh 19:12:40 homie [~user@xdsl-78-34-218-138.netcologne.de] has joined #scheme 19:16:13 -!- Jafet [~Jafet@unaffiliated/jafet] has quit [Ping timeout: 264 seconds] 19:19:24 somnium [~user@adsl-65-179-75.dab.bellsouth.net] has joined #scheme 19:27:34 -!- e-future [~e-future@unaffiliated/sergio/x-8197433] has quit [Quit: Lost terminal] 19:31:10 Riastradh: To be fair fixing the GIL in Python wouldn't be easy (even stackless python has a GIL) and to make things worse Guido doesn't give a damn about it and just says: "always use multiple processes, not threads" 19:33:50 How is that fair? It's fairly damning, that's true. 19:34:36 Why go to the trouble of dealing with threads at all if the interpreter can't be run simultaneously in more than one of them? 19:35:13 because it makes programming so much easier 19:35:24 Huh? 19:35:45 mild sarcasm implied 19:35:58 but I did just use threads to good effect in Python last week 19:36:09 chandler: yes i agree 19:36:26 Would your use of threads have been any different if they were green threads? 19:36:30 Did you run the interpreter usefully in different threads, or did you just send some other computation, written in C, to another thread? 19:37:10 Riastradh, perhaps it would be fair to say that Ruby and Python have decided to be domain-specific languages, and that they have simply [perhaps accidentally] restricted the domain in which they are of any use? That doesn't pertain much to the Scheme situation, however. 19:37:19 Riastradh  the former, I started N computations in parallel and let the first one to finish win 19:37:55 But with the global interpreter lock, inimino, that's no different from starting N computations in green threads. 19:38:05 gnomon: That's a good one. Python isn't a poorly designed language per se. It's just well designed for the domain of, uh, riding the short bus! 19:38:15 yes, it would have been no different with green threads 19:38:39 chandler, exactly! The best way to win is by moving the goalposts - in this case, right into the parking lot. 19:38:40 (Note: that particular slur may not translate to Canadese.) 19:38:52 and if it mattered, running separate processes would have been the solution 19:38:53 Please. We prefer "Canuckistani". 19:40:15 My objection is simply to the use of pthreads, whose *only* utility is that they enable portable parallelization, in situations where parallelism is explicitly ruled out anyway. 19:40:20 inimino: The point is that not only was Guido too willfully ignorant to implement Python in a fashion that it could make use of native threads, he *also* couldn't figure out that green threads would be much more scalable and faster in nearly every situation. 19:40:57 There are plenty of Scheme systems that don't support parallelism, but their threads are more robust and more scalable than pthreads. 19:41:15 What's a green thread? 19:41:16 chandler  no argument there 19:41:34 Komi, a thread scheduled in userland. 19:41:51 however, Python does now have a multiprocess module which supports the same thread-style API but runs separate interpreter threads 19:41:58 Most Scheme systems use userland threads rather than kernel threads through pthreads. 19:42:11 inimino, what is with your use of that odd ellipsis? It's an unusual habit. 19:42:11 The only situation where Python's use of native threads helps now is if two interpreter threads call out to C functions - and that's assuming the C functions are happy with being called from different threads in the first place. In that situation, one could *easily* spawn a separate thread in a foreign call to handle parallelizing those calls, provided the interpreter has its act together with respect to signals. 19:42:12 Riastradh: by the OS or something similar to coroutines? 19:42:15 so I could have used that (if I'd wanted to depend on Python 2.6 or whatever it was) 19:42:33 inimino, oh, have they lifted the global interpreter lock now? 19:42:40 gnomon  it's something that started in another channel, long story... 19:42:47 Riastradh  no 19:42:49 (Is that what those boxes are? Ellipsis?) 19:43:23 Riastradh, http://www.fileformat.info/info/unicode/char/22f1/index.htm 19:43:29 My irssi or screen seems to be permanently broken with respect to Unicode, so all I see are question marks. 19:43:36 Riastradh  but there's a module that starts new instances of the Python interpreter, but supports the same API as the threading module 19:44:05 Remarkably, chandler, good chunks of Unicode work here under irssi and screen and rxvt-unicode. 19:44:26 Here they show up as diagonal ellipsis. Crazy. 19:44:30 I had to tell screen to set LC_ALL appropriately, though. 19:44:31 It worked the first time I started it. Some later attach/detach process broke it. 19:44:39 *alaricsp* returns briefly, as dinner is in the oven 19:44:49 they are indeed diagonal ellipses :) 19:45:05 Yes, threads with a GIL don't help you to get performance, but they can be useful for expressing concurrent problem domains 19:45:07 inimino, I'm confused: does that mean that you can or can't run the interpreter multiple times in parallel? 19:45:18 Riastradh  you can 19:45:27 Eg, handling multiple TCP connections in a server; it's often just easier to write a procedure that handles one and thread it. 19:45:34 So they *have* lifted the global interpreter lock. 19:45:39 you just have to start separate processes to do it 19:45:45 Riastradh: You can't. This actually creates separate *processes*. 19:45:47 Oh. So you don't have shared memory. 19:45:48 the GIL is per-process, not per-machine 19:45:59 It's akin to fork with a few builtins for IPC. 19:46:02 alaricsp, you don't need kernel threads for that, and it is generally a mistake to use kernel threads for that. 19:46:11 In short, Python uses pthreads where green threads should be used, and processes where threads should be used. 19:46:12 Riastradh: Agreed 19:46:32 BUT, IMHO threads are a low-level tool; too low-level for many developers. They're better without shared memory anyway, as there's less mistakes to be made if IPC has to be explicit 19:46:37 I suppose that where multiple processes ought to be used, they'd tell you to use a hypervisor and start multiple OS instances. 19:46:50 shared-memory threads are a sharp tool... great in the right hands. 19:47:32 chandler, Python also uses backwards, twisted programming where green threads ought to be used. 19:47:51 However, that doesn't mean you need to start processes up; Erlang does just fine without mutable shared state in a single process 19:48:01 Ah yes, the Twisted Python libraries. 19:48:08 Erlang has mutable shared state, alaricsp. 19:48:10 I thought they used that where call/cc ought to be used. 19:48:21 Erlang processes themselves are mutable shared state. 19:48:27 I've never actually used those myself, but I gather it's all event-driven with registered callbacks for various events 19:48:56 Riastradh: Shared in what sense? 19:49:11 Riastradh: Where, out of interest? I've only read up on the language, never used it. The Erlang book I read, at least, taught wrapping all mutable state in servers... 19:49:15 Shared in the sense that the state of a process is shared with all other processes communicating with it, chandler. 19:50:09 ... In what sense? I'm still not getting it. 19:50:44 Ok, right. I'm talking about multiple processes being able to directly mutate the same state slots in memory. Yeah, the state is shared in that any process can send that process messages to make it reply with state-dependent information, and you can ask the runtime for process information and get some read access to state that way, but that's a "side channel" for debuggery AIUI 19:51:15 The liveness of a process is shared with the other processes communicating with it, but that can only be altered by the process itself if I remember correctly. 19:51:33 But, I mean, you don't (unless you go peeking under the covers in discouraged ways, at least) get to race over concurrent access to a mutable variable ;-) 19:51:44 chandler: I think you can send a process a kill signal... but it's entitled to catch it. IIRC. 19:51:46 ecloud [~rutledge@ip72-208-148-56.ph.ph.cox.net] has joined #scheme 19:51:47 Er, there's actually a kill message, I'm wrong. 19:51:53 anyone going to the sfp this year? 19:51:55 make_cell (X) -> spawn (loop, [X]). loop (X) -> receive {fetch, P} -> P ! X, loop (X); {store, Y} -> loop (Y) end. fetch (Cell) -> Cell ! {fetch, self()}, receive X -> X end. store (Cell, X) -> Cell ! {store, X}. 19:51:59 No, kill can't be caught. 19:52:05 There's a mutable cell for you. 19:52:23 You can send 'EXIT' to a process, and the process can catch it, but if it doesn't, then it propagates to all processes with which the first is linked. 19:52:34 Riastradh: Yes, but you've gone to the effort to build that (and one can build any bad thing one likes in a Turing-complete language) 19:52:47 The "mutation" is confined to the cell process. I dispute that this is anything like mutable shared state. 19:53:03 It's not like it gives you mutable cells and threads and says "Go write yourself a mutex if you want, there's algorithms in the literature" ;-) 19:53:32 The Erlang messaging primitives, in the hands of Average Developers, are reasonably likely to lead to a working system 19:53:46 Erlang just changes the level at which processes share state. 19:53:46 This is a property pthreads does not share, IMHO ;-) 19:53:52 Yes, quite 19:53:59 And that's a significant thing 19:54:11 It's quite different from a truly low-level threading API. I don't need to worry about arcane details like memory barriers at all. 19:54:53 It's also quite different than native threads in most high-level programming languages. If I have a value, I know that value isn't going to change underneath me. How a process responds to a given message might, but that's a completely different ball of wax. 19:54:57 Sure you do, chandler. Suppose the cell is stored on a remote host. 19:55:42 Now it behaves like mutable memory shared between multiple CPUs: writes can be delayed, batched, and so on. 19:56:10 The value of the pid won't change underneath me. Once I fetch a value, it won't change underneath me. 19:56:18 That happens even if it's local; there's a per-process input message queue, and the mutable cell manager process may not be scheduled for a while 19:57:03 Yes, you can build a shared memory in Erlang, with all that entails; but you have to actually try to; it's not like that by default 19:57:18 Sure, chandler, but the same is generally true in most Scheme programs. In (let ((x (car p))) ...), if you don't SET! X, then X won't change. But a subsequent call to CAR might yield a different value, just like a subsequent call to fetch(Cell) might yield a different value in Erlang. 19:57:20 Likewise, you can build an Erlang-style message-passing system in C+pthreads 19:57:35 If I design my program badly, I can easily wind up with nondeterministic bugs associated with message delays and processing order. But that doesn't diminish the set of invariants that the Erlang model provdes that aren't provided by, say, native threads in Common Lisp. 19:57:38 Riastradh: Yes: but that's manageable complexity 19:58:40 It's somewhat easier in Lisps to write threads that don't share state in unexpected ways, as there's more of a culture of not mutation global state than in the C or Java worlds, for example - but you still have to be careful, for sure 19:59:21 *inimino* waits for someone to bring up Haskell 19:59:51 Riastradh: That's still missing the guarantee. I can properly encapsulate several individual pieces of state into a single Erlang process, and while I am "changing" the state I know that this instance of the process is the only one that has access to that state. Threads in Scheme don't traditionally provide that guarantee. I have to use locks. 19:59:58 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Quit: +++ killed by SIGSEGV +++] 20:00:03 or Clojure for that matter 20:00:40 Sure. My general point is just that ignoring how to deal with shared memory is not a good plan, because even if you throw shared memory operations out of your primitive operations, the structures still arise. Example: two processes sharing a resource on a file system. 20:00:57 Yes 20:01:03 Some problem domains are, inherently, about shared state 20:01:48 *inimino* .oO(wasn't there some database guy around here?) 20:02:06 inimino: That would be me... 20:02:14 aha :) 20:02:21 'tho you can have purely functional databases ;-) 20:02:42 That's not an argument that the Erlang model doesn't provide useful guarantees. I could easily make the same argument about memory management, and it would reveal just as much (or little). 20:02:42 and the world would be a better place, surely 20:03:11 inimino: In some respects. But, often, the problem domain calls for shared mutable state, and then it's gotta turn up somehow... 20:03:32 *alaricsp* points at the average "social networking web site" as a big ball of shared mutable state 20:03:40 Ewwww. 20:03:55 And, for me, "social networking web site" = "potential customer for my replicated database technology" ;-) 20:04:34 in theory it could be done without mutable state, it would just be impractical for performance reasons 20:05:01 However, under the covers, the transaction system we're working on will *secretly* be copy-on-writing immutable tree structures, with only a root pointer being traditional shared-mutable-state! And they'll never know! Hee hee hee! 20:05:22 chandler, sure. Originally I was replying to alaricsp's claim that shared memory threads are a sharp tool but that Erlang does just fine without mutable shared state, as if using Erlang absolved one of having to deal with synchronizing shared resources. 20:05:29 alaricsp  what language are you using? 20:05:49 -!- Blkt [~user@dynamic-adsl-78-13-252-73.clienti.tiscali.it] has quit [Ping timeout: 240 seconds] 20:06:15 Riastradh  but message-passing as a technique *does* absolve one of such issues, when it can be used to solve the same problem where shared memory would have been used... 20:06:21 Riastradh: Yeah, I didn't mean you *can't* cut yourself in Erlang, just that you have to do some work to remove the safety guards to do so - rather than every developer being handed a nice bare razor and wished good luck. 20:06:35 Riastradh: I didn't get that impression. 20:06:40 bozhidar [~user@93-152-185-88.ddns.onlinedirect.bg] has joined #scheme 20:06:52 inimino: C, sadly, but I have a plan to sneak chibi scheme in there when I get a few days spare. We need a stored-procedure language... 20:06:54 Riastradh  and Erlang makes the safer model easy, and if you want to cut yourself on a sharp edge, you have to sharpen it yourself 20:06:55 alaricsp: that sounds like every clojure program (except for the "they'll never know" part):P 20:06:55 Erlang does without mutable shared state in the same sense that Scheme does without manual memory management. 20:07:06 In any case, you can write your threads with purely functional data structures if you like, in Scheme. 20:07:17 I wouldn't read either of those statements as saying that the entire class of problems vanishes in that language. 20:07:37 alaricsp  ah, I guess there's still no getting away from C for lots of low-level tasks; I actually really enjoy C on its own merits 20:07:54 You certainly can! It would be nice to know that other parts of the system - including the implementation and other libraries - played by those rules, too. 20:08:08 I brought this up to draw a contrast between Scheme and Python, in that in Scheme one can write programs that use scalable threads in a direct style, whereas in Python if one wants to write programs with scalable threads they must be written in CPS. 20:08:17 A purely functional Scheme with Erlang-style processes would be a very, very nice thing. 20:09:03 How about replacing lists by bounded-balance binary trees, while we're at it? 20:09:40 I can't tell if you're being sarcastic or not. 20:09:44 ooh, finger-trees instead of pairs would be awesome 20:10:25 the hard part would be finding a haskell programmer willing to implement it 20:10:54 I tried to figure out finger trees and got lost when the paper got to recursive type class instantiation or something. 20:12:05 chandler, I'm actually somewhat serious about it. It would be neat if the basic data structure supported logarithmic-time indexing and fast sorted associations. 20:12:32 -!- neilv [~user@dsl092-071-029.bos1.dsl.speakeasy.net] has quit [Quit: Leaving] 20:13:54 the paper made more sense after I read some other articles by people trying to make sense of it, but I still dont have the faintest idea how to try to implement them :( 20:14:30 Having a basic data structure that is extremely difficult to understand sounds like a losing proposition to me. 20:15:14 OT, can anyone recommend a place to find a (more or less) canonical implementation of the pattern matching algorithm in syntax-case/syntax-rules? 20:15:32 The GHC libraries also include bounded-balance binary trees -- in fact, at least two nearly identical implementations, for Data.Set and Data.Map, except that one of them (Data.Map, I think) is buggy. 20:16:02 (The difference? Data.Set has a 4 somewhere, and Data.Map has a 5.) 20:16:54 somnium: I'm not sure there's a canonical implementation. The pattern matching part of it is fairly simple. 20:17:03 Also, that's hardly OT. 20:17:35 somnium, I stole this from Scheme48; it's fairly straightforward: 20:17:47 chandler: I just wrote one, and I was feeling all happy that it was just around 200 lines (pattern + template), then realized I had no idea how they were usually implemented 20:17:47 You could look at an implementation of `syntax-rules' ala Riastradh's, but I'd suggest writing it in a straightforward backtracking style, either with `call/cc' or via CPS. 20:17:55 Riastradh: great! thanks 20:18:17 Riastradh, there was that paper that you discussed a while back about adding those properties to basic lists while maintaining O(1) append times, wasn't there? 20:18:24 I'll have to dig through my notes. 20:18:30 Mine? I have never implemented SYNTAX-RULES (to my knowledge, at least!). 20:19:07 Riastradh, I meant your earlier comment to chandler about a basic data structure with logarithmic-time indexing and fast sorted associations. 20:19:19 When I wrote that, I didn't realize that you stole the SYNTAX-RULES implementation in Riaxpander from Scheme48. 20:19:23 gnomon, dunno. You might be thinking of David van Horn's recent SRFI, or you may be thinking of Stephen Adams' paper (on which all the bounded-balance binary trees in functional languages are based -- although the math in it is a little buggy), of which is an implementation. 20:20:07 chandler, actually, no, I had my name legally changed to `Richard Kelsey and Jonathan Rees', and then found a time machine to retroactively write the code and copyright it under my (new) name. 20:21:00 Heh. Honestly, I never noticed the copyright on that file, and only skimmed it once anyway. 20:21:27 hotblack23 [~jh@p4FC595ED.dip.t-dialin.net] has joined #scheme 20:22:17 The important part of bb-tree.scm is page 5, which provides several ways to put two bb-trees together, depending on how well they are balanced. The most general of them, JOIN and CONCATENATE, run in logarithmic time. 20:23:11 These operations are purely structural, too, so they would apply just as well to indexed sequences as they apply to key-ordered collections. 20:23:12 Fare [~Fare@ita4fw1.itasoftware.com] has joined #scheme 20:25:42 chandler: I did it with a parser monad, which is cps only cheating I guess 20:26:04 This doesn't give you CONS or SNOC in O(1) time, not even amortized time, as finger trees apparently do, but I claim that the definitions of INSERT-MINIMUM and INSERT-MAXIMUM are tremendously more obvious than those of the corresponding operations on finger trees. 20:26:20 (and DELETE-MINIMUM and DELETE-MAXIMUM) 20:26:30 somnium: That works too. 20:26:40 Whatever control-flow abstraction floats your boat... 20:27:18 I don't know, Riastradh, bb-trees.scm makes reference to two papers and I haven't read either one (in fact, I can't even find a copy of the first one that isn't behind an ACM paywall). 20:27:47 I think I have a copy, gnomon, and I think it is not obnoxiously copyrighted, but you want to read the second one anyway, not the first one. 20:28:24 -!- alvatar [~alvatar@59.127.222.87.dynamic.jazztel.es] has quit [Quit: leaving] 20:29:04 Riastradh, I'm pretty sure that the paper I have in mind is about a relatively simple structure which gives O(log n) APPEND behaviour while leaving the other list properties unchanged. 20:33:24 In SRFI 101, I think CONS and CAR run in constant time, while CDR and APPEND run in logarithmic time. 20:34:38 No, CDR runs in constant time too. 20:34:51 LENGTH and APPEND run in logarithmic tim.e 20:34:53 Ah, that looks mightily familiar. 20:35:55 vlists are interesting too 20:36:04 Aha! It was Okasaki's 1995 paper that I remember reading! Thanks very much, Riastradh. 20:36:18 Vlists require hairy garbage collector hacks. 20:36:46 what are Vlists? 20:36:46 well, they don't require them; but they do to get a space advantage over pairs. 20:37:03 They do require GC hacks in order to make CDR run in constant time. 20:37:08 (for my logs: the Okasaki paper about purely functional random access lists (which let some traditionally linear list accessors run in constant or logarithmic time) is at http://www.eecs.usma.edu/webs/people/okasaki/fpca95.ps ) 20:37:16 http://en.wikipedia.org/wiki/VList 20:38:01 -!- alexsuraci [~alexsurac@pool-71-188-133-67.aubnin.fios.verizon.net] has quit [Remote host closed the connection] 20:38:13 Riastradh: guile's vlists appear to have a constant-time vlist-tail... 20:38:54 In that case we must be talking about two different data structures, or your vlists have space leaks. 20:39:55 you can poke module/ice-9/vlist.scm in your neighborhood guile checkout to find out :P 20:41:44 I had this lying around my home directory: 20:42:49 Can you give me a URI for Guile's vlist.scm? 20:43:14 they do indeed keep around stale refs, as you note. 20:43:27 git://git.sv.gnu.org/guile.git 20:43:30 OK, so your vlists have space leaks. 20:43:35 yep! 20:43:41 kar8nga [~kar8nga@i-104.vc-graz.ac.at] has joined #scheme 20:44:25 Personally, I don't like to tolerate space leaks. They are extremely hard to detect and debug. 20:44:40 (That is why I don't go near conservative garbage collectors.) 20:45:28 i don't like genies or ghosts either. they are untrustworthy, i hear. 20:48:07 Can call/cc be implemented in terms of shift/reset, and shift/reset in terms of call/cc? 20:48:28 alexsuraci [~alexsurac@pool-71-188-133-67.aubnin.fios.verizon.net] has joined #scheme 20:48:32 ...,,, 20:49:01 ...sorry, my keyboard flipped out there. 20:49:01 Komi: no. 20:49:05 Komi, approximately, yes. 20:49:08 hah! 20:49:26 Riastradh is probably right, but i seem to recall no being my conclusion 20:49:27 Shift & reset can certainly be implemented in terms of CWCC, and if you wrap your whole program in a reset, then CWCC can be implemented in terms of shift and reset. 20:50:06 are you sure? even regarding dynamic-wind? 20:50:17 Oh, DYNAMIC-WIND will behave oddly no matter how shift and reset are involved. 20:50:25 tsk tsk 20:50:45 dynamic-wind is the reason you can't implement call/cc with composable continuations. 20:51:08 i'm thinking about the notion of wrapping the whole program in a reset 20:51:33 what if the whole program isn't avaiable? (as in a repl) 20:51:33 Komi: as long as your're prepared for capturing a continuation to unwind all the way to the reset, sure 20:51:34 (define (cwcc p) ((shift k (k (lambda () (p (lambda v (shift k* (k (lambda () v] 20:51:59 That gives you the primitive control operators; define the real ones together with DYNAMIC-WIND. 20:52:59 -!- asarch [~asarch@187.132.134.6] has quit [Remote host closed the connection] 20:53:14 interesting, why was it decided to use call/cc instead of shift/reset in the RNRS standards? 20:53:15 Komi: (loop (print (reset (eval (read))))) 20:53:28 i mean, why did they chose one and not the other? 20:53:30 CWCC is more traditional and more generally understood. 20:53:48 Its interaction with dynamic context is clearer. 20:54:07 Until about two or three years ago nobody had ever really implemented composable continuations in a practical system. 20:54:28 MrFahrenheit [~RageOfTho@users-33-26.vinet.ba] has joined #scheme 20:54:47 The choice of operations to use was not clear. (Are shift and reset the primitives? Control and prompt? Cupto and whatever? Splitter and frobblethorpe?) 20:55:22 -!- NNshag [user@lns-bzn-57-82-249-16-182.adsl.proxad.net] has quit [Ping timeout: 248 seconds] 20:55:34 Then in about 2006, Ken Shan and Oleg Kiselyov showed how to express them all in terms of shift and reset and give meta-CPS semantics for them, which made the theoreticians happy, and a year or two later more primitive operators were implemented in PLT Scheme, which made the implementors happy. 20:56:13 is there a paper on that? 20:56:27 In PLT Scheme: (define (cwcc p) (call-with-composable-continuation (lambda (k) (p (lambda (v) (abort-current-continuation (default-continuation-prompt-tag) (lambda () (k v] 20:56:38 Komi: http://wingolog.org/archives/2010/02/26/guile-and-delimited-continuations was my "journey" 20:56:58 Riastradh, wingo: thanks a lot 20:57:05 Yes, Komi, there are papers both by Shan & Kiselyov and on PLT Scheme by the PLT Scheme folks. 20:57:30 i like dybvig & peyton-jones' "monadicdc" paper too 20:57:48 the dybvig part of it, at least 20:57:58 a good survey of the design space 20:58:14 i like reading the papers, it's interesting research 20:58:37 although i can't understand anything about denotational semantics and such when presented 20:58:40 chandler and I once discussed writing a SRFI for composable continuations a few years ago. I don't know whether I still have the document around. 20:58:51 Komi, just pretend it's written in Scheme with funny syntax. 20:59:22 -!- copec [~copecd@64.244.102.130] has quit [Ping timeout: 265 seconds] 21:00:03 to be honest, i mostly skim the text and try to understand the whole concept then work the way slowly through the examples provided 21:00:46 jmcphers [~jmcphers@218.185.108.156] has joined #scheme 21:00:49 going to read a bit, thanks for the help :) 21:02:44 asarch [~asarch@187.132.134.6] has joined #scheme 21:04:03 copec [~copecd@64.244.102.130] has joined #scheme 21:04:54 so, anyone going to sfp? 21:04:55 wingo, does Guile have any nice way to multiplex I/O events and interthread communication? If not, an enterprising Guile hacker could port to Guile pretty easily... 21:05:52 -!- kar8nga [~kar8nga@i-104.vc-graz.ac.at] has quit [Remote host closed the connection] 21:06:04 Riastradh: not out of the box, no. i'll mail the list, thanks! 21:06:21 where is sfp? 21:06:50 wingo, for a port, one should probably start by looking at srfi-18-suspend.scm. 21:06:54 montreal 21:07:22 ...oh, right, Guile already supports SRFI 18, so that shouldn't be necessary at all. 21:07:46 right, in theory 21:07:53 NNshag [user@lns-bzn-27-82-248-27-130.adsl.proxad.net] has joined #scheme 21:07:54 always good to test though :) 21:11:25 mmc [~michal@109.117.179.106] has joined #scheme 21:23:05 ada2358 [~ada2358@login.ccs.neu.edu] has joined #scheme 21:26:16 Gumug [~Gumug@64.134.168.246] has joined #scheme 21:27:43 MononcQc [~Ferd@modemcable062.225-20-96.mc.videotron.ca] has joined #scheme 21:29:02 schmir [~schmir@p54A90137.dip0.t-ipconnect.de] has joined #scheme 21:29:31 is it common for people that are first learning to program to become discouraged that they can't figure something out, like for example, an exercise in HtDP? 21:30:51 Yes. 21:32:47 i feel like a monkey trying to figure out a math problem 21:32:55 What's the problem you're trying to solve? 21:33:43 well, i know how to do it now... it was the, obviously easy to understand now, task for determining profit margin for theatre owner 21:34:33 Gumug: you're early in HtDP ? 21:34:46 i almost feel like, if i can't figure out how to solve an exercise in chapter 3, why continue on lol 21:35:01 Fare: chap 3 21:35:47 i learn best visually so i thought, well maybe i could download the SICP videos and they could help me along... i understand SICP is more advanced though 21:37:10 cpr420 [~cpr@unaffiliated/cpr420] has joined #scheme 21:37:21 profit = money input - money output. 21:37:38 unless you're hollywood 21:38:30 ? 21:38:55 http://entertainment.slashdot.org/story/10/07/09/1621218/Hollywood-Accounting-mdash-How-Harry-Potter-Loses-Money?from=rss 21:38:56 -rudybot:#scheme- http://tinyurl.com/2do7mbd 21:39:18 -!- mmc [~michal@109.117.179.106] has quit [Ping timeout: 240 seconds] 21:46:01 -!- ecloud [~rutledge@ip72-208-148-56.ph.ph.cox.net] has quit [Quit: ecloud] 21:50:57 *wingo* wonders if sfp is falling out of favor as a conference 21:51:13 Why do you wonder that? 21:52:17 -!- paint [~paint@unaffiliated/paint] has quit [Quit: IRC is just a multiplayer Notepad] 21:53:06 because i haven't seen good papers from there recently, i don't hear much buzz about it... 21:53:10 dunno 21:53:45 also, three years in a row in north america is too many ;) 21:53:48 I've never heard much buzz about it, but perhaps the reason for your first observation is that you are becoming more experienced and consequently less easily impressed... 21:55:39 dunno, my ignorance is still very broad, and especially regarding the conference scene -- a more likely explanation than experience, in my case :P 21:56:09 Sorry, that probably came across as rather condescending. I rather meant to refer to the impression I got of Guile's having been broadening its tastes under your direction to incorporate more ideas from other Lisp systems. 21:57:53 -!- copec [~copecd@64.244.102.130] has quit [] 22:00:21 -!- samth is now known as samth_away 22:00:44 paint [~paint@unaffiliated/paint] has joined #scheme 22:01:03 mmc [~michal@109.116.179.199] has joined #scheme 22:04:57 -!- Fare [~Fare@ita4fw1.itasoftware.com] has quit [Quit: Leaving] 22:06:09 -!- dzhus [~sphinx@89-178-249-129.broadband.corbina.ru] has quit [Ping timeout: 246 seconds] 22:08:18 malcolmci [~malcolmci@203.171.96.17.static.rev.aanet.com.au] has joined #scheme 22:17:37 didn't sound condescending to me -- my ignorance is indeed broad, and it is interesting to learn more about its boundaries :) 22:17:40 *wingo* -> z 22:17:42 night! 22:31:13 -!- wingo [~wingo@83.44.191.132] has quit [Ping timeout: 265 seconds] 22:32:12 just a thought... 22:33:12 given that call/cc can restore a point in the computation i suposse it may be possible to use it to have resumable restarts like the condition system of CL in Scheme 22:33:14 -!- schmir [~schmir@p54A90137.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 22:33:57 however, if the CL standard requires implementations to have the machinery needed to implement restarts it's strange no CL system has an analog of call/cc which seems could fit this purpose among others 22:38:55 TR2N [email@89.180.153.197] has joined #scheme 22:38:56 -!- stis [~stis@1-1-1-39a.veo.vs.bostream.se] has quit [Read error: Connection reset by peer] 22:39:40 -!- Gumug [~Gumug@64.134.168.246] has quit [Quit: Gumug] 22:41:21 -!- cpr420 [~cpr@unaffiliated/cpr420] has quit [Ping timeout: 265 seconds] 22:41:52 -!- hotblack23 [~jh@p4FC595ED.dip.t-dialin.net] has quit [Quit: Leaving.] 22:43:17 Restarts have only dynamic extent, not unlimited extent; they cannot be used for re-entry. 22:43:38 And yes, you can implement restarts in Scheme using CWCC. See, for example, MIT Scheme (runtime/error.scm). 22:43:41 *Riastradh* vanishes. 22:46:24 davazp [~user@83.55.180.105] has joined #scheme 22:52:54 -!- fradgers- [~fradgers-@5adb10a1.bb.sky.com] has left #scheme 22:55:48 -!- pdelgallego [~pdelgalle@1503031474.dhcp.dbnet.dk] has quit [Ping timeout: 240 seconds] 22:57:50 schmir [~schmir@p54A90137.dip0.t-ipconnect.de] has joined #scheme 22:58:09 -!- schmir [~schmir@p54A90137.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 23:00:07 -!- malcolmci [~malcolmci@203.171.96.17.static.rev.aanet.com.au] has quit [Remote host closed the connection] 23:06:55 mathk [~mathk@dispo-82-65-193-21.adsl.proxad.net] has joined #scheme 23:14:49 -!- MrFahrenheit [~RageOfTho@users-33-26.vinet.ba] has quit [Quit: Leaving] 23:15:42 marvel_ [~marvel@unaffiliated/marvel] has joined #scheme 23:16:53 -!- mmc [~michal@109.116.179.199] has quit [Ping timeout: 240 seconds] 23:20:00 -!- marvel_ is now known as marvel 23:34:35 TR2N` [email@89.180.153.197] has joined #scheme 23:35:48 -!- TR2N [email@89.180.153.197] has quit [Ping timeout: 240 seconds] 23:37:32 -!- TR2N` is now known as TR2N 23:37:51 -!- Riastradh [~riastradh@fsf/member/riastradh] has quit [Ping timeout: 246 seconds] 23:38:09 MrFahrenheit [~RageOfTho@users-55-247.vinet.ba] has joined #scheme 23:38:10 mmc [~michal@109.112.3.95] has joined #scheme 23:41:28 -!- IJP_ [~Ian@host86-135-143-76.range86-135.btcentralplus.com] has quit [Quit: leaving] 23:41:54 R3cur51v3 [~Recursive@rrcs-97-77-55-50.sw.biz.rr.com] has joined #scheme 23:48:29 Cheery [~cheery@a88-113-49-213.elisa-laajakaista.fi] has joined #scheme 23:48:30 RageOfThou [~RageOfTho@users-55-224.vinet.ba] has joined #scheme 23:48:51 Is it a common approach to make a compiler an interpreter? 23:49:09 or rather.. make a compiler out of an interpreter. 23:50:03 -!- R3cur51v3 [~Recursive@rrcs-97-77-55-50.sw.biz.rr.com] has quit [Ping timeout: 258 seconds] 23:50:50 I'm having trouble making sense out of that question. 23:51:36 Is it a common approach to make sense out of a questions? 23:51:50 -!- MrFahrenheit [~RageOfTho@users-55-247.vinet.ba] has quit [Ping timeout: 246 seconds] 23:52:15 no, mockery is more common. 23:52:52 Cheery: is Java a compiler or an interpreter? 23:53:33 foof: no, java is a programming language. 23:54:20 maybe I should smash my forehead to the table from not figuring it out before. 23:54:58 but indeed.. what else would a compiler be than an interpreter? 23:55:21 it interprets the input program.. to bytecode. 23:56:03 if you put correct things into your scope, you can rename 'interpret' to 'compile' 23:58:44 but then.. maybe I should ask a question since I joined this channel to ask one. :/ 23:59:52 -!- mathk [~mathk@dispo-82-65-193-21.adsl.proxad.net] has quit [Quit: ..zzZzzZ] 23:59:59 aside some obvious things that can be found with google, do you know about documentation related to the stuff that is used to make V8 execute javascript so fast?