01:24.42 |
Notify |
03BRL-CAD Wiki:Haa1234321 * 0
/wiki/User:Haa1234321: |
03:17.44 |
Notify |
03BRL-CAD:phoenixyjll * 57738
brlcad/trunk/src/libbrep/intersect.cpp: At most one element would
be in the pending array. Just use a single ON_X_EVENT rather than
an array. |
03:29.33 |
Notify |
03BRL-CAD:phoenixyjll * 57739
brlcad/trunk/src/libbrep/intersect.cpp: Correct the
comments. |
03:50.17 |
brlcad |
Izak__: looks like it may have been an order
of operations problem.. try normalizing either the inputs or the
result in norm() |
03:50.28 |
brlcad |
s/normalizing/unitizing/ |
03:50.38 |
brlcad |
it was in the middle before you removed
it |
04:23.44 |
Notify |
03BRL-CAD:brlcad * 57740
brlcad/trunk/src/libged/search.c: ws style cleanup, move struct to
top |
04:31.48 |
Notify |
03BRL-CAD:brlcad * 57741
brlcad/trunk/src/libged/search.c: check function args so we don't
have an opportunity to dereference NULL |
04:32.42 |
Notify |
03BRL-CAD:brlcad * 57742
brlcad/trunk/include/bu.h: provide sane behavior if we happen to
pass a null pointer to a BU_PTBL_ macro. |
05:18.57 |
*** join/#brlcad kesha
(~kesha@14.139.122.114) |
06:38.00 |
*** join/#brlcad d_rossberg
(~rossberg@66-118-151-70.static.sagonet.net) |
07:13.31 |
kesha |
hi brlcad |
07:13.43 |
kesha |
Updated patch on sf. |
07:14.26 |
kesha |
http://paste.kde.org/pe3c06397/
-> this is what I get running "make regress-step2g" . |
07:14.35 |
kesha |
#2380-#2391 |
07:15.09 |
kesha |
And I have sent you screenshots of all three
tests in mail. |
07:15.46 |
kesha |
http://www.steptools.com/support/stdev_docs/index.html
-> this is the site from which I have picked up models |
07:25.25 |
kesha |
http://www.steptools.com/copyright.html
-> copyright |
07:27.26 |
kesha |
I think I should add this http://paste.kde.org/pd4db1886/
as comment before all the three .step files and then we can use.
But I am not very sure. I have never dealt with license and
copyrights related issue earlier |
07:27.53 |
kesha |
Will adding the copyright comments be
sufficient ? |
07:29.55 |
*** join/#brlcad kimzzzz
(~AndChat31@1.38.31.241) |
07:42.38 |
Notify |
03BRL-CAD Wiki:Phoenix * 6150
/wiki/User:Phoenix/GSoc2013/Reports: /* Week 14 */ |
07:57.07 |
*** join/#brlcad kesha
(~kesha@14.139.122.114) |
07:59.06 |
*** join/#brlcad caen23
(~caen23@92.85.89.94) |
08:01.24 |
Notify |
03BRL-CAD Wiki:KeshaSShah * 0
/wiki/File:Instance_stepfile1.png: |
08:01.44 |
Notify |
03BRL-CAD Wiki:KeshaSShah * 0
/wiki/File:Instance_stepfile2.png: |
08:02.30 |
Notify |
03BRL-CAD Wiki:KeshaSShah * 0
/wiki/File:Instance_stepfile3.png: |
08:02.55 |
Notify |
03BRL-CAD Wiki:KeshaSShah * 6154
/wiki/User:KeshaSShah/GSoC13/Reports: /* Week 14 */ |
08:07.10 |
Notify |
03BRL-CAD Wiki:KeshaSShah * 6155
/wiki/User:KeshaSShah/GSoC13/Reports: /* September 19 */ |
08:54.22 |
*** join/#brlcad FLOSSrookie
(~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
09:07.31 |
Ch3ck |
looks like src/librt/bool.c is pretty messed
up! will take a peek ;) |
09:07.58 |
*** join/#brlcad Ch3ck_
(~Shadownet@195.24.220.16) |
09:34.32 |
Notify |
03BRL-CAD:d_rossberg * 57743
brlcad/trunk/include/bu.h: reverted r57742this revision needs some
additional considerations: it breaks the build and putting
additional brackets around the macros doesn't solve all issues,
e.g.:brlcad/src/librt/bool.c:1998:14: error: the address of
?\226?\128?\152open_parts?\226?\128?\153 will always evaluate as
?\226?\128?\152true?\226?\128?\153 [-Werror=address] |
09:35.06 |
d_rossberg |
Ch3ck: this should solve the bool.c
issue |
09:47.52 |
Izak__ |
d_rossberg: Thanks for reverting that
commit |
09:48.16 |
Izak__ |
Ch3ck: Build is doing great now :) |
09:48.18 |
Ch3ck |
d_rossberg: :) ;) |
09:49.06 |
*** join/#brlcad kimzzzz
(~AndChat31@1.38.29.119) |
10:43.42 |
*** join/#brlcad kimzzzz
(~AndChat31@1.38.29.119) |
10:52.22 |
*** join/#brlcad
AndChat|317009 (~AndChat31@1.38.29.119) |
11:19.41 |
Notify |
03BRL-CAD:tbrowder2 * 57744
(brlcad/trunk/src/util/bu_arg_parse.cpp
brlcad/trunk/src/util/bu_arg_parse.h
brlcad/trunk/src/util/dsp_add2.c): remove atexit function; use new
bu_arg_exit function |
11:22.49 |
Notify |
03BRL-CAD:tbrowder2 * 57745
(brlcad/trunk/src/util/bu_arg_parse.cpp
brlcad/trunk/src/util/bu_arg_parse.h
brlcad/trunk/src/util/dsp_add2.c): drop '_value' from getter
funcs |
11:28.44 |
*** join/#brlcad kimzzzz
(~AndChat31@1.38.29.119) |
11:34.51 |
*** join/#brlcad Izak_
(~Izak@195.24.220.16) |
12:24.40 |
Notify |
03BRL-CAD:indianlarry * 57746
brlcad/branches/nurbs/src/librt/primitives/brep/brep.cpp: Cleaning
up recursive bailouts for forced subdivision pullback need to work
on tolerences then work back into FIRST order pullback,
WIP |
12:25.26 |
brlcad |
thanks d_rossberg, should have compiled more
fully, just tried a few dirs |
12:25.40 |
brlcad |
make sense, any static will issue a
warning |
13:00.12 |
*** join/#brlcad FLOSSrookie
(~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
13:05.54 |
Notify |
03BRL-CAD:indianlarry * 57747
brlcad/branches/nurbs/src/librt/primitives/brep/brep.cpp: More
cleanup in surface_GetClosestPoint3dFirstOrder() |
13:18.31 |
Notify |
03BRL-CAD:indianlarry * 57748
(brlcad/branches/nurbs/TODO
brlcad/branches/nurbs/doc/docbook/system/mann/en/search.xml and 23
others): Merging trunk into branch 'nurbs' r:57712:57745 |
13:27.32 |
*** join/#brlcad caen23
(~caen23@92.85.89.94) |
13:32.20 |
Notify |
03BRL-CAD:indianlarry * 57749
(brlcad/trunk/src/libdm/dm_obj.c
brlcad/trunk/src/libtclcad/tclcad_obj.c): The typedef "Tcl_Obj" not
declared at top of block causing problems under windows. |
14:00.33 |
Notify |
03BRL-CAD:starseeker * 57750
(brlcad/trunk/src/conv/step/g-step/Comb_Tree.cpp
brlcad/trunk/src/conv/step/g-step/Shape_Definition_Representation.cpp):
No contents yet, but start writing out comb product
definitions. |
14:05.52 |
Notify |
03BRL-CAD:indianlarry * 57751
brlcad/trunk/src/librt/search.c: "HIDDEN static" ->
"HIDDEN". |
14:16.41 |
Notify |
03BRL-CAD:starseeker * 57752
brlcad/trunk/src/conv/step/g-step/Comb_Tree.cpp: start working on
how to extract matricies from combs |
14:25.29 |
brlcad |
starseeker: your code comments are very
curious .. what are you considering a product? |
15:04.57 |
*** join/#brlcad FLOSSrookie
(~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
15:27.00 |
kanzure |
brlcad: still working on the python bindings.
i've figured out a basic architecture that i'm happy with. instead
of generating the bindings and committing that to a python package
repo, i'm going to make a hard dependency on my fork of ctypesgen
(which is what i used to generate those ctypes bindings), and just
run ctypesgen at python module install time. |
15:27.09 |
kanzure |
brlcad: the goal there is to not create a
billion lines of code that i have to maintain |
15:27.38 |
kanzure |
brlcad: and it should generate bindings
compatible with whatever version of brlcad the python
user/developer has installed. but also they have to install the
brlcad headers for their version of brlcad. |
16:00.11 |
Notify |
03BRL-CAD:carlmoore * 57753 (brlcad/trunk/TODO
brlcad/trunk/include/icv.h and 6 others): remove trailing blanks
and fix spellings |
16:09.31 |
*** join/#brlcad Gaganjyot
(~gagan@106.192.46.172) |
16:16.43 |
*** join/#brlcad Izak
(~Izak@195.24.220.16) |
16:16.53 |
*** join/#brlcad Ch3ck_
(~Shadownet@195.24.220.16) |
16:18.55 |
*** join/#brlcad Izak_
(~Izak@195.24.220.16) |
16:41.35 |
brlcad |
kanzure: sounds reasonable .. were you able to
reduce any lines of code? |
16:47.08 |
kanzure |
brlcad: the module will probably end up being
very tiny. if you mean the generated code.. sort of. there's a few
problems in the generator library that i'm going to fix. their only
output formats are "python text file" and "json". obviously if we
are in python we can just create python objects, so that's why i've
forked ctypesgen: https://github.com/kanzure/ctypesgen |
16:54.32 |
*** join/#brlcad FLOSSrookie
(~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) |
16:56.42 |
Notify |
03BRL-CAD:starseeker * 57754
brlcad/trunk/src/conv/step/g-step/Comb_Tree.cpp: Check for
non-identity matricies over breps in possible wrapper
combs. |
17:06.27 |
*** join/#brlcad kesha
(~kesha@49.249.191.48) |
17:57.18 |
Notify |
03BRL-CAD:starseeker * 57755
brlcad/trunk/src/conv/step/g-step/Comb_Tree.cpp: Having some
success now seeing matrix over object instances. |
18:11.34 |
Notify |
03BRL-CAD Wiki:IIIzzzaaakkk * 6156
/wiki/User:Izak/GSOC_2013_logs: /* September 16th to September 21st
*/ |
18:17.39 |
Notify |
03BRL-CAD:carlmoore * 57756
brlcad/trunk/src/conv/g-vrml.c: remove a space |
18:24.55 |
Notify |
03BRL-CAD:brlcad * 57757 brlcad/trunk/CHANGES:
clarify and reorganize change policy comments so that it's clear
that we characterize interface changes into one of three
categories. this affords a place to mention our policy on allowing
NEW api to change as needed while it's being actively developed, as
well as clarifying minimally impacting changes to any release, and
being then more strict about our deprecation |
18:24.57 |
Notify |
policy requirement. |
18:40.09 |
Notify |
03BRL-CAD:brlcad * 57758 brlcad/trunk/CHANGES:
not just API, all interfaces, and not just a log. it's our
policy. |
18:42.04 |
Notify |
03BRL-CAD:carlmoore * 57759
brlcad/trunk/src/conv/g-x3d.c: implement h?; remove some unneeded
braces; simplify usage of 'units' variable |
18:44.18 |
Notify |
03BRL-CAD:brlcad * 57760 brlcad/trunk/CHANGES:
no longer below |
18:56.53 |
starseeker |
brlcad: uh... I'm figuring out what needs to
be a "product" as I go? |
18:57.10 |
starseeker |
even reading the STEP docs and looking at
examples, it's a bizarre arrangement |
18:58.08 |
starseeker |
Once it settles down a bit more I'll try to
clean up the comments and make the naming conventions more
consistent (will need to do some of that anyhow just to write a
coherent man page) |
19:09.38 |
brlcad |
starseeker: from my understanding, and the
graphs I pointed at yesterday reinforce the notion, a product is
comprised of one or more assemblies (groups), which are comprised
of one or more subassemblies (groups), which are comprised of one
or more parts (regions), which contain the actual representation
information |
19:09.53 |
brlcad |
so basically, our notion of a .g is a
product |
19:10.19 |
brlcad |
out above-region combs (groups) are assemblies
and subassemblies |
19:12.37 |
brlcad |
really cool: clang has -Wdocumentation to find
errors in comments! (looks like primarily doxygen
errors) |
20:01.10 |
Notify |
03BRL-CAD:indianlarry * 57761
brlcad/branches/nurbs/src/librt/primitives/brep/brep.cpp: working
subdivision back into parts of first order pullback that fail,
getting close but currently recursing to deep based on normals at
edges, WIP |
20:15.14 |
Notify |
03BRL-CAD:brlcad * 57762 NIL: syncing missing
file from trunk |
20:15.51 |
Notify |
03BRL-CAD:brlcad * 57763
brlcad/branches/RELEASE/TODO: sorting priorities needed to release,
pushing others back onto the backlog |
20:16.45 |
Notify |
03BRL-CAD:brlcad * 57764
brlcad/branches/RELEASE/TODO: do or do not, there is no
try |
20:17.19 |
starseeker |
brlcad: I think I actually added in support
for the -Wdocumentation flag at one point, but with -Werror it may
have been impractical... |
20:18.13 |
*** part/#brlcad Gaganjyot
(~gagan@106.192.46.172) |
20:18.36 |
starseeker |
this work? http://llvm.org/devmtg/2012-11/Gribenko_CommentParsing.pdf |
20:19.25 |
brlcad |
starseeker: yeah, you posted that
earlier |
20:19.30 |
brlcad |
looks like it's integrated |
20:19.34 |
starseeker |
awesome |
20:19.52 |
starseeker |
want to try adding it to the build? |
20:20.13 |
brlcad |
not right this second, but can get added to
the list |
20:20.26 |
brlcad |
there's a list of several warning flags hoping
to eventually turn on once all the issues are fixed |
20:20.36 |
brlcad |
they're in the file that tests for
them |
20:21.20 |
starseeker |
cool - I'll add in a note for that one. Last
time I tried it we weren't too bad |
20:29.43 |
starseeker |
the documentation says axis2_placement_3d
defines the "orientation" |
20:39.15 |
starseeker |
there's also a
cartesian_transformation_operator... |
20:39.36 |
starseeker |
nuts - not seeing any discussion of
matrices |
20:43.05 |
Notify |
03BRL-CAD:starseeker * 57765
brlcad/trunk/misc/CMake/BRLCAD_CompilerFlags.cmake: Add
-Wdocumentation to the list of warnings to look into
adding |
21:12.40 |
Notify |
03BRL-CAD:starseeker * 57766
brlcad/trunk/src/conv/step/g-step/Comb_Tree.cpp: May be able to
generate inputs for AXIS2_PLACEMENT_3D components... |
21:24.39 |
Notify |
03BRL-CAD:mohitdaga * 57767
brlcad/trunk/src/libicv/CMakeLists.txt: Add tests folder in libicv.
Primary aim of these files will be to do performance analysis of
libicv api calls. Also it will be helpful in checking memory leaks.
In the long run this will demonstrate the usage of
libicv. |
21:39.38 |
Notify |
03BRL-CAD:carlmoore * 57768
brlcad/trunk/src/conv/g-xxx_facets.c: implement h?; remove unneded
break & set of braces |
21:50.56 |
mpictor |
brlcad: how helpful was the STACK
output? |
21:52.27 |
mpictor |
or have you had a chance to look at much of
its output yet? |
21:54.02 |
Notify |
03BRL-CAD:r_weiss * 57769
brlcad/trunk/src/libbrep/intersect.cpp: Fixed a bug in libbrep
function curve_fitting where the bounds of the knots array was
exceeded. |
22:07.56 |
Notify |
03BRL-CAD:starseeker * 57770
brlcad/trunk/src/conv/step/g-step/Comb_Tree.cpp: Add more thoughts
about AXIS2_PLACEMENT_3D and
CARTESIAN_TRANSFORMATION_OPERATOR_3D |
22:47.22 |
maths22 |
brlcad: what is the status for web work and
the extensions? |
22:48.51 |
Notify |
03BRL-CAD:tbrowder2 * 57771
(brlcad/trunk/src/util/bu_arg_parse.cpp
brlcad/trunk/src/util/bu_arg_parse.h
brlcad/trunk/src/util/dsp_add2.c): rename arg constructor functions
per Sean's suggestion |
22:51.54 |
Notify |
03BRL-CAD:tbrowder2 * 57772
(brlcad/trunk/src/util/bu_arg_parse.cpp
brlcad/trunk/src/util/bu_arg_parse.h
brlcad/trunk/src/util/dsp_add2.c): change switch arg func to return
int instead of long per Sean's suggestion |
23:57.38 |
brlcad |
starseeker: if i'm reading the spec right,
it's ap214 and ap210 that support arbitrary matrix placement like
we use |
23:58.09 |
brlcad |
ap214 has a Component_placement entity type
that is used for just that purpose |
23:58.33 |
brlcad |
http://www.prostep.org/fileadmin/freie_downloads/Guidlines-UseCases/ProSTEP-iViP_Implementation-Guideline_STEP-CC08_1.2.pdf
seems to confirm |