Back
[01:08:20] <ries> hey Guys, openssl x509 -noout -text -in public.crt gives me 581:error:0906D064:PEM routines:PEM_read_bio:bad base64 decode:pem_lib.c:753:
[01:10:01] <ries> wrong channel :)
[01:10:22] <seb_kuzminsky> heh
[06:02:58] <seb_kuzminsky> anyone know why we install a bunch of lib*.so files into /usr/lib? turns out there's no need, it's the lib*.so.0 files (that we also install) that matter
[06:05:36] <cradek> I think normally you install .so.N and ldconfig makes symlinks
[06:06:24] <cradek> ok, that information is probably 15 years old...
[06:06:35] <cradek> ldconfig ignores symlinks now
[06:06:49] <cradek> so I replace my answer with 'dunno, sorry'
[06:08:23] <cradek> er yes I guess it still works that way
[06:09:16] <cradek> seems likely that .so without version number doesn't belong in the packages
[06:13:43] <seb_kuzminsky> lintian agrees that *.so does not belong in the package
[06:14:21] <seb_kuzminsky> the usual way it's done is you install libfoo.so.X.Y.Z, and ldconfig makes a bunch of symlinks for you
[06:14:31] <seb_kuzminsky> libfoo.so.X.Y -> libfoo.X.Y.Z
[06:14:37] <seb_kuzminsky> libfoo.X -> libfoo.X.Y
[06:14:46] <seb_kuzminsky> libfoo -> libfoo.X
[06:14:55] <seb_kuzminsky> (oops, plus the ".so" bits i forgot)
[06:15:21] <seb_kuzminsky> we skip the .Y.Z in our libs, which is fine
[06:17:20] <seb_kuzminsky> executables (and other libraries) generally link against libfoo.so.X, because the ".X" is the library interface version, and you're supposed to change it if you break binary compatibility
[06:17:54] <seb_kuzminsky> we distribute all our libs in the same deb as all our executables, so it's not super duper important for us to be super careful with this
[06:24:15] <seb_kuzminsky> so, uh, yeah i'm gonna get rid of those .so files
[06:31:41] <CIA-2> EMC: 03seb 07v2.4_branch * r3162ca884d3d 10/src/Makefile: Don't install lib*.so files, they're not needed
[08:12:49] <CIA-2> EMC: 03seb 07v2.4_branch * re289537f81b8 10/src/ (8 files in 8 dirs): stop pretending that unversioned .so's are useful
[08:24:34] <seb_kuzminsky> oops that broke rip comp :-(
[08:28:25] <seb_kuzminsky> crap, the deb too
[08:28:26] <seb_kuzminsky> comp
[08:29:03] <seb_kuzminsky> comp does unversioned linking (eg -lemchal), which makes perfect sense now that i think about it
[08:29:21] <seb_kuzminsky> why doesnt ldconfig make the right symlinks?
[08:30:44] <seb_kuzminsky> hmm, i think emc2-dev is supposed to supply eg libemchal.so -> libemchal.so.0
[08:31:30] <alex_joni> well.. emc2-dev is optional
[08:31:36] <seb_kuzminsky> executables are linked to a particular version of the library, but when compiling, by default, we link against whatever happens to be available
[08:32:24] <alex_joni> except that with version changes the new components might not be able to communicate with the older ones
[08:32:49] <seb_kuzminsky> i dont understand what you mean
[08:33:32] <seb_kuzminsky> compiled executables are linked to a particular abi-version of the library (in our case "0")
[08:34:10] <seb_kuzminsky> when you compile & link something and say "-lemchal" on the linker command-line, it finds libemchal.so, follows the symlink to libemchal.so.0, and links against that
[08:34:26] <seb_kuzminsky> so the executable knows what abi version of the library it needs
[08:34:46] <seb_kuzminsky> if you upgrade to libemchal.so.1, you should *not* run the old executables with the new library
[08:35:04] <seb_kuzminsky> that's how i think it works
[08:35:40] <alex_joni> * alex_joni knows little about shared libs
[08:35:51] <alex_joni> bbl.. ;)
[08:35:55] <seb_kuzminsky> before i started messing with it, emc2.deb had two real files for each library: libfoo.so and libfoo.so.0, both with identical contents
[08:36:16] <seb_kuzminsky> the libfoo.so should not be a real file and does not belong in the "executables" deb
[08:36:39] <seb_kuzminsky> it belongs in the emc2-dev.deb, and should be a symlink to the real lib in emc2.deb
[08:36:43] <seb_kuzminsky> * seb_kuzminsky hacks some more
[08:42:26] <seb_kuzminsky> thank goodnes gracious for our test suite, saves boneheaded me from looking even more stupid
[08:50:56] <CIA-2> EMC: 03seb 07v2.4_branch * rabcb2c18b7cc 10/src/ (8 files in 8 dirs): undo the previous broken commit
[09:28:38] <CIA-2> EMC: 03seb 07v2.4_branch * r78dabc105291 10/src/Makefile: make the unversioned .so symlinks a bit simpler
[09:28:42] <CIA-2> EMC: 03seb 07v2.4_branch * rdd8c21350ac9 10/ (debian/emc2-dev.files debian/emc2.files.in src/Makefile): Put the unversioned .so symlinks in emc2-dev.deb
[09:29:11] <seb_kuzminsky> ok this is pretty good now i think
[09:30:48] <seb_kuzminsky> * seb_kuzminsky stumbles off to bed
[14:32:38] <seb_kuzminsky> morning guys
[14:32:46] <seb_kuzminsky> * seb_kuzminsky stumbles blearily to the coffee maker
[14:35:08] <jepler> hi seb_kuzminsky
[14:35:41] <jepler> I wonder whether all these packaging changes should go in 2.4, as opposed to master.
[14:37:30] <seb_kuzminsky> oops maybe i should have consulted with you first... i think of them as basically bugfix tweaks
[14:38:06] <seb_kuzminsky> and so i think they belong in 2.4, but if you disagree i'll take them out of 2.4 and put them in master instead
[14:38:17] <jepler> let's leave this unless we identify a problem with the changes
[14:38:26] <jepler> but talk about the next lintian-inspired changes you're inclined to make before they go in
[14:38:57] <cradek> is there a lot of stuff left that it doesn't like?
[14:39:11] <jepler> I haven't looked..
[14:39:17] <seb_kuzminsky> http://emc2-buildbot.colorado.edu/buildbot/builders/deb-hardy-sim-binary-i386/builds/110/steps/shell_5/logs/warnings
[14:39:44] <seb_kuzminsky> we're supposed to not put byte-compiled python code in the deb, that's a big one
[14:39:57] <seb_kuzminsky> (it gets byte-compiled on the target machine when you install the deb)
[14:40:15] <jepler> so I read on the internet
[14:40:33] <seb_kuzminsky> something about rpath defined inside our object files, not sure what that means yet
[14:41:12] <cradek> yeah surely packaging pyc is a bug
[14:41:15] <seb_kuzminsky> and we install a single object file (emc.so) in /usr/share, when it belongs in /usr/lib
[14:41:41] <seb_kuzminsky> the other complaints aren't such a big deal, but those are things i'd like to fix if i can
[14:42:08] <seb_kuzminsky> and if you guys agree
[14:42:12] <cradek> I think these might not be bugs: emc2-sim: library-not-linked-against-libc ./usr/lib/emc2/modules/abs.so
[14:42:43] <jepler> well I know abs.so happens to work just fine
[14:43:15] <cradek> I agree rpath /usr/lib is unnecessary (but harmless)
[14:43:47] <jepler> I strongly suspect rpath is useful for RIP installations
[14:43:51] <cradek> ah I see W and E now - saying the W are harmless is silly, I'll stop that
[14:43:54] <jepler> maybe I'm mistaken
[14:44:16] <cradek> yes rpath is maybe even needed for that (although if people are using emc-environment, maybe not)
[14:44:52] <jepler> it's true that the LD_LIBRARY_PATH setting in emc-environment probably makes that work fine
[14:45:30] <seb_kuzminsky> we also have a bunch of linker sloppiness that i'd like to fix:
http://emc2-buildbot.colorado.edu/buildbot/builders/deb-hardy-rt-binary-i386/builds/107/steps/shell_4/logs/warnings
[14:45:56] <cradek> wow!
[14:46:20] <seb_kuzminsky> so: nothing major, just a bunch of little annoying quirklets
[14:46:22] <jepler> that's all fine to fix in master
[14:46:38] <seb_kuzminsky> but not in 2.4?
[14:46:56] <cradek> thanks for caring about this stuff
[14:47:09] <seb_kuzminsky> it's janitor-class work...
[14:47:25] <jepler> I'm reluctant to change it in v2.4_branch if there's no benefit identified beyond "it makes dpkg stop complaining"
[14:47:48] <jepler> for instance, if you looked at the dpkg-shlibdeps warnings and figured out we could drop an entire dependency by fixing it, I'd feel different
[14:47:52] <cradek> a stronger benefit MIGHT be that we could remove a dependency
[14:47:57] <cradek> yep that
[14:48:16] <seb_kuzminsky> a slight load-time improvement, maybe
[14:48:16] <cradek> at a glance, I kind of doubt you'll lose any dependency even if you fix all of these
[14:48:34] <seb_kuzminsky> but yeah, i agree this wont make anything better for users in any real way
[14:49:03] <jepler> of course, it's well established at this point that I don't actually want to see the software improved..
[14:50:06] <cradek> meh
[14:53:34] <seb_kuzminsky> we all want to see it improved, and you're probably right to be conservative with the release branch at this point
[14:57:11] <cradek> I've always been unsure whether our packaging was any good and it's neat that you're finding/using tools that tell you how to fix it all up
[14:57:46] <cradek> but I agree about the release branch - we should be making the minimum necessary changes there so as to not needlessly invalidate testing we've done
[14:58:00] <seb_kuzminsky> well the packaging certainly *works*, which is some awesome pudding right there
[14:58:18] <seb_kuzminsky> ok, i'll hold off on any more frivolous packaging commits to 2.4
[14:58:36] <CIA-2> EMC: 03jepler 07v2.4_branch * r3ebf987130f2 10/src/hal/components/steptest.comp: ensure maxvel is reached during jogging by setting target further from current
[14:58:53] <seb_kuzminsky> (and sorry if i stepped on any toes or messed up any release procedures, that was not my intent...)
[14:59:57] <cradek> you're fine, don't worry like that.
[15:02:00] <jepler> everything's fine, nothing is ruined
[15:08:12] <seb_kuzminsky> ok cool
[15:08:13] <seb_kuzminsky> gotta go, ttyl
[17:57:22] <jepler> here's a script that will run axis under the Python 'cProfile' profiler:
http://emergent.unpy.net/files/sandbox/profile_axis
[17:57:35] <jepler> cProfile seems to be available at least since hardy
[17:57:49] <jepler> switch the path to axis to match your system, put the script on your path mode +x, and set DISPLAY = profile_axis
[17:59:03] <jepler> an example profile, of aystarik's program:
http://pastebin.ca/1834091
[18:00:05] <SWPadnos> what does the 600/425 number mean in ncalls?
[18:00:16] <jepler> I'm not sure
[18:00:57] <jepler> When there are two numbers in the first column (for example, 43/3), then the latter is the number of primitive calls, and the former is the actual number of calls. Note that when the function does not recurse, these two values are the same, and only the single figure is printed.
[18:01:03] <jepler> We define primitive to mean that the call was not induced via recursion
[18:01:15] <SWPadnos> ok
[18:03:37] <SWPadnos> how big is that program?
[18:04:19] <jepler> 40k lines of which something like 9k are arcs
[18:04:37] <SWPadnos> huh. is interpret called for each word?
[18:04:54] <SWPadnos> 5 million seems like a lot of calls for a 40kline program
[18:07:22] <jepler> each segment of each arc does something like 8 calls to interp(), which is a function local to arc_feed which performs linear interpolation between start and end values
[18:07:55] <SWPadnos> ah, ok. I was interpreting (no pun intended) that as "interpreter" rather than "interpolator"
[18:15:54] <cradek> collect data -> smoking gun
[18:16:25] <cradek> nice
[18:17:46] <jepler> ncalls tottime percall cumtime percall filename:lineno(function)
[18:17:53] <jepler> 8650 0.059 0.000 13.411 0.002 /home/jepler/emc2-dev/lib/python/rs274/glcanon.py:128(arc_feed)
[18:18:45] <jepler> too bad the code gets much uglier
[18:22:15] <cradek> can you do it in the c++ ARC_FEED instead?
[18:30:16] <jepler> fwiw:
http://emergent.unpy.net/files/sandbox/arc-speedups.mbox
[18:31:56] <aystarik> http://slabode.exofire.net/index.shtml
[18:33:24] <jepler> aystarik: I apologize for being uncivil yesterday.
[18:33:44] <aystarik> jepler: me too. peace?
[18:33:49] <jepler> aystarik: please.
[18:37:40] <jepler> lunchtime here, bbl
[18:56:40] <alex_joni> heh
[20:05:34] <robh_> robh_ is now known as Guest13218
[20:07:33] <Guest13218> Guest13218 is now known as robh__
[21:05:29] <CIA-2> EMC: 03seb 07v2.4_branch * r5471aa23dbc6 10/tests/hm2-idrom/broken-load-test.hal: be more verbose when testing
[21:05:30] <CIA-2> EMC: 03seb 07v2.4_branch * rf7d1c9a14ecd 10/src/hal/drivers/mesa-hostmot2/pins.c: fix an off-by-one error when counting IOPort instances
[21:05:31] <CIA-2> EMC: 03seb 07v2.4_branch * r70fca8469127 10/ (3 files in 2 dirs): add a test with IO Pins but no IOPort module instances
[21:05:39] <CIA-2> EMC: 03seb 07v2.4_branch * r5005549d698e 10/src/hal/drivers/mesa-hostmot2/hm2_test.c: Fix up some comments
[21:37:16] <cradek> jepler: I'm too tired to fix those arcs
[21:44:18] <jepler> I can't say I blame you..
[21:52:13] <jepler> hm .. the change that precomputes sin(theta) and cos(theta) makes the difference between rotated and non-rotated go down into the noise
[21:55:07] <jepler> rotated, best of ten trials 8.967; average 10.04; stdev 0.404. unrotated, best of ten trials 9.15; average 9.96; stdev 0.368.
[21:55:19] <jepler> using the time axis-remote --reload method
[22:43:07] <aystarik> ok, moved Arcs to C...
[22:50:44] <robh_> robh_ is now known as Guest59299
[22:51:04] <Guest59299> Guest59299 is now known as robh__
[23:04:02] <aystarik> question, why we apply rotation only to arcs in G17?
[23:08:24] <cradek> aystarik: it's a bug
[23:08:39] <cradek> aystarik: if you'd fix it I'd be really thrilled :-)
[23:09:14] <cradek> the motion is right - preview is wrong - jeff noticed it today too.
[23:09:32] <cradek> I sent some comments about your patch.
[23:09:52] <aystarik> great! thanks!
[23:17:36] <cradek> thank you - this will be a good change if we get it in shape
[23:19:09] <cradek> aside from a bug I spotted, most of my comments are about making the simplest possible commits, and separating unrelated changes into separate commits - I had trouble understanding about half of your patch because it seemed unrelated to the description of the commit.
[23:19:54] <cradek> I think you fixed several separate things, which is great - but it's better if those are separated with appropriate commit messages.
[23:22:13] <aystarik> it's easier to break one big patch into several after it's done, maintaining stack while doing coding is less productive. IMHO.
[23:23:10] <cradek> that may be, but that separation should be done before asking others to review, IMHO.
[23:24:36] <cradek> strange - does something in my email cause yours to do this "Chris Radek ??????????:" thing?
[23:29:14] <aystarik> no, this is my thunderbird -- in russian locale it insists to do "Person *wrote*" in russian. I did not find how to fix that rather than change it's locale to english...
[23:29:27] <cradek> ah, ok
[23:29:38] <cradek> maybe it's mine that changes it to ???
[23:30:12] <cradek> no big deal, I just wondered if I was sending out bogus emails somehow
[23:41:49] <alex_joni> good night all