Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #54673 > unrolled thread

Really?

Back to article view | Back to comp.lang.forth

Contents

  Really? Mark Wills <markwills1970@gmail.com> - 2017-02-06 06:46 -0800
    Re: Really? foxaudioresearch@gmail.com - 2017-02-06 07:20 -0800
    Re: Really? polymorph self <jackvanc3@gmail.com> - 2017-02-06 08:58 -0800
    Re: Really? rickman <gnuarm@gmail.com> - 2017-02-06 13:06 -0500
    Re: Really? hughaguilar96@gmail.com - 2017-02-06 11:25 -0800
    Re: Really? "HAA" <someone@microsoft.com> - 2017-02-07 11:45 +1100
    Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-06 15:38 -1000
      Re: Really? hughaguilar96@gmail.com - 2017-02-07 09:50 -0800
    Re: Really? Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-02-06 23:39 -0500
      Re: Really? Mark Wills <markwills1970@gmail.com> - 2017-02-07 08:04 -0800
      Re: Really? "HAA" <someone@microsoft.com> - 2017-02-08 11:04 +1100
        Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 23:42 -0800
          Re: Really? "HAA" <someone@microsoft.com> - 2017-02-08 20:12 +1100
            Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-08 02:44 -0800
            Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-08 17:48 +0000
              Re: Really? Alex <alex@rivadpm.com> - 2017-02-08 18:43 +0000
                Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-08 15:24 -0800
              Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-08 16:26 -0800
      Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 22:45 -0800
        Re: Really? hughaguilar96@gmail.com - 2017-02-07 22:50 -0800
      Re: Really? clozaga@gmail.com - 2017-02-08 21:03 -0800
        Re: Really? clozaga@gmail.com - 2017-02-08 21:04 -0800
        Re: Really? hughaguilar96@gmail.com - 2017-02-11 20:01 -0800
          Re: Really? Alex <alex@rivadpm.com> - 2017-02-12 16:26 +0000
            Re: Really? hughaguilar96@gmail.com - 2017-02-12 16:52 -0800
              Re: Really? Alex <alex@rivadpm.com> - 2017-02-13 09:49 +0000
                Re: Really? minforth@arcor.de - 2017-02-13 07:03 -0800
                Re: Really? hughaguilar96@gmail.com - 2017-02-13 13:41 -0800
                  Re: Really? Alex <alex@rivadpm.com> - 2017-02-13 22:32 +0000
                    Re: Really? hughaguilar96@gmail.com - 2017-02-15 11:42 -0800
                      Re: Really? Alex <alex@rivadpm.com> - 2017-02-15 20:41 +0000
                        Re: Really? hughaguilar96@gmail.com - 2017-02-17 09:42 -0800
                          Re: Really? Alex <alex@rivadpm.com> - 2017-02-17 22:22 +0000
            Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-12 19:24 -1000
              Re: Really? Alex <alex@rivadpm.com> - 2017-02-13 08:49 +0000
    Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-07 11:01 +0000
      Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 03:06 -0800
        Re: Really? hughaguilar96@gmail.com - 2017-02-07 09:35 -0800
        Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-07 17:35 +0000
          Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 23:24 -0800
            Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-09 08:57 +0000
              Re: Really? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-09 13:24 +0100
                Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-11 15:32 +0000
        Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-07 20:42 +0000
          Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-07 13:58 -1000
            Re: Really? hughaguilar96@gmail.com - 2017-02-07 21:51 -0800
              Re: Really? rickman <gnuarm@gmail.com> - 2017-02-08 01:47 -0500
                Re: Really? hughaguilar96@gmail.com - 2017-02-07 22:52 -0800
                  Re: Really? rickman <gnuarm@gmail.com> - 2017-02-08 03:34 -0500
                    Re: Really? Alex <alex@rivadpm.com> - 2017-02-08 13:43 +0000
                      Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-08 15:39 -1000
                        Re: Really? hughaguilar96@gmail.com - 2017-02-08 22:39 -0800
                          Re: Really? Alex <alex@rivadpm.com> - 2017-02-09 08:56 +0000
                            Re: Really? hughaguilar96@gmail.com - 2017-02-09 14:36 -0800
                              Re: Really? Alex <alex@rivadpm.com> - 2017-02-10 08:33 +0000
                        Re: Really? Alex <alex@rivadpm.com> - 2017-02-09 09:03 +0000
                          Re: Really? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-09 10:51 +0100
                            Re: Really? john <anon@example.com> - 2017-02-09 11:54 +0000
                              Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-09 09:30 -1000
                            Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-09 14:14 +0000
                              Re: Really? Alex <alex@rivadpm.com> - 2017-02-09 14:37 +0000
                                Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-09 15:24 +0000
                                  Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-09 12:01 -0800
                                    Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-10 01:09 +0000
                                      Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-09 18:19 -0800
                                        Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-09 16:30 -1000
                                      Re: Really? hughaguilar96@gmail.com - 2017-02-09 19:16 -0800
                                        Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-10 16:29 +0000
                                          OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 17:30 +0000
                                            Re: OT: [ was re: Really?] Foreign aid Cecil Bayona <cbayona@cbayona.com> - 2017-02-10 11:46 -0600
                                              Re: OT: [ was re: Really?] Foreign aid Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-02-10 11:54 -0600
                                                Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 18:05 +0000
                                              Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 17:55 +0000
                                                Re: OT: [ was re: Really?] Foreign aid Cecil Bayona <cbayona@cbayona.com> - 2017-02-10 12:04 -0600
                                                  Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 18:07 +0000
                                                    Re: OT: [ was re: Really?] Foreign aid Cecil Bayona <cbayona@cbayona.com> - 2017-02-10 12:57 -0600
                                                      Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-10 19:26 +0000
                                                        Re: OT: [ was re: Really?] Foreign aid Cecil Bayona <cbayona@cbayona.com> - 2017-02-10 14:04 -0600
                                                          Re: OT: [ was re: Really?] Foreign aid Alex <alex@rivadpm.com> - 2017-02-11 09:35 +0000
                                          Re: Really? hughaguilar96@gmail.com - 2017-02-10 16:33 -0800
                                      Static type checking (was: Really?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-10 11:07 +0000
                                Re: Really? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-11 15:16 +0000
                                  Re: Really? Cecil Bayona <cbayona@cbayona.com> - 2017-02-11 10:20 -0600
                                  Re: Really? hughaguilar96@gmail.com - 2017-02-11 19:02 -0800
                              Re: Really? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-10 17:31 +0100
                    Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-08 15:34 -1000
                Re: Really? "Elizabeth D. Rather" <erather@forth.com> - 2017-02-07 21:15 -1000
                Re: Really? Paul Rubin <no.email@nospam.invalid> - 2017-02-07 23:46 -0800
          Re: Really? hughaguilar96@gmail.com - 2017-02-07 22:47 -0800
            Re: Really? Ron Aaron <rambamist@gmail.com> - 2017-02-08 08:52 +0200
      Re: Really? rickman <gnuarm@gmail.com> - 2017-02-07 06:29 -0500
        Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-07 20:47 +0000
          Re: Really? rickman <gnuarm@gmail.com> - 2017-02-07 16:23 -0500
            Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-08 09:47 +0000
              Re: Really? rickman <gnuarm@gmail.com> - 2017-02-08 05:13 -0500
                Re: Really? stephen@mpeforth.com (Stephen Pelc) - 2017-02-08 11:23 +0000
      Re: Really? Cecil Bayona <cbayona@cbayona.com> - 2017-02-07 09:49 -0600
    Really? Mark Wills <markwills1970@gmail.com> - 2017-02-09 00:30 -0800
      Re: Really? "HAA" <someone@microsoft.com> - 2017-02-10 10:32 +1100
        Re: Really? hughaguilar96@gmail.com - 2017-02-09 17:22 -0800

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

#54767 — Static type checking (was: Really?)

stephen@mpeforth.com (Stephen Pelc) writes:
>On Thu, 09 Feb 2017 12:01:06 -0800, Paul Rubin
><no.email@nospam.invalid> wrote:
>
>>stephen@mpeforth.com (Stephen Pelc) writes:
>>> The safety-critical version of DcocGen, DocGen/SC, has formally
>>> parsed stack comments since the year 2000.
>>
>>Does it compare the stack comment with the code?
>
>No, but if you look carefully on the MPE web site we have asked
>for people to provide to such a tool. Many have waved their hands
>but none have delivered.
>
>After Brexit, there is now no suitable source of funding for such
>a poject. If you want to see the papers, look for EuroForth papers
>by Jaanos Poial.

While Jaanus Poial has done some very good work, I don't think that
his work on static type checking of Forth is on the right track for
something that's practical for existing Forth code, or new Forth code
without too much deviation from current idioms.  Two or three students
of mine have done prototyping work on static type checking for Forth,
and the results were neither satisfying nor promising, and I have come
to the conclusion, that that's not the fault of the students:

Type checking of Forth code is hard (and static type checking is
harder), because it's hard to find good type rules beyond stack depth
checking.  E.g., is 

key 5 *

a type error?  We need more context to decide this:

key 5 * emit

That probably is a type error.

key 5 * .

Ok, for debugging, but probably a type error otherwise.

key 5 * a + char+ c@

Looks like an access to a lookup table with 5-byte entries, don't
complain.

key 5 * a + @

A potentially unaligned access to a lookup table.  Maybe complain
about lack of portability, if you are on a machine that supports
unaligned accesses.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#54791

Alex <alex@rivadpm.com> writes:
>Perhaps that needs to be in the standard. If we can parse moustachieod 
>locals, surely we can formally parse stack comments.

We can restrict stack descriptions such that they can be parsed and,
to some extent, understood by the compiler.  E.g., see the use of
stack effect descriptions in vmgen:
<https://www.complang.tuwien.ac.at/anton/vmgen/html-docs/Simple-instructions.htm>

The question is if we are prepared to limit Forth to the things that a
specific stack effect syntax would limit us to, and if we are prepared
to write our stack effect descriptions in the way required by the
syntax.

And if we are, then there is still the stony path towards
standardization before us: Some people want it for one purpose, others
for other purposes, and of course, someone will point out
not-yet-invented purposes that we need to prepare for ...

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#54793

On 2/11/2017 9:16 AM, Anton Ertl wrote:
> Alex <alex@rivadpm.com> writes:
>> Perhaps that needs to be in the standard. If we can parse moustachieod
>> locals, surely we can formally parse stack comments.
>
> We can restrict stack descriptions such that they can be parsed and,
> to some extent, understood by the compiler.  E.g., see the use of
> stack effect descriptions in vmgen:
> <https://www.complang.tuwien.ac.at/anton/vmgen/html-docs/Simple-instructions.htm>
>
> The question is if we are prepared to limit Forth to the things that a
> specific stack effect syntax would limit us to, and if we are prepared
> to write our stack effect descriptions in the way required by the
> syntax.
>
> And if we are, then there is still the stony path towards
> standardization before us: Some people want it for one purpose, others
> for other purposes, and of course, someone will point out
> not-yet-invented purposes that we need to prepare for ...
>
> - anton
>
Bad link;
< 
https://www.complang.tuwien.ac.at/anton/vmgen/html-docs/Simple-instructions.html 
  >

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#54800

On Saturday, February 11, 2017 at 8:31:38 AM UTC-7, Anton Ertl wrote:
> Alex <alex@rivadpm.com> writes:
> >Perhaps that needs to be in the standard. If we can parse moustachieod 
> >locals, surely we can formally parse stack comments.
> 
> We can restrict stack descriptions such that they can be parsed and,
> to some extent, understood by the compiler.  E.g., see the use of
> stack effect descriptions in vmgen:
> <https://www.complang.tuwien.ac.at/anton/vmgen/html-docs/Simple-instructions.htm>
> 
> The question is if we are prepared to limit Forth to the things that a
> specific stack effect syntax would limit us to, and if we are prepared
> to write our stack effect descriptions in the way required by the
> syntax.
> 
> And if we are, then there is still the stony path towards
> standardization before us: Some people want it for one purpose, others
> for other purposes, and of course, someone will point out
> not-yet-invented purposes that we need to prepare for ...

Factor already does this. 

There are some limitations, especially that functions can't have a variable number of parameters or return values like in Forth (in Forth the value of one parameter will determine whether there is another parameter or parameters). The Factor crowd (who out-number the ANS-Forth crowd by an order of magnitude) seem to get by okay --- they write programs that work --- the ANS-Forth crowd don't write programs, but instead spend all of their time on the internet boasting that they set the standard for people like me and that everybody is entirely dependent upon their genius, all of which is just a great steaming pile of salesmanship.

Threads such as this are awful boring! The ANS-Forth enthusiasts never write any code --- they just speculate wildly on what could be written at some time in the future --- nothing has really changed since the 1980s when all the Forthers were talking up Forth's unlimited potential...

[toc] | [prev] | [next] | [standalone]

#54769

In article <589c77b9.95886950@news.eternal-september.org>,
Stephen Pelc <stephen@mpeforth.com> wrote:
>On Thu, 9 Feb 2017 10:51:48 +0100 (CET),
>albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) wrote:
>
>>That's why ( addr len -- fl ) "comments" are harmful. There must be a
>>narrative, (a sequence of proper sentences that are statements, i.e.
>>can be true or false) that tells *everything* one must know about
>>this word (that is not defined in the context of the project already).
>
>Stack comments are essential. People who do not provide a stack
>comment for every word do not work for MPE. However, each word
>*must* also have a description. In MPE world, this is the
>  \ *G What this word does and why.
>comment provided for each word.
>
>In order to write code that is maintainable beyond the time
>frame of the original programmer, his memory and her availability,
>both the stack comment and the description/narrative must be
>present.
>
>Note that this discipline applies to all programming languages.

