Re: [Emc-developers] Link-time optimization in realtime objects

[schoone...@gmail.com]

On 16/08/19 13:04, Robert Ellenberg wrote:

Hi All,

Has anyone tried to use link-time optimization in the realtime object
builds? I think the motion / TP build would be a good candidate for it, so
we could improve inlining of things like posemath.

Best,
Rob



Hi Rob,

In an ideal world, the inline code in question should be inserted by the 
compiler,

removing the call and stack shuffling thus producing a faster binary.
What the compiler actually does sometimes differs.;-)

If the code is long, a couple of push/pops from the stack if negligible,
compared to the amount of binary code bloat you can get, sometimes at 
the expense
of code sitting nicely in processor cache ready to be instantly called 
again.


I think the only way to find out is to test it.
On the face of it, short functions, repeatedly used, should benefit from it.

Nothing in defining inlines should affect rt operation AFAIK,
we have shed loads of inlines and defined functions in the revised rtai 
/ hal code in Machinekit.
(mostly wrapper functions and accessors etc. to cater for both legacy 
code and the newer code)


cheers


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Building LinuxCNC on Debian 10

[schoone...@gmail.com]

>> There was talk of sourceview2 not being available - that is much 
more serious.


Yet again, just add it to your Buster repo for now, the sid version 
should work

https://packages.debian.org/search?keywords=python-gtksourceview2

The other problem with gmoccapy is python-gst.

AFAIR there is also a difference between python-gst-0.1 and 
python-gst1.0 in what

modules are actually contained in it.
Think this was why we had to disable audio in gmoccapy for Stretch and 
above in Machinekit.





___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Building LinuxCNC on Debian 10

[schoone...@gmail.com]

What is -vte used for?



https://packages.debian.org/search?keywords=python-vte



Suggests that is it still there in Sid.


Hi Andy

virtual terminal emulation

Buster is full of holes currently, where packages in sid have not been 
back-ported.

You should find that the kernel, gcc libc etc. versions mean that most sid 
packages will work with Buster
I have recently backported libck from sid to Buster in our own repo 
(Machinekit), since we use it for atomic operations, until Debian get their act 
together.

regards




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Merge Just One Commit Up

[schoone...@gmail.com]

On 04/06/19 13:05, emc-developers-requ...@lists.sourceforge.net wrote:

Date: Mon, 3 Jun 2019 14:45:28 -0500
From: John Thornton
To: EMC developers
Subject: [Emc-developers] Merge Just One Commit Up
Message-ID:<21236f20-9c1c-944e-ab39-bed182e41...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

How do you merge just your special commit from 2.7 to 2.8 to master?

I use git, git-gui, and gitkraken.

Thanks
JT

From whatever branch you want it included in:

git cherry-pick 


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[schoone...@gmail.com]

Hi Chris,

I actually approached it from the other direction.
What we required initially was a HAL only stack, it was only later that I
tried to get the CNC stack to build.

The repo's show what is in each stack so I won't detail that.
The process is largely just hard slog through the Makefiles, 
configure.ac etc

to eliminate what is not required for each stack.
Then doing it all again in debian/ to ensure the package is right.

Some things are quite easy and straightforward but there are some overlaps
between the stacks, both for instance use inifiles,
and in each case that overlapping file or lib resides in the HAL stack.

The big problem with packages, is that dpkg will not accept a single 
file duplication

between two packages, even if it is identical.
If package A contains file1 and so does package B, when package B is 
installed dpkg

will refuse to overwrite file1 and the install fails.

Therefore the CNC stack, does not contain a lot of the very files it 
needs to build or run.

I got around this with some trickery in the Jenkins / Docker builder.
It first builds machinekit-hal, then copies a preset list of headers and 
libs to two
directories called 'fakelib' and 'fakeinclude', which whilst in the 
build path are not in the
debian install specs and the contents are just there to facilitate the 
build.


Therefore the CNC stack is completely reliant upon libs which are part 
of the HAL stack

and only does anything when combined with it.

It does however remove a lot of the clutter and hopefully make it easier 
for someone in future
to play with 'drop in' interpreters, replacing NML and many of the 
things it could really do with.


The HAL stack has the gladevcp / pyvcp elements.
Whilst you could argue that they are largely used with Axis say, a 
standalone panel is in fact

