| 00:00.03 | *** join/#picogui gonkulator (~brandon@h-66-167-168-33.DNVTCO56.covad.net) |
| 00:32.40 | *** join/#picogui kidder (~s@24.65.171.188) |
| 01:11.57 | *** join/#picogui zak (~noname@aden2-35-dhcp.resnet.Colorado.EDU) |
| 03:18.11 | *** join/#picogui Soopaman (~soopaman@h24-66-55-163.wp.shawcable.net) |
| 04:02.20 | njs | ~seen scanline |
| 04:02.24 | | scanline <micah@aden2-42-dhcp.resnet.Colorado.EDU> was last seen on IRC in channel #picogui, 2d 13h 36m 57s ago, saying: 'ttyl lalo :)'. |
| 04:03.06 | gonkulator | PicoBot: seen scanline |
| 04:03.06 | PicoBot | scanline was last seen on #tacobeam 4 hours, 42 minutes and 33 seconds ago, saying: bbl [Sun Mar 30 10:33:14 2003] |
| 04:03.22 | njs | ah, good point. |
| 05:11.17 | *** join/#picogui Xentac (~jchu@amga45cyy30x9.bc.hsia.telus.net) |
| 05:11.28 | Xentac | Aden? |
| 07:39.01 | *** join/#picogui scanline (micah@aden2-42-dhcp.resnet.Colorado.EDU) |
| 07:44.46 | *** join/#picogui scanline (micah@aden2-42-dhcp.resnet.Colorado.EDU) |
| 08:51.54 | *** join/#picogui Talez (~talez@talez.arach.net.au) |
| 09:17.57 | njs | scanline: I did some fiddling with C++-without-libstdc++ tonight. The summary is, it's possible with a bit of work, and the resulting C++ overhead may be quite low. The grisly details (notes for myself) are at http://fresco.org/~njs/c++-without-stdc++ . |
| 09:43.19 | *** join/#picogui scanline (micah@aden2-42-dhcp.resnet.Colorado.EDU) [NETSPLIT VICTIM] |
| 09:43.19 | *** join/#picogui Soopaman (~soopaman@h24-66-55-163.wp.shawcable.net) [NETSPLIT VICTIM] |
| 09:43.19 | *** join/#picogui file (file@mctn1-7186.nb.aliant.net) [NETSPLIT VICTIM] |
| 09:43.37 | *** join/#picogui Dire (~Admin@100.8.33.65.cfl.rr.com) [NETSPLIT VICTIM] |
| 09:44.11 | *** join/#picogui Talez (~talez@talez.arach.net.au) [NETSPLIT VICTIM] |
| 09:44.11 | *** join/#picogui darth_mall (~silme@12-211-244-177.client.attbi.com) [NETSPLIT VICTIM] |
| 09:44.11 | *** join/#picogui lurgyman (~lurgyman@aden2-123-dhcp.resnet.Colorado.EDU) [NETSPLIT VICTIM] |
| 09:44.11 | *** join/#picogui captain_proton (~jupiter@aden2-23-dhcp.resnet.Colorado.EDU) [NETSPLIT VICTIM] |
| 09:44.11 | *** join/#picogui prot-home-sleep (~jupiter@aden2-23-dhcp.resnet.Colorado.EDU) [NETSPLIT VICTIM] |
| 09:44.12 | *** join/#picogui PicoBot (~PicoBot@ivan.client.mscd.edu) |
| 09:44.12 | *** join/#picogui jojo (jojo@infidyne.com) [NETSPLIT VICTIM] |
| 12:37.41 | *** join/#picogui Dentoid (Dentoid@TP5022-08.itn.liu.se) |
| 12:37.45 | Dentoid | scanline, are you there? |
| 12:38.28 | Dentoid | captain_proton, or you? |
| 12:38.29 | Dentoid | :) |
| 13:23.50 | lalo | there is a new release of SCons |
| 14:13.18 | *** join/#picogui gonkulator (~brandon@h-66-167-168-33.DNVTCO56.covad.net) |
| 14:13.49 | *** join/#picogui gonkey{iBook} (~brandon@h-66-167-168-33.DNVTCO56.covad.net) |
| 15:13.44 | *** join/#picogui prpplague (~JoeBob1@12.148.134.9) |
| 15:24.56 | *** join/#picogui bigthor (~bigthor@80.Red-80-32-133.pooles.rima-tde.net) |
| 15:25.07 | bigthor | hi |
| 15:42.05 | *** join/#picogui zak (~noname@aden2-35-dhcp.resnet.Colorado.EDU) |
| 15:45.37 | *** join/#picogui Dentoid (dento_3000@h242n1fls35o814.telia.com) |
| 16:08.59 | Xentac | hey kergoth |
| 16:09.09 | kergoth | hey |
| 16:09.35 | Xentac | do you ever plan on using the openzaurus-announce list anymore? ;) |
| 16:09.44 | kergoth | I always forget it exists |
| 16:09.45 | kergoth | :) |
| 16:09.49 | Xentac | hehehe |
| 16:10.10 | Xentac | just curious, cause I was tired of all the crap on the -users list... so I decided to unsubscribe |
| 16:12.04 | kergoth | yeah, its all end user blabber for the most part |
| 16:12.11 | Xentac | exactly |
| 16:12.25 | Xentac | I find myself smacking my forehead all too often |
| 16:12.37 | Xentac | and keeping up with the traffic on that list is annoying |
| 16:13.05 | Xentac | but that means I also miss all the tips about problems that other people have already run in to |
| 16:13.05 | kergoth | you try out 3.2 yet? the user response on it is better than the response on any release to date |
| 16:13.23 | Xentac | not yet... I was waiting for any major problems |
| 16:13.45 | Xentac | I'll probably switch over sometime after this week |
| 16:13.54 | Xentac | this is the last week of classes... and I have 4 things due on friday |
| 16:14.56 | kergoth | from what i can tell, there arent any (major problems that is) |
| 16:15.09 | kergoth | couple minor ones, most of which are already fixed in cvs and/or bk |
| 16:15.34 | Xentac | not saying I don't trust you or anything... but I'm still a little wary... I remember last time I tried to do an upgrade right away |
| 16:15.53 | Xentac | it was the dreaded, "ok, no one update from the feeds for a while", time |
| 16:16.30 | kergoth | ahh yeah |
| 16:16.35 | kergoth | unstable can be.. unstable |
| 16:16.45 | Xentac | yup |
| 16:17.10 | Xentac | but apart from school taking up my time right now, I'm so going to upgrade to 3.2 |
| 16:17.37 | Xentac | it'll probably be a clean new install... which means that I have to seperate everything the way I liked it again |
| 16:17.59 | kergoth | flashing is recommended. i cant guarantee the sanity of the ipkg upgrade path due to ipkg brokenness |
| 16:18.08 | Xentac | yeah, that's what I read |
| 16:18.17 | Xentac | I don't mind that... my zaurus needs cleaning up anyway ;o) |
| 16:18.32 | kergoth | heheh |
| 16:22.12 | Xentac | kergoth: I know you probably hear this a lot, but thanks a lot for your work on OZ... I know you're probably stressed out about it quite a bit, but I for one, appreciate it |
| 16:23.26 | *** join/#picogui merlin262 (~andrew@utdgw5-2.utdallas.edu) |
| 17:07.57 | *** join/#picogui gonk{work} (~Pineapple@ivan.client.mscd.edu) |
| 17:16.21 | *** join/#picogui gonkulator (~brandon@Metro0276.client.mscd.edu) |
| 17:21.28 | *** join/#picogui Tomun (~alan@whalefood.demon.co.uk) |
| 17:36.46 | *** part/#picogui Tomun (~alan@whalefood.demon.co.uk) |
| 18:00.08 | *** join/#picogui Oktal (~mat@pc1-rdng3-5-cust199.winn.cable.ntl.com) |
| 18:45.43 | *** join/#picogui DevGirl (maisa@200.203.12.232) |
| 18:52.24 | *** join/#picogui DevGirl (maisa@200.203.12.232) |
| 19:10.20 | *** join/#picogui gonkulator (~brandon@Metro0276.client.mscd.edu) |
| 19:12.12 | gonkulator | zak: hi |
| 19:24.28 | gonkulator | hi zak |
| 19:25.09 | gonkulator | hi DevGirl |
| 19:27.00 | zak | hi gonkulator |
| 19:27.10 | gonkulator | hi zak |
| 19:27.40 | zak | hi gonk{work} |
| 19:30.21 | gonkulator | there, now all of scanline's tabs are blue :) |
| 19:31.04 | zak | now if only he'd wake up |
| 19:31.43 | gonkulator | yeah |
| 19:31.52 | gonkulator | then he will be really frustrated with me... |
| 19:32.14 | zak | lol |
| 19:32.32 | gonkulator | oh well |
| 19:32.36 | gonkulator | I'll lie low for a while |
| 19:33.04 | gonkulator | howdy prpplague |
| 19:46.49 | prpplague | gonkulator: howdy |
| 19:57.48 | *** join/#picogui file (file@mctn1-6782.nb.aliant.net) |
| 20:45.24 | *** join/#picogui Oktal (~mat@pc1-rdng3-5-cust199.winn.cable.ntl.com) |
| 21:26.29 | lalo | hi scanline |
| 21:26.38 | scanline | hi lalo |
| 21:27.07 | lalo | the idea of using C++ as "C with Exceptions" is interesting |
| 21:27.22 | lalo | how much would that hinder people wanting to use other languages? |
| 21:27.48 | scanline | well, we'd have to make all functions that we'd want to be usable from other languages declared as 'extern "C"' |
| 21:28.17 | lalo | and not use exceptions? that would make the point quite moot |
| 21:28.18 | scanline | I'm not sure what happens if for example an exception is thrown in an extern "C" function though |
| 21:28.41 | captain_proton | probably bad things |
| 21:29.05 | scanline | The main thing that was keeping me from considering C++ is the size, but most of that comes from libstdc++... and njs experimented with compiling C++ without that |
| 21:30.40 | scanline | C++ inlines could also be handy as a replacement for macros |
| 21:30.58 | lalo | inlines are cool. |
| 21:31.06 | scanline | especially for things like the reconfigurable vector math... we'd usually want that to be inlined, but to save space it could be disabled |
| 21:31.34 | captain_proton | inlined vector stuff can't compete with template expressions though |
| 21:31.37 | lalo | vector math? |
| 21:32.23 | scanline | lalo: pg2 should formalize all the coordinate and rectangle math into something based on vectors, so it's easy to switch from 2D to 3D and from int to float at compile time |
| 21:34.15 | lalo | but that won't be done by libOm... and the point is that individual Om "methods" can be written in either C or C++ |
| 21:34.30 | lalo | so the methods that do this can go C++ |
| 21:34.44 | scanline | err, nods |
| 21:35.12 | lalo | dunno, C++ sounds... redundant :-P |
| 21:35.25 | lalo | if we could use exceptions, that would be cool |
| 21:35.35 | scanline | yeah, mainly depends on exceptions |
| 21:35.37 | lalo | but it looks like we can't |
| 21:36.03 | lalo | OTOH |
| 21:36.36 | scanline | hmm |
| 21:36.41 | scanline | interesting |
| 21:36.42 | lalo | you could claim Om is a "protocol" (or a set of conventions) and easily write a libOm++ |
| 21:36.46 | lalo | what happens? |
| 21:37.03 | scanline | I compiled the C++ function with g++ and the C main() with gcc |
| 21:37.17 | scanline | then I tried using gcc to link them, but it couldn't find a few symbols |
| 21:37.29 | scanline | __cxa_allocate_exception, __cxa_throw, and __gxx_personality_v0 |
| 21:37.45 | kergoth | gcc3? |
| 21:37.51 | scanline | so I try with C++, and I get "Aborted", which is what should happen in the case of an unhandled exception |
| 21:37.51 | lalo | I suppose you have to link them with g++ |
| 21:38.03 | scanline | kergoth: 3.2.2 |
| 21:38.09 | kergoth | scanline: -lsupc++ |
| 21:38.17 | scanline | ah |
| 21:38.23 | kergoth | unless you're using stdc++ stuff, in which case -lstdc++ |
| 21:38.24 | scanline | right, njs mentioned that in his little document |
| 21:38.27 | kergoth | :) |
| 21:38.30 | lalo | there is probably a way to catch exceptions with C, but it's probably compiler-dependent |
| 21:38.46 | scanline | hmm |
| 21:38.52 | scanline | lalo: yeah |
| 21:38.54 | scanline | lalo: or... |
| 21:39.23 | scanline | lalo: how about libOm is in C++, and can either catch C++ exceptions or exceptions triggered through some C-friendly way? |
| 21:39.54 | scanline | still redundancy... |
| 21:39.55 | lalo | that would miss the point of making it easier to write. |
| 21:40.00 | scanline | yeah |
| 21:40.15 | lalo | this time I go with RMS... let's use C, we already know it |
| 21:40.39 | scanline | C is good.. but it's good to explore other options |
| 21:40.54 | scanline | suppose we should think about how to actually handle exceptions in C |
| 21:41.01 | lalo | yes |
| 21:41.05 | lalo | it's an open issue |
| 21:41.11 | scanline | it would be nice to have something cleaner than what pg1 uses, and that would provide stack backtraces |
| 21:41.32 | scanline | the error tracing that can be optionally built into errorcheck; sorta-kinda does a backtrace |
| 21:41.44 | lalo | I thought I would study what Python uses, but what Python uses doesn't trace into C |
| 21:41.45 | scanline | but not in a way that's really usable |
| 21:42.27 | scanline | AFAIK python sets the exception in a global variable, then returns NULL or some other error code that the caller has to check for |
| 21:42.41 | scanline | I'd really like to either avoid or automate anything the caller has to do |
| 21:43.46 | scanline | and then there's the whole issue of how to clean up properly when an exception is thrown... |
| 21:43.53 | lalo | I think I scratched on a good model - if the function returns anything, it's an exception, and real return values are in out arguments |
| 21:43.59 | scanline | the errorcheck; stuff didn't handle that, so you'd have to write something custom to clean up |
| 21:44.14 | lalo | because from using python I discovered sometimes a function wants to return more than one value |
| 21:44.29 | lalo | but of course exeptions shouldn't be strings |
| 21:44.48 | scanline | I think exceptions should be Om objects |
| 21:44.54 | scanline | they'll need network transparency |
| 21:45.22 | lalo | yes, that's what sounds right |
| 21:46.48 | scanline | so you could have a convention of returning NULL for success, and some sort of exception object otherwise- and the caller would be responsible for cleaning up in the case of an exception, and tagging the exception with a signature for that function so we can backtrace |
| 21:47.13 | scanline | easiest way to automate that would probably be a macro you wrap function calls in |
| 21:47.51 | lalo | perhaps more than one macro |
| 21:48.16 | lalo | for the common case where you don't want to catch any exceptions, use a macro that does something like |
| 21:48.43 | lalo | e = call_func(); if (e) {e.tag(); return e} |
| 21:49.04 | lalo | (pardon my programmatic license in pretending e has methods) |
| 21:49.19 | scanline | np : |
| 21:49.20 | scanline | :) |
| 21:49.54 | scanline | so then you'd also want one that doesn't return from the calling function, just tags the exception and returns it from the macro |
| 21:50.05 | lalo | yes |
| 21:50.25 | scanline | you could use that to do all cleanup manually, or to catch the exception |
| 21:50.59 | scanline | it would work... but pretty messy compared to C++'s exceptions and destructors |
| 21:51.27 | lalo | if exceptions are nicely self_contained, cleanup could be pretty much reduced to freeing the exception object |
| 21:52.33 | scanline | I'm mainly concerned about, for example, exceptions thrown in a function after that function allocates memory but before it puts that memory somewhere it can be referenced |
| 21:53.05 | lalo | hmm |
| 21:53.24 | lalo | yes |
| 21:53.39 | lalo | my experience in C is not big enough to see a way out of this |
| 21:54.21 | scanline | C++ can clean up statically allocated objects automatically, and you can use try{}finally to clean up the rest |
| 21:54.31 | scanline | it's still something you have to worry about whether in C or C++ |
| 21:56.03 | lalo | actually |
| 21:56.59 | lalo | the only place this is a problem is in a macro that possibly automatically-returns in case of error |
| 21:57.18 | lalo | IMHO the "C Way" would be to dictate you can't use this macro if you have data that must be freed |
| 21:57.51 | lalo | in the function that *raises* the exception, np, you can free before raising |
| 21:57.57 | lalo | you probably already have an if anyway |
| 21:58.05 | scanline | so this would be pretty much how pg1 handles exceptions, but the exceptions would be full objects rather than just ints, and they could be tagged to provide backtraces |
| 21:58.45 | lalo | well |
| 21:59.06 | lalo | before I dragged you in, I was already planning to draw inspiration for Om from pg1 ;-) |
| 21:59.23 | scanline | hehe |
| 21:59.28 | lalo | it's a quite clean pseudo-object-model without the bloat of glib's |
| 21:59.38 | scanline | it's annoying to have to use a macro for every call, but I don't think there's any way around that in C |
| 21:59.56 | scanline | you mean the object model thingy pg1 uses for widgets? |
| 22:00.03 | lalo | yes |
| 22:00.14 | scanline | pg1 has completely separate object models for widgets, video drivers, and input drivers :-/ |
| 22:01.09 | scanline | eep, I need to get to class |
| 22:01.09 | scanline | bbl |
| 22:02.13 | lalo | cya |
| 22:39.15 | kergoth | mondays suck!!!@!#%#^! |
| 22:39.38 | gonkulator | kergoth: whats going wrong for you? |
| 22:40.07 | kergoth | machines failing for no apparent reason |
| 22:40.10 | kergoth | flashed my c700 with a 5500 rom |
| 22:40.26 | kergoth | c700 fails to start opie, instead hangs the unit |
| 22:40.29 | kergoth | spilled coffee on my desk |
| 22:40.33 | kergoth | headache |
| 22:40.48 | gonkulator | damn |
| 22:41.34 | kergoth | are you winning? |
| 22:41.59 | gonkulator | not yet... |
| 22:42.22 | gonkulator | soon I hope |
| 22:57.06 | scanline | lalo: here's another option -> http://www.halfbakery.com/idea/C_20exception_20handling_20macros |
| 22:58.11 | scanline | http://users.footprints.net/~kaz/kazlib.html |
| 22:58.41 | captain_proton | scanline: you need to come retrieve these brownies |
| 22:58.46 | scanline | ahh |
| 22:58.51 | scanline | right now? |
| 22:59.00 | captain_proton | yes |
| 22:59.02 | captain_proton | right now |
| 22:59.07 | scanline | mmkay |
| 23:00.37 | lalo | what is halfbakery.com? |
| 23:00.59 | scanline | something that came up when googleing? |
| 23:02.29 | scanline | looks like they use setjmp/longjmp and a stack |
| 23:03.04 | lalo | O.O |
| 23:03.13 | scanline | http://users.footprints.net/~kaz/kazlib_doc/node186.html |
| 23:03.58 | scanline | Kazlib also has a cute-looking dictionary component |
| 23:06.12 | lalo | eep |
| 23:06.27 | lalo | something allocated too much memory and locked my machine |
| 23:06.40 | scanline | killall -9 mozilla-bin |
| 23:06.41 | scanline | :) |
| 23:06.46 | lalo | hehehe |
| 23:08.49 | lalo | specially if we hope to have backtraces |
| 23:21.11 | scanline | lalo: just posted a sumamry of this exception stuff to pgui-devel |
| 23:21.24 | scanline | slow mailing list server... |
| 23:22.45 | lalo | it's sf ;-) |
| 23:23.54 | scanline | ah, there it is |
| 23:45.48 | *** join/#picogui njs` (~njs@vindaloo.ICSI.Berkeley.EDU) |