00:00:00 --- log: started forth/05.10.01
00:49:47 --- quit: Snoopy42 (Read error: 110 (Connection timed out))
02:12:36 --- join: Topaz (n=top@sown-86.ecs.soton.ac.uk) joined #forth
04:04:12 --- quit: tathi ("leaving")
04:57:31 --- join: Robert (n=robert@unaffiliated/robert) joined #forth
05:27:58 --- join: PoppaVic (n=pete@0-1pool64-237.nas22.chicago4.il.us.da.qwest.net) joined #forth
05:28:15 <PoppaVic> Howdy
05:28:17 <Robert> Hi.
05:28:53 <PoppaVic> What's the latest?
05:30:12 <Robert> Some coding... Just a minimal Forth kernel to show people how it works, without having to get into details like optimised/general code.
05:32:57 <PoppaVic> Hmm.. I think the sun just went - oh, the lamps are croaking - nm.
05:33:23 <PoppaVic> Yeah, premature-optimising is insane.
05:33:49 <Robert> Insane... but fun. ;)
05:34:40 <PoppaVic> well, I'd disagre - we try to help folks like that every day in ##C. THe kids all mumble optimized and efficient - and have no clue wtf what they even need to write.
05:36:18 <Robert> Fun as in playing.
05:36:22 <Robert> Not as in getting things done.
05:36:23 <PoppaVic> ahh
05:36:32 <Robert> I agree it's evil then. :)
05:36:42 <PoppaVic> Yeah, their "playing" gets very old.
05:37:07 <PoppaVic> I'm all for tinkering and throwaways, but sheesh.
05:49:24 --- quit: aum ()
06:58:53 <virl> The kids all mumble optimized and efficient?
06:59:01 --- quit: Topaz (Remote closed the connection)
07:02:52 <virl> he what? should that an attack be on xell or what?
07:49:01 <PoppaVic> Hmm... ok, I've either made a decision or hit a wall.
07:50:09 <PoppaVic> So far as I can tell, there is nothing remotely like a lib for save/load/send/recv of utf-8 and presentation-interfacing.
07:50:44 <Robert> You mean in general, or for a specific language/target?
07:51:55 <PoppaVic> I was thinking about my vm/engine... THe SOURCE to it is ascii, and heads will be ascii, but I wanted to use utf8 for all our own I/O. Basically, the only solution is am opaque string-type
07:53:08 <PoppaVic> I sorta' thought so years ago, but had hoped libs would catch up. They haven't, so... It's a bollix we'd need to work around.
07:54:13 <PoppaVic> Robert: even the wchar_t of C is a bollixed mess... Trying to save/load such would be just about futile.
07:55:17 <Robert> Think about Haskell's solution, then.
07:55:27 <Robert> Strings are linked lists of 32-bit unicode characters.
07:55:38 <Robert> So at least 8 bytes per character are used. :)
07:56:22 <PoppaVic> a LL for such is just silly
07:58:04 <Robert> Yes, but functional.
07:58:17 <PoppaVic> Basically, once built, the language should prolly save/load/store/write utf-8 - which means support - and presentation would be vastly simplified.
07:58:42 <Robert> How will you store it internally?
07:58:43 <PoppaVic> Robert: yer thinking like the kids that do realloc() per-input-char
07:58:55 <Robert> _I_ am?
07:59:04 <Robert> I'm describing the Haskell solution.
07:59:12 <Robert> I don't think it's a good one.
07:59:15 <PoppaVic> Robert: prolly as utf-8, because you just can't wish for wchar_t
07:59:25 <PoppaVic> yeah, sorry - Haskell, I meant
07:59:49 <Robert> Won't that couse trouble if one wants easy string manipulation?
08:00:03 <PoppaVic> string "of what" becomes my issue
08:00:29 <PoppaVic> ascii? fine. Convert it? ok.
08:00:45 <PoppaVic> convert BACK to ascii? (is that possible/sensible?)
08:01:56 <Robert> I guess it would be possible to use utf-8 in a string manipulation library, but I wouldn't like to code and debug it. 
08:02:00 <PoppaVic> Near as I can tell, from assorted readings at assorted times, unicode and utf-8 do not represent "embedded interpretations" - they simply reflect assorted charsets, no?
08:02:16 <PoppaVic> I never said the idea thrilled me.
08:02:52 <PoppaVic> But, getting a unified access to utf-8 seems a decent idea - everyone else wants to gloss it over.
08:03:04 --- join: JasonWoof (n=jason@c-71-192-20-4.hsd1.ma.comcast.net) joined #forth
08:03:04 --- mode: ChanServ set +o JasonWoof
08:03:09 <PoppaVic> hi jas
08:04:12 <PoppaVic> Robert: being American, I have managed for decades with ascii. I'm pretty sure the unicode/utf-8 shit is mostly for prompts and such - in local languages, but - other than HTML - how the heck can I tell?
08:05:19 <PoppaVic> Adding the ideas of colors and fonts/sizes - to me - suggests "use html".
08:05:28 <PoppaVic> so, I dunno.
08:05:46 <Robert> ASCII has prevented me from spelling my name. ;)
08:05:54 <PoppaVic> locales and unicode still makes me a trifle ill
08:06:09 <PoppaVic> Robert: how would you change that?
08:06:25 <PoppaVic> And, does it matter on a remote-machine/user?
08:07:31 <Robert> I change the spelling. ;)
08:07:52 <PoppaVic> I can easily envision a (slit) operator. But, now I almost have to add typing to stack-elements.
08:08:16 <PoppaVic> ..to add utf-8/unicode, I mean
08:08:20 <Robert> The typical ASCII horror is this: you enter your name in some web form. It barfs at it, telling you that "this is not a valid name".
08:09:05 <PoppaVic> yeah. The html presentation needs an html form of send-back that reflects/can-reproduce the output.
08:09:44 <PoppaVic> and, yes: anything should be reproducable in ascii - even if it looks insane.
08:10:23 <PoppaVic> I'm thinking it would take a fixed-set of escape-sequences.
08:11:10 <PoppaVic> Whenever I get too depressed, I think of ANSI-escapes.
08:12:56 <PoppaVic> There has just GOT to be a way to reconcile it. Even if we just scream and settle on 32-bit "chars"
08:13:33 <Robert> I think that might be the best way.
08:13:37 <PoppaVic> (internally? do we NEED a special form internally? - prolly)
08:13:54 <Robert> But I have no hard data on how much memory that's used by character data.
08:14:04 <PoppaVic> oh, you would not believe it
08:14:31 <PoppaVic> mandating all names/words/headers use ascii would simplify life hugely.
08:15:24 <PoppaVic> BUT, you'd still have "other" - and you'd want to obfuscate/opaque access to ascii AND "other" as far as presentation, at least.
08:18:04 * PoppaVic sighs
08:18:11 <PoppaVic> It's just not remotely pretty
08:18:20 <PoppaVic> Hmm
08:19:03 <PoppaVic> OK, let's ask a backasswards question: when do you NEED utf-8/unicode presentation/fonts?
08:21:38 <PoppaVic> It looks (to me) that it is 100% related to "write a string". (Unless someone knows of really whacked keyboards?)
08:22:24 <PoppaVic> even the html I recently downloaded is using an attrib of "charset=utf-8"
08:22:50 <PoppaVic> I dunno if this would be similar to form-entries?
08:23:08 <PoppaVic> brb... lemme' beat the isp
08:23:10 --- quit: PoppaVic ("Pulls the pin...")
08:24:37 --- join: PoppaVic (n=pete@0-1pool47-89.nas30.chicago4.il.us.da.qwest.net) joined #forth
08:24:55 <PoppaVic> OK, solved that issue
08:25:05 <Robert> Not sure if there even is a standard.
08:25:20 <Robert> And if there is, that only means that there exist non-standard versions.
08:25:20 <PoppaVic> there ain't
08:25:29 <PoppaVic> ASCII is pretty much *it*
08:25:32 <Robert> But I guess eventually one will appear.
08:25:50 <PoppaVic> I dunno about form-input and such, but it seems likely it too is ASCII
08:26:35 <PoppaVic> I'm beginning to think that a "string type" should just about be mandatory.
08:28:03 <PoppaVic> ..which would mean that, within the "language", you'd want handler-flags and vtables.
08:28:14 <Robert> They should make a modern C, without the legacy.
08:28:38 <PoppaVic> ..it also seems likely we'd need to settle on a "binary format" for files/images, etc
08:29:17 <PoppaVic> well, I can't force a rewrite on the C-commies, but I'd love a solution for this new VM
08:29:32 <Robert> What are you using it for?
08:29:41 <Robert> Or will be, in case it's not done.
08:29:42 <PoppaVic> which? the vm?
08:29:45 <Robert> Yes.
08:30:21 <PoppaVic> Ahh, I want a tight, portable core for a shell and other utilities - as opposed to writing a set of libs and coding in C forever.
08:30:54 <PoppaVic> THis is a central element in my "Metabuilder" stuff
08:31:43 <PoppaVic> I could, quite probably, use Gforth - but that propogates an awful lot of the issues and lets C and platforms pervert them.
08:32:31 <PoppaVic> Using a bytecode-engine simply means we can get past a lot of the crap.
08:33:15 <PoppaVic> ..and, yes: we might take an interactivity "speed hit" - but it should simplify native-code-compiling/optimizing
08:34:52 <Robert> Hm, I was thinking about using something machineforth-like for that. But I'm not sure how portable it will be in practice.
08:35:26 <PoppaVic> bytecode-engine == 100% portable, since any platform would need to r/w it at the least.
08:35:41 <Robert> Depends...
08:35:50 <PoppaVic> We merely mandate control.
08:35:59 <Robert> If it's too large, it won't fit on some platforms you would potentially like to support.
08:36:19 <PoppaVic> Java had a clew, and then got stupid. I'm not a committee or stupid
08:36:48 <PoppaVic> nonsequitur: you'd write a transformer/compiler to generate true native-code
08:38:39 <PoppaVic> The prime reason I am working within the VM-structure is mostly because I just KNOW that different CPU/platforms can do some shit better/faster
08:39:10 <PoppaVic> ..and we should not care if they do. What we care about is the source and bytecode
08:42:00 <PoppaVic> Robert: do you remember FIG-forth?
08:42:16 <PoppaVic> (tinkering with it, I mean)
08:43:17 <PoppaVic> It had a lot of Good Ideas, even though it was written in asm.
08:43:59 <PoppaVic> They only had a dozen or 2(3?) funcs that really depended on actual cpu-opcodes.
08:44:34 <Robert> It's from before I was born. And I've only used it some (the 6502 version).
08:45:02 <PoppaVic> Sure, it wasn't super-portable; and, yes: you generally parsed-to-compile. But, you could have a forth up and running in a day or two
08:45:23 <PoppaVic> We can do better.
08:47:12 <PoppaVic> I want us to have a lowlevel, mandated language. Where we can all talk-the-talk and walk-the-walk AND interface to C - anywhere.
08:49:22 <PoppaVic> The only thing I can't see as sensible/possible to the whole mess is inline-asm. That looks to me - from all angles - like an invitation to haqueers
08:49:51 <PoppaVic> otoh, I don't see a monster-issue with dlopen/plugins
08:51:27 <PoppaVic> This is why, months ago, I broached the idea of a synthetic-assembler in #asm (and here). And, I knew we could Forthish over the top of it.
08:52:03 <Robert> Synthetic?
08:52:11 <PoppaVic> Further, I was also aware we'd get a few smarties to optimize JIT
08:52:43 <PoppaVic> synthetic, sure: not THE regs or stack or opcodes - just enough to combine and recombine to do what we all need
08:53:03 <PoppaVic> in other words: synthesized & portable
08:53:39 <PoppaVic> ..and we would never, EVER care how any platform wrote and optimized their native-code
08:54:05 <PoppaVic> This is akin to Java and .Net from the outside/top
08:55:01 <PoppaVic> Another view would be: a nonexistant-CPU emulator - we don't care how shit gets done, just that it does.
08:55:30 <PoppaVic> ..we WOULD care about our bytecode
08:56:29 <PoppaVic> and, hell: we'd nearly EXPECT every advocate to write a native-code compiler for either the bytecode or the source.. All we _care_ about is: run the bytecode.
08:57:18 <PoppaVic> oh, and "this source is IT - suffer it"
08:58:31 <PoppaVic> The issues I generally see are source-related and ABI - we want an ABI/API we can rely on, and could care the hell less what happens to get it all done.
09:03:19 <PoppaVic> The problem with most "languages" is they want to take source and slap out native-code. GCC manages to generate .asm instead, but shit.. they generate .i (intermediate) files too - and can't work with them. Plus, to C - "preprocessing" is 1D: you use it or lose it... Forthish languages are different.
09:04:04 <Robert> Yes. I was thinking a bit about if it's possible to integrate gcc into that way of metaprogramming.
09:04:14 <PoppaVic> Similar issues make sh (and variants) problematic - in the other direction.
09:04:27 <Robert> Or if you'd have to use an interpreted language for the compiler.
09:04:31 <PoppaVic> right
09:04:50 <PoppaVic> The bytecode is the "intermediate file" - and executable.
09:05:21 <PoppaVic> Further compiling that should, likely, generate a native-code object
09:06:25 <PoppaVic> Soo.. we have ASCII source (portable), we have bytecode (portable and executable), and we have nativecode (nonportable, executable)
09:07:38 <PoppaVic> the Latter is only generated by transforming the former, (sensibly).
09:08:20 <PoppaVic> And, of course: there should be a way to have the engine load the nativecode variants.
09:09:31 <PoppaVic> dlopen makes me smile anywhere - even when my powerbook sez it's not recommended for "new projects"
09:10:23 <PoppaVic> native objects, libs, and plugins(modules) are a completely positive thing.
09:10:55 <PoppaVic> bytecode and images and the engine(support) are also positive.
09:11:56 <PoppaVic> Remember, please: parsing/interpreting is a time/space eater. Expecting the host or client to do all of it is jsut silly.
09:12:47 <PoppaVic> generating our "intermediate code" on a host and sending that to a client/target saves a load of space/time.
09:12:52 <Robert> Ah.
09:12:56 <Robert> There we go.
09:13:28 <Robert> Small Forth, very heavily commented with explanations of everything.
09:13:31 <PoppaVic> Doesn't matter if we talk client/server (internet) or "distributions".
09:13:42 <PoppaVic> Robert: url?
09:14:11 <Robert> 622 lines of assembly language. A holy number. ;)
09:14:30 <Robert> Hm, not yet. Got it to work a minute ago, but if you want to see I could upload.
09:14:41 <PoppaVic> I dunno, asm generally makes me ill: I'm an ancient Z80/8080 hand ;-)
09:14:55 <PoppaVic> just make sure I get the url, ok? ;-)
09:15:56 <Robert> http://www.robos.org/code/edforth.tgz
09:16:15 <Robert> Remember, it's of course not complete and not exactly throroughly tested.
09:16:33 <PoppaVic> Got it
09:16:55 <PoppaVic> 10.7K? teeny ;-)
09:17:07 <Robert> That's with the libc loader.
09:17:16 <Robert> The object code is a couple of kB.
09:17:18 <PoppaVic> Cool. It's here to read
09:17:40 <PoppaVic> ANyway, you can prolly see where my above comments lead.
09:18:05 <Robert> It's not meant for serious use - just an indirect-threaded Forth for demonstration of Forth (and x86 assembly language in general).
09:18:26 <PoppaVic> Yep - I can't use it on my powerbook, but I can prolly read it
09:19:19 <PoppaVic> The whole CPU thing is why I like the jas/tathi "opcodes" and definitely using C
09:22:02 <PoppaVic> I've never once - in over 20 years of C - seen a nice, uniform ASCII/source methodology to reflect the ABI... It's all munged and madness, as looking at the gcc and platform/cpu sources will soon teach you.
09:23:53 <Robert> C has a 7-bit character data type. Enough said. ;)
09:25:22 <PoppaVic> too harsh and leaves out a lot of issues - nuf said
09:27:05 <PoppaVic> I'll tell you what... Show me a decent "examplar Forth", using a synthetic CPU. And support freaky chars/strings well - I'll port it ;->
09:27:48 <PoppaVic> "Port it from WHAT?", you ask - I have no idea - almost nothing but ascii is portable!
09:28:34 <PoppaVic> let's try another approach...
09:29:44 <PoppaVic> Given that we know ascii is portable most anywhere (particularly to forthish), show me a system w/o "strings" other than ascii-heads.
09:30:10 <PoppaVic> ..I think we need an opaque-type.
09:32:10 <PoppaVic> we can talk of int and short, and even uint32_t and uint16_t; but adding "string" to it seems to bollix the universe.
09:32:37 <PoppaVic> "strings" seem to defy definition
09:33:25 <PoppaVic> I believe this the fault of "char" (byte) and "void/void*"
09:33:52 <Robert> Like I said, I was thinking about making a machineforth-like code, which can easily be ported, and then build a more complex system on top of that.
09:34:05 <PoppaVic> Yep, as I;ve been doing
09:34:39 <PoppaVic> It won't make you friends, though - no one wants to hear that their axe isdull
09:36:45 <Robert> Being popular is all about getting crazy enough friends.
09:38:08 <PoppaVic> or feeding their own insanities
09:40:37 <PoppaVic> I see that particular insanity regular with ##C - some folks feel that ansi or posix are "complete standards"
09:41:59 <PoppaVic> They keep forgetting.. ANSI doesn't cover abi let alone dirs/files; and posix covers dirs/files - but that everone adopts bits of this & that.
09:42:52 <PoppaVic> So, only in creating a synthetic-aperature-language can you even remotely promote "portability"
09:43:31 <PoppaVic> and, shit... THe minute you need a string or a path-sep, yer opening the door to "bite my ass hard!"
09:43:58 <Robert> Just don't fall in the trap of Java - making it so portable that actually doing anything gets inconvenient. ;)
09:44:17 <Robert> Like, having to create five different objects to read a line of input.
09:44:23 <PoppaVic> right. You can't. You need local vtables and such
09:44:47 <PoppaVic> all we care about is bytes and bytecodes, etc.
09:45:04 <PoppaVic> or: ascii, bytes, and bytecodes
09:45:46 <PoppaVic> and, I flat-out refuse to consider crap that uses other-than-eight bits/byte
09:46:24 <PoppaVic> I can't help the fact that CS twits added new terms, but I can refuse to suffer them overly.
09:46:57 <PoppaVic> you just about need to to talk to the Internet, anyway
09:47:25 <PoppaVic> "Oh, but those are 'octets'!" - nogo, kid. I was here before you, goddamnit
09:47:54 <PoppaVic> shit, they want to argue wtf a "nybble" is and how to spell it!
09:48:07 <Robert> Just watch out for the 12-bit dinosaurs.
09:48:15 <PoppaVic> screw  em
09:48:30 <PoppaVic> a new mobo is less than $400
09:49:45 <PoppaVic> ppc, x86 or M68 - they can usually talk 'byte' and 'nybble' and simply need endian for longer - even if 'word' is broken.
09:50:36 <PoppaVic> consistency. In our own code and available for checks: this will allow porting anywhere.
09:51:00 <PoppaVic> I like vtables and vectors/callbacks for a reason
09:52:36 <PoppaVic> I never EVER understood crapforms that refused to think "powers of two"
09:52:57 <PoppaVic> S'not like they promoted trinary
09:54:11 <PoppaVic> Anyway, I'll attach the tarball to you this pm.
09:54:19 <Robert> Now we'll have some fun with 64-bit incompatiblities.
09:54:24 <Robert> OK, nice.
09:54:29 <Robert> I sent the letter.
09:54:39 <PoppaVic> Yeah. 64-bit rugrats are ANOTHER idiocy.
09:55:06 <PoppaVic> "why can't I compile this 64-bit" - umm, why is the 32-bit code bad?
09:55:31 <PoppaVic> they think it's - what? faster? larger? tighter? I can't tell anymore
09:56:40 <PoppaVic> I'm trying to see an advatage to 8-bytes. Pointers? size_t? Unacceptable, it should have been a struct to begin with.
09:56:41 <Robert> Well... 32 bits of addressing space is getting a bit tight.
09:57:08 <PoppaVic> if 32 bits is "tight" then 64 bits is nust another step to sloppy-shit
09:57:13 <PoppaVic> nust/just
09:57:22 <Robert> Hm?
09:57:26 <Robert> How do you mean?
09:57:46 <PoppaVic> I've watched a lot of idiots talk about multi-gig files.
09:58:28 <PoppaVic> None of them consider several files smaller and merging/sorting - they seem to believe any one file should fill a drive
09:59:06 <PoppaVic> I grew up on 64K and smaller, more than that is just golden
09:59:12 <virl> one byte would be cool, but howto solve multibyte arithmetic properly?
09:59:44 <Robert> The question is why to NOT do 64-bit on (relatively) high-end machines.
09:59:52 <PoppaVic> Every 'size' needs it's own math
09:59:57 <Robert> It's not like everything will be 64-bit.
10:00:17 <PoppaVic> Thats fine, and I applaud them - now show me portable.
10:00:21 <virl> when you have data from a 32 bit system and want to accelerate it, so you use 32 bit but you cant do that on a 8bit system, so howto solve this?
10:00:35 <PoppaVic> or, admit it and document it as "mandated"
10:01:05 <PoppaVic> think back to 8086
10:01:28 <PoppaVic> nuff said - we had LARGE numbers in forth on 8080s
10:02:07 <Robert> But why limit yourself to that? 
10:02:20 <PoppaVic> It sounds trite, but I suspect kids can't see how forth and such did 16 or 320bit numbers on 8-bit forths
10:02:47 <Robert> I mean, you could make everything 8-bit and emulate floating-point and 32-bit arithmetic.
10:02:50 <PoppaVic> 32bit, not 320
10:02:59 <Robert> But you'd still have 32-bit datatypes.
10:03:03 <PoppaVic> yeppers
10:03:16 <PoppaVic> but that 8-bit matters
10:03:16 <Robert> ..and a lot of performance loss.
10:03:26 <PoppaVic> yep, so write it proper - top-down
10:03:53 <PoppaVic> anyway, I need to slid and check dinner & whatnot - stay well
10:03:56 --- quit: PoppaVic ("Pulls the pin...")
10:03:57 <Robert> Bye
10:04:21 <virl> eh? that idea seems somekind of silly. 'oh man, we have the power but why should we use it?'
10:04:51 <virl> it reminds me why OOP is slow.
10:05:36 <Robert> Oh?
10:07:06 <virl> thousands of classes which interconnects to each other, slows down in runtime linking and execution time. it also produce an overhead.
10:07:39 <Robert> Depends on how you do it, I guess...
10:08:45 <virl> yep, so most do it wrong
10:09:07 <virl> ehm, I meant most do it wrong.
11:01:19 --- join: OrngeTide (i=orange@rm-f.net) joined #forth
11:01:24 <Robert> Hi.
11:01:46 <OrngeTide> hi
11:04:57 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth
11:05:18 <Robert> And hi, tathi 
11:12:07 <tathi> Hi Robert
11:39:00 --- quit: ccfg ("leaving")
11:39:14 --- join: ccfg (n=ccfg@dsl-roigw3a42.dial.inet.fi) joined #forth
13:02:46 --- join: sproingie (i=foobar@64-121-2-59.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth
15:29:40 <virl> is there a forth for the TI Voyage 200?
15:29:58 <Robert> What kind of machine is that?
15:32:42 <virl> an calculator
15:32:48 <virl> a
15:33:01 <Robert> Hm, OK. Sorry, I have no idea.
15:37:44 <virl> nicely integrated the programming language in them, it's some kind of basic I think.
15:38:07 <Robert> Got a TI-82 here.
15:39:44 <virl> hmm a TI-82 how is it?
15:40:28 <virl> I have also a TI-83 Plus here.. is it compareable?
15:40:33 <Robert> Pretty OK for a calculator, but I don't code much for fun.
15:40:40 <Robert> Yeah, they're very similar.
18:25:21 --- join: aum (n=aum@60-234-156-82.bitstream.orcon.net.nz) joined #forth
19:14:11 --- join: TheBlueWizard (i=TheBlueW@ts001d0068.wdc-dc.xod.concentric.net) joined #forth
20:01:26 --- part: TheBlueWizard left #forth
20:06:30 --- join: Amanita_Virosa (n=jenni@CPE0000e812679b-CM000a7362da55.cpe.net.cable.rogers.com) joined #forth
20:56:06 --- join: LOOP-HOG (n=chatzill@63.105.22.119) joined #forth
20:56:13 <LOOP-HOG> hi
21:10:38 --- quit: Amanita_Virosa ("Slips out quietly")
22:19:25 --- quit: OrngeTide ("bye")
22:34:19 --- quit: sproingie (Remote closed the connection)
23:58:18 --- quit: LOOP-HOG ("ChatZilla 0.9.61 [Mozilla rv:1.7.1/20040707]")
23:59:59 --- log: ended forth/05.10.01