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