#emc | Logs for 2006-01-18

[00:08:43] <jepler> can anyone confirm that paul_c's instruction to get the emc source is right? I'm twiddling my thumbs waiting for 4.38 to boot in qemu.
[00:16:22] <SWPadnos> where are those instructions?
[00:16:48] <Jymmm> |<--- between here and there --->|
[00:16:57] <SWPadnos> oh - those instructions ;)
[00:17:27] <jepler> apt-get source emc
[00:17:28] <jepler> Will get you the most recent tarball. Check with viewcvs at SF for the last
[00:17:28] <jepler> tag - This will be most recent checkout from which the emc package was
[00:17:28] <jepler> compiled from.
[00:17:43] <jepler> that's what paul wrote; I guess he didn't copy the emc-users list on the reply, just the bdi4emc-help list
[00:17:59] <SWPadnos> ok. the changelog for BDI 4.38 doesn't say anything about emc updates. it's mostly security
[00:18:03] <SWPadnos> ok
[00:18:06] <SWPadnos> makes sense ;)
[00:18:14] <jepler> yeah, but I think it's wrong
[00:18:38] <SWPadnos> lots of wrong stuff going on lately, on both "sides", I think
[00:27:08] <SWPadnos> jepler, how did you get networking to work under qemu?
[00:27:17] <SWPadnos> that's the only issue I have with it so far
[00:30:33] <jepler> SWPadnos: I didn't do anything special, but outgoing networking is working well enough to run 'apt'
[00:30:56] <jepler> this is qemu 0.8.0 with kqemu
[00:31:09] <jepler> and I'm just running it as a user
[00:31:53] <SWPadnos> hmmm
[00:32:06] <SWPadnos> I can't seem to get the network to start up correctly
[00:32:22] <SWPadnos> maybe the qemu-ifup script isn't properly set sudo
[00:32:39] <SWPadnos> I don't have access to /dev/net/tun as a normal user
[00:41:06] <jepler> I don't seem to have any 'qemu-ifup'
[00:42:26] <SWPadnos_> /etc/qemu-ifup
[00:43:04] <SWPadnos_> hey there jmk
[00:43:36] <jmkasunich> hi
[00:43:37] <jepler> nope, no qemu-ifup under /etc
[00:43:39] <jepler> * jepler shrugs
[00:43:44] <jepler> it works for me!
[00:43:53] <jmkasunich> bet I missed alex...
[00:44:05] <SWPadnos_> odd - I'll see if BDI works, it didn't work with puppy
[00:44:32] <SWPadnos_> yep
[00:46:57] <SWPadnos_> BDI does seem to like it when I give qemu 1G of RAM to play with
[00:47:00] <jmkasunich> getting reliable, portable, high-resolution time measurements is a pain in the ass
[00:47:15] <jepler> bdi 4.38 seems to run OK, but slowly
[00:47:21] <jepler> maybe I should give it more RAM too
[00:47:23] <SWPadnos_> yes. I'd just use the RTLinux or RTAI functions, and leave it at that
[00:47:37] <SWPadnos_> if they're 55ms resolution, then so be it
[00:48:05] <jmkasunich> if I base overrun detection on that, some users will get false overrun errors
[00:48:31] <SWPadnos_> there should be a timer_resolution function, and you can disable reporting if it's too coarse
[00:48:47] <jmkasunich> if there is one, I haven't found it
[00:48:49] <SWPadnos_> heh
[00:50:14] <jmkasunich> right now I'm inclined to tag that particular issue "defer until 2.1"
[00:50:57] <SWPadnos_> that sounds good to me
[00:51:32] <jmkasunich> RTPAI needs good time measurement - that is fundamental to RT code
[00:51:46] <jmkasunich> there seems to be no quickie fix, so...
[00:53:08] <jmkasunich> its unfortunate, but the evolution of the PC seems to be moving away from RT capabilities
[00:53:32] <SWPadnos_> high throughput, high latency seems to be the mantra
[00:53:48] <jmkasunich> I really do think we've already passed the "golden years" for RT in the PC, and the era of dedicated hardware may be about to return
[00:54:08] <jmkasunich> granted, this time around the hardware can be an order of magnitude cheaper...
[00:54:20] <SWPadnos_> it seems that way. and it's easier to make dedicated hardware with FPGAs and the like (even analog stuff with PSOC's)
[00:54:35] <jmkasunich> Grex, M5i20, et al...
[00:58:32] <Jymmm> Was there a purpose for puppy or just proof of concept thing?
[00:58:58] <SWPadnos_> I think it's supposed to be a small, lightweight replacement for BDI
[00:58:59] <jmkasunich> probably a little of both
[00:59:11] <SWPadnos_> and a proof of concept
[00:59:18] <fenn> for one there was no ready-to-go emc2 distro
[00:59:52] <fenn> i really dont know how you can fill up a CD and not have room for dev tools..
[01:00:21] <SWPadnos_> KDE helps
[01:00:38] <SWPadnos_> many of the devtools are there, they just aren't installed by default
[01:00:58] <SWPadnos_> wow - that is a very slow installation under qemu
[01:01:07] <jepler> SWPadnos: yeah, I think it took hours
[01:01:18] <jepler> (1.5GHz host CPU here)
[01:01:23] <SWPadnos_> the file copy progress bar is only like 1/30th done now
[01:01:37] <SWPadnos_> 1.8GHz here - I don't think qemu uses SMP
[01:01:51] <jepler> I found that if I change to a different desktop, qemu just stops, but if I iconify it keeps running.
[01:01:56] <SWPadnos_> and a fast SATA drive as well
[01:02:02] <SWPadnos_> odd
[01:02:38] <SWPadnos_> it still seems to run here (according to top on a different desktop)
[01:03:40] <SWPadnos_> interesting - top doesn't seem to know about multiple CPUs
[01:07:53] <SWPadnos_> ok - it does know about multiples, but displays load percentages as % of one CPU
[01:08:14] <SWPadnos_> unless you turn IRIX mode off (capital I)
[01:09:34] <CIA-5> 03jmkasunich * 10emc2/TODO: Modified TODO: giving up on RT overrun detection for 2.0.0 release, too many operating system dependencies. Added a few other items.
[01:09:39] <Jymmm> What's IRIX mode?
[01:10:18] <SWPadnos> it makes CPU load show up as a percentage of a single CPU ;)
[01:27:31] <cncuser> back
[01:31:50] <jepler> hi cncuser
[01:35:11] <jepler> SWPadnos: my qemu says "VLAN 0 devices: user redirectory ne2000 pci macaddr=..." for "info network"
[01:35:35] <SWPadnos> h,,,
[01:35:36] <SWPadnos> hmmm
[01:36:00] <jepler> er, "redirector".
[01:36:18] <SWPadnos_> mine just says "0: ifname=tun0 macaddr= ...
[01:36:31] <SWPadnos_> (with aMAC address instead of ...)
[01:37:14] <SWPadnos_> the puppy install said there was no cable attached
[01:37:23] <jepler> qemu 0.8.0?
[01:38:29] <SWPadnos_> nope - 0.7.0
[01:38:37] <SWPadnos_> maybe that could be a problem ;)
[01:38:55] <SWPadnos_> Ubuntu seems to be a bit behind the times on several apps. bumer
[01:38:59] <SWPadnos_> bummer
[01:39:50] <jepler> try 'qemu -net user'? The ChangeLog in 0.8.0 seems to show that 'user' networking was back in 0.7 too
[01:40:04] <jepler> maybe the default's just different
[01:41:03] <SWPadnos_> I may try that after the BDI install finishes
[01:41:19] <jmkasunich> SWP: which bdi are you installing?
[01:41:42] <jepler> is rtai gpl too?
[01:42:10] <jmkasunich> jepler: I'm about 99.9% sure it is
[01:42:18] <SWPadnos> 4.38
[01:44:31] <cncuser> hi jeples, swpadnos, jmkasunich
[01:44:38] <cncuser> s/es/er/
[01:44:41] <SWPadnos> ih cncuser
[01:44:46] <SWPadnos> s/ih/hi/
[01:44:59] <cncuser> :)
[01:45:03] <cncuser> allmost a joke ;)
[01:45:08] <SWPadnos> yeah
[01:45:13] <SWPadnos> almost ;)
[01:45:24] <jepler> yes, https://gna.org/projects/rtai/ says it's gpl
[01:46:36] <jmkasunich> why did you ask?
[01:47:25] <jepler> jmkasunich: because licenses, and obeying them, is important
[01:47:52] <jmkasunich> true
[01:48:04] <jmkasunich> I thought maybe you were investigating something
[01:55:45] <cncuser> hmm, with grep i see lgpl and gpl
[01:56:34] <jmkasunich> LGPL is probably the interfaces, so that the RTOS can be used by proprietary projects
[01:59:15] <cncuser> looks clean :)
[02:06:11] <jepler> I've finally got this broken emc_1.0-29 package to get past the "configure" step
[02:06:42] <jmkasunich> I assume you are trying the build on the appropriate BDI?
[02:07:11] <jepler> "appropriate"? I don't even know which bdi emc_1.0-29 went with (maybe 4.29?). I'm trying to build on 4.38.
[02:07:26] <jmkasunich> heh
[02:07:39] <jmkasunich> what I meant was "the BDI that Paul claims it is for" ;-)
[02:07:49] <jepler> then yes
[02:14:24] <cncuser> hmmm
[02:14:37] <cncuser> SWPadnos: still awake ?
[02:14:44] <SWPadnos> yee
[02:14:46] <SWPadnos> yes
[02:14:49] <SWPadnos> maybe
[02:14:56] <cncuser> SWPadnos: and, hows the puppy devel going ?
[02:15:02] <cncuser> :)
[02:15:32] <SWPadnos> I've got a problem with qemu and networking, so it's not really going roght now
[02:15:36] <SWPadnos> right
[02:15:44] <cncuser> SWPadnos: no, for real, hope you havent done much, for i need to talk to barry kauler
[02:15:58] <SWPadnos_> nope - I haven't
[02:16:03] <cncuser> SWPadnos: if you get the latest qemu, the networking works like a charm
[02:16:05] <cncuser> out of the box
[02:16:19] <SWPadnos_> I really am having qemu network problems, so I'm waiting until those are fixed
[02:16:19] <cncuser> the one that comes as a debian packages with sarge doesnt ;)
[02:16:36] <SWPadnos_> I've noticed that on Ubuntu as well (which uses Debian packages)
[02:16:39] <cncuser> if had trouble with this tooo
[02:16:51] <cncuser> SWPadnos: get the qemusource, and off yu go
[02:16:56] <SWPadnos_> yep
[02:16:57] <cncuser> SWPadnos: its really easy
[02:17:02] <cncuser> i may have a script :)
[02:17:03] <SWPadnos_> have you tried kqemu?
[02:17:10] <cncuser> yes, it works great
[02:17:16] <SWPadnos_> ok- I may try that as well
[02:17:21] <SWPadnos_> should be a bit faster ;)
[02:17:23] <cncuser> the guistuff is allmost 5 times faster
[02:17:27] <cncuser> i think
[02:17:50] <cncuser> havent noticed much when compiling though
[02:18:14] <SWPadnos_> I only see kqemu 0.7.2 - should the version match qemu?
[02:18:21] <cncuser> no its ok
[02:19:00] <cncuser> get qemu, unpack cd into dir
[02:19:05] <cncuser> get kqemu unpack
[02:19:15] <cncuser> compile the usual way
[02:19:20] <cncuser> modprobe kqemu and youre in
[02:19:29] <SWPadnos_> shouldn't the two dirs be in the same parent, or does kqemu go under qemu?
[02:19:37] <cncuser> under qemu
[02:19:47] <cncuser> kqemu is a subdir that get built if it is there
[02:19:54] <SWPadnos_> right
[02:20:31] <SWPadnos_> I have a BDI install running under qemu right now - I may wait a until it finishes before installing the new version ;)
[02:20:49] <cncuser> and then all you need to do is launch it, as it for default has working netork conoigured, no iptables stuff, tun devices or something
[02:20:57] <cncuser> haha
[02:21:18] <cncuser> SWPadnos: i tried bdi in a qemu too, after a day i finished and decided never to use it again :)
[02:21:21] <SWPadnos_> the 0.70 version says it's using tun, but the emulated install thinks there's no cable plugged in
[02:21:36] <cncuser> SWPadnos: just dont use the old crap :)
[02:22:11] <SWPadnos_> in 15 minutes or so, I'll be able to upgrade
[02:22:23] <cncuser> SWPadnos: they wont interfere
[02:22:34] <cncuser> SWPadnos: as, qemu installs into /usr/local
[02:22:37] <cncuser> by tefault
[02:22:40] <cncuser> default
[02:22:45] <cncuser> so you can use both
[02:23:11] <cncuser> qemu -cdrom image..... for the original debian package, /usr/local/bin/qemu for the newer one
[02:25:26] <cncuser> has bdi still dma deaktivated with the installkernel ?
[02:25:36] <SWPadnos_> argh - no list of configure options
[02:29:15] <SWPadnos_> I wonder if it automatically picks up the fact that I have 64-bit CPUs
[02:29:33] <SWPadnos_> there are a lot of "cast to pointer from integer of different size" warnings
[02:34:12] <cncuser> dont know if its 64 prrof, but i think it must be, for it runs on sparcs too, i once did that
[02:34:13] <jmkasunich> SWP: what are you compiling?
[02:34:19] <SWPadnos> qemu
[02:34:37] <jmkasunich> ok
[02:34:54] <jmkasunich> * jmkasunich wonders how emc2/hal/rtapi will do in that department
[02:35:10] <SWPadnos> as long as it runs, it's OK for testing
[02:35:16] <SWPadnos> I don't care if it's RT or not
[02:35:21] <cncuser> jmkasunich: hehe, it wont do much but look nice ;)
[02:35:27] <jmkasunich> I meant bunches of warnings
[02:35:36] <cncuser> jmkasunich: no warnings
[02:35:40] <cncuser> jmkasunich: why ?
[02:35:50] <SWPadnos> on a 64-bit RTAI?
[02:35:55] <jmkasunich> "cast to pointer from integer of different size" and such
[02:36:06] <cncuser> SWPadnos: oh, i c, hmm, dunno
[02:36:32] <SWPadnos> I'll try that some time (when I get daring enough to boot an RT / SMP / 64-bit / NVidia kernel on that machine
[02:36:34] <cncuser> SWPadnos: whats the point with using a 64bit cou with emc ? :)
[02:36:47] <jepler> now that it comes time to start emc in qemu, it's very sluggish...
[02:36:53] <jmkasunich> cause that is what he has...
[02:37:09] <cncuser> jepler: shure, but it works :) even axis looks nice in qmeu :)
[02:37:18] <jmkasunich> SWP: typedef volatile unsigned long hal_u32_t;
[02:37:21] <SWPadnos> realize that in a couple of years, it'll be hard to find 32-bit systems
[02:37:22] <jepler> cncuser: "popimage" has been showing for about 5 minutes
[02:37:26] <cncuser> jepler: the simulated run looks almost as nice as native
[02:37:27] <jmkasunich> I suspect that is gonna be a problem
[02:37:42] <SWPadnos> that should be OK - it's pointers that change
[02:37:43] <cncuser> jepler: haha, yes :)
[02:37:51] <cncuser> jepler: be patient :)
[02:37:54] <jmkasunich> SWP: more than a couple years, but yeah, someday
[02:37:56] <SWPadnos> unless ksirc ate your asterisks
[02:38:25] <jmkasunich> int and long are still both 32 bits?
[02:38:30] <SWPadnos> once Windows 64-bit gets more drivers, it'll happen (for better or for worse)
[02:38:39] <SWPadnos> long may not be, but int still is, I think
[02:38:42] <cncuser> SWPadnos: noway :)
[02:39:03] <jmkasunich> still a 2-3 year or more period to flush out the old (my employer has PCs on a three year cycle)
[02:39:22] <jepler> surely we'll still be able to boot a 32-bit OS in even 6 years
[02:39:24] <jmkasunich> many non-bleeding edge home users are on an even longer cycle
[02:39:45] <jepler> given that GRUB works on an AMD64 I assume that even good old 16-bit DOS is still viable
[02:39:56] <SWPadnos_> sure - you'll be able to buy on eBay for a while
[02:40:26] <SWPadnos_> true - you may have a 64-bit CPU, but the OS can still be 32 bit
[02:41:47] <jmkasunich> I guess for my hal_u32_t I can do some preprocessor magic to figure out what type is 32 bits long
[02:42:05] <jepler> or assume c99, and write uint32_t or whatever the new type is called.
[02:42:10] <SWPadnos_> probably
[02:42:41] <jmkasunich> is gcc >= c99?
[02:42:53] <jmkasunich> because gcc is the only compiler I intend to worry about
[02:42:56] <SWPadnos_> with RTAI 3.2, do you still need ADEOS pathces?
[02:42:59] <SWPadnos_> patches
[02:43:09] <jmkasunich> damfino
[02:43:10] <jepler> even gcc3.4 has pretty good c99 support, I assume 4.x is much better still.
[02:43:29] <jmkasunich> the rtai folks are doing all kind of weird stuff lately
[02:43:49] <SWPadnos_> should I use 3.1 (or 3.0)?
[02:43:55] <jmkasunich> jepler: heh, we're still supporting boxes with gcc 2.95
[02:44:16] <jepler> jmkasunich: in fact, the rtai people say 2.95 is the preferred compiler
[02:44:20] <jmkasunich> what are you doing, your own custom install of RTAI (as opposed to BDI?)
[02:44:37] <SWPadnos_> me?
[02:44:47] <jmkasunich> swp: yes, you
[02:45:08] <jmkasunich> jepler: still? I remember that, but lately I've heard talk of gcc 3.x on the rtai list
[02:45:12] <SWPadnos_> I'm going to try to make an SMP 64-bit RTAI kernel, and see what blows up in the emc compile
[02:45:37] <jmkasunich> I very recently (days ago) heard someone from RTAI say that gcc 4.x was NOT supported, but 3.x was
[02:45:47] <jepler> jmkasunich: still. http://www.rtai.org/modules.php?name=FAQ&myfaq=yes&id_cat=1&categories=Installation+%26+configuration#3
[02:45:49] <jmkasunich> brave man
[02:45:57] <jepler> jmkasunich: I'm not saying that this text isn't out of date, but it is the faq on their own website
[02:46:08] <SWPadnos_> heh - hopefully nothing will get broken by just booting and compiling
[02:46:49] <jmkasunich> ok, I can buy "3 supported, 2.95 recommended"
[02:47:12] <jmkasunich> although their site is hideous, and I wouldn't trust anything on it to be current
[02:48:47] <SWPadnos_> you don't like canary on salmon?
[02:49:15] <jmkasunich> I don't like out of date, misleading, and just plain mixed up info
[02:50:24] <SWPadnos_> heh
[02:51:48] <jepler> SWPadnos_: cradek was also trying to build a real-time kernel package for ubuntu just recently ..
[02:51:57] <jepler> SWPadnos_: I think he got a package but hadn't yet been able to test-boot it
[02:52:14] <jepler> SWPadnos_: you might want to touch base with him before you spend a lot of time on it
[02:52:25] <SWPadnos_> oh - cool. I won't spend too much time on that
[02:52:29] <SWPadnos_> thanks
[02:56:26] <Jymmm> Jymmm is now known as Red70sShow
[02:56:26] <Red70sShow> Red70sShow is now known as Jymmm
[02:57:59] <SWPadnos_> int=4 bytes, long int = 8 bytes, long long int = 8 bytes, pointer = 8 bytes
[02:59:07] <jmkasunich> ok, so those typedefs will need fixed
[02:59:10] <SWPadnos_> double = 8 bytes, long double = 16 bytes (!)
[02:59:16] <SWPadnos_> float is still 4
[03:00:51] <jepler> SWPadnos_: I think it's still really 10 bytes but mumble alignment mumble
[03:01:10] <SWPadnos_> I used sizeof, not addresses of successive variables
[03:01:24] <SWPadnos_> printf("Sizeof(long double) = %d\n", sizeof(long double));
[03:01:51] <jepler> but so that all the elements of 'long double x[4]' are well aligned, you have to bump the size (because by definition they're a sizeof() apart in memory)
[03:02:10] <SWPadnos_> hmmm - I'm not sure I believe that
[03:02:13] <SWPadnos_> char is still 1
[03:02:37] <SWPadnos_> could be a special case though
[03:04:49] <jmkasunich> struct { long double a,b,c,e } foo; print sizeof(foo)
[03:04:51] <jmkasunich> then
[03:05:00] <jmkasunich> struct { long double a[4] } foo; print sizeof(foo)
[03:05:33] <jmkasunich> nah, that doesn't prove anything
[03:05:36] <jmkasunich> both will be 64
[03:05:44] <jmkasunich> even if the actual size is 10
[03:05:58] <SWPadnos_> heh
[03:06:15] <jmkasunich> be more interesting to try it with shorts and/or ints, see how they are packed
[03:06:25] <SWPadnos_> it might work if I do struct {long double a; char b[4]}
[03:06:30] <SWPadnos_> packed
[03:07:54] <jepler> for qsort() to be able to work on structs and scalars both, the role I said about the elements of an array being sizeof(element_type) apart must be true
[03:08:06] <jepler> can't qsort work on long double * just as well as struct { long double } * ?
[03:08:25] <jepler> s/role/rule/
[03:08:43] <jepler> john f*** kennedy, bdi takes ages to shut down in qemu
[03:08:51] <SWPadnos_> there are options to set the size of long double to 128 or 96 bits. I guess it just defaults to 96 bits
[03:11:03] <SWPadnos_> anyway - that doesn't matter here, since emc only uses floats and doubles
[03:14:49] <CIA-5> 03jmkasunich * 10emc2/tcl/bin/setupconfig.tcl: The 'delete config' function of setupconfig.tcl now works. The backup and restore functions are next.
[03:15:17] <jmkasunich> heh - backup and restore are more important, but my configs directory was full of crap from testing the "new" function ;-)
[03:15:48] <SWPadnos_> scrathing your own itch - it's the open source way ;)
[03:15:53] <SWPadnos_> scratching
[03:16:20] <jmkasunich> besides, delete was easier
[03:16:59] <jmkasunich> this damn thing is starting to suffer from bloat
[03:17:16] <SWPadnos_> ok - the long double is still 80 bits of precision, but the default on i386 is to align to 96 bits, and the default on X86-64 is to align to 128 bits
[03:17:37] <SWPadnos_> (32-bit and 64-bit boundaries, respectively)
[03:17:46] <jmkasunich> makes sense
[03:18:01] <jepler> 80 bits is a pretty silly size for a basic type
[03:18:15] <SWPadnos> unfortunately, that's what the 8087 used, so we're stuck with it
[03:18:19] <SWPadnos> it's a "tenbyte"
[03:18:40] <jmkasunich> it was intended to hole intermediate results, with enough precision to prevent roundoff etc from accumulating
[03:18:54] <jmkasunich> you should never have big arrays of them or such
[03:19:01] <jmkasunich> s/hole/hold
[03:19:19] <SWPadnos> too bad they provided an interface to get them out of the FPU ;)
[03:19:59] <jmkasunich> you might want to evaluate expressions that are too complex for the FPU stack
[03:20:28] <SWPadnos> not me, never ...
[03:22:02] <jepler> you might want to task-switch
[03:22:09] <SWPadnos> not me, never ...
[03:23:47] <jepler> wasn't (isn't?) there also an 80-bit BCD type in the 8087?
[03:24:36] <jepler> 17 digits, according to wikipedia.
[03:24:37] <jmkasunich> not sure about that
[03:25:10] <jmkasunich> I wonder if IEEE 754 predated the 8087, or if the spec was written around the defacto standard established by the part?
[03:27:05] <jepler> "Packed BCD numbers are encoded in the 8087 coprocessor's packed BCD format. They can be up to 18 digits long, packed two digits per byte. The assembler zero-pads BCDs initialized with fewer than 18 digits. Digit 20 is the sign bit, and digit 19 is reserved."
[03:27:12] <jepler> http://www.sxlist.com/techref/language/masm/masmc06.htm
[03:28:18] <jmkasunich> I bet that feature is used a lot ;-)
[03:28:54] <jepler> http://http.cs.berkeley.edu/~wkahan/ieee754status/754story.html
[03:29:11] <jepler> umm, cobol?
[03:31:29] <cncuser> good night folks, 4:40 here, gotto sleep
[03:31:37] <jmkasunich> goodnight
[03:35:05] <jepler> are the new non-x87 floating point units (sse etc) full '754 yet?
[03:35:39] <SWPadnos> I don't think so, though sse3 (or nvidia/ati graphics pipes) may be
[03:36:13] <SWPadnos> then again, at only 40k transistors, you could put a whole lot of 8087 on a chip these days
[03:36:30] <jmkasunich> massive parallism ;-)
[03:36:46] <SWPadnos> yeah, like 10000 of them on today's GPUs
[03:37:11] <jmkasunich> I still remember when I got my first FPU... I was running PovRay on a 386sx and spent the big bux for an 80387 to speed up rendering
[03:37:33] <SWPadnos> that must have made it possible to complete scenes in under an hour ;)
[03:37:37] <jepler> AltiVec and SSE are quite similar at the highest levels. They are SIMD vector units with the same vector size (128-bits) and a similar general design. SSE adds several important new features compared to AltiVec. The single and double precision floating point engines are fully IEEE-754 compliant, which means that all four rounding modes, exceptions and flags are available </http://developer.apple.com/hardware/ve/sse.html>
[03:37:39] <SWPadnos> (small scenes)
[03:37:49] <SWPadnos> oh - cool.
[03:38:01] <jepler> it's a bit funny reading Apple pages talking about how Intel is better than PPC
[03:38:06] <SWPadnos> yeah
[03:38:12] <SWPadnos> too bad they ignred AMD
[03:38:14] <SWPadnos> ignored
[03:39:17] <jepler> looks like 80-bit floats are absent in sse, even as temporaries.
[03:39:50] <SWPadnos> they are probably 32-bits internally, and round-off/precision errors be damned
[03:39:59] <SWPadnos> they are meant for graphics, after all
[03:40:59] <jepler> -mfpmath=sse is default for x86-64
[03:41:24] <SWPadnos> in kernel, or gcc in general?
[03:41:28] <jepler> in gcc
[03:41:33] <SWPadnos> interesting
[03:41:44] <jepler> "info gcc" says "The resulting code should be considerably faster in the majority of cases and avoid the numerical instability problems of 387 code, but may break some existing code that expects temporaries to be 80bit."
[03:41:59] <jepler> it's better .. 'cept when it ain't
[03:42:03] <SWPadnos> right
[03:42:35] <SWPadnos> I thought it was only sse3 that added floating point SIMD instructions
[03:42:58] <SWPadnos> or was that sse2?
[03:44:05] <jepler> Both AltiVec and SSE do single precision floating point arithmetic. SSE2 also does double precision floating point arithmetic. </apple>
[03:44:17] <SWPadnos> hm
[03:44:34] <jepler> I think it's MMX -> integer; SSE, 3DNow! -> single precision; SSE2 -> double precision; SSE3 -> profit
[03:45:28] <SWPadnos> heh - that could be
[03:45:46] <SWPadnos> I should look into high speed image processing aclgorithms using SSE
[03:45:53] <SWPadnos> algorithms, that is
[03:46:55] <jepler> SSE3 adds a small series of instructions mostly geared to making complex floating point arithmetic work better in some data layouts. [...] Finally, it adds a small set of additional permutes and some horizontal floating point adds and subtracts that may be of use to some developers. </apple>
[03:47:45] <jepler> what kinds of image processing algorithms? I bet stuff like small 1D convolutions are very appropriate for the vector-type operations
[03:48:18] <SWPadnos> rotation, scaling, translation, cropping (easy), raw->(some format) conversion, colorspace corrections
[03:48:29] <SWPadnos> probably compression as well
[03:48:52] <jepler> if you can speed up dcraw when processing .crw images I'll give you a shiny, crisp one dollar bill
[03:49:07] <SWPadnos> ooooh - crispy ones
[03:49:17] <SWPadnos> which algorithm?
[03:49:49] <jepler> whatever's used by the ufraw plug-in for gimp
[03:50:05] <SWPadnos> I think there are several options
[03:51:07] <SWPadnos> ok - two options, normal and quick (low quality)
[03:51:36] <SWPadnos> well - if I improve dcraw or imagemagick, the changes will (of course) be fed back to the projects
[03:52:24] <jepler> I'm not even sure what the slow part of dcraw is, but even on a fast machine it takes several seconds to decode (in normal quality mode)
[03:54:42] <SWPadnos> I noticed that - I ran tests on a number of machines, using 14MPixel images (from a Kodak DCS Pro14n)
[03:55:59] <SWPadnos> interestingly, it was about 3x as fast on Linux as on Windows, using the same machine
[03:56:12] <SWPadnos> (processing time, not file access)
[03:56:29] <jepler> huh. what compiler on windows?
[03:56:44] <SWPadnos> I used both Borland C and gcc under cygwin
[03:56:58] <SWPadnos> I don't have any MS or Intel compilers
[03:57:25] <jepler> % cumulative self self total
[03:57:25] <jepler> time seconds seconds calls s/call s/call name
[03:57:25] <jepler> 48.42 51.75 51.75 1 51.75 80.25 ahd_interpolate
[03:57:25] <jepler> 26.60 80.18 28.43 13075049 0.00 0.00 cam_to_cielab
[03:57:25] <jepler> 11.66 92.64 12.46 1 12.46 12.46 convert_to_rgb
[03:57:46] <jepler> step 1. inline cam_to_cielab?
[03:58:01] <jmkasunich> srange... the commit message from my commit at 2214 has arrived, the one from the commit at 2009 has not
[03:58:24] <SWPadnos> I still haven't gotten the TODO changes from a couple of days ago ;)
[03:59:02] <SWPadnos> 13 million calls to that function - looks like a good candidate ;)
[03:59:10] <jmkasunich> good point - I remember one commit message disappearing entirely, but didn't recall that it was a commit to TODO
[03:59:23] <jmkasunich> so thats two commits to TODO that didn't get sent to the list
[04:01:58] <SWPadnos> I wonder if the root dir isn't monitored for some reason
[04:02:11] <jmkasunich> maybe
[04:02:13] <SWPadnos> I also don't havea commit notice for the changes Ray made to directory.map
[04:02:45] <SWPadnos> or README by Alex on dec. 13
[04:02:56] <jmkasunich> heh, guess thats it
[04:03:41] <SWPadnos> maybe that would be a good SF support ticket
[04:03:58] <SWPadnos> if they have such a thing
[04:04:33] <jmkasunich> they have support tickets, but its probably an error in the way we have the commit list configured
[04:04:48] <SWPadnos> could be - I was just going to check the list archives
[04:04:54] <SWPadnos> in case it's a mailer thing
[04:06:22] <SWPadnos> nope - not in the archives
[04:06:44] <cradek> I just checked in a possible fix
[04:07:08] <CIA-5> 03cradek * 10CVSROOT/loginfo: commits in the root directory did not get mailed
[04:07:43] <cradek> does anyone have a TODO change to try?
[04:08:04] <jmkasunich> Mailing emc-commit@lists.sourceforge.net...
[04:08:04] <jmkasunich> Generating notification message...
[04:08:04] <jmkasunich> Generating notification message... done.
[04:08:16] <cradek> that seems promising
[04:08:22] <jmkasunich> that happened on my commit to setupconfig.tc, but not on my one to TODO
[04:08:31] <cradek> even now?
[04:08:34] <jmkasunich> so it is detectable as soon as the commit is done (if you are looking)
[04:08:43] <cradek> I mean, since my change?
[04:08:44] <jmkasunich> no, I haven't changed TODO or done a test commit yet
[04:08:56] <cradek> oh, ok
[04:09:02] <cradek> I probably fixed it
[04:09:16] <jmkasunich> doing test now
[04:09:47] <jmkasunich> worked
[04:09:48] <CIA-5> 03jmkasunich * 10emc2/TODO: added a blank line to TODO - testing a commit list issue
[04:09:54] <cradek> whee
[04:10:02] <jmkasunich> I'm glad someone knows how the commit list works, cause I sure don't
[04:10:10] <SWPadnos> is CIA signed up to the list?
[04:10:26] <cradek> CIA and the mailing list are unrelated
[04:10:29] <jmkasunich> I was just wondering about that
[04:10:29] <SWPadnos> I'm pretty sure I saw the messages on IRC before (may not have)
[04:10:35] <cradek> yes you probably did
[04:10:39] <jmkasunich> how does CIS get the news
[04:10:41] <jmkasunich> you did
[04:10:50] <jmkasunich> s/CIS/CIA
[04:11:00] <cradek> the cvs checkin runs a cia script as well as sending the mail
[04:11:16] <cradek> the cia script ... does a magic cia thing
[04:11:28] <SWPadnos> I guess it worked
[04:11:30] <jmkasunich> sends a mail to the cia server, or something else?
[04:12:05] <cradek> yeah, it sends an xml email to cia.navi.cx
[04:12:21] <cradek> of all things
[04:12:46] <cradek> well I got the TODO email
[04:13:06] <jmkasunich> me too...
[04:13:13] <jmkasunich> hey, another bug bites the dust
[04:13:22] <cradek> whee
[04:15:57] <SWPadnos> and we didn't even know it existed ;)
[04:16:24] <jmkasunich> actually, the missing message from some days ago was bugging me
[04:16:56] <SWPadnos> me too - I assumed it was a mail problem, or some temporary SF thing (they were having problems at the time)
[04:17:25] <cradek> it's easy to dismiss anything as a temporary SF problem - they have many of them
[04:18:24] <jmkasunich> I wonder if they fixed the most recent pserver one
[04:18:30] <Jymmm> In case you guys were wondering what to get me for Christmas: http://www.sonystyle.com/is-bin/INTERSHOP.enfinity/eCS/Store/en/-/USD/SY_DisplayProductInformation-Start;sid=9ZZMU-hklpFNMaupT-VGWKdp4z1yNijySlc=?ProductSKU=RDRHX715&Dept=tvvideo&CategoryName=hav_DVD_DVDPlayers
[04:18:48] <jmkasunich> bah
[04:19:33] <jmkasunich> looks like the pserver login problem is fixed
[04:20:06] <cradek> I can't take credit for that one
[04:20:21] <jmkasunich> no, that was just SF getting off their duffs
[04:30:26] <jmkasunich> bedtime for me
[04:31:35] <Jymmm> POOF! Who was that masked man??????????????
[04:47:22] <jepler> disappointing. My 1.8GHz AMD64 has only a 10% speed advantage over my 1.5GHz pentium-m running dcraw
[04:47:38] <SWPadnos_> 32-bit OS or 64-bit?
[04:47:54] <jepler> 64-bit OS
[04:48:00] <SWPadnos_> ok
[04:48:22] <SWPadnos_> I ran tests, and I think there was about a doubling from an athlon XP 2200 to the Opteron
[04:48:26] <SWPadnos_> lemme check
[04:48:39] <jepler> maybe I'm using bad gcc options
[04:49:10] <jepler> -funroll-loops gained me more than a second, 4.0 vs 5.3
[04:49:23] <jepler> now it's significantly faster than the laptop (4.0 vs 6.1)
[04:49:26] <SWPadnos_> this is what I found was the best (on the Athlon XP):
[04:49:38] <SWPadnos_> gcc -O3 -march=athlon-xp -fomit-frame-pointer -finline-functions -fexpensive-optimizations -fprefetch-loop-arrays -falign-functions=4 -falign-loops=4 -falign-jumps=4 -msse -mmmx -m3dnow -mfpmath=sse -lm dcraw.c -o dcraw-xp
[04:50:02] <SWPadnos_> it's probably a bit different for the AMD64 though
[04:50:36] <jepler> -fexpensive-optimizations is implied by -O3; I'll look into the rest
[04:51:10] <jepler> -fprefetch-loop-arrays adds .3 seconds
[04:51:14] <SWPadnos_> true enough - it's in O2
[04:51:19] <jepler> -fomit-frame-pointer doesn't make any difference
[04:51:36] <jepler> (less register pressure on amd64)
[04:52:11] <jepler> -falign-loops doesn't seem to matter
[04:57:15] <SWPadnos_> argh - what's the incantation to get profiling on dcraw?
[04:58:39] <jepler> gcc -pg ...; dcraw ...; gprof dcraw | less
[04:58:44] <Jymmm> SWPadnos: two vultures, frog lips, wing of bat, and one small diet soda
[04:59:02] <SWPadnos_> damn - I don't have any diet soda
[04:59:12] <Jymmm> Well, that's for me actually
[04:59:17] <SWPadnos_> h
[04:59:19] <SWPadnos_> oh
[05:00:49] <jepler> with -fprofile-generate + -fprofile-use I got a user time under 4 seconds
[05:00:52] <jepler> so now I'm going to go to bed
[05:01:08] <SWPadnos_> ok
[05:01:15] <SWPadnos_> vs. the 80 before?
[05:02:07] <jepler> I think those profiling numbers in seconds were wrong
[05:02:21] <jepler> the wall time was about 11 seconds for the first compiles
[05:02:28] <SWPadnos_> ok
[05:02:42] <SWPadnos_> still, a 3x speedup is pretty significant
[05:03:20] <SWPadnos_> can youpost the full gcc line?
[05:04:05] <jepler> gcc -march=athlon64 -fprofile-use -funit-at-a-time -m64 -mno-ieee-fp -fomit-frame-pointer -O3 -funroll-loops -ftree-vectorize dcraw.c -o dcraw_jepler -lm -ljpeg
[05:04:12] <jepler> but I also did some optimizations in dcraw.c
[05:04:18] <SWPadnos_> ok
[05:04:26] <SWPadnos_> that cielab conversion was pretty horrendous
[05:04:53] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/dcraw-optimizations.patch
[05:05:11] <SWPadnos_> thanks
[05:05:39] <jepler> tune TS based on L1 cache size. the default, 256, doesn't fit in 1M
[05:05:39] <SWPadnos_> heh - called from only one or two places, no doubt
[05:05:53] <SWPadnos_> you have an Athlon64?
[05:05:57] <SWPadnos_> not opteron
[05:06:01] <jepler> it's a .. palermo
[05:06:05] <jepler> sempron
[05:06:06] <SWPadnos_> ok
[05:06:07] <jepler> marketing word
[05:06:12] <SWPadnos_> that should be 512k cache
[05:06:16] <jepler> and a "+" at the end
[05:06:24] <SWPadnos_> gotta have a +
[05:06:25] <jepler> goodnight
[05:06:28] <SWPadnos_> or it's not marketable
[05:06:34] <SWPadnos_> night - thanks again
[05:07:24] <jepler> -frename-registers (known buggy, according to the info page) trimmed another .1 second
[05:07:40] <SWPadnos_> heh - that might not be the best thing
[05:07:46] <SWPadnos_> if it actually is buggy
[05:07:58] <jepler> the image still looked the same
[05:08:14] <SWPadnos_> do bitwise comparisons sho that?
[05:08:17] <SWPadnos_> show
[05:08:24] <jepler> I dunno, I'm not preserving the output from run to run
[05:08:38] <SWPadnos_> ok. I can check that
[05:08:45] <SWPadnos_> what size image were you using?
[05:09:08] <jepler> it's a 6-megapixel image from a canon digital rebel
[05:09:47] <SWPadnos_> ok - I've got 4.7, 8.5, and 14 mpixel images -I'll check the smaller ones
[05:10:18] <SWPadnos_> holy crap!
[05:10:35] <jepler> ??
[05:10:50] <SWPadnos_> the 5mpixel image processed in 0.79 seconds
[05:10:55] <SWPadnos_> there must be some error there
[05:11:14] <SWPadnos_> the 14 MP still took roughly 12 seconds (not using your patch)
[05:11:56] <jepler> did I mention that one of my optimizations assumes that colors==3 all the time?
[05:12:08] <jepler> this option helps another .1s: -fbranch-target-load-optimize
[05:12:14] <jepler> really going to bed this time...
[05:12:15] <SWPadnos_> nope, but I haven't applied your patch yet
[05:12:17] <SWPadnos_> ok
[05:12:55] <SWPadnos_> there must be a square or cube law increase going on here
[05:15:40] <jepler> or else the steps before ahd_interpolate() are much harder for the kodak
[05:16:06] <jepler> you should be able to do blocks in ahd_interpolate() on separate CPUs ...
[05:17:23] <SWPadnos_> I think there are some image-wide settings (contrast, gray level)
[05:18:44] <SWPadnos_> the total time to process the 8.5MP file is around 1.2 seconds here
[05:21:55] <jepler> I've been using this file: http://emergent.unpy.net/index.cgi-files/sandbox/crw_9476.crw
[05:22:24] <SWPadnos_> ok - one sec
[05:22:25] <jepler> and dcraw is $Revision: 1.309 $
[05:22:37] <SWPadnos_> I have an older one, I can just about guarantee ;)
[05:22:48] <SWPadnos_> 1.178
[05:23:09] <jepler> it's probably not using the same interpolation method .. I think ahd is relatively new
[05:23:19] <jepler> upgrade & slow down!
[05:23:32] <SWPadnos_> strange - I just downloaded it, and I have revision 1.295 in the download dir
[05:23:59] <jepler> * jepler shrugs
[05:24:21] <SWPadnos_> maybe I downloadde on a different machine?
[05:24:49] <SWPadnos_> yep - duh
[05:26:10] <SWPadnos_> it is slower - around 6 seconds
[06:01:41] <Jymmm> you want a 384MB jpg to process?
[06:01:52] <SWPadnos> no thanks
[06:01:57] <Jymmm> wuss
[06:02:07] <SWPadnos> I have some gigabyte images actually
[06:02:28] <SWPadnos> I can't fit all the blue marble images on my hard drives
[06:03:01] <Jymmm> Orion Nebula
[06:05:01] <SWPadnos> http://earthobservatory.nasa.gov/Newsroom/BlueMarble/BlueMarble_monthlies.html
[06:06:15] <Jymmm> ```
[06:06:21] <Jymmm> cool
[06:06:27] <SWPadnos> yeah
[06:06:47] <SWPadnos> the large images are around 20G each, compressed (*8 for the whole planet)
[06:08:01] <Jymmm> http://hubblesite.org/
[06:08:22] <SWPadnos> I have a few of those as well (though not the humongous ones)
[06:09:03] <SWPadnos> hmmm - I may have multiplied one time too many - it looks like the large images are 2.9G gzipped RAW files
[06:09:57] <Jymmm> Well, at least those I can toss on a dvd
[06:10:20] <Jymmm> gonna get 200 (maybe 400) later this month
[06:10:42] <SWPadnos> dvds
[06:10:44] <SWPadnos> ?
[06:10:58] <Jymmm> Yeah, blanks
[06:12:30] <SWPadnos> ah
[06:13:47] <Jymmm> I'm running real low right now and costco is gonna be having a sale
[06:15:07] <SWPadnos> really? I'll have to look at the coupon flyer again
[06:18:00] <Jymmm> yep
[06:18:24] <SWPadnos> this is a cool image. low res, but still amazing http://www8.arsc.edu/nasa/bmng/world_8km/world.topo.bathy.200408.3x5400x2700.jpg
[06:18:44] <SWPadnos> the highest resolution is 500m instead of 8km
[06:20:12] <Jymmm> Tis ok, I found another one I'll be using shortly
[06:20:52] <SWPadnos> ok - time for bed. see you later
[06:21:31] <Jymmm> G'Night SWPadnos
[06:21:39] <SWPadnos> SWPadnos is now known as SWP_Away
[06:21:52] <SWP_Away> night
[06:22:26] <SWP_Away> for large images, look here :) ftp://www8.arsc.edu/nasa/bmng/world_big/
[06:22:54] <Jymmm> thanks!
[06:23:00] <SWP_Away> heh - sure
[06:23:08] <SWP_Away> only 90G or so of gzipped image data
[06:23:38] <Jymmm> heh
[07:48:09] <anonimasu> hi
[10:05:27] <Jacky^> morning
[10:40:36] <anonimasu> morning
[10:42:17] <Jacky^> hi anonimasu
[14:31:17] <Jacky^> Jacky^ is now known as Jacky^afk
[16:08:22] <Jymmm> Jymmm is now known as Red70sShow
[16:08:22] <Red70sShow> Red70sShow is now known as Jymmm
[16:11:44] <Jymmm> http://tinyurl.com/ca56n
[16:12:03] <SWP_Away> sicko
[16:12:17] <Jymmm> SWP_Away that's not a pic of you?
[16:12:28] <SWP_Away> I don't think so
[16:12:34] <SWP_Away> hard to tell ;)
[16:12:35] <Jymmm> you sure?
[16:12:47] <SWP_Away> can't really see the person, after all
[16:12:54] <Jymmm> didnt you say you had problems getting your glight one time?
[16:13:00] <Jymmm> flight
[16:13:21] <SWP_Away> several times, but not due to my face setting off the metal detectors
[16:13:26] <SWP_Away> SWP_Away is now known as SWPadnos
[16:13:47] <Jymmm> lol
[16:55:22] <Jacky^afk> Jacky^afk is now known as Jacky^
[18:48:45] <Jacky^> http://www.flickr.com/
[18:54:27] <Ebstein> Jacky^: is flickr free ?
[18:55:38] <Ebstein> ok :) is free
[18:56:01] <Ebstein> i understand after look
[19:32:49] <servant74> question ... where can I find a bootable bdi cd image to download?
[19:33:28] <SWPadnos> http://www.cncgear.com/EMC/BDI/
[19:33:42] <SWPadnos> there's a list of mirrors at http://www.linuxcnc.org/bdi/
[19:34:31] <servant74> thanks
[19:34:36] <SWPadnos> sure
[19:42:05] <les_w> hello all
[19:42:17] <SWPadnos> hey Les
[19:42:42] <les_w> boring office work day for me
[19:43:16] <les_w> having to buy microphones (with client's money)
[19:43:34] <Jacky^> hey les_w
[19:43:40] <alex_joni> hello all
[19:43:54] <les_w> $1200 for the capsules, about as much again for the preamps
[19:44:03] <les_w> jacky!!!
[19:44:11] <Jacky^> :-)
[19:44:12] <les_w> my package came!
[19:44:19] <Jacky^> good
[19:44:20] <les_w> thank you
[19:44:26] <Jacky^> ;)
[19:44:33] <Jacky^> how much you payed ?
[19:44:37] <Jacky^> for customs ?
[19:44:43] <les_w> I read the books
[19:44:50] <Jacky^> nice
[19:44:54] <les_w> did not have to pay
[19:45:03] <Jacky^> wow, cool
[19:45:12] <Jacky^> something broken ?
[19:45:20] <les_w> I have not opened the can of napoli air haha
[19:45:26] <les_w> nothing broken
[19:45:27] <Jacky^> hehe
[19:45:32] <Jacky^> good
[19:46:05] <les_w> oh and the bottle...do I splash that on my face or drink it?
[19:46:25] <Jacky^> I think you could drink it too
[19:46:27] <Jacky^> hehe
[19:46:32] <les_w> hahaha
[19:47:10] <les_w> I must adapt the power plug on the carpenter
[19:47:16] <les_w> 220v right?
[19:47:22] <Jacky^> yeah
[19:47:47] <Jacky^> we've been busy these latest days ..
[19:48:21] <les_w> well it is good to be busy
[19:48:25] <les_w> usually
[19:48:36] <Jacky^> not at all
[19:49:36] <les_w> I have not been very busy since I have to wait for a production quote from a company
[19:50:16] <les_w> In fact yesterday I installed new amplifiers and speaker drivers in the music room
[19:50:51] <Jacky^> my brother-in-law, my sister and the son had a bad car accident in sunday
[19:51:22] <Jacky^> we did napoli-bari-napoli for 3 days to go at the hospital
[19:51:31] <Jacky^> 600 km at day
[19:52:01] <Jacky^> Its a miracle theyre al alive
[19:52:56] <Jacky^> http://digilander.libero.it/jackydgl0/incidente.jpg
[19:53:02] <les_w> looking
[19:53:09] <Jacky^> hewas driving at 160 km/h
[19:53:26] <Jacky^> had a sleep .. after 4 hours of travel
[19:54:04] <les_w> friend?
[19:54:05] <Jacky^> the children had a fly of 20 mt ..
[19:54:20] <Jacky^> my sister
[19:55:10] <alex_joni> don't want to make fun of that accident, but saying "had a fly of 20 mt" is really funny
[19:55:55] <Jacky^> http://digilander.libero.it/jackydgl0/pics/anmary.jpg
[19:56:11] <Jacky^> shes my daughter was in the car
[19:56:32] <Jacky^> she flyed out,
[19:56:49] <alex_joni> Jacky^: I know, I understood.. feel sorry for that
[19:56:57] <Jacky^> and she's lucky because..
[19:57:36] <alex_joni> who is in that picture? (incidente..)
[19:57:52] <Jacky^> she finished in meadow
[19:58:08] <Jacky^> in the picture are the driver
[19:58:16] <Jacky^> and k4ts
[19:58:32] <alex_joni> aha..
[19:59:03] <Jacky^> the children flyed up to a wall 3 mt high
[19:59:15] <Jacky^> in a meadow
[19:59:37] <Jacky^> tomorrow they will leave the hospital
[19:59:48] <Jacky^> it seem incredible to me yet ..
[20:00:07] <Jacky^> he lost the control of the car for about 150 mt
[20:00:14] <Jacky^> at 160 km/h
[20:01:43] <Jacky^> my sister couldnt found the son looking arond the car
[20:02:21] <anonimasu> hello
[20:02:54] <Jacky^> they found she because other peoples have seen the fly she did ..
[20:02:57] <alex_joni> hi anders
[20:03:02] <Jacky^> hi anonimasu
[20:03:02] <anonimasu> what's up?
[20:04:14] <alex_joni> not mcuh
[20:04:22] <alex_joni> much
[20:05:17] <Jacky^> the strange thing, no airbag has opened
[20:05:33] <anonimasu> that requires quite a shick
[20:05:35] <anonimasu> shock..
[20:05:47] <Jacky^> maybe for the sensors position too
[20:05:54] <anonimasu> like a brick wall,shock/har stop
[20:05:58] <alex_joni> anonimasu: crashing at 160km/h is quite a shock
[20:06:18] <anonimasu> alex_joni: that depends if you hit something, or if you pass through it
[20:07:28] <Jacky^> he just lost the control of the car for about 150 mt
[20:07:44] <les_w> glad they will be ok
[20:07:48] <Jacky^> he sayd about 4-5 sec.
[20:08:00] <anonimasu> yeah :)
[20:08:09] <Jacky^> crashing everywhere
[20:08:31] <Jacky^> les_w: I think at a Miracle
[20:08:45] <Jacky^> cant explain it in other ways
[20:09:38] <Jacky^> dinner time
[20:09:39] <Jacky^> later
[20:09:44] <Jacky^> Jacky^ is now known as Jacky^afk
[20:20:45] <CIA-14> 03alex_joni * 10emc2/src/emc/kinematics/ (prflib.h trajectory.h): removed two files of incompatible license
[20:32:39] <Jacky^afk> Jacky^afk is now known as Jacky^
[21:30:47] <Jymmm> Jymmm is now known as Jymmmm
[21:31:08] <Jymmmm> Jymmmm is now known as Jymm
[21:33:23] <SWPadnos> hey Jymm, got that spindle control all figured out? :)
[21:34:10] <Jymm> nope
[21:34:15] <alex_joni> let him decide on the number of m&m's first
[21:34:19] <Jymm> and it's SAFE spindle control.
[21:34:19] <SWPadnos> well OK then :)
[21:34:56] <Jymm> SWPadnos so you have any ideas or just being a smartass?
[21:35:05] <Jymm> huh? huh? huh?
[21:35:11] <SWPadnos> not much to go on yet
[21:35:33] <Jymm> what are you babbling about?
[21:35:34] <SWPadnos> you asked a qquestion a lot like "how do I build a car?"
[21:36:16] <Jymm> I have a SSR, how do you prevent it from triggerigng during boot, crash, loose cable etc
[21:36:55] <SWPadnos> loose cable is easy, you make sure that the SSR requires activation rather than allowing deactivation
[21:37:03] <Jymm> ok, how
[21:37:15] <SWPadnos> ie, there's no power to the SSR unless some switch is closed
[21:37:33] <Jymm> defeats the purpose of spindle control
[21:38:09] <SWPadnos> yes, but if there's computer control of the spindle, then you can't reliably prevent it from turning on if the software goes haywire
[21:38:41] <SWPadnos> or someone else hits ENTER while the dialog asking you to change tools is onscreen
[21:38:54] <SWPadnos> see -that was easy ;)
[21:39:02] <Jymm> I'm gonna ban you bitch!
[21:39:33] <SWPadnos> it's not a trivial problem, as the discussions between e.g. ray and myself have shown
[21:39:33] <Jymm> MAch has a 8Khz pulse, if the pulse is missing the spndle stops.
[21:39:54] <SWPadnos> if the pulse train is missing, the breakout board should shut off
[21:40:02] <Jymm> I dont know how exactly the rx is suppose to see that, but it sounds reasonable
[21:40:08] <SWPadnos> rx?
[21:40:16] <Jymm> Receiver
[21:40:26] <Jymm> a blk box
[21:40:32] <SWPadnos> what is the receiver?
[21:40:46] <Jymm> I dont know, something has to receive that 8KHz pulse
[21:40:58] <alex_joni> Jymm: watchdog
[21:41:00] <SWPadnos> ok, so you don't have one
[21:41:13] <Jymm> and I dont have a 8KHz pulse either.
[21:41:17] <SWPadnos> look at Steve Stallings' site: http://www.pmdx.com/
[21:41:20] <Jymm> That was just one example
[21:41:22] <alex_joni> set to a bit more than 1/8Khz
[21:41:34] <SWPadnos> you could do it with a microcontroller
[21:41:39] <Jymm> alex_joni I'm not using Mach, I was just describing their solution
[21:42:11] <SWPadnos> emc2 can do that as well - just set up a squarewave generator, and connect it to a parport pin
[21:42:17] <Jymm> I'd rather have some HW safety device instead of relying upon the controller
[21:42:32] <SWPadnos> this is a combination, but it doesn't serve your purpose
[21:42:55] <SWPadnos> the charge pump solution prevents bad things from happening before the software starts
[21:43:03] <SWPadnos> it doesn't prevent the software from doing bad things
[21:43:48] <Jymm> I'm more concerned if the sw crashes
[21:43:54] <Jymm> or freezes, etc
[21:44:21] <SWPadnos> that'll depend on how the crash occurs, ie, does it kill off interrupts (which may be used to generate the pulse stream)
[21:44:32] <Jymm> I'm still gonna have a ON/OFF/AUTO switch as well.
[21:44:57] <SWPadnos> one trick is to use latching switches (latched with a coil activated by the switch)
[21:45:07] <SWPadnos> it's a standard e-stop / start configuration
[21:45:34] <Jymm> well estop will kill all, but I'm taking accidental startup
[21:45:34] <k4ts> hello
[21:45:46] <Jymm> like tool changes
[21:45:56] <Jymm> like between manual tool changes
[21:46:05] <Jymm> or part swap
[21:46:22] <Jymm> Hi k4ts
[21:46:31] <SWPadnos> are you assuming that the software will be stable while your fingers are on the tool?
[21:46:43] <SWPadnos> hi k4ts
[21:46:54] <Jymm> Software, yes. System itself, no.
[21:47:00] <k4ts> hi SWPadnos
[21:47:11] <SWPadnos> System being the copmputer, or the whole machine and controller?
[21:47:16] <SWPadnos> computer
[21:47:27] <Jymm> computer, os, paraport cable
[21:48:02] <SWPadnos> ok, then the charge pump solution is probably sufficient
[21:50:09] <k4ts> SWPadnos two nick?
[21:50:12] <Jymm> ok, what is a "charge pump" (and I am readin that page)
[21:50:18] <SWPadnos> two machines ;)
[21:50:25] <k4ts> ih
[21:50:28] <Jymm> k4ts clones
[21:50:44] <k4ts> ih ih Jymm
[21:51:26] <k4ts> I also two pc Jacky^ and k4ts
[21:52:30] <Jymm> SWPadnos: what's a "charge pump" circuit that I could make?
[21:52:39] <jepler> Jymm: Hook a RC filter up to the output of a digital I/O port. If the I/O port maintains a 50% duty cycle, then the voltage on the capacitor is about V/2. If it stops at high or low, then the voltage goes to V or 0.
[21:53:37] <jepler> Jymm: so you stop the spindle when voltage goes above 2/3 V or below 1/3V
[21:53:38] <alex_joni> opamp as a comparator for the voltage
[21:53:41] <alex_joni> and you're set
[21:53:57] <Jymm> jepler: would that prevent transiants?
[21:54:09] <Jymm> lil glitches
[21:54:10] <alex_joni> output from opamp drives a transistor, that drives a relay
[21:54:18] <alex_joni> also driven by estop
[21:54:22] <Jymm> alex_joni I'm using a SSR
[21:54:23] <SWPadnos> phone
[21:54:26] <alex_joni> Jymm: repends on the the RC values
[21:54:28] <Jymm> SWPadnos k
[21:55:02] <Jymm> I dont mind a couple second delay on enabling, wouldn't really want a delay on disable
[21:55:02] <alex_joni> The general rule on about people on IRC seems to be "Attractive, single, mentally stable: choose two"
[21:55:21] <alex_joni> how fast does the spindle stop?
[21:55:36] <Jymm> pretty quick
[21:55:45] <Jymm> no brake or anything
[21:57:10] <jepler> alex_joni: is there a way to do this with a single comparator?
[21:57:27] <jepler> alex_joni: seems like you'd have to have two, and OR them together
[21:57:29] <alex_joni> not really
[21:57:34] <alex_joni> yes, what you said
[21:57:43] <SWPadnos> you need a diode
[21:58:44] <SWPadnos> ok - off the phone
[21:59:06] <Jymm> s/the phone/my rocker/
[21:59:10] <Jymm> =)
[21:59:14] <SWPadnos> of course
[22:00:05] <SWPadnos> a simple charge pump is jus a resistor tied to the port pin, going to a cap, which goes to a diode, which goes to another cap. the output is the node at the second cap and the diode, the cap should be connectedto ground, and probably shuold have a resistor across it
[22:00:26] <Jymm> Ok, so what your saying is receive an active signle for at least (lets say) 5 seconds, and if the single is lost at all, it wont enable the output
[22:01:08] <SWPadnos> the output is only enabled while the signal is active (within some fraction of a second)
[22:01:38] <Jymm> I like my idea better
[22:01:54] <SWPadnos> here's a big complex charge pump (10 stages) http://www.solarbotics.net/library/circuits/misc_pump.html
[22:02:11] <Jymm> A + B_lagged_5s AND together
[22:02:11] <SWPadnos> 7 stages
[22:02:22] <jepler> SWPadnos: oh, in this context I don't think it's about increasing voltage
[22:02:46] <SWPadnos> it sort of is - you increase for each pulse, and the bleeder resistor decvreases linearly
[22:02:55] <SWPadnos> not enough pulses per time unit, and the output goes low
[22:04:10] <jepler> but if the input gets stuck doesn't your circuit end up at Vcc - Vf?
[22:04:40] <SWPadnos> could be - there should be a diod eto prevent that, but I don't remember exactly where it goes at the moment ;)
[22:06:16] <Jymm> jepler: Your RC filter desc was to utilize a pulse stream?
[22:06:31] <SWPadnos> the Geckodrive group has a charge pump .pdf file with two circuits in it
[22:06:43] <SWPadnos> "ChargePumpSafety.pdf"
[22:06:47] <jepler> is that one of those terrible yahoo things that I have to log in to?
[22:06:48] <Jymm> * Jymm looks
[22:06:53] <SWPadnos> yes
[22:07:07] <jepler> ah, here's a copy: http://www.artofcnc.ca/ChargePumpSafety.pdf
[22:08:09] <alex_joni> <StaticFish> Where did I put my stick of RAM?
[22:08:10] <alex_joni> <StaticFish> I'm losing my memory.
[22:08:13] <alex_joni> lol
[22:08:21] <SWPadnos> I saaw that one ;)
[22:08:35] <jepler> OK, I think I understand Fig. 1
[22:10:02] <jepler> It wouldn't have crossed my mind to use the gate capacitance to get rid of a capacitor, almost seems too clever
[22:10:40] <SWPadnos> Mariss is a smart guy
[22:10:50] <alex_joni> <conrailto> any German speakers here?
[22:10:51] <alex_joni> <issq> i own a set of harmon kardens
[22:11:22] <SWPadnos> <BUBBLES> Shit. I need a date for a new year's eve concert.
[22:11:24] <SWPadnos> <Nick> december 31st
[22:11:34] <cradek> haha
[22:11:34] <jepler> where are you getting these?
[22:11:39] <jepler> they're pretty funny
[22:11:43] <SWPadnos> bash.org
[22:11:43] <Jymm> bash.org
[22:11:44] <alex_joni> bash.org
[22:11:46] <SWPadnos> bash.org
[22:11:50] <alex_joni> bash.org
[22:11:50] <cradek> is it bash.org?
[22:11:54] <SWPadnos> I think so
[22:11:57] <alex_joni> lol
[22:12:08] <alex_joni> this might even qualify for bash.org :D
[22:12:11] <SWPadnos> heh
[22:12:52] <Jymm> nah, not sick and twisted enough
[22:12:58] <SWPadnos> OK - this is great:
[22:12:59] <SWPadnos> (dez) I had to write an essay about handicapped parking spots
[22:13:01] <SWPadnos> (dez) I chose to write about how fat people are not handicapped
[22:13:03] <SWPadnos> (dez) And how they should get special parking spots at the end of the lot
[22:13:31] <alex_joni> <Blowjob-Queen> Is she still internet dating him?
[22:13:31] <alex_joni> <Fizzly> They were in the middle of a "harsh break up" last I remember.
[22:13:31] <alex_joni> <Fizzly> Text was flying so fast.
[22:13:32] <alex_joni> <Fizzly> Emoticons ran wild.
[22:13:59] <jepler> those are not so funny
[22:14:09] <jepler> I love the "quick comeback" type
[22:14:17] <alex_joni> <E^> Your mom is like HTML
[22:14:18] <alex_joni> <E^> Tiny head, huge body!
[22:14:22] <alex_joni> how's that?
[22:16:22] <SWPadnos> http://bash.org/?178890
[22:16:39] <jepler> <che> there's a programmer's union?
[22:16:39] <jepler> <Wintermute> yes
[22:16:41] <jepler> <Wintermute> Local 100100101110101010010
[22:16:46] <SWPadnos> heh
[22:17:07] <jepler> SWPadnos: oh that's so funny
[22:17:14] <SWPadnos> I liked it ;)
[22:19:08] <SWPadnos> <skrike> I think the people above me are having sex
[22:19:10] <SWPadnos> <skrike> either that or they're sleeping restlessly and agreeing with each other a lot.
[22:25:30] <alex_joni> <Dave_The_Insane[depressed]> whats with all the netsplits?
[22:25:30] <alex_joni> <Rodzilla> J0 MAMA
[22:25:30] <alex_joni> <Dave_The_Insane[depressed]> o_O
[22:25:30] <alex_joni> <Rodzilla> SHE'S SO FAT SHE SPLIT THE FREAKING INTERNET IN HALF
[22:25:31] <alex_joni> <Rodzilla> AHAAHAHAHAHHAH
[22:27:48] <alex_joni> this is nice:
[22:27:50] <alex_joni> <the_JinX> Now, Play Russian Roulette In Bash, Just Run This Line:
[22:27:50] <alex_joni> <the_JinX> [ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo "You live"
[22:27:50] <alex_joni> <psychosquee[]> the_JinX: What are the odds?
[22:27:50] <alex_joni> <the_JinX> 1 in 6 chance of removing your linux
[22:27:52] <alex_joni> * psychosquee[] has quit IRC (Connection reset by peer)
[22:32:31] <alex_joni> well.. guess I'll go to bed
[22:32:33] <alex_joni> night all
[22:32:38] <cradek> g'night
[22:32:39] <SWPadnos> see ya
[22:33:20] <k4ts> night
[22:50:25] <cradek> <theclubhousebarandgrillgod> i have a ????? who is the admin here
[22:50:25] <cradek> <Kyle> You have a horse?
[22:50:26] <cradek> <jeff> I'd like to buy a vowel.
[23:29:30] <Jacky^> night