Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #54673 > unrolled thread
| Started by | Mark Wills <markwills1970@gmail.com> |
|---|---|
| First post | 2017-02-06 06:46 -0800 |
| Last post | 2017-02-09 17:22 -0800 |
| Articles | 20 on this page of 100 — 19 participants |
Back to article view | Back to comp.lang.forth
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]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-02-10 11:07 +0000 |
| Subject | Static type checking (was: Really?) |
| Message-ID | <2017Feb10.120729@mips.complang.tuwien.ac.at> |
| In reply to | #54759 |
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]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-02-11 15:16 +0000 |
| Message-ID | <2017Feb11.161604@mips.complang.tuwien.ac.at> |
| In reply to | #54751 |
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]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-02-11 10:20 -0600 |
| Message-ID | <o7ndhg$lsi$1@dont-email.me> |
| In reply to | #54791 |
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]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-02-11 19:02 -0800 |
| Message-ID | <d883d712-c45e-4bed-b4a8-feba59cdff64@googlegroups.com> |
| In reply to | #54791 |
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]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-02-10 17:31 +0100 |
| Message-ID | <o7kpsg$ep2$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #54750 |
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]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-02-08 15:34 -1000 |
| Message-ID | <P7OdnVrbyIO1WgbFnZ2dnUU7-Y2dnZ2d@supernews.com> |
| In reply to | #54711 |
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]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2017-02-07 21:15 -1000 |
| Message-ID | <08idnax6OtEYWAfFnZ2dnUU7-b3NnZ2d@supernews.com> |
| In reply to | #54703 |
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]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-02-07 23:46 -0800 |
| Message-ID | <87bmudw2ek.fsf@nightsong.com> |
| In reply to | #54703 |
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]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-02-07 22:47 -0800 |
| Message-ID | <2a41e59d-863d-4034-9888-d93ddfcc54b8@googlegroups.com> |
| In reply to | #54691 |
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]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2017-02-08 08:52 +0200 |
| Message-ID | <o7ef44$u25$1@dont-email.me> |
| In reply to | #54702 |
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]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-07 06:29 -0500 |
| Message-ID | <o7cavk$tio$1@dont-email.me> |
| In reply to | #54682 |
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]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-02-07 20:47 +0000 |
| Message-ID | <589a3147.422395951@news.eternal-september.org> |
| In reply to | #54684 |
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]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-07 16:23 -0500 |
| Message-ID | <o7ddog$b4o$1@dont-email.me> |
| In reply to | #54692 |
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]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-02-08 09:47 +0000 |
| Message-ID | <589ae812.469190510@news.eternal-september.org> |
| In reply to | #54696 |
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]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-08 05:13 -0500 |
| Message-ID | <o7eqt8$va1$1@dont-email.me> |
| In reply to | #54714 |
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]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2017-02-08 11:23 +0000 |
| Message-ID | <589afb16.474058583@news.eternal-september.org> |
| In reply to | #54715 |
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]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2017-02-07 09:49 -0600 |
| Message-ID | <o7cq6n$pua$1@dont-email.me> |
| In reply to | #54682 |
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]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-02-09 00:30 -0800 |
| Message-ID | <e13f7f62-c271-4ead-a684-8630cbd08479@googlegroups.com> |
| In reply to | #54673 |
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]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2017-02-10 10:32 +1100 |
| Message-ID | <o7iu3r$11nt$1@gioia.aioe.org> |
| In reply to | #54737 |
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]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-02-09 17:22 -0800 |
| Message-ID | <48d32131-38dd-408d-9e13-591ff6be3d0b@googlegroups.com> |
| In reply to | #54758 |
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