00:04:21 -!- Edico [n=Edico@unaffiliated/edico] has quit ["Leaving"] 00:04:29 mmt, Scheme will no longer block all threads and keyboard interrupts if you try to open a fifo on whose other end no one is waiting. 00:17:59 elf__ [i=elf@antenora.aculei.net] has joined #scheme 00:18:31 -!- elf__ [i=elf@antenora.aculei.net] has quit [Client Quit] 00:30:07 -!- attila_lendvai_ [n=ati@business-89-132-61-222.business.broadband.hu] has quit [Read error: 113 (No route to host)] 00:32:14 -!- annodomini_ [n=lambda@wikipedia/lambda] has quit [] 00:45:49 -!- errordeveloper [n=errordev@78-86-1-110.zone2.bethere.co.uk] has quit [Connection reset by peer] 00:49:18 errordeveloper [n=errordev@78-86-1-110.zone2.bethere.co.uk] has joined #scheme 01:05:39 orgy_ [n=ratm_@pD9FFC3CB.dip.t-dialin.net] has joined #scheme 01:16:36 -!- amaron [n=amaron@cable-94-189-243-158.dynamic.sbb.rs] has quit [Read error: 110 (Connection timed out)] 01:21:56 -!- orgy` [n=ratm_@pD9FFD85F.dip.t-dialin.net] has quit [Read error: 110 (Connection timed out)] 01:25:28 -!- X-Scale [i=email@2001:470:1f08:b3d:0:0:0:2] has quit [Read error: 110 (Connection timed out)] 01:38:39 kniu [n=kniu@pool-71-165-128-172.lsanca.dsl-w.verizon.net] has joined #scheme 01:40:46 -!- elias` [n=me@unaffiliated/elias/x-342423] has quit [Read error: 145 (Connection timed out)] 01:43:15 -!- berat [n=berat@85.110.166.73] has quit [Read error: 110 (Connection timed out)] 01:43:40 berat [n=berat@88.228.58.71] has joined #scheme 01:47:15 johnnowak [n=johnnowa@207-38-171-48.c3-0.wsd-ubr1.qens-wsd.ny.cable.rcn.com] has joined #scheme 01:51:56 -!- hadronzoo [n=hadronzo@gateway.publicvpn.net] has quit [] 01:56:07 -!- benny [n=benny@i577A10CC.versanet.de] has quit [Read error: 110 (Connection timed out)] 01:58:34 -!- AtnNn [n=welcome@modemcable087.62-56-74.mc.videotron.ca] has quit [Read error: 110 (Connection timed out)] 02:08:41 -!- johnnowak [n=johnnowa@207-38-171-48.c3-0.wsd-ubr1.qens-wsd.ny.cable.rcn.com] has quit [] 02:29:12 X-Scale [i=email@2001:470:1f08:b3d:0:0:0:2] has joined #scheme 02:42:24 -!- errordeveloper [n=errordev@78-86-1-110.zone2.bethere.co.uk] has quit [Read error: 110 (Connection timed out)] 02:49:01 -!- kilimanjaro [n=kilimanj@70.116.95.163] has quit ["Leaving"] 02:55:39 Does anyone know rougly how many "major" Scheme implementations use a segmented memory scheme for Heap and/or Stack allocation, and how many just use a single flat contiguous region? 02:55:51 s/roug/rough 02:56:23 khmer 02:56:32 *crickets* 02:57:27 -!- athos [n=philipp@92.250.204.223] has quit ["leaving"] 03:02:20 Can you be more specific, arcfide? 03:02:39 Are you talking about something like Chez's meta-BIBOP scheme? 03:02:49 I believe so. 03:03:45 Recent versions of Scheme48 have optional support for a scheme like Chez's. 03:03:58 I don't think anyone else does, though, except perhaps for Ikarus. 03:04:41 Hrm, what is the more common scheme for handling the allocation of memory? 03:05:13 Well, are you talking about allocating pages of memory from the operating system, or are you talking about allocating space for objects on a heap? 03:05:24 Or: what do you intend to do with this information? 03:05:50 Even plt has malloc. I try to kill it when I see it though. 03:06:07 When Chez Scheme allocates space for objects, it has a set of memory segments or regions that it tracks, and when it needs more memory, it just grabs another segment. 03:06:10 -!- kniu [n=kniu@pool-71-165-128-172.lsanca.dsl-w.verizon.net] has quit [Connection timed out] 03:06:36 In a recent presentation, Kent indicated that the nature of heep and stack allocation in Chez Scheme was one of the key factors in deciding to pursure native threading when a request for it came in. 03:07:01 Uriah? 03:07:01 I don't know what he meant by that. 03:07:19 kniu [n=kniu@pool-71-165-128-172.lsanca.dsl-w.verizon.net] has joined #scheme 03:07:39 Chez Scheme allocates segments to each thread when they are spawned, which makes the GC "feasible" in some reliable way, according to the talk. 03:08:06 If the memory were, say, allocated in one big spot, then apparently, it is much harder to handle the way the GC is done. I don't know, I was curious about it. 03:09:21 I don't know all the details to Chez Scheme's memory or threading, though, so I don't have enough information to really explain what goes on, but there is some sort of segment to thread relationship that allows threads to be more easily handled as relates to memory allocation and garbagce collection. 03:10:02 I was curious to see how many other Schemes have a model similiar. 03:10:18 Why don't you ask to look at the Chez source code to see how it works? 03:10:18 Anyways, I'm off to eat Dinner. 03:10:51 Riastradh: I'm certainly not about to undertake such a task. Even were Chez Open-Source, it's not that big a deal to me, and I don't want to know all those hairy details. 03:17:26 -!- Arelius [n=Indy@netblock-68-183-230-134.dslextreme.com] has quit [] 03:18:06 AtnNn_ [n=welcome@modemcable087.62-56-74.mc.videotron.ca] has joined #scheme 03:19:17 hadronzoo [n=hadronzo@ppp-70-247-161-87.dsl.rcsntx.swbell.net] has joined #scheme 03:25:38 -!- AtnNn_ [n=welcome@modemcable087.62-56-74.mc.videotron.ca] has quit [Remote closed the connection] 03:26:18 harsha_v [n=chatzill@66.250.143.213] has joined #scheme 03:26:28 AtnNn [n=welcome@modemcable087.62-56-74.mc.videotron.ca] has joined #scheme 03:26:58 -!- harsha_v [n=chatzill@66.250.143.213] has left #scheme 03:30:40 -!- masm [n=masm@a83-132-152-110.cpe.netcabo.pt] has quit [Read error: 113 (No route to host)] 03:31:36 -!- AtnNn [n=welcome@modemcable087.62-56-74.mc.videotron.ca] has quit [Remote closed the connection] 03:31:48 AtnNn [n=welcome@modemcable087.62-56-74.mc.videotron.ca] has joined #scheme 03:31:55 synx: Wouldn't you want to use malloc if you were, say, working with an FFI? 03:34:34 arcfide: you would have a better way to allocate memory that gets along with your scheme's method of garbage collection. 03:35:26 Hopefully your FFI doesn't force you to use malloc. You might use it if you were developing a FFI yourself though. 03:35:27 synx: You propose that there is a nice way of putting all foreign data structures that need to be allocated into the GC in a reliable way? 03:35:56 Yes. 03:36:20 Sorry, which Scheme implementation has this? 03:36:26 (make-bytes 42) for instance, then use that memory for a 42 byte array. 03:36:26 dsmith_ [i=wjzouagm@cpe-71-74-230-225.neo.res.rr.com] has joined #scheme 03:38:02 synx: And so, let's say I create this structure as a one time thing, and drop all reference to it in the Scheme side of the system, but I have passed this array into a function in the foreign side; it will reside there for a while: how does the Scheme implementation know not to collect it? 03:38:06 since it's impossible to tell what the size of a C structure should be without compiling it, for that platform, on that computer, I don't think any FFI would require you to attempt to malloc such a thing. 03:38:30 arcfide: That's what finalizers are for :p 03:39:00 Of course the FFI would not require you to do so, but you may wish to do so anyways if you have a means of obtaining the sizes at compile time. 03:39:06 synx: Finalizers? 03:39:19 synx: Can you give me an example of how these would be used? 03:39:22 Yes, finalizers to inform the C library to stop using that memory. 03:39:42 So I would still have to free the memory in the foreign code? 03:40:08 Not unless you mallocked it in the foreign code. 03:41:06 You should use malloc when you're stuck in C. But usually with scheme there's a better way. 03:42:16 arcfide pasted "Automatic GC in Foreign Code?" at http://paste.lisp.org/display/76647 03:42:22 synx: Say I have something like the above. 03:42:45 make-widget stores this property array somewhere in the foreign code. 03:43:20 When make-window returns, how does the Scheme implementation know that it should not clean up props, and how does it know when it can clean up props, if, say, the window is closed? 03:43:21 Yes, well you should never call make-widget in that fashion then. props doesn't have any finalizers that you need to add. 03:43:38 And so, how would you do this? 03:43:40 Or, presumably make-widget adds its own finalizers to props. 03:43:50 (make-finalizer)? I dunno, depends on your scheme. 03:43:59 What exactly do these finalizers do? 03:44:03 In plt it's (register-executor) and (will-executor) 03:44:22 finalizers are procedures that, when scheme is about to garbage collect an object, it calls those procedures. 03:44:29 This is a made-up Scheme we are dealing with here, anyways, so I'm just trying to understand how you would handle this. 03:44:40 Okay, and how does this help? 03:44:59 Well one useful finalizer could be destroy-widget, for instance. 03:45:12 (register-executor thingy propes destroy-widget) 03:45:37 But the widget is not a Scheme object. 03:45:49 It's created in the foreign code and passed back. 03:45:53 props is though. 03:45:56 Right. 03:46:27 So when it goes to clean up props, what happens? 03:47:10 It calls destroy-widget, which is a C library function that ensures that the widget's memory will never be accessed by that library again. 03:47:29 So, it will destroy the widget that contains prop? 03:47:37 Or in plt's case it postpones the collection until you check the executor, which you usually do in a separate thread. 03:47:45 Yes arcfide. 03:48:03 synx: So, in that model, suddenly, my windows will close automatically and just die without my intervention. 03:48:47 Yes, well if you want your windows to stay open, you probably shouldn't let them go out of scope. 03:48:50 Because that widget should stay open until I close it. PROPS needs to hang around until I decide to close the window, at which point, the GC should automatically handle cleaning up PROPS. 03:48:59 The Window *is* in scope. 03:49:31 It's allocated by the foreign code, and a handle of some kind to it is returned to the Scheme system, which retains it for further use in, say, an event loop. 03:49:43 Sounds like you need to return props from make-window too. (define-struct wrapper (widget props)) or something. 03:50:12 So I have to wrap every single data structure that would ever be embedded in any code anywhere in the foreign side? 03:50:13 Wait, so the window is allocated via malloc by the foreign code, but it expects you to pass prebaked memory to it too? 03:50:44 Of course. I'm using Scheme to assign properties that I want, but the actual library that uses this list is a foreign library which does its own allocations. 03:50:46 That's usually what I do yes. 03:51:07 synx: That's pretty crazy, imo. 03:51:21 If I were writing a foreign library like that I'd have it copy the input strings anyway. 03:51:57 But you don't control the library, you're just using it. 03:52:23 Well if you want to use a poorly designed library, you might have to write some code to work around it. 03:52:43 Many many functions are designed to be passed memory blocks that are used. 03:53:01 Yes, but they don't themselves malloc memory. 03:53:06 They're most all mutators. 03:53:18 Structures, and so forth, will be passed and used, and be expected to be used by other parts of the system, however, it may not be the case that these structures will be visible in the foreign library, and it wouldn't be a poorly designed library just because of this. 03:53:31 And yes, they are malloced. 03:53:31 If you said (malloc props) then you'd be in trouble, because when make-window returns, props are now a memory leak. 03:54:18 maybe you don't care about a few bytes here and there, but even little memory leaks help hide the big ones. 03:54:43 synx: You'd have to do more managing, of course, but you are claiming that the "right" way wouldn't need any management of these structures that are allocated, and that they should be automatically handled by th GC in a clean way. I don't consider keeping them hanging around in artifical records or whatever to be very clean. 03:55:06 No I'm just saying you shouldn't use malloc. 03:55:09 This example was concocted to demonstrate, hopefully, that such a thing wouldn't be the case, and that you can't simply do that. 03:55:21 The management is done with finalizers, and also with structures to hold stuff we need to not finalize. 03:55:52 So, either a dirty my code with a bunch of dangling object references because I want GC to handle things, or I free things when I don't want them anymore. 03:56:12 If you used (malloc props) to avoid a memory leak you would have to write a finalizer anyway, except now it has to destroy the widget /and/ free the props data. 03:56:51 I would think you want your widget. You said that the user was surprised to see it suddenly disappear. 03:57:21 Finalizers are a fine thing to use, but they are still manually managing your memory, and they aren't much better than FREE, and I think their use seems orthogonal to whether one uses MAKE-BYTES or MALLOC. 03:58:09 finalizers are better than free, because you can postpone freeing the memory until you have idle processor time, and you can batch up the frees so they all happen at once and defragment. 03:58:15 From what you are telling me of finalizers, they are a means of ensuring that FREE is called at the right time, that's still manual memory management. 03:58:16 aka garbage collection 03:59:09 well okay, then you should use scheme-garbage-collected-malloc not malloc, when you're in the context of a scheme garbage collector. 03:59:25 I just like to call it make-bytes. 03:59:43 The only advantage I see here of using MAKE-BYTES over MALLOC is that you don't have to stick another FREE in your finalizer. However, you are writing the finalizer regardless, so this seems like very little benefit. Not that I would mind having MAKE-BYTES, but I don't see it as being so good as to be called "right" compared to MALLOC. 04:00:41 Your example has your C library using malloc to allocate the widget. That's why you have to write a finalizer. If you malloc props too, then you have to write two finalizers. 04:01:06 If you could have demonstrated to me that, using MAKE-BYTES, would not have to worry about what to do with that after it is no longer needed, then I would have agreed with you, but in this case, I would still have to write a finalizer, and that defeats the whole draw you initially proposed. 04:01:37 Please write up your points of view so that I can read them when I'm done with a discussion in #haskell. 04:02:38 (`Write up' as in `summarize', rather than transcribing the conversation that has passed.) 04:02:58 your mom transcribed the conversation that has passed 04:03:13 Riastradh: If you really think it is worth it... 04:03:18 *rudybot* transcribed synx' mom 04:03:24 Yes, arcfide, I think it is. 04:04:44 I am unconvinced that a construct like MAKE-BYTES that allocates some region of memory and registers it with the Scheme collector is the more inherently "right" way of doing FFIs than to use a MALLOC/FREE combination, mostly because I fail to see where MAKE-BYTES would actually prevent you from having to track the memory nonetheless. 04:05:39 It seems to me that unless one were able to register all blocks of memory that came in from a foreign library, that one would still have to manage the memory and still have to remember what memory is being stored where and visible when. 04:07:05 I would be heartily convinced if it were possible to create a construct such as MAKE-BYTES that, like Scheme constructors, the object returned never has to be considered again in terms of allocation or deallocation because the garbage collector would handle it, without any finalizers or the like, and still let it be thrown back and forth in all manners between foreign and Scheme code. 04:07:07 Sorry, I haven't read the whole conversation. I don't know what MAKE-BYTES is. 04:07:24 It uh... makes a sequence of bytes. 04:07:47 Let's talk at a slightly higher-level, since bytes are red herrings. 04:07:51 ...without the hyphen. 04:07:59 MAKE-BYTES is a hypothetical equivalent of MALLOC that registers the memory region allocated with the garbage collector; the objects returned can be passed directly to foreign code. 04:08:19 Sorry, passed and used effectively directly in foreign code. 04:08:49 I say that using malloc and free is unneeded and dangerous, and that if you pass a garbage collected bytes array to your C library, then you just make sure that array doesn't get finalized before the structure that contains it is finalized. 04:08:52 There is a finite bound on many resources available to programs. 04:08:59 Memory is one such resource. 04:09:03 File descriptors are another such resource. 04:09:12 Database handles are yet another. 04:09:31 if you malloc something, then you need to write a finalizer anyway, to free it once some poorly defined event in the future occurs. 04:09:40 synx: I assume you also extend this beyond arrays, to structures and any other foreign object? 04:09:49 database handles ~ file descriptors... 04:10:12 arcfide: If my C library requires me to allocate a structure, and has no way of doing so itself, then I'm kind of screwed anyway. 04:10:16 Some resources are used only through Scheme. For example, the memory occupied by Scheme objects can be managed by the garbage collector. 04:10:34 When these objects cease to be referenced, the garbage collector can reclaim the memory they occupied. 04:11:07 -!- AtnNn [n=welcome@modemcable087.62-56-74.mc.videotron.ca] has quit [Connection timed out] 04:11:34 Some resources are shared between Scheme and foreign code in some way. For example, Scheme can refer to file descriptors, but they must be closed by foreign code when they are no longer needed. 04:12:55 For each scarce resource, to avoid leaking the resource, responsibility must lie somewhere in the aggregate program (Scheme, foreign libraries, operating system, &c.) to release the resource when it is no longer needed. 04:13:17 Responsibility for releasing the memory occupied by Scheme objects lies on the garbage collector. 04:14:45 In Scheme systems where foreign code may refer to Scheme objects that occupy memory, either the garbage collector must be conservative (i.e. the Scheme implementation must have a bug) or the objects must be registered with the garbage collector. (More so, if the memory occupied by objects might move, then the *locations* where the objects are referred to must be registered with the garbage collector. This is often actually simp 04:15:09 What you folks are discussing, however, are foreign resources referred to by Scheme programs. 04:15:41 You were cut off at "actually simp..." 04:16:14 -!- orgy_ [n=ratm_@pD9FFC3CB.dip.t-dialin.net] has quit [Remote closed the connection] 04:16:17 ...This is often actually simpler than registering the objects themselves, because multiple foreign parties can refer to a common object by different locations, effecting a sort of implicit reference counting.) 04:17:15 Let's take a simple case of a foreign library concerning scarce resources, where for each resource that can be allocated by the library, a single party is responsible for releasing that resource when it is no longer needed. This is the model followed by the malloc and free routines from C's standard library. 04:17:27 (Excuse me a moment for a bio-break.) 04:17:55 -!- jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)] 04:21:16 Another example of resources for each of which a single party is responsible is address info records obtained from the standard getaddrinfo routine. 04:22:10 Managing these resources manually is very tricky, because for each resource, the various parts of a program must agree on which party is responsible for releasing the resource. Failure to agree leads to double-freeing or leaking space. 04:23:19 This is why manual reference counting is much easier: the different parts can claim responsibility for definite periods of time, and once nobody is responsible, the resource may be released. No consensus is required in the design, except when cycles arise. 04:23:59 synx: in plt, passing a `make-bytes' block to a foreign library that will hold on to it is a quick way to segfault. 04:25:29 I guess I didn't consider that the garbage collector might move the memory somewhere else. 04:25:54 synx: s/might/will/ 04:26:10 Enter Scheme. In some cases, we can represent resources by objects that occupy memory managed by the garbage collector. In these cases, we can say that a Scheme program is responsible for the resource as long as the object representing it is referenced by the program. 04:27:44 Most garbage collectors provide some way for the program to execute some action when the memory occupied by an object representing a resource is reclaimed -- in other words, when the Scheme program has finally relinquished responsibility for the resource. 04:30:54 When writing Scheme programs that handle scarce, foreign resources, we could eschew the facilities provided by the garbage collector for disclaiming responsibility for the resources once the objects representing them cease to be referenced. We could explicitly call ALLOCATE-RESOURCE and RELEASE-RESOURCE (e.g., MALLOC and FREE, or OPEN and CLOSE, or PGSQL-CONNECT and PGSQL-DISCONNECT). 04:31:46 If we do this, then every part of the Scheme program must agree on which Scheme party is responsible for the resource. 04:33:12 Attaining consensus about this in Scheme, however, is even harder than it is in C, because in Scheme, non-local control transfers can happen. In C, they are generally reserved for one party that runs the show; few libraries, if any, will ever longjmp across library boundaries. 04:34:24 jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has joined #scheme 04:34:55 C programs are furthermore seldom written with the intent to be called from a REPL in a running image. 04:35:43 (even if those C programs are Scheme implementations) 04:36:11 -!- jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)] 04:37:06 So in C, there is no danger, for example, of having the developer hit ^C and return to the REPL, aborting whatever library routine was in progress. If anything like this happens, it probably means that the developer was just exiting the whole program and returning to gdb to restart it, or similar. 04:38:25 Even if developers and ^C and REPLs are not involved, some part of the program, called by a party responsible for a resource, might signal a condition, and a condition handler might ask a user for a choice of action to proceed, and the user might choose to abort the transaction. 04:40:51 For instance, if I wrote a Usenet reader, and in the process of fetching headers, one of the headers turned out malformed, the part of the program that reads headers might signal a condition, and other parts of the program might supply ways to recover: by skipping this header, by aborting the transaction altogether, &c. 04:41:33 If I abort the transaction and just return to the top level of Edwin, exiting the news reader altogether, I don't want the Scheme process to hang on to a socket file descriptor; these are scarce resources. 04:42:15 (Or I might just hit ^G in the middle of fetching headers, and return to the top-level Edwin loop.) 04:43:32 If I just wrote my news reader to follow a sequence of instructions, the first of which is to open a socket and the last of which is to close a socket, then by hitting ^G I have probably killed all chances for the resource to be released. 04:44:28 Now, with a sequence of instructions whose control flow I control, I could use UNWIND-PROTECT or similar to ensure that before control exits the extent, I release the resource. But this doesn't help if the news reader must return to the Edwin loop to let the user interact. 04:45:17 In that case, there is no clear extent to protect, so UNWIND-PROTECT isn't enough. I need to make sure that the resource gets released some other way. 04:46:05 I could establish a condition handler that releases the resource if any condition is signalled, but then if I as the user opt just to skip the header when the condition propagates up to my attention -- well, some early condition handler would already have closed the connection, thwarting my attempt at recovery. 04:47:21 So there are many ways in which the resource could reasonably fail to be released. I say `reasonably' to mean situations that could arise in normal interaction and be handled gracefully; this excludes bad RAM, the machine catching fire, &c., naturally. 04:47:43 By the way, this channel has been awfully silent. Have I scared you all away? 04:47:55 Nope. :-) 04:48:12 We're just all listening. ;-) 04:48:45 I was wondering how long he'd go on 04:50:02 The news reader could prevent ^G from interrupting the process, and making it fail to release the resource, simply by blocking out keyboard interrupts, but that leads to unresponsive programs that are unpleasant to deal with. 04:51:56 If we can represent a resource by an object that the garbage collector will reclaim, though, and ask the garbage collector to execute an action when the object's memory is reclaimed, then provided that the code that actually releases the resource works (if it doesn't, there's no way to win), we can be reasonably sure that eventually the resource will be released, independent of conditions such as ^G. 04:52:32 jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has joined #scheme 04:53:06 We can release the resource sooner if the user doesn't hit ^G, but the garbage collector can be exploited to ensure that the program is robust against such asynchronous interruptions, without much difficulty. 04:53:11 *foof* was eating breakfast 04:55:14 So, arcfide, suppose you were dealing with the widget library that you have in mind. 04:55:49 Perhaps you could elaborate a little bit on the model of resources and responsibility that would apply here. 04:58:39 Usually, with something like this, I would have had some kind of destroy procedure associated with the widget which FREE'd the results once the object encapsulating the allocated array was done. 04:59:30 Or, manually free them. 04:59:32 Well, let's suppose we have a foreign widget library, which has built up a widget graph that constitutes a GUI. 04:59:46 And a Scheme program wants to operate on one of these widgets. 04:59:48 Usually, though, I actually do most of this in C and on the stack. 05:01:08 Unfortunately, though, I have to go to bed now. :-/ 05:01:32 What you mentioned earlier is that you were afraid that when the Scheme GC ran, it might spontaneously close a window that a user was interacting with. 05:01:37 Is this accurate, or am I misremembering something? 05:01:53 Well, crash, more like it. 05:02:15 So are you suggesting that this means Scheme has overstepped its responsibility, and released a resource that was still in use by another party? 05:02:23 Resources are hard, let's go shopping! 05:02:29 Yes. 05:03:24 Now, you'll need to fill in a few details here. How were the two parties (Scheme and the other one still using the resource) intended to cooperate over the resource? They can't both be given sole responsibility for it -- it doesn't matter whether Scheme is involved; two parties each believing itself to have sole responsibility for a resource will screw one another over. 05:03:38 I don't know if I would say that Scheme has overstepped its bounds so much as the Programmer has done something stupid. 05:03:41 Lemonator [n=kniu@pool-71-165-128-172.lsanca.dsl-w.verizon.net] has joined #scheme 05:03:54 Riastradh speaks deep political truths. 05:04:04 Let's leave programmers out of the picture for a minute; they're notoriously difficult beasts. 05:05:04 I usually assume that letting two parties collaborate in this way is a recipe for disaster, so I expect a degree of arbitration from a third party. 05:05:12 In order for this widget library to work at all with two parties sharing some resources, they must share the responsibility for the resources somehow. For example, the resources could be reference-counted (in which case, in Scheme's view, we can see an increment of the reference count as a resource for which the Scheme GC is responsible itself). 05:05:36 ...oh, by the way, folks, tomorrow is Circadian Rhythm Disruption Day in the US. 05:05:49 yaaay C.R.D.D! 05:06:05 I once missed a chess match because of that :/ 05:06:22 Helping me to be late/early to class, because I certainly don't watch TV to notice the warnings. 05:06:45 I read the newspaper, and my University sends out notices. 05:07:00 Anyways, please, do continue with this, but I really must go. Sorry I can't stay longer. 05:07:01 arcfide, so, should Scheme have only released its responsibility for the resource to the arbitrating party, rather than releasing the resource altogether? 05:07:25 (For example, the arbitrating party could be a reference count.) 05:07:45 Riastradh: Yes, more or less. 05:07:46 If so, then it sounds as though the finalizer you discussed earlier had a pretty straightforward bug. 05:08:27 -!- kniu [n=kniu@pool-71-165-128-172.lsanca.dsl-w.verizon.net] has quit [Read error: 110 (Connection timed out)] 05:08:55 However, in the case of the finalizer I mentioned above, I am assuming that Scheme has absolutely no control over the resource, and that the only party responsible for management of the resource is the third party. Neither Scheme nor the Foreign code would have allocated or deallocated the memory. 05:08:58 Sorry, resource. 05:09:50 So the finalizer ought to have informed the third party that it had no further interest in the resource. 05:10:15 tjafk1 [n=timj@e176208213.adsl.alicedsl.de] has joined #scheme 05:10:53 In the model I suggested above, I assumed that the third party would have knowledge of when to release the resource, and that neither Scheme nor the foreign code would know this. 05:11:13 *arcfide* drifts away. 05:11:25 bitweiler [n=phax@adsl-69-154-35-153.dsl.stlsmo.swbell.net] has joined #scheme 05:12:03 synx, can you remind me what your point of view was? I didn't read enough of the conversation to catch it. 05:14:01 -!- berat [n=berat@88.228.58.71] has quit [Remote closed the connection] 05:14:29 My point of view was to avoid using unmanaged memory where possible, though I guess it's not such a good idea if that memory's going to up and disappear on the C programs. 05:14:40 What is `unmanaged memory'? 05:15:03 un-garbage-collected memory, for the lazy typists. 05:17:29 Phrased in terms of resources and responsibility, do you mean that you think Scheme programs should always request that the garbage collector take final responsibility for releasing a resource when it is no longer needed by Scheme? 05:18:48 Maybe not for extremely scarce resources like file descriptors. 05:18:54 Why not? 05:18:55 -!- dmoerner [n=dmr@ppp-71-139-45-71.dsl.snfc21.pacbell.net] has quit [Remote closed the connection] 05:19:14 I say `final responsibility' here because of course the Scheme program can release the resource sooner if possible, and then lift the responsibility from the garbage collector. 05:19:55 Because if you try to open a file and it says no descriptors left, the only thing you can do then is a full garbage collection... 05:20:01 So? 05:20:31 So maybe you don't want to spend time freeing memory resources, for instance. 05:20:37 ? 05:20:54 It can take a few seconds even to collect a couple hundred megabytes of memory. 05:21:06 What is the alternative you have in mind? 05:21:12 Failing? 05:21:33 annodomini [n=lambda@c-75-69-96-104.hsd1.nh.comcast.net] has joined #scheme 05:21:54 No, close the file descriptors via unwind-protect, so that you don't have to do a full garbage collect to close them. 05:22:19 As I said, you can always try to release the resources sooner. 05:22:41 annodomini_ [n=lambda@c-75-69-96-104.hsd1.nh.comcast.net] has joined #scheme 05:22:43 Oh, final responsibility. Sure that's fine then. 05:22:45 But a mischievous user such as myself might hit ^G and block those efforts. 05:24:16 I'm not sure whether arcfide left satisfied, but I suspect that what he was talking about was buggy code to release resources -- or rather, code that releases the wrong resource. (Reponsibility for a resource, and a resource, are two different resources for which a party can be responsible!) 05:30:05 -!- gweiqi [n=greg@69.120.126.163] has left #scheme 05:31:16 -!- mejja [n=user@c-4bb5e555.023-82-73746f38.cust.bredbandsbolaget.se] has quit [Remote closed the connection] 05:32:34 -!- araujo [n=araujo@gentoo/developer/araujo] has quit ["Leaving"] 05:33:38 -!- tjafk [n=timj@e176219079.adsl.alicedsl.de] has quit [Read error: 110 (Connection timed out)] 05:34:56 -!- foof [n=user@dn157-046.naist.jp] has quit ["ERC Version 5.2 (IRC client for Emacs)"] 05:35:10 -!- jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)] 05:38:50 -!- annodomini [n=lambda@wikipedia/lambda] has quit [Read error: 110 (Connection timed out)] 05:39:17 davidad [n=me@NORTHWEST-THIRTYFIVE-FOUR-TWENTY-TWO.MIT.EDU] has joined #scheme 05:46:14 -!- hark [n=strider@hark.slew.org] has quit [Read error: 113 (No route to host)] 05:47:53 foof [n=user@dn157-046.naist.jp] has joined #scheme 05:51:32 jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has joined #scheme 05:51:37 *foof* mutters disparaging remarks about os x 05:55:12 What now? 05:56:31 hark [n=strider@hark.slew.org] has joined #scheme 05:57:10 Apparently if you try to copy a lot of data from the finder you may have to cold boot your computer. 05:57:24 Wonderful. 05:57:37 I tend to avoid the Finder. 05:57:40 So far cp(1) doesn't seem to be so afflicted. 06:02:43 -!- annodomini_ is now known as annodomini 06:30:34 -!- hadronzoo [n=hadronzo@ppp-70-247-161-87.dsl.rcsntx.swbell.net] has quit [] 06:33:17 -!- stepnem [n=stepnem@topol.nat.praha12.net] has quit [Remote closed the connection] 06:40:56 kilimanjaro [n=kilimanj@70.116.95.163] has joined #scheme 06:49:57 reprore [n=reprore@ntkngw304058.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 06:52:30 -!- jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)] 07:01:02 AtnNn [n=welcome@modemcable087.62-56-74.mc.videotron.ca] has joined #scheme 07:03:20 vixey [n=yoo@amcant.demon.co.uk] has joined #scheme 07:07:04 sreeram [n=sreeram@122.164.141.57] has joined #scheme 07:07:07 -!- AtnNn [n=welcome@modemcable087.62-56-74.mc.videotron.ca] has quit [Remote closed the connection] 07:07:18 AtnNn [n=welcome@modemcable087.62-56-74.mc.videotron.ca] has joined #scheme 07:08:50 jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has joined #scheme 07:09:33 -!- dejai [n=dejai@230.15.233.220.exetel.com.au] has quit [Remote closed the connection] 07:10:55 dejai [n=dejai@230.15.233.220.exetel.com.au] has joined #scheme 07:10:55 dejai_ [n=dejai@230.15.233.220.exetel.com.au] has joined #scheme 07:12:36 -!- jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)] 07:12:53 sreeram_ [n=sreeram@59.92.93.112] has joined #scheme 07:14:30 attila_lendvai_ [n=ati@business-89-132-61-222.business.broadband.hu] has joined #scheme 07:17:41 -!- Kusanagi [n=Lernaean@unaffiliated/kusanagi] has quit [] 07:18:20 Kusanagi [n=Lernaean@unaffiliated/kusanagi] has joined #scheme 07:20:43 -!- sreeram [n=sreeram@122.164.141.57] has quit [Nick collision from services.] 07:21:43 -!- sreeram_ is now known as sreeram 07:23:36 lol foof :) 07:23:52 happy daylight savings time. 07:23:53 it probably tries to wrap everything in some massive transaction 07:28:20 benny [n=benny@i577A114A.versanet.de] has joined #scheme 07:29:12 jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has joined #scheme 07:30:57 -!- bitweiler [n=phax@adsl-69-154-35-153.dsl.stlsmo.swbell.net] has quit ["null? reason"] 07:32:52 -!- dejai_ [n=dejai@230.15.233.220.exetel.com.au] has quit ["Leaving"] 07:33:52 -!- attila_lendvai_ [n=ati@business-89-132-61-222.business.broadband.hu] has quit ["..."] 07:37:34 -!- reprore [n=reprore@ntkngw304058.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Remote closed the connection] 07:39:33 -!- eli [n=eli@winooski.ccs.neu.edu] has quit [Remote closed the connection] 07:41:48 reprore [n=reprore@ntkngw304058.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 07:42:28 eli [n=eli@winooski.ccs.neu.edu] has joined #scheme 07:44:04 -!- kilimanjaro [n=kilimanj@70.116.95.163] has quit ["Leaving"] 07:44:34 -!- dejai [n=dejai@230.15.233.220.exetel.com.au] has quit [Remote closed the connection] 07:44:40 -!- reprore [n=reprore@ntkngw304058.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Remote closed the connection] 07:46:46 -!- annodomini [n=lambda@wikipedia/lambda] has quit [] 07:52:56 dejai [n=dejai@230.15.233.220.exetel.com.au] has joined #scheme 07:59:10 -!- jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)] 08:06:16 inimino1 [n=inimino@atekomi.inimino.org] has joined #scheme 08:07:35 -!- Lemonator [n=kniu@pool-71-165-128-172.lsanca.dsl-w.verizon.net] has quit [Read error: 110 (Connection timed out)] 08:09:21 -!- inimino [n=inimino@atekomi.inimino.org] has quit [Read error: 104 (Connection reset by peer)] 08:16:18 jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has joined #scheme 08:37:11 seoushi_ [n=seoushi@c-67-186-243-205.hsd1.ut.comcast.net] has joined #scheme 08:39:53 -!- synthase [n=synthase@68.63.48.10] has quit [Read error: 110 (Connection timed out)] 08:41:13 -!- seoushi_ is now known as seoushi 08:46:08 hi 08:46:10 I am confused 08:46:31 I thought I built a mutable cell using CALL-WITH-CURRENT-CONTINUATION 08:46:34 hello confused 08:46:46 except it only works at the toplevel 08:47:04 I can't use it as a mutable cell in a program.. only at the toplevel 08:47:10 ejs [n=eugen@94-248-60-222.dynamic.peoplenet.ua] has joined #scheme 08:47:18 is it the same with the LETREC/CWCC mutable cell? 08:47:50 you are confusing me! 08:49:17 (DEFINE (STORAGE* YES) (LET LOOP ((VALUE 'BORING-VALUE)) (LET ((NEXT (YES VALUE))) (LOOP NEXT)))) 08:50:05 (DEFINE BAZ (CWCC (LAMBDA (K) ((LAMBDA (U) (U U)) (LAMBDA (THIS) (LAMBDA (V) (STORAGE* (LAMBDA (X) (COND ((CWCC I) => (LAMBDA (J) (K (LIST X J (THIS THIS))))) (ELSE V)))))))))) 08:50:33 at the toplevel (of SISC) it behaves like a mutable cell.. 08:50:47 but you can't define SET-CELL-VALUE and use it in a procedure 08:50:52 weird isn't it ?? 08:52:54 -!- Modius [n=Modius@adsl-68-90-188-165.dsl.austtx.swbell.net] has quit ["I'm big in Japan"] 08:53:21 Arelius [n=Indy@netblock-68-183-230-134.dslextreme.com] has joined #scheme 08:53:22 -!- inimino1 is now known as inimino 09:04:32 barney [n=bernhard@p549A1949.dip0.t-ipconnect.de] has joined #scheme 09:07:25 underspecified_ [n=eric@softbank220043052007.bbtec.net] has joined #scheme 09:15:52 -!- dejai [n=dejai@230.15.233.220.exetel.com.au] has quit [Remote closed the connection] 09:19:13 incubot: slumdog millionaire wasn't half bad; though i waited until the eleventh hour to see it 09:19:15 i waited until it was < 0F out 09:19:40 incubot: nice; also: moar lens flare 09:19:43 Chicken is also not R5RS by default. 09:20:23 incubot: Does Chicken support the new QWACC operator? 09:20:26 I can read C not written in my style, if I have an operator precedence table to refer to; I just prefer to write it with my style. 09:21:02 wingo-tp [n=wingo@30.Red-79-156-145.staticIP.rima-tde.net] has joined #scheme 09:23:59 Isn't there a paper/essay floating around on how closures are equivalent to objects? 09:24:22 there's a zen koan about it 09:24:51 hrm 09:25:24 -!- underspecified [n=eric@softbank220043052007.bbtec.net] has quit [Read error: 113 (No route to host)] 09:34:06 qwacc operator? 09:34:20 lambda: the ultimate object 09:39:22 -!- sreeram [n=sreeram@59.92.93.112] has quit [Read error: 110 (Connection timed out)] 09:46:29 sreeram [n=sreeram@122.164.183.21] has joined #scheme 09:51:12 -!- ejs [n=eugen@94-248-60-222.dynamic.peoplenet.ua] has quit ["Leaving"] 09:55:34 araujo [n=araujo@gentoo/developer/araujo] has joined #scheme 09:57:10 Judofyr [n=Judofyr@c349BBF51.dhcp.bluecom.no] has joined #scheme 10:06:04 masm [n=masm@a83-132-152-110.cpe.netcabo.pt] has joined #scheme 10:10:16 jah [n=jah@42.138.72-86.rev.gaoland.net] has joined #scheme 10:12:00 -!- ttmrichter [n=ttmricht@221.235.57.111] has quit [Remote closed the connection] 10:17:11 athos [n=philipp@92.250.204.223] has joined #scheme 10:28:47 mike [n=m@dslb-088-066-239-062.pools.arcor-ip.net] has joined #scheme 10:29:15 -!- mike is now known as Guest30416 10:31:01 -!- sad0ur_ [n=sad0ur@psi.cz] has quit [Remote closed the connection] 10:44:27 s76__ [n=todos@175-52-124-91.pool.ukrtel.net] has joined #scheme 10:45:12 errordeveloper [n=errordev@78-86-1-110.zone2.bethere.co.uk] has joined #scheme 10:48:24 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [] 10:49:15 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 10:49:37 -!- elmex [i=elmex@ist.m8geil.de] has quit [Remote closed the connection] 10:49:39 elmex [i=elmex@ist.m8geil.de] has joined #scheme 10:49:50 Adamant_ [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 10:49:52 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Connection reset by peer] 10:51:00 -!- Adamant_ [n=Adamant@unaffiliated/adamant] has quit [No route to host] 11:03:08 -!- elmex [i=elmex@ist.m8geil.de] has quit [Remote closed the connection] 11:03:11 elmex [i=elmex@ist.m8geil.de] has joined #scheme 11:03:20 Adamant [n=Adamant@unaffiliated/adamant] has joined #scheme 11:03:42 amaron [n=amaron@cable-94-189-243-158.dynamic.sbb.rs] has joined #scheme 11:04:46 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 11:15:10 -!- elmex [i=elmex@ist.m8geil.de] has quit [Remote closed the connection] 11:16:03 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 11:17:12 -!- puchacz [n=puchacz@87-194-5-99.bethere.co.uk] has quit [Remote closed the connection] 11:17:30 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 11:19:45 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 11:21:10 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 11:25:16 -!- Arelius [n=Indy@netblock-68-183-230-134.dslextreme.com] has quit [] 11:30:12 ttmrichter [n=ttmricht@59.174.132.46] has joined #scheme 11:32:22 -!- amaron [n=amaron@cable-94-189-243-158.dynamic.sbb.rs] has quit [Read error: 110 (Connection timed out)] 11:42:27 -!- jah [n=jah@42.138.72-86.rev.gaoland.net] has quit ["Quitte"] 11:44:08 -!- Guest30416 [n=m@dslb-088-066-239-062.pools.arcor-ip.net] has quit ["This computer has gone to sleep"] 11:48:00 -!- AtnNn [n=welcome@modemcable087.62-56-74.mc.videotron.ca] has quit [Remote closed the connection] 11:54:54 -!- masm [n=masm@a83-132-152-110.cpe.netcabo.pt] has quit [Read error: 113 (No route to host)] 11:57:52 -!- sreeram [n=sreeram@122.164.183.21] has quit [] 12:02:55 AtnNn [n=welcome@modemcable087.62-56-74.mc.videotron.ca] has joined #scheme 12:09:03 -!- jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)] 12:18:44 puchacz [n=puchacz@87-194-5-99.bethere.co.uk] has joined #scheme 12:20:07 -!- AtnNn [n=welcome@modemcable087.62-56-74.mc.videotron.ca] has quit [Connection timed out] 12:20:49 jewel [n=jewel@dsl-242-138-129.telkomadsl.co.za] has joined #scheme 12:22:05 -!- errordeveloper [n=errordev@78-86-1-110.zone2.bethere.co.uk] has quit [Remote closed the connection] 12:22:22 errordeveloper [n=errordev@78-86-1-110.zone2.bethere.co.uk] has joined #scheme 12:24:05 masm [n=masm@a83-132-152-110.cpe.netcabo.pt] has joined #scheme 12:25:53 jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has joined #scheme 12:27:42 ffx` [n=ffx@60-241-74-240.static.tpgi.com.au] has joined #scheme 12:45:27 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 12:46:54 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 12:54:52 elmex [i=elmex@ist.m8geil.de] has joined #scheme 13:01:21 hkBst [n=hkBst@gentoo/developer/hkbst] has joined #scheme 13:02:35 orgy` [n=ratm_@pD9FFC3CB.dip.t-dialin.net] has joined #scheme 13:03:31 ttmrichter_ [n=ttmricht@58.48.196.110] has joined #scheme 13:07:39 -!- barney [n=bernhard@p549A1949.dip0.t-ipconnect.de] has quit [Remote closed the connection] 13:09:03 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 13:10:03 synthase [n=synthase@68.63.48.10] has joined #scheme 13:10:30 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 13:13:33 -!- jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)] 13:14:44 -!- ttmrichter [n=ttmricht@59.174.132.46] has quit [Read error: 110 (Connection timed out)] 13:21:00 v__ [n=v@219.139.138.150] has joined #scheme 13:30:19 jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has joined #scheme 13:41:41 amaron [n=amaron@cable-94-189-243-158.dynamic.sbb.rs] has joined #scheme 13:43:14 stepnem [n=xchat@topol.nat.praha12.net] has joined #scheme 13:51:30 -!- synx [i=synx@gateway/gpg-tor/key-0xA71B0C6A] has quit [Remote closed the connection] 13:54:16 mike [n=m@dslb-088-066-248-058.pools.arcor-ip.net] has joined #scheme 13:54:44 -!- mike is now known as Guest23503 13:56:37 synx [i=synx@gateway/gpg-tor/key-0xA71B0C6A] has joined #scheme 14:01:33 elias` [n=me@unaffiliated/elias/x-342423] has joined #scheme 14:09:36 -!- ayrnieu [n=julian@c-76-30-82-6.hsd1.tx.comcast.net] has quit [Remote closed the connection] 14:13:57 ayrnieu [n=julian@c-76-30-82-6.hsd1.tx.comcast.net] has joined #scheme 14:15:30 sreeram [n=sreeram@122.164.183.21] has joined #scheme 14:22:10 reprore [n=reprore@ntkngw304058.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 14:29:03 pfffff, neither larceny nor gambit support srfi-43 :( 14:30:26 i find that hard to believe, you sure they are not providing all procs already? 14:33:43 yes, both complain of not knowing vector-unfold 14:35:56 http://srfi.schemers.org/srfi-43/vector-lib.scm <-- the version in there looks pretty portable, you could just add it 14:39:41 chaoslynx [n=cpehle@p57A74156.dip.t-dialin.net] has joined #scheme 14:41:06 gweiqi [n=greg@69.120.126.163] has joined #scheme 15:02:14 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 15:02:40 -!- errordeveloper [n=errordev@78-86-1-110.zone2.bethere.co.uk] has quit [Remote closed the connection] 15:02:58 errordeveloper [n=errordev@78-86-1-110.zone2.bethere.co.uk] has joined #scheme 15:03:41 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 15:03:44 repror___ [n=reprore@ntkngw304058.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 15:04:00 -!- reprore [n=reprore@ntkngw304058.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Read error: 131 (Connection reset by peer)] 15:05:09 sepult [n=buggarag@xdsl-84-44-175-34.netcologne.de] has joined #scheme 15:10:21 jah [n=jah@42.138.72-86.rev.gaoland.net] has joined #scheme 15:14:43 I'll try to live without it for now 15:15:29 choas [n=lars@p5B0DFE8D.dip.t-dialin.net] has joined #scheme 15:17:07 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 15:17:11 Nshag [i=user@Mix-Orleans-106-2-218.w193-248.abo.wanadoo.fr] has joined #scheme 15:18:34 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 15:19:25 hkBst, why do you want to use SRFI 43? 15:24:50 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 15:24:51 Riastradh: it would make my code nicer 15:25:36 What part of it do you want to use? 15:26:17 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 15:28:16 Riastradh: vector-unfold and vector-map mostly 15:28:21 There's about one useful operation in it, and that's VECTOR-COPY! because there are too many indices to keep straight. 15:28:58 -!- chaoslynx [n=cpehle@p57A74156.dip.t-dialin.net] has quit [Read error: 60 (Operation timed out)] 15:29:09 (vector-map (lambda (x) (frob grovel x)) vector) => (collect-vector-of-length (vector-length vector) (for x (in-vector vector)) (frob grovel x)) 15:32:17 Riastradh: where is collect-vector-of-length from? 15:33:26 ; add . 15:35:05 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 15:36:03 annodomini [n=lambda@c-75-69-96-104.hsd1.nh.comcast.net] has joined #scheme 15:36:32 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 15:37:41 annodomini_ [n=lambda@c-75-69-96-104.hsd1.nh.comcast.net] has joined #scheme 15:40:32 -!- jah [n=jah@42.138.72-86.rev.gaoland.net] has quit ["Quitte"] 15:43:51 -!- synthase [n=synthase@68.63.48.10] has quit [Connection timed out] 15:48:43 Jarvellis [n=jarv@dsl-217-155-101-22.zen.co.uk] has joined #scheme 15:53:35 -!- annodomini [n=lambda@wikipedia/lambda] has quit [Read error: 110 (Connection timed out)] 16:09:36 peter_12 [n=peter_12@88.188.168.41] has joined #scheme 16:21:15 -!- peter_12 [n=peter_12@88.188.168.41] has quit [] 16:22:56 -!- jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)] 16:25:12 -!- Jarvellis [n=jarv@dsl-217-155-101-22.zen.co.uk] has quit [Remote closed the connection] 16:28:24 -!- v__ [n=v@219.139.138.150] has quit ["Leaving"] 16:31:16 Jarvellis [n=jarv@dsl-217-155-101-22.zen.co.uk] has joined #scheme 16:38:27 jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has joined #scheme 16:42:02 -!- Jarvellis [n=jarv@dsl-217-155-101-22.zen.co.uk] has quit [Remote closed the connection] 16:45:13 Jarvellis [n=jarv@dsl-217-155-101-22.zen.co.uk] has joined #scheme 16:45:39 lowlycoder [n=x@unaffiliated/lowlycoder] has joined #scheme 16:50:04 -!- amaron [n=amaron@cable-94-189-243-158.dynamic.sbb.rs] has quit [Read error: 110 (Connection timed out)] 17:02:08 Edico [n=Edico@unaffiliated/edico] has joined #scheme 17:05:40 -!- sreeram [n=sreeram@122.164.183.21] has quit [] 17:06:04 dmoerner [n=dmr@ppp-71-139-45-71.dsl.snfc21.pacbell.net] has joined #scheme 17:06:11 -!- annodomini_ [n=lambda@wikipedia/lambda] has quit [] 17:10:55 -!- jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)] 17:11:35 sreeram [n=sreeram@122.164.183.21] has joined #scheme 17:13:06 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 17:14:31 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 17:18:58 -!- dsmith_ is now known as dsmith 17:22:07 Caesium [i=nathan@lambda.caesium.org] has joined #scheme 17:26:41 -!- lowlycoder [n=x@unaffiliated/lowlycoder] has quit ["leaving"] 17:28:06 jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has joined #scheme 17:33:25 -!- deep is now known as Guest64436 17:44:53 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 17:46:18 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 17:46:27 -!- offby1 [n=user@q-static-138-125.avvanta.com] has quit [Read error: 104 (Connection reset by peer)] 17:47:28 -!- jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)] 17:48:56 kilimanjaro [n=kilimanj@70.116.95.163] has joined #scheme 17:55:14 offby1 [n=user@q-static-138-125.avvanta.com] has joined #scheme 17:57:32 rudybot_ [n=luser@q-static-138-125.avvanta.com] has joined #scheme 17:59:19 synthase [n=synthase@68.63.48.10] has joined #scheme 17:59:53 ecraven [n=nex@140.78.42.103] has joined #scheme 18:03:36 jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has joined #scheme 18:03:57 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 18:04:37 davidad1 [n=me@dhcp-18-111-18-142.dyn.mit.edu] has joined #scheme 18:05:22 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 18:05:37 -!- jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has quit [Connection reset by peer] 18:11:13 -!- rudybot [n=luser@q-static-138-125.avvanta.com] has quit [Read error: 110 (Connection timed out)] 18:11:31 -!- davidad [n=me@NORTHWEST-THIRTYFIVE-FOUR-TWENTY-TWO.MIT.EDU] has quit [Connection timed out] 18:12:54 -!- Kusanagi [n=Lernaean@unaffiliated/kusanagi] has quit [] 18:17:05 -!- errordeveloper [n=errordev@78-86-1-110.zone2.bethere.co.uk] has quit [Remote closed the connection] 18:17:22 errordeveloper [n=errordev@78-86-1-110.zone2.bethere.co.uk] has joined #scheme 18:22:42 jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has joined #scheme 18:30:15 -!- jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has quit [Connection reset by peer] 18:33:48 -!- Jarvellis [n=jarv@dsl-217-155-101-22.zen.co.uk] has quit [Read error: 110 (Connection timed out)] 18:34:09 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 18:34:53 -!- rudybot_ is now known as rudybot 18:35:34 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 18:39:04 saccade_ [n=saccade@65-78-24-47.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has joined #scheme 18:39:50 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 18:41:15 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 18:41:16 -!- repror___ [n=reprore@ntkngw304058.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Remote closed the connection] 18:46:53 jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has joined #scheme 18:55:02 -!- saccade_ [n=saccade@65-78-24-47.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has quit ["This computer has gone to sleep"] 18:55:38 -!- jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has quit [Read error: 104 (Connection reset by peer)] 19:03:06 irc [i=JohnnyL@ool-182f0b98.dyn.optonline.net] has joined #scheme 19:03:19 -!- irc [i=JohnnyL@ool-182f0b98.dyn.optonline.net] has left #scheme 19:12:10 jeremiah [n=jeremiah@31.Red-213-98-123.staticIP.rima-tde.net] has joined #scheme 19:12:18 reprore [n=reprore@ntkngw304058.kngw.nt.ftth.ppp.infoweb.ne.jp] has joined #scheme 19:12:53 saccade_ [n=saccade@65-78-24-47.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has joined #scheme 19:14:09 -!- inimino [n=inimino@atekomi.inimino.org] has quit [verne.freenode.net irc.freenode.net] 19:14:09 -!- Fare [n=Fare@ita4fw1.itasoftware.com] has quit [verne.freenode.net irc.freenode.net] 19:14:09 -!- elf [i=elf@antenora.aculei.net] has quit [verne.freenode.net irc.freenode.net] 19:14:09 -!- incubot [i=incubot@klutometis.wikitex.org] has quit [verne.freenode.net irc.freenode.net] 19:14:09 -!- inhortte [i=polaris@fucksheep.org] has quit [verne.freenode.net irc.freenode.net] 19:14:09 -!- ilitirit [n=john@watchdog.msi.co.jp] has quit [verne.freenode.net irc.freenode.net] 19:14:09 -!- Leonidas [n=Leonidas@unaffiliated/leonidas] has quit [verne.freenode.net irc.freenode.net] 19:14:09 -!- kandinski [i=kandinsk@rowrcolo.net] has quit [verne.freenode.net irc.freenode.net] 19:14:09 -!- dlouhy [n=jdlouhy@pinball.ccs.neu.edu] has quit [verne.freenode.net irc.freenode.net] 19:14:09 -!- heat [i=dima@66.160.171.42] has quit [verne.freenode.net irc.freenode.net] 19:14:09 -!- tizoc [n=user@unaffiliated/tizoc] has quit [verne.freenode.net irc.freenode.net] 19:15:15 -!- vixey [n=yoo@amcant.demon.co.uk] has quit ["Quitting!"] 19:19:30 inimino [n=inimino@atekomi.inimino.org] has joined #scheme 19:19:30 Fare [n=Fare@ita4fw1.itasoftware.com] has joined #scheme 19:19:30 kandinski [i=kandinsk@rowrcolo.net] has joined #scheme 19:19:30 elf [i=elf@antenora.aculei.net] has joined #scheme 19:19:30 Leonidas [n=Leonidas@unaffiliated/leonidas] has joined #scheme 19:19:30 ilitirit [n=john@watchdog.msi.co.jp] has joined #scheme 19:19:30 incubot [i=incubot@klutometis.wikitex.org] has joined #scheme 19:19:30 heat [i=dima@66.160.171.42] has joined #scheme 19:19:30 dlouhy [n=jdlouhy@pinball.ccs.neu.edu] has joined #scheme 19:19:30 tizoc [n=user@unaffiliated/tizoc] has joined #scheme 19:19:30 inhortte [i=polaris@fucksheep.org] has joined #scheme 19:20:12 -!- ASau [n=user@193.138.70.52] has quit [Remote closed the connection] 19:20:13 ASau [n=user@193.138.70.52] has joined #scheme 19:20:28 -!- Guest23503 [n=m@dslb-088-066-248-058.pools.arcor-ip.net] has quit ["This computer has gone to sleep"] 19:25:37 -!- saccade_ [n=saccade@65-78-24-47.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com] has quit ["This computer has gone to sleep"] 19:25:42 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 19:27:04 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 19:32:38 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 19:34:03 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 19:36:36 -!- davidad1 [n=me@dhcp-18-111-18-142.dyn.mit.edu] has quit [Connection timed out] 19:37:06 Lemonator [n=kniu@pool-71-165-128-172.lsanca.dsl-w.verizon.net] has joined #scheme 19:37:15 Riastradh: thanks for addressing the FIFO behaviour 19:41:19 -!- reprore [n=reprore@ntkngw304058.kngw.nt.ftth.ppp.infoweb.ne.jp] has quit [Remote closed the connection] 19:41:35 ack0 [n=user@s559195f7.adsl.wanadoo.nl] has joined #scheme 19:43:22 -!- specbot [n=specbot@common-lisp.net] has quit [Read error: 113 (No route to host)] 19:44:06 -!- lisppaste [n=lisppast@common-lisp.net] has quit [Network is unreachable] 19:44:24 -!- minion [n=minion@common-lisp.net] has quit [Read error: 110 (Connection timed out)] 19:50:45 attila_lendvai [n=ati@catv-89-132-189-132.catv.broadband.hu] has joined #scheme 19:56:34 Kusanagi [n=Lernaean@unaffiliated/kusanagi] has joined #scheme 19:57:37 ehird [n=ehird@208.78.103.223] has joined #scheme 19:58:24 Which is generally preferred as a general use scheme: Gauche or 48? 19:59:39 Personally I prefer Scheme48 for admiral use, but I don't know about generals. 20:00:55 so I think I found an actual use for continuation passing style. 20:01:40 wish I could just rewrite this image collection system in scheme. 20:02:57 Takes so much freaking time and effort to maintain this python stuff. 20:07:35 yeah, but then when you tire of it, your successor will wish it were written in Ruby, or 20:11:11 jgracin [n=jgracin@82.193.210.126] has joined #scheme 20:13:48 -!- jso [n=user@151.159.200.8] has quit [Read error: 54 (Connection reset by peer)] 20:14:07 so, nobody likes gauche? :-) 20:15:15 jso [n=user@151.159.200.8] has joined #scheme 20:18:29 If you were more specific with your inquiry, more specific persons might reply more specifically. 20:19:17 I couldn't really be more specific. 20:19:49 ken-p [n=unknown@84.92.70.37] has joined #scheme 20:20:08 -!- sreeram [n=sreeram@122.164.183.21] has quit [] 20:24:14 ehird: Gauche is somewhat hard to maintain. 20:24:15 lisppaste [n=lisppast@common-lisp.net] has joined #scheme 20:24:22 You mean, the interpreter? 20:24:25 ehird: I find Chicken way less problematic. 20:24:38 Yes, I mean interpreter. 20:24:55 I don't remember details, but if it were easy to maintain, 20:25:13 I'd complete that long-hanging TODO update long ago. 20:25:33 OK, thanks 20:25:49 minion [n=minion@common-lisp.net] has joined #scheme 20:25:54 jgracin_ [n=jgracin@82.193.210.126] has joined #scheme 20:25:56 specbot [n=specbot@common-lisp.net] has joined #scheme 20:26:31 Note: that's my personal opinion. 20:27:58 TODO update? 20:28:08 Riastradh: pkgsrc/doc/TODO 20:28:18 (We're not in #netbsd or #pkgsrc any more!) 20:28:28 Riastradh: yes, I remember. :) 20:30:34 Oh dear! I made a typo in my checkin notes :o 20:30:35 As for practical reasons, I find Chicken rather easy to use. 20:31:04 i dont think I can edit them :( 20:31:08 Though I didn't try embedding it. 20:31:16 leppie: why? 20:31:26 Clearly you need source control for your source control history, leppie. 20:31:28 Administrative restriction? 20:31:31 = and friends are now transistive as required. <--- oops :) 20:32:50 -!- jgracin [n=jgracin@82.193.210.126] has quit [Read error: 110 (Connection timed out)] 20:37:11 JohnnyL [i=JohnnyL@ool-182f0b98.dyn.optonline.net] has joined #scheme 20:38:29 cool, I CAN edit them, just never knew how, but now I do :) 20:39:00 slom_ [n=slom@pD9EB69A9.dip.t-dialin.net] has joined #scheme 20:39:41 -!- Mr_Awesome [n=eric@isr5452.urh.uiuc.edu] has quit [Read error: 110 (Connection timed out)] 20:42:23 -!- JohnnyL [i=JohnnyL@ool-182f0b98.dyn.optonline.net] has quit [] 20:43:40 ASau, any clue why `-j' might induce FreeBSD make(1) to strip pathname componens from sources and targets, such as turning `../foo/bar.c' and `../foo/bar.o' into `bar.c' and `bar.o'? 20:44:09 Components, even. 20:44:26 `modus componens'? 20:44:33 One possible scenario is this: 20:45:06 it skips "depends" and ".sinclude" silently doesn't include. 20:45:16 No, this is a POSIX makefile. 20:45:20 Thus you end without ".PATH". 20:45:22 No BSDisms or GNUisms at all, as far as I know. 20:45:33 Or VPATH. 20:46:03 Then I'd say that, you don't notice objdir. 20:46:20 Misplaced comma. 20:46:31 And the pathnames are written literally, as in: LIARC_SOURCES = ../runtime/runtime-unx.c ../runtime/...., LIARC_OBJECTS similarly, and some targets have $(LIARC_OBJECTS) as dependencies. 20:46:33 ..., that you... 20:46:54 Pfff. 20:47:02 `make -B' and GNU make both do the right thing. It's only BSD make with `-j k' that doesn't. 20:47:07 (k = 2, in this case) 20:47:35 Strange. 20:47:38 bmake too? 20:48:03 Can you provide small example? 20:48:30 To be precise: I am using the GNU make and FreeBSD make that are bundled with Mac OS X (10.5), with and without -j, and of the four configurations, only one of them, BSD make with -j, fails. 20:48:47 uname -r, please. 20:48:52 9.5.0 20:48:57 I don't know how OSX version relates to Darwin one. 20:49:50 make --version 20:49:51 GNU Make 3.80 20:50:02 uname -mrs 20:50:03 Darwin 8.11.0 Power Macintosh 20:50:04 ?? 20:50:12 It isn't BSD make. 20:50:31 BSD make is called `bsdmake' on OS X. 20:50:40 GNU make is called `gnumake' and just `make'. 20:50:50 Alright. 20:50:54 I didn't know that. 20:51:09 I'm preparing a small example now. 20:53:18 Yes, it looks like FreeBSD's one. 20:54:39 ...judging from man page. 20:54:54 20:54:56 JohnnyL [i=JohnnyL@ool-182f0b98.dyn.optonline.net] has joined #scheme 20:55:18 Enter foo/bar/, and compare `gnumake', `bsdmake', `gnumake -j2', `bsdmake -j2'. 20:55:25 (Run `make clean' to clean up the object files.) 20:55:41 -!- JohnnyL [i=JohnnyL@ool-182f0b98.dyn.optonline.net] has left #scheme 20:56:09 NetBSD make exhibits the same problem. 20:57:10 Arelius [n=Indy@netblock-68-183-230-134.dslextreme.com] has joined #scheme 20:57:40 Have noticed the same. 20:57:47 -!- errordeveloper [n=errordev@78-86-1-110.zone2.bethere.co.uk] has quit [Read error: 60 (Operation timed out)] 20:58:49 Bug. 21:00:36 Well, no. 21:00:58 .PREFIX The file prefix of the file, containing only the file 21:00:59 portion, no suffix or preceding directory components; 21:00:59 also known as `*'. 21:01:32 This is intended behaviour. 21:01:41 Argh. 21:01:54 You should use .ALLSRC 21:02:16 In fact, the rule is incorrect. 21:02:21 Check sys.mk. 21:02:21 POSIX doesn't say that. 21:02:31 `the $* macro shall evaluate to the current target name with its suffix deleted.' 21:02:52 (See .) 21:03:14 Correct one should look like ".c.o:; $(CC) $(CFLAGS) $(CPPFLAGS) -c -o $(.TARGET $(.ALLSRC)" 21:03:16 However, I see that I have not requested POSIX behaviour. 21:04:25 errordeveloper [n=errordev@78-86-1-110.zone2.bethere.co.uk] has joined #scheme 21:05:02 I'm not sure anyone's eager to replace traditional behaviour with "standard" one. 21:06:28 Specifying `.POSIX' doesn't help. 21:06:35 Grumble. 21:07:47 Neither NetBSD nor FreeBSD nor Dragonfly list ".POSIX". 21:08:15 My Darwin 8.11.0 doesn't either. 21:08:47 I suggest writing rule in traditional way: 21:09:03 .c.o:; $(CC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $> 21:09:19 Or "$<" instead of "$>". 21:10:44 error_developer_ [n=errordev@78-86-1-110.zone2.bethere.co.uk] has joined #scheme 21:13:09 Hm. 21:13:47 After reading POSIX man page, I doubt I'm ever going to use such underpowered make. 21:13:52 It is quite impractical. 21:14:37 It is indeed. And I'm already using a program to generate the Makefile.in to be processed by an autoconf configure script... 21:14:39 You can have more reasonable BSD, OSF or GNU make any time you want. 21:16:01 Even GNU make is hard to use. 21:16:35 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 21:16:40 Boggle. Using $@ and $< worked for the isolated example but not for the real case. 21:16:45 they all stink :-( 21:16:57 just use a script that generates autotools files 21:17:06 Oops, never mind. 21:17:20 offby1: the problem is in parallel builds. 21:17:30 bmake, pmake, gmake support them. 21:17:36 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 21:17:55 Homebrew "solutions" usually don't. 21:18:09 what about imake nmake qmake and emake? 21:18:14 zmake? 21:18:25 I don't use them. :) 21:18:30 make? 21:19:33 mmak 21:19:33 e 21:20:53 I think there was a reason why $< and $@ were avoided, but I have forgotten it. 21:22:08 Nope, that was $^, which is a GNUism. 21:22:38 I'm not sure about $<, but $@ usage is consistent across BSD-POSIX line. 21:22:53 -!- slom_ [n=slom@pD9EB69A9.dip.t-dialin.net] has quit [Read error: 110 (Connection timed out)] 21:22:53 bmake supports linked lists 21:23:16 since it supports variable name concatination 21:24:03 hadronzoo [n=hadronzo@gateway.publicvpn.net] has joined #scheme 21:24:11 -!- errordeveloper [n=errordev@78-86-1-110.zone2.bethere.co.uk] has quit [Read error: 110 (Connection timed out)] 21:24:12 -!- jao [n=jao@221.Red-79-155-152.dynamicIP.rima-tde.net] has quit [Remote closed the connection] 21:24:27 why even use a make-alike? 21:24:39 See above. 21:25:29 I tried to :) 21:25:39 I don't notice. 21:26:11 If you're fine with having only one CPU busy with building and another idling, 21:26:17 it doesn't matter to me. 21:26:32 I want all units to do useful work. 21:26:47 ... why do you need a make-alike to parallelize builds? 21:27:00 Thus reducing build time by factor 2 or 4 or even more. 21:27:13 Because they are already there. 21:27:28 Can you propose anything of comparable quality right now? 21:27:44 SCons? Sure, eww, python, but it works very well... 21:27:46 Make is out there, and tends to support parallelizing builds. 21:27:53 SCons? 21:27:56 http://www.scons.org/ 21:28:02 Sorry, but it doesn't fit. 21:28:38 I'm not about to make Python a requirement for porting MIT Scheme to a new system. 21:29:21 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 21:29:27 Naturally it would be nice to have something in Scheme, but that wouldn't work for this purpose. 21:29:52 heh, yes, depending on python -would- be silly for that case 21:30:00 ehird: does it have central configuration file? 21:30:06 Like sys.mk? 21:30:09 I guess make is the best option then, as a lowest common denominator 21:30:17 ASau: Not sure. 21:30:24 http://www.scons.org/doc/production/HTML/scons-user.html 21:30:46 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 21:30:49 Sorry, 800 K docs is WRONG answer. 21:30:54 I count it as "NO". 21:31:00 And this is strong MINUS. 21:31:22 I hate comprehensive documentation too. 21:31:32 jgracin__ [n=jgracin@82.193.210.126] has joined #scheme 21:31:41 Now we come to another point. 21:33:00 If a proponent can't defend a tool, it is bad tool. 21:33:10 Not a replacement in any case. 21:33:26 Remember, make is out there and it works nice already. 21:33:38 `Nice' is too strong a word. 21:33:47 It hobbles along, at least. 21:34:22 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 21:34:32 I can accept even this wording. :) 21:34:44 While make hobbles, scons doesn't exist. 21:35:32 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 21:35:42 jao [n=jao@221.Red-79-155-152.dynamicIP.rima-tde.net] has joined #scheme 21:38:50 -!- jgracin_ [n=jgracin@82.193.210.126] has quit [Read error: 110 (Connection timed out)] 21:39:03 First impressions after reading about scons and cons, 21:39:09 is they are solving non-problems. 21:39:17 -!- Arelius [n=Indy@netblock-68-183-230-134.dslextreme.com] has quit [] 21:39:22 Like unsync. clocks across network. 21:39:31 Arelius [n=Indy@netblock-68-183-230-134.dslextreme.com] has joined #scheme 21:40:16 -!- ecraven [n=nex@140.78.42.103] has quit ["bbl"] 21:48:39 this might be a question for #emacs, but i'm trying to set up my .emacs to turn on auto-fill-mode for scheme comments only. the c-mode hook at http://www.emacswiki.org/emacs/AutoFillMode doesn't work. does anyone have a .emacs set up that turns on auto-fill-mode just for comments? 21:48:59 I have this vague notion that there's a variable for just that 21:49:50 dmoerner: there's a variable called comment-auto-fill-only-comments; I suspect that if you set that to t in scheme mode, you'll get what you want. (You might want to make it buffer-local, too) 21:50:02 offby1, thanks, i'll check that out 21:50:33 annodomini [n=lambda@c-75-69-96-104.hsd1.nh.comcast.net] has joined #scheme 21:51:00 -!- seoushi [n=seoushi@c-67-186-243-205.hsd1.ut.comcast.net] has quit ["Leaving"] 21:51:42 annodomini_ [n=lambda@c-75-69-96-104.hsd1.nh.comcast.net] has joined #scheme 21:56:17 offby1, thanks, it worked perfectly 21:58:16 mejja [n=user@c-4bb5e555.023-82-73746f38.cust.bredbandsbolaget.se] has joined #scheme 21:58:25 \p/ 21:58:54 did you make it buffer-local? 21:59:04 if not, is that setting now trashing your other modes? :-| 22:01:56 i didn't make it buffer-local, and it isn't trashing my other modes, as far as i can tell 22:02:39 well, I bet it's doing _something_ evil. Check your liquor cabinet when you get home. 22:03:51 i think calls to auto-fill-function are buffer-local by default 22:05:11 0_o 22:07:32 -!- annodomini [n=lambda@wikipedia/lambda] has quit [Read error: 110 (Connection timed out)] 22:13:05 -!- hadronzoo [n=hadronzo@gateway.publicvpn.net] has quit [] 22:16:51 hhm [n=hhm@c-89-160-84-241.cust.bredband2.com] has joined #scheme 22:17:48 -!- hhm [n=hhm@c-89-160-84-241.cust.bredband2.com] has quit [Read error: 104 (Connection reset by peer)] 22:17:52 hhm_ [n=hhm@c-89-160-84-241.cust.bredband2.com] has joined #scheme 22:24:50 -!- hkBst [n=hkBst@gentoo/developer/hkbst] has quit [Read error: 104 (Connection reset by peer)] 22:29:02 -!- jgracin__ [n=jgracin@82.193.210.126] has quit [Remote closed the connection] 22:31:34 Nichibutsu [n=myfabse@wikipedia/Track-n-Field] has joined #scheme 22:33:21 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 22:34:46 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 22:36:09 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 22:36:15 -!- ehird [n=ehird@208.78.103.223] has left #scheme 22:37:34 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 22:37:57 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 22:38:14 -!- hhm_ [n=hhm@c-89-160-84-241.cust.bredband2.com] has left #scheme 22:39:21 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Connection reset by peer] 22:40:44 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 22:42:09 -!- Adamant [n=Adamant@unaffiliated/adamant] has quit [Client Quit] 22:42:16 -!- dmoerner [n=dmr@ppp-71-139-45-71.dsl.snfc21.pacbell.net] has quit [Read error: 131 (Connection reset by peer)] 22:43:52 -!- ack0 [n=user@s559195f7.adsl.wanadoo.nl] has quit ["ERC Version 5.3 (IRC client for Emacs)"] 22:47:56 -!- stepnem [n=xchat@topol.nat.praha12.net] has quit [Remote closed the connection] 22:48:47 stepnem [n=xchat@topol.nat.praha12.net] has joined #scheme 22:56:04 -!- stepnem [n=xchat@topol.nat.praha12.net] has quit ["Leaving"] 23:03:26 -!- jonrafkind [n=jon@c-98-202-86-149.hsd1.ut.comcast.net] has quit [Read error: 110 (Connection timed out)] 23:06:22 -!- ASau [n=user@193.138.70.52] has quit [Remote closed the connection] 23:06:37 ASau [n=user@193.138.70.52] has joined #scheme 23:08:52 Adamant [n=Adamant@c-76-29-188-22.hsd1.ga.comcast.net] has joined #scheme 23:10:44 borism_ [n=boris@195-50-200-198-dsl.krw.estpak.ee] has joined #scheme 23:12:06 stepnem [n=xchat@topol.nat.praha12.net] has joined #scheme 23:15:44 borism__ [n=boris@195-50-201-100-dsl.krw.estpak.ee] has joined #scheme 23:17:35 -!- borism [n=boris@195-50-201-67-dsl.krw.estpak.ee] has quit [Read error: 145 (Connection timed out)] 23:18:51 -!- borism_ [n=boris@195-50-200-198-dsl.krw.estpak.ee] has quit [Read error: 145 (Connection timed out)] 23:21:21 -!- jewel [n=jewel@dsl-242-138-129.telkomadsl.co.za] has quit [Read error: 113 (No route to host)] 23:22:44 -!- nasloc__ [i=tim@kalug.ks.edu.tw] has quit [Read error: 104 (Connection reset by peer)] 23:22:49 lowlycoder [n=x@unaffiliated/lowlycoder] has joined #scheme 23:23:01 is anyone here writing facebook apps using scheme? 23:23:08 if so, what library are you using to interface with facebook? 23:23:35 -!- puchacz [n=puchacz@87-194-5-99.bethere.co.uk] has quit [Remote closed the connection] 23:25:49 dmoerner [n=dmr@ppp-71-139-45-71.dsl.snfc21.pacbell.net] has joined #scheme 23:27:12 -!- lowlycoder [n=x@unaffiliated/lowlycoder] has quit [Client Quit] 23:27:48 -!- wingo-tp [n=wingo@30.Red-79-156-145.staticIP.rima-tde.net] has quit [Read error: 113 (No route to host)] 23:27:53 lowlycoder: Sorry, I haven't dared to touch Facebook apps. 23:28:38 -!- choas [n=lars@p5B0DFE8D.dip.t-dialin.net] has quit ["leaving"] 23:31:39 amaron [n=amaron@cable-94-189-243-158.dynamic.sbb.rs] has joined #scheme 23:34:59 -!- kilimanjaro [n=kilimanj@70.116.95.163] has quit ["Leaving"] 23:48:05 -!- morphir [n=morphir@217.168.81.9] has quit [Remote closed the connection] 23:50:50 Deformati [n=joe@71.238.45.45] has joined #scheme 23:51:44 -!- annodomini_ is now known as annodomini 23:51:49 morphir [n=morphir@217.168.81.9] has joined #scheme 23:57:14 -!- Lemonator [n=kniu@pool-71-165-128-172.lsanca.dsl-w.verizon.net] has quit ["Leaving"] 23:57:47 kniu [n=kniu@pool-71-165-128-172.lsanca.dsl-w.verizon.net] has joined #scheme 23:58:45 -!- kniu [n=kniu@pool-71-165-128-172.lsanca.dsl-w.verizon.net] has quit [Remote closed the connection]