very useful when using HAL on its own.

Realistically it matters not, anything that could be of use is in the 
HAL stack and as the CNC stack

can only be used with the HAL stack, it will have access to it too.

regards

Mick

From: Chris Morley

Mick

Thanks for joining in.

I should point out that this idea was formed and brought up me me alone.

There has been no internal discussion in linuxcnc.


That was the point of this - to gauge interest and see if there are immediate 
road blocks,

such as license, philosophy, or complete lack of interest.


I personally don't have the technical programming skill to understand how to do 
this.

If the work is mostly mechanical - I can be helpful.

I would guess that a lot of it is mechanical - particularly since you guys 
support legacy components.


I am hoping some more linuxcnc developers chime in their opinions - good or bad.


Could you summarizer what was required to breakout the cnc stack from the HAL 
stack?


Thank you

Chris M



___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[schoone...@gmail.com]

Hi Steve

The main problem is probably your OS
We only support Debian and the package dependencies are based upon what 
is in the Debian repos.


Ubuntu tends to just do whatever it likes and wants to 'Ubuntuise' 
everything.

There is a reason why the linuxcnc distro image is also Debian based.

The czmq / zmq libraries are a particular problem because they were changed
to a new version that is backwardly incompatible with the old one by the 
zmq project.


At great trouble we ported our code to the new API, to enable Machinekit 
to run on later

versions of debian where it is the default.

The new libs are now backported by Debian as far back as Jessie thankfully.
The version requirements are to get the correct ones from Debian repos.

If you install Debian Jessie / Stretch (even Buster if you use my repo), 
it will just work.


The docs clearly state "You should first have a working Debian installation"
http://www.machinekit.io/docs/getting-started/getting-started-platform/

Hope that clarifies


On 09/09/18 16:06, Steve Better wrote:

Hi Schooner,

Glad you are here!

I tried to install Machinekit-HAL today. My OS is Ubuntu 16.04. After
I installed libczmq-dev with apt-get, I just cannot continue
successfully with the following error:

"Requested 'libczmq > 4.0' but version of libczmq is 3.0.2"

This is not friendly to attract more people to participate in this project.

I think the Machinekit project and the LinuxCNC project need to be more
visionary. Not just in the software aspect, but also in the motion
control aspect. We need more advanced technologies these days to control
a manipulator or a mobile robot. OROCOS and ROS is still not very
successful in practice, and maybe they won't get there ever.
Well, young people are attracted by mobile internet and AI, the CNC
technology seems to be old since the EMC emerging in 1990s. We need
modern visions like OROCOS and ROS to push this project further.


On 09/09/2018 06:27 PM, schoone...@gmail.com wrote:

Hi Chris,

As my paws are all over a lot of the work you are mentioning
(multicore in collaboration with Michael Haberler some years back)
and the splitting into HAL and CNC stacks, why not contact me direct
to discuss.

I think there is scope for collaboration which could be to both our
projects
benefit, not least from a reduction in maintenance.

The multicore work you mention, primarily adds atomic operations and
other measures
to prevent things like the side effects of multi core, multi cache
operations, where values can be updated
by one cache before another has finished.

Machinekit's HAL generally has hugely diversified from the original
linuxcnc, instantiated components for instance
which can be added or removed at any time, even in a running system.
Because of backwardly compatible measures however, its use is not
visibly greatly different.

The splitting out of HAL, not only allows the stack to be used for non
CNC projects, such as ROS,
but is arranged so that installing machinekit-cnc on top of
machinekit-hal, brings you back to a fully functioning machinekit again.

We are contemplating moving to a 2 package installation and
deprecating the original machinekit repo and packages.

If you were to split out your CNC stack, which has some features we do
not have,
with the correct tweaks it could even sit on our HAL stack and result
in a fully functioning
CNC controller again.

Unfortunately we have not replaced NML with zmq, that would be the
'holy grail'.
Michael Haberler and Alex's protobuf message headers and zmq
(machinetalk) would probably be the way to go there

It is something we would be interested in discussing, I am sure.

regards

Mick
On 09/09/18 01:27, emc-developers-requ...@lists.sourceforge.net wrote:

From: Chris Morley
To: EMC DEV
Subject: [Emc-developers] Breakout of HAL/ machinekits's HAL
Message-ID:
 



