Back
[08:03:44] <mozmck> seb_kuzminsky: I was able to successfully rebase your deb-configure branch onto 2.7 I also checked and master is the same as 2.7 for those files so rebasing there would be trivial as well.
[08:05:57] <mozmck> Looking at the logs for 2.7/master since you branched, there is not much changed at all. Just a few dependencies and settings for Debian 8
[09:10:36] <mozmck> seb_kuzminsky: I ran ./configure now in 2.7 and in new-deb-configure (made a couple small modifications first). So far I see one small problem. In 2.7 libudev-dev is a dependency of linuxcnc-uspace - shouldn't that just be libudev?
[09:12:16] <mozmck> In new-deb-configure libudev-dev is not added as a dependency to linuxcnc-uspace, but it is in Build-Depends
[09:26:25] <mozmck> another thing I notice is that the linuxcnc-dev package in 2.7 depends on g++, but in the new-deb... on build-essential and not g++
[09:26:42] <mozmck> Which is right, or should it be both?
[09:28:16] <mozmck> I see, build-essential depends on gcc and g++, so that is probably better.
[09:45:18] <seb_kuzminsky> hey mozmck
[09:46:43] <mozmck> hi seb
[09:46:56] <seb_kuzminsky> i think you're right it's a bug in 2.7 and master that we depend on libudev-dev, that should be a build-dependency
[09:47:01] <mozmck> ok
[09:47:24] <mozmck> Looks like your stuff works well except for a couple minor things like that.
[09:48:06] <seb_kuzminsky> and i think build-depending on build-essential is an improvement over g++, it's simpler & clearer & more future-proof, without increasing the number of packages needed to build by very much
[09:48:19] <mozmck> yes, looks good to me.
[09:48:28] <seb_kuzminsky> i think both the differences you pointed out are improvements in new-deb-conf
[09:48:31] <seb_kuzminsky> ;-)
[09:49:06] <seb_kuzminsky> thanks for doing the rebase, if you fix the tcl thing & force-push the branch i'll be happy to take a look at it
[09:49:26] <mozmck> I may test a little more - I have a wheezy system I can test with also.
[09:49:38] <mozmck> what is wrong with the tcl thing?
[09:50:27] <mozmck> is depending on tcl-dev and tk-dev not right?
[09:50:57] <mozmck> you forced tcl-8.5 for ubuntu 10.04
[10:20:15] <seb_kuzminsky> mozmck: my understanding on that is kinda fuzzy, jepler told me in houston that you need to control what version of tcl you build against but i didnt really get it
[10:23:59] <seb_kuzminsky> in master (but not in 2.7) there's a new test that makes sure linuxcnc's tcl stuff isn't broken, tests/tclsh-extensions
[10:24:14] <seb_kuzminsky> whichever branch new-deb-conf lands in should have that tests
[10:24:17] <seb_kuzminsky> *test
[10:31:22] <mozmck> hmm, is that part of the packaging?
[10:34:00] <seb_kuzminsky> it's part of both packaging and configuring/building
[10:34:50] <mozmck> how does that affect the changes to configure/control.in/rules.in?
[10:35:02] <seb_kuzminsky> during the config/build phase you need to build the tcl extensions (our tclish linuxcnc.so and hal.so) against a specific version of tcl/tk, then you need to package the debs so they depend on the right version on the users' machines
[10:35:20] <mozmck> I checked between master and 2.7 and saw no difference there.
[10:35:52] <seb_kuzminsky> i had mistakenly (apparently) thought it was ok to just use whatever version of tcl the system installed by default (ie, to build-depend on tcl-dev instead of tcl$VERSION-dev)
[10:36:17] <mozmck> ah, so the TCLTK_VERSION stuff needs to be done in the python configure somehow.
[10:36:23] <seb_kuzminsky> so i wrote new-deb-conf's debian/configure to do that
[10:36:40] <seb_kuzminsky> but jeff objected, and wrote a test to prove me wrong
[10:36:46] <seb_kuzminsky> which i dont understand
[10:36:47] <seb_kuzminsky> :-(
[10:36:50] <mozmck> ok. I'll look at that. :)
[10:36:55] <seb_kuzminsky> and now i remember why i never finished this branch :-(
[10:37:24] <seb_kuzminsky> it may be that some distros have a tcl-dev that's fine for us, and some need to be overridden (like 10.04 apparently)
[10:37:25] <mozmck> That doesn't *sound* too hard, but maybe that's because of my ignorance :)
[10:37:40] <seb_kuzminsky> it's easy to do, but i dont know what needs to be done exactly
[10:37:58] <seb_kuzminsky> some more stanzas like the 10.04 tcl-dev version override, but which distros & which versions?
[10:38:01] <seb_kuzminsky> bbl
[10:38:12] <mozmck> bbl here too.
[11:21:46] <REEEN> Test message (sorry)
[11:22:15] <skunkworks> Echo
[11:27:23] <seb_kuzminsky> http://www.pbfcomics.com/271/
[11:34:47] <seb_kuzminsky> mozmck: i think i figured it out
[11:35:07] <seb_kuzminsky> we need python-tk, and it's built against a specific version of tk, so we need to use that version of tk too
[11:35:58] <seb_kuzminsky> on all distros(?) except lucid (10.04), the default version of tk is the version python-tk is built against, but on 10.04 tk defaults to 8.4 and python-tk is built against 8.5, so we need to override the default
[13:01:14] <cradek> I wonder when machinekit will get around to changing the name of everything, so we avoid stuff like
http://linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/28869-problem-in-starting-linuxcnc-raspberry-b
[13:03:04] <seb_kuzminsky> kudos to andypugh and arceye for being as civil & helpful to the poor mk user are they were
[13:03:06] <CaptHindsight> oh stop being so arrogant :)
[13:03:07] <cradek> it's not the end of the world, but it's probably quite frustrating for the (their) user
[13:03:24] <cradek> yeah, those guys are both awesome
[13:03:58] <cradek> unfortunately rebranding is very hard and tedious :-/
[13:05:26] <seb_kuzminsky> yeah, i remember how hard you and jeff et al worked on that when we had to rebrand
[13:12:49] <skunkworks> http://www.cnczone.com/forums/tormach-personal-cnc-mill/259506-tormach.html
[13:13:15] <skunkworks> heh
[13:13:16] <skunkworks> They are going to be launching their own proprietary control software and will be transitioning away from mach
[13:14:49] <cradek> they announced that they will make an announcement?
[13:14:57] <skunkworks> hype
[13:15:30] <cradek> that's gotta be a good way to kill your sales in the short term
[13:18:34] <tjtr33> hal functions have .time pins ( eg ddt_x.time from sim/axis_mm.ini) but i have problem connecting it to a minmax comp.
[13:18:35] <tjtr33> "./core_simFunctionLatencyMax.hal:50: Pin 'ddt_x.time' does not exist"
[13:18:47] <tjtr33> trying to automate some latency testing
[13:19:15] <micges> those are params not pins
[13:20:14] <tjtr33> so i can only plot thx
[13:20:27] <micges> yeah
[13:20:53] <tjtr33> this data typing is unfriendly ;)
[13:35:16] <seb_kuzminsky> tjtr33: a patch to convert the function time params to output pins would be welcome
[13:39:16] <tjtr33> seb_kuzminsky, trying to write one now. trying to capture the c output of the 'halcomp' tool to look at the c src
[13:39:56] <tjtr33> like where are these variables like 'period' and 'fperiod' listed
[13:40:50] <tjtr33> ( sec 12.1 of hal manual & the src for ddt.comp )
[14:07:25] <PCW> I guess the reason they are not scaled to nS is that that would require a floating point thread (or do all threads have FP now?)
[14:20:20] <tjtr33> seb_kuzminsky, PCW hack params to pins in halcompile ?
http://pastebin.com/GEEmR0Sg
[14:42:19] <skunkworks> zlog
[15:08:05] <tjtr33> what creates the .time parameter? its not in the .c output of halcompile --perprocess blah.comp
[15:43:45] <tjtr33> i dont think the .time param is in the comp itself. it something aligned with the comp at runtime. i cant see it in the .ko file
[15:48:45] <micges> tjtr33: .time is created directly by hallib while creating realtime function structure
[15:50:43] <tjtr33> thx
[15:52:54] <tjtr33> new->runtime = 0; sheesh!
[15:53:21] <tjtr33> code that cant be specified by the source files
[15:54:18] <tjtr33> can the new pins be hacked into hallib.c then ?
[15:56:54] <micges> what pins?
[15:58:37] <tjtr33> create a .time pin, like the .time param, so we can monitor real latency of function calls
[16:01:35] <tjtr33> line 1700 of hal_lib.c " hal_param_s32_new(buf, HAL_RO, &(new->runtime), comp_id); change to make a hal pin for debugging
[16:05:19] <tjtr33> thx miges, gotta stop cant stare at lcd this long. faded grey text on white text srceen = migrane
[16:06:02] <micges> heh change to green on black :D
[16:09:00] <tjtr33> ahhhh thanks!
[16:09:20] <tjtr33> ( chgd the irc colors )
[16:10:54] <mozmck> seb_kuzminsky: so does that mean the configure as you have it is fine?
[16:42:04] <dgarr> tjtr33: seb_kuzminsky a patch to convert .time params to pins (tested briefly on uspace 2.7 precise):
[16:42:05] <dgarr> http://www.panix.com/~dgarrett/stuff/0001-hal_lib-change-.time-item-from-parameter-to-pin.patch
[16:59:49] <tjtr33> dgarr, thx, will try as soon as i can focus
[17:00:25] <tjtr33> exactly where id hack it ( heh so very suspect :)
[17:03:17] <dgarr> ok -- let us know, i had worked on this for my own use a long time ago. it might be usefult to make a conp and utility for histogramming .time pins
[17:08:08] <tjtr33> i was thinking just connecting to minmax comp and using halmeter, but plots are more informative. timestamps moreso
[17:52:34] <KGB-linuxcnc> 03Francis Tisserant 05seb/master/po4a 98eb690 06linuxcnc 03docs/src/config/lathe_config_fr.txt french translation po4a * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=98eb690
[17:52:34] <KGB-linuxcnc> 03Francis Tisserant 05seb/master/po4a 5f38ef7 06linuxcnc 03docs/html/index_fr.html French translation, update structure of index_fr.html * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5f38ef7
[19:14:59] <andypugh> The search-box on the left, when fed “latency histogram” does not actually find out that there is a script in /scripts for creating them.
[22:58:03] <tjtr33> hello, --enable-run-in-place no longer an option to configure?
[22:58:12] <tjtr33> tomp@lptp-1004snd:~/linuxcnc-dev/src$ ./configure --enable-run-in-place
[22:58:13] <tjtr33> configure: WARNING: unrecognized options: --enable-run-in-place
[22:58:34] <seb_kuzminsky> tjtr33: right, that's gone away a while ago
[22:58:47] <tjtr33> uh web docs not up to date
[22:58:52] <seb_kuzminsky> nowdays, if you don't specify a --prefix, you get the old run-in-place behavior
[22:58:56] <seb_kuzminsky> link please?
[22:59:18] <seb_kuzminsky> bummer, i missed dgarr
[22:59:25] <tjtr33> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Installing_LinuxCNC#Building_LinuxCNC_realtime section 2.5
[22:59:53] <seb_kuzminsky> thanks
[23:00:00] <seb_kuzminsky> yep, that's out of date
[23:00:01] <tjtr33> did you see his patch?
[23:00:09] <tjtr33> for pins for time
[23:00:13] <seb_kuzminsky> i saw it and i'd like to give him some feedback
[23:00:42] <tjtr33> oh, i just edited it in and was building, is it ok to try?
[23:01:10] <seb_kuzminsky> err, probably
[23:01:15] <seb_kuzminsky> let me know if it works!
[23:01:26] <tjtr33> k
[23:01:30] <seb_kuzminsky> will you update the wiki build instructions or should i?
[23:03:06] <tjtr33> i can in a bit, plan on it tonight
[23:04:19] <seb_kuzminsky> cool, thanks
[23:05:28] <seb_kuzminsky> heh, --enable-run-in-place was deprecated before 2.4.0 came out
[23:10:07] <seb_kuzminsky> dgarr (if you read back): i think there's no need to move runtime to its own struct, i think it's fine to stay in hal_funct_t
[23:11:13] <seb_kuzminsky> in hal_export_funct(), new comes from alloc_funct_struct(), which gets it from the hal shm just like hal_malloc() does
[23:12:55] <seb_kuzminsky> if you *do* decide to keep it as a separate struct, it's good that you delay the call to hal_malloc() for the hal_funct_pins_t struct until after dropping the mutex
[23:13:22] <seb_kuzminsky> but in that case you should check the return value of hal_malloc() and handle out-of-memory errors
[23:13:44] <seb_kuzminsky> maybe maxtime should be a pin too?
[23:14:14] <seb_kuzminsky> tjtr33: huh, did you know there's already a maxtime parameter from each hal function?
[23:14:47] <seb_kuzminsky> you had said you were going to connect a time pin to a minmax, maybe you want the min too (which isn't currently exported at all)
[23:22:17] <tjtr33> yes i saw that, and didnt know it existed
[23:23:11] <tjtr33> but you cant wire a parameter to a hal comp :( so you can graph it, but cant automate it
[23:48:48] <tjtr33> seb_kuzminsky, it built ok, i have .time pins for functs. will consider the other points after updating wiki
http://ibin.co/1ragyBhzspo9
[23:48:53] <tjtr33> thx dgarr
[23:52:32] <seb_kuzminsky> that's good
[23:52:47] <seb_kuzminsky> i wonder if we have any comps that try to make a pin called 'time' themselves
[23:53:21] <seb_kuzminsky> nope, doesn't look like it