[Emc-developers] Leaving my roles in LinuxCNC

[Jeff Epler]

It's been a long time since I actively participated in this project and
I want to let you all know that I have begun to remove myself from roles
in various places including sourceforge & github. I'm in private
discussions to ensure this happens without disrupting the project.

To the developers & community: Thank you so much for letting me play a
part in this project. It was an important chapter of my life (that
started around 20 years ago!) and I wish you all the best for the
future. I hope and trust you'll continue to take this project in good
directions. I wish you all the best.

Note: Please send any replies privately to jepler AT gmail.com. This
address is no longer regularly monitored for messages and I will
unsubscribe from the lists after this message goes out.

Jeff


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

Re: [Emc-developers] Broken master 06jan23

[Jeff Epler]

Thank you all for the discussion.

I merged #2251, closed #2250, and in a moment I'll "unlock" the master
branch.

Take care,
Jeff


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

Re: [Emc-developers] Broken master 06jan23

[Jeff Epler]

[Chris requested that I explicitly respond to each part of his message.
I will do so even though I have little that is constructive to add]

On Sun, Jan 08, 2023 at 04:06:07AM +, Chris Morley wrote:
> Why would we change to 'main' ?
> How does the name change fix merge problems?
> It does create doc and web reference problems.

In the long run, it's better to match standard github practice. However,
I agree that we need not do this right now. It just seemed like a nice hack
to avoid re-winding the master branch while still removing the bad merge
from project history.

> I disagree with having to use pull requests for devs. (if I understood that 
> right)
> We already have problems getting pull request reviewed and aproved.

I will not change this without consensus.

In the long run, though, successful projects are able to review and
merge (or, when necessary, reject) pull requests in a timely fashion. In
this respect, our project's health is poor.

I think that the way that "core developers" can simply ignore the pull
request process if they choose to do so contributes to this. These core
developers can both bypass this speed bump if they choose, and ignore
pull requests from others even where their expertise can accelerate the
PR's inclusion.

In other projects where I participate (incuding my work, which is all
public on github) working via pull request is the default.  It works
well, and by numbers I believe that most PRs come from external
contributors but admittedly "the it works" depends on having ~4.5 paid
FTEs on the project.  A small number of reviewers are able to make short
work of most PRs, especially when there's a culture of doing it. I spend
maybe 5% of my time reviewing PRs, while some of my colleagues probably
spend substantially more.

(And FWIW thanks for the work you did reviewing PRs over the last year,
I see you commented on or reviewed more than a few)

However, it's impossible to single-handedly establish such a culture
when a different culture is entrenched. The project would have to want
to change.

> These things seem like radical responses to an uncomon mistake.
> This will be only be the second time in about 15 years something like this 
> happened.

You're right, in that I would like to use this as an opportunity to move
the project in a direction I think is good. The term "radical" is
charged, of course. From my point of view, I'm promoting styles of
working that are what I do everyday and which I perceive as working
well.

> If you want to talk merge strategies see my other maillist talk.
> The jest of is - why merge released branches into master at all.

As my colleague said, the idea to end the project's long-standing policy
of merging from stable to main seems like a "radical [response] to an
uncomon mistake."

I do not require a response to any of these points.

Jeff


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

Re: [Emc-developers] Broken master 06jan23

[Jeff Epler]