Content-Type: text/plain; charset="iso-8859-1"

I see that machinekit has broken out HAL and cnc (Well and lots of
others) into different repositories.

https://github.com/machinekit

[https://avatars1.githubusercontent.com/u/6759549?s=280=4]<https://github.com/machinekit>


machinekit ? GitHub<https://github.com/machinekit>
github.com
GitHub is where people build software. More than 28 million people
use GitHub to discover, fork, and contribute to over 85 million
projects.

It also seems they have updated HAL considerably,

They were working on RT multicore support, anytime instantiation of
HAL components

cython support.. probably other stuff - I'm not sure if it includes
ARM or FPGA upgrades.


I was thinking that maybe linuxcnc should discuss if that is
something that would be of interested.


pros I see:

-chance to break HAL out of cnc stack

-seemingly an upgrade in capability

-someone else has done a lot of work/testing already

-might allow more cross work of developers between the projects


cons:

-surely a lot of work to incorporate (though it does suppo

Re: [Emc-developers] Breakout of HAL/ machinekits's HAL

[schoone...@gmail.com]

Hi Chris,

As my paws are all over a lot of the work you are mentioning (multicore 
in collaboration with Michael Haberler some years back)
and the splitting into HAL and CNC stacks, why not contact me direct to 
discuss.


I think there is scope for collaboration which could be to both our projects
benefit, not least from a reduction in maintenance.

The multicore work you mention, primarily adds atomic operations and 
other measures
to prevent things like the side effects of multi core, multi cache 
operations, where values can be updated

by one cache before another has finished.

Machinekit's HAL generally has hugely diversified from the original 
linuxcnc, instantiated components for instance

which can be added or removed at any time, even in a running system.
Because of backwardly compatible measures however, its use is not 
visibly greatly different.


The splitting out of HAL, not only allows the stack to be used for non 
CNC projects, such as ROS,
but is arranged so that installing machinekit-cnc on top of 
machinekit-hal, brings you back to a fully functioning machinekit again.


We are contemplating moving to a 2 package installation and deprecating 
the original machinekit repo and packages.


If you were to split out your CNC stack, which has some features we do 
not have,
with the correct tweaks it could even sit on our HAL stack and result in 
a fully functioning

CNC controller again.

Unfortunately we have not replaced NML with zmq, that would be the 'holy 
grail'.
Michael Haberler and Alex's protobuf message headers and zmq 
(machinetalk) would probably be the way to go there


It is something we would be interested in discussing, I am sure.

regards

Mick
On 09/09/18 01:27, emc-developers-requ...@lists.sourceforge.net wrote:

From: Chris Morley
To: EMC DEV
Subject: [Emc-developers] Breakout of HAL/ machinekits's HAL
Message-ID:



Content-Type: text/plain; charset="iso-8859-1"

I see that machinekit has broken out HAL and cnc (Well and lots of others) into 
different repositories.

https://github.com/machinekit

[https://avatars1.githubusercontent.com/u/6759549?s=280=4]

machinekit ? GitHub
github.com
GitHub is where people build software. More than 28 million people use GitHub 
to discover, fork, and contribute to over 85 million projects.

It also seems they have updated HAL considerably,

They were working on RT multicore support, anytime instantiation of HAL 
components

cython support.. probably other stuff - I'm not sure if it includes ARM or FPGA 
upgrades.


I was thinking that maybe linuxcnc should discuss if that is something that 
would be of interested.


pros I see:

-chance to break HAL out of cnc stack

-seemingly an upgrade in capability

-someone else has done a lot of work/testing already

-might allow more cross work of developers between the projects


cons:

-surely a lot of work to incorporate (though it does support legacy code, if I 
understand right)

-lack of experience with concepts/code - will take time to become comfortable

-we'd have to admit they are not bad people:)


Ok that last one was meant as fun.


There are very smart and hard working people on both projects, it would be nice 
to benefit both

projects.


I have not really looked at the code, nor am qualified to give indepth opinion 
of the code.

I have watched the video of the multicore idea.

https://www.youtube.com/watch?v=brT0bEkJLSY

There are more videos (including one about the trajectory planner that we now 
use)


Thoughts?


Chris M




___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers