| 00:00.49 | *** join/#picogui Xent (jchu@amga45cyy30x9.bc.hsia.telus.net) |
| 00:04.33 | *** join/#picogui Xent (jchu@amga45cyy30x9.bc.hsia.telus.net) |
| 01:12.37 | *** join/#picogui kidder (~s@h24-65-171-188.gv.shawcable.net) |
| 01:32.04 | njs` | scanline: hey, you've read http://freetype.sourceforge.net/david/reliable-c.html , right? |
| 01:47.42 | scanline | njs`: hmm.. I will have shortly :) |
| 01:48.04 | lalo | njs`: any insights on exceptions? |
| 01:53.06 | njs` | well, it's an analysis of the issues there :-) |
| 01:53.27 | njs` | (and kazlib is actually cited as one implementation of the approach he finds best) |
| 01:53.39 | scanline | njs`: this is exactly the sort of paper I needed, thanks |
| 01:54.03 | njs` | scanline: cool. It's a great paper, that I read long enough ago that I'd forgotten other people might not have seen it :-) |
| 01:54.36 | njs` | is it really that much harder to wrap a C++ library than a C library when it comes to exceptions? |
| 01:54.45 | njs` | I've never actually written wrappers, I'm actually curious. |
| 01:55.02 | scanline | njs`: if you're doing it by hand, you'd have to have C++ code to handle exceptions |
| 01:55.14 | scanline | I know a lot of common wrappers like SWIG handle exceptions fine |
| 01:55.25 | njs` | I mean, presumably when you make a python wrapper for a C library, your wrapper has to convert PG_BAD_PARAM to a pg.BadParameter exception anyway? |
| 01:55.41 | scanline | erg.. |
| 01:55.54 | scanline | Brede keeps looking over my shoulder... |
| 01:56.36 | scanline | njs`: yes, for python it shouldn't really matter either way |
| 01:56.46 | scanline | but it's annoying when trying to write C code that uses a C++ library |
| 01:56.51 | lalo | thing is |
| 01:56.59 | lalo | it's easy to write C++ code that uses a C library |
| 01:57.09 | njs` | well, you're either going to have a C wrapper for C++ or a C++ wrapper for C :-) |
| 01:57.10 | lalo | but it's a PITA to write C code that uses a C++ library |
| 01:57.26 | lalo | which kind of misses the point of language-neutrality |
| 01:57.30 | njs` | (or multiple implementations, which really doesn't seem like a bad idea to me) |
| 01:57.46 | lalo | I think in the long term multiple implementations are the way to go |
| 01:58.04 | lalo | but starting with C sounds right to me |
| 01:58.32 | njs` | You could also have people writing pg apps use C-with-exceptions too, though I doubt that'd go over terribly well :-) |
| 01:58.58 | scanline | well, libOm needs to be language neutral |
| 01:59.07 | scanline | I do like the idea of starting with C but then making separate reimplementations |
| 01:59.38 | scanline | In python for example, a native libOm might be less complicated than a wrapper around the C libOm :) |
| 02:00.21 | njs` | lalo: it's also a PITA to write C code that pretends to do exceptions :-) |
| 02:04.09 | scanline | hmm |
| 02:04.28 | scanline | The decision of the initial language to write libOm in should depend on what we intend to write most of picogui in |
| 02:04.50 | scanline | if we're going to commit to having separate implementations of a centrally defined protocol, that might as well be C++ |
| 02:06.02 | scanline | yep |
| 02:06.51 | scanline | Most of C++ is overkill for this IMHO, since we'll have a custom object model.. but exceptions might make it worth it |
| 02:07.30 | njs` | nod |
| 02:08.13 | njs` | well, you know I'm not totally convinced on the object model either :-), but that's a somewhat separate issue |
| 02:08.52 | scanline | another bonus for using C++ that I don't think we discussed yet- even though Om's object model is mostly orthogonal to C++ classes, classes could be used to organize code in a way that makes it easier to reuse in other projects |
| 02:09.36 | scanline | there are several parts of picogui that I've wanted to reuse in other projects, but didn't because it would have been to annoying |
| 02:09.42 | njs` | yeah. namespaces are desperately lacking from C. |
| 02:12.40 | scanline | s/to/too/ |
| 03:10.31 | *** join/#picogui scanline (micah@aden2-42-dhcp.resnet.Colorado.EDU) |
| 03:11.17 | lalo | I hate IE! I hate javascript! |
| 03:20.32 | *** join/#picogui gonkulator (~brandon@h-66-167-168-33.DNVTCO56.covad.net) |
| 03:36.39 | *** join/#picogui lurgyman (DanKuester@aden2-123-dhcp.resnet.Colorado.EDU) |
| 03:42.56 | lalo[out] | well |
| 03:43.00 | lalo[out] | good night y'all |
| 03:45.32 | scanline | g'night lalo |
| 03:50.05 | *** join/#picogui merlin262 (~andrew@crtntx1-ar1-4-60-243-225.crtntx1.dsl-verizon.net) |
| 03:50.52 | merlin262 | hey scanline |
| 03:51.01 | merlin262 | read the E-mail about C/C++ |
| 03:51.12 | scanline | hi |
| 03:51.28 | merlin262 | have you thought about the binary compatibility issues with C++? |
| 03:51.54 | scanline | yes |
| 03:52.03 | merlin262 | that's the #1 reason why I wouldn't use it |
| 03:52.12 | merlin262 | but, things are definately getting better on that front |
| 03:52.15 | scanline | it shouldn't be any more of an issue than exceptions though |
| 03:52.26 | merlin262 | hmmm |
| 03:52.28 | scanline | we're not using the STL.. so there's just gcc2 vs gcc3 types of issues |
| 03:52.42 | merlin262 | What, I think the best solution would be, is |
| 03:52.51 | merlin262 | writing pgserver in C++, so you get those benifits |
| 03:52.56 | merlin262 | but, keeping the client libs in C |
| 03:53.00 | scanline | if you have all the server components and a C++ libOm compiled into one binary, the only compatibility-breaking point is between libOm and the client |
| 03:53.19 | scanline | merlin262: it's looking like the client libs will be done the same way they are now, with a separate lib for each language |
| 03:53.27 | merlin262 | hmmm.. |
| 03:53.28 | merlin262 | good |
| 03:53.41 | scanline | so you could statically link pgserver if you're worried about compatibility |
| 03:53.44 | merlin262 | Yea |
| 03:53.49 | scanline | and then you only have C++ binary compatibility issues on the client if the client is in C++ |
| 03:54.04 | merlin262 | that's about what I was thinkiing |
| 03:55.05 | merlin262 | I think C++ would be a good choice for writing pgserver |
| 03:55.06 | merlin262 | potentially |
| 03:55.27 | merlin262 | that's my $0.02 |
| 03:56.32 | scanline | well, exceptions and inlines would be handy |
| 03:56.43 | scanline | we need exceptions in any case, and c++ has a nice built in implementation of them |
| 03:57.18 | merlin262 | you could use signals in C, couldn't you? |
| 03:57.21 | merlin262 | it'd be nasty |
| 03:58.42 | scanline | signals? |
| 03:58.43 | scanline | no... |
| 03:59.13 | scanline | the two real ways are to pass back exceptions using return codes and some macros, or using setjmp/longjmp |
| 03:59.22 | scanline | pg1 uses the return value method |
| 04:00.40 | merlin262 | hehe, I saw an app that used signals before |
| 04:00.44 | merlin262 | I forget what it was |
| 04:01.02 | merlin262 | Return codes are a nice and friendly standby |
| 04:10.02 | scanline | you should take a look at that paper I posted a link to on pgui-devel |
| 04:10.15 | scanline | njs always comes up with links to good papers :) |
| 04:10.37 | gonkulator | http://freetype.sourceforge.net/david/reliable-c.html#exceptional |
| 04:10.57 | kergoth | eh, did you actually proppose the use of signals as an exception method? |
| 04:10.59 | kergoth | you sick bastard |
| 04:11.38 | scanline | can you access the main program's stack from within a signal handler? |
| 04:12.10 | captain_proton | i'm sure you can |
| 04:12.28 | scanline | not to mention not being portable to non-unixen |
| 04:15.04 | kergoth | ew |
| 04:15.21 | kergoth | ~fishslap gonkulator |
| 04:15.22 | | ACTION slaps gonkulator up side the head with a wet fish. |
| 04:15.32 | scanline | gonkulator: there's a reason you don't code in pgserver :) |
| 04:16.08 | merlin262 | Note: said proposal was only joking |
| 04:18.49 | gonkulator | how does OpenGL do errors? |
| 04:19.57 | scanline | gonkulator: OpenGL sets a global error flag if there was an error |
| 04:20.01 | kergoth | oo loreena mckennit, who's name i can never spell |
| 04:20.02 | scanline | a lot like errno in POSIX |
| 04:20.05 | kergoth | i love her music |
| 04:20.09 | scanline | kergoth: indeed |
| 04:20.17 | kergoth | so calming |
| 04:20.34 | scanline | I get such a warm fuzzy feeling having my coffee pot balanced on top of my full tower machione |
| 04:20.37 | scanline | er, machine |
| 04:20.43 | kergoth | in fact, i have a print on canvas of a painting that was based on the same poem that song was baed on |
| 04:25.06 | merlin262 | bash, that's the program |
| 05:24.39 | njs | heh |
| 05:24.51 | njs | I was actually wondering last night what happened if you threw from a signal handler |
| 05:25.39 | njs | I need to find someone who knows about such thinks and poke them until they explain how signals work at the OS level. |
| 05:26.32 | njs | and reading the discussion in backlog, I'm mildly astonished at how apropos a paper I managed to suggest :-) |
| 06:27.20 | scanline | njs: signal handlers can do a lot of strange things... usually to be on the safe side I have most signal handlers set flags that cause the actual signal handling to happen later |
| 07:24.58 | njs | scanline: that's the officially recommended thing, though I _know_ a lot more than that is possible. I'm really curious about _what_ they're doing, though -- e.g., _why_ are certain things fragile? |
| 07:26.09 | scanline | worth looking into |
| 07:58.51 | *** join/#picogui Dire (Admin@199.223.94.110) |
| 07:58.56 | Dire | wee |
| 07:59.18 | zak | e |
| 07:59.20 | zak | wee? |
| 07:59.49 | Dire | wee |
| 11:47.57 | *** join/#picogui file (file@mctn1-7597.nb.aliant.net) |
| 13:03.47 | *** join/#picogui Zensunni (~curtis@203.111.137.12) |
| 13:03.50 | Zensunni | morning |
| 13:04.45 | Zensunni | anyone awake? |
| 13:05.00 | Zensunni | I came in here a few months back looking to port PicoGUI to my works very lightweight platform.... |
| 13:05.13 | Zensunni | figured I'd check it over again |
| 13:08.24 | scanline | hi |
| 13:08.46 | Zensunni | hi |
| 13:08.52 | Zensunni | wow... someone IS awake. (o8 |
| 13:10.43 | scanline | :) |
| 13:11.20 | Zensunni | am just looking at the footprint of PicoGUI.... |
| 13:11.23 | Zensunni | might be too big :( |
| 13:11.49 | scanline | ah |
| 13:12.04 | scanline | there are areas where you could definitely trim it, but how big do you need? |
| 13:12.06 | Zensunni | it's a _really_ small system... 128K ROM, 256K RAM.... |
| 13:12.11 | scanline | ah |
| 13:12.25 | scanline | yeah, picogui is probably too big for that in its current state |
| 13:12.38 | Zensunni | fortunately, I convinced them to let me include a "compressed" program format into the loader... |
| 13:12.45 | scanline | and until it is reorganized it would be hard to use without an OS |
| 13:12.59 | Zensunni | we have an OS |
| 13:13.05 | scanline | ah, ok |
| 13:13.45 | Zensunni | so, we have tasks, and message queues, etc... |
| 13:14.17 | Zensunni | and iirc, there's already a driver for the LCD we most frequently use.... |
| 13:14.42 | scanline | neat |
| 13:15.02 | Zensunni | the new site looks very bright..... very neat.... |
| 13:15.13 | scanline | :) |
| 13:16.14 | Zensunni | I thought of it again because a recently suggested app would work very well with drop-lists and similar widgets... |
| 13:16.20 | Zensunni | especially with a touch screen |
| 13:17.21 | Zensunni | so... this reorg you mention..... is it progressing painfuly slowly? |
| 13:17.38 | scanline | it hasn't started |
| 13:17.49 | scanline | the plan is to get 1.0 released first |
| 13:17.57 | Zensunni | that slow, huh? :) |
| 13:18.02 | Zensunni | ah... |
| 13:18.08 | Zensunni | silly me, I thought 1.0 WAS out... |
| 13:18.26 | scanline | well, we're referring to the current code as the 1.0 architecture, but the version's only at 0.45 right now |
| 13:18.38 | Zensunni | ah |
| 13:18.39 | scanline | there's a pretty concrete plan on the wiki showing what's left for 1.0 |
| 13:19.03 | scanline | after that we'll mainly only do bugfixes on the current code, and we'll start almost from scratch on 2.0 |
| 13:19.29 | Zensunni | ok |
| 13:19.43 | Zensunni | you mentioned something about large potential for trimming? |
| 13:20.20 | scanline | yeah, the first thing that comes to mind is making the build system smart enough to remove video functions that aren't used because all other video drivers override them |
| 13:20.55 | Zensunni | interesting... |
| 13:21.22 | Zensunni | you mean all selected drivers? |
| 13:21.27 | scanline | yes |
| 13:22.32 | Zensunni | hmm |
| 13:22.58 | scanline | for example, the default video base library has to implement every primtive for compatibility's sake |
| 13:22.59 | Zensunni | this will be a static link.... so I can make the linker recursively search for the functions.... |
| 13:23.07 | Zensunni | thought, I can see it being a big advantage for others :) |
| 13:23.18 | scanline | if you're only using one other video base library and it overrides a primitive, the default one doesn't need to be included but currently it is |
| 13:23.34 | scanline | the linker isn't smart enough to do it |
| 13:23.36 | Zensunni | yuh |
| 13:23.46 | scanline | the binding isn't done with normal calls, but via function pointers |
| 13:23.46 | Zensunni | hmm |
| 13:23.53 | scanline | that's why this optimization hasn't been done yet |
| 13:23.54 | Zensunni | gotcha |
| 13:24.28 | Zensunni | hmm |
| 13:24.55 | Zensunni | well, looks like someone is semi-actively keeping the sed133x driver alive..... |
| 13:25.18 | Zensunni | assuming you were using a single video driver, there would be a HEAP of optimisations, I take it.... |
| 13:25.23 | scanline | yep |
| 13:26.12 | Zensunni | my head is buzzing with the pre-conception of some #def system for building function tables.... |
| 13:26.57 | scanline | actually, the video system doesn't use any macros |
| 13:26.58 | Zensunni | so each driver references the primitives it doesn't support, implicity requiring they be linked in... |
| 13:27.08 | scanline | ah |
| 13:27.16 | scanline | well, two ways had come to my mind... |
| 13:27.24 | Zensunni | hmm? |
| 13:27.43 | scanline | 1. you have part of the build system scan the drivers and determine what's necessary, and stripping the rest out of defaultvbl |
| 13:28.32 | scanline | 2. each video driver that's in use has a separate file listing the primitives it's implemented. That file from every driver is included into a mess of macros that enables the defaultvbl primitives selectively |
| 13:29.09 | Zensunni | yeah... could do... |
| 13:30.41 | Zensunni | ok... so... assuming I hack the video driver code cleaner.... |
| 13:30.42 | Zensunni | what next? |
| 13:31.24 | scanline | next I'd try sorting the .o files by size and trying to figure out what's taking up the most space in the bigest one |
| 13:31.26 | scanline | er, biggest |
| 13:31.38 | scanline | this is all assuming you've already tweaked the menuconfig options to death :) |
| 13:31.56 | Zensunni | (o8 |
| 13:32.21 | scanline | you can remove almost all text from the binary that way, and remove unused widgets |
| 13:32.45 | Zensunni | yer |
| 13:33.40 | Zensunni | of course, this display allows you to play some funky overlay tricks.... |
| 13:34.14 | Zensunni | it has 3 "planes".... (A.B)+C ..... so you can mask out A with B, and put a temporary display in C... |
| 13:34.29 | Zensunni | saving you from redrawing stuff, for instance |
| 13:34.37 | scanline | that's cool |
| 13:34.46 | Zensunni | but that's not really a very portable feature... |
| 13:35.00 | scanline | you could use it in picogui, but it would be a nasty hack |
| 13:35.01 | Zensunni | nor something you can take advantage of genericly... |
| 13:35.12 | Zensunni | yuh |
| 13:36.34 | Zensunni | see... the way we're going, I'm almost developing a 2plane GUI anyway.... |
| 13:36.47 | Zensunni | I'd rather take someone elses better planned system and work it down to our needs |
| 13:37.42 | Zensunni | ah... the network layer.... |
| 13:38.46 | Zensunni | if you're handling your networking properly, you'll have a decent chunk of code involved in packetising, etc...? |
| 13:38.54 | scanline | there's not a lot in the network layer that can be removed |
| 13:39.22 | scanline | the network request code is shared by the theme and widget template code |
| 13:39.26 | Zensunni | well, we won't have any networking..... comms will be via message queues... |
| 13:39.52 | scanline | yeah, but you'll still need to handle requests sent via those queues |
| 13:39.53 | Zensunni | or pipes |
| 13:40.02 | Zensunni | sure |
| 13:40.05 | scanline | you could strip out the TCP/IP-specific code, but not the request packing/unpacking |
| 13:40.20 | Zensunni | yup |
| 13:41.27 | Zensunni | am just digging through the CVS as we converse |
| 13:44.01 | Zensunni | so, where is the actual network code? |
| 13:45.50 | scanline | pgserver/net/ |
| 13:46.20 | scanline | I think all the TCP/IP stuff is in request.c |
| 13:46.32 | Zensunni | ah.. the one file I _didn't_ look in :) |
| 14:00.05 | Zensunni | meanwhile.... it's almost midnight here... |
| 14:00.29 | Zensunni | and I've a nasty day of beating RF transcievers into submission ahead of me.... |
| 14:00.45 | Zensunni | so.... thanks for your help.... I'll let you know if I get anywhere with it all :) |
| 14:11.53 | *** join/#picogui laodamas (christop@bakr23-130.resnet.colorado.edu) |
| 14:22.56 | *** join/#picogui lurgyman (~lurgyman@aden2-123-dhcp.resnet.Colorado.EDU) |
| 14:40.43 | *** part/#picogui gonkulator (~brandon@h-66-167-168-33.DNVTCO56.covad.net) |
| 14:45.13 | *** join/#picogui gonkulator (~brandon@h-66-167-168-33.DNVTCO56.covad.net) |
| 15:00.01 | gonkulator | wow |
| 15:00.07 | gonkulator | enlightenment just went 1.0 |
| 15:00.09 | gonkulator | amazing |
| 15:00.13 | gonkulator | PicoBot: seen scanline |
| 15:00.13 | PicoBot | scanline was last seen on #tacobeam 51 minutes and 44 seconds ago, saying: captain_proton: if you still have that picogui april 1 screenshot, could you send it back to me? I for some reason thought I had uploaded it already and deleted it... [Tue Apr 1 01:21:22 2003] |
| 15:00.17 | scanline | hi |
| 15:00.22 | gonkulator | morning scanline |
| 15:01.22 | gonkulator | cool |
| 15:10.45 | gonkulator | hi Xentac |
| 15:12.20 | Xentac | hi gonkulator |
| 15:12.33 | Xentac | ugh |
| 15:13.43 | Xentac | happy April fools day... |
| 15:15.46 | scanline | web site trouble, and clumsiness on my part... |
| 15:16.02 | gonkulator | lol |
| 15:16.05 | Xentac | hehehe |
| 15:16.24 | gonkulator | jurpa has grown to more than 2000 lines of code! |
| 15:16.26 | gonkulator | w00t |
| 15:17.39 | *** join/#picogui lalo[out] (~lalo@200.203.12.232) |
| 15:17.46 | scanline | hi lalo |
| 15:53.57 | *** join/#picogui prpplague (~JoeBob1@12.148.134.9) |
| 15:55.20 | *** join/#picogui merlin262 (~andrew@dyna039170.utdallas.edu) |
| 16:06.38 | *** join/#picogui Dentoid (dento_3000@h242n1fls35o814.telia.com) |
| 16:34.36 | *** join/#picogui qovab (~KVVKF@205.161.225.40) |
| 16:34.58 | *** part/#picogui qovab (~KVVKF@205.161.225.40) |
| 16:55.42 | *** join/#picogui zak (~noname@aden2-35-dhcp.resnet.Colorado.EDU) |
| 17:05.26 | *** join/#picogui Oktal (~mat@pc1-rdng3-5-cust199.winn.cable.ntl.com) |
| 17:07.15 | *** join/#picogui zak (noname@aden2-135-dhcp.resnet.Colorado.EDU) |
| 18:21.50 | scanline | hi lalo |
| 18:27.38 | lalo | hey scanline |
| 18:28.06 | scanline | any ideas about getting the April 1 material posted? :) |
| 18:28.51 | lalo | sure |
| 18:28.59 | scanline | spiffy |
| 19:00.46 | *** join/#picogui Oktal_ (mat@pc1-rdng3-5-cust199.winn.cable.ntl.com) |
| 19:07.29 | *** join/#picogui Oktal (~mat@pc1-rdng3-5-cust199.winn.cable.ntl.com) |
| 19:07.41 | *** join/#picogui Oktal_ (mat@pc1-rdng3-5-cust199.winn.cable.ntl.com) |
| 19:33.05 | *** join/#picogui Oktal_ (mat@pc1-rdng3-5-cust199.winn.cable.ntl.com) |
| 20:01.40 | *** join/#picogui DevGirl (maisa@200.203.12.232) |
| 20:02.02 | gonk{work} | hey DevGirl! |
| 20:02.40 | DevGirl | hi hi! |
| 20:11.02 | *** join/#picogui carpman{mayuka} (~djackson@dsl081-122-066.dfw1.dsl.speakeasy.net) |
| 20:53.41 | *** join/#picogui gonkulator (~brandon@Metro0276.client.mscd.edu) |
| 21:38.55 | *** join/#picogui prpplague (~JoeBob1@12.148.134.9) |
| 21:52.57 | *** part/#picogui Dentoid (dento_3000@h242n1fls35o814.telia.com) |
| 22:09.25 | *** join/#picogui sigmund (aradesh@ti100710a080-5608.bb.online.no) |
| 22:09.40 | sigmund | hi |
| 23:46.23 | *** join/#picogui merlin262 (~andrew@crtntx1-ar1-4-60-243-225.crtntx1.dsl-verizon.net) |