On Thu, 2012-08-09 at 09:10 +0200, Michael Haberler wrote:
> Chris,
> Am 09.08.2012 um 06:00 schrieb Chris Morley:
> ..
> > While a lot of the details are over my head the ideas your talking about
> > are important.
> > We are not so good at long time planning in linuxcnc but it has seemed to
> > work up to this point never-the-less.
> >
> > I see a few things coming in the nearish future that may put us in a
> > position of considering developing
> > a new version.
> > licensing is a bit of a mess right now - which limits who will use/develop
> > use if there is legal questions of use/distribution.
> > GTK3 is going to be a requirement especially if we want to stay current
> > with GLADE.
> > I see that pygtk is not going to be developed further, pyobject is the new
> > direction.
> > There is interest in deeper changes in linuxcnc, but I think it is quite
> > impenetrable, Michael being the real driving force
> > for new features, basically I think because he has spent the time to
> > understand it the best (and is interested).
> >
> > May be at the point that a lot of code needs to be updated for the new
> > libraries (which I realize doesn't need to happen
> > right away) we might want to consider a rewrite to fix our licensing
> > inconsistencies and limitations of current structure.
> >
> > By writing a new version there are no pressure to get it done right away,
> > the current version could continue.
> >
> > I am wondering if its a case of 'start to build it and they will come' - to
> > help develop it :)
> > I guess the first thing to do is list what the goals are to see if it is
> > worth the trouble to get there.
> >
> > Enjoying the discussion...
> > Chris M.
> linking a rewrite of LinuxCNC ("LinuxCNC3") and a licensing cleanup is an
> interesting idea, and I think worth exploring in more detail.
>
> I dont have a suggestion for a future license yet, but assume we had one
> (lets call it v3license) and it would enable bringing in other key components
> more easily.
>
> I need to think this through, but my first take on a greenfield approach to
> V3 would be:
>
> 1. carrying forward HAL and RTAPI, all the HAL components, motion, comp, the
> sim/rt environment to v3license would be key.
> 2. dropping NML/RCS completely and replacing it with zeromq and a
> protobuf-based messaging and language bindings will be a huge relief
> (eventually - post learning curve, but it will). It's just messaging, RPC,
> and an error queue, plus serialisation - thats all, and these themes are well
> covered.
> 3. HAL needs a bit of a brushup to be tied into the new messaging, but that
> should be forward compatible.
> 4. interpreter: I'd say the current *structure* had its day (NB: I dont mean
> cradek's work) and it would be fair to reconsider whether C++ is actually
> needed or one could go to, say, a Python-based interpreter to start with; if
> C++ were the decision, I would consider Joseph Coffland's OpenSCAM
> interpreter code as an alternative to port to.
> 5. It would be a great point to start work on the revamped structure
> (interpreter more closely tied into motion) I discussed with Chris. For that,
> cutting loose from the existing NLM framework would actually be a benefit.
> Probably a block-based interface would be better than carrying forward canon
> as a public API.
> 6. task: given a proper messaging API binding I see no good reason to retain
> C++ here, replacing by Python is fine IMO
> 7. GUI's: porting forward GladeVCP to GTK3 and pyGobject would be clearly a
> milestone. I love Axis, but I dont quite see how it can realistically be
> forward-ported.
> 8. Language and toolkit plethora: I'd suggest to not carry forward
> TCL/Tk/TkInter use.
> 9. emcsh, emcrsh, halrmt & friends: happy to let these go and replace by a
> Python API to start with - they'd be heavily affected by 2) and no point in
> keeping C++ for that.
> 10. It would be the opportunity to slide in Redis as a persistent key/value
> store (not just tool table, for istance machine state - parameters - too,
> probably config)
> 11. The coding creep towards a 'single PC does it all' model should be
> revisited - I dont like it at all.
>
> ---
>
> 1) is the dealbreaker IMO - redoing the HAL, RTAPI, component infrastructure
> basically for license purposes is out of reach IMO. Is that doable?
>
> Assume this can be achieved, a first great milestone would be to have the
> brushed-up gladevcp run a HAL-only application; maybe low-level talk to
> motion through a revamped API (Python). Actually I think LinuxCNC kindof
> 'misses a market' - I see use for HAL-only applications with GUI.
>
> Then, go from there filling in parts - messaging infrastructure, task,
> interpreter.
>
> whale of a plan.. this will years of coexistence of v2 and v3. But I agree it
> is time to consider that cut.
>
> - Michael
Hi all,
As a longtime user(1) I'm going to butt in here. My main worry is that
this will break most of the GUI's. I use TkEmc and Mini most of the
time. As a user I'm not going to complain as long as things "just
work".
Interp and motion need to modular enough to one can drop in a new or
different interp; here I'm thinking about 4-5 axis vector programming
and there will be other things that are useful or just passing fads.
Planning for non-intel cpu's seems essential as does communication with
the HML via a network as that seems easier than implementing a specific
new protocol just to drive the HML.
I like the idea of setting up a flat screen/mouse/keyboard and having it
stay static even though the underlying motion stuff changes.
Discussion is good and appreciated.
Dave
(1) Jon shipped me ppmc #1 in early Jan 2000. :-)
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
