00:00:00 --- log: started forth/05.11.19
00:12:41 --- join: swalters (n=swalters@6532183hfc82.tampabay.res.rr.com) joined #forth
02:30:55 --- quit: swalters ("User disconnected")
04:11:53 --- quit: tathi ("leaving")
04:29:47 --- join: akebono (n=fujiwara@218.231.198.135.eo.eaccess.ne.jp) joined #forth
04:30:15 <akebono> Quote: Let us live for the beauty of our own reality. -- Charles Lamb
04:30:46 <akebono> HI
04:32:15 --- quit: akebono ("Leaving")
05:11:54 --- join: PoppaVic (n=pete@0-2pool198-63.nas30.chicago4.il.us.da.qwest.net) joined #forth
05:41:23 --- quit: skylan (Read error: 104 (Connection reset by peer))
05:47:09 --- join: skylan (n=sjh@dialup-216-211-5-151.tbaytel.net) joined #forth
06:02:42 --- join: Robert (n=robert@unaffiliated/robert) joined #forth
06:44:56 <crc> good morning everyone
06:45:08 <Robert> Morning, crc.
06:46:28 --- quit: saon ("Lost terminal")
06:52:26 --- join: saon (n=saon@unaffiliated/saon) joined #forth
07:26:04 --- quit: saon ("Lost terminal")
07:27:25 --- join: saon (n=saon@unaffiliated/saon) joined #forth
07:49:07 --- quit: humulus (Read error: 101 (Network is unreachable))
08:14:54 --- quit: snowrichard ("Leaving")
08:25:48 <PoppaVic> Hmm... THis is really... irksome.
08:29:19 <Robert> What?
08:30:12 <PoppaVic> I'm working on a file-format/semantic for initialization/configuration.
08:30:59 <PoppaVic> Somehow, I think I have to get data from my isolated linux-box into this powerbook... At one time, I'd written essentials in Gforth.
08:32:16 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth
08:33:12 <PoppaVic> Basically, INI-files are nothing more than "dumbed-down" forth.
08:33:29 <PoppaVic> ..yet, they should be 'dumb' and furthermore, simple.
08:34:25 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth
08:35:17 <PoppaVic> The diff seems to be in parsing/scanning/lexing the location-of and content-of as well as "do this, you silly bastich"
08:35:28 <PoppaVic> hmmm
08:38:18 --- join: humulus (n=humulus@xover.htu.tuwien.ac.at) joined #forth
08:40:37 <PoppaVic> amusing.
08:44:43 <PoppaVic> I find it interesting... lisp needs lisp or asm/c, and forth needs asm/c - and never the twain shall meet.
08:45:00 <PoppaVic> outrageous
08:46:13 --- join: akebono (n=fujiwara@218.231.198.135.eo.eaccess.ne.jp) joined #forth
08:46:14 <akebono> Quote: Let us live for the beauty of our own reality. -- Charles Lamb
08:46:24 <akebono> hi
08:46:56 <crc> hi akebono
08:47:19 <akebono> here I've seen very few people active
08:47:50 <akebono> I'm from Tokyo. :-)
08:47:52 <crc> this channel is quiet often, but does have some periods of high activity
08:48:03 * crc lives in Pennsylvania, USA
08:48:29 * tathi too
08:48:34 <akebono> ah.
08:48:45 <akebono> Forth seems to be popular in the U.S.
08:49:35 <akebono> so, are you all programmers of some embedded systems?
08:49:45 --- quit: snowrichard ("Leaving")
08:49:45 <tathi> no
08:49:59 <crc> no, I do apps for the x86 architecture mostly
08:50:07 <akebono> oh, it's interesting.
08:50:31 <tathi> and I'm running Linux on a Mac.
08:50:42 <akebono> hmmm.
08:51:09 <akebono> I have once used an interpreter of Forth for the Macintosh.
08:51:18 <akebono> years ago.
08:51:26 <akebono> It was from Forth Inc.
08:52:54 <akebono> it took time to understand forth, especially the inner and outer interpreters.
08:54:19 --- join: tgunr (n=davec@66.160.179.125) joined #forth
08:57:26 --- quit: humulus (Read error: 101 (Network is unreachable))
08:59:17 <crc> not all forths use inner and outer interpreters 
09:01:12 <akebono> ah
09:01:41 <akebono> I remember I bought a very thick and big book written by someone.
09:02:17 <akebono> "All about Forth" or some title.
09:11:27 <crc> The only book on Forth that I've ever read was "Thinking Forth"
09:20:50 --- join: PoppaVic_ (n=pete@0-1pool73-176.nas24.chicago4.il.us.da.qwest.net) joined #forth
09:23:22 --- quit: PoppaVic (Nick collision from services.)
09:23:25 --- nick: PoppaVic_ -> PoppaVic
09:23:53 <PoppaVic> the EU and germany are more hot on forth than the US.. THe USSR really dived in
09:24:28 <akebono> ah.
09:24:51 <akebono> also, I read Forth Inc's ANSI Forth book.
09:24:58 <PoppaVic> Problem is... On the whole, forth thinks it's an OS
09:25:46 <PoppaVic> yeah, Brody writes pretty well
09:26:03 <PoppaVic> "Thinking Forth" is even better than "Starting Forth"
09:26:24 <PoppaVic> ...ANything by Dr. Ting is also useful
09:27:59 <akebono> to understand Forth, I though I should read an assembly source code of a Forth interpreter, and I tried.
09:28:11 <PoppaVic> no
09:28:16 * PoppaVic sighs
09:28:26 <PoppaVic> It's like talking about C, in that respect
09:28:50 <PoppaVic> Stop worrying about the asm generated via C or Forth
09:29:04 <PoppaVic> all you care about is lookups and effects
09:29:17 <akebono> no, hand-written code for Z80.
09:29:23 <PoppaVic> ahhhhh
09:29:33 <PoppaVic> only, IF you have a z80
09:29:34 <akebono> it is what I used as a sample.
09:29:48 <PoppaVic> ..I happen to recall the Z80 very fondly, so I sympathize
09:30:21 <akebono> but, I have to confess that I couldn't understand it all.
09:30:21 <PoppaVic> See FIG-forth and F-83, and then peruse Loeligers works
09:30:52 <PoppaVic> forth ends up being an engine over the OS over the CPU
09:31:07 <PoppaVic> oor, it goes insane and replaces them
09:31:48 <PoppaVic> other than maybe Gforth, Pforth, Cforth or (see) FICL - forth tends to believe itself *THE* system
09:31:54 <akebono> it looks like a network of executable code blocks, woven by an interpreter.
09:32:02 <PoppaVic> not really
09:32:10 <PoppaVic> the former is torqued
09:32:18 <Robert> Hm.
09:32:31 <Robert> I'm writing on a document about Forth internals on more recent machines.
09:32:33 <PoppaVic> a tree/list of lists/code-refs
09:32:43 <PoppaVic> Robert: sounds painful
09:32:45 <Robert> Moving Forth is great, but for the pre-cache era.
09:32:48 <Robert> PoppaVic: A bit, yes.
09:33:09 <PoppaVic> Robert: I've been fighting uphill for years - documenting it has GOT to be worse
09:33:47 <Robert> I've written a simple Forth to use for demonstration, too. So I hope it'll be useful for people who are new to Forth, and want to get more familiar with it.
09:33:59 <akebono> yes, I agree.
09:34:30 <PoppaVic> Robert: the prob is... Near as I can tell... Folks want to propose/implement a Forth that obviates all the tools under it - including the OS
09:34:50 <akebono> as a novice, how Forth's inner code blocks and its header parameters are interrelated was not very clear.
09:35:07 <PoppaVic> well, FOrth - as is - has no headers
09:35:27 <PoppaVic> Worse, it makes assumptions about stacks and use
09:35:55 <PoppaVic> /and/, orders, values and/
09:36:36 <akebono> really, it seems I need another very good book on Forth.
09:36:42 <PoppaVic> My personal conclusion is: C (gcc) over asm over the OS. Forth should reside above C
09:36:51 <crc> PoppaVic: what languages don't make assumptions about such things?
09:37:11 <PoppaVic> crc: prolly poorly stated: I meant each variant.
09:37:17 <crc> ahh
09:37:33 * crc has used several different C compilers that all make different ABI assumptions
09:37:35 <Robert> akebono: I think you should learn by doing.
09:37:48 <PoppaVic> yeah, those ABI can become painful
09:37:51 <Robert> akebono: The Forth primitives are simple enough to grasp without too much effort.
09:37:56 <crc> it's not really much better with any compiled language
09:38:10 <Robert> akebono: Are you experienced with the x86 assembly language?
09:38:21 <akebono> no, only Z80.
09:38:24 <PoppaVic> for a virgin, I would recommend installing Gforth and reading the docs and tinkering for a few months if not a year.
09:39:04 <PoppaVic> crc: the ABI's and "how the fuck can I learn about [ABI issue]" are the prob
09:39:15 <Robert> akebono: Ah, I see. The demonstration Forth I wrote is for x86. Moving Forth is pretty relevant to z80-age chips, though.
09:39:40 <PoppaVic> I grant you that, ideally, we should NOT care - but element types and structs can mulch it all.
09:40:35 <crc> PoppaVic: I understand the problem with ABI's. There is no cross-platform standard for them, which makes life difficult when interfacing different languages together
09:40:48 <PoppaVic> Once, I thought classes would help; THen I thought typedef would. Now, all I can do is scream.
09:41:38 <PoppaVic> crc: right... You almost NEED to be able to ascertain various features - particular in the form of ascii that can be values, sets, arrays, strings, etc.
09:41:42 <akebono> okay, I'll reread my books on Forth. The interrelationship between the inner and outer interpreter and how code areas are linked should be understood.
09:42:00 <Robert> Yes. It's fairly simple, though, once you get it.
09:42:10 <Robert> Feel free to ask if you want something explained.
09:42:22 <PoppaVic> Sure, forth itself is not too ugly.. Simplistic, but not ugly.
09:43:10 <PoppaVic> ..and mind you: simplistic is not BAD - it just means you can envision extensions.
09:43:10 <akebono> BTW, the inventor of Forth is still active in enhancing the language?
09:43:23 <PoppaVic> well, Chuck is off in his own universe
09:43:25 <crc> yes, in the form of colorforth (http://colorforth.com)
09:43:53 <Robert> Most forthers live in their own universes.
09:44:02 * PoppaVic tries to envision a "-std=<variant>" flag....
09:44:03 <Robert> Which isn't always a bad thing.
09:44:28 <PoppaVic> Robert: 20+ years later... Yeah, it's getting irksome.
09:45:06 <Robert> Hehe.
09:45:24 <Robert> Your universe is not to blame for that, only the incompatible universes of everyone else!
09:45:25 <PoppaVic> Gforth ports pretty well, but sheesh - it still makes my nuts hurt.
09:46:00 <PoppaVic> Robert: hehe - now yer suggesting gcc==Metacompiler and Gforth is "portable" ;-)
09:46:38 <akebono> I really have read a few of the inventor's article, and he seems to warn that we should not rely on the illusion of OS and sharable libraries.
09:47:17 <Robert> Well, his demands of computers seems somewhat different from ours.
09:48:41 <akebono> ah, in the sense that only he himself meet the demands, not anyone else...?
09:49:00 <akebono> meet -> can meet the demands fully,
09:49:42 <PoppaVic> h,,
09:49:46 <PoppaVic> hmm, (too)
09:50:19 <PoppaVic> look: the OS/libs/Linker is going to exist regardless of Chucks views
09:50:27 <Robert> I was mostly thinking about the fact that he seems to be working mostly with very well-defined and specialised problems.
09:50:50 <PoppaVic> Basically: you either feed off the BIOS or a ROM or the OS/libs/linker
09:50:54 <Robert> Such as telescope controlling software, or a program to design a microchip.
09:51:11 <akebono> self-running.
09:51:26 <PoppaVic> yes. geezus, if I was fighting ucpu apps, I'd build Z80-boards and use FIG-forth.
09:51:40 <Robert> Whereas most people today use a very complex system of programs, many which have to be portable among different platforms.
09:52:09 <PoppaVic> right.. and EVERY APP (or program) rides on the OS/libs/linker
09:52:17 <akebono> yes,
09:52:17 <Robert> Hehe. I found a tube of 9 RCA1802 CPUs, and there's a FIG-Forth port for that chip. I could get a bunch  of Forth computers. ;)
09:52:42 <PoppaVic> Robert: sure.. and for a closed-system, self-contained-app: I'd agree
09:53:08 <akebono> but he seems to be questioning the concept and what we think of as our reality....
09:53:30 <PoppaVic> But, after a year fighting sh and forth.... One begins to ponder "why the fuck are we suffering 'sh'?"
09:54:11 <PoppaVic> ..and, mind you: I was fighting to learn forth a few decades before I met 'sh' ;-)
09:55:25 <PoppaVic> ..and, to confuse matters further: forth is pretty-much suitable for transliteration into other languages and compilers.
09:56:53 <akebono> it can be an intermediate language.
09:57:01 <PoppaVic> Every problem (with forth) seems to arise as folks pretend it's a "interpreter" - but it has to generate unique object-code that is executable-only.
09:57:17 <PoppaVic> yeppers
09:57:53 <PoppaVic> When folks talk of sh, scheme, python or whatever - I keep wondering why the fuck Forth ain't there already.
09:58:24 <PoppaVic> ..and the answer is not pretty
09:59:08 <akebono> it seems a different approach of abstraction...
09:59:24 <PoppaVic> right.. or forwards/isolation
09:59:43 <akebono> abstraction without abstraction in other words.
10:00:06 <PoppaVic> hmm, or "abstraction without reliance"
10:00:33 <akebono> because only the machine codes remain.
10:00:34 <PoppaVic> ..at SOME point reliance is required. Fine. We can live with that.
10:00:38 <PoppaVic> right
10:00:52 <PoppaVic> and even the MC is likely to call upon the OS
10:00:57 <PoppaVic> ..or BIOS
10:01:59 <PoppaVic> But, these are issues for developers - and I fight folks daily - so, you need to tinker with forth itself.
10:02:44 <akebono> I feel in Forth, there can be more different styles of coding.
10:02:47 <PoppaVic> as a rule... I'd suggest Gforth
10:03:09 <PoppaVic> "styles"? Not too likely.
10:03:31 <akebono> methods?
10:03:41 <PoppaVic> hmm.. I'd have to know more
10:04:02 <akebono> as it sticks closer to the machine codes
10:04:35 <PoppaVic> To most forthers... You have order;vocs; wordlists; words; immediate/compiled.
10:04:42 <PoppaVic> stop thinking MC
10:05:19 <crc> PoppaVic: if you compile to native code, you have to keep the MC in mind
10:08:07 <akebono> Forth words tend to be short, not like big Fortran subroutines, but how to define words and how to combine them to have a good result can be diverse.
10:08:55 <akebono> because the minimum word unit tends to be simpler and smaller.
10:09:25 <akebono> So, in a sense, programming in Forth is freer.
10:10:18 <akebono> So, there can be various different universes,
10:11:59 <PoppaVic> yes... in a sense or two
10:12:23 <akebono> and good programmers can find the shortest path to the goal, but novice user like me has to struggle....
10:12:48 <PoppaVic> crc: understood.. However, there is "do I need c? asm? mc? linkers? libs?"
10:13:21 <crc> true, but that all depends on what you're trying to do
10:13:49 <PoppaVic> Best is - from my view: get the job done and portable. I don't suffer perl or sh or autoshit/m4, so this raises my limits.
10:13:56 <crc> dealing with other languages and libraries isn't always needed
10:14:02 <PoppaVic> crc: I agree - and I don't fault it.
10:14:34 <PoppaVic> there are several levels to everything, and it seems EVERY level has shit we must specify.
10:14:35 * crc has been working hard to get RetroForth and other languages to coexist more easily
10:15:53 <PoppaVic> crc: I think a variety needs this crap I am working on *sigh* It grates me to even suggest it matters.
10:16:39 <akebono> Anyway, I am going to read Glen B. Haydon's All About Forth again.
10:16:53 <akebono> to see the internals better.
10:16:53 <PoppaVic> I can't endorse it, but fine.
10:17:21 <PoppaVic> In theory, the internals SHOULD be something you can tend to avoid.
10:18:27 <PoppaVic> akebono: I think (personally) yer diving in at around the level where we usually argue do...loop and suchlike.
10:22:14 <akebono> part of issues like how to optimize the result machine codes seems to be something that mainly designers of Forth interpreters should handle....
10:23:36 <akebono> so, I'll do my best to understand the internals, and if it helps me writing better Forth codes, it'll be fine.
10:24:40 <akebono> Thank you for your suggestions. I should go to bed, as I am in Tokyo, it's too late.
10:24:46 <Robert> Good night, akebono!\
10:25:18 <akebono> Ciao!
10:25:22 --- part: akebono left #forth
10:28:42 <PoppaVic> Optimizing is an option, a layer: a chore.
10:35:05 <Robert> An option? An onion. :) Makes your eyes hurt.
10:35:20 <PoppaVic> yeah,
10:35:39 <PoppaVic> I was hoping I'd catch someone early - it seems unlikely, doesn't it?
10:35:57 * PoppaVic sighs
10:36:21 <PoppaVic> We see these "pre-optimized" maniacs everyday, in ##C
10:36:27 <Robert> Hehe.
10:36:29 * Robert whistless.
10:36:45 <Robert> I've done that mistake a number of times.
10:36:46 <PoppaVic> does it run? (well, no - but I want to optimize!)
10:37:23 <PoppaVic> does it run well? (well - again, no: but I STILL want to optimize!)
10:37:28 <Robert> Speaking of which, I have some code to optimise... it works, but I'm worried that the performance isn't good enough.
10:37:52 <PoppaVic> I'd ask: doing? for? to? who-notices?
10:38:42 <PoppaVic> first make it work
10:39:25 <PoppaVic> Robert: a LOT of folks would do better to consider Forth(C(platform(cpu(asm))))
10:40:04 <Robert> I'd prefer to keep it portable, so asm isn't an option. I've seen C code doing the same thing faster, so I know there's some way to improve.
10:40:08 <PoppaVic> I've been bugged for at least 2 decades about this crap
10:40:11 <Robert> (viterbi decoding)
10:41:07 <PoppaVic> if yer code is slow in forth; then slow in C, look for problems NOW - before you even get into asm or mc
10:42:01 <Robert> Yes... I need to take a closer look. 
10:42:07 <PoppaVic> ..problem is envisioning Forth(platform(C(asm(mc())))
10:59:25 <PoppaVic> actually...
10:59:42 <PoppaVic> Hm,, there are TWO points of contention
11:06:18 <PoppaVic> interesting
11:21:44 --- quit: PoppaVic ("stay well, folks - I need a break.")
11:31:31 --- quit: tgunr (Read error: 104 (Connection reset by peer))
11:49:48 <Quartus> Hey, all.
11:49:57 <crc> hi Quartus
11:50:01 <Robert> Hi.
11:55:32 <Robert> There we go.
11:55:50 <Robert> Wrong channel, actually.
12:31:00 --- join: snoopy_17 (i=snoopy_1@dslb-084-058-182-003.pools.arcor-ip.net) joined #forth
12:46:21 --- join: Serg_penguin (n=z@ppp85-140-28-204.pppoe.mtu-net.ru) joined #forth
12:46:30 <Serg_penguin> hi
12:46:51 <Serg_penguin> how the Forth life going ? anny news ?
12:47:59 <crc> I've been working on the internals of RetroForth a lot, cleaning things up
12:48:37 --- quit: Snoopy42 (Read error: 110 (Connection timed out))
12:48:56 --- nick: snoopy_17 -> Snoopy42
13:04:04 --- quit: madgarden ("?OUT OF DATA  ERROR")
13:05:11 --- join: madgarden (n=madgarde@Quebec-HSE-ppp3617924.sympatico.ca) joined #forth
14:49:29 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth
14:52:36 <Robert> Hi.
15:03:58 --- quit: snowrichard ("Leaving")
15:12:29 --- quit: Serg_penguin ()
15:13:31 --- join: sproingie (i=foobar@64-121-2-59.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth
15:43:01 --- quit: sproingie ("Leaving")
17:36:57 --- quit: cmeme ("Client terminated by server")
17:40:46 --- join: cmeme (n=cmeme@216.184.11.2) joined #forth
17:42:11 --- quit: cmeme (Client Quit)
17:44:05 --- quit: JasonWoof (Remote closed the connection)
17:58:39 --- quit: tathi ("leaving")
18:16:51 --- join: cmeme (n=cmeme@boa.b9.com) joined #forth
19:58:51 --- join: akebono (n=fujiwara@218.231.198.163.eo.eaccess.ne.jp) joined #forth
19:58:51 <akebono> Quote: A book worth reading is worth buying. -- John Ruskin
19:58:59 <Robert> Morning.
19:59:06 <akebono> Morning.
19:59:35 * Robert notices that it's morning in Sweden as well, and thinks about going to bed.
19:59:35 <akebono> Are the people like you visits this channel in this time range?
19:59:54 <Robert> What do you mean, if they're here this time of the day?
20:00:07 <akebono> yes, what time is it there?
20:00:16 <Robert> 05:00.
20:00:25 <akebono> oh, it's in Europe.
20:00:30 <Robert> There has been very little activity since you went to bed.
20:00:32 <Robert> Yes, Swede.
20:00:35 <Robert> Sweden*
20:00:58 <akebono> ah, not just Americans but Europeans like to program in forth.
20:01:13 <akebono> I have one question.
20:01:14 <Robert> Yes, and Japanese too it seems. :)
20:01:31 <akebono> I am one of the very few.
20:01:46 <Robert> There aren't that many in Sweden, either.
20:01:51 <akebono> My question is about HERE.
20:02:37 <akebono> Does it usually return the address just after the CODE field of the most recent definition?
20:03:18 <akebono> if not modified by the program in the CODE?
20:04:00 <Robert> HERE returns the address of the top of the heap. It's simply where any new data will be placed.
20:04:31 <Robert> If you call HERE right after creating a word with CREATE, then yes.
20:04:42 <akebono> I see.
20:04:55 <akebono> and if I use ALLOT, it's incremented.
20:05:07 <Robert> Yes.
20:05:18 <akebono> okay.
20:05:25 <Robert> Same thing if you use "," - comma.
20:05:43 <Robert> HERE will also be incremented.
20:05:45 <akebono> ah, memories for data are allocated.
20:06:59 <akebono> also, what does NEXT do in practice?
20:07:34 <akebono> which appears at the end of a compiled definition, doesn't it?
20:07:52 <Robert> It gets the address of the next word to interpret, and jumps there.
20:08:06 <Robert> No, in the end of a compiled definition is EXIT
20:08:27 <Robert> NEXT comes after a low-level word, coded in assembly language.
20:08:51 <akebono> ah, EXIT.
20:09:01 <Robert> I attempt to explain this here (this document is NOT finished!) - http://www.robos.org/?edforth
20:09:31 <Robert> So far I have explained NEST, EXIT, NEXT
20:09:57 <akebono> I see.
20:10:11 <akebono> Exit is like return() in C.
20:10:15 <Robert> Yes.
20:12:05 <akebono> building one's own forth may be the fastest approach of understanding forth...
20:13:56 <akebono> it seems the compile/interpret mode switching is a key of the system.
20:14:42 <Robert> Yes to both.
20:14:55 <Robert> That was how I learned to understand Forth - by implementing it.
20:16:10 <akebono> the switching enables forth to be an ultimate bootstrapping machine.
20:16:43 * Robert really needs to sleep now.
20:16:47 <Robert> Good night!
20:16:58 <akebono> Thanks. good night or morning!
20:17:52 --- join: swalters (n=swalters@6532183hfc82.tampabay.res.rr.com) joined #forth
20:24:42 --- quit: akebono ("Leaving")
21:25:24 --- join: JasonWoof (n=jason@pdpc/supporter/student/Herkamire) joined #forth
21:25:24 --- mode: ChanServ set +o JasonWoof
21:42:30 --- quit: JasonWoof (Remote closed the connection)
23:59:59 --- log: ended forth/05.11.19