A proper narrative implies the stack comment.
My stylized narratives even allow mechanical extraction of
stack comments.

It is a kind of lithmus test for the narrative whether the stack
action can be derived from it.

>
>Stephen

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#54731

On 2/7/17 10:34 PM, rickman wrote:
> On 2/8/2017 1:52 AM, hughaguilar96@gmail.com wrote:
>> On Tuesday, February 7, 2017 at 11:47:26 PM UTC-7, rickman wrote:
>>> On 2/8/2017 12:51 AM, hughaguilar96@gmail.com wrote:
>>>> This is what I said:
>>>>
>>>> On Tuesday, February 7, 2017 at 10:35:16 AM UTC-7,
>>>> hughag...@gmail.com wrote:
>>>>> The way that this worked, was that the team members had very
>>>>> distinct responsibilities.
>>>>> ...
>>>>> The important point is that everybody stays out of each other's
>>>>> turf --- this way, instead of one big project developed by a team,
>>>>> there are three small projects each developed by a single person
>>>>> --- all three parts have to work together, of course, so there has
>>>>> to be good communication.
>>>>
>>>> This is what Elizabeth Rather said:
>>>>
>>>> On Tuesday, February 7, 2017 at 4:58:49 PM UTC-7, Elizabeth D.
>>>> Rather wrote:
>>>>> * It's important for the team members to agree on common coding
>>>>> styles.
>>>>> This makes it much easier for them to read each others' code, and feel
>>>>> comfortable about sharing code. This agreement should be codified
>>>>> at the
>>>>> beginning of the project.
>>>>
>>>> Why are the team members reading each others' code? Why are they
>>>> sharing code?
>>>>
>>>> AFAIK, when I wrote MFX nobody at Testra read my code. If they did,
>>>> they never commented on it to me. It was really all about the code
>>>> doing what it was supposed to do --- I don't think anybody cared
>>>> about the internal workings.
>>>>
>>>> Moving on, here is a quote from Elizabeth Rather:
>>>> ------------------------------------------------------------------------------------
>>>>
>>>> Truly, I don't see the point of all this paranoia about reentrancy,
>>>> particularly in systems without a multitasker. VARIABLE was
>>>> *designed* for things that would be used in multiple definitions. I
>>>> remember the horror of (*gasp*) global variables back in the 1960's
>>>> in Fortran. But, frankly, in 30+ years of programming in Forth I
>>>> never found them a problem. I think this is all about mythical dragons.
>>>> ------------------------------------------------------------------------------------
>>>>
>>>>
>>>> Maybe the Valdocs team got bit by a mythical dragon! If Elizabeth
>>>> Rather taught them Forth, then she most certainly taught them that
>>>> if any string needed to be held for any period of time, then PAD was
>>>> where it should be stored. What could go wrong?
>>>>
>>>> Here is another Elizabeth Rather quote:
>>>> ------------------------------------------------------------------------------------
>>>>
>>>> People are much too phobic about [global] variables. The cry, "They
>>>> aren't re-entrant" simply means you have to look at the whole
>>>> application and how it is organized.
>>>> ------------------------------------------------------------------------------------
>>>>
>>>>
>>>> The idea that you "simply ... have to look at the whole application"
>>>> works well in Elizabeth Rather's novice class because the "program"
>>>> is less than 20 lines long and consists of maybe 3 or 4 functions
>>>> --- it is easy to look at the whole application and make sure that
>>>> there are no clashes in the commonly used global variables.
>>>>
>>>> Looking at the whole application is going to be difficult when there
>>>> is 16MB of source-code --- the programmers need to understand the
>>>> concept of re-entrancy --- they can't pass data between functions in
>>>> global variables.
>>
>>> You are aware that re-entrancy is only an issue with multitasking,
>>> right?  Was this OS multitasking?
>>
>> Re-entrancy is not just an issue with multi-tasking.
>>
>> If a function uses PAD internally and calls another function that uses
>> PAD internally, then chaos will result.
>>
>> This should be obvious to anybody!
>
> I don't know I've ever seen this referred to as reentrancy.  Looking on
> the web it's hard to find authoritative sources about reentrancy... but
> here is wikipedia, not that I consider wikipedia to necessarily be
> authoritative.
>
> ********************************
> In computing, a computer program or subroutine is called reentrant if it
> can be interrupted in the middle of its execution, and then be safely
> called again ("re-entered") before its previous invocations complete
> execution. The interruption could be caused by an internal action such
> as a jump or call, or by an external action such as a hardware interrupt
> or signal. Once the reentered invocation completes, the previous
> invocations will resume correct execution.
> ********************************
>
> So they do allow for the case of a routine calling another and ending up
> calling itself.  But what you describe is one routine calling another
> that shares a common data structure.  That's not technically reentrancy.
>  Still, I suppose I get your point.  Recursion is a form of reentrancy.
>  But that simply means you need to be aware when routines can be called
> recursively which is very infrequent.  Otherwise, you simply have to be
> aware when you are sharing data structures.
>

