00:08:43 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 where are those instructions? 00:16:48 |<--- between here and there --->| 00:16:57 oh - those instructions ;) 00:17:27 apt-get source emc 00:17:28 Will get you the most recent tarball. Check with viewcvs at SF for the last 00:17:28 tag - This will be most recent checkout from which the emc package was 00:17:28 compiled from. 00:17:43 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 ok. the changelog for BDI 4.38 doesn't say anything about emc updates. it's mostly security 00:18:03 ok 00:18:06 makes sense ;) 00:18:14 yeah, but I think it's wrong 00:18:38 lots of wrong stuff going on lately, on both "sides", I think 00:27:08 jepler, how did you get networking to work under qemu? 00:27:17 that's the only issue I have with it so far 00:30:33 SWPadnos: I didn't do anything special, but outgoing networking is working well enough to run 'apt' 00:30:56 this is qemu 0.8.0 with kqemu 00:31:09 and I'm just running it as a user 00:31:53 hmmm 00:32:06 I can't seem to get the network to start up correctly 00:32:22 maybe the qemu-ifup script isn't properly set sudo 00:32:39 I don't have access to /dev/net/tun as a normal user 00:36:30 SWPadnos_ has joined #emc 00:41:06 I don't seem to have any 'qemu-ifup' 00:42:26 /etc/qemu-ifup 00:42:50 jmkasunich has joined #emc 00:43:04 hey there jmk 00:43:36 hi 00:43:37 nope, no qemu-ifup under /etc 00:43:39 * jepler shrugs 00:43:44 it works for me! 00:43:53 bet I missed alex... 00:44:05 odd - I'll see if BDI works, it didn't work with puppy 00:44:32 yep 00:46:57 BDI does seem to like it when I give qemu 1G of RAM to play with 00:47:00 getting reliable, portable, high-resolution time measurements is a pain in the ass 00:47:15 bdi 4.38 seems to run OK, but slowly 00:47:21 maybe I should give it more RAM too 00:47:23 yes. I'd just use the RTLinux or RTAI functions, and leave it at that 00:47:37 if they're 55ms resolution, then so be it 00:48:05 if I base overrun detection on that, some users will get false overrun errors 00:48:31 there should be a timer_resolution function, and you can disable reporting if it's too coarse 00:48:47 if there is one, I haven't found it 00:48:49 heh 00:50:14 right now I'm inclined to tag that particular issue "defer until 2.1" 00:50:57 that sounds good to me 00:51:32 RTPAI needs good time measurement - that is fundamental to RT code 00:51:46 there seems to be no quickie fix, so... 00:53:08 its unfortunate, but the evolution of the PC seems to be moving away from RT capabilities 00:53:32 high throughput, high latency seems to be the mantra 00:53:48 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 granted, this time around the hardware can be an order of magnitude cheaper... 00:54:20 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 Grex, M5i20, et al... 00:58:32 Was there a purpose for puppy or just proof of concept thing? 00:58:58 I think it's supposed to be a small, lightweight replacement for BDI 00:58:59 probably a little of both 00:59:11 and a proof of concept 00:59:18 for one there was no ready-to-go emc2 distro 00:59:52 i really dont know how you can fill up a CD and not have room for dev tools.. 01:00:21 KDE helps 01:00:38 many of the devtools are there, they just aren't installed by default 01:00:58 wow - that is a very slow installation under qemu 01:01:07 SWPadnos: yeah, I think it took hours 01:01:18 (1.5GHz host CPU here) 01:01:23 the file copy progress bar is only like 1/30th done now 01:01:37 1.8GHz here - I don't think qemu uses SMP 01:01:51 I found that if I change to a different desktop, qemu just stops, but if I iconify it keeps running. 01:01:56 and a fast SATA drive as well 01:02:02 odd 01:02:38 it still seems to run here (according to top on a different desktop) 01:03:40 interesting - top doesn't seem to know about multiple CPUs 01:07:53 ok - it does know about multiples, but displays load percentages as % of one CPU 01:08:14 unless you turn IRIX mode off (capital I) 01:09:34 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 What's IRIX mode? 01:10:18 it makes CPU load show up as a percentage of a single CPU ;) 01:13:35 mbaulfinger has joined #emc 01:27:31 back 01:31:50 hi cncuser 01:35:11 SWPadnos: my qemu says "VLAN 0 devices: user redirectory ne2000 pci macaddr=..." for "info network" 01:35:35 h,,, 01:35:36 hmmm 01:36:00 er, "redirector". 01:36:18 mine just says "0: ifname=tun0 macaddr= ... 01:36:31 (with aMAC address instead of ...) 01:37:14 the puppy install said there was no cable attached 01:37:23 qemu 0.8.0? 01:38:29 nope - 0.7.0 01:38:37 maybe that could be a problem ;) 01:38:55 Ubuntu seems to be a bit behind the times on several apps. bumer 01:38:59 bummer 01:39:50 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 maybe the default's just different 01:41:03 I may try that after the BDI install finishes 01:41:19 SWP: which bdi are you installing? 01:41:42 is rtai gpl too? 01:42:10 jepler: I'm about 99.9% sure it is 01:42:18 4.38 01:44:31 hi jeples, swpadnos, jmkasunich 01:44:38 s/es/er/ 01:44:41 ih cncuser 01:44:46 s/ih/hi/ 01:44:59 :) 01:45:03 allmost a joke ;) 01:45:08 yeah 01:45:13 almost ;) 01:45:24 yes, https://gna.org/projects/rtai/ says it's gpl 01:46:36 why did you ask? 01:47:25 jmkasunich: because licenses, and obeying them, is important 01:47:52 true 01:48:04 I thought maybe you were investigating something 01:55:45 hmm, with grep i see lgpl and gpl 01:56:34 LGPL is probably the interfaces, so that the RTOS can be used by proprietary projects 01:59:15 looks clean :) 02:06:11 I've finally got this broken emc_1.0-29 package to get past the "configure" step 02:06:42 I assume you are trying the build on the appropriate BDI? 02:07:11 "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 heh 02:07:39 what I meant was "the BDI that Paul claims it is for" ;-) 02:07:49 then yes 02:14:24 hmmm 02:14:37 SWPadnos: still awake ? 02:14:44 yee 02:14:46 yes 02:14:49 maybe 02:14:56 SWPadnos: and, hows the puppy devel going ? 02:15:02 :) 02:15:32 I've got a problem with qemu and networking, so it's not really going roght now 02:15:36 right 02:15:44 SWPadnos: no, for real, hope you havent done much, for i need to talk to barry kauler 02:15:58 nope - I haven't 02:16:03 SWPadnos: if you get the latest qemu, the networking works like a charm 02:16:05 out of the box 02:16:19 I really am having qemu network problems, so I'm waiting until those are fixed 02:16:19 the one that comes as a debian packages with sarge doesnt ;) 02:16:36 I've noticed that on Ubuntu as well (which uses Debian packages) 02:16:39 if had trouble with this tooo 02:16:51 SWPadnos: get the qemusource, and off yu go 02:16:56 yep 02:16:57 SWPadnos: its really easy 02:17:02 i may have a script :) 02:17:03 have you tried kqemu? 02:17:10 yes, it works great 02:17:16 ok- I may try that as well 02:17:21 should be a bit faster ;) 02:17:23 the guistuff is allmost 5 times faster 02:17:27 i think 02:17:50 havent noticed much when compiling though 02:18:14 I only see kqemu 0.7.2 - should the version match qemu? 02:18:21 no its ok 02:19:00 get qemu, unpack cd into dir 02:19:05 get kqemu unpack 02:19:15 compile the usual way 02:19:20 modprobe kqemu and youre in 02:19:29 shouldn't the two dirs be in the same parent, or does kqemu go under qemu? 02:19:37 under qemu 02:19:47 kqemu is a subdir that get built if it is there 02:19:54 right 02:20:31 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 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 haha 02:21:18 SWPadnos: i tried bdi in a qemu too, after a day i finished and decided never to use it again :) 02:21:21 the 0.70 version says it's using tun, but the emulated install thinks there's no cable plugged in 02:21:36 SWPadnos: just dont use the old crap :) 02:22:11 in 15 minutes or so, I'll be able to upgrade 02:22:23 SWPadnos: they wont interfere 02:22:34 SWPadnos: as, qemu installs into /usr/local 02:22:37 by tefault 02:22:40 default 02:22:45 so you can use both 02:23:11 qemu -cdrom image..... for the original debian package, /usr/local/bin/qemu for the newer one 02:23:21 skunkworks has quit 02:25:26 has bdi still dma deaktivated with the installkernel ? 02:25:36 argh - no list of configure options 02:29:15 I wonder if it automatically picks up the fact that I have 64-bit CPUs 02:29:33 there are a lot of "cast to pointer from integer of different size" warnings 02:34:12 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 SWP: what are you compiling? 02:34:19 qemu 02:34:37 ok 02:34:54 * jmkasunich wonders how emc2/hal/rtapi will do in that department 02:35:10 as long as it runs, it's OK for testing 02:35:16 I don't care if it's RT or not 02:35:21 jmkasunich: hehe, it wont do much but look nice ;) 02:35:27 I meant bunches of warnings 02:35:36 jmkasunich: no warnings 02:35:40 jmkasunich: why ? 02:35:50 on a 64-bit RTAI? 02:35:55 "cast to pointer from integer of different size" and such 02:36:06 SWPadnos: oh, i c, hmm, dunno 02:36:32 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 SWPadnos: whats the point with using a 64bit cou with emc ? :) 02:36:47 now that it comes time to start emc in qemu, it's very sluggish... 02:36:53 cause that is what he has... 02:37:09 jepler: shure, but it works :) even axis looks nice in qmeu :) 02:37:18 SWP: typedef volatile unsigned long hal_u32_t; 02:37:21 realize that in a couple of years, it'll be hard to find 32-bit systems 02:37:22 cncuser: "popimage" has been showing for about 5 minutes 02:37:26 jepler: the simulated run looks almost as nice as native 02:37:27 I suspect that is gonna be a problem 02:37:42 that should be OK - it's pointers that change 02:37:43 jepler: haha, yes :) 02:37:51 jepler: be patient :) 02:37:54 SWP: more than a couple years, but yeah, someday 02:37:56 unless ksirc ate your asterisks 02:38:25 int and long are still both 32 bits? 02:38:30 once Windows 64-bit gets more drivers, it'll happen (for better or for worse) 02:38:39 long may not be, but int still is, I think 02:38:42 SWPadnos: noway :) 02:39:03 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 surely we'll still be able to boot a 32-bit OS in even 6 years 02:39:24 many non-bleeding edge home users are on an even longer cycle 02:39:45 given that GRUB works on an AMD64 I assume that even good old 16-bit DOS is still viable 02:39:56 sure - you'll be able to buy on eBay for a while 02:40:26 true - you may have a 64-bit CPU, but the OS can still be 32 bit 02:41:47 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 or assume c99, and write uint32_t or whatever the new type is called. 02:42:10 probably 02:42:41 is gcc >= c99? 02:42:53 because gcc is the only compiler I intend to worry about 02:42:56 with RTAI 3.2, do you still need ADEOS pathces? 02:42:59 patches 02:43:09 damfino 02:43:10 even gcc3.4 has pretty good c99 support, I assume 4.x is much better still. 02:43:29 the rtai folks are doing all kind of weird stuff lately 02:43:49 should I use 3.1 (or 3.0)? 02:43:55 jepler: heh, we're still supporting boxes with gcc 2.95 02:44:16 jmkasunich: in fact, the rtai people say 2.95 is the preferred compiler 02:44:20 what are you doing, your own custom install of RTAI (as opposed to BDI?) 02:44:37 me? 02:44:47 swp: yes, you 02:45:08 jepler: still? I remember that, but lately I've heard talk of gcc 3.x on the rtai list 02:45:12 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 I very recently (days ago) heard someone from RTAI say that gcc 4.x was NOT supported, but 3.x was 02:45:47 jmkasunich: still. http://www.rtai.org/modules.php?name=FAQ&myfaq=yes&id_cat=1&categories=Installation+%26+configuration#3 02:45:49 brave man 02:45:57 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 heh - hopefully nothing will get broken by just booting and compiling 02:46:49 ok, I can buy "3 supported, 2.95 recommended" 02:47:12 although their site is hideous, and I wouldn't trust anything on it to be current 02:48:47 you don't like canary on salmon? 02:49:15 I don't like out of date, misleading, and just plain mixed up info 02:50:24 heh 02:51:48 SWPadnos_: cradek was also trying to build a real-time kernel package for ubuntu just recently .. 02:51:57 SWPadnos_: I think he got a package but hadn't yet been able to test-boot it 02:52:14 SWPadnos_: you might want to touch base with him before you spend a lot of time on it 02:52:25 oh - cool. I won't spend too much time on that 02:52:29 thanks 02:56:26 Jymmm is now known as Red70sShow 02:56:26 Red70sShow is now known as Jymmm 02:57:59 int=4 bytes, long int = 8 bytes, long long int = 8 bytes, pointer = 8 bytes 02:59:07 ok, so those typedefs will need fixed 02:59:10 double = 8 bytes, long double = 16 bytes (!) 02:59:16 float is still 4 03:00:51 SWPadnos_: I think it's still really 10 bytes but mumble alignment mumble 03:01:10 I used sizeof, not addresses of successive variables 03:01:24 printf("Sizeof(long double) = %d\n", sizeof(long double)); 03:01:51 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 hmmm - I'm not sure I believe that 03:02:13 char is still 1 03:02:37 could be a special case though 03:04:49 struct { long double a,b,c,e } foo; print sizeof(foo) 03:04:51 then 03:05:00 struct { long double a[4] } foo; print sizeof(foo) 03:05:33 nah, that doesn't prove anything 03:05:36 both will be 64 03:05:44 even if the actual size is 10 03:05:58 heh 03:06:15 be more interesting to try it with shorts and/or ints, see how they are packed 03:06:25 it might work if I do struct {long double a; char b[4]} 03:06:30 packed 03:07:54 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 can't qsort work on long double * just as well as struct { long double } * ? 03:08:25 s/role/rule/ 03:08:43 john f*** kennedy, bdi takes ages to shut down in qemu 03:08:51 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 anyway - that doesn't matter here, since emc only uses floats and doubles 03:14:49 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 heh - backup and restore are more important, but my configs directory was full of crap from testing the "new" function ;-) 03:15:48 scrathing your own itch - it's the open source way ;) 03:15:53 scratching 03:16:20 besides, delete was easier 03:16:59 this damn thing is starting to suffer from bloat 03:17:16 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 (32-bit and 64-bit boundaries, respectively) 03:17:46 makes sense 03:18:01 80 bits is a pretty silly size for a basic type 03:18:15 unfortunately, that's what the 8087 used, so we're stuck with it 03:18:19 it's a "tenbyte" 03:18:40 it was intended to hole intermediate results, with enough precision to prevent roundoff etc from accumulating 03:18:54 you should never have big arrays of them or such 03:19:01 s/hole/hold 03:19:19 too bad they provided an interface to get them out of the FPU ;) 03:19:59 you might want to evaluate expressions that are too complex for the FPU stack 03:20:28 not me, never ... 03:22:02 you might want to task-switch 03:22:09 not me, never ... 03:23:18 Telefunken has quit 03:23:47 wasn't (isn't?) there also an 80-bit BCD type in the 8087? 03:24:36 17 digits, according to wikipedia. 03:24:37 not sure about that 03:25:10 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 "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 http://www.sxlist.com/techref/language/masm/masmc06.htm 03:28:18 I bet that feature is used a lot ;-) 03:28:54 http://http.cs.berkeley.edu/~wkahan/ieee754status/754story.html 03:29:11 umm, cobol? 03:31:29 good night folks, 4:40 here, gotto sleep 03:31:35 cncuser has quit 03:31:37 goodnight 03:35:05 are the new non-x87 floating point units (sse etc) full '754 yet? 03:35:39 I don't think so, though sse3 (or nvidia/ati graphics pipes) may be 03:36:13 then again, at only 40k transistors, you could put a whole lot of 8087 on a chip these days 03:36:30 massive parallism ;-) 03:36:46 yeah, like 10000 of them on today's GPUs 03:37:11 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 that must have made it possible to complete scenes in under an hour ;) 03:37:37 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 03:37:39 (small scenes) 03:37:49 oh - cool. 03:38:01 it's a bit funny reading Apple pages talking about how Intel is better than PPC 03:38:06 yeah 03:38:12 too bad they ignred AMD 03:38:14 ignored 03:39:17 looks like 80-bit floats are absent in sse, even as temporaries. 03:39:50 they are probably 32-bits internally, and round-off/precision errors be damned 03:39:59 they are meant for graphics, after all 03:40:59 -mfpmath=sse is default for x86-64 03:41:24 in kernel, or gcc in general? 03:41:28 in gcc 03:41:33 interesting 03:41:44 "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 it's better .. 'cept when it ain't 03:42:03 right 03:42:35 I thought it was only sse3 that added floating point SIMD instructions 03:42:58 or was that sse2? 03:44:05 Both AltiVec and SSE do single precision floating point arithmetic. SSE2 also does double precision floating point arithmetic. 03:44:17 hm 03:44:34 I think it's MMX -> integer; SSE, 3DNow! -> single precision; SSE2 -> double precision; SSE3 -> profit 03:45:28 heh - that could be 03:45:46 I should look into high speed image processing aclgorithms using SSE 03:45:53 algorithms, that is 03:46:55 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. 03:47:45 what kinds of image processing algorithms? I bet stuff like small 1D convolutions are very appropriate for the vector-type operations 03:48:18 rotation, scaling, translation, cropping (easy), raw->(some format) conversion, colorspace corrections 03:48:29 probably compression as well 03:48:52 if you can speed up dcraw when processing .crw images I'll give you a shiny, crisp one dollar bill 03:49:07 ooooh - crispy ones 03:49:17 which algorithm? 03:49:49 whatever's used by the ufraw plug-in for gimp 03:50:05 I think there are several options 03:51:07 ok - two options, normal and quick (low quality) 03:51:36 well - if I improve dcraw or imagemagick, the changes will (of course) be fed back to the projects 03:52:24 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 I noticed that - I ran tests on a number of machines, using 14MPixel images (from a Kodak DCS Pro14n) 03:55:59 interestingly, it was about 3x as fast on Linux as on Windows, using the same machine 03:56:12 (processing time, not file access) 03:56:29 huh. what compiler on windows? 03:56:44 I used both Borland C and gcc under cygwin 03:56:58 I don't have any MS or Intel compilers 03:57:25 % cumulative self self total 03:57:25 time seconds seconds calls s/call s/call name 03:57:25 48.42 51.75 51.75 1 51.75 80.25 ahd_interpolate 03:57:25 26.60 80.18 28.43 13075049 0.00 0.00 cam_to_cielab 03:57:25 11.66 92.64 12.46 1 12.46 12.46 convert_to_rgb 03:57:46 step 1. inline cam_to_cielab? 03:58:01 srange... the commit message from my commit at 2214 has arrived, the one from the commit at 2009 has not 03:58:24 I still haven't gotten the TODO changes from a couple of days ago ;) 03:59:02 13 million calls to that function - looks like a good candidate ;) 03:59:10 good point - I remember one commit message disappearing entirely, but didn't recall that it was a commit to TODO 03:59:23 so thats two commits to TODO that didn't get sent to the list 04:01:58 I wonder if the root dir isn't monitored for some reason 04:02:11 maybe 04:02:13 I also don't havea commit notice for the changes Ray made to directory.map 04:02:45 or README by Alex on dec. 13 04:02:56 heh, guess thats it 04:03:41 maybe that would be a good SF support ticket 04:03:58 if they have such a thing 04:04:33 they have support tickets, but its probably an error in the way we have the commit list configured 04:04:48 could be - I was just going to check the list archives 04:04:54 in case it's a mailer thing 04:06:22 nope - not in the archives 04:06:44 I just checked in a possible fix 04:07:08 03cradek * 10CVSROOT/loginfo: commits in the root directory did not get mailed 04:07:43 does anyone have a TODO change to try? 04:08:04 Mailing emc-commit@lists.sourceforge.net... 04:08:04 Generating notification message... 04:08:04 Generating notification message... done. 04:08:16 that seems promising 04:08:22 that happened on my commit to setupconfig.tc, but not on my one to TODO 04:08:31 even now? 04:08:34 so it is detectable as soon as the commit is done (if you are looking) 04:08:43 I mean, since my change? 04:08:44 no, I haven't changed TODO or done a test commit yet 04:08:56 oh, ok 04:09:02 I probably fixed it 04:09:16 doing test now 04:09:47 worked 04:09:48