00:36.44 |
starseeker |
phooey - FreeCAD didn't like the shape
representation definition - guess I'll have to put both styles of
shape definition in |
01:39.39 |
brlcad |
starseeker: for what it's worth, I've heard
numerous commentaries about opencascade's STEP support being pretty
terrible |
02:15.02 |
Notify |
03BRL-CAD:starseeker * 57084
brlcad/trunk/src/other/stepcode/include/ordered_attrs.h: Take a
stab at exporting the orderedAttrs functions for Windows. |
02:21.09 |
starseeker |
brlcad: fair enough, but it can load the Rhino
export of the same geometry |
02:21.25 |
starseeker |
so it's clearly worth adding the extra header
entries |
02:21.44 |
starseeker |
it's not hard, just a bit tedioius to hook up
;-) |
02:23.08 |
starseeker |
it's a bit tricky sorting out what the
actually *requried* parts of the STEP files are from the
informational entries we probably don't care about |
02:23.43 |
brlcad |
sure, not saying the course of action you
mentioned wasn't worth it |
02:23.52 |
starseeker |
longer term it might be worth seeing about
establishing some attribute conventions for _GLOBAL or something
that map to the STEP bits I'm seeing |
02:24.20 |
brlcad |
just that freecad is unreliable in terms of
correctness |
02:24.30 |
starseeker |
is currently mired in
figuring out exactly why his step export doesn't import when
Rhino's does |
02:24.49 |
starseeker |
there are geometry differences in that we are
(currently) not splitting closed loops |
02:24.56 |
starseeker |
er closed curves rather |
02:25.25 |
starseeker |
but I can't tell whether I'm just not handling
them correctly writing them out, or step-g isn't reading them in
correctly |
02:26.13 |
starseeker |
agrees freecad isn't a
benchmark of correctness |
02:27.07 |
starseeker |
they are the most logical open source export
target for our geometry though (maybe even the only other realistic
one) |
02:27.21 |
starseeker |
at least, as far as NURBS are
concerned |
02:28.11 |
starseeker |
the OCE guys were intersted in looking at
stepcode at one point, so once we've got our stuff polished up it
may make them take another look |
02:29.02 |
starseeker |
takes another run at the
bu_semaphore test as long as he's here... |
02:32.49 |
Notify |
03BRL-CAD:starseeker * 57085
brlcad/trunk/src/libbu/tests/CMakeLists.txt: Whatever needs to go
in the WINMM entry, it's gonna have to be part of the ADDEXEC
line... |
02:41.22 |
starseeker |
blinks |
02:41.41 |
starseeker |
brlcad: that might have done it - I just got a
successful build of tester_bu_semaphore on MSVC |
13:44.57 |
*** join/#brlcad infobot
(~infobot@rikers.org) |
13:44.57 |
*** topic/#brlcad is BRL-CAD
|| http://brlcad.org || logs:
http://ibot.rikers.org/%23brlcad/
|| GSoC 2013! http://brlcad.org/wiki/Google_Summer_of_Code |
14:32.43 |
Notify |
03BRL-CAD:carlmoore * 57103
brlcad/trunk/src/librt/primitives/hrt/hrt.c: remove trailing
blanks/tabs; fix spelling; supply periods in 'e.g.' |
14:50.25 |
brlcad |
heh |
14:52.48 |
brlcad |
hickoryknoll: you around? like to get a copy
of your various codes and talk about what's next :) |
14:53.08 |
Ch3ck_ |
sipping a bottle of
coke! |
15:25.25 |
zero_level_ |
hey can anyone help me switch off
[-Werror=array-bounds] flags ? |
15:28.55 |
Ch3ck_ |
brlcad: i've just submitted the patch for
stubbing an empty pull into BRL-CAD could you please apply it so I
could proceed with generating for pull_comb() subroutine? |
15:40.17 |
zero_level_ |
Izak__ : I am not sure why this is happening
on my pc. |
15:40.31 |
zero_level_ |
smthing to do with hrt.c |
15:42.36 |
zero_level_ |
at line 502 and 517 |
15:45.29 |
Izak__ |
Hoping someone helps
zero_level: turn off those flags |
15:46.56 |
Izak__ |
``Erik: How do rt_xxx_plot() functions
work? |
15:50.00 |
*** join/#brlcad kesha
(~kesha@14.139.122.114) |
15:52.25 |
*** join/#brlcad kesha
(~kesha@14.139.122.114) |
16:26.21 |
*** join/#brlcad caen23
(~caen23@92.83.172.41) |
16:45.03 |
*** join/#brlcad vladbogo
(~vlad@86.121.103.57) |
17:07.29 |
*** join/#brlcad vladbogo_
(~vlad@86.121.96.61) |
17:20.11 |
``Erik |
Izak_: they generate a list of line segments
to approximate the wireframe of the geometry in 3d space, which
something like the mged display window uses to draw the geometry
using GL_LINES... like for a BoT, it just draws the edges of the
triangles, for a sph it draws edges in a latitude/longitude
style... |
17:21.49 |
``Erik |
http://www.youtube.com/watch?v=T2DXrs0OpHU#t=20
quantum computing explained |
17:22.00 |
``Erik |
(by the dude who does phdcomic) |
17:22.42 |
``Erik |
starseeker: http://users.cms.caltech.edu/~mvanier/hacking/rants/cars.html |
17:31.48 |
starseeker |
``Erik: heh, that's awesome -
thanks! |
17:36.04 |
starseeker |
"Visual Basic - a car that drives
you" |
17:36.29 |
*** join/#brlcad Notify
(~notify@66-118-151-70.static.sagonet.net) |
17:36.36 |
Notify |
03BRL-CAD:carlmoore * 57104
brlcad/trunk/src/conv/nmg/g-nmg.c: remove unneeded brace pairs, and
re-implement -P argument in ***Usage*** statement (why did that
revert from my earlier commit?) |
17:36.40 |
Notify |
03BRL-CAD Wiki:IIIzzzaaakkk * 6028
/wiki/User:Izak/GSOC_2013_logs: /* August 19th to August 24th
*/ |
18:05.38 |
zero_level_ |
brlcad : Can you please help me regarding the
"array-bounds" flag ? |
18:14.57 |
*** join/#brlcad brlcad
(~sean@66-118-151-70.static.sagonet.net) |
18:15.37 |
*** join/#brlcad hickoryknoll
(~hickorykn@66-118-151-70.static.sagonet.net) |
18:16.11 |
*** join/#brlcad Izak_
(~Izak@66-118-151-70.static.sagonet.net) |
18:16.24 |
*** join/#brlcad n_reed
(~molto_cre@66-118-151-70.static.sagonet.net) |
18:16.25 |
*** join/#brlcad Ch3ck
(~Ch3ck@66-118-151-70.static.sagonet.net) |
18:16.42 |
*** join/#brlcad starseeker
(~starseeke@66-118-151-70.static.sagonet.net) |
18:16.42 |
*** join/#brlcad zero_level
(~mohit@66-118-151-70.static.sagonet.net) |
18:16.44 |
*** join/#brlcad ejno
(~ejno@unaffiliated/kazaik) |
18:17.20 |
*** join/#brlcad kesha
(~kesha@14.139.122.114) |
18:17.55 |
*** join/#brlcad maths22
(~gcimaths@66-118-151-70.static.sagonet.net) |
18:22.40 |
brlcad |
Izak_: the answer is NOT to turn off the
flags |
18:22.56 |
brlcad |
they are messages intended for you to fix the
problem the compiler identified |
18:23.09 |
*** join/#brlcad Notify
(~notify@66-118-151-70.static.sagonet.net) |
18:29.15 |
Notify |
03BRL-CAD Wiki:Vladbogolin * 6029
/wiki/User:Vladbogolin/GSoC2013/Logs: /* Week 10 */ |
18:40.03 |
*** join/#brlcad zero_level_
(0e8bf3a2@gateway/web/freenode/ip.14.139.243.162) |
18:40.28 |
``Erik |
:o it worked! |
18:45.44 |
Notify |
03BRL-CAD:carlmoore * 57105
brlcad/trunk/src/libicv/bw.c: remove trailing blanks/tabs |
18:50.04 |
*** join/#brlcad Izak
(~Izak@195.24.220.16) |
18:53.19 |
*** join/#brlcad Izak__
(~Izak@195.24.220.16) |
18:57.12 |
Notify |
03BRL-CAD:starseeker * 57106
brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Add more top-level
shape definition logic. Seeing differences in how these are
defined, so need to give a little thought as to what best practices
would be... |
18:59.23 |
Notify |
03BRL-CAD:brlcad * 57107 NIL: create a branch
where indianlarry can commit nurbs work in progress without any
interference to/from trunk development. |
19:00.43 |
Izak__ |
brlcad:My compiler shows me no errors. The
sextic equation has 6 roots and 7 coefficients, just as the torus'
final equation has atmost 4 roots and 5 coefficients. So I don't
understand how to fix an error I am not experiencing |
19:02.14 |
brlcad |
Izak__: newer versions of gcc are better at
warning |
19:02.47 |
brlcad |
if you are to believe the warning, what was it
saying was the problem? |
19:03.11 |
brlcad |
(and you should believe the warning, it's a
real issue) |
19:03.47 |
Notify |
03BRL-CAD:starseeker * 57108
brlcad/trunk/doc/html/CMakeLists.txt: Add logo ico file to CMake
logic |
19:03.54 |
brlcad |
``Erik: suspense is killing |
19:04.01 |
Izak__ |
It says I provided more elements than an array
could carry: BUT I never did that |
19:04.45 |
``Erik |
? |
19:04.45 |
brlcad |
14:40 < ``Erik> :o it worked! |
19:04.45 |
``Erik |
oh, notify came back with no action on my
part |
19:04.45 |
brlcad |
ah, awesome |
19:04.51 |
brlcad |
Izak__: but you did |
19:05.01 |
brlcad |
again, believe the message .. now to
understand it |
19:05.24 |
brlcad |
what exactly was the message and/or line of
code |
19:05.41 |
Izak__ |
I am using gcc 4.4.6. |
19:05.54 |
brlcad |
yep, that's ancient in gcc terms ;) |
19:06.18 |
brlcad |
gcc 4.7 and 4.8 started adding and enabling
some pretty advanced bug detection infrastructure |
19:06.42 |
``Erik |
recent clang is pretty impressive with bug
spotting and static analysis, as well |
19:06.52 |
brlcad |
yeah |
19:07.11 |
brlcad |
they both have a variant of the research that
coverity is built around |
19:07.13 |
Izak__ |
Mohit says it is line 502 and 517 of
hrt.c |
19:07.20 |
``Erik |
(fwiw, fbsd is using a fork of gcc 4.2.1 due
to license issues, so all this new shiney bug stuff is 'different'
there) |
19:07.40 |
brlcad |
Izak__: what's 502 (and do you have a log to
see the exact message?) |
19:08.56 |
Izak__ |
brlcad: This is what mohit showed me http://paste.kde.org/p4d4c4a66/ |
19:10.11 |
zero_level_ |
brlcad : in the meanwhile can you inform me
how to switch off the flag. |
19:10.37 |
zero_level_ |
I searched using grep, add_definitions , dont
see any settings ! O.o |
19:14.10 |
Izak__ |
What's happening ? |
19:17.29 |
*** join/#brlcad DarkCalf
(~DarkCalf@173.231.40.99) |
19:20.49 |
*** join/#brlcad n_reed
(~molto_cre@66-118-151-70.static.sagonet.net) |
19:21.17 |
*** join/#brlcad brlcad
(~sean@66-118-151-70.static.sagonet.net) |
19:21.36 |
*** join/#brlcad hickoryknoll
(~hickorykn@66-118-151-70.static.sagonet.net) |
19:21.46 |
*** join/#brlcad zero_level
(~mohit@66-118-151-70.static.sagonet.net) |
19:21.46 |
*** join/#brlcad maths22
(~gcimaths@66-118-151-70.static.sagonet.net) |
19:21.51 |
brlcad |
sago is fuxed today |
19:21.59 |
*** join/#brlcad ejno
(~ejno@66-118-151-70.static.sagonet.net) |
19:22.03 |
*** join/#brlcad ejno
(~ejno@unaffiliated/kazaik) |
19:22.11 |
*** join/#brlcad Izak_
(~Izak@66-118-151-70.static.sagonet.net) |
19:22.11 |
Izak__ |
why? |
19:22.21 |
*** join/#brlcad n_reed_
(~molto_cre@66-118-151-70.static.sagonet.net) |
19:22.24 |
brlcad |
these network problems |
19:22.36 |
brlcad |
their entire network keeps going
down |
19:23.03 |
brlcad |
somebody is probably attacking them, having
some friday fun |
19:23.12 |
*** join/#brlcad starseeker
(~starseeke@66-118-151-70.static.sagonet.net) |
19:23.23 |
*** join/#brlcad Notify
(~notify@66-118-151-70.static.sagonet.net) |
19:23.38 |
brlcad |
Izak__: okay, hopefully our discussion doesn't
get derailed again but lets start with the first one,
hrt.c:502:9 |
19:24.00 |
*** join/#brlcad Ch3ck
(~Ch3ck@66-118-151-70.static.sagonet.net) |
19:24.09 |
brlcad |
what is the error? |
19:24.12 |
zero_level_ |
Izak__ to smothen your discussion . |
19:24.15 |
zero_level_ |
cf is of dimension 5 |
19:24.34 |
zero_level_ |
fastf_t cf[BN_MAX_POLY_DEGREE+1]; |
19:24.44 |
brlcad |
zero_level_: the point is for him to figure
this out, no? :) |
19:24.59 |
zero_level_ |
where BN_MAX)POLY_DEGREE = 4 |
19:25.08 |
zero_level_ |
brlcad : ok. |
19:25.08 |
brlcad |
appreciated, but opportunity lost |
19:25.16 |
zero_level_ |
oops. |
19:25.53 |
brlcad |
Izak__: so there, see if you understand the
problem now |
19:26.06 |
*** part/#brlcad n_reed_
(~molto_cre@66-118-151-70.static.sagonet.net) |
19:26.32 |
zero_level_ |
brlcad : but by the look of the code i couldnt
figure out if we needed that stuff from 502 to 525 in
hrt.c |
19:28.07 |
brlcad |
well one has to know what "that stuff" means
to figure that out, yes? |
19:28.26 |
Izak__ |
zero_level: Are you saying the sextic equation
does not have roots or what? I dont follow |
19:28.51 |
brlcad |
Izak__: if you didn't follow what he just told
you, lets continue :) |
19:29.02 |
brlcad |
he basically gave you the answer to what the
problem is |
19:29.47 |
brlcad |
but if you don't see it, we can walk through
the problem to make sure you understand exactly what the compiler
is saying |
19:30.22 |
zero_level_ |
brlcad : sure. |
19:30.30 |
zero_level_ |
brlcad : let me help Izak_ here. |
19:30.43 |
zero_level_ |
I will try to guide him step by
step. |
19:31.07 |
brlcad |
zero_level_: go for it, appreciated |
19:31.39 |
zero_level_ |
Izak__ : since compilers are right. (always).
And I face this problem. So there is a problem. |
19:31.40 |
brlcad |
~zero_level++ |
19:32.16 |
Izak__ |
listening |
19:32.29 |
zero_level_ |
Izak__ : If you look at the kde.paste
link |
19:32.59 |
zero_level_ |
there is a error on line 502. at 9th
col. |
19:33.18 |
zero_level_ |
do u see this ? |
19:33.38 |
zero_level_ |
why do u think that is a problem ? |
19:33.41 |
Izak__ |
seen it |
19:34.19 |
Izak__ |
cause 5 > BN_MAX_POLY_DEGREE |
19:34.28 |
zero_level_ |
no. |
19:34.41 |
zero_level_ |
do u use grep. |
19:34.46 |
Izak__ |
yes |
19:34.55 |
zero_level_ |
what is s ? |
19:35.10 |
zero_level_ |
replace by s by S. |
19:35.22 |
zero_level_ |
so what is S ? Which data type it is
? |
19:35.54 |
Izak__ |
a polynomial |
19:36.12 |
zero_level_ |
ok. what is S.cf ? |
19:36.52 |
Izak__ |
Array of polynomial coefficients |
19:36.54 |
zero_level_ |
also find out where is the polynomial data
type defined ? |
19:36.58 |
zero_level_ |
ok. |
19:37.06 |
zero_level_ |
what is the length of the array ? |
19:40.29 |
Izak__ |
5 |
19:41.39 |
Izak__ |
there? |
19:42.21 |
zero_level_ |
can u see find if any where in the complete
src repository we have more than 4 degree of polynomial.
? |
19:43.37 |
Izak__ |
I think from bn.h the maxmum order of a
polynomial is 4 so I don't think we have more than a 4 dgr
poly |
19:44.04 |
zero_level_ |
i did grep -r "dgr = 6" |
19:44.18 |
zero_level_ |
and only got hrt.c |
19:45.00 |
starseeker |
yipe - gqa isn't happy (regression tests
failing with a stack smash) |
19:45.00 |
zero_level_ |
was just wondering if there
is a way to handle poly. with 5 or more degrees |
19:52.10 |
brlcad |
so that's the issue Izak__ |
19:52.14 |
brlcad |
there is a compile-time limit on the maximum
size of polynomials |
19:52.32 |
brlcad |
that limit is set with
BN_MAX_POLY_DEGREE |
19:52.52 |
brlcad |
do you see how the compiler message is
right? |
19:53.00 |
Izak__ |
yes |
19:53.20 |
brlcad |
do you see how just turning off the message
would be bad? :) |
19:53.37 |
Izak__ |
yeah |
19:54.02 |
brlcad |
you're indexing beyond the compile-time
defined size of that cf array |
19:54.06 |
brlcad |
So... |
19:54.11 |
brlcad |
how to fix this |
19:54.20 |
brlcad |
what's the first idea that comes to
mind? |
19:54.49 |
Izak__ |
my compiler has to be upgraded |
19:54.58 |
brlcad |
heh |
19:55.04 |
brlcad |
well all that will do is give you the
error |
19:55.08 |
brlcad |
you have the error |
19:55.19 |
brlcad |
what's the first idea that comes to mind for
fixing the error? |
19:55.40 |
Izak__ |
Making the root_solver accomodate sextic
polynomials |
19:56.29 |
brlcad |
well, yes, you obviously need to accommodate
this particular sextic polynomial |
19:56.53 |
brlcad |
but that implies the current implementation
won't handle them, which you do not know |
19:57.23 |
Izak__ |
Increment BN_MAX_POLY_DEGREE to 6 |
19:57.41 |
brlcad |
that would be the first step |
19:57.52 |
brlcad |
that will increase the array size and at least
make your lines not be errors |
19:58.18 |
brlcad |
won't mean it'll evaluate correctly or at all,
but that definitely has to happen just from a C data structures
perspective |
19:58.38 |
brlcad |
that, however, is a pretty major
change... |
19:58.39 |
Izak__ |
Work on roots.c |
19:58.42 |
brlcad |
you'll need to test it |
19:58.56 |
brlcad |
the problem won't be compilation |
19:59.17 |
brlcad |
you have to make sure that increasing the size
to 6 doesn't break any of the 4th order polynomial
evaluations |
19:59.29 |
brlcad |
fortunately, we have unit and regression tests
to confirm it |
19:59.31 |
Notify |
03BRL-CAD:starseeker * 57109
(brlcad/trunk/src/other/stepcode/src/express/test/print_attrs.c
brlcad/trunk/src/other/stepcode/src/express/test/print_schemas.c):
Wrap unistd.h as well. |
19:59.49 |
brlcad |
start there, set it to 6, compile, then run
"make test" and "make benchmark" and make sure both pass without
any failures |
20:00.08 |
brlcad |
make sure they pass without failures BEFORE
you set it to 6 too, obviously... |
20:00.16 |
brlcad |
to make sure it's in a working state before
you "compare" |
20:00.25 |
brlcad |
Izak__: make sense what you need to
do? |
20:06.08 |
Izak__ |
thankful to brlcad: and
zero_level |
20:07.23 |
brlcad |
the next step will be to confirm whether the
root solver can actually handle a stable sextic equation |
20:07.53 |
brlcad |
I suggest editing the unit test |
20:08.03 |
brlcad |
in src/libbn/tests is a roots tests |
20:08.33 |
brlcad |
you can add a 6th order test (after confirming
that BN_MAX_POLY_DEGREE=6 doesn't break anything) |
20:08.38 |
Izak__ |
was thinking of
that |
20:08.49 |
brlcad |
something with known input/output values like
the real example in http://elib.mi.sanu.ac.rs/files/journals/tm/21/tm1124.pdf |
20:12.12 |
*** join/#brlcad mpictor
(~mark@2601:d:b280:b5:d63d:7eff:fe2d:2505) |
20:13.53 |
Izak__ |
understanding what " that's
what made your gsoc proposal interesting in the first place"
means |
20:24.58 |
zero_level_ |
Izak__ , brlcad : in libbn/poly.c i dont see
any function which solves sextic polynomial. |
20:25.06 |
zero_level_ |
looks like we have to implement one. |
20:25.18 |
Ch3ck_ |
you could get started. |
20:25.19 |
Ch3ck_ |
;) |
20:25.39 |
Ch3ck_ |
since i know it's really complicated writing a
root solver of order 6 |
20:26.36 |
zero_level_ |
Ch3ck_ : I understand the
complexity. |
20:26.48 |
zero_level_ |
Just brought in because of the
discussion. |
20:27.19 |
zero_level_ |
Izak__ : Its ok. n |
20:27.23 |
Ch3ck_ |
well will check on some recent math on
resolvingthe problem. |
20:36.10 |
starseeker |
brlcad: looks like enabling the stack
protection flags is giving gqa a fit - that's when the gqa
regression test starts failing (r56758) |
20:36.15 |
Ch3ck_ |
brlcad: starseeker: waiting for the empty pull
routine patch to be applied so I could create the one for pulling
combinations in the pull |
20:39.50 |
Notify |
03BRL-CAD Wiki:NyahCh3ck20 * 6030
/wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 19 August - 25
August */ |
21:03.24 |
*** part/#brlcad Ch3ck_
(~Ch3ck@195.24.220.16) |
21:04.41 |
Ch3ck |
gotta home get some rest now
probably take on Prison Break ;) |
21:09.26 |
brlcad |
zero_level_: there's no specific support for
sextic, but it may or may not matter (for this particular
primitive) |
21:09.41 |
brlcad |
the routine used is in
src/librt/roots.c |
21:11.07 |
brlcad |
Izak_: the test program I was thinking of was
actually src/util/roots_example.c |
21:11.35 |
brlcad |
that's basically a unit test, but it predates
the current unit test infrastructure |
21:11.52 |
``Erik |
a more generalized root solver would be nice
to have in libbn |
21:12.04 |
brlcad |
if our solver doesn't work for sextic, we'll
look at integrating something more generalized (that already
exists, like gmp) |
21:12.21 |
brlcad |
but hopefully not gmp |
21:12.27 |
brlcad |
it's a pig |
21:12.48 |
Notify |
03BRL-CAD Wiki:NyahCh3ck20 * 0
/wiki/File:Pull_Combination.png: this pulls an unpushed
object |
21:14.01 |
Notify |
03BRL-CAD Wiki:NyahCh3ck20 * 0
/wiki/File:Pushed_pulled_object.png: This restores the object to
original state after push is applied |
21:15.46 |
Notify |
03BRL-CAD Wiki:NyahCh3ck20 * 6033
/wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* Coding Log Report
for GSoc 2013 */ |
21:17.35 |
Notify |
03BRL-CAD Wiki:NyahCh3ck20 * 6034
/wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* = Test Results
*/ |
21:33.23 |
Notify |
03BRL-CAD:brlcad * 57110
brlcad/trunk/src/libged/gqa.c: do not tokenize over
spaces |
21:42.23 |
*** join/#brlcad mpictor
(~mark@c-67-177-102-131.hsd1.in.comcast.net) |
22:06.46 |
``Erik |
Neil deGrasse Tyson #@neiltyson If you need to
invoke your academic pedigree or job title for people to believe
what you say, then you need a better argument |
22:14.46 |
Notify |
03BRL-CAD:starseeker * 57111
brlcad/trunk/src/libged/gqa.c: Fix stack smash where strtok was
reading beyond the limits of optarg (Sean found it) |