00:00:00 --- log: started forth/07.10.28
00:06:02 --- join: H4ns (n=Hans@dslb-088-070-189-187.pools.arcor-ip.net) joined #forth
00:08:06 --- quit: H4ns (Read error: 104 (Connection reset by peer))
00:09:25 --- join: saon_ (n=saon@adsl-154-209-184.jax.bellsouth.net) joined #forth
00:09:50 --- quit: saon (Read error: 104 (Connection reset by peer))
00:10:24 --- quit: forther (Read error: 110 (Connection timed out))
00:21:11 --- quit: timlarson__ (Read error: 104 (Connection reset by peer))
00:31:35 --- nick: XeF4_ -> XeF4
00:33:48 --- quit: saon_ (Read error: 104 (Connection reset by peer))
00:35:16 --- join: timlarson__ (n=timlarso@user-12l37rb.cable.mindspring.com) joined #forth
00:37:35 --- join: saon (n=saon@adsl-154-209-184.jax.bellsouth.net) joined #forth
02:59:25 --- join: yumehito (n=yumehito@b-internet.87.103.254.70.snt.ru) joined #forth
03:53:12 --- quit: Off_Namuh74 (Read error: 104 (Connection reset by peer))
05:07:26 --- join: Off_Namuh74 (i=GPS@gateway/tor/x-7f2c9a67d080f154) joined #forth
05:33:10 --- join: Quartus__ (n=Quartus_@205.205.50.1) joined #forth
05:35:14 --- join: Al2O3 (n=Al2O3@c-75-70-5-69.hsd1.co.comcast.net) joined #forth
05:47:54 --- quit: Al2O3 (Read error: 104 (Connection reset by peer))
05:47:54 --- join: Al2O3_ (n=Al2O3@c-75-70-5-69.hsd1.co.comcast.net) joined #forth
05:48:04 --- quit: Al2O3_ (Remote closed the connection)
05:48:15 --- join: Al2O3 (n=Al2O3@c-75-70-5-69.hsd1.co.comcast.net) joined #forth
06:07:35 --- quit: Robert (Read error: 104 (Connection reset by peer))
06:11:49 --- join: Robert (i=robert@unaffiliated/robert) joined #forth
07:30:13 --- quit: saon ("Lost terminal")
07:40:11 --- join: nighty__ (n=nighty@sushi.rural-networks.com) joined #forth
07:50:30 --- join: ygrek (i=user@gateway/tor/x-740b6e01314fe842) joined #forth
07:53:24 --- quit: nighty^ (Read error: 113 (No route to host))
08:09:57 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth
08:09:57 --- mode: ChanServ set +o tathi
08:11:35 --- quit: nighty__ (Read error: 110 (Connection timed out))
08:11:57 --- join: nighty^ (n=nighty@sushi.rural-networks.com) joined #forth
08:45:34 --- join: iano_ (n=iosgood@sub26-46.member.dsl-only.net) joined #forth
08:45:39 --- quit: iano_ (Remote closed the connection)
08:45:58 --- join: iano_ (n=iosgood@sub26-46.member.dsl-only.net) joined #forth
08:46:46 --- quit: iano_ (Client Quit)
08:46:57 --- join: iano_ (n=iosgood@sub26-46.member.dsl-only.net) joined #forth
08:57:33 --- quit: nighty^ (Read error: 113 (No route to host))
08:59:39 --- join: nighty^ (n=nighty@sushi.rural-networks.com) joined #forth
09:02:26 --- quit: nighty^ (Remote closed the connection)
09:12:34 --- join: Amanita_Virosa (n=jenni@pool-71-244-118-203.albyny.fios.verizon.net) joined #forth
09:13:25 <Amanita_Virosa> is there a standard word that does "variable @" in a form like "WORD variable"?
09:15:14 <arke> hmm
09:15:16 <arke> none that I know of.
09:15:22 <arke> long time no talk though, hi :D
09:15:28 <Amanita_Virosa> hiya arke :)
09:15:47 <Amanita_Virosa> i'm designing a script language...  it's more FORTH than not, but it's still a little different in a few ways.
09:15:58 <arke> hmm
09:16:02 <arke> maybe PEEK?
09:16:10 <arke> PEEK <variableName>
09:16:11 <Amanita_Virosa> too wordy, i want to use something symbolic.
09:16:25 <Amanita_Virosa> some types of variables require this for every get.
09:16:47 <Amanita_Virosa> (the problem is that the language is 5-stack)
09:16:52 <arke> 5 stack o.O
09:17:16 <Amanita_Virosa> yep: Parameter, Return, Exception, Object, and Float
09:17:52 <arke> ah
09:17:55 <arke> what's the object stack for?
09:18:04 <Amanita_Virosa> pointers.
09:18:08 <Amanita_Virosa> to GC-managed objects.
09:18:12 --- join: nighty^ (n=nighty@sushi.rural-networks.com) joined #forth
09:18:14 <Amanita_Virosa> mostly strings
09:18:29 <Amanita_Virosa> although there are other things that it can be used for
09:19:44 <Amanita_Virosa> anyway, when fetching a floating point value, or an object pointer, i can't just use the regular form, because that'll just copy it onto the P stack
09:21:45 <Amanita_Virosa> maybe i should just use @... i'm not using it anyway.
09:22:40 <arke> might confuse forthers though :D
09:22:56 <Amanita_Virosa> heh well i think the whole system will.
09:23:05 <iano_> Amanita_Virosa: You know about VALUE?
09:23:07 <Amanita_Virosa> writing the name of a variable will copy the value of that variable, not the address, for one thing :P
09:23:16 <Amanita_Virosa> iano_ - VALUE?  is that what i'm looking for?
09:23:35 <iano_> It changes the semantics of the variable to be more like CONSTANT
09:23:40 <Amanita_Virosa> oh.
09:23:46 <Amanita_Virosa> interesting.
09:24:04 <iano_> and you must use "n TO value" to change the value
09:24:05 <Amanita_Virosa> well, i'm designing a high-level script language, so a few things are different
09:24:17 <Amanita_Virosa> i want to avoid making things too different though
09:24:17 <Amanita_Virosa> ah
09:24:20 <Amanita_Virosa> i use ->
09:24:24 <Amanita_Virosa> n -> var
09:24:26 <Amanita_Virosa> to change the value
09:24:27 <iano_> right
09:24:35 <iano_> so do some others, like iFOrth
09:24:41 * Amanita_Virosa nods.
09:25:36 <Amanita_Virosa> despite how different this is in some fundamental ways, it's still mostly a FORTH... token-threaded and partial support from an interpreter, with a garbage collector...
09:25:40 <iano_> So there is VALUE for cell variables, and non-standard FVALUE for floats
09:25:50 <Amanita_Virosa> but it's not a "FORTH-syntax script language"... it's a high-level forth.
09:25:56 <Amanita_Virosa> ah
09:25:57 <iano_> and non-standard +TO to have an analog of +!
09:25:57 * Amanita_Virosa nods.
09:26:00 <Amanita_Virosa> hehe
09:26:05 <Amanita_Virosa> that's a neat one.
09:26:13 <Amanita_Virosa> hadn't even thought of that.
09:26:40 <Amanita_Virosa> the problem i'm having is directing where the variable comes out
09:26:53 <Amanita_Virosa> when you call the name, there are several valid locations that the data can emerge
09:27:09 <iano_> a problem with the current standard is TO gets overloaded (used for all types of VALUES as well as for any local variable extensions like LOCALS| or { }
09:27:28 <iano_> well, quirk rather than problem
09:27:34 * Amanita_Virosa nods.
09:27:41 <Amanita_Virosa> i use differently-named ->'s
09:27:46 <Amanita_Virosa> to store
09:27:49 <Amanita_Virosa> the problem is the fetch
09:29:41 <iano_> Forth VALUEs work like constants: the name fetches the value to the stack directly
09:30:05 <iano_> which stack depends on the type of the VALUE
09:30:17 <Amanita_Virosa> hrm...  i don't think that's going to work so well for me.
09:30:48 <iano_> are your types boxed? do values know their type?
09:31:07 <iano_> like in Lisp?
09:31:14 <Amanita_Virosa> no, values don't know their type unless they're objects.
09:31:28 <iano_> I see.
09:31:33 <Amanita_Virosa> variables know their size
09:31:56 <iano_> really. Why not also store a type?
09:32:07 <iano_> so you know which stack to fetch to
09:32:14 <Amanita_Virosa> extra overhead that i'm trying to avoid?
09:32:25 --- join: Al2O3_ (n=Al2O3@c-75-70-5-69.hsd1.co.comcast.net) joined #forth
09:32:45 <iano_> well, you're already storing the size, which is more than a standard Forth does. :)
09:32:48 <Amanita_Virosa> still...  VARIABLE can store a pointer, an integer, or a single-precision.  a 2VARIABLE can store a doubleint, a double-precision, or a single-precision complex...
09:33:01 <Amanita_Virosa> no, i'm not storing the size in the variable, i'm storing it in the dictionary
09:33:05 <Amanita_Virosa> that's not a runtime overhead
09:33:15 <iano_> Oh, I see.
09:33:47 <Amanita_Virosa> so what i really need is a "GET variable" routine
09:33:53 <Amanita_Virosa> i just want to pick a meaningful name that's not confusing
09:34:00 <Amanita_Virosa> @ would be confusing :P
09:34:02 <iano_> variable @
09:34:19 <Amanita_Virosa> now, see, those types of pointers aren't representable on the stack.
09:34:25 <iano_> and go back to have it return a reference
09:34:54 <iano_> Ah, so you want to abstract away from pointers altogether?
09:35:04 <Amanita_Virosa> yes.
09:35:16 <Amanita_Virosa> i've made some deliberate design decisions to make this less low-level.
09:35:18 <iano_> How are you handling arrays?
09:35:28 <Amanita_Virosa> they're objects.
09:35:55 <iano_> well, how about <- to balance ->
09:36:11 <Amanita_Virosa> i've considered that...  it just looks somewhat wrong somehow.
09:36:30 <kc5tja> How about ?? ?
09:36:38 <Amanita_Virosa> double-questionmark?
09:37:24 <iano_> Hm... I still think it is better to just have invoking the variable by itself do the right thing.
09:37:41 <iano_> Maybe have more than just VARIABLE / 2VARIABLE
09:37:45 <Amanita_Virosa> iano_ - the only way to do that would be to move to strongly typed variables
09:37:53 <Amanita_Virosa> which i'm not saying is a bad idea exactly...
09:37:58 <Amanita_Virosa> just the only way to do it
09:38:15 <iano_> I would have a different VARIABLE for each typed stack
09:38:26 <Amanita_Virosa> it'd be a bit stranger than that, even
09:38:32 <kc5tja> Forth implements F@/F! for floating point values, 2@/2! for double-wide integers, etc.
09:38:35 --- quit: Off_Namuh74 (Remote closed the connection)
09:38:39 <Amanita_Virosa> because double-precision float and single-precision complex both go to the same stack, but with different representations
09:39:15 <iano_> sounds like a recipe for disaster :)
09:39:25 <iano_> might as well add a complex stack
09:39:32 <kc5tja> Why would a complex go to the same stack as a float?
09:39:41 <Amanita_Virosa> because complex numbers are *made* of floats.
09:39:52 <arke> aah
09:39:55 <Amanita_Virosa> disassembling and reassembling complex numbers from floats makes perfect sense
09:39:56 <arke> it's a 64-bit stack then?
09:39:59 <arke> double scalars and float complex?
09:40:11 <Amanita_Virosa> complex numbers are stored as a pair of doubles
09:40:13 <Amanita_Virosa> on the stack
09:40:18 <kc5tja> OK.
09:40:22 <Amanita_Virosa> it's only when they move to variables that they can be reformatted
09:40:23 <kc5tja> I'm not seeing a problem then.
09:40:43 <Amanita_Virosa> that's why 4VARIABLE exists: to store double-precision complex :P
09:40:46 <iano_> just curious: you have an application in mind for complex numbers? or just a test case?
09:41:08 <kc5tja> : Complex! ( f: real img -- ) ( d: addr -- )   dup f! float+ f! ;
09:41:10 <Amanita_Virosa> to be honest, the whole float system is just because it has such a low cost of implementation
09:41:33 <kc5tja> : Complex@ ( f: -- real img ) ( d: addr -- )  dup f@ float+ f@ fswap ;
09:41:41 <Amanita_Virosa> kc5tja - in a normal FORTH, absolutely.
09:41:51 <arke> hmm :)
09:42:06 <arke> another reason why I don't like Forth for my DSP work :D
09:42:08 <iano_> I'd just as soon use objects for complex numbers as long as you have objects...
09:42:09 <kc5tja> OK, so you're looking to implement generic functions in Forth then?
09:42:21 <Amanita_Virosa> generic functions?
09:42:33 <kc5tja> Functions that dispatch based on the types of its arguments.
09:42:35 <Amanita_Virosa> iano_ - hrm...  that's almost a good idea.
09:42:39 <Amanita_Virosa> kc5tja - no.
09:42:58 <Amanita_Virosa> in fact, i'm trying to *AVOID* doing that
09:43:06 <Amanita_Virosa> it's what iano is suggesting, but i'm trying to avoid it :P
09:43:07 <kc5tja> Hmm...as I see it, you have mutually exclusive requirements then.
09:43:28 <Amanita_Virosa> not really, all i need is the stem of a name for a function like "GET variable"
09:43:28 <kc5tja> You either have type-aware words, or multiple per-type words.  You can't really have *neither*.  :)
09:43:43 <Amanita_Virosa> sure, multiple per-type words, that's what i've been saying
09:44:10 <Amanita_Virosa> i use -> to move an integer to a variable, F-> to move a float, CF-> to move a complex
09:44:14 <iano_> well, you can have *size* aware words and a type-aware programmer :)
09:44:21 <Amanita_Virosa> yes, that's what i'm doing
09:44:32 <iano_> worst of both worlds :)
09:44:37 <Amanita_Virosa> the words are size-aware, because the token compiler has that information available when it compiles :P
09:44:44 <Amanita_Virosa> lol
09:44:47 <Amanita_Virosa> well maybe
09:44:56 <iano_> but easy to code
09:44:56 <kc5tja> iano_: For something this simple, they're the same.  But type-aware words are much more powerful.
09:45:17 <iano_> agreed
09:45:29 <kc5tja> Anyway, why not just use Get?
09:45:34 <Amanita_Virosa> true, type-aware words are more powerful, because they move that burden to the runtime system.
09:45:39 <kc5tja> GetFloat, GetCF, etc?
09:45:48 <kc5tja> Amanita_Virosa: Actually, not necessarily.
09:45:51 <Amanita_Virosa> terseness? :P
09:46:06 <kc5tja> -> is 2 letters.  CF-> is 4.  GetCF is only 5.
09:46:06 <Amanita_Virosa> well, okay, if i went to strong typing of variables, you're right
09:47:21 <Amanita_Virosa> it does make arrays a whole lot more complicated to implement though
09:47:24 <kc5tja> Yeah, you'd have to augment the Forth compiler itself and define some handy immediate words.  I remember doing this for Pygmy Forth to emit some (very limited, but still very instructive) raw assembly language code from Forth years ago.  Pretty neat.
09:47:41 <iano_> fetch is many times more common than store, one of the motivations of Forth's VALUE/TO vocabulary where fetching is 0 letters
09:48:06 --- quit: Al2O3 (Connection timed out)
09:48:13 <Amanita_Virosa> iano_ - exactly.  that's why fetching is 0 letters for "copy value to P stack"
09:48:25 <Amanita_Virosa> F and O stack are the problem
09:49:14 <kc5tja> Hmm...  Folks in the C++ crown associate & with "reference".  Maybe &CF FOO would be good syntax?  
09:49:27 <kc5tja> The idea being to read it as, "Reference the complex FOO"
09:49:38 <Amanita_Virosa> hrm, now that sounds like what i'm thinking.
09:49:42 <Amanita_Virosa> i like it
09:50:09 <Amanita_Virosa> i'm not using & for anything yet anyway
09:51:43 <Amanita_Virosa> that's a good suggestion, thank you kc5tja :)
09:51:48 <kc5tja> No problem
09:52:05 <kc5tja> I enjoy solving other people's dilemmas at the expense of my own.  :-)
09:52:22 <Amanita_Virosa> hehe
09:53:36 <kc5tja> Instead of working on OpenAX.25, for example, I'm pondering the possibilities of treating pointers monadically, and what useful benefits might come from it, at least from an analytical perspective.
09:54:27 <iano_> I vaguely remember a Haskell pointer-monad experiment. Did you check the LtU archives?
09:54:41 <kc5tja> I haven't.
09:54:53 <kc5tja> But, a pointer monad in Haskell would not be useful.
09:55:03 <kc5tja> I'm looking more for its application in lower-level languages.
09:55:14 <kc5tja> But, I'll search anyway.
09:55:23 <iano_> right, it was just an experiment (though might be useful if using Haskell as a cross-compiler)
09:55:29 <kc5tja> If you can have ListOf Int, then PointerTo Int should be treated the same way.
09:55:49 <kc5tja> (assuming you define return and >>= appropriately, of course)
09:57:30 <arke> :)
09:57:30 --- join: Off_Namuh (i=GPS@gateway/tor/x-7eb52baf0291f064) joined #forth
09:58:11 <arke> aah, yes!
09:58:38 * arke is about 15 minutes away from releasing an update to one of his VST Plugins
09:58:47 <Robert> VST?
09:59:05 <arke> Robert, "Virtual studio technology", it's a plugin standard for software instruments and effects
09:59:08 <arke> audio stuff
10:00:22 <Amanita_Virosa> &F turns out to be quite convenient
10:00:25 <Amanita_Virosa> i like it :)
10:02:13 <arke> yeah, pretty neat
10:05:49 <Amanita_Virosa> i can't decide if my script is an evolution of FORTH, or just a misguided experiment.  i suspect only time will tell hehe.
10:09:47 <kc5tja> All Forth programs are, if properly designed, evolutions of Forth.  But as with all evolution, if something isn't fit for survival . . . ;D
10:10:06 <Amanita_Virosa> kc5tja - exactly :)
10:14:56 <Amanita_Virosa> there we go, ++> --> +=> and -=> :P
10:15:10 <Amanita_Virosa> that's deliciously perverse.
10:34:14 --- quit: Amanita_Virosa ("Zoom zoom.")
10:59:47 --- join: forther (n=forther@c-67-180-150-67.hsd1.ca.comcast.net) joined #forth
11:40:09 --- join: crc_ (n=crc@pool-70-110-143-33.phil.east.verizon.net) joined #forth
11:42:07 --- quit: crc (Read error: 110 (Connection timed out))
11:54:18 --- quit: nighty^ (Read error: 113 (No route to host))
11:56:17 --- join: nighty^ (n=nighty@sushi.rural-networks.com) joined #forth
12:08:36 --- quit: wossname (Connection timed out)
12:21:38 --- join: snoopy_1711 (i=snoopy_1@dslb-084-058-180-062.pools.arcor-ip.net) joined #forth
12:29:47 --- quit: Snoopy42 (Read error: 145 (Connection timed out))
12:29:56 --- nick: snoopy_1711 -> Snoopy42
12:30:21 --- join: H4ns (n=Hans@p57A0C9D8.dip.t-dialin.net) joined #forth
12:31:55 --- part: H4ns left #forth
12:36:15 --- join: nighty__ (n=nighty@sushi.rural-networks.com) joined #forth
12:49:52 --- quit: nighty^ (Read error: 110 (Connection timed out))
12:58:21 --- quit: Al2O3_ ("Eggplant & SenseTalk: Driving Success Through Automation")
13:54:28 --- join: wossname (n=w@CPE00195b252b77-CM001a666a6e78.cpe.net.cable.rogers.com) joined #forth
13:59:45 --- nick: crc_ -> crc
14:11:00 --- quit: JasonWoof (Read error: 110 (Connection timed out))
14:11:09 --- join: bjorkintosh (n=bjork@ip72-204-54-41.fv.ks.cox.net) joined #forth
14:11:17 <bjorkintosh> is there yet a forth std lib?
14:11:57 <iano_> yes, it's called ANS Forth
14:12:15 <slava> or factor :)
14:12:35 <bjorkintosh> factor?
14:12:43 <iano_> slava: come back in 3 years when you have a standards document ;)
14:12:51 <bjorkintosh> hahaha
14:13:01 <slava> iano_: i'd rather have one quality implementation than a standard ;-)
14:13:24 <iano_> which goes to show that useful != standard
14:13:31 <bjorkintosh> so it goes.
14:14:04 <iano_> bjorkintosh: looking for anything in particular?
14:14:30 <bjorkintosh> i was going through the c std lib by plauger earlier... and i thought i'd stop in and ask about ye olde forthe
14:15:04 <iano_> std lib is huge; what area in particular?
14:15:32 <slava> c std lib isn't huge
14:15:32 <bjorkintosh> the usual :)
14:15:40 <slava> in fact its so thin its almost useless
14:15:44 <iano_> compared to forth ;)
14:15:57 <bjorkintosh> 15 chapters in plauger's book.
14:17:16 <iano_> ANS has a FILES wordset like stdio.h, a STRING set like string.h
14:18:03 <iano_> and most Unix forths have FFI to get at actual libraries like libc.
14:18:23 <bjorkintosh> ah i see.
14:18:25 <iano_> though each forth does FFI differently
14:18:33 <bjorkintosh> forth like the south, shall rise again!
14:18:50 <iano_> and there is quite a bit of C/Forth impedance mismatch
14:19:51 <slava> iano_: are you the shootout guy?
14:20:04 <iano_> heh. I guess so
14:20:14 <iano_> I haven't looked at it for a while.
14:20:28 <iano_> I've been on some language comparison wikis recently
14:20:50 <iano_> http://www.rosettacode.org/
14:21:16 <iano_> http://en.literateprograms.org/
14:21:20 --- join: C0ltZs1 (i=Unix@74-132-210-197.dhcp.insightbb.com) joined #forth
14:22:37 --- part: tapo left #forth
14:24:29 <Robert> As in the programming language shootout?
14:24:52 <Robert> I remember a certain guy used to refer to that all the time to prove the superiority of ML.
14:25:49 <bjorkintosh> ah.
14:29:09 <bjorkintosh> well then, i'll come back when a std lib emerges.
14:29:13 <bjorkintosh> adios :-h
14:29:16 <Robert> Heh
14:29:16 --- part: bjorkintosh left #forth
15:01:00 --- quit: ygrek (Remote closed the connection)
15:06:12 --- join: JasonWoof (n=jason@c-71-192-28-153.hsd1.ma.comcast.net) joined #forth
15:06:12 --- mode: ChanServ set +o JasonWoof
15:06:39 <Robert> Hi
15:07:24 <arke> Hi.
15:14:27 <kc5tja> Robert: Except that ML is a damn good language, and freakin' kick-ass compilers.
15:15:04 <Robert> That's truee
15:15:11 <Robert> I'm actually using it right now.
15:15:30 <Robert> Was just saying it's how I remember the old programming language shootout.
15:15:37 * kc5tja nods
15:15:38 <arke> must have been smerdy ;)
15:15:59 * kc5tja was pontificating some more today about the nature of a pointer monad.
15:16:10 <Robert> Yes, of course.
15:16:16 <kc5tja> Although it is definitely *possible*, it's just not useful.
15:16:31 <kc5tja> The concept is just too low-level.
15:19:59 <arke> for apps, no
15:20:04 <arke> for an operating system? ... ;)
15:20:43 <slava> kc5tja: have you looked into region-based memory management?
15:20:49 <kc5tja> Many times.
15:20:55 <slava> between regions and gc i don't think there's much room for pointer twiddling unless you're implementing a language runtime
15:21:39 <kc5tja> slava: By process of elimination, yes, it'd be language runtime pontifications.  :)
15:22:18 <Robert> I haven't. What is it?
15:22:21 <kc5tja> Specifically, is it possible to build an interactive language environment from the ground up in a functional language with strong typing?  That is the question.
15:22:48 <kc5tja> Robert: Managing memory with a stack of slab allocators (basically).
15:23:13 <kc5tja> each slab exists in a lexical scope, but you're free to allocate objects in any slab that is currently in scope.
15:25:34 --- join: arcus_ (n=Miranda@130.195.209.73) joined #forth
15:26:01 <Robert> What is it used for? Complement to a gc, or replacement?
15:28:44 <slava> both
15:45:53 --- join: doublec (n=doublec@202.180.114.137) joined #forth
15:49:42 --- quit: arcus_ (Connection reset by peer)
15:50:13 --- join: arcus (n=Miranda@130.195.209.73) joined #forth
15:50:20 --- join: nighty^ (n=nighty@sushi.rural-networks.com) joined #forth
15:50:39 <arcus> what is used for a gc and as a replacement? 
15:50:50 <arcus> ircbrowse.com seems to be down at the moment. 
15:50:54 <arcus> :-[
15:52:34 <slava> region-based memory mangement
15:52:46 --- quit: nighty__ (No route to host)
16:03:10 * kc5tja implemented a very crude approximation of garbage collection on a stack.  It's probably suitable only for strings at the moment.  (Which, I suppose, is itself worthwhile for release.)
16:03:27 <kc5tja> But, ultimately, I'd like to see a full implementation including support for more complex types.
16:31:05 --- join: saon (n=saon@207.138.42.211) joined #forth
16:57:57 --- quit: arcus (Connection timed out)
18:03:57 --- quit: iano_ ()
18:05:47 --- quit: XeF4 ("Reconnecting")
18:05:49 --- join: XeF4 (i=xef4@epilogue.org) joined #forth
18:15:45 --- quit: forther (Read error: 110 (Connection timed out))
18:22:48 --- quit: saon ("leaving")
18:23:52 --- join: saon (n=saon@207.138.42.211) joined #forth
18:39:31 --- quit: nighty^ (Read error: 113 (No route to host))
18:49:05 --- join: nighty^ (n=nighty@sushi.rural-networks.com) joined #forth
19:00:47 --- join: H4ns (n=Hans@p57A0C9D8.dip.t-dialin.net) joined #forth
19:04:36 --- quit: georgebush ()
19:11:59 --- quit: nighty^ (Read error: 110 (Connection timed out))
19:12:53 --- join: nighty^ (n=nighty@sushi.rural-networks.com) joined #forth
20:04:33 --- quit: yumehito ("no cat anywhere ever gave anyone a straight answer")
20:06:38 --- join: arke_ (n=arke@p54A7EF4E.dip.t-dialin.net) joined #forth
20:20:06 --- quit: tathi ("leaving")
20:22:12 --- quit: arke (Read error: 110 (Connection timed out))
20:22:12 --- nick: arke_ -> arke
20:30:10 --- join: forther (n=forther@c-67-180-150-67.hsd1.ca.comcast.net) joined #forth
21:03:29 --- quit: Off_Namuh (Read error: 104 (Connection reset by peer))
21:24:09 --- join: Raystm2 (i=Ray@unaffiliated/raystm2) joined #forth
21:24:25 --- join: Off_Namuh81 (i=GPS@gateway/tor/x-af5eff76e634bd8f) joined #forth
21:53:44 --- join: Al2O3 (n=Al2O3@c-75-70-5-69.hsd1.co.comcast.net) joined #forth
22:09:43 --- part: H4ns left #forth
22:42:43 --- quit: nighty^ (Read error: 113 (No route to host))
22:44:27 --- quit: JasonWoof ("off to bed")
22:45:53 --- quit: doublec ()
22:46:55 --- join: JasonWoof (n=jason@c-71-192-28-153.hsd1.ma.comcast.net) joined #forth
22:46:55 --- mode: ChanServ set +o JasonWoof
23:03:40 --- quit: Raystm2 ("Should have paid the bill.")
23:22:22 --- quit: Al2O3 ("Eggplant & SenseTalk: Driving Success Through Automation")
23:30:18 --- quit: wossname (Read error: 110 (Connection timed out))
23:51:47 --- join: doublec (n=doublec@203-211-104-119.ue.woosh.co.nz) joined #forth
23:59:59 --- log: ended forth/07.10.28