02:38:05 Modius [~Modius@cpe-70-123-140-183.austin.res.rr.com] has joined #ccl 04:19:18 Is there a way to get UUID in CCL, in any or all the variants? 07:10:50 jdz [~jdz@193.206.22.97] has joined #ccl 12:44:36 -!- sellout- [~Adium@c-24-61-13-161.hsd1.ma.comcast.net] has quit [Ping timeout: 255 seconds] 12:49:53 sellout- [~Adium@c-24-61-13-161.hsd1.ma.comcast.net] has joined #ccl 12:52:50 -!- sellout- [~Adium@c-24-61-13-161.hsd1.ma.comcast.net] has quit [Client Quit] 13:11:01 sellout- [~Adium@64.134.67.68] has joined #ccl 13:42:46 clop2 [~jared@moat3.centtech.com] has joined #ccl 13:50:18 trivial quesetion... i'm surprised that the second version uses more memory than the first, here... http://pastebin.com/femgghf7 13:50:24 just wondering why that is 13:50:27 -!- chandler [~foo@opendarwin/developer/chandler] has left #ccl 14:11:38 -!- sellout- [~Adium@64.134.67.68] has quit [Quit: Leaving.] 14:15:20 sellout- [~Adium@173-162-137-153-NewEngland.hfc.comcastbusiness.net] has joined #ccl 14:16:42 milanj [~milanj_@109-93-62-183.dynamic.isp.telekom.rs] has joined #ccl 14:21:09 hi, does ccl have fork, i assume it doesn't since i cant find anything with (apropos "fork") ? 14:22:32 milanj: not that it will help you any, but you should do (apropos "FORK") instead. 14:23:42 milanj: you can try using osicat 14:24:23 hm, thanks for tip, i did not know that it's implementation dependent (upcase string in apropos) 14:24:41 milanj: it is not implementation dependent 14:25:18 "Whether or not the search is case-sensitive is implementation-defined." ? 14:25:24 if i got you right 14:26:14 milanj: oh, right. never noticed that. 14:26:32 i have not seen an implementation where it is case-insensitive 14:26:40 me neither 14:27:09 really? then why did you use lower case? 14:27:10 btw. i suscpet that any library can implement fork style feature for different lisp compilers 14:27:27 i just read that it's "implementation dependent" 14:27:37 after your remark 14:28:04 but still you say you have not seen an implementation where it is case-insensitive... 14:28:41 and what do you mean by "a library can implement fork"? 14:29:38 "can easily implement" 14:30:03 hm, there is osicat:fork 14:30:04 heh 14:30:12 thanks for tip 14:30:30 why do you need "fork"? 14:31:08 i'm pretty sure if you think that a library "can easily implement fork" then you don't know what you're talking about 14:31:26 no offense 14:31:45 sure, thanks for tip anyway 14:33:15 sure, go on, shoot yourself in the foot. 14:39:01 will do 14:41:51 -!- sellout- [~Adium@173-162-137-153-NewEngland.hfc.comcastbusiness.net] has quit [Quit: Leaving.] 15:40:00 APROPOS is case-insensitive in CCL 15:40:37 gbyers, does fork work on a CCL process? 15:40:51 I.e do you end up with a working lisp in the new process? 15:41:58 I know it works well enough to spawn other processes, but I don't know if everything works correctly 15:42:02 To remain in lisp 15:43:22 billstclair: thanks for clarification. 15:44:31 ccl::run-external-process does a fork 15:44:42 using #_fork 15:45:07 And the lisp works well enough in the child to call ccl::exec-with-io-redirection 15:45:38 But jdz's question is the first one to answer. Why, milanj, do you need "fork"? 15:53:26 rme [~rme@50.43.163.111] has joined #ccl 15:53:36 -!- jdz [~jdz@193.206.22.97] has quit [Ping timeout: 255 seconds] 16:18:41 well, i need parallel execution and i can't use threads, right now i'm using run-external-program but i thought it would be easier with fork() if it's working correctly 16:19:22 anyway, i will stay with run-external-program, thanks billstclair 16:19:34 ok 16:20:19 The problem with fork is that it doesn't fork all threads. 16:20:19 Code you didn't write that's not thread-safe? 16:21:11 So you can't do fork and expect to have two fully-functional lisps. 16:21:19 rme, yes, i dont want to use threads anyway and would not run code from SLIME 16:21:36 ccl always uses at least two threads 16:22:20 hmm, did not know that 16:22:49 The initial-process thread doesn't do anything except wait around, though, unless your startup code makes it do something different 16:23:22 Or does it do some periodic cleanup, rme? 16:23:42 auto-flushes streams, does some special case interrupt handling 16:25:05 see ccl::housekeeping 16:26:35 i really needed multi process simulation in linux processes context, thanks for explanation though 16:26:46 i will use run-external-program 16:27:11 You probably want ccl:run-program, don't you? 16:27:34 yes, i'm using that 16:28:08 but fork() (if it's working 100% right) is simple solution without need to worry about code loading and stuff ... 16:57:32 anRch [~markmilli@pool-68-163-148-10.bos.east.verizon.net] has joined #ccl 17:05:51 jajcloz [~jaj@pool-108-20-32-147.bstnma.fios.verizon.net] has joined #ccl 17:09:01 sellout- [~Adium@c-24-61-13-161.hsd1.ma.comcast.net] has joined #ccl 17:32:09 -!- anRch [~markmilli@pool-68-163-148-10.bos.east.verizon.net] has quit [Ping timeout: 255 seconds] 17:51:42 clop2: It looks like strip-cars2 always allocates one more cons cell than strip-cars. If you do (ccl:macroexpand-all '(loop for pair in x collect (car pair))) you'll probably see that it conses some temporary thing to keep track of the tail end of the result list. 17:53:29 Modius: You asked about UUID generation in ccl; there's no built-in way to do that. There's bound to be a UUID library, though. 17:54:16 rme: Thanks 17:54:20 *rme* finishes reviewing #ccl logs 17:54:50 rme: There is a library, I was just wondering if a case could be added to the lib like with some other versions (was thinking of submitting a LW-related patch) 17:55:11 What special thing does the library need? 17:56:53 rme: Doesn't really need anything :) 17:57:06 When I asked, I didn't know that even at OS level it was generating fully random guids (in windows) 18:12:03 rme, thanks, i'll take a look 18:25:23 anRch [~markmilli@63.112.62.27] has joined #ccl 18:42:51 what's the difference between ccl::rtdsc64 and ccl::rtdsc? 18:43:23 the latter seems to not necessarily be a fixnum? 18:45:43 correct 18:46:40 rdtsc64 returns an (unsigned-byte 64) and rdtsc just returns the number of bits that fit in a fixnum 18:48:20 ah, so on 64-bit i probably want to just use rdtsc (under the assumption that 61 bits is enough), but on a 32-bit platform i might be in trouble because presumably 32-bits of rdtsc wouldn't be enough for lots of applications? 18:52:54 It depends on how much time whatever it is you're measuring takes, yes. 18:53:44 I believe that it's possible that multiple processors won't necessarily have the TSCs in sync. 18:54:07 yeah, that could probably get goofy 18:55:05 There's a function ccl::rdtsc-monotonic that tries to deal with that, but it's unexported, use at your own risk, etc. 19:00:43 ah nice 19:00:47 i should probably stay away from it for now though 19:04:49 internal-time-units-per-second is 1e6 on 64-bit lisps, so that makes get-internal-{run,real}-time pretty useful in many cases. 19:05:50 right, it seems like the rdtsc stuff is quite a bit faster though 19:07:06 rdtsc is something like a dozen instructions; get-internal-run-time involves a system call. 19:08:52 yeah; i was looking at the code... 19:09:07 i'm not sure what get-internal-run-time does but it seems to a bit slower than real-time 19:39:07 -!- anRch [~markmilli@63.112.62.27] has quit [Quit: anRch] 20:02:26 jdz [~jdz@host80-110-dynamic.14-87-r.retail.telecomitalia.it] has joined #ccl 20:31:08 tunes [~Fare@ita4fw1.itasoftware.com] has joined #ccl 21:55:34 gb_ [~gb@c-68-35-35-22.hsd1.nm.comcast.net] has joined #ccl 21:55:41 -!- gb_ [gb@clozure-517540A9.hsd1.nm.comcast.net] has quit [Quit: Leaving] 21:55:42 -!- gb_ [~gb@c-68-35-35-22.hsd1.nm.comcast.net] has quit [Client Quit] 22:13:54 -!- milanj [~milanj_@109-93-62-183.dynamic.isp.telekom.rs] has quit [Quit: Leaving] 22:28:40 -!- alms_ [~alms_@146-115-42-237.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 22:55:33 -!- jajcloz [~jaj@pool-108-20-32-147.bstnma.fios.verizon.net] has quit [Quit: jajcloz] 23:25:59 -!- jdz [~jdz@host80-110-dynamic.14-87-r.retail.telecomitalia.it] has quit [Ping timeout: 240 seconds] 23:26:54 -!- tunes [~Fare@ita4fw1.itasoftware.com] has quit [Quit: Leaving] 23:30:27 bfulgham [~brent@wsip-72-215-191-226.sb.sd.cox.net] has joined #ccl 23:37:58 jdz [~jdz@host253-111-dynamic.8-87-r.retail.telecomitalia.it] has joined #ccl