00:05:10 -!- seangrove [~user@70-36-236-168.dsl.static.sonic.net] has quit [Remote host closed the connection] 00:08:30 fod [~fod@92.251.255.7.threembb.ie] has joined #scheme 00:21:50 seangrove [~user@70-36-236-168.dsl.static.sonic.net] has joined #scheme 00:26:22 josephholsten [~josephhol@adsl-38-12-46.tulsaconnect.com] has joined #scheme 00:37:08 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Ping timeout: 265 seconds] 00:55:16 -!- dfkjjkfd [~paulh@36-12-ftth.onsnetstudenten.nl] has quit [Quit: Lost terminal] 01:15:38 -!- nego [~nego@c-76-16-30-244.hsd1.il.comcast.net] has quit [Ping timeout: 276 seconds] 01:15:45 -!- githogori [~githogori@249.sub-75-208-48.myvzw.com] has quit [Remote host closed the connection] 01:17:50 araujo [~araujo@gentoo/developer/araujo] has joined #scheme 01:20:21 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Max SendQ exceeded] 01:20:45 araujo [~araujo@gentoo/developer/araujo] has joined #scheme 01:23:16 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Max SendQ exceeded] 01:23:39 araujo [~araujo@gentoo/developer/araujo] has joined #scheme 01:30:08 jcowan [~John@cpe-98-14-172-204.nyc.res.rr.com] has joined #scheme 01:34:10 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Ping timeout: 265 seconds] 01:34:38 -!- bgs100 [~ian@unaffiliated/bgs100] has quit [Quit: Leaving] 01:42:53 -!- saint_cypher [~rjspotter@70-36-245-104.dsl.static.sonic.net] has quit [Quit: Leaving.] 01:49:50 -!- seangrove [~user@70-36-236-168.dsl.static.sonic.net] has quit [Ping timeout: 272 seconds] 01:50:52 pinchyfingers [~user@pool-98-114-40-249.phlapa.fios.verizon.net] has joined #scheme 01:53:46 *jcowan* unvanishes and that. 02:00:25 hi jcowan :D 02:00:39 Hey ho. 02:05:10 jcowan: there's still something magical/metaphysical about this notion of "unvanishing" that i can't quite put my finger on. i once thought it was related to the ancient greek notion of aletheia ("unforgetting") as truth. 02:05:30 Quite so. 02:05:43 I go from the state of being vanished to the state of being apparent; hence, I unvanish. 02:05:54 "Antivanish" would also be a suitable term. 02:05:56 maybe it's the characterization of absence as a positive, essential state; it's negation as something tangible but derivative. 02:06:01 jcowan: interesting 02:06:11 s/it's/its/ 02:06:30 Oh. One of the rare cases in which both "its" and "it's" make sense. 02:07:02 dnm [~dnm@c-68-34-57-154.hsd1.va.comcast.net] has joined #scheme 02:09:13 bizarre. 02:09:21 elly: how's cambridge treating you, btw? 02:09:29 excellent :) 02:09:43 sorry we never got coffee; i had to head west unexpectedly. 02:09:53 i trust you're having a good time, though ;) 02:10:47 wait, you headed west? 02:10:49 dammit 02:10:50 where'd you go? 02:11:47 elly: i got an offer for a startup in LA i couldn't pass up; interviewed at google santa monica, though, a week or so ago. maybe they'll let me transfer back east ;) 02:12:06 oh, nice! 02:12:15 well, good luck 02:12:20 do tell me if you become part of the borg 02:12:47 thanks, elly; oh, you mean there isn't some sort of spontaneous borg-consciousness that detects my absorption ;) 02:13:01 but, seriously; i'll drop you a line when i'm back east. 02:13:02 I wouldn't know about that 02:13:04 okay :) 02:13:17 if MS is the Borg, is Google The Eye Of Sauron? 02:13:22 (ducks) 02:13:22 saccade_ [~saccade@209-6-54-113.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has joined #scheme 02:13:31 microsoft isn't the borg :P 02:13:37 google is canonically the Rainbow Borg 02:13:47 ah 02:13:56 microsoft was the Evil Empire 02:17:39 MS is now just the tragic red-headed stepchild, isn't it; or the middle-aged bully, past its prime? 02:17:57 probably that latter one 02:18:31 The funny thing is that most people that I know who work there are fine technically and upstanding ethically. 02:18:47 maybe it is a case study in emergent phenomena, then. 02:19:00 Maybe, maybe not. It may just be top-down effects. 02:19:05 good point 02:19:38 elly: microsoft was the borg, IBM was the evil empire 02:19:45 so what's google? 02:19:48 haven't heard of this "rainbow borg" thing 02:19:51 oh 02:19:53 Eye Of Sauron 02:19:54 it's after our logo colors 02:19:59 yeah, I got that 02:20:17 (and also, I like to think, our excellent LGBT policies) 02:20:44 haven't figured out a good analogy for Google yet. they're the type of evil you get from a bunch of people who are convinced they aren't evil 02:20:52 Google is The Movement 02:21:01 Crusade? Jihad? 02:21:10 I triggered a centithread by saying that working for Google is a job. 02:21:19 Maybe they're the Parliament of the Firefly/Serenity universe. 02:21:21 shocking. 02:21:52 chandler: it's... sort of like a church militant :P 02:22:30 'knights templar'? 02:22:51 There were people who suggested I resign. They may have been right. 02:23:41 they were right, if your objective is to have a insular unrealistically positive culture. 02:24:08 I dunno 02:24:11 startups thrive on unrealistically positive 02:24:14 "Right" in the sense that I was seriously mismatched with the culture. 02:24:21 I maintain a reasonable work-life balance (0830 -> 1800 daily) and that seems to be just fine 02:24:47 Everything seems just fine until you find out it isn't. 02:24:52 it often depends on what group you are in, anyway 02:25:12 Those hours would have been serious crunch time for some at my former employer. 02:26:03 the people on my team all work less hours than that 02:26:08 the average is around 8.5 02:26:13 anyway. people don't go for unrealistically positive when you start knowing more about them than they do themselves. 02:26:22 *do about themselves. 02:26:44 I don't follow that, Adamant. 02:27:14 jcowan: Google has an insane amount of information about basically everyone on the planet connected to the Net 02:27:30 and therefore...? 02:27:31 I overstate things, but not by much 02:27:49 if information is power, and the Chinese certainly think so 02:27:58 Oh, I thought by "unrealistically positive" you meant "about the organization" 02:28:03 (from within, that is) 02:28:07 and power corrupts... 02:28:26 I really hope not 02:28:33 "Tends to corrupt". 02:28:48 I think the Chinese have pointed out that it doesn't really matter in the end. 02:28:51 Adamant: what's your gmail? ;) 02:28:57 that much data is a target 02:29:00 Adamant: any buddhist will tell you that 02:29:06 FurnaceBoy: I know, right 02:29:23 actually I've switched to DuckDuckGo 02:29:28 for search engine 02:29:36 Adamant: and what do you use for email? :) 02:29:50 FurnaceBoy: I was acknowledging your point 02:29:54 :) 02:30:01 yes, in the negative space :) 02:30:24 I'm probably going to get a pay up front email account. 02:30:41 Adamant: they only know what I ask them! 02:31:07 pjb: what don't you ask them? :P 02:31:15 Almost everything. 02:31:36 Adamant: don't pay for an email account. Set it up on your own computer! 02:31:50 *elly* runs her own mail server 02:31:55 *FurnaceBoy* too 02:31:56 pjb: I have no interest in running a mail server :P 02:31:59 *Azuvix* too 02:32:02 *chandler* too 02:32:02 Adamant: you should. 02:32:05 it's /really/ easy 02:32:08 pjb: I can 02:32:10 Yup. 02:32:13 Adamant: running your mail server ensure that you don't censor yourself. 02:32:14 It's /really/ annoying. 02:32:14 that doesn't mean I want to 02:32:25 I'd recommend against it unless you like pain. And spam. And painful spam. 02:32:28 chandler: it's a one time setup. It runs alone for years. 02:32:43 chandler has hit the reason why people use gmail 02:32:50 odd, i don't get pain or much spam which is weird since my address has been on usenet for decades and all over my source trees 02:32:53 Particularly if you get it right and use something stable. 02:32:59 the single biggest one, anyway 02:33:14 seangrove [~user@c-71-198-44-87.hsd1.ca.comcast.net] has joined #scheme 02:33:18 not that it's not a nice piece of software. 02:33:40 also, my reference to the Chinese was the Operation Aurora stuff 02:33:43 pjb: It has been running for years, but it was rather difficult to set up (and wound up being complicated by a kernel bug in JFS that caused Dovecot and some other software to miss new mail in the Maildir). I still haven't found an anti-spam solution I can live with. 02:34:01 chandler: Mail.app ;-) 02:34:17 Putting anti-spam in the client is not a workable solution for me. 02:34:20 chandler: the good ones require enough effort that pay has to be involved. 02:34:42 araujo [~araujo@gentoo/developer/araujo] has joined #scheme 02:34:48 On the plus side, though, if you get a fully-functioning email server, a web server isn't too far off. 02:34:50 That, and greylisting which is easy to configure on your mail server. 02:35:16 Greylisting is the solution I can tolerate, except when it loses mail from poorly-configured relays. 02:35:59 It drives me to gmail for some things (any situation where I don't want to wait for the bounce delay). 02:36:56 I use gmail extensively for work and it does a fine job 02:37:13 Yes, it does. 02:37:33 it's good software, no doubt. 02:37:45 But it's not the Internet. gmail = bbs. 02:37:54 That's overstating it. 02:38:01 if Google had a pay for no data collection option, I'd stick with it. 02:38:20 How could they not collect data about mail that's hosted on their servers? 02:38:25 well, no collection/ads 02:38:39 chandler: I mean the data mining of emails to serve ads 02:39:06 It really sound crazy to go thru google for email! 02:39:26 Or thru microsoft or any big ISP... 02:39:29 Adamant: That you can do. Just pay for Google Apps. 02:39:51 *pjb* going back to sleep. 02:40:50 aidalgol [~user@114-134-7-235.rurallink.co.nz] has joined #scheme 02:41:30 pjb: Ultimately, my mail "goes through" some big ISP unless I'm using client-side encryption (GPG and the like). 02:41:36 There's no way around that. 02:41:59 *FurnaceBoy* vpn's to colo 02:42:07 *FurnaceBoy* trusts leaf networks least of all 02:42:48 That doesn't add anything (in the realm of email) beyond the SSL connection I use to my IMAP server and SMTP relay. 02:42:52 right. 02:43:11 Ultimately, my server is hosted *somewhere*, and the mail I receive or send comes from or goes to somewhere else. 02:43:16 of course 02:43:30 but i don't recommending trusting leaf networks. especially a traveller. 02:43:54 *jcowan* doesn't think that ceasing to use Google makes the slightest difference, any more than starting to conceal my email address would. 02:43:55 I distrust Google, but relying on someone else for email is a fact of life, even if it's just whoever provides connectivity to your colo. 02:44:02 -!- Azuvix [~Azuvix@174-19-234-140.bois.qwest.net] has quit [Quit: I bless your computer, my child.] 02:44:18 chandler: my isp doesn't STORE my mail. that's the nsa's job. ;_) 02:44:30 FurnaceBoy: How do you know? 02:44:34 *FurnaceBoy* sighs 02:44:42 jcowan: my colo provider? 02:44:48 Yes. Unless you own it. 02:44:50 jcowan: I'll ask them and let you know 02:44:52 *FurnaceBoy* sighs 02:45:02 -!- wingo [~wingo@obfw.oblong.net] has quit [Ping timeout: 264 seconds] 02:45:04 Business operates on trust almost all the time. 02:45:06 luz [~davids@201.17.88.176] has joined #scheme 02:45:10 jcowan: that's my line 02:45:34 jcowan: bottom line, i trust my colo provider more than gmail not to store my mail. 02:45:43 It's just like the notion of "unlogged channel" on IRC. Meaningless. 02:45:45 jcowan: I think there are some advantages to staying out of an emerging monoculture. 02:45:58 'just like' 02:46:06 jcowan: I *know* somebody's logging it. 02:46:14 jcowan: but this is one choice I do have. 02:46:16 jcowan: That's not meaningless if the set of participants is controlled somehow. 02:46:30 jcowan: further, see above re: untrusted edge networks. 02:47:10 jcowan: which is really why i like vpn to, ultimately, a provider i cannot wholly trust (duh) 02:47:24 *elly* sshes to a dedicated machine somewhere to read mail 02:47:28 i have more to fear from edge networks than that provider. especially where i have travelled. 02:47:53 FurnaceBoy: What do you use for VPN? 02:47:56 openvpn 02:48:20 Ah. I've never made DNS work properly with that (OS X client). Haven't been able to figure out why, and gave up after a while. 02:48:34 *FurnaceBoy* uses it on os x for many years 02:48:58 So, pick one: 1) character ports are built on binary ports; 2) binary ports are separate from character ports; 3) all binary ports are character ports. 02:49:18 Describe option 1 further? 02:49:38 R6RS style: you have a binary port, you apply a codec to it to get a character port. 02:49:58 -!- ASau [~user@83.69.227.32] has quit [Read error: Connection reset by peer] 02:50:43 Oh, OK. I'm not convinced there's any advantage to option number 2, and it's less flexible. 02:52:15 What is the use case for this flexibility? I've found two: encoding detection in character sources and reading/writing strings embedded in binary formats. 02:53:20 But both have synchronization problems, given that both kinds of ports need buffering. 02:54:05 toast` [~toast`@c-71-231-102-232.hsd1.wa.comcast.net] has joined #scheme 02:54:06 Option 3 is what Gambit does, and it's fine provided (a) you don't mind the overhead and (b) you are never in an environment in which only binary ports are useful. 02:54:25 Can you elaborate a bit on option 3? 02:54:37 The cases I had in mind for the flexibility were as you described. 02:54:53 In Gambit, file/device/network ports are a subtype of binary ports, which are a subtype of character ports, which are a subtype of object ports. 02:55:31 A bytevector port is a binary port but not a file port. A string port is a character port but not a binary port. A general vector port is an object port but not a character port. 02:55:47 Likewise a directory port. 02:56:01 That hierarchy does not make sense to me. Character ports by nature should not be a subtype of binary ports, since they restrict the set of allowable input or output bytes. 02:56:18 Er, turn that around. 02:56:35 I don't understand it even when reversed. 02:56:38 Character ports *should* be a subtype of binary ports, if there is any subtype relation between the two. 02:56:58 A string port is not a binary port, unless by some reverse codec. 02:57:01 kniu [~kniu@CMU-311358.WV.CC.CMU.EDU] has joined #scheme 02:58:05 And if every binary port has an associated codec as of when it was opened, then it can work as a character port too. That's subtyping, but at a price. 02:59:11 A string output port has a restricted output domain when compared to a binary port, so if these types are not disjoint the string port should be a subtype of the binary port. 03:00:06 Er, make that "character output port". 03:00:27 And if character ports and binary ports are to have any sort of subtype relationship, then a reverse codec does become necessary, doesn't it? 03:01:03 -!- metasyntax [~taylor@72.86.89.174] has quit [Quit:  In our sky there is no limits, and masters we have none; heavy metal is the only one! ] 03:03:44 It's more about what procedures are applicable. Gambit binary ports allow object I/O (read, write, display), character I/O (read-char, write-char) and binary I/O (read-u8, write-u8). 03:04:02 A character port that is not a binary port does not allow read-u8 or write-u8. 03:04:13 Likewise, an object port that is not a character port does not allow read-char or write-char. 03:04:43 So there is no specific "output domain" (or "input domain"); it depends on the procedure being invoked. 03:05:02 Ah. 03:05:18 How does one set the encoding used for character and object I/O? 03:05:49 If the argument to open-*-file (and friends) is not a string, then it must be a disembodied p-list. 03:05:49 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Read error: Connection timed out] 03:06:12 araujo [~araujo@gentoo/developer/araujo] has joined #scheme 03:06:15 That allows you to set encoding, buffering, etc. 03:06:58 Suppose I need to send strings of multiple encodings as part of some binary protocol. Is there any mechanism provided for doing so without encoding the strings in memory and using binary I/O primitives? 03:08:59 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Max SendQ exceeded] 03:09:54 araujo [~araujo@gentoo/developer/araujo] has joined #scheme 03:10:40 No. But that mechanism seems to me to suffice. 03:10:56 (Actually, I lie; there is an API to get/set the settings.) 03:12:26 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Max SendQ exceeded] 03:12:46 araujo [~araujo@gentoo/developer/araujo] has joined #scheme 03:21:28 -!- offby1 is now known as NancyDungeon 03:21:36 -!- NancyDungeon is now known as offby1 03:21:58 ASau [~user@83.69.227.32] has joined #scheme 03:25:17 -!- luz [~davids@201.17.88.176] has quit [Quit: Client exiting] 03:26:14 githogori [~githogori@adsl-66-123-22-146.dsl.snfc21.pacbell.net] has joined #scheme 03:28:05 -!- tessier [~treed@kernel-panic/copilotco] has quit [Ping timeout: 276 seconds] 03:28:11 tessier [~treed@mail.copilotco.com] has joined #scheme 03:32:14 -!- pinchyfingers [~user@pool-98-114-40-249.phlapa.fios.verizon.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 03:32:43 wingo [~wingo@cpe-76-166-198-241.socal.res.rr.com] has joined #scheme 03:34:30 edw [~user@71.23.221.213] has joined #scheme 03:37:21 -!- MichaelRaskin [~MichaelRa@195.91.224.225] has quit [Ping timeout: 272 seconds] 03:39:18 jonrafkind [~jon@c-67-172-254-235.hsd1.ut.comcast.net] has joined #scheme 03:44:43 -!- copumpkin [~copumpkin@94.164.58.13] has quit [Ping timeout: 245 seconds] 03:45:16 copumpkin [~copumpkin@94.164.58.13] has joined #scheme 03:48:08 does that happen to do w/ r7rs by any chance 03:50:35 It might. 03:53:06 I just noticed you're in the wg, that's all -- checking out the discussion a bit. 03:54:18 By "it might" I'm not trying to be coy, I just mean that WG1 hasn't decided anything about binary ports yet. 03:56:48 -!- edw [~user@71.23.221.213] has quit [Ping timeout: 265 seconds] 03:57:27 I really didn't understand why IO changed the way it did w/ r6rs 03:58:35 I don't know so much about the technical merits of the various approaches, although I do find Gambit's way to be pretty nice in practice 03:59:26 -!- josephholsten [~josephhol@adsl-38-12-46.tulsaconnect.com] has quit [Ping timeout: 276 seconds] 04:00:12 I don't claim to know the reasons behind almost any R6RS decision. 04:00:18 evhan [~evhan@76-250-39-229.lightspeed.mdsnwi.sbcglobal.net] has joined #scheme 04:00:47 One of the things that irritates me the most is a near complete lack of anything to do with alists 04:01:48 -!- fod [~fod@92.251.255.7.threembb.ie] has quit [Remote host closed the connection] 04:03:09 i/o has nothing to do with alists. 04:03:14 No kidding.. 04:05:11 -!- copumpkin [~copumpkin@94.164.58.13] has quit [Ping timeout: 258 seconds] 04:06:33 -!- jyaan [~jyaan@c-98-250-102-194.hsd1.mi.comcast.net] has quit [Read error: Connection reset by peer] 04:06:57 copumpkin [~copumpkin@94.167.3.221] has joined #scheme 04:09:46 *jcowan* likes alists alot 04:09:51 -!- aidalgol [~user@114-134-7-235.rurallink.co.nz] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 04:13:08 jyaan [~jyaan@c-98-250-102-194.hsd1.mi.comcast.net] has joined #scheme 04:14:31 Most bizarre thing just happened, apps stopped responding, dmesg gave segfaults, and filesystem went down 04:15:44 Have you told your Twitter followers yet? 04:17:02 What exactly is your problem 04:17:08 he said "alot" 04:17:17 And btw, I don't use Twitter 04:17:20 "Alot" is very bad. :( 04:17:37 Unless you are actually talking about alots http://hyperboleandahalf.blogspot.com/2010/04/alot-is-better-than-you-at-everything.html 04:17:38 -rudybot:#scheme- http://tinyurl.com/y42zurt 04:18:20 rudybot: do you like your new yurt? 04:18:21 *offby1: This is a *new* API. 04:18:49 MichaelRaskin [~MichaelRa@pantagruel.mccme.ru] has joined #scheme 04:19:20 mjonsson_ [~mjonsson@cpe-98-14-173-5.nyc.res.rr.com] has joined #scheme 04:19:37 -!- mjonsson [~mjonsson@cpe-98-14-173-5.nyc.res.rr.com] has quit [Read error: No route to host] 04:20:07 franki^: regarding the page: some people type in all lower case for the aesthetics :P 04:21:35 proq` [~user@184-76-24-220.war.clearwire-wmx.net] has joined #scheme 04:22:57 -!- proq [~user@unaffiliated/proqesi] has quit [Ping timeout: 272 seconds] 04:29:14 jyaan: I used to be one of them, but then I was trying to explain that I had been helping my uncle Jack off a horse and decided that capitalisation was necessary after all. ;) 04:29:35 Hahaha 04:30:01 -!- mjonsson_ [~mjonsson@cpe-98-14-173-5.nyc.res.rr.com] has quit [Remote host closed the connection] 04:30:48 Actually, I'd prefer a spelling system where everything was phonetic and we used capitalization to distinguish nouns rather than various mangled spellings 04:30:59 nouns and verbs* 04:31:47 Yeah, English is a huge mess, but I can't really change that so I just try and follow conventions 04:32:07 phonetic spelling would be a mess: different people pronounce the same words differently 04:32:30 There are some ways around that 04:32:49 we'd lose olin 04:33:01 ERROR: unbound identifier: layambdah 04:33:03 endings like en can be pronounced various ways and that's fine, same with prefixes 04:33:16 Lol, I would spell it laambda 04:33:33 You pronounce the b? 04:33:42 Hm maybe not :S 04:34:27 Seems that I try to but it doesn't make a difference in pronunciation 04:36:31 Btw, does anyone know which language it is that accepts "" for "lambda"? I know for certain that I did it before, but I could never find out which language it was again.... 04:36:35 wingo: :) 04:36:51 What is olin? :s 04:36:54 jyaan: racket might. 04:37:07 Maybe, I was pretty sure it was a Scheme 04:37:10 guile does. 04:37:14 rudybot: eval (map ( (x) (* x 2)) (list 1 2 3) 04:37:15 *offby1: error: eval:1:0: read: expected a `)' to close `(' 04:37:17 rudybot: eval (map ( (x) (* x 2)) (list 1 2 3)) 04:37:18 *offby1: ; Value: (2 4 6) 04:37:20 ta da 04:37:27 Oh must have been guile, I used guile when I first started Scheme 04:37:36 metoo 04:38:00 rbarraud_ [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has joined #scheme 04:38:26 -!- rbarraud [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has quit [Read error: No route to host] 04:39:57 hadronzoo [~hadronzoo@ppp-70-251-108-227.dsl.rcsntx.swbell.net] has joined #scheme 04:40:14 Didn't work in guile, I got unbound variable. Maybe old versions only? 04:41:03 Racket works -- at least I relax and know I wasn't imaging it :P 04:41:10 I can relax* 04:42:24 I'm going to turn of my computer for the night -- worried about it misbehaving.. Night everyone- 04:42:44 -!- jyaan [~jyaan@c-98-250-102-194.hsd1.mi.comcast.net] has quit [Quit: Leaving.] 04:47:03 -!- rbarraud_ [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 04:47:31 rbarraud_ [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has joined #scheme 04:47:36 *wingo* exhales 04:51:02 any opinions on syntax-rules patterns with type predicates? like (syntax-rules () (_ X:string YS ...) (_ X:symbol YS ...)), is there a library or srfi like this already? 04:52:19 been looking at some papers on dylan's macro system, still not quite convinced, but this seemed like it could be an expressive feature 04:53:30 somnium`: (syntax-rules () (_ X:string XS ...))) would not match (string-append "foo" "-bar"), would it? 04:54:01 And, well, as the names states, syntax-rules works on syntax 04:55:42 well, I guess it could be implemented with syntax-case 04:56:11 It's already possible to distinguish symbols from other things. 04:56:29 Distinguishing string literals from numbers would pose no essential problem. 04:56:34 if you expect it to match "obvious" objects, such as "foo" and 3 and |bar|, yes, you can do it. 04:56:45 I think the word you're looking for is "literal". 04:56:52 Yes :) 04:57:00 chandler: how do you distinguish numbers from strings in syntax-rules patterns? 04:57:15 You can't. 04:57:29 You can distinguish symbols from other kinds of objects. 04:57:39 I'm pondering adding it to my 'scheme-admiring-language-that-does-not-implement-scheme' that Ive almost bootstrapped 04:58:00 What I was saying is that there's no essential issue with adding the ability to distinguish strings from numbers, for instance. 04:58:09 somnium`: it seems everyone in here has one of those.. :) 04:59:09 somnium`: but deciding whether an expression evaluates to a string or a symbol is not going to be easy to implement. 04:59:27 rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has joined #scheme 04:59:44 -!- rbarraud_ [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 252 seconds] 05:02:27 Axioplase: it would be fairly easy to add it to my toy expander as I have it now 05:03:27 I tend to think that it's an indecidable problem, but I may be wrong there. 05:03:34 FurnaceBoy: Ah, I thought most people here had languages that actually-implement-scheme 05:03:59 Axioplase: I don't think he's trying to check whether it *evaluates* to a string, but just whether it is a literal string. 05:04:08 Axioplase: syntax->datum , split on ":", lookup a predicate ... 05:04:16 ah, ^^ what chandler said 05:04:53 chandler: I said he could implement for litterals, and then added that "evaluates to a FOO" might be "trickier". 05:06:07 I just wanted to be sure we were all talking about the same thing, as it wasn't clear. 05:06:13 somnium`: they can't seem to resist being different! 05:06:49 -!- FurnaceBoy [~FurnaceBo@ns2.smartgames.ca] has quit [Quit: nite] 05:07:15 josephholsten [~josephhol@ip70-189-106-111.ok.ok.cox.net] has joined #scheme 05:07:17 -!- josephholsten [~josephhol@ip70-189-106-111.ok.ok.cox.net] has quit [Client Quit] 05:10:14 -!- lusory [~bart@bb116-14-95-15.singnet.com.sg] has quit [Ping timeout: 264 seconds] 05:13:01 -!- jcowan [~John@cpe-98-14-172-204.nyc.res.rr.com] has left #scheme 05:13:58 lusory [~bart@bb119-74-197-142.singnet.com.sg] has joined #scheme 05:20:13 -!- mbohun [~mbohun@202.124.72.169] has quit [Remote host closed the connection] 05:28:03 vu3rdd [~vu3rdd@164.164.250.10] has joined #scheme 05:29:32 mbohun [~mbohun@202.124.72.169] has joined #scheme 05:34:22 -!- wbooze [~user@xdsl-78-34-251-1.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 05:34:26 -!- homie [~user@xdsl-78-34-251-1.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 05:51:48 rdd [~rdd@c83-250-48-164.bredband.comhem.se] has joined #scheme 06:05:10 -!- toast` [~toast`@c-71-231-102-232.hsd1.wa.comcast.net] has quit [Quit: toast`] 06:13:09 -!- jonrafkind [~jon@c-67-172-254-235.hsd1.ut.comcast.net] has quit [Ping timeout: 272 seconds] 06:14:45 schmir [~schmir@mail.brainbot.com] has joined #scheme 06:16:12 -!- rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has quit [Read error: Connection reset by peer] 06:16:29 rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has joined #scheme 06:19:12 kar8nga [~kar8nga@i-15.vc-graz.ac.at] has joined #scheme 06:20:15 aidalgol [~user@114-134-7-235.rurallink.co.nz] has joined #scheme 06:24:59 -!- wingo [~wingo@cpe-76-166-198-241.socal.res.rr.com] has quit [Ping timeout: 252 seconds] 06:34:24 -!- rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 06:34:56 rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has joined #scheme 06:49:40 -!- rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 06:50:10 rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has joined #scheme 06:54:09 -!- rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 06:54:45 rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has joined #scheme 07:07:37 -!- rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 07:08:09 rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has joined #scheme 07:10:55 skld [~skld@unaffiliated/skld] has joined #scheme 07:11:49 -!- schmir [~schmir@mail.brainbot.com] has quit [Remote host closed the connection] 07:22:25 schmir [~schmir@mail.brainbot.com] has joined #scheme 07:24:21 -!- incubot [incubot@klutometis.wikitex.org] has quit [Remote host closed the connection] 07:28:31 incubot [~incubot@klutometis.wikitex.org] has joined #scheme 07:29:39 pdelgallego [~pdelgalle@1503031474.dhcp.dbnet.dk] has joined #scheme 07:31:30 -!- atomx [~user@93.112.81.240] has quit [Ping timeout: 240 seconds] 07:35:31 gravicappa [~gravicapp@80.90.116.82] has joined #scheme 07:41:10 -!- kar8nga [~kar8nga@i-15.vc-graz.ac.at] has quit [Remote host closed the connection] 07:42:29 -!- rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 07:42:58 rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has joined #scheme 07:45:17 dfkjjkfd [~paulh@176-13-ftth.onsnetstudenten.nl] has joined #scheme 07:45:45 -!- hadronzoo [~hadronzoo@ppp-70-251-108-227.dsl.rcsntx.swbell.net] has quit [Quit: hadronzoo] 07:52:07 -!- rdd [~rdd@c83-250-48-164.bredband.comhem.se] has quit [Ping timeout: 265 seconds] 07:52:40 -!- jensn [~ceres@c-83-233-158-96.cust.bredband2.com] has quit [Ping timeout: 265 seconds] 08:00:35 jensn [~ceres@c-83-233-158-96.cust.bredband2.com] has joined #scheme 08:03:41 -!- githogori [~githogori@adsl-66-123-22-146.dsl.snfc21.pacbell.net] has quit [Remote host closed the connection] 08:05:48 -!- rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 08:06:16 rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has joined #scheme 08:09:14 HG` [~HG@xdslfb136.osnanet.de] has joined #scheme 08:16:24 -!- rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 08:16:54 rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has joined #scheme 08:17:52 -!- Axioplase is now known as Axioplase_ 08:19:15 -!- dfkjjkfd [~paulh@176-13-ftth.onsnetstudenten.nl] has quit [Quit: Lost terminal] 08:30:56 -!- tessier [~treed@mail.copilotco.com] has quit [Changing host] 08:30:56 tessier [~treed@kernel-panic/copilotco] has joined #scheme 08:32:48 I see one problem with that "ooc-lang:" 08:33:08 it uses parser. 08:33:30 If it uses one, why the hell you want postfix notation? 08:33:34 -!- rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 08:34:00 rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has joined #scheme 08:41:10 -!- ASau [~user@83.69.227.32] has quit [Remote host closed the connection] 08:41:30 -!- proq` [~user@184-76-24-220.war.clearwire-wmx.net] has quit [Ping timeout: 240 seconds] 08:41:37 _mpu [~mpu@unaffiliated/-mpu/x-0307768] has joined #scheme 08:41:41 ASau [~user@83.69.227.32] has joined #scheme 08:47:59 -!- ASau [~user@83.69.227.32] has quit [Remote host closed the connection] 08:50:38 ASau [~user@83.69.227.32] has joined #scheme 08:51:43 -!- rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 08:52:11 rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has joined #scheme 08:57:08 -!- ASau [~user@83.69.227.32] has quit [Ping timeout: 276 seconds] 08:58:38 ASau [~user@83.69.227.32] has joined #scheme 09:02:17 -!- ASau [~user@83.69.227.32] has quit [Remote host closed the connection] 09:03:37 jgracin [~jgracin@dh111-186.xnet.hr] has joined #scheme 09:06:18 ASau [~user@83.69.227.32] has joined #scheme 09:07:34 hkBst [~hkBst@gentoo/developer/hkbst] has joined #scheme 09:16:10 -!- rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 09:16:39 rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has joined #scheme 09:24:43 -!- ASau [~user@83.69.227.32] has quit [Remote host closed the connection] 09:26:09 ASau [~user@83.69.227.32] has joined #scheme 09:30:10 -!- ASau [~user@83.69.227.32] has quit [Remote host closed the connection] 09:31:09 ASau [~user@83.69.227.32] has joined #scheme 09:38:26 -!- ASau [~user@83.69.227.32] has quit [Ping timeout: 264 seconds] 09:41:25 -!- aidalgol [~user@114-134-7-235.rurallink.co.nz] has quit [Quit: zZzZzZz] 09:42:31 alaricsp [~alaric@relief.warhead.org.uk] has joined #scheme 09:47:26 kephas [~pierre@AStrasbourg-551-1-65-8.w92-141.abo.wanadoo.fr] has joined #scheme 09:49:08 -!- nowhereman [~pierre@AStrasbourg-551-1-9-160.w86-213.abo.wanadoo.fr] has quit [Ping timeout: 276 seconds] 10:10:03 -!- jmcphers [~jmcphers@218.185.108.156] has quit [Remote host closed the connection] 10:10:45 jmcphers [~jmcphers@218.185.108.156] has joined #scheme 10:14:21 fradgers- [~fradgers-@5adafe9d.bb.sky.com] has joined #scheme 10:17:27 -!- mbohun [~mbohun@202.124.72.169] has quit [Quit: Leaving] 10:26:26 -!- rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 264 seconds] 10:33:07 metasyntax [~taylor@72.86.89.174] has joined #scheme 10:46:07 -!- vinnana [~pkensche@cmbipc58.cmbi.umcn.nl] has quit [Ping timeout: 265 seconds] 11:40:12 -!- hkBst [~hkBst@gentoo/developer/hkbst] has quit [Ping timeout: 258 seconds] 11:47:11 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #scheme 11:49:11 -!- TE263w` [~user@styldeks.am-1.org] has quit [Ping timeout: 276 seconds] 11:50:57 vasil_sd [~vasil_sd@80.90.116.82] has joined #scheme 12:00:34 dfkjjkfd [~paulh@195-13-ftth.onsnetstudenten.nl] has joined #scheme 12:13:13 FurnaceBoy [~FurnaceBo@ns2.smartgames.ca] has joined #scheme 12:19:56 hkBst [~hkBst@gentoo/developer/hkbst] has joined #scheme 12:20:18 -!- alaricsp [~alaric@relief.warhead.org.uk] has quit [Ping timeout: 240 seconds] 12:36:42 -!- MichaelRaskin [~MichaelRa@pantagruel.mccme.ru] has quit [Ping timeout: 240 seconds] 12:39:01 nego [~nego@c-76-16-30-244.hsd1.il.comcast.net] has joined #scheme 12:40:11 MichaelRaskin [~MichaelRa@pantagruel.mccme.ru] has joined #scheme 12:49:27 -!- MichaelRaskin [~MichaelRa@pantagruel.mccme.ru] has quit [Ping timeout: 252 seconds] 13:11:33 -!- _mpu [~mpu@unaffiliated/-mpu/x-0307768] has quit [Quit: Leaving] 13:12:49 alaricsp [~alaric@relief.warhead.org.uk] has joined #scheme 13:20:58 and^ [~aaaaaa@ti0035a340-dhcp0387.bb.online.no] has joined #scheme 13:28:24 -!- FurnaceBoy [~FurnaceBo@ns2.smartgames.ca] has quit [Quit: WeeChat 0.3.3] 13:28:59 FurnaceBoy [~FurnaceBo@bas2-toronto10-2925235460.dsl.bell.ca] has joined #scheme 13:31:48 TE263w` [~user@styldeks.am-1.org] has joined #scheme 13:33:55 mjonsson [~mjonsson@cpe-98-14-173-5.nyc.res.rr.com] has joined #scheme 13:34:29 MichaelRaskin [~MichaelRa@pantagruel.mccme.ru] has joined #scheme 13:45:27 Riastradh [debian-tor@fsf/member/riastradh] has joined #scheme 14:02:48 -!- mjonsson [~mjonsson@cpe-98-14-173-5.nyc.res.rr.com] has quit [Ping timeout: 258 seconds] 14:08:40 -!- nego [~nego@c-76-16-30-244.hsd1.il.comcast.net] has quit [Read error: Connection reset by peer] 14:09:47 -!- schmir [~schmir@mail.brainbot.com] has quit [Ping timeout: 276 seconds] 14:17:36 kingping_ [~kp@95.70.95.205] has joined #scheme 14:17:38 Hello 14:18:06 How do I determine how many bits a flonum contains? 14:18:28 I'm using R6RS. 14:20:38 kingping_, the fastest way would probably be to check the documentation. The best way would likely be to read the implementation source. The most educational way, assuming you get a response at all, would be to ask on the mailing list dedicated to that implementation; doubly so if the implementor actively reads and responds to that list. 14:20:57 No, no, this one's easier: the answer is 64. 14:21:11 *gnomon* pouts 14:21:40 Riastradh: Racket doc says it depends on platform/compilation options and may be either 31 or 63. 14:22:16 Bizarre. 14:22:49 gnomon: That's the trouble. Since I'd like to be it portable across different implementations. The only thing I need though is to extract some data from the flonum. 14:23:04 -!- jgracin [~jgracin@dh111-186.xnet.hr] has quit [Remote host closed the connection] 14:23:23 (the latter being exponent and mantissa) 14:23:41 Good heavens, why do you want the mantissa? Surely it is the significand you are interested in. 14:24:58 $ lynx -dump http://docs.racket-lang.org/reference/numbers.html | grep 'Inexact real numbers are implemented as either single- or double-precision IEEE floating-point numbers' 14:25:08 Also, where did you find the figures 31 and 63? The source suggests that there is an option for enabling IEEE 754 single-precision floats, but that by default, there are only IEEE 754 double-precision floats -- i.e., by default, the answer I gave is correct. 14:25:12 Riastradh: Yes, significand. 14:25:51 okay 14:26:12 Hope that's true for all R6RS major implementations. 14:27:37 Anyway, there's no standard way to get at the bits of the IEEE 754 floating-point format given an inexact real number. 14:28:04 (Perhaps you saw the 31 and 63 as the numbers of bits for the two's-complement representations of fixnums.) 14:29:18 Probably 14:30:35 -!- and^ [~aaaaaa@ti0035a340-dhcp0387.bb.online.no] has quit [Remote host closed the connection] 14:30:49 femtoo [~femto@95-89-198-68-dynip.superkabel.de] has joined #scheme 14:32:23 -!- kingping_ [~kp@95.70.95.205] has quit [Quit: Thanks. Vale.] 14:34:08 schmir [~schmir@mail.brainbot.com] has joined #scheme 14:42:39 -!- jensn [~ceres@c-83-233-158-96.cust.bredband2.com] has quit [Read error: Connection reset by peer] 14:43:13 jensn [~ceres@c-83-233-158-96.cust.bredband2.com] has joined #scheme 14:48:34 -!- vu3rdd [~vu3rdd@164.164.250.10] has quit [Remote host closed the connection] 14:53:49 -!- HG` [~HG@xdslfb136.osnanet.de] has quit [Quit: HG`] 14:56:27 -!- MichaelRaskin [~MichaelRa@pantagruel.mccme.ru] has quit [Remote host closed the connection] 15:05:34 hohoho [~hohoho@ntkngw229253.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 15:12:56 wbooze [~user@xdsl-87-79-232-38.netcologne.de] has joined #scheme 15:12:56 homie [~user@xdsl-87-79-232-38.netcologne.de] has joined #scheme 15:13:53 -!- schmir [~schmir@mail.brainbot.com] has quit [Remote host closed the connection] 15:18:03 luz [~davids@201.17.88.176] has joined #scheme 15:24:51 dzhus [~sphinx@89-178-231-100.broadband.corbina.ru] has joined #scheme 15:26:42 rdd [~rdd@c83-250-48-164.bredband.comhem.se] has joined #scheme 15:29:03 -!- gravicappa [~gravicapp@80.90.116.82] has quit [Ping timeout: 258 seconds] 15:30:18 -!- vasil_sd [~vasil_sd@80.90.116.82] has quit [Ping timeout: 240 seconds] 15:38:08 toast` [~toast`@c-71-231-102-232.hsd1.wa.comcast.net] has joined #scheme 15:38:28 Fare [~Fare@ita4fw1.itasoftware.com] has joined #scheme 15:39:28 -!- saccade_ [~saccade@209-6-54-113.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has quit [Quit: This computer has gone to sleep] 15:42:18 -!- toast` [~toast`@c-71-231-102-232.hsd1.wa.comcast.net] has left #scheme 15:42:29 toast` [~toast`@c-71-231-102-232.hsd1.wa.comcast.net] has joined #scheme 15:44:24 -!- toast` [~toast`@c-71-231-102-232.hsd1.wa.comcast.net] has quit [Quit: toast`] 15:45:02 toast` [~toast`@c-71-231-102-232.hsd1.wa.comcast.net] has joined #scheme 15:46:26 jonrafkind [~jon@c-67-172-254-235.hsd1.ut.comcast.net] has joined #scheme 15:56:33 kar8nga [~kar8nga@k-115.vc-graz.ac.at] has joined #scheme 15:57:23 saccade_ [~saccade@c-66-31-201-117.hsd1.ma.comcast.net] has joined #scheme 16:00:00 fowlduck [~fowlduck@2002:4547:f82e:0:fa1e:dfff:fed7:9dc1] has joined #scheme 16:00:28 wingo [~wingo@adsl-75-28-21-123.dsl.irvnca.sbcglobal.net] has joined #scheme 16:10:09 -!- wingo [~wingo@adsl-75-28-21-123.dsl.irvnca.sbcglobal.net] has quit [Read error: Connection reset by peer] 16:17:23 -!- toast` [~toast`@c-71-231-102-232.hsd1.wa.comcast.net] has quit [Quit: toast`] 16:20:23 toast` [~toast`@c-71-231-102-232.hsd1.wa.comcast.net] has joined #scheme 16:20:23 -!- pygospa [~pygospa@g225237096.adsl.alicedsl.de] has quit [Read error: Connection reset by peer] 16:20:24 Delita [~pete@74.39.194.248] has joined #scheme 16:21:56 jewel [~jewel@196-215-16-132.dynamic.isadsl.co.za] has joined #scheme 16:22:04 -!- kar8nga [~kar8nga@k-115.vc-graz.ac.at] has quit [Remote host closed the connection] 16:23:51 nego [~nego@c-76-16-30-244.hsd1.il.comcast.net] has joined #scheme 16:24:18 -!- nego [~nego@c-76-16-30-244.hsd1.il.comcast.net] has quit [Client Quit] 16:25:15 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Read error: Connection timed out] 16:25:39 pygospa [~pygospa@f055019204.adsl.alicedsl.de] has joined #scheme 16:26:00 araujo [~araujo@gentoo/developer/araujo] has joined #scheme 16:27:14 -!- toast` [~toast`@c-71-231-102-232.hsd1.wa.comcast.net] has quit [Quit: toast`] 16:28:37 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Max SendQ exceeded] 16:29:36 araujo [~araujo@gentoo/developer/araujo] has joined #scheme 16:31:23 -!- pygospa [~pygospa@f055019204.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds] 16:32:14 antoszka [~antoszka@unaffiliated/antoszka] has joined #scheme 16:33:26 pygospa [~pygospa@f055018175.adsl.alicedsl.de] has joined #scheme 16:34:45 wingo [~wingo@obfw.oblong.net] has joined #scheme 16:35:42 -!- Delita [~pete@74.39.194.248] has quit [Quit: leaving] 16:36:26 Fnord! 16:37:51 -!- hohoho [~hohoho@ntkngw229253.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Quit: Leaving...] 16:40:23 -!- jewel [~jewel@196-215-16-132.dynamic.isadsl.co.za] has quit [Ping timeout: 265 seconds] 16:41:05 Did you mean to say something there, Riastradh? 16:42:20 vu3rdd [~vu3rdd@122.166.174.166] has joined #scheme 16:42:53 Where? 16:43:08 I haven't said anything since this morning in the conversation about flonum bits.n 16:44:24 Hm. Must have imagined it then. 16:44:52 Imagined anything interesting about Scheme lately? 16:45:09 *FurnaceBoy* 's head meta-splodes 16:45:20 I've been trying to figure out what memory exhaustion really means, and how it should be handled. 16:46:35 Are you referring to real page exhaustion, address space exhaustion, heap limit exhaustion, or something else? 16:46:38 In particular, what memory exhaustion means to a userland process running under a multiprocess operating system on a machine with virtual memory, such as GNU/Linux on a typical workstation. 16:46:51 Ah yes 16:47:02 I'm referring to all of the above, really. 16:47:07 Does Linux still overcommit VM? 16:47:36 It means that one should expect a visit from the dreaded OOM Killer. 16:48:01 karme [~user@static.180.75.40.188.clients.your-server.de] has joined #scheme 16:48:27 Well, the oom killer is unavoidable in some situations, but I'd like the system to behave more gracefully before entering those situations. 16:48:29 (You weren't expecting something graceful here, were you? Certainly there wouldn't be any warning that the OOM Killer is about to be set loose and that applications which can reduce their memory usage should find a way to do so if possible. That would be Hard Work.) 16:49:01 chandler: I suffered this misery in a past life looking after some production JVM-based services 16:49:35 I had a perfectly good weak hash mapped-cache, all ripe for the flushing, but no! Not even an java.lang.OutOfMemoryError! I got SIGKILL... 16:49:48 *alaricsp* restrains his punching-arm 16:49:50 Here are two bad situations, which are bad in different ways, which behave badly but which shouldn't. 16:50:50 (1) You have multiple JVM processes, say running web servers, with enormous heaps containing large amounts of cached data, say web page data read from disk. You try to read another one, and at that point Linux gives up the ghost, invokes its lack of warranty, and lets out the oom killer, even though any of those processes could have released a lot of their storage. 16:51:39 alaricsp: Probably after it killed something completely irrelevant that also happens to auto-respawn like the GNOME panel. I've seen it do that a few times in a row before finally killing the process that's using 9GB of real memory. 16:51:46 proq [~user@unaffiliated/proqesi] has joined #scheme 16:52:18 chandler: Hah! These servers had few processes running, so I didn't fall particularly afoul of that, but I can imagine the mirth that would ensue if it chose sshd etc. 16:52:56 (2) You have an application that has a relatively small working set during most of its running, but the working set varies from time to time, so that overall, the amount of live data is much larger than the actual working set -- and much larger than the main memory. Unfortunately, the garbage collector, going about its business finding live data, pulls in lots of currently unneeded pages from secondary storage into main memory, making the applic 16:53:18 "making the applic" 16:53:25 ...ation thrash. 16:53:45 :) 16:54:33 I vaguely recall some work on avoiding that by storing GC metadata in special metadata pages to some extent... doesn't really help with small pointer-rich objects like cons cells, mind. 16:54:59 MichaelRaskin [~MichaelRa@195.91.224.225] has joined #scheme 16:55:23 Both of these situations can be solved relatively easily: in (1), the operating system just needs to let the processes know when memory is nearing exhaustion, and the processes need to drop some of their cached data; in (2), the operating system needs to tell the application when it is about to flush a page from main memory to secondary storage, at which point the GC can approximate a list of pointers out of that page, so that it doesn't need to 16:55:45 I suppose generational GC might help a bit, as the "bulk data" is probably not recently created, so can be scanned less often 16:56:35 In situation number 2, I could imagine the application telling the kernel that it's finished scanning a particular page and thus may feel free to page it out to disk. 16:56:57 Generational garbage collection solves an orthogonal problem: wasting time processing objects that don't need processing. That improves throughput, but doesn't help to handle memory exhaustion gracefully. 16:57:05 chandler, yes, the application needs that too. 16:58:17 You can do that with madvise(MADV_DONTNEED). 16:58:35 (2) is solved by `bookmarking collection', which some folks at UMass Amherst implemented earlier this decade. They submitted a very small, non-invasive patch to the Linux kernel to notify applications when pages are about to be flushed, and their patch was roundly rejected, apparently because Linux kernel hackers don't `get' garbage collection. 16:59:43 :( 17:00:47 Another way to solve (2) is with Brooks's real-time collector: his collector never touches data that the mutator wasn't about to touch anyway, and so avoids faulting pages in from secondary storage when the application didn't ask for them. Unfortunately, that collector requires a read barrier, a write barrier, and an EQ? barrier. 17:01:15 (Also, as written in the paper, his collector isn't real-time when arbitrary-length arrays are involved.) 17:02:26 While his read barrier is relatively low-overhead (each application read from memory requires two physical reads from memory; no branches or anything), it still has overhead, and the EQ? barrier can cause page faults. 17:04:14 Finally, Brooks's collector doesn't address memory exhaustion. 17:10:22 MIT Scheme goes to a little effort to recover gracefully from memory exhaustion -- at least, exhaustion of the allocated virtual address space. It keeps a reserve area of the heap, and when the (simple-minded stop & copy) collector fails to reclaim enough storage, it interrupts the program and tries to abort to the nearest REPL. That way, at least Edwin keeps running when the expression you typed in the REPL buffer fills the heap. 17:12:19 The intent of the behaviour is good (the implementation is a bit tricky, and could stand to be more robust), but this criterion for memory exhaustion -- when there is no more room in the virtual address space -- makes sense only when the virtual address space is actually limited, however, and, practically speaking, it basically isn't limited on modern machines. 17:12:39 Indeed. 17:13:35 One (ugly) fix is to learn (from the user, or from the system) how much memory is safe to ask for, ask for it, and use only that - with your own app-level VM if required. 17:13:55 Touch all the pages to ensure they've not been overcommitted to somebody else before doing anything 17:14:10 etc 17:15:39 Has there been much work on doing VM at the object-management level (by which I mean, the domain of GCs and tagged pointers, rather than the domain of pages)? 17:16:36 I think I have a book somewhere on a Smalltalk system that had a global-table-of-objects that mapped object IDs (array indices) to either an in-memory pointer or a NULL if it was swapped out to disk, or some such 17:17:06 rdbms cache ... 17:17:56 Hmmm, potentially applicable 17:17:59 I don't know exactly what you mean, but I think the answer is `sort of'. For example, the 3600 has a Baker-style incremental garbage collector (I don't think it is real-time, but it is incremental) with a hardware read barrier that relies on the memory being tagged, so that the collector can look into an arbitrary word in an arbitrary page and do something useful with it. 17:18:59 Well, I mean systems (be they software or hardware) that swap *objects* rather than *pages*, or at least pay attention to what objects are in the pages when swapping pages 17:19:03 Smalltalk systems are usually slow interpreters anyway, so software read barriers (and indirections like that) may be more palatable, but generally I am not happy with read barriers, because I care about fast systems. 17:19:12 Me too 17:19:28 I don't know of any systems that swap on the object level rather than on the page level. 17:19:52 It strikes me that there are synergies of concerns between a GC and a VM 17:20:07 ya, that's what Riastradh is talkin about 17:20:16 Indeed 17:21:37 Well, sort of. A garbage collector's job is to identify the *live* data. A pager's job is to keep the *active* data in main memory. There is always an intersection between the two, but the intersection may be small. 17:22:14 -!- saccade_ [~saccade@c-66-31-201-117.hsd1.ma.comcast.net] has quit [Ping timeout: 264 seconds] 17:22:58 -!- Hal9k [~Lernaean@unaffiliated/kusanagi] has quit [] 17:24:35 By the way, I misspoke earlier about Brooks's collector. The read barrier does have a branch; it's just lighter-weight than Baker's read barrier. It could also have a page fault, with appropriate page protections and cooperation from the MMU, instead of a branch. 17:26:03 Also, in Brooks's collector, CONS can cause pages to be swapped in, of course, because CONS does a little bit of garbage collection work; it's just that the read barrier generally never causes pages to be swapped in unless the mutator needed them anyway. 17:29:34 Hal9k [~Lernaean@unaffiliated/kusanagi] has joined #scheme 17:31:07 bweaver [~user@75-148-111-133-Chattanooga.hfc.comcastbusiness.net] has joined #scheme 17:33:20 jlf [~user@pdpc/supporter/active/jlf] has joined #scheme 17:37:50 nego [~nego@c-76-16-30-244.hsd1.il.comcast.net] has joined #scheme 17:40:14 -!- wingo [~wingo@obfw.oblong.net] has quit [Ping timeout: 264 seconds] 17:40:47 githogori [~githogori@70.sub-75-210-122.myvzw.com] has joined #scheme 17:49:12 Perhaps if I say something completely absurd about garbage collection and virtual memory, it will more effectively trigger an excited discussion. 17:50:18 Or would it be better to say something absurd and inflammatory about Linux? 17:50:58 I'm sorry, Riastradh, but you lost my interest to lunch about an hour ago. I might be able to say something about the subject now, though. 17:51:21 Well, maybe lunch will steal MY interest now, then! 17:51:33 I mean now, not then. 17:51:40 What a curious construction. 17:53:17 Anyway, do weigh in if you like -- my lunch is right by my keyboard anyway. (LEBCAK) 17:53:33 gravicappa [~gravicapp@ppp91-78-230-107.pppoe.mtu-net.ru] has joined #scheme 17:54:33 wingo [~wingo@173.243.145.79] has joined #scheme 17:55:10 Transformer [~Transform@ool-4a59e397.dyn.optonline.net] has joined #scheme 17:57:00 wingo, before you can enter, you'll have to opine on the subject of the preceding not-quite-discussion. 17:58:01 -!- Transformer [~Transform@ool-4a59e397.dyn.optonline.net] has quit [Excess Flood] 17:58:03 Riastradh: on garbage collection? 17:58:24 i regret to say that i am ignorant, and that guile lamely uses bdw-gc ;) 17:58:46 maybe one day we will do differently, until then, i don't know or control very much there... 17:59:23 Well, the problem applies to that, too. 17:59:41 What does Guile consider memory exhaustion? What action does it take when it considers memory to be exhausted? 18:00:35 -!- femtoo [~femto@95-89-198-68-dynip.superkabel.de] has quit [Quit: Leaving] 18:03:47 MrFahrenheit [~RageOfTho@users-42-95.vinet.ba] has joined #scheme 18:03:53 I think there are a few different questions tangled up in this discussion. One is what the kernel could do to help address these situations ideally; another is what small modifications could be made to the kernel to help user-space programs deal with these situations (provided even small modifications could be sold to kernel hackers), and lastly there's the question of what a user-space program could do right now. 18:05:13 Right now, the kernel will handle flushing memory associated with pages on disk better than real pages of memory that could be dropped by the application if need be. 18:05:42 This suggests that even if writing data to disk is not desired, applications should keep flushable caches in mmap'd files on disk. 18:06:15 If the data is infrequently synced, the associated overhead may be small. 18:06:16 Yes, there are different questions here -- part of what I meant to illustrate with the two situations I gave is that they don't cover everything that `memory exhaustion' might mean, and I'd like to find what memory exhaustion generally means. 18:07:10 Is memory exhaustion different from disk exhaustion? 18:07:29 (I don't think it is.) 18:07:37 No, except in that swap may be limited more than the disk. 18:08:02 (For example, I have a 1 GB swap partition on this machine, rather than a variable-size swap file on some partition with a file system.) 18:10:10 I'm not even considering swap here. Disk exhaustion seems to be handled equally poorly by operating systems, if not worse: unlike the OOM killer, there's no disk reaper that can just arbitrarily erase a large file. 18:10:29 (Do copy-on-write filesystems have a reaper to delete old snapshots in exhaustion cases?) 18:11:44 disk space overcommit is possible without copy-on-write, too (holes) 18:12:05 chandler: that sounds too dangerous and silly 18:12:08 (afair) 18:12:50 But filesystems have a quota system (and root, hopefully, gets an exclusive one) 18:13:17 Actually, there is an important difference between disk exhaustion and memory exhaustion (although it may be masked with memory-mapped disk I/O): write(fd, buffer, size) can fail with ENOSPC; *p can't fail recoverably. 18:14:26 That is, system calls have a defined interface for recoverable failure (even if they stupidly fail to make it usable; e.g., I hear that on Linux, close can fail with ENOSPC -- and not actually close the file descriptor). 18:14:56 Riastradh: you can catch SIGSEGV in response to *p and deal with that condition 18:15:04 this is one way to do userspace copy-on-write 18:15:21 You don't get a SIGSEGV in an exhaustion scenario. You get SIGKILL. 18:15:40 elly, that works in a different situation. 18:15:52 Systems generally don't let you return from a segv. 18:16:04 If the page is mapped non-readable, and your SIGSEGV handler remaps the page readable, then you can restart *p and proceed, as if nothing had happened. 18:16:32 Jafet: longjmp 18:16:44 Riastradh: or run your gc and try to mmap() there 18:16:56 elly: that's forbidden by posix, and a few systems that adhere to it. 18:17:04 but not Linux 18:17:19 No? I thought it was. 18:17:29 Riastradh: i think it will alloc and alloc and alloc and eventually (hopefully) be oom-killed, but probably the gc thrash will immobilize it first 18:17:30 siglongjmp() works perfectly in this situation 18:17:32 We're not talking about what one can do within the confines of POSIX, Jafet. We're talking about what computer systems with garbage collection should, and practically can, do. 18:17:35 You don't need to longjmp out of the signal handler. 18:17:36 regarding guile 18:17:51 Riastradh: I see. 18:17:56 elly, yes, the SIGSEGV handler presumably does something before remapping the page readable, such as scanning the page. 18:17:59 Delita [~pete@74.39.194.248] has joined #scheme 18:18:07 sure 18:18:10 -!- Delita [~pete@74.39.194.248] has quit [Client Quit] 18:18:13 Delita [~pete@74.39.194.248] has joined #scheme 18:19:51 One idea I had was for programs to mark their data as either essential, or cached (ie. could be recomputed). 18:20:19 But I'm not sure what proportion of memory tends to fall in each category. 18:20:22 But if the hardware faults because you run *p = x where p is a pointer into the next empty page mapped for the heap, and the operating system is incapable of finding a physical backing for that page, because main memory and secondary storage are both full, what do you do? 18:20:38 Well, on Linux, you get eaten by the oom killer. 18:21:58 You could kill the process that least deserves to survive, instead of a random one like linux does. 18:22:21 I don't want to kill any processes before they have had a chance to release some of their memory. 18:23:16 Well, if you treat "memory available" as an IO resource in itself, you could schedule processes in turn until one of them gets the hint and does that. 18:23:40 For what it's worth, I believe iOS (nee iPhone OS) has a "low memory notification" that gets delivered to apps before they are killed. 18:24:11 If they release memory, are they then not killed? 18:24:14 (I think linux does something like that) 18:24:24 No, Linux has nothing like that, Jafet. 18:24:52 As I said earlier, some folks at UMass Amherst implemented a garbage collector that takes advantage of such a notification, and submitted a small patch to the Linux kernel to support such notifications, and the patch was roundly rejected. 18:25:20 Oh, sorry: those are two different notifications. 18:25:21 Doesn't it suspend processes when memory is out? 18:25:31 One is when a page is about to be moved to secondary storage; one is when a process is about to be killed. 18:25:43 (The bookmarking collector wanted the first type of notification.) 18:26:06 I don't know whether Linux notifies a process just before sending it SIGKILL. 18:26:38 Belaf [~campedel@194.209.131.192] has joined #scheme 18:26:41 It does if ulimits (so, artificial resource bounds) are set 18:26:44 -!- Belaf [~campedel@194.209.131.192] has left #scheme 18:27:16 -!- nego [~nego@c-76-16-30-244.hsd1.il.comcast.net] has quit [Quit: leaving] 18:27:35 That's different. That has to do with the virtual address space that is allocated, which may be substantially larger than the physical memory available to the system. 18:27:36 nego [~nego@c-76-16-30-244.hsd1.il.comcast.net] has joined #scheme 18:29:27 According to bash over here, ulimit lets you limit the resident size of a process 18:30:20 That is only a hint to the operating system about whose pages to swap out first when main memory is full. 18:31:43 I see. 18:32:22 What systems have better resource management? Perhaps we should base discussion on those instead 18:32:53 Gosh, I'm missing a good conversation here. Time to catch up on the scrollback. 18:34:12 Well, one simple way to avoid SIGKILL on *p = x is to avoid overcommitting virtual memory. 18:36:39 Riastradh: in the mmap case this means first filling the file at the moment :( / though i think there will be / maybe is a syscall to really reserve the space (think i saw some discussion related to copy-on-write fs ...) 18:37:12 Yes, I have left memory-mapped I/O as a parenthesis. 18:37:48 langmartin [~user@exeuntcha2.tva.gov] has joined #scheme 18:38:42 -!- Delita [~pete@74.39.194.248] has quit [Quit: leaving] 18:40:09 Avoiding overcommit might be a sensible strategy, but it certainly complicates allocator implementation. 18:40:40 kar8nga [~kar8nga@m-243.vc-graz.ac.at] has joined #scheme 18:40:41 How does it complicate allocator implementation? 18:40:49 fallocate 18:40:54 For what it's worth, I usually set my Linux systems to "always overcommit". 18:41:30 Riastradh: Allocation is no longer as simple as incrementing the allocation pointer in a large anonymous map. 18:41:53 That is, unless your heap is small enough that it can always be backed by real pages. 18:42:33 Oh, you mean that it complicates a userland process's allocator. 18:42:39 Yes. 18:43:06 Well, you can always scan through the whole space to zero it as soon as you've mmapped it. 18:43:14 -!- vu3rdd [~vu3rdd@122.166.174.166] has quit [Remote host closed the connection] 18:43:26 You can still contrive a race condition for that 18:44:30 You can't allocate more address space than you'll ever use. That might be fine for some systems, but wouldn't work well when there are multiple address space ranges to be allocated and it's not known in advanced how much of each needs to be backed by real pages. 18:44:50 For instance, the generations in a generational collector, or the typed regions in a BIBOP-style scheme. 18:47:33 You can allocate virtual address space in chunks -- large enough for a cheap heap pointer, small enough not to allocate much more virtual address space than the application's live data actually need. 18:48:28 That, or dynamically expand or contract each region depending on its load, as measured after a collection. 18:49:25 I know SBCL likes to map basically all the virtual address space there is and then manage everything in the space itself, but I don't think that's a very helpful strategy. 18:49:42 aidalgol [~user@114-134-7-235.rurallink.co.nz] has joined #scheme 18:50:22 I'm still not certain that this will result in a better failure case than simply disabling overcommit and requiring real pages as needed. Will malloc or the underlying system call that it relies upon (mmap? sbrk? I've no idea in practice) actually return NULL for a situation where all real pages are exhausted, or will the request for additional real pages simply trigger the OOM killer? 18:50:55 I hope that it will actually return a failure and not just kill the application. 18:50:57 Let's test this hypothesis. 18:51:23 -!- nego [~nego@c-76-16-30-244.hsd1.il.comcast.net] has quit [Ping timeout: 255 seconds] 18:51:36 I have a BIBOP-style mostly-contention-free allocator for C that maps far more virtual address space than will ever actually be used. It's a useful strategy as it punts the fragmentation problem elsewhere. 18:52:25 I have a machine here that has four gigabytes of RAM, and 20 gigabytes of swap, according to top. Let's see what malloc and mmap do. 18:53:01 nego [~nego@c-76-16-30-244.hsd1.il.comcast.net] has joined #scheme 18:53:37 That's probably easier to test by turning off swap. 18:53:48 I don't have root on this machine. 18:53:52 I've a virtual machine I can use for testing too. 18:54:08 Perhaps that would be handier -- although virtual machines tend to overcommit resources too... 18:54:13 You're trying to invoke the OOM killer on a machine you don't have root on? 18:54:21 I'm going to disable overcommit. 18:54:32 Oops. Good point. 18:55:14 There's enough real RAM on this machine to handle a situation where the virtual machine uses all of the RAM it's been allocated. 18:57:55 Well, mallocing 40 GB gave a null pointer. 18:58:06 (mallocking?) 18:59:07 Malloc(k)ing 20 GB gave space. Now the machine is initializing 20 GB of memory with ones, and thrashing. 18:59:39 josephholsten [~josephhol@216.16.128.242] has joined #scheme 19:00:29 Anyway, I think it is pretty clear that the right thing for malloc and mmap to do when memory is exhausted (with overcommit disabled) is to fail, not to terminate the process. 19:01:19 I don't think terminating the process is reasonable in that situation: even if the program is badly written, it will probably pretty soon try to dereference a pointer in the first or last page of virtual memory and crash anyway. 19:03:28 -!- karme [~user@static.180.75.40.188.clients.your-server.de] has quit [Remote host closed the connection] 19:04:50 -!- rdd [~rdd@c83-250-48-164.bredband.comhem.se] has quit [Ping timeout: 264 seconds] 19:10:19 Riastradh: malloc does appear to fail gracefully in an out-of-memory scenario. 19:11:11 -!- dfeuer [~dfeuer@wikimedia/Dfeuer] has quit [Ping timeout: 265 seconds] 19:12:19 Riastradh: That applies to when overcommit is disabled. With overcommit always permitted, the process is terminated by the OOM killer. 19:13:06 Hmm? With vm.overcommit_memory set to 0, I observed malloc of 40 GB to return 0. 19:13:56 (on a system with 20 GB of swap and 4 GB of RAM) 19:14:17 I'm not mallocing 40GB. I'm attempting to malloc 256K chunks of 4K each. 19:14:28 OK. 19:15:00 I've tested the three options for overcommit behavior provided by Linux - always overcommit, heuristic overcommit, and never overcommit. 19:16:06 With never overcommit, malloc fails gracefully when attempting to allocate the 76742th chunk (after 314335232 bytes have already been allocated). 19:17:06 -!- hkBst [~hkBst@gentoo/developer/hkbst] has quit [Remote host closed the connection] 19:17:29 With always overcommit behavior, the process is terminated by the OOM killer when attempting to allocate the 240441th chunk (after 984846336 bytes have already been allocated). 19:18:25 With heuristic overcommit behavior, the process is terminated by the OOM killer when attempting to allocate the 240498th chunk (985079808 bytes already allocated). 19:18:41 Heuristic overcommit is the kernel default. 19:21:15 We can see the pitfalls of using "never overcommit" behavior here. While it fails gracefully, `free -m` claims that 943MB out of 1002MB total is free, counting buffers and cache as used, but the test program can only allocate 299MB before it is killed. 19:25:34 dfeuer [~dfeuer@wikimedia/Dfeuer] has joined #scheme 19:25:42 HG` [~HG@xdsl-92-252-89-19.dip.osnanet.de] has joined #scheme 19:26:18 What do you think about having a memory priority system, just as we have CPU priority? When the system runs out (or is about to run out) of memory, it lets higher-priority processes have it, and forces lower-priority ones to exit. 19:27:42 Process granularity is insufficient. A process of any priority may be holding on to real pages that it does not need and could free if asked nicely by the kernel. 19:28:41 That's OK, if the kernel gives processes a chance to release memory before killing them. 19:28:49 Okay, say the system signals every process when memory is low. Any process which does free memory might have its priority raised. 19:28:59 karme [~user@static.180.75.40.188.clients.your-server.de] has joined #scheme 19:29:43 If swap is also full though, one might end up waking up processes in swap, and thrashing is assured to happen 19:31:21 It won't be more than two or three years until swap on rotating media is a thing of the past. Thrashing to NAND is a much, much more palatable possibility. 19:31:24 saint_cypher [~rjspotter@70-36-245-104.dsl.static.sonic.net] has joined #scheme 19:33:04 But will flash have enough write lifetime to be used as swap? 19:34:04 How does the practical, observed lifetime of flash media compare with that of magnetic media, anyway? Disks fail all the time. 19:34:55 Riastradh, right now the weak point in flash media appears to be the poor quality control of the controller chips, not the actual NAND media. Presumably the next weakest link will turn out to be wear levelling schemes. 19:35:26 Any individual disk *might* work for an indefinite period of time, whereas Flash media that's written often enough will eventually fail within a relatively predictable amount of time. 19:36:09 That's why I asked about practical, observed lifetime. 19:36:11 I don't think treating flash as a consumable resource is a terrible problem provided the chipset provides adequate advance warning of impending death. 19:36:23 Remember CDs in the 80s? A lifetime of listening. 19:36:34 My firsthand experience with one drive is "somewhere between a month and three months". 19:36:41 It's probably a bad drive, though. 19:37:00 Perhaps I should say `the expectation value of a disk's lifetime, given the observed distribution of disk lifetimes.' 19:38:07 The first USB flash device I used died completely in about three months. However, while I haven't used many more since then, I haven't observed any of them to fail (yet). 19:38:07 I'm not sure if we have enough data on flash lifetime yet, especially those used as hard drive replacements. Few use them even now, due to the price. 19:38:27 Sure, but we have plenty of data on magnetic lifetime. 19:38:49 Jafet: There's plenty of data, but manufacturers aren't exactly forthcoming, and it does depend on the manufacturer. 19:39:10 It's usually quoted at 10,000 erase/write cycles, but whether you hit that on any one sector depends on the quality of the wear-leveling in the controller. 19:39:27 "Thrashing to NAND is a much, much more palatable possibility." <- not via SATA. :) it's just the same problem, shifted a bit 19:39:28 It will be going down as manufacturers move beyond 2 bits per cell. 19:40:03 the hierarchy is always going to be there. ssds don't change that 19:41:08 I don't see what SATA has to do with it. Thrashing tends to invoke the worst-case performance behavior of rotating media. SSDs demonstrate much better behavior in that scenario. 19:41:48 SATA imposes an overall bandwidth limit, but at the moment SSDs can't saturate 6Gbps SATA. That'll likely change in a year or two. 19:42:03 chandler: the point about sata was, that even though the storage has happier qualities, it's still behind an interface that leaves the hierarchy very much in place. i.e. a quantitive change, not a qualitative change. 19:42:13 -!- Adamant [~Adamant@unaffiliated/adamant] has quit [Ping timeout: 245 seconds] 19:42:19 chandler: it's not just bandwidth... 19:42:40 Why is the nature of the interface to the storage relevant? 19:42:56 that's not the basic point. the basic point is that you're stuck with a hierarchy. ssds don't change that. 19:43:06 -!- nego [~nego@c-76-16-30-244.hsd1.il.comcast.net] has quit [Quit: Lost terminal] 19:43:32 I don't understand the relevance of the point to the conversation. 19:43:35 sure, the slowest storage is a bit faster. 19:43:50 i don't understand the relevance of ssds to the conversation. hence my remarks. 19:44:01 but nm 19:44:22 swapping to ssds is still swapping to the slowest storage you have. 19:44:37 and sata is nothing like a memory interface., obv 19:44:54 The point I made is that a memory exhaustion handling strategy that causes applications to page in data when searching for pages to free is more palatable when swap is on a SSD than on a hard drive. 19:45:01 yes. 19:45:06 the lack of seek is a factor 19:45:36 SATA isn't a given for that point either. This discussion would apply equally to a system where the processor has a built-in NAND controller. 19:45:58 sure, that just shifts things in time a little... 19:46:05 Swapping to an SSD isn't the slowest storage you have, if there's also rotating media in the system. It's an order of magnitude faster. 19:46:30 we can always make ssd look fast by installing slower storage ): 19:46:32 :) 19:46:41 FurnaceBoy: seek rate is the bottleneck for all sorts of applications; swapping, transaction-logging/updating, etc. 19:46:48 anyway, we also never have as much real memory as we like, hence talking about swapping 19:46:53 making the seek rate -zero- is a big deal. 19:46:58 lucca: granted 19:47:09 FurnaceBoy: Please read the discussion that preceded your entry into the conversation. 19:47:22 chandler: i did, mostly :) 19:49:04 Anyway, I want a garbage collector that behaves gracefully in the face of memory exhaustion, and performs well in the face of pressure on main memory, and grants me unlimited ponies. 19:49:22 mejja [~user@c-14bee555.023-82-73746f38.cust.bredbandsbolaget.se] has joined #scheme 19:49:33 *FurnaceBoy* is hungry and contemplates pony steak 19:49:34 But for now, I'll have to settle with having a cookie instead. 19:50:08 rudybot: give Riastradh 'a-cookie 19:50:18 mejja: error: with-limit: out of time 19:50:21 Bounded-time pauses would be nice, too. 19:50:43 I wonder if it would be possible to create a user-space daemon that detects a situation that's likely to trigger the OOM killer and informs processes that have asked to be notified about such situations that it would be a good idea to dispose of any real pages they don't need. 19:51:13 It would be possible on linux, where userspace processes have access to far more system information than they usually need. 19:51:53 Such a daemon could help also processes coordinate their collections, so they don't all require their maximum number of pages at the same time. 19:52:46 It could also suspend any uncooperative process that's allocating pages until the cooperative processes have disposed of excess pages. 19:54:51 -!- HG` [~HG@xdsl-92-252-89-19.dip.osnanet.de] has quit [Quit: Leaving.] 19:55:38 pavelludiq [~user@87.246.58.79] has joined #scheme 19:55:51 -!- pygospa [~pygospa@f055018175.adsl.alicedsl.de] has quit [Ping timeout: 258 seconds] 19:56:57 Too bad Adobe gobbled up Felix Klock so that not much more is likely to happen to regional garbage collection. It'd be nice if it supported weak references, for instance. 19:57:12 Or, rather: not much more is likely to be published about regional garbage collection. 19:57:25 pygospa [~pygospa@g225204225.adsl.alicedsl.de] has joined #scheme 19:57:26 -!- pavelludiq [~user@87.246.58.79] has quit [Remote host closed the connection] 19:57:35 pavelludiq [~user@87.246.58.79] has joined #scheme 20:00:27 saccade_ [~saccade@BRAIN-AND-COG-FIVE-THIRTY-SEVEN.MIT.EDU] has joined #scheme 20:01:03 nego [~nego@c-76-16-30-244.hsd1.il.comcast.net] has joined #scheme 20:03:08 -!- niko [~niko@freenode/staff/niko] has quit [Changing host] 20:03:08 niko [~niko@freenode/staff/ubuntu.member.niko] has joined #scheme 20:15:06 bgs100 [~ian@unaffiliated/bgs100] has joined #scheme 20:18:52 -!- saint_cypher [~rjspotter@70-36-245-104.dsl.static.sonic.net] has quit [Quit: Leaving.] 20:19:18 -!- pygospa [~pygospa@g225204225.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds] 20:21:03 -!- nego [~nego@c-76-16-30-244.hsd1.il.comcast.net] has quit [Quit: Lost terminal] 20:21:29 pygospa [~pygospa@f055247203.adsl.alicedsl.de] has joined #scheme 20:28:50 -!- dzhus [~sphinx@89-178-231-100.broadband.corbina.ru] has quit [Ping timeout: 264 seconds] 20:29:36 Riastradh: what ever happened with T? Were you able to get it dumping elf, or emitting ppc instead of sparc? 20:40:11 nego [~nego@c-76-16-30-244.hsd1.il.comcast.net] has joined #scheme 20:41:14 -!- karme [~user@static.180.75.40.188.clients.your-server.de] has quit [Remote host closed the connection] 20:41:26 -!- pavelludiq [~user@87.246.58.79] has quit [Ping timeout: 264 seconds] 20:42:23 -!- kar8nga [~kar8nga@m-243.vc-graz.ac.at] has quit [Remote host closed the connection] 20:54:11 -!- langmartin [~user@exeuntcha2.tva.gov] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 20:55:53 -!- pygospa [~pygospa@f055247203.adsl.alicedsl.de] has quit [Ping timeout: 276 seconds] 20:56:55 pygospa [~pygospa@f055051105.adsl.alicedsl.de] has joined #scheme 21:04:24 -!- fowlduck [~fowlduck@2002:4547:f82e:0:fa1e:dfff:fed7:9dc1] has quit [Ping timeout: 272 seconds] 21:04:43 -!- Riastradh [debian-tor@fsf/member/riastradh] has quit [Ping timeout: 245 seconds] 21:05:40 lbc [~lbc@1908ds1-aboes.0.fullrate.dk] has joined #scheme 21:07:18 fowlduck [~fowlduck@69.71.248.46] has joined #scheme 21:20:30 saint_cypher [~rjspotter@h-67-101-43-36.snfccasy.dynamic.covad.net] has joined #scheme 21:23:39 -!- stepnem [~stepnem@88.103.132.186] has quit [Quit: ZNC - http://znc.sourceforge.net] 21:25:00 -!- pygospa [~pygospa@f055051105.adsl.alicedsl.de] has quit [Ping timeout: 240 seconds] 21:26:48 stepnem [~stepnem@88.103.132.186] has joined #scheme 21:27:05 pygospa [~pygospa@g226238082.adsl.alicedsl.de] has joined #scheme 21:27:47 rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has joined #scheme 21:28:11 I want to use libotr from Scheme (Guile in particular). Should I use SWIG or write bindings by hand? 21:36:20 -!- kniu [~kniu@CMU-311358.WV.CC.CMU.EDU] has quit [Remote host closed the connection] 21:40:32 -!- saccade_ [~saccade@BRAIN-AND-COG-FIVE-THIRTY-SEVEN.MIT.EDU] has quit [Quit: This computer has gone to sleep] 21:46:07 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Read error: Connection timed out] 21:46:42 araujo [~araujo@gentoo/developer/araujo] has joined #scheme 21:47:36 -!- saint_cypher [~rjspotter@h-67-101-43-36.snfccasy.dynamic.covad.net] has quit [Read error: Connection reset by peer] 21:49:30 -!- araujo [~araujo@gentoo/developer/araujo] has quit [Max SendQ exceeded] 21:50:13 araujo [~araujo@gentoo/developer/araujo] has joined #scheme 21:50:26 -!- gravicappa [~gravicapp@ppp91-78-230-107.pppoe.mtu-net.ru] has quit [Ping timeout: 264 seconds] 21:50:53 -!- aidalgol [~user@114-134-7-235.rurallink.co.nz] has quit [Quit: Emacs upgrade.] 22:00:11 -!- pygospa [~pygospa@g226238082.adsl.alicedsl.de] has quit [Ping timeout: 276 seconds] 22:01:21 pygospa [~pygospa@g230092203.adsl.alicedsl.de] has joined #scheme 22:05:24 RageOfThou [~RageOfTho@users-33-178.vinet.ba] has joined #scheme 22:06:00 saint_cypher [~rjspotter@h-67-101-148-122.snfccasy.dynamic.covad.net] has joined #scheme 22:09:15 -!- MrFahrenheit [~RageOfTho@users-42-95.vinet.ba] has quit [Ping timeout: 258 seconds] 22:13:44 nowhere_man [~pierre@AStrasbourg-551-1-27-88.w83-196.abo.wanadoo.fr] has joined #scheme 22:14:42 -!- kephas [~pierre@AStrasbourg-551-1-65-8.w92-141.abo.wanadoo.fr] has quit [Ping timeout: 240 seconds] 22:22:09 -!- z0d [~z0d@unaffiliated/z0d] has quit [Ping timeout: 272 seconds] 22:27:32 -!- pygospa [~pygospa@g230092203.adsl.alicedsl.de] has quit [Ping timeout: 253 seconds] 22:27:34 I seem to be writing a lot of macros like (syntax-rules () (mac X Y) ... (mac X Y MORE ...) (begin (mac X Y) (mac MORE ...))), is it bad style? is it standard to use a helper for this pattern? 22:28:35 somnium`: do use helpers for any pattern! 22:29:28 pygospa [~pygospa@g226226252.adsl.alicedsl.de] has joined #scheme 22:29:33 the tricky part is that some args need to be repeated and its hard to capture the shape to repeat, maybe something good will occur to me 22:30:59 Try to standardize things up. 22:32:05 rtra_ [~rtra@unaffiliated/rtra] has joined #scheme 22:33:28 -!- rtra [~rtra@unaffiliated/rtra] has quit [Ping timeout: 245 seconds] 22:34:26 IJP [~Ian@host109-154-194-223.range109-154.btcentralplus.com] has joined #scheme 22:34:32 hypercube32 [~hypercube@14.154.202.68.cfl.res.rr.com] has joined #scheme 22:38:37 -!- pygospa [~pygospa@g226226252.adsl.alicedsl.de] has quit [Ping timeout: 252 seconds] 22:39:35 -!- emma [~em@unaffiliated/emma] has quit [Ping timeout: 265 seconds] 22:40:20 pygospa [~pygospa@g227141096.adsl.alicedsl.de] has joined #scheme 22:45:19 -!- mejja [~user@c-14bee555.023-82-73746f38.cust.bredbandsbolaget.se] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716]] 22:46:01 -!- rbarraud__ [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has quit [Read error: Connection reset by peer] 22:48:26 rbarraud [~rbarraud@118-92-10-101.dsl.dyn.ihug.co.nz] has joined #scheme 22:51:12 emma [~em@unaffiliated/emma] has joined #scheme 22:52:57 -!- bweaver [~user@75-148-111-133-Chattanooga.hfc.comcastbusiness.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 22:55:28 Nils^ [steele@beegees.mtveurope.org] has joined #scheme 22:55:33 hello night-schemers 22:55:33 -!- emma [~em@unaffiliated/emma] has quit [Ping timeout: 245 seconds] 22:56:07 Azuvix [~Azuvix@174-19-234-140.bois.qwest.net] has joined #scheme 22:56:12 emma [~em@unaffiliated/emma] has joined #scheme 22:56:12 -!- Azuvix [~Azuvix@174-19-234-140.bois.qwest.net] has quit [Client Quit] 22:57:58 I'm currently building procedures with parameternames (as suggested by the book of Abelson, Sussman, Sussman) 22:58:12 so in all its beauty this is of course working: 22:58:13 (define (lolfunc paramone ) (paramone) ) 22:58:14 (lolfunc newline ) 22:59:03 but how can I give functions with parameters (partly optional) ? 22:59:42 my old scheme uses eval-string and it gets a whole scheme block as string. But I think this can be done much cleaner and nicer 23:01:47 (lambda ? 23:01:59 the book should cover it? 23:02:10 yes, its there 23:02:22 well, i'm only a n00b but i believe that's what you need 23:02:47 Quadrescence will explain more when he's back I suppose 23:03:30 Lambda is a known concept to me. But so far the whole (big big) program does not use it on purpose, as style. 23:03:40 so I'm just a little contributer and want to stick with that style 23:03:53 Nils^, you want to pass something instead of newline that accepts arguments? 23:04:14 jonrafkind: a method with arguments and a chain of methods. 23:04:29 I guess I could just define the method before that... 23:04:53 well, no. It must be possible with arguments 23:05:01 *Nils^* just made up his mind 23:05:04 rudybot: eval (define call-with-one (lambda (proc) (proc 1))) 23:05:15 rudybot: eval (call-with-one add1) 23:05:15 chandler: ; Value: 2 23:07:50 chandler: was that supposed to help me? 23:08:27 I don't understand your question, so I thought I'd share some code and see if it prompted any further questions or clarifications. 23:09:23 chandler: in your code the argument "1" is already in the definition. (call-with-one add1 1) would be the thing I'm searching for 23:09:50 well, its more complex, but this would be a good start 23:09:53 rudybot: eval (define call-with-one-argument (lambda (proc argument) (proc argument))) 23:10:02 rudybot: eval (call-with-one-argument add1 1) 23:10:02 chandler: ; Value: 2 23:11:51 chandler: yes, like this. thanks. 23:12:01 this can be only done with lambda? 23:13:19 -!- NNshag [user@lns-bzn-21-82-64-80-169.adsl.proxad.net] has quit [Read error: Operation timed out] 23:13:38 As opposed to? 23:13:51 You can use the shorthand `define' style that you were using before, if you like. 23:14:06 rudybot: eval (define (call-with-one-argument proc argument) (proc argument)) 23:14:12 rudybot: eval (call-with-one-argument add1 2) 23:14:12 chandler: ; Value: 3 23:14:18 It's the same thing. 23:14:21 ah, good 23:14:23 thanks 23:14:31 "shorthand"? 23:15:06 (define (foo . bar) baz ...) == (define foo (lambda bar baz ...)) 23:15:23 someone just compared ksplice to lisp, how lisp functions could be replaced in a running system. the metaphor is the same but the practical differences are wider than the grand canyon 23:15:57 :) 23:16:18 that ksplice people are able to get anything to work is amazing... 23:16:39 they appear to be hackers' hackers. 23:16:57 i agree, but ill never use it. my linux machine is unstable enough, thank you 23:17:00 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Quit: Leaving] 23:17:44 chandler: I assumed that (eval-string) is a bad method. Is this even true? If not I already have anything I need :) 23:17:58 I don't know what `eval-string' is. 23:18:25 (eval-string "(display \"Hello World\")") 23:18:29 schmir [~schmir@p54A90FA3.dip0.t-ipconnect.de] has joined #scheme 23:18:46 this is eval string. It takes a string and evals it as program 23:19:12 rudybot: eval (eval-string "(display \"Hello World\")") 23:19:16 Nils^: your sandbox is ready 23:19:16 Nils^: error: reference to undefined identifier: eval-string 23:19:37 It's probably not a good idea unless you are implementing something like rudybot's eval command. 23:19:39 maybe its not in every scheme variant, I don't know anything else than guile 23:19:42 It's not a standard procedure. 23:20:33 -!- pdelgallego [~pdelgalle@1503031474.dhcp.dbnet.dk] has quit [Ping timeout: 245 seconds] 23:21:37 the good thing is that its not limited, it can be used with as many functions and arguments as needed. Once I find out how to do this in a safe way I'll get rid of eval-string 23:22:03 -!- fowlduck [~fowlduck@69.71.248.46] has quit [Remote host closed the connection] 23:22:15 -!- schmir [~schmir@p54A90FA3.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 23:22:28 -!- emma [~em@unaffiliated/emma] has quit [Ping timeout: 272 seconds] 23:27:51 -!- josephholsten [~josephhol@216.16.128.242] has quit [Quit: josephholsten] 23:28:00 emma [~em@unaffiliated/emma] has joined #scheme 23:28:11 Nshag [user@lns-bzn-20-82-64-4-34.adsl.proxad.net] has joined #scheme 23:29:02 -!- luz [~davids@201.17.88.176] has quit [Remote host closed the connection] 23:30:12 luz [~davids@201.17.88.176] has joined #scheme 23:30:16 -!- somnium` [~user@adsl-65-185-34.dab.bellsouth.net] has quit [Remote host closed the connection] 23:33:38 -!- emma [~em@unaffiliated/emma] has quit [Ping timeout: 265 seconds] 23:34:14 emma [~em@unaffiliated/emma] has joined #scheme 23:40:24 -!- emma [~em@unaffiliated/emma] has quit [Ping timeout: 240 seconds] 23:51:33 emma [~em@unaffiliated/emma] has joined #scheme 23:53:41 mbohun [~mbohun@202.124.72.248] has joined #scheme 23:56:40 -!- emma [~em@unaffiliated/emma] has quit [Ping timeout: 272 seconds] 23:56:57 emma [~em@unaffiliated/emma] has joined #scheme 23:58:01 is there a way to build the actual name of a function out of parameter? like (build add 1) which then results in (add1) 23:58:17 (I mean besides eval-string and string-append :) )