* jmkasunich is back
jmkasunich: I'm back too
did you read back?
yes.. I glanced, anyway
I'm working on making USE_STUBS and MATHLIB be obeyed
do you think that's the right thing to do?
(while still using rtapi_math.h and no rtapi_math_i386.h)
to be honest I don't know
take a look at configure.in, line 752
for an explanation of what it used to do
there is even more stuff in configure that tries to identify the rtos, and use <rtos>-config to find out the right things to do
a lot of effort went into that, I don't know how much of it is still in use and how much is ignored
cradek took a look eariler, and said:
cradek I'm struggling to not be overcome by the complexity and messyness of this
cradek it makes me really want to say let's drop support for anything but rtai
that bugs me, because the whole reason for rtapi in the first place was to allow support for different rtos's
alex, paul, and I all put a lot of effort into that config stuff, it seems a shame to just dump it
it's just an oversight that these math-related things weren't put in the new Makefiles
jmkasunich: is what I pasted on the other channel (fputs defined in siggen.o) what you'd expect to see if math stubs are being used?
the user space math lib wants to be able to print "divide by zero, program halted" to stderr
mathstubs has a fputs that just returns
likewise it defines things like errno and such
it is a total hack
you shouldn't be seeing that on your ubuntu box tho?
no, this is on my bdi2 chroot
I think (one of the) libm hack(s) is about fixed
the error from the farm notwithstanding
I assume thats because it started compiling after your first commit and missed the second
its building again as we speak
the next one may work *crosses fingers*
oh, wait, I broke bdi-tng too
bdi-tng uses the same hack as bdi2
even tho its rtai, there is no rtai_math
siggen loads, thats where it failed before with undefined symbols
(this is on bdi2)
found a different problem, but one thing at a time
[John@cubix2 emc2head]$ bin/halcmd loadrt motmod
/home/John/farm/emc2head/rtlib/motmod.o: unresolved symbol vsnprintf
HAL:0: ERROR: insmod failed, returned 1
at one time I had my own inplementation of vsnprintf for exactly this case
I think it might have been removed by someone who thought the kernel would always provide
not important, I'll finish testing with siggen, then move on to bdi-tng
it's still there, vsn_printf in vsnprintf.h
not if 0'ed out or anything?
#if LINUX_VERSION_CODE > KERNEL_VERSION(2,4,0)
/* Kernel is 2.4 or higher, use it's vsnprintf() implementation */
#define vsn_printf vsnprintf
/* 2.2 and older kernels don't have vsnprintf() so we bring in
our own implementation (vsn_printf) of it here.*/
ok, I'm mystified
maybe the second arm needs '#define vsnprintf vsn_printf' ?
I need to look at it in context to answer intelligently
right now you know more than me
on the bright side, BDI-2 siggen is making a nice sine wave
moving on to TNB
to derail the conversation, since so many pins and parameters are created with printf()-style formatting, how do you feel about adding new APIs that encapsulate this, e.g., hal_pin_TTT_newf(hal_dir_t, hal_XXX_t **, int, char *format, ...)
those massive repeated stanzas of copy/paste code make me nutz
even better would be a clean way to handle error returns
ideally each pin would only need a line of C, not 6 or 7
might be a candidate for a goto, although we'd lose the ability to print the name that failed
I'll be around tomorrow afternoon/eve.
I think I will
my wife has a bunch of yard work with my name on it, but we'll probably be working in the morning before it gets hot
in the afternoon I'll hide in the cool basmenet
even when I broke it, you tell me thanks when I unbreak it.
that's really kind of you.
the new build system is incredibly better than the old... I don't mind a few hiccups
Hi Dan. How you doing on this fine holiday weekend?
good. My dad is here this weekend
how was cncworkshop?
Fantastic. Having developers and machines together makes for a great time.
so, threading is working. toolchanging is working. very cool
Awesome. All the things we talked about long years ago.
I guess I'll have to get the lathe set up here for testing
It is not a real easy system to set up but the abilities are fantastic.
I will try to get emc2 set up here in the next couple weeks
I got a spare computer from a friend for free
Good. I'm anxious to hear your reactions.
At fest I mentioned that you were the only one of the early adopters not present.
I have the sherline lathe, encoders, steppers, drives, just need the time.
I wish I could have been there.
That is a scarce thing when you have a growing family.
I have been learning python lately and have written a polar coordinate/bolt circle calculator with a tk gui
and will be trying to copy you and cp1
it's fun stuff
I realized that the editor is the key. Will start learning what it takes to program one
I see the note from you regarding python is still on the basement wall.
then add all the little routines
What was that 8 years ago.
cradek and jepler are python experts. I'll try and learn from their code
it's good chatting with you Ray.
and you, Dan.
Tell the family hello for me.
come out to Oregon some time
You bet we will.
EvertL is now known as Evertlammerts
alex_jon1 is now known as alex_joni
jmkasunich: I haven't looked back. how badly broken did my changes this morning leave the other platforms?
minor problem (a typo really) on BDI-2, I fixed it already
haven't actually tested since last night, but I have every reason to believe they still work fine
(the typo caused a compile failure)
I only converted one driver to use the new APIs, because I only wanted to convert what I could test
ok, we can do more later
I'd really like to look at error handling
the new API eliminates one or two lines, I want to get rid of more