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:
wrong channel :)
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
I think normally you install .so.N and ldconfig makes symlinks
ok, that information is probably 15 years old...
ldconfig ignores symlinks now
so I replace my answer with 'dunno, sorry'
er yes I guess it still works that way
seems likely that .so without version number doesn't belong in the packages
lintian agrees that *.so does not belong in the package
the usual way it's done is you install libfoo.so.X.Y.Z, and ldconfig makes a bunch of symlinks for you
libfoo.so.X.Y -> libfoo.X.Y.Z
libfoo.X -> libfoo.X.Y
libfoo -> libfoo.X
(oops, plus the ".so" bits i forgot)
we skip the .Y.Z in our libs, which is fine
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
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
so, uh, yeah i'm gonna get rid of those .so files
EMC: 03seb 07v2.4_branch * r3162ca884d3d 10/src/Makefile: Don't install lib*.so files, they're not needed
EMC: 03seb 07v2.4_branch * re289537f81b8 10/src/ (8 files in 8 dirs): stop pretending that unversioned .so's are useful
oops that broke rip comp :-(
crap, the deb too
comp does unversioned linking (eg -lemchal), which makes perfect sense now that i think about it
why doesnt ldconfig make the right symlinks?
hmm, i think emc2-dev is supposed to supply eg libemchal.so -> libemchal.so.0
well.. emc2-dev is optional
executables are linked to a particular version of the library, but when compiling, by default, we link against whatever happens to be available
except that with version changes the new components might not be able to communicate with the older ones
i dont understand what you mean
compiled executables are linked to a particular abi-version of the library (in our case "0")
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
so the executable knows what abi version of the library it needs
if you upgrade to libemchal.so.1, you should *not* run the old executables with the new library
that's how i think it works
* alex_joni knows little about shared libs
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
the libfoo.so should not be a real file and does not belong in the "executables" deb
it belongs in the emc2-dev.deb, and should be a symlink to the real lib in emc2.deb
* seb_kuzminsky hacks some more
thank goodnes gracious for our test suite, saves boneheaded me from looking even more stupid
EMC: 03seb 07v2.4_branch * rabcb2c18b7cc 10/src/ (8 files in 8 dirs): undo the previous broken commit
EMC: 03seb 07v2.4_branch * r78dabc105291 10/src/Makefile: make the unversioned .so symlinks a bit simpler
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
ok this is pretty good now i think
* seb_kuzminsky stumbles off to bed
* seb_kuzminsky stumbles blearily to the coffee maker
I wonder whether all these packaging changes should go in 2.4, as opposed to master.
oops maybe i should have consulted with you first... i think of them as basically bugfix tweaks
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
let's leave this unless we identify a problem with the changes
but talk about the next lintian-inspired changes you're inclined to make before they go in
is there a lot of stuff left that it doesn't like?
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
we're supposed to not put byte-compiled python code in the deb, that's a big one
(it gets byte-compiled on the target machine when you install the deb)
so I read on the internet
something about rpath defined inside our object files, not sure what that means yet
yeah surely packaging pyc is a bug
and we install a single object file (emc.so) in /usr/share, when it belongs in /usr/lib
the other complaints aren't such a big deal, but those are things i'd like to fix if i can
and if you guys agree
I think these might not be bugs: emc2-sim: library-not-linked-against-libc ./usr/lib/emc2/modules/abs.so
well I know abs.so happens to work just fine
I agree rpath /usr/lib is unnecessary (but harmless)
I strongly suspect rpath is useful for RIP installations
ah I see W and E now - saying the W are harmless is silly, I'll stop that
maybe I'm mistaken
yes rpath is maybe even needed for that (although if people are using emc-environment, maybe not)
it's true that the LD_LIBRARY_PATH setting in emc-environment probably makes that work fine
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
so: nothing major, just a bunch of little annoying quirklets
that's all fine to fix in master
but not in 2.4?
thanks for caring about this stuff
it's janitor-class work...
I'm reluctant to change it in v2.4_branch if there's no benefit identified beyond "it makes dpkg stop complaining"
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
a stronger benefit MIGHT be that we could remove a dependency
a slight load-time improvement, maybe
at a glance, I kind of doubt you'll lose any dependency even if you fix all of these
but yeah, i agree this wont make anything better for users in any real way
of course, it's well established at this point that I don't actually want to see the software improved..
we all want to see it improved, and you're probably right to be conservative with the release branch at this point
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
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
well the packaging certainly *works*, which is some awesome pudding right there
ok, i'll hold off on any more frivolous packaging commits to 2.4
EMC: 03jepler 07v2.4_branch * r3ebf987130f2 10/src/hal/components/steptest.comp: ensure maxvel is reached during jogging by setting target further from current
(and sorry if i stepped on any toes or messed up any release procedures, that was not my intent...)
you're fine, don't worry like that.
everything's fine, nothing is ruined
gotta go, ttyl
here's a script that will run axis under the Python 'cProfile' profiler: http://emergent.unpy.net/files/sandbox/profile_axis
cProfile seems to be available at least since hardy
switch the path to axis to match your system, put the script on your path mode +x, and set DISPLAY = profile_axis
an example profile, of aystarik's program: http://pastebin.ca/1834091
what does the 600/425 number mean in ncalls?
I'm not sure
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.
We define primitive to mean that the call was not induced via recursion
how big is that program?
40k lines of which something like 9k are arcs
huh. is interpret called for each word?
5 million seems like a lot of calls for a 40kline program
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
ah, ok. I was interpreting (no pun intended) that as "interpreter" rather than "interpolator"
collect data -> smoking gun
ncalls tottime percall cumtime percall filename:lineno(function)
8650 0.059 0.000 13.411 0.002 /home/jepler/emc2-dev/lib/python/rs274/glcanon.py:128(arc_feed)
too bad the code gets much uglier
can you do it in the c++ ARC_FEED instead?
[18:31:56] <aystarik> http://slabode.exofire.net/index.shtml
aystarik: I apologize for being uncivil yesterday.
jepler: me too. peace?
lunchtime here, bbl
robh_ is now known as Guest13218
Guest13218 is now known as robh__
EMC: 03seb 07v2.4_branch * r5471aa23dbc6 10/tests/hm2-idrom/broken-load-test.hal: be more verbose when testing
EMC: 03seb 07v2.4_branch * rf7d1c9a14ecd 10/src/hal/drivers/mesa-hostmot2/pins.c: fix an off-by-one error when counting IOPort instances
EMC: 03seb 07v2.4_branch * r70fca8469127 10/ (3 files in 2 dirs): add a test with IO Pins but no IOPort module instances
EMC: 03seb 07v2.4_branch * r5005549d698e 10/src/hal/drivers/mesa-hostmot2/hm2_test.c: Fix up some comments
jepler: I'm too tired to fix those arcs
I can't say I blame you..
hm .. the change that precomputes sin(theta) and cos(theta) makes the difference between rotated and non-rotated go down into the noise
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.
using the time axis-remote --reload method
ok, moved Arcs to C...
robh_ is now known as Guest59299
Guest59299 is now known as robh__
question, why we apply rotation only to arcs in G17?
aystarik: it's a bug
aystarik: if you'd fix it I'd be really thrilled :-)
the motion is right - preview is wrong - jeff noticed it today too.
I sent some comments about your patch.
thank you - this will be a good change if we get it in shape
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.
I think you fixed several separate things, which is great - but it's better if those are separated with appropriate commit messages.
it's easier to break one big patch into several after it's done, maintaining stack while doing coding is less productive. IMHO.
that may be, but that separation should be done before asking others to review, IMHO.
strange - does something in my email cause yours to do this "Chris Radek ??????????:" thing?
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...
maybe it's mine that changes it to ???
no big deal, I just wondered if I was sending out bogus emails somehow
good night all