Re: [Emc-developers] missing arm64 builds for stretch?
On 06/02/18 12:07, emc-developers-requ...@lists.sourceforge.net wrote: Date: Mon, 5 Feb 2018 10:15:20 -0700 From: Sebastian Kuzminsky To: EMC developers , Gene Heskett Subject: Re: [Emc-developers] missing arm64 builds for stretch? Message-ID: <7230e202-1c13-550f-2763-82cc8b511...@highlab.com> Content-Type: text/plain; charset=utf-8; format=flowed That is correct, the buildbot doesn't build/test/package on arm64 yet. The reason for that is that we don't have any arm64 buildslaves. We do have a couple of armhf (32-bit) buildslaves, running on Odroid U3 machines. They are super flaky and unreliable and account for about 90% of the headaches the buildbot produces. I don't want to add any more flaky little machines to take care of. What I want is a server-class arm64 board with several CPUs and a couple of gigs of RAM per CPU, to run virtual armhf and arm64 buildslaves on, just like how the x86 and amd64 buildslaves are managed. 8 CPUs and 16 GB RAM would be comfortable. Does anyone have first-hand experience with any hardware like that? Hi Seb, My advice, rent one from Scaleway, they specialise in arm servers ( both v7 and v8 ) https://www.scaleway.com/armv8-cloud-servers/ I have been using them for a server for remote builds in docker containers and much more for 6 months now, since I was put onto them by John Morris. Their servers are simple to set up, reliable and cheap. No minimum contract, billing by the minute, chop and change whenever you like. I have built machinekit on aarch64 (a pine64 board). The only major issue, was I had to write my own io.h as per https://github.com/machinekit/machinekit/issues/1269#issuecomment-326965404 The rest was just lib dependencies which at the time required custom libs, but now could use the stock ones. regards -- 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 fails to load on Live CD - Uspace
On 27/11/17 17:08, emc-developers-requ...@lists.sourceforge.net wrote: Message: 2 Date: Mon, 27 Nov 2017 14:41:30 + From: "Marius Liebenberg" To: "EMC developers" Subject: [Emc-developers] Gmoccapy fails to load on Live CD - Uspace Message-ID: Content-Type: text/plain; format=flowed; charset=utf-8 Hi Gmoccapy fails to load with the following error when run on the latest live CD installation from here http://www.linuxcnc.org/testing-stretch-rtpreempt/linuxcnc-stretch-uspace-amd64-r9.iso Found an error! The following information may be useful in troubleshooting: Traceback (most recent call last): File "/usr/bin/gmoccapy", line 102, in from gmoccapy import player # a class to handle sounds File "/usr/lib/python2.7/dist-packages/gmoccapy/player.py", line 27, in import gst ImportError: No module named gst The python-gst-1.0 package used in Stretch has deprecated the gst module used by gmoccapy (and gscreen) for the audio player I have removed the dependency for the Machinekit Stretch packages and added a conditional test for the running distro which disables the relevant sections of gmoccapy and gscreen when Stretch is found. Fixes it for now until they are rewritten so as to use something else https://github.com/machinekit/machinekit/commit/e125fea793319a8aace0ef838deeebbb0bf51682 - Regards / Groete Marius D. Liebenberg +27 82 698 3251 +27 12 743 6064 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- -- 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] linuxcnc VCP Discussions
Hi Chris, On 22/11/17 01:44, Chris Morley wrote: There was a discussion on IRC about linuxcnc's VCPs others maybe interested in There is a hold up on porting gladeVCP from GTK2 to GTK3 -the gremlin (graphics) widget. There was a project started to create a QT based VCP - QTvcp. There is a possibility to port over machinkit's qt based live graphics view widget. There is a possibility to port over machinekits whole QML VCP project. Not quite as simple as that unfortunately. It uses machinetalk and protobuf messaging which replaces NML in many places. A lot of the HAL stuff has changed also. You could probably use Cetus as a standalone, but I personally would not touch QML. It abstracts stuff the the point of unintelligibility and the process for creating a panel is not simple, as witnessed by the number of demos trying to show that it is. IMHO the core problem is not *vcp, it is Axis and gtk. Gremlin can be embedded in a Qt window and is still a very capable plotter/previewer. With some minor tweaks, gremlin still works fine embedded into Qt5.9 and Debian Stretch. If you had a GUI which is Qt based, (whether pyQt or C++) the process of getting a Qt based vcp to integrate with it is childs play, by comparison to getting something else to play nicely with gtk2. I feel c or c++ as the base language is not the best choice for a widget based VCP project. I feel it severely limits the number of people who can and will develop on it. The Designer widget libraries are by necessity written in C++, but the widgets once written can be used in Designer by pyQt The number of people wanting to develop actual widgets as opposed to panels, is liable to be limited to those who can or have a special need. I think if we can find away to replace gremlin that converting gladeVCP to GTK3 is worthwhile - a lot of work has gone into making it and it works pretty darn well. I think the qtvcp project is worthwhile and I think QT has a lot of momentum and probably the future. The problem that Linuxcnc has with Qt, is only supporting obsolete lib versions, because your distros do not support the later versions. So long as you have to support rtai kernels, with all the difficulty of building and kernel specific limitations, this is likely to remain a problem. Qt is on 5.9.2 at present. Debian Stretch has got as far as about 5.7.1 in its packages. Jessie is at 5.3.2, but does not install it by default, still using Qt4. Machinekit has packages for Stretch and Jessie. If you write everything in Qt4, you will later have to port to Qt5 at some stage and some things have changed considerably. X embedding is an obvious example as per our previous discussions. Qt5 has a facility now to create widgets 'on-the-fly' at runtime from designer .ui files http://doc.qt.io/qt-5/quiloader.html I have used this successfully to create a C++ qtvcp system I called QtPanel. This creates the panel, parses the .ui file and creates pins and slot/signal mechanisms to service the widgets and connect to HAL. That second bit is similar to what you did in python and I implemented in C++ quite some years ago, when looking at this. Feel free to contact off list if you want more info regards Mick -- 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] QTvcp 4/5 opinions wanted
Chris Revisiting the problems with X11 and Qt5, prompted me to look again at embedding. I have now managed, in C++, to embed native X11 windows into Qt5.8 widgets. I adapted the qxtglobalshortcut5 repo (https://github.com/ddqd/qxtglobalshortcut5) into https://github.com/ArcEye/qxtwindow, to make it a library, This was to use the window listing mechanism and the findWindow() function which uses that. This is all based upon the now defunct Qxt project, which I used extensively with Qt4. Also required that libQt5X11Extras be built (which it is by default in 5.8) The full code of a demo is in the Readme in that repo. It will spawn a copy of mplayer, wait until the window is created and then get its ID and embed it into a container widget. That embedding has completely changed from Qt4, but does work, so long as you explicitly re-parent the container to the widget it was created from, (passing the parent in the createWindowContainer() call did not seem to work properly) and first show() the parent then the child container. I also reimplemented the resize event to make the container resize to match any changes in window size. Using the reverse method and passing a Qt Wid in a spawn to programs that support embedding, such as mplayer or rxvt, works OK too. So should all be possible in python too. Feel free to use the repo or contact me off list regards -- 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] Emc-developers Digest, Vol 132, Issue 12
On 18/04/17 11:15, emc-developers-requ...@lists.sourceforge.net wrote: > I've been working on a branch that would supply linuxcnc with a python QT > based vcp program. > > This is capable of GLADEvcp type panels and operator screens including python > handler files. > > Qt seems to be the future of GUIs Good to see the idea came to fruition Chris. Seems a long time ago we were kicking this around previously. > > > The questions I am wonder on are: > > > python 2 or 3 ? Python 3 came out 9 years ago and has never taken off because of the backward incompatibilities with python 2 Until the major libraries available in 2 are ported to 3, that looks likely to continue. The EOL for python 2.7 (which already has some of the major changes in 3 backported to it) was originally 2015 and this was extended again to 2020. That could happen again, or the python org could finally admit they made a massive mistake and try to fix it :) > > > PYQT4 or 5 ? > > > Currently it's built with python 2 and PYQT4. > > > My personal opinion is that I see little reason to use python 3 yet - it > seems many libraries are slow to switch. > > > QT5 is not available in wheezy but is available in Mint (a fairly common used > distribution) > > Looks like debian Jessie has PYQT5 in both styles of python. > > > So to use QT5 we would not be able to use QTvcp in wheezy and i would need > some make file help > > to juggle when to build and not. Qt4.8 is EOL and even Qt5 is getting near to spawning into v6 Wheezy likewise is only receiving security updates, with more backports are available and Debian will pull the plug on it completely next year. Qt5 and Jessie is the only sane option to my mind, Qt5 is now default in Stretch too, but 4.8 is still supported probably for the reasons below. > > > I haven't read any significant differences between qt4/5 I just would like > to future proof the work. There are problems with Qt5, specifically in the area of X. The X implementation in Qt5 will prevent any Qt5 program from displaying at all, in an icewm window manager system for instance. A lot of the problems I have read about centre on video cards, GUIs, openGL etc More serious potentially to a VCP, is X embedding. Under 4.8 I could embed a gremlin window into a Q11XEmbedContainer or Q11XEmbedWidget quite simply. Qt5 did away with these classes. They maintain that you can use other classes to achieve the same, but last time I tried it, they didn't work. I haven't tried for quite a while and this suggests it can be done by another route http://stackoverflow.com/questions/32703557/qx11embedcontainer-equivalent-in-qt5 Just be sure that whatever you produce can embed and be embedded OK. The other changes are largely headers due to class reorganisation changes etc etc, in C++ at least, I don't use python. Good luck. > > it's really disappointing the debacle of GTK2 and 3. > > > Opinions other comments? > > > Chris M -- 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] The best way writing man pages?
On 12/07/16 14:15, emc-developers-requ...@lists.sourceforge.net wrote: > Date: Fri, 8 Jul 2016 17:16:09 -0500 > From: Jeff Epler > Subject: Re: [Emc-developers] The best way writing man pages? > To: EMC developers > Message-ID:<20160708221609.gb76...@unpythonic.net> > Content-Type: text/plain; charset=us-ascii > > 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 I could do a PR, but you would have to advise what path(s) you want the src/hal/components/Submakefile and halcompile to use for the generated docs. We used man/docs/man9 as an interim measure, but that is likely to change as soon as we remove troff man pages altogether, in favour of asciidoc and a viewer script. Off-list is fine, I only get a digest whenever the number of posts reaches a critical mass. regards -- 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?
On 08/07/16 15:27, Jeff Epler wrote: > (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!) Feel free to 'borrow with pride' I put into Machinekit some time ago https://github.com/machinekit/machinekit/blob/master/src/hal/utils/comp.g#L933 (Whether or not you need the front matter section, depends upon what you are going to do with it afterwards) regards -- Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T 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] Who changed the requiered python version?
Just checking the first box in 'make menuconfig' for building a 64 bit kernel will be enough. My configs disable various 'features' I don't want, like suspend to RAM / disk etc so may not be what you require. regards On 02/01/2016 20:04, emc-developers-requ...@lists.sourceforge.net wrote: > Tahnks for the hint, I just checked on that and it seems that the named > .config is for an x86 kernel, > So I have to walk through the xconfig stuff without understandig waht I > do, or... -- ___ 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?
On 02/01/16 17:09, emc-developers-requ...@lists.sourceforge.net wrote: > You are right, no realtime kernel till now! The coment in buildbot > should be adapted to reflect this and make clear there is no rt Kernel > for Jessie. It is simple to build a rt-preempt kernel for Jessie, I am currently running an amd64 version of 4.1.15-rt17 Peter Wallace did a guide some while back too, just replace version numbers with current ones. http://sourceforge.net/p/emc/mailman/message/33665819/ regards -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Find __comp_first_inst by Traversing List of, Components?
Hi
The below from my Qt HAL access libraries demonstrates a way to access
components.
Note that the pointer is passed and from that the name is read, so you
have all you need once you find the right one.
regards
void HAL_Access::getAllComponentNames(QStringList& list)
{
int next;
hal_comp_t *comp;
rtapi_mutex_get(&(hal_data->mutex));
next = hal_data->comp_list_ptr;
while (next != 0)
{
comp = (hal_comp_t *)SHMPTR(next);
list.append(comp->name);
next = comp->next_ptr;
}
rtapi_mutex_give(&(hal_data->mutex));
}
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] [PATCH] Bug in radio button pyvcp_widgets
Arises from [Emc-users] Regression in pyvcp's radiobutton from 2.5 to 2.6.5, nothing selected in the hal layer on startup initval field setting the correct widget to active at initialisation, but changes to prevent unnecessary updates suppressing initial setting of associated pin to match. Explicitly setting pin associated with active button selection via initval at initialisation corrects this. Patch is against 2.8 but the code is the same 2.6 - 2.8 regards >From b8330d1f03a4ffd49140d306806da98860c64409 Mon Sep 17 00:00:00 2001 From: Mick Date: Tue, 20 Jan 2015 10:24:30 + Subject: [PATCH] Bug in radio button pyvcp_widgets initval field setting the correct widget to active at initialisation, but changes to prevent unnecessary updates supressing initial setting of associated pin to match. Explicitly setting pin associated with active button selection via initval at initialisation corrects this. Signed-off-by: Mick Grant --- lib/python/pyvcp_widgets.py |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/python/pyvcp_widgets.py b/lib/python/pyvcp_widgets.py index c0dbeb4..a9d5b1f 100644 --- a/lib/python/pyvcp_widgets.py +++ b/lib/python/pyvcp_widgets.py @@ -614,7 +614,7 @@ class pyvcp_radiobutton(Frame): n+=1 self.selected = initval - +pycomp[self.halpins[initval]]=1 ## ArcEye - FIXED - only update the pins if changed ## def update(self,pycomp): -- 1.7.10.4 -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] halcompile patch - extralib field
Changes made and tested, appears OK. I have forked your linuxcnc-mirror repo and hopefully created a valid pull request to this commit. If this works it is a major step forward in my git-fu :) regards On 09/11/14 14:59, schoone...@btinternet.com wrote: > On 09/11/14 13:39, Jeff Epler wrote: >> Hello. >> >> Since you're working on github, it's better to submit a github pull >> request, which will persist on a list on github until it's dealt with. > I will have to look into that. The only repo on github seemed to be > well behind the master > and because I had not forked that, was not aware how to create a pull > request to the main repo. >> I did not test with your patch, but here are some items I thought of >> while looking at the patch. >> >> I see that extralib is applied when building kernel modules as a part of >> EXTRA_CFLAGS. This won't work to actually link a library in kernel >> space (you simply can't do that in any way), and when building for the >> new "uspace" userspace realtime I doubt this will do what is desired. >> If the option is specified for a scenario where it can't be used, it >> would be better if it were an explicit error. You can do this by >> calling the Error() function with an explanatory message. > The libs I was thinking of were statically linked ones of common functions > not dynamically linked libraries,but I have removed that bit > and generated an error if used with rt builds. >> The syntax accepts multiple "extralib" lines but only the first one is >> ever used. You can use " ".join(extralibs) to concatenate all the >> various extralibs declarations. > That is what comes of cut and pasting the nearest thing in appearance to > what you need:) > I was only ever thinking of one line and just needed a string rather > than array > Makes more sense however to allow several entries in one file, join now used > > Will come back when tested and I find how to create a pull request from > an external repo > > regards > > > -- > ___ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] halcompile patch - extralib field
On 09/11/14 13:39, Jeff Epler wrote: > Hello. > > Since you're working on github, it's better to submit a github pull > request, which will persist on a list on github until it's dealt with. I will have to look into that. The only repo on github seemed to be well behind the master and because I had not forked that, was not aware how to create a pull request to the main repo. > > I did not test with your patch, but here are some items I thought of > while looking at the patch. > > I see that extralib is applied when building kernel modules as a part of > EXTRA_CFLAGS. This won't work to actually link a library in kernel > space (you simply can't do that in any way), and when building for the > new "uspace" userspace realtime I doubt this will do what is desired. > If the option is specified for a scenario where it can't be used, it > would be better if it were an explicit error. You can do this by > calling the Error() function with an explanatory message. The libs I was thinking of were statically linked ones of common functions not dynamically linked libraries,but I have removed that bit and generated an error if used with rt builds. > > The syntax accepts multiple "extralib" lines but only the first one is > ever used. You can use " ".join(extralibs) to concatenate all the > various extralibs declarations. That is what comes of cut and pasting the nearest thing in appearance to what you need:) I was only ever thinking of one line and just needed a string rather than array Makes more sense however to allow several entries in one file, join now used Will come back when tested and I find how to create a pull request from an external repo regards -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] halcompile patch - extralib field
Hi Hopefully got the contribution requirements right, in a public clone of master, signed off etc https://github.com/ArcEye/linuxcnc-dev/commit/9ec6eb1d4e56cc6748e18f11ecfcd2b66ef86845 The above arose from user on the forum trying to link a custom library in his component, but being unable to without going outside halcompile (comp) and building on the command line, which was proving difficult for him. Most of use with userspace components but will add the paths / libs to the initial object file build stage of the rt module build too if that should be required. Should have zero impact if unused. Usage example extralib "-L/usr/local/lib -lspecial-custom-stuff"; anywhere in the comp file header above the ;; delimiters Python probably capable of polishing, largely borrowed with pride from existing code, python not being my preferred language. regards -- ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
