00:15.31 |
``Erik |
hm |
00:34.38 |
brlcad |
how was dinner with la chica loca? |
00:36.03 |
starseeker |
raises
eyebrow |
00:38.03 |
``Erik |
la what now? |
00:38.57 |
``Erik |
oh |
00:39.13 |
``Erik |
heh, I didn't get out of there until too late,
so I called them and let them know I wouldn't make it |
00:46.24 |
starseeker |
is bemused - the stix fonts
are still not released, but at least they finally settled on the
SIL Open Font License |
00:46.52 |
starseeker |
also, they have "discovered many missing
glyphs in the non-Unicode fonts" |
00:47.01 |
starseeker |
wonders how that
happened... |
00:50.17 |
AirBender |
what is bwish in brlcad sources? |
00:51.36 |
AirBender |
uhmm something like a customized tcl/tk
? |
00:51.50 |
AirBender |
is it needed? can I use just Tcl/Tk? |
00:53.25 |
starseeker |
you can build with a system Tcl/Tk if it's the
right version, but IIRC bwish is still built as a wrapper? I'd
have to check |
00:53.41 |
AirBender |
ok |
00:53.42 |
starseeker |
is bwish causing a problem? |
00:53.51 |
starseeker |
can usually treat it like
wish |
00:53.55 |
AirBender |
I'm having undefined references with
bwish |
00:54.05 |
starseeker |
blinks |
00:54.09 |
starseeker |
starting MGED? |
00:54.17 |
AirBender |
tkImgFmtPIX |
00:54.29 |
starseeker |
which program are you running? |
00:54.30 |
AirBender |
when compiling brlcad |
00:54.33 |
starseeker |
oh |
00:54.36 |
AirBender |
from svn |
00:54.56 |
starseeker |
um - you might try updating - there've been a
lot of commits today... |
00:55.05 |
starseeker |
dunno if any of theim hit that part |
00:55.06 |
AirBender |
ok |
00:55.12 |
starseeker |
which directory is it failing in? |
00:55.24 |
AirBender |
the symbol is required in cmd.c from
bwish |
00:55.39 |
AirBender |
src/bwish/cmd.c |
00:55.44 |
AirBender |
lne 76 |
00:55.48 |
AirBender |
line* |
00:56.05 |
starseeker |
erm |
00:56.26 |
starseeker |
yeah, try an svn up first and see if that
pulls any fixes |
00:56.35 |
AirBender |
yeap, doing that |
00:56.49 |
AirBender |
36338 |
00:56.58 |
AirBender |
let's see |
01:03.24 |
AirBender |
lots of warning huh... |
01:06.32 |
AirBender |
by far the most warning-full compilation I've
ever done... =D |
01:06.46 |
starseeker |
hmm, font article: http://mihmo.livejournal.com/45152.html |
01:06.57 |
starseeker |
AirBender: yeah, it's a bit noisy in some
areas |
01:07.06 |
starseeker |
particularly on the newest gcc
compilers |
01:08.00 |
AirBender |
yeap |
01:08.34 |
CIA-22 |
BRL-CAD: 03starseeker * r36339
10/brlcad/trunk/configure.ac: If we aren't ready to build step yet,
can't have the Makefile in configure.ac without breaking
distcheck. |
01:13.05 |
*** join/#brlcad matthewmpp_
(n=chatzill@wsip-98-172-82-189.ph.ph.cox.net) |
01:13.54 |
brlcad |
AirBender: what are your configure
flags? |
01:13.55 |
*** part/#brlcad matthewmpp
(n=chatzill@wsip-98-172-82-189.ph.ph.cox.net) |
01:15.12 |
brlcad |
a couple dirs are chatty, but you really
shouldn't be getting a lot of warnings unless you enabled
additional warnings |
01:15.13 |
AirBender |
mmm |
01:15.32 |
brlcad |
more than a dozen of the core are even
completely warning-free |
01:15.34 |
AirBender |
--enable-optimized --widh-ogl
--prefix=/usr/local/brlcad |
01:15.47 |
brlcad |
huh, interesting |
01:16.13 |
AirBender |
may be the reason is I'm using Gcc
4.x.x |
01:16.32 |
AirBender |
may be the reason is I'm using Gcc
4.4.1 |
01:16.45 |
brlcad |
nah, I've run many a build on 4.4
already |
01:16.50 |
AirBender |
ok |
01:17.29 |
brlcad |
also, fwiw, the bwish issue is something
pretty recent from one of the 100+ commits today |
01:17.46 |
AirBender |
I think it's ok now |
01:17.46 |
brlcad |
if you want a stable build, can grab the
stable branch instead |
01:18.13 |
AirBender |
I want to be synced with svn |
01:18.22 |
AirBender |
there's no problem |
01:18.25 |
brlcad |
so you were just out of sync? |
01:18.31 |
AirBender |
it's building ok now |
01:18.40 |
brlcad |
or did you edit something? |
01:18.53 |
AirBender |
and the warning were on the first 10 minutes
of compiling... |
01:19.04 |
brlcad |
oh, heh |
01:19.05 |
brlcad |
yeah |
01:19.16 |
brlcad |
everything in src/other is not our code, so
it's chocked full of warnings |
01:19.24 |
brlcad |
that compiles fire |
01:19.26 |
brlcad |
*first |
01:19.33 |
AirBender |
I see... |
01:19.41 |
AirBender |
well it's my first time with brlcad |
01:19.58 |
brlcad |
src/other are our external dependencies, they
compile when it doesn't detect a suitable system-installed version
of that dependency |
01:20.09 |
brlcad |
e.g., libpng, libz, tcl/tk, etc |
01:20.20 |
AirBender |
yes, I've read it some minutes
ago... |
01:21.03 |
AirBender |
interesting approach... instead of installing
every dependency on avery error |
01:22.46 |
brlcad |
*nod*, mostly download/distribution
convenience but also for controlled compilation testing |
01:22.58 |
AirBender |
ok |
01:23.00 |
brlcad |
lets us turn everything on or everything off
or individually, etc |
01:24.22 |
AirBender |
by the way, do you see brlcad as a replacing
for CATIA? |
01:25.07 |
AirBender |
replacement* |
01:25.11 |
AirBender |
sorry for my english |
01:25.33 |
brlcad |
that's certainly a desirable achievement and a
package that covers a similar domain |
01:25.34 |
CIA-22 |
BRL-CAD: 03starseeker * r36340
10/brlcad/trunk/src/libdm/dm-rtgl.c: Well, can now refresh with B -
but doing a draw of a second item when the first one is working
without either letting the first one finish or clearing causes a
crash. |
01:26.07 |
brlcad |
but I more see ourselves as just doing the
best at whatever our users need, more niche requirements, more
flexible customization |
01:27.03 |
brlcad |
CATIA employs more than 1000 developers -- we
have quite a ways to reach that scale to be considered an outright
replacement for all their features |
01:27.16 |
AirBender |
I know, and I understand that... |
01:27.39 |
AirBender |
I just wanted to read an opinion of the
current state |
01:28.04 |
``Erik |
seen the 'industry diagram' on the web
site? |
01:28.24 |
AirBender |
uhmm in the screenshots? |
01:29.11 |
``Erik |
in the 'diagrams' chunk of the gallery,
yes |
01:29.22 |
``Erik |
http://brlcad.org/gallery/s/diagrams/Industry_Diagram.png.html |
01:30.23 |
``Erik |
that kinda helps explain our... niche
:) |
01:30.23 |
AirBender |
interesting... |
01:31.15 |
starseeker |
hmm, caps only, but looks OK small (not
clearly licensed though :-() http://www.kottke.org/plus/type/silkscreen/ |
01:31.28 |
brlcad |
we're slowly expanging towards the
left |
01:32.54 |
AirBender |
excellent |
01:33.05 |
brlcad |
starseeker: not bad.. not as good as profont
though :) |
01:33.17 |
brlcad |
plus the all-caps is rather annoying |
01:33.26 |
starseeker |
nods |
01:33.55 |
starseeker |
downloads profont to see if
he can dig the author's name out of the font
file... |
01:35.35 |
AirBender |
cool just finished the build process...
installing now |
01:35.56 |
AirBender |
Many thanks for the help |
01:36.37 |
starseeker |
thanks for trying it out! |
01:36.41 |
AirBender |
hope brlcad meets my partner's
requirements... |
01:36.47 |
AirBender |
in fact they will be the users... |
01:36.57 |
starseeker |
run /usr/local/brlcad/bin/mged to get
going |
01:37.10 |
AirBender |
I'm just building it |
01:37.17 |
AirBender |
ok |
01:37.29 |
starseeker |
you saw the docs page? |
01:37.53 |
AirBender |
not too much |
01:37.56 |
starseeker |
http://brlcad.org/wiki/Documentation |
01:38.14 |
starseeker |
specifically, Introduction to MGED and the
MGED Quick Reference Card |
01:39.10 |
AirBender |
ok |
01:39.23 |
brlcad |
AirBender: yeah, that tutorial book is
required reading -- just like any CAD system, it's very complex
with a lot to learn for new users |
01:40.18 |
brlcad |
if you want to try something fun, can run the
"/usr/local/brlcad/bin/benchmark" command to test your system
performance |
01:40.20 |
AirBender |
I know... but that's for my partners... I have
enough to do with my part(communications/electronics) |
01:40.47 |
AirBender |
will try that |
01:42.13 |
AirBender |
Wow, nice to see good documentation |
01:43.57 |
AirBender |
seems like your specialty is in the cmputer
graphics/rendering area... |
01:44.30 |
AirBender |
well it's the most atractive info to publish
anyway =D |
01:47.37 |
starseeker |
brlcad: I take it most of the profont bzflag
discussion took place on irc? |
01:47.46 |
brlcad |
starseeker: mostly |
01:47.59 |
brlcad |
starseeker: try emailing the profont
addrs |
01:48.09 |
brlcad |
there should be a couple in the license
file |
01:48.36 |
brlcad |
the problem is the license file is mostly just
poorly worded |
01:48.54 |
starseeker |
nods - ooooold ones - figured
those had been tried already, but I suppose it can't
hurt |
01:48.56 |
brlcad |
I remember it having a couple serious
problems |
01:50.13 |
starseeker |
hopes his gmail addy won't be
spam flagged... |
01:50.14 |
brlcad |
the terms "maybe" added an additional
restriction and didn't explicitly allow derivative works |
01:50.30 |
brlcad |
both those being lgpl/gpl
incompatibilities |
01:50.40 |
starseeker |
nods |
01:51.01 |
brlcad |
otherwise the terms are almost cc-by or
cc-by-nc (the latter of which would be a problem) |
01:51.25 |
brlcad |
looks up the
name |
01:51.32 |
starseeker |
what do you make of the SIL open font
license? |
01:51.52 |
brlcad |
so yeah, Carl Osterwald or Steve Gilardi would
probably suffice |
01:53.13 |
AirBender |
is the benchmark usable for the
developers? |
01:53.19 |
AirBender |
or just for my interest? |
01:53.27 |
AirBender |
it finished |
01:53.52 |
AirBender |
6651 times faster than reference |
01:54.42 |
brlcad |
AirBender: it explains what the number means,
but yeah it's useful to know |
01:55.11 |
starseeker |
raises his eyebrow - never
seen a one letter prefix to a mac.com email
address |
01:55.19 |
brlcad |
plus it gives you a metric you can run system
to system, compilation to compilation, etc .. and gives you a
directly comparable metric |
01:56.30 |
brlcad |
starseeker: er, don't think they're valid..
three is the min |
01:59.24 |
starseeker |
brlcad: hmm. must be a red herring |
01:59.48 |
AirBender |
well, hope to be able to cooperate with this
great project in the near future |
02:00.02 |
brlcad |
AirBender: likewise! |
02:00.02 |
starseeker |
"Carl R. Osterwald"
<i.DeleteThis@mac.com> wrote... |
02:00.20 |
AirBender |
now we will install it on the other
computers |
02:00.47 |
brlcad |
we're always looking for new devs |
02:00.51 |
brlcad |
if you're a developer |
02:01.01 |
AirBender |
I've read that there's a C++ abstraction layer
in development? |
02:01.15 |
brlcad |
yeah, geometry engine akin to the ACIS
engine |
02:01.27 |
AirBender |
ok |
02:01.53 |
brlcad |
we have a C API over geometry services right
now |
02:02.19 |
brlcad |
http://brlcad.org/BRL-CAD_Priorities.png |
02:02.39 |
brlcad |
high-level marketing priority talk |
02:03.16 |
brlcad |
starseeker: can't hurt to e-mail/cc every
address you find :) |
02:04.33 |
brlcad |
or contacting folks they used to
know |
02:04.39 |
brlcad |
we didn't go that far last time |
02:04.48 |
brlcad |
(e.g., http://bishop.mc.duke.edu/bolo/guides/mapedit.html
) |
02:05.56 |
starseeker |
suspects anything short of
sending out paid detectives would be easier than finding brlcad a
satisfactory replacement font :-) |
02:09.02 |
*** join/#brlcad maes
(n=maes@190.163.31.17) |
02:10.58 |
*** part/#brlcad maes
(n=maes@190.163.31.17) |
02:12.28 |
*** join/#brlcad maes
(n=maes@190.163.31.17) |
02:12.50 |
brlcad |
one e-mail to a dozen addresses is pretty easy
:P |
02:12.59 |
starseeker |
hehe |
02:13.16 |
brlcad |
they'll either come back failures or get
ignored |
02:13.22 |
starseeker |
it doesn't get serious until we pick up the
phone and start calling people |
02:15.05 |
brlcad |
would totally be worth it for that
font |
02:15.19 |
brlcad |
tens of thousands of geeks would
rejoice |
02:16.40 |
starseeker |
well, distcheck now passes again on the
Mac |
02:16.57 |
starseeker |
sans step-g, sadly :-( |
02:17.22 |
starseeker |
really doesn't get that, what
it is saying is undefined IS defined in an included header, and
Linux can find it... |
02:20.38 |
starseeker |
should probably head home
now |
02:21.30 |
starseeker |
saddles up and moves
out |
02:38.46 |
CIA-22 |
BRL-CAD: 03brlcad * r36341
10/brlcad/trunk/src/bwish/cmd.c: |
02:38.46 |
CIA-22 |
BRL-CAD: document the Tk_PhotoImageFormat
tkImgFmtPIX structure, that it comes from |
02:38.46 |
CIA-22 |
BRL-CAD: libtclcad and providing PIX image
processing support to Tk's image subsystem |
02:38.46 |
CIA-22 |
BRL-CAD: (even though it only seems to be used
by bwish and not mged oddly enough). |
02:38.46 |
CIA-22 |
BRL-CAD: restructure to avoid decls while
we're at it. |
03:07.04 |
*** part/#brlcad maes
(n=maes@190.163.31.17) |
04:18.39 |
CIA-22 |
BRL-CAD: 03brlcad * r36342
10/brlcad/trunk/src/conv/step/OpenNurbsInterfaces.cpp: our nurbs
headers have to come after the step/sdai headers because we also
define DEBUG_OFF |
04:19.37 |
CIA-22 |
BRL-CAD: 03brlcad * r36343
10/brlcad/trunk/src/conv/step/RepresentationItem.h: missing sdai.h
for the SCLP23wahtever wrappage. |
04:20.51 |
CIA-22 |
BRL-CAD: 03brlcad * r36344
10/brlcad/trunk/configure.ac: readd step to build, it should
generate the makefile regardless of compilability |
04:24.01 |
CIA-22 |
BRL-CAD: 03brlcad * r36345
10/brlcad/trunk/src/conv/Makefile.am: re-enable traversal into the
step dir. critical piece seems to be missing here that you have to
define DIST_SUBDIRS so we traverse all dist dirs regardless of
SUBDIRS (which isn't the same as EXTRA_DIST'ing a
subtree) |
04:24.48 |
CIA-22 |
BRL-CAD: 03brlcad * r36346
10/brlcad/trunk/src/conv/step/Makefile.am: minor cleanup,
one-per-line, shouldn't tab empty lines, declare built
sources. |
04:25.42 |
PrezKennedy |
brlcad, guess what my current title at the
pentagon is |
04:26.06 |
starseeker |
grins evilly... must resist
temptation... |
04:26.24 |
starseeker |
brlcad: thanks alot for looking at that step
stuff |
04:26.32 |
starseeker |
is grateful |
04:26.44 |
brlcad |
there are compilation failures/assumptions
galore that still have to get fixed |
04:27.03 |
brlcad |
PrezKennedy: Monkey Butler? |
04:27.21 |
PrezKennedy |
close... computer programmer |
04:27.30 |
brlcad |
cool |
04:39.53 |
CIA-22 |
BRL-CAD: 03brlcad * r36347
10/brlcad/trunk/include/ (dvec.h vector.h): rename vector.h to
dvec.h so we can avoid a name clash with the old stl compatibility
header of same name |
04:39.53 |
CIA-22 |
BRL-CAD: 03brlcad * r36348
10/brlcad/trunk/include/dvec.h: rename to dvec.h; need raytrace.h
for fastf_t |
04:39.53 |
CIA-22 |
BRL-CAD: 03brlcad * r36349
10/brlcad/trunk/src/conv/step/PullbackCurve.cpp: include dvec.h
instead of vector.h so we get the right header |
04:39.53 |
brlcad |
so that gets it to compile for me (untested
runtime) |
04:39.53 |
brlcad |
check distcheck and see if it still
fails |
04:39.55 |
PrezKennedy |
its all good, contract will be over long
before we ever have the tools we need to code :) |
04:40.12 |
brlcad |
excellent |
04:46.28 |
brlcad |
starseeker: mini todo list for the mess in
there... 1) copyright headers to all files (sh/header.sh, you or
indianlarry since it was proxy should be fine), 2) standard
footers, 3) no using namespace std;, 4) headers are a mess (see
HACKING) but at least need common.h first, then system, then
whatever else everywhere for portability, 5) svn:ignore dir
products (docs need that too), 6) indentation
(sh/indent.sh) |
04:50.05 |
starseeker |
brlcad: sounds good - I'll hit it first thing
tomorrow morning (will sleep momentarily) |
04:50.38 |
starseeker |
sorry about docs - been building out of dir
too much and forgot the reorg wiped out the old settings |
04:51.22 |
starseeker |
muchas gracias :-) |
04:53.58 |
*** join/#brlcad Ralith_
(n=ralith@69.90.49.189) |
04:54.24 |
*** join/#brlcad kanzure
(i=bryan@dhcp-84-36.me.utexas.edu) |
06:39.57 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) [NETSPLIT
VICTIM] |
06:40.48 |
*** join/#brlcad kanzure
(i=bryan@dhcp-84-36.me.utexas.edu) [NETSPLIT
VICTIM] |
07:04.28 |
*** join/#brlcad cpc26
(n=cpc26@72.170.156.242) |
07:52.45 |
*** join/#brlcad cpc26
(n=cpc26@72.170.156.242) |
08:53.26 |
CIA-22 |
BRL-CAD: 03brlcad * r36350
10/brlcad/trunk/include/Makefile.am: vector.h was renamed to
dvec.h |
09:48.40 |
CIA-22 |
BRL-CAD: 03d_rossberg * r36351
10/brlcad/trunk/src/librt/ (4 files in 2 dirs): vector.h was
renamed to dvec.h because of possible a conflict with a STL header
file name |
10:13.16 |
CIA-22 |
BRL-CAD: 03d_rossberg * r36352
10/brlcad/trunk/src/conv/obj-g.c: because of MSVC compiler error:
replaced c99 idiom with c89 compatible one (all declarations have
to be on top of a block) |
12:05.14 |
*** join/#brlcad _clock_
(n=_sushi_@80-218-244-105.dclient.hispeed.ch) |
12:11.32 |
CIA-22 |
BRL-CAD: 03brlcad * r36353
10/brlcad/trunk/src/librt/brep_test.cpp: another vector.h to dvec.h
conversion |
13:32.11 |
*** join/#brlcad parigaudi
(n=quassel@pd95b7f5e.dip0.t-ipconnect.de) |
13:44.40 |
*** join/#brlcad Elrohir
(n=kvirc@p5B14EE36.dip.t-dialin.net) |
13:50.23 |
CIA-22 |
BRL-CAD: 03brlcad * r36354
10/brlcad/trunk/src/util/Makefile.am: need to put the source in
extra dist manually if it's not compiled, just like the
others |
13:51.39 |
CIA-22 |
BRL-CAD: 03brlcad * r36355
10/brlcad/trunk/doc/docbook/Makefile.am: handful of other files and
one dir missing from the dist. nirt fig20, authors xml, mged05
image, spec image dir, and manpage readme missing. |
13:53.36 |
starseeker |
brlcad: ah, thanks |
13:55.21 |
brlcad |
do you get a slew of warnings in the step dir
about "warning: ignoring old commands for target"? |
13:55.33 |
starseeker |
yes |
13:55.44 |
starseeker |
on Mac |
13:55.44 |
brlcad |
is that from a clean checkout? |
13:55.46 |
starseeker |
not sure about Linux |
13:55.50 |
starseeker |
I believe so |
13:56.00 |
brlcad |
not one that "upgraded" to having it
enabled |
13:56.48 |
starseeker |
oh, wait |
13:57.12 |
brlcad |
i think it's the two variable rules causing
it, but needs to be tested clean first in case it's red
herring |
13:57.14 |
starseeker |
I think I saw those warnings only when
conv/step was enabled |
13:58.04 |
starseeker |
does a quick svn
status |
13:58.46 |
brlcad |
it's not how it is now -- it's whether you had
a plain checkout/build with it already on, or if you reran
autogen.sh at some point |
13:59.20 |
brlcad |
only way to test clean is: sh autogen.sh
&& ./configure && make distclean && sh
autogen.sh && ./configure --whatevers.... |
13:59.28 |
brlcad |
or just check out clean again |
13:59.54 |
brlcad |
hits the
road |
14:00.05 |
starseeker |
brlcad: I've been doing part of that cleaning
process, but not full - I was just getting set up for a distcheck
build so I'll give it a go |
14:00.49 |
brlcad |
you only need the double autogen/configure
when you suspect its automake being pissy .. which those
double-rules could be |
14:01.03 |
brlcad |
course, that ${}: rule is screwy too |
14:01.49 |
brlcad |
that probably needs to be changed, plus the
other change, and hopefully we're good to go with a few doc
updates |
14:02.10 |
brlcad |
need to get larry to document his change in
TODO |
14:02.13 |
brlcad |
er NEWS |
14:02.28 |
starseeker |
freudian slip ;-) |
14:02.47 |
brlcad |
not really, TODO needs to be updated too
:) |
14:03.26 |
starseeker |
wishes indianlarry had
committed his recent work - merging in any changes after I get done
with indents and header/footers will be hell |
14:03.44 |
starseeker |
oh, well - burnt hand teaches best
:-P |
14:05.32 |
*** join/#brlcad KingofCSU
(n=king@222.247.247.227) |
14:11.00 |
brlcad |
word of caution that indent.sh results need to
be visually inspected |
14:11.10 |
brlcad |
particularly if there are #ifdefs or
namespaces |
14:11.44 |
brlcad |
easier if there are headers/footers first as
the footer will end up being indented indicating there are extra
braces |
14:37.11 |
starseeker |
hrm make[2]: *** No rule to make target
`html/specifications/en/images', needed by `distdir' |
14:37.14 |
starseeker |
checks |
14:38.37 |
starseeker |
oh - brlcad, the reason spec images weren't
there yet is that there aren't any (yet) |
14:43.04 |
starseeker |
the empty directory was causing problems,
iirc |
14:45.05 |
starseeker |
doesn't remember which
ones |
14:56.54 |
starseeker |
deletes the spec images
directory until needed |
14:59.51 |
CIA-22 |
BRL-CAD: 03starseeker * r36356
10/brlcad/trunk/doc/docbook/ (Makefile.am
specifications/en/images/): Don't put an empty directory in the svn
repository - will re-enable this logic once there are actual
specification images. |
15:08.08 |
starseeker |
yeah, it's overriding commands in step dir on
a clean build |
15:13.08 |
CIA-22 |
BRL-CAD: 03starseeker * r36357
10/brlcad/trunk/src/conv/step/ (344 files): Add footers to all step
conv files that don't appear to be static copies of NIST files -
need to discuss what has to happen with the NIST code with
indianlarry in order to use the step libs in
src/otheer/step |
15:17.45 |
CIA-22 |
BRL-CAD: 03starseeker * r36358
10/brlcad/trunk/src/conv/step/ (STEPEntity.cpp STEPEntity.h
STEPWrapper.cpp STEPWrapper.h): Get a few more files that aren't
NIST copies. |
15:57.10 |
starseeker |
hmm, interesting: http://pastebin.bzflag.bz/m3e5e2b63 |
16:10.00 |
starseeker |
does Mac have emmintrin.h I
wonder... |
16:10.38 |
starseeker |
ok it does... |
16:14.21 |
starseeker |
const double *, that looks ok... |
16:39.48 |
*** join/#brlcad parigaudi
(n=quassel@pd95b7f5e.dip0.t-ipconnect.de) |
17:23.48 |
``Erik |
ppc mac? didja try building a universal
binary? |
18:26.46 |
``Erik |
"The greeks invented sex. Later, the italians
invented it with women." |
18:32.52 |
starseeker |
brlcad: yep, you called it - the fpu
implementation works |
18:39.54 |
brlcad |
you should compmile on linux with fpu, then
compare sse vs fpu |
18:40.22 |
starseeker |
wouldn't fpu pretty much always be
slower? |
18:40.31 |
starseeker |
shudders to think about
raytracing |
18:42.00 |
CIA-22 |
BRL-CAD: 03starseeker * r36359
10/brlcad/trunk/src/conv/step/ (PullbackCurve.cpp PullbackCurve.h):
Put headers on PullBackCurve files |
18:51.27 |
CIA-22 |
BRL-CAD: 03starseeker * r36360
10/brlcad/trunk/src/conv/step/ (6 files): Switch from using std
namespace to explicitly prefixing with std:: (per brlcad's
advice) |
18:59.28 |
*** join/#brlcad Ralith
(n=ralith@d142-058-090-093.wireless.sfu.ca) |
18:59.38 |
starseeker |
hey Ralith :-) |
19:00.01 |
Ralith |
hullo |
19:00.07 |
starseeker |
how goes it? |
19:00.28 |
Ralith |
much to my dismay, univ involves work
;_; |
19:00.35 |
starseeker |
heh |
19:00.53 |
starseeker |
yeah, they do like that |
19:01.17 |
Ralith |
at least it's friday |
19:02.47 |
starseeker |
Ralith: do you recall if we're using
quaterniuns for rotation in ogre or is it the yaw, pitch, etc.
stuff? |
19:07.13 |
*** join/#brlcad Ralith
(n=ralith@d142-058-090-093.wireless.sfu.ca) |
19:08.31 |
Ralith |
and the wifi sucks, to boot. |
19:14.07 |
starseeker |
distcheck passes on Linux |
19:17.51 |
starseeker |
looks at the TODO file for
items to do before next release and winces |
19:25.48 |
Maloeran |
starseeker, fpu can be faster if you are doing
a lot of cos(), sin(), pow() and other stuff that the SSE
instructions won't do |
19:26.13 |
Maloeran |
Besides that... stick to SSE of course
:) |
19:40.14 |
``Erik |
I thought amd had trig 'n shtuff built into
theirs? just intel was r-tarded? :) |
19:40.25 |
``Erik |
(mebbe needs explicit 3dnow stuff) |
19:53.35 |
Maloeran |
There was no trigonometry stuff in 3dnow
either |
19:54.08 |
Maloeran |
But it had horizontal instructions, the fun
stuff that Intel took 7 years to think about and they managed not
to get it quite right either |
19:56.07 |
Maloeran |
Go USD, a recovery of 5% in just a
week! |
19:56.19 |
Maloeran |
It's amazing for such a major currency to be
so unstable... |
20:07.33 |
*** join/#brlcad Ralith_
(n=ralith@d142-058-090-093.wireless.sfu.ca) |
20:13.58 |
brlcad |
starseeker: no, the fpu is very often faster
-- it depends on a lot of factors |
20:14.07 |
brlcad |
how much work you can keep feeding the
pipeline |
20:14.48 |
brlcad |
there's a cost to transfer data into and out
of the simd registers |
20:15.11 |
brlcad |
so that cummulative overhead has to be
recovered with enough computation and minimal/no interruptions as
much possible |
20:15.36 |
``Erik |
mal: what're you talking about? CAD fluxes
like mad, sure, but I'd hardly call it a major ... :>
*duck* |
20:35.32 |
starseeker |
makes notes on personal
todo... email profont guys, benchmark fpu vs sse, check out
ttkdraw... |
20:37.11 |
Maloeran |
``Erik, that's a good point! You can see it
both ways... Either the USD is fluctuating wildly, or it is stable
but every other currency in the world is! ;) |
20:38.10 |
Maloeran |
brlcad, cost to puttign stuff in and out of
the simd registers is about the same as for the fpu |
20:38.50 |
Maloeran |
Technically, older archs like Athlon64 were
faster with fpu stuff ( a movss from memory requires zeroing out
the remaining 96 bits, so it was slower ), but recent chips like
Core 2 crunch the SSE stuff better |
20:39.40 |
Maloeran |
FPU requieres the code to fxchg all the time
to bring any value you want to work on at the top of the stack, SSE
lets you access any register directly in a sane way |
20:40.28 |
brlcad |
not just the load |
20:40.36 |
brlcad |
you still have to wait for the pipeline to
flush to get your result |
20:40.46 |
brlcad |
that's part of the "load" overhead if you
can't fill it |
20:40.59 |
Maloeran |
The latency and throughoutput of the SSE stuff
is better for all recent chips, as far as I know |
20:41.14 |
Maloeran |
If you benchmark an Athlon64 or a Pentium 4,
then it's a very different story |
20:41.55 |
brlcad |
we tested just two years ago and took a pretty
big hit for incorrent work |
20:42.32 |
brlcad |
thinks it was two, a xeon
either way |
20:42.35 |
Maloeran |
Besides all the "basic" instructions, you can
do stuff like fmin(), fmax(), fabs() without branching on SSE, it's
a single instruction |
20:42.52 |
Maloeran |
I guess it was a Xeon based on the Pentium 4
arch |
20:43.57 |
brlcad |
well we have a perfect way to test that theory
on most chips with our vmath interface |
20:44.22 |
Maloeran |
You can eliminate a lot of branches if you
begin doing bitwise stuff with SSE, but that'll take some use of
SSE intrinsics |
20:44.59 |
brlcad |
those are pretty specific cases from what I'm
talking about |
20:45.16 |
brlcad |
there are lots of things sse/simd does way
better |
20:45.19 |
brlcad |
otherwise what'd be the point |
20:45.31 |
Maloeran |
*nods* Right, I'm not too sure what your
benchmark was doing of course |
20:45.43 |
brlcad |
the general commpute case though, isn't
beneficial generally speaking though |
20:46.25 |
Maloeran |
Well I would be very surprised, I thought that
was only right for chips of the P4 or Athlon64 generation |
20:46.41 |
brlcad |
otherwise the compiler could just do it for
all math ops and we'd be good to go -- some compilers can do it for
sections of code where there is a loop of ops that translate well,
but still not for general case |
20:47.04 |
Maloeran |
nods |
20:48.06 |
brlcad |
if you're writing the algorithm fresh and can
keep the pipeline filled, great :) |
20:49.02 |
Maloeran |
I guess I'm a bit biased, I write the code
with a good idea in mind of what GCC will output... when I'm not
just using SSE intrinsics directly |
20:49.03 |
brlcad |
the test case we were using was a surface
solver iirc |
20:51.10 |
brlcad |
the only point I was making was that you can't
just take something like a simple single vector multiply, feed it
to the simd unit, and expect it to speed up |
20:52.25 |
Maloeran |
Right, although the throughoutput should be
higher with SSE on some very recent chips |
20:52.42 |
Maloeran |
x87 is getting rather deprecated |
20:52.44 |
``Erik |
be amusing to twist vmath up with sse stuff to
see what the difference is there, though |
20:52.56 |
brlcad |
throughput should be higher even on older
ones |
20:53.20 |
brlcad |
if you have more than random food for the
pipeline, you can keep it busy and get some gain |
20:53.38 |
brlcad |
that's just not the general case unless you
design for it |
20:53.54 |
brlcad |
``Erik: yeah, jason actually did that with
those vector headers in include/ |
20:53.56 |
Maloeran |
You can keep the x87 busy as well, the Athlon
FX and Athlon 64 were doing very intense register renaming under
the hood from sequences of fxchg |
20:54.06 |
brlcad |
not vmath directly, but several of the same
routines are implemented |
20:54.12 |
brlcad |
which is what he's using in the
solver |
20:54.50 |
brlcad |
yeah, l1/l2 cache on the chip is just as
important, but likewise you have to plan for it |
20:55.03 |
brlcad |
keeping data coherent and fit in cachelines
doesn't just happen |
20:55.36 |
Maloeran |
I never wrote any x87 assembly, tracking where
your stuff is on the fpu stack looks painful |
20:55.38 |
brlcad |
if you're already coherent and fit, then yeah
sure .. you'll translate pretty simply to simd and can g et even
more gains |
20:55.45 |
Maloeran |
nods |
20:56.43 |
brlcad |
totally would love to see all our CSG prims
have a coheret shot() routine with a coherent boolean eval to
leverage the same techniques that are used for triangle
tracing |
20:57.00 |
brlcad |
at least an order of magnitude to be harvested
there |
20:57.29 |
brlcad |
even with lots of data validation branches
remaining sprinkled throughout |
20:57.42 |
Maloeran |
Sounds like there are other things to worry
about before getting into fpu versus SSE :) |
20:58.11 |
brlcad |
everyone likes faster tracing ;) |
20:58.18 |
brlcad |
that'd make a great paper too |
20:58.39 |
Maloeran |
shivers at the mention of
writing papers |
20:58.45 |
brlcad |
heh |
20:58.59 |
brlcad |
you shoulda written one on rayforce at the
time :) |
20:59.13 |
Maloeran |
It looks most uninteresting to me,
really |
20:59.19 |
brlcad |
think most have caught up by now though
too |
20:59.36 |
brlcad |
"most" being ill-defined of course |
20:59.46 |
brlcad |
the top five tracer impls |
20:59.51 |
Maloeran |
Perhaps, not too sure if they are still stuck
in their BSP ages, or other tree-based techniques |
21:00.50 |
Maloeran |
I code for fun really, I just hate the thought
of reading or writing papers |
21:06.13 |
Maloeran |
Such as this rather fast "tricubic weighted
b-splines" image filtering I just wrote today for the CFD
visualization... I tend to think it would have been rather boring
to just implement what some paper might have said |
21:09.25 |
Maloeran |
( although if the algorithm has an official
name, I don't have a clue what it is ) |
21:10.42 |
``Erik |
damn you, emacs |
21:17.33 |
brlcad |
you might get joy/satisfaction just out of
solving the problem, but I hate to spend time solving a problem
that has already been solved |
21:17.47 |
brlcad |
there are plenty of unsolved problems to
resolve every problem that is simply 'new' to me |
21:17.59 |
brlcad |
to each their own :) |
21:20.51 |
``Erik |
nice http://jalemanyf.files.wordpress.com/2008/05/microsoft-fail.jpg |
21:21.29 |
``Erik |
(look at the laptop they're driving
with) |
21:28.47 |
yukonbob |
heh |
21:38.33 |
*** join/#brlcad Ralith
(n=ralith@69.90.49.189) |
22:28.10 |
starseeker |
``Erik: is that legit or a photoshop
job? |
22:28.43 |
``Erik |
dunno, had the same thought myself |
22:34.22 |
Maloeran |
True brlcad, I guess sometimes it just takes
as long to understand what someone else did and re-create it, than
just create something yourself :) |
22:34.59 |
Maloeran |
Eheh Erik, nice one |
22:45.51 |
*** join/#brlcad IriX64
(n=Warlock@bas2-sudbury98-1177726213.dsl.bell.ca) |
22:46.05 |
brlcad |
Maloeran: that's often true, but even if it's
faster to figure it out myself, to me that is still wasted effort
as it builds on nothing but my own experiences (which as impressive
as they may be will never be as much as everyone else currently and
previously alive) |
22:50.00 |
brlcad |
plus in my fatalistic view, I'll be dead soon
enough and everything I've learned is moot, so there's value in
knowing the things I've done are actually 'improvements' in some
regard as they build on those before; for whatever qualification of
'better' (faster, easier, more maintainable, foss-style free,
innovative, new, whatever) |
22:51.57 |
*** join/#brlcad louipc
(n=louipc@archlinux/trusteduser/louipc) |
22:52.23 |
``Erik |
just like exercise, you'll be dead soon
enough, and any muscle you have will just rot away, and there're
other people with more muscle :D so exercise would be
pointless |
22:52.26 |
``Erik |
*duck* |
22:52.48 |
brlcad |
if muscle were the goal, that would be
completely true :) |
22:53.08 |
``Erik |
is getting ready to code up
something overdone and useless just to get the brain exercise from
it :) |
22:53.48 |
``Erik |
provided, of course, she decides to let me O.o
cats seem to know that their proper place is on the laptops
keyboard. |
22:53.49 |
brlcad |
I do it for the "drugs" .. the endorphin
rushes, the runner's highs, the 'feel good' and 'feel fantastic'
times |
22:54.24 |
``Erik |
endorphines trigger the opiate receptors,
there're other ways to trigger those :D not nearly as healthy, but
easier and quicker |
22:54.26 |
brlcad |
makes me happy, might as well enjoy my limited
time here |
22:54.39 |
brlcad |
right |
22:54.56 |
``Erik |
or; bind to, rather |
22:55.11 |
``Erik |
brain chemistry is nutty stuff |
22:56.19 |
brlcad |
my way doesn't actually endanger others
(generally speaking), shorten my lifespan (generally speaking),
require interacting with nefarious individuals, or make an impact
on my ability to buy toys (which also just make me happy) |
22:56.46 |
``Erik |
whoa, I don't need to know about your "toys"
there, dude |
22:57.05 |
brlcad |
my toys rock |
22:57.12 |
brlcad |
:) |
22:57.48 |
``Erik |
speaking of, I've been thinking about picking
up the sheevaplugs bigger brother |
22:58.11 |
yukonbob |
laughs about ``Erik going on
about "toys" and "plugs" |
22:58.39 |
brlcad |
sheep plugs? ew |
22:58.56 |
``Erik |
sshoot, had the url the other day |
22:59.17 |
``Erik |
yukonbob: I thought you liked debian?
O.o |
22:59.31 |
brlcad |
this thing?
http://www.treehugger.com/files/2009/02/marvell-sheevaplug-plug-pc-computer-wall-wart.php |
23:00.14 |
``Erik |
that's the $100 wall wart version, there's a
$250 one with loads more to it |
23:00.25 |
yukonbob |
``Erik: /me -used- to be a debian person,
before I evolved to *BSD. |
23:00.58 |
``Erik |
ahhh, you saw the light, hehehe |
23:00.58 |
``Erik |
the sheeva stuff all comes with debian, I'm
hoping to get fbsd going on one |
23:01.22 |
louipc |
wow that's awesome |
23:03.48 |
yukonbob |
as far a Linux goes, debian seems sane to me.
I'm inclinded to say same about slack, but these days I only _read_
about it (infrequently). Been ~14 years since I've _run_
it. |
23:06.34 |
``Erik |
http://www.globalscaletechnologies.com/p-24-openrd-client-openrd-client-board-with-enclosure.aspx |
23:06.37 |
``Erik |
there we go |
23:06.52 |
``Erik |
hah, yowza, that's quite a while :) |
23:06.57 |
``Erik |
I went to bsd about 10 years ago |
23:09.06 |
yukonbob |
<- FreeBSD dabbling ~10
years ago, NetBSD permanently since NetBSD 1.6 |
23:09.51 |
``Erik |
never tried netbsd. fbsd is my
bread&butter, done some obsd, and I've even dug up old 43bsd
and 44bsdlite for simh |
23:10.05 |
``Erik |
(I think the 43 used the 'tahoe'
set) |
23:10.30 |
``Erik |
on a vax 780... was working on installing
BRL-CAD 4.4 on it... :D |
23:23.45 |
``Erik |
*snrkt* http://www.collegehumor.com/picture:1923263
nice |
23:56.11 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |