| 00:20.06 | *** join/#brlcad Nohla (~jesica@190.178.94.95) |
| 01:29.02 | *** join/#brlcad ibot (ibot@rikers.org) |
| 01:29.03 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD is now available on Gentoo! (20100225) |
| 01:29.55 | brlcad | glanced again |
| 01:30.28 | brlcad | you realloc when count == max - 1 |
| 01:30.32 | CIA-43 | BRL-CAD: 03starseeker * r38161 10/brlcad/trunk/src/libgcv/obj/obj_parser.c: Something about that use of array doesn't work with realloc - just use switch (succeeds). |
| 01:30.50 | brlcad | that should probably be count >= max - 1 |
| 01:30.54 | brlcad | and you never increment count |
| 01:31.20 | starseeker | count is incremented using *curr |
| 01:31.39 | brlcad | are you only testing add_vertex? |
| 01:31.43 | brlcad | was referring to the others |
| 01:31.55 | starseeker | oh, yeah - add vertex is the only working one at the moment |
| 01:32.14 | starseeker | was just stubbing out the others |
| 01:32.16 | brlcad | ah |
| 01:33.04 | starseeker | got some thinking to do about group handling |
| 01:33.28 | starseeker | that nice little twist of allowing multiple groups on one g line makes for some complications |
| 01:35.18 | brlcad | did you understand why the previous array didn't work? |
| 01:35.38 | starseeker | kinda unfortunate that the id/id_list mechanism for matching is generic - I see why that is but it means conditional handling of an ID based on what line it appears with either has to be called from the lexer code or some funky fu is needed in yacc land... |
| 01:35.43 | starseeker | brlcad: not entirely |
| 01:36.04 | brlcad | your previous organization is much better than the version that works now :0 |
| 01:36.07 | brlcad | :) |
| 01:36.14 | brlcad | the bug was minor :) |
| 01:36.15 | starseeker | yeah, I know... |
| 01:36.21 | starseeker | aaaaaa |
| 01:36.31 | brlcad | think of the pointer values |
| 01:37.06 | brlcad | you set array's value to the value of the container |
| 01:37.20 | starseeker | right... |
| 01:37.22 | brlcad | then told realloc to give you a bigger one |
| 01:37.26 | brlcad | which it does |
| 01:37.40 | brlcad | which is set as the new array value |
| 01:37.56 | starseeker | do I need to reset the container value to the array value now? |
| 01:37.59 | brlcad | the original container pointer still points to the old colntainer |
| 01:38.27 | brlcad | you probably want the address of that container, not the container itself |
| 01:38.34 | starseeker | restrains some colorful words and makes use of svn merge.. |
| 01:39.03 | brlcad | so when you set array to a new allocation, you're modifying the original pointer |
| 01:39.12 | brlcad | (i.e., a pointer to a pointer) |
| 01:39.31 | brlcad | point_t **array; |
| 01:40.23 | ``Erik | hm, reallocs? yuh oh |
| 01:41.23 | ``Erik | realloc has performance implications on various platforms, linux does some really ugly page remapping to make it fast at the cost of opening up some possible attack vectors, phkmalloc is... significantly slower but builds physically cohesive pages iirc |
| 01:41.24 | brlcad | also block-size allocations would probably work better, and a bigger step size |
| 01:41.28 | starseeker | ``Erik: plus getting cute about using the same array logic for multiple structures |
| 01:42.05 | ``Erik | (names, phkmalloc() will allocate a full new buffer, copy the data, then free the old buffer) |
| 01:42.23 | brlcad | think how many vertices there might be "on average", go up to the next power of two |
| 01:42.39 | ``Erik | justin was using realloc for every triangle or something in early adrt's and it'd take frrrrreverrr on fbsd :) |
| 01:43.05 | ``Erik | (also; try to allocate in page multiples) |
| 01:44.10 | starseeker | brlcad: I can get the address of the container (point_t **) but then what? If I (point_t **)bu_malloc to that I get a bus error |
| 01:46.07 | starseeker | here's something cheap... |
| 01:46.30 | CIA-43 | BRL-CAD: 03brlcad * r38162 10/brlcad/trunk/src/libbu/units.c: unbreak compilation, no exactly floating point comparisons |
| 01:46.46 | CIA-43 | BRL-CAD: 03starseeker * r38163 10/brlcad/trunk/src/libgcv/obj/obj_parser.c: Try this for array realloc... |
| 01:46.47 | brlcad | that new string function seems wholly wrong |
| 01:47.56 | brlcad | not only does it malloc up a new vls instead of using one passed to it .. it's just generating a comma-separated list of all values, which seems to defeat the purpose of unit management |
| 01:48.26 | brlcad | starseeker: you don't bu_malloc/realloc to the ** |
| 01:48.36 | brlcad | you alloc to the same thing as before, to the * |
| 01:49.06 | starseeker | committed something that seems to work... |
| 01:49.23 | ``Erik | he assigns the ** using a & |
| 01:49.32 | starseeker | ``Erik: uh... define page multiples? |
| 01:49.37 | brlcad | thinks starseeker needs to work through the classic towers of hanoi CS homework assignment ;) |
| 01:50.24 | ``Erik | page size is typically 4k, sometimes 1k... a sub-page alloc has extra overhead to try to pack it into an existing page |
| 01:50.26 | brlcad | starseeker: better, now get rid of newarray |
| 01:50.57 | ``Erik | a page is the smallest chunk of 'real' memory the machine can do anything with... :) |
| 01:52.04 | CIA-43 | BRL-CAD: 03starseeker * r38164 10/brlcad/trunk/src/libgcv/obj/obj_parser.c: get rid of unneeded variable. |
| 01:52.31 | starseeker | ``Erik: does C offer some sort of sizeof variation to report the current machine's page size? |
| 01:52.33 | brlcad | make sense now? |
| 01:52.43 | starseeker | nods |
| 01:52.47 | starseeker | yep |
| 01:52.52 | ``Erik | um, there's usually a #define in one of the headers |
| 01:52.59 | brlcad | make sense why the previous didn't work? |
| 01:54.18 | starseeker | I believe so - when I was working directly on the "array" and not its pointer, I wasn't actually getting the new memory location |
| 01:54.38 | brlcad | you were getting the new memory from realloc |
| 01:54.49 | brlcad | you were just never changing the struct |
| 01:55.04 | starseeker | OK. |
| 01:55.56 | starseeker | so the struct wasn't getting the word, as it were, and kept treating the array as if it was the original size? |
| 01:56.31 | ``Erik | ah, getpagesize() :D |
| 01:57.52 | starseeker | makes a note to look at the towers of hanoi problem... I'll get this down someday, doggone it... |
| 01:58.02 | brlcad | array = A ; vertices.geometric = G; initially A->0 and G->B ; then A->B ; realloc makes A->C .. but is still G->B |
| 01:58.57 | ``Erik | (see, starseeker might do it lispy and just go recursive, just evading the thing you're trying to point out... *cough* :D ) |
| 01:59.38 | starseeker | so array is actually a copy of the original value of the pointer value of G (B), and changing the contents of A has no implication as far as the contents of G are concerned |
| 03:00.39 | *** join/#brlcad ibot (ibot@rikers.org) |
| 03:00.39 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD is now available on Gentoo! (20100225) |
| 04:00.27 | *** join/#brlcad PrezKennedyII (Matthew@whitecalf.net) |
| 04:03.04 | jack | wtf :) |
| 04:03.18 | jack | there are so many different kinds of cancer |
| 04:03.32 | jack | i doubt they'll really have it under control in 10 years |
| 04:25.47 | brlcad | which is why it's mind-boggling |
| 04:25.56 | brlcad | conceivable |
| 04:26.17 | brlcad | if it works as well as it's seeming, it's targeted protein suppression in cells |
| 04:28.08 | brlcad | and as complex of a problem of variants as there is, there could just as easily be an explosion of industry behind it |
| 04:29.00 | brlcad | catering to the variants and even other disease types |
| 04:31.03 | brlcad | consider the marget that exploded (no pun intended) behind erectile disfunction medication .. and that wasn't life threatening or as costly with major funded foundations hunting for cures |
| 04:31.36 | brlcad | if it can make it past phase III for any cancer, it's going to be huge |
| 04:32.18 | brlcad | s/marget/market/ |
| 04:34.29 | brlcad | average approal and testing cycle for products going to market is 7 to 8 years, and can be fast-tracked in about half that time |
| 04:35.34 | brlcad | leaves a good bit of time for industry to diversify and expand if proven successful |
| 04:37.35 | Ralith | brlcad: wow, seriously? |
| 04:37.37 | Ralith | got a link? |
| 04:38.19 | brlcad | http://gizmodo.com/5501103/this-is-the-future-of-the-fight-against-cancer |
| 04:38.27 | Ralith | I'm under the impression that cancer is along the lines of the ultimate "if nothing else kills you, this thing will" |
| 04:38.40 | Ralith | making this a major step towards massively extended lifespan |
| 04:39.27 | Ralith | and here I thought that nanotech healing magic was science fiction. |
| 04:40.08 | brlcad | not massively extended beyond current lifespan limits, but certainly would have the potential to raise the mean |
| 04:40.36 | Ralith | it's a start, anyway. |
| 04:40.52 | brlcad | we're still heavily bound by about 7 fundamental factors that lead to cell death |
| 04:40.59 | Ralith | only 7? |
| 04:41.15 | brlcad | 7 nobel prizes in wait? |
| 04:41.20 | Ralith | I'm hoping so. |
| 04:41.23 | brlcad | they're non-all non-trivial |
| 04:41.40 | brlcad | er, yeah, what I meant not what I wrote ;) |
| 04:41.43 | Ralith | ^^ |
| 04:42.05 | Ralith | a nontrivial problem is solved with every thesis. |
| 04:42.11 | Ralith | (well, in theory anyway) |
| 04:42.17 | brlcad | cure any one of those and average lifespan only increases a few years |
| 04:42.34 | brlcad | cure them all and we don't really know what will happen |
| 04:43.07 | Ralith | probably we'll hit another wall moderately further down the line. |
| 04:43.07 | brlcad | conceivably unbounded (not unlike a few organisms already on the planet) |
| 04:43.44 | Ralith | it seems optimistic that the human body would just happen to be perfectly capable of maintaining itself indefinitely, once the immediate barriers are broken down (those are the programmed ones, right?) |
| 04:44.14 | Ralith | but, if we can get that far, it seems perfectly reasonable to believe that anything of that nature too would be surmountable. |
| 04:44.52 | Ralith | I wonder if this cancer thing has applications in gene therapy. |
| 04:45.03 | Ralith | it seems to be functionally related, though I'm no biologist. |
| 04:45.31 | brlcad | to employ the classic car analogy, some of the factors are like running out of oil, running tires to blowout, and rust |
| 04:47.27 | brlcad | the research this builds on is Ribonucleic acid interference (research from about 10 years ago |
| 04:47.31 | brlcad | RNAi |
| 04:47.55 | brlcad | which won a nobel prize a few years ago |
| 04:48.33 | brlcad | which is a form of gene theragpy |
| 04:48.44 | brlcad | or at least applicable ot it |
| 04:59.11 | Ralith | fun |
| 04:59.19 | Ralith | well, here's to hoping everything goes as planned! |
| 07:43.23 | *** join/#brlcad Nohla (~jesica@190.178.66.21) |
| 08:22.13 | jack | :) |
| 08:22.46 | jack | we knew already that the nanobots industry will grab for cancer patients first |
| 08:22.55 | jack | too much money to get there |
| 08:50.53 | *** join/#brlcad mafm (~mafm@83.45.253.170) |
| 10:31.18 | Ralith | I didn't know it was likely to be applicable. |
| 13:08.22 | CIA-43 | BRL-CAD: 03erikgreenwald * r38165 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: start "point gluing" for when a cube vertex is exactly on the surface |
| 13:24.58 | CIA-43 | BRL-CAD: 03Term Papers 07http://brlcad.org * r2206 10/wiki/Talk:Main_Page: New section: [[Talk:Main Page#Term Papers|Term Papers]] |
| 13:27.10 | CIA-43 | BRL-CAD: 03Term Papers 07http://brlcad.org * r2207 10/wiki/Talk:Main_Page: /* Term Papers */ |
| 13:46.52 | CIA-43 | BRL-CAD: 03erikgreenwald * r38166 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: woops, pointerized that |
| 13:48.44 | ``Erik | the article indicates that the nanobots have to be pretty specifically programmed and are one shot things, still need to catch it, diagnose it correctly, then go through a whole treatment series... O.o mebbe some day we'll get an annual preventative slurry though *shrug* |
| 14:25.41 | CIA-43 | BRL-CAD: 03brlcad * r38167 10/brlcad/trunk/src/libgcv/Makefile.am: need the .in for distcheck |
| 14:42.22 | CIA-43 | BRL-CAD: 03brlcad * r38168 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: comment out exact floating point comparison |
| 15:05.58 | ``Erik | heh. |
| 15:06.14 | ``Erik | got a problem with bit encoding in a floating point number? O.o |
| 15:08.02 | CIA-43 | BRL-CAD: 03erikgreenwald * r38169 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: use near zero, even though it might introduce errors. should be ok for the current test case |
| 15:47.30 | brlcad | not particularly, got a problem with a halted strict build |
| 15:52.05 | CIA-43 | BRL-CAD: 03brlcad * r38170 10/brlcad/trunk/src/libgcv/Makefile.am: clean up the Makefile since we're not yet traversing into that directory. |
| 16:45.38 | *** join/#brlcad parigaudi (~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
| 16:47.57 | CIA-43 | BRL-CAD: 03indianlarry * r38171 10/brlcad/trunk/src/libged/edcodes.c: Added HIDDEN definition back on edcodes_collect_regnames() for 'static' function declaration consistency. |
| 17:26.37 | *** join/#brlcad PrezKennedy (Matthew@whitecalf.net) |
| 17:40.24 | CIA-43 | BRL-CAD: 03r_weiss * r38172 10/brlcad/trunk/src/conv/ (Makefile.am obj-g_new.c): Experimental code for new obj-g conversion based on lex/yacc obj parsing. |
| 17:47.07 | brlcad | woot |
| 17:48.01 | ``Erik | (with much effort from starseeker) |
| 17:48.19 | brlcad | I bet |
| 17:59.44 | CIA-43 | BRL-CAD: 03erikgreenwald * r38173 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: remove one of the many magic #'s |
| 18:03.25 | starseeker | tries converting a sphere into nmg and bot to see what happens... |
| 18:03.40 | ``Erik | hrm? using whick? |
| 18:03.41 | ``Erik | which? |
| 18:04.11 | ``Erik | the, uh, natural way of the code right now is for simple midpoint use... it'll work right but be blocky |
| 18:04.19 | starseeker | the existing routines, not marching cubes |
| 18:04.20 | ``Erik | the 'neat' stuff requires code modification to exercise |
| 18:04.27 | ``Erik | oh, that works well |
| 18:04.32 | ``Erik | :D |
| 18:04.51 | starseeker | brlcad was mentioning regressions, and we do need to stablize ahead of release... |
| 18:04.56 | ``Erik | it's nmg_bool.c that causes... issues |
| 18:06.04 | ``Erik | (converting to a bot is just cnverting to nmg, then printing out the faces as triangles...) |
| 18:09.06 | CIA-43 | BRL-CAD: 03Sean 07http://brlcad.org * r2208 10/wiki/Talk:Main_Page: Reverted edits by [[Special:Contributions/Term Papers|Term Papers]] ([[User talk:Term Papers|Talk]]); changed back to last version by [[User:Ssd|Ssd]] |
| 18:09.57 | CIA-43 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Term Papers]] with an expiry time of infinite (account creation disabled): Spamming links to external sites |
| 18:20.40 | CIA-43 | BRL-CAD: 03Sean 07http://brlcad.org * r2209 10/wiki/Talk:Main_Page: /* BRL-CAD Primitives */ reference tmp/primitives/ |
| 19:14.59 | starseeker | looks like 7.16.2 is OK |
| 19:15.25 | starseeker | only breaks in head with the BoT option to facetize - nmg succeeds |
| 19:15.43 | starseeker | checks 7.16.4... |
| 19:18.08 | CIA-43 | BRL-CAD: 03indianlarry * r38174 10/brlcad/branches/STABLE/src/libged/edcodes.c: |
| 19:18.08 | CIA-43 | BRL-CAD: Merge changes to 'edcodes.c' from main trunk that fixes a forward function |
| 19:18.08 | CIA-43 | BRL-CAD: declaration needed to compile brlcad with debug disabled. This merge represents |
| 19:18.08 | CIA-43 | BRL-CAD: two small related revisions to the main trunk, 37579 and 38171, since release |
| 19:18.08 | CIA-43 | BRL-CAD: 7.16.6. |
| 19:18.51 | ``Erik | O.O |
| 19:28.17 | *** join/#brlcad Nohla (~jesica@201.255.254.170) |
| 19:49.25 | starseeker | unless I bungled the test, 7.16.6 succeeds |
| 19:50.29 | CIA-43 | BRL-CAD: 03erikgreenwald * r38175 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri_mc.c: de-macro the hit function. Move primary ray stepping up to detection and use edges array for "current" intersection. Add more tolerancing. Step cross-rays back a bit. |
| 20:16.50 | *** join/#brlcad R0b0t1 (~Enigma@unaffiliated/r0b0t1) |
| 21:52.11 | starseeker | OK up through 37632 |
| 21:57.17 | CIA-43 | BRL-CAD: 03r_weiss * r38176 10/brlcad/trunk/src/conv/obj-g_new.c: reworking to remove redundant vertices |
| 21:58.16 | brlcad | yay, distcheck all passes |
| 21:58.25 | brlcad | with all configurations |
| 22:00.51 | brlcad | four configurations: all+warnings, warnings, all+optimized+warnings, optimized+warnings |
| 22:01.03 | starseeker | sweeet |
| 22:18.56 | starseeker | OK through 37768 |
| 22:29.29 | CIA-43 | BRL-CAD: 03brlcad * r38177 10/brlcad/trunk/configure.ac: |
| 22:29.30 | CIA-43 | BRL-CAD: remove the -gstabs+ option since it's causing problems on 64-bit systems, |
| 22:29.30 | CIA-43 | BRL-CAD: including an internal compiler error with gcc 4.1.3; instead use -ggdb3 and will |
| 22:29.30 | CIA-43 | BRL-CAD: have to revist debugging into mac dylibs (as they were the original motivator) |
| 22:44.06 | ``Erik | heh, was sitting here jabbing at the home theater remote wondering why it wasn't turning on... one of the cats unplugged it O.o |
| 23:33.58 | *** join/#brlcad Ralith (~ralith@69.90.48.97) |