#linuxcnc-devel | Logs for 2018-08-22

Back
[01:31:38] -!- hazzy-lab has quit [Read error: Connection reset by peer]
[01:33:58] -!- hazzy-lab has joined #linuxcnc-devel
[01:59:41] -!- KimK has quit [Remote host closed the connection]
[02:02:29] -!- hazzy-lab1 has joined #linuxcnc-devel
[02:05:56] -!- hazzy-lab has quit [Ping timeout: 276 seconds]
[02:05:57] hazzy-lab1 is now known as hazzy-lab
[03:29:30] -!- sockspls20 has joined #linuxcnc-devel
[03:36:53] -!- sockspls20 has quit [Ping timeout: 255 seconds]
[03:51:49] -!- selroc has joined #linuxcnc-devel
[03:54:41] -!- selroc has quit [Client Quit]
[04:05:32] -!- selroc has joined #linuxcnc-devel
[04:41:48] -!- ve7it has quit [Remote host closed the connection]
[04:56:53] -!- c-log has quit [Ping timeout: 276 seconds]
[04:58:12] -!- c-log has joined #linuxcnc-devel
[05:14:08] -!- rikai has joined #linuxcnc-devel
[05:16:44] -!- rikai has quit [Killed (Unit193 (Spam is not permitted on freenode.))]
[05:43:21] -!- KimK has joined #linuxcnc-devel
[07:28:45] -!- selroc has quit [Quit: Leaving]
[08:13:00] -!- meti9 has joined #linuxcnc-devel
[08:15:33] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15dngarrett pushed 2 new commits to 06master: 02https://github.com/LinuxCNC/linuxcnc/compare/0a3468b49eab...84a7b049ae11
[08:15:33] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06master 14ec4b6c6 15Dewey Garrett: show_errors.tcl: insert_file: info for open fail
[08:15:33] -linuxcnc-github:#linuxcnc-devel- 13linuxcnc/06master 1484a7b04 15Dewey Garrett: show_errors.tcl: messages for dmesg priv fail #486...
[08:17:42] -!- meti9 has quit [Remote host closed the connection]
[11:54:49] <seb_kuzminsky> jepler: sometimes there's a cron job that runs 'apt-get update', which locks the db
[12:32:19] -!- ve7it has joined #linuxcnc-devel
[13:27:32] -!- logs has joined #linuxcnc-devel
[13:27:52] -!- jepler has quit [Changing host]
[13:27:52] -!- jepler has joined #linuxcnc-devel
[13:27:57] -!- ve7it has joined #linuxcnc-devel
[14:25:10] -!- ve7it has quit [Quit: Leaving]
[14:25:30] -!- ve7it has joined #linuxcnc-devel
[14:31:35] -!- LawrenceG has joined #linuxcnc-devel
[14:32:19] -!- LawrenceG has quit [Client Quit]
[14:32:54] -!- ve7it has quit [Quit: Leaving]
[14:33:06] -!- ve7it has joined #linuxcnc-devel
[14:33:31] -!- ve7it has quit [Client Quit]
[14:33:50] -!- ve7it has joined #linuxcnc-devel
[14:37:18] -!- ve7it has quit [Client Quit]
[14:38:09] -!- JT-Shop has quit [Quit: Leaving]
[14:38:14] -!- ve7it has joined #linuxcnc-devel
[14:42:27] -!- jthornton has quit [Ping timeout: 240 seconds]
[14:42:58] -!- ve7it has quit [Quit: Leaving]
[14:44:18] -!- ve7it has joined #linuxcnc-devel
[15:09:30] -!- jthornton has joined #linuxcnc-devel
[15:56:39] -!- avelardi22 has joined #linuxcnc-devel
[16:04:28] -!- avelardi22 has quit [Ping timeout: 260 seconds]
[16:16:27] -!- jthornton has quit [Read error: Connection reset by peer]
[16:24:01] -!- jthornton has joined #linuxcnc-devel
[16:26:29] -!- JT-Shop has joined #linuxcnc-devel
[16:35:53] <hazzy-lab> # TODO: Change to Enum once we drop support
[16:35:53] <hazzy-lab> # for the almost dead and agonizing Python 2.7
[16:35:53] <hazzy-lab> # <pitchforks> Death to Python 2.7! </ pitchforks>
[16:35:53] <hazzy-lab> ^ proof that some gov employees do have a sense of humor
[16:35:53] <hazzy-lab> Mostly for jepler :D
[16:58:30] -!- KimK has quit [Quit: No Ping reply in 180 seconds.]
[16:59:46] -!- KimK has joined #linuxcnc-devel
[17:16:34] -!- Roguish has joined #linuxcnc-devel
[17:28:20] seb_kuzminsky is now known as python27
[17:28:25] <python27> i'm not dead yet!
[17:28:32] python27 is now known as seb_kuzminsky
[17:28:35] <hazzy-lab> LOL
[17:32:07] -!- Jin^eLD has joined #linuxcnc-devel
[17:35:39] <Jin^eLD> hi, I'm writing a hal component and I was hoping to get some hints on a few things; why are all input pins defined as (0+*__comp_inst->pin_name) ? I was about to save pin pointers in some local structs, it worked nicely for output pins as those are defined without "0+"
[17:36:29] <Jin^eLD> I am hesitant to bypass the defines and access __comp_inst directly, or would it be OK to do so?
[17:47:09] <seb_kuzminsky> if you feel the need to access comp's internal stuff directly you may be happier writing your component in C directly, then you get full access to everything, without having to 'peek behind the curtain'
[17:48:26] <Jin^eLD> well, I compared .comp code and the generated .c file, the comp version does really help a lot, speeds up the process significantly
[17:49:08] <Jin^eLD> but from your answer I understand that peeking would be OK if I'm prepared for unexpected redefines by a later halcompile version?
[17:49:34] <seb_kuzminsky> peeking is definitely ok with me :-)
[17:49:56] <Jin^eLD> cool, thanks :)
[17:49:58] <seb_kuzminsky> my main worry would not be that halcompile changes its mind about how to structure its hidden internals
[17:50:19] <Jin^eLD> ..but?
[17:50:28] <seb_kuzminsky> my main worry would be to understand the behavior of those internals well enough that what you do doesn't mess up what halcompile is trying to do
[17:51:05] <Jin^eLD> good point, although I do not think that I am doing anything "dangerious", just trying to access the pins in a sligtly different manner
[17:51:16] <Jin^eLD> *dangerous
[17:51:18] <seb_kuzminsky> go for it :-)
[17:52:24] <Jin^eLD> I have a gearbox that has 12 pins and a combination of those maps to a certain spindle speed... it kind of felt a lot simplier to create an array of those pin pointers and collect their values into a bitmask while looping over the array :)
[17:52:45] <seb_kuzminsky> that makes sense
[17:53:24] <Jin^eLD> worked fine with output pins, but the input pin define prevented me from saving &(pin)
[17:54:07] <Jin^eLD> I assume the 0+ thing is only for marking it as input somehow, at least as far as I understand it would not change anything technically?
[17:56:37] <seb_kuzminsky> i don't know what the "0+" is doing there... :-/
[17:56:57] <seb_kuzminsky> halcompile keeps track internally of what pins are inputs vs outputs
[17:58:07] <seb_kuzminsky> I would expect that when it writes the C output it doesn't annotate the C with that information in any explicit way (other than by making sure to pass in the correct flags when creating the pins)
[17:59:17] <Jin^eLD> well, the generated C code has those defines... or what did you mean by not annotating?
[17:59:31] <Jin^eLD> #define spindle_speed_in_abs (0+*__comp_inst->spindle_speed_in_abs)
[17:59:32] <Jin^eLD> vs
[17:59:32] <Jin^eLD> #define spindle_speed_out (*__comp_inst->spindle_speed_out)
[18:00:13] <Jin^eLD> I saw it as a weird way of marking input vs output, but to what end? if I read that correctly, both are the same to the compiler
[18:01:10] <Jin^eLD> of course if the reason was to prevent doing what I am doing on the input pins.... would be good to know :)
[18:02:21] <seb_kuzminsky> i agree with you, i think those are the same to the compiler
[18:02:38] <seb_kuzminsky> i don't know why halcompile makes the #defines different for input pins vs output pins
[18:03:51] <Jin^eLD> oh crap, that peekingn isn't that because if I try to use &(*__comp_inst->middle_left) then the pin name is of course a macro..
[18:04:00] <Jin^eLD> *isnt that easy
[18:04:35] <Jin^eLD> my notebook keyboard broke, typing on an external rubber thingie which is terrible and needs strong presses, sometimes I miss letters, sometmes whole words dammit
[18:04:37] <Jin^eLD> :)
[18:04:53] <seb_kuzminsky> i guess you could bypass the macro entirely and use '
[18:04:53] <seb_kuzminsky> The book is way longer than 8 minutes, and pretty dense:
[18:05:05] <seb_kuzminsky> oops, i mean:
[18:05:23] <seb_kuzminsky> use __comp_inst->middle_left without the macro or &
[18:06:03] <Jin^eLD> well, the macro is defined by halcompile further up
[18:06:13] <seb_kuzminsky> yes, but you don't have to use the macro
[18:06:17] <Jin^eLD> and indeed, now that you say it, why the hell am I stilldoing &(*) :))))
[18:06:29] <Jin^eLD> the macros name matches the pin name in the struct
[18:07:00] <Jin^eLD> wherever I use middle_left it gets expanded
[18:07:23] <Jin^eLD> or is there some way to bypass it "locally" without #undef'ing it?
[18:07:40] <seb_kuzminsky> you can just type "__comp_inst->spindle_speed_out"
[18:07:54] <seb_kuzminsky> __comp_inst is defined inside the FOR_ALL_INSTS() loop
[18:08:02] <seb_kuzminsky> and since you're peeking, you can just use it ;-)
[18:08:26] <seb_kuzminsky> no need to undef any of the macros, just ignore them
[18:09:52] <Jin^eLD> well.. that does not work that way.. unless you mean something that I am not aware of
[18:10:27] <seb_kuzminsky> why doesn't it work?
[18:10:41] <Jin^eLD> any __comp_inst->spindle_speed_out results in __comp_inst->(*__comp_inst->spindle_speed_out)
[18:11:03] <Jin^eLD> because of the define
[18:11:24] <Jin^eLD> ok i picked the wrong example (output), but for input its: #define spindle_speed_in_abs (0+*__comp_inst->spindle_speed_in_abs)
[18:11:40] <Jin^eLD> so any use of "spindle_speed_in_abs" expands
[18:11:59] <seb_kuzminsky> oh, right
[18:12:03] <Jin^eLD> let me google...
[18:12:15] <seb_kuzminsky> ok, so you *do* have to undef the macro, so it doesn't collide with the struct field
[18:12:54] <seb_kuzminsky> and then use the __comp_inst->field syntax consistently throughout your program
[18:13:40] <Jin^eLD> seems so...
[18:18:58] <Jin^eLD> kind of ugly, but I guess thats the price for peeking :P
[18:19:02] <Jin^eLD> thank you :)
[18:21:08] <Jin^eLD> time to hibernate, nite!
[18:21:15] -!- Jin^eLD has quit [Quit: Leaving.]
[18:30:35] -!- Jin^eLD has joined #linuxcnc-devel
[18:30:51] <Jin^eLD> could not leave it alone and just go to sleep heh, but I found the solution
[18:31:28] <Jin^eLD> #pragma push_macro("reducer_left")
[18:31:29] <Jin^eLD> #undef reducer_left
[18:31:30] <Jin^eLD> use __comp_inst->reducer_left as needed
[18:31:30] <Jin^eLD> #pragma pop_macro("reducer_left")
[18:31:59] <Jin^eLD> this way I do not have to know how the macro was defined and can restore it after I got my pointer assignments
[18:32:35] <Jin^eLD> feels safer than just to undef it forever
[18:32:50] <Jin^eLD> but now really time to sleep, thanks again for your help :)
[18:33:16] -!- Jin^eLD has quit [Client Quit]
[18:43:59] -!- Zic22 has joined #linuxcnc-devel
[18:47:09] -!- Zic22 has quit [Remote host closed the connection]
[19:25:33] -!- njh has quit [Ping timeout: 268 seconds]
[19:28:18] -!- njh has joined #linuxcnc-devel
[21:20:36] -!- njh has quit [Ping timeout: 252 seconds]
[21:22:57] -!- njh has joined #linuxcnc-devel
[21:24:45] -!- Tom_shop has joined #linuxcnc-devel
[21:29:55] -!- Tom_shop has quit [Changing host]
[21:29:55] -!- Tom_shop has joined #linuxcnc-devel
[21:41:19] -!- Tom_shop has quit [Quit: Leaving]
[21:46:38] <hazzy-lab> Is there a way to get the INI file that the currently running LCNC session was started with?
[21:46:39] <hazzy-lab> The INI_FILE_NAME environment variable will not work since it is only available in the environment LCNC is running in.
[21:46:39] <hazzy-lab> even a log file would do, I tried using linuxcnc_print.txt, but it is only generated when LCNC fails to load ..
[21:50:18] <hazzy-lab> I am thinking something like `import linuxcnc; linuxcnc.ini_file`
[21:50:29] <hazzy-lab> I was successfully able to add a new string constant to emcmodule.cc, but not sure if the INI file is available in that context
[22:29:30] -!- MarkusBec_ has joined #linuxcnc-devel
[22:29:31] -!- W1N9Zr0 has quit [*.net *.split]
[22:29:33] -!- MarkusBec has quit [*.net *.split]
[22:31:39] -!- W1N9Zr0 has joined #linuxcnc-devel
[23:23:54] -!- Roguish has quit [Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]]
[23:24:03] -!- zaratustra6 has joined #linuxcnc-devel
[23:27:27] -!- zaratustra6 has quit [Remote host closed the connection]
[23:39:55] -!- ve7it has quit [Remote host closed the connection]