00:04:20 raikov [n=igr@60.32.127.43] has joined #scheme 00:06:52 dean [n=aoeu@75.16.124.182] has joined #scheme 00:09:55 dean pasted "SICP Exercise 2.58 b" at http://paste.lisp.org/display/82261 00:10:25 is 00:10:47 or 00:13:57 -!- johnnowak [n=johnnowa@207-38-171-48.c3-0.wsd-ubr1.qens-wsd.ny.cable.rcn.com] has left #scheme 00:15:45 -!- raikov [n=igr@60.32.127.43] has quit [Read error: 60 (Operation timed out)] 00:18:13 -!- dean [n=aoeu@75.16.124.182] has quit [Remote closed the connection] 00:18:58 -!- soupdragon [n=f@amcant.demon.co.uk] has quit ["Leaving"] 00:25:55 -!- kniu [n=kniu@pool-71-107-56-85.lsanca.dsl-w.verizon.net] has quit [Read error: 60 (Operation timed out)] 00:27:02 so, GNU diff isn't a very god display for comparision 00:27:09 good* 00:27:28 Is there any standard tools for a programmer friendly diff display 00:27:34 without getting into GUI tools? 00:27:35 -!- blackened` [n=blackene@ip-89-102-28-224.karneval.cz] has quit [] 00:28:30 Not following you, Arelius... to my mind, GUI is bitchin for synchronized side by side diffs. 00:28:37 is it? 00:28:46 then I must be missing something 00:28:48 It is. because I say so. No, really. 00:28:51 ohh wait 00:28:54 you sai GUI 00:29:00 Yeah, GUI is nice 00:29:14 but sometimes I want to be able to do a proper diff over ssh or some such 00:29:18 If you don't want to use a GUI (and that included Emacs diff modes), then I don't know what you are going to get. 00:29:24 Arelius: emacs has a fancy "ediff" mode which is arguably not a GUI 00:29:27 The other options for 80-char wide terminals are not very good. 00:29:41 kilimanjaro [n=kilimanj@70.116.95.163] has joined #scheme 00:29:59 do you know if you can use ediff with git diff by chance? 00:30:23 Arelius: Does git's diff print the export in a standard format? 00:30:32 Unified diffs seem to work the best, IME. 00:30:46 -!- Dark-Star [n=michael@p57B562E3.dip.t-dialin.net] has quit [Read error: 104 (Connection reset by peer)] 00:30:47 Usually SCM programs have a way of generating Unified diffs. 00:31:07 peter_12 [n=peter_12@S010600119506b129.gv.shawcable.net] has joined #scheme 00:31:11 so ediff takes unified diffs? 00:31:58 -!- joast [n=rick@76.178.184.231] has quit [Read error: 110 (Connection timed out)] 00:32:02 IIRC. 00:33:33 thanks 00:33:58 joast [n=rick@76.178.184.231] has joined #scheme 00:35:05 Arelius: ediff doesn't "take" diffs; it compares files and displays the differences. 00:35:11 -!- athos [n=philipp@92.250.250.68] has quit [Remote closed the connection] 00:35:26 *arcfide* must be thinking of the normal diff modes in Emacs. 00:36:11 ediff != diff-mode 00:40:58 kniu [n=kniu@pool-71-107-56-85.lsanca.dsl-w.verizon.net] has joined #scheme 00:43:22 what's diff-mode 00:48:19 -!- MichaelRaskin [n=MichaelR@195.91.224.225] has left #scheme 00:49:29 MichaelRaskin [n=MichaelR@195.91.224.225] has joined #scheme 00:51:50 -!- foof [n=user@dn157-046.naist.jp] has quit ["ERC Version 5.2 (IRC client for Emacs)"] 00:54:53 Archeron, A special emacs mode for a buffer that contains a context diff 00:55:26 derrida [n=mgs@unaffiliated/deleuze] has joined #scheme 00:58:01 I know this might sound a bit silly, but, it's Father's Day- for years now my father has wanted to understand recursion. Conceptually, we can get through the idea of a binary sort but everytime things start degenerating into a mixed up conversation ending worse than they started. :) Can anyone think of a good analogy I could use to try and make things very clear for him? Everything I come up with is too far disconnected from reality i think. :) 00:58:36 -!- sreeram [n=sreeram@122.174.65.3] has quit [Read error: 60 (Operation timed out)] 00:59:29 maybe there's a recursive algorithm for long division 00:59:45 That sounds more than a bit silly. I don't think /my/ father has ever fretted about recursion. If yours has, more power to you both! 01:00:19 How about a Peano curve? 01:03:27 reprore [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 01:06:34 -!- reprore [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Remote closed the connection] 01:08:57 Daemmerung: he programs in a high level language for his work. 01:09:13 offby1: i think towers of hanoi is going to be the next attempt =) 01:09:29 Daemmerung: 01:10:32 Daemmerung: woah, very cool. i have never learned about this i don't think. 01:20:22 -!- underspecified_ [n=eric@softbank220043052007.bbtec.net] has quit [] 01:21:03 derrida: wait. He's a professional programmer, but doesn't get recursion? 01:22:22 No, I get it. My father does breadboard (? I think that's the word) electronics, but is not a professional EE. 01:23:24 reprore [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 01:30:15 -!- Nshag [i=user@Mix-Orleans-106-3-139.w193-248.abo.wanadoo.fr] has quit ["Quitte"] 01:30:26 Daemmerung: does he fail to understand Ohm's Law? 01:33:36 derrida: Our numbering system is recursive. A Natural Number is either: The Number One, or The Number One plus a Natural Number. 01:34:17 Three, is The Number One plus The Number One plus The Number one. You'll see that the right hand side of all my "... plus ..." expressions is a Natural Number. 01:38:59 Towers of Hanoi is probably a better example. 01:43:19 I believe the numbering system is a simpler example of recursion. The factorial program is, after all, the "hello world" of purely function programming languages. 01:43:30 s/function/functional/ 01:46:26 It's indeed an example, but something tells me it won't be illustrative, because it's not a _problem_. I think it'd be best to find a problem whose solution is clearly of the form "solve a similar but simpler problem, then modify that solution a little bit to complete it". 01:46:49 I doubt, e.g., that it would have helped _me_ to learn recursion using the number system as an example. 01:52:28 sreeram [n=sreeram@122.174.68.30] has joined #scheme 01:55:37 authorblues [n=authorbl@c-71-226-102-202.hsd1.sc.comcast.net] has joined #scheme 01:56:21 is there any way to invoke mit-scheme in such a way that it runs a file and doesnt load that live interpreter? 01:56:51 -!- reprore [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Remote closed the connection] 01:57:25 mit-scheme --batch-mode --load --eval '(%exit)' 01:58:46 I find that I learned recursion by associating recursion with recursive definitions of functions in mathematics. 02:02:28 Riastradh: that was a large step in the right direction 02:02:40 What about it doesn't do what you want? 02:02:45 Riastradh: is there any way to get rid of the fluff... like the Loading and the exit 02:02:57 i really just want it to print what it is asked to print and nothing more 02:03:37 Oh. Sorry, that was fixed a couple of months ago (so that now batch mode suppresses loading notifications), but I suppose that postdated the last snapshot released; you can work around it by explicitly using 02:03:55 mit-scheme --batch-mode --eval '(fluid-let ((load/suppress-loading-message? #t)) (load "") (%exit))' 02:04:45 derrida: maybe your father understands recursion and so doesn't have any "Aha!" moment and so thinks he doesn't get it. 02:05:22 thats exactly what i wanted 02:06:24 -!- joast [n=rick@76.178.184.231] has quit [Read error: 110 (Connection timed out)] 02:07:39 Riastradh: thanks for the help. now to turn this into a bash alias for easy use... 02:07:53 Why do you want to use this often interactively? 02:08:49 joast [n=rick@76.178.184.231] has joined #scheme 02:09:16 im not sure. i just dont really care too much for the interactive interpreter. its a matter of preference, i suppose(?) 02:09:52 I don't use that, either; I use Edwin or GNU Emacs and seldom invoke Scheme from a shell (except to start Edwin). 02:10:22 ive never really used edwin. im not really certain the point, which is a sign of my own ignorance 02:10:41 i learned scheme for about 2 weeks in a senior-level uni class, and now im trying to learn it for real 02:11:15 Presumably you use something to edit code... Surely at least editing code qualifies as `a point'. 02:12:00 haha, yes, but i mean edwin in particular 02:12:14 doesnt seem cost effective, since i just use either gedit or vi 02:14:27 GEdit is what doesn't seem cost effective to me. :-) 02:15:42 Has MIT Scheme gone 64-bit yet? 02:15:46 arcfide: sorry. it works for me. its the first text editor i ever used on linux, and im a creature of habit 02:16:10 authorblues: Well, if you can get plenty of real work done with it.... 02:16:39 There is no native x86-64 support. You can use the C back end, however. 02:17:04 arcfide: i can and have. i like it. i mean, ive never been one to subscribe to the vi/emacs war, because i personally dont prefer a console text editor. i really like using the mouse in a visual text editor. 02:17:20 authorblues: Have you tried NEdit? 02:17:37 Riastradh: Hrm, okay, I'm trying to recall, but does the C back end have the same memory limit issues on 64-bit machines? 02:17:41 No. 02:17:48 Well, yes, but it doesn't matter. 02:17:57 Riastradh: Right, because it's huge, right? :-) 02:18:04 The data representation still subtracts six bits from the usable address space. 02:18:07 -!- dudleyf [n=dudleyf@ip70-178-212-238.ks.ks.cox.net] has quit [] 02:18:29 And the C back end is the one that does Scheme->C->Native? 02:18:32 That leaves 58 bits, rather than 26 bits, of usable address space, which far exceeds the capacity of any existing implementation of any 64-bit architecture of which I am aware. 02:18:34 arcfide: ill check it out 02:18:57 authorblues: I also have some stuff written for NEdit that makes it easier to write Scheme with it. 02:19:35 arcfide: ive found scheme fairly painless with gedit. some trivial syntax highlighting, highlights corresponding paren. no complaints so far :-) 02:20:44 foof [n=user@dn157-046.naist.jp] has joined #scheme 02:23:53 jonrafkind [n=jon@c-98-202-86-149.hsd1.ut.comcast.net] has joined #scheme 02:25:33 danking: If you took 211, then you should know why the factorial function suck as a hello-world. 02:25:50 apparently im not smart enough to set this command up as an alias. 02:26:02 so ill continue using the interactive interpreter 02:26:03 -!- authorblues [n=authorbl@c-71-226-102-202.hsd1.sc.comcast.net] has left #scheme 02:35:37 bombshelter13p_ [n=bombshel@24.114.232.33] has joined #scheme 02:45:03 bombshelter13p__ [n=bombshel@24.114.232.33] has joined #scheme 02:45:15 i guess authorblues was unaware that vim/emacs have had guis for years. :\ 02:47:39 -!- bombshelter13p__ [n=bombshel@24.114.232.33] has quit [Client Quit] 02:51:25 -!- bombshelter13p_ [n=bombshel@24.114.232.33] has quit [Read error: 60 (Operation timed out)] 02:53:10 tjafk1 [n=timj@e176195171.adsl.alicedsl.de] has joined #scheme 02:55:06 cky [n=cky@cpe-024-211-249-162.nc.res.rr.com] has joined #scheme 02:59:53 -!- RageOfThou [n=RageOfTh@89.146.182.158] has quit [Read error: 110 (Connection timed out)] 03:00:33 -!- cky [n=cky@cpe-024-211-249-162.nc.res.rr.com] has quit [Remote closed the connection] 03:04:19 cky [n=cky@cpe-024-211-249-162.nc.res.rr.com] has joined #scheme 03:08:57 -!- tjafk2 [n=timj@e176197224.adsl.alicedsl.de] has quit [Read error: 110 (Connection timed out)] 03:10:47 eli: why does factorial suck as a hello-world, b/c the intuitive def'n isn't tail recursive? 03:11:17 -!- sreeram [n=sreeram@122.174.68.30] has quit [] 03:12:21 raikov [n=igr@203.181.243.11] has joined #scheme 03:19:24 underspecified_ [n=eric@walnut.naist.jp] has joined #scheme 03:20:33 danking: No, because numbers are not intuitively recursive. 03:20:58 tail-recursion has almost nothing to do with understanding recursion... 03:21:11 -!- thesnowdog_ is now known as thesnowdog 03:21:20 This is why 211 always uses structural recursion to introduce the concept. 03:23:04 Structural recursion is easier to relate to because there is a direct connection there: a problem is made of sub-parts, so expressing a solution in terms of the sub-parts becomes *very* natural. OTOH, with numbers people don't intuitively take "3" to have "2" as a sub-part -- and that's probably one of the biggest barriers to internalizing recursion or induction when it's introduced with numbers. 03:24:01 Things like the correct stopping condition, what is the base case, or basecase-less strong induction are very confusing when used with numbers. 03:25:21 ha, eli is saying what I said 90 minutes ago, more articulately 03:25:37 what's a good example of strong induction in programming? 03:25:55 when I held an electromagnet up to my friend's monitor, just to piss him off 03:26:24 offby1: Sorry, I just skimmed through it... 03:26:50 not a problem -- you really -did- say it more articulately 03:26:53 offby1: that's purely electromagnetic, no strong force involved ;) 03:26:56 *eli* notes his confusion of datkin and danking... 03:27:38 it's happened before 03:27:46 datkin: The best example I ever saw for demonstrating the difference is the one that I had in my intro to logic course -- we used the towers of hanoi: 03:28:01 The simple version is directly corresponding to simple recursion, 03:28:30 and a variant of it is that the discs are randomly spread across the three poles -- and you need to sort them out following the usual rules. 03:28:31 saccade_ [n=saccade@dhcp-18-188-74-28.dyn.mit.edu] has joined #scheme 03:28:37 -!- derrida [n=mgs@unaffiliated/deleuze] has quit ["leaving"] 03:28:44 That variant is extremely easy/natural with strong induction. 03:29:18 (But we had that course back before the integer numbers were invented. Probably the reason for offby1's recommendation...) 03:33:10 wow, old course. 03:34:59 eli: maybe I'll try that out after my final tomorrow 03:35:12 datkin: Maybe what? 03:35:24 jlongster [n=user@173-20-80-84.client.mchsi.com] has joined #scheme 03:35:45 Oh, sorry, I read a comma after "maybe". 03:35:53 In any case, it's nearly trivial. 03:36:20 -!- raikov [n=igr@203.181.243.11] has quit [Read error: 110 (Connection timed out)] 03:36:21 (This was in our first semester, and IIRC, it was the first homework.) 03:39:17 ice_man` [n=user@CPE000d6074b550-CM001a66704e52.cpe.net.cable.rogers.com] has joined #scheme 03:39:25 -!- ice_man` [n=user@CPE000d6074b550-CM001a66704e52.cpe.net.cable.rogers.com] has quit [Remote closed the connection] 04:05:52 -!- Kusanagi [n=Lernaean@unaffiliated/kusanagi] has quit [Nick collision from services.] 04:05:53 Hydr4 [n=Lernaean@24-107-112-153.dhcp.stls.mo.charter.com] has joined #scheme 04:08:17 -!- MichaelRaskin [n=MichaelR@195.91.224.225] has quit [Read error: 60 (Operation timed out)] 04:12:59 amca [n=amca@CPE-121-208-82-97.qld.bigpond.net.au] has joined #scheme 04:19:33 -!- annodomini [n=lambda@wikipedia/lambda] has quit [] 04:31:10 In C, the integers 0 and 1 are used for booleans. In Erlang true and false symbols are used. What is the benefit of having an actual boolean data type in Scheme? 04:37:18 Unambiguity. 04:37:52 MichaelRaskin [n=MichaelR@213.171.48.239] has joined #scheme 04:42:52 -!- underspecified_ [n=eric@walnut.naist.jp] has quit [] 04:48:08 -!- parolang [n=user@keholmes.oregonrd-wifi-1261.amplex.net] has quit [Remote closed the connection] 04:49:18 gfb [i=ad22383a@gateway/web/freenode/x-2b1cc9fcb2bdbbaf] has joined #scheme 04:49:19 peter_12: less bugs. 04:49:39 eli: why is that? 04:50:07 You have less chances of treating a non-boolean value as a boolean one. 04:50:40 Take a language with a single type as an extreme example -- this means no type errors whatsoever -- not static, and not dynamic. 04:51:10 (TCL was pretty close to that silliness.) 04:51:20 *eli* enjoys speaking about TCL in past tense 04:54:20 -!- jlongster [n=user@173-20-80-84.client.mchsi.com] has quit [Read error: 113 (No route to host)] 04:55:22 -!- gfb [i=ad22383a@gateway/web/freenode/x-2b1cc9fcb2bdbbaf] has quit [Ping timeout: 180 seconds] 04:55:23 johnnowak [n=johnnowa@207-38-171-48.c3-0.wsd-ubr1.qens-wsd.ny.cable.rcn.com] has joined #scheme 04:59:39 pantsd [n=hkarau@206-248-163-186.dsl.teksavvy.com] has joined #scheme 05:10:58 ikaros [n=ikaros@f051054047.adsl.alicedsl.de] has joined #scheme 05:12:58 incubot: amazing; not quite fractal, but spontaneous; and only ameliorated by psilocybin: http://www.youtube.com/watch?v=306MUlh054Y 05:13:02 Nope. I'm only bored enough to write a fractal renderer in AutoLisp, and I already did that. 05:13:59 -!- peter_12 [n=peter_12@S010600119506b129.gv.shawcable.net] has quit [] 05:19:57 -!- arcfide [n=arcfide@h-68-165-56-221.chcgilgm.dynamic.covad.net] has left #scheme 05:20:10 arcfide [n=arcfide@h-68-165-56-221.chcgilgm.dynamic.covad.net] has joined #scheme 05:22:15 vyazovoi [n=vyazovoi@horrible-unlim.vpn.mgn.ru] has joined #scheme 05:41:27 Riastradh: I am working with paredit, scheme mode, and a noweb meta minor mode that switches the major mode depending upon where in the file I am. That is, since I have mixed TeX with Scheme code, I want Emacs to have a different mode running when I am editing the Scheme code to when I am editing the TeX code. 05:41:46 This isn't quite working because when I load paredit, it checks the entire file and gives me grief over unmatched quotes. 05:42:12 Is there some way of handling this cleanly or at least, in a way that it works? 05:46:55 C-u M-x paredit 05:47:51 -!- vyazovoi [n=vyazovoi@horrible-unlim.vpn.mgn.ru] has left #scheme 05:48:31 foof: Um, what if it is being loaded automatically as part of a hook into the scheme-mode which is loaded when I enter a section of the buffer, and thus I can't use C-u. 05:48:33 ? 05:48:47 Then bitch to Riastradh, as many other people have :) 05:48:57 I personally hate that default setting to. 05:51:28 foof: Well, I don't know that it is so bad, but I need some way to have it check the balancing only on sectios that it should be checking, and not on those sections which are actually TeX code. 05:54:02 -!- ikaros [n=ikaros@f051054047.adsl.alicedsl.de] has quit ["Leave the magic to Houdini"] 05:55:01 -!- ASau [n=user@193.138.70.52] has quit [Remote closed the connection] 05:55:13 ASau [n=user@193.138.70.52] has joined #scheme 05:56:34 -!- ecraven [n=nex@140.78.42.103] has quit [Remote closed the connection] 05:59:02 thesnowdog_ [i=thesnowd@114.73.37.115] has joined #scheme 06:11:01 underspecified_ [n=eric@isa7-dhcp-116-224.naist.jp] has joined #scheme 06:13:06 eno_ [n=eno@adsl-70-137-150-39.dsl.snfc21.sbcglobal.net] has joined #scheme 06:16:26 -!- ASau [n=user@193.138.70.52] has quit ["off"] 06:16:56 -!- thesnowdog [i=thesnowd@122.110.27.132] has quit [Read error: 110 (Connection timed out)] 06:20:40 -!- thesnowdog_ is now known as thesnowdog 06:23:44 -!- eno [n=eno@nslu2-linux/eno] has quit [Read error: 110 (Connection timed out)] 06:26:30 -!- eno_ is now known as eno 06:27:22 mmc [n=mima@cs162149.pp.htv.fi] has joined #scheme 06:34:31 -!- arcfide [n=arcfide@h-68-165-56-221.chcgilgm.dynamic.covad.net] has left #scheme 06:56:32 ecraven [n=nex@140.78.42.103] has joined #scheme 06:59:38 pierpa [n=user@host202-182-static.80-94-b.business.telecomitalia.it] has joined #scheme 07:01:34 -!- mmc [n=mima@cs162149.pp.htv.fi] has quit [Read error: 110 (Connection timed out)] 07:10:55 -!- Poeir [n=Poeir@c-98-222-133-165.hsd1.il.comcast.net] has quit [Read error: 60 (Operation timed out)] 07:11:08 Poeir [n=Poeir@c-98-222-133-165.hsd1.il.comcast.net] has joined #scheme 07:17:32 ASau [n=user@host169-231-msk.microtest.ru] has joined #scheme 07:18:16 -!- melgray [n=melgray@97-126-114-243.tukw.qwest.net] has quit [] 07:29:48 mmc [n=mima@esprx02x.nokia.com] has joined #scheme 07:30:37 rgrau [n=user@161.116.222.132] has joined #scheme 07:31:28 raikov [n=igr@60.32.127.43] has joined #scheme 07:35:21 ejs [n=eugen@36-90-135-95.pool.ukrtel.net] has joined #scheme 07:36:51 athos [n=philipp@92.250.250.68] has joined #scheme 07:39:25 -!- kniu [n=kniu@pool-71-107-56-85.lsanca.dsl-w.verizon.net] has quit [Read error: 110 (Connection timed out)] 07:39:55 kniu [n=kniu@pool-71-107-56-85.lsanca.dsl-w.verizon.net] has joined #scheme 07:51:18 -!- ejs [n=eugen@36-90-135-95.pool.ukrtel.net] has quit ["This computer has gone to sleep"] 07:52:39 barney [n=bernhard@p549A0FCB.dip0.t-ipconnect.de] has joined #scheme 07:53:32 -!- raikov [n=igr@60.32.127.43] has quit [Read error: 110 (Connection timed out)] 07:57:20 -!- underspecified_ [n=eric@isa7-dhcp-116-224.naist.jp] has quit [] 08:02:27 Dark-Star [n=michael@p57B5422E.dip.t-dialin.net] has joined #scheme 08:05:17 -!- Hydr4 is now known as Kusanagi 08:08:29 dzhus [n=sphinx@95-24-114-97.broadband.corbina.ru] has joined #scheme 08:26:15 wingo [n=wingo@ATuileries-153-1-13-190.w82-123.abo.wanadoo.fr] has joined #scheme 08:26:43 ejs [n=eugen@77.222.151.102] has joined #scheme 08:32:13 -!- ejs [n=eugen@77.222.151.102] has quit [Read error: 60 (Operation timed out)] 08:32:36 ejs [n=eugen@nat.ironport.com] has joined #scheme 08:43:19 blackened` [n=blackene@ip-89-102-28-224.karneval.cz] has joined #scheme 09:27:26 npe [n=npe@212.224.218.143] has joined #scheme 09:28:42 -!- athos [n=philipp@92.250.250.68] has quit ["leaving"] 09:30:25 -!- saccade_ [n=saccade@dhcp-18-188-74-28.dyn.mit.edu] has quit ["This computer has gone to sleep"] 09:30:26 -!- npe [n=npe@212.224.218.143] has quit [Read error: 104 (Connection reset by peer)] 09:31:24 npe [n=npe@212.224.218.143] has joined #scheme 09:41:56 npe_ [n=npe@212.224.218.143] has joined #scheme 09:41:56 -!- npe [n=npe@212.224.218.143] has quit [Read error: 104 (Connection reset by peer)] 09:42:22 -!- npe_ is now known as npe 09:43:02 -!- npe [n=npe@212.224.218.143] has quit [Client Quit] 09:43:40 jewel [n=jewel@dsl-242-129-65.telkomadsl.co.za] has joined #scheme 09:47:35 -!- kilimanjaro [n=kilimanj@70.116.95.163] has quit [Remote closed the connection] 09:54:01 -!- Arelius [n=indy@64.174.9.113] has quit ["leaving"] 09:54:13 Arelius [n=indy@64.174.9.113] has joined #scheme 10:05:00 -!- wingo [n=wingo@ATuileries-153-1-13-190.w82-123.abo.wanadoo.fr] has quit [Read error: 60 (Operation timed out)] 10:26:16 -!- dzhus [n=sphinx@95-24-114-97.broadband.corbina.ru] has quit ["-_-"] 10:26:44 -!- cracki [n=cracki@sglty.kawo2.RWTH-Aachen.DE] has quit ["If technology is distinguishable from magic, it is insufficiently advanced."] 10:33:46 -!- Dark-Star [n=michael@p57B5422E.dip.t-dialin.net] has quit [Read error: 104 (Connection reset by peer)] 10:39:31 raikov [n=igr@203.181.243.11] has joined #scheme 11:01:12 -!- raikov [n=igr@203.181.243.11] has quit [Read error: 110 (Connection timed out)] 11:16:02 xwl_ [n=user@147.243.236.60] has joined #scheme 11:16:45 cracki [n=cracki@41-144.eduroam.RWTH-Aachen.DE] has joined #scheme 11:21:11 underspecified_ [n=eric@softbank220043052007.bbtec.net] has joined #scheme 11:22:08 sepult [n=user@xdsl-87-78-75-85.netcologne.de] has joined #scheme 11:35:03 Edico [n=Edico@unaffiliated/edico] has joined #scheme 11:46:33 dzhus [n=sphinx@95-24-82-94.broadband.corbina.ru] has joined #scheme 11:49:55 ejs1 [n=eugen@77.222.151.102] has joined #scheme 11:51:57 -!- sepult [n=user@xdsl-87-78-75-85.netcologne.de] has quit ["ERC Version 5.3 (IRC client for Emacs)"] 11:59:48 -!- ejs [n=eugen@nat.ironport.com] has quit [Read error: 110 (Connection timed out)] 12:02:07 -!- rgrau [n=user@161.116.222.132] has quit [Remote closed the connection] 12:07:49 Mestoco [n=user@a88-115-8-123.elisa-laajakaista.fi] has joined #scheme 12:09:21 Mr-Cat [n=Miranda@hermes.lanit.ru] has joined #scheme 12:10:43 luz [n=davids@189.122.121.232] has joined #scheme 12:13:04 -!- jewel [n=jewel@dsl-242-129-65.telkomadsl.co.za] has quit [Read error: 113 (No route to host)] 12:19:17 -!- ken-p [n=ken-p@84.92.70.37] has quit [Success] 12:22:32 -!- johnnowak [n=johnnowa@207-38-171-48.c3-0.wsd-ubr1.qens-wsd.ny.cable.rcn.com] has quit [] 12:22:51 -!- ejs1 [n=eugen@77.222.151.102] has quit ["This computer has gone to sleep"] 12:28:30 -!- amca [n=amca@CPE-121-208-82-97.qld.bigpond.net.au] has quit ["Farewell"] 12:34:17 -!- cky [n=cky@cpe-024-211-249-162.nc.res.rr.com] has quit ["Restarting IRC client :-)"] 12:34:45 cky [n=cky@cpe-024-211-249-162.nc.res.rr.com] has joined #scheme 12:47:39 -!- leppie [n=lolcow@dsl-243-41-58.telkomadsl.co.za] has quit [Read error: 54 (Connection reset by peer)] 12:48:20 leppie [n=lolcow@41.243.41.58] has joined #scheme 12:49:13 -!- leppie [n=lolcow@41.243.41.58] has quit [Read error: 104 (Connection reset by peer)] 12:49:49 leppie [n=lolcow@dsl-243-41-58.telkomadsl.co.za] has joined #scheme 12:57:56 annodomini [n=lambda@c-75-69-96-104.hsd1.nh.comcast.net] has joined #scheme 13:04:10 -!- pantsd [n=hkarau@206-248-163-186.dsl.teksavvy.com] has quit [Read error: 113 (No route to host)] 13:04:49 pantsd [n=hkarau@69-165-160-51.dsl.teksavvy.com] has joined #scheme 13:05:06 Judofyr [n=Judofyr@77.40.165.3] has joined #scheme 13:07:01 -!- dsmith [n=dsmith@cpe-173-88-196-177.neo.res.rr.com] has quit ["Leaving"] 13:07:18 -!- dzhus [n=sphinx@95-24-82-94.broadband.corbina.ru] has quit ["-_-"] 13:10:28 sepult [n=user@xdsl-87-78-75-85.netcologne.de] has joined #scheme 13:10:53 -!- pantsd [n=hkarau@69-165-160-51.dsl.teksavvy.com] has quit ["Leaving."] 13:14:03 I suppose the reason why I liked numbers as an example of recursion was *because* it was unnatural. To view subway stations and lines or lists as recurisve seemed all to familiar, it didn't make me say "Hey, that's a totally different way of thinking." 13:16:02 rmorris [n=user@209.120.179.205] has joined #scheme 13:17:18 -!- Mr-Cat [n=Miranda@hermes.lanit.ru] has quit [Read error: 104 (Connection reset by peer)] 13:21:15 somewhat belated, but chibi 0.2 is out 13:24:51 bombshelter13_ [n=bombshel@toronto-gw.adsl.erx01.mtlcnds.ext.distributel.net] has joined #scheme 13:25:55 -!- annodomini [n=lambda@wikipedia/lambda] has quit [] 13:31:05 Thanks, foof! Nabbing a copy now. 13:36:30 -!- sepult [n=user@xdsl-87-78-75-85.netcologne.de] has quit ["ERC Version 5.3 (IRC client for Emacs)"] 13:37:29 sepult [n=user@xdsl-87-78-75-85.netcologne.de] has joined #scheme 13:41:24 moghar [n=user@unaffiliated/moghar] has joined #scheme 13:49:41 metasyntax|work [n=taylor@75-149-208-121-Illinois.hfc.comcastbusiness.net] has joined #scheme 13:52:28 Mr-Cat [n=Miranda@hermes.lanit.ru] has joined #scheme 13:54:17 -!- Adamant_ [n=Adamant@unaffiliated/adamant] has quit [] 13:54:22 jewel [n=jewel@dsl-242-129-65.telkomadsl.co.za] has joined #scheme 13:54:27 -!- Daemmerung [n=goetter@1133sae.mazama.net] has quit [Read error: 54 (Connection reset by peer)] 14:00:36 attila_lendvai [n=ati@catv-89-132-189-132.catv.broadband.hu] has joined #scheme 14:05:02 Nshag [i=user@Mix-Orleans-106-4-142.w193-248.abo.wanadoo.fr] has joined #scheme 14:05:25 -!- Mestoco [n=user@a88-115-8-123.elisa-laajakaista.fi] has quit [Read error: 110 (Connection timed out)] 14:10:14 roderic [n=user@pinball.ccs.neu.edu] has joined #scheme 14:12:55 ejs [n=eugen@252-237-124-91.pool.ukrtel.net] has joined #scheme 14:14:17 -!- sepult [n=user@xdsl-87-78-75-85.netcologne.de] has quit [Read error: 104 (Connection reset by peer)] 14:16:49 sepult [n=user@xdsl-87-78-131-34.netcologne.de] has joined #scheme 14:18:48 Judofyr_ [n=Judofyr@77.40.165.3] has joined #scheme 14:19:41 -!- cracki [n=cracki@41-144.eduroam.RWTH-Aachen.DE] has quit ["If technology is distinguishable from magic, it is insufficiently advanced."] 14:20:44 annodomini [n=lambda@130.189.179.215] has joined #scheme 14:24:43 -!- Judofyr_ [n=Judofyr@77.40.165.3] has quit ["raise Hand, 'wave'"] 14:25:52 ejs1 [n=eugen@nat.ironport.com] has joined #scheme 14:30:04 stepnem_ [i=stepnem@173-19-7-99.client.mchsi.com] has joined #scheme 14:30:09 -!- ejs [n=eugen@252-237-124-91.pool.ukrtel.net] has quit [Read error: 104 (Connection reset by peer)] 14:30:41 -!- Judofyr [n=Judofyr@77.40.165.3] has quit [Read error: 113 (No route to host)] 14:35:12 -!- ejs1 [n=eugen@nat.ironport.com] has quit [Read error: 60 (Operation timed out)] 14:38:24 ejs1 [n=eugen@91.124.237.252] has joined #scheme 14:39:42 -!- metasyntax|work [n=taylor@75-149-208-121-Illinois.hfc.comcastbusiness.net] has quit ["If you reach back in your memory, a little bell might ring, 'bout a time that once existed when money wasn't king."] 14:41:57 soupdragon [n=f@amcant.demon.co.uk] has joined #scheme 14:50:10 chickamade [n=chickama@222.254.8.145] has joined #scheme 14:54:39 -!- chickamade [n=chickama@222.254.8.145] has left #scheme 14:58:17 -!- moghar [n=user@unaffiliated/moghar] has quit [Read error: 113 (No route to host)] 15:00:58 moghar [n=user@157.185.jawnet.pl] has joined #scheme 15:01:48 -!- ASau [n=user@host169-231-msk.microtest.ru] has quit ["off"] 15:03:27 -!- ejs1 [n=eugen@91.124.237.252] has quit ["This computer has gone to sleep"] 15:04:40 ikaros [n=ikaros@f050246097.adsl.alicedsl.de] has joined #scheme 15:05:13 ejs0 [n=eugen@252-237-124-91.pool.ukrtel.net] has joined #scheme 15:10:01 -!- offby1 [n=user@pdpc/supporter/monthlybyte/offby1] has quit [Read error: 104 (Connection reset by peer)] 15:13:17 Adamant [n=Adamant@c-76-29-188-60.hsd1.ga.comcast.net] has joined #scheme 15:21:03 metasyntax|work [n=taylor@75-149-208-121-Illinois.hfc.comcastbusiness.net] has joined #scheme 15:25:27 xwl [n=user@62.237.32.162] has joined #scheme 15:26:41 -!- stepnem [n=stepnem@topol.nat.praha12.net] has quit [Read error: 113 (No route to host)] 15:27:50 reprore [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 15:30:01 -!- Mr-Cat [n=Miranda@hermes.lanit.ru] has quit [Read error: 54 (Connection reset by peer)] 15:32:06 CSdread_ [n=danielf@c-68-35-129-24.hsd1.nm.comcast.net] has joined #scheme 15:33:37 athos [n=philipp@92.250.250.68] has joined #scheme 15:34:28 offby1 [n=user@q-static-138-125.avvanta.com] has joined #scheme 15:35:05 -!- greg02 [n=greg@ool-18bc79e7.dyn.optonline.net] has quit ["Lost terminal"] 15:35:16 dudleyf [n=dudleyf@65.243.31.107] has joined #scheme 15:37:20 foof: nice blog post, enjoyed reading it 15:39:20 krat3r [n=krat@81.84.156.103] has joined #scheme 15:40:32 -!- krat3r [n=krat@81.84.156.103] has quit [Client Quit] 15:41:37 peter_12 [n=peter_12@S010600119506b129.gv.shawcable.net] has joined #scheme 15:41:41 thanks :) 15:41:44 dean_ [i=4b107cb6@gateway/web/freenode/x-284627a82af23b21] has joined #scheme 15:42:20 do I just need a C compiler to compile chibi 15:42:56 Yeah... I haven't tried it on Windows yet, but it should build out of the box on OS X or Linux. 15:43:09 i'll test drive windows for you :) 15:44:26 try "make PLATFORM=mingw" 15:46:33 Oh... does windows have either of funopen or fmemopen? 15:47:44 fmemopen? 15:48:16 hehe, that's a funny function :) 15:48:24 A glibc-ism, a weaker variant of funopen. 15:48:36 It's not a glibc-ism: http://www.opengroup.org/onlinepubs/9699919799/functions/fmemopen.html 15:49:03 oh :) 15:49:42 Anyway, you need one or the other right now for string ports, which are needed for procedures like string->number and number->string. 15:51:30 -!- pierpa [n=user@host202-182-static.80-94-b.business.telecomitalia.it] has quit [Read error: 110 (Connection timed out)] 15:52:47 -!- reprore [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Read error: 104 (Connection reset by peer)] 15:53:03 reprore [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 15:54:09 http://www.musashimiyamoto.com/musashi/musahi_art.html 15:55:03 That didn't make it into the post, but is related. There's another really nice painting of a monk drawn in a single line. 15:55:10 nice picture 16:00:37 wingo [n=wingo@66.Red-83-34-178.dynamicIP.rima-tde.net] has joined #scheme 16:00:52 argggg, not portable C C89 :( damn GCC-isms 16:01:05 -!- dean_ [i=4b107cb6@gateway/web/freenode/x-284627a82af23b21] has quit ["Page closed"] 16:01:12 There are no GCC-isms. There is some C99. 16:01:35 well those! 16:02:28 ... mostly C99 that is also supported by the Plan 9 compiler, which supports only a very minimal C spec. 16:03:12 Specifically, I use named field initializers in struct literals. 16:03:13 derrida [n=jacques@unaffiliated/deleuze] has joined #scheme 16:04:09 And there are some variadic macros. 16:04:40 But I was very careful to avoid fancier things like # and ##. 16:06:07 I didn't know # was fancy 16:06:24 It is if you're stuck in the 80's. 16:07:11 *foof* pictures leppie in parachute pants and big hair 16:07:35 -!- sepult [n=user@xdsl-87-78-131-34.netcologne.de] has quit ["ERC Version 5.3 (IRC client for Emacs)"] 16:08:41 argg, you cant use array notation on enums it seems :( 16:09:32 You mean you can't say array[MY_ENUM] ? 16:09:48 no, you cant do myenum[index] 16:10:12 Should that work in any version of C? 16:10:15 I don't do that, do I? What would it even mean? 16:10:25 t = &(sexp_types[sexp_pointer_tag(x)]); 16:10:50 in the gc line 41 16:11:06 sexp_types is not an enum 16:11:19 static struct sexp_struct sexp_types[] = { ... } 16:11:31 enum sexp_types in sexp.h 16:11:48 hmmm 16:12:10 Oh... those should be in separate namespaces, though that was bad style of me to pun the names. 16:12:23 ok :) 16:12:27 Change the enum name to anything, or nothing, it isn't used anywhere. 16:12:36 dereferencing type-punned pointer will break strict aliasing rules! 16:13:20 Is that what that warning means? 16:14:13 ok, that helped, till it choked on those struct initializers 16:15:06 What compiler are you using? 16:15:17 -!- dudleyf [n=dudleyf@65.243.31.107] has quit [] 16:15:50 msvc 16:16:43 foof: no, it means something else 16:17:51 Elly: I saw that warning before but don't get it anymore, how did you get it? 16:18:10 in C99, pointers of different types are not allowed to alias each other 16:18:19 (the aforementioned "strict aliasing rule") 16:18:28 of course, nobody actually does this, so it's off by default in every compiler 16:19:27 I am trying to remember how you summon that warning 16:20:09 OK, I knew that, and am not interested in platforms where it could actually break :) 16:21:15 that's good, because I can't remember what particular combination of casting and not casting causes it 16:21:29 You didn't get it just now? 16:21:47 no :P 16:22:44 weinholt` [i=weinholt@2a02:9a0:a101:0:a08d:37ca:dfb1:950b] has joined #scheme 16:22:53 -!- weinholt [i=weinholt@debian/emeritus/weinholt] has quit [Read error: 60 (Operation timed out)] 16:22:55 MrFahrenheit [n=RageOfTh@89.146.171.132] has joined #scheme 16:22:59 -!- weinholt` is now known as weinholt 16:23:41 Oh wait, I think that was a 64bit problem. I don't have a 64bit machine handy to test with though... 16:23:48 hm 16:23:54 it occurs to me that I haven't showered yet today 16:23:57 *Elly* -> 16:24:34 TMI 16:25:09 dudleyf [n=dudleyf@65.243.31.107] has joined #scheme 16:26:49 Elly: -pedantic ? 16:28:16 oh, you wanna recreate it :) 16:28:45 (char*)(void*)(char*) should cause it not? 16:30:28 incubot: bell biv devoe called... even they don't want their pants back 16:30:31 ah - qmail - the name didn't ring a bell the first time around 16:37:17 -!- reprore [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Read error: 104 (Connection reset by peer)] 16:37:30 reprore [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 16:41:51 ejs [n=eugen@252-237-124-91.pool.ukrtel.net] has joined #scheme 16:44:10 REPLeffect [n=REPLeffe@69.54.115.254] has joined #scheme 16:47:39 -!- ejs [n=eugen@252-237-124-91.pool.ukrtel.net] has quit ["This computer has gone to sleep"] 16:49:17 foof, casting a pointer to function, into a pointer to object, is not even valid C99. 16:50:21 Yes, that I know. 16:50:41 ioizzgd [n=ioizzgd@206.251.250.219] has joined #scheme 16:50:42 And don't particularly care :) 16:51:29 Implementations in which pointers to function have a format different from pointers to objects, furthermore, are not at all far-fetched. For example, if pointers to objects occupy one `word', then a pointer to function could occupy two words, one for a pointer to its code and one for a pointer to its (stack-allocated) environment. 16:51:33 dlctestnt [n=dlctestn@206.251.250.209] has joined #scheme 16:53:34 Actually, although I wouldn't bother to change that if it created any more code, I only need to change the type of the foreign function pointer in opcodes. 16:54:24 Harvard architectures are fairly common in embedded processors as well. 16:54:53 fdgfdgdfg [i=4431d24f@gateway/web/freenode/x-132a57fa8447e314] has joined #scheme 16:54:59 bweaver [n=user@75-148-111-133-Chattanooga.hfc.comcastbusiness.net] has joined #scheme 16:55:35 -!- fdgfdgdfg [i=4431d24f@gateway/web/freenode/x-132a57fa8447e314] has quit [Client Quit] 16:55:43 Riastradh: or if you're on a harvard - 16:55:44 e:f;b 16:56:14 gfb [i=4c455486@gateway/web/freenode/x-0edf9b1ecaf7e81a] has joined #scheme 16:56:19 ... I'll add it to the todo list, for now I desperately need to sleep... 17:01:41 eek, segfaulted on call/cc 17:02:42 (define x #f) 17:03:00 Hmm? 17:03:11 (+ 2 3 4 (call-with-current-continuation (lambda (k) (set! x k) 32))) 17:03:14 (x 0) 17:03:42 -!- Fade [i=fade@outrider.deepsky.com] has quit [Read error: 60 (Operation timed out)] 17:03:45 Fade [i=fade@outrider.deepsky.com] has joined #scheme 17:04:01 in chibi scheme i mean 17:04:04 melgray [n=melgray@70.99.250.82] has joined #scheme 17:11:18 rdd [n=user@c83-250-157-93.bredband.comhem.se] has joined #scheme 17:13:07 a-s` [n=user@92.81.45.243] has joined #scheme 17:13:13 -!- kniu [n=kniu@pool-71-107-56-85.lsanca.dsl-w.verizon.net] has quit [Read error: 60 (Operation timed out)] 17:21:14 should I read "The Little Schemer" before or after SICP? 17:21:41 Before, probably 17:22:05 but "The Seasoned Schemer"? 17:23:43 Probably before SICP too, but it's not that big a deal 17:24:33 -!- soupdragon [n=f@amcant.demon.co.uk] has quit [Connection reset by peer] 17:24:52 ok 17:25:30 -!- mmc [n=mima@esprx02x.nokia.com] has quit [Remote closed the connection] 17:26:47 -!- a-s [n=user@92.81.130.69] has quit [Connection timed out] 17:26:49 kniu [n=kniu@pool-71-107-56-85.lsanca.dsl-w.verizon.net] has joined #scheme 17:28:54 Greg02 [n=greg@ool-18bc79e7.dyn.optonline.net] has joined #scheme 17:29:03 ejs [n=eugen@252-237-124-91.pool.ukrtel.net] has joined #scheme 17:33:05 soupdragon [n=f@amcant.demon.co.uk] has joined #scheme 17:33:12 -!- reprore [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Read error: 104 (Connection reset by peer)] 17:33:29 reprore [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 17:33:35 -!- ejs [n=eugen@252-237-124-91.pool.ukrtel.net] has quit [Client Quit] 17:35:58 Daemmerung [n=goetter@1133sae.mazama.net] has joined #scheme 17:46:54 sreeram [n=sreeram@122.174.68.30] has joined #scheme 17:52:30 -!- reprore [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Read error: 104 (Connection reset by peer)] 17:52:44 reprore [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 17:53:32 dysinger [n=tim@71.20.231.3] has joined #scheme 18:05:50 -!- peter_12 [n=peter_12@S010600119506b129.gv.shawcable.net] has quit [] 18:10:27 -!- rdd [n=user@c83-250-157-93.bredband.comhem.se] has quit [Read error: 104 (Connection reset by peer)] 18:21:53 -!- MichaelRaskin [n=MichaelR@213.171.48.239] has quit [Read error: 60 (Operation timed out)] 18:22:11 cracki [n=cracki@sglty.kawo2.RWTH-Aachen.DE] has joined #scheme 18:33:42 -!- jonrafkind [n=jon@c-98-202-86-149.hsd1.ut.comcast.net] has quit [Read error: 110 (Connection timed out)] 18:44:16 jonrafkind [n=jon@crystalis.cs.utah.edu] has joined #scheme 18:45:40 CaptainMorgan [n=CaptainM@75.68.42.94] has joined #scheme 18:47:01 -!- barney [n=bernhard@p549A0FCB.dip0.t-ipconnect.de] has quit [Remote closed the connection] 18:49:52 hkBst [n=hkBst@gentoo/developer/hkbst] has joined #scheme 18:50:01 lowlycoder [n=x@unaffiliated/lowlycoder] has joined #scheme 18:56:34 -!- reprore [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Remote closed the connection] 18:59:06 -!- CSdread_ [n=danielf@c-68-35-129-24.hsd1.nm.comcast.net] has quit [] 18:59:24 -!- lowlycoder [n=x@unaffiliated/lowlycoder] has quit ["leaving"] 18:59:47 -!- ski [n=slj@c-e113e055.1149-1-64736c10.cust.bredbandsbolaget.se] has quit [Read error: 104 (Connection reset by peer)] 19:04:51 ski [n=slj@c-e113e055.1149-1-64736c10.cust.bredbandsbolaget.se] has joined #scheme 19:05:57 lowlycoder [n=x@unaffiliated/lowlycoder] has joined #scheme 19:06:30 -!- fishey [n=fisheyss@ool-4573344b.dyn.optonline.net] has quit [Read error: 110 (Connection timed out)] 19:07:20 fishey [n=fisheyss@ool-4573344b.dyn.optonline.net] has joined #scheme 19:08:22 Edico: nonsense, man; SICP head-first 19:09:29 heh, that reminds me of sth 19:09:32 *sjamaan* rummages 19:09:34 http://headrush.typepad.com/creating_passionate_users/2005/04/announcing_head.html 19:09:36 -rudybot:#scheme- http://tinyurl.com/ktmxyz 19:10:10 Man, I wish that wasn't an april fools joke :( 19:10:11 moghar` [n=user@157.185.jawnet.pl] has joined #scheme 19:10:14 -!- moghar [n=user@unaffiliated/moghar] has quit [Read error: 113 (No route to host)] 19:10:25 -!- moghar` is now known as moghar 19:11:22 Gosh, have I mentioned how brain-damaged C's syntax is? 19:11:40 Not yet today, I think 19:11:42 do you need to? 19:12:11 -!- wingo [n=wingo@66.Red-83-34-178.dynamicIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)] 19:12:29 reprore [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 19:13:18 Suppose you want to write a literal struct or union. Maybe you want to pass it as an argument to a procedure, or maybe you want to store it in a variable declared with static storage, or maybe you immediately want to extract a field from it; it shouldn't make a difference which one you want. 19:13:53 -!- joast [n=rick@76.178.184.231] has quit [Read error: 110 (Connection timed out)] 19:14:38 So you might even write a macro to generate these literal structs or unions, with the hope that you can use a common macro for all of those purposes. 19:15:15 static struct foo the_foo = (MAKE_FOO (x, y, z)); frob (MAKE_FOO (x, y, z)); fnord ((MAKE_FOO (x, y, z)) . foo_field); 19:15:55 Suppose we had `struct foo { int x; double y; void *z; };' earlier. Quiz: How do you write the MAKE_FOO macro, to do what it obviously ought to do? 19:15:59 (We're talking C99 here, by the way.) 19:16:20 wingo [n=wingo@31.Red-79-156-66.staticIP.rima-tde.net] has joined #scheme 19:16:22 sjamaan: yikes; that cat has a hostile cranium, but underdeveloped frontal lobes 19:18:02 joast [n=rick@76.178.184.231] has joined #scheme 19:18:09 -!- reprore [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Remote closed the connection] 19:18:16 arcfide [n=arcfide@h-68-165-56-221.chcgilgm.dynamic.covad.net] has joined #scheme 19:18:22 Don't be discouraged if you can't find a working answer to my quiz; I'd just like to hear what you're trying. 19:18:47 (Maybe I ought not to spoil the quiz by telling you that there is no correct way to define MAKE_FOO.) 19:18:54 greetings #schemers. 19:18:58 (Oops.) 19:20:47 Come on, no takers? 19:21:04 #define MAKE_FOO(x,y,z) {x,y,z} 19:21:34 No, that fails for ((MAKE_FOO (x, y, z)) . x), because the C compiler doesn't know what kind of struct `. x' asks for the x field of. 19:21:50 oh ok 19:22:28 (Also, if we're using C99, please at least exploit the amenities it affords such as named initializers: #define MAKE_FOO(X, Y, Z) { .x = (X), .y = (Y), .z = (Z) } 19:22:31 ) 19:24:47 hey wingo 19:24:51 wingo: congrats on the release 19:24:59 heya duncanm. tx! 19:27:02 "Behold the power of the Y combinator" --ah, if only. 19:27:11 That is choice. 19:27:26 reprore [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 19:27:42 Riastradh: Regarding your quiz, I would have immediate switched languages and concluded that such a thing was crazy to attempt in C. 19:27:57 That is not an option for the present purposes. 19:28:27 There's nothing semantically tricky about this, incidentally. It's just that C's syntax is a pile of brain damage. 19:28:37 Yes. 19:28:38 Of course, it's syntax for types is much worse. 19:28:42 -!- lowlycoder [n=x@unaffiliated/lowlycoder] has quit ["leaving"] 19:31:44 hey what about making a lisp syntax for C 19:32:04 actually I had an even better idea, lisp compiler 19:32:27 -!- gfb [i=4c455486@gateway/web/freenode/x-0edf9b1ecaf7e81a] has quit [Remote closed the connection] 19:34:22 soupdragon: http://www.bitc-lang.org/ for your amusement 19:40:06 gfb [i=4c455486@gateway/web/freenode/x-918ac3089d88d1df] has joined #scheme 19:43:22 -!- joast [n=rick@76.178.184.231] has quit [Read error: 110 (Connection timed out)] 19:45:35 joast [n=rick@76.178.184.231] has joined #scheme 19:48:53 -!- jonrafkind [n=jon@crystalis.cs.utah.edu] has quit [No route to host] 19:51:05 Oddly enough, despite the Scheme-like syntax, there are no macros in BitC. 19:54:50 a-s`` [n=user@92.81.136.29] has joined #scheme 19:55:17 -!- xwl [n=user@62.237.32.162] has quit [Read error: 113 (No route to host)] 19:55:26 -!- a-s`` [n=user@92.81.136.29] has quit [Remote closed the connection] 20:01:02 lowlycoder [n=x@unaffiliated/lowlycoder] has joined #scheme 20:02:03 mrsolo [n=mrsolo@nat/yahoo/x-a0e4be9eb94da9bc] has joined #scheme 20:03:21 don't know if these are well known sexp C's: 20:03:35 SC: http://www.international-lisp-conference.org/2005/speakers.html#tasuku_hiraishi 20:03:37 -rudybot:#scheme- http://tinyurl.com/malrfr 20:04:11 sexpc: http://mumble.net/~campbell/darcs/old-sexpc/ 20:04:24 I attended that talk, and was not impressed. 20:05:11 A newer old version of sexpc (later renamed to scexp) is here: http://www.unmutual.info/software/scexp/ 20:05:19 do you know of any other (better) sexp syntax C's with macros 20:05:45 I am currently working on a more sophisticated variant on the same idea, with hygienic macros. 20:08:28 thanks for the link; and I'll look at BitC as a potential path for non-lisp people 20:08:48 -!- a-s` [n=user@92.81.45.243] has quit [Connection timed out] 20:15:52 mmc [n=mima@cs162149.pp.htv.fi] has joined #scheme 20:16:02 CSdread_ [n=danielf@c-68-35-129-24.hsd1.nm.comcast.net] has joined #scheme 20:23:00 -!- wingo [n=wingo@31.Red-79-156-66.staticIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)] 20:24:31 -!- REPLeffect [n=REPLeffe@69.54.115.254] has quit [Read error: 110 (Connection timed out)] 20:26:07 wingo [n=wingo@127.Red-79-151-219.dynamicIP.rima-tde.net] has joined #scheme 20:28:52 jonrafkind [n=jon@crystalis.cs.utah.edu] has joined #scheme 20:29:19 what's the most used GUI toolkit for scheme? 20:32:23 minion: thwap to Riastradh 20:32:24 Riastradh: please look at thwap: THWAP! http://www.angryflower.com/bobsqu.gif and http://www.angryflower.com/itsits.gif (see also: http://www.unmutual.info/misc/sb_itsits.mp3 ) 20:32:51 Lectus: there is no portable gui toolkit 20:33:01 each implementation would answer that question differently 20:34:11 -!- dfeuer [n=dfeuer@wikimedia/Dfeuer] has quit [Read error: 113 (No route to host)] 20:34:12 I'm trying PLT. Looks like it's the best implementation. It has IDE, GUI toolkit, good docs, etc. But I'm tempted to try others like bigloo because of native compilation. 20:34:57 But I'm unsure about the gains in speed. I might be better sticking to PLT since to produces executables anyway. 20:35:56 probably a good choice. 20:38:31 -!- ejs0 [n=eugen@252-237-124-91.pool.ukrtel.net] has quit [Read error: 60 (Operation timed out)] 20:38:53 OK, so why does SET-CAR! fail on a literal list? 20:39:10 literals are immutable 20:39:15 PLT has native compilation too 20:39:18 aha 20:39:40 How can I tell if someone has passed my function an immutable list? 20:40:35 not sure if you can? 20:40:44 i'm not* 20:41:29 -!- lowlycoder [n=x@unaffiliated/lowlycoder] has quit ["leaving"] 20:41:42 Perhaps you should consider not mutating pairs. 20:42:02 I've never needed to, just curious about potential pitfalls. 20:42:33 I'd only want to do it for circular lists, I think. 20:42:34 repror___ [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 20:42:35 -!- reprore [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Read error: 104 (Connection reset by peer)] 20:44:31 exit 20:44:34 bah 20:44:40 -!- rmorris [n=user@209.120.179.205] has left #scheme 20:47:24 -!- metasyntax|work [n=taylor@75-149-208-121-Illinois.hfc.comcastbusiness.net] has quit ["If you reach back in your memory, a little bell might ring, 'bout a time that once existed when money wasn't king."] 20:50:17 lowlycoder [n=x@unaffiliated/lowlycoder] has joined #scheme 20:51:29 jewel: how can it be done? 20:58:17 -!- joast [n=rick@76.178.184.231] has quit [Read error: 110 (Connection timed out)] 21:00:31 Lectus: man mzc 21:01:12 joast [n=rick@76.178.184.231] has joined #scheme 21:02:24 -!- hosh [n=hosh@c-71-199-176-82.hsd1.ga.comcast.net] has quit [Read error: 110 (Connection timed out)] 21:03:27 http://docs.plt-scheme.org/mzc/index.html 21:04:50 incubot: many zippy claws? 21:04:54 Why didn't all mammals develop vorpal claws millions of years ago? 21:05:43 incubot: jabberwocky jabberwocky jabberwocky jabberwocky jabberwocky jabberwocky jabberwocky! 21:05:43 -!- lowlycoder [n=x@unaffiliated/lowlycoder] has quit ["leaving"] 21:05:46 yeah, checked out jabberwocky once.. will look again 21:09:32 Lectus: The C compiler is not recommended -- in fact, it produces code that is slower than the built-in jitter. 21:15:00 redchrom [n=redchrom@93.185.183.27] has joined #scheme 21:16:54 ken-p [n=ken-p@84.92.70.37] has joined #scheme 21:16:55 native code is always faster than interpreted code, provided it's the right native code. Usually it's horribly inefficient, bulky and ungainly native code though, that just does the same thing the interpreter would have done, possibly even more slowly. 21:16:57 I'm talking to you, gcj. 21:17:22 -!- wingo [n=wingo@127.Red-79-151-219.dynamicIP.rima-tde.net] has quit [Read error: 113 (No route to host)] 21:17:41 synx: Well, that applies to cases where you have such a thing like "an interpreter". 21:19:14 bytecode interpreter, virtual machine, whatever you want to call it. 21:21:43 I bet it's possible for the interpreter to analyze the bytecode and create sequences of machine code instructions where there is an equivalence to the bytecode, hopefully inside tight loops and such. 21:21:44 But it still takes that extra time to analyze. 21:22:17 That's a common misconception. 21:22:51 It takes time to analyze, but good jits can generate code that is better because they have more information than static compilers. 21:24:40 -!- Edico [n=Edico@unaffiliated/edico] has quit ["Leaving"] 21:26:24 -!- bweaver [n=user@75-148-111-133-Chattanooga.hfc.comcastbusiness.net] has quit [Read error: 113 (No route to host)] 21:28:30 hosh [n=hosh@c-71-199-176-82.hsd1.ga.comcast.net] has joined #scheme 21:29:12 kilimanjaro [n=kilimanj@70.116.95.163] has joined #scheme 21:29:15 -!- repror___ [n=reprore@ntkngw261071.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Remote closed the connection] 21:29:44 -!- jewel [n=jewel@dsl-242-129-65.telkomadsl.co.za] has quit [Remote closed the connection] 21:29:48 -!- ikaros [n=ikaros@f050246097.adsl.alicedsl.de] has quit ["Leave the magic to Houdini"] 21:32:38 synx, the process you've described of analysing bytecode and creating sequences of machine code... that's usually called a JIT, sir. 21:33:43 synx, there are also some very interest papers on the topic that you may care to read. Andreas Gal(s?) in particular wrote a couple of papers about a very nifty technique called a tracing JIT which not only analyzes the static bytecode but also the runtime behaviour of that bytecode. 21:33:53 saccade_ [n=saccade@dhcp-18-188-74-28.dyn.mit.edu] has joined #scheme 21:34:20 As eli says, since the analysis can take advantage of program behaviour that may be true locally but false globally, the JIT can perform much more aggressive optimizations than can a static compiler 21:34:24 . 21:34:41 Yes, and it's slower than if you have the native code in the first place. Not appreciably though for most cases. 21:34:44 I wouldn't write a graphics card driver in java. 21:35:14 There was also a project from, I think, HP, called Dynamo, which did something similar: it virtualized the processor on which native code was running and JIT'd the bare machine code, and managed to achieve a very counterintuitive speedup, for similar reasons. 21:35:37 synx: "it's slower" is just wrong. 21:35:40 synx, I'm afraid you're just not right. 21:35:45 I suppose that's true. 21:35:45 ... 21:35:49 jinx, eli. 21:35:53 :) 21:36:20 Here, jussec, let me dig through my list of papers. 21:36:21 he's right in reality, just not in theory 21:36:37 synx: Funny that you mention a graphics driver -- since creating GPU code on the fly is a common jitting application that is way faster than any native compilation. 21:36:39 I still don't know why compilers don't produce self modifying machine code. Could optimize itself as the program changed state. 21:37:06 http://andreasgal.com/publications/ , http://portal.acm.org/ft_gateway.cfm?id=1134780&type=pdf&coll=&dl=ACM&CFID=15151515&CFTOKEN=6184618 21:37:08 -rudybot:#scheme- http://tinyurl.com/mxagfr 21:37:10 Adamant: He's right in the Java reality -- but that's unrelated to the general issue. 21:37:30 http://www.ics.uci.edu/%7Efranz/Site/pubs-pdf/ICS-TR-07-12.pdf 21:38:11 -!- bombshelter13_ [n=bombshel@toronto-gw.adsl.erx01.mtlcnds.ext.distributel.net] has quit [] 21:38:15 I realize the biggest slowdown is people writing bad code, regardless of the language. 21:38:32 eli: I haven't heard of that ever happening... but I'm kind of out of the loop. What do you mean by "aggressively optimizing?" 21:38:53 Holy smokes, this one is old, but here you go anyhow: http://arstechnica.com/reviews/1q00/dynamo/dynamo-1.html 21:39:04 I'm just thinking for things like block copies, just a bunch of mov statements. 21:39:16 Any time you have something writing to the disk, that'll take up way more time than any that would be lost figuring out what native code to use. 21:39:39 gnomon: I think that dynamo was one of the first. 21:39:46 -!- gfb [i=4c455486@gateway/web/freenode/x-918ac3089d88d1df] has quit [Ping timeout: 180 seconds] 21:40:01 synx: there are several things that a dynamic jitter can do better. 21:40:33 synx: One of the obvious things is optimizing branches based on how the code actually runs. 21:40:49 And here's a good set of posts by someone who's writing graphics infrastructure that is based around using LLVM to dynamically optimize shader fragment programs: http://zrusin.blogspot.com/search/label/LLVM 21:40:58 -!- langmartin [n=user@exeuntcha.tva.gov] has quit ["ERC Version 5.3 (IRC client for Emacs)"] 21:41:07 Like what, eli? 21:41:59 gnomon: considering it was comparing single instruction interpretation, to multiple instruction interpretation, I don't think that Code Morphing thing really applies to purely native code. 21:42:03 synx: Another is deciding on inlining based on how frequently a function is called -- a static compiler needs to implement some heuristics to guess when it is good to inline a function, and a jitter can just observe the current costs and re-jit a function differently at runtime. 21:43:02 synx, you see that link I posted above? The long one that goes to portal.acm.org? It's a short paper, and it's very, very applicable to what you're talking about. It actually tackles the objections you've raised almost in the order that you raised them. 21:43:17 eli: I don't think you can predict reliably which branch is going to be taken. You mean like detecting when say a counter passes a maximum value, and replacing the condition checking with a simple jump instruction? 21:43:31 synx, you've just argued eli's point. 21:43:44 jewel [n=jewel@dsl-242-129-65.telkomadsl.co.za] has joined #scheme 21:43:54 A JIT doesn't *have* to predict how a loop operates: it can just observe and measure, and change the fast path when the program behaviour changes. 21:44:33 synx: Sure -- the nice thing about conditionals is that they're *very* predictable. A double-nested loop over 1..1000 has almost all of its executions follow the same path. 21:44:44 -!- puchacz [n=puchacz@87-194-5-99.bethere.co.uk] has quit [Remote closed the connection] 21:44:50 That'd run into problems if the counter was returned to a lower state... 21:45:17 synx: Yet another one is similar to runtime code generation -- think about taking (lambda (x y) (foo (* z 3) x y)), and propagating the constant after inlining the foo body -- that's something that a static compiler can never do. 21:45:33 gnomon: you assume I'm trying to prove myself right. 21:46:20 I'm all in support of self modifying code. It's a great way to optimize on demand. 21:46:21 Is that what you say JIT brings, that native code compilation cannot? 21:46:25 synx, no, I'm assuming that you're interested in the topic and would like to learn more about it, so I'm trying to direct you to some very helpful resources I ran across while I was pondering the same ideas. 21:46:31 synx: And all of these things are very well documented, so just read gnomon's links to get a better picture. (Arguing against branch prediction is not something that you should do without knowing how it's done.) 21:47:34 I'd say it's more a limit of what compilers already exist than of native code itself. 21:48:01 It's a limit of what information can possibly be available at compile time versus run time, synx. 21:48:27 Do you agree that profile-driven optimization is a good idea? If so, a good JIT is just that very tactic advanced to the Nth degree. 21:49:46 synx, there's also some really interesting discussion down the thread that starts at http://news.gmane.org/find-root.php?message_id=%3c200905302229.31837.bobby%40sharedrealm.com%3e . Pay special attention to the posts from Mike Pall: even if their content weren't convincing enough on their own, it might help to know that he's the guy writing the JIT. 21:49:48 -rudybot:#scheme- http://tinyurl.com/mkunqy 21:50:00 But for instance if you used that 1..1000 loop, and you replaced it with an efficient unconditional loop for the first 1000, when would you check to see if it had passed 1000? 21:50:14 synx: what's wrong with this pseudo machine code: LOOP: x=0; foo(x); x=x+1; if x A smart JIT would do that probably on the fourth or fifth pass through the loop. 21:50:43 You'd have to check every iteration, which is what the "inefficient" instructions do. 21:50:45 gnomon: Is there a reason that native code cannot use the information available at run time? 21:50:49 yeah 1000 = 5*200 so you can unroll the loop 1/5th 21:50:55 for example 21:51:18 synx, there's no reason it can't, but you're describing $SOME_COOL_TECHNIQUE, and I'm telling you that $SOME_COOL_TECHNIQUE == "JIT" :) 21:52:14 hmm, loop unrolling... 21:52:23 -!- borism [n=boris@195-50-201-218-dsl.krw.estpak.ee] has quit [Client Quit] 21:52:27 (in particular, in the thread above, you might want to check out http://article.gmane.org/gmane.comp.lang.lua.general/55201 - it includes very convincing benchmarks against raw C) 21:52:30 gnomon: JIT only refers to using an abstract non-native bytecode, not translating native code to other native code. It's JIT compiling, not JIT assembling. 21:53:07 I mean JIT stands for "just in time" so I guess it could be both. But I've only heard of it used in the context of a virtual machine before. 21:53:07 Who says it does? I believe the aforementioned Dynamo project demonstrated quite neatly that there's no reason that recompiling native code can't produce speed gains. 21:53:36 Well C is a very limited and restrictive language. I can understand why it would be slow as beans. 21:54:03 The Dynamo project didn't recompile native code. It took non-native x86 code, and created native GPU code from it. 21:54:25 Qemu does something similar, which is why it includes a very good optimizing compiler and several native codegens; this infrastructure is at the core of Rob Landley's newly launched QCC project, which is aimed at grafting a simple C front end atop qemu's (wait for it) JITing back-end. 21:55:35 Wait, what? synx, when HP's Dynamo project was created, the term "GPU" didn't meaningfully exist. Did you read the article? 21:55:57 It dynamically recompiled PA-8000 machine code to PA-8000 machine code. 21:56:33 In particular: "Dynamo is an odd beast. It is, in essence, an interpreter for HP's PA-8000 instruction set that *itself* runs on a PA-8000 processor. That's right -- it interprets programs that could just as easily be executed natively on the same hardware. For a research prototype, this isn't as strange as it seems. The Dynamo project was started to investigate issues in what was seen as an increasingly important ar 21:56:34 Oh I must have misread gnomon 21:56:35 So it's not a JIT compiler. 21:56:36 I think we're all in agreement here. 21:56:49 !? 21:57:06 Dynamo == JIT. 21:57:45 (also, the full paper about it: http://www.hpl.hp.com/techreports/1999/HPL-1999-78.html ) 21:57:50 -!- dudleyf [n=dudleyf@65.243.31.107] has quit [] 21:58:02 It's not translating any language though. It's just a self modifying program. 21:58:35 It's an interpreter that dynamically compiles source PA-8000 machine code to target PA-8000 machine code, optimizing as it goes. 21:59:02 It doesn't matter that the source language is PA-8000 machine code, or Java, or Plankalkull: it's compiling dynmically at runtime and caching the results. It's a JIT. 22:00:09 -!- joast [n=rick@76.178.184.231] has quit [Connection timed out] 22:00:31 Define compiling. 22:00:45 Translating from a source language to a target language. 22:01:00 Define JIT. 22:01:14 thehcdreamer [n=thehcdre@93.37.245.15] has joined #scheme 22:01:17 -!- jewel [n=jewel@dsl-242-129-65.telkomadsl.co.za] has quit ["Leaving"] 22:01:17 I mean Wiki says... 22:01:18 "A compiler is a computer program (or set of programs) that transforms source code written in a computer language (the source language) into another computer language (the target language, often having a binary form known as object code)." 22:01:49 Ok. Why can't the source code be the output produced by some other compiler? 22:01:57 Yes, not just using the same language. 22:01:58 JIT is an acronym for "just in time" 22:02:18 joast [n=rick@76.178.184.231] has joined #scheme 22:02:29 That's an expansion of the acronym, not a definition. 22:03:11 You can't translate Japanese to Japanese. It's just I dunno, optimization at that point, not compilation. 22:03:22 That's correct. They're the same thing. 22:03:34 There are plenty of source-to-source Scheme optimizers, for example. 22:03:56 In fact, there are several layers of source-to-source compilation in the Ikarus scheme system. Its optimization infrastructure is built around that concept. 22:04:05 eli: A JIT compiler can in theory create better code than a static compiler, but is this code so much better that the cost of analyzing and creating it is less than the savings in execution time of the program? Additionally, while I know this is all theoretically possible, does the PLT compiler currently exhibit such speed improvements over existing Scheme static compilers that are known to be generally fast? 22:04:37 So transforming PA-8000 to PA-8000 is not compiling either. Therefore it's not a JIT compiler. 22:04:43 synx: If I have x86 machine code and translate it to ARM machine code, is this compilation? 22:05:29 synx, are you asserting that Dynamo would fit your definition of "compiler" if it compiled X to PA-8000 machine code, for any value of X that does not equal "PA-8000 machine code"? 22:06:08 Well, I'd call it emulation, but I guess? I was under the impression that compilation and translation were synonymous. 22:06:48 Yes that's pretty much what I'm saying. 22:06:55 If you believed that compilation and translation were synonymous you would not have said that Dynamo is not a JIT, unless there's something in there that either you or I have missed. 22:07:02 synx: So, is it compilation to translate informal American English into Standard American English? 22:09:07 (synx, I'm arguing this point so hard because I used to be in the same mindset you're currently in, and it took me an embarrassing year and a half to convince myself otherwise) 22:09:20 Spoken language has a horrifically confused history that I would prefer not to delve too far into. 22:09:21 -!- thehcdreamer [n=thehcdre@93.37.245.15] has quit [] 22:09:56 I don't think they would call it translation though, arcfide. Correction maybe. :> 22:11:35 gnomon: I think you misread the mindset I'm in. I don't doubt the ability of run-time native code production. 22:11:40 So, would you accept the term: ameliorater? 22:12:00 arcfide, heh, I see what you did there ;) 22:12:21 All I'm claiming is if you can do X in non-native bytecode, and you can do X in native instructions, then the latter will be faster. It's a silly thing to argue about really. 22:12:32 CSdread__ [n=danielf@c-76-113-2-83.hsd1.nm.comcast.net] has joined #scheme 22:12:54 synx: But that's not true, unless you qualify your statement significantly. 22:12:57 But it's *not*. It seems like it should be silly, but - surprisingly! - doing it with an extra emulation layer can actually make it *faster*. 22:13:07 That was the big surprise that came out of the Dynamo project. 22:13:18 hbbnj [n=irc@s83-191-238-2.cust.tele2.se] has joined #scheme 22:13:45 My name is not Amelia... 22:14:18 (also, keep in mind that on modern processors, encoding to some smaller machine code representation that is otherwise more or less equivalent can produce enormous speed gains simply because the resulting code will better use the cache system; see ARM's Thumb instruction set for an example of this) 22:14:28 Doing an extra emulation layer in native instructions is still faster. :> 22:14:40 Faster than what? 22:16:05 Faster than doing an extra emulation layer in bytecode. 22:16:19 Assuming the two programs are equivalent. 22:17:29 synx: Define equivalence. 22:19:01 Not a trivial task! 22:19:20 Well, at least not according to some random dude named AlanT. I don't know, he was a bit of a troll. 22:19:38 I can construct a program X in bytecode that is observationally equivalent to program X' in native code with respect to return value, O(1) use of space, and output on SI/O, where X runs arbitrarily faster than X'. 22:19:40 Like how native code that calculated the 2000th prime number would probably be slower than a bytecode version of 1+1. 22:20:10 arcfide: Yes -- since a JIT can always start with the same analysis that a static compiler does. Re the second question -- it performs better than the C compiler, but comparing it to other compilers is subject to a whole bunch of side issues (and flamewars). 22:20:19 -!- hbbnj [n=irc@s83-191-238-2.cust.tele2.se] has quit [Read error: 104 (Connection reset by peer)] 22:21:15 -!- moghar [n=user@unaffiliated/moghar] has left #scheme 22:22:23 eli: If I understand you correctly, in order for the execution of a program to run faster with a JIT than a natively compiled equivalent (here I assume that the JIT must start with the source code, and not some statically compiled version), it must further improve the code beyond what the static compiler does, otherwise it will run in the time it takes for the static compiler to run and the time for the native code to run, roug 22:23:37 eli: I know that it is theoretically possible to improve the code enough to result in a speed up, but I'm asking whether this has been achieved yet with PLT's compiler, which, apparently, it has not quite done conclusively. 22:24:50 JITs rarely (probably never) begin from source. Even if they would, then "obviously" compile+run is faster than some "pure interpreter". ("obviously" modulo things like Stalin, and "pure interpreter" is not something that describes any language that I know about.) 22:25:21 PLT needs a lot of work yet. It still remains the only program on my computer that can grind everything to a halt at the flip of a hat. 22:25:22 More in memory consumption than speed though, I'd say... 22:26:01 eli, I think some earlier versions of bash might fit your definition of "pure interpreter". 22:26:09 Certainly DOS batch files do. 22:26:14 (or should!) 22:26:27 gnomon: Oh, yes, I forgot about those stupid things... 22:26:44 Useful pedagogical examples, though! 22:27:23 I remember that I once sped up a menu system I wrote as a DOS batch file by 20 times, simply by loading smartdrv.exe. It was hitting the disk for every single line of code, even the ones in loops. 22:27:28 synx: In all cases that you complained about "PLT grinding your computer to a halt", the issues were implementation- and language-independent. (aka, it was your code.) 22:27:53 -!- CSdread_ [n=danielf@c-68-35-129-24.hsd1.nm.comcast.net] has quit [Read error: 110 (Connection timed out)] 22:28:20 gnomon: Ugh, terms like that ("smartdrv.exe") are always successful in making me twitch. 22:28:29 Well it was my code, but also the memory consumption of PLT. I wrote the same sort of thing in another language and had no problems. 22:28:37 Hee hee hee! 22:29:16 -!- CSdread__ is now known as CSdread_ 22:29:17 My last blooper was a CGI program. The web server spawned 5 copies of it, to handle 5 requests, and the script was hanging. 22:30:30 Wouldn't normally be a problem, but for some reason plt was allocating 230 megabytes of memory for each process, for a total of 1.6 gigabytes. Everything just stopped. 22:31:24 A-a-a-h. 22:31:30 This is a problem near and dear to my heart. 22:31:39 synx: My computer was running three *heavy* mred-based servers throughout the last academic year, with around 2-3 copies of drscheme, and another heavy mzscheme process. I rebooted it *once* in all this time, to upgrade the OS and kernel. 22:32:19 If I may lapse into my professional capacity for a moment, here, your *service* was deficient because of a misbehaviour in your code and its supporting environment, not because PLT was misbehaving. PLT was doing exactly what your code was telling it to do. 22:33:19 synx: The heavy mred servers were submission servers -- running random student code in Scheme, in profj, and in my zoo of custom languages. The heavy mzscheme process is my web server. Also, every day there is a nightly build which is very heavy in itself. 22:33:23 synx: Why a cgi script that *you* wrote claims 230mb is not a question for me to answer. 22:33:47 That may mean that PLT may indeed be a bad fit for a one-process-per-webserver-thread service, but that's a design issue in the service, not a code problem in PLT. 22:34:04 minion: advice for synx 22:34:04 synx: #11919: No. You must believe the ERROR MESSAGE. You MUST believe the error message. 22:34:49 Well, I really like Petite for CGI, but no Scheme worth its salt is going to stop you from freezing your server through excessive and blunt programming techniques, though I'm not familiar with the techniques or code in this discussion. 22:34:59 *arcfide* goes to do something AFC. 22:36:50 I wasn't making a giant endless list. I was just outputting some text, based on arguments I parsed with regular expressions. 22:37:55 This isn't directly applicable to the argument at hand, but it's hilarious, so: http://regex.info/blog/2006-09-15/247 22:40:15 Dark-Star [n=michael@p57B5422E.dip.t-dialin.net] has joined #scheme 22:41:31 synx: regexps are *easy* to get wrong. Use the wrong regexp on an input port and you make it read a whole file into memory. Use another wrong funciton, and you duplicate that memory. etc. 22:41:36 -!- hkBst [n=hkBst@gentoo/developer/hkbst] has quit [Read error: 104 (Connection reset by peer)] 22:42:52 Follow that road long enough and you'll find yourself snorting PCP and being played right over the edge of a cliff to accompaniment of Hall and Oates and the keyboard cat. 22:43:42 -!- mmc [n=mima@cs162149.pp.htv.fi] has quit [Read error: 110 (Connection timed out)] 22:44:18 mmc [n=mima@cs162149.pp.htv.fi] has joined #scheme 22:44:57 Hah, no it was just splitting on &. I only mention regexps because they'd have to get loaded. It wasn't a dumb pattern or anything, nor was it an input port. 22:45:28 Now I'm regretting deleting the script that did that, meh. 22:48:24 "it was just splitting on &" is exactly what I said in "duplicating that memory". 22:48:48 -!- annodomini [n=lambda@wikipedia/lambda] has quit [Read error: 110 (Connection timed out)] 22:50:13 Well I could have used some kind of tokenizer, but it was just like 20 bytes at most. 22:50:49 SRFI-13 is your friend, there. 22:51:05 http://srfi.schemers.org/srfi-13/srfi-13.html#string-tokenize 22:52:05 Look forget about my hamhanded use of regular expressions. I know about string-tokenize. It still doesn't put aside that plt makes for terrible CGI scripts. 22:52:59 synx: Just using the `-positions' variant avoids the duplication. 22:53:00 gnomon: No, string tokenize has the same problem. 22:53:24 synx: You still did not demonstrate anything other than the terrible-ness of your own code. 22:54:00 Or that seemingly simple operations use deceptive amounts of memory. 22:54:36 I wish I could demonstrate it, but I deleted the script days ago, so all I'm doing is complaining. 22:55:12 "simple operations use deceptive amounts of memory" is true in *many* contexts. 22:55:20 (define (rcons l x) (append l (list x))) 22:55:28 I'm sure if I made a script now it'd use 3 bytes of memory just to spite me. 22:55:45 -!- saccade_ [n=saccade@dhcp-18-188-74-28.dyn.mit.edu] has quit ["This computer has gone to sleep"] 22:56:07 (the text of the implementation of string-tokenize, from the SRFI-13 reference implementation: curl -sr 61778-62743 http://srfi.schemers.org/srfi-13/srfi-13.scm ) 22:56:57 That's not deceptive though. You beat it into my head quite well that append is a O(n) operation. 22:56:58 I mean like (display (list 3)) taking 40 megabytes or something. 22:57:44 gnomon: My point was that (regexp-split #rx"&" str) -- as well as the `string-tokenize' version -- duplicates the whole string, so if you use it over a big string, you can get fun. 22:58:09 synx: *if* there was an issue with something like *that*, then it's a bug. 22:59:11 eli, you're quite right, and my reason for believing otherwise was mistaken: I thought that string-tokenize did something smart like just store a list of offset positions internally. 22:59:48 gnomon: Yeah, that's why I refered to PLT's `-position' variants. 23:00:12 -!- attila_lendvai [n=ati@catv-89-132-189-132.catv.broadband.hu] has quit [Read error: 113 (No route to host)] 23:00:25 eli, which were the things that I was actually thinking about. Thanks for that :) 23:01:03 I dunno substring itself shouldn't actually duplicate the string I'd say, unless strings get mutated. 23:01:25 gnomon: The first thing that I referred to is a very cute feature of PLT that Matthew implemented ages ago and that I always loved -- the ability to use regexp functions over a port. 23:01:30 Strings are allowed to be mutated, unfortunately - see STRING-SET!. 23:01:43 I've written C "string" hacks all the time where all they did was copy a pointer offset and a length. 23:01:46 eli, oh? I'll have to look at that more closely! 23:01:50 gnomon: But things *can* get tricky there -- use the wrong regexp, and the whole files ends up in your RAM. 23:01:57 Eek. 23:01:59 ...to get a substring. 23:02:11 bweaver [n=user@68.60.0.190] has joined #scheme 23:02:29 rudybot: eval (regexp-split #rx" " (open-input-string "foo bar baz")) 23:02:29 eli: ; Value: (#"foo" #"bar" #"baz") 23:02:41 well mutated or not, I'd like to have a non-copying substring. 23:02:54 attila_lendvai [n=ati@catv-89-132-189-132.catv.broadband.hu] has joined #scheme 23:02:55 synx, in order to ensure that your substring didn't get mutated out from under you, you'd have to have a smart runtime system with copy-on-write detection, and then we're back to the JIT argument. 23:03:27 (well, not entirely, but we're at least heading back in that direction) 23:03:45 synx: Another problem with that is that with a precise collector, the ofsetted string would keep a reference to the whole string. 23:03:59 Oooh, that's a very good point. 23:04:17 Oh it could get mutated out from under me. What I think would be most tricky is garbage collection. 23:04:32 ... and this means that you can just as well implement it yourself as a structure holding the original string and a start/end indexes. 23:04:45 Or a list of such indices! 23:04:51 Yeah. 23:05:30 That's true enough. 23:05:51 synx: If you face that problem (that the new string keeps a referene to the old one), then the implementation is not tricky at all, and it basically looks the same as it would inside Scheme. 23:05:53 And then to display those structures, you would need to invoke substring anyway. 23:06:29 synx, or you could look into PLT's non-copying string manipulation library! 23:06:43 synx: Not in PLT at least -- functions like `write-string' accept a start/end argument (for this reason, among others). 23:06:48 Apparently it's rife with opportunities for productive code theft. 23:07:04 Actually I think plt's structs can have a custom displayer attribute... 23:08:14 Ooh okay. 23:11:56 -!- Dark-Star [n=michael@p57B5422E.dip.t-dialin.net] has quit [Read error: 54 (Connection reset by peer)] 23:15:45 -!- Lectus [n=Frederic@189.105.10.45] has quit [Connection reset by peer] 23:17:10 zbigniew, aarrgh! I blame C's brain-damage for creeping upon my own brain while I was writing that message. 23:30:57 -!- mmc [n=mima@cs162149.pp.htv.fi] has quit [Read error: 110 (Connection timed out)] 23:31:56 Lectus [n=Frederic@189.105.10.45] has joined #scheme 23:32:55 someone needs to blanket the planet with angry flower fliers, because no one seems to get it. biodegradable, of course 23:35:21 -!- CSdread_ [n=danielf@c-76-113-2-83.hsd1.nm.comcast.net] has quit ["Ajax isnt that something you clean the bathroom with?"] 23:47:31 -!- ken-p [n=ken-p@84.92.70.37] has quit [Connection timed out] 23:51:13 Riastradh: its okay. 23:51:26 incubot: pun intended? 23:51:29 Anyways, `Continuation Passing Style' helps in understanding recursion better, and perhaps that is the purpose intended by the book. 23:51:46 -!- blackened` [n=blackene@ip-89-102-28-224.karneval.cz] has quit [] 23:52:08 blackened` [n=blackene@ip-89-102-28-224.karneval.cz] has joined #scheme 23:53:04 yeah, I think C caused me some brain damage as well 23:54:43 raikov [n=igr@60.32.127.43] has joined #scheme 23:56:32 incubot: it and its it's is panindented? 23:56:56 -!- sreeram [n=sreeram@122.174.68.30] has quit [] 23:58:07 incubot: pan-in-dentator?