On Sun, Jan 08, 2023 at 04:06:07AM +, Chris Morley wrote:
> AFAICT the code (I didn't look at the docs mind you) is fixed.
> What is actually broken in master now?
> What are we trying to fix? The history?

Content of changes in 2.9 were discarded, instead of being added to
master. This includes documentation fixes. I hope you will respect that
just like code changes, documentation changes are valuable contributions
to this project.

For a list of changes between master and jepler/alternate-bad-merge-fix
see https://gist.github.com/jepler/86390ab9be17babf0349a1a8c5198e2e --
these represent changes in 2.9 that were NOT taken by the bad merge
commit but probably should have been.

The majority are documentation changes (which does not mean they are
lower value than code changes). That said, a lot of code changes were
discarded too.  For instance, an entire config is missing.  As far as
source code goes it looks like bugfixes to gremlin, qtvcp, and others
are missing.  To get an idea this "git diff --stat" summary of
differences in lib/ src/ bin/ and scripts/ provides an overview:

 lib/python/glnav.py |   4 +-
 lib/python/qtvcp/qt_pstat.py|   5 +-
 .../qtvcp/widgets/camview_widget.py |   4 +-
 lib/python/qtvcp/widgets/round_gauge.py |  13 +-
 .../qtvcp/widgets/round_progress.py |   2 +-
 lib/python/vismach.py   |   2 +-
 scripts/linuxcnc.in |   4 +-
 src/Makefile|   3 +-
 src/emc/canterp/Submakefile |  16 +-
 src/emc/rs274ngc/interp_base.cc |  29 +-
 src/emc/task/emctask.cc |   4 +
 .../axis/extensions/emcmodule.cc|  22 +-
 src/emc/usr_intf/gmoccapy/getiniinfo.py |  12 +
 .../usr_intf/gmoccapy/gmoccapy.glade| 255 +
 src/emc/usr_intf/gmoccapy/gmoccapy.py   |  76 +++-
 .../usr_intf/gmoccapy/notification.py   |   7 +-
 .../usr_intf/gmoccapy/release_notes.txt |  14 +-
 src/hal/components/axistest.comp|   2 +-
 src/hal/components/bldc.comp| 161 -
 src/hal/components/feedcomp.comp|   6 +-
 src/hal/components/gantry.comp  |  34 +-
 src/hal/components/lut5.comp|  14 +-
 src/hal/components/moveoff.comp | 146 
 src/hal/components/multiswitch.comp |   7 +-
 src/hal/components/panelui.c|   2 +-
 src/hal/components/plasmac.comp |  10 +-
 src/hal/components/spindle.comp |  84 ++---
 src/hal/components/xyzab_tdr_kins.comp  | 257 ++
 src/hal/user_comps/vismach/Submakefile  |   3 +-
 .../user_comps/vismach/xyzab-tdr-gui.py | 225 
 src/libnml/os_intf/_sem.c   |   2 +-
 src/rtapi/uspace_rtapi_app.cc   |   4 +-

Jeff


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

Re: [Emc-developers] Broken master 06jan23

[Jeff Epler]

Thanks for speaking up about the problem as soon as you realized it.
I have temporarily locked the "master" branch on github until this
problem is resolved.

I understand that the idea of force-pushing master to 1d836df^ before
the problem was discussed and dismissed (on IRC?). I did not see this
discussion.

Seb and I have each prepared PRs that approach fixing the problem. I
have a third, non-pull-request suggestion.

https://github.com/LinuxCNC/linuxcnc/pull/2250 --

Seb re-cherry-picks work from 2.9, excluding doc work that did not apply
cleanly. This would mean the doc work is lost from master if nobody else
steps up to cherry-pick and pull request the changes to master too:

https://github.com/LinuxCNC/linuxcnc/pull/2251 --
I merge 2.9 into 1d836df^ (git notation for "the commit before 1d836df),
doing my best to take the better side of each conflict in the
documentation (usually it was pretty clear; a total of 4 files had
conflicts), then merge 1d836df with the "ours" strategy (to effectively
discard its version of the changes), and then cherry-pick commits
subsequent to 1d836df, only one of which introduced changes.  This
hopefully catches the majority of doc work, but I merely selected one
side or the other of the doc changes, rather than carefully merging them
word by word.


The third suggestion is to use this as the moment to adopt the github
standard "main" branch name, instead of the deprecated branch name
"master". I would prepare a new branch similar to #2251, but NOT merge
1d836df in it, and push this as "main".


Besides fixing things in one of these ways, I think we should strongly
consider using github "branch protection", so that any change to main
and a "branch that looks like a version number" must go through the pull
request process.  This doesn't catch all problems, and it would require
folks to step up as pull request reviewers, but it might have avoided
this problem.


I'll check back on this thread as well as the developers IRC channel to
see if a consensus develops and then implement it.  Because this is
blocking ongoing work it's problably better to resolve it in a timely
fashion than to spend a long time figuring out the best possible
resolution.

It sounds like Seb is not available for the rest of the week-end fwiw.

Jeff


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

Re: [Emc-developers] Is it still possible to build RTAI debs?

[Jeff Epler]

On Tue, Jun 28, 2022 at 09:40:27PM +0100, andy pugh wrote:
> On Tue, 28 Jun 2022 at 13:49, Jeff Epler  wrote:
> 
> > Personally, I'd hoped the path forward would be using rtai realtime from
> > uspace.  It means LinuxCNC doesn't require any kernel modules, but
> > rather it can run on any Preempt-RT kernel and also any RTAI kernel
> > whose userspace API is compatible with the rtai-config script that was
> > found at configure time.
> 
> That seems like it can work, in that compiling uspace on the rtai
> kernel works, and says "using LXRT realtime"

Coool!  how's the latency in this configuration?

Jeff


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

Re: [Emc-developers] Is it still possible to build RTAI debs?

[Jeff Epler]

On Tue, Jun 28, 2022 at 01:04:29AM +0100, andy pugh wrote:
> Trying to address a recent request to add latency-histogram to the
> menu, I have attempted to build a .deb
> 
> But my previous recipe (./debian/configure -r ) no longer works.
> 
> All my test machines (at the moment) are running an RTAI kernel.
> 
> Have we actually abandoned support for this whilst I was not looking?

Yes, I made a commit to remove kernel-rtai and xenomai support from
debian/configure. I think that subsequent to mailing this you also
re-found the PR where this was discussed at the time:
https://github.com/LinuxCNC/linuxcnc/pull/1175
You stated your preference at the time to not make the change and I
didn't listen. I apologize, because I should not have acted so
unilaterally, and regret the extra work it's creating for you now.

I don't mind if it is re-added. A problem is, the low% chance of the
runtests failing end up leaving the buildbot broken for hours/days and
require seb's intervention each time. But if buildbot doesn't test it,
then it'll end up bitrotted anyway.

Personally, I'd hoped the path forward would be using rtai realtime from
uspace.  It means LinuxCNC doesn't require any kernel modules, but
rather it can run on any Preempt-RT kernel and also any RTAI kernel
whose userspace API is compatible with the rtai-config script that was
found at configure time.

It's preferable to kernel-mode RTAI because there are no LinuxCNC kernel
modules and no extremely weird math library tricks for using math
functions and floating point inside the kernel.

Since the RTAI problems (which did affect my real system, not just
virtualized buildbot systems) occur when unloading rtai kernel modules,
an interesting fact about the lxrt approach is that it should not be
necessary to ever un-load the rtai modules after they are loaded, though
this is probably what the halrun/realtime code still does.

I wrote this and lightly tested it years ago, but it is far from ready
for actual use, due to lack of actual use. And of course I'm not able to
commit to working on it even if people bring me excellent bug reports.

It looks like configuring `--with-realtime=uspace` should try to pick up
rtai-config from standard locations, but of course this is likely to be
all bitrotted as well. I have no way to test from here, as I have no
RTAI systems.

Jeff


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

Re: [Emc-developers] New Users Blocked

[Jeff Epler]

No, there is not an account on joomlapolis. Previously, it has always
been possible to update without one, but there have long been signs that
they were moving in this direction.

I'm not able at the moment to do anything related to the forum, so I
hope y'all can work it out.

Jeff


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

[Emc-developers] Bug#1012789: Can you check if Img works at all?

[Jeff Epler]

Thanks for tryting LinuxCNC on aarch64. I don't know of anyone presently
using such a configuration.

As far as the "undefined symbol" message:

Please check whether in "wish", it works to "package require Img" or
whether the same error occurs. If it's the same error then may point to a
general problem between libtk-img and libtiff.

As far as the "LIBGL: Error while gathering supported extension
(eglInitialize: EGL_BAD_DISPLAY), default to none" message:

Most UIs for LinuxCNC require working OpenGL. You can try a different UI
such as tklinuxcnc, it doesn't use OpenGL and probably also doesn't use
Img. However, it's much less friendly (IMO)

Jeff

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

Re: [Emc-developers] linuxcnc is marked for autoremoval from testing

[Jeff Epler]

This (and the notice for mesaflash) appear to be in error.  See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011268

Jeff


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

Re: [Emc-developers] building/running linuxcnc from source question

[Jeff Epler]

I have a potential fix at https://github.com/LinuxCNC/linuxcnc/pull/1275

Jeff


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

[Emc-developers] Archiving git repositories without recent activity

[Jeff Epler]

I think we should consider archiving some git repositories under the
linuxcnc organization that are unlikely to see further development:

https://github.com/LinuxCNC/stretch-live-build (last activity: 2019)
https://github.com/LinuxCNC/live-wrapper (last activity: 2018)
https://github.com/LinuxCNC/wizards (last activity: 2017)

Archiving is a reversible process that disables issues and pull
requests, and shows a notice that the repository is archived.

https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/archiving-a-github-repository/about-archiving-repositories

An example of how an archived repository looks:

https://github.com/LinuxCNC/hostmot2-firmware

I volunteer to do the work, which may consist of a small README update
before checking a box in the github website.

Jeff


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

Re: [Emc-developers] Using `main` instead of `master` branch

[Jeff Epler]

For those who desire more background, both on the motivation and on the
breadth of organizations that are choosing to make this change:

[some links are about ending use of the M/S terms in electrical
interfaces, which is also a thing that is being addressed]

https://www.acm.org/diversity-inclusion/words-matter
https://sfconservancy.org/news/2020/jun/23/gitbranchname/
https://www.nytimes.com/2021/04/13/technology/racist-computer-engineering-terms-ietf.html
https://www.mail-archive.com/python-dev@python.org/msg111965.html
https://standards.ieee.org/about/sasb/resolutions.html (search December 2020 in 
page)
https://www.linuxfoundation.org/en/blog/master-slave-and-the-fight-over-offensive-terms-in-computing-kate-conger-new-york-times-april-13-2021/
https://betterprogramming.pub/github-replacing-master-with-main-is-a-huge-win-for-inclusion-in-tech-bf517478275b
https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language
https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/
https://www.sparkfun.com/spi_signal_names
https://www.eetimes.com/its-time-for-ieee-to-retire-master-slave/
https://www.oshwa.org/a-resolution-to-redefine-spi-signal-names/
https://cdm.link/2020/06/lets-dump-master-slave-terms/
https://blog.adafruit.com/2020/07/12/the-linux-kernel-has-now-adopted-inclusive-language/

Jeff


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

Re: [Emc-developers] Using `main` instead of `master` branch

[Jeff Epler]

On Tue, Jul 27, 2021 at 07:53:54PM +, Alec Ari via Emc-developers wrote:
> Hi everyone,
> 
> Are there plans to switch the master branch to main? Just curious. I saw they 
> changed it for the Mesa3D git repo and that's the default now for Github.

I'm not opposed to it.  We'll want to make sure that buildbot
understands the change, and update documentation, so it's not something
that is without small cost; But before long I think people will be
surprised and confused by the old names, just as some people experience
surprise the first few times they ran into the new name for the default
branch.

(For my work we've converted hundreds of repos over, and had little
trouble from developers and a bit more trouble from scripts &
automation)

I will be happy to pitch in with the technical steps on github and
advise developers on what they need to do after the change.

Jeff


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

Re: [Emc-developers] hostmot2-firmware

[Jeff Epler]

On Mon, Jul 19, 2021 at 03:29:23PM -0400, Curtis Dutton wrote:
> I see that hostmot2-firmware has been marked as unmaintained.
> 
> I will still be be adding components to hostmot2. Next up is a harmonic
> drive serial encoder interface for hostmot2.
> 
> I'll be submitting the sigma 5 encoder driver code to linux cnc as soon as
> I can, though I have been testing it for the last 6 months or so and it is
> working. Just need to finish documentation. (If anyone needs this now let
> me know and I'll get you some source code to try out)
> 
> Will I just be making pull requests to linuxcnc.hostmot2 firmware anyhow?

For the parts that go in the hostmot2 fpga firmare, you can work
directly with Peter Wallace.  The linuxcnc organization still maintains
the hostmot2 driver in linuxcnc itself, as well as the mesaflash
firmware uploader, both of which need updates when hostmot2 fpgas get
new capabilities.

Jeff


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

Re: [Emc-developers] [Emc-users] Code of Conduct

[Jeff Epler]

On Tue, Jun 29, 2021 at 07:19:08PM +0100, andy pugh wrote:
> On Tue, 29 Jun 2021 at 16:39, andy pugh  wrote:
> 
> > I largely agree, apart from prohibiting "answering outside the scope
> > of the question"
> 
> Thanks for reconsidering this clause, Seb.

I see a number of reasonable folks here concerned about how this rule
would be interpreted and applied, and I don't mind seeing it removed.

I talked to one of the community moderators at Adafruit, where most of
the wording was adopted from.  It sounds like there was a specific need
for it there, and those circumstances don't apply to LinuxCNC.

At the same time, it's good to be mindful of how the advice and help we
give will be perceived; I think we should take to heart Kirk's message
in this thread about toxic behavior.  Kirk has been in this community a
long time.  How many more people simply left the community when they
arrived and got unhelpful help, likely with a dose of contempt? How much
more vibrant could the community have been today if that is not how it
happened?

We've got stuff to work on, y'all.  Communities are work to maintain,
just like software is.

Jeff


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

[Emc-developers] Code of Conduct

[Jeff Epler]

The LinuxCNC community including this mailing list now has a written
code of conduct. Unless it's your idea of fun to harass other people,
this is a big non-event for you.

You can read the code of conduct here:
https://www.linuxcnc.org/CODE_OF_CONDUCT/

Jeff


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

[Emc-developers] IRC Server Change to libera.chat Reply-To:

[Jeff Epler]

[This is a plain-text copy of the blog post 
https://www.linuxcnc.org/2021/06/02/IRC-Server-Change/
Head there for a version with clicky links.  I hope to see many of you
over at Libera.chat!]

Following the example of many prominent projects including Centos,
Fedora, FreeBSD, Gentoo, Wikipedia, and Ubuntu, the LinuxCNC project is
shifting its primary real-time chat presence to the new Libera.chat IRC
service. See the community page for information on how to connect,
including directly in your web browser.

Most IRC clients support connecting to multiple networks at the same
time, so if you still want to participate on channels on Freenode (or
have direct messages with people on Freenode) this option is available
to you as well.

We thank Freenode’s largely volunteer staff for providing a space to
organize and discuss LinuxCNC for many years, and we thank the
Libera.chat staff for providing a new space for the years to come.

Because of reported retaliation for mentioning the libera.chat
alternative on freenode, the channel topics on the Freenode channels
will not be updated to directly refer to libera.chat by name.

Jeff


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

Re: [Emc-developers] flipflop

[Jeff Epler]

On Tue, Apr 06, 2021 at 09:05:51PM +0100, andy pugh wrote:
> I wonder why the output pin of flipflop.comp is of type io?
> 
> Perhaps it was intended for a specific purpose?

flipflop only drives a value onto its output when it is clocked or when
its set input is true.  The theory was probably that there was some way
to make other state-holding elements out of this, such as an SR-latch.

I have no idea whether this is used.


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

Re: [Emc-developers] handle_lxrt_request

[Jeff Epler]

As I said on IRC, I added the rtai lxrt support to uspace realtime to
check off a checkbox item, but I have never intended to publicize it as
a "please expect this configuration to work 100%".  I didn't expect
anybody to end up with it accidentally, either.

If nobody is interested in maintaining it (I'm not), I suggest to remove
the rtai (and xenomai) "support" of uspace realtime, or hide it behind a
stronger configure argument to request an unsable and unsupported
configuration. (--with-plentiful-kernel-oopses, maybe)

That will lead to users in this situation not getting realtime until
they change their configure arguments, but hopefully they won't get
crashes either.

(the uspace rtai has never been in a released linuxcnc version so
technically pulling the feature isn't a regression)

Jeff


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

[Emc-developers] [jbi...@debian.org: Update on removing obsolete GNOME libraries & gtk2 MBF]

[Jeff Epler]

.. which is likely, in turn, to affect LinuxCNC.  Those interested
should look at modernizing the parts of LinuxCNC that still use gtk2.

I know this still includes halscope and halmeter.  it would be a real
pity to lose halscope to CADTs^Wthe progress of the Linux desktop.

- Forwarded message from Jeremy Bicha  -

Date: Sun, 25 Nov 2018 19:06:06 -0500
From: Jeremy Bicha 
To: debian-de...@lists.debian.org
Cc: debian-gtk-gnome , Debian GNOME 
Maintainers 
Subject: Update on removing obsolete GNOME libraries & gtk2 MBF
X-Spambayes-Classification: ham; 0.00

It's been several months since the last update from the Debian GNOME
team on our efforts to remove unmaintained libraries from Debian. We
have made significant progress in this goal and the removal of
libgnome is within reach. See the charts later in this email.

Also, we have succeeded in removing gtk2 from the default GNOME
install for Buster (as of meta-gnome3 1:3.22+13).

gtk2 mass bug filing
-
For Bullseye, we are serious about our intention to remove libglade2,
libgtk2-perl, and pygtk. This is part of a larger effort to reduce
gtk2 use as much as possible. This is a massive project as over 600
packages in unstable are using gtk2 now.

gtk3 was declared stable with its 3.22 release in 2016. gtk3 has many
advantages over gtk2: support for HIDPI scaling, support for Wayland,
CSS theming, better support for non-C programming languages through
GObject Introspection, and more. Practically speaking, gtk2 has nearly
reached its End of Life.

We want to do a gtk2 mass bug filing now. Please contact us if you
would like to help us file all these bugs.

If you use or maintain a GTK2 project, please discuss GTK2's
deprecation with upstream. I believe a majority of GTK2 apps are
unmaintained so you may need to do the porting yourself if you aren't
ready for your favorite apps to be removed from Debian.

Removed from Debian
---
esound
gconfmm2.6
gksu & libgksu
gnome-keyring-sharp
gnome-sharp2
goffice-0.8
gocanvas
libsocialweb
libunique3
mx
opal & ptlib
pygoocanvas
webkit-sharp
webkit-sharp3

libgnome2-perl
libgnome2-canvas-perl
libgnome2-gconf-perl
libgnome2-vfs-perl
libgnome2-wnck-perl
libgoo-canvas-perl
libgtk2-appindicator-perl
libgtk2-unique-perl

Removed from Testing

In this section, the parentheses indicate the remaining packages that
depend on them (reverse dependencies). A trailing & is used to point to
libraries that themselves are listed as removed. A trailing !! means that
the removal process has started either through an Intent to Remove bug or a
RM bug.

(gbonds & thawab will be uploaded soon to fix their issues.)

gnome-python (gnome-python-desktop&, gjots2, revelation)
gnome-python-desktop (xword!!)
gnome-vfs (libgnome&)
libbonobo (libbonoboui&)
libbonoboui (libgnomeui&)
libgnome (libgnomeui&)
libgnomeui (gnome-python&, gbonds, gnome-commander!!, gresolver!!,
linsmith)
libgnome-keyring (libgnomeui&, moonshot-ui, mozilla-gnome-keyring,
  mysql-workbench)
orbit2 (pyorbit&, libbonobo&)
pygtksourceview (cherrytree, liblunar!!)
pyorbit (gnome-python&)
python-poppler (pdfshuffler)
rarian (gbonds)
webkitgtk (swt-gtk!!, thawab)

libgtk2-gladexml-perl
libgtk2-notify-perl
libgtk2-sourceview2-perl
libgtk2-spell-perl
libgtk2-trayicon-perl
libgtk2-traymanager-perl

Discussing removal
-
clutter-gesture

Deferred until Bullseye
--
gconf
gtksourceview2
gtksourceview3
gtkspell3
libglade2
libglademm2.4
libgnomecanvas
libgnomecanvasmm2.6
libgtk2-perl
libunique
pygtk
python-gtkglext1 (xpra)
vte (cdebconf-terminal which is part of debian-installer)

Not removing at this time

libart-lgpl

On behalf of the Debian GNOME Team,
Jeremy Bicha



- End forwarded message -


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

[Emc-developers] Removing myself from the LinuxCNC decision-making process

[Jeff Epler]

Hi all.

I first became involved with LinuxCNC in 2004, and it remains the Free
Software project to which I've made the largest contribution.  However,
I haven't been very involved with the development or use of LinuxCNC for
years---in fact, looking back at my blog, it has been almost 9 years
since I last did anything on my little CNC router worth mentioning.

During my time as a more active developer, I often positioned myself as
a gatekeeper.  At the time I believed that by exercising control over
what went in to LinuxCNC, I was preserving the software from harm.  More
important than whether any of those individual decisions was right or
wrong, I now worry that I have contributed to a bad culture in LinuxCNC
that drove away contributors.

It has been said that the Internet is founded on "rough consensus and
running code".  Today, I think that LinuxCNC could benefit from more of
this attitude and less of my "gate-keeping" style of dealing with
contributions.

For these reasons, I have decided that it's time to make it official:
I'm taking myself out of the loop of LinuxCNC, particularly and most
importantly as it comes to making decisions about pull requests.

As far as any administrative privileges I have (github, website, IRC,
sourceforge(!), etc): I'll turn in my keys to any of those on request,
as long as that leaves at least two people who will keep that service
going to the benefit of LinuxCNC developers and users.  In the meantime,
I don't mind keeping the forum software and its OS up to date as I have
been doing.

A number of you are really good friends.  I'd like to keep it that way.
I plan to keep hanging out in #linuxcnc-devel and I'll try to provide my
"wisdom" if it's requested.

Please use the remainder of this thread to reminisce about the good
times.  For instance, I fondly remember two events in particular from
the CNC Workshops I attended in Galesburg:

1) We're all sitting at the pizza place, and Jon Elson and John Kasunich
are both trying to out-do the other with stories about mishaps with
power electronics.  I've still got nothing on even the tamest of their
tales.

2) While running the Mazak, I discover that hitting alt-tab makes rtapi
freeze up for a few milliseconds while the screen redraws, leading to an
audible "BAM!" from the mill.  Instead of exercising common sense and
not doing *that* again, I held down alt-tab to make it go "BAM BAM BAM
BAM" until someone ran up to hit estop.  (the fix was replacing the
video card, I think I recall)  You shouldn't leave a newbie in charge of
a big machine like that, even for a moment!

I wish you all, and the project itself, the best.

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Pull requests

[Jeff Epler]

On Thu, Jul 19, 2018 at 08:27:33PM +, Alec Ari via Emc-developers wrote:
> I was under the impression that seb, cradek, and jepler handle PRs..

I am doing very little active work on LinuxCNC at this time.

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Pre-Pull Request Review: Better laser engraver support + new HAL pin type "PORT"

[Jeff Epler]

On Mon, Jun 25, 2018 at 10:18:50AM -0400, Curtis Dutton wrote:
> The place where ports are allocated is halcmd_commands.c line 687. That was
> the easiest place I could find to do it. That code should probably be in
> hal_lib.c and just be called by hal command.

Should this line be dropped then?
+printf("  portsizeGet/Set the buffer size of a port signal\n");

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Pre-Pull Request Review: Better laser engraver support + new HAL pin type "PORT"

[Jeff Epler]

This is exciting, thank you.

Can you please mention how this compares/contrasts with
streamer/sampler, which have been factored into hal_stream_XXX API calls
in our master branch?

>From what I can see,
 - hal "streams" are typed
 - hal "streams" are agreed on by allocating small integers, not names
 - hal "streams" storage are outside of the primary HAL shared memory area

.. it looks like
 - hal "ports" are untyped (byte oriented)
 - hal "ports" are named
 - hal "ports" storage are inside the primary HAL shared memory area

I didn't actually spot the implementation of 'halcmd portsize', just the
addition of it to halcmd's help message
+printf("  portsizeGet/Set the buffer size of a port signal\n");

I would love it if there were manpages for these new functions.  You can
write manpages in good old fashioned roff style in docs/man/man3/*.3hal or
in more modern asciidoc style in docs/src/man/man3/*.txt.  Ask if you
need help with markup or Makefiles, some (Sub)makefile might be needed
for asciidoc pages.

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] using the dummysig trick (was Re: pid with derivative inputs)

[Jeff Epler]

I think there's little use for the functions SWP proposed, assuming his
analysis that they have to take a HAL lock is true.  The functions
aren't useful at component-init time, because it's expected for there to
be no connections yet; but they're not usable at runtime, which is when
the dummysig trick is useful.  Is there another use case to consider?

Go ahead and use dummysig if it's appropriate, and wrap it in an API if
you like, but don't add these other functions without a good motivation.

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Compiling Kins

[Jeff Epler]

On Thu, Mar 08, 2018 at 04:29:00PM +, andy pugh wrote:
> Is it possible to compile a kins module without compiling all of LinuxCNC?
> halcompile appears not to properly compile pumakins (as an example).

Not in general.

pumakins is an example of a kinematics module that actually is a
combination of several source files (in addition to pumakins.c,
_posemath.c and sincos.c are included).  halcompile does not handle such
components.  (this dependency is a bit hidden, it's written in
src/Makefile, search for pumakins)


You didn't show the error, but I assume that it was something like
(assuming uspace)

pumakins: dlopen: ...: undefined symbol

the named symbol (such as pmRpyQuatConvert) comes from one of those
other source files that is linked into the pumakins component when built
inside LinuxCNC.

tripodkins, on the other hand, not only compiles with halcompile, but
the result will also 'loadrt'.

By using Makefile.modinc directly, you should be able to build C
components from multiple source files.  However, this is not documented
or tested, so it's probably broken and how would you know about it
anyway?

Well, here, I at least wrote a test.  It passes in master branch with
uspace.

-- >8 --
Subject: [PATCH] tests: test building a component with multiple source files

---
 tests/halcompile/multisrc/.gitignore|  2 ++
 tests/halcompile/multisrc/Makefile  | 10 ++
 tests/halcompile/multisrc/checkresult   |  2 ++
 tests/halcompile/multisrc/extra.c   |  1 +
 tests/halcompile/multisrc/go.hal|  2 ++
 tests/halcompile/multisrc/multisrc.comp |  9 +
 tests/halcompile/multisrc/test.sh   |  6 ++
 7 files changed, 32 insertions(+)
 create mode 100644 tests/halcompile/multisrc/.gitignore
 create mode 100644 tests/halcompile/multisrc/Makefile
 create mode 100755 tests/halcompile/multisrc/checkresult
 create mode 100644 tests/halcompile/multisrc/extra.c
 create mode 100644 tests/halcompile/multisrc/go.hal
 create mode 100644 tests/halcompile/multisrc/multisrc.comp
 create mode 100755 tests/halcompile/multisrc/test.sh

diff --git a/tests/halcompile/multisrc/.gitignore 
b/tests/halcompile/multisrc/.gitignore
new file mode 100644
index 0..cc2070e0a
--- /dev/null
+++ b/tests/halcompile/multisrc/.gitignore
@@ -0,0 +1,2 @@
+*.so
+multisrc.c
diff --git a/tests/halcompile/multisrc/Makefile 
b/tests/halcompile/multisrc/Makefile
new file mode 100644
index 0..c799a90a6
--- /dev/null
+++ b/tests/halcompile/multisrc/Makefile
@@ -0,0 +1,10 @@
+obj-m += multisrc.o
+multisrc-objs := multisrc.o extra.o
+
+%.c: %.comp
+   halcompile --preprocess $^
+
+include $(shell halcompile --print-modinc)
+
+clean:
+   rm -f multisrc.c *.o *.[sk]o
diff --git a/tests/halcompile/multisrc/checkresult 
b/tests/halcompile/multisrc/checkresult
new file mode 100755
index 0..6a2d1e553
--- /dev/null
+++ b/tests/halcompile/multisrc/checkresult
@@ -0,0 +1,2 @@
+#!/bin/sh
+grep -q -F 'RTmultisrc' $1
diff --git a/tests/halcompile/multisrc/extra.c 
b/tests/halcompile/multisrc/extra.c
new file mode 100644
index 0..3d7062941
--- /dev/null
+++ b/tests/halcompile/multisrc/extra.c
@@ -0,0 +1 @@
+int f() { return 1; }
diff --git a/tests/halcompile/multisrc/go.hal b/tests/halcompile/multisrc/go.hal
new file mode 100644
index 0..8f22120fc
--- /dev/null
+++ b/tests/halcompile/multisrc/go.hal
@@ -0,0 +1,2 @@
+loadrt multisrc
+show
diff --git a/tests/halcompile/multisrc/multisrc.comp 
b/tests/halcompile/multisrc/multisrc.comp
new file mode 100644
index 0..e991f209a
--- /dev/null
+++ b/tests/halcompile/multisrc/multisrc.comp
@@ -0,0 +1,9 @@
+component multisrc;
+pin out bit out;
+function _;
+license "GPL";
+;;
+extern int f();
+FUNCTION(_) {
+out = f();
+}
diff --git a/tests/halcompile/multisrc/test.sh 
b/tests/halcompile/multisrc/test.sh
new file mode 100755
index 0..ab1d52bb8
--- /dev/null
+++ b/tests/halcompile/multisrc/test.sh
@@ -0,0 +1,6 @@
+#!/bin/bash
+set -e
+make modules
+make install
+halrun go.hal
+make clean
-- 
2.11.0

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] vismach and deeply nested models resulting in errors

[Jeff Epler]

Cc: 
Bcc: 
Subject: Re: [Emc-developers] Really cool use of Vismach, and a puzzling
 problem
Reply-To: 
In-Reply-To: 


vismach relies on classic OpenGL's "modelview" stack, which has a
limited number of entries.  When the complxity of the transformation of
an item in vismach exceeds this limit, that error will occur.  This will
affect "deeply nested" models, of which the wire bending seems to be an
example.

The solution would be to modify vismach so that it does not depend on
the OpenGL transformation stack (never do push/pop matrix GL calls, only
loadmatrix).  This would be good for a motivated dev to do anyway, since
that's one step in converting vismach to modern, not deprecated, OpenGL.

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Ethercat driver

[Jeff Epler]

On Sun, Feb 04, 2018 at 08:29:53PM +0100, Nicklas Karlsson wrote:
> https://openethercatsociety.github.io/doc/soem/index.html
> ...
> Features as of 1.2.0 :
> Changed license to GPLv2 only. Adresses leagal concerns about master 
> licensing.
> ...
> 
> So I guess it is OK.
> 

On this date, that page still contains the text

| You can use SOEM for the sole purpose of creating, using and/or
| selling or otherwise distributing an EtherCAT network master provided
| that an EtherCAT Master License is obtained from Beckhoff Automation
| GmbH.

restricting how the software may be used, modified, and distribured in
contradiciton of other terms of the GPL.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Ethercat driver

[Jeff Epler]

Our policy is that any code added to LinuxCNC has to be compatible with
the license terms "GPL version 2 or any later version".
https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

Anything that imposes a restriction on how the software can be used (for
example, if it is claimed that using the software requires an additional
license, as Beckhoff Automation GmbH reportedly does) cannot be
incorporated.

For a rather old thread on exactly the same topic, see this one from
2013:
https://sourceforge.net/p/emc/mailman/emc-developers/thread/20131022150751.GB2631%40unpythonic.net/

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Mode switching bug

[Jeff Epler]

On Sat, Dec 02, 2017 at 08:19:33AM -0600, Moses McKnight wrote:
> Hi Rene,
> 
> In case you missed it, dgarr sent this on IRC as a possible fix:
> 
> a test patch for #361 (there may be unknown side effects)
> http://www.panix.com/~dgarrett/stuff/0001-test-fix-for-361.patch
> 
> Moses

I think we should give Dewey's fix a try fwiw.  It will feel like a
regression for people who use axis-and-other-UI to jog, but we may have
to bite that bullet.

Jeff 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Interpreter in Python

[Jeff Epler]

On Fri, Dec 01, 2017 at 11:41:13AM +, andy pugh wrote:
> In remap code you can use:
> from intepreter import *
> 
> and have acces to the (largely undocumented) interpreter Python interface:
> https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/rs274ngc/interpmodule.cc
> 
> But how can you import that module into Python that is _not_ part of a
> G-code remap ?

It appears that the answer is insane.

import gcode
try:
gcode.parse("", None)
except AttributeError:
pass
import interpreter

note: I'm not sure you can do anything useful with items from the
interpreter module after doing this.

Have a nice day,
Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Default path for gcode files

[Jeff Epler]

On Fri, Sep 01, 2017 at 04:36:35PM +, Dewey Garrett wrote:
> 
> > The machine next to it is running version 2.5.4,
> > and does reference the nc_files folder for gcode
> > files. I checked the ini file for any other
> > reference to nc_files, and no other instances
> > exist.
> 
> This commit altered file opening (5 years ago):
>   https://github.com/LinuxCNC/linuxcnc/commit/8c1dfd04
> 
> "...
>  linuxcncrsh also used to prepend the string constant "../../nc_files"
>  to every filename being opened.  This is just totally bogus and broken.
> ..."
> 
> The commit is included in 2.6 but not in any v2.5 tag

Thanks for doing that research, Dewey.

One problem with using this hard-coded relative path is that we changed
the organization of sample configurations: we used to have a single
level organization (such as configs/sim/axis.ini) but now we have a multi-level
organization.

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Default path for gcode files

[Jeff Epler]

On Fri, Sep 01, 2017 at 09:21:42AM -0400, Eric H. Johnson wrote:
> Dewey,
> 
> So is PROGRAM_PREFIX in the DISPLAY section getting ignored? I previously set 
> it to:

to the best of my knowledge, PROGRAM_PREFIX has never been used by
task for opening part programs with relative paths.  If I'm mistaken
about this, can you state a released version number or git ref which
behaved differently?  If that behavior has changed, we'd want to treat
it as a regression.

(task *does* read PROGRAM_PREFIX, but it appears to do so only for
locating custom M-code scripts, which is an unfortunate historical
choice)

Rather, UIs may read PROGRAM_PREFIX and use it in whatever way they see
fit, such as showing the file open dialog with that directory as the
initial location.  This is what AXIS does, last time I checked.

If you decide you want to enhance your UI so that it automatically joins
relative paths to PROGRAM_PREFIX before sending them to task, that would
make sense to me.

should consider using boost::filesystem for this purpose, since we
already use several other boost facilities.  In the future, when C++17
support is widespread, we can transition to use of std::filesystem with
a mostly-compatible API.  This would involve a few steps, such as adding
the right development packages to debian/ packaging metadata, adding
configure tests to find the right library names to link, etc, before it
could be used in a UI program.

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Wierd Gcode error

[Jeff Epler]

$ rs274 -g jung.ngc
...
  292 N247   STRAIGHT_FEED(2.0760, 0., -3.1970, 0., 0.,
0.)
Radius to end of arc differs from radius to start:
start=(Z-3.1970,X2.0760) center=(Z-4.5680,X-0.2560)
end=(Z-3.2700,X2.1565) r1=2.7052 r2=2.7395 abs_err=0.03436
rel_err=1.2543%
N248 G3 X4.313 Z-3.27 I-2.332 K-1.371

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Wierd Gcode error

[Jeff Epler]

It looks like I introduced a bug in 2.7.10 that causes axis/gremlin to
show any gcode error as "Unable to open file <>".

I'll get the bug fixed in 2.7 and master branches, I understand why it
is occurring.  See issue #273 and pull #299.  The problem results from
the way I worked around the interpreter not wanting to close the files
it's opened.

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Stretch-based LinuxCNC images ready for testing

[Jeff Epler]

On Fri, Jul 21, 2017 at 11:01:45AM -0400, tom-...@bgp.nu wrote:
> Will there be an RTAI kernel for Stretch at some point?   

Personally, I do not plan to work on an RTAI kernel.

In the event an RTAI kernel for Stretch reaches the point where it is
good enough for linuxcnc.org to ship it, it should not be difficult to
produce live images for it; it's a one-line change to the building
scripts for these images to change the kernel, and a second one-line
change to instal "linuxcnc" instead of "linuxcnc-uspace".

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Moving to github - progress!

[Jeff Epler]

On Mon, Jul 17, 2017 at 09:08:10PM -0500, Jon Elson wrote:
Great, thanks for the hard work!  It looks pretty easy to browse files 
in the master branch, have to learn how to find the others.


If you're at the front page of the repo 
(https://github.com/LinuxCNC/linuxcnc) look at the left for
"Branch: master ▼" just below where it says "1x,xxx commits".  Click it 
open, then choose the branch you want.


You can also do it just by entering a URL, e.g., to view the 2.7 branch:
https://github.com/LinuxCNC/linuxcnc/tree/2.7

or to see a commit-based view instead of a tree-based view click "1x,xxx 
commits" button or go to e.g.:

https://github.com/LinuxCNC/linuxcnc/commits/2.7

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinxCNC Python Module

[Jeff Epler]

Please keep replies on the list.  Whole message quoted so that the 
context is not lost.


On Tue, Jun 27, 2017 at 09:39:00AM +1000, Phillip Carter wrote:

On 26/06/17 22:34, Jeff Epler wrote:

   On Mon, Jun 26, 2017 at 02:58:42PM +1000, Phillip Carter wrote:

   Is the documentation correct for the LinuxCNC Python Module in
   regards to kinematics_type?

   In the documentation for the LinuxCNC Python Interface there is
   reference to:
   kinematics_type
   (returns integer) - identity=1, serial=2, parallel=3, custom=4 .


   Yeah I agree that is not what the module does.  Use the pseudo-enumerated
   values you see in emcmodule.cc:

   ENUM(KINEMATICS_IDENTITY);
   ENUM(KINEMATICS_FORWARD_ONLY);
   ENUM(KINEMATICS_INVERSE_ONLY);
   ENUM(KINEMATICS_BOTH);

That being the case:
In commit [1]681cf92 I created a variable (trivkinstype) that I now think is
unnecessary.
Should I submit a patch that removes this variable?


Yes, I suspect it is more correct to get this value from the stat buffer 
instead of from an inifile item.  For one thing, the code that is 
parsing the [KINS]KINEMATICS value will only work when the kinematics is 
trivkins, not when it's something else like genserkins, right?


Jeff



   doc patches welcome.


I will look into this.



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinxCNC Python Module

[Jeff Epler]

On Mon, Jun 26, 2017 at 02:58:42PM +1000, Phillip Carter wrote:
Is the documentation correct for the LinuxCNC Python Module in regards 
to kinematics_type?


In the documentation for the LinuxCNC Python Interface there is 
reference to:

kinematics_type
(returns integer) - identity=1, serial=2, parallel=3, custom=4 .


Yeah I agree that is not what the module does.  Use the 
pseudo-enumerated values you see in emcmodule.cc:

ENUM(KINEMATICS_IDENTITY);
ENUM(KINEMATICS_FORWARD_ONLY);
ENUM(KINEMATICS_INVERSE_ONLY);
ENUM(KINEMATICS_BOTH);


doc patches welcome.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] DISCUSS: Move primary git to github

[Jeff Epler]

Just a reminder that the date for the IRC meeting and vote on this 
proposal is coming up.  I hope to see you all there.


Original text follows:

PROPOSED: That we move our primary git to github, retiring
git.linuxcnc.org and the "Signed-off-by" process.

For more background about what and why, please see the RFC thread:
   https://sourceforge.net/p/emc/mailman/message/35845586/

For more details about our (infrequent!) IRC meetings, please see
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MeetingsOnIRC
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Meeting201706

Proposed Timeline:

2017-06-24: Discuss and vote the issue in an IRC meeting
2017-07-24: Actual switch-over date announced by this date;
   switch-over to take place no earlier than 1 week from
   announcement
2017-TBD:   Switch over to github for primary git


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] WOST for hm2 drivers

[Jeff Epler]

.. as a specific example, hostmot2.h defines hostmot2_t.  Between 2.7 
and master, we added the config.pktuarts and pktuart fields to it.  This 
is technically API compatible, since the fields were only added; the 
meaning of existing fields is not changed.  However, it is ABI 
incompatible since the size and layout of the structure changed.  We've 
never tried to be ABI compatible in this way.


Between 2.6 and 2.7, we made an incompatible API change, removing one 
API and adding two to replace it:


   -int hm2_sserial_check_errors(hostmot2_t *hm2, hm2_sserial_instance_t *inst);
   +int hm2_sserial_check_local_errors(hostmot2_t *hm2, hm2_sserial_instance_t 
*inst);
   +int hm2_sserial_check_remote_errors(hostmot2_t *hm2, hm2_sserial_instance_t 
*inst);

If this had been public API, then we would have needed to provide the 
old API too, during the interval that the old API was deprecated.


Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] WOST for hm2 drivers

[Jeff Epler]

Another important consideration is whether the hostmot2 API is stable 
enough that we want to make it a part of the public API of LinuxCNC.  
That means things like not deliberately making breaking API changes 
without notice for a whole stable release cycle; so e.g., if we do this 
in 2.8, then want to make a change, we have to still support the same 
API during 2.9 and only change it in 2.10; this is a multi-year process, 
since we don't even start a stable release cycle on a yearly basis these 
days.


Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] is possible run lcnc over vxworks?

[Jeff Epler]

On Fri, Jun 16, 2017 at 09:35:55PM +0200, theman whosoldtheworld wrote:
> is possible run lcnc over vxworks? and how?

LinuxCNC depends on rtapi (bundled as part of the LinuxCNC source tree) for
portability to different RTOSes.

To use LinuxCNC on a new rtos such as vxworks, "all" you have to do is create
an implementation of rtapi.

I am not familiar with vxworks, so I can't speculate whether this is difficult
or very difficult.  If vxworks has an API that is broadly similar to POSIX
threads, then it is going to be less hard; you might just have to implement the
very small interface of the 'RtapiApp' virtual base class [plus additional
detection logic, scripting in scripts/realtime, and, oh, lots of other stuff I
don't remember off the top of my head].  If it's not broadly similar to POSIX,
then you can either see what has to be made a virtual method of RtapiApp, or
make a fresh implementation from scratch (the classic kernel-mode realtime with
rtai is like this, though it predates uspace and rtapi_app by many years).

Then you will have to do whatever porting is necessary to run non-realtime
POSIX apps such as milltask, and if you aren't running a local graphical user
interface you'll have to deal with nml-over-tcp and all the rough edges that
exist there.  (and of course if you can't run regular non-realtime POSIX apps
such as milltask then you have a much bigger problem)

Basically, you need to throw a lot of developer time at it and maybe you'll get
a useful result and maybe you won't.

Ultimately, accepting a vxworks rtapi implementation would be a tough call for
LinuxCNC developers; I'd be reluctant unless we had a plan for keeping it
actively automatically tested and had a developer who would show up to fix at
least showstopper bugs.

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] DISCUSS: Move primary git to github

[Jeff Epler]

PROPOSED: That we move our primary git to github, retiring
git.linuxcnc.org and the "Signed-off-by" process.

For more background about what and why, please see the RFC thread:
https://sourceforge.net/p/emc/mailman/message/35845586/

For more details about our (infrequent!) IRC meetings, please see
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MeetingsOnIRC
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Meeting201706

Proposed Timeline:

2017-06-24: Discuss and vote the issue in an IRC meeting
2017-07-24: Actual switch-over date announced by this date;
switch-over to take place no earlier than 1 week from
announcement
2017-TBD:   Switch over to github for primary git

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Problem loading second file in recent builds of master

[Jeff Epler]

A couple similar problems created at that version "3116" you
mentioned were reported and fixed 
https://github.com/LinuxCNC/linuxcnc/issues/269
https://github.com/LinuxCNC/linuxcnc/issues/271
I'm sad, but it sounds like there's yet another problem lurking
there.

However, I didn't reproduce your problem here.  Based on what you
described, here are the steps I followed:
 * start the sample configuration configs/sim/axis/axis.ini
 * click the "reload" icon in the toolbar to reload the splash part
   program
I tested with v2.8.0-pre1-3128-gafe82611f, which is after version
3116 that you said you identified as leading to the problem; and at
v2.8.0-pre1-3133-g6a3b4a226 which you also mentioned.

Can you let me know the specific steps you follow to reproduce the
problem?  Please reproduce it with configs/sim/axis/axis.ini if you
can, or let us know if it requires a specific configuration.  It
could potentially also depend on the loaded part program.

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] RFC: Retire git.linuxcnc.org and move primary git to GitHub

[Jeff Epler]

On Thu, May 18, 2017 at 05:24:46PM +, James Waples wrote:
> Github has a pretty good code search and viewer. Is there something
> fundamentally missing from it that the current system has? I don't use it a
> great deal so there may be areas lacking in functionality.

Here's what Andy said a few posts up the thread:
github search simply ignores many characters so a search for object.property
becomes a search for object and/or property.  

For instance, compare the result of searching for "s.poll" in github and gitweb:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git=search=grep=s.poll
https://github.com/LinuxCNC/linuxcnc/search?q=s.poll

github docs[1] state
You can't use the following wildcard characters as part of your
search query: . , : ; / \ ` ' " = * ! ? # $ & + ^ | ~ < > ( ) {
} [ ]. The search will simply ignore these symbols.
which is actually not great for searching code.  Simple for them to
code, I imagine.  There's a two year old issue asking for it to be
improved[2].

gitweb help warns:
On large trees, this search can take a while and put some strain on
the server, so please use it with some consideration
but I don't think this has caused us trouble in practice.

Jeff
 [1]: https://help.github.com/articles/searching-code/
 [2]: https://github.com/isaacs/github/issues/402

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] RFC: Retire git.linuxcnc.org and move primary git to GitHub

[Jeff Epler]

How do developers of LinuxCNC feel about the idea of moving the
primary git hosting from git.linuxcnc.org to GitHub?

Historically, we made the decision to self-host our revision control
after a prolonged outage of the CVS service at sourceforge.net in
2006.  Unlike git, cvs is only useful with a server (even "cvs diff"
and "cvs log" are network operations), so this was a serious
impediment to working on LinuxCNC.

When we made the transition to git in 2009, GitHub did not have the
stature or reputation that it now does among Free Software and Open
Source developers, so we continued to host our own revision control
system at that time.

Two things have become more clear to me recently.  First, the degree
of immediate hardship if GitHub goes down is fairly minor, since
everyone can continue to work on their local complete copies of the
git history of LinuxCNC.  Second, if GitHub has an extended downtime
or becomes unsuitable for other reasons, we can select other free
git hosting services (e.g., BitBucket) or spin up our own
hosting (e.g., GitLab CE).

Advantages of switching to GitHub as primary rather than a mirror are
that we can:

 - retire the "Signed-off-by" rule[1], and instead rely on GitHub's
   Terms of Service section D.5[2] to ensure contributions are
   offered under an appropriate Free Software license.  The
   "Signed-off-by" rule prevents us from immediately accepting a
   substantial number of first contributions made via GitHub.

 - merge pull requests directly through their web interface, instead
   of requiring a manual merge and push even for simple
   non-conflicted merges

 - administer push & merge access using the GitHub web UI; users can
   administer their own ssh keys through the GitHub web UI

 - get correct information on GitHub about who merged a PR or closed
   an issue when the commit message says "Close: #nnn".  (Right now,
   because the mirror from git.linuxcnc.org to GitHub is done under
   Chris Radek's ssh identity, he is identified as closing all
   issues and PRs!)

 - retire the self-hosted git.linuxcnc.org service

There are several one time costs associated with this change:

 - Documentation will need to be modified to reflect the new
   workflow

 - Seb Kuzminsky must set up change notifications from GitHub to
   buildbot; he states that he thinks "it will be easy to get that
   part to work"

 - Each repository user must issue a "git remote" command to change
   the "origin" remote, or get a fresh clone

 - Each developer using direct push access now will need their 
   GitHub account added to the linuxcnc "organization" on GitHub.

To begin with, I've identified 12 developers with push access to
git.linuxcnc.org who made at least one commit since 2016-1-1 and had
a GitHub account that I could find.  We'd initially set everyone on
that list to have push access on GitHub.[3]  If this list doesn't
include you, just contact an admin with your GitHub login.[4]

If you're a developer with direct push access currently and choose
not to create a GitHub account, we'll work out an alternate workflow
with you.

Of course, we will continue to accept patches via the mailing list,
from public git repos besides GitHub, and so on.

If there seems to be a general consensus to switch, then I'll
officially make a proposal for voting in a future IRC-meeting.

Jeff

 [1]: 
http://linuxcnc.org/docs/devel/html/code/contributing-to-linuxcnc.html#_signed_off_by_policy
 [2]: 
https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license
 [3]: http://media.unpythonic.net/linuxcnc-pushed-since-2016-1-1.txt
 [4]: Administrators of the GitHub linuxcnc organization are
  currently Chris Radek, Seb Kuzminsky, and me

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] problems running source build of 2.8 master

[Jeff Epler]

On Mon, Mar 06, 2017 at 08:33:56PM -0600, Jon Elson wrote:
> Great, it works!  Thanks for the quick fix!

Thanks for verifying the fix.

Jeff

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] problems running source build of 2.8 master

[Jeff Epler]

On Sun, Mar 05, 2017 at 11:54:03PM -0600, Jeff Epler wrote:
> The related line in the source is:
>   src/hal/drivers/hal_ppmc.c:RTAPI_MP_ARRAY_INT(timestamp, MAX_BUS*8, 
> "bus/slot locations of timestamped encoders");
> due to a technical limitation, the second parameter to
> RTAPI_MP_ARRAY_INT must be a literal number, not the result of a
[...]

This turns out to be easier to fix than I worried it would be.
https://github.com/LinuxCNC/linuxcnc/pull/243

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] problems running source build of 2.8 master

[Jeff Epler]

On Sun, Mar 05, 2017 at 01:47:06PM -0600, Jon Elson wrote:
> And, I get this error :
> 
> timestamp=0x00: Invalid type character `*'

The related line in the source is:
src/hal/drivers/hal_ppmc.c:RTAPI_MP_ARRAY_INT(timestamp, MAX_BUS*8, 
"bus/slot locations of timestamped encoders");
due to a technical limitation, the second parameter to
RTAPI_MP_ARRAY_INT must be a literal number, not the result of a
calculation.  This limitation is only present for "uspace" builds of
LinuxCNC, and is unfortunately not diagnosed at compile time, but rather
only when the parameter is used.  Since MAX_BUS is 3, the fix is to
replace this instance of MAX_BUS*8 with the literal number 24, or do the
harder work of removing this limitation of RTAPI_MP_ARRAY macros on
uspace builds.

Jeff

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] gmoccapy - differences between 2.7 and master

[Jeff Epler]

Hi.

I understand what you are asking for, and I think your motivation is
good.  But since your suggestion impacts all developers who are fixing
bugs, we need to have a dialog about it and find a solution that serves

The crux of the issue I see is that "git merge branch-A" when on
branch-B always merges *ALL* commits that are on branch-A and not yet on
branch-B, and our workflow is to merge 2.7 to master "from time to time"
in order to get all the bugfixes and minor enhancements in the
development version.

This workflow seems to function well for most parts of LinuxCNC, and I
would like to preserve it.  Other workflows, such as using cherry-pick
to make similar changes in 2.7 and master, put extra responsibility on
*all* developers who make changes to 2.7, and increase the risk that a
change that SHOULD have been made in 2.7 and master is made only in
master.

Instead, I'd rather search for some guidelines and strategies that will
rarely impact developers who are fixing bugs in linuxcnc that are not
related to gmoccapy.  However, I think it's inevitable that this will
impose some extra duties on developers pushing fixes to gmoccapy bugs in
2.7.

Basically, I propose the following workflow for fixing gmoccapy bugs
differently in 2.7 and master:
 * Make the appropriate change in 2.7, test and push
 * Switch to master branch
 * Merge 2.7 to master with but don't commit.  Typical commandline:
git merge --no-commit origin/2.7
 * Discard gmoccapy changes, regardless of whether they are conflicts.
   Typical commandline:
git checkout --ours -- \
configs/sim/gmoccapy \
docs/src/gui/gmoccapy* \
docs/src/gui/images/gmoccapy* \
share/gmoccapy \
src/emc/usr_intf/gmoccapy \
src/po/gmoccapy
   [note use of the shell line-continuation character "\" to avoid long
   lines in this e-mail]
 * test, commit, and push master branch
 * If applicable, make the gmoccapy appropriate change/bugfix for master
   branch and push that

For developers not working on gmoccapy, the only change in the workflow
is that, in case a merge conflict is seen and it names a gmoccapy file,
to contact Norbert (or any fellow gmoccapy developers he cares to
designate) instead of trying to resolve any merge conflicts themselves.

There are probably other ways to accomplish this goal; the workflow for
fixing gmoccapy bugs in 2.7 that I outline above is just the first
method I thought of.  Let's continue this dialogue and find the solution
that seems to have the least complexity.

Jeff
PS renaming files won't help, because in at least some cases git is
smart enough to automatically find the renamed file and apply the change
to it (this can be disabled by 'git merge -Xno-renames' but I wouldn't
want to require this, since it means we also couldn't do "good renames"
but could only use renaming as a way to break automatic merging)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Graphical HAL Viewer-Editor

[Jeff Epler]

On Wed, Nov 16, 2016 at 06:13:35AM -0600, Jim Craig wrote:
> If I develop this application around the python-pygoocanvas package can 
> we modify the standard linuxcnc distribution to include this package by 
> default? If so I will continue and modify the code to use this new 
> canvas for the drawing portion of the application.

In Debian packaging, the requirements of each package are listed (lists
of more Debian package names) in the package metadata.

So in the end, when your application is packaged as a Debian package,
installing it will automatically install the dependencies.

This doesn't require changing "the standard linuxcnc distribution" to
list python-pygoocanvas somewhere, except in the dependency list of the
hypothetical new package (and then installing the package itself)

Jeff

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

Re: [Emc-developers] New to developers list

[Jeff Epler]

I'm totally open to 'comp' gaining a new output format that describes the
component.  that beats parsing manpage markup by a factor of about a billion.
but somebody needs to design that format and implement it in comp.

Jeff

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] G76 Errors

[Jeff Epler]

On Thu, Sep 08, 2016 at 09:45:56AM -0700, Kirk Wallace wrote:
> I'm not following the above well. Let's take the first item in the 
> manual's G76 error list.
> http://linuxcnc.org/docs/2.7/html/gcode/g-code.html#gcode:g76
> 
> "...
> It is an error if:
> 
> The active plane is not the ZX plane
> ..."
> 
> Currently, the interp_convert.cc code contents for G76 doesn't seem to 
> check for the active plane. In running g-code I can set any plane and 
> G76 runs normally, (although the active g-codes box always switches to 
> indicate G17 when the cycle starts).
> 
> So, should the line about the active plane be removed from the G76 
> manual entry because it's not really an error.

You are making statements about how what happens after you do something
the manual states "is an error", i.e., is an example of a mistaken part
program.

I think this particular item falls into the third class of thing I tried
to explain:  By saying that it is an error to program any plane but G18,
a *future* verison of LinuxCNC can define new and different behavior if
a different plane is selected.  One example that comes to mind is that
e.g., G18.1 G76 could do something new and wonderful: thread with
the WU axes instead of the ZX axes.

If you remove this notice from the documentation today, then we don't
have the freedom to do this in a new version, ever.

That is why I wouldn't remove such a notice from the documentation
unless there's a benefit to doing so, and the benefit from that is
larger than approximately the benefit of any *new* behavior that could
be defined for that in the future, TIMES the odds of someone actually
deciding to implement it.

Jeff

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

Re: [Emc-developers] G76 Errors

[Jeff Epler]

At least three things fall in the category "It is an error if ...":

 * The part program is invalid, and LinuxCNC rejects it with a message.

 * The part program is invalid, but LinuxCNC may not detect it.
   Undesired motion (or other action) may ensue.  This could reflect a
   case that the developer knows she did not correctly define during the
   design of the interpreter.

 * The part program is invalid, and a future version of LinuxCNC
   is free to assign a different meaning to the part program in
   a future release, with or without notice in the documentation.

Some of the things listed as an error for G76 clearly fall into the
second two categories.

Jeff

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

Re: [Emc-developers] Proposal: add DRO_FORMAT to the [DISPLAY] section

[Jeff Epler]

If it will improve user experience, go for it.

Some worries:
 * a UI preference won't change e.g., how the center-format arc radius
   check is performed in the interpreter, but some user might expect it to(?)
 * right now different (but fixed) precisions are available for mm and
   in.  It is a regression if this is no longer possible

Note that in Python as in C, it is possible to take the 'width' and
'precision' values (or both) from the list of format arguments, like so:

>>> "%*.*f" % (5, 3, math.pi)  # width 5, precision 3
'3.142'
>>> "%*.*f" % (6, 2, math.pi)  # width 6, precision 2
'  3.14'

Jeff

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

Re: [Emc-developers] I like to merge GladeVCP CamView to 2.7 branch

[Jeff Epler]

Runtime dependencies that are constant for all platforms are listed in
debian/control.{top,bottom}.in under the stanza for the related binary
package.

Runtime dependences that vary from platform to platform and are not
autodetected by dpkg-buildpackage are listed in debian/configure.  Right
now this is only @KERNEL_HEADERS@, so this variable would need to be
renamed or a new variable would need to be created and substituted.

Compile-time dependencies are handled similarly, but in the very top
stanza of debian/control.top.in.

Optional features that some users want to install and others do not are
best implemented via multiple binary packages, particularly if a large
amount of disk space is used by the optional feature's dependencies.
Creating a new binary package involves making a new Package stanza in
debian/control.bottom.in and a new list of files to include in that
binary package in debian/.files or .files.in if
substitution of @-variables is required.  Perhaps an appropriate package
name would be linuxcnc-camview.

Optional features that don't even exist on all supported platforms would
be done similarly to how (in master branch), debian/configure decides
whether to include e.g., debian/control.uspace-rtai.in in the generated
debian/control file.

Of course, src/configure.in and src/Makefile "make install" support are
also needed to get things in the right place for dpkg-buildpackage, as
well as for RIP users.

Jeff

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

Re: [Emc-developers] Fwd: Any idea when CVE-2016-5696 is going to get fixed?

[Jeff Epler]

Linuxcnc.org has never done security updates for kernels or other
prerequisites for LinuxCNC that we host on linuxcnc.org's apt
repositories, and absent new volunteers who will contribute their time
to do so this is unlikely to change.

In the case of remote (network) kernel vulnerabilities, I recommend
never connecting a linuxcnc machine to an untrusted network.  I put all
mine behind nat-style technologies.  No, I don't know whether NAT
mitigates this particular CVE.

In the case of local vulnerabilities, any user who can run "realtime
start" owns the machine so local privilege escalation attacks are
uninteresting to me.

Jeff

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

Re: [Emc-developers] github pull requests, automatic checks, and signed-off-by

[Jeff Epler]

On Tue, Aug 16, 2016 at 04:41:14PM -0500, John Morris wrote:
> In the absence of pull request data, when building a plain push, is it 
> enough to check the list of commits from `git log upstream/master...`?

hm, maybe, if that ref is available.

I notice a typical clone line by travis-ci is
$ git clone --depth=50 --branch=travis-ci-2.7 
https://github.com/jepler/linuxcnc.git jepler/linuxcnc
   
so I'd have to do additional git operations for the case where there are
more than 50 commits in a PR anyway, but I think the upstream/master
branch is not going to exist yet without fetching it.  So I'd have to do
a full fetch every time to be sure I have the relevant history...

Jeff

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

Re: [Emc-developers] github pull requests, automatic checks, and signed-off-by

[Jeff Epler]

On Mon, Aug 15, 2016 at 04:55:51PM -0500, Jeff Epler wrote:
> so yeah that is a promising idea!  Do the SOB check as a pre-build step,
> and no need to run a service for that.

Unfortunately, this doesn't seem to pan out.  If travis-ci already built
at some ref abc123 for a push, it won't build again at ref abc123 when
it is the subject of a pull request.  But it's only when the pull
request is formulated that we have the information about what commit
range needs to be checked for signed-off-by.

Jeff

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

Re: [Emc-developers] github pull requests, automatic checks, and signed-off-by

[Jeff Epler]

On Mon, Aug 15, 2016 at 03:27:11PM -0500, John Morris wrote:
> 
> 
> On 08/15/2016 02:43 PM, Jeff Epler wrote:
> > I have about an 80% solution to checking signed-off-by and showing it on
> > github pull requests as an automated check.  You can see a PR that
> > satisfies our policy here in my personal github fork:
> >
> > https://github.com/jepler/linuxcnc/pull/3
> >
> > (for some reason you have to be signed in on github to see the result of
> > checks.  then click the "show all checks" link just below the list of
> > commits)
> >
> > This requires a service hosted on public http(s); my chosen
> > implementation uses apache and python along with some random internet
> > and github components to glue everything together.
> 
> Did I see you playing with automated builds on Travis CI recently? 
> You're running custom web services to support the SOB check; could the 
> functionality be moved to Travis?

Yes, we (I) recently did that.  It's active for 2.7 and master branches,
and you should see pass/fails of the Travis CI build in your pull
requests if they are based off a new enough branch point.

At first glance, I didn't think a Travis CI build has enough information
to know this, but I see that some environment variables are provided
that may help:
TRAVIS_COMMIT_RANGE::
The range of commits that were included in the push or pull
request.  (Note that this is empty for builds triggered by the
initial commit of a new branch.)


TRAVIS_PULL_REQUEST::
The pull request number if the current job is a pull request,
“false” if it’s not a pull request.
[https://docs.travis-ci.com/user/environment-variables/]

so yeah that is a promising idea!  Do the SOB check as a pre-build step,
and no need to run a service for that.

Jeff

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

Re: [Emc-developers] github pull requests, automatic checks, and signed-off-by

[Jeff Epler]

On IRC, Chris Radek notes that this would also mean
rewriting/reimplementing the current e-mail integration (emc-commit
list), irc integration (kgb-linuxcnc), and buildbot integration.  This
is technically doable with github's webhooks, but needs additional
developer time.

Jeff

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] github pull requests, automatic checks, and signed-off-by

[Jeff Epler]

I have about an 80% solution to checking signed-off-by and showing it on
github pull requests as an automated check.  You can see a PR that
satisfies our policy here in my personal github fork:

https://github.com/jepler/linuxcnc/pull/3

(for some reason you have to be signed in on github to see the result of
checks.  then click the "show all checks" link just below the list of
commits)

This requires a service hosted on public http(s); my chosen
implementation uses apache and python along with some random internet
and github components to glue everything together.

The remaining 20% would be moving the implementation to a better site
than one of my personal websites, and making sure it's robust. (I'd
probably put it on the VM that hosts forum.linuxcnc.org, since I
administer it, it'll be easy to set up another virtual host and install
the dependencies)

I'm just wondering: should I spend further time on this?


Github "checks" are advisory only; nothing stops a dev clicking "merge
pull request" if checks are incomplete or failed.  This is in stark
contrast with our current SOB checking, which is mandatory; client side
"git push --force" cannot bypass this check.

We could do one of the following:

a. nothing.  this is easiest.

b. finish implementing this.  this is good, because patch submitters
   will get an automated notice pointing them at our SOB policy; and
   devs who are considering whether to work on merging a PR can see
   early if this will prevent pushing them to glo

c. finish implementing this, and decide it's good enough to replace the
   mandatory check and allow us to use the "merge pull request" button.
   
   This would make github our primary git server.  I would advise that
   we retain our project git server at git.linuxcnc.org as a hedge
   against github downtime or a cultural shift that makes github less
   desirable to use.

I am personally stuck between options b and c.  I think that c would
require an IRC vote, since the current policy was adopted by IRC vote.
What do my fellow devs think?

Jeff

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Github PRs

[Jeff Epler]

On Wed, Aug 10, 2016 at 03:56:02PM -0500, John Morris wrote:
> Thanks, Jeff.  In the future, what would you guys prefer I do?  Perhaps, 
> when I want an automated build, push directly to glo; and when I want to 
> propose a change set for merge, submit a Github PR?

If you have push access on glo that sounds like a fine interim solution.

Jeff

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Github PRs

[Jeff Epler]

On Wed, Aug 10, 2016 at 12:47:25PM -0500, John Morris wrote:
> I just noticed that the issue tracker has moved to Github, and 
> linuxcnc.org/community now says PRs should be sent there.  I love a lot 
> of things about Github, so that's great!
> 
> I don't see that the LinuxCNC Github repo is integrated with the 
> Buildbot, is that true?  My PR#135 isn't being built, but it was 
> submitted just a few minutes ago; maybe I'm too eager.

No, the buildbot doesn't integrate with github.  Somebody with the
ability to push directly to our private git server, git.linuxcnc.org,
has to do that in order to get a buildbot test of proposed changes.

I'll see if I can't twiddle the right knobs to do that now... ok, that
seems to be working.

Jeff

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] master : loading a program changes optional stops setting

[Jeff Epler]

On Fri, Jul 22, 2016 at 12:07:33PM +0200, Niemand Sonst wrote:
> Hallo,
> 
> found another strange behavior:

Everything is terrible.  Please file an issue on github.

Jeff

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Copying values from pins to signals: What's the right algorithm

[Jeff Epler]

On Thu, Jul 21, 2016 at 04:10:05PM +0100, andy pugh wrote:
> On 21 July 2016 at 16:00, Jeff Epler <jep...@unpythonic.net> wrote:
> > net estop-out charge-pump.enable iocontrol.0.user-enable-out
> 
> 
> Is a simple workaround (for the moment) to make the configs look like:
> 
> net estop-out  iocontrol.0.user-enable-out
> net estop-out charge-pump.enable
> 
> ?
> 
> (or, in fact, does switching the order of the pins in the net
> statement change the behaviour?)

Yup, I think this would help (except for all the problems that come with
editing the files stepconf/pncconf generate)

Jeff

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Copying values from pins to signals: What's the right algorithm

[Jeff Epler]

We recently noticed a weird problem with stepconf-generated
configurations: During startup, the charge pump (which is supposed to be
linked to estop) activates for a huge fraction of a second.

This turns out to be due to a change made between 2.5 and 2.6:

commit 51a0afc7639461edb58b0e495da1d26e5b7d4f75
Author: Michael Haberler 
Date:   Mon Mar 17 09:31:30 2014 +0100

hal/link/unlink: revise semantics of hal_link()/hal_unlink():

old behavior: a pin's default value would be overwritten by a signal value
on link, effectively making the default pin value invisible outside the
component, and potentially causing a jump in the pin's value on link.

an unlink would re-apply the pin's hidden default value regardless of the
signal value, also causing a potential jump in the pin's value on unlink.

new behavior: the very first link of a signal to a pin will make the
signal inherit the pin's value. On unlink, the pin's default value will
be set from the current signal value.

The result is:
- no sudden jumps in pin values as a result of link/unlink
- it is now possible to access a pin's default value from other pins
- it is possible to have the changed default value retained on unlink

Change of behavior: Code relying on signal values defaulting to zero
post-linking should be revised to consider:

So far, a new signal value defaulted to 0/0.0/false regardless of
the pin's values linked to it.

Now, the signal will inherit the first linked pin's value.

ref: [Emc-developers] PID bidirectional pins. Mar 16 2014

The discussion in that thread, (which can be found here:

http://mid.gmane.org/CAN1%2BYZVHDRyLhG9MesvZ7EiuxJ4Q3uFyw7LaNQXqfrYrkO7G9A%40mail.gmail.com
) centers around pid.#.Pgain pins, which were "IO" pins at that time and are 
now "IN" pins.

The specific original problem is that writing this:
net estop-out charge-pump.enable iocontrol.0.user-enable-out
causes the power-on value of "charge-pump.enable" (which is TRUE) to be copied
to the signal "estop-out", where it remains until quite a long time later in
startup, when iocontrol finally writes FALSE to iocontrol.0.user-enable-out;
just how long depends on system load, because iocontrol is a free-running task,
not a realtime task.

I think it's important to fix the specific problem that affects 
stepconf-generated
config files (possibly changing stepconf in the process), but also to re-visit
the algorithm hal_link() uses to decide when to copy a value from a pin to a 
signal.

Here's the thought experiment I've been using for myself, and mentioned on IRC:

# (newsig rather than creating via net command, to show that a signal
# can also have an explicit initial value)
newsig S signed
sets S 1
# Note: assume pin PI is direction IN  and power-on value 2
net S <= PI
# Note: assume pin PO is direction OUT and power-on value 3
net S <= PO
# Note: assume pin PJ is direction IN  and power-on value 4
net S <= PJ

show sig S

Note that HAL threads are not started, so the function that updates PO has
never had a chance to run and drive PO's value.

The question is:  What value should S show?

Old LinuxCNC (2.5.x) would show 1, because that value was driven onto S
by sets, and PO has never driven a new value onto S.  Note that if the 'net'
commands are reordered, 2.5.x would always show 1.

Current LinuxCNC shows 2, because the value of the first pin (regardless
of direction) connected to the signal is copied to the signal, and PO has 
never driven a new value onto S.  Note that if the 'net' commands are reordered,
linuxcnc would show different values (2, 3, or 4).

I think it should show 3, because pin P0 is the pin that will drive
the signal, and its power-on value is 3.  Note that if the 'net' commands are
reordered, this method would always show 3.  Specifically, I think that the 
condition
for driving the pin's current value onto the signal should be

 if (( sig->writers == 0 ) && ( sig->bidirs == 0 )) {

so that, as long as the signal was not yet connected to any pin that could
potentially drive it, the value of the pin being linked is copied into the
signal.  But I've revised my opinion about the best fix several times, so I'd
like to get others' thoughts on the matter.

Jeff

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] "uspace plus": Ready for testing and code-review

[Jeff Epler]

"Uspace plus", which I originally called "uspace+rtai", is a
modification of uspace realtime to support a total of 4 modes
with a single build (depending on the availabiliy of headers for the
RTAI and Xenomai modes):
* LXRT realtime with RTAI kernel
* "Posix Skin" realtime with Xenomai kernel
* "Posix" realtime with PREEMPT-RT kernel
* Non-realtime with vanilla kernel

This all works great on my test machine, a i7-4790K with Debian Jessie,
and the following kernels:
3.18.0-1-rtai-amd64 (highlab.com)
3.18.20-xenomai-2.6.5 (self-built)
4.1.0-0.bpo.2-rt-amd64 (snapshot.debian.org)
4.4.0-trunk-rt-amd64 (self-built)
4.6.0-0.bpo.1-rt-amd64 (snapshot.debian.org)
so I am ready for testers and for review of the patches.  I *will*
continue rebasing the branch until its inclusion in the master branch,
so take care when fetching new versions.

Known limitations include 
 - hm2_eth and hm2_spi will only work with PREEMPT-RT realtime, since they 
   make Linux syscalls from a realtime context. (this problem is not
   detected, you'll just probably not get good RT performance)
 - until buildbot is reorganized, pre-built linuxcnc-uspace packages
   will not include RTAI support
 - It's not clear what range of RTAI versions can be supported with
   the same binary.
 - Xenomai kernels are "build it yourself", though their directions are
   clear and easy to follow.

The diff relative to our master branch at the moment looks big:
 59 files changed, 18564 insertions(+), 249 deletions(-)
this is because in order to support older Linux distributions, I include
a copy of some newer boost headers.  Ignoring this, the diff is much
smaller:
 22 files changed, 890 insertions(+), 242 deletions(-)
each new RTOS is under 200 lines of code. (is there an alternative to
boost's lockless queue that would be in all Linux distros we are
targeting for master branch, and not RTOS-specific?)

The code is on git.linuxcnc.org and github.com/linuxcnc/linuxcnc in
branch jepler/master/uspace-plus and
https://github.com/LinuxCNC/linuxcnc/pull/110

When you configure linuxcnc, specify --with-relatime=uspace and look for
which RTOSes were detected to support:
checking for realtime API(s) to use... uspace+lxrt+xenomai

If you give this a try, or if you review the changes and have any notes
for me, please put them on the pull request
https://github.com/LinuxCNC/linuxcnc/pull/110 or on this mailing list.

Jeff

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] exec() in Python3

[Jeff Epler]

On Sun, Jul 17, 2016 at 06:20:09AM -0500, John Thornton wrote:
> Thanks so much for the help Jeff and yes I'm working with Glade 3.16.1 
> and Python 3.4.3
[...]
>  vars(self)['button'+str(index)] = Gtk.Button(label=item)

I was not familiar with vars(), which is in Python 2.7.9 and Python
3.4.2.  I'll have to remember that one, it seems preferable getattr().

Jeff

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] exec() in Python3

[Jeff Epler]

In general, you shouldn't use exec() at all.

First and best option, make self.button be a list of buttons, so that
you can write self.button[index].

You may be working with an object structure you can't control (like
glade or something), in which case use getattr:
self.grid.add(getattr(self, 'button%d' % index))

You could put this getattr behind a method, so that you don't have to
repeat it at each site where you need to refer to a button by index:

def button(self, i): return getattr(self, 'button%d' % index)
...
def anothermethod(self):
self.grid.add(self.button(index))

Jeff

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] The best way writing man pages?

[Jeff Epler]

Ah I see now that your workflow is not asciidoc -> man.  I prefer to
maintain "man" as the primary viewer for component documentation in
LinuxCNC, so unfortunately it's not a matter of just snagging your
commit and fixing up any conflicts.  :-/  I am still glad to have it to
study, however!

Thanks again,
Jeff

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] installed new linuxcnc on my original machine, conversion script blew up

[Jeff Epler]

andy,

try putting a commented-out [HALUI] section in a file that doesn't
otherwise have one..

#[HALUI]
#oops = true

I think this reproduces gene's reported error.

I made this educated guess because 'copysection' doesn't anchor its
search for the section to the beginning of a line

def copysection(block):
#Just makes a straight copy of blocks that don't need any work
regex = "\[%s\](.+?)(?:\n\[|$)" % block

while all_sections does:

all_sections = re.findall("^\[(.+)\]", inistring, re.MULTILINE)

The code in copysection may also misbehave if there's a [ inside a
value:

THINGS_I_LIKE = [HALUI]

Jeff

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Now with Xenomai support (was Re: Preview: "uspace+rtai")

[Jeff Epler]

On Sat, Jul 09, 2016 at 05:27:39PM -0500, Jeff Epler wrote:
> What probably could work with more effort?  [...] Xenomai support, if
> anybody wants to use that flavor of kernel

I went ahead and implemented this too.  It's now in that pull request's
branch.

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Preview: "uspace+rtai" (uspace realtime with RTAI kernel)

[Jeff Epler]

On Sat, Jul 09, 2016 at 05:51:45PM -0500, Jon Elson wrote:
> On 07/09/2016 05:27 PM, Jeff Epler wrote:
> >
> > The code is at https://github.com/LinuxCNC/linuxcnc/pull/108 and is
> > currently being rebased frequently.  If you give it a try, I would love
> > to hear your feedback in this thread or on the issue on github.
> >
> >
> OK, we established that the PPMC driver works OK with the 
> old uspace.  Is there any concern that it might not work 
> with uspace or rtai with this new rtapi?

I expect it to be fine, but I haven't tested it (I don't have any of
your cards, but I do have some mesa cards I could test with if I dug
them out).

Jeff

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Preview: "uspace+rtai" (uspace realtime with RTAI kernel)

[Jeff Epler]

I'm excited about some work I've done recently, which I'm calling
"uspace+rtai".  It raises the possiblity that, with a single linuxcnc
binary package we could support a wide range of kernel versions, both
RTAI and PREEMPT-RT, with just 200 new lines of code and 1 new object
file needed for RTAI.


Since LinuxCNC 2.0, we've had a fairly stable realtime API, called
RTAPI.  But for a very long time, the only sort of RTOS that worked with
LinuxCNC was RTAI, and in this case all the real-time parts of LinuxCNC
had to be built as kernel modules.  Since the Linux kernel doesn't have
a stable ABI, this meant it was necessary to build LinuxCNC differently
for each individual kernel -- right down to a single kernel
configuration change!  This is one reason we're so slow to get packages
for new Linux distribution versions.

In LinuxCNC 2.7, we finally got "uspace" (which I now mentally
think of as "uspace+posix"), a realtime implementation that relies only
on Linux userspace APIs and POSIX threads, and which gives good
performance on many machines when paired with kernels that have the
"preempt-rt" patch set.  I built on the experience of (if not directly
on the code of) Michael Buesch and Machinekit contributors when I
implemented this.  This works pretty great, and the same build of
LinuxCNC works on a wide range of preempt-rt kernels, all the way from
Linux 3.2 to Linux 4.6, without recompiling anything.  On the other
hand, the systems I've personally tested with "preempt-rt" don't have
good enough latency for software step generation systems, with latencies
of over 100us (though some report systems that are better), so it's not
anywhere near a universal solution.

When I wrote uspace, I was aware that RTAI (and, I think, Xenomai) have
userspace realtime models; RTAI's is called LXRT.  I made some educated
guesses about what APIs in RTAPI would need different implementations
for different underlying RTOSes, and designed an abstract class
(RtapiApp) that would permit different implementations.

For a long time, nothing happened; then I became interested in actually
finishing the implementation for RTAI LXRT.  It seems to be a success:
The required code to support RTAI is under 200 lines, and the total
diff relative to our master branch at the moment is
 14 files changed, 487 insertions(+), 165 deletions(-)

Because of the way RTAI's LXRT is designed, it appears that a binary
built with a particular RTAI release would work with any kernel version
as long as it is patched with a matching RTAI patchset; I haven't done
any checking to find out whether the LXRT ABI changes frequently or
infrequently between RTAI releases.


Enough background.  As to the state of my branch, let me anticipate and
answer some questions:


What do I think works?  Any realtime components that use only RTAPI APIs.

What have I tested?  "runtests", AXIS with a software stepgen parport
config, detecting hostmot2 hardware, etc.  Base computer: Debian Jessie
with Seb's 3.18.0-1-rtai-amd64.

What probably doesn't work?  hm2_eth and hm2_spi, since they work by
Linux syscalls.

What probably could work with more effort?  I would love to see socket
APIs in RTAPI which can either talk to Linux sockets (syscalls) or
RTNET.  I don't know how feasible this is, and I've never used RTNET in
the first place.  Ditto Xenomai support, if anybody wants to use that
flavor of kernel.  In both cases, though, I'm not planning to write it.
(But if you want to do this work 'out-of-tree', I will absolutely help
structure LinuxCNC to facilitate this; use our issue tracker or this
mailing list if you have ideas for that.  For instance, my tree is
probably close to being able to enable support for a different RTOS to
be built with just the linuxcnc-dev package installed)

What's left before it hits master?  Mostly packaging, reacting to
feedback from testers, and getting the permission of Moses in his RM
capacity.

What might the future hold?  I hope that someday we can get rid of
kernel modules in linuxcnc entirely.  Software bugs in LinuxCNC are less
likely to wedge the whole system, debugging is better, and it opens the
door to using C++ in components and drivers. (I'm not proposing to break
linuxcnc's ability to build kernel modules in 2.8)


The code is at https://github.com/LinuxCNC/linuxcnc/pull/108 and is
currently being rebased frequently.  If you give it a try, I would love
to hear your feedback in this thread or on the issue on github.

Jeff

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net

Re: [Emc-developers] The best way writing man pages?

[Jeff Epler]

Thanks for the pointer!  Would you be interested in preparing a
pull-request for linuxcnc so that the authorship information can be
correctly preserved, or should I just do a little copy and paste?

Jeff

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] The best way writing man pages?

[Jeff Epler]

It's LinuxCNC, we love to have many ways of doing things.

I'm writing this answer assuming that the goal is to include the
component in LinuxCNC's git tree.

If you are writing a component in .comp format, putting man code in
the docstrings is the way I recommend, though it is the clumsiest
because backslashes for formatting directives like \fI and \fR have to
be doubled to \\fI and \\fR.  This gets automatically converted and
added when the .comp file goes through our build process.

(If you wish you could write asciidoc in a comp file, you're not alone.
I would love to see a feature to do this added to halcompile!)

Otherwise, you can write the documentation in asciidoc format.  This
involves putting the file in docs/src/man/man9 (for realtime components)
or .../man1 (for non-realtime components).  I think additions in these
directories are also picked up automatically by our build system.

If you really like writing man markup directly, then you can put it in
docs/man/man9 or .../man1 and again it should automatically get picked
up by the system.

Jeff

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] [PATCH] halcompile: reject non-unix-style line endings

[Jeff Epler]

Signed-off-by: Jeff Epler <jep...@unpythonic.net>
---
Untested, natch.

 src/hal/utils/halcompile.g | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/hal/utils/halcompile.g b/src/hal/utils/halcompile.g
index ca59af3..b489979 100644
--- a/src/hal/utils/halcompile.g
+++ b/src/hal/utils/halcompile.g
@@ -119,6 +119,10 @@ def _parse(rule, text, filename=None):
 def parse(filename):
 initialize()
 f = open(filename).read()
+if '\r\n' in f:
+raise SystemExit, "%s:0: File contains DOS-style line endings, cannot 
continue" % filename
+if '\r' in f:
+raise SystemExit, "%s:0: File contains Mac-style line endings, cannot 
continue" % filename
 a, b = f.split("\n;;\n", 1)
 p = _parse('File', a + "\n\n", filename)
 if not p: raise SystemExit, 1
-- 
2.1.4


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] DISCUSS: Merge the "joints-axes" project to master branch

[Jeff Epler]

On Fri, Jun 10, 2016 at 09:01:43PM -0500, Jeff Epler wrote:
> I propose that we vote the following items at the next IRC meeting
> (Saturday, June 25, 2016-06-25T1600Z):
> 
> That we
>  * Thank all developers who have contributed to the joints-axes project,
>but particularly Dewey Garrett, Michael Geszkiewicz, Alex Joni, and
>Andy Pugh for their major contributions
>  * Rebase and then merge the most current "joints-axes" branch to the
>linuxcnc.org master branch
>  * Recommend to developers and to release manager Moses McKnight
>to shift the emphasis of master branch development to stability
>rather than new features, so that we can release "2.7+1" with JA
>features sooner rather than later

All the items passed unanimously.  Here's the log prepared by
: http://meetlog.archivist.info/meeting.php?id=201606

Thank you, Dewey, Michael, Alex, and Andy!

For the status of the merge, you can keep your eye on
https://github.com/LinuxCNC/linuxcnc/pull/85
.. it looks like Seb has finished the rebase he wanted to, so I'm not
actually sure what we're waiting on.

I would also like to thank everyone who participated in the IRC
meeting, and everyone who chimed in on this thread with their support
for and positive experiences with the features added in the
"joints-axes" branch.  Thank you all.

Jeff

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Gremlin parsing code with infinite loops

[Jeff Epler]

http://linuxcnc.org/docs/2.7/html/gui/axis.html#axis:preview-control

I *believe* the special handling code is in the portion that is shared
between axis and gremlin, so try using (AXIS,stop) at the point you want
to end the preview.

Jeff

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] DISCUSS: Merge the "joints-axes" project to master branch

[Jeff Epler]

Just a reminder that we will hold IRC voting about these items soon.  If
you have any viewpoints that have not already been raised during the
mailing list discussion, please raise them ASAP.

Jeff

On Fri, Jun 10, 2016 at 09:01:43PM -0500, Jeff Epler wrote:
> I propose that we vote the following items at the next IRC meeting
> (Saturday, June 25, 2016-06-25T1600Z):
> 
> That we
>  * Thank all developers who have contributed to the joints-axes project,
>but particularly Dewey Garrett, Michael Geszkiewicz, Alex Joni, and
>Andy Pugh for their major contributions
>  * Rebase and then merge the most current "joints-axes" branch to the
>linuxcnc.org master branch
>  * Recommend to developers and to release manager Moses McKnight
>to shift the emphasis of master branch development to stability
>rather than new features, so that we can release "2.7+1" with JA
>features sooner rather than later
> 
> We haven't held an IRC meeting for quite some time, so if you are
> unfamiliar with the process (I am!) you can read about it on our wiki:
> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MeetingsOnIRC
> The next step is to discuss the merits of the proposal in this mailing
> list prior to the IRC meeting and vote.
> 
> If you are unfamiliar with "joints-axes", it is a project to improve how
> LinuxCNC handles machines which do not have a simple 1-to-1
> correspondence between motors and axis letters.  For example, a gantry
> with 2 motors on the "Y" axis works much better with the new features
> that "joints-axes" adds: you can jog any axis incrementally, and apply
> soft limits to axes.  Users of more exotic machines like the "linear
> delta" will also see improvements.
> 
> Documentation for this branch is online, particularly conversion
> instructions for .ini and .hal files:
> 
> http://linuxcnc.org/docs/ja/html/getting-started/updating-linuxcnc.html#_hal_changes_updates_for_joints_axes
> 
> If you are aware of regressions in the joints-axes branch, I encourage
> you to document them with github issues as soon as possible, and request
> that we tag them with the (just added) joints-axes label so we can track
> them.
> 
> Jeff
> 
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
> 

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] DISCUSS: Merge the "joints-axes" project to master branch

[Jeff Epler]

I propose that we vote the following items at the next IRC meeting
(Saturday, June 25, 2016-06-25T1600Z):

That we
 * Thank all developers who have contributed to the joints-axes project,
   but particularly Dewey Garrett, Michael Geszkiewicz, Alex Joni, and
   Andy Pugh for their major contributions
 * Rebase and then merge the most current "joints-axes" branch to the
   linuxcnc.org master branch
 * Recommend to developers and to release manager Moses McKnight
   to shift the emphasis of master branch development to stability
   rather than new features, so that we can release "2.7+1" with JA
   features sooner rather than later

We haven't held an IRC meeting for quite some time, so if you are
unfamiliar with the process (I am!) you can read about it on our wiki:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MeetingsOnIRC
The next step is to discuss the merits of the proposal in this mailing
list prior to the IRC meeting and vote.

If you are unfamiliar with "joints-axes", it is a project to improve how
LinuxCNC handles machines which do not have a simple 1-to-1
correspondence between motors and axis letters.  For example, a gantry
with 2 motors on the "Y" axis works much better with the new features
that "joints-axes" adds: you can jog any axis incrementally, and apply
soft limits to axes.  Users of more exotic machines like the "linear
delta" will also see improvements.

Documentation for this branch is online, particularly conversion
instructions for .ini and .hal files:

http://linuxcnc.org/docs/ja/html/getting-started/updating-linuxcnc.html#_hal_changes_updates_for_joints_axes

If you are aware of regressions in the joints-axes branch, I encourage
you to document them with github issues as soon as possible, and request
that we tag them with the (just added) joints-axes label so we can track
them.

Jeff

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] qemu-arm-user works for cross-building linuxcnc

[Jeff Epler]

On Wed, May 25, 2016 at 11:43:37PM -0600, EBo wrote:
> Jeff,
> 
> This looks very interesting!  Do you have any extended instructions on 
> this, or is this all we have?

There's better documentation on the internet about using
qemu-debootstrap and schroot than I could write.  Once inside the
chroot, building linuxcnc is just like building it in a regular Debian
installation, because it is a regular debian installation.

> Also, since you are targeting jessie-armhf, is this a RPi hardware target?

I don't have any specific needs for ARM hardware.  I like to know we
build and run on ARM because being portable to different architectures is
a good indicator of software quality, and I like to know that when
someone who does have ARM hardware needs comes along, the base system
will work right for them to write (and hopefully contribute) hardware
drivers.

Plus I just wanted to try out this kind of emulated environment, and
once I learned about the major caveat that prevents running our
testsuite, I did want to make sure that got noted somewhere.  The
mailing list seemed like the easiest way to do that.

Jeff

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Bug: Coordinate system discrepancy in preview

[Jeff Epler]

On Fri, May 13, 2016 at 03:37:21PM -0500, John Morris wrote:
> I'm trying to make sense of some strange behavior in preview.  See the
> program, attached and pasted below, which documents the problem.
> 
> Is this a known bug?

Not to me before now.  But confirmed in 2.6 and 2.7 branches.

Jeff

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] More than 8 stepgen

[Jeff Epler]

Patch welcome.  It's probably trivial.

Jeff

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Fanuc_tooltip_orientation patch

[Jeff Epler]

Thank you for offering this patch to improve LinuxCNC.

I don't know enough about lathes or fanuc gcode to evaluate whether the
general idea of changing orientation numbers in this way is right or
wrong.  I hope someone else will be able to do this.  Instead, my notes
below are all boring technical stuff.

This patch is not "Signed-Off-By".  Without this special line in a
commit message, our policy states that we cannot incorporate your change
into linuxcnc.  See our contributor documentation for what this line
means and how to add it to your commit message.

This patch does not add documentation for the new feature.  Without
documentation, new users cannot discover the functionality for
themselves.

However, I don't see what happens to orientation when a tool table file is
rewritten.  For instance, the value 2 is read from a file and converted
to 3 in memory.  Later, a gcode such as G10 L10 P1 R[1/8] is executed
(set radius of tool number 1 to [1/8]) that causes the whole tool table
to be written.  It appears to me, without testing, that the value 3 will
be written to the table, which will not have the correct meaning when
the table is next read in, such as when starting the machine the next
time.

>  toolTable[pocket].backangle = backangle;
> + if (fanuc_tooltip_orientation) {
> + if (orientation == 2) toolTable[pocket].orientation = 3;
> + else if (orientation == 3) 
> toolTable[pocket].orientation = 2;
> + else if (orientation == 6) 
> toolTable[pocket].orientation = 8;
> +else if (orientation == 8) toolTable[pocket].orientation 
> = 6;
> +else if (orientation == 1) 
> toolTable[pocket].orientation = 4;
> +else if (orientation == 4) 
> toolTable[pocket].orientation = 1;
> +else toolTable[pocket].orientation = 
> orientation;
> + }
> + else
>  toolTable[pocket].orientation = orientation;

This indentation is very irregular.  The 'if' shold be indented as much
as the line above it, and all the lines inside should be indented the
same, more like this:
toolTable[pocket].backangle = backangle;
if (fanuc_tooltip_orientation) {
if (orientation == 2) toolTable[pocket].orientation = 3;
else if (orientation == 3) toolTable[pocket].orientation = 2;
else if (orientation == 6) toolTable[pocket].orientation = 8;
else if (orientation == 8) toolTable[pocket].orientation = 6;
else if (orientation == 1) toolTable[pocket].orientation = 4;
else if (orientation == 4) toolTable[pocket].orientation = 1;
else toolTable[pocket].orientation = orientation;
}
else
toolTable[pocket].orientation = orientation;

LinuxCNC's coding style is that tab characters are always displayed as 8
spaces, but the indentation level is 4 spaces.  Either configure your
editor to insert 4 spaces when you type tab, or always type 4 spaces
manually to set indentation.

Jeff

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] [Emc-commit] joints_axes12: tests/ fixes for ini files requiring JA update

[Jeff Epler]

On Sun, Mar 13, 2016 at 09:00:35PM +, Dewey Garrett wrote:
> Numerous tests that use an ini file have not been exercised recently in the
> joints_axesNN branches because the linuxcnc script invokes the update_ini
> script which (when running non-interactively) exits with a tkinter error but 
> ok
> (0) status.  Thus, the tests are not executed (nor is an updated ini file 
> created
> by the update_ini script).

Ouch.  Good catch.  What should we do to avoid having these tests fail
silently in the future?

Jeff

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] About the header file "ioctl.h" in HAL?

[Jeff Epler]

It sounds like you are using RTAI realtime, which builds all realtime
components as kernel modules.

The header  is not suitable for use when building a kernel
module.

Since no drivers in linuxcnc use rtnet, I do not have any examples to
point you towards.  I suggest you read rtnet documentation, it should
clarify what headers you can use for networking features.

The existing ethernet driver in linuxcnc 2.7, hm2_eth, only works with
"uspace" realtime where realtime runs as a standard linux process but
real-time scheduling priority.  Components are just shared libraries,
and hm2_eth makes regular userspace socket calls.

Jeff

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] how to use my own shared library in HAL?

[Jeff Epler]

first off, for kernel-based realtime (rtai), this is not possible at
all.

second, assuming you are going to call into this shared library from
uspace in a realtime context, you will need to audit the library source
code to make sure it is not making any API calls that are not OK for
realtime.

All that said: This is technically possible for uspace realtime but is
not currently facilitated by halcompile or "Makefile.modinc" which is a
Makefile fragment that it uses to actually do the work of building a .so
realtime component.

I will be happy to review patches to improve/fix this.  Basically, it
would be necessary to:

 * change Makefile.modinc.in so that it can supply extra linker
   arguments under the "%.so:" rule near where -lm is currently
   hard-coded (src/Makefile.modinc.in)

   We use some trickery regarding symbol visibility in .so realtime
   components, so that the EXPORT_SYMBOL directives are obeyed.  Right
   now the trick used in Makefile is newer and probably better than the
   one in Makefile.modinc.in.  I'm not sure whether either trick affects
   the ability to link in other libraries, but the newer trick is more
   like the normal way shared library symbol visibility is managed on
   Linux.  We should probably update Makefile.modinc.in to use the new
   trick, particularly if the old trick causes problems with additional
   shared libraries

 * change halcompile so that it can receive these extra arguments as
   commandline arguments and pass them on to make via the commandline
   (src/hal/utils/halcompile.g).  If it's feasible, halcompile should
   also refuse to accept the arguments if the realtime is not uspace.

 * document these features in the manual (docs/man/man1/halcompile.1,
   docs/src/hal/comp.txt)

 * and write a new test under tests/halcompile/ that shows these
   features work.  

Please be aware of our policy to use Linux Kernel-style Signed-Off-By
http://linuxcnc.org/docs/2.7/html/code/contributing-to-linuxcnc.html#_signed_off_by_policy

You can use several methods, such as a github pull request, to share
your patches for review:
http://linuxcnc.org/docs/2.7/html/code/contributing-to-linuxcnc.html#_linuxcnc_on_github

Jeff

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Subroutine handling changes 2.7.0 to 2.7.3 ?

[Jeff Epler]

just looking at git logs real quick

commit 135389587230ac9a56caba9a44fe3f2836861262
Author: John Morris 
Date:   Mon Oct 26 16:11:27 2015 -0500

Bugfix:  Start line and remap interaction

the commit message explains in further detail what it intended to fix.

Jeff

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] testing change to pncconf

[Jeff Epler]

On Mon, Feb 08, 2016 at 07:08:05AM -0800, Condit Alan wrote:
> Is the python source available on the standard user install so that I
> can edit it and test the change or do I need to install the developer
> source and run make?

I strongly advise against ever editing a file installed from a package
(other than a configuration file in /etc)  If you do, the changes will
be silently overwritten when you receive an update.

You also can't use git format-patch to send us correct patches, but end
up describing in prose what change needs to be made; this only consumes
the time of the developer who volunteers to recreate your change and
properly make it in git.

Jeff

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Stepconf and Gtk3

[Jeff Epler]

For your information, I just updated our wiki page
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions with
information about the gtk3 version availability on our various supported
platforms.

Assuming the information I recorded is accurate, it is necessary to
support gtk 3.x versions back to 3.4.2 for new features in the master
branch.

I am the original author of stepconf but I am now so unfamiliar with it
that I am probably not a good person to review your changes.  Chris
Morley may be the one with the most familiarity today, he has certainly
made most of the recent changes and enhancements to it.

Are there any user-visible benefits to upgrading to gtk3, or are the
benefits primarily in addressing technical debt?

Jeff

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Error during make

[Jeff Epler]

On Wed, Jan 06, 2016 at 05:55:42PM +0100, Niemand Sonst wrote:
> emc/rs274ngc/interp_remap.cc:200: error: ‘end’ is not a member of ‘std’

I did verify that, unlike last time, std::end is missing on the Ubuntu
10.04 machine I have access to (so it's not simply a missing header
again):

$ cat std_end.cc
#include 
const char c[]{1,2,3,4};
auto p = std::end(c);

[on ubuntu 10.04]
$ g++ -std=c++0x std_end.cc && echo success
std_end.cc:3: error: ‘end’ is not a member of ‘std’
std_end.cc:3: error: unable to deduce ‘auto’ from ‘’

[on debian wheezy]
$ g++ -c -std=c++11 std_end.cc && echo success
success

Use of std::end was introduced at commit e38ff45f16 to fix real (if
minor) technical debt; because the new code is type safe, if the
underlying type of the members missing, optional and so forth change so
that they cannot be initialized by the literal constant 0, it will be a
compiler error.  Before my change, the type of these members did not
matter; they would be initialized to all-bits-zero which is undefined
behavior if they are later changed to some C++ types that are not "plain
old data".

At this point I choose not to make any further efforts to fix master
branch support for Ubuntu 10.04.  If someone else produces patches to do
this, I will do my best to evaluate them impartially, but as I have
explained I view the change as important and would not like to see it
simply reverted.

Jeff

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

Re: [Emc-developers] Axis bug in 2.7.3 (was: Question on a change in Axis from 2.5 to 2.7.3)

[Jeff Epler]

There are many tutorials online which describe how to use git bisect.
Here's one:
https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git#Binary-Search

You would simply configure and build a RIP version of linuxcnc at each
step of the binary search, then test it for whether the bug is present
or not.  The end result, if your testing procedure was correct, is that
you know at what commit the behavior you are testing changed.

Unfortunately, in lengthy bisects without a fully automatic testing
procedure, I often make mistakes and initially let blame fall on an
incorrect commit.

I also don't have any theory why specifying one axis name vs two axis
names would reliably change the behavior of the reload function.

> G10 L20 P1 X0Y0
vs
> G10 L20 P1 X0
which (aside from the name) seems to be the only difference between the
two bits of code.

As I tired to indicate in my initial reply in this thread, I am not
particularly committed to making "axis remote --reload" work while an
MDI is actively executing; I think this is a mistaken idea.  It was an
initial design decision in AXIS that a change to the active coordinate
system that was *NOT* done by AXIS own touch-off would never trigger an
automatic reload.

Perhaps *this* is the decision that should be revisted; I would consider
a patch which would optionally trigger a reload when the active g5x
offset or g92 offset was changed, at the next moment that AXIS believes
it is OK to perform a reload (e.g., after the MDI that generated the
coordinate system change was finished)

This could be controlled by an inifile option or a menu option.
Probably the former would be preferable for you, so that an operator
can't make the wrong setting at runtime.

Jeff

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

Re: [Emc-developers] Axis bug in 2.7.3 (was: Question on a change in Axis from 2.5 to 2.7.3)

[Jeff Epler]

Yuck.  I am sorry that this got worse between 2.5 and 2.7, but it is
likely that there is no simple fix.

I think the root of the problem you're having is that:
 * AXIS has to change modes to AUTO to actually (re)load a part
   program
 * but at the time you make the reload request, you are in MDI mode and
   an MDI command is executing
 * so AXIS can't change to MDI mode right away (this is why it becomes
   unresponsive for a bit)
 * after this, the event-driven nature of GUI programming means that
   some function gets called when it shouldn't, resulting in the actual
   error message displayed.

The comment block above the root_window.update() states why it is there:
to ensure that key presses that occurred while the program was loading
are discarded, rather than processed.  It has also been there for a long
time, well before 2.5.x. (in fact all the way back to before AXIS was
integrated with the program once known as EMC, if my spelunking in the
project history is accurate!)

Unfortunately, the update also handles other events, such as the
periodic checking of HAL pin changes or the reception of requests sent
by axis-remote.  These are inapproriate events to handle.  But there's
not sufficient control over *what kind of events* update() will handle.
:(

Without further analysis, I am loathe to simply remove that line.  But
if you are making local modifications to linuxcnc anyway, then go ahead
and do whatever you need to do to make your system work like you need.

If you do have additional analysis (such as what specific commit broke
it, which may be findable using git bisect since you have a good
procedure to reproduce the problem) or an alternative solution, please
let us know what you are able to learn.

Jeff

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

Re: [Emc-developers] Error during make

[Jeff Epler]

use make V=1 to print the commands as they are executed.

Hm, in my example program I made sure to include , but 
isn't included in rs274ngc_interp.hh.

I just pushed this change to master branch which may fix it:

commit 18517a3ee9cffe35a27c12d14b314e77794459aa
Author: Jeff Epler <jep...@unpythonic.net>
Date:   Sun Jan 3 13:54:04 2016 -0600

task: include  for std::nearbyint

Signed-off-by: Jeff Epler <jep...@unpythonic.net>

diff --git a/src/emc/rs274ngc/interp_internal.hh 
b/src/emc/rs274ngc/interp_internal.hh
index 6df90b1..f2eb3a9 100644
--- a/src/emc/rs274ngc/interp_internal.hh
+++ b/src/emc/rs274ngc/interp_internal.hh
@@ -24,6 +24,7 @@
 #include "emcpos.h"
 #include "libintl.h"
 #include 
+#include 
 
 
 #define _(s) gettext(s)

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

Re: [Emc-developers] Who changed the requiered python version?

[Jeff Epler]

On Sat, Jan 02, 2016 at 01:08:41PM +0100, Niemand Sonst wrote:
> I took the first hurdle, the UEFI Bios and could install Debian 8.2 - 
> amd64 - MATE, but the second hurdle installing LinuxCNC from the ISO 
> could not be taken, because UEFI Bios only accept 64-bit operating 
> systems, even with security boot disabled!

I am sorry you purchased defective hardware.  You should consider
returning it for a refund if you still can.

[...]
> After sorting most of the stuff out, I added the linuxcnc repositories:
> 
> deb http://buildbot.linuxcnc.org/ jessie 2.7-rtpreempt
> deb-src http://buildbot.linuxcnc.org/ jessie 2.7-rtpreempt
> 
> and installed LinuxCNC.
> 
> OK Latency test shows 32035966 ns, that is the highest I ever got! Even a 
> virtual machine is better ;-) But i did no optimation till now.

It is quite likely that after performing these steps *you are not
operating with a realtime kernel*.  uspace will run both on vanilla
kernels (but without using realtime task priority) and on preempt-rt
kernels (using realtime task priority).  Only in the latter case (and if
your computer has acceptable RT performance) will you get good latency.

Unfortunately, a preempt-rt kernel is not currently available from
Debian for 8.x -- there *was* one in jessie-backports, but they deleted
it.

Seb's RTAI kernel for 64-bit systems crashes, so I similarly can't
recommend that.

However, for developing user interface software, uspace non-realtime is
typically adequate.  For running attached hardware over ethernet, not so
much.  I woudln't recommend it even for testing.

> After installing "gstreamer0.10-plugins-base" the start went OK. Jeff could 
> you please add that dependence?

Yes.   Done.

> Neverthereless the code for both GUI must be adapted to avoid such an error, 
> only for not beeing present "sound". I will fix that as soon as my
> new development system is running.
> 
> I do connect the laptop with WLAN0 to the world and want to use eth0 to 
> connect to a MESA 7i76E to control my testing hardware.
> But as far as I found out till now, that will not be possible, because ther 
> is no realtime kernel for Jessie 64 bit
> and the info on buildbot is not correct.

So, nobody has written the install instructions for Debian Jessie with
preempt-rt.  It should be possible using snapshot.debian.org, which
still has an archive of the preempt-rt kernel from jessie-backports.
(The kernel was withdrawn not because it was broken, but because Debian
testing's development moved on to a kernel without a RT patch)

http://snapshot.debian.org/package/linux/4.1.3-1/

.. but having just spent 15 minutes trying to do so I haven't yet been
successful at getting apt to automatically download and install these
packages.

> - Does wheesy support 64 bit completly ?

I used wheezy with preempt-rt kernel in the past.  There is a preempt-rt
kernel in main for wheezy.
https://packages.debian.org/search?suite=wheezy=linux-image-rt-amd64

Jeff

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

Re: [Emc-developers] Error during make

[Jeff Epler]

$ lsb_release  -cr
Release:10.04
Codename:   lucid
$ g++-4.4 -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
4.4.3-4ubuntu5.1' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared 
--enable-multiarch --enable-linker-build-id --with-system-zlib 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc 
--enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic 
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu 
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) 
$ cat nbi.cc
#include 
const auto i = std::nearbyint(3.14);
$ g++-4.4 -std=c++0x -c nbi.cc && echo success
success

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