| 01:17.23 | Notify | 03BRL-CAD Wiki:Soulwindow * 0 /wiki/User:Soulwindow: |
| 01:48.45 | Notify | 03BRL-CAD Wiki:Conanactual * 0 /wiki/User:Conanactual: |
| 01:50.45 | Notify | 03BRL-CAD:starseeker * 57609 (brlcad/trunk/include/raytrace.h brlcad/trunk/src/libged/search.c brlcad/trunk/src/librt/search.c): Clear up memory leaks in the search code. |
| 02:47.45 | Notify | 03BRL-CAD:starseeker * 57610 (brlcad/trunk/include/raytrace.h brlcad/trunk/src/libged/search.c brlcad/trunk/src/librt/search.c): Needing a unique list of directory pointers back from a search is probably going to be common - at least, comb already uses that style in several calls - so duplicating that logic multiple times is a no-go. Wrap up the logic into another simple function, since most of the 'search types' |
| 02:47.47 | Notify | under contemplation earlier actually end up being toplevel path list generator options and the return table type for this scenario is a table of pointers instead of a table of full paths (latter has a non-standard freeing obligation). |
| 03:00.39 | Notify | 03BRL-CAD:starseeker * 57611 brlcad/trunk/src/libged/search.c: Don't crash if search results are null. |
| 03:05.07 | Notify | 03BRL-CAD:starseeker * 57612 brlcad/trunk/src/libged/search.c: comment explaining why we're re-assembling plan argv elements into a string |
| 05:02.36 | *** join/#brlcad kesha_ (~kesha@49.202.238.88) |
| 05:05.58 | Notify | 03BRL-CAD:phoenixyjll * 57613 brlcad/trunk/src/libbrep/boolean.cpp: Delete the generated m_curve. And overload the operator= to avoid sharing of m_curve. |
| 05:23.32 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
| 05:48.45 | kesha_ | brlcad: After make step-g , running ./step-g ... always ends up with error -> http://paste.kde.org/p3cf74f23/ |
| 05:49.30 | kesha_ | yesterday also I posted several pastebins showing the same error. |
| 06:38.26 | *** join/#brlcad kesha_ (~kesha@49.249.191.17) |
| 06:48.57 | *** join/#brlcad kesha__ (~kesha@49.249.17.148) |
| 07:19.42 | *** join/#brlcad vladbogo (~vlad@188.25.237.111) |
| 07:28.02 | *** join/#brlcad kesha__ (~kesha@49.249.17.88) |
| 07:40.33 | Notify | 03BRL-CAD Wiki:KeshaSShah * 6129 /wiki/User:KeshaSShah/GSoC13/Reports: /* Week 13 */ |
| 07:41.24 | Notify | 03BRL-CAD:vladbogo * 57614 brlcad/trunk/src/libdm/dm-qt.cpp: Print log calls only if debug level is enabled. |
| 07:48.29 | *** join/#brlcad kesha__ (~kesha@49.249.17.55) |
| 07:52.59 | Notify | 03BRL-CAD:vladbogo * 57615 brlcad/trunk/src/libdm/dm-qt.cpp: Implemented qt_draw + comments. |
| 08:20.02 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) |
| 08:57.10 | kesha__ | What is the flag used while compiling to silent variable declared but not used warnings into errors ? |
| 08:57.15 | kesha__ | http://paste.kde.org/pdb346bbb/ |
| 10:56.18 | *** join/#brlcad caen23 (~caen23@92.81.182.233) |
| 11:09.44 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) |
| 11:45.15 | *** join/#brlcad kesha__ (~kesha@49.249.17.55) |
| 12:02.36 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
| 12:04.27 | brlcad | kesha__: segfaults like that are expected for many versions |
| 12:04.58 | brlcad | notice in the commit version numbers that they tend to come in sets of activity |
| 12:06.19 | brlcad | so you can test earlier and later versions "smartly", jumping forward to the next set or jumping to the end of a given set to see where work stopped for a while |
| 12:06.35 | brlcad | if they're all busted, then that will answer our question |
| 12:08.13 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) |
| 12:24.59 | Notify | 03BRL-CAD:phoenixyjll * 57616 brlcad/trunk/src/libged/brep.c: Free the result internal. |
| 12:31.03 | Notify | 03BRL-CAD:phoenixyjll * 57617 brlcad/trunk/src/libbrep/intersect.cpp: Delete the input curve by default. |
| 12:33.22 | *** join/#brlcad kesha (~kesha@49.249.16.116) |
| 12:42.04 | kesha | brlcad: okay, but many give -Werror that variable set but not used. Basically convert warning into error. |
| 12:42.20 | kesha | Can we compile them successfully ? Any flags ? |
| 12:44.50 | kesha | I tried out an obvious way of commenting those unused, but then it complained that that variable was undeclared when used in later part of code |
| 12:46.56 | brlcad | i believe INSTALL covers that |
| 12:47.21 | brlcad | it's one way for configure and another for cmake |
| 12:47.25 | brlcad | they both document it somewhere |
| 12:47.29 | brlcad | try --help |
| 12:55.32 | kesha | http://paste.kde.org/pdd20c49c/ |
| 12:55.40 | kesha | opp of 29 |
| 13:02.08 | Notify | 03BRL-CAD:phoenixyjll * 57618 brlcad/trunk/src/libbrep/boolean.cpp: Delete the curves in newloop if it's not valid (so not added to the final geometry) |
| 13:08.15 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) |
| 13:19.02 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
| 13:25.57 | Notify | 03BRL-CAD:phoenixyjll * 57619 (brlcad/trunk/src/libbrep/boolean.cpp brlcad/trunk/src/libbrep/intersect.cpp): Still memory leak... |
| 13:34.46 | Notify | 03BRL-CAD:phoenixyjll * 57620 (brlcad/trunk/src/libged/brep.c brlcad/trunk/src/librt/comb/comb_brep.cpp): Free the internals. |
| 13:37.36 | Notify | 03BRL-CAD Wiki:Phoenix * 6130 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 13 */ |
| 13:38.44 | *** join/#brlcad Ch3ck_ (~Shadownet@195.24.220.16) |
| 13:45.22 | Notify | 03BRL-CAD:phoenixyjll * 57621 brlcad/trunk/src/librt/comb/comb_brep.cpp: Call rt_db_free_internal(). |
| 13:51.46 | Notify | 03BRL-CAD:phoenixyjll * 57622 brlcad/trunk/src/librt/comb/comb_brep.cpp: Free the two original breps... |
| 13:56.01 | Notify | 03BRL-CAD:starseeker * 57623 (brlcad/trunk/include/raytrace.h brlcad/trunk/src/libged/search.c brlcad/trunk/src/librt/db_lookup.c): I don't know if this is the 'proper' final form of the db_tops command, but as possible uses of db_search expand the costs of duplicating this logic will get high very quickly. Make a stab at a librt db_tops. |
| 13:57.06 | starseeker | waits for brlcad to strike down r57623... |
| 14:06.33 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) |
| 14:36.27 | kesha | brlcad: how to deal with this fatal error ? http://paste.kde.org/p1396e8d5/ |
| 15:00.34 | Notify | 03BRL-CAD:carlmoore * 57624 (brlcad/trunk/include/icv.h brlcad/trunk/src/bwish/tcl.c and 2 others): fix spelling, and remove trailing blanks/tabs |
| 15:07.55 | Notify | 03BRL-CAD:starseeker * 57625 (brlcad/trunk/include/raytrace.h brlcad/trunk/src/libged/comb.c and 2 others): More search API work. The comb example makes the case for making it trivially easy to handle either lists or individual paths, so structure the API that way - db_search_path, db_search_paths, etc. comb.c builds but is currently untested - need to test. Should be just about ready to start marking functions |
| 15:07.57 | Notify | deprecated for the old search API. |
| 15:18.45 | Notify | 03BRL-CAD:starseeker * 57626 brlcad/trunk/doc/docbook/system/mann/en/comb.xml: Fix typos |
| 15:20.34 | Notify | 03BRL-CAD:starseeker * 57627 brlcad/trunk/src/libged/comb.c: Add missing blank line |
| 15:25.28 | Notify | 03BRL-CAD:starseeker * 57628 brlcad/trunk/include/raytrace.h: These were never in a released version of BRL-CAD, so just yank them. |
| 15:41.10 | *** join/#brlcad Ch3ck_ (~Shadownet@195.24.220.16) |
| 15:48.07 | ``Erik | Ayn Rand McNally: Road Atlas Shrugged |
| 15:51.59 | starseeker | heh |
| 15:52.09 | Notify | 03BRL-CAD:starseeker * 57629 (brlcad/trunk/CHANGES brlcad/trunk/include/raytrace.h brlcad/trunk/src/librt/search.c): Mark the old search API and db_full_path_list structure as deprecated. |
| 15:53.09 | *** join/#brlcad caen23 (~caen23@92.81.189.104) |
| 15:58.24 | *** join/#brlcad kesha (~kesha@49.249.17.91) |
| 16:02.11 | Notify | 03BRL-CAD:starseeker * 57630 brlcad/trunk/include/raytrace.h: Clean up the header - compact the deprecated calls, update API comments |
| 16:08.19 | starseeker | turns his sites on dbfind - time to add whatever is need to search to fully encompass its capabilities and make it go away |
| 16:08.45 | *** join/#brlcad kesha (~kesha@49.249.17.119) |
| 16:10.54 | Notify | 03BRL-CAD:indianlarry * 57631 (brlcad/branches/nurbs/CHANGES brlcad/branches/nurbs/TODO and 57 others): Merging trunk into branch 'nurbs' r:57498:57630 |
| 16:16.46 | *** join/#brlcad _Ch3ck (~Shadownet@195.24.220.16) |
| 16:38.37 | kesha | brlcad: http://paste.kde.org/p527c9652/ I get this compiling error for all revision r49k around .. Do I need to set some variables ? |
| 16:49.58 | *** join/#brlcad kesha (~kesha@49.249.17.119) |
| 17:06.57 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
| 17:13.39 | _Ch3ck | brlcad: finished the pull routine ;) succesfully pulled the translation and the combinations right up to the root of the tree so what do i do next? |
| 17:13.49 | _Ch3ck | uploading patch to source forge now.... |
| 17:20.44 | Ch3ck | brlcad: I'll try to port it to archer and see how it goes but currently facing some problems with the archer interface |
| 17:37.02 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 6131 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* Sept 09 - Sept 15 */ |
| 18:18.27 | Izak_ | brlcad: I have drawn lines in mged/archer using plot(). Still can't figure out how to iterate though the elevation and azimuth ranges to plot the heart. Which do you think should be in the outer loop (if the order matters) ? |
| 18:19.15 | Izak_ | have parametric equations already but don't know how to exploit them |
| 18:20.57 | Izak_ | I observed that the 2 lobes of the heart are simply reflections of eachother along the Z-axis. Can this help with designing the strategy to write rt_hrt_plot()? brlcad: |
| 18:24.48 | *** join/#brlcad Izak__ (~Izak@195.24.220.16) |
| 18:27.10 | Izak__ | ``Erik: Any light to throw on the aforementioned concerns I've expressed ? |
| 18:30.34 | ``Erik | if the two lobes are identical, you can evaluate one side and mirror it for the other... you might even be able to cut it into quarters this way |
| 18:32.45 | ``Erik | contemplate taking one of these quarters and overlaying a grid... each intersection on the grid provides you an x/y, if you can solve the z for that point, you can approximate the surface and draw lines between those intersection points (which may even give you the _tess function later) |
| 18:33.08 | ``Erik | does that sound feasible? |
| 18:36.45 | Izak__ | What about this ? Since a plane through the vertical Z-axis acts like a mirror, does it mean I draw from The negative Z radial direction vector (-C) though the positive X direction vector (A) to the positive Z direction vector (C), that's anti-clockwise ? |
| 18:37.46 | ``Erik | winding order doesn't matter for plot, it's just line segments |
| 18:38.04 | *** join/#brlcad caen23 (~caen23@92.81.189.104) |
| 18:40.52 | Izak__ | HHmm. ``Erik: So you mean i work from one quarter to another ?. That's a great divide and conquer approach. |
| 18:41.15 | ``Erik | I don't think the lines even need to be connected,[D technically... like it's a list of line lists |
| 18:41.46 | ``Erik | yeah, start with a quarter, mirror it one way (say the Z axis), then mirror the result (on, say, the X axis), done |
| 18:44.49 | Izak__ | Is a grid a single isocontour ? Like in the ell / superell, i see 3 grids, is each a grid what you call an isocontour ? |
| 18:46.26 | ``Erik | but it'll probably start with a grid ... for(x=0;x<width;x+=step) for(y=0;y<height;y+=step) stash(x,y,eval(x,y)); for(x=0;x<width;x+=step)for(y=0;y<height;y+=step) { add_line( unstash(x,y), unstash(x+step,y) ); add_line( unstash(x,y), unstash(x,y+step) ); } |
| 18:47.11 | ``Erik | ell/sph doens't use a grid, it traveses the surface in the 3 planes... |
| 18:47.54 | ``Erik | I'm thinking more like how the raytracer works, just sample a regular grid and link each intersection point to its neighbors |
| 18:49.17 | ``Erik | (and I'd think you should just do it really simple at first and accept the visual flaws to get something working, then you can fix the flaws or decide if another approach is better) |
| 18:50.27 | Izak__ | yeah ``Erik: The problem is getting that alpha-version working first. I agree |
| 19:26.58 | brlcad | starseeker: were they deprecated in 7.24 or .. 7.22 ? |
| 19:27.11 | brlcad | thought it might be earlier |
| 19:30.55 | *** join/#brlcad kesha_ (~kesha@49.249.0.250) |
| 19:37.34 | _Ch3ck | runs to bed! |
| 19:38.03 | Izak__ | Izak_ yawns.... |
| 19:38.20 | Izak__ | yawns.... |
| 19:41.37 | brlcad | starseeker: tops looks okay to me |
| 19:42.18 | brlcad | some room for improvement perhaps, but isn't that always the case |
| 19:42.47 | brlcad | 'flat' seems like the wrong option ... at least by definition they're not top-level objects |
| 19:43.10 | brlcad | but then you want a list of all objects, so perhaps inverting the function semantically is in order |
| 19:45.38 | brlcad | e.g., db_ls() or db_index() to get "all objects", of which tops may be a categoric option (along with all regions, all solids, all hidden, ... typedef bitwise enum ftw) |
| 19:46.56 | brlcad | then the only consideration is whether we have any callers that want to manage their own memory (e.g., on the stack with a limit), or always use heap and require caller bu_free() the return (btw, the doxygen docs should state that requirement) |
| 19:53.55 | Notify | 03BRL-CAD Wiki:Harman052 * 6132 /wiki/User:Harman052/GSoc2013/Logs: |
| 20:00.56 | Notify | 03BRL-CAD Wiki:Harman052 * 6133 /wiki/User:Harman052/GSoc2013/Logs: /* September 13 2013 */ |
| 20:13.24 | Notify | 03BRL-CAD:starseeker * 57632 brlcad/trunk/include/raytrace.h: Add the search.c file tag to the comments at the new API |
| 20:15.46 | brlcad | nifty: http://www.drdobbs.com/cpp/programming-without-variables/240161204 |
| 20:17.24 | Notify | 03BRL-CAD:starseeker * 57633 brlcad/trunk/src/libged/search.c: Add the ability to search to do a 'flat' search where every object in the .g file is a toplevel starting point for search. As long as we are at it, add the same ability to specific paths as well. Right now, the | symbol is added to the beginning of the search path to identify it as a flat search. For non-full-path searches the results will be the same |
| 20:17.26 | Notify | (for more processing overhead) but it does make a difference for the results if full path output is of interest. |
| 20:24.18 | Notify | 03BRL-CAD:starseeker * 57634 brlcad/trunk/src/libged/search.c: Just do the smart thing under the hood and avoid the full flat search unless we need full paths. |
| 20:27.16 | Notify | 03BRL-CAD:starseeker * 57635 brlcad/trunk/src/libged/search.c: Actually, that's not necessarily true when the hidden flag is involved - play safe and do what's requested |
| 20:28.51 | starseeker | brlcad: the search APIs? I just now deprecated them |
| 20:29.48 | starseeker | likes the db_index idea... |
| 20:31.23 | starseeker | I mainly added the ability to do the "every object is a toplevel object" return to make the search feature in r57633 easier to implement |
| 20:31.43 | brlcad | huh, okay I thought at least some of them already had a comment, just not the DEPRECATED symbol |
| 20:31.54 | starseeker | I guess that does suggest that a more general function like db_index... |
| 20:31.58 | brlcad | I figured it was for search |
| 20:32.29 | brlcad | alternative is two separate functions, but I think they are mergeable into one API |
| 20:32.37 | starseeker | is trying to walk a line between not making a mess of the API again and coding up something that will be at least moderately less embarassing to come back to... |
| 20:33.10 | brlcad | appreciates this in ever increasing quantities ;) |
| 20:33.27 | brlcad | what do you think about the memory management aspect? |
| 20:34.22 | starseeker | I went with the "caller needs to free" thing mainly because I was worried that a large enough db list could really cause problems for the stack, and the API complexity of dealing with "here's some but not all of the result" didn't appeal... |
| 20:35.01 | brlcad | I like that reasoning, okay |
| 20:35.07 | brlcad | pretty sound |
| 20:35.28 | brlcad | going points, requiring callers bu_free vs. allowing the caller to decide vs. forcing the caller to provide .. merits and downsides to both, but there would be issues cascading for partial results |
| 20:35.34 | brlcad | s/going/good/ |
| 20:35.49 | starseeker | will add it to the doxygen comments - I hadn't documented the tops thing much yet because I figured there was at least one major iteration of some sort coming ;-) |
| 20:36.30 | brlcad | i think aflag and tops actually go away with a typedef bitwise enum |
| 20:36.52 | starseeker | like the region flag on struct directory? |
| 20:36.59 | starseeker | mix and match ftw? |
| 20:37.06 | brlcad | basically a set of filters |
| 20:37.27 | brlcad | wonders if 'index' implies something else |
| 20:37.46 | starseeker | hmm... db_set? |
| 20:37.51 | brlcad | too generic |
| 20:37.55 | brlcad | db_catalog()? |
| 20:38.17 | brlcad | db_index isn't bad, need to see what else we call index |
| 20:38.17 | starseeker | maybe, has connotations of comprehensiveness |
| 20:38.22 | brlcad | true |
| 20:38.46 | brlcad | db_contents() |
| 20:39.17 | brlcad | db_ls() fits conceptually |
| 20:40.06 | starseeker | db_objects()? |
| 20:40.31 | brlcad | I'd kind of expect directory pointers back |
| 20:40.45 | starseeker | I think that's what I'm providing, isn't it? |
| 20:40.51 | starseeker | double checks... |
| 20:40.59 | brlcad | returing an argv |
| 20:41.05 | brlcad | I thought I saw |
| 20:41.11 | starseeker | ah, right |
| 20:41.14 | starseeker | my bad |
| 20:41.24 | starseeker | considered dp, but went with the more generic solution |
| 20:41.27 | brlcad | we should have another function that converts an argv to a set of dirp's |
| 20:41.43 | starseeker | and vice versa, for that matter ;-) |
| 20:41.50 | brlcad | sure |
| 20:42.09 | starseeker | db_obj_names()? |
| 20:44.19 | brlcad | unless we're going to have a set of other funcs that naturally go with it, we don't (yet) need a package scope in the name |
| 20:44.24 | brlcad | likes db_ls and db_index more too |
| 20:44.43 | starseeker | would go with ls if it weren't for the mged behavior of just listing everything |
| 20:44.58 | starseeker | but I guess it wouldn't be unreasonable to have an ls --tops option or some such |
| 20:45.02 | brlcad | looks like rays have a notion of an index, the spatial partition has a cutting plane index notion |
| 20:45.34 | brlcad | mged's ls command is actually 'similar' .. it's got flags that filter out and show more |
| 20:45.44 | starseeker | is warming up to db_ls the more he thinks about it - the default is the flat list (ls), and the enums match up to options to ls (filters) |
| 20:46.05 | brlcad | ged_ls would naturally wrap it |
| 20:46.32 | starseeker | whats a good example of typedef bitwise enum? I'm not comfortable enough with bits to want to come at it cold... |
| 20:46.46 | brlcad | of course, it does beg wether it *should* return a list of dirp's instead of argv's ... and have a function to extract an argv from that as a helper |
| 20:46.57 | brlcad | since it is a *db*_ command |
| 20:47.16 | brlcad | dunno, not compelling, but interesting consideration |
| 20:47.54 | starseeker | nods - fair enough. I return either db_full_path or directory pointers from search, and the db_ls API should be generic rater than tuned to my specific convenience here |
| 20:48.39 | brlcad | i'm sure search can be made to use either |
| 20:48.44 | starseeker | with a wrapper function, it's like one extra line anyway - not a big price to pay, since I'd bet directory pointers would be the more common case in the code |
| 20:48.47 | brlcad | they're not that different conceptually |
| 20:49.19 | brlcad | it's more API-design wise whether we predominantly have db_* funcs that deal in string-name terms or struct directory * terms |
| 20:49.32 | starseeker | sure - if we have functions that do argv->dp and dp->argv, it really makes no difference at all |
| 20:50.01 | brlcad | there'd be a minor performance difference if you need one vs the other and the db's were huge |
| 20:50.39 | starseeker | in that situation I imagine you'd want to stay with dp as much as possible? |
| 20:50.59 | brlcad | e.g., to walk the dirp hash, extract strings to return argv, look up each string into a dirp ... |
| 20:51.35 | brlcad | that's O(N^2) .... + N :) |
| 20:52.00 | brlcad | vs. O(N) if all you needed was the dirp |
| 20:53.41 | brlcad | hm, and it'd still be O(N) to walk the dirp hash, extract dirp array, extract string for each dirp (it's 2*N, so overall complexity is N) |
| 20:53.42 | starseeker | is actually translating the path names to dp under the hood now for search, so pushing out that step to other functions would actually reduce the logic slightly |
| 20:54.06 | brlcad | yeah, I think it needs to return dirp |
| 20:54.18 | starseeker | db_ls? |
| 20:54.21 | brlcad | otherwise that becomes very expensive and non-linearly |
| 20:54.42 | brlcad | sure |
| 20:54.53 | brlcad | lets see how it feels |
| 20:55.05 | starseeker | should I modify the search API to take directory pointers as inputs too then? |
| 20:55.17 | starseeker | guess that makes sense |
| 20:55.29 | starseeker | rolls up the coding sleeves... here we go again |
| 20:55.32 | brlcad | if it's in librt, probably |
| 20:55.49 | starseeker | where should the argv->dp and dp->argv functions live? |
| 20:56.00 | starseeker | will be needing them shortly |
| 20:56.16 | brlcad | libged should be the place where string conversions happen (even if it's by calling a db routine to do the conversion/extraction) |
| 20:56.58 | starseeker | OK - I can rough out some code in src/libged/search.c and if it looks OK we can find somewhere more general to put it |
| 20:57.04 | brlcad | need to check, wouldn't be at all surprised if one of those functions already exists somewhere |
| 20:58.00 | brlcad | I think they clearly belong in librt, notion was just that they probably already exist somewhere else |
| 20:58.54 | brlcad | maybe just put all three in a src/librt/ls.c |
| 20:59.04 | starseeker | 3? |
| 20:59.09 | starseeker | ah |
| 20:59.22 | starseeker | db_ls, db_argv_to_dp and db_db_to_argv ? |
| 20:59.30 | brlcad | db_ls() and the argv->dp and dp->argv funcs (either moving or implementing if they dont' exist somewhere) |
| 21:01.45 | brlcad | db_argv_to_dirp() db_argv_from_dirp() ? they could be separated into src/librt/argv.c instead (and there are conceivably other other to/from argv-specific calls) |
| 21:02.21 | brlcad | heh, already a db_argv_to_path() |
| 21:02.37 | starseeker | yeah, that's argv to db_full_path though :-) |
| 21:03.18 | brlcad | I just mean that it fits the convention (db_argv_*) |
| 21:03.24 | starseeker | ah :-) |
| 21:03.55 | brlcad | either becomes db_argv_*() or db_type1_to_type2() (no _from_) |
| 21:04.00 | starseeker | what does argv actually abbreviate - argument vector ? |
| 21:04.07 | brlcad | we have several other "from" funcs as it is, so nothing major there |
| 21:04.39 | brlcad | yep |
| 21:05.00 | starseeker | so would that make it db_argv_to_dpv and db_dpv_toargv ? |
| 21:05.23 | starseeker | s/db_dpv_toargv/db_dpv_to_argv |
| 21:05.35 | brlcad | argument count, argument vector ("value" also works, but I believe vector was the original intent) |
| 21:06.19 | starseeker | brlcad: how did you want to set up the enum? |
| 21:06.29 | starseeker | is reworking db_tops... |
| 21:06.44 | brlcad | see bu_fnmatch for starters |
| 21:06.56 | brlcad | it's got flags that are the same concept |
| 21:07.22 | starseeker | ah |
| 21:07.30 | brlcad | they're not wrapped in an enum, but same idea |
| 21:07.37 | starseeker | so we pass in the dbip and the flags |
| 21:07.43 | brlcad | yep |
| 21:08.32 | brlcad | get back a 'struct directory **' (a dpv, a null-terminated list of struct directory *'s)? |
| 21:08.44 | brlcad | hm, that could be a littlbe bit of a problem |
| 21:09.01 | brlcad | not a problem for db_ls() but a problem for the other two |
| 21:09.10 | starseeker | how does (or doesn't) the enum changes things vs. the int for something like this? |
| 21:09.33 | starseeker | you mean sanity checking to make sure the directory array is null terminated? |
| 21:09.52 | brlcad | so option1: db_argv_to_dpv() and db_argv_from_dpv() .. or .. option2: db_argv_to_dpv() and db_dpv_to_argv() |
| 21:10.22 | starseeker | ah. hmm |
| 21:10.32 | starseeker | is too used to the ghostscript toools |
| 21:10.39 | starseeker | pdf2ps, ps2pdf, etc. |
| 21:11.46 | brlcad | yeah, my gut feeling for years has been the same bias, just because we're not consistent and that irks me |
| 21:12.01 | brlcad | but API-design I'm not so sure |
| 21:12.05 | brlcad | design-wise |
| 21:12.22 | brlcad | they logically group together as argv functions |
| 21:12.34 | brlcad | argv strings to/from various representation types |
| 21:13.24 | brlcad | but then maybe they shouldn't .. maybe db_argv_to_path() shouldn't exist and there should instead be a db_dpv_to_path() |
| 21:14.05 | starseeker | does db_full_path have such a vector in its struct? |
| 21:14.08 | brlcad | I stay up way too late thinking about these kinds of things... |
| 21:14.13 | starseeker | hehe |
| 21:15.10 | brlcad | db_argv_to_path() is a little bit of a different beast because the ordering of the argv matters, it's not an arbitrary set of objects |
| 21:16.52 | starseeker | as long as we're on naming conventions, which one would you like to use for the db_ls enum? |
| 21:26.13 | *** join/#brlcad mpictor (~mark@c-67-177-102-131.hsd1.in.comcast.net) |
| 21:29.20 | brlcad | without any other uses yet defined, I'd stick with an 'int flags' argument, no enum/typedef to keep the API simple |
| 21:29.34 | starseeker | ok |
| 21:30.26 | brlcad | otherwise same concern I mentioned on the list earlier, it becomes a type we have to document and people reading the API have to learn |
| 21:30.42 | brlcad | bitwise flags in an int is pretty common (fnmatch, regex, ...) |
| 21:31.09 | starseeker | is there ever a situation where we can or would want to return things that match the RT_DIR_PHONY_ADDR flag? |
| 21:31.09 | brlcad | and matches several other places we have flags (debug flags, cv types, ..) |
| 21:31.57 | brlcad | look at where all that is used ... is it actually written to disk ever? |
| 21:32.05 | brlcad | if it's not, then no |
| 21:32.27 | brlcad | if it is, db_ls() should have some way to return it |
| 21:36.36 | brlcad | starseeker: fwiw, you don't need to do the D B _ S E A R C H _ P A T H expansion any longer .. slowly weeding those out as API is cleaned up |
| 21:36.56 | starseeker | oh, you mean in search.c? |
| 21:36.59 | starseeker | or in the header? |
| 21:37.01 | brlcad | they used to help differentiate public API from static/internal/private functions in the implementation files |
| 21:37.07 | brlcad | in the public headers |
| 21:37.14 | starseeker | nods |
| 21:37.43 | brlcad | as public headers, the rest is weeded out so every comment should be important for the statement that follows |
| 21:39.34 | brlcad | don't forget your HIDDEN markers on static/private/internal functions that aren't declared in a header |
| 21:40.04 | starseeker | erm |
| 21:40.08 | starseeker | forgot - will fix |
| 21:45.02 | brlcad | mpictor: awesome list of issues .. making me want to run that on our codebase |
| 21:45.13 | brlcad | were they all "anti-simplify"? |
| 21:46.48 | Notify | 03BRL-CAD:starseeker * 57636 (brlcad/trunk/src/libged/search.c brlcad/trunk/src/librt/search.c): Mark some functions as HIDDEN |
| 21:47.33 | Notify | 03BRL-CAD:tbrowder2 * 57637 brlcad/trunk/src/util/bu_opt_parse.h: reduce and modify possible arg value types |
| 21:49.01 | Notify | 03BRL-CAD:tbrowder2 * 57638 brlcad/trunk/src/util/bu_opt_parse.h: don't need char type either |
| 21:49.23 | maths22 | brlcad: I meant the list of things for brl-cad itself |
| 21:53.46 | Notify | 03BRL-CAD:tbrowder2 * 57639 brlcad/trunk/src/util/dsp_add2.c: change int to long; set char* values to 0 |
| 21:55.34 | Notify | 03BRL-CAD:tbrowder2 * 57640 brlcad/trunk/src/util/bu_opt_parse.cpp: change int handling to long; eliminate unneeded val types; start handling data mapping from TCLAP back to bu_args after successful parsing |
| 22:03.55 | brlcad | maths22: i'm afraid I don't understand, need some context or repeat |
| 22:10.41 | zero_level | brlcad: During one our disucssio, you said something about. "HIDDEN extern" |
| 22:10.57 | zero_level | And it being an error. |
| 22:11.19 | zero_level | Can you suggest me how to get rid of this. If it is an error ? |
| 22:15.09 | zero_level | c/disucssio/discussion |
| 22:15.42 | ``Erik | http://blogs.scientificamerican.com/roots-of-unity/2013/09/12/10-trig-functions-youve-never-heard-of/?WT_mc_id=SA_DD_20130913 |
| 22:23.12 | zero_level | ``Erik : Can you help me regarding "HIDDEN" ? Is it a macro ? I dont find it defined anywhere.(used searching tools) Can you point me somewhere in the code where this is defined. |
| 22:23.54 | Notify | 03BRL-CAD:starseeker * 57641 brlcad/trunk/src/librt/CMakeLists.txt: Add db_ls and related functions - comples, but not hooked up or tested - this is just initial code to drive discussion. |
| 22:25.46 | starseeker | brlcad: let me know if that's at least the right general idea. |
| 22:26.02 | zero_level | ``Erik, brlcad, starseeker : I would like to point you all to the modification in rt. (uses of icv). |
| 22:27.17 | zero_level | as per the current practice I have used UCHAR data to be sent to icv api (i.e icv_writeline(...,ICV_DATA_UCHAR) ). |
| 22:27.49 | zero_level | For specimen see L:578 in src/rt/view.c |
| 22:29.39 | zero_level | I seek your help to modify this to write double data (as produced by rt.). (Need pointer on how should I proceede =) |
| 22:29.53 | zero_level | has little idea regarding rt. |
| 22:29.57 | zero_level | :) |
| 22:37.02 | ``Erik | zero_level: HIDDEN is typically defined as static or nil, ignore it and don't use it |
| 22:38.13 | maths22 | brlcad; I asked 15:53 < maths22> brlcad: is there any website work I should/can be working on? |
| 22:38.27 | maths22 | You replyed: 23:50 < brlcad> maths22: oh my gosh yes! |
| 22:38.32 | maths22 | 23:51 < brlcad> i'll try to come up with a summary of where we're at on Monday |
| 22:47.12 | zero_level | ``Erik : thanks :) |
| 22:59.14 | mpictor | brlcad: didn't see your comment |
| 22:59.21 | mpictor | not all are anti-simplify |
| 23:00.43 | Notify | 03BRL-CAD:mohitdaga * 57642 (brlcad/trunk/src/libicv/bw.c brlcad/trunk/src/libicv/encoding.c and 3 others): Ignore HIDDEN |
| 23:01.00 | zero_level | ``Erik see r57643. |
| 23:02.02 | mpictor | there are 3 different ones for resolve.c:502; I can guess about 2 of them but not sure what anti-dce is |
| 23:02.47 | Notify | 03BRL-CAD:mohitdaga * 57643 brlcad/trunk/src/libicv/dpix.c: Ignore HIDDEN |
| 23:05.44 | mpictor | stack took a *very* long time to run on stepcode, with 8 cores at 100%, but I did force powersaving because it was running so hot |
| 23:08.17 | *** join/#brlcad kesha__ (~kesha@49.249.0.50) |
| 23:12.10 | mpictor | brlcad: script to run stack with CMake: http://pastebin.com/mHq06tAs |