00:00:00 --- log: started forth/06.12.07 00:09:10 --- join: Cheery (n=Cheery@a81-197-54-146.elisa-laajakaista.fi) joined #forth 02:22:19 --- quit: crc (Read error: 110 (Connection timed out)) 02:39:27 --- join: crc (n=crc@pool-70-110-168-177.phil.east.verizon.net) joined #forth 02:39:41 --- quit: crc (Read error: 104 (Connection reset by peer)) 02:39:46 --- join: crc (n=crc@pool-70-110-168-177.phil.east.verizon.net) joined #forth 02:40:04 --- mode: ChanServ set +o crc 03:30:13 --- quit: JasonWoof ("off to bed") 03:47:14 --- join: ecraven (n=nex@eutyche.swe.uni-linz.ac.at) joined #forth 04:07:27 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 04:07:27 --- mode: ChanServ set +o tathi 04:22:59 --- join: Mitja (n=abcd@unaffiliated/mitja) joined #forth 04:34:22 --- quit: erider ("I don't sleep because sleep is the cousin of death!") 04:58:29 --- quit: virl ("Verlassend") 05:01:20 --- quit: tathi ("leaving") 05:18:03 --- join: zpg (n=user@user-514d7663.l2.c2.dsl.pol.co.uk) joined #forth 05:19:28 afternoon 05:59:43 --- nick: Raystm2 -> nanstm 06:13:02 --- join: Ray_work (n=Raystm2@199.227.227.26) joined #forth 06:13:59 --- quit: segher (Nick collision from services.) 06:14:08 --- join: segher (n=segher@dslb-084-056-197-035.pools.arcor-ip.net) joined #forth 06:15:58 Good morning 06:25:51 Hi Ray. 06:26:13 Hi there zpg. How's your afternoon, so far? 06:26:27 Uneventful as ever :) 06:26:49 Have you just arrived at work? 06:27:54 Ya, got here about 40 minutes ago. Turn on things, make coffee... ( I'm the only one that doesn't drink coffee. I wonder why they trust me to make a good cup. :) ) 06:28:11 But I get here first so... 06:28:55 Got a trainee assigned to me today. 06:29:15 Busy day ahead then? 06:29:40 An articulate, well groomed and good attitude, young man showing great promise. 06:29:47 Ya, I will be. 06:45:03 --- join: virl (n=virl@chello062178085149.1.12.vie.surfer.at) joined #forth 06:54:26 --- quit: ellisway (Read error: 104 (Connection reset by peer)) 06:58:15 --- join: madwork (n=foo@204.138.110.15) joined #forth 07:11:24 --- quit: ecraven ("bbl") 07:35:24 --- join: JasonWoof (n=jason@c-71-192-26-248.hsd1.ma.comcast.net) joined #forth 07:35:24 --- mode: ChanServ set +o JasonWoof 07:35:48 --- quit: virl ("Verlassend") 08:15:24 --- join: futhin (n=wunderwa@bespin.org) joined #forth 08:15:24 --- mode: ChanServ set +o futhin 08:21:41 --- part: futhin left #forth 08:48:14 --- join: Shine (n=Frank_Bu@xdsl-84-44-225-68.netcologne.de) joined #forth 08:51:36 --- join: ellisway (n=ellis@host-87-74-241-174.bulldogdsl.com) joined #forth 09:00:44 --- join: neceve (n=claudiu@unaffiliated/neceve) joined #forth 09:56:42 --- quit: neceve (Read error: 104 (Connection reset by peer)) 09:59:48 --- join: neceve (n=claudiu@unaffiliated/neceve) joined #forth 10:04:10 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 10:04:10 --- mode: ChanServ set +o tathi 10:19:02 --- join: jackokring (n=jackokri@static-195-248-105-144.adsl.hotchilli.net) joined #forth 10:28:56 hi 10:30:45 http://forth.pastebin.ca/270438 10:32:15 their are 2 modes to enter a sudoku 10:32:54 Did you see the San Fransisco FIG sudoku discussion btw? 10:33:01 one with <| ... | ... | ... |> which allots the memory used and one with [| ... | ... | ... |] 10:33:10 with "+" redefined in the relevant vocabulary? 10:33:37 <| and [| redefine defer | 10:34:45 the problem is that one time | has the stack effect ( digit1 digit3 digit3 -- ) and the other time ( board digit1 digit3 digit3 -- board+3 ) 10:35:05 it works but ... 10:39:48 --- join: snowrichard (n=richard@12.18.108.162) joined #forth 10:47:18 hi snowrichard 10:49:52 --- join: crest_ (n=crest@p54896A4C.dip.t-dialin.net) joined #forth 10:51:20 --- quit: Crest (Nick collision from services.) 10:51:22 --- nick: crest_ -> Crest 10:55:20 --- quit: ellisway (Read error: 104 (Connection reset by peer)) 11:10:04 --- quit: neceve (Remote closed the connection) 11:10:10 --- join: Snoopy42_ (i=snoopy_1@dslb-084-058-174-043.pools.arcor-ip.net) joined #forth 11:17:42 --- quit: Snoopy42 (Read error: 145 (Connection timed out)) 11:17:51 --- nick: Snoopy42_ -> Snoopy42 11:40:19 nice, this regexp stuff works well. 12:30:51 hey 12:37:07 Quartus: do you have standard code for your module words that you'd share? 12:37:19 yes, I do -- let me ferret it up 12:37:42 thanks 12:41:41 --- join: marble (n=glass@cpc1-bolt6-0-0-cust18.manc.cable.ntl.com) joined #forth 12:42:58 http://nealbridges.com/source/modules.fs 12:43:31 That uses [undefined], which is non-standard, but you can snip that out if you don't want it. 12:45:57 I'm using gforth currently 12:46:10 Figured, but you did say Standard. :) 12:46:35 ya :) 12:47:42 That code is solid -- it uses its own module facility to hide its own private definitions. 12:52:30 --- join: ellisway (n=ellis@host-87-74-241-174.bulldogdsl.com) joined #forth 12:52:46 hi 12:52:51 hi. 12:52:51 hey 12:53:01 the volume has turned down here a tad. 12:53:15 good stuff. 12:54:29 * Ray_work goes to the lounge to lay down thru lunch. 12:54:42 Quartus: i've been meaning to ask you -- recall our zliteral code from yesterday ... does one need to worry about heap consumption? this is a more general question too -- does one need to pay mind to all these small ALLOTs? 12:54:57 zpg, I don't lose sleep over'em. 12:55:07 They're ALLOCATES, actually. 12:55:24 really? 12:55:35 : save-mem swap >r dup allocate throw swap 2dup r> -rot move ; 12:55:42 ah, neat. 12:56:04 i got the pcre stuff working very smoothly here btw. 12:56:09 good 12:56:13 No issues with the ffi? 12:56:25 it seems pretty solid 12:56:29 in general 12:57:34 I think it's just undocumented and unofficial because they haven't made a release of gforth since shortly after they added it. 12:58:40 no issues at all. 12:58:56 apart from trying to call libpcre.a instead of libpcre.dylib 12:59:10 and not having /sw/lib in a searchable path. 12:59:22 but those are minor and not ffi-problems. 12:59:24 If you scan c.l.f, there's some message from Ertl, I think it was, where he said they wrote the ffi, quickly discovered it was the 'wrong way to do it', and are reworking it. 12:59:47 What that means, I don't know. 12:59:49 huh 13:00:05 you were using the syntax where you specify the number of arguments and the return type, I think? 13:00:09 something along the lines of 'obviously not good enough'. 13:00:17 Yes. 13:00:29 there's also a syntax where you specify the type of each argument as well. 13:00:58 maybe that's what he was talking about 13:01:19 I don't know. It seemed a sweeping condemnation of what was there. 13:01:36 ah. 13:01:41 dunno then 13:01:58 Nor do I. Irritating, as it clearly works fine, and documenting it would only be useful. 13:02:34 yeah 13:03:06 AFAICT development on gforth pretty much petered out a few years ago 13:03:21 As I understand it a new revision is being worked on now. 13:03:58 oh, cool 13:04:10 0.6.2 works quite well, mind you. 13:04:26 these might give an idea of ffi ptr/int specications: 13:04:27 libpcre pcre_compile ptr int ptr int ptr (ptr) pcre_compile 13:04:27 libpcre pcre_exec ptr ptr ptr int int int int int (ptr) pcre_exec 13:05:02 zpg, I'm using a much simpler import facility that works under windows. 13:05:10 5 (int) pcre pcre_compile pcre_compile 13:05:10 8 (int) pcre pcre_exec pcre_exec 13:05:26 yeah i saw that yesterday 13:05:28 seems more concise 13:05:34 works, anyway. 13:05:51 you're still including fflib.fs right? 13:05:59 Quartus: can you do it the verbose way? 13:06:16 what about parameters that don't go in a single int register? 13:06:17 I'm including lib.fs. It includes another file. 13:06:23 eg floats of long longs? 13:06:33 JasonWoof, haven't tried. 13:06:34 s/of/or/ 13:06:50 mysql_num_rows() returns a 64-bit int 13:07:00 On PPC you have to use the verbose syntax, since parameters generally get passed in registers 13:07:04 At a guess, you'd have to specify a two-cell return. 13:07:08 --- quit: snowrichard ("Leaving") 13:07:23 yeah i was wondering about floats with ffi 13:07:45 If it's not a pointer to a float, then you'd have to move the float onto the data stack. 13:08:25 gforth has a float stack 13:08:33 dosen't it? 13:08:34 yes it does. 13:08:37 i has 13:08:50 *does 13:08:58 *it 13:09:02 :! 13:09:20 the ffi as it's currently defined passes parameters from the data stack; don't think it touches the float stack. I haven't looked very closely, though. 13:10:12 tathi, do you have some use in mind for the modules code? 13:10:31 modules? what madules code? 13:10:42 nobody tells me anything ;) 13:10:46 http://nealbridges.com/source/modules.fs 13:11:53 I did when I asked 13:12:06 been carrying on 3 conversations at once and can't remember what it was though 13:12:11 :) 13:13:45 oh, right. I while ago I started a vi-like editor in Forth. Was looking at picking it up again and thought it would be nice to hide a bunch of the implementation stuff. 13:14:55 I find having to make the decision -- ' will this word be visible or not ' -- is an aid to writing better code. 13:15:11 yeah 13:16:02 and it's a bit like a class system, you can open and access private words from previous modules in new ones. 13:17:26 under my ANS layer in RetroForth, I ported a few windows .h structures over, and put each .h in its own module -- so each had its own namespace. I open them as needed to get at the struct definitions. 13:17:44 nice 13:18:05 it is. The namespace facility in Standard Forth is sweet; gets very little use, I think. 13:18:14 yeah 13:18:21 I don't know how to use it 13:18:27 with the modules code, I use the hell out of it. 13:19:17 jason -- module foo : wow ." a private word" ; public: : gah ." This is public, but can access " wow ; end-module 13:19:18 well, the usual interface to it kind of sucks 13:20:07 within a module, you can switch back and forth between private: and public: (private: is the initial default). 13:20:20 And you can nest modules. 13:21:04 oh, sweet! someone added a PPC assembler to the CVS version of gforth 13:21:20 er, assembler/disassembler 13:21:31 nice. Who's the culprit 13:21:38 I was just in the process of doing that -- wasn't looking forward to fixing the last issues 13:21:56 the commit message says, "added PPC assembler by Michal Revucky; and another one without FSF copyright" 13:22:17 There was a young man named Revucky... 13:28:12 grr...CVS can be so annoying. 13:28:36 I keep forgetting that you have to pass a command-line flag to be informed about new directories which were added 13:47:46 --- join: virl (n=virl@chello062178085149.1.12.vie.surfer.at) joined #forth 13:53:33 Wow. HP calculator's RPN is quite Forth-like. 14:01:24 i just have a ti83+ 14:01:57 and afaik their is no forth system for it 14:02:18 can you define functions on the hp? 14:09:13 --- nick: nanstm -> tiff 14:13:32 tep free magnetic energy google it ?! 14:13:41 out chatting 14:18:45 That's one of the crackpot Naudin's 'free energy' claims, isn't it? 14:21:20 I've seen his junk exposed on the JREF page for the past few years. 14:24:40 good evening 14:24:49 hey again 14:29:03 "There was a young man... " hahaha 14:29:12 heh 14:29:32 you caught me in giggle mode. darn it. 14:30:22 * Ray_work is very tired. 14:30:32 not much sleep over last few days due to illness. 14:30:38 Stop that at once. 14:30:51 Giggle mode, very accessible when I'm in that condition. 14:30:59 Yes, sir! At once. 14:42:10 --- quit: Cheery ("Download Gaim: http://gaim.sourceforge.net/") 15:02:29 --- quit: jackokring (Read error: 110 (Connection timed out)) 15:35:53 --- quit: Ray_work (Read error: 104 (Connection reset by peer)) 15:50:21 --- quit: tathi ("leaving") 15:55:26 zpg? 15:56:17 had a thought re regexp 15:57:39 --- join: dso (n=user@200.181.84.119) joined #forth 16:08:28 --- part: dso left #forth 16:16:37 hi 16:16:51 what's the thought? 16:23:04 Hey. Thought was that you could store regexp dfas in an associative list, so that if you compiled the same pattern twice, it would return the previous dfa instead of making a new one. 16:23:16 Memoization, effectively. 16:24:33 In a constrained environment the list could be walked to free the least-recently-used as required, whenever a new compilation was requested. 16:25:02 It would amount to a caching system, would be very easy to code. 16:26:31 yeah, sounds neat. 16:27:34 as regards your earlier question about worrying about small allocations. 16:27:57 http://home.earthlink.net/~neilbawd/opg.txt 16:28:04 oops, wrong window :) 16:32:55 Yeah, the caching idea is a good one. I often wonder about allocation (or rather, allot'ing and creating temporary storage areas that are, due to implementation, static) 16:33:18 Perhaps nothing to worry about, but it'd be neat not to get into bad habits in terms of over-consumption. 16:33:34 Right. I don't worry about it much in anything that isn't expect to run continuously. 16:33:52 That figures. I guess we have quasi-garbage collection anyhow. 16:34:10 (in situations where ALLOT is used in non-continuous applications) 16:34:27 Yes, once you exit Forth, the memory is all garbage, and is collected. :) 16:34:37 Exactly. A nice thought. 16:34:48 Does that include ALLOCATE btw? 16:34:52 It does. 16:34:56 Even better. 16:35:06 Under any modern OS I'm aware of, at any rate. 16:35:09 Including the Palm OS. 16:35:13 --- join: nighty_ (n=nighty@sushi.rural-networks.com) joined #forth 16:35:30 Incidentally, my recollection is hazy re: malloc() and free() in C. If we malloc() a few times, then exit without free'ing, would a modern OS still treat that memory as locked? 16:35:44 Yeah, that's good enough for me :) 16:36:04 (malloc --> i.e. memory leaks) 16:36:05 It's not locked, though. malloc just allocates it. The OS should free it up on exit -- I'm not aware of any that wouldn't. 16:36:21 So why the big deal made of not free()ing malloc()s? 16:36:41 In-program leaks. Say, you're running FireFox, and it keeps consuming memory. 16:36:44 I get that if it's on a large scale on a small system, the situation would be wasteful/problematic. But the majority of the time, it seems unnecessary. 16:36:52 Yeah, that's true. 16:37:06 So most discussion of memory leakage is in terms of in-programme then? 16:37:10 Suppose it never freed the memory it allocated for bitmaps. You'd run out of memory, then out of swap, and then boom. 16:37:16 * zpg nods 16:37:18 Sure. 16:37:43 right, memory-leakage matters in anything that isn't transient. 16:38:33 Great, thanks for clearing that up. It's telling that most of my hacking takes place in GC'd languages. 16:39:31 I don't know of any OS that would leave orphaned memory, though. Crazy-ness. 16:39:45 Last question (then I best head to the social tea section again): in Forth, is our heap (as in, HERE moving up in memory) already pre-allocated in full? That is to say, when I start gforth or QF, is the full heap-space allocated in one go? 16:40:08 I believe it is in GForth; in Quartus Forth, it grows as it is used. 16:40:15 Interesting, okay. 16:40:35 And does ALLOCATE always use memory that is above (or below) the HEAP then? 16:40:47 Allocate may use memory from wherever it chooses. 16:40:58 including heap? 16:40:58 It won't be at HERE, though. 16:41:15 if it's above here, wouldn't a conflict ensue when here reaches the same address? 16:41:47 It won't be in the block of memory HERE uses. I suppose in a really crappy implementation, ALLOCATE might return blocks from the top-end of dataspace, but I've never seen that done. 16:42:03 Okay, that makes perfect sense. 16:42:09 There is an ALLOCATE implementation kicking around that uses dataspace, but it's a designated pre-ALLOTed chunk of dataspace that is then managed. 16:42:22 I see. 16:42:34 Also, what sits at address, say, 0? 16:42:49 In C terms, ALLOCATE is malloc(). Dataspace is a large pre-allocated array. 16:42:59 In what Forth? 16:43:03 HERE is always a high-value number when I start Forth. Example --> "here . 2242608 ok" at gforth startup. 16:43:10 yes, in Forth. 16:43:15 Sure. That's OS and implementation-dependent. 16:43:20 I mean, in *which* Forth? 16:43:31 Oh sorry, misread. Say, gforth. Or QF. 16:43:38 not, "in wot, Forth??" :) 16:43:42 heh 16:43:57 0 in QF is in dataspace. In GForth it isn't, at least not on this box. 16:44:25 So when you say it's in dataspace, what might be sitting there on QF? 16:44:44 In Quartus Forth the first few values in dataspace are used by the kernel. HERE starts a bit higher. 16:45:02 Let me do HERE in a fresh run of QF ... I get: 260 16:45:11 Ah okay. 16:45:21 So primitives, that sort of thing? 16:45:33 No, primitives are all in codespace, completely different address space. 16:45:38 Ah okay. 16:45:44 So what do you mean by kernel? 16:45:56 If it's dataspace, what sort of kernel data is being held there? 16:46:04 Oh, I thought you were asking if primitives lived in low dataspace. 16:46:32 I was, you cleared that up for me -- a misunderstanding on my part. I'm now wondering what you're keeping pre-260 if that makes sense. In general terms of course. 16:46:59 pictured numeric output buffer, floating-point stack, event buffer, stuff like that. 16:47:04 (I don't need a cell-by-cell run-down :)) 16:47:16 Ahh okay, neat. 16:47:23 This has all be very helpful, thanks as usual. 16:47:32 Sure. 16:47:55 I best go boil the kettle as is done here, otherwise I'll get harangued for my absence :) 16:48:03 Ok. 17:12:00 --- join: Zarutian_ (n=Zarutian@194-144-84-110.du.xdsl.is) joined #forth 17:12:31 Iceland, eh? 17:12:43 --- quit: Zarutian (Nick collision from services.) 17:13:09 --- nick: Zarutian_ -> Zarutian 17:18:09 --- join: Snoopy42_ (i=snoopy_1@dslb-084-058-178-112.pools.arcor-ip.net) joined #forth 17:24:37 --- quit: Snoopy42 (Read error: 145 (Connection timed out)) 17:24:49 --- nick: Snoopy42_ -> Snoopy42 17:58:19 --- quit: marble (".") 19:00:33 --- quit: zpg (Read error: 110 (Connection timed out)) 19:09:23 --- quit: nighty_ ("Disappears in a puff of smoke") 19:39:03 --- quit: segher (Read error: 110 (Connection timed out)) 19:49:10 --- quit: Shine (Nick collision from services.) 19:49:14 --- join: Shine_ (n=Frank_Bu@xdsl-81-173-249-115.netcologne.de) joined #forth 19:49:27 --- nick: Shine_ -> Shine 19:54:58 --- quit: virl (Remote closed the connection) 20:15:38 Quartus: ahh, the module thing sounds cool 20:15:56 I finally had a chance to look 20:16:10 It is -- I was saying to tathi, having to make the 'will this word be visible' decision helps me write better code. 20:16:49 in herkforth all are visible 20:17:00 but I decide if it's a word that will be used by other things 20:17:09 I have a prefix that means that it's meant to be used internally only 20:17:31 Private module words are visible, but only if you expose the module in question. 20:21:46 cool stuff 20:21:48 --- quit: JasonWoof ("off to bed") 20:26:00 --- quit: Mitja () 20:32:04 --- quit: Shine (Read error: 110 (Connection timed out)) 21:11:35 --- quit: ellisway (Read error: 104 (Connection reset by peer)) 21:12:02 --- join: slava (n=slava@CPE0080ad77a020-CM000e5cdfda14.cpe.net.cable.rogers.com) joined #forth 21:12:02 --- mode: ChanServ set +o slava 21:32:20 LUDDITE! YOU ARE ALL A FOOL! 21:32:37 this means you, of course, slava :) 21:32:57 THINK!!! 21:33:36 perhaps his new meds are working, he hasn't been on c.l.f for a bit 21:34:28 hmm, no -- he's in rec.crafts.metalworking 21:35:40 http://groups.google.com/group/rec.crafts.metalworking/msg/2651828374b38ae1 21:38:53 "Your home and bank account are safe with people like me ." 21:40:02 haha 21:40:09 i tried to build minimal factor images today 21:40:19 i got it down to 600kb before i got bored 21:40:32 did the ghost of colorForth past rise up to show you the error of your ways? 21:40:43 well, it was an exercise in untangling some dependencies 21:41:08 600k! That's a healthy size for a kernel. 21:41:33 how does that break down? 21:42:51 well, there's the data structure library, basic math words, parser, exception handling, module system, interactive interpreter, i/o words 21:42:55 no native compiler, gui, or tools 21:43:01 what's the biggest chunk? 21:43:17 i don't know 21:43:54 it's about an order of magnitude bigger than I'd expect. 21:43:54 i could probably make it smaller 21:44:36 i can build an image which just, eg, prints hello world and exits. this might be something like 10kb 21:45:07 sure. But hence my question about what's the biggest chunk. The only one of those I don't know what it is exactly is the data structure library. 21:45:25 arrays, hashtables, queues, etc 21:46:05 this 'kernel' is 1600 words 21:46:15 Sure. Still. I'd be curious to know how it breaks down. 21:46:27 i'm not sure how to find out 21:46:47 object file sizes? 21:47:12 the image is a single file 21:48:11 a .s would contain offset info that would help determine how big each section is, though of course I imagine it's not strictly sequential 21:48:26 these are not .o, or .s files 21:48:32 a factor image is a serialized object heap 21:48:41 I thought factor was written in C. 21:48:54 a portion is written in C, which is a ~100kb executable 21:49:11 I see. 21:49:15 most of it is written in factor, and the sources are loaded and dumped into an image 21:49:29 if you load the compiler, the image will have native code in it as well 21:49:39 with gui, tools, documentation, compiler its about 6mb 21:49:48 ok, maybe that's part of the reason. 21:49:59 That seems really, really huge to me, though. 21:50:26 just the documentation takes up a fair amount of space. 21:51:20 Text is big. Quartus Forth's kernel is 20K, but there's six times as much in the binary -- text messages, and symbol lookup. Highly compressed, but still the lion's share. 21:51:36 my image is not compressed 21:51:51 gzipped, the 6mb becomes just 1.5mb 21:52:08 I have a Palm OS symbol lookup table, 6200+ names & values, compressed down to 50K. 21:52:31 LotsOfCamelCaseConstants. 21:53:15 structs, etc. 21:53:43 my image stores objects so starting factor is a matter of loading the image and jumping to the entry point 21:53:48 so pointers take up a lot of space 21:54:32 I see. 21:55:27 also documentation is not stored strictly as text, but in a tree form, analogous to html, perhaps, but pre-parsed 21:55:52 oh, my strings are unicode strings too 21:56:36 I'm used to dealing with tens of K, rather than hundreds or thousands, as regards compiler kernels -- I'm sure there's a good reason for every byte, but you can imagine that it sounds big from a Forth perspective. 21:57:32 there's probably no good reason for a lot of bytes, because i haven't put the effort into shaving off unnecessary k's 21:57:40 i try to keep things small, but within limits 21:58:59 I guess from working with the Palm for ten years, I've had to always strive to keep size down and speed up. 21:59:11 speed is a goal for me 21:59:17 With a desktop system, you can get away with more. 22:00:12 common lisp systems are typically larger than factor, and all they have in the stock image is the terminal interpreter, no gui etc 22:00:16 sbcl has a 22mb image 22:00:38 sure, lisp is huge. 22:04:56 on x86-64, the factor image is almost twice as large, somewhere around 10mb 22:05:11 the pointers, I'm guessing. 22:05:29 yup 22:05:38 not exactly twice as large, because strings don't double in size 23:07:39 --- join: ellisway (n=ellis@host-87-74-241-174.bulldogdsl.com) joined #forth 23:59:59 --- log: ended forth/06.12.07