00:02:56 -!- josephholsten [~josephhol@216.16.128.242] has quit [Quit: josephholsten] 00:03:26 IJP [~Ian@host81-151-82-209.range81-151.btcentralplus.com] has joined #scheme 00:03:33 -!- aidalgol [~user@202.36.179.65] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 00:03:42 -!- mmc [~michal@109.112.229.253] has quit [Ping timeout: 240 seconds] 00:05:22 -!- RageOfThou [~RageOfTho@users-33-197.vinet.ba] has quit [Ping timeout: 276 seconds] 00:05:51 hosh_office [~hosh@c-71-204-27-0.hsd1.ga.comcast.net] has joined #scheme 00:08:40 _Pb [~pb@75.131.194.186] has joined #scheme 00:15:05 IceD^: There have been attempts at making a portable FFI for R6RS, see spells http://bit.ly/aI0KfH and nausicaa http://bit.ly/aZsmrx 00:18:46 spells looks nice 00:18:57 it has file-size-in-bytes ;) 00:21:37 -!- hosh_office [~hosh@c-71-204-27-0.hsd1.ga.comcast.net] has quit [Ping timeout: 276 seconds] 00:23:30 -!- _Pb [~pb@75.131.194.186] has quit [Quit: Leaving] 00:23:58 mmc [~michal@109.112.195.234] has joined #scheme 00:24:49 TR2N [email@89.180.198.16] has joined #scheme 00:33:14 wbooze [~user@xdsl-78-34-237-59.netcologne.de] has joined #scheme 00:33:19 homie [~user@xdsl-78-34-237-59.netcologne.de] has joined #scheme 00:34:26 -!- worldhlord [~eldragon@84.79.67.254] has quit [Ping timeout: 265 seconds] 00:36:58 mjonsson_ [~mjonsson@cpe-98-14-173-5.nyc.res.rr.com] has joined #scheme 00:41:14 eprod [~user@96-25-191-71.gar.clearwire-wmx.net] has joined #scheme 00:43:10 foof, sent. 00:45:27 -!- fradgers- [~fradgers-@5adafe9d.bb.sky.com] has left #scheme 01:08:06 got it 01:11:19 -!- mmc [~michal@109.112.195.234] has quit [Quit: Leaving.] 01:13:15 Do let me know if there is anything at all confusing or non-obvious about it. There are many subtle details in it, and I went through several iterations of its design and implementation. 01:14:43 _Pb [~pb@75.131.194.186] has joined #scheme 01:15:56 proq [~user@unaffiliated/proqesi] has joined #scheme 01:20:26 nego [~nego@c-76-16-30-244.hsd1.il.comcast.net] has joined #scheme 01:21:14 What does `integer->file-descriptor' return if the fd doesn't exist? 01:22:55 That's an error. 01:23:29 INTEGER->FILE-DESCRIPTOR could check the error, or (as it does in unix-fd.scm) it could silently return a file descriptor object whose number is bogus. 01:24:14 -!- masm [~masm@2.80.156.45] has quit [Quit: Leaving.] 01:25:13 The only legitimate, non-interactive use of INTEGER->FILE-DESCRIPTOR that I know of is the one I described. 01:26:50 I see: you would like programs to report errors to the user if the user fails to supply a file descriptor of a particular number to the program, and INTEGER->FILE-DESCRIPTOR provides no way to do this. 01:27:58 Right. 01:28:07 Instead of what I just described, INTEGER->FILE-DESCRIPTOR could always run fcntl(fd, F_GETFL, 0). If fcntl gives EBADF, then INTEGER->FILE-DESCRIPTOR returns false; otherwise, it (claims responsibility for the file descriptor and) returns a file descriptor object as before. 01:28:15 Better? 01:29:21 Yes :) 01:29:42 (If you need more control, then you can use OPEN-FILE-DESCRIPTOR and a foreign routine yourself.) 01:29:58 -!- bgs100 [~ian@unaffiliated/bgs100] has quit [Quit: Leaving] 01:32:13 jcowan [~John@cpe-98-14-172-204.nyc.res.rr.com] has joined #scheme 01:32:49 I suppose I ought to have lisppasted all that cruft, rather than emailed it. 01:35:57 Riastradh: I need to finish my process interface and consider all the fd manipulation to see if I can use this. 01:36:29 Though since you can both cede control and take control of fd's from Scheme it should be fine. 01:38:17 In the typical case, Chibi takes FILE* objects and wraps them with ports. The FILE* objects are responsible for the fd's. But what happens if I then want to reference the corresponding fd from Scheme? 01:38:19 -!- emma is now known as em 01:39:09 You must choose who has responsibility for them. Either Scheme can have responsibility or stdio can have responsibility, but not both. 01:39:30 (In the latter case, Scheme may have responsibility for the file stream containing a file descriptor for which stdio has responsibility, of course.) 01:41:21 If ports wrap FILE*s which wrap fds, then you can't go mucking with the fd, of course, but you can refer to things with it. 01:41:39 Ksh, for example, uses stdio, but ksh's clients talk in terms of fds. 01:41:53 Oh, sure -- you are welcome to use fileno on the file stream, and pass around the resulting integer. 01:42:24 I don't know what machinery ksh uses to map fds back to FILE*s, though. 01:42:46 You can have multiple FILE*s open on the same fd. 01:43:07 Only if you are willing to deal with the problems of conflicting buffers, though. 01:43:15 Or are operating unbuffered. 01:43:39 You can, but is there any legitimate reason to do so? 01:48:10 -!- jonrafkind [~jon@crystalis.cs.utah.edu] has quit [Ping timeout: 276 seconds] 01:49:14 It may be possible to redesign and reimplement the interface I designed and implemented so that for any file descriptor object, Scheme may or may not be responsible for its file descriptor; that way, operations taking file descriptors would be independent of whether Scheme is responsible for them or not. 01:49:55 s/would be/could be/1 01:50:00 I have not yet thought that possibility through. 01:50:46 -!- _Pb [~pb@75.131.194.186] has quit [Quit: Leaving] 01:52:13 That's what I was planning - in Chibi every object has a flag indicating whether the finalizer should be run or not/ 01:52:56 Finalizer singular? Every object has at most one finalization procedure associated with it? 01:53:25 Every type has at most one finalization procedure. 01:54:23 I'll probably add guardians built on ephemerons for want you want object-specific finalizers to run. 01:54:23 I see. 01:54:31 for when you want 01:56:02 -!- nego [~nego@c-76-16-30-244.hsd1.il.comcast.net] has quit [Quit: Lost terminal] 01:57:11 It seems like custom finalizers opens a huge can of worms though. What if they never return? 01:58:02 -!- saccade_ [~saccade@dhcp-18-111-82-90.dyn.mit.edu] has quit [Quit: This computer has gone to sleep] 01:58:39 Then Scheme spins. 01:59:29 Then you cease to maek progress. How is that different from any other case of infinite looping? 02:00:05 If (x) is called, where (define (x) (x)), your program is hosed. 02:00:26 A more interesting question, perhaps, is what happens when a finalizer is re-entered. 02:01:33 jcowan: Because other infinite loops can be recovered with an interrupt. Interrupting the GC seems like a good way to achieve data corruption. 02:02:07 Interrupting the GC?? 02:02:22 The GC's work should be done by the time you call finalization procedures. 02:03:02 hosh_office [~hosh@c-71-204-27-0.hsd1.ga.comcast.net] has joined #scheme 02:03:03 You can move/copy the data, but you can't sweep until you've run the finalizer. 02:03:19 -!- dfkjjkfd [~paulh@69-13-ftth.onsnetstudenten.nl] has quit [Quit: Lost terminal] 02:03:43 Why not? 02:04:13 For that matter, the finalization mechanism needn't even be part of the garbage collector. 02:04:18 The finalizer needs to be able to access the object. 02:04:39 Not necessarily. It is very likely that all it needs access to is a certain part of the object. 02:05:01 For example, in the case of a file descriptor object, all it needs access to is the alien storing the file descriptor's number. 02:05:21 eldragon [~eldragon@84.79.67.254] has joined #scheme 02:05:53 That said, if you need access to the object, and not just a part of it, then just don't sweep it, and call the finalization procedures post-GC. 02:06:44 And reclaim the space on the next GC? 02:07:09 Right. 02:07:58 That's what Java does, and it makes sense to me. 02:08:12 -!- jao [~user@173.243.145.79] has quit [Ping timeout: 265 seconds] 02:08:29 Note that in Java an object can only be finalized once, even if it is reconnected by the finalizer. 02:09:03 But, as I said, it is likely that all the finalization procedure really needs is a part of the object. 02:09:43 Riastradh: That doesn't help, the GC can only preserve the whole object or none of it. 02:09:59 (cons (make-weak-cell file-descriptor) file-descriptor-alien) 02:10:10 That remembers the whole object weakly, but part of the object strongly. 02:11:05 That's orthogonal - I'm only talking about the single specific object that is about to be GCed. 02:11:09 Keep a list of those. After garbage collection, run through it, applying the finalization procedure to the cdr of each pair whose car is broken. 02:12:04 In order to fix up that sort of stuff, you need to have per-object-type queues on which the objects can be registered. 02:12:19 As a user-level optimization, sure, you can use weak references and structure your data so as to require as little data as possible for finalization. That doesn't matter for the GC implementation. 02:13:58 Of course it matters for the GC implementation -- it implies that the GC needs no special support for finalization; all it needs is support for weak references and some way to periodically call a procedure, preferably shortly after each garbage collection. 02:14:06 Weak references by themselves aren't enough: if a weak reference is held in a data structure, something has to notify the structure that the weak reference has gone south. 02:14:24 "A procedure" does not compose. 02:15:07 Sure, it doesn't compose alone, so the run-time system provides a particular procedure that implements a mechanism that does compose. 02:15:18 The garbage collector doesn't need to know about all that. 02:15:35 All it needs is some way to notify the run-time system that a garbage collection has just happened, so it may be a good time to run finalization procedures. 02:15:36 josephholsten [~josephhol@ip70-189-106-111.ok.ok.cox.net] has joined #scheme 02:16:29 That could run in another thread. The GC would want to wake the thread though. 02:17:23 Sure, that would work. 02:18:26 You already have the logic in place for the GC to call procedures, of course, and that suffices -- the run-time system can just plug in a procedure that implements whatever mechanism you want (composable or not), such as waking a thread. 02:19:18 Ah, without special-casing the GC I could just allocate an object of a special type and leave no references to it. Its type-specific finalizer would wake the thread. 02:20:44 aidalgol [~user@202.36.179.65] has joined #scheme 02:22:36 That's an inversion of what Riastradh described. 02:23:57 Yes, I hit return before I read. 02:24:47 -!- hosh_office [~hosh@c-71-204-27-0.hsd1.ga.comcast.net] has quit [Quit: Leaving] 02:25:00 br1 [~Bruno@r190-135-33-203.dialup.adsl.anteldata.net.uy] has joined #scheme 02:25:39 davazp [~user@83.54.164.142] has joined #scheme 02:29:03 hosh_office [~hosh@c-71-204-27-0.hsd1.ga.comcast.net] has joined #scheme 02:30:14 mg4001 [~mg4001@cpe-76-93-28-217.socal.res.rr.com] has joined #scheme 02:39:57 If you do give file descriptors a flag saying for each one whether Scheme is responsible for it, be careful to make updates to the flag atomic with transfers of responsibility. 02:40:11 -!- Azuvix [~Azuvix@174-19-234-140.bois.qwest.net] has quit [Quit: Why walk when you can code? ;)] 02:40:29 I don't understand this responsibility distinction. Is this a situation in which ports wrap fds directly? 02:42:11 You write a procedure that needs to use a file descriptor. Your procedure neither takes responsibility for a file descriptor from someone, nor cedes responsibility for the file descriptor to someone. For example, your procedure might pass the file descriptor to fcntl(F_GETFL) to get its flags. Does your procedure care whether it is Scheme or some other party who has responsibility for the file descriptor? 02:42:27 Ah, you're missing some context; let me forward it to you. 02:47:18 Sent. 02:47:37 Read. 02:52:36 timj__ [~timj@e176192001.adsl.alicedsl.de] has joined #scheme 02:52:42 So I was right; the objects you call "file descriptors" are indeed packages for fds, though they don't meet Scheme's port interface. 02:53:09 -!- br1 [~Bruno@r190-135-33-203.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] 02:54:21 The idea will certainly work, but it abandons the fact that fds are manifest as integers. 02:56:27 That's why he provides `call-with-file-descriptor-number'. 02:56:32 -!- timj_ [~timj@e176195223.adsl.alicedsl.de] has quit [Ping timeout: 265 seconds] 02:57:21 Oh yes, but that's not what I was talking about. 02:58:09 Heh, http://apenwarr.ca/log/?m=201008#10 02:59:12 How does it abandon that fact? 03:02:30 *jcowan* examines the API again. 03:02:38 -!- josephholsten [~josephhol@ip70-189-106-111.ok.ok.cox.net] has quit [Quit: josephholsten] 03:03:44 Ah, I see, it's the semantic restriction on integer->fd, that you can only call it if nobody owns the fd. 03:07:22 -!- mjonsson_ [~mjonsson@cpe-98-14-173-5.nyc.res.rr.com] has quit [Ping timeout: 248 seconds] 03:08:29 jonrafkind [~jon@c-67-172-254-235.hsd1.ut.comcast.net] has joined #scheme 03:08:35 The real problem, I think, is that fd allocation is partly controlled by the kernel, partly by userland. 03:10:21 The real problem, I think, is that the kernel doesn't GC resources. 03:10:22 Most of the time, non-well-known fds are allocated by the kernel, but user programs can allocate whatever fds they want for whatever purposes they want. 03:10:33 foof: Well, it does at process termination. 03:10:46 Temp files too? 03:10:48 And since there is no guarantee that finalizers are ever run.... 03:11:03 If you create them properly (open + unlink) 03:11:29 Ah, true. 03:11:42 Wait... that's not always an option. 03:12:14 Not on @#$ Windows, no, although Cygwin simulates it. 03:12:17 Open-and-unlink doesn't work if you want to pass the file off to another program that doesn't inherit a file descriptor as an `argument'. 03:12:34 True, but what would? 03:12:42 A temp file. 03:13:01 That isn't unlinked until the other program is done with it. 03:13:12 (I wish many more programs did -- particularly programs that want privileges just to open a particular device or create a single raw socket or similar.) 03:14:13 What counts as "done with it"? The next program might pass it to another and then terminate, letting the next program run. 03:14:42 Unless temp files have statically typed names (as opposed to mere strings), the kernel won't know when to quit. 03:14:50 -!- hosh_office [~hosh@c-71-204-27-0.hsd1.ga.comcast.net] has quit [Ping timeout: 248 seconds] 03:15:34 What you're asking for is a capability system, but one in which the kernel doesn't necessarily know about all preserved capabilities. 03:16:01 They could have dynamically typed "names" - the important part is being able to track the resource. 03:18:40 metasyntax [~taylor@72.86.89.174] has joined #scheme 03:19:21 hosh_office [~hosh@c-71-204-27-0.hsd1.ga.comcast.net] has joined #scheme 03:19:23 Capabilities could work together with resource management, but are not required - a reference to a resource would simply imply access. 03:20:57 Why bother with files at all? They're an outdated concept. 03:21:45 seangrove [~user@c-71-198-44-87.hsd1.ca.comcast.net] has joined #scheme 03:22:38 Currently we have two kinds of references: names, which are interprocess but can be forged, and fds, which have to be passed explicitly but can't be. 03:23:02 And if files are obsolete, so is the terminal interface, but I don't see any of us escaping from it here. 03:23:36 s/interprocess/persistent/ 03:23:46 mjonsson_ [~mjonsson@cpe-98-14-173-5.nyc.res.rr.com] has joined #scheme 03:25:32 -!- hosh_office [~hosh@c-71-204-27-0.hsd1.ga.comcast.net] has quit [Ping timeout: 265 seconds] 03:25:43 Why are terminals obsolete? I've yet to see a decent alternative. 03:26:04 nego [~nego@c-76-16-30-244.hsd1.il.comcast.net] has joined #scheme 03:26:05 soupdragon [~quantum@unaffiliated/fax] has joined #scheme 03:30:29 Isn't there a way to pass an fd to an existing process? 03:30:48 Yes. It's pretty hairy. 03:31:43 Via a local-domain (aka Unix) socket. 03:31:56 Hairy indeed. 03:32:07 If you're using a reasonable operating system (*BSD, Linux), here's how you do it (except that the `union' part is unnecessary because malloc guarantees the necessary alignment anyway): . (Scroll to the examples section.) 03:32:39 *jcowan* having spent a bunch of time porting Chibi to an only semi-reasonable system is very much inclined to agree. 03:32:52 If you're using an unreasonable operating system (e.g., Solaris (perhaps older than 10; I know it is the case on 9)), you have to pull out Stevens' book to find all the #ifdefinalization to get it right. 03:33:00 foof: Are you testing Chibi on Solaris, or do you want me to be Solaris Guy as well? 03:33:29 Oddly I don't have access to a Solaris box at the moment. 03:33:43 I do, so I'll try making it work there. 03:33:56 hosh_office [~hosh@c-71-204-27-0.hsd1.ga.comcast.net] has joined #scheme 03:34:02 It was very gratifying to see Cygwin build Chibi with no errors. 03:34:29 :) 03:35:05 Riastradh: Why is that API SHOUTING AT ME?! 03:35:41 Can someone please immensely increase the rate at which the moon's phase changes, for a couple of cycles, and then put it back? I'm trying to reproduce a bug, but having no luck -- it's a bug possibly in some celestial mechanics code, even. 03:36:13 lol 03:37:23 Sounds like you need a mock clock, though not necessarily a general one. 03:38:55 I'm off to bed now, but I'll see in the morning whether you succeeded in speeding up the moon, assuming that no transient network errors thwart me (ha). 03:39:17 *jcowan* expected to be defenestrated for that one, but evidently no luck. 03:40:02 *gnomon* preemptively refenestrates jcowan, just in case 03:40:36 Thank you. Could you hand me a hose to wash off the manure, also? 03:41:09 (What, has the channel been relocated to Prague?) 03:42:24 *Riastradh* vanishes. 03:42:54 Better than The Citadel, I'd say. 03:43:27 saccade_ [~saccade@209-6-54-113.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has joined #scheme 03:58:04 foof: do you have any thoughts how I can get myself out of the hole I've dug myself into with system-created condition objects? 03:58:15 I can give a precis of the situation if it helps. 04:01:15 The system-created objects don't need to be changed - the predicates and accessors just need to be able to recognize system-created objects (possibly handling them differently from user-defined exception types). 04:02:34 Yes, that's good. But how can userland create objects that are recognized by those predicates/accessors?^ 04:03:14 IOW, how can you create a condition that answers #t to divide-by-zero-condition? if you are implementing your own numbers? 04:03:55 (define (condition-message x) (if (system-created? x) (system-condition-message x) (generic-condition-message x))) 04:04:37 1) I don't understand that 2) I don't see its relevance. 04:04:59 -!- nego [~nego@c-76-16-30-244.hsd1.il.comcast.net] has quit [Quit: Lost terminal] 04:05:30 You're issue is with implementation, right? You don't want to specify something that requires implementations to change their exception systems? 04:05:43 s/Your're/Your/ 04:06:14 _Pb [~pb@75.131.194.186] has joined #scheme 04:06:31 <_Pb> has anyone here used scheme in a cgi script? 04:06:36 Yes, hence the predicate/accessor (aka interface) approach to recognizing system conditions. But how do we make those predicates/accessors deal with user conditions that are in effect subtypes of system conditions? 04:07:35 You implement both approaches - a translation for system types, and whatever you want for user types. 04:07:49 -!- eprod [~user@96-25-191-71.gar.clearwire-wmx.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 04:07:51 Then just dispatch like above on whether it's a system type. 04:08:46 I had rejected dynamic translation because it may have to happen several times going up the handler chain (which may contain both standard and native handlers), and will almost certainly lose information in the process. 04:09:17 What it boils down to is, interfaces don't have constructors, unless you hack around the problem somehow. 04:09:36 Exception handling doesn't have to be balzingly fast. 04:09:51 And those implementations that really want speed can modify their core exceptions. 04:09:55 Not about speed; as I say, losing information. 04:10:34 How do you lose information? You never translate the object, you just have generic accessors. 04:11:09 And how do you add new types to those generic accessors? 04:11:33 Particularly in systems that don't reify record types? 04:12:21 -!- proq [~user@unaffiliated/proqesi] has quit [Ping timeout: 240 seconds] 04:12:21 Use dispatch closures, or TinyCLOS-style objects, or whatever you want - that's an implementation detail. 04:12:39 With what API? 04:12:54 This API must be standardized, since it's a supported thing to create your own user conditions. 04:13:12 With the generic-* API, alongside the native-* API, both hidden by the normal exception API. 04:13:28 We are at cross-purposes, I think. 04:13:38 It's the SPI (service provider interface) that matters here. 04:13:40 Creating new conditions always creates generic objects. 04:13:59 I haven't been following what you folks have been doing, but I'm already boggling at this discussion. 04:14:02 I'm afraid I don't see what your problem is. 04:14:04 What is a generic object in this context? 04:14:17 chandler: Please enlighten me, then. 04:14:44 jcowan: An object which follows the condition API you expose. 04:14:45 I have no enlightenment, since I'm not following this completely. My bogglement begins with the term "exceptions" instead of "conditions". 04:15:01 *foof* *hates* the term "condition" 04:15:29 I assume that you've rejected stealing from Common Lisp wholesale for a really, really good reason. 04:15:31 Ah. When foof speaks, mentally translate "exception" to "condition", that's all. I call them "condition objects", not "conditions", except when I forget to. 04:16:12 My background assumption is that the native representation of system-created condition objects should be preserved. 04:16:13 I don't understand why system-created condition objects and user-created condition objects need to be differentiated. 04:16:21 chandler: If we had no way to access the first and second elements of a pair, I would likewise reject `car' and `cdr'. 04:16:36 Despite their being used in CL :P 04:17:03 foof: I would reject them too, but "condition" is not an arbitrary term. It was chosen because conditions needn't be exceptional. 04:17:28 Of *course* their exceptional, they break the normal flow of control. 04:18:00 Whereas a condition is an if or cond form, or in some contexts relates to threads. 04:18:02 Not necessarily. One may create a condition without raising an exception. 04:18:18 s/condition/condition object 04:18:52 The reason I dislike "condition" is that it confuses what has actually happened (an attempt to divide by zero, whcih is the *condition*) with a representation of that condition, which is a condition *object*. 04:19:06 Conditions don't break the normal flow of control at all in Common Lisp, unless by breaking the flow of control you mean that control transfers to some function whose name is not lexically apparent - but this isn't exactly an uncommon occurence. 04:19:23 I just don't see how the English word "condition" has anything at all to do with what we're discussing. 04:19:25 In any case, the name is a bikeshed. 04:20:02 jcowan: Isn't this (the issue of preserving native representations) the backdrop against which the Common Lisp condition system was designed? Rather than specifying that condition objects where CLOS objects or structure instances, a separate condition object system was added precisely to allow backwards compatibility. 04:20:42 True. But that was then and this is now. Schemes already have condition systems with their own underlying representations, some of which are not disjoint from other Scheme types. 04:21:30 I see that CL uses "situation" for my "condition" and "condition" for my "condition object". But no matter. 04:21:32 jcowan: If you want I can draw up a sample way to have two record types and provide a wrapper API that provides access to both, without needing to translate between record types. 04:21:50 ... but right now I need food :) 04:21:53 So can I, foof. The idea is to have N record types, dynamically adjustable. 04:22:33 Sorry, I meant two record _systems_, both dynamically adjustable. 04:22:47 Excellent, foof. Go and eat while I harangue Chandler. 04:23:21 jcowan: What representations are in use now that you're looking at preserving compatibility with? 04:23:44 The worst case is probably scheme48, whose conditions are a-lists. I don't have a specific list in mind. 04:24:12 In addition, I'm trying to avoid specifying a type tree, because it may well conflict with existing type trees. 04:24:18 Doesn't Scheme48 actually have two condition systems these days? (I don't really know; I've stopped paying attention.) 04:24:28 I only know what Riastradh says. 04:24:55 I think there are low-level and high-level conditions, but that's just to break a mutual implementation dependency of some sort. 04:25:08 Regardless, I don't think specifying disjointness is necessary, so long as there are predicates that can distinguish individual condition type instances from each other. 04:25:57 Another problem is that conditions in existing systems have subtyping relationships that don't agree with one another. 04:26:21 This is the worst problem with implementing arbitrary languages on the JVM, along with the Java-specified behaviors of String and Object. 04:26:39 I'm not grokking the JVM connection. 04:26:56 Never mind it for now. 04:27:32 If R7RS specifies a hierarchy of condition types, it won't necessarily agree with existing hierarchies in any way. Exposing just interfaces solves that problem. 04:28:55 But unless the interfaces themselves are reified (rather than just being conventional ways of discussing predicates and accessors), it's not obvious how to have an API that allows creating condition types that implement those interfaces. 04:28:57 I would suggest not exposing *any* hierarchy and making all standard condition types pairwise disjoint. 04:29:17 -!- _Pb [~pb@75.131.194.186] has quit [Quit: Leaving] 04:30:10 And if the underlying system does not make that guarantee? By using an interface only, I don't have to provide guarantees one way or the other. 04:30:27 Can you elaborate more on your "interface only" proposal? 04:31:19 Suppose we decide that division by zero is a kind of system-created condition one ought to be able to detect in a standard conditio handler. Then there is a predicate DIVIDE-BY-ZERO-CONDITION? that applies to any object and returns #t to such an object. 04:31:26 s/we/the WG 04:32:13 Perhaps the WG also decides that the numerator should be available. In that case, DIVIDE-BY-ZERO-CONDITION-NUMERATOR will be provided by conforming implementations to recover it. 04:32:47 That constitutes an interface for divide-by-zero conditions. 04:32:54 OK; what distinguishes this from a *non*-interface-only proposal? 04:33:33 With just an interface, we can't create an object that satisfies D-B-Z-C?. 04:34:18 SO those who wish to handle conditions can recover information from them, but those who wish to create conditions cannot add information to them in a systematically recoverable way. 04:34:18 What problem is solved by not allowing users to construct objects that satisfy the type predicate? 04:36:15 In particular, how is constructing a divide-by-zero-condition explicitly different than constructing one by dividing by zero? 04:37:48 It doesn't allow you to add additional information suitable to your API. 04:38:14 DBZC is a bad example, because I don't see what additional information there might be. 04:38:18 How would I construct a divide-by-zero-condition explicitly and add additional information to it? 04:38:36 In CL, you'd derive a condition type from DBZC. 04:38:57 That's a different operation than MAKE-CONDITION. 04:39:04 What is gained by eliminating MAKE-CONDITION? 04:39:39 Nothing; I now see that it's subtyping, not instantiation, that's the problem. 04:41:17 Or rather, that works if we have MAKE-*-CONDITION; MAKE-CONDITION requires that the condition type be reified. 04:41:40 OK. Now suppose the implementation provides a native divide-by-zero-condition type, which happens to be represented as an alist. By virtue of module-based import renaming, its type predicate is accessible as `native-divide-by-zero-condition?'. Suppose I also have an interface to define new condition types, but I can't inherit from the native divide-by-zero-condition. 04:42:09 Okay. 04:42:37 Suppose I define a condition type `user-divide-by-zero-condition' and define the predicate `divide-by-zero-condition?' as follows: (define divide-by-zero-condition? (lambda (o) (or (native-divide-by-zero-condition? o) (user-divide-by-zero-condition? o)))) 04:42:51 (I ought to have used the short form of `define' for that.) 04:43:16 Yes, that works in a single case, but it does not compose to many independent user types representing divides by zero. 04:43:39 Why not? Suppose they're all subtypes of `user-divide-by-zero-condition'. 04:44:09 Suppose now that it's all wrapped up in a nice layer so that subclassing `divide-by-zero-condition' actually subclasses a user- type that's disjoint from the native- type. 04:44:32 In what ways has this broken one of your requirements? 04:44:37 Okay, so the predicate looks like this: it returns #t on divide-by-zero condition objects (the reified-type kind) and also some implementation-specified set of ojbects. 04:45:48 To put this another way: native divide-by-zero condition objects can't become instances of some user divide-by-zero condition types, so why can't they be treated as disjoint types except for the purpose of some predicate that recognizes both the native kind and the user-defined kind? 04:46:28 I follow that. 04:47:07 Indeed, it is reasonable. It also requires a comparatively heavyweight condition system, much more so than SRFI 9, say, which does not even require record types to be reified. 04:47:59 The requirement on implementations, then, is that for each pre-existing condition type for which a standardized type exists, a false user condition type of that kind be created to serve as an abstract base type for user-defined conditions inheriting from that type. 04:48:10 If there are to be compound conditions (which we get for free), it becomes even more complicated. 04:48:54 s/get/don't get 04:48:57 jao [~user@cpe-76-166-198-241.socal.res.rr.com] has joined #scheme 04:49:09 I'm not sure what your plans are for handlers. Are you using generalized predicates to select them? 04:49:31 No, at least not at the base level. 04:50:03 I'm not sure why this scheme requires record types to be reified. 04:50:12 Er, condition types. 04:51:01 Certainly I'd think twice before doing that; attempts at doing so (e.g. through R6RS's procedural layer for records) have been abysmal failures, not least because the loss of hygiene information across phases makes it impossible to do so correctly. 04:51:10 At the base level, there is only a single handler in effect, which can defer to a condition or exit through a captured continuation. 04:51:52 s/to a condition/to an enclosing handler 04:51:59 Yikes. That doesn't compose. 04:52:22 How not? 04:53:38 For resumption semantics, call a CC inside the condition; for termination semantics, call one passed to the handler when it's established. 04:54:49 A procedure in program A (let's call it `p-a') calls a procedure in library B (let's call it `p-b') and passes it a thunk `p-a^'. `p-b' introduces a new handler; `p-a^' signals a condition. `p-b's handler does something silly under the assumption that the thunk won't signal any conditions. 04:54:56 Even when it *does* compose, it scales badly. 04:55:14 Rather than a more efficient handler search, you're now walking a linked list made out of closures. 04:56:02 Well-written handlers should defer when meeting conditions they do not understand. 04:56:08 A handler is basically a cond. 04:56:28 Good hygiene suggests that if `p-a^' signals a condition whose type is not visible to `p-b', the handler in `p-b' ought not to be able to intercept the condition. 04:56:59 That seems too fascist to me. Usually will not want to, yes; should not be able to, no. 04:57:36 Yes, that's what well-written handlers should do, but suggesting that all exception handlers be written in the form of (in C++ terms) catch (Exception e) { ... } seems wrong. 04:57:38 In particular, if p-b is a sandbox, it should be able to intercept and dispose of any and all conditions signaled by p-a^. 04:58:24 (That doesn't help with captured continuations, I grant.) 04:58:40 But that only means fully sandboxing Scheme is hard. 04:59:01 Sandboxing is a widly complicated problem. Conditions need to be thought about in the design of a sandbox, but it shouldn't be assumed that the ordinary mechanisms of the language are sufficient to express sandboxing. 04:59:10 I agree. 05:00:02 I don't understand the scaling argument, but never mind that now. 05:00:26 The only objection I have to what you have described is that it's "jist awfu complicated." 05:00:45 It's a simple argument. If dispatch is based on type, the appropriate handler can be selected efficiently. The scheme you proposed is a linear traversal of handlers. 05:01:15 Ah, I see. Yes. 05:01:54 I don't think suggesting that condition handlers ought not to be able to handle all conditions is any more fascist than any other form of program hygiene. Condition types ought to follow lexical rules, and only those who know the name of a condition should have claim to handle it. 05:01:55 If a handler is to be allowed to handle arbitrary objects, then you can't do better than linearly traversing them. 05:03:02 I will continue thinking. In any case, off to bed. 05:03:04 with me 05:03:53 That's not a bad idea. It's late. 05:04:17 Ye have my leave to depart. :-) 05:05:45 -!- jcowan [~John@cpe-98-14-172-204.nyc.res.rr.com] has left #scheme 05:22:24 -!- homie [~user@xdsl-78-34-237-59.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 05:22:43 -!- wbooze [~user@xdsl-78-34-237-59.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 05:29:52 chandler: A procedure like repl, or a handler for a web page request, etc. needs to be able to catch any exception without knowing the name. 05:40:51 -!- aidalgol [~user@202.36.179.65] has quit [Quit: Test time. (crapcrapcrapcrapcrapcrapcrapcrapcrap...!)] 05:49:02 Toekutr [~toekutr@adsl-69-107-109-7.dsl.pltn13.pacbell.net] has joined #scheme 06:05:22 rbarraud [~rbarraud@118-93-88-14.dsl.dyn.ihug.co.nz] has joined #scheme 06:06:34 -!- rbarraud__ [~rbarraud@118-92-0-92.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 248 seconds] 06:08:38 -!- jonrafkind [~jon@c-67-172-254-235.hsd1.ut.comcast.net] has quit [Ping timeout: 255 seconds] 06:09:25 TE263w` [~user@styldeks.am-1.org] has joined #scheme 06:11:23 -!- TE263w [~user@styldeks.am-1.org] has quit [Ping timeout: 260 seconds] 06:11:26 -!- e-future [~e-future@unaffiliated/sergio/x-8197433] has quit [Ping timeout: 265 seconds] 06:11:56 -!- leppie [~lolcow@196-215-63-152.dynamic.isadsl.co.za] has quit [Ping timeout: 265 seconds] 06:12:03 metasyntax` [~taylor@72.86.89.174] has joined #scheme 06:12:04 -!- gnomon_ [~ben@216.40.38.232] has quit [Ping timeout: 276 seconds] 06:12:28 -!- joast [~rick@76.178.178.72] has quit [Ping timeout: 240 seconds] 06:12:28 leppie [~lolcow@196-215-63-152.dynamic.isadsl.co.za] has joined #scheme 06:12:38 e-future [~e-future@unaffiliated/sergio/x-8197433] has joined #scheme 06:13:28 gnomon_ [~ben@216.40.38.232] has joined #scheme 06:13:52 -!- Obfuscate [~keii@ip98-176-17-38.sd.sd.cox.net] has quit [Ping timeout: 264 seconds] 06:13:52 -!- metasyntax [~taylor@72.86.89.174] has quit [Ping timeout: 264 seconds] 06:13:52 -!- bremner [~bremner@yantan.tethera.net] has quit [Ping timeout: 264 seconds] 06:14:14 bremner_ [~bremner@yantan.tethera.net] has joined #scheme 06:14:55 joast [~rick@76.178.178.72] has joined #scheme 06:15:11 Obfuscate [~keii@ip98-176-17-38.sd.sd.cox.net] has joined #scheme 06:20:06 -!- Riastradh [debian-tor@fsf/member/riastradh] has quit [Ping timeout: 246 seconds] 06:20:51 hohoho [~hohoho@p67f6db.tokynt01.ap.so-net.ne.jp] has joined #scheme 06:40:53 Riastradh [debian-tor@fsf/member/riastradh] has joined #scheme 07:01:48 ASau` [~user@77.246.230.215] has joined #scheme 07:11:01 -!- davazp [~user@83.54.164.142] has quit [Remote host closed the connection] 07:20:05 pdelgallego [~pdelgalle@1503031474.dhcp.dbnet.dk] has joined #scheme 07:22:40 -!- atomx [~user@93.112.81.240] has quit [Ping timeout: 240 seconds] 07:29:08 -!- rbarraud [~rbarraud@118-93-88-14.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 265 seconds] 07:30:52 slom [~sloma@port-87-234-239-162.static.qsc.de] has joined #scheme 07:40:14 gravicappa [~gravicapp@80.90.116.82] has joined #scheme 07:45:27 -!- jao [~user@cpe-76-166-198-241.socal.res.rr.com] has quit [Ping timeout: 240 seconds] 07:57:51 rbarraud [~rbarraud@118-93-88-14.dsl.dyn.ihug.co.nz] has joined #scheme 08:08:01 elderK [~elderK@pdpc/supporter/active/elderk] has joined #scheme 08:08:33 -!- mg4001 [~mg4001@cpe-76-93-28-217.socal.res.rr.com] has left #scheme 08:09:09 -!- elderK [~elderK@pdpc/supporter/active/elderk] has quit [Remote host closed the connection] 08:13:04 -!- Toekutr [~toekutr@adsl-69-107-109-7.dsl.pltn13.pacbell.net] has quit [Quit: REALITY IS TEARING ITSELF ASUNDER, BUT I MUST RACE] 08:31:06 -!- seangrove [~user@c-71-198-44-87.hsd1.ca.comcast.net] has quit [Ping timeout: 248 seconds] 08:33:24 chittoor [~chittoor@listertech.in] has joined #scheme 08:47:01 masm [~masm@bl19-138-98.dsl.telepac.pt] has joined #scheme 09:12:22 hkBst [~hkBst@gentoo/developer/hkbst] has joined #scheme 09:13:41 dfkjjkfd [~paulh@69-13-ftth.onsnetstudenten.nl] has joined #scheme 09:18:27 stis [~stis@1-1-1-39a.veo.vs.bostream.se] has joined #scheme 09:21:32 aidalgol [~user@118.148.162.3] has joined #scheme 09:40:13 schmir [~schmir@p54A906E1.dip0.t-ipconnect.de] has joined #scheme 09:42:22 -!- rbarraud [~rbarraud@118-93-88-14.dsl.dyn.ihug.co.nz] has quit [Read error: Connection reset by peer] 09:44:04 StucKman [~mdione@lakshmi.inria.fr] has joined #scheme 09:44:22 -!- StucKman [~mdione@lakshmi.inria.fr] has left #scheme 09:48:16 -!- eldragon [~eldragon@84.79.67.254] has quit [Read error: Connection reset by peer] 09:51:04 eldragon [~eldragon@84.79.67.254] has joined #scheme 09:55:34 -!- aidalgol [~user@118.148.162.3] has quit [Ping timeout: 276 seconds] 09:56:33 -!- ineiros is now known as ineiros_ 09:57:29 ineiros [~itniemin@james.ics.hut.fi] has joined #scheme 10:02:08 nik0 [~niko@freenode/staff/niko] has joined #scheme 10:04:17 -!- niko [~niko@freenode/staff/niko] has quit [Ping timeout: 619 seconds] 10:05:37 -!- nik0 is now known as niko 10:09:52 rbarraud [~rbarraud@118-93-88-14.dsl.dyn.ihug.co.nz] has joined #scheme 10:10:03 -!- jmcphers [~jmcphers@218.185.108.156] has quit [Remote host closed the connection] 10:10:43 jmcphers [~jmcphers@218.185.108.156] has joined #scheme 10:16:35 -!- 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] 10:19:10 aidalgol [~user@114-134-6-5.rurallink.co.nz] has joined #scheme 10:24:17 alvatar [~alvatar@28.126.222.87.dynamic.jazztel.es] has joined #scheme 10:24:32 atomx [~user@93.112.81.240] has joined #scheme 10:31:21 fradgers- [~fradgers-@5adafe9d.bb.sky.com] has joined #scheme 11:02:59 antoszka [~antoszka@unaffiliated/antoszka] has joined #scheme 11:12:48 -!- slom [~sloma@port-87-234-239-162.static.qsc.de] has quit [Remote host closed the connection] 11:19:16 -!- rbarraud [~rbarraud@118-93-88-14.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 245 seconds] 11:29:51 -!- aidalgol [~user@114-134-6-5.rurallink.co.nz] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 11:37:48 Checkie [1686@unaffiliated/checkie] has joined #scheme 11:51:08 -!- hkBst [~hkBst@gentoo/developer/hkbst] has quit [Remote host closed the connection] 12:12:34 pavelludiq [~user@87.246.30.76] has joined #scheme 12:14:53 -!- rotty [~rotty@nncmain.nicenamecrew.com] has quit [Ping timeout: 258 seconds] 12:17:59 -!- pavelludiq [~user@87.246.30.76] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 12:18:11 pavelludiq [~user@87.246.30.76] has joined #scheme 12:30:55 -!- EbiDK [~ebi@3e6b7ac3.rev.stofanet.dk] has quit [Ping timeout: 276 seconds] 12:31:08 Blkt [~user@93-33-132-104.ip44.fastwebnet.it] has joined #scheme 12:31:34 good day everyone 12:31:40 hi 12:34:21 karme [~user@static.180.75.40.188.clients.your-server.de] has joined #scheme 12:35:41 rotty [~rotty@nncmain.nicenamecrew.com] has joined #scheme 12:38:37 EbiDK [~ebi@3e6b7ac3.rev.stofanet.dk] has joined #scheme 12:56:04 Jafet [~Jafet@unaffiliated/jafet] has joined #scheme 13:08:06 luz [~davids@201.17.88.176] has joined #scheme 13:14:02 -!- karme [~user@static.180.75.40.188.clients.your-server.de] has quit [Remote host closed the connection] 13:15:35 -!- markatto [~markatto@kappa.citi.umich.edu] has quit [Ping timeout: 260 seconds] 13:24:52 -!- schmir [~schmir@p54A906E1.dip0.t-ipconnect.de] has quit [Ping timeout: 276 seconds] 13:28:25 bzzbzz [~franco@modemcable240.34-83-70.mc.videotron.ca] has joined #scheme 13:38:51 wbooze [~user@xdsl-87-79-172-183.netcologne.de] has joined #scheme 13:38:58 homie [~user@xdsl-87-79-172-183.netcologne.de] has joined #scheme 13:43:16 bweaver [~user@75-148-111-133-Chattanooga.hfc.comcastbusiness.net] has joined #scheme 13:44:43 MrFahrenheit [~RageOfTho@users-55-242.vinet.ba] has joined #scheme 13:50:41 langmartin [~user@exeuntcha2.tva.gov] has joined #scheme 13:58:24 -!- copumpkin is now known as snowboard 13:59:19 mmc [~michal@109.112.16.45] has joined #scheme 14:00:21 -!- snowboard is now known as copumpkin 14:13:10 davazp [~user@83.54.164.142] has joined #scheme 14:25:24 -!- mmc [~michal@109.112.16.45] has quit [Ping timeout: 265 seconds] 14:27:27 slom [~sloma@port-87-234-239-162.static.qsc.de] has joined #scheme 14:33:07 -!- hohoho [~hohoho@p67f6db.tokynt01.ap.so-net.ne.jp] has quit [Ping timeout: 276 seconds] 14:42:26 femtoo [~femto@95-89-188-214-dynip.superkabel.de] has joined #scheme 14:44:58 -!- gnomon_ [~ben@216.40.38.232] has quit [Quit: leaving] 14:48:22 markatto [~markatto@kappa.citi.umich.edu] has joined #scheme 14:49:32 pavellud` [~user@87.246.30.76] has joined #scheme 14:50:15 -!- slom [~sloma@port-87-234-239-162.static.qsc.de] has quit [Remote host closed the connection] 14:50:50 -!- pavelludiq [~user@87.246.30.76] has quit [Ping timeout: 248 seconds] 14:55:42 -!- soupdragon [~quantum@unaffiliated/fax] has quit [Quit: soupdragon] 15:17:07 Toekutr [~toekutr@adsl-69-107-109-7.dsl.pltn13.pacbell.net] has joined #scheme 15:20:23 -!- hosh_office [~hosh@c-71-204-27-0.hsd1.ga.comcast.net] has quit [Ping timeout: 265 seconds] 15:23:21 mmc [~michal@109.112.15.73] has joined #scheme 15:24:36 hosh_office [~hosh@c-71-204-27-0.hsd1.ga.comcast.net] has joined #scheme 15:30:51 -!- hosh_office [~hosh@c-71-204-27-0.hsd1.ga.comcast.net] has quit [Ping timeout: 240 seconds] 15:42:43 jewel [~jewel@196-215-88-46.dynamic.isadsl.co.za] has joined #scheme 15:43:23 jonrafkind [~jon@crystalis.cs.utah.edu] has joined #scheme 15:53:49 hosh_office [~hosh@c-71-204-27-0.hsd1.ga.comcast.net] has joined #scheme 15:56:47 -!- mmc [~michal@109.112.15.73] has quit [Ping timeout: 255 seconds] 16:00:12 NNshag [user@lns-bzn-60-82-254-199-39.adsl.proxad.net] has joined #scheme 16:01:41 mmc [~michal@109.112.15.73] has joined #scheme 16:02:55 -!- Nshag [user@lns-bzn-40-82-251-171-238.adsl.proxad.net] has quit [Ping timeout: 276 seconds] 16:10:16 -!- em is now known as emma 16:24:00 WLen [~Len@77.127.31.111] has joined #scheme 16:33:33 -!- femtoo [~femto@95-89-188-214-dynip.superkabel.de] has quit [Quit: Leaving] 16:35:44 caoliver [~oliver@75-134-208-20.dhcp.trcy.mi.charter.com] has joined #scheme 16:35:49 -!- caoliver [~oliver@75-134-208-20.dhcp.trcy.mi.charter.com] has quit [Remote host closed the connection] 16:36:11 caoliver [~oliver@75-134-208-20.dhcp.trcy.mi.charter.com] has joined #scheme 16:38:52 Style question: should one avoid internal defines if one doesn't mean to capture environment? E.g. I have a procedure specific to another proc. I could use an internal define/letrec to keep them together, but then the enclosing routine gets longish. What's the received wisdom here? 16:43:59 i like internal defines 16:44:01 If there is any reason to call A outside of B, then one should typically keep the definition of A outside the definition of B. That way, for example, one can test A at the REPL. However, if A is integrally tied to B and would require an unmanageable number of extra parameters to have its definition hoisted outside that of B, then one should usually put the definition of A inside B. 16:45:24 This is a small video frame editor, and I find the tweener (frame interpolation) routine is very big (a few pages) if I roll all the tweener specific routines inside. 16:45:39 small = 1/2kloc 16:46:23 Why put them all inside the routine? 16:46:30 I tend to like to see all of a routine on one screen height of emacs without using hide/show. 16:46:56 Because the subordinate procs are used only in one routine. 16:47:11 They don't have a separate general purpose. 16:48:24 BTW: thanks for entertaining this discussion. I'm really lost here. Things work, but I'm unhappy with the code's organization. 16:48:49 Ask your editor to collapse the definitions. Or give your screen a quarter-turn... 16:49:22 I mentioned hide/show which I used muchly when hacking this thing up. 16:49:26 If you like to separate the definitions because it makes the program easier to understand, then by all means do so. That's what I'd do. 16:50:14 I was tending to think that if I'm not capturing an environment, I should avoid internal defns. 16:50:28 Even if a subroutine may not have a general purpose, it may have a concept that can be understood mostly separately from the enclosing routine, in which case separating its definition may make the program more understandable. 16:52:04 I'm tending to think that way. Otherwise the subroutine tends to get lost in the visual noise, not to mention that emacs indents the line comments flush left anyhow. 16:52:22 Huh? 16:53:18 Emacs doesn't indent line comments (two semicolons) flush left. It indents top-level comments (three semicolons) flush left, but line comments it indents like code. 16:53:51 Ok. I tend to ;;; subroutine comments. 16:55:02 Well, that's why Emacs is putting them at the left margin, then! Use ;; for comments that apply to the expression on the following line, and Emacs will indent them next to it. 16:55:03 ;;; This is a top-level definition. 16:55:03 16:55:03 (define (frob grovel) 16:55:03 ;; Here's a comment about fnords. 16:55:03 (fnord grovel mumble frotz)) 16:57:13 ;;; Warning! Tangle below 16:57:14 (define tangle... 16:57:15 ;;; Tangle's helper fn 16:57:15 (define tangle% ... 16:58:16 ;; Comments don't seem important enough for a procedure heading, and ;;; indents flush left. 16:59:46 s/procedure heading/definition at any level/ 16:59:52 I don't see a definition after FROB. Is there something between that and ";;; Warning! Tangle below"? 16:59:53 seangrove [~user@c-71-198-44-87.hsd1.ca.comcast.net] has joined #scheme 17:00:02 -!- mmc [~michal@109.112.15.73] has quit [Ping timeout: 264 seconds] 17:00:43 gnomon: We're discussing comment style. ;;, ;;;, and ;;;; 17:00:57 That looked odd. 17:01:30 caoliver, I understand. I was making a joke about http://www.rawilson.com/illuminatus.html#fnord 17:01:37 No, gnomon, I just missed that line when pasting. Here it is: 17:01:38 (grovel mumble frotz)) 17:01:53 Oh, the comment must have been cut off too. Anyway, it wasn't important. 17:02:02 -!- IceD^ [~iced@live.bn.by] has quit [Ping timeout: 255 seconds] 17:02:22 It's why ducks eat trees. 17:03:33 Thanks for letting me mumble. I think I know how I want to organize this now. 17:03:56 *caoliver* needs loud music. 17:08:54 -!- gravicappa [~gravicapp@80.90.116.82] has quit [Ping timeout: 258 seconds] 17:13:50 -!- mjonsson_ [~mjonsson@cpe-98-14-173-5.nyc.res.rr.com] has quit [Ping timeout: 264 seconds] 17:16:00 mjonsson_ [~mjonsson@cpe-98-14-173-5.nyc.res.rr.com] has joined #scheme 17:20:36 metasyntax [~taylor@12.132.219.7] has joined #scheme 17:21:52 -!- WLen [~Len@77.127.31.111] has quit [Quit: leaving] 17:23:38 -!- caoliver [~oliver@75-134-208-20.dhcp.trcy.mi.charter.com] has quit [Remote host closed the connection] 17:27:33 -!- metasyntax is now known as metasyntax`` 17:27:44 WLen [~Len@77.127.31.111] has joined #scheme 17:32:49 saccade_ [~saccade@209-6-54-113.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has joined #scheme 17:35:09 hohoho [~hohoho@ntkngw229253.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 17:41:53 mg4001 [~mg4001@cpe-76-93-28-217.socal.res.rr.com] has joined #scheme 17:53:16 -!- hohoho [~hohoho@ntkngw229253.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Remote host closed the connection] 17:55:14 pumpkin [~copumpkin@94.167.101.117] has joined #scheme 17:55:27 -!- copumpkin [~copumpkin@94.166.54.176] has quit [Ping timeout: 240 seconds] 17:57:58 jao [~user@173.243.145.79] has joined #scheme 17:59:55 femtoo [~femto@95-89-188-214-dynip.superkabel.de] has joined #scheme 18:06:25 hohoho [~hohoho@ntkngw229253.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 18:18:38 -!- ASau [~user@83.69.227.32] has quit [Read error: Connection reset by peer] 18:20:50 Fare [~Fare@ita4fw1.itasoftware.com] has joined #scheme 18:25:40 -!- Jafet [~Jafet@unaffiliated/jafet] has quit [Ping timeout: 240 seconds] 18:32:10 -!- 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] 18:42:11 -!- e-future [~e-future@unaffiliated/sergio/x-8197433] has quit [Ping timeout: 240 seconds] 18:42:22 compplusplus [~kvirc@nat07.lluga.net] has joined #scheme 18:51:21 gravicappa [~gravicapp@ppp85-140-67-171.pppoe.mtu-net.ru] has joined #scheme 18:51:28 -!- davazp [~user@83.54.164.142] has quit [Read error: Connection reset by peer] 18:58:15 ASau [~user@83.69.227.32] has joined #scheme 19:08:10 -!- pumpkin [~copumpkin@94.167.101.117] has quit [Ping timeout: 276 seconds] 19:09:20 schmir [~schmir@p54A917B3.dip0.t-ipconnect.de] has joined #scheme 19:09:50 copumpkin [~copumpkin@94.166.83.186] has joined #scheme 19:09:54 saccade_ [~saccade@BRAIN-AND-COG-FIVE-THIRTY-SEVEN.MIT.EDU] has joined #scheme 19:16:33 -!- pdelgallego [~pdelgalle@1503031474.dhcp.dbnet.dk] has quit [Ping timeout: 258 seconds] 19:16:47 -!- compplusplus [~kvirc@nat07.lluga.net] has quit [Quit: When two people dream the same dream, it ceases to be an illusion. KVIrc 3.4.3 Shiny(svn-3438) http://www.kvirc.net] 19:17:03 Foo! 19:19:06 proq [~user@unaffiliated/proqesi] has joined #scheme 19:19:08 Bar! 19:20:27 Baz! 19:21:06 Quux! 19:21:22 or did I skip one? 19:21:47 No, you're good. Next up: 19:21:49 Zot! 19:22:43 foof: Sorry, I was unclear. What I meant to say was that it ought to be lexically apparent what conditions a given program handles, and thus if you need to handle all error-like conditions then there should be a name associated with that type. I'm not sure that a web server actually needs to handle all conditions, though. 19:23:20 Riastradh, what's after zot? Frobbotz? 19:23:27 -!- seangrove [~user@c-71-198-44-87.hsd1.ca.comcast.net] has quit [Ping timeout: 258 seconds] 19:23:27 (with-condition-handling-is-hard (lambda () (lets-go shopping))) 19:24:19 *gnomon* notices that the top google hit for "foo bar baz quux zot" is paredit 19:24:24 gnomon, well, after zot it becomes less canonical, but often `mumble' and `frotz' go together. What is certain, though, is that if there is `mumble' and there is `frotz', then never shall there be any betwixt the twain. 19:24:25 foof: Unless you're working with immediate-unwind semantics, it's not the condition handler that's problematic in the case of a web server, it's the action (or restart) that's taken in response to the condition. 19:26:03 foof: The invocation of a condition handler does not remove the web server loop from the current continuation. Calling some other continuation in response might, however. This situation can occur outside of a condition handler as well, and needs to be handle generally. 19:27:25 "handled" 19:28:44 "chandled" 19:32:39 foof: It's not clear to me that it's sensible to handle the set of all conditions or the set of "serious" or "error-like" conditions. It might be more sensible to parameterize a default prompt / prefix of the current continuation which is aborted to when an error-like condition with no active handlers is signalled. 19:33:48 -!- schmir [~schmir@p54A917B3.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds] 19:33:53 foof: It might also be sensible to interdict *all* attempts to remove a given prompt from the current continuation. 19:34:39 schmir [~schmir@p54A910EB.dip0.t-ipconnect.de] has joined #scheme 19:34:52 foof: It's probably *not* a good idea to introduce a requirement that a useful REPL should be expressible using only the procedures and syntax in the report. REPLs are complex. 19:37:39 seangrove [~user@user-64-9-233-108.googlewifi.com] has joined #scheme 19:37:45 chandler, consider the following networked, sandboxed evaluation program: (define (main argv) (bind-listen-accept-loop (car argv) (lambda (in out) (let loop () (write (eval (read in) (interaction-environment)) out) (loop]. Assume that there are no network errors. I want to report problems to clients, but never halt the REPL unless the client asks for it in particular, and certainly never halt the accept loop. 19:38:57 How would you realize these desiderata? 19:43:25 Let's ignore conditions for the moment. 19:44:12 How do you prevent this REPL-ish program from calling some continuation available to it in the interaction environment that does not contain (is that the right verb?) the accept loop and REPL loop? 19:44:54 We'll just sandbox the interaction environment. (with-interaction-environment (make-fresh-environment (scheme-report-environment 5)) (lambda () ...)) 19:45:00 RageOfThou [~RageOfTho@users-33-142.vinet.ba] has joined #scheme 19:46:56 Forget the interaction environment; replace `(interaction-environment)' by `(scheme-report-environment 5)'. 19:47:15 So there's no way for the clients to get at such continuations. 19:47:34 -!- alvatar [~alvatar@28.126.222.87.dynamic.jazztel.es] has quit [Quit: leaving] 19:48:16 Assume for the moment that it isn't that easy. The problem with default condition handlers is that they amount to an abort to a prompt that's set as a default somewhere. If it's possible to interdict this abort, then it's possible to continue running the eval loop. Alternatively, if it's possible to parameterize this prompt, it'd be simple to ensure that unhandled errors wind up aborting to a prompt defined in the loop. 19:49:08 -!- MrFahrenheit [~RageOfTho@users-55-242.vinet.ba] has quit [Ping timeout: 265 seconds] 19:50:27 pdelgallego [~pdelgalle@1503031474.dhcp.dbnet.dk] has joined #scheme 19:50:32 fowlduck [~fowlduck@2002:4547:f82e:0:fa1e:dfff:fed7:9dc1] has joined #scheme 19:51:05 Suppose the default condition handler exits the program with a nonzero value. 19:51:24 Don't define your condition system that way. 19:51:47 In that case, what should (define (main argv) (error "Lose!")) do? 19:51:53 I'm not trying to be blithe, but this is a discussion about how to define a condition system, such semantics are avoidable. 19:52:16 Turn that second comma into a semicolon there, please. 19:53:20 That's fine -- I just want to see a global view of the consequences on practical program behaviour of how you would like a condition system to be set up. 19:54:29 If you want the exit-on-error semantics, then the continuation of the default error-not-handled prompt should be a call to `exit'. 19:57:39 Let me just take a step back for a moment. We're on Unix. I execute a Scheme program, effectively calling the procedure defined by (define (main argv) ...) somewhere. What do you want to happen when MAIN signals a condition, before it has established any condition handler? 20:01:10 Ideally, I'd like the implementation to provide a recursive REPL for debugging the problem. (Is that not what you're looking for?) 20:01:35 I'm assuming that such a debugger need not be expressible using only the procedures and syntax defined in the WG1 report. 20:03:09 OK. That's one answer, but now suppose I want to use this program totally non-interactively. 20:03:53 How do I guarantee that if it does anything other than succeed, the process exits with a nonzero status? 20:04:03 That is, what do I have to do in MAIN to guarantee this? 20:04:18 (or, what would you like one to have to do in MAIN?) 20:05:59 fda314925 [~fda314925@211.239.124.232] has joined #scheme 20:09:08 I'm thinking about it. It's no longer clear to me that what I was thinking of a few minutes ago makes any sense at all. 20:14:01 -!- femtoo [~femto@95-89-188-214-dynip.superkabel.de] has quit [Quit: Leaving] 20:16:43 Sometimes, it is nice to assume that I am running my programs in a Lisp machine where if anything unforeseen goes wrong, of course I can just tell it how to proceed when it prompts me with a debugger. However, sometimes, that is not the case at all, particularly in order to write robust programs that don't require babysitters. 20:19:38 Indeed, but it seems to me that handling all conditions is a rather nasty operation that makes it difficult to reason about what condition handler will be invoked when a given condition is signalled. 20:20:18 It would be especially nice if condition handlers followed lexical rules. 20:21:13 This suggests to me that defining what happens when no handler is found for a condition is preferable to handling all conditions. 20:21:35 seangrov` [~user@173-116-13-69.pools.spcsdns.net] has joined #scheme 20:22:44 -!- seangrove [~user@user-64-9-233-108.googlewifi.com] has quit [Ping timeout: 255 seconds] 20:22:52 -!- schmir [~schmir@p54A910EB.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 20:24:50 schmir [~schmir@p54A915BA.dip0.t-ipconnect.de] has joined #scheme 20:38:26 bill_h [~hager@c-98-231-14-62.hsd1.fl.comcast.net] has joined #scheme 20:48:22 -!- Fare [~Fare@ita4fw1.itasoftware.com] has quit [Quit: Leaving] 20:49:13 martinhex [~mjc@93-97-29-243.zone5.bethere.co.uk] has joined #scheme 20:52:47 -!- pdelgallego [~pdelgalle@1503031474.dhcp.dbnet.dk] has quit [Quit: Leaving] 20:54:23 -!- jewel [~jewel@196-215-88-46.dynamic.isadsl.co.za] has quit [Ping timeout: 265 seconds] 20:57:33 bill_h pasted "racket web-server send/suspend" at http://paste.lisp.org/display/113617 20:58:33 is anyone familiar with racket's web server and send/suspend? I am failing miserably with even the simplest case. Anyone see where I'm going wrong in the paste? 20:59:09 pdelgallego [~pdelgalle@1503031474.dhcp.dbnet.dk] has joined #scheme 20:59:43 bill_h, i recommend asking on #racket 21:00:04 Thanks 21:06:50 aidalgol [~user@202.36.179.65] has joined #scheme 21:08:22 jcowan [c6b912cf@gateway/web/freenode/ip.198.185.18.207] has joined #scheme 21:10:47 Speak to me of compound conditions. Do they really make sense? Are they actually useful? 21:11:30 Does anyone have experience with them, and if so, for doing what? 21:13:43 jcowan, Racket doesn't have them (if I understand what they are correctly) and I've never missed them 21:14:47 I've never missed low-level macros, either. :-) 21:17:00 In short, a compound condition is an object that is constructed by merging several conditions (not condition types) and answers #t to all their predicates, as well as responding "correctly" to all their accessors, except that if a CC contains conditions with overlapping slot names, it searches the base conditions left-to-right for the first one with the appropriate slot. 21:17:30 fod [~fod@92.251.255.6.threembb.ie] has joined #scheme 21:17:30 Thus base conditions must be introspectable at run time so that this can be done, unlike most other Scheme objects. 21:18:00 The theory is that one may want to have a condition that reports, e.g. both a network error and a file error (because the file system in question is distributed) and can be caught by handlers interested in either. 21:20:29 -!- langmartin [~user@exeuntcha2.tva.gov] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 21:20:35 right, that's what i thought 21:21:23 so, obv the tyranny of the primary decomposition is no fun 21:21:42 but if your conditions are extensible, then you just have to pick a place to put that error 21:21:55 Otherwise conditions are just records with single inheritance, and I really do not want to duplicate all that machinery just to do this one magic thing. 21:21:57 and you can define a predicate that behaves the way you want 21:22:19 *sigh* Everyone says "And you can define a predicate", but that does not compose. 21:22:19 why shouldn't conditions just be that? 21:22:48 (Side note: does Racket do R6RS?) 21:22:51 perhaps you mean something that i don't expect by 'compose' 21:23:13 jcowan, yes, see: http://docs.racket-lang.org/r6rs/index.html 21:23:26 If I want to extend the behavior of a predicate, I can redefine it to do what I want. If you want to extend etc. etc. But if we both want to? 21:23:38 we define new predicates 21:23:39 Redefine? 21:24:47 Azuvix [~Azuvix@174-19-234-140.bois.qwest.net] has joined #scheme 21:24:52 If I wish to alter the behavior of the procedure called "+", then redefining + is necessary and sufficient. But only one agency in a system can do so successfully. 21:25:00 -!- Adamant [~Adamant@unaffiliated/adamant] has quit [Quit: Adamant] 21:25:07 er, reassigning. 21:25:19 Assigning + is not kosher. 21:25:21 jcowan, i'm thinking of extensibility via binding rather than via assignment 21:25:27 Shadowing is a different matter. 21:26:31 if you want to add a new condition that both network and file condition handlers respond to, then yes, you're out of luck (unless the original author made the predicate extensible) 21:26:46 Ah. How is a predicate made extensible? 21:26:59 the same way anything else can be made extensible in Scheme 21:27:08 there are lots of techniques for this 21:27:33 the predicate is just a function - i'm not imagining any special kind of 'extensible predicate' 21:28:05 -!- jmcphers [~jmcphers@218.185.108.156] has quit [Remote host closed the connection] 21:28:38 as it happens, Racket has a nice mechanism for struct extesibility that would be useful here 21:28:46 Pointer? 21:28:46 jmcphers [~jmcphers@218.185.108.156] has joined #scheme 21:28:48 but i don't think this issue has anything to do with conditions 21:29:11 -!- schmir [~schmir@p54A915BA.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds] 21:29:21 http://docs.racket-lang.org/reference/structprops.html 21:29:31 schmir [~schmir@p54A90E72.dip0.t-ipconnect.de] has joined #scheme 21:29:55 -!- Azuvix is now known as Saluteman 21:31:04 Well, Racket does have compound conditions, then, at least if you import (rnrs conditions (6)). 21:31:36 -!- seangrov` [~user@173-116-13-69.pools.spcsdns.net] has quit [Remote host closed the connection] 21:32:07 however, those do not answer #t to exn? in the rest of Racket 21:32:08 gtg 21:32:11 -!- samth is now known as samth_away 21:32:16 I was trying to make a case for Racket being quite different from PLT Scheme in many ways... does that seem accurate? 21:32:23 seangrove [~user@173-116-13-69.pools.spcsdns.net] has joined #scheme 21:32:34 Saluteman, that case would be hard to make, since the claim is false 21:32:40 Racket == PLT Scheme 21:32:58 Except for a lot of syntax, extra goodies thrown in... 21:33:20 Saluteman, those were all in PLT Scheme 21:33:28 Racket is just a new name 21:33:39 Including for loops and an enter! instead of load statement? 21:34:17 PLT, whatever it is called, grows bigger over time, so of course new releases, whether accompanied by changes of name or not, will have features not in old releases. 21:34:33 -!- stis [~stis@1-1-1-39a.veo.vs.bostream.se] has quit [Remote host closed the connection] 21:34:55 Which, to me, says "different". 21:35:49 Racket is not really more different from PLT Scheme than MIT Scheme 9.0.1 is from MIT Scheme 7.7.90... 21:36:07 Hmm. 21:36:46 I think there are may be more differences between PLT Scheme 100 and PLT Scheme 200 than there are between PLT Scheme v4 and Racket v5. 21:36:55 More fundamental differences, that is. 21:37:00 Time will tell whether the change of name is a marketing stunt, a signal of an intended change in direction, or a footnote to history. 21:37:11 -!- schmir [~schmir@p54A90E72.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 21:37:12 (1 sentence, 4 cliches!) 21:37:28 jcowan: Applause. 21:40:34 Racket is the Merrill Lynch of Scheme (or what ML was before it overreached and got bought up cheap) 21:41:23 Okay, I think I've got it. 21:41:37 -!- fradgers- [~fradgers-@5adafe9d.bb.sky.com] has left #scheme 21:42:22 schmir [~schmir@p54A911BA.dip0.t-ipconnect.de] has joined #scheme 21:43:15 *alaricsp* joins the party 21:43:20 'lo jcowan 21:43:36 Adamant [~Adamant@unaffiliated/adamant] has joined #scheme 21:43:45 The issue I feel here is that the "multiple inheritance" nature of conditions is something that's useful far beyond conditions 21:43:57 -!- gravicappa [~gravicapp@ppp85-140-67-171.pppoe.mtu-net.ru] has quit [Ping timeout: 240 seconds] 21:44:22 And so designing a complex condition system (or even a simple one!) that captures it is likely to be WRONG AND EVIL in my idealistic world-view, unless it's done as a general mechanism for compound-typed objects that then gets used for conditions ;-) 21:45:31 All this talk of conditions that respond to arbitrary numbers of type predicates, and have all the slots "expected" by these different type predicates says "we are desinging a record system with inheritance" to me 21:45:37 Can we perhaps talk in terms of real programs and practical systems, rather than in terms of world views, idealistic or otherwise? 21:45:54 If we design something with all those features, then it'll also be quite useful as a record system... 21:46:01 Riastradh: Ha! A novel idea! It'll never take off. 21:46:02 I originally asked for people with actual experience, as you will see up-log. Complete silence. 21:46:44 I'd like to hear an answer to the question too. 21:46:47 *jcowan* takes the fascist approach to slot-name conflicts under multiple inheritance: "That would be an error, d00d." 21:46:59 There may be an application lurking in Scheme48. 21:47:42 Alas, the rest of the word uses "compound condition" to mean "boolean expression containing at least one AND or OR", it seems 21:48:21 Oopsy 21:49:50 -!- Checkie [1686@unaffiliated/checkie] has quit [Ping timeout: 264 seconds] 21:50:39 CL has compound conditions too, but does them at the type level, not at the instance level. 21:51:15 That's an interesting point. I wonder which is better? 21:53:26 -!- seangrove [~user@173-116-13-69.pools.spcsdns.net] has quit [Ping timeout: 264 seconds] 21:53:44 Doing them at the type level means that you don't have to have introspection, anyhow. But it also means more machinery for the user. 21:53:54 -!- aidalgol [~user@202.36.179.65] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 21:54:05 I do think it's a valid point, though, that this nice system for classifying things with properties *is a record system* (or some superset such as an OO system, depending on where you draw your lines), given that it really needs a user-visible condition definition mechanism; there's then a temptation to use conditions as a record system, if one isn't otherwise defined. And if one is otherwise defined, why not use it for conditions? 21:55:25 Well, the arguments against MI are well known and I don't think I have to rehash them. The argument for MI for conditions that makes some sense to me is that you may want to be a subtype of some other type, and also grab some useful slots from elsewhere so that people who want to look in those slots can do so. 21:56:21 Java (which does not have MI) provides a couple of useful slots at the root (Throwable): message string, embedded condition (for when a condition handler wraps the incoming condition in a new condition and resignals it), stack trace, and a few more. 21:56:22 -!- Saluteman is now known as Azuvix 21:57:42 Yeah 21:57:49 OTOH, the condition system as we find it in R6RS conflates subtyping and inheritance very badly. FOO-CONDITION may inherit from BAR-CONDITION because a foo is a type of bar, or just because it likes BAR-CONDITION's slots. 21:58:56 Novice OO programmers love inheriting classes to get at their functionality, when they should delegate ;-) 22:00:54 'tho I hate the condition embedding in Java; it's a consequence of the controversial practice of requiring all exceptions to be listed in a method's signature, thereby forcing the endless wrapping into generic "LibraryException" classes in order to break out of the exception type system. 22:03:46 Agreed. 22:04:13 Here it's not functionality but recognizability; if I inherit from you, people will see me as you. 22:04:35 hypercube32 [~hypercube@169-91.202-68.tampabay.res.rr.com] has joined #scheme 22:04:40 Yes 22:05:28 And not having "methods in classes", but instead having GFs, removes much of the temptation to inherit-for-behaviour, which cleans things up a bit: the mind is focussed more on public interfaces when inheriting. 22:06:40 I guess the burning question is "Is there a way of providing desired functionality without having to actually build an MI record system" 22:06:51 Well, how desired is it, really? 22:07:57 If we just forget about compound conditions and MI, all we need is to have a few standard types providing a basic set of implementation-specified conditions. 22:08:15 I'm not sure. As a general principle, if people desire it, I'd like WG1 to either provide it, or the tools with which it can be portably built, where possible. 22:08:53 However, proving their desire for it to be ill-founded is also an option: "It can be done just as well with a simpler mechanism", for example 22:10:18 A portable implementation requires introspection, though. Do you really want to saddle the record system with introspection? 22:10:47 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Quit: leaving] 22:11:21 pchrist [~spirit@gentoo/developer/pchrist] has joined #scheme 22:12:17 Ideally not, but I want to look further into the costs of it before forming a final decision on that! It's certainly scope for being optional, though 22:12:34 A plausible list of system condition types: simple (what you get from ERROR), assertion-failure, implementation-restriction, domain-error, syntax-error, lexical-syntax-error, undefined-variable, i/o-error. 22:12:48 Does that sound necessary and sufficient, offhand? 22:13:14 (thank you (implementers)) 22:13:35 Anyhow, must run. Thanks and farewell. 22:13:38 or rather, (thank (you) (implementers)) 22:13:48 -!- jcowan [c6b912cf@gateway/web/freenode/ip.198.185.18.207] has quit [Quit: Page closed] 22:16:49 As long as i/o-error is broad enough to cover things like "(current-seconds-since-epoch) failed as the system clock has not been set yet" and the various errnos that can be returned from syscalls other than socket stuff, yeah (I'd argue it's still i/o as it's communicating with the OS kernel, which is still outside the process), yeah 22:18:18 bgs100 [~ian@unaffiliated/bgs100] has joined #scheme 22:18:33 Arguably, perhaps a permissions-error should be introduced, distinct from i/o-error... perhaps. 22:25:57 -!- fod [~fod@92.251.255.6.threembb.ie] has quit [Ping timeout: 240 seconds] 22:26:24 fod [~fod@92.251.255.6.threembb.ie] has joined #scheme 22:27:05 -!- schmir [~schmir@p54A911BA.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 22:27:48 mmc [~michal@93-39-40-29.ip74.fastwebnet.it] has joined #scheme 22:30:01 -!- ray [ray@xkcd-sucks.org] has quit [Read error: Connection reset by peer] 22:31:04 ray [ray@xkcd-sucks.org] has joined #scheme 22:34:47 -!- chittoor [~chittoor@listertech.in] has quit [Quit: Leaving] 22:35:56 schmir [~schmir@p54A911BA.dip0.t-ipconnect.de] has joined #scheme 22:43:03 -!- schmir [~schmir@p54A911BA.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds] 22:44:07 rbarraud [~rbarraud@118-93-88-14.dsl.dyn.ihug.co.nz] has joined #scheme 23:04:14 -!- bweaver [~user@75-148-111-133-Chattanooga.hfc.comcastbusiness.net] has quit [Ping timeout: 264 seconds] 23:05:56 chandler: Every server I've ever written has started off by wrapping all request handlers with a catch-all exception handler. Even if not running sandboxed code, I develop quickly and can't forsee every exception that might be passed out of the handler, so it's a huge time saver not to list them all up front. 23:10:31 seangrove [~user@70-36-236-168.dsl.static.sonic.net] has joined #scheme 23:16:36 In particular, for my web server I run servelt-like apps loaded dynamically from disk. Any set of exceptions would be incomplete in that case. 23:18:56 Komi [Komi@62.32.134.47] has joined #scheme 23:19:13 aidalgol [~user@202.36.179.65] has joined #scheme 23:22:22 foof: Does the server need to *handle* the exception, or just specify what happens when the exception is not otherwise handled? 23:24:19 Specify what happens when the exception is not otherwise handled. 23:26:08 Well, generally log the error and kill the connection, though if it were an option dropping into a debugger accessible on a local socket would be a nice option. 23:37:09 -!- Azuvix [~Azuvix@174-19-234-140.bois.qwest.net] has quit [Quit: [TalkSoup] Get it today: http://talksoup.aeruder.net] 23:41:30 -!- saccade_ [~saccade@BRAIN-AND-COG-FIVE-THIRTY-SEVEN.MIT.EDU] has quit [Ping timeout: 248 seconds] 23:46:09 saccade_ [~saccade@dhcp-18-111-82-90.dyn.mit.edu] has joined #scheme 23:51:51 -!- aidalgol [~user@202.36.179.65] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 23:54:09 -!- bremner_ [~bremner@yantan.tethera.net] has quit [Quit: ZNC - http://znc.sourceforge.net] 23:54:33 bremner [~bremner@yantan.tethera.net] has joined #scheme 23:54:43 -!- seangrove [~user@70-36-236-168.dsl.static.sonic.net] has quit [Ping timeout: 276 seconds] 23:59:10 -!- saccade_ [~saccade@dhcp-18-111-82-90.dyn.mit.edu] has quit [Ping timeout: 252 seconds]