Re: IMO

[Ray Henry <rehenry-at-up.net>]

John

Sorry to take so long to get back to you on this.  I feel like someone turned 
the treadmill up to max and I'm falling behind.  (comments mixed in)


On Thursday 08 May 2003 12:59 pm, you wrote:
> 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.

I think that we got their attention.  Once we sort out the list stuff this 
should resolve itself.

> > 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.

Good.  We'll get started on the new module.  I think that I saw you come up 
as a developer now so you can generate a local copy of the repository and 
begin to work to your hearts content.

> > 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!

True, and I was in and out of the meeting doing my facilitating thing.  Id be 
happy with emc-dev for the new, unstable module.

> > 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?

Now that you are a developer you are able.  It will only require a bit of cvs 
code once you have your copy of the repository.

I'll attempt a cleanup of the documents module over the weekend.  Let me 
clean out the old handbook stuff from temp_html and you can commit it there.

> 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.

The TNG version is what I use to connect with SF here.  The lyx tools are in 
it and ready to go.  The ssh and ssh-keygen were trivial with it.  
Sourceforge even remembers me now so that the only time I need my password is 
to work with the CVS.

> > 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.

Will doesn't even remember so I could lie and get away with it.  I think he 
had to move back a version in a couple of files.  CVS is the greatest thing 
because it keeps a history.

> > 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.

Both Matt and I have been raised to developer status so some of these 
housekeeping details can be handled without interrupting the serious code 
writers.

> 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

Good.  Others interested in the remodel should do the same.

> 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.)

Yep!  I think that we can do this.  Then we'll create the emc-users
http://lists.sourceforge.net/lists/listinfo/emc-users and move folk over.

Ray