Back
[02:04:14] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 cbca1a2 06linuxcnc 10debian/configure packaging: use correct dependencies on Debian Jessie * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cbca1a2
[11:54:06] <KGB-linuxcnc> 03Norbert Schechner 052.6 6b3ac3c 06linuxcnc 10(5 files in 2 dirs) docs - gmoccapy now up to date with 1.4.1 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6b3ac3c
[11:54:06] <KGB-linuxcnc> 03Norbert Schechner 052.6 25fbed2 06linuxcnc Merge branch '2.6' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=25fbed2
[11:54:49] <KGB-linuxcnc> 03Norbert Schechner 052.7 7d375ed 06linuxcnc 10debian/configure Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7d375ed
[11:54:59] <mozmck> Playing with gradients is fun! Notice the spindle speed HBar:
http://ibin.co/1mtUl8c40Lvd
[11:55:43] <KGB-linuxcnc> 03Norbert Schechner 05master 12fe0ad 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=12fe0ad
[12:28:19] <seb_kuzminsky> norbert's merges are perfect now, this is great
[13:43:32] <KimK> mozmck: are your new widgets usable under the "old regime" (xml?), or just under the new glade, etc. ?
[13:44:33] <mozmck> KimK: I just did some minor modifications to the bar and led gladevcp widgets.
[13:46:34] <KimK> I ask because I'd like to see someone make an illuminated rectangular pushbutton with legend. something like this:
http://www.flamecorp.com/Eaton-MSC.php
[13:49:06] <mozmck> hmm, couldn't that be done with a normal button with bitmaps on it?
[13:50:34] <KimK> I don't know, two bitmaps? You'd need one for lit and one for dark, wouldn't you? Four in the case of the horizontal-split ones, but they might be too hard.
[13:51:07] <mozmck> Yes, I think it would need two bitmaps
[13:51:33] <mozmck> Are they lit normally, or just when pushed/active?
[13:52:09] <KimK> Too complicated that way, maybe? The pushbutton and the lamp(s) must be independent.
[13:53:34] <mozmck> So the lamp could either be on all the time, or connected to maybe a HAL signal?
[13:53:45] <KimK> The computer graphic lamps make multiple colors at least theoretically possible, usually too complicated for a real sw/lamp assemb;y, too many bulbs/filters.
[13:54:41] <KimK> Yes, it could be either way. And the horizontal-split switches offer even more possibilities,
[13:56:16] <mozmck> what does the horizontal-split switch do?
[13:57:01] <mozmck> looks like one switch with two light sections - one on top and one on the bottom?
[14:00:04] <KimK> Yes exactly. A few even have two light sections and two switch sections, but you don't see that too often, usually one button for both. I have a use in mind for the singles where they are state indicators (gear shift), the lamps can change by M-code or what was the last button pressed in idle state. The legend would show the max RPM in that gear and the Mcode.
[14:02:59] <KimK> I have this done now (in "old" xml) using text and a round led above a rectangular pushbutton, but all of this in one item would look better. Let me know if a screenshot would help.
[14:03:24] <mozmck> That might help, but I don't know that I have time right now to work on something like that.
[14:04:09] <mozmck> I was playing with those widgets because it was a fairly easy way to learn some cairo and test things.
[14:05:12] <KimK> OK, sure, no problem. Just wondering when I saw your demos. I have the same problem, other fish to fry.
[14:05:59] <mozmck> I don't think it would be too hard to do though.
[14:06:44] <KimK> I'll look into your bitmap method, but I thought the bitmaps could only display, I didn't think you could click on them.
[14:07:10] <mozmck> Well, most toolkits allow you to put bitmaps on buttons.
[14:07:19] <mozmck> I would assume gtk does as well.
[14:07:42] <KimK> OK, great, thanks for the tip.
[16:24:15] <seb_kuzminsky> huh, our build system builds .comp files kind of wonky
[16:24:23] <seb_kuzminsky> it doesn't support "option userspace;
[16:24:48] <seb_kuzminsky> it assumes all comps are rt comps
[16:25:17] <seb_kuzminsky> there a src/hal/user_comps, but that's surprisingly not for userspace comps
[16:30:52] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 4db9919 06linuxcnc 10docs/src/hal/comp.txt document halcompile's "option userspace" a bit more * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4db9919
[16:30:52] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 eba2c40 06linuxcnc 10docs/src/hal/comp.txt halcompile: fix a copy/paste error in the docs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eba2c40
[16:49:34] <KGB-linuxcnc> 03Dewey Garrett 052.6 a7c10d0 06linuxcnc 10src/emc/ini/inihal.cc inihal.cc: bugfix, typo for ini.n.backlash * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a7c10d0
[17:08:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 573b09e 06linuxcnc 10src/hal/components/axistest.comp 10src/hal/components/simple_tp.comp fix some stray execute permissions * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=573b09e
[17:10:39] <seb_kuzminsky> and the .comp files in src/hal/components dont actually get compiled by comp/halcompile
[17:11:55] <seb_kuzminsky> they get made into .c files using halcompile's undocumented -o flag, then compiled using our normal .c rules
[17:16:36] <KimK> seb_kuzminsky: I hope to be making some rt comps in the future, so I much appreciate what you're doing to get things straightened out. Or clarified for the new and naive, at least.
[18:14:05] <cmorley1> mozmck: Can you make a patch for your upgraded LEDs? I think they are nice. Probably should make the square ones pretty too...
[18:16:26] <cmorley1> Kimk: You just want and LED with text in the middle of it? or does the text change on led State?
[18:58:31] <linuxcnc-build_> build #881 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/881 blamelist: Dewey Garrett <dgarrett@panix.com>
[19:24:38] <mozmck> Hi cmorley1, did you see the Hbar too?
[19:24:55] <cmorley1> Yes looks very nice
[19:25:08] <mozmck> I could make a patch. I played with the square LEDs, but didn't get anything I really liked yet.
[19:25:48] <mozmck> square LED's are usually pretty dull in real life, but I'm sure they can be spiffed up a little
[19:26:23] <mozmck> What Kimk was talking about was a lighted button, with the light being independent of the button state.
[19:26:26] <cmorley1> yes I think consistent would be nice but maybe people don't mix shapes much..?
[19:26:42] <mozmck> I don't know.
[19:27:14] <mozmck> I was thinking I could figure out how to add a property so you could select between the "shiny" or "flat" style.
[19:27:17] <cmorley1> anyways they does add some spiff to them ... we could even make it a clickable optionm
[19:27:29] <cmorley1> option - the fancy part i mean
[19:27:37] <mozmck> heh, what I just said!
[19:27:41] <cmorley1> lol
[19:27:52] <mozmck> or "pretty" vs "ugly"
[19:28:18] <mozmck> (not really - it would just be funny to make that the options)
[19:29:16] <cmorley1> GTK have had packages called something like that before..
[19:30:55] <cmorley1> well when you get bored of playing with them, if you send me a patch I will see about incorporating, if you like.
[19:32:06] <cmorley1> gotta go ttyl
[19:34:41] <mozmck> ok, will do
[19:35:36] <tinkerer> happy new year all!
[19:37:28] <tinkerer> seb_kuzminsky: do you have time for the tcl issues?
[19:53:10] <seb_kuzminsky> tinkerer: hey there, happy new year
[19:53:29] <seb_kuzminsky> i dont know enough about tcl to do anything about the weird 8.6 problem :-/
[19:53:43] <seb_kuzminsky> but if you have any input i'd love to hear it
[19:53:50] <tinkerer> :)
[19:53:52] <tinkerer> ok
[19:54:12] <mozmck> I think you have to be 60+ year old to know tcl that well ;)
[19:55:03] <tinkerer> I've asked Gene.... ;)
[19:55:09] <mozmck> haha!
[19:56:28] <seb_kuzminsky> heh
[19:56:43] <mozmck> I need to learn it I guess. From what I saw looking the other day it looks like it has advantages over lua for many things.
[19:58:41] <tinkerer> try move the code:
[19:58:41] <tinkerer> state {$task_state == $STATE_ON && $taskfile != ""} \
[19:58:41] <tinkerer> .toolbar.program_step {.menu.machine "S_tep"}
[19:58:41] <tinkerer> some "state lines" up or down and then restart lcnc
[20:02:38] <seb_kuzminsky> tinkerer: what does that do?
[20:02:55] <tinkerer> or reorder the state invocations in proc update_state
[20:03:24] <seb_kuzminsky> what does "state" do in those statments? what is going on in that code?
[20:03:39] <seb_kuzminsky> (told you i dont know what i'm doing)
[20:03:53] <tinkerer> TCL error in asynchronous code:
[20:03:54] <tinkerer> bad option "_Pause": must be activate, add, cget, clone, configure, delete, entrycget, entryconfigure, index, insert, invoke, post, postcascade, type, unpost, xposition, or yposition
[20:03:54] <tinkerer> while executing
[20:03:54] <tinkerer> ".menu.machine "_Pause""
[20:03:54] <tinkerer> invoked from within
[20:03:54] <tinkerer> "if {$::last_interp_state != $::INTERP_IDLE || $::last_task_state != $::task_state} {
[20:03:54] <tinkerer> set_mode_from_tab
[20:03:55] <tinkerer> }"
[20:03:55] <tinkerer> (procedure "update_state" line 50)
[20:03:56] <tinkerer> invoked from within
[20:03:56] <tinkerer> "update_state"
[20:03:57] <tinkerer> ("after" script)
[20:04:38] <tinkerer> for instance
[20:05:05] <tinkerer> now it's ".menu.machine "_Pause""
[20:07:15] <seb_kuzminsky> ok, i moved it down a couple of state statements, and i get the error you just pasted
[20:08:45] <seb_kuzminsky> but i dont understand the significance of it
[20:08:47] <tinkerer> yep, and when you reorder the whole code then you get another error
[20:08:51] <seb_kuzminsky> yeah
[20:09:09] <seb_kuzminsky> what is causing the error? and why does it work with tcl 8.4 and 8.5, but not 8.6?
[20:09:30] <tinkerer> maybe its a stack issue
[20:09:34] <seb_kuzminsky> "wrong number of args" makes no sense to me
[20:09:47] <seb_kuzminsky> because i dont know who's args we're talking about
[20:09:52] <seb_kuzminsky> *whose
[20:11:24] <tinkerer> don't hardening on the type of error
[20:11:49] <tinkerer> after reordering the code i got:
[20:11:49] <tinkerer> TCL error in asynchronous code:
[20:11:49] <tinkerer> can't read "task_state": no such variable
[20:11:49] <tinkerer> while executing
[20:11:49] <tinkerer> "$task_state == $STATE_ON && ($interp_state == $INTERP_READING || $interp_state == $INTERP_WAITING) "
[20:11:50] <tinkerer> invoked from within
[20:11:50] <tinkerer> "if {$::last_interp_state != $::INTERP_IDLE || $::last_task_state != $::task_state} {
[20:11:51] <tinkerer> set_mode_from_tab
[20:11:51] <tinkerer> }"
[20:11:52] <tinkerer> (procedure "update_state" line 58)
[20:11:52] <tinkerer> invoked from within
[20:11:53] <tinkerer> "update_state"
[20:11:53] <tinkerer> ("after" script)
[20:18:07] <tinkerer> it's interesting that it's always on this point:
[20:18:08] <tinkerer> "if {$::last_interp_state != $::INTERP_IDLE || $::last_task_state != $::task_state} {
[20:18:08] <tinkerer> set_mode_from_tab
[20:18:08] <tinkerer> }"
[20:18:46] <tinkerer> *at
[20:23:06] <seb_kuzminsky> tinkerer: so proc state takes a statement and a list of widgets to modify state on
[20:23:17] <seb_kuzminsky> if the statement is true
[21:04:57] <tinkerer> seb_kuzminsky: to be honest I don't know how it realy works but changing the line after the last state-invocation the error has gone...
[21:04:57] <tinkerer> from
[21:04:57] <tinkerer> if { $::motion_mode == $::TRAJ_MODE_FREE && $::kinematics_type != $::KINEMATICS_IDENTITY} {
[21:04:57] <tinkerer> to
[21:04:58] <tinkerer> if { [uplevel \#0 [list expr {$::motion_mode == $::TRAJ_MODE_FREE && $::kinematics_type != $::KINEMATICS_IDENTITY}]]} {
[21:13:40] <aspect> that change shouldn't make any difference at all
[21:13:59] <tinkerer> shouldn't ;)
[21:14:17] * aspect is from #tcl and currently checkout out linuxcnc.git to see if I can help :-)
[21:15:37] <aspect> is itcl in use? There has been some breakage with 8.6/itcl4 releases
[21:17:14] <cradek> aspect: nope
[21:17:25] <cradek> aspect: and thank you for looking at it
[21:31:50] <aspect> hm. I'm not seeing anything obviously wrong on the script level, but as miguel@#tcl points out, 8.6 has some fairly big changes on the C side "that misbehave for some undocumented idioms that previously ran fine"
[21:35:40] <aspect> hopefully we can get some tools to figure out where that might be .. I see a lot of C using the Tcl API. That's less my forte, but by the time seb is back there will hopefully be some hints in #tcl
[21:43:14] <aspect> might also be worth trying a build against 8.6.3, which fixes a few issues in .2 but of course debian hasn't quite got it packaged yet
[22:10:54] <seb_kuzminsky> hi aspect, thanks for looking at our spaghetti
[22:14:24] <tinkerer> hmmmm, just putting the line
[22:14:24] <tinkerer> puts "whats going on....?"
[22:14:24] <tinkerer> between state lines and the if lines sweeps the error...
[22:14:24] <tinkerer> is this a timing issue?
[22:14:24] <tinkerer> ok, then good n8!
[22:15:55] <seb_kuzminsky> tinkerer: thanks for looking at it
[22:47:13] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6-tcl8.6-fix c39a7f2 06linuxcnc 10src/emc/usr_intf/Submakefile 10src/emc/usr_intf/emcrsh.cc 10src/emc/usr_intf/schedrmt.cc remove some dead code * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c39a7f2