Done. What would you like for the description text for the category?
Moses
On 1/21/20 8:10 PM, Chris Morley wrote:
Hey I hoping someone can make a Qtvcp catagory under the 'user interfaces'
catagory and make me the moderator.
I'm not sure who to ask directly...
thanks
Chris M
__
On 11/14/19 1:03 PM, Sebastian Kuzminsky wrote:
On 11/14/19 12:35 PM, Moses McKnight wrote:
My vote would be to only support 64-bit going forward. Distributions are
starting to discontinue 32-bit editions as well, and the hardware that is
32-bit only is pretty rare for anything new. For
I suspect that had to do with either your video cable or perhaps the particular
kernel you were testing. I have had that issue on numbers of 32-bit kernels and
the problem has almost always been the video cable or connection (especially
with VGA cables).
I've used 64-bit kernels with the i915
My vote would be to only support 64-bit going forward. Distributions are
starting to discontinue 32-bit editions as well, and the hardware that is 32-bit
only is pretty rare for anything new. For instance, the board in the link you
sent is "available for special order only until factory stock
That sounds like it can go in the 2.8 branch - I'll try and commit it soon.
Thanks Les!
Also, since you reported bug #579
(https://github.com/LinuxCNC/linuxcnc/issues/579), as of yesterday that should
be fixed in the latest 2.7, 2.8, and master branches. So if you would like to,
try using ON_
What Chris says is right - if GUI changes are just in the form of VCP and
configs and all, it is fine with me - and thanks for your work!
Moses
On 7/5/19 2:57 PM, Chris Morley wrote:
The release manager has last say on what can't be added.
Assuming your 'GUI' changes are VCP changes (not say
I *think* QTVCP is not the same thing as QTPYVCP, and if you look at the commit
logs for master it looks like qtvcp was merged into master on Jan 18.
Chris, what are the differences in QTVCP and QTPYVCP? I have not had time to
follow either of those much - although I'm interested in using Qt.
skett wrote:
On Thursday 30 May 2019 02:15:59 pm Chris Morley wrote:
Yes a couple weeks is way too short.
A couple months is more like it.
Chris M
I'm with Chris, see why below.
Original message ----
From: Moses McKnight
Date: 2019-05-30 9:48 a.m. (GMT-07:00)
To: emc-
ana...@hotmail.com>:
Yes a couple weeks is way too short.
A couple months is more like it.
Chris M
Original message
From: Moses McKnight
Date: 2019-05-30 9:48 a.m. (GMT-07:00)
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] 2.8 Release planning
I'm
On 5/30/19 10:51 AM, andy pugh wrote:
On Thu, 30 May 2019 at 16:49, Moses McKnight wrote:
I'm thinking we should give a couple of weeks (depending of course on if
we can
get the work done) to get the initial stuff done and then make an rc1
release
candidate. Then wait a couple of weeks
d etc.
Do you have any other ideas?
On 5/30/19 10:20 AM, Chris Morley wrote:
How long are we giving for bug fixes docs and stabilizing. Roughly?
Chris M
Original message
From: Moses McKnight
Date: 2019-05-30 8:40 a.m. (GMT-07:00)
To: EMC developers
Subject: Re: [Emc-devel
list.
JT
On 5/29/2019 8:04 PM, Moses McKnight wrote:
Hi All,
It seems that there is somewhat of a consensus to release 2.8 with it's
current features plus bugfixes.
This means that major features such as reverse run would not be in 2.8, but
would be merged into master as soon as 2.8 i
Hi All,
It seems that there is somewhat of a consensus to release 2.8 with it's current
features plus bugfixes.
This means that major features such as reverse run would not be in 2.8, but
would be merged into master as soon as 2.8 is branched off.
So this is kind of a last call for comments
I'm glad to see the activity here!
As for development coordination, there are Github Issues and Pull Requests, and
the Wiki is also good for things that may not fit the preceding. I still find
mailing list to be quite useful as well.
On 5/21/19 8:59 PM, Rod Webster wrote:
It would be good
Hi Phillip,
Last I heard there were issues merging reverse-run with master - so that is new
to me! I tend to agree with Chris on this, but I don't know enough about the
state of reverse run. There are bug fixes for the TP ready for 2.7, but a lot
of merge conflicts putting them in master cur
Hi Randy,
Thanks for the offers to help! For IRC, you need to register your nick with
NickServ on freenode in order to post. This was done a little while back
because of a flood of spammers.
https://freenode.net/kb/answer/registration
I volunteered to be the release manager quite a while ba
On 3/20/19 6:59 PM, Gene Heskett wrote:
On Wednesday 20 March 2019 16:14:26 Moses McKnight wrote:
Now y'all are making me nervous! Now what did I do with my backup
tapes...
Tapes? I've been using amanda, with virtual tapes on a big hd for over a
decade, and have found 2 things:
1
On 3/20/19 3:00 PM, Gene Heskett wrote:
On Wednesday 20 March 2019 15:29:10 Peter C. Wallace wrote:
On Wed, 20 Mar 2019, Moses McKnight wrote:
Date: Wed, 20 Mar 2019 13:45:42 -0500
From: Moses McKnight
Reply-To: EMC developers
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc
On 3/20/19 1:01 PM, Gene Heskett wrote:
Now we know of two victims. Stuart and I. :(
Well, that would explain why it didn't get removed from distributions! 2
glitches out of 2 million installs (<-random number), and it is the official
text editor for Gnome.
I suspect a third person probabl
If there are no serious objections I also think that is a good idea.
What about reverse-run which has been mentioned? Is it as well tested and used?
Moses
On 10/19/18 11:53 AM, andy pugh wrote:
On Tue, 2 Oct 2018 at 03:45, Moses McKnight wrote:
Andy asked about the multi-spindle stuff
preciate if this was public (maillist) and not private (IRC) (of
course both is good too)
Thanks
Chris M
________
From: Moses McKnight
Sent: September 19, 2018 2:27 PM
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] New Stuff
I agree that we should
I agree that we should release sooner than later. It would be great if the
issues mentioned by Rene were fixed prior to a release, but realistically some
of those may take a while.
Run-from-line for instance has more problems than that mentioned in #246, it
also does very bad stuff if there i
I have not looked at it much, but I have some questions:
What exactly IS it?
What are the advantages of it?
Does it require a bunch of extra dependencies?
Moses
On 09/12/2018 04:20 AM, andy pugh wrote:
On Wed, 12 Sep 2018 at 05:19, Chris Morley wrote:
Seb, Chris, Andy, Jeff - anyone else...
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
On 12/02/2017 07:48 AM, Rene Hopf wrote:
Hi,
Im working on the mode switching issues:
ht
On 07/18/2016 04:19 PM, EBo wrote:
> On Jul 18 2016 3:09 PM, Moses McKnight wrote:
>> On 07/18/2016 03:19 PM, John Kasunich wrote:
>>>
>>>
>>> On Mon, Jul 18, 2016, at 03:28 PM, Chris Morley wrote:
>>>>
>>>> I think the whole mode thi
ce or setup rather than
> normal work. Jogging in cartesean space is extremely
> common.
>
> This train of thought leads me to think that the the
> existing manual mode needs to be split into joint-manual
> (FREE) and axis-manual (TELEOP).
>
> John Kasunich
>
>
On 07/18/2016 01:29 PM, Niemand Sonst wrote:
> Am 18.07.2016 um 20:11 schrieb Sebastian Kuzminsky:
>> On 07/18/2016 11:19 AM, Niemand Sonst wrote:
>>> OK, I think I found the problem, but I will need help to solve this issue!
>>> I do not know C++, sorry:
>>>
>>> Please take a look at emc/task/emct
Hi all,
In accordance with the recommendation from the last IRC meeting, I plan to make
a "feature freeze" and make a new branch for the next release in the near
future. The joints/axes project merge is a pretty major thing and we would
like
to release this sooner than later.
So does anyone
Hi all,
The joints-axes branch has now been merged into master! Joints/axes was a
project to separate "joints" from "axes" in order to better support machines
where a single motor does not directly drive motion along an axis, such as
gantry machines, robot arms, hexapods, and similar.
Anyone
click just
zoomed, and a button1 click without Shift would pan (move) the part around. Is
that what you intended for it to do? I would have thought you would not want
it
to rotate for lathes either.
Oh, and thanks for adding some documentation for that mode!
Thanks,
Moses McK
After a little more digging, it appears that you should still be able set
traj_period_nsec in the loadrt line in your hal file and the trajectory planner
will run at that rate.
If you set traj_period_nsec slower than servo_period_nsec then the cubic
interpolation will be used, but if not then t
Moving the panel is trivial - right-click on the panel, go to Panel->Panel
Preferences, and uncheck "Lock Panel" if it is checked. Then you should have a
little area at the far left of the panel which you can click, and drag the
panel
wherever you want it.
Moses
On 08/05/2015 03:47 AM, Gene
Hi Curtis,
I think the branch has not seen much activity for a while - everyone is working
on other projects. But, I have a definite interest and hope to get some time
to
look at it soon.
I believe what has been normally happening instead of merging is that the
joints_axisN branch has been d
I think it is just waiting for people to have time to test and fix it, and it
will go into master at some point. Other people probably know the status
better
than I, and I'm sure bug fixes and help is always welcome!
The way I understand it they have be doing a rebase instead of merging, and
workaround using the gladevcp -H option
Moses
On 04/02/2015 08:51 AM, Moses McKnight wrote:
> Thanks for looking at it. Looks like you are in the same boat I am. I saw
> that
> code in axis, but I couldn't follow it either. I was suspecting that the
> processes needed to be wai
Thanks for looking at it. Looks like you are in the same boat I am. I saw
that
code in axis, but I couldn't follow it either. I was suspecting that the
processes needed to be waited on.
I'm thinking it is the c.poll() line in the check_dynamic_tabs function. Hmm,
looking at it now, I think
Thanks, I did figure out I can use -H and add hal files to the gladevcp
commands, and that works.
On 04/01/2015 04:34 PM, Chris Morley wrote:
>
> Perfect. I will look into that when I'm off work. I think you are using 2.7?
> Chris M
>
> - Reply message -
> From:
ing only functions as
callbacks
Registering handlers in module thc_box object
adding import dir .
module 'thc_settings' imported OK
module 'thc_settings' : 'get_handlers' function found
Registering handlers in module thc_settings object
activating GTK bug workar
nd are you using to load the tab? If the tab pins load after
> gscreen this would happen. Seeing code would help.
> Chris M
>
> - Reply message -----
> From: "Moses McKnight"
> To:
> Subject: [Emc-developers] Gscreen runs postgui.hal before embedded tabs are
Hi,
I'm building a custom skin for Gscreen based on the Gaxis skin. I have 2
embedded gladevcp tabs/panels, and HAL widgets on them. In the postgui.hal
file
I connect pins from one of these embedded tabs to pins from my custom component.
In Axis, or just plain Gscreen with no custom skin, th
Here is the post: https://lkml.org/lkml/2015/4/1/118
Notice the date at the top ;)
Here is another good one: https://lkml.org/lkml/2015/3/31/994
On 04/01/2015 06:24 AM, Gene Heskett wrote:
> A contributor to the kernel named Boris, just posted a patch disabling
> the 32 bit build entirely.
>
> I
Here is a patch which makes Gscreen look in the user's local .theme directory
for themes as well as in /usr/share/themes.
It also filters out all the directories that do not contain gtk-2.0 themes. Let
me know if this could be implemented better or needs more checks than I put in.
This patch
"testpanel."+encname,encname+"-signal")
Moses
On 01/19/2015 01:03 PM, Moses McKnight wrote:
> I have no experience using this, but in halmodule.cc I see there is a
> "connect"
> function:
>
> {"connect", connect, METH_VARARGS,
> &
I have no experience using this, but in halmodule.cc I see there is a "connect"
function:
{"connect", connect, METH_VARARGS,
"connect pin to signal"},
On 01/19/2015 12:31 PM, Niemand Sonst wrote:
> Does noboddy have an idea or help for me?
> The hal pin motion.requested-vel do show
Hi,
In playing with JT's GUI tutorial, I tried adding a HAL_GremlinPlus widget to a
notebook page, and it crashes glade a couple of seconds after adding it. The
error shown in the terminal is:
(glade-3:342): Gtk-WARNING **: Attempting to add a widget with type GtkHBox to
a
HAL_GremlinPlus, b
halmake?
On 06/24/2014 10:10 AM, Marius Liebenberg wrote:
>
>
> On 2014-06-24 17:06, Chris Radek wrote:
>> On Tue, Jun 24, 2014 at 02:46:50PM +0100, andy pugh wrote:
>>
>>> "The program 'comp' can be found in the following packages
>>> mailutils-mh nmh" in the obvious way.
>> Maybe we should renam
I would have to agree, that hardy support should not be dropped. We are
dealing with machine controllers here, not merely consumer PC's that
*have* to have (or so people seem to think) the latest everything every
6 months or sooner.
It makes sense to me to not force people running good stable
I'm not sure I understand all this. Isn't kmail the kde email client?
As far as I know you have to install that yourself because it does not
come on the Ubuntu liveCD, which the LinuxCNC liveCD is based on. If
you install Kubuntu it might be installed, but I don't know because I've
never used
On 05/19/2012 03:50 AM, Jan de Kruyf wrote:
> Just a quick note here:
> Xenomai has kernel 3 support for a while already And they have started
> making true on their roadmap regarding Xenomai3.
Where do you see that? I have browsed their git repos several times and
just did again, and have not f
49 matches
Mail list logo