At least in a normal multitasking environment each task will have its 
own PAD as well as USER variables.

Cheers,
Elizabeth

-- 
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

[toc] | [prev] | [next] | [standalone]

#54707

On 2/7/17 8:47 PM, rickman wrote:
> On 2/8/2017 12:51 AM, hughaguilar96@gmail.com wrote:
>> This is what I said:
>>
>> On Tuesday, February 7, 2017 at 10:35:16 AM UTC-7, hughag...@gmail.com
>> wrote:
>>> The way that this worked, was that the team members had very distinct
>>> responsibilities.
>>> ...
>>> The important point is that everybody stays out of each other's turf
>>> --- this way, instead of one big project developed by a team, there
>>> are three small projects each developed by a single person --- all
>>> three parts have to work together, of course, so there has to be good
>>> communication.
>>
>> This is what Elizabeth Rather said:
>>
>> On Tuesday, February 7, 2017 at 4:58:49 PM UTC-7, Elizabeth D. Rather
>> wrote:
>>> * It's important for the team members to agree on common coding styles.
>>> This makes it much easier for them to read each others' code, and feel
>>> comfortable about sharing code. This agreement should be codified at the
>>> beginning of the project.
>>
>> Why are the team members reading each others' code? Why are they
>> sharing code?
>>
>> AFAIK, when I wrote MFX nobody at Testra read my code. If they did,
>> they never commented on it to me. It was really all about the code
>> doing what it was supposed to do --- I don't think anybody cared about
>> the internal workings.
>>
>> Moving on, here is a quote from Elizabeth Rather:
>> ------------------------------------------------------------------------------------
>>
>> Truly, I don't see the point of all this paranoia about reentrancy,
>> particularly in systems without a multitasker. VARIABLE was *designed*
>> for things that would be used in multiple definitions. I remember the
>> horror of (*gasp*) global variables back in the 1960's in Fortran.
>> But, frankly, in 30+ years of programming in Forth I never found them
>> a problem. I think this is all about mythical dragons.
>> ------------------------------------------------------------------------------------
>>
>>
>> Maybe the Valdocs team got bit by a mythical dragon! If Elizabeth
>> Rather taught them Forth, then she most certainly taught them that if
>> any string needed to be held for any period of time, then PAD was
>> where it should be stored. What could go wrong?
>>
>> Here is another Elizabeth Rather quote:
>> ------------------------------------------------------------------------------------
>>
>> People are much too phobic about [global] variables. The cry, "They
>> aren't re-entrant" simply means you have to look at the whole
>> application and how it is organized.
>> ------------------------------------------------------------------------------------
>>
>>
>> The idea that you "simply ... have to look at the whole application"
>> works well in Elizabeth Rather's novice class because the "program" is
>> less than 20 lines long and consists of maybe 3 or 4 functions --- it
>> is easy to look at the whole application and make sure that there are
>> no clashes in the commonly used global variables.
>>
>> Looking at the whole application is going to be difficult when there
>> is 16MB of source-code --- the programmers need to understand the
>> concept of re-entrancy --- they can't pass data between functions in
>> global variables.
>
> You are aware that re-entrancy is only an issue with multitasking,
> right?  Was this OS multitasking?
>

Every Forth provided and supported by FORTH, Inc. from 1973 until today 
has been a multitasking system, including the embedded targets from SwiftX.

And I have no idea what "program" Hugh is referring to,

Cheers,
Elizabeth

-- 
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

[toc] | [prev] | [next] | [standalone]

#54710

rickman <gnuarm@gmail.com> writes:
> You are aware that re-entrancy is only an issue with multitasking,
> right?  Was this OS multitasking?

1. Re-entrancy is an issue anytime you have interrupts, which could be
thought of as multitasking but usually isn't.

2. I don't know if Valdocs was multitasking, but if it wasn't, maybe it
should have been.  People kept complaining about it being slow.  Maybe
it was slow because things that should have been done as background
tasks, instead made the UI wait.

[toc] | [prev] | [next] | [standalone]

#54702

On Tuesday, February 7, 2017 at 1:42:30 PM UTC-7, Stephen Pelc wrote:
> On Tue, 07 Feb 2017 03:06:46 -0800, Paul Rubin
> >Got any advice about how to manage Forth projects?
> 
> 1) Hire good programmers (applies to any language),
> 2) Apply the surgical team aproach from the Mythical Man Month.
> 3) Be prepared to be brutal - do not waste time getting rid
>    of bad people. You may have to get rid of a guru, they tend
>    to be destructive in teams.
> 4) Keep the team small.

All of your 4 ideas are the same --- hire only good programmers and fire the bad programmers.

So, what is your definition of a good Forth programmer?

You have repeatedly said that I'm a bad Forth programmer --- is there any definition of a good Forth programmer, other than just being opposite of me?

[toc] | [prev] | [next] | [standalone]

#54706

On 02/08/2017 08:47, hughaguilar96@gmail.com wrote:

> So, what is your definition of a good Forth programmer?
> 
> You have repeatedly said that I'm a bad Forth programmer --- is there any definition of a good Forth programmer, other than just being opposite of me?

You may or may not be a good Forth programmer.  However, you've amply
demonstrated your inability to work with others and be civil.

I'm getting ready to hire some people on contract, but even if you were
the most qualified programmer on the planet I wouldn't hire you, since
you would be poisonous to team cohesion.  Not to mention you don't know
how to take criticism and improve your game.

Morale is almost as important as technical competence, and team members
who can't take direction are destructive.

[toc] | [prev] | [next] | [standalone]

#54684

On 2/7/2017 6:01 AM, Stephen Pelc wrote:
> On Mon, 6 Feb 2017 06:46:00 -0800 (PST), Mark Wills
> <markwills1970@gmail.com> wrote:
>
>> "As for Forth, although it has dedicated advocates, it's
>> explicit stack orientation and its lack of modularity limit
>> the scale of Forth programs. One of the largest Forth efforts
>> was an integrated operating system called Valdocs (Valuable
>> Document System) on the Epson QX-10. The software remained buggy
>> couldn't be updated quickly enough for the machine to remain
>> competitive - although you could just as easilly blame the
>> computer's Z-80 processor (since at the time the 8088 based IBM PC
>> and 68000 based Apple Macintosh were being introduced) and difficulty
>> in finding experienced Forth programmers. Whatever the cause, this
>> soured the acceptance of Forth for large scale projects."
>>
>> http://www.cpushack.com/CPU/cpuAppendB.html#Forth
>
> I have met several of the Valdocs people. The critical problems
> with the project were project management problems. In any large
> project, project management is really, really important.
>
> To give an example of a current large Forth project that has
> evolved over 30 years, see the Candy system at
>   http://constructioncomputersoftware.com/
> which is currently built on VFX Forth for Windows. Candy consists
> of 55 Mb of source code in 1.2 million lines of code and generates
> an executable of 27 Mb. I always quote this one because I do a full
> rebuild before each VFX Forth release.

