Re: IMO

[jmkasunich-at-ra.rockwell.com]

Ray wrote:

> 1 - Where to post Hardware Abstraction Layer stuff
>
> I like keeping the HAL thread with this group (emc-at-nist.gov
> subscribers) for a bit because it generated good discussion,
> sense of direction, and momentum recently.

Agreed, at least for now.  When this list becomes more of
a "users" list, the HAL stuff should move out.

> We need to dual post at least to the emc-developer list,
> 'cause that's where most of the code writers read.

I am reluctant to dual post, especially since my posts tend
to be long and boring.  But if that is the concensus, I'll
be happy to do it.

> 2 - Fork the sourceforge CVS to allow for HAL
>
> My thinking on this may be a bit different from John K's post.
> He suggested a couple of emcmots that both get compiled and
> then are selectable by an ini variable.

?? do you mean my comments to Craig about an emcmot that
disables the servo loops?  That was an aside, not really
related to the sourceforge fork issue at all.

> I believe that the move to abstraction layers will produce
> a much stronger, more flexible EMC.

I hope so ;-)

> I also believe that, for a while with this effort, near
> chaos will be our primary product.

Yes, hence the stable/development version suggestion.

> I am really excited about the changes that we will make
> but before we have  finished it we will have rethought
> everything that we do now.

> For example, Professor Hugh Jack posted a very kind report
> to the MatPLC list in which he described the discussion from
> EMC Monday.  One reply suggested that their work is very
> similar to the HAL that is being developed here and that
> the entire EMC could run as a module within their framework.

Can you post a link to an archive or something so we could
take a look?  I've been thinking of a PLC within EMC, but
EMC within a PLC is a fresh perspective that deserves some
thought, at least.

> I'd like to see us set aside a full CVS version of the
> current EMC before we begin to build in the range of
> changes that we outlined during EMC Monday.  This module
> should be compilable and runnable on the several platforms
> that we currently support.  It should be editable so that
> we can continue to fix bugs in it.  For a while, this will
> be the stable, BDI, and Sherline version.

Definitely!!

> Right now there are three CVS modules in the repository; emc,
> rcslib, and documents.  I propose that we freeze emc and add
> emc-hal.  Copy a reasonably full set of the current emc code
> into emc-hal and quickly hack up emc-hal so that it becomes
> our work in progress.  In spite of steep learning, we should
> start these hacks soon, small though they may be, so that we
> keep momentum.

Agreed, except for the name.  The HAL is only one part of what
we discussed at NAMES.  For example, Fred mentioned work in
progress to extract the real time OS dependant code to a
separate file, and define a generic API for those functions.
Perhaps emc-dev, for development version?  Or maybe emc-hack!

> 3 - Add a documents directory for HAL
>
> Add a HAL directory in the documents module to hold descriptive
> material for the new systems.  Eventually this kind of stuff
> should find it's way into the developer handbook.

There are actually two documentation tasks.  First, we have to
document how the existing EMC works.  Then we have to document
how we want the new EMC to work.  Only after we have decent
specs to we start coding.  We will want to continue updating
the docs in the stable branch, while defining specs in the
development branch.

> This will not be intended to replace the excellent web
> material that John K maintains but might archive it as
> he chooses.

I'd like to move my stuff to CVS and/or linuxcnc.org ASAP.
How do I do that?

I want to get back on the documentation project, but I want
to do it right.  That means Tex, or Lyx, or whatever.  I have
some setup to do.  My main PC up till now was running W95 (but
when I set it up, I set aside partitions for Linux).  After
NAMES, I installed Linux (using BDI 2.18) and now have a dual
boot system.  I've almost got internet connectivity working
on the Linux side, maybe this weekend.  Then I can copyout
the source for reference, and install whatever tools I need
to write docs in our language of choice.

> 4 - Add developers to EMC at sourceforge
>
> We need to widen the base of developers that have write access
> to the sourceforge repository.  Write access will allow all
> of us to collaborate on the documentation as well as the code.

Yes!  I'll take all the documentation help I can get.

> I approached my developer status with a great deal of fear
> that I'd make a complete fool of myself and destroy more
> than one persons good work.  My fears proved to be true.

Did you actually destroy other peoples work?  Or just look
foolish?  I'm willing to risk the latter, the former is scary.

> I do find that as I read a chunk of code and figure out
> what's going on, I can comment that chunk and put it back
> in the source for the benefit of others.

That's a great way to do the low-level documentation.  I've
been struggling with that issue.  Detached docs tend to get
neglected.  If the high level docs point to the source files,
interested parties can get the details from the comments.

5 - Fix Sourceforge Lists

> Right now there are four almost unused lists associated with
> the EMC at sourceforge.  They are;
>
> Developers (2 msgs)
> Help (5 msgs)
> Open Discussion (15 msgs)
> emc-developers (0 msgs)

Are we looking at the same place?

At http://sourceforge.net/projects/emc, I see three "public forums"
and one mailing list.

The mailing list is "emc-developers" with 192 messages (only 5 in
2003).  The forums are:

Help (5 msgs)
Open Discussion (15)
emc-developers (0)

> The last one, emc-developers, is where this note is also going.
> There are zero messages there because it is nothing more than a
> device to fan out messages sent to it to each member on the
> development team.

So the "emc-developers" forum is just a webby way to post to
the "emc-developers" mailing list?  I didn't know that.  I
joined the mailing list at:
http://lists.sourceforge.net/lists/listinfo/emc-developers

I strongly suggest that those who were involved in the NAMES
meeting and others who want to contribute should join the
developers list soon at the link above.  I don't want to keep
dual posting stuff like this to the "users" list.

> To start this we should designate a developer/administrator
> or someone willing to become one (do I see a hand raised?)
> to serve as a kind of lists mom for these.  No moderating
> here, just someone to keep up with sourceforge's list
> abilities and see that the settings for each list make it
> do what it is supposed to do.

> Then we need to cut the existing lists to two, emc-developers
> and emc-users.

The "public forums" should either link to the mailing lists or
dissappear.  I vote for "dissappear".  The mailing lists have
web accessible archives, so there is no need for a separate
forum to provide web access.  (You can't post to the "forums"
without having a sourceforge account anyway, might as well join
the mailing list instead.)

John Kasunich