00:00:00 --- log: started forth/13.07.03
00:02:06 --- quit: dys (Ping timeout: 264 seconds)
00:02:22 --- join: dys (~user@2a01:1e8:e100:8296:21a:4dff:fe4e:273a) joined #forth
01:59:31 --- join: protist (~protist@69.172.69.111.dynamic.snap.net.nz) joined #forth
02:03:31 --- quit: protist (Read error: Connection reset by peer)
02:12:41 --- join: protist (~protist@139.172.69.111.dynamic.snap.net.nz) joined #forth
02:18:19 --- quit: protist (Ping timeout: 248 seconds)
02:26:57 --- quit: Ethical (Ping timeout: 252 seconds)
02:30:59 --- join: Ethical (~sam@ppp59-167-172-238.static.internode.on.net) joined #forth
03:27:55 --- join: nighty^ (~nighty@tin51-1-82-226-147-104.fbx.proxad.net) joined #forth
05:04:34 --- quit: proteusguy (Remote host closed the connection)
05:58:12 --- quit: yiyus (Read error: Operation timed out)
06:02:47 --- join: yiyus (1242712427@je.je.je) joined #forth
06:38:04 --- quit: Nisstyre (Ping timeout: 256 seconds)
07:00:35 --- join: Nisstyre (~yours@oftn/member/Nisstyre) joined #forth
07:45:13 * itsy is going to Silicon Dreams this weekend :-) http://www.silicondreams.org.uk
07:47:29 --- join: RodgerTheGreat (~rodger@50-198-177-185-static.hfc.comcastbusiness.net) joined #forth
07:52:03 <ErhardtMundt> hello
07:52:15 <RodgerTheGreat> howdy, ErhardtMundt 
07:52:17 <ErhardtMundt> I'm working on my own forth implementation
07:52:29 <ErhardtMundt> do you have any advice on how to structure the control stack?
07:52:33 <ErhardtMundt> hey, RodgerTheGreat
07:53:07 <RodgerTheGreat> ErhardtMundt: you mean you're thinking about having a separate stack for loop indices?
07:53:31 <ErhardtMundt> RodgerTheGreat: I don't know, I'm just reading the forth94 docs
07:53:40 <ErhardtMundt> and there it's mentioned a control stack
07:55:44 <ErhardtMundt> RodgerTheGreat: isn't it a common practice to use a control stack?
07:56:41 <RodgerTheGreat> ordinarily there is a parameter stack ('THE' stack) and a return stack (which contains return addresses for subroutine calls
07:56:44 --- join: protist (~protist@6.172.69.111.dynamic.snap.net.nz) joined #forth
07:56:54 <RodgerTheGreat> some forths keep loop indices on the rstack
07:57:56 <ErhardtMundt> RodgerTheGreat: so how's control handled?
07:57:56 <RodgerTheGreat> my understanding is that ANS Forth didn't want this implementation detail to be made explicit so ANS forths sometimes use an auxiliary stack for this purpose
07:58:15 <RodgerTheGreat> you mean words like IF and THEN?
07:58:47 <ErhardtMundt> I mean, the tick word, for example, affects the way the next token from the parser is interpreted
07:58:59 <ErhardtMundt> (not executed but used as a name)
07:59:04 --- join: spoofer3_ (~spoofer3@94.sub-174-253-245.myvzw.com) joined #forth
07:59:25 <ErhardtMundt> how does the interpreter deal with that?
07:59:55 <RodgerTheGreat> I guess that's one approach. The Forths I've seen before would have tick itself consume the next token rather than setting some sort of flag elsewhere
08:01:01 <ErhardtMundt> RodgerTheGreat: I see
08:01:12 <ErhardtMundt> and what about compilation mode?
08:01:35 <RodgerTheGreat> that's generally just a variable
08:02:13 --- quit: spoofer3 (Ping timeout: 252 seconds)
08:02:14 <RodgerTheGreat> if you wanted to make : ; and the like nestable ala reforth you might indeed want to use a stack
08:02:39 <RodgerTheGreat> but in most cases that complexity is not necessary
08:03:04 <ErhardtMundt> forth94 doesn't allow nested compilations
08:03:07 <ErhardtMundt> does it?
08:03:21 <RodgerTheGreat> I'm not familiar with that implementation
08:03:52 <ErhardtMundt> anyway, a flat compilation mode would suffice, I think
08:04:31 <ErhardtMundt> I'd need to know which is nestable and which is not though
08:05:41 <ErhardtMundt> RodgerTheGreat: are IF, BEGIN, DO … structs nestable in the most common implementations?
08:05:53 <RodgerTheGreat> yes
08:06:12 <RodgerTheGreat> but those simply work by storing their intermediate data on the (parameter) stack
08:06:23 <ErhardtMundt> oh
08:06:36 <ErhardtMundt> next question
08:06:43 <RodgerTheGreat> BEGIN for example just leaves an address for a later backward branch on the stack
08:06:57 <ErhardtMundt> I see
08:07:01 <ErhardtMundt> when is the return stack used?
08:07:09 <RodgerTheGreat> during execution
08:07:35 <ErhardtMundt> the parameter stack seems to be a good place to push/pop cells
08:07:42 <ErhardtMundt> why is R stack needed?
08:08:05 <RodgerTheGreat> say you defined : B  foo bar ;
08:08:16 <RodgerTheGreat> and : A B quux ;
08:08:24 <RodgerTheGreat> then you invoke A
08:08:33 <RodgerTheGreat> the first thing A does is invoke B
08:08:47 <RodgerTheGreat> when A invokes B, it saves the current PC on the rstack
08:09:08 <RodgerTheGreat> then B executes. It invokes foo and then bar, (which in turn may manipulate the rstack)
08:09:24 <RodgerTheGreat> when B returns, it pops from the rstack and resumes execution of A
08:09:31 <RodgerTheGreat> then quux is invoked
08:09:42 <RodgerTheGreat> this is very simplified but hopefully the idea is clear
08:09:53 <ErhardtMundt> it is indeed
08:09:55 <ErhardtMundt> thanks
08:10:35 <RodgerTheGreat> the rstack and parameter stack are basically twisted together into one structure in the C calling convention
08:10:54 <RodgerTheGreat> this is why "stack frames" are necessary in such languages
08:11:53 <ErhardtMundt> next question is about cells allocation
08:11:56 <RodgerTheGreat> ok
08:12:13 <ErhardtMundt> is there any allocation register?
08:12:32 <ErhardtMundt> or any place the allocated space is tracked
08:12:57 --- join: proteusguy (~proteusgu@ppp-58-11-75-103.revip2.asianet.co.th) joined #forth
08:13:08 <RodgerTheGreat> yeah, there's a value called 'here'
08:13:28 <RodgerTheGreat> sometimes it's implemented as a variable instead of a value
08:13:57 <RodgerTheGreat> (the distinction is whether invoking it gives you what's stored there or the address of the location)
08:15:26 <RodgerTheGreat> for performing allocation the words you will most often use are , (comma) and allot
08:15:35 --- quit: spoofer3_ (Ping timeout: 248 seconds)
08:16:40 <ErhardtMundt> as far as I know, memory is layed that way: names, stacks and heap
08:16:55 <ErhardtMundt> allot works on the last one
08:16:58 <ErhardtMundt> doesn't it?
08:17:28 --- join: mo (~mool@c-76-26-237-95.hsd1.fl.comcast.net) joined #forth
08:17:52 --- nick: mo -> Guest40129
08:18:09 <RodgerTheGreat> in the simplest approach, there's just dictionary space and the two stacks. The dictionary is a linked-list of headers followed by data which grows linearly. Allot and , both append to dictionary space,
08:18:39 <RodgerTheGreat> I guess you could think of that as a heap, but heaps usually imply nonlinear allocation/deallocation
08:18:59 <RodgerTheGreat> in baremetal forths, dynamic allocation isn't really a thing
08:19:22 <ErhardtMundt> so allocated space is just a special entry in the names list
08:19:33 <RodgerTheGreat> yes
08:19:40 <RodgerTheGreat> if you're using a forth which sits on top of an OS you will probably have c-style malloc and free in addition to allot and friends
08:20:12 <ttmrichter> There's nothing stopping you from doing malloc/free-style allocation, of course, but in the kinds of systems generally targeted by bare-metal Forths it would be of dubious use.
08:20:13 <RodgerTheGreat> but my point is that a heap isn't strictly necessary
08:20:47 <RodgerTheGreat> ttmrichter: yeah you could of course implement abstractions like that from within forth
08:21:00 <ErhardtMundt> is that space shrinkable or expandable?
08:26:35 <ErhardtMundt> I mean, are there forth words in order to perform those actions?
08:27:34 <RodgerTheGreat> forth emphasizes the use of static allocation
08:27:50 <RodgerTheGreat> it depends on the implementation I guess
08:28:38 <RodgerTheGreat> but when you think about it, dynamic allocation/resizing are fairly complex abstractions and aren't something any computer can actually *do*.
08:28:54 <RodgerTheGreat> forth normally operates on a lower level than all that
08:29:04 <ErhardtMundt> last (maybe) question: when do I need to use ALIGN word?
08:29:16 <RodgerTheGreat> again, if you have a kernel which already provides those services your forth will likely expose them
08:29:34 <RodgerTheGreat> I would guess primarily in "code words"
08:30:03 <RodgerTheGreat> I've never used a forth which required me to use it explicitly
08:30:22 <ErhardtMundt> I'm planning to deploy my implementation on a Commodore64
08:30:26 <RodgerTheGreat> if your architecture requires alignment I'd imagine words like CREATE and ALLOT use it implicitly where appropriate
08:30:59 <RodgerTheGreat> ah, so you'll be trying to take advantage of various 6502 addressing modes
08:31:07 <ErhardtMundt> yeah
08:31:29 <ErhardtMundt> I'm planning to replace BASIC data with my FORTH code
08:32:48 <RodgerTheGreat> that's a nice approach; I'm certain you can get a good forth kernel to fit in the rom space commodore basic uses
08:33:15 <tathi> CREATE aligns the data pointer, ALLOT doesn't (you can allot arbitrary sized memory chunks).
08:33:53 <ErhardtMundt> what's exactly the data pointer?
08:34:13 <tathi> Er, the pointer to the next free memory address in data space.
08:34:21 <tathi> let's see what ANS calls it
08:34:38 <tathi> "data-space pointer"
08:34:43 <ErhardtMundt> oh, ok
08:35:09 <ErhardtMundt> I'm just reading the specs
08:35:10 <tathi> Note also that ANS doesn't require alignment (so ALIGN and ALIGNED can just do nothing if your system supports misaligned fetches...)
08:35:44 <ErhardtMundt> in the glossary it would be appreciated if the "parameter" of the word follows or is follower by the word itself
08:35:46 <tathi> E.g. Forth Inc.'s Swiftforth on x86 used to (maybe still does?)
08:36:10 <ErhardtMundt> tathi: good to know
08:36:32 <ErhardtMundt> *followed
08:36:34 <tathi> ErhardtMundt: what do you mean?  They all have a stack-effect comment right there...
08:37:00 <ErhardtMundt> tathi: CHAR ( “<spaces>name” -- char )
08:37:20 <ErhardtMundt> I would expect “<spaces>name” to be placed on the stack
08:37:37 <tathi> Ah.  The quotes mean it is parsed from the input stream.
08:37:37 <ErhardtMundt> rather than being taken in the next token
08:37:45 <ErhardtMundt> oh
08:37:56 <tathi> Since Forth doesn't have a built in string "type".
08:38:37 <tathi> Section 2.2.3 Parsed-text notation
08:39:50 <ErhardtMundt> oh, I should have missed it
08:40:06 <tathi> Yeah, there's lots of stuff tucked away in odd little corners.
08:41:54 <RodgerTheGreat> if you're building a forth for a resource-constrained platform I'd recommend adapting forth to the platform rather than trying to shoot for standards-compliance
08:43:10 <tathi> Can you give a specific example of where the standard requires something that would use more resources?
08:43:22 * dys pleads guilty as he used "<<" instead of lshift in his first forth to save precious bytes
08:43:27 <tathi> I always hear people say that and I can never understand why...
08:45:54 <tathi> dys: ah.  I wasn't thinking *that* resource constrained.
08:46:42 <RodgerTheGreat> well for example if align is a nop on your platform you wasted space for a dictionary header and possibly a bunch of cycles for a feature which has no purpose other than compliance
08:47:51 <tathi> RodgerTheGreat: well, then, don't implement it.  You don't have to implement all the core words; you just have to label it a "standard system subset" if you don't.
08:52:14 <ErhardtMundt> can the space allocated with ALLOT be recycled for future uses?
08:53:20 <tathi> Not really...you can pass a negative number to ALLOT and it will go backwards...
08:53:35 <RodgerTheGreat> 'marker' and/or 'forget' can be used to deallocate all the dictionary space after a given point
08:53:49 <RodgerTheGreat> that's what a 'linear allocator' is
08:53:52 <tathi> But most systems put code and data in the same space, so...except in very specific circumstances you risk backing up over compiled code...
08:54:09 <ErhardtMundt> tathi: what happens if I define a word, then allot, then define another word and finally I don't need anymore the space alloted?
08:54:15 <ErhardtMundt> is it lost forever*?
08:54:29 <RodgerTheGreat> it
08:54:34 <tathi> ErhardtMundt: in general, yes.
08:54:47 <RodgerTheGreat> it's not lost but it's going to keep taking up space
08:55:01 <RodgerTheGreat> you could repurpose it for something else if something else needs that amount of space
08:56:30 <ErhardtMundt> variable names are kept in the dictionary, right?
08:56:52 <ErhardtMundt> they leave on the stack the address when EXECUTEd
08:57:05 <RodgerTheGreat> correct
08:57:07 <ErhardtMundt> as far as I understood
08:57:10 <ErhardtMundt> great
08:57:31 <ErhardtMundt> I read FORGET is now obsolete
08:57:39 <ErhardtMundt> was it replaced by something?
08:57:43 <RodgerTheGreat> marker
08:57:58 <RodgerTheGreat> it's a little easier to use properly than forget
08:58:26 --- join: spoofer3 (~spoofer3@2600:100f:b01a:a110:f76:4169:32eb:37f2) joined #forth
08:59:07 <RodgerTheGreat> forget can be handy when you're programming interactively but marker makes way more sense when you're working from a source file
09:13:06 <ErhardtMundt> POSTPONE (“<spaces>name”--)
09:13:06 <ErhardtMundt> Skip leading space delimiters. Parse name delimited by a space. Find name. Append the compilation semantics of name to the current definition. An ambiguous condition exists if name is not found.
09:13:18 <dzho> http://www.forth200x.org/unobsolete-forget.txt
09:13:36 <ErhardtMundt> what does it mean the "append" part?
09:13:48 <ErhardtMundt> what's actually appended?
09:13:55 <tathi> "compile a call to", roughly...
09:14:55 <ErhardtMundt> ok
09:15:07 <tathi> dzho: yeah, there are all kinds of arguments about why forget is "obsolete" and "hard to implement", but AFAICT they're all bogus, so which you use or implement boils down to personal preference mostly...
09:16:23 <dzho> mostly I run into this issue interactively, where I don't decide I want to FORGET until later, at which point it's too late to use MARKER . . . I think.
09:16:31 <tathi> yeah, exactly.
09:16:57 --- join: mtm (~mtm@c-24-130-130-44.hsd1.ca.comcast.net) joined #forth
09:17:03 <dzho> I suppose you could get the address of the word in question, and then negatively ALLOT?
09:17:28 <tathi> dzho: but that doesn't fix up the headers...
09:17:46 <dzho> :(
09:18:11 <tathi> ErhardtMundt: oh, that's POSTPONE, so it's not just "compile a call to".  Sorry.
09:18:59 <tathi> The "compilation semantics" means what the word does when the interpreter encounters it in compilation state.
09:20:19 <ErhardtMundt> shouldn't it be the default behaviour?
09:20:21 --- join: ncv (~quassel@79.113.85.122) joined #forth
09:20:21 --- quit: ncv (Changing host)
09:20:21 --- join: ncv (~quassel@unaffiliated/neceve) joined #forth
09:20:30 <tathi> So in a traditional system where each word has an immediate flag, if the word is immediate, POSTPONE will compile a call to it.  If it's not immediate, POSTPONE will compile a literal with the XT, and then compile a call to "COMPILE,".
09:21:25 <tathi> Or something like that.
09:39:06 <ErhardtMundt> mmh
09:43:59 <ASau> You should get it clear then first, what compilation semantics is.
09:44:13 --- join: barglfargl (~brglfrgl@66-168-203-39.dhcp.gsvl.ga.charter.com) joined #forth
09:44:35 --- quit: barglfargl (Read error: Connection reset by peer)
09:45:00 --- join: barglfargl (~brglfrgl@66-168-203-39.dhcp.gsvl.ga.charter.com) joined #forth
09:45:00 --- quit: barglfargl (Read error: Connection reset by peer)
09:46:43 --- join: barglfargl (~brglfrgl@66-168-203-39.dhcp.gsvl.ga.charter.com) joined #forth
09:47:29 <ErhardtMundt> the context is either COMPILATION, INTERPRETATION or RUN-TIME
09:47:58 <ErhardtMundt> I can't figure out what INTERPRETATION context is.
09:52:29 <ASau> Section 2.1 is pretty clear on this.
09:58:50 --- quit: spoofer3 (Ping timeout: 245 seconds)
10:01:21 --- quit: protist (Ping timeout: 260 seconds)
10:01:33 --- quit: Nisstyre (Quit: Leaving)
10:25:36 --- quit: mtm (Quit: Leaving...)
10:47:41 --- quit: barglfargl (Quit: Leaving)
10:53:07 <ARMWorksiMac1> You know, in the old days, before Kim Harris and his gang had to fancify Forth, the docs and diagrams just said "Run Time" and "Compile Time". Interpretation, if different, as well. Those guys and their semantics and syntax and Backus Naur diagrams. Gak! It was like reading an Ayn Rand philosophy paper on Man qua Man. To top it off, after all that they made the standard fuzzy with impossible things like FP stack 
10:53:08 <ARMWorksiMac1> can be mixed with P Stack or seperate, which is not portable at all.
10:55:25 <RodgerTheGreat> there are some advantages to standardization, but it definitely made things more complicated.
10:55:43 <RodgerTheGreat> it made the structure of dictionary headers opaque too
11:12:02 <ASau> Pf.
11:12:53 <ASau> There's a big observable difference between programming languages that have denotational semantics and those that don't.
11:15:06 --- join: dto (~user@pool-96-252-62-13.bstnma.fios.verizon.net) joined #forth
11:17:36 <Vuokko> detonatable semantics....
11:21:33 --- quit: epicmonkey (Ping timeout: 252 seconds)
11:35:23 --- join: ASau` (~user@p4FF9759B.dip0.t-ipconnect.de) joined #forth
11:38:41 --- quit: ASau (Ping timeout: 264 seconds)
11:39:17 --- nick: ASau` -> ASau
11:41:31 --- quit: dto (Read error: Operation timed out)
11:41:41 --- join: cp_ (~cp@talula.plus.com) joined #forth
12:29:34 --- join: epicmonkey (~epicmonke@188.134.41.113) joined #forth
12:29:47 --- join: barglfargl (~brglfrgl@66-168-203-39.dhcp.gsvl.ga.charter.com) joined #forth
12:31:02 <ARMWorksiMac1> I think it is a denotatable difference :-)
12:31:03 --- quit: barglfargl (Client Quit)
12:31:36 <ARMWorksiMac1> Semantically speaking.
12:32:00 <ARMWorksiMac1> From a syntactical point of view.
12:32:23 <ARMWorksiMac1> Using The Laws of Form in stead of BNF of course.
12:33:48 <ASau> Whatever.
12:34:25 <ASau> It helps quality of implementations, what cannot be said about various Forths.
12:34:26 <ARMWorksiMac1> They started using the lingo of compiler writers instead of interpreters that can do anyting. 
12:35:04 <ARMWorksiMac1> And argued over completenes theorems and whole ball of wax. Such a waste.
12:36:44 * ASau laughs.
12:37:27 <ASau> Still those programmers and languages succede and Forth does not.
12:48:02 --- quit: cp_ (Ping timeout: 246 seconds)
13:10:23 <ARMWorksiMac1> Can't argue with that.
13:12:47 <ARMWorksiMac1> I remain convinced that it is the standards club that ruined it.
13:13:29 <ARMWorksiMac1> Standards cghanging too often adn ech too different. And ANSI was too general with too many things left to each implementation.
13:14:45 <ARMWorksiMac1> Lost the simplicity of <BUILDS DOES> and being able tot understand the whole thing in favor of an imagined portability.
13:15:09 <ASau> The latter is misdirected.
13:16:00 <ARMWorksiMac1> Love Mike Hore's MOPS though. ANd it will compile on ANSI or earlier versions with very minor help.
13:16:22 <ASau> <builds does> thing is one of few that didn't change.
13:16:33 <ARMWorksiMac1> They renamed it.
13:16:36 <ASau> So what?
13:16:49 <ARMWorksiMac1> CREATE DOES> I think.
13:16:57 <ASau> This is the least of all problems.
13:17:17 <ARMWorksiMac1> Isn't CREATE a bit different from <BUILDS ?
13:17:33 <ASau> Not in "create ... does>" respect.
13:17:41 --- join: Inode (~inode@unaffiliated/inode) joined #forth
13:18:05 <ASau> What is more important is that the whole this thing seems to be wrong concept.
13:18:07 <ARMWorksiMac1> yes, it was those unexpected announcements sent to all the publications that there was a new standard.
13:19:01 <ARMWorksiMac1> And the standard was from a littel club but it sounded very offical. The Forth Standards Team.
13:19:44 <ARMWorksiMac1> Totally confused buyers, expecialy serious commercial projects.
13:20:23 <ARMWorksiMac1> And tools were always half-assed. Especially tools for tethered embedded development, etc.
13:20:48 <ASau> The main problem is not the multitude of standards still.
13:20:59 <ASau> In fact, there's no this multitude for a long time.
13:21:24 <Vuokko> what is the main difference between <builds and create?
13:21:47 <ASau> You can use "create" independently.
13:22:00 <ASau> "<builds" works only in conjunction with "does>".
13:22:52 <ARMWorksiMac1> I dislike ANSI for the difficulty in people bulding their own implekmentation.
13:23:16 <ARMWorksiMac1> ASau:  What do you see as the main problem?
13:23:18 <ASau> There's no difficulty.
13:23:49 <ASau> The language still depends on raw human power, this is the main problem.
13:24:00 <ARMWorksiMac1> Sure there is. Many things are left undefined for the implementor to figure out - and wind up unique or poorly done.
13:24:30 <ARMWorksiMac1> Like C. The human is the compiler.
13:24:51 <ASau> Things being "undefined" actually simplify implementation.
13:25:47 <ARMWorksiMac1> Or not. How many people haveyou seen try in the last 25 years?
13:26:17 <RodgerTheGreat> the human is not the compiler in C
13:26:17 <ASau> At least Retro folks.
13:26:53 <ASau> The problem with standard is not that it leaves a lot of things undefined or left to implementor.
13:27:03 <ASau> The problem with it is that it is irrelevant.
13:27:24 <ARMWorksiMac1> Sure, C is an assembler for a virtual machine. Try writing C without the pre-processor.
13:27:26 <ASau> It is behind technology in nearly every aspect.
13:28:13 <ARMWorksiMac1> It should be behind after 25 years of stagnation.
13:28:19 <ASau> C contains preprocessor, so this argument is irrelevant.
13:28:49 <ARMWorksiMac1> Ppreproccesor is defines in K&R?
13:28:53 --- join: barglfargl (~brglfrgl@66-168-203-39.dhcp.gsvl.ga.charter.com) joined #forth
13:29:00 <ASau> K&R don't describe C.
13:29:44 <ASau> Nobody uses K&R already.
13:30:01 <ARMWorksiMac1> Ok. Got it. Up is down. Left is right.
13:30:06 <ASau> No.
13:30:15 <ASau> Up is up. Right is right.
13:30:26 <ASau> That's why K&R does not describe C.
13:32:01 <ASau> It is hard to find compiler that is able to process that code without sometimes heavy modifications.
13:32:05 <ARMWorksiMac1> I'm just pulling your chain.
13:32:27 <ARMWorksiMac1> Forth was always dominated by Forth compiler writers.
13:32:38 <ARMWorksiMac1> I saw very very few seriou sapplications.
13:32:54 <ASau> Yes, that's the problem.
13:33:26 <ARMWorksiMac1> I di some very big instrumentation projects myself and came into i tfrom that direction. Which is why I was so frustrated by the standards goons.
13:34:45 <ARMWorksiMac1> I think a good modern comparison is the Linux gurus who jump on every ne Raspberry Pi or Beagle Bone or anything else. Fix up a kernel and alternative file systems then move on to the next gadget.
13:34:49 <ASau> Basically, that's the main reason why the language stagnates.
13:35:34 <ARMWorksiMac1> They never finish the GPIUO or anything that needs a driver. They move on before then. They are configuration experts - then gone.
13:36:24 <ASau> It is very easy to patch up a primitive compiler,
13:36:30 <ARMWorksiMac1> All the FOrth energy went into who can write a better CASE statement instead of practical fixed point math, etc.
13:36:32 <ASau> but everything else is not even worked on.
13:36:48 <ASau> Fixed point math is heavy undertaking.
13:36:53 <ASau> Almost nobody needs it.
13:37:15 <ARMWorksiMac1> There was tremendous resistance when I first introduced hardware floating point and a full vocabulary.
13:37:41 <ASau> And given that FPNs are cheap, it is as easy to use FPNs.
13:38:02 <ASau> easier and more practical
13:38:07 <ARMWorksiMac1> AMD9511 chip on an Apple II (it also did integer math so was quite a speed up for everything).
13:39:04 <ARMWorksiMac1> PostScript is basically Forth built around good floating point.
13:39:19 <ASau> Fixed point math requires a lot of mostly pointless manual work.
13:39:30 <ARMWorksiMac1> I know a few peple who still write code in PostScript.
13:40:40 <ARMWorksiMac1> On an AVR in an Arduino it can be worth it, but today you can plant an ARM M4 in the same space at 160 MHz and with hardware FP.
13:40:49 <ARMWorksiMac1> And the same cost.
13:41:13 <ASau> Yes.
13:42:22 <ARMWorksiMac1> The same goes for the "advantage" of interactive development. It was cool back then, but now the edit/compile/upload/test cycle in Eclipse (or whatever) on modern cheap workstation is nearly instant.
13:43:56 <ASau> Yes.
13:43:59 <ARMWorksiMac1> I have a couple of boxes here that are AMD 8 core 3.4GHz with dual displays that were barebones a couple hundred bucks and the Acer 21" LCDs are on sale for $80 each. A -j24 option for make will compile a Linux kernel in a couple of minutes.
13:45:43 <ASau> Even on less powerful workstations one can easily build projects much larger than anything written in Forth in a wink of an eye.
13:46:46 <ARMWorksiMac1> Still, I want to finish my old ARM FIG style Forth and use it on one of my ARM9 systems. Half the cashe can be locked and I can get the core vocabulary in the loacked cache. Also lock the MMU and run bare metal on a real-time task of some sort.
13:47:04 <ARMWorksiMac1> I want to see if there is any reason to do it.
13:48:28 <ASau> I did FIG style Forth for some time.
13:49:01 <ARMWorksiMac1> I saw potential for the object model in MOPS. It would take a user comminity plus agreement to use a single version of MOPS to build up the body of work that would make it worthwhile.
13:49:26 <ASau> It is a big leap forward that this dialect died out.
13:49:55 <ARMWorksiMac1> But I must say, with the very impressive Python libraries of all sorts, that is where I am today.
13:49:56 <ASau> For instance, its parser and block subsystem are really broken.
13:50:51 <ARMWorksiMac1> MOPS was on Macs and used the modern file structure. Mike did not wnat to rewrite for Intel Macs and it sort of died there. 
13:52:41 <ASau> Slightly less stringent drawbacks are clumsy dictionary structure,
13:52:41 <ARMWorksiMac1> The text, physics and math and visualization packages are being used by researchers everywhere and Django and database features are easy to use and very nice as well. I havestarted putting Debian Squeeze on our ARM systems and run X, Python and TKinter. It is a great way to go.
13:52:45 <ASau> lack of exceptions and other error handling,
13:53:08 <ARMWorksiMac1> Yep.
13:54:18 <ASau> rather funky arithmetics
13:54:22 <ARMWorksiMac1> Need a cell MODEM? There is an SMS library already written. Python is growing rapidly in popularity.
13:55:28 --- part: Inode left #forth
13:55:44 <ARMWorksiMac1> You have to catch on to "Pythonic" thinking, but it is not irritating and doesn't cause brain damage like things like Microsoft Reverse Hungarian coding standards.
13:56:39 <ASau> Python is very far from being ideal, but it is definitly an enormous progress when compared to Forth.
13:57:24 <ASau> With its conventional infix notation, garbage collection, no direct access to memory, and so on.
14:01:47 <Vuokko> but the pinnacle of programming languages is PHP.
14:02:52 <Vuokko> it works with everything magically does things which can't be imagined and is familiar with syntax
14:03:26 <Vuokko> and take that with a lot of sarcasm
14:15:10 --- quit: ncv (Remote host closed the connection)
14:20:18 --- quit: barglfargl (Quit: Leaving)
14:29:38 --- quit: nighty^ (Remote host closed the connection)
14:31:58 --- join: kulp (~kulp@unaffiliated/kulp) joined #forth
14:32:29 --- quit: epicmonkey (Ping timeout: 260 seconds)
14:36:08 --- join: Mat2 (~claude@91-65-144-133-dynip.superkabel.de) joined #forth
14:36:19 <Mat2> hi
15:01:50 --- quit: carc (Quit: QUIT)
15:04:34 --- join: carc (~carc@unaffiliated/carc) joined #forth
16:20:02 --- quit: Mat2 (Quit: Verlassend)
17:42:31 --- join: dto (~user@pool-96-252-62-13.bstnma.fios.verizon.net) joined #forth
18:07:36 --- join: Nisstyre-laptop (~yours@oftn/member/Nisstyre) joined #forth
18:07:39 --- quit: dto (Remote host closed the connection)
18:21:02 --- nick: Nisstyre-laptop -> Nisstyre
18:39:24 --- quit: Nisstyre (Quit: Leaving)
18:53:47 --- quit: ASau (Ping timeout: 246 seconds)
19:07:35 --- join: ASau (~user@p4FF9759B.dip0.t-ipconnect.de) joined #forth
19:20:01 --- join: Nisstyre (~yours@oftn/member/Nisstyre) joined #forth
19:23:36 --- join: spoofer3 (~spoofer3@2600:100f:b024:901e:ab7d:6b5a:820c:5302) joined #forth
19:38:43 --- quit: goingretro (Remote host closed the connection)
19:55:15 --- quit: tangentstorm (Ping timeout: 252 seconds)
20:11:35 --- join: tangentstorm (~michal@108-218-151-22.lightspeed.rcsntx.sbcglobal.net) joined #forth
20:16:03 --- join: barglfargl (~brglfrgl@66-168-203-39.dhcp.gsvl.ga.charter.com) joined #forth
20:25:57 --- quit: barglfargl (Quit: Leaving)
21:32:57 --- quit: proteusguy (Ping timeout: 260 seconds)
21:35:36 --- join: epicmonkey (~epicmonke@188.134.41.113) joined #forth
21:35:59 --- join: protist (~protist@226.172.69.111.dynamic.snap.net.nz) joined #forth
21:47:06 --- join: proteusguy (~proteusgu@ppp-58-11-75-103.revip2.asianet.co.th) joined #forth
21:55:59 --- quit: epicmonkey (Read error: Operation timed out)
21:58:09 --- quit: proteusguy (Ping timeout: 260 seconds)
22:00:58 --- quit: Guest40129 (Quit: Leaving)
22:01:39 --- join: proteusguy (~proteusgu@ppp-58-11-75-103.revip2.asianet.co.th) joined #forth
23:06:54 --- quit: protist (Ping timeout: 256 seconds)
23:39:06 --- quit: Nisstyre (Quit: Leaving)
23:39:46 --- quit: proteusguy (Remote host closed the connection)
23:48:33 --- quit: RodgerTheGreat (Quit: RodgerTheGreat)
23:59:24 --- join: proteusguy (~proteusgu@180.183.42.219) joined #forth
23:59:59 --- log: ended forth/13.07.03