00:01.54 |
brlcad |
k |
00:21.48 |
starseeker |
whoops |
00:21.57 |
starseeker |
is sure most of the
undocumented stuff is probably him |
00:22.03 |
starseeker |
sorry 'bout that |
00:22.27 |
``Erik |
at least you didn't leave glpong debian files
all over O:-) |
00:24.34 |
starseeker |
brlcad: do you want me to get the mged man
stuff renamed prior to release? |
00:24.49 |
starseeker |
can start, but doesn't want
to disrupt things... |
00:41.45 |
CIA-43 |
BRL-CAD: 03starseeker * r37570
10/brlcad/trunk/src/libdm/dm-rtgl.c: Missing entry in rtgl struct -
new slot for drawVListHiddenLine |
00:57.15 |
mafm |
http://dl.free.fr/o0gQpSKj4/mafm-errors.log
<---- for brlcad or anybody interested |
00:58.43 |
mafm |
they seem to be the same as with
ccache |
00:59.03 |
mafm |
if you have an idea of what's wrong, it'd be
welcome -- tomorrow, I'm off to bed now |
00:59.05 |
mafm |
night |
01:06.08 |
starseeker |
copies his early stage prelim
getopt_long stuff to bz for later work and tries to catch the
store |
01:06.25 |
starseeker |
must get supplies before snow... |
01:32.28 |
``Erik |
here's a rare one...
http://www.dailymail.co.uk/news/article-1242637/Gay-man-tried-poison-lesbian-neighbours-slug-pellets-legged-cat-feud-walks-free.html |
01:36.43 |
louipc |
haha the war of the genders |
05:46.06 |
*** join/#brlcad Ralith_
(~ralith@69.90.48.97) |
08:45.38 |
*** join/#brlcad CoconutCrab
(~toor@unaffiliated/coconutcrab) |
08:48.14 |
CoconutCrab |
hello everyone |
08:48.29 |
CoconutCrab |
does anyone have problem compiling brlcad with
gcc 4.3.3? |
09:07.21 |
*** join/#brlcad mafm
(~mafm@99.Red-83-45-252.dynamicIP.rima-tde.net) |
11:55.01 |
*** join/#brlcad parigaudi
(~quassel@pd95b7f5e.dip0.t-ipconnect.de) |
12:54.53 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
13:33.50 |
CIA-43 |
BRL-CAD: 03starseeker * r37571
10/brlcad/trunk/ (14 files in 5 dirs): |
13:33.51 |
CIA-43 |
BRL-CAD: Getting set up to move the MGED
commands to mann with a .nged prefix. As a |
13:33.51 |
CIA-43 |
BRL-CAD: first step, move those reported to
have conflicts by gentoo, but all MGED |
13:33.52 |
CIA-43 |
BRL-CAD: commands will need to be moved.
brlman script also needed a minor tweak to |
13:33.52 |
CIA-43 |
BRL-CAD: handle manpage extensions that
weren't an exact match for the man* character in |
13:34.01 |
CIA-43 |
BRL-CAD: the directory name. Not clear yet if
it can handle specifying 1 vs. 3 vs. n man |
13:34.01 |
CIA-43 |
BRL-CAD: pages, but for commands like rt it
will eventually need to - look into it. |
13:34.38 |
starseeker |
brlcad: that look OK? |
13:54.48 |
brlcad |
at a glance, it looks like the right
direction |
13:55.34 |
brlcad |
can you actually look the nged pages up with
man? |
13:58.50 |
CIA-43 |
BRL-CAD: 03brlcad * r37572
10/brlcad/branches/STABLE/ (465 files in 104 dirs): merge trunk to
STABLE from r37287 to HEAD r37570 |
14:12.21 |
brlcad |
interesting read:
http://www.haiku-os.org/blog/stippi/2010-01-12_everyone_loves_benchmarks |
14:16.22 |
*** join/#brlcad CGI463
(~7f000001@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
14:35.11 |
CIA-43 |
BRL-CAD: 03brlcad * r37573
10/brlcad/branches/STABLE/ (20 files in 5 dirs): merge trunk to
STABLE from r37570 to HEAD r37571, last minute addition |
14:35.18 |
mafm |
http://dl.free.fr/o0gQpSKj4/mafm-errors.log
<- does anybody has suggestions about this? |
14:41.12 |
mafm |
it seems to me that at least the one of "int
brlcad::BANode<BA>::depth()" can't be fixed without modifying
the source |
14:41.52 |
``Erik |
not letting me download any file, redirects to
something with a bunch of french |
14:42.52 |
d_rossberg |
mafn: there is a conflict with the TNT
library's header files on your computer |
14:43.18 |
d_rossberg |
TNT and STL both have a "max"
template |
14:44.04 |
d_rossberg |
the namespace should preven this type of
error |
14:44.06 |
starseeker |
brlcad: with the patch to brlman,
yes |
14:44.16 |
mafm |
er Télécharger ce fichier |
14:44.23 |
starseeker |
at least, on my gentoo box it works |
14:44.49 |
``Erik |
yeh, clicked it, but it just lodas the same
page again |
14:44.53 |
``Erik |
loads |
14:45.02 |
mafm |
``Erik: click on Télécharger ce fichier
(sorry but I don't know other file uploading services) |
14:45.15 |
mafm |
ops |
14:45.16 |
mafm |
dunno then |
14:45.32 |
mafm |
I can't upload it to paste.debian.net, too
big |
14:46.35 |
CoconutCrab |
hello, I can't compiling brlcad on my amd64
system, can someone help me? |
14:46.43 |
CoconutCrab |
here is the error when compiling http://dpaste.com/154981/ |
14:47.12 |
mafm |
http://encodable.com/cgi-bin/filechucker.cgi?action=landing&path=/&file=mafm-errors.log |
14:47.17 |
CIA-43 |
BRL-CAD: 03brlcad * r37574
10/brlcad/tags/rel-7-16-6/: tagging release 7.16.6 with all
regressions passing |
14:47.25 |
mafm |
``Erik:
http://encodable.com/cgi-bin/filechucker.cgi?action=landing&path=/&file=mafm-errors.log |
14:47.26 |
CoconutCrab |
is it due to my gcc installation? I also found
someone who has the same problem like mine |
14:47.29 |
brlcad |
mafm: saw your log from last night,
interesting error |
14:47.46 |
brlcad |
looks like it might be old, do you have an svn
checkout? |
14:48.12 |
brlcad |
``Erik: the link is the tiniest on that french
page |
14:48.28 |
mafm |
brlcad: I used 7.16.4 tarball |
14:49.21 |
brlcad |
you shouldn't use -k :) |
14:49.54 |
brlcad |
the error is the first one in the log, the
rest is just cascaded failures because those libraries dont'
exist |
14:50.23 |
mafm |
that should be easy to fix then, just prefix
the call with the namespace |
14:50.47 |
mafm |
TNT::max() is probably reduntant in modern C++
too |
14:50.53 |
``Erik |
yeh, threw it through google translate, it
still didn't come up *shrug* mebbe my tinyproxy dropped something
weird *shrug* |
14:52.42 |
d_rossberg |
mafm: for this error there has to be a "using
namespace TNT;" somewhere |
14:53.46 |
d_rossberg |
probable in a tnt header, can you switch it
off (e.g. with a macro) |
14:54.06 |
``Erik |
brlcad: do you know if zeta is generally
considered to be the 'real' beos, or as good as the final beos was?
the haiku vs zeta difference was impressive, but I d'no the beos
'scene' (was googling 'round for zeta...) |
14:59.14 |
mafm |
d_rossberg: http://paste.debian.net/58823/ |
14:59.25 |
mafm |
most amazing |
15:00.26 |
mafm |
``Erik: the relevant error: http://paste.debian.net/58824/ |
15:01.15 |
brlcad |
and THEREIN is why "using namespace std;" is
BAD and should never be used. |
15:01.19 |
mafm |
interestingly enough, your version in
src/other/tnt/jama_lu.h has it too |
15:01.33 |
``Erik |
I got it from the 'encodable' link... but with
roßberg and brlcad both looking and better at c++ than myself, I'm
just chillin' (took the day off due to weather, too) |
15:01.37 |
``Erik |
:) |
15:02.14 |
mafm |
I think that the problem is another: putting
"using namespace" in a header file is asking to be slapped with a
large trout |
15:02.30 |
brlcad |
yes, any using statements in a header.. tsk
tsk |
15:02.36 |
brlcad |
but *especially* using std |
15:02.46 |
starseeker |
mafm: that would make a good warning in a
programming book :-) |
15:02.54 |
brlcad |
that propagates a massive volume of symbols
into the global namespace |
15:03.07 |
``Erik |
probably a quick hack when gcc started
throwing errors on 'cout' without a using or std:: |
15:03.30 |
brlcad |
devs do it to just type less |
15:03.43 |
mafm |
I read recently proposing to include std
always... since no library should override std:: functions (which
somewhat defeats the purpose of namespace altogether, but
well...) |
15:04.06 |
starseeker |
hunts for the large
trout... |
15:04.17 |
mafm |
*someone* (famous in C++ world)
proposing |
15:04.35 |
``Erik |
thinks starseeker is starting
to smell like a dirty mirc user *cough* |
15:04.47 |
mafm |
anyway, what's to be done in this case, any
idea? |
15:04.54 |
starseeker |
``Erik: eh? |
15:05.10 |
starseeker |
irssi all the way, with a little xchat if I'm
on my home box |
15:05.12 |
mafm |
starseeker: the large trout slapping is a
reference to MIRC program |
15:05.19 |
starseeker |
ah :-) |
15:05.25 |
``Erik |
would changing it to TNT::max() in
opennurbs_ext.cpp fix it? |
15:06.19 |
d_rossberg |
mafm: write a bug report to JAMA ;) |
15:07.22 |
``Erik |
(or where the ambiguous max() actually
lives... didn't really look *shrug* :) |
15:08.20 |
CIA-43 |
BRL-CAD: 03brlcad * r37575 10/brlcad/trunk/
(NEWS README include/conf/PATCH): bump to 7.16.7, alas still
expecting at least one more release on the 7.16 line to fix the mac
input bug and get all of the 64-bit windows changes in. this should
be a bugfix-only release. |
15:08.56 |
brlcad |
remove the using statements, fix the code
;) |
15:09.07 |
brlcad |
then push it upstream |
15:09.34 |
starseeker |
(long philosophical argument with upstream
optional...) |
15:10.13 |
brlcad |
not usually |
15:10.22 |
brlcad |
most realize it's just lazyness |
15:10.31 |
brlcad |
they just might not care |
15:10.35 |
starseeker |
nods |
15:11.17 |
mafm |
``Erik: yes, that probably would |
15:11.20 |
starseeker |
brlcad: so go lite on trunk commits till we
get the two mentioned issues knocked out? |
15:11.26 |
brlcad |
given you guys rewrote most of the solver
approach, is tnt/jama even used any more? |
15:11.36 |
starseeker |
I believe it is |
15:11.36 |
mafm |
the version shipped with debian and the one in
src/other/tnt is slightly different though |
15:11.58 |
brlcad |
starseeker: getting those two issues dealt
with should really be the priority (and any other bugs) |
15:12.09 |
brlcad |
since we'll probably need to stamp another
release in a week or two |
15:12.13 |
starseeker |
nods |
15:12.39 |
starseeker |
every run I've taken at the Mac input bug has
gotten me nowhere - any suggestions on where to start? |
15:12.42 |
brlcad |
tons of stuff I want to commit too that are on
hold :( |
15:13.05 |
mafm |
- debian +brlcad |
15:13.11 |
starseeker |
Ah, there it is - SurfaceTree::isFlat is where
we are using tnt/jama, if I understand correctly how it
works |
15:13.14 |
mafm |
- for (int i = 0; i <=
std::min(n,k+3); i++) { |
15:13.15 |
mafm |
+ for (int i = 0; i <=
min(n,k+3); i++) { |
15:13.52 |
starseeker |
(that may or may not be necessary - I never
did try implementing it without tnt/jama and speed
testing) |
15:14.17 |
mafm |
hmmm |
15:14.32 |
mafm |
so you're trying to get rid of this dependency
and release soon? |
15:14.49 |
starseeker |
might be worth rolling our own there if that's
the only reason we are keeping tnt/jama in the tree at all, but
that would take some care - that's a kinda funky and very important
function |
15:15.00 |
starseeker |
mafm: havn't been trying |
15:15.02 |
starseeker |
works find |
15:15.04 |
starseeker |
er fine |
15:15.31 |
starseeker |
plenty of broken stuff to do before we try to
fix something touchy like that that's working |
15:15.48 |
mafm |
I see |
15:17.11 |
starseeker |
Bob is mowing through the Windows stuff in
good shape - I'm betting it's that input bug that's gonna ream
us |
15:18.03 |
*** join/#brlcad CoconutCrab
(~toor@unaffiliated/coconutcrab) |
15:19.41 |
CGI463 |
is this channel intended for developers
only? |
15:21.32 |
starseeker |
users welcome :-) |
15:21.59 |
starseeker |
lot of dev talk goes on, but it's not intended
to be exclusively dev |
15:23.20 |
CGI463 |
i am actually trying to install version 7.10.4
on an ubuntu box. brand new to irc, new to autotools, pretty ok w/
basic linux stuff |
15:23.32 |
starseeker |
uh - why such an old version? |
15:24.10 |
CGI463 |
it's what brlcad.org >> download
>> linux |
15:24.16 |
CGI463 |
that's what sourceforge gave me |
15:24.17 |
starseeker |
erm. |
15:24.35 |
CoconutCrab |
binary version |
15:24.43 |
starseeker |
oh |
15:24.53 |
starseeker |
it's much better if you can compile a newer
version |
15:26.10 |
mafm |
do you think that they would be pissed off if
I mention that putting "using namespace" in headers is a bad
practice? |
15:26.11 |
CGI463 |
binary for linux is *.sh or *.deb,
right? |
15:26.31 |
CGI463 |
this was a tar.bz2 file |
15:26.36 |
starseeker |
CGI463: our binary versions are pretty
old |
15:26.47 |
starseeker |
if you can compile source, try this:
http://sourceforge.net/projects/brlcad/files/BRL-CAD%20Source/7.16.4/brlcad-7.16.4.tar.gz/download |
15:28.07 |
starseeker |
CGI463: not necessarily, binaries on Linux can
get complicated. rpm and deb are binary package formats, but you
can also get just a tar.gz of a binary (this wouldn't have the
metadata associated with an rpm or deb) |
15:28.26 |
brlcad |
mafm: give that a try --v |
15:28.45 |
CIA-43 |
BRL-CAD: 03brlcad * r37576
10/brlcad/trunk/src/other/tnt/ (jama_cholesky.h jama_eig.h
jama_lu.h jama_svd.h tnt_linalg.h): remove the using namespace
declarations as they cause symbol collisions and ambiguous call
errors. this may be incomplete, but it fixes the portions we use.
jama looked to be the most abusive. |
15:29.21 |
CGI463 |
i will try the new source file now. the route
i took led me to this page:
http://sourceforge.net/projects/brlcad/files/BRL-CAD%20for%20Linux/
where it seems like 7.12 is the most current option? |
15:29.31 |
brlcad |
mafm: we just did a 7.16.6 release (tagged
today, not yet uploaded) |
15:30.45 |
CGI463 |
should i extract to the /usr/brlcad/
directory? |
15:31.01 |
*** mode/#brlcad [+o brlcad]
by ChanServ |
15:31.03 |
*** topic/#brlcad by brlcad
-> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.6
tagged today (20100205) |
15:31.12 |
mafm |
k, will try in a minute |
15:31.19 |
brlcad |
odd, who set topic lock? |
15:31.24 |
*** mode/#brlcad [-t] by
brlcad |
15:31.28 |
mafm |
too bad there's no "unusing" namespace
:P |
15:31.45 |
*** mode/#brlcad [-o brlcad]
by brlcad |
15:31.49 |
*** topic/#brlcad by brlcad
-> test |
15:31.52 |
*** topic/#brlcad by brlcad
-> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad
|| #brlcad logs: http://ibot.rikers.org/%23brlcad/
|| Happy Open Source Anniversary! (December 21st) || Release 7.16.6
tagged today (20100205) |
15:31.57 |
brlcad |
that's better |
15:32.52 |
brlcad |
mafm: you'd get better mileage instead of
saying it's bad practice by saying that it's causing conflicts and
ambiguous symbols and *link* here's a patch |
15:35.03 |
mafm |
I'm trying to say this, I'll paste you the
e-mail before sending |
15:35.20 |
mafm |
I tend to piss off people too often lately, I
might be getting asperger's :P |
15:42.05 |
CGI463 |
when running 'make test' i am getting an error
from opennurbs? |
15:44.01 |
CoconutCrab |
what is the error about? |
15:44.37 |
mafm |
brlcad: you have new mail |
15:45.01 |
CGI463 |
'::ptrdiff_t' has not been declared |
15:45.08 |
CGI463 |
seems to be what it doesn't like |
15:45.08 |
CoconutCrab |
same like mine |
15:46.05 |
starseeker |
CGI463: how did you build? |
15:47.11 |
CGI463 |
i guess i don't understand the question . . .
i just did what the install file said './configure', 'make', 'sudo
make install' |
15:47.28 |
starseeker |
ok |
15:47.38 |
starseeker |
try with ./configure --enable-all |
15:47.49 |
starseeker |
see if that changes anything |
15:49.10 |
brlcad |
mafm: that looks good actually, might want to
give them this too: http://brlcad.org/~sean/tnt_namespace.patch |
15:49.21 |
CoconutCrab |
CGI463: http://dpaste.com/155007/ <---
something like this? |
15:49.58 |
brlcad |
say it's not fully tested, but got us past our
error and if anything just needs a few more namespace scopes on TNT
and std symbols |
15:51.46 |
CGI463 |
starseeker: no, doesn't change
anything |
15:51.54 |
mafm |
brlcad: that's against your [possible
outdated] copy or a fully updated copy? |
15:52.04 |
brlcad |
mafm: no idea |
15:52.11 |
brlcad |
it's against what we have checked in
:) |
15:52.24 |
brlcad |
which was some version from them from some
point in time :) |
15:52.53 |
mafm |
they have 1.2.5 now, just for
reference |
15:53.02 |
mafm |
anyway I'll mention the possibility that it's
outdated |
15:53.10 |
starseeker |
CGI463: hmm. |
15:53.16 |
brlcad |
looks like tnt is 1.2.6 |
15:53.27 |
brlcad |
and jama is 1.2.5 |
15:53.28 |
starseeker |
ok, one more thing just to be sure we've got a
clean setup: |
15:53.42 |
brlcad |
with a jama beta for 3.0.12 (wtf) |
15:53.52 |
starseeker |
make distclean && ./autogen.sh
&& ./configure --enable-all && make |
15:54.20 |
brlcad |
starseeker: their error is the same as that
other person from the forums |
15:54.26 |
starseeker |
oh, OK |
15:54.58 |
brlcad |
ptrdiff_t is a std type, there is something
screwy with their c++ install |
15:55.02 |
starseeker |
AH, that thing |
15:55.19 |
starseeker |
yeah, that's not us |
15:55.31 |
CoconutCrab |
I am using gentoo, gcc version 4.3.4 |
15:56.29 |
CGI463 |
ubuntu, gcc 4.2.4 |
15:56.30 |
brlcad |
from the looks of things, it seems a recent
gcc injected a bug or incompatibility in the cstddef
header |
15:57.01 |
CGI463 |
and the error i am getting is the one that you
posted a link to |
15:57.43 |
mafm |
brlcad: send. Though I suspect that he would
prefer to use TNT::max versions and so on when available, he's also
the author of TNT: http://math.nist.gov/~RPozo/ |
15:57.59 |
mafm |
s/send/sent/ |
15:58.27 |
brlcad |
CGI463: try running this: |
15:58.29 |
brlcad |
curl -O http://brlcad.org/~sean/tmp/test.cxx
&& g++ test.cxx && ./a.out ; echo $? |
15:58.44 |
brlcad |
do you get a compile error or does it report
0 |
15:59.55 |
starseeker |
is this related? https://bugs.launchpad.net/ubuntu/+source/gcc-4.3/+bug/355408 |
16:00.14 |
brlcad |
mafm: perhaps, but he should make it clear
regardless :) |
16:00.19 |
CoconutCrab |
brlcad: it runs fine and report 0 |
16:00.22 |
brlcad |
and can tell him his website is
busted |
16:01.13 |
CGI463 |
100 161 100 161 0 0 591 0
--:--:-- --:--:-- --:--:-- 0 |
16:01.22 |
brlcad |
starseeker: yeah, that looks to be exactly the
issue |
16:01.40 |
brlcad |
CGI463: that's the curl download stats :) .. I
presume the latter 0 is the result |
16:02.18 |
CGI463 |
there is a new line and then a '$' with
nothing after it |
16:02.39 |
mafm |
busted? |
16:02.51 |
brlcad |
none of his images load for me |
16:02.54 |
brlcad |
except his mug |
16:03.21 |
starseeker |
same here - broken image links |
16:03.25 |
mafm |
ah, sure, and that's maybe the ugliest image
in the site :PP |
16:03.43 |
brlcad |
oh admit it, he turns you on |
16:04.08 |
brlcad |
SWM seeks MAFM |
16:04.11 |
mafm |
he's piping hot, yep :P |
16:04.30 |
mafm |
anyway, I meant to put this one, where tnt and
jama appear side by side: http://math.nist.gov/tnt/ |
16:04.41 |
CGI463 |
starseeker: i am still in the 4.2 series . . .
i don't know if that matters |
16:04.41 |
mafm |
what's SWM |
16:04.51 |
brlcad |
CGI463: can you upgrade? |
16:05.13 |
CGI463 |
i've never done it, but i'll see what i can do
. . . |
16:05.36 |
brlcad |
there's probably some trivial header file that
can be included to get past the error, but it's still a problem in
your standard c++ headers |
16:05.38 |
starseeker |
upgrading is a good thing to learn how to do
anyway |
16:06.05 |
brlcad |
do a locate cstddef |
16:06.16 |
brlcad |
and then see what package that file belongs
to |
16:06.38 |
brlcad |
that's probably what needs to be upgraded (or
just all of gcc/g++) |
16:07.08 |
brlcad |
CoconutCrab: same goes for you :) |
16:07.48 |
CoconutCrab |
brlcad: er... my version is already
4.3.4 |
16:08.13 |
CoconutCrab |
and I am afraid of upgrading to 4.4 as it
could cause breakage (for gentoo) |
16:08.15 |
CoconutCrab |
:( |
16:09.52 |
CoconutCrab |
I also tried with 4.3.3 |
16:12.34 |
mafm |
brlcad: same error with 7.16.6... did you
really fix it? |
16:13.58 |
mafm |
the patch that you sent me doesn't seem to be
applied there |
16:14.42 |
starseeker |
he tagged 7.16.6 before the tnt/jama
stuff |
16:15.15 |
mafm |
oh bugger |
16:15.27 |
mafm |
you patched a file, I was talking him about
another file |
16:16.04 |
mafm |
oh, actually it was a bunch of them in your
patch... one of them the one that I was talking about... not so bad
then |
16:16.33 |
mafm |
applying patch and compiling
again.... |
16:16.35 |
CoconutCrab |
so what I am going to do is bugging distro
people to fix it |
16:17.58 |
mafm |
to fix the 4.4 issue in gentoo? |
16:18.14 |
CoconutCrab |
also, I don't think this bug is the bug above
(launchpad) |
16:18.18 |
*** join/#brlcad cjdevlin
(~7f000001@99-74-181-148.lightspeed.cicril.sbcglobal.net) |
16:18.59 |
CoconutCrab |
mafm: it is in gentoo unofficial repo, so they
should find a way to fix :P |
16:20.29 |
mafm |
I see |
16:22.58 |
cjdevlin |
would it be worth trying to install gcc4.4 in
my user account and trying to pass the compiler option
manually? |
16:23.30 |
cjdevlin |
cjdevlin == cgi from earlier (accidentally got
disconnected/learning cgiirc) |
16:26.44 |
brlcad |
mafm: heh, the fix isn't in 7.16.6 |
16:27.02 |
brlcad |
that was already tagged, wouldn't inject that
sort of change at the last-minute |
16:27.05 |
brlcad |
svn head |
16:27.52 |
brlcad |
CoconutCrab: without any more information, it
does seem to be some upstream problem |
16:28.23 |
CoconutCrab |
brlcad: I understand |
16:28.26 |
mafm |
I applied the patch on top, and fails with
other errors in opennnurbs |
16:28.55 |
brlcad |
until we see evidence to the contrary, of
course .. like I said, there is *probably* some #include we could
add that would avoid the bug, but I can't test that without access
to a gentoo box |
16:28.59 |
brlcad |
which I don't have at the moment |
16:29.42 |
brlcad |
cjdevlin: what is your goal and interest?
:) |
16:29.43 |
starseeker |
are the gentoo folks here running stable or
unstable? |
16:30.07 |
brlcad |
might just be easier to get someone else on
linux to hand you some binaries if you're kicking tires |
16:30.19 |
starseeker |
has a gentoo box, and (knock
on wood) hasn't seen these issues, but admits he is running cutting
edge |
16:30.22 |
CoconutCrab |
I am mixing between stale/unstable package,
gcc version is stable |
16:30.45 |
starseeker |
hmm. that could be the difference |
16:30.46 |
CoconutCrab |
oh wait |
16:31.02 |
CoconutCrab |
my friend who also have a gentoo box compiled
it successfully |
16:31.12 |
starseeker |
O.o |
16:31.15 |
CoconutCrab |
he is using x86, not amd64 like me |
16:31.19 |
CoconutCrab |
same GCC version |
16:31.27 |
starseeker |
ah. Yes, I'm also x86 |
16:31.32 |
CoconutCrab |
I have his config.log |
16:32.37 |
cjdevlin |
i actually just read about it on /. and wanted
to try it out. i do some engineering for auvs and based on the
description of how this program handles materials it seems like
this would be the optimum program to design on |
16:32.52 |
cjdevlin |
and by engineering i mean i am a
hobbyist. |
16:33.02 |
starseeker |
goes to grab some lunch,
bbl |
16:33.03 |
CoconutCrab |
cjdevlin: you are using ubuntu 64 bit version
right? |
16:33.12 |
cjdevlin |
32 |
16:33.22 |
CoconutCrab |
I see..... |
16:34.00 |
starseeker |
is 32 bit as well, fwiw (my
machine looks older every day...) |
16:34.50 |
CoconutCrab |
I diff-ed the config log of my friend and
mine, but wasn't able to get any clue |
16:37.02 |
cjdevlin |
are you getting these configure warnings?:
configure: WARNING: The floating point implementation does not seem
to be IEEE 754 configure: WARNING: compliant. The behavior of
htond and htonf may be incorrect. |
16:37.48 |
CoconutCrab |
there are some warnings there, but I don't
think they are important, or at least not related to our
problem |
16:41.45 |
mafm |
may I commit freely as when I had permission
to do so? |
16:42.44 |
mafm |
starseeker: brlcad: ^ |
16:43.41 |
brlcad |
CoconutCrab: it's not likely a
configure/config.log issue, even a compiler issue, it's the
standard headers |
16:43.52 |
mafm |
(otherwise if some kind of previous
peer-review is required, etc) |
16:43.55 |
brlcad |
the STL |
16:44.11 |
brlcad |
cjdevlin: that warning can be
ignored |
16:44.24 |
brlcad |
mafm: of course |
16:44.31 |
CoconutCrab |
brlcad: let me check which package that file
belong to |
16:44.40 |
brlcad |
you didn't get "tentative" commit rights, you
got commit |
16:45.20 |
mafm |
but I was working on separate rt3 branch, less
perilous should somehting go wrong :) |
16:45.55 |
cjdevlin |
brlcad: i understand a bit about programming,
but this article seems to be over my head: could it have anything
to do with what we are seeing? it seems like if brlcad is compiling
on one 4.3 box, it isn't the previously mentioned bug. |
16:46.04 |
cjdevlin |
this article: http://readlist.com/lists/gcc.gnu.org/gcc-help/1/7059.html |
16:46.34 |
CoconutCrab |
brlcad: it is belong to gcc, so if me and my
friend have the same gcc version, the header should also be the
same right? |
16:46.59 |
brlcad |
theoretically, which file were you
testing? |
16:47.49 |
CoconutCrab |
brlcad:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/include/g++-v4/new <---
this one |
16:48.10 |
brlcad |
cjdevlin: interesting little discussion there,
but not sure it's relevant |
16:48.26 |
brlcad |
CoconutCrab: what is your exact error
again? |
16:48.45 |
CoconutCrab |
http://dpaste.com/155007/
this |
16:50.23 |
brlcad |
try adding: "#include <cstddef>" before
the #include <new> in
src/other/openNURBS/opennurbs_system.h |
16:50.33 |
brlcad |
see if that does anything useful |
16:52.26 |
CIA-43 |
BRL-CAD: 03mafm * r37577
10/brlcad/trunk/src/librt/opennurbs_ext.cpp: Prefixing with TNT::,
otherwise it fails with a patch that I'm testing, and it's the
correct way to do it anyway (not relying on external 'using
namespace'). |
16:52.27 |
brlcad |
or even #include <stddef.h> |
16:52.29 |
brlcad |
if that makes no diff |
16:52.43 |
CoconutCrab |
brlcad: make-ing |
16:55.16 |
brlcad |
mafm: oops! .. I edited that file to, but just
didn't commit it |
16:55.41 |
CoconutCrab |
brlcad: it still does not work, same
error |
16:55.51 |
brlcad |
you tried both? |
16:55.59 |
brlcad |
cstddef and stddef.h |
16:56.14 |
CoconutCrab |
ah sorry, didn't read the later |
16:56.38 |
mafm |
ah |
16:56.39 |
brlcad |
grep ptrdiff_t
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/include/g++-v4/* | grep
typedef |
16:56.54 |
mafm |
no problem them |
16:57.04 |
CoconutCrab |
brlcad: ok, that worked |
16:57.18 |
brlcad |
wow, yeah |
16:57.21 |
CoconutCrab |
:) |
16:57.23 |
brlcad |
that's a bug |
16:57.37 |
brlcad |
(in stl) |
16:57.54 |
CoconutCrab |
so it is gcc fault right? |
16:58.19 |
brlcad |
yep |
16:58.30 |
brlcad |
try moving the #include up |
16:58.54 |
brlcad |
you'll see a little further up in the file a
#include <stdlib.h> .. put it before that and see if it
works |
16:59.20 |
CoconutCrab |
ok, make clean first |
16:59.28 |
brlcad |
cd src/other/openNURBS |
16:59.39 |
brlcad |
you don't have to have it walk all
dirs |
16:59.45 |
brlcad |
make clean in just the openNURBS dir |
16:59.48 |
brlcad |
then make again |
17:00.35 |
CoconutCrab |
brlcad: it works, sir |
17:01.33 |
brlcad |
what version are you? |
17:01.42 |
brlcad |
cjdevlin: you can try the same edit |
17:01.56 |
cjdevlin |
currently making |
17:02.04 |
cjdevlin |
on a slightly slower machine |
17:02.05 |
CoconutCrab |
brlcad: brlcad? newest version,
7.16.4 |
17:02.10 |
brlcad |
I mean version of gcc |
17:02.32 |
CoconutCrab |
4.3.4 |
17:03.00 |
brlcad |
for what it's worth, be sure to check out the
documentation on the website once you get things compiled |
17:03.04 |
brlcad |
BRL-CAD has a steep learning curve |
17:03.08 |
CoconutCrab |
:) |
17:03.22 |
brlcad |
that documentation is pretty much essential
reading until we make more progress on improving
usability |
17:03.36 |
CoconutCrab |
yes, I will do that for sure |
17:03.39 |
CoconutCrab |
thank you! |
17:03.44 |
brlcad |
the tutorials in particular, and even after
them, you're just starting to scratch the surface in terms of
capabilities and features |
17:03.50 |
CoconutCrab |
and I will lurk in this channel for a while
:P |
17:03.53 |
brlcad |
the quick reference sheet as well ;) |
17:04.27 |
CIA-43 |
BRL-CAD: 03brlcad * r37578
10/brlcad/trunk/src/other/openNURBS/opennurbs_system.h: workaround
fix for the STL bug evident in gcc4 (at least version 4.3.4 and
others) |
17:04.57 |
CoconutCrab |
I met this bug with gcc 4.3.3 too |
17:05.21 |
brlcad |
nods |
17:05.56 |
brlcad |
and cjdevlin is on the 4.2 line, it's been in
there a while apparently |
17:06.17 |
brlcad |
the fix is exactly that bug report that was
closed out .. that *should* have been in 4.3.4 |
17:06.21 |
brlcad |
but maybe didn't quite make it |
17:06.33 |
brlcad |
and will be in 4.3.5 or .6 |
17:06.58 |
brlcad |
goes to the gym before this
big storm hits and has him snowed in all weekend |
17:07.08 |
CoconutCrab |
see you later :) |
17:08.45 |
mafm |
hmmm, new error http://paste.debian.net/58837/ |
17:16.01 |
CIA-43 |
BRL-CAD: 03brlcad * r37579
10/brlcad/trunk/src/libged/edcodes.c: odd compilation error on
debian about invalid storage class. take the easy route and assume
it's just having trouble with the forward declaration. |
17:17.51 |
mafm |
brlcad: you're gone! |
17:18.23 |
``Erik |
heh |
17:21.28 |
mafm |
hmm, so I'm using trunk now, in 7.16.4 and .6
this wasn't giving any trouble, but now it is: |
17:21.38 |
mafm |
configure: error: *** iwidgets was disabled,
yet no usable iwidgets system package was found *** |
17:21.45 |
mafm |
iwidgets4 package is installed |
17:22.40 |
mafm |
error in config.log: http://paste.debian.net/58840/ |
17:37.54 |
``Erik |
w00t, got my usb drive working on fbsd8 O.o
heh, that only took 2 months. |
17:38.24 |
``Erik |
shakes fist at wd for doing
things oh so very slightly wrong O.o |
17:40.23 |
mafm |
nevermind the error above, seems to be caused
somehow by ccache or some strange interaction |
17:40.56 |
mafm |
w00t indeed \o/ |
18:04.33 |
``Erik |
aw sweet, now I have cu on my bsd box talking
to my openrd client correctly... O.o this is turning out to be a
good day. |
18:08.32 |
mafm |
congrats :) |
18:08.35 |
CIA-43 |
BRL-CAD: 03mafm * r37580
10/brlcad/trunk/src/librt/primitives/brep/brep_debug.cpp: Quelling
warnings about const string being treated as non-const. |
18:16.50 |
mafm |
starseeker: there are unused vars in
proc-db/csgrep, is it ok to remove them or are there as part of WIP
enhancements? |
18:24.02 |
``Erik |
would imagine they could be
whacked... can always revert the change later... |
18:25.49 |
mafm |
ok |
18:26.09 |
mafm |
I asked starseeker because he seems to have
edited the file recently several times |
18:27.22 |
CIA-43 |
BRL-CAD: 03mafm * r37581
10/brlcad/trunk/src/proc-db/csgbrep.cpp: Removing unused
variables |
18:27.29 |
mafm |
``Erik: you know about autotools,
right? |
18:27.36 |
mafm |
I have a little problem here |
18:27.58 |
``Erik |
I've heard of autotools, yes... |
18:28.10 |
mafm |
I mean that you write the tests and so on
:) |
18:28.26 |
mafm |
tclcad.c:34:19: error: itk.h: No such file or
directory |
18:28.49 |
mafm |
attach.c:40:19: error: itk.h: No such file or
directory
|
18:28.50 |
``Erik |
looks like you're missing a header
O.o |
18:29.01 |
``Erik |
are you using teh system incrTcl? |
18:29.09 |
mafm |
yes |
18:29.22 |
``Erik |
then you're missing a -I for it on
those |
18:29.23 |
mafm |
but in my case, that file is in itk3-dev
package |
18:29.40 |
mafm |
so actually I don't have itk.h in my
system |
18:29.47 |
``Erik |
ah |
18:29.56 |
mafm |
the obvious reply is "well, install it"
:) |
18:30.08 |
mafm |
but my point is that maybe a check for that
file is missing |
18:30.12 |
``Erik |
well, configure should look for it
and |
18:30.13 |
``Erik |
yeah |
18:30.25 |
``Erik |
enable local incrTcl or stop the script,
something |
18:31.55 |
mafm |
the -litk seems to be missing, also:
/usr/bin/ld: ../../src/libtclcad/.libs/libtclcad.so: error:
undefined reference to 'Itk_Init' |
18:32.09 |
``Erik |
that might be macro fu |
18:32.46 |
``Erik |
is testing a configure.ac
tweak here, wait a minute it gets committed... |
18:33.38 |
mafm |
I'm adding it to LDFLAGS myself, only 3 errors
to go, and one of them is this |
18:35.27 |
``Erik |
give that a whack, it might cover several of
your LDFLAGS issues... O.o :D |
18:35.36 |
CIA-43 |
BRL-CAD: 03erikgreenwald * r37582
10/brlcad/trunk/configure.ac: Attempt to include itk.h in the
itcl/itk compile/run test. Should detect the situation where libitk
and itcl-dev are installed, but itk-dev is not (mafm's
find). |
18:36.18 |
mafm |
do I test removing the recently installed
itk3-dev first, to check if it fixes it? |
18:37.05 |
``Erik |
um, if you have time to waste, I didn't think
you'd installed it yet... :) *shrug* if it's not right, at least
it's not more wrong... :D |
18:37.52 |
``Erik |
if you'd rather work on other stuff, we can
make starseeker set something up to test it :D he's a linux
weenie... |
18:38.41 |
mafm |
well, with itk3-dev and LDFLAGS="-litk3.3" it
works, and all errors are finally gone |
18:38.54 |
``Erik |
<-- has only seen a -dev package seperation
on few linux distros, never on a unix/bsd |
18:39.16 |
mafm |
I succeeded in the adulthood test, whetever
the name :P |
18:39.41 |
mafm |
I think that debian always separes -dev, or
almost always |
18:40.01 |
``Erik |
compilation completed? didja try running bench
and regress? |
18:41.00 |
``Erik |
debian didn't used to... but I moved my
primary interest from debian to fbsd around a decade ago, and those
misc/debian remnants that were 'horribly and misleadingly outdated'
were from when I lost access to my last debian box.. :) |
18:41.39 |
mafm |
the missing itk should manifest as this?
incrTcl was disabled, but no system incrTcl library was
found |
18:42.44 |
mafm |
well, actually you can save loads of MB when
installing on tiny boxes, probably they did it because of the arm
and mips ports |
18:43.31 |
``Erik |
if the incrTcl build was explicitely disabled
and there is no system incrTcl, you'll lost stuff like mged if it's
allowed to build at all... I dunno the tcl stuff |
18:43.53 |
``Erik |
I'd guess it was more of a "why add all these
files and stuff when puny mortals will never know they're
gone" |
18:44.16 |
``Erik |
picobsd works dandy in tight configurations
with all that, and ucLinux seems to be hot for embedded |
18:44.43 |
``Erik |
hehehe... FreeBSD 8.0-STABLE FreeBSD
8.0-STABLE #0: Sat Dec 5 08:24:01 EST 2009
erik@fenris:/usr/obj/arm/usr/src/sys/DB-88F6XXX arm |
18:45.49 |
``Erik |
(basically a souped up sheeva plug... 7 usb
ports, onboard vga, JTAG, more ram, etc) |
18:46.09 |
mafm |
dunno, but nowadays for example maemo in nokia
advanced sets runs with Debian (nokia is /the/ mobile manufacturer
in Europe, dunno about US) |
18:46.23 |
mafm |
aaaaaanyway, what I meant with the incrTcl
thingy.. |
18:46.42 |
mafm |
that's the error that I get without itk3
installed and your new configure.ac |
18:47.00 |
``Erik |
none of nokia's cool phones make it to the US
:( the cellphone networks are run by idiots |
18:47.22 |
mafm |
so is this the proper manifestation of the
missing lib, or should warn about the missing itk itself? |
18:47.30 |
``Erik |
geeks look at european and japanese 'low end'
cellphones in awe :( the iphone was insanely ahead of the rest when
it came out, fo rexample |
18:48.17 |
``Erik |
I'm not sure, personally, I'd think BRL-CAD
should be able to build without incrTcl (or tcl at all) to allow
library only incarnations |
18:48.49 |
``Erik |
but some core libraries reference tcl and
there MIGHT be scripts buried somewhere that use incr format for oo
stuff... like I said, I don't know the tcl part |
18:49.07 |
``Erik |
I'm sure brlcad will opine when he returns
:) |
18:49.23 |
mafm |
configure:33685: checking for incrTcl library
functionality |
18:49.25 |
mafm |
[compiler command] |
18:49.26 |
mafm |
conftest.c:128:17: error: itk.h: No such file
or directory |
18:49.39 |
mafm |
so yes, it seems that it's the correct
error |
18:49.43 |
``Erik |
ayup, that was what I was shooting for
:D |
18:50.05 |
``Erik |
it's now as dependant on incrTk as it is on
incrTcl. |
18:50.23 |
mafm |
goody |
18:50.37 |
mafm |
now, test without LDFLAGS and itk3-dev
installed... |
18:50.50 |
``Erik |
<-- was actually figuring on bugging
starseeker in a bit, has a stripped down machine (no X, no tcl),
but configure still imagines it wants to build tkhtml3 |
18:52.00 |
mafm |
ewwwww, I have strange errors now when
compilint the conftest :( |
18:52.33 |
``Erik |
O.o http://pastebin.bzflag.bz ? (or
http://paste.lisp.org if you're
feeling moar awesumz) |
18:52.48 |
mafm |
http://paste.debian.net/58859/ |
18:53.09 |
mafm |
oh, bzflag has its own pastebing... spiffy
:D |
18:53.27 |
``Erik |
yeh, brlcad.org == *.bzflag.bz |
18:53.27 |
mafm |
You don't have permission to access / on this
server. :|||| |
18:53.52 |
mafm |
anyway, pasted above in the other
site |
18:54.07 |
``Erik |
it's pastebin.bzflag.bz, not
.brlcad.org |
18:54.13 |
``Erik |
whu, who |
18:54.15 |
``Erik |
whoa |
18:54.17 |
``Erik |
it's busted good |
18:54.50 |
``Erik |
tclInt.h should be from, uh, tcl85-dev or
whatever |
18:55.19 |
mafm |
it is |
18:55.56 |
mafm |
err, wait, it's itclInt |
18:55.57 |
``Erik |
is it in /usr/include/tcl8.5/ ? (maybe
/usr/include/tcl8.5/generic ?) |
18:56.02 |
mafm |
what a mess with all these iiiiiiis |
18:56.50 |
``Erik |
yes... they thought they were being clever...
they hacked on a horrible mockery of OO to tcl... like C++ does to
C... and 'incr' is the tcl-ese for ++ |
18:57.15 |
mafm |
<PROTECTED> |
18:57.41 |
``Erik |
supposedly, 86 will have a decent enough
native oo where we can ditch incrTcl and live happily ever after
:) |
18:59.07 |
mafm |
8.6 is in experimental, didn't hit unstable
yet |
18:59.13 |
mafm |
but I could try |
18:59.32 |
``Erik |
well, not asking you to, just mentioning that
there is hope... that someday... |
18:59.34 |
mafm |
anyway I suppose that you didn't migrate
completely yet |
18:59.49 |
mafm |
hopefully, yep :) |
19:01.06 |
``Erik |
we tend to be fairly fast in jumping on new
versions... tcl 8.5 before most distros had it, ... at one point, I
was pulling pieces of incr from CVS as bug fixes, since they were
taking way too long |
19:01.54 |
mafm |
hmm |
19:02.09 |
mafm |
but what's the problem in this case, a bug in
itcl too? |
19:02.32 |
``Erik |
dunno |
19:02.35 |
mafm |
it seems to include "tclInt.h" which doesn't
exist locally, but in subdirs |
19:02.49 |
``Erik |
it seems like mebbe debian messed with actual
install paths in funny ways, mebbe? |
19:03.08 |
``Erik |
/usr/local/include/tcl8.4/generic/tclInt.h |
19:03.49 |
``Erik |
that's where mine is, which is reasonably
close to 'stock' (just moves all the tcl files into
tcl8.4/ |
19:04.10 |
``Erik |
heh, fbsd 4.7 binaries coming off of this disk
I'm recovering... yowza |
19:04.39 |
mafm |
here it introduces the intermediate
itcl-private/ |
19:06.08 |
``Erik |
mebbe one of the other tcl using debs has some
fu for that you could crib? |
19:07.04 |
mafm |
mmm |
19:08.22 |
``Erik |
argh... old C... I used va_start et all when I
coulda used a very succinct macro :( |
19:10.12 |
mafm |
what's that macro? |
19:13.25 |
``Erik |
variatic macro... woulda been, uh, #define
print_and_die(args...) { print(args); exit(-1); } |
19:13.33 |
``Erik |
something to that effect |
19:13.54 |
``Erik |
instead it's a 30 line monster reimplementing
a subset of printf |
19:14.40 |
``Erik |
well, the snow has started here... blizzard
time :D |
19:25.50 |
*** join/#brlcad Yoshi47
(~jan@64.235.102.210) |
19:25.56 |
mafm |
:) |
19:26.07 |
mafm |
I implemented something like that for a
logger-like function |
19:26.39 |
mafm |
I don't like the C++ << crap when you
want to format something |
19:28.59 |
``Erik |
c++ can still use the fprintf family |
19:29.58 |
mafm |
well yes, but I implemented it as a
logger |
19:30.31 |
mafm |
so you say logDEBUG("error in %s: %s",
__file__, errorStr); |
19:30.57 |
mafm |
same as fprintf but without putting fprintf
everywhere |
19:31.16 |
mafm |
actually the __file__ part and other stuff,
like timestamp, where automatically printed but hidded from
caller |
19:42.48 |
mafm |
``Erik: could you please $ locate
itclInt.h? |
19:43.32 |
``Erik |
uhm, I don't install incr from package, I just
use the BRL-CAD one |
19:45.25 |
mafm |
so bad |
19:45.41 |
mafm |
Files /usr/include/tcl8.5/itclInt.h and
/usr/include/tcl8.5/itcl-private/generic/itclInt.h are
identical |
19:45.49 |
mafm |
I think that therein lies the
problem |
19:50.00 |
mafm |
did you try to recompile after you changes
``Erik? |
19:50.34 |
``Erik |
yup |
19:50.52 |
``Erik |
lemme try again *shrug* |
19:51.25 |
``Erik |
but I'm pretty limited in what I have
available tow ork with, I took the day off and my home machines are
mostly torn down to move data off of a stack of old hard
drives |
19:52.29 |
mafm |
well, np then, just wondering if it's a
problem with me or maybe outdated code that was disabled for a
reason |
19:54.26 |
mafm |
the thing is that before you fixed it I could
do things by hand, now it doesn't even finish configuring |
19:58.08 |
``Erik |
are you still using --disable-incrtcl or
whatever? |
19:58.34 |
``Erik |
<-- wasn't able to get it to use a system
incrtcl/incrtk well on fbsd after a bunch of fighting, that's why
the port forces it to build :/ |
20:22.10 |
mafm |
disable-all |
20:22.48 |
``Erik |
isn't sure that CAN work, ...
mebbe if tons of environment flags are set?
*shrug* |
20:24.58 |
mafm |
I'm modifying the test for that case,
including <tcl.h> before that, just in the case |
20:25.03 |
mafm |
it can harm, can it? |
20:26.51 |
``Erik |
dunno, if it breaks one of the 'normal' ways
of building, it'll get fixed... :)) |
20:31.53 |
mafm |
adding <tcl.h> in front doesn't fix
it |
20:32.00 |
mafm |
darnit, tcl! |
21:20.35 |
mafm |
I think that it has to do with how you include
info from tclConfig.sh and friends |
21:35.42 |
``Erik |
tried to convince folk to
ditch tcl's bass ackwards build system and do a nice clean normal
one, but the argument to keep things as original as possible won
over |
21:36.35 |
mafm |
meh |
21:37.26 |
``Erik |
a decent swig integration would be ... most
interesting :) |
22:00.19 |
*** join/#brlcad Ralith
(~ralith@69.90.48.97) |