Back
[01:12:16] <KGB-linuxcnc> 03Chris Morley 05widgets 56f38a8 06linuxcnc 10lib/python/gladevcp/hal_python.xml 10lib/python/gladevcp/hal_pythonplugin.py 03lib/python/gladevcp/overridewidget.py gladevcp -add override slider widget * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=56f38a8
[01:12:16] <KGB-linuxcnc> 03Chris Morley 05widgets 4957087 06linuxcnc 10share/gscreen/skins/gaxis/gaxis.glade 10share/gscreen/skins/gaxis/gaxis_handler.py gaxis -use Override widgets for overrides * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4957087
[01:12:17] <KGB-linuxcnc> 03Chris Morley 05widgets 86d2fbb 06linuxcnc 10src/emc/usr_intf/gscreen/gscreen.py gscreen -add local theme capability * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=86d2fbb
[01:12:20] <KGB-linuxcnc> 03Chris Morley 05widgets a3ed75c 06linuxcnc 10(150 files in 2 dirs) gscreen -add a local theme suited to touchscreens * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a3ed75c
[01:14:33] <cmorley> seb_kuzminsky: any chance to add to 2.7 before release? see the last for commits on the widgets branch i just pushed.^^^
[01:14:50] <cmorley> I 'll check back for your answer...sleep time
[08:40:09] <cradek> the last week or two, enco keeps desperately sending me offers
[08:40:19] <cradek> wonder if they're tanking
[08:42:38] <seb_kuzminsky> they do seem hungrier than usual
[08:42:59] <cradek> I even bought something recently
[08:43:27] <seb_kuzminsky> cmorley: the try and the comment near the top of overridewidget.py (first commit) seem slightly misleading
[08:44:42] <skunkworks> Yay - rooted phone!
[08:46:08] <skunkworks> because I really don't need NFL updates randomly
[08:46:55] <skunkworks> (and I wanted lollipop)
[08:53:37] <seb_kuzminsky> cmorley: glade file diffs are hard for me to read, but i trust you to make correct well tested changes there
[08:54:23] <seb_kuzminsky> heh:
[08:54:23] <seb_kuzminsky> - print 'hi'
[08:58:01] <seb_kuzminsky> cmorley: in the final commit "gscreen -add a local theme suited to touchscreens", looks like you accidentally added an editor swap file
[09:14:59] <cradek> permissions on a lot of those images are wrong in the last commit
[09:15:25] <cradek> also, are the .xvpics thumbnails on purpose?
[09:25:08] <linuxcnc-build> build #3 of 1503.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed install-missing-build-dependencies configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1503.rip-jessie-rtpreempt-amd64/builds/3 blamelist: Dewey Garrett <dgarrett@panix.com>
[09:25:23] <linuxcnc-build> build #3 of 1501.rip-jessie-rtpreempt-i386 is complete: Failure [4failed install-missing-build-dependencies configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1501.rip-jessie-rtpreempt-i386/builds/3 blamelist: Dewey Garrett <dgarrett@panix.com>
[09:25:26] <linuxcnc-build> build #3 of 1502.rip-jessie-amd64 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1502.rip-jessie-amd64/builds/3 blamelist: Dewey Garrett <dgarrett@panix.com>
[09:38:10] <seb_kuzminsky> cmorley: those build failures are my fault - i added jessie machines to the buildbot and our branches dont know how to deal with them yet
[09:38:36] <seb_kuzminsky> i'll be fixing those build issues over the next day or two, then you should rebase your branch and address any other issues and try again
[09:38:53] <seb_kuzminsky> oops, same goes for you dgarr, not your build failure
[09:40:23] <KGB-linuxcnc> 03Sebastian Kuzminsky 05v2.5_branch 01609da 06linuxcnc 10scripts/platform-is-supported packaging: dont build 2.5 on debian jessie * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=01609da
[09:40:39] <cradek> packaging: dont be ridiculous
[09:41:11] <KGB-linuxcnc> 052.5-for-jessie 49c7fa2 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=49c7fa2
[09:45:33] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6-for-jessie d0e21fa 06linuxcnc Merge remote-tracking branch 'origin/v2.5_branch' into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d0e21fa
[09:45:33] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6-for-jessie a3c7d24 06linuxcnc 10debian/configure 10debian/control.in packaging: libgnomeprintui2.2 is not available on Debian Jessie * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a3c7d24
[09:45:47] <linuxcnc-build> build #3 of 1500.rip-jessie-i386 is complete: Failure [4failed install-missing-build-dependencies compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/3 blamelist: Dewey Garrett <dgarrett@panix.com>
[09:46:01] <seb_kuzminsky> that merge of 2.5 into 2.6-for-jessie carefully undoes the "dont build on jessie" that i just added to 2.5
[09:56:47] <cradek> cool
[09:57:13] <cradek> the goal for jessie right now is 2.6-uspace and 2.7-uspace?
[10:00:57] <seb_kuzminsky> yeah
[10:01:12] <seb_kuzminsky> because i'm way behind on modern rtai kernels, again
[10:01:51] <seb_kuzminsky> for now it's just rip, once the smoke clears from that it'll be easy to add debs
[10:02:10] <seb_kuzminsky> hubris, meet fall
[10:05:23] <skunkworks> I didn't think 2.6 supported uspace
[10:05:44] <cradek> oops you're right
[10:06:05] <cradek> the goal for jessie right now is 2.7-uspace?
[10:08:47] <seb_kuzminsky> meh, uspace ~= sim
[10:09:14] <seb_kuzminsky> as far as the buildbot cares
[10:10:15] <skunkworks> ah
[10:58:26] <linuxcnc-build> build #3388 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3388 blamelist: Dewey Garrett <dgarrett@panix.com>
[11:29:24] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/debs_wodocs 83c71c1 06linuxcnc 10debian/rules.in debian/rules.in restore fail exit * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=83c71c1
[11:57:09] <linuxcnc-build> build #2725 of 4003.deb-lucid-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4003.deb-lucid-i386/builds/2725 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[13:48:42] <linuxcnc-build> build #6 of 1503.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed install-missing-build-dependencies configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1503.rip-jessie-rtpreempt-amd64/builds/6 blamelist: Dewey Garrett <dgarrett@panix.com>
[13:48:49] <linuxcnc-build> build #6 of 1502.rip-jessie-amd64 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1502.rip-jessie-amd64/builds/6 blamelist: Dewey Garrett <dgarrett@panix.com>
[13:48:55] <linuxcnc-build> build #6 of 1501.rip-jessie-rtpreempt-i386 is complete: Failure [4failed install-missing-build-dependencies configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1501.rip-jessie-rtpreempt-i386/builds/6 blamelist: Dewey Garrett <dgarrett@panix.com>
[14:00:35] <jepler> it looks like somebody needs to port the linuxcnc trajectory planner to ed nisley's hp plotter so that it doesn't get those terrible dwell marks at the end of every movement
[14:03:44] <cradek> it might stop to wait for the next command to come in over the serial...
[14:05:50] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 d0e21fa 06linuxcnc Merge remote-tracking branch 'origin/v2.5_branch' into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d0e21fa
[14:05:50] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 a3c7d24 06linuxcnc 10debian/configure 10debian/control.in packaging: libgnomeprintui2.2 is not available on Debian Jessie * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a3c7d24
[14:05:50] <KGB-linuxcnc> 052.6-for-jessie a3c7d24 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a3c7d24
[14:09:18] <linuxcnc-build> build #6 of 1500.rip-jessie-i386 is complete: Failure [4failed install-missing-build-dependencies compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/6 blamelist: Dewey Garrett <dgarrett@panix.com>
[14:55:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 141ce4a 06linuxcnc 10debian/configure packaging: debian 'testing' doesnt't have libgnomeprintui2.2 either * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=141ce4a
[15:10:21] <linuxcnc-build> build #3391 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3391 blamelist: Dewey Garrett <dgarrett@panix.com>
[15:12:36] <seb_kuzminsky> if dgarr shows up, tell him to wait for me to fix 2.7 & then rebase his stuff
[15:32:47] <jepler> I missed the motivation for not building documentation. is it to help the buildbot, or other?
[15:35:20] <jepler> can we somehow use dpkg's -A/-B and build-depends-indep
https://wiki.debian.org/Build-Depends-Indep to only build the docs when desired?
[15:35:53] <jepler> iiuc, invoking dpkg-buildpackage -B could skip building documentation altogether
[15:38:58] <seb_kuzminsky> i am not motivated to not build documentation
[15:41:25] <jepler> there's a tension between changing buildbot for faster turnaround vs testing more
[15:42:13] <cradek> building docs on buildbot routinely catches problems with docs
[15:42:17] <jepler> yes
[15:42:18] <seb_kuzminsky> the buildbot *is* getting pretty slow... because our test suite is improving
[15:42:23] <cradek> well when I touched the docs last, it does
[15:42:27] <seb_kuzminsky> heh
[15:42:33] <jepler> but mostly all the architectures catch the same doc bugs
[15:42:38] <cradek> true
[15:43:18] <jepler> I guess if I think we could support building without docs in this way, I should look into it
[15:43:36] <jepler> I know people have asked in the past about package building without docs and I've mostly just done a rolleyes
[15:43:47] <jepler> these poor folks who can only afford an rpi and an iphone with an irc client
[15:44:02] <jepler> but when dgarr wants it I take it a little bit more seriously
[15:44:17] <cradek> what is the situation where one wants to build an incomplete package?
[15:44:26] <cradek> I build without docs in RIP all the time
[15:45:06] <cradek> I rarely want to build debs - I just use the releases and I'm happy they have the docs in them
[15:45:14] <jepler> right now we build both i386 and amd64 doc packages for jessie
[15:45:16] <cradek> so I'd like to understand the motivation
[15:45:21] <jepler> there's no reason to build the doc package for both of them, it could be built just once
[15:45:28] <jepler> that to me is the real motivation
[15:46:03] <jepler> well not for jessie
[15:46:06] <jepler> not yet
[15:46:08] <jepler> wheezy
[15:46:39] <jepler> other people have wanted build-without-docs e.g., to have fewer build dependencies, to have a faster build turnaround, etc. mostly on underpowered and small-disk-space embedded systems.
[15:46:41] <seb_kuzminsky> all our rip builders build docs too
[15:47:08] <jepler> afk
[15:47:15] <seb_kuzminsky> that part was because i thought the coverage was worth the time, but i'm open to an argument that i sliced that wrong
[15:47:23] <cradek> I bet they wouldn't need to
[15:47:35] <jepler> now we have to swirl pdf vs html documentation into it
[15:47:43] <jepler> which I think has changed in 2.7 too
[15:47:44] <cradek> (I'm not sure we need rip builders at all)
[15:47:55] <jepler> cradek: can only runtests for RIP, at least right now
[15:48:03] <cradek> oh!
[15:48:08] <seb_kuzminsky> rip builders are needed to run the tests, on each and every platform
[15:48:13] <jepler> build package -> intall -> runtests would be awesome if it worked, but nobody made it work
[15:48:14] <cradek> never mind me
[15:48:23] <jepler> really afk
[15:48:26] <seb_kuzminsky> seeya jeff
[15:49:50] <seb_kuzminsky> i started down the path of making linuxcnc-test packages, containing /tests and /scripts/runtests
[15:50:03] <seb_kuzminsky> i got like 80% done before getting distracted by the shiny and wantering off
[15:55:22] <seb_kuzminsky> it's in a branch called (ugh) ubc3-deb, which is on highlab but not on glo, and also: which doesn't work
[15:58:21] <seb_kuzminsky> i'll try to extract the useful (but broken) parts of it and push it to glo, based on master, maybe tonight
[16:01:52] <jepler> other than installing the runtests script with a better name (dejagnu has /usr/bin/runtest, no s) my knee jerk is that it must not be that hard
[16:01:59] <jepler> I guess it likes to put output files in test directories
[16:02:12] <jepler> so now you have a problem with permissions
[16:04:20] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 03ef68a 06linuxcnc 10debian/configure packaging: ubuntu 14.04 and newer dont have libgnomeprintui2.2 either * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=03ef68a
[16:05:19] <seb_kuzminsky> also (minor), runtests runs rip-environment
[17:25:34] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 de1f8eb 06linuxcnc 10debian/configure Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=de1f8eb
[17:26:10] <seb_kuzminsky> eugh, there's still the noisy merge of 2.7 into master
[17:26:38] <seb_kuzminsky> but this is the official all-clear announcement for 2.7 and earlier branches - they should all work on the buildbot now
[17:37:30] <linuxcnc-build> build #9 of 1503.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed install-missing-build-dependencies configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1503.rip-jessie-rtpreempt-amd64/builds/9 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[17:37:38] <linuxcnc-build> build #9 of 1502.rip-jessie-amd64 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1502.rip-jessie-amd64/builds/9 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[17:37:41] <linuxcnc-build> build #9 of 1501.rip-jessie-rtpreempt-i386 is complete: Failure [4failed install-missing-build-dependencies configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1501.rip-jessie-rtpreempt-i386/builds/9 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[17:40:34] <seb_kuzminsky> wait, what
[17:41:48] <Tom_itx> you were saying?
[17:44:04] <seb_kuzminsky> how did i botch this?
[17:44:55] <Tom_itx> dude... you're asking the wrong person
[17:46:27] <seb_kuzminsky> oh, i messed up the merge conflict resolution of debian/configure from 2.6 to 2.7
[17:46:30] <seb_kuzminsky> grr
[17:47:57] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 41c9be7 06linuxcnc 10debian/configure packaging: fix up botched merge of libgnomeprintui2.2 dependency handling * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=41c9be7
[17:48:03] <seb_kuzminsky> <-- sloppy
[17:58:12] <linuxcnc-build> build #9 of 1500.rip-jessie-i386 is complete: Failure [4failed install-missing-build-dependencies compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/9 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[18:02:41] <Tom_itx> i'm using halui.spindle.start / stop on my pendant to do that. in MDI mode if i issue a S500 M3 then switch to manual mode and push the spindle start/stop button on the pendant the spindle stops. However if i move back to the MDI screen, the spindle starts up again
[18:03:35] <Tom_itx> if i switch back to manual mode and push the STOP on the AXIS screen the spindle stops and remains so even after switching screens to MDI again
[18:04:10] <Tom_itx> is axis not seeing the halui.spindle.stop?
[18:04:18] <seb_kuzminsky> Tom_itx: please open a bug for that
[18:04:56] <Tom_itx> seems like something new for 2.7 HOWEVER... I also added fwd rev code and hardware to my spindle so it could be something i'm doing
[18:05:01] <Tom_itx> before i holler too loud
[18:05:29] <seb_kuzminsky> ah
[18:05:30] <Tom_itx> the pendant code stayed the same
[18:05:41] <seb_kuzminsky> see if you can reproduce it with one of our standard sim configs
[18:06:01] <Tom_itx> i'd have to add my pendant code to one of em
[18:06:21] <Tom_itx> which is using mesa hardware that the sims don't see
[18:06:42] <Tom_itx> the axis STOP works ok
[18:07:02] <seb_kuzminsky> or use halcmd to poke the same halui pins that your pendant does
[18:07:04] <Tom_itx> it's only when using the halui.spindle.stop / start that i see it
[18:07:12] <Tom_itx> yeah
[18:08:44] <Tom_itx> can i open halcmd from the GUI?
[18:09:23] <seb_kuzminsky> i dont think so
[18:09:28] <seb_kuzminsky> i run "halcmd" in the terminal
[18:10:11] <Tom_itx> use setp to set the value?
[18:12:06] <seb_kuzminsky> yep
[18:12:53] <seb_kuzminsky> or (i just learned this syntax from the manpage): pinname = value
[18:13:09] <seb_kuzminsky> seems clearer than "setp pinname value" that i always use
[18:19:31] <Tom_itx> sim seems to honor the halui.spindle.stop start commands
[18:20:07] <Tom_itx> watching spindle.speed.out in hal configuration
[18:22:20] <Tom_itx> odd thing, i can set both the stop and start true and they remain. you would think one would toggle the other value
[18:23:15] <seb_kuzminsky> they're In pins, right? so halui isn't supposed to set them, some external hal circuitry is supposed to set them
[18:23:23] <Tom_itx> they are inputs.. so in reality they both could be true at the same time but not adviseable
[18:23:28] <seb_kuzminsky> i think they (like many halui In pins) are edge triggered, not level triggered
[18:23:41] <Tom_itx> well i should turn one off and one on in halcmd
[18:23:46] <Tom_itx> just realized that
[18:24:07] <Tom_itx> the button logic takes care of it i'm pretty sure
[18:24:37] <seb_kuzminsky> a momentary button behavior matches the expected input behavior of those pins
[18:25:02] <Tom_itx> i'm using toggle2nist on the button
[18:25:20] <seb_kuzminsky> i dont know that one
[18:25:45] <Tom_itx> behaves like a JK ? flipflop
[18:25:50] <Tom_itx> i think
[18:26:07] <Tom_itx> on off outputs
[18:26:15] <seb_kuzminsky> the manpage is not very clear to me
[18:26:27] <seb_kuzminsky> and it claims toggle2nist requires floating point, really? weird
[18:26:38] <Tom_itx> i'll investigate further before i holler
[18:26:43] <seb_kuzminsky> ok thanks
[18:26:52] <seb_kuzminsky> let us know if you find any funny business
[18:26:58] <Tom_itx> still recovering from injury so it's slow going
[18:28:02] <Tom_itx> i just never noticed it before but i A: added fwd/rev to the spindle and B: updated to 2.7 ~pre7 at the same time
[18:28:40] <Tom_itx> it behaves the same whether it's going fwd or rev
[18:29:26] <seb_kuzminsky> so you have a momentary button on your pendant, connected to a toggle2nist .in pin, with its .out going to halui.spindle.start?
[18:30:04] <Tom_itx> can you do multiple halcmd line on the same line?
[18:30:11] <Tom_itx> separated by what?
[18:30:18] <Tom_itx> yes
[18:30:59] <Tom_itx> http://tom-itx.no-ip.biz:81/~webpage/cnc/configs/sherline/my_jog.hal
[18:31:03] <Tom_itx> spindle code near the bottom
[18:31:52] <Tom_itx> (it's a mess) right now
[18:33:18] <Tom_itx> the 'out' on toggle2nist is .on and .off outputs
[18:35:15] <Tom_itx> so halui.spindle.start and halui.spindle.stop will never be the same state
[18:37:19] <seb_kuzminsky> that's up to your hal circuitry
[18:37:20] <seb_kuzminsky> bbl
[18:40:03] <Tom_itx> yes
[18:55:10] <linuxcnc-build> build #3394 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3394 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:19:43] <jepler> seb_kuzminsky: "needs fp" is probably just an oversight
[19:22:29] <linuxcnc-build> build #1736 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1736 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:26:28] <arrowbook> who know that the equation dv =-2.0*match_ac*dt, we use the factor of 2.0; in the function of update_freq of stepgen.c
[19:27:04] <arrowbook> why we use 2.0
[19:32:18] <jepler> that line of code was written over 10 years ago, and by somebody who no longer participates on irc. the odds that someone has a specific recall about it are very slim.
[19:32:39] <jepler> but jmk is a very smart guy, so I assume the number is the right one
[19:34:24] <jepler> you could try it with a different number like 99 or 3.14 or 1e6 and see what breaks ;)
[19:35:47] <jepler> hm, interesting thing above, though -- there's a hard-coded "if error is < .0001, don't bother trying to minimize position error". I wonder if anybody's been inconvenienced by that not being a tunable
[19:36:29] <arrowbook> oh, is the update_freq using trapezoid or s-curve?
[19:37:20] <jepler> stepgen uses a trapezoidal velocity profile
[19:38:43] <jepler> linuxcnc-devel-2015-08-14.log:09:30 <jepler> arrowbook: stepgen can limit acceleration, giving a trapezoidal velocity profile. it has an internal feedback loop similar to pid, too, but that has no tunable parameters.
[19:40:05] <jepler> like figure 16.3 here, though I haven't reviewed the rest of the page for its suitability or accuracy and it is a site unrelated to linuxcnc
http://engineeronadisk.com/book_modeling/motiona3.html
[19:41:54] <linuxcnc-build> build #3395 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3395 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:43:08] <arrowbook> i can understand most of the code of stepgen , just some factor 2.0 or 0.5
[19:43:31] <arrowbook> except
[19:51:13] <jepler> that code has had 2 changes in the last 5 years, nobody is an expert in it
[19:53:00] <arrowbook> oh,thank you
[20:51:00] <cradek> http://linuxcnc.org/index.php/english/forum/10-advanced-configuration/28547-heavy-hal-file-gives-problem-setting-motionanalog#61784
[20:51:07] <cradek> maybe we need to increase it again
[22:18:24] <jepler> that's an awful bug report
[22:18:39] <jepler> when I do a non-specific thing I get a non-specific error
[22:20:03] <jepler> haltcl: for {set i 0} {$i < 100000} {incr i} { newsig s$i float }
[22:20:03] <jepler> HAL: ERROR: insufficient memory for signal 's3836'
[22:20:03] <jepler> newsig failed
[22:22:17] <jepler> haltcl: loadrt mux4
[22:22:18] <jepler> HAL: ERROR: insufficient memory for component 'mux4'
[22:22:52] <jepler> the errors mostly seem to be good for out-of-memory, but what do you *do* about it...?
[22:23:14] <jepler> anyway, I don't mind doubling hal shared memory area for 2.7
[23:20:36] <cradek> I spent minutes and minutes trying to figure out whether it can be a modparam
[23:20:42] <cradek> the answer is I don't know
[23:24:17] <KGB-linuxcnc> 03Chris Morley 05widgets 86b875b 06linuxcnc 10lib/python/gladevcp/hal_python.xml 10lib/python/gladevcp/hal_pythonplugin.py 03lib/python/gladevcp/overridewidget.py gladevcp -add override slider widget * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=86b875b
[23:24:18] <KGB-linuxcnc> 03Chris Morley 05widgets 2867564 06linuxcnc 10share/gscreen/skins/gaxis/gaxis.glade 10share/gscreen/skins/gaxis/gaxis_handler.py gaxis -use Override widgets for overrides * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2867564
[23:24:18] <KGB-linuxcnc> 03Chris Morley 05widgets 238fb45 06linuxcnc 10src/emc/usr_intf/gscreen/gscreen.py gscreen -add local theme capability * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=238fb45
[23:24:20] <KGB-linuxcnc> 03Chris Morley 05widgets 22c2b56 06linuxcnc 10(35 files) gscreen -add a local theme suited to touchscreens * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=22c2b56
[23:24:24] <KGB-linuxcnc> 03Chris Morley 05widgets 608f66d 06linuxcnc 10share/gscreen/skins/gaxis/gaxis_handler.py gaxis -name some widgets so the theme can see them * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=608f66d
[23:25:59] <cmorley> seb_kuzminsky cradek : I pushed fixes for your comments (thanks) to widgets. When you get a moment please take a look