| 00:56.01 | brlcad | DarkCalf: howdy |
| 00:56.56 | Notify | 03BRL-CAD:starseeker * 60375 (brlcad/trunk/src/libbu/encode.c brlcad/trunk/src/libbu/tests/bu_encode.c): Make a stab at escaping for Tcl. The real test will be assignment and recovery from Tcl variables. |
| 00:57.07 | brlcad | starseeker: quoting and escaping go hand-in-hand and are the general way to deal with it without making it language-specific |
| 01:02.00 | brlcad | intentionally tried to avoid introducing a notion of "encoding" as that can get very messy |
| 01:06.21 | brlcad | starseeker: note that what I started on encode.c ... I eventually started moving away from that in favor of the more generalized interface in escape.c |
| 01:06.50 | brlcad | that may be what you need anyways -- you pass an expression of char(s) to escape |
| 01:23.04 | *** join/#brlcad dli (~dli@66.49.141.210) | |
| 01:51.02 | Notify | 03BRL-CAD:starseeker * 60376 brlcad/trunk/src/librt/db_match.c: Try the tcl-ified bu_vls_encode in db_regexp_match_all |
| 02:03.42 | Zhao_Anqing | starseeker: hi |
| 02:04.30 | Zhao_Anqing | I facetize all models of toyjeep.g and it cause a nmg_bool failure. |
| 02:04.48 | Zhao_Anqing | So that's a bug should be fixed? |
| 02:04.55 | brlcad | yep |
| 02:05.09 | brlcad | any failure is one that we'd hope to someday fixed |
| 02:06.03 | Zhao_Anqing | OK. get it. Let me try to debug this. |
| 02:06.18 | brlcad | don't spend more than a couple hours on it |
| 02:06.24 | brlcad | nmg debugging can be quite complicated |
| 02:08.37 | Zhao_Anqing | That's fine. |
| 02:21.36 | Notify | 03BRL-CAD:brlcad * 60377 brlcad/trunk/include/ged.h: the problem is really the result should not be a simple string. it needs to be a result set and the calling application can format the result however it needs to (so there's no need for encoding or quoting whatsoever) |
| 02:21.40 | brlcad | Zhao_Anqing: feel free to discuss or ask questions -- that's why we're here ;) |
| 02:23.32 | Zhao_Anqing | Thanks you very much. That's really kind of you. |
| 02:23.36 | Zhao_Anqing | ^-^ |
| 02:24.58 | brlcad | starseeker: haha, I just read 60371 ... that's very close to the thought processes that let to bu_str_escape() |
| 02:27.20 | Zhao_Anqing | What's the meaning of the dot-line, when I display a model? |
| 02:27.42 | Zhao_Anqing | for example, the pink car. |
| 02:27.47 | Notify | 03BRL-CAD:brlcad * 60378 brlcad/trunk/include/bu/vls.h: see bu_str_escape() as it evolved out of a nearly identical thought process |
| 02:27.53 | brlcad | a dotted line is usually something being subtracted |
| 02:32.45 | starseeker | brlcad: OK, what I shoved into encode should probably be the guts of escape then... |
| 02:33.09 | starseeker | or may already be... |
| 02:33.51 | starseeker | ah, probably better |
| 02:34.31 | starseeker | bingo |
| 02:35.04 | starseeker | brlcad: so... is there a reason bu_str_escape and friends haven't been used to swat the Tcl command line issues? |
| 02:35.41 | starseeker | also, what are we going to do with encode/decode? honest-to-goodness hex and base64 support? |
| 02:36.11 | starseeker | is thinking to use that to let breps survive g-asc -> asc-g roundtrip |
| 02:36.56 | brlcad | starseeker: no reason at all ... |
| 02:36.59 | brlcad | I started with the quote approach just like you did |
| 02:37.06 | brlcad | and realized the limitations/problems |
| 02:37.16 | brlcad | started working on general escaping, got that implemented |
| 02:37.22 | brlcad | then got pulled off onto something else |
| 02:37.32 | starseeker | ah :-) |
| 02:37.45 | starseeker | OK, I'll try to clean up my mess and use bu_str_escape |
| 02:37.55 | brlcad | the intent is/was to go back and either scrap the quoting/encoding interface or make it call escape |
| 02:38.44 | brlcad | I wasn't willing to just rip out bu_vls_encode() because it was far better tested and already working very well |
| 02:39.17 | brlcad | bu_str_escape should be good to go, but all I have to prove it is .. butkus |
| 02:39.19 | starseeker | the potential increase in importing makes resolving the funny-name issues a priority now |
| 02:39.37 | starseeker | nods - OK, I'll put the encode/decode logic back the way it was |
| 02:39.55 | brlcad | I don't think it matters much |
| 02:41.26 | brlcad | I'm inclined to kill that API for simplicity if we end up not using it because it is probably directly replaced with bu_str_escape() |
| 02:41.36 | brlcad | now *encoding* is still a completely different topic |
| 02:41.47 | brlcad | if we do end up needing that, api will need to be revisited |
| 02:41.53 | starseeker | nods |
| 02:42.20 | brlcad | I had trouble seeing a bonefide need outside of the geometry service |
| 02:43.01 | brlcad | the crux of this particular issue with "ls" is a GED api issue .. that it can't/doesn't return a set |
| 02:43.22 | brlcad | that's actually not so hard to fix |
| 02:43.32 | starseeker | wants to turn the binary serialization of brep objects into base64 text for asc output. We don't have the resources to design an asc representation for something as complex as brep right now, but we need to do *something* to let asc continue to function |
| 02:43.47 | starseeker | brlcad: oh, you mean rework libged to not rely on strings? |
| 02:44.01 | brlcad | well it's still a string (a set of strings) |
| 02:44.11 | starseeker | argv array? |
| 02:44.52 | brlcad | that or an opaque struct that contains an array, accessed by a func |
| 02:45.15 | brlcad | something like ged_append_result(...) |
| 02:45.18 | starseeker | winces. that's a major rework of the ged API |
| 02:45.25 | starseeker | and its callees |
| 02:45.26 | brlcad | nah, it's like just a line or two |
| 02:46.02 | brlcad | all the CALLEEs are a pita to make them go from bu_vls_printf() and Tcl_AppendResult() to ged_whatever() |
| 02:46.20 | starseeker | we'll still need the tcl escaping for the object names too... |
| 02:46.40 | starseeker | regardless of the container, if the strings can't make it into tcl variables intact weird things are likely |
| 02:46.45 | brlcad | sure, but ged doesn't need to do that |
| 02:46.49 | brlcad | tcl can do that |
| 02:47.06 | brlcad | rather, it's the application calling libged's responsibility |
| 02:47.13 | starseeker | ah |
| 02:47.13 | brlcad | ged just returns the data |
| 02:47.18 | brlcad | the app formats it |
| 02:47.49 | starseeker | OK, so as long as ged gives it to the app in an unambiguous form (instead of the inherently ambiguous string) the app has a fair shot at doing that |
| 02:47.52 | brlcad | say it goes into a list or menu or dialog or needs quotes or is unicode-encoded or whatever.. that's the apps problem |
| 02:48.02 | brlcad | right |
| 02:48.39 | brlcad | I *think* we can get away with a simple null-terminated homogenous array of strings for our current commands |
| 02:48.51 | starseeker | I think that *does* involve some changes to ged functions though - everywhere a results string is assembled in libged, something different will have to be done - either append to the argv or stockpile in the struct that the function will call... |
| 02:48.53 | brlcad | haven't exhaustively looked, but think that'll be fine |
| 02:49.07 | brlcad | exactly! |
| 02:49.11 | brlcad | and that's a few hundred lines |
| 02:49.18 | brlcad | not terrible conversion though |
| 02:49.29 | brlcad | it's all the places that reference ged_result_str |
| 02:49.50 | brlcad | that's why I'm inclined to turn them all into funcs and an opaque pointer |
| 02:50.02 | brlcad | so if we want to change it again, the app doesn't know or care |
| 02:50.05 | brlcad | all internal to libged |
| 02:50.15 | starseeker | um. Makes sense. |
| 02:50.25 | brlcad | is glad to be feeling slightly better that he can think clearly again |
| 02:50.28 | starseeker | heh |
| 02:50.40 | starseeker | if you feel like stubbing out the API, I can start the grunt work |
| 02:50.47 | brlcad | I did laugh when I saw your comment |
| 02:51.12 | starseeker | really doesn't want the STEP improvements to run smack into "the GUI can't do squat with this import" issues... |
| 02:51.32 | starseeker | oh, when i started down the path you'd already walked? |
| 02:54.36 | brlcad | no, your musings in the header about ... "well, the caller might want to escape different chars ... and if they do that then this should probably be different api .. and if it's different api, probably doesn't need to be using vls strings ... and so on" |
| 02:55.28 | starseeker | ah :-) |
| 02:55.43 | brlcad | that's basically the thought process I went through |
| 02:55.56 | brlcad | albeit over a couple days I think |
| 02:58.51 | Notify | 03BRL-CAD:starseeker * 60379 (brlcad/trunk/src/libged/ls.c brlcad/trunk/src/librt/db_match.c brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl): Pull the chances impacting command functionality - should be using bu_str_escape and friends to do the tcl quoting, and should be happening at the app level once we teach libged to return something that lets us operate properly on a list of object names (problem is libged |
| 02:58.53 | Notify | returning a space separated list, when spaces are in the object names it needs to be returning as well...) |
| 03:02.44 | starseeker | brlcad: will the container be a void pointer, or do we expose some bu structure? |
| 03:03.59 | starseeker | (bu_list or bu_ptbl for easy iterating perhaps?) |
| 03:08.04 | starseeker | we may want to expose bu_str_escape as a tcl command, like we do with bu_brlcad_data... Been meaning to do that for bu_temp_file as well |
| 03:49.49 | hcurtis | brlcad: Hi, Sean. My revised proposal is on Melange. |
| 04:08.59 | brlcad | starseeker: I was thinking a ged structure, not an existing bu container just so it can be changed at will, with accessor functions defined |
| 04:09.42 | brlcad | can maybe start with a simple null-terminated argv IFF we can assume there will be no NULL results coming back |
| 04:10.04 | brlcad | hcurtis: glad to hear it |
| 04:41.56 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 04:50.00 | *** join/#brlcad stevegt_ (~stevegt@50.242.72.226) | |
| 05:46.17 | *** join/#brlcad infinite_ (~infinite@14.139.122.114) | |
| 05:57.20 | *** join/#brlcad hoiji (671b082a@gateway/web/cgi-irc/kiwiirc.com/ip.103.27.8.42) | |
| 06:14.20 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 06:32.07 | Notify | 03BRL-CAD Wiki:Clouddrift * 7013 /wiki/User:Clouddrift/GSoC2014: /* Schedule */ |
| 06:35.40 | *** join/#brlcad infinite__ (~infinite@14.139.122.114) | |
| 06:38.17 | Notify | 03BRL-CAD Wiki:Clouddrift * 7014 /wiki/User:Clouddrift/GSoC2014: /* Schedule */ |
| 06:51.12 | *** join/#brlcad merzo (~merzo@user-94-45-58-138-1.skif.com.ua) | |
| 06:59.01 | *** join/#brlcad infinite__ (~infinite@14.139.122.114) | |
| 07:04.35 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 07:07.11 | *** join/#brlcad luca79 (~luca@host199-110-dynamic.9-87-r.retail.telecomitalia.it) | |
| 07:58.57 | *** join/#brlcad infinite__ (~infinite@14.139.122.114) | |
| 08:04.59 | *** join/#brlcad hcurtis (b82d2950@gateway/web/freenode/ip.184.45.41.80) | |
| 08:13.53 | *** join/#brlcad infinite__ (~infinite@14.139.122.114) | |
| 08:26.10 | infinite__ | bu_vls_printf is doing what exactly? PS: I am reading the relevant code but would be helpful if someone who has worked on it could just brief me once. Where is it exactly printing? |
| 09:27.46 | *** join/#brlcad javampire (~ncsaba@p4FF70623.dip0.t-ipconnect.de) | |
| 10:32.19 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 10:35.01 | *** join/#brlcad dli (~dli@66.49.141.210) | |
| 11:13.09 | *** join/#brlcad infinite__ (~infinite@14.139.122.114) | |
| 11:39.57 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 12:01.03 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) | |
| 12:18.03 | *** join/#brlcad Denis_ (~denisilie@141.85.225.204) | |
| 12:31.19 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 12:31.36 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 12:59.05 | *** join/#brlcad luca79 (~luca@host191-29-dynamic.4-87-r.retail.telecomitalia.it) | |
| 13:14.04 | *** join/#brlcad richa (uid11933@gateway/web/irccloud.com/x-axensgkydgncpfuu) | |
| 13:18.36 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 13:32.10 | *** join/#brlcad infinite__ (~infinite@14.139.122.114) | |
| 13:45.35 | Notify | 03BRL-CAD Wiki:William.ng * 0 /wiki/User:William.ng: |
| 13:58.20 | starseeker | brlcad: so, struct ged_results with the contents accessed by functions? |
| 14:00.00 | starseeker | e.g. char *ged_result_string(struct ged_results *ret) ? |
| 14:00.32 | starseeker | size_t ged_result_cnt(struct ged_results *ret) |
| 14:01.21 | starseeker | char *ged_result_get(struct ged_results *ret, size_t index) |
| 14:01.36 | *** join/#brlcad ries (~ries@190.9.171.121) | |
| 14:13.42 | infinite__ | brlcad : Hi! I have been researching and reading the code for voxelization and raytracing, I would essentially like to improve the efficiency of generating voxels, by introducing parallelism as done in ray tracing, would it be nice implementing something resembling http://jcgt.org/published/0002/01/02/paper.pdf? |
| 14:13.47 | *** join/#brlcad hoiji (73f1f878@gateway/web/cgi-irc/kiwiirc.com/ip.115.241.248.120) | |
| 14:21.44 | Notify | 03BRL-CAD:starseeker * 60380 brlcad/branches/openscenegraph/src/mged/dm-osg.cpp: Include fbio.h |
| 14:38.06 | Notify | 03BRL-CAD:starseeker * 60381 (brlcad/trunk/include/ged.h brlcad/trunk/src/libged/ged_private.h): Start working on an API for ged results returning. Way to introduce it incrementally will be to have a (part of ged_private.h, probably not needed as public API) function ged_results_add which updates both ged_results and the return vls at the same time - that way everything will look the same to functions expecting the |
| 14:38.08 | Notify | results string until we can update them. Can we get away with having *just* the struct ged_results; decaration in ged.h and let the more specific definition with (for the moment) the bu_ptbl as contents live in ged_private.h? |
| 14:38.17 | *** join/#brlcad ries_nicked (~ries@190.9.171.121) | |
| 14:43.46 | Notify | 03BRL-CAD:starseeker * 60382 brlcad/trunk/include/ged.h: Not sure about returning one string for everything - maybe a worthwhile convenience, but a bit dubious given a simple iteration and vls build can produce the same result... |
| 14:53.14 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 14:58.29 | d_rossberg | infinite__: the paper descibes a method for triangulized boundary representations we don't have ... or i'm missing something? |
| 15:16.16 | *** join/#brlcad infinite__ (~infinite@14.139.122.114) | |
| 15:32.13 | Notify | 03BRL-CAD:d_rossberg * 60383 (rt^3/trunk/include/brlcad/FileDatabase.h rt^3/trunk/src/coreInterface/FileDatabase.cpp): itf the file doesn't exist create it |
| 15:34.34 | *** join/#brlcad gaganjyot__ (~gagan@27.255.252.57) | |
| 15:57.00 | *** join/#brlcad pandrei (~pandrei@188.26.182.115) | |
| 16:15.41 | *** join/#brlcad hoiji (671b082a@gateway/web/cgi-irc/kiwiirc.com/ip.103.27.8.42) | |
| 17:03.00 | *** join/#brlcad infinite__ (~infinite@14.139.122.114) | |
| 17:07.49 | *** join/#brlcad kesha (~kesha@14.139.122.114) | |
| 17:09.26 | *** join/#brlcad hcurtis (b82d2950@gateway/web/freenode/ip.184.45.41.80) | |
| 17:13.31 | *** join/#brlcad jasleen_ (~chatzilla@117.253.202.223) | |
| 17:26.10 | *** join/#brlcad infinite__ (~infinite@14.139.122.114) | |
| 17:35.10 | brlcad | interesting: http://code.google.com/p/muparserx/ |
| 17:36.12 | brlcad | infinite__: hello .. is this for gsoc or on your own? |
| 17:36.26 | *** join/#brlcad FOSScookie (~brian@107-200-34-31.lightspeed.tulsok.sbcglobal.net) | |
| 17:37.00 | brlcad | infinite__: that paper assumes polygonal geometry |
| 17:37.42 | brlcad | ah and what d_rossberg noted too but when you weren't here |
| 17:40.23 | *** join/#brlcad stevegt_ (~stevegt@cislunar.TerraLuna.Org) | |
| 17:57.05 | *** join/#brlcad hoiji (671b082a@gateway/web/cgi-irc/kiwiirc.com/ip.103.27.8.42) | |
| 18:18.04 | infinite__ | brlcad : was unable to connect, sorry for that, there is some problem in LAN connection here, would be fixed soon. That was essentially not for gsoc, I realize the article is not intersecting, but I think we could make use of http://luebke.us/publications/eg09.pdf to boost efficiency |
| 18:30.17 | *** join/#brlcad cstirk (~charlie@c-71-56-216-45.hsd1.co.comcast.net) | |
| 18:35.11 | brlcad | infinite__: you are missing the repeated responses that the paper involves polygonal geometry, which we don't have |
| 18:42.19 | *** join/#brlcad ries_nicked (~ries@190.9.171.121) | |
| 18:46.24 | infinite__ | brlcad: I think I have understood something wrong, can you brief me about the concept of bounding box |
| 18:48.26 | *** join/#brlcad infinite__ (~infinite@14.139.122.114) | |
| 18:50.03 | *** join/#brlcad infinite (~infinite@14.139.122.114) | |
| 18:50.31 | *** join/#brlcad infinite (~infinite@14.139.122.114) | |
| 19:08.30 | brlcad | infinite: it's a box that fits around something |
| 19:08.40 | infinite | PS: The paper http://luebke.us/publications/eg09.pdf is different from the one I cited before, |
| 19:08.43 | brlcad | your question is both confusing and concerning |
| 19:09.50 | brlcad | I know that paper, same comment still applies |
| 19:11.54 | brlcad | at least to an extent, we could benefit from having a SAH implemented per primitive to improve spatial partitioning |
| 19:13.04 | brlcad | infinite: I think you need to explain some context, what you're hoping to decide or research or achieve |
| 19:18.54 | infinite | There lies scope to improve the speed of rt. Instead of the way we are following right now, the algorithm presented in paper , if implemented for rt_bound_tree would fasten up the process. |
| 19:24.46 | brlcad | do you know how much of performance is currently consumed or affected by the performance rt_bound_tre() ? |
| 19:30.44 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 19:32.20 | *** join/#brlcad FOSScookie (~brian@107-200-34-31.lightspeed.tulsok.sbcglobal.net) | |
| 19:33.06 | Notify | 03BRL-CAD:starseeker * 60384 (brlcad/trunk/src/libged/ged_private.h brlcad/trunk/src/libged/ged_util.c): apparently the other 'append' functions weren't used anywhere. |
| 19:34.42 | *** join/#brlcad LordOfBikes (~armin@dslb-088-066-134-078.pools.arcor-ip.net) | |
| 19:36.06 | brlcad | infinite: you're certainly on a good track, but know that any work to improve performance should be preceded by performance profiling |
| 19:37.12 | brlcad | that said, for the voxelization program, you should start first by just making it parallel (we have many examples of this in brl-cad)) |
| 19:42.44 | infinite | using semaphores, as in raytracing, right? But genuinely speaking, I am doubtful if that much would suffice as the work for GSoC project, so I am analysing what additionally I can do |
| 19:49.01 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 19:49.27 | *** part/#brlcad jasleen_ (~chatzilla@117.253.202.223) | |
| 19:54.38 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) | |
| 19:55.01 | brlcad | infinite: yes and no ... if you parallelize well enough, there are no semaphores |
| 19:58.18 | brlcad | there's a LOT that g-voxel could be made to do that would be incredibly useful |
| 20:01.37 | brlcad | support for output formats, conversion of voxelized data back into geometry (voxel-g) |
| 20:04.07 | brlcad | improvement of our voxel geometry data type (vol) |
| 20:04.08 | brlcad | etc |
| 20:04.21 | brlcad | should talk to daniel about his thoughts if you're looking for other suggestions |
| 20:07.42 | *** join/#brlcad merzo (~merzo@86-79-132-95.pool.ukrtel.net) | |
| 20:16.38 | *** join/#brlcad gaganjyot__ (~gagan@27.255.252.57) | |
| 20:19.28 | brlcad | starseeker: you can't just write into a vls's char* |
| 20:19.57 | brlcad | Notify: hello |
| 20:22.29 | ``Erik | well, you can, but you're setting yourself up for Bad Things(tm) |
| 20:23.04 | ``Erik | !notify day |
| 20:23.05 | Notify | BRL-CAD: starseeker:14, brlcad:2, d_rossberg:1 |
| 20:23.07 | Notify | BRL-CAD Wiki: Sean:2, Clouddrift:2, William.ng:1 |
| 20:24.27 | infinite | For voxel-g, you said once marching cubes sucks for geometries with discontinuties, what about splatting? |
| 20:24.58 | ``Erik | what do you mean by "splatting"? O.o |
| 20:31.04 | infinite | Splatting is yet another algorithm for volume visualization, "Splatting performs a front to back object order traversal of the voxels in volumetric dataset. Each voxel's contribution to the image is calculated and composited using a series of table lookups" as described. |
| 20:35.17 | ``Erik | hm http://en.wikipedia.org/wiki/Volume_rendering#Splatting |
| 20:37.15 | ``Erik | doesn't seem appropriate for g-voxel to me from that minimal description *shrug* but I'm not digging deep, too much other stuff to worry about right now |
| 20:43.10 | Notify | 03BRL-CAD:starseeker * 60385 (brlcad/trunk/include/ged.h brlcad/trunk/src/libged/ged.c and 4 others): Make a stab at adding a functional ged_results interface. One consequence of this (or, more correctly, of the need to quote object names in applications) will be that all formatting of output (like, say, the multi-column output from ls) will need to become the responsibility of the calling application, since the |
| 20:43.12 | Notify | assembly of the final string for such multi-column output can't happen without the strings being pre-quoted. |
| 20:43.51 | brlcad | infinite: you don't get geometry from splatting, you get a visualization |
| 20:44.11 | brlcad | so yeah, maybe for interactive visualization of our vol primitive |
| 20:44.27 | brlcad | or for visualizing the results from g-voxel |
| 20:44.52 | brlcad | but the utility is practically non-existent without all of the application infrastructure so that it's easy to use |
| 20:45.01 | hcurtis | Hello, everyone. I'd like to create a patch, but I've run into problems getting set up. I've read the information on the wiki, but there seem to be multiple approaches. I'm learning about Subversion, Aptitude, CMake, etc. |
| 20:45.14 | hcurtis | I'm an entry-level programmer (but a fast learner). I use a Windows 7 PC that has Eclipse and Visual Studio. Also, I've downloaded Virtual Box and the BRL-CAD VM disk image. |
| 20:45.29 | starseeker | brlcad: where did I do that? |
| 20:45.30 | brlcad | infinite: I'd be more inclined to look at leveraging some PCL algorithm to reconstrust surfaces |
| 20:45.35 | hcurtis | I'm hoping that someone can advise me on the best approach for my situation. I'd like to get set up and start working on a patch as soon as possible. |
| 20:45.44 | starseeker | doesn't doubt it, but not immediately clicking |
| 20:46.12 | brlcad | _ged_results_add() |
| 20:46.34 | brlcad | hi henry |
| 20:47.02 | starseeker | uh... I'm inserting strings into a table there? |
| 20:47.09 | hcurtis | brlcad: Hi, Sean. |
| 20:47.50 | starseeker | brlcad: I guess my comment isn't clear, hang on |
| 20:48.04 | brlcad | ahh, I see starseeker |
| 20:48.11 | brlcad | the comment sounded like you were writing into it |
| 20:48.20 | brlcad | should be marked const |
| 20:48.41 | brlcad | should always be on the lookout for const, not just as an afterthought :) |
| 20:50.10 | brlcad | hcurtis: I see that's the exact same inquiry you left on the mailing list -- you need to ask a more specific question |
| 20:50.29 | brlcad | hcurtis: in actuality, you didn't ask a single question. |
| 20:51.03 | hcurtis | brlcad: Ok. |
| 20:51.04 | brlcad | asking for open-ended advice is not efficient, there are FAR too many variables and issues |
| 20:51.26 | Notify | 03BRL-CAD:starseeker * 60386 brlcad/trunk/src/libged/ged_private.h: Clarfiy the header comment a bit. |
| 20:51.30 | brlcad | get set up and try to do something, discuss as you go along, ask questions if you get stuck |
| 20:52.28 | starseeker | brlcad: I think I set that up so the guts aren't exposed - bu_ptbl was convenient for me for testing, but I was trying to do the "hide the details" approach |
| 20:52.38 | hcurtis | brlcad: That's the problem. I _am_ stuck. |
| 20:53.14 | starseeker | hcurtis: trying to do... which task? |
| 20:53.35 | hcurtis | brlcad: And my best guess is that you and the other mentors want this patch ASAP. |
| 20:54.54 | hcurtis | starseeker: I need to be able to compile the code for my patch. |
| 20:55.10 | starseeker | what problem is your patch trying to address? |
| 20:56.43 | hcurtis | I am going to attempt one involving the implementation of a primitive surface area function. |
| 20:56.48 | starseeker | brlcad: I think I've also got an approach that will allow a gradual migration off of the result_str - perhaps we could even keep it in some cases, although it's not immediately clear that would be a good idea |
| 20:57.06 | starseeker | hcurtis: OK, there are lots of examples |
| 20:57.41 | brlcad | hcurtis: yes, any patches really need to be in by sunday to have any bearing |
| 20:58.04 | brlcad | ideally today or tomorrow |
| 20:58.18 | starseeker | hcurtis: look at the existing functions for primitives that have them - the new one will be hooked in the same way, but the "guts" will be different |
| 20:58.29 | hcurtis | starseeker: But I'm not actually there working on the patch yet. I've never done this before, and I'm still trying to get my computer ready to do it. |
| 20:58.45 | brlcad | now you're getting more specific! :) |
| 20:58.45 | starseeker | hcurtis: can you build BRL-CAD? |
| 20:59.08 | hcurtis | brlcad: You're teaching me well. |
| 20:59.29 | brlcad | hcurtis: see my reply on the mailing list, I think that might help |
| 20:59.43 | hcurtis | starseeker: That's my problem. I don't yet know. |
| 20:59.50 | starseeker | uh... |
| 21:00.25 | brlcad | hcurtis: so try to build, see where you get stuck |
| 21:00.34 | brlcad | you said you read the wiki page |
| 21:00.41 | brlcad | it provides step-by-step instruction |
| 21:00.43 | starseeker | how can you not know yet? Where are you on this process? http://brlcad.org/wiki/Compiling |
| 21:00.55 | hcurtis | starseeker: I'm an entry-level programmer, and I'm trying to learn and get better. |
| 21:01.31 | starseeker | hcurtis: that's fine, but the steps on that page are straightforward |
| 21:01.52 | hcurtis | brlcad: Thank you very much, Sean. I appreciate all that you've done to help me. |
| 21:01.55 | brlcad | that doesn't let you get away with not reading the documentation and attempting the steps :) ... if you've attempted and something didn't work, speak up and ask about it :) |
| 21:02.39 | brlcad | we're here to help, but ultimately you have to do the work without us telling you what to do |
| 21:03.12 | brlcad | when you get stuck, you need to figure out what you're actually stuck on and ask for help |
| 21:03.18 | starseeker | ``Erik: cool notify feature by the way |
| 21:03.30 | brlcad | note that getting stuck implies you *tried* something that got you into that situation |
| 21:04.31 | hcurtis | brlcad: I understand. I was never asking for a free pass. I've already spent hours working on this, and I realize that the clock is ticking. I knew it was time to ask for help. |
| 21:04.38 | brlcad | starseeker: I find it ironic that you've become so enamored with ptbls .. never would have guessed that |
| 21:05.17 | brlcad | hcurtis: that's good (well not good that you spent HOURS, but good that you realize and are asking...), now you just need to figure out what your question is |
| 21:06.12 | starseeker | brlcad: for whatever reason, I find them more intuitive to deal with than bu_list structures... |
| 21:06.34 | starseeker | brlcad: I suppose I'm over-using them lately... |
| 21:06.56 | starseeker | probably could use bu_list for some of this |
| 21:08.24 | brlcad | would be interesting to see what the performance curve of each of these looks like |
| 21:08.44 | brlcad | insertions, deletions, serial lookup, random lookup |
| 21:09.35 | starseeker | out of curiosity, which "container" would you have expected me to gravitate towards? (besides the comfy world of STL containers...) |
| 21:10.13 | hcurtis | starseeker: Here's where I am in the list at http://brlcad.org/wiki/Compiling. I was about to download CMake, but I then recalled seeing a BRL-CAD wiki page saying that I can use Eclipse, which I already have, to compile. Do I still need CMake? |
| 21:10.24 | starseeker | yes |
| 21:11.18 | starseeker | CMake generates the outputs that other tools (Eclipse, make, ninja, MSVC, etc.) use |
| 21:11.40 | hcurtis | starseeker: Ok |
| 21:12.12 | starseeker | would suggest following the procedure as documented on the wiki - it's going to use a fairly minimal subset of the tools you *can* use |
| 21:12.32 | starseeker | once you can do that, *then* look at options like Eclipse if they are helpful |
| 21:12.53 | starseeker | but the question is Eclipse vs. straight-up command line make, not vs. CMake |
| 21:13.27 | starseeker | and even that question is not one to spend time on |
| 21:13.51 | starseeker | use Make unless you have some reason to do otherwise (like a lot of skill with Eclipse) |
| 21:14.07 | hcurtis | starseeker: I understand. Thank you. |
| 21:22.35 | brlcad | hcurtis: and if you hit a wall trying to follow the steps exactly as written, try them again using the VM image .. that should work exactly as-is and get you up the fastest but obviously with an emulated environment |
| 21:27.21 | hcurtis | brlcad: Thank you. And that points to one of my underlying questions. Would it be better to use that VM environment or my usual Windows 7 environment? I wondered whether I should avoid using the VM if possible because I have only a little experience with VMs. |
| 21:28.08 | starseeker | Windows is a difficult environment to work with for BRL-CAD - if that's your normal setup, I'd recommend the VM |
| 21:28.47 | hcurtis | brlcad: I'm not saying I'm scared of VMs or something...rather, I just need to get this patch to you without running into any more complications. |
| 21:29.05 | starseeker | I definitely would *not* recommend trying CMake+Eclipse on Windows 7 - that configuration is completely untested, to the best of my knowledge, and almost certain to break |
| 21:29.45 | hcurtis | starseeker: I see. Thank you. |
| 21:31.39 | starseeker | hcurtis: you will find as you program more that Windows is kind of an alien landscape to many (even most) open source programmers - it's far more likely for them to be using an open source OS |
| 21:32.48 | starseeker | so, generally speaking, Windows issues will be harder to debug and harder to find help with. BRL-CAD is rather unusual in the level of support it provides for MSVC |
| 21:33.32 | hcurtis | starseeker and brlcad: Now, *this* is the kind of insider info I was looking for. I did read the wiki pages...however, a lot of this stuff is new to me. I am trying. I definitely appreciate your help. |
| 21:34.11 | starseeker | google and wikipedia are your friends - if you don't understand terms, don't be afraid to research them |
| 21:34.33 | starseeker | you will be doing that as long as you are doing programming - the only thing that will change is what you are studying |
| 21:35.15 | hcurtis | starseeker: Absolutely |
| 21:36.12 | starseeker | If you didn't know what CMake was, for example, you should have taken the time to read their website when you went to download it. |
| 21:38.13 | starseeker | if you want the voice of experience, I can assure you that you won't get away with *not* understanding things - you'll just end up taking longer than you had to before you are forced to learn them anway |
| 21:39.41 | starseeker | s/anway/anyway |
| 21:40.10 | starseeker | makes a note to suggest building a spellchecker into irssi to ``Erik... |
| 21:42.48 | hcurtis | starseeker: You are very right. As I was telling Sean, however, I've already spent hours getting nowhere. I realize that the clock is ticking, and I knew it was time to ask for help. I'm not the type to look for a free pass. |
| 21:50.49 | hcurtis | starseeker: Anyway, thank you once again for your information and advice. |
| 21:52.40 | *** join/#brlcad infinite_ (~infinite@14.139.122.114) | |
| 22:09.06 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 22:21.41 | *** join/#brlcad hsrai (~hsrai@202.164.53.116) | |
| 22:33.40 | ``Erik | starseeker: what, the statistics reporting? been there since just about the beginning... https://github.com/erikg/cl-cia/blob/master/irc.lisp line 124 |
| 22:38.10 | *** join/#brlcad ries (~ries@190.9.171.121) | |
| 22:38.35 | ``Erik | heh, when(spelling_errors>1)printf("Learn to spel, fool!\n"); /* spell misspelled on purpose */ |
| 22:48.06 | infinite_ | brlcad : Guess moving least squares would do well. www.google.co.in/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDAQFjAA&url=http%3A%2F%2Fwww.pointclouds.org%2Fassets%2Ficra2012%2Fsurface.pdf&ei=DC4_U7KxComErAet44DgDA&usg=AFQjCNEA0LQcvrI461SsiZIZkgWn7Jq6AA&sig2=LGaAKh7isQnfu5HbjYADqA&bvm=bv.64367178,d.bmk |
| 23:14.41 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) | |
| 23:37.13 | *** join/#brlcad ries (~ries@190.9.171.121) | |
| 23:49.49 | *** join/#brlcad infinite__ (~infinite@14.139.122.114) | |