Just out of curiosity, how long does it take to compile this code?  Any 
idea of what feature of the computer limits the speed?  CPU speed, disk 
speed, memory speed, cache size?

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#54692

On Tue, 7 Feb 2017 06:29:34 -0500, rickman <gnuarm@gmail.com> wrote:

>Just out of curiosity, how long does it take to compile this code?

29 seconds on an i7, 3.4GHz, 8 Gb RAM, Win 7.

It used to be 72 seconds, but we discovered that the word that
moved words from one wordlist to another was general purpose. It
was replaced by a specific one.

> Any idea of what feature of the computer limits the speed?  CPU speed, disk 
>speed, memory speed, cache size?

Disk cache is the limit. The first compile after a reboot can take 
twice as long.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#54696

On 2/7/2017 3:47 PM, Stephen Pelc wrote:
> On Tue, 7 Feb 2017 06:29:34 -0500, rickman <gnuarm@gmail.com> wrote:
>> On 2/7/2017 6:01 AM, Stephen Pelc wrote:
>>
>>> To give an example of a current large Forth project that has
>>> evolved over 30 years, see the Candy system at
>>>   http://constructioncomputersoftware.com/
>>> which is currently built on VFX Forth for Windows. Candy consists
>>> of 55 Mb of source code in 1.2 million lines of code and generates
>>> an executable of 27 Mb. I always quote this one because I do a full
>>> rebuild before each VFX Forth release.
>
>> Just out of curiosity, how long does it take to compile this code?
>
> 29 seconds on an i7, 3.4GHz, 8 Gb RAM, Win 7.
>
> It used to be 72 seconds, but we discovered that the word that
> moved words from one wordlist to another was general purpose. It
> was replaced by a specific one.
>
>> Any idea of what feature of the computer limits the speed?  CPU speed, disk
>> speed, memory speed, cache size?
>
> Disk cache is the limit. The first compile after a reboot can take
> twice as long.
>
> Stephen

I wish you hadn't snipped the stats of the code being compiled.  I'm 
pasting them back in so this info is all together.

Mayonnaise

-- 

Rick C

I always wanted to end a post with the word Mayonnaise.

[toc] | [prev] | [next] | [standalone]

#54714

On Tue, 7 Feb 2017 16:23:06 -0500, rickman <gnuarm@gmail.com> wrote:

>I wish you hadn't snipped the stats of the code being compiled.  I'm 
>pasting them back in so this info is all together.
>
>Mayonnaise

What do you mean by mayonnaise?

How about the recipe for the mayonnaise?
Whole-egg or proper?
Shop-bought or home-made?
If shop-bought, then which?
If home-made, then ingredients and age of eggs.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#54715

On 2/8/2017 4:47 AM, Stephen Pelc wrote:
> On Tue, 7 Feb 2017 16:23:06 -0500, rickman <gnuarm@gmail.com> wrote:
>
>> I wish you hadn't snipped the stats of the code being compiled.  I'm
>> pasting them back in so this info is all together.
>>
>> Mayonnaise
>
> What do you mean by mayonnaise?
>
> How about the recipe for the mayonnaise?
> Whole-egg or proper?
> Shop-bought or home-made?
> If shop-bought, then which?
> If home-made, then ingredients and age of eggs.

A tribute to Richard Brautigan.  His birthday was last week.  I liked 
his writing when I was in college.  He died at the age of 49 by suicide. 
  I always found that strange.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#54718

On Wed, 8 Feb 2017 05:13:38 -0500, rickman <gnuarm@gmail.com> wrote:

>A tribute to Richard Brautigan.  His birthday was last week.  I liked 
>his writing when I was in college.  He died at the age of 49 by suicide. 
>  I always found that strange.

Brautigan was always worth a read. However, you didn't need to
mention the suicide - an extremely selfish act. But see
  http://www.rollingstone.com/culture/features/the-life-and-death-of-richard-brautigan-19850411

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#54685

On 2/7/2017 5:01 AM, Stephen Pelc wrote:
> On Mon, 6 Feb 2017 06:46:00 -0800 (PST), Mark Wills
> <markwills1970@gmail.com> wrote:
>
>> "As for Forth, although it has dedicated advocates, it's
>> explicit stack orientation and its lack of modularity limit
>> the scale of Forth programs. One of the largest Forth efforts
>> was an integrated operating system called Valdocs (Valuable
>> Document System) on the Epson QX-10. The software remained buggy
>> couldn't be updated quickly enough for the machine to remain
>> competitive - although you could just as easilly blame the
>> computer's Z-80 processor (since at the time the 8088 based IBM PC
>> and 68000 based Apple Macintosh were being introduced) and difficulty
>> in finding experienced Forth programmers. Whatever the cause, this
>> soured the acceptance of Forth for large scale projects."
>>
>> http://www.cpushack.com/CPU/cpuAppendB.html#Forth
>
> I have met several of the Valdocs people. The critical problems
> with the project were project management problems. In any large
> project, project management is really, really important.
>
> To give an example of a current large Forth project that has
> evolved over 30 years, see the Candy system at
>   http://constructioncomputersoftware.com/
> which is currently built on VFX Forth for Windows. Candy consists
> of 55 Mb of source code in 1.2 million lines of code and generates
> an executable of 27 Mb. I always quote this one because I do a full
> rebuild before each VFX Forth release.
>
> For another Forth-based app, see
>   http://www.micross.co.uk/micross/tracknet/
> Nick Nelson has presented many EuroForth papers over the years.
>
> Leon from Forth Inc has presented several papers on PC projects
> in the last couple of years.
>
> We have many clients with embedded systems of over 500 kb in Flash.
>
> Success or failure of projects is mostly down to project management.
>
> Stephen
>
I worked for a company that wanted to rewrite a large project in 
assembly language  and they promoted an engineer to be Software Manager, 
a very bad idea. He hired several programmers right off school which in 
itself not the end but he allowed them a pretty much unsupervised run of 
the project a bad idea.

They tried to get me involved in the project and I had enough weight in 
the place that I could refuse, I could see the project was doomed, they 
would not listen to the advice of people that were familiar with the 
task at hand. After a year of flailing around the whole team was fired 
and the project was given to the last remaining engineers including 
myself, in less than three month we had the project working and ready to 
demo to customers.

The moral here is that bad management can can sink a ship faster than 
the Titanic, we used the same tools they had and got the job done.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#54737

There's a nice post on the Forth Programming Facebook page this morning about ValDocs, including a documentary video that followed the company to their first CES show. Seems like it was a very capable product. Just built on the wrong hardware. 

See here: http://m.electronicdesign.com/blog/rising-star

[toc] | [prev] | [next] | [standalone]

#54758

Mark Wills wrote:
> There's a nice post on the Forth Programming Facebook page this morning about ValDocs,
> including a documentary video that followed the company to their first CES show. Seems
> like it was a very capable product. Just built on the wrong hardware.
> ...

And too late.  This was 1984.  The IBM PC had already been out a couple years and
commercial interest in CP/M was falling.  What buyer was going to invest $1000's
in technology of the past.

[toc] | [prev] | [next] | [standalone]

#54761

On Thursday, February 9, 2017 at 4:31:11 PM UTC-7, HAA wrote:
> Mark Wills wrote:
> > There's a nice post on the Forth Programming Facebook page this morning about ValDocs,
> > including a documentary video that followed the company to their first CES show. Seems
> > like it was a very capable product. Just built on the wrong hardware.
> > ...
> 
> And too late.  This was 1984.  The IBM PC had already been out a couple years and
> commercial interest in CP/M was falling.  What buyer was going to invest $1000's
> in technology of the past.

The primary feature of the 8088 and MS-DOS was that it provided 640KB of memory --- the Commodore-64 with its 6510 was actually faster --- the 6502, Z80, etc. all suffered terribly from their 64KB limitation.

[toc] | [prev] | [standalone]

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

Back to top | Article view | comp.lang.forth

csiph-web