| 00:06.33 | CIA-33 | BRL-CAD: 03starseeker * r36171 10/brlcad/trunk/src/libdm/dm-ogl.c: Ooops, typos. |
| 00:09.25 | starseeker | man this ogl bug is subtle |
| 00:10.37 | louipc | ``Erik: but did the taliban lose 100 or 7? |
| 00:23.50 | starseeker | helllllp... |
| 00:29.58 | starseeker | how do I debug this thing??? |
| 00:32.45 | starseeker | can't believe it's UpdateTitle that results in sudden death... |
| 00:37.57 | starseeker | contemplates making a Tk window before calling ogl_open and "faking" a gui startup sequence |
| 00:38.15 | starseeker | q |
| 00:38.18 | starseeker | whoops |
| 03:58.06 | CIA-33 | BRL-CAD: 03brlcad * r36172 10/brlcad/trunk/ (include/bu.h src/libbu/globals.c): move the doxy docs for the globals declared extern in bu.h to bu.h |
| 11:51.23 | CIA-33 | BRL-CAD: 03davidloman * r36173 10/brlcad/trunk/src/proc-db/ (4 files in 2 dirs): initial work for a building/structure proc-db |
| 11:53.53 | d-lo | brlcad or anyone else: is there any existing functionality for tracking 'used' object names inside a database? (so as to prevent duplication) |
| 11:58.30 | brlcad | you do a db_lookup on the name |
| 11:58.39 | brlcad | LOOKUP_QUIET |
| 11:59.07 | d-lo | good deal, thanks. |
| 11:59.22 | brlcad | that is also a librt routine, not a write-only operation |
| 11:59.49 | d-lo | Also, is there any dire reason (beyong preference) to use C over C++? |
| 12:00.07 | brlcad | no such assertion |
| 12:01.04 | brlcad | tools can be c/c++, it's the libs and existing c apps that shouldn't mix |
| 12:01.25 | d-lo | okay. I only ask because I keep running into 'great things' that could be done with a pinch of OO. |
| 12:01.49 | d-lo | Que ``Erik with some snide "lisp rulz!!1!" comment :) |
| 12:01.52 | brlcad | turning a tool into a library routine would be problematic as c++ down the road if portaions are generalizable to a library, like libged |
| 12:03.29 | brlcad | you can do most OO constructs in c, at least most of the ones that are not just syntax shortcuts |
| 12:04.05 | d-lo | I was really looking at function overloading... its a pain not having it :) |
| 12:12.52 | brlcad | ah, you can get yourself polymorphism, but you have to do a little setup |
| 12:13.25 | d-lo | but how much is gained by 'doing a little setup' versus just using cpp? |
| 12:14.03 | brlcad | depends on the use |
| 12:14.24 | brlcad | it keeping it as a set of C routines that you can pull into a library is important, then might be worthwhile |
| 12:14.34 | brlcad | otherwise, just use c++ |
| 12:15.01 | d-lo | and the only reason why a cpp lib is bad is simply because all the others are c libs? |
| 12:15.16 | brlcad | notes "cpp" is rather confusing/misleading as it's the name of the "c pre processor" that expands #includes and such |
| 12:15.52 | brlcad | a cpp lib isn't bad |
| 12:16.07 | brlcad | mixing c++ into a C api is generally bad |
| 12:17.10 | d-lo | right, so if this make building thing turns into a lib (down the road), then wiring it into libged would prove difficult if libBuilding (or whatever) is c++ ? |
| 12:17.32 | brlcad | there are ABI portability issues with the libraries, linkage incompatibilities, other issues |
| 12:17.42 | brlcad | if it is fully contained as such, then not so bad |
| 12:18.22 | brlcad | it's more that you cannot expose it (at all) symbol-wise and public API |
| 12:19.28 | brlcad | e.g., openNURBS in librt -- not exposed, just an implementation detail under the hood so linkage still doesn't expose any c++ |
| 12:19.57 | d-lo | Hrm, so it it were all 'under the hood' and operated on a provided db_i only, then it would be safe? |
| 12:20.13 | brlcad | doable |
| 12:20.53 | brlcad | be more concerned that you've learned how to use one shiney hammer, so everything looks like it needs to be beaten with that hammer :) |
| 12:21.28 | brlcad | they're different mindsets with tradeoffs on both ends, good to be proficient in both :) |
| 12:21.36 | d-lo | huh? I am talking about how to best implement an idea. |
| 12:21.44 | brlcad | likewise |
| 12:21.59 | brlcad | the language has little to do with that |
| 12:23.17 | brlcad | it's more a procedural data-driven approach vs an object-oriented approach vs a functional approach, etc |
| 12:24.05 | brlcad | you can take most problems and implement them with any one of those three and there are lots of tradeoffs, rare that one is superbly dominating "better" |
| 12:24.11 | brlcad | usually more just one is more "familiar" |
| 12:24.35 | brlcad | just saying it's good to hone skills at least on the other two at some point as well |
| 12:25.26 | brlcad | otherwise everything starts looking like an OO problem and you miss the big picture, acquire bad habits, tend to over-architect, over-abstract, obfuscate, ... it's a balance |
| 12:34.22 | *** join/#brlcad Yoshi47 (n=jan@firewall.walinga.com) |
| 13:18.21 | *** join/#brlcad d_rossberg (n=rossberg@BZ.BZFLAG.BZ) |
| 13:21.05 | ``Erik | *readreadread* |
| 13:22.53 | ``Erik | exposing c++ shtuff in libraries gets into issues with different name mangling (there is no standard). G++ isn't (or wasn't) even self-consistent, so a library providing c++ entry points compiled with, say, gcc 4.1 couldn't be correctly linked to with gcc 4.2, it'd get missing symbols, iirc |
| 13:24.22 | ``Erik | heh, yes, people new to oo become "architect astronauts" and start designing things like... upstairs... :D *duck* |
| 13:44.07 | d-lo | tee hee. |
| 14:50.50 | *** join/#brlcad mafm (n=mafm@225.Red-83-45-72.dynamicIP.rima-tde.net) |
| 15:22.56 | brlcad | howdy mafm m |
| 15:23.50 | mafm | hi there |
| 16:34.11 | *** join/#brlcad Elrohir (n=kvirc@p5B14D686.dip.t-dialin.net) |
| 16:47.31 | *** join/#brlcad Ralith (n=ralith@d142-058-080-147.wireless.sfu.ca) |
| 17:05.46 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) |
| 18:07.09 | *** join/#brlcad Ralith (n=ralith@d142-058-091-146.wireless.sfu.ca) |
| 18:38.17 | ``Erik | hm, a darcs library was listed as a 'todo' back in june |
| 18:38.18 | CIA-33 | BRL-CAD: 03davidloman * r36174 10/brlcad/trunk/src/proc-db/ (makebuilding/makebuilding.c mkbuilding.h): Coninuting work on Makebuilding. Added mkbuilding.h |
| 18:44.48 | *** join/#brlcad Ralith (n=ralith@69.90.49.189) |
| 19:15.33 | CIA-33 | BRL-CAD: 03brlcad * r36175 10/brlcad/trunk/src/util/pl-dm.c: vls strings use %V now instead of %S |
| 19:34.09 | CIA-33 | BRL-CAD: 03brlcad * r36176 10/brlcad/trunk/src/util/pl-dm.c: reorder function definitions so forward declarations are not necessary. |
| 20:02.10 | CIA-33 | BRL-CAD: 03starseeker * r36177 10/brlcad/trunk/src/libdm/dm-ogl.c: |
| 20:02.10 | CIA-33 | BRL-CAD: OK, temporarily comment out some of the dm-ogl code - this allows things to come |
| 20:02.11 | CIA-33 | BRL-CAD: up on the Mac, but (obviously) messes with the initialization of the gl context |
| 20:02.11 | CIA-33 | BRL-CAD: something fierce. Try to work out why these commands are upsetting things. |
| 20:25.46 | CIA-33 | BRL-CAD: 03brlcad * r36178 10/brlcad/trunk/src/util/pl-dm.c: more cleanup, quell slew of warnings, remove unused vars. |
| 20:39.13 | CIA-33 | BRL-CAD: 03brlcad * r36179 10/brlcad/trunk/src/util/pl-dm.c: enable the '-t o' option to open up an ogl display manager. sure enough, it crashes. |
| 20:40.12 | brlcad | what's interesting there is that there are no calls to make_current |
| 20:42.31 | ``Erik | hum, "reverse debugging" in the new gdb |
| 22:32.32 | Maloeran | Reverse debugging? Walking instructions backwards? |
| 22:32.37 | ``Erik | ayup |
| 22:32.48 | Maloeran | That would require an awful lot of memory, and be very slow |
| 22:33.48 | Maloeran | I guess that works to walk a couple instructions back, but you could never get very far anyway. You can't undo system calls and such |
| 22:33.51 | ``Erik | um, there's some lib that does it in a not totally sucky way (mebbe it saves state delta on nondeterministic ops) |
| 22:35.36 | ``Erik | http://news.ycombinator.com/item?id=868769 |
| 22:35.44 | Maloeran | gnome-terminal is pretty bad as a terminal. You flood it on stdout and it freezes or dies |
| 22:36.12 | ``Erik | yeah, it does checkpointing |
| 22:36.17 | Maloeran | Multi-inferior? What is that? |
| 22:36.43 | ``Erik | gnome-terminal and kterm are ass, xterm is ok, rxvt-devel was what I really used before hopping over to mac |
| 22:37.08 | ``Erik | "multi-inferior" sounds like some damn emacs weenie was allowed in the club, I d'no O.o :D |
| 22:37.41 | Maloeran | Yes, I'm always using rxvt. I put Ubuntu on the laptop and I sometimes use gnome-terminal for some reason, but it's pretty bad |
| 22:38.56 | ``Erik | screen eliminates all the pro's that gnome-terminal and kterm have for anyone who can operate a basic text editor... :) |
| 22:39.25 | ``Erik | and if you can't figure out "pico" or "nano", you don't belong opening a terminal emulator :D |
| 22:40.35 | ``Erik | http://dmtcp.sourceforge.net/ |
| 22:40.37 | Maloeran | This is quite bad when doing printf() debugging, and the terminal freezes or dies. When it freezes, it also freezes the program trying to write on the stdout pipe |
| 22:41.05 | Maloeran | And when it dies... You lose all programs launching from that terminal, that's just lovely |
| 22:41.10 | Maloeran | launched* |
| 22:41.36 | ``Erik | I don't remember the app crashing, but I do remember getting annoyed that the kernel compiles on linux took much longer on my 120mhz machine... |
| 22:42.27 | Maloeran | And it's slow, yes. Now imagine the terminal freezing or dying meaning the compilation stops trying to write on stdout |
| 22:42.46 | Maloeran | punches gnome-terminal some more |
| 22:46.04 | ``Erik | rxvt and be happy O.o |
| 22:47.03 | Maloeran | I know, I'm just amazed that some mainstream and common software can be so buggy, and it's just a terminal |
| 22:47.40 | ``Erik | probably one of those "good enough for the plebes, but all the REAL power-users know better" |
| 22:47.43 | ``Erik | :/ |
| 22:50.00 | ``Erik | (though having written a color terminal emulator using a gtk+ text widget before, it's trivial to make it sorta work and a real pain to make it fast) |
| 22:51.02 | Maloeran | Seems rather easy to make it fast... but I wouldn't use gtk+ for the rendering, I would play with X directly |
| 22:51.40 | ``Erik | scanning and handling control codes was the big stinker on mine, I think |
| 22:52.11 | Maloeran | Yes, that part sounds rather messy |
| 22:52.33 | ``Erik | and looking at my code, I've learned quite a few tricks in the last decade heh |
| 22:52.49 | Maloeran | Oh, you too? :) |
| 22:53.05 | Maloeran | Sometimes I'm almost glad I lost most of my >5 years old code |
| 22:53.57 | ``Erik | <-- has learned quite a coding few tricks in the last 26 years, intends to learn quite a few more coding tricks in the next 26 :) |
| 22:54.19 | Maloeran | Even updating the old Rayforce just a month ago... I rewrote all the multithreading, threw away a bunch of pthreads stuff to use x86/amd64 atomic instructions |
| 22:54.30 | Maloeran | Eheh |
| 22:54.50 | ``Erik | heh, I found a simd library for sbcl last week O.O |
| 22:55.12 | louipc | haha I'm a power user for using rxvt? |
| 22:55.13 | Maloeran | Pthreads still annoy me on many aspects, I'm so tempted to just use clone(), futex() and my atomic instructions |
| 22:55.17 | ``Erik | <-- grouses some more that rayforce isn't in BRL-CAD |
| 22:56.30 | Maloeran | The wake up process of pthreads, for threads blocked on condition variables doesn't allow any decent prioritization mechanism |
| 22:56.44 | ``Erik | louipc: more that a "power-user" wouldn't use gnome-terminal... |
| 22:56.46 | Maloeran | And the underlying futex() stuff is so much more flexible |
| 22:56.57 | ``Erik | upside down A's and backwards E's, man |
| 22:57.32 | ``Erik | mal: that's great until you want it to work on something other than linux, or the linux internals change (again) |
| 22:58.21 | Maloeran | You can't define scheduling priorities for different threads with pthreads, seriously how retarded is that? |
| 22:58.21 | ``Erik | the solaris libthread.so package was effin' INSANELY awesome, but coding to it means you don't leave solaris and hope they don't jerk the rug out from under you... |
| 22:58.52 | Maloeran | Mmhm :), I never played with it I'm afraid |
| 22:59.27 | Maloeran | I did some home-made threading on Linux, using the system calls, to see how flexible the underlying interface is... and that just made me more frustrated with Posix threads |
| 22:59.58 | ``Erik | the bsd thread mapping capability is awesome, too... ya get to choose if a thread is a userland thing, an OS 1:1 mapping, or an OS many:many mapping... without recompiling! :) |
| 23:00.43 | ``Erik | the linux kobj thingie was designed to do processes, then threading was bolted into it, and it was shaken around to do anything inbetween... *shrug* |
| 23:00.54 | Maloeran | Being able to wake up any thread *you* choose when signaling a condition variable or releasing a mutex, how come you can't do that with Posix threads? |
| 23:01.07 | ``Erik | when pthreads were new, the notion of threading was in its infancy and every vendor had tis own horrible attempt |
| 23:01.14 | Maloeran | Or definiting the "niceness" or scheduling priority of any thread, gez, that should be simple enough |
| 23:01.36 | ``Erik | what if the OS only supports userland threads? or doesn't have the notion of process priority? |
| 23:01.54 | Maloeran | Then disable the feature, or make it do nothing! But at least make it *possible*! |
| 23:02.06 | Maloeran | You can't have different scheduling priorities with Posix threads, you just can't |
| 23:02.06 | ``Erik | nt4 was made posix compatible, and it only had retarded round robin scheduling iirc |
| 23:02.38 | Maloeran | I don't mind if some features are not available on some platforms, but at least make them available on the platforms that do support them |
| 23:02.42 | louipc | in unix worse is better |
| 23:02.44 | louipc | that's why! |
| 23:03.38 | Maloeran | Erik, I'm seriously very close to just switch over to my own Linux-only threading stuff, with a pthread fallback for other OSes |
| 23:03.53 | ``Erik | srry, dude, their crystal ball was in the shop when pthreads were spec'd, I mean, the notion that a student could write a semi-usable *nix-like os and people would help him for shits and giggles woulda gotten you laughed out of the room |
| 23:04.23 | ``Erik | so predicting how linux does its nth generation threading... yknow.. |
| 23:05.20 | Maloeran | Erik, I'm just saying that pthreads do not expose a bunch of very fundamental features for threading. I know some OSes may not support them |
| 23:05.40 | ``Erik | yeah, I hear ya, dude... I'm saying that pthreads predates those fundamental features :D |
| 23:06.02 | Maloeran | Well if they aren't going to update the library, then we need something new |
| 23:06.20 | louipc | yep |
| 23:06.29 | Maloeran | I think I'll just switch over to my Linux threading stuff, with a pthread fallback |
| 23:08.10 | ``Erik | would rather have cpu affinity control than priority control for threads *shrug* :) |
| 23:08.14 | Maloeran | How could not imagine that someone may want to define different scheduling priorities for different threads. No, they had to enforce that *all* threads *MUST* share the same scheduling priority. Why? Why?... |
| 23:08.33 | ``Erik | hm |
| 23:08.44 | ``Erik | what if I renice a multithreaded program to 20 |
| 23:08.45 | Maloeran | There's cpu affinity stuff, although it's a different library |
| 23:09.04 | Maloeran | All the threads share the same niceness, says the specification |
| 23:09.05 | ``Erik | and I really fucking mean make every thread go to 20, I don't want the program to decide if it's going to listen |
| 23:09.08 | ``Erik | ? |
| 23:09.20 | ``Erik | ok, so posix does that for me, what about futex? |
| 23:09.26 | Maloeran | What if the program has some low priority and high priority threads? |
| 23:09.55 | louipc | well there should be a signal for it, non? |
| 23:10.08 | Maloeran | futex() is the kernel-level thing for mutexes and condition variables, but if you write your own threading stuff, you can define the scheduling of threads any way you want it |
| 23:10.14 | ``Erik | sleep(0); forces a yield, essentually giving you a low priority thread (in a semi-cooperative fashion) |
| 23:10.38 | ``Erik | um |
| 23:10.49 | ``Erik | I have a book somewhere that talks about the low level threading crap |
| 23:10.50 | Maloeran | What if you have a bunch of threads and you wake to wake up a specific one, which must run right *now*? |
| 23:10.52 | ``Erik | wonder where I put it |
| 23:11.11 | Maloeran | Signaling it and sleep(0) may or may not make it actually run |
| 23:11.22 | ``Erik | mal: then your program is written really poorly :D *duck* |
| 23:11.23 | louipc | sounds like fun problems |
| 23:11.42 | Maloeran | Erik, that's a very common case of feeder/consumer threads |
| 23:12.47 | ``Erik | doesn't remember needing to wake it up "right now" doing those things, putting them back into the run queue was sufficient O.o |
| 23:13.50 | Maloeran | Typical example : on a 8 cores machine, with 8 consumer threads, you predict the threads will begin to starve soon and the feeder thread must absolutely run very soon |
| 23:14.12 | ``Erik | "add job; inc jobs available;" | "Icanhasawurkunit? tkae; dec jobs avail" |
| 23:14.20 | Maloeran | And posix threads just won't you do that, you can merely try to wake it up and sleep() a few threads in the hope that it will get to run |
| 23:14.29 | ``Erik | heh |
| 23:14.37 | Maloeran | won't let* you do that |
| 23:15.00 | ``Erik | 8 threads/procs on 8 cores tends to cause OTHER ugly problems, like resource lockstepping |
| 23:15.27 | ``Erik | <-- likes to do 2n-1 for things that touch single interface resources like disk drives |
| 23:15.47 | Maloeran | That thread prioritization problem should not exist, because it doesn't exist when you use a decent low-level threading interface ( like futex() ) |
| 23:16.22 | ``Erik | <-- more apt to think that the problem doesn't... actually... exist... :D *duck* |
| 23:16.43 | Maloeran | Especially since kernels sometimes try to keep the same threads on the same core, and the kernel may have decided that your very important feeder thread must run on core 5, so it's just not going to wake up for a while |
| 23:16.48 | Maloeran | And threads end up starving |
| 23:18.01 | Maloeran | I don't know, it's a matter of flexibility and control... and pthreads don't give you much in both areas |
| 23:18.50 | ``Erik | *shrug* I've never had issue cooking all 8 cores (or 256) until something using an ugly slow resource (disks, network, etc) come into play |
| 23:19.51 | ``Erik | take, for example, BRL-CAD's rt, it can smoke up 1024 cpu's n/p even writing to disk if it buffers right, but it uses maybe one worth in mged due to network silliness with giantlock and shtuff |
| 23:21.07 | Maloeran | Sure sure, but I'm not tempted to assume the design is optimal, in comparison to what could be achieved with more control and flexibility |
| 23:22.26 | ``Erik | I d'no, dude, I have a feeling that you might be wayyyy down the path of diminishing returns |
| 23:23.01 | Maloeran | For one thing, atomic instructions instead of mutexes or spin locks make a huge difference |
| 23:23.20 | Maloeran | ( Okay, it's not portable, but when you got them... ) |
| 23:23.22 | ``Erik | yeah, I can see that one easily |
| 23:23.37 | ``Erik | far less cycles and eliminates branches |
| 23:24.10 | ``Erik | but inventing a threading system to keep a producer hot? O.o |
| 23:24.11 | Maloeran | More than that, you avoid the constant read and write to shared memory lines |
| 23:24.49 | Maloeran | It's not just for that, I was pointing out one example but pthreads are limited on many aspects |
| 23:25.09 | ``Erik | sure, but how much do those aspects really matter? :D just throwin' it out there |
| 23:25.43 | Maloeran | Meh :), you add them all up and I think it matters |
| 23:26.13 | ``Erik | I'd be curious as to your post mortem analysis :) |
| 23:26.19 | Maloeran | Atomic instructions, thread scheduling from mutexes or condition variables, CPU affinity, per-thread niceness/priority, etc. |
| 23:28.34 | Maloeran | The feeder thing actually was a problem in Rayforce when rendering something simple, it goes up to 100-500 frames per second and the kernel too often tries to maintain the "feeder" thread on the same CPU core instead of waking it up right now when needed |
| 23:28.39 | ``Erik | pthread_attr_setschedparam() ? |
| 23:28.50 | Maloeran | So unless you buffer up a lot of work ahead, I mean several frames, threads can starve |
| 23:29.13 | Maloeran | Keep on reading to see if you can actually do anything with that |
| 23:29.47 | Maloeran | You can set FIFO or round-robbing scheduling, but you can't define a thread priority for normal thread scheduling |
| 23:31.08 | ``Erik | that's not what the man page says O>o |
| 23:32.52 | Maloeran | You should try it out, to have a nice surprise on sched_priority... It requires root to be modified! |
| 23:33.50 | Maloeran | And it doesn't work for SCHED_OTHER, which is the normal out-of-order threading |
| 23:34.01 | ``Erik | sounds like you attempted to increase the priority... that's against the fundamental security model, only root can increase priority, users can only reduce priority (increase nice) |
| 23:34.45 | Maloeran | Niceness is shared by all Posix threads |
| 23:35.02 | Maloeran | And sched_priority has no effect for SCHED_OTHER scheduling |
| 23:35.44 | Maloeran | ( While SCHED_RR and such requires root ) |
| 23:40.36 | ``Erik | *shrug* |
| 23:42.33 | Maloeran | Anyway... as you said, it was designed too long ago, and it needs an urgent update or rewrite |
| 23:43.18 | ``Erik | (I'd find it amusing if you end up re-inventing fork() ) |
| 23:44.29 | Maloeran | It's not quite fork(), threads use the clone() system call, so does fork() of course |
| 23:44.35 | louipc | that would be cool |
| 23:44.45 | Maloeran | clone() is a very flexible little system call |
| 23:45.15 | louipc | I heard it was stolen from plan9 or something |