jmkasunich: just got home
I'm in a low energy state....
I was thinking about doing more on the stepgen thing, but not tonight
is that what you're going to ask about?
how'd you guess ;-)
what version of g++ and gcc did configure find?
gcc-3.4 for CC
(according to Makefile.inc)
and for CXX?
what's g++ --version show?
should I try installing g++ 3.4 to make it match gcc?
OK -- so here's the problem
I invoke $(CC) to find out if -funit-at-a-time is supported, then assume that $(CXX) supports it too
but because your $(CXX) is older, that doesn't work
I happen to know that the distributor of your OS has a patch for this problem, but he hasn't contributed it.
he's just whined about it
since we don't want people to have to fuck with their OS install too much, I'd say that configure had better sort this out
is there g++-3.4 installed?
doesn't seem to be
even if you apt-get it, configure will still default to /usr/bin/gcc
I see two main solutions. one assumes we'll require the user to install g++-3.4, one doesn't.
first, I can change Makefile to check separately for support of each flag with $(CC) and with $(CXX)
second, I can change configure to try to append the same version string to $(CXX) as $(CC)
question - what does funit-at-a-time buy us?
it allows the compiler to consider the whole input before generating any code
it may lead to improved inlining or optimization -- for instance, because the compiler can prove all the places a file-level static is modified
thats what I got from man gcc
it's probably not a big difference
I also seem to recall (this is from the fuzzy reached of my mind, and may be outdated even if I'm remembering it correctly) that too much optimization has been known to lead to problems with RT code
if you want to remove -funit-at-a-time at all, that's acceptable to me too
I don't have any benchmark that shows it's an important optimization to enable
we don't have many benchmarks at all
any particular reason you are turning specific optimizations on and off, instead of using -O2, etc?
I thought that -funit-at-a-time was not enabled at any optimization level by default, but I see now that I am mistaken
I explicitly do -fno-strict-aliasing because it *is* enabled by default (at -O2) but causes problems with cast-happy code-- not that I know it's caused a specific problem
I'm very tempted to remove the unit-at-a-time
now does -fno-strict-aliasing cause a fit too?
building now, so far so good
vm clocks don't keep very good time
gained 6 minutes in two days
Is this some kind of slow turn-on circuit, or what? http://emergent.unpy.net/files/sandbox/whatsit.png
the capacitors are both small surface-mount type, must be small values
I dunno - there isn't a lot of context there
no resistors in the circuit anywhere seems strange
what connects to that circuit?
I'm not sure -- it's part of the pluto-p fpga board, but I haven't figured out where they go (the ?s go right to vias)
I don't think there are any resistors involved, there aren't many discretes and I think I've accounted for them all but this thing
just one instance of this circuit?
The transistor is a small surface-mount type and it's possible I've misidentified it
is the transistor a tiny sot-23 or such? or something that might be switching power?
jmkasunich: do you think you can decide on a fix for stepgen in the next few days? I'd like to make 2.0.5 this weekend
cradek: change the initial value and call it done
I don't want to do anything more radical than that, especially for 2.0
that's entirely safe, but might not fix it 100%?
IMO, its not busted
should we do nothing then?
I don't understand all of what you and swp were talking about, but I thought you said it violated constraints sometimes
changing the initial condition won't hurt anything, and will dramatically reduce the number of "strange" things people might see
but the single step in the wrong direction, or dir change with no step pulses, aren't technically wrong
they will not accumulate, and they will not result in an output that is more than one step away from the target
jepler: the build worked
although I got warnings I've never seen before from the RT code
aha, there was a resistor I missed
Building modules, stage 2.
*** Warning: "rt_task_wait_period" [/home/jmkasunich/emc2head/src/rtapi.ko] undefined!
that is followed by lines griping about a whole load of other symbols
it looks like the right ? may be VCCio and the left ? is a signal that is affected by whether the device is successfully programmed
bdi has different versions of gcc and g++? does that even work?
I don't think BDI ships with differnet versions
I had to apt-get gcc
I was following http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?BDI-4_38_Compile_EMC2
so the repositories are screwy somehow then, same difference I think
I also had to get python2.4-dev, libreadline5-dev, and yapps2, to make configure happy
rtai-config tells configure what gcc was used to build RTAI (and I assume the kernel as well)
but nothing tells configure what g++ to use I don't think
none of the kernel stuff is built with g++
maybe it doesn't matter if they're the same - I guess I don't know
I've always just seen them be the same
but some of EMC is built with g++, and if its going to be exchanging data in structs in shmem with RT stuff built with gcc, maybe they should be the same?
I suppose I could try running the EMC2 that I just built
no clue how the RT will work in a VM tho
I thought it didn't link
it'll run slowly, I've done it several times
those were warnings, as far as I can tell the build succeeded
(although it may barf when I try to run it)
I think you'll see if they matter when you try insmod :)
I have discovered that 3 VMs that are all doing something bogs things down pretty good
both of the breezy VMs needed updates
this is weird
the bdi box is gaining several seconds per minute
I think there's an appnote or faq on using ntp on VMs
which leads me to believe that time issues are a known problem
maybe they think it's important to emulate the bad timekeeping of pc hardware
no PC hardware is that bad
no- that's a software problem ;)
though a 100ppm crystal reference would be off by ~1 hour / year, so it's partly hardware
14 seconds in 2 minutes is a lot worse than 100ppm
was the time correct at "bootup"?
that was several days ago
I ran ntpdate, observed the two machines in sync, wait two mins, and they're out again
run ntpdate again, and it had to adjust by 14 seconds
I wonder if some boot-time constant for TSC timing or something like that was wrong because of the hardware being emulated
18 seconds in the last 4 mins
I'm reading a PDF about timekeeping in VMs
ok - you've probably surpassed my meager knowledge of the subject then :)
be enlightened: http://www.vmware.com/pdf/vmware_timekeeping.pdf
thank you, O wise one
my host has lots of these in dmesg:
[1217016.817603] rtc: lost some interrupts at 2048Hz.
lots being relative - they seem to come in bursts of 5-10 within a few seconds, followed by thousands or tens of thousands of seconds without any
heh - I wonder what would happen if someone tried to run Mach in a Windows VM? ;)
hmmm - there's apparently experimental support for Edgy host/guest installs in the latest version
SWPLinux: how about wine? hahahaha
whaaaaaaa whaaaaaaa whaaaaaaaa!
wine works. just not as well as I would like.
it runs UT99... but no gamma correction. :(
anyways... lates. off to bed.
I've never gotten wine to run anything, though I've always tried to do it with package managers instead of compiling on my own
good night A-L-P-H-A
the only thing I've run in wine on dapper (the packaged one) was windows firefox, and it worked perfectly
SWPLinux: works for uTorrent, mirc, unreal tournament 99... that's all I've ran.
plugins, sound, everything
cradek: I should do that, so I can watch my online porn.
I mean youtube.
did you use a package, or compile?
apt-get install wine
SWPLinux: the package from WINEhq works... add wine's repo, to the repo list.
it could not have been easier
cradek: the wine from the original repos are out of date.
I think I never managed to get the package lists or something
* cradek shrugs
E: Package wine has no installation candidate
0.9.23 is the wine on edgy. 0.9.26 is out... fixes a lot of things
hmmm. I have universe enabled
I even have multiverse enabled
[04:54:32] <A-L-P-H-A> http://winehq.com/site/download-deb
thanks. I was about to re-enable that repository ;)
SWPadnos: what am I here for? Your money? Well, that, and to be sometimes helpful.
I had tried this long ago, but never managed to get past the "E: sorry bud" mesage
good night again. thanks
hmmm - AMD64 could be my problem
and SMP may not help either
would not surprise me at all to hear that wine is borken on 64
so you run it on neither AMD64 nor SMP?
right, I have neither of those things
[05:00:23] <cradek> https://launchpad.net/distros/ubuntu/+ticket/946
argh. I can't even build-dep wine
hmmm - thanks
so - on to more emc-related things
which is the correct set of ADEOS patches to use for RTAI now?
the ones that come in the rtai distribution
ok. I'm not sure all the files are there for A64 yet
there's a rtai manual now, if I was starting with a newer rtai today I'd read it
heh - is that a suggestion? ;)
yay LTS, I don't have to worry about this for a while
only half a suggestion, the other half is me saying I haven't kept up with rtai
alex built the dapper magma kernel
I'd hate to be the expert on that - it remids me of a line from the movie "All Of Me"
"If I can be of any help, you're in worse trouble than I thought"
(said the blind guy)
so about stepgen
jmk said we could/should change the initial value to make the problem less likely
including in 2.0
do you agree?
well, I'm not sure there is a non-intrusive fix
and I'm not sure that the issue identified in stepgen is really a problem (or the one Ed Nisley reported)
so I'd be leery of making radical changes to fix a problem that nobody else has ever had in the stable branch
I agree it's probably not Ed's problem
ie, yes, I think that's an OK thing to make it look better, but it doesn't really fix anything
so it's just a cosmetic thing
I think so. it prevents the first move from creating a glitch, but it doesn't change the mechanism by which glitches are made
so they're theoretically still possible
well it changes the number of glitches from 1+pn to pn where n is the number of moves or something like that
no, it causes the initial conditions to not be prone to a glitch
but those conditions may exist later
let's do nothing in 2.0
and a glitch will still happen in those cases
I'm happy about that
that sounds fine to me as well, unless we can verify that there's a real problem
I can live with that too
alex, the guy who for some reason couldn't install ubuntu... installed bdi
I still think he had a bad burn - I don't know why he ignored my advice to try again or run the media check on it
of course - Paul came to the rescue
it's too hard, dontcha know
well now he can ask his copious questions on paul's list :-)
but not about EMC2 ...
paul will FUD him out of using emc2, don't worry
* cradek shrugs
I wonder if I should stop hosting the BDI ISOs
depends if it's worth to you what you get in return :-)
I haven't bothered to pull his access, and I suppose that if there are situations where BDI works for someone, then they may as well have access to it
(not that it's my responsibility to provide that access)
the main bdi site is on 'ourproject' now I think
you may not get much traffic (who knows, they may not either)
I think it's significant, but not overwhelming
The idea behind the ourproject.org initiative is for it to be a tool which encourages the cooperative work effort of all types of people from every part of the world, promoting the coming together of people and the exchange of ideas and solutions to problems, with the condition that the results of the projects will remain freely accessible to whoever may find them useful, within this tool.
I can see it because the sitename is different from the EMC2 ISO
The condition for hosting projects at ourproject.org (in addition to the requirement that the projects and their contents do not violate Human rights, worker's rights, or environmental protection laws) is that the content created during the project must be released under one of these licenses: ... GNU General Public License (GPL)
sounds nice and cooperative, for the most part
wonder how they handle reports of GPL violations in their projects.
hmmm. it seems strange that the last change date for the x86_64 patches is 16 months old
maybe I should be looking at a different RTAI code name (not magma)
yeah that doesn't sound promising
but some stuff in that tree is 4 days old, which does sound promising
wow it got late again - goodnight
yep. I should get to bed also.
SWPLinux_ is now known as SWPLinux
SWPadnos_ is now known as SWPadnos
hey there Alex
I had a problem restarting the loggers a few days ago - the logger script wouldn't do it
I ended up having to run them from the command line (cut/paste, luckily ;) )
I thought so
did the processes spawn?
I wasn't logged in as emcboard though
hmm.. might be a reason
well, there was an error (or warning) about a possible misspelling of a name
line 55, $::Host, I think
that's a warning
showing my limited perl hacking abilities :D
the loggers never connected when I ran them in the script, but they did when run from command line
I wonder if it would work if you source or '.' the file instead
Guest649 is now known as skunkworks_
skunkworks_ is now known as skunkworks
SWPadnos_ is now known as SWPadnos