Back
[00:24:56] -!-
cylly2 has quit [Ping timeout: 252 seconds]
[00:28:44] -!-
Thetawaves has quit [Quit: This computer has gone to sleep]
[00:39:33] -!-
syyl has quit [Quit: Leaving]
[00:59:55] -!-
servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[01:11:46] -!-
atom1 has quit [Client Quit]
[01:31:05] -!-
dimas__ has quit [Read error: Connection reset by peer]
[01:33:35] -!-
skunkworks [skunkworks!~chatzilla@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[01:42:47] -!-
andypugh has quit [Quit: andypugh]
[02:01:53] -!-
atom1 has quit [Client Quit]
[02:41:20] -!-
demacus has quit [Ping timeout: 246 seconds]
[02:43:23] -!-
sumpfralle has quit [Ping timeout: 245 seconds]
[02:48:20] -!-
robin_sz has quit [Ping timeout: 246 seconds]
[03:10:00] -!-
FinboySlick has quit [Quit: Leaving.]
[03:39:02] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[04:14:19] -!-
JT-Shop has quit [Read error: Connection reset by peer]
[04:14:19] -!-
jthornton has quit [Read error: Connection reset by peer]
[04:15:02] -!-
JT-Shop [JT-Shop!~John@184.20.140.167] has joined #linuxcnc-devel
[04:15:05] -!-
jthornton [jthornton!~john@184.20.140.167] has joined #linuxcnc-devel
[04:20:13] -!-
iwoj_ has quit [Quit: Computer has gone to sleep.]
[04:45:32] -!-
Valen has quit [Quit: Leaving.]
[04:48:55] -!-
ajrabassa has quit [Quit: Leaving]
[04:56:46] -!-
dimas_ has quit [Ping timeout: 276 seconds]
[05:02:56] -!-
Fox_M|afk has quit [Ping timeout: 265 seconds]
[05:08:12] -!-
iwoj has quit [Read error: Connection reset by peer]
[05:13:56] -!-
dgarr has quit [Ping timeout: 246 seconds]
[05:31:42] -!-
iwoj has quit [Quit: Computer has gone to sleep.]
[05:39:38] -!-
psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[05:42:16] -!-
Thetawaves has quit [Quit: This computer has gone to sleep]
[06:05:04] -!-
mhaberler has quit [Quit: mhaberler]
[06:05:20] -!-
Guthur has quit [Remote host closed the connection]
[06:32:37] -!-
vladimirek has quit [Remote host closed the connection]
[06:40:21] -!-
KimK has quit [Ping timeout: 248 seconds]
[06:42:19] -!-
Keknom has quit [Quit: Leaving.]
[06:57:14] -!-
berndj has quit [Ping timeout: 255 seconds]
[07:15:07] -!-
micges [micges!~micges@djq145.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[07:46:29] -!-
mk0 has quit [Ping timeout: 248 seconds]
[07:49:49] -!-
Valen has quit [Quit: Leaving.]
[07:54:14] -!-
robin_sz has quit [Ping timeout: 246 seconds]
[08:03:07] -!-
Valen has quit [Quit: Leaving.]
[08:04:56] -!-
iwoj has quit [Quit: Computer has gone to sleep.]
[08:09:40] -!-
Thetawaves has quit [Quit: This computer has gone to sleep]
[08:16:17] -!-
micges_ [micges_!~micges@dcg23.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[08:18:38] -!-
micges has quit [Ping timeout: 240 seconds]
[08:21:04] -!-
rob_h [rob_h!~rob_h@027c18f3.bb.sky.com] has joined #linuxcnc-devel
[08:33:55] micges_ is now known as
micges
[08:37:50] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[09:01:18] -!-
Poincare has quit [Quit: changing servers]
[09:12:56] -!-
mhaberler has quit [Quit: mhaberler]
[09:15:44] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[09:18:59] -!-
micges has quit [Remote host closed the connection]
[10:13:59] -!-
psha[work] has quit [Quit: Lost terminal]
[10:20:03] -!-
mhaberler has quit [Quit: mhaberler]
[10:52:22] -!-
sumpfralle has quit [Quit: Leaving.]
[10:57:46] -!-
Valen has quit [Quit: Leaving.]
[11:10:21] -!-
iwoj has quit [Quit: Computer has gone to sleep.]
[11:17:19] -!-
micges [micges!~micges@dcg23.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[11:17:40] -!-
factor has quit [Quit: Leaving]
[13:20:49] -!-
mrsun has quit [Read error: Connection reset by peer]
[13:26:59] <jepler> dgarr: thanks, that is more or less what I thought was the case. (ngcgui_lib)
[14:15:00] -!-
mk0 has quit [Read error: Connection reset by peer]
[14:23:54] -!-
psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[15:25:34] -!-
A0Sheds has quit [Quit: puff of smoke]
[15:52:04] -!-
dimas has quit [Remote host closed the connection]
[16:01:07] -!-
sumpfralle has quit [Ping timeout: 244 seconds]
[16:25:12] -!-
Tom_L has quit [Client Quit]
[16:46:09] -!-
IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 12.0/20120423130206]]
[17:12:52] -!-
sumpfralle has quit [Ping timeout: 256 seconds]
[17:20:34] -!-
maximilian_h [maximilian_h!~bonsai@130.255.104.157] has joined #linuxcnc-devel
[17:36:09] -!-
andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[17:57:27] -!-
toastydeath has quit [Read error: Connection timed out]
[18:06:46] -!-
phantoxe has quit []
[18:39:07] -!-
ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[19:00:43] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[19:19:10] -!-
vladimirek has quit [Remote host closed the connection]
[19:30:33] -!-
toastydeath has quit [Read error: Connection timed out]
[19:56:14] <CIA-68> 03mhaberler 07master * r394be3e65914 10/configs/sim/remap/python-stdglue/stdglue.py: remap/stdglue: force sync() when finishing an M6
[20:00:06] <mhaberler> jepler: I'd be grateful if you could look over
http://git.mah.priv.at/gitweb/emc2-dev.git/commit/2d3ed23aaebbf40ccd23d33f5b6a47eab8147990 - no comprende Tcl here
[20:12:16] -!-
syyl_ws has quit [Remote host closed the connection]
[20:21:43] -!-
pepijndevos has quit [Remote host closed the connection]
[20:34:07] -!-
DJ9DJ has quit [Quit: bye]
[20:43:49] -!-
psha has quit [Quit: Lost terminal]
[20:48:04] -!-
ve7it has quit [Remote host closed the connection]
[20:58:53] -!-
RagingComputer has quit [Ping timeout: 260 seconds]
[21:05:11] -!-
maximilian_h has quit [Quit: Leaving.]
[21:15:14] -!-
bedah has quit [Quit: gn8]
[21:18:19] -!-
maximilian_h [maximilian_h!~bonsai@anon-164-63.vpn.ipredator.se] has joined #linuxcnc-devel
[21:18:24] -!-
maximilian_h has quit [Client Quit]
[21:20:44] -!-
atex57 has quit [Client Quit]
[21:32:24] <andypugh> Jepler? Do you know what is going on here?
[21:32:28] <andypugh> #undef tx_data
[21:32:28] <andypugh> #define tx_data(i) (0+*(__comp_inst->tx_data[i]))
[21:32:30] <andypugh> #undef rx_data
[21:32:31] <andypugh> #define rx_data(i) (*(__comp_inst->rx_data[i]))
[21:32:32] <andypugh> #undef bytes
[21:32:33] <andypugh> #define bytes (0+*__comp_inst->bytes)
[21:32:47] <andypugh> Those 0+ things look wrong.
[21:33:22] <andypugh> (I get " lvalue required as left operand of assignment" which makes sense with that subsititution)
[21:34:27] <andypugh> I am puzzled why txdata and rxdata are different, though the pattern is that input pins get the 0+ I think
[21:34:37] <andypugh> I have a vague memory this got fixed,,,
[21:42:15] <jepler> andypugh: it's what comp puts in the macro to make assigning to an input pin an error
[21:42:46] <jepler> this is a valid assignment: (*inst->pin) = 1;
[21:42:56] <jepler> but this isn't: (0+*(inst->pin)) = 1;
[21:43:55] <andypugh> Ah. OK, yes.
[21:44:38] <andypugh> I am trying to limit the value of the input, but I am doing it after the fashion of an imbecile.
[21:45:30] <jepler> to do that you will need to introduce a temporary value
[21:46:04] <jepler> x = rx_data(0); if(x < 0) x = 0; ...
[21:46:13] <andypugh> I guess that is a compiler error, so no scope for making it clearer, like "you are being daft again, andy, that's an input pin"
[21:46:38] <jepler> mhaberler: I suspect that you meant to remove the line 'enable_group $::manual' from within 'if {$::interp_state == $::INTERP_IDLE}'
[21:46:50] <jepler> since it'll either be enabled or disabled just below
[21:47:10] <mhaberler> let me see..
[21:48:14] <mhaberler> no, that is not the case. If the interp is running (STATE_ON=1, interp_state != INTERP_IDLE) you can queue a command iff there's place in the queue
[21:48:58] <mhaberler> so when queuing a command and interp is already executing an mdi command, the first test wont bite
[21:49:45] <jepler> when $::interp_state == $::INTERP_IDLE and $::queued_mdi_commands < $::max_queued_mdi_commands then you enable_group $::manual twice
[21:50:01] <mhaberler> right
[21:50:44] <jepler> does that mean it should be an elseif?
[21:50:50] <mhaberler> ah, could move that to an elseif, yes
[21:51:07] <jepler> it's OK to enable something twice; the last enable or disable is the one that sticks
[21:51:18] <mhaberler> thats what I thought
[21:52:57] <jepler> you'll need to update other UIs to send EMC_TASK_PLAN_EXECUTE_MDI, or maybe the new message should be the one issued internally in task so that fewer changes required(?)
[21:54:14] <mhaberler> the reason for making a new NML message was to make it distinguishable fro EMC_TASK_PLAN_EXECUTE which might be internally generated
[21:55:26] <mhaberler> the other alternative to deal with this is to introduce a new interp state which indicates 'running and queue full'
[21:55:48] <mhaberler> some backpresse on UI is needed to disable input window if q full
[21:56:22] <mhaberler> so I dont see how I get away with 0 UI change
[21:56:34] <mhaberler> but less would be good of course
[21:57:04] <jepler> introduce EMC_TASK_PLAN_EXECUTE_INTERNAL and use it for "internally generated"
[21:57:11] <jepler> leave EMC_TASK_PLAN_EXECUTE as is
[21:57:21] <mhaberler> yes, makes sense
[21:58:14] <jepler> is it the one in static void mdi_execute_hook(void)
[21:58:15] <jepler> ?
[21:58:35] <mhaberler> for instance, yes - but also after queuebuster ops
[21:58:44] <jepler> ah, a topic which I have not followed
[21:59:08] <mhaberler> that was a wise decision
[21:59:14] <jepler> :-/
[21:59:43] <mhaberler> that is one of the most underdesigned, kludgy and error prone areas of the whole animal
[22:00:55] <mhaberler> and it prompted me to write this up (for v3)
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?QueuebustersRevisited
[22:03:07] <mhaberler> re this fix: I fear introducing new interpstates to convey 'q full' will basically double the number of states, so it doesnt strike me as a good solution
[22:03:20] -!-
dimas has quit [Ping timeout: 246 seconds]
[22:04:09] <jepler> since I love numbered parameters so much, let me point out that you can do indirection with them
[22:04:21] <jepler> ##5500
[22:04:39] <mhaberler> you're my G-code readability hero...
[22:05:01] <jepler> so now you're 5070 seconds into executing the program...
[22:05:05] <mhaberler> oh, re tainting..
[22:05:48] <mhaberler> that multiple indirection feature needs to be killed. It's tantamount to a self-modifying program.
[22:06:28] <mhaberler> oh, a board issue: feature deprecation.
[22:07:00] <mhaberler> indirection, and indirect calls
[22:07:09] <andypugh> mhaberler: It is part of what lets you emulate arrays thought.
[22:07:41] <mhaberler> that is not a good reason to keep it - rather have a bona-fide array
[22:07:56] <andypugh> In G-code!?
[22:08:05] <jepler> I do in fact know of a program that uses variable indirection for this purpose
[22:08:15] <andypugh> That fusee?
[22:08:21] <jepler> yes, jmk's fusee
[22:08:32] <mhaberler> if you absolutely, positively need to have an array, its trivial do do with a python oword subroutine
[22:09:10] <andypugh> But what is wrong with a self-modifying program anyway?
[22:09:30] <mhaberler> fifty years of computer science?
[22:09:57] <mhaberler> it basically kills most options for static analysis and is a great way to shoot youself in the foot
[22:10:01] <andypugh> "Appeal to Authority" is a logical fallacy :)
[22:10:33] <andypugh> Yes, but, G-code isn't a programming language.
[22:10:42] <mhaberler> I'm not from that camp - it is frowned upon for very good reasons
[22:11:05] <jepler> I guess I think of it as indirectio, not self-modification
[22:11:11] <jepler> +n
[22:11:22] <andypugh> I doubt that anyone performs static analysis on G-code, and not only does it allow you to shoot yourself in the foot, it lets you machienthe foot right off.
[22:12:14] <mhaberler> but the argument is still valid: jepler came up with the indirect oword label when cradek and me were fixing is - this is possible but simply pathologic
[22:12:27] -!-
servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[22:12:27] <jepler> we should fix the interpreter to not allow anything but number literals in some places, like in O SUB
[22:12:28] <andypugh> That too, it changes data, not behaviour.
[22:12:34] <mhaberler> definitely
[22:12:47] <mhaberler> very much in favor
[22:13:23] <andypugh> O<#10> SUB bothers you?
[22:13:42] <mhaberler> halting problem: undecidable
[22:13:51] <mhaberler> so: yes, it does
[22:14:47] <jepler> http://pastebin.com/TwvTmc8V
[22:14:49] <andypugh> No sense of adventure some folks.. You should have seen my BASIC games, computed GOTOs all over the place, and (very nearly) objects too (an array of strings of user-defined functions which were evaluated to determine the tactics displayed by a piece)
[22:14:52] <mhaberler> btw if you need an array example without milling your feet off, I'm happy to cook one up - what exactly is the use case
[22:14:54] <jepler> you'd have to decide what this program actually means
[22:15:26] <jepler> now, you could define the language so that O ENDSUB doesn't need a number; it matches the only thing it could match (and the same for all the other O ENDs)
[22:15:51] <mhaberler> you're right - you cant even determine whether it will execute without error in advance, nevermind halting
[22:16:44] <andypugh> Optional end points if it changes #1 inside the sub.
[22:17:02] <jepler> er, I meant to include '#1 = 1' after ENDSUB
[22:17:28] <mhaberler> what is 'jmk's fusee'?
[22:17:36] <jepler> also I'm not sure if <> are supposed to be there
[22:17:59] <mhaberler> no, because in your case those would be the literal '#1', not the ref to param 1
[22:18:03] <andypugh> I agree that there seems no place for computed osubs
[22:18:23] <jepler> so anyway, you could argue that the code's an error, since there's no O1 SUB (only O2 SUB, given the value #1 had at the time O SUB was encountered), or you could argue that there is (since #1 has the value 1 when the CALL is encountered and the SUB is sought)
[22:18:31] <andypugh> mhaberler:
http://jmkasunich.com/cgi-bin/blosxom/shoptask/fusee-1.html
[22:18:32] <jepler> but once inside, #1 has the value 3, so the ENDSUB doesn't match the SUB...
[22:19:04] <mhaberler> thanks
[22:19:55] <jepler> so anyway .. I'd be really tempted to modify o words so that: only sub and call take numbers; at least sub must be a literal number. all the rest don't "need" numbers; they're to make a simple implementation easier. we can immediately make them optional with a warning if they are supplied but don't match...
[22:20:02] <jepler> (immediately = after substantial interpreter work)
[22:21:01] -!-
micges has quit [Quit: Leaving]
[22:21:52] <andypugh> I guess "numbers" includes "strings"?
[22:22:06] <mhaberler> I guess he means literals
[22:22:25] <mhaberler> btw… to strengthen oword label matching, I had to dump your pseudoMdiLinenumber thing, which in turn required fixing motion to not treat 0 special...
[22:23:08] <mhaberler> now MDI oword sub calls actually report line numbers with some bearing on source location
[22:23:26] <jepler> yes, literals
[22:23:35] <jepler> mhaberler: I was vaguely aware of that going by...
[22:24:22] <mhaberler> this was a classic case of collective unconscious: people had been coding around this motion id zero wart for years
[22:25:12] <mhaberler> if you now load a oword ngc file and call it from MDI, axis does the right thing on current line feedback
[22:25:34] <mhaberler> it just doesnt do subroutine file tracking, but thats another issue
[22:27:00] <mhaberler> jepler: could we summarize your proposal once more? I'll try.. probably KenL should have a look
[22:27:30] <mhaberler> 'sub and ensub labels shall be literals - no expressions allowed'
[22:28:02] <mhaberler> I would tend to say: same for call
[22:32:39] <jepler> I would rather not throw that out with the bathwater
[22:33:55] <jepler> as far as I know there's no use case for non-literals in those other cases, but there is arguably a use for a variable O CALL
[22:34:16] <mhaberler> case statement emulation?
[22:34:29] -!-
toastydeath has quit [Ping timeout: 246 seconds]
[22:34:31] <jepler> well .. one I'm thinking of is daisy.ngc
[22:35:07] <jepler> if there were a numbered paramter for 'axes present', then instead of the G1 X Y Z A it could be O#<axismask> call
[22:35:23] <jepler> and whatever axes are present would be handled, in the ... 511 O SUBs required
[22:35:42] <jepler> maybe not the best example to make up
[22:36:34] <mhaberler> I'm losing you - what's this 'axes present' thing?
[22:36:44] <jepler> a bitmask of axes in the machine
[22:36:58] <jepler> 1 for X, 2 for Y, ..., 2^8 = 256 for W
[22:36:58] <mhaberler> you mean configured?
[22:37:17] <mhaberler> adding a predefined named param is roundabout 10 loc
[22:37:54] <mhaberler> is that generally useful?
[22:38:06] <jepler> oh probably not
[22:38:19] <jepler> I mean, how many part programs are going to adapt to a Z axis being present or absent
[22:38:43] <mhaberler> actually, it probably can be fished out of _setup by a Python oword sub without any code change
[22:39:07] <mhaberler> since basically all of _setup is exposed in embedded Python
[22:42:17] <mhaberler> ok, so re queued MDI - I'll massage the names of the EMC_TASK_PLAN_EXECUTE* messages hoping for lower impact. thanks!
[22:42:25] <jepler> OK
[22:42:28] <jepler> I'm glad I could offer some feedback
[22:42:42] <jepler> I'll bbl
[22:42:45] <mhaberler> cu!
[22:54:51] <mhaberler> jepler: bad news. There is a good reason to retain both EMC_TASK_PLAN_EXECUTE and EMC_TASK_PLAN_EXECUTE_MDI at the UI level:
[22:55:48] <mhaberler> the former is non-queued, the latter IS queued. This, btw, is the reason why I posed the question here whether we should make auto runs queued as well, both on IRC and ml
[22:56:06] <mhaberler> if both are queued - no reason to distinguish
[22:56:54] <mhaberler> oh.. let me check again..
[22:56:59] -!-
atex57 has quit [Quit: ChatZilla 0.9.61 [Mozilla rv:1.7/20040617]]
[22:58:04] <mhaberler> uh, sorry, I was wrong. re UI - EMC_TASK_PLAN_EXECUTE is used only for MDI; the other uses of EMC_TASK_PLAN_EXECUTE are in task only so its possible
[23:21:32] -!-
Keknom has quit [Quit: Leaving.]
[23:22:42] -!-
mhaberler has quit [Quit: mhaberler]
[23:27:38] -!-
syyl has quit [Quit: Leaving]
[23:30:18] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[23:39:07] -!-
rob_h has quit [Ping timeout: 252 seconds]
[23:50:22] -!-
FinboySlick has quit [Quit: Leaving.]
[23:50:40] -!-
FinboySlick1 has quit [Quit: Leaving.]
[23:51:49] -!-
phantoxeD has quit [Ping timeout: 245 seconds]