00:50.28 |
Notify |
03BRL-CAD:n_reed * 59344
(brlcad/trunk/src/librt/primitives/brep/brep.cpp
brlcad/trunk/src/librt/primitives/brep/brep_debug.cpp): make sure
we're getting a valid face and surface indices |
01:18.31 |
brlcad |
starseeker: I finally found a system where I
could reproduce the 'new' warnings, and you went ahead and fixed
them all.. pffft, thx :) |
02:03.06 |
brlcad |
zxq9: what tclpng lib issue? I haven't heard
about any issues actually |
02:06.03 |
brlcad |
hi Ignacio` |
02:06.27 |
Ignacio` |
!hi brlcad |
02:06.27 |
gcibot |
brlcad, hi |
02:06.28 |
Ignacio` |
:P |
02:06.29 |
Ignacio` |
brlcad, hi :) |
02:06.33 |
brlcad |
maths22: no template |
02:20.02 |
zxq9 |
brlcad: There is a (probably simple) build
failure on Gentoo. Its not brlcad itself, its a dependency that
hasn't been updated -- but I haven't looked into it. |
02:20.14 |
zxq9 |
That's why I was wondering what the status of
brlcad packaging was at the moment. |
03:07.02 |
brlcad |
starseeker: that's possibly a good
name/convention for a new container ... or a rename, but it'd be a
bit of a headache |
03:09.56 |
maths22 |
brlcad: would you be able to point me to an
example of a cmake file that generates a define? |
03:10.41 |
brlcad |
maths22: sure, gimmie a second |
03:11.16 |
maths22 |
I want to do the lrint one, but I want to see
an example so I don't try to reinvent the wheel or be really
confused |
03:11.16 |
brlcad |
and maths22 you could tell inderpreet the
version of mediawiki and give him permissions with whatever you're
comfortable with |
03:11.22 |
maths22 |
sure |
03:11.37 |
brlcad |
ah, that one's slightly complicated because of
it's c99 nature |
03:11.56 |
maths22 |
I will give admin on wordpress, since its not
currently production |
03:12.23 |
maths22 |
I see no need for admin on mediawiki, as
everything is on the server side regarding the theming |
03:12.40 |
brlcad |
at the most simple level, here's one:
BRLCAD_FUNCTION_EXISTS(alarm HAVE_ALARM) |
03:12.53 |
maths22 |
if it doesn't exist, what does it
do? |
03:13.05 |
brlcad |
it does not set HAVE_ALARM |
03:13.12 |
brlcad |
if it's found, it sets it |
03:13.23 |
brlcad |
now the issue with lrint() is that it will
pass the test |
03:13.28 |
brlcad |
we need two tests |
03:13.38 |
maths22 |
if it passes the test, how is there a
problem? |
03:13.43 |
brlcad |
one for whether it exists, and another for if
it's declared/usable |
03:13.52 |
maths22 |
isn't the idea to only replace it if it does
not work |
03:14.08 |
maths22 |
I don't really get the difference |
03:14.09 |
brlcad |
because functions must be both declared and be
a symbol that can be linked against in order to work |
03:14.25 |
brlcad |
you can declare anything in C |
03:14.27 |
maths22 |
Which does BRLCAD_FUNCTION_EXISTs
check? |
03:15.29 |
maths22 |
is the problem that it might be declared but
not in the library? |
03:33.03 |
brlcad |
maths22: no, the problem is that we told the
compiler to compile in strict c89 mode and lrint() is not part of
c89 |
03:33.22 |
brlcad |
so it's available (as a symbol), but it's not
declared |
03:34.00 |
brlcad |
if something is not declared and you try to
use it, the compiler will complain/warn, which is what you're
seeing |
03:38.31 |
Notify |
03BRL-CAD:brlcad * 59345
brlcad/trunk/src/libged/joint.c: denote what the var is (noun) not
just describe it's age (adjective), make them match |
04:01.43 |
brlcad |
starseeker: factor of 4.82 for both
hypersampled and not, nice |
04:03.22 |
maths22 |
that makes sense |
04:04.28 |
maths22 |
Could a function exists function check compile
with all flags that are enabled? |
04:04.50 |
starseeker |
brlcad:
bu_attribute_variable_set->bu_key_value_set wouldn't be just a
search/replace? |
04:05.26 |
starseeker |
heh - it's gotten to the point point where I
don't like developing *without* strict enabled |
04:05.31 |
starseeker |
s/point point/point |
04:05.41 |
brlcad |
maths22: i think they are now |
04:06.06 |
brlcad |
so it might fail BRLCAD_FUNCTION_EXISTS() even
though it does technically "exist" |
04:06.40 |
brlcad |
there are other ways to test functions,
though, as can be seen elsewhere in that section of the
CMakeLists.txt file |
04:07.54 |
brlcad |
starseeker: possibly, but not 100%
sure |
04:08.29 |
brlcad |
it would lead to confusing variable names
(usually use avs and avsp) |
04:09.25 |
starseeker |
point. OK, we can save it for a new container
if/when |
04:11.43 |
*** join/#brlcad Rishabh
(~chatzilla@106.78.124.186) |
04:19.21 |
maths22 |
brlcad: I will look |
04:19.48 |
maths22 |
Would a custom wrapper for lrint be defined
based on the presence of HAVE_LRINT |
04:28.44 |
brlcad |
shouldn't need a wraper |
04:29.08 |
brlcad |
it should just be a definition issue |
04:29.33 |
brlcad |
only thing making it complicated is getting
the build logic right |
04:34.23 |
brlcad |
maths22: I'll be addressing the lrint failure
in about 10 hours |
04:35.17 |
brlcad |
can revert in the meantime or ride it out (I
curiously don't get the error) |
05:21.41 |
*** join/#brlcad kesha
(~kesha@14.139.122.114) |
06:09.53 |
Notify |
03BRL-CAD Wiki:Edgardormzsosa * 0
/wiki/User:Edgardormzsosa: |
06:56.15 |
*** join/#brlcad luca79
(~luca@net-37-116-125-191.cust.dsl.vodafone.it) |
07:26.53 |
*** join/#brlcad Rishabh
(~chatzilla@106.78.41.193) |
07:43.01 |
*** join/#brlcad kesha
(~kesha@14.139.122.114) |
09:24.35 |
*** join/#brlcad Anaphaxeton
(~george@unaffiliated/anaphaxeton) |
10:39.39 |
Anaphaxeton |
if i understand correctly, mged is a frontend
to a series of tools? |
10:43.27 |
Anaphaxeton |
also is it possible to run it from inside my
desktop (kde) instead of a terminal? |
10:43.58 |
Anaphaxeton |
an open terminal is not really annoying but it
does occupy space |
11:26.17 |
*** join/#brlcad Ch3ck
(~d3r1ck@pD954DEC7.dip0.t-ipconnect.de) |
12:04.42 |
*** join/#brlcad zxq9
(~ceverett@FL9-125-199-207-150.okn.mesh.ad.jp) |
12:58.13 |
maths22 |
I d'nt get an error either; however, since I
introduced lrint, I was interested in figuring out how to fix
it |
13:13.25 |
*** join/#brlcad kesha
(~kesha@14.139.122.114) |
13:13.44 |
*** join/#brlcad Rishabh
(~chatzilla@1.187.236.76) |
13:14.01 |
*** join/#brlcad luca79
(~luca@net-37-116-125-191.cust.dsl.vodafone.it) |
13:58.25 |
*** join/#brlcad kesha
(~kesha@14.139.122.114) |
14:08.24 |
brlcad |
Anaphaxeton: yes, mged is a front-end (as is
'archer', as is the command-line) |
14:09.00 |
brlcad |
it can be started from an icon -- our .deb
distributions provide a full set of icons and menu items |
14:09.12 |
brlcad |
or you can manually add one yourself with a
self-build |
14:46.25 |
Anaphaxeton |
i think that if you included the debian icons
in the source distribution, the archlinux packager will be happy to
use them! or at least if there is a separate tarball with the
icons. |
14:52.04 |
Anaphaxeton |
but how do i invoke brl-cad from the desktop?
everything i tried does not work, except if the desktop opens a
terminal together with mged. which i cant get rid of afterwards of
course |
15:02.51 |
*** join/#brlcad FreezingCold
(~FreezingC@135.0.41.14) |
15:20.00 |
Notify |
03BRL-CAD:carlmoore * 59346
brlcad/trunk/doc/README.OSCON-2014: fix spellings of
'Muuss','Ohloh','other'; remove trailing blanks/tabs |
15:24.31 |
*** join/#brlcad luca79
(~luca@net-37-116-125-191.cust.dsl.vodafone.it) |
15:46.31 |
*** join/#brlcad FreezingCold
(~FreezingC@135.0.41.14) |
16:18.34 |
*** join/#brlcad kesha
(~kesha@14.139.122.114) |
16:25.22 |
Notify |
03BRL-CAD:starseeker * 59347
(brlcad/trunk/include/analyze.h
brlcad/trunk/src/libanalyze/CMakeLists.txt and 2 others): More
g_diff->library work, set up basic test case. It looks like
SplitList from Tcl will work for createing avs objects, and aside
from that g_diff appears (at least, as far into this as I've
current dug) to be way overusing the Tcl level of database
interaction when lower levels will work fine - |
16:25.25 |
Notify |
significant surgery indicated. |
16:41.25 |
Notify |
03BRL-CAD:starseeker * 59348
brlcad/trunk/src/libanalyze/diff.c: print avs2 here to actually see
different results... |
16:45.42 |
Notify |
03BRL-CAD:starseeker * 59349
brlcad/trunk/include/bu.h: Document that bu_avs_get returns NULL if
it doesn't find anything. |
17:06.27 |
Notify |
03BRL-CAD:starseeker * 59350
brlcad/trunk/src/libanalyze/diff.c: Add some type based
checking. |
17:08.57 |
*** join/#brlcad deepak
(~chatzilla@117.214.206.14) |
17:23.24 |
deepak |
I'm unable to understand this task |
17:23.28 |
deepak |
www.google-melange.com/gci/task/view/google/gci2013/5277586288541696 |
17:24.07 |
deepak |
can anyone explain me in brief, what it really
is? |
17:36.15 |
Ignacio` |
gcibot,
http://www.google-melange.com/gci/task/view/google/gci2013/5277586288541696 |
17:36.18 |
gcibot |
Loading Google charts from API |
17:36.18 |
gcibot |
Status: Reopened |
17:36.18 |
gcibot |
Mentor(s): Sean |
17:36.19 |
Ignacio` |
gcibot, thx. |
17:36.19 |
gcibot |
Ignacio`, you're welcome ✔ |
17:45.09 |
deepak |
What I have learned is that, in this user can
switch to different charts like if he click on first button output
come in pie-chart, if second button output occur in bar-chart.
Please correct me if i'm wrong. |
17:55.56 |
brlcad |
Anaphaxeton: the icons are in the
distribution, but don't get used unless you create a .deb ... it'd
need a lot of build system logic to know how to install them
properly, which is inherent to .deb files |
17:56.39 |
brlcad |
Anaphaxeton: how are you invoking brl-cad
(presumably mged)? |
17:56.56 |
Anaphaxeton |
<PROTECTED> |
17:57.09 |
brlcad |
deepak: my quick understanding is that the
benchmark web interface was implemented using one API and since
then another API has become available that is better |
17:57.22 |
Anaphaxeton |
why not have the icons in ./shared? |
17:58.07 |
brlcad |
you mean in your home directory? |
17:58.20 |
brlcad |
or in the system shared directory? |
17:59.02 |
brlcad |
brl-cad installs to only where you install it,
so ... it would be quite unexpected to drop files into the
installing person's home directory unless they requested
that |
17:59.13 |
brlcad |
moreover, the person compiling is often not
the person using it |
17:59.37 |
brlcad |
there's lots of complexity involved to
properly install an icon on a system, which like I said is what
.deb files DO |
17:59.49 |
Anaphaxeton |
system shared. /opt/brlcad/shared in my
case |
18:00.39 |
brlcad |
they certainly could go there since that's the
installation location, but then there's also the question of making
sure the "icons" are appropriate for your desktop |
18:00.50 |
Anaphaxeton |
with archlinux, things are quite flexible. if
make install thows the icons in shared the packager will manage
everything easilly |
18:00.58 |
Anaphaxeton |
throws* |
18:02.12 |
brlcad |
certainly not opposed to doing that -- those
decisions are generally delegated to the individual platform
maintainers, so they can implement what's best for that
platform |
18:02.54 |
brlcad |
right now, the iconds for debian, for example,
live in misc/debian/icons and they get put into the .deb file when
it's created |
18:03.31 |
brlcad |
we have a PKGBUILD and brlcad.install file for
archlinux, but that's all the archlinux maintainer
provided |
18:03.40 |
Anaphaxeton |
on the other hand, since i spoke about
archlinux, if the appropriate icons are somewhere in the sources
the archlinux packager should pick them from the source and place
them at the target dir |
18:03.42 |
brlcad |
I'm not sure if there's a current archlinux
maintainer |
18:03.43 |
Anaphaxeton |
so |
18:03.56 |
Anaphaxeton |
let me see |
18:04.10 |
brlcad |
you're welcome to become a platform maintainer
or submit a patch if this is something that interests you
;) |
18:04.34 |
brlcad |
misc/archlinux is where the arch-specific
files are stored |
18:04.50 |
brlcad |
if the icons become shared, they'd probably
get moved from misc/debian/icons to misc/icons |
18:05.17 |
deepak |
Brlcad: What i'm supposed to do in this task.
One more question how to submit patch, what I need to do for that?
|
18:05.38 |
Anaphaxeton |
there is a maintainer. i will take a look on
his package and see what can b done about the icons. |
18:05.56 |
brlcad |
Anaphaxeton: there's a maintainer listed, but
I'm not sure he's still active |
18:06.09 |
Anaphaxeton |
last commit was in octomber |
18:06.22 |
Anaphaxeton |
so i guess he/she is |
18:06.28 |
Anaphaxeton |
probably he |
18:06.29 |
Anaphaxeton |
:p |
18:06.41 |
Anaphaxeton |
october* |
18:07.09 |
Anaphaxeton |
one more thing. i was told brl-cad is cnc
friendly, is that true? |
18:07.36 |
brlcad |
we're build for solid modeling, which is
inherently what cnc needs |
18:08.38 |
Anaphaxeton |
good. let's see what i will achieve with it
:> |
18:08.38 |
brlcad |
our direct integration with cnc hardware is in
infancy (we have a student-developed g-gcode exporter), but you can
certainly create and print/cut/lathe models |
18:09.35 |
brlcad |
we don't have any awareness of router bits or
toolpaths one might expect in a CAM system |
18:10.12 |
brlcad |
but you can create a model and feed that to a
CNC via various paths |
18:12.05 |
brlcad |
what input(s) does your CNC accept besides STL
(which is always kind of the default fallback option) |
18:13.17 |
Anaphaxeton |
that was the question i was ready to
type |
18:13.50 |
Anaphaxeton |
what file(s) would a lab ask me? |
18:15.06 |
Anaphaxeton |
long story short: i want to build a laptop
case, i thought s/w would help me, i came here, i started thinking
about cnc and then about building a cnc :p |
18:16.26 |
Anaphaxeton |
but designing with brl-cad seems absolutely
realistic whereas building my own cnc doesn't so it seems the best
option is to pay for manufacturing, atm |
18:18.04 |
Anaphaxeton |
so i will ask the cnc folks (when i locate
them) what file(s) they need and we 'll see |
18:24.34 |
*** join/#brlcad deepak
(~chatzilla@117.214.206.14) |
19:43.28 |
brlcad |
Anaphaxeton: most labs default to asking for
STL because that's the one that most everything understands,
however terrible it is |
19:44.04 |
*** join/#brlcad luca79
(~luca@net-37-116-125-191.cust.dsl.vodafone.it) |
19:44.39 |
brlcad |
we have trouble expressing some of our
geometries as STL, especially our newer or advanced
representations, but the older forms go to STL without problem
about 90% of the time with the remaining 10% requiring
inspection/work |
19:47.09 |
Notify |
03BRL-CAD:brlcad * 59351
brlcad/trunk/src/rt/viewg3.c: remove duplicate line_num |
19:50.57 |
Anaphaxeton |
i suppose that my humble case will have no
problem then! |
19:52.57 |
brlcad |
if you run into a problem, we can help you
work through it, whether it's a modeling issue or a software
issue |
19:53.20 |
Anaphaxeton |
when the time comes |
19:53.25 |
Anaphaxeton |
thank you very much! |
19:53.33 |
brlcad |
we push out fixes and new developments almost
every day, so we can investigate issues on the fly |
19:53.39 |
brlcad |
no problem |
19:53.45 |
Anaphaxeton |
how so? |
19:53.47 |
brlcad |
we're always here, even when we're not
;) |
19:54.15 |
Anaphaxeton |
i mean, are you doing this
professionally? |
19:54.35 |
brlcad |
I'm just saying that if you do run into a
problem and it turns out to be a bug, not something you did wrong,
we can help you figure that out quickly and (usually) can even get
a fix in place for you so you can keep going |
19:55.09 |
brlcad |
we're open source with a pretty vibrant
community of people willing and interested in helping each
other |
19:55.23 |
Anaphaxeton |
good good! :)) |
19:55.32 |
brlcad |
that means you can actually improve the tools
and if you can't, someone else probably can for you if you ask
nicely enough ;) |
19:56.00 |
Anaphaxeton |
i wish i could help the way i want |
19:56.07 |
brlcad |
i wish you could too! |
19:56.14 |
Anaphaxeton |
first impression from the system was |
19:56.18 |
Anaphaxeton |
wow cli |
19:56.21 |
Anaphaxeton |
ahem gui |
19:56.25 |
brlcad |
nods |
19:56.28 |
Anaphaxeton |
i bet everyone is the same hehe |
19:56.31 |
brlcad |
yep |
19:56.58 |
brlcad |
we're acutely aware of our 80's/90's
appearance and terribly difficult usability |
19:57.07 |
brlcad |
we make emacs look easy to learn |
19:58.07 |
brlcad |
revamping our usability has been a #1 priority
for a number of years .. it just takes a while to convert a cargo
ship into a cruise ship! |
19:58.17 |
Anaphaxeton |
i thought about how the ui could be better.
probably the cli is almos perfect |
19:58.30 |
Anaphaxeton |
maybe a better completion |
19:58.59 |
brlcad |
our cli is a strength .. could be better, but
it's actually better than most (even the big-name proprietary CAD
systems) |
19:59.39 |
Anaphaxeton |
i am a CAD noob, but when it comes to cli and
usability i know how things should be |
19:59.51 |
Anaphaxeton |
about the gui i cant say much for
sure |
20:00.40 |
Anaphaxeton |
the gui doesnt integrate. ok it is obvious.
but i cant judge the usability of the menus or interaction with the
model, yet |
20:00.51 |
brlcad |
our new archer gui is "better" than mged's GUI
but it's still being developed, a ways to go before it's a full
replacement |
20:00.59 |
Anaphaxeton |
what i would really like is
antialiasiing! |
20:01.09 |
brlcad |
of the wireframe? |
20:01.12 |
Anaphaxeton |
yes |
20:01.27 |
brlcad |
interesting, I don't think anyone has actually
ever requested that specifically |
20:03.01 |
Anaphaxeton |
it is more pleasant and probably more
"accurate", no? |
20:03.17 |
Anaphaxeton |
well, enough comments for now |
20:03.29 |
Anaphaxeton |
i must do more in order to have more to
say! |
20:06.29 |
brlcad |
as usual, "it depends" :) |
20:09.51 |
*** join/#brlcad FreezingCold
(~FreezingC@135.0.41.14) |
20:13.52 |
Anaphaxeton |
for now i will be using mged. how does archer
draw? i mean the models and the ui |
20:14.41 |
brlcad |
it's meant to be mostly a GUI appearance
transformation |
20:14.51 |
brlcad |
the 3D context and the command line are
otherwise nearly identical |
20:15.30 |
brlcad |
the menu changes, the two windows are
combined, and there are buttons for more common
operations |
20:15.48 |
Anaphaxeton |
i saw but is there some toolkit
backend? |
20:15.49 |
brlcad |
plus you can interactively use the mouse to
edit most primitives, which is not an option in mged |
20:16.08 |
brlcad |
toolkit? |
20:16.43 |
brlcad |
both mged and archer use the same "command
library" under the hood, the same libraries for rendering,
geometry, etc |
20:17.33 |
brlcad |
ah, if you're referring to blending in with
your desktop environment, it uses a similar backend but in a
completely different way -- it's not as disturbing as
mged |
20:18.04 |
brlcad |
note that on the mged->File->Preferences
menu, you can adjust much of what is probably bothering you about
it :) |
20:18.16 |
brlcad |
the colors, fonts, sizes, etc |
20:19.31 |
Anaphaxeton |
cool thanks :) |
20:20.22 |
Anaphaxeton |
so if i understand correctly brl-cad on linux,
draws directly on X11? |
20:22.40 |
Anaphaxeton |
its widgets i mean |
20:23.27 |
Anaphaxeton |
archer is static and i cant see what it links
against :> |
20:35.44 |
*** join/#brlcad KimK
(~Kim__@ip24-255-223-153.ks.ks.cox.net) |
20:41.12 |
Notify |
03BRL-CAD:brlcad * 59352
brlcad/trunk/src/libpc/pcNetwork.cpp: initialize v1/v2 before use
(unknown if getVertexbyID fully sets them) |
20:45.59 |
Notify |
03BRL-CAD Wiki:Atabac 2000 * 0
/wiki/User:Atabac_2000: |
20:47.58 |
brlcad |
Anaphaxeton: on linux we draw both directly
and indirectly to X11 |
20:48.18 |
brlcad |
the widgets are all drawn via Tk |
20:48.58 |
brlcad |
(the same library that sits underneath
PythonTk, Tcl/Tk, PerlTk, etc) |
20:56.05 |
Anaphaxeton |
i know tk |
20:56.23 |
Anaphaxeton |
do you stick to tk for convenience? |
20:59.21 |
Ignacio` |
[Gtk rules lml] |
21:05.42 |
brlcad |
Anaphaxeton: not at all, we adopted Tk circa
1986 when it was the best option available |
21:05.58 |
brlcad |
our next generation interface is being
developed in Qt |
21:06.43 |
brlcad |
we have one of the largest bodies of Tk code
in an application anywhere (can probably count those bigger on two
hands) |
21:06.49 |
Anaphaxeton |
Qt is the way to go. Ignacio` is totally wrong
:p |
21:06.58 |
Anaphaxeton |
prepares for
war |
21:07.10 |
Ignacio` |
xD |
21:07.18 |
Ignacio` |
you have reason :P |
21:07.26 |
Ignacio` |
but Gtk is very pretty :3 |
21:07.47 |
Anaphaxeton |
is it prettier than gtk3 indeed? |
21:07.51 |
Anaphaxeton |
gtk2 * |
21:08.06 |
*** join/#brlcad WhiteCalf
(~DarkCalf@173.231.40.98) |
21:08.08 |
Ignacio` |
Gtk3 is more pretty than gtk2 |
21:08.09 |
Ignacio` |
:P |
21:08.23 |
Anaphaxeton |
ok ok ok |
21:08.52 |
Ignacio` |
:P |
21:08.56 |
brlcad |
gtk was considered along with a dozen
others |
21:08.56 |
Anaphaxeton |
:D |
21:09.17 |
Anaphaxeton |
gtk is good on linux but people elsewhere
complain |
21:09.20 |
brlcad |
it fulfills our requirements nearly as well as
Qt but for the customization we're looking to do, Qt made that a
little bit easier |
21:09.51 |
brlcad |
and gtk is a fair bit more complex in terms of
dependency management (they use a TON of external
dependencies) |
21:10.01 |
Anaphaxeton |
so you are working on both archer and the
next-gen qt program? |
21:10.21 |
brlcad |
you as in the team or me personally?
:) |
21:10.35 |
maths22 |
brlcad: You will need to do something about
the email I sent you |
21:10.37 |
Anaphaxeton |
whoever is writting one! |
21:10.51 |
maths22 |
mac.com seems to be blocking the server's
smtp |
21:10.54 |
brlcad |
they are both being worked on, "yes"
:) |
21:10.56 |
Anaphaxeton |
is merely
curious |
21:12.30 |
brlcad |
maths22: huh! that's concerning |
21:12.52 |
maths22 |
I looked at http://whatismyipaddress.com/blacklist-check,
and none of those blacklists had it blacklisted |
21:13.14 |
maths22 |
However, the one in the email (https://support.proofpoint.com/dnsbl-lookup.cgi)
has it blacklisted |
21:14.32 |
maths22 |
It seems to have been bouncing your emails
from the server for a bi |
21:14.36 |
maths22 |
/bi/bit |
21:25.51 |
brlcad |
submitted a false-positive report, will see
what happens |
21:25.56 |
brlcad |
~maths22++ |
21:26.22 |
brlcad |
there's no reason stated, so it's not like
there's anything we can even investigate |
21:43.09 |
*** join/#brlcad Anaphaxeton
(~george@unaffiliated/anaphaxeton) |
21:52.17 |
*** join/#brlcad Anaphaxeton
(~george@unaffiliated/anaphaxeton) |
21:54.07 |
maths22 |
true |
21:56.21 |
Ignacio` |
brlcad, you decided the gci winners? |
22:02.16 |
Notify |
03BRL-CAD:starseeker * 59353
brlcad/trunk/src/libanalyze/diff.c: Use containers under a struct
to systematically categorize and store various aspects of the diff
tests. From this, we will be able to generate various outputs
without encoding the reporting logic in amongst the diff
logic. |
22:02.41 |
Notify |
03BRL-CAD:brlcad * 59354
brlcad/trunk/src/librt/primitives/brep/brep.cpp: use point_t's
where they are points and initialize most points and vectors more
consistently. tons of warnings were being issued about using
potentially unitialized variables, implying the logic in places may
very well be wrong. we need a way to enable c++ strict on a
per-directory basis... |
22:05.57 |
Notify |
03BRL-CAD:starseeker * 59355
brlcad/trunk/src/libanalyze/diff.c: don't initialize beyond where
we actually need to. |
22:17.23 |
Notify |
03BRL-CAD:brlcad * 59356
(brlcad/trunk/include/brep.h
brlcad/trunk/src/libbrep/PullbackCurve.cpp
brlcad/trunk/src/libbrep/opennurbs_ext.cpp): Refactor
brep_newton_iterate() to eliminate the unused surface. duplication
identified by harmanpreet (related: sf patch 183). |
22:23.27 |
brlcad |
IgnacioPlaying: we don't decide our winners
until Monday |
22:51.04 |
Notify |
03BRL-CAD:carlmoore * 59357
brlcad/trunk/src/util/imgdims.c: implement h for help; case '?':
not needed because default: takes care of it |
23:43.43 |
Notify |
03BRL-CAD:r_weiss * 59358
brlcad/trunk/src/librt/primitives/bot/btg.c: Fixed several bugs in
file btg.c functions bottie_shot_double, bottie_prep_double and
hitfunc. Some variables were not initialized correctly causing
raytracing BOTs using TIE to crash. |