| 00:00.40 | starseeker | can't wait for the animal rights guys to hop onto this one... |
| 00:04.15 | puddingpimp | I wonder if animal rights guys give two shits about insects |
| 00:12.27 | *** join/#brlcad PabloGarrido (n=PabloGar@189.79.77.114) | |
| 00:18.40 | *** part/#brlcad PabloGarrido (n=PabloGar@189.79.77.114) | |
| 00:38.42 | *** join/#brlcad Ralith (n=ralith@69.90.48.129) | |
| 01:02.51 | *** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net) | |
| 01:39.34 | louipc | probably but it's low on the priority list |
| 01:47.52 | puddingpimp | I mean, I've never heard of the SPCA bringing suit against anyone for burning ants for example |
| 01:49.27 | louipc | vegans don't eat honey because it's cruel to the bees though. |
| 02:32.44 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 02:47.22 | brlcad | starseeker: the api could certainly provide both -- an iterator that returns strings that were appended and a visitor callback |
| 02:48.17 | brlcad | returning a raw bu_list of bu_vls isn't exactly ideal as it does beg for some sort of container struct to make a list out of |
| 02:48.28 | brlcad | under the hood, sure, just not exposed via API |
| 02:48.35 | brlcad | visitor and/or iterator ftw |
| 02:49.48 | brlcad | i ran across several instances where it looked like there should be a typedef'd enum .. almost any time you have a "set" of #defines that logically group together, that generally begs for it |
| 02:51.29 | brlcad | e.g. the ged func return codes, the edit "modes" (which are questionably part of public api), action codes on various calls (like quiet/noisy lookups, soft/hard errors, verbosity levels, etc) |
| 03:23.39 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1177593829.dsl.bell.ca) | |
| 04:36.20 | starseeker | brlcad: yeah, I figured raw bu_list/bu_vls wasn't ideal, but you had mentioned wanting to avoid introducing new structures |
| 05:04.55 | starseeker | glares at togl |
| 05:07.00 | starseeker | hmm, I like this quote: "Questions about whether design is necessary or affordable are quite beside the |
| 05:07.03 | starseeker | point: design is inevitable. The alternative to good design is bad design, not |
| 05:07.05 | starseeker | no design at all." |
| 05:12.25 | starseeker | or better yet: If you can't afford to do something right, then be darn sure you can afford to do it wrong. |
| 08:54.53 | brlcad | to return a bu_list/bu_vls would involve a new structure |
| 08:55.11 | brlcad | can do that under the hood, just not the api |
| 10:46.56 | *** join/#brlcad parigaudi (n=quassel@217.91.127.94) | |
| 11:10.01 | brlcad | that's why you either provide a visitor pattern (where the visitor func merely iterates over the bu_list and calls the callback) ... or you implement an iterator like strsep() or BU_LIST_NEXT() |
| 12:59.15 | *** join/#brlcad d-lo (n=claymore@63.246.136.16) | |
| 12:59.32 | d-lo | mernin all |
| 13:13.46 | ``Erik | yargh |
| 13:58.31 | *** join/#brlcad _clock_ (n=_sushi_@80-218-244-105.dclient.hispeed.ch) | |
| 14:00.13 | d-lo | whats new ``Erik |
| 14:00.15 | d-lo | ? |
| 14:25.37 | *** join/#brlcad d_rossberg (n=rossberg@BZ.BZFLAG.BZ) | |
| 14:44.41 | *** join/#brlcad mafm (n=mafm@225.Red-83-45-72.dynamicIP.rima-tde.net) | |
| 15:06.37 | *** join/#brlcad samrose (n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) | |
| 15:48.13 | starseeker | wonders what GED_VMIN is for, and why it's defined as -2048... |
| 15:51.58 | *** join/#brlcad Elrohir (n=kvirc@p5B14F730.dip.t-dialin.net) | |
| 16:02.24 | brlcad | starseeker: OOOOld baggage |
| 16:02.45 | brlcad | mged's display managers have a vector space mapping of -2048 to +2047 |
| 16:03.07 | starseeker | ah |
| 16:03.37 | starseeker | wonders if that should be mentioned in the comments around those defines... |
| 16:03.39 | brlcad | used for things like plotting, object selections, etc |
| 16:03.52 | brlcad | it's assumed in LOTS of places |
| 16:04.00 | brlcad | really bad |
| 16:04.07 | starseeker | eeek |
| 16:04.57 | brlcad | just search on 2048 in src/libdm and src/mged .. those should all be dynamic but aren't |
| 16:05.49 | brlcad | GED_VMIN probably just shouldn't even exist |
| 16:05.55 | brlcad | I see no reason for that to be public api |
| 16:06.18 | brlcad | a lot that is in ged.h doesn't belong there, belongs in private implementation header |
| 16:07.51 | Maloeran | Gah, that sounds very bad, a hard-coded limit assumed everywhere in the code? |
| 16:08.14 | Maloeran | Although I'm not entirely sure what that "vector space mapping" is used for |
| 16:08.57 | brlcad | it's not a core piece of code, it's for plotting the wireframes and conversion to plot/postscript formats |
| 16:09.34 | Maloeran | Ah I see. That really should have been made more flexible... |
| 16:09.35 | brlcad | they're integer indexed formats, so it bounds the range as 4k x 4k |
| 16:10.17 | starseeker | winces - plotting the wireframes is currently how we view all the models... |
| 16:10.40 | starseeker | maybe not core but still... |
| 16:10.53 | brlcad | starseeker: it's more a code maintenance problem when 4k x 4k displays become common |
| 16:11.06 | brlcad | have to weed out those instances |
| 16:11.12 | starseeker | nods |
| 16:11.24 | starseeker | would looove to see pixel densities get that high :-) |
| 16:11.25 | brlcad | i mean it's not like it's "everywhere", just in a couple dozen places |
| 16:12.58 | brlcad | rewriting it all to be dynamic wouldn't be too difficult, it just shouldn't be compile-time limited (or if it must, might as well use max-representation) |
| 16:28.10 | starseeker | brlcad: does view_obj make sense in libged? |
| 16:28.46 | brlcad | yay, svn checkout on solaris |
| 16:28.51 | brlcad | starseeker: nope |
| 16:29.14 | starseeker | cool, solaris build here we come :-) |
| 16:29.16 | brlcad | none of the old "objects" should remain, too wired to tcl |
| 16:29.30 | brlcad | dm_obj, dg_obj, view_obj |
| 16:29.52 | brlcad | er, wdb_obj, not dm_obj |
| 16:30.15 | brlcad | they were part of the "move it to get it done, i'll fix it later" claim.. |
| 16:30.37 | starseeker | actually, I don't think his struct view_obj in libged references tcl - I was just thinking since it seems to manage GUI view state rather than geometry as such, it might make more sense elsewhere... |
| 16:31.33 | brlcad | the struct might not, but all of the vo_* callbacks do |
| 16:32.41 | brlcad | view_obj.c should get broken up into 37 command files |
| 16:32.45 | brlcad | (at a glance) |
| 16:33.40 | starseeker | checks... oooo, yeah you're right |
| 16:33.42 | starseeker | Tcl everywhere |
| 16:33.57 | brlcad | by definition :) |
| 16:34.01 | brlcad | the "obj" is a Tcl object |
| 16:34.42 | starseeker | yech |
| 16:34.53 | starseeker | that'll be fun |
| 16:34.59 | brlcad | in theory, it becomes a "view" parent command (view aet, view rot, etc) but still needs tcl decoupled |
| 16:35.52 | brlcad | you can tell just from an ls that the obj commands comprise about 150 commands that need to be refactored |
| 16:35.54 | starseeker | still want individual files for the "subcommands"? |
| 16:36.34 | brlcad | depends how complicated, but in the general case of "view", yes |
| 16:37.06 | brlcad | that separation goes *way* back, about 15 years iirc |
| 16:37.59 | brlcad | to group commands based on whether they modify the 3d view, modify geometry, or modify the display |
| 16:38.29 | brlcad | problem is most commands modify multiples/all of those, or at least they could |
| 16:39.24 | brlcad | I'd rather see an aet.c that is utilized by a parent view.c, have that aet.c specify (via libged private actions/flags) that the view/geometry/display is modified |
| 16:39.27 | starseeker | mm. So prefixing with a parent command would allow us to remove the ambiguity, at the expense of more verbose commands? |
| 16:39.58 | brlcad | prefixing with a parent? |
| 16:40.14 | starseeker | "view ae" as opposed to "ae" |
| 16:40.17 | brlcad | no different than it is now, just code organization and what has access to what data |
| 16:40.27 | brlcad | that's how it is now, you can do both |
| 16:40.54 | brlcad | though 'view aet' to be precise |
| 16:41.20 | starseeker | right, but if we're planning stateless editing of geometry, just "ae" becomes ambiguous - do you mean the current geometry, the view, ... |
| 16:41.58 | brlcad | right |
| 16:42.17 | starseeker | so do we deprecate the plain "ae" or just have it default to view? |
| 16:42.34 | brlcad | it'd either disapper (unlikely) or just default to what is most intuitive |
| 16:42.51 | starseeker | nods |
| 16:42.52 | brlcad | default to view would be my expectation in that case |
| 16:45.36 | brlcad | autoview is a good example, it's characterized as a drawable geometry (dg) object command |
| 16:45.44 | brlcad | at least a good example of how the categorization fails |
| 16:46.19 | brlcad | it only modifies the view, but can't be a view command because it needs access to the drawn geometry in order to figure out the new view size |
| 16:46.43 | brlcad | it's also one of the few already refactored iirc |
| 16:46.58 | brlcad | so it's in dg still and outside, so can compare |
| 16:52.04 | *** join/#brlcad ed-209 (n=cc@pool-98-114-228-98.phlapa.fios.verizon.net) | |
| 17:12.02 | brlcad | lunch! |
| 19:58.46 | *** join/#brlcad Ralith (n=ralith@d142-058-080-247.wireless.sfu.ca) | |
| 20:02.19 | brlcad | woot, the tcl folks reviewed our command length extender patch |
| 20:02.35 | brlcad | looks like it'll be applied with a slight mod |
| 20:17.29 | *** join/#brlcad Elrohir (n=kvirc@p5B14F730.dip.t-dialin.net) | |
| 20:35.17 | *** join/#brlcad b0ef (n=b0ef@157.26.202.84.customer.cdi.no) [NETSPLIT VICTIM] | |
| 20:35.17 | *** join/#brlcad akafubu (n=akafubu@unaffiliated/akafubu) [NETSPLIT VICTIM] | |
| 20:35.17 | *** join/#brlcad mafm (n=mafm@225.Red-83-45-72.dynamicIP.rima-tde.net) [NETSPLIT VICTIM] | |
| 21:29.05 | starseeker | hmmm: http://labs.trolltech.com/blogs/2009/10/02/introducing-new-port-of-qt-to-your-favourite-platform/ |
| 21:35.42 | Maloeran | Hey Erik, will you be staying at home tomorrow as well? Looks like I'll have a day off tomorrow |
| 22:06.25 | *** join/#brlcad Yoshi477 (n=jan@d72-39-56-44.home1.cgocable.net) | |
| 23:29.05 | *** join/#brlcad Ralith (n=ralith@69.90.49.189) | |
| 23:44.17 | starseeker | brlcad: continuing the "dumb questions about libged" trend, how should private and public structures be decided in terms of what goes in ged.h? In C, won't we have to have any structure used inside struct ged also be public? (In the case, say, of a hypothetical ged_result structure used in struct ged?) |
| 23:54.34 | brlcad | starseeker: there are no dumb questions, a lot of our existing maintainence issues are because people didn't ask questions |
| 23:55.22 | starseeker | heh - OK, make it "things I should probably be able to figure out for myself by this stage" :-P |
| 23:58.06 | starseeker | has come a ways with C/C++, but there's so much more to learn... |
| 23:58.41 | brlcad | :) |
| 23:59.08 | brlcad | you can spend a decade learning and still learn new things |
| 23:59.26 | brlcad | at which point you'll forget things you learned, relearn them, learn something new, repeat, etc :) |
| 23:59.40 | starseeker | hehe |
| 23:59.53 | brlcad | the structs will have to be declared, at least their type -- whether it matters if it's an incomplete type depends on use |