...particularly the auto-generated graphs. We can see in a *graphic* way
what a complete mess the code is!

http://img515.imageshack.us/my.php?image=classactivetaskcollgrapcs7.png

Somebody should print the full UML graph rooted on the CLIENT_STATE class
(400 member variables anyone?) in poster-sized paper (only size that would
have readable text), and take it to the next BOINC workshop :D

Post a reply to this message

Nicolas Alvarez wrote:
> ....particularly the auto-generated graphs. We can see in a *graphic* way
> what a complete mess the code is!

In my gut reaction, any diagram that has "shared memory" in the same 
layout as "project" is broken. :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Nicolas Alvarez wrote:
> ...particularly the auto-generated graphs. We can see in a *graphic* way
> what a complete mess the code is!
> 
> http://img515.imageshack.us/my.php?image=classactivetaskcollgrapcs7.png
> 
> Somebody should print the full UML graph rooted on the CLIENT_STATE class
> (400 member variables anyone?) in poster-sized paper (only size that would
> have readable text), and take it to the next BOINC workshop :D
> 

Looks like something I've seen on TDWTF ...

Post a reply to this message

Darren New wrote:
> Nicolas Alvarez wrote:
>> ....particularly the auto-generated graphs. We can see in a *graphic* way
>> what a complete mess the code is!
> 
> In my gut reaction, any diagram that has "shared memory" in the same
> layout as "project" is broken. :-)

Ah yes. Science apps and the core client communicate using shared memory.
They have a bunch of code to queue messages on the shared memory block.

Request-response communication over shared memory? Wouldn't *pipes* do the
job perfectly?!

(Not to mention those requests and responses are in *XML*. And that there
isn't any real XML parser involved, it's XML parsed with strstr().)

Post a reply to this message