[PicForth] Installation, test, refine & BIG picture.

[easlab at absamail.co.za]

> >>JC> What's the scope of work involved in porting PicForth to gforth
> >>JC> 0.6.2?
> 
> > ----- some answer s/opinions snipped---
> 
> This point was primarily brought up because anyone installing gforth is 
> naturally going to install the latest version, particularly if a site 
> uses package management tools like apt-get, emerge, or RPMs.  For my 
> personal machines, it pretty much doesn't matter.  However, I had some 
> users ask about gforth for another project on a server I run, and while 
> they can use --prefix to install locally, they can't replace the 
> /usr/bin copy.
> 
Yes, I too fell into that hole.
OTOH it's not justified for picforth to 'track' gforth, but probably,
the install instructions should have the 'warning' written
 !!!**** BIG****!!! to avoid the mistake of installing the 
latest version ?

> >>JC> Next, what about supporting the PIC16F8620 parts?

Have you tested the existing facilities ?
I strongly believe in the 'hello world', ie. successive refinement approach.
OTOH I've read that the 'old pics' are becoming less available and more
expensive ?   Personally I'm not impressed with the trend to start making
good wheel-barrows, and then 'upgrading' them to Ferraris.  If one 
needs such fancy hardware facilities, then why not use a 'proper 
instruction set' device.

Samuel Tardieu wrote:
> >>Porting to a new platform with the same instruction set ought to be
> >>very easy. Probably only constant definitions and such. You can look
> >>at pic16f88.inc to get a taste of what it takes.
> 
> >It's all about getting the maximum results with the available resources.
> >Division of labour is a big factor.  
> >   This is usually understood and not discussed.
> >Of course if your a school teacher, you're looking for tasks to keep the
> >kiddies busy.
> 
> I think we're all capable of understand "division of labour".  ....

Apparently not.    This observation is not directed to you.
And I want YOUR project to succeed, so that you can contribute to 
the list for MY benefit.

IMObservation, so far this list has failed 'to build a set of working
projects' ?
Division of labour means that although the initial work is excellent,
the attributes needed to  'move the list along' in the sense that
collaborators with a different experience and knowledge set can
also benefit and even contribute; are missing.

My experience/observations of picforthList:-
*  I started before the list existed or [I suspect] ANY outside 
  collaborators existed.
* I made the mistake of trying 'the latest' gforth.
* I got some help/advice from the author of gforth from the forth
    NewsGroup.
* I started doing a graduated set of tests [these should exist for new
     users - I'll contribute my results] to both test picforth, and the 
    following stages until a programmed device is testable.
    And to help build some familiarity with forth syntax.
* I found and described a minor [unlikely to be encountered] error
      which Samuel Tardieu fixed.
*  The initation of the mailing-list would have facilitated the 
    expansioin of collaborators, except that the leader won't/can't
    handle trivial queries appropriately.   Real life projects fail due to
   apparent trivialities [the weather was a vital factor in not waiting
   to 'solve' Iraq].   I'm not familiar with linux [nor should I have to be
  - my prefered OS/language is oberon] so I didn't know how to scroll
    the screen up to see the vital data.   Picforth's 'leader' couldn't
    or wouldn't tell me how to.  Since I have vast experience with 
    collaborative mailingLists, I know what IS possible. So I just put
    my project on hold.
*   If the mailingLists, can get a critical mass, so that 'other' contributors
    can answer the non-specialised questions, and we can build test 
   data etc. to help beginners, then perhaps Samuel Tardieu can just  
   occasionally be burdened by specialist tasks.

That's what division of labour means.

> The makefile refers to dcc2.  dcc2.fs does not exist, so the make aborts.
> Makefile attempts to change into the ./doc directory, which does not 
> exist.
> There appears to be a missing Makefile that belongs in ./doc
> 
>  gforth picforth.fs -e 'host picquit' does indeed drop one into an 
> interactive shell.  It should probably be noted for the benefit of 
> inexperienced users poking around that once in the shell, you need to do 
> 'include myfile.fs' before the various interactive words (see, map, dis, 
> words) generate any output.

As noted, I'm no expert with linux, but I've made log-notes of my 
installation steps, which did succeed.   Have you got it running yet ?

What programmer do/will you use ?
My programmer is DOS based, so I tried to use dosemu, instead of
having to transfer data to a dos-box.  [one wants a rapid turn around,
to make many small steps towards the goal].  Dosemu is a bit of
a 'can of worms' and I couldn't get it to drive the par-port.

I'd like to restart my project if there were other collaborators
to make a team with the required COMBINED skills.

Thanks,

 == Chris Glur.