00:05.32 |
brlcad |
crdueck: sph would be perfectly suitable
(doesn't get any simpler) |
00:06.09 |
CIA-128 |
BRL-CAD: 03tbrowder2 * r49848
10/brlcad/trunk/src/vdeck/ (cgarbs.c match.c parsarg.c): ws,
style |
00:09.20 |
crdueck |
brlcad: yes exactly, i'm just confused as to
how primitive "objects" are passed to functions. also, is it
appropriate to be asking these types of questions or should i be
answering these myself? I have been reading lots of source and
trying to figure it out for myself before asking here but i'm still
confused. |
00:09.57 |
brlcad |
crdueck: all primitives define a set of
callbacks (see src/librt/primitives/table.c) -- you're basically
stubbing in a new function for use in a future callback |
00:10.23 |
brlcad |
it's perfectly appropriate to ask these types
of questions, you're not expected to just figure stuff out on your
own |
00:13.07 |
brlcad |
it's hard enough to write the code, this isn't
academic -- we want you to learn the code |
00:13.32 |
brlcad |
questions are just fine, the more specific you
can make them the better |
00:14.09 |
brlcad |
basically, you'd be adding a function that
takes an rt_db_internal, and you go from there to figure out the
area |
00:15.06 |
brlcad |
maybe something with a signature like: int
rt_ell_volume(fastf_t *volume, const struct rt_db_internal
*ip); |
00:16.07 |
brlcad |
for volume, none are defined yet so you'd be
stubbing in the first one |
00:16.45 |
crdueck |
okay, so i see that rt_db_internal has fields
idb_{major,minor}_type, what do these represent? the type of
primitive? |
00:17.44 |
brlcad |
yes |
00:18.12 |
brlcad |
that's an unwrapped database object |
00:18.58 |
brlcad |
if you look at rt_sph_prep() you'll see how to
crack out the actual rt_ell_internal from it |
00:24.54 |
crdueck |
by casting the rt_db_internal as a
rt_ell_internal and accessing the idb_ptr field |
00:25.04 |
crdueck |
and that contains the relevent vectors a,b,c
to define the ell |
00:25.09 |
crdueck |
relevant* |
00:30.05 |
brlcad |
yes, include/rtgeom.h has the
definition |
01:19.04 |
brlcad |
if you really want to get fancy, you could
create a test harness that proves the implementation is correct
with a few specific test cases (similar to
src/libbu/test_*.c) |
01:19.25 |
brlcad |
examples creating objects programmatically in
src/proc-db (e.g. src/proc-db/csgbrep.cpp) |
01:21.48 |
crdueck |
i'm still having trouble compiling the svn
version unfortunately. i'm going to sort that out but i wanted to
get my hands dirty with a patch first. like you said, there's time
to get everything in working order after the application
deadline |
01:27.05 |
CIA-128 |
BRL-CAD: 03tbrowder2 * r49849
10/brlcad/trunk/src/conv/comgeom/comgeom-g.1: correct
typo |
01:28.45 |
CIA-128 |
BRL-CAD: 03tbrowder2 * r49850
10/brlcad/trunk/src/conv/comgeom/comgeom-g.1: correct example for
current usage |
01:38.00 |
brlcad |
nods |
01:45.23 |
starseeker |
for those looking for a good patch topic - the
function rt_bot_bbox does not currently create a correct bounding
box |
01:51.12 |
starseeker |
the function rt_bot_prep_pieces_ in
src/librt/primitives/bot/g_bot_include.c does produce a good
bounding box, so something about that logic is not captured
correctly by rt_bot_bbox |
01:53.12 |
brlcad |
starseeker: I was just looking at that, but a
quick check of the function looks like it just iterates over
vertices, no? |
01:53.53 |
starseeker |
that was the idea, but there's some quirk I
didn't track down successfully |
01:54.12 |
starseeker |
I think you were the one who noticed it wasn't
working originally... |
01:54.29 |
brlcad |
I did, but then I don't remember the
problem |
01:54.44 |
starseeker |
bbox was too big |
01:55.11 |
brlcad |
I remember the brep bbox being too big because
of the way it was aligning |
01:55.45 |
brlcad |
but for bot, I just remember it being
"different" and giving rt changes |
01:55.49 |
starseeker |
brep has other issues, IIRC - I think the bbox
is calculated without factoring in the trims |
01:56.52 |
brlcad |
well, either way that'd be a good one to
suggest to the list, maybe with a hint on how to test it |
01:57.23 |
starseeker |
svn diff -r46385:46386 shows it was turned
off, so reversing that will turn it back on |
01:58.06 |
brlcad |
I didn't suggest it to the nurbs guy just
because I thought it'd be better to see nurbs code from him, but
bot bbox was the first thing that came to mind actually |
01:59.58 |
CIA-128 |
BRL-CAD: 03tbrowder2 * r49851
10/brlcad/trunk/src/conv/comgeom/ (cvt.c f2a.c mat.c read.c
region.c solid.c): ws, style |
03:03.47 |
*** join/#brlcad louipc
(~louipc@archlinux/fellow/louipc) |
03:39.13 |
*** join/#brlcad abhi2011
(~chatzilla@24-176-220-90.static.lnbh.ca.charter.com) |
04:11.11 |
CIA-128 |
BRL-CAD: 03Crdueck 07http://brlcad.org * r3405
10/wiki/User:Crdueck: GSoC 2012 - crdueck ~WIP~ |
04:17.36 |
*** join/#brlcad witness123
(~witness@14.139.228.211) |
04:54.50 |
*** join/#brlcad witness123
(~witness@14.139.228.211) |
05:31.54 |
*** join/#brlcad Neil__
(~chatzilla@117.229.20.128) |
05:39.46 |
*** join/#brlcad Stattrav_
(~Stattrav@61.12.114.82) |
06:41.28 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
07:05.32 |
*** join/#brlcad andrei_
(~andrei@188.25.175.75) |
07:05.36 |
andrei_ |
hello |
07:17.42 |
*** join/#brlcad Stattrav_
(~Stattrav@61.12.114.82) |
07:20.33 |
*** join/#brlcad witness123
(~witness@14.139.228.211) |
07:24.05 |
*** join/#brlcad witness123
(~witness@14.139.228.211) |
07:24.13 |
*** join/#brlcad Stattrav_
(~Stattrav@61.12.114.82) |
07:29.15 |
andrei_ |
I m running the script from http://brlcad.org/wiki/Code_Cleanup
on the brlcad svn-source. This is the output I recieve. In my
opinion the 20k duplicated lines doesn't sound as much. Can someone
please check the output I posted is correct ? |
07:30.02 |
andrei_ |
I m executing http://pastebin.ca/2134240 while
having both brlcad source , simian and the script in the same
directory. This is the output I recieve : http://pastebin.ca/2134240 |
07:42.05 |
andrei_ |
<PROTECTED> |
08:27.25 |
*** join/#brlcad witness123
(~witness@14.139.228.211) |
08:34.18 |
*** join/#brlcad Stattrav_
(~Stattrav@61.12.114.82) |
08:39.31 |
*** join/#brlcad stas
(~stas@188.24.36.145) |
08:46.03 |
*** join/#brlcad witness123
(~witness@14.139.228.211) |
08:51.58 |
*** join/#brlcad witness_
(~witness@14.139.228.211) |
09:17.45 |
*** join/#brlcad Al_Da_Best
(~Al_Da_Bes@027e71f6.bb.sky.com) |
09:20.09 |
*** join/#brlcad stas
(~stas@188.24.36.145) |
09:36.21 |
*** join/#brlcad andrei_
(~andrei@188.25.175.75) |
09:37.23 |
*** join/#brlcad andrei_
(~andrei@188.25.175.75) |
10:33.38 |
*** join/#brlcad atneik
(~atneik@59.178.154.162) |
10:46.02 |
*** join/#brlcad Stattrav_
(~Stattrav@61.12.114.82) |
11:02.38 |
*** join/#brlcad witness123
(~witness@14.139.228.211) |
11:21.00 |
*** join/#brlcad witness123
(~witness@14.139.228.211) |
12:08.40 |
*** part/#brlcad atneik
(~atneik@59.178.154.162) |
12:35.28 |
*** join/#brlcad cristina
(~cristina@188.24.64.167) |
12:35.31 |
cristina |
hello |
12:52.37 |
Al_Da_Best |
Hi |
13:00.44 |
andrei_ |
hey ( just had to be a different greeting
way) |
13:01.55 |
``Erik |
yargh, mateys, shiver me timbers |
13:59.20 |
starseeker |
cristina: howdy |
13:59.49 |
starseeker |
cristina: just curious, were you still
interested in the CSG visualization project? |
14:02.51 |
starseeker |
If so, you might be interested in this
CMake-based Goblin source tarball, which has the part of Goblin we
can use: http://bzflag.bz/~starseeker/goblin-2.8b30-cmake.tar.gz |
14:20.38 |
brlcad |
andrei_: a coverity scan account could
certainly be provided, but there's only a couple dozen issues
remaining (maybe a week's worth of work) |
14:21.57 |
brlcad |
andrei_: as for the quantity of duplication,
that's not entirely relevant because you probably won't get through
more than a few thousand lines in one summer regardless of there
being 100k or 20k |
14:22.20 |
brlcad |
that said I think your simian settings could
probably be relaxed a little / changed to detect more patterns of
duplication |
14:22.51 |
brlcad |
if you read the simian manpage, you might find
some more duplication |
14:23.05 |
brlcad |
cristina: how's the proposal coming
along? |
14:24.13 |
cristina |
brlcad, my proposal is not ready yet |
14:24.28 |
*** join/#brlcad atneik_
(~atneik@59.178.154.162) |
14:24.35 |
cristina |
I'm behind the schedule |
14:24.45 |
brlcad |
andrei_: oh, also if you want to schedule time
in your proposal to work on coverity issues, that's fine but it
probably shouldn't account for more than a couple weeks of
work |
14:24.55 |
brlcad |
cristina: ok |
14:25.13 |
brlcad |
do you know if you might have a rough draft
sometime early this week? |
14:25.51 |
brlcad |
it'd be nice to see at least a rough draft
three or four days before the submission deadline so we have to
provide feedback and you have time to respond to that
feedback |
14:26.38 |
andrei_ |
brlcad : I don't know if you noted , I
submitted the latest version of my proposal draft here :
https://docs.google.com/file/d/0BzrcTnxrBIMvdlFuMTFNWkFRX3FEMU9qbU1JUW9Hdw/edit |
14:27.05 |
brlcad |
I did not, can't keep track of everyone
:) |
14:27.23 |
cristina |
brlcad I know that it's useful to get feedback
and I'll try to make it |
14:27.58 |
brlcad |
cristina: that would be fantastic, especially
given how interesting and useful that project is, hopefully
something you're excited to work on :) |
14:28.14 |
andrei_ |
sorry, I didn't want to make it sound like a
reproach |
14:29.47 |
cristina |
:-) |
14:30.29 |
andrei_ |
brlcad : anyhow , I have two main issues with
my proposal. Focusing on a very specific part of code ( I wil
follow your advice regarding simian) and the deliverable section I
don t know how to fit it to be neither unrealistic nor
insufficient |
14:31.44 |
brlcad |
andrei_: so especially for a code refactoring
project, it's great to scope out some goals and be realistic, but
that is also the easiest type of project to rescope and change
direction on once you've started |
14:32.44 |
andrei_ |
so I should have a strict plan and follow it
closesly |
14:32.47 |
*** part/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
14:32.48 |
brlcad |
so you could work on the largest line counts
first, just working down the list; or you could hit up all the
issues in a given directory; etc .. but the approach doesn't matter
as much as having some initial plan to begin with |
14:33.46 |
brlcad |
we just need something measureable so that we
can determine whether you're making progress or whether we need to
adjust your goals |
14:34.36 |
*** part/#brlcad atneik_
(~atneik@59.178.154.162) |
14:34.42 |
brlcad |
so you can just pick a plan that is appealing
to you, is conservatively reasonable based on your skills, and then
just go to town with patches until you get commit access |
14:35.02 |
brlcad |
I think you already did a patch,
yes? |
14:35.06 |
andrei_ |
yes |
14:35.17 |
brlcad |
so that's great |
14:35.25 |
andrei_ |
you mentioned the "patch" to remove a global
var |
14:35.34 |
brlcad |
right, that's an easy starting point |
14:35.51 |
brlcad |
another might be to actually fix just one of
the simian duplications |
14:36.23 |
andrei_ |
so it's an actual acceptable approach to
follow the simian output |
14:36.30 |
brlcad |
sure |
14:36.53 |
andrei_ |
I m not sure how I should change the script
provided , in order to be more relevant for my cause |
14:37.32 |
brlcad |
it doesn't even matter whether you start from
the top to bottom, bottom to top, or even out of order as long as
there's a method to the madness ;) |
14:37.54 |
brlcad |
andrei_: do you understand what the script is
doing? |
14:38.20 |
andrei_ |
<PROTECTED> |
14:38.30 |
andrei_ |
it goes through every file in the specified
path |
14:38.39 |
andrei_ |
excluding the stated paths |
14:39.38 |
andrei_ |
basically it uses simian for every file in
source with the selected extension except for those with
-not |
14:39.46 |
starseeker |
cristina: if you're having trouble scoping the
project or working out design ideas, please feel free to discuss
them in channel |
14:39.59 |
starseeker |
that's why we're here :-) |
14:40.11 |
brlcad |
andrei_: that's basically correct |
14:40.35 |
brlcad |
it runs the 'find' command to get a list of
some files (man find) and then it runs the simian command on that
list of files |
14:40.52 |
andrei_ |
it something like ./find | grep " what
interests me " |
14:41.11 |
starseeker |
cristina: we aren't expecting you to have a
fully mature, polished solution written up in the first
draft |
14:41.27 |
starseeker |
refinement is a normal part of the
process |
14:41.29 |
brlcad |
andrei_: yeah, sorta |
14:41.45 |
brlcad |
andrei_: so assuming you're in the right
directory, the list of files is what it is |
14:41.58 |
brlcad |
you can then just focus on the simian
command |
14:42.29 |
brlcad |
if you read the simian manual page and look at
the line in the script, you'll see that right now the wiki page
example just passes the -threshold=25 option |
14:42.39 |
brlcad |
there are LOTS of other options iirc |
14:42.59 |
brlcad |
plus you could get rid of that threshold
option and you'll see a lot more |
14:43.31 |
andrei_ |
you have a point |
14:43.52 |
andrei_ |
I need a better understanding of Simian to
have a good starting point |
14:44.00 |
brlcad |
again, that aspect doesn't really matter so
much right now either other than you should at least read the
simian manual page and be basically familiar with what it's capable
of if you're going to propose using it all summer ;) |
14:44.28 |
brlcad |
the 20k you have is certainly plenty and more
than you could work on all summer anyways |
14:45.00 |
andrei_ |
after this discussion I believe that
aswell... |
14:46.19 |
brlcad |
even if you're some amazing hot-shot and you
got through all 20k in the first month and you actually didn't
introduce bad API or bugs, it's VERY easy to find more work for you
-- no worries there whatsoever. ;) |
14:46.38 |
andrei_ |
haha |
14:46.57 |
*** join/#brlcad Stattrav_
(~Stattrav@61.12.114.82) |
14:47.26 |
brlcad |
I wouldn't expect more than 5% reduction when
you add in time for discussion and refactoring that goes along with
reducing code |
14:48.19 |
brlcad |
because usually the best way to eliminate
duplication isn't to just make a new function -- it's to utilize an
existing function and completely rewriting the place where there
was duplication |
14:48.19 |
andrei_ |
my issue right now is simian and the fact that
I have never used it before |
14:48.37 |
brlcad |
so that is your priority |
14:48.40 |
brlcad |
read the simian docs |
14:49.03 |
brlcad |
shouldn't take more than an hour even if
you're slow and fall asleep :) |
14:49.13 |
brlcad |
more likely, 10 minutes |
14:49.22 |
andrei_ |
oh |
14:49.30 |
andrei_ |
if you mean the overview they have on their
site |
14:49.39 |
andrei_ |
I have read it when I downloaded
simian |
14:49.39 |
brlcad |
wherever they have their docs |
14:50.11 |
brlcad |
I mean, can you tell me without looking what
that -threshold=25 does? hopefully you can if you're using
it |
14:50.44 |
brlcad |
if not, worth re-reading |
14:50.48 |
andrei_ |
<PROTECTED> |
14:50.51 |
andrei_ |
how "deep" to go? |
14:51.00 |
brlcad |
nope :) |
14:51.59 |
brlcad |
so, all that means is it's worth re-reading
the docs again, now especially that you're run the tool and are a
little familiar with the output |
14:52.17 |
andrei_ |
ah |
14:52.18 |
brlcad |
it might make more sense and "stick"
better |
14:52.30 |
andrei_ |
I found exactly what I was looking for, I
found a page that explain each parameter and what it does |
14:53.03 |
andrei_ |
as I didn't manage to find any manual in
simian before. I do need to have a better look |
14:56.34 |
andrei_ |
so threshold tells simian to ignore files with
less than 25 duplicated lines |
14:59.40 |
*** join/#brlcad stas
(~stas@188.24.36.145) |
15:03.45 |
andrei_ |
this is how I currently run the script . I
consider this a bit better for what I need |
15:03.52 |
andrei_ |
java -Xms200m -Xmx2000m -jar simian-2.3.33.jar
-threshold=10 -reportDuplicateText $files |
15:06.58 |
andrei_ |
in any case, thanks a lot for the help:) will
get back to work. |
15:52.50 |
cristina |
starseeker, I looked through the
functionalities of the Goblin library and I got the idea that their
C++ methods could be used to implement the back end graph
structures |
15:53.40 |
brlcad |
andrei_: no problem, good discussion |
15:55.12 |
cristina |
I'm not familiar with tcl/tk so I'm having
some trouble understanding how to use these structures in order to
construct the graphical widgets |
16:18.47 |
brlcad |
cristina: so you have two choices with respect
to the gui -- you can aim on implementing something near-term or
long-term |
16:19.20 |
brlcad |
near-term being some time less than 3 years
and long-term probably greater |
16:19.57 |
brlcad |
the difference being the near-term is learning
the tcl/tk capabilities of archer, learning how to use their
widgets and running with that |
16:21.28 |
brlcad |
long-term would be to use Qt or some drawing
layer that works with Qt canvases or OGRE opengl contexts |
16:22.00 |
brlcad |
the latter is arguably easier if you don't
know Tcl/Tk but wouldn't be a capability put into use for quite
some time |
16:23.22 |
brlcad |
basically, more flexibility in the long-term
but more rapid development and widespread use with a near-term
approach |
16:23.33 |
brlcad |
(tcl/tk is really pretty easy to
learn) |
16:23.48 |
*** join/#brlcad matovitch
(5c672642@gateway/web/freenode/ip.92.103.38.66) |
16:23.53 |
matovitch |
hello |
16:23.56 |
brlcad |
so something to keep in mind |
16:23.58 |
brlcad |
hello matovitch |
16:34.03 |
cristina |
brlcad, I assume it's better if the result of
this project would be put in use sooner |
16:34.14 |
cristina |
I see that there's still a migration to archer
phase. Is this why you mentioned the 3 year period? |
16:34.17 |
brlcad |
both are valuable, it's what is more
interesting to you |
16:34.38 |
brlcad |
yes, migration TO archer is still under way
and will take at *least* 2-3 years |
16:35.08 |
brlcad |
archer will stay in use then for 2-5 years
afterwards probably while a new interface is built up |
16:35.29 |
cristina |
aha, so I would have to make use of the
capabilities of mged and later, after they are entirely migrated,
use the ones of archer? |
17:01.50 |
*** join/#brlcad stas
(~stas@188.24.36.145) |
17:02.20 |
brlcad |
cristina: no entiendo |
17:03.00 |
brlcad |
if you use tcl/tk, you do have access to all
of the current capabilities of mged/archer now (which is a
lot) |
17:03.41 |
brlcad |
whereas with Qt, you'd have to implement a lot
more low-level access to walk the hierarchy (not hard, but it'd be
another week or two of work) |
17:06.43 |
cristina |
brlcad: ok. yo entiendo ahora |
17:08.41 |
cristina |
I misunderstood something. I thought archer is
going to replace mged |
17:09.43 |
brlcad |
it is |
17:10.40 |
brlcad |
for all intensive purposes, they are one in
the same .. archer is about to go into alpha status and will
"merge" with mged within the next two years |
17:11.11 |
brlcad |
it all depends on the length of the alpha and
beta timeframes, but it's estimated to be around 2-3
years |
17:12.08 |
brlcad |
the underpinnings to archer are nearly
identical to mged, though, so the real difference would be with a
qt-interface |
17:15.09 |
cristina |
this is what I wanted to know. If there are
any differences between mged and archer on the tcl/tk capabilities
that I'm going to learn |
17:28.30 |
brlcad |
there are some differences, but they're pretty
minor -- archer and mged share most of the same underlying commands
that you'd use |
18:07.28 |
starseeker |
cristina: for a CSG viewing widget, you would
actually be creating (initially) a stand-alone Tcl/Tk widget with
an API, and then hooking that into mged/archer as a second step (as
I understand it) |
18:07.40 |
starseeker |
assuming you go the Tcl/Tk route, of
course |
18:11.10 |
starseeker |
when it comes to the "get geometry
information" aspects, there are several possibilities - you can
either use commands at the Tcl/Tk level, or use BRL-CAD's C library
API's "behind the scenes" - you'll probably be doing a bit of both,
at different levels |
18:14.40 |
starseeker |
To create the widget, the pieces needed are a)
ability to extract BRL-CAD's geometry hierarchy and format it in
such a way that it can be fed to a graph layout API (Goblin or some
other choice) b) take the output from the graph generator and use
that to create a visual layout (in Tcl/Tk or some other toolkit)
and c) make the visual layout interactive |
18:17.24 |
starseeker |
That gives you some milestones to focus on,
since each stage builds on the previous stages and the individual
stages can each be tested |
18:19.31 |
starseeker |
Goblin has an application in it called goblet
that does some visual graph layouts, so that's a starting
point |
18:20.05 |
starseeker |
or at least, something to study to see how c++
data -> tcl/tk graphics can be accomplished |
18:21.50 |
*** join/#brlcad Al_Da_Best
(~Al_Da_Bes@027e71f6.bb.sky.com) |
18:22.19 |
starseeker |
cristina: if you don't have time to work out
all the details of how you would generate the visual widgets, then
that's something to schedule in your timeline for your
application |
18:29.50 |
*** join/#brlcad witness123
(~witness@14.139.228.211) |
18:41.26 |
CIA-128 |
BRL-CAD: 03Matovitch 07http://brlcad.org * r3406
10/wiki/User:Matovitch: First edit :) |
18:43.54 |
cristina |
starseeker: I am going to include a "research"
period in which I can decide this |
18:50.00 |
*** join/#brlcad matovitch
(5c672642@gateway/web/freenode/ip.92.103.38.66) |
18:50.09 |
matovitch |
hello |
18:58.31 |
CIA-128 |
BRL-CAD: 03starseeker * r49852
10/brlcad/trunk/src/other/CMakeLists.txt: Mark the SCL variables as
advanced |
18:59.22 |
*** join/#brlcad harmanpreet
(~chatzilla@210.56.122.39) |
19:00.52 |
*** join/#brlcad merzo
(~merzo@79-79-133-95.pool.ukrtel.net) |
19:01.45 |
harmanpreet |
hi..!! may I know how can I made page on wiki
of brlcad? I created my account, but couldn't find any way to
create page there. |
19:02.15 |
matovitch |
I had the same problem. ^^ |
19:02.38 |
matovitch |
Your page is already create. |
19:03.09 |
matovitch |
Go to the /User:your_name and edit |
19:04.31 |
Al_Da_Best |
Welcome to Wiki's :P Yeah, every page exists
as soon as it gets edited |
19:16.44 |
harmanpreet |
thanks matovitch..!! |
19:16.56 |
matovitch |
you're welcome |
19:26.49 |
andrei_ |
brlcad : I have just finishing removing a
global variable , but it does fit the word "minimal" a bit too
good. |
19:27.51 |
andrei_ |
there is a counter in /libbu/ globals.c called
bu_n_realloc which is incremented by a function in malloc.c but is
never used aside of that |
19:27.56 |
andrei_ |
I have simply commented it. |
19:42.54 |
andrei_ |
and the same with bu_n_malloc |
19:43.29 |
andrei_ |
are they still needed in case of debugs, or is
this a acceptable fix? |
20:18.41 |
bhinesley |
brlcad: I'm working on a proposal for adding
-exec to the search command. |
20:19.02 |
bhinesley |
we've talked before about registering libged
commands, so that a list of them can be obtained |
20:19.17 |
bhinesley |
can't seem to find the relevant log
entries... |
20:19.47 |
bhinesley |
but it seems this will be necessary for the
project |
20:20.41 |
bhinesley |
I'm assuming there is a particular way you'd
like this implemented..? |
20:22.51 |
bhinesley |
I'll give you a chance to respond before I ask
you anything specific :) |
20:26.48 |
CIA-128 |
BRL-CAD: 03tbrowder2 * r49853
10/brlcad/trunk/src/vdeck/ (cgarbs.c std.h): ws, align code
chunks |
20:34.43 |
andrei_ |
if those above-stated are acceptable global
removals , on what should I move on? Moving to Simian
output? |
20:38.24 |
CIA-128 |
BRL-CAD: 03Matovitch 07http://brlcad.org * r3407
10/wiki/User:Matovitch: |
20:38.32 |
CIA-128 |
BRL-CAD: 03tbrowder2 * r49854
10/brlcad/trunk/src/vdeck/cgarbs.c: update K&R to ANSII C
function arg style |
20:39.34 |
CIA-128 |
BRL-CAD: 03tbrowder2 * r49855
10/brlcad/trunk/src/vdeck/vdeck.c: ws, style |
20:40.00 |
CIA-128 |
BRL-CAD: 03Matovitch 07http://brlcad.org * r3408
10/wiki/User:Matovitch: |
20:43.34 |
brlcad |
andrei_: I'm thinking you didn't attempt a
recompile |
20:44.06 |
brlcad |
try this: grep bu_n_malloc src/*/*.c |
20:44.10 |
andrei_ |
I did |
20:44.24 |
andrei_ |
and I used eclipse to check the dependencies
upon /libbu/ |
20:44.38 |
andrei_ |
ooooh |
20:44.47 |
andrei_ |
a second |
20:45.00 |
andrei_ |
I think I ignored the upper dependencies.
Right. |
20:45.52 |
andrei_ |
src/libbu/globals.c:long bu_n_malloc =
0; |
20:45.54 |
andrei_ |
src/libbu/malloc.c:
bu_n_malloc++; |
20:45.55 |
andrei_ |
src/rt/main.c:longmdelta = bu_n_malloc -
n_malloc; |
20:45.57 |
andrei_ |
src/rt/main.c: n_malloc =
bu_n_malloc; |
20:46.00 |
andrei_ |
this is what I got. |
20:46.07 |
brlcad |
I know the result, no need to paste it
:) |
20:46.58 |
andrei_ |
it could be added as a parameter to the hidden
function |
20:47.43 |
andrei_ |
anyhow, so much for the quick joy. Thanks for
help and getting back to fixing this properly. |
21:05.42 |
crdueck |
i've posted a first draft of my application to
the wiki, it's still very rough and i'd very much appreciate any
feedback. you can find it here: http://brlcad.org/wiki/User:Crdueck
thanks |
21:06.58 |
CIA-128 |
BRL-CAD: 03tbrowder2 * r49856
10/brlcad/trunk/src/vdeck/vdeck.c: ws |
21:08.01 |
CIA-128 |
BRL-CAD: 03Bhinesley 07http://brlcad.org * r3409
10/wiki/User:Bhinesley/gsoc2012/search_proposal: /* Prior
commitments */ |
21:17.26 |
CIA-128 |
BRL-CAD: 03tbrowder2 * r49857
10/brlcad/trunk/src/conv/comgeom/ (3d.h solid.c tools.c):
ws |
21:29.55 |
*** join/#brlcad witness123
(~witness@14.139.228.211) |
21:58.27 |
*** join/#brlcad witness123
(~witness@14.139.228.211) |
22:20.25 |
CIA-128 |
BRL-CAD: 03Bhinesley 07http://brlcad.org * r3410
10/wiki/User:Bhinesley/gsoc2012/search_proposal: /* Summary */ aka
outline (for the more in depth "description" section) |