01:24.26 |
*** join/#brlcad Twingy
(n=justin@74.92.144.217) |
01:42.44 |
starseeker |
growls in frustration at
STABLE - might just nuke and reload again |
01:42.49 |
brlcad |
:) |
01:45.01 |
starseeker |
"why are you SKIPPING files I just told you to
MERGE?? whadaya mean PROPFIND failed???" |
01:55.18 |
yukonbob |
hello, cadheads |
02:05.37 |
starseeker |
whoa - did sourceforge just change their
site? |
02:07.58 |
brlcad |
howdy yukonbob |
02:08.01 |
brlcad |
starseeker: howso? |
02:08.06 |
brlcad |
it changed a couple days ago |
02:08.14 |
starseeker |
orange theme, different look |
02:08.27 |
starseeker |
huh, guess I didn't notice |
02:08.28 |
starseeker |
ick |
02:08.51 |
brlcad |
i never go to the main page |
02:09.01 |
brlcad |
but yeah, that was announced a couple days
ago |
02:09.06 |
brlcad |
1-2 days |
02:09.12 |
starseeker |
ah |
02:10.30 |
brlcad |
heh, looks like it's set up for iphone
use |
02:10.41 |
brlcad |
kinda silly on a big browser window |
02:10.47 |
starseeker |
no kidding |
02:11.15 |
starseeker |
deems this change for the
sake of change |
02:15.53 |
CIA-23 |
BRL-CAD: 03starseeker * r32312
10/brlcad/tags/rel-7-12-6/: Tag 7.12.6 release |
02:16.00 |
starseeker |
Well at least that worked |
02:16.08 |
starseeker |
glares at
STABLE |
02:17.09 |
starseeker |
fudge, missed the bo command update in the
Changelog |
03:24.37 |
CIA-23 |
BRL-CAD: 03starseeker * r32313
10/brlcad/branches/STABLE/: Updating STABLE isn't going well - wipe
it out in prep to move in new copy |
03:25.43 |
CIA-23 |
BRL-CAD: 03starseeker * r32314
10/brlcad/branches/STABLE/: Copy 7.12.6 release to become new
STABLE branch |
03:26.06 |
starseeker |
the svn nuclear option |
04:04.21 |
*** join/#brlcad pacman87
(n=timothy@71.170.63.120) |
04:06.35 |
pacman87 |
su |
04:06.53 |
Ralith |
su: Permission denied |
04:07.17 |
pacman87 |
no, you're supposed to do a /nick Password,
and then say ' ' |
04:08.53 |
pacman87 |
anyway, i lost power a while back, and when i
rebooted, my gfx card fan was really noisy, so i pulled it out to
try to fix it. when i put it back in, it didn't work. i finally
got it working again, but it's still quite loud |
04:09.19 |
pacman87 |
and now my intel gfx died on me so i have to
reboot again... |
04:21.17 |
*** join/#brlcad homovulgaris
(n=d@117.196.138.171) |
04:23.39 |
homovulgaris |
brlcad: i see that boost 1.35 is being added
as a part of geometry service into rt3. Should we be keeping two
copies. I mean the src/other/boost is not the complete package
ofcourse. But if it is better either of us can remove the
'unnecessary?' double storage ? |
04:27.48 |
brlcad |
homovulgaris: howdy, haven't sync'd up with
you in a while! |
04:29.03 |
homovulgaris |
:) |
04:29.12 |
brlcad |
sure, makes sense regarding eliminating the
double storage -- how would you propose going about that? |
04:29.13 |
homovulgaris |
lots of action in the group lately..
:) |
04:29.26 |
brlcad |
oh yeah |
04:29.27 |
*** join/#brlcad pacman87
(n=timothy@71.170.63.120) |
04:29.30 |
brlcad |
my mailbox floweth over |
04:29.40 |
brlcad |
tis good stuff |
04:29.42 |
homovulgaris |
I mean if Geometry Service needs boost they
can use the one in src/other |
04:29.58 |
brlcad |
yeah, I think that at least is the
plan |
04:30.32 |
brlcad |
just maybe a little premature since it's just
now finally getting off of one guy's own repository/machine and
finally getting syncd |
04:30.33 |
homovulgaris |
I won't be able to use the rt3/.. one right
. |
04:30.39 |
brlcad |
right |
04:30.41 |
homovulgaris |
ok. |
04:30.47 |
brlcad |
that direction doesn't make sense |
04:30.56 |
brlcad |
rt^3 can use brlcad though |
04:31.06 |
brlcad |
just a matter of how to sort that out exactly
wrt the build system |
04:31.20 |
homovulgaris |
I am going ahead with passing data structures
for implicit constraints rather than expressions as per ur
comments |
04:31.42 |
brlcad |
Ralith started cleaning some of that up,
moving towards being able to specify where the BRLCAD_ROOT is
at |
04:31.58 |
brlcad |
which then in theory should either have boost
or have a means to point to where boost is at |
04:32.27 |
brlcad |
i saw your updated comments, did what I wrote
make sense? |
04:32.29 |
homovulgaris |
yeah i had some trouble when i compiled rt3 2
days back.. regarding BRLCAD_ROOT |
04:33.48 |
homovulgaris |
it made a lot of sense. I wasnt planning on
using expressions for implicit constraints. But for explicit ones I
guess expression parsing is inevitable. I started a bit of work on
a Math VM for evaluating expressions. |
04:34.30 |
homovulgaris |
http://www.lyx.org/~leeming/yac/
I mostly want to do something like this |
04:34.42 |
brlcad |
when you say "using expressions" do you mean
"using string expressions"? |
04:34.51 |
*** join/#brlcad pacman88
(n=timothy@71.170.63.120) |
04:34.52 |
homovulgaris |
It supports almost the entire gnuplot
syntax |
04:35.15 |
brlcad |
what's the license? |
04:35.18 |
homovulgaris |
boost |
04:35.24 |
brlcad |
k |
04:35.33 |
homovulgaris |
but it is an application i want to convert it
into a library |
04:35.35 |
brlcad |
is it part of boost? |
04:37.11 |
brlcad |
looks like no (which is fine, just
curious) |
04:37.17 |
brlcad |
interesting project at a glance |
04:37.35 |
brlcad |
so that one is more interesting than the other
project you mentioned ? |
04:37.36 |
homovulgaris |
lots of interesting concepts in the
code.. |
04:38.22 |
homovulgaris |
yac is just one application of the spirit
parsing capabilities . It even supports expressions of the form
factorial(x) = (x < 0.1) ? 1 : x * factorial(x - 1) |
04:38.46 |
homovulgaris |
and all the usual trigonometric and other
mathematical functions |
04:38.53 |
brlcad |
support closures? |
04:39.11 |
homovulgaris |
closures as in ? |
04:40.27 |
homovulgaris |
spirit suppors closures of course
http://spirit.sourceforge.net/distrib/spirit_1_8_3/libs/spirit/doc/closures.html |
04:40.38 |
brlcad |
yeah, I saw that in spirit a while
back |
04:41.04 |
brlcad |
background info, http://en.wikipedia.org/wiki/Closure_(computer_science) |
04:41.37 |
brlcad |
basically from a lame pragmatic non-rigorous
standpoint, the ability to define functions as objects in
themselves, functions within functions |
04:41.59 |
brlcad |
that refer to their containing
function |
04:42.34 |
brlcad |
pseudo dynamic programming, rather powerful
construct |
04:43.59 |
homovulgaris |
hmm.. |
04:45.18 |
brlcad |
so how does yac relate to phoenix? |
04:45.32 |
brlcad |
is it in leu of phoenix? in conjunction with
it? |
04:45.59 |
brlcad |
did phoenix burn up and if so, when will it be
reborn? :) |
04:45.59 |
homovulgaris |
yac uses phoenix and spirit |
04:46.14 |
brlcad |
oh, really? didn't see that |
04:49.02 |
homovulgaris |
Geometry Service sounds like a cool idea.
didn't have much time to think about it though |
04:49.51 |
brlcad |
the information is only just getting started,
it's a pretty big effort with lots of payoff |
04:50.03 |
brlcad |
several design docs still to be
uploaded |
04:50.22 |
brlcad |
hmm, the skip grammar in yac is kinda
sucky |
04:50.55 |
homovulgaris |
we won't hve to support it since we don't
expect any piped input |
04:51.43 |
homovulgaris |
or even interactive mode so to speak. Since we
would only be dealing with std::strings or char * skip grammar can
be much simplified |
04:51.51 |
brlcad |
oh, actually I just missed it -- the comment
is misleading |
04:52.00 |
brlcad |
it also supports ; terminations |
04:52.33 |
brlcad |
i'm thinking of a constraint that is really
multiple constraints |
04:52.50 |
brlcad |
like in the example you put on the
wiki |
04:53.14 |
brlcad |
some of them are multiple grouped evaluations
(e.g. 0 > x > 1) |
04:53.58 |
homovulgaris |
effectively they will be implemented as
constraint ( x>0 && x<1) |
04:54.05 |
brlcad |
nods |
04:54.14 |
homovulgaris |
so constraints depend on constraints and
hypergraphs come in |
04:55.05 |
homovulgaris |
which is why I will have to modify the
existing constraint class to have a std::list<Constraint *>
as well to support similar logic operations once we support such
constaints |
04:56.13 |
brlcad |
ranged(a) = a > 0 && a < 1;
ranged(x) && mod(x * 10, 2)==0; |
04:56.18 |
brlcad |
or somesuch |
04:56.48 |
homovulgaris |
boost/adjacency_list.hpp is just 600 lines..
:) but I am pretty sure I have a lot to cover up before thinking
about hypergraphs.. my 100 hour expectation not going very
smoothly. |
04:57.40 |
homovulgaris |
Sean, regarding passing the
constraint/evaluators as data strcutres what do u suggest ? actual
function pointers ? or some sort of lookup table |
04:59.34 |
brlcad |
you mean like a global lookup table? |
04:59.43 |
brlcad |
or some context-specific lookup
table? |
04:59.44 |
homovulgaris |
yeah |
05:00.13 |
homovulgaris |
global lookup table of possible constraint
types. But I think passing pointers is better |
05:00.31 |
brlcad |
well the main benefit of having some global
table would be the ability to refer to multiple evaluators by
name/type/id/whatever |
05:00.49 |
brlcad |
if you only need one callback, then a function
pointer seems to make more sense, it's simpler |
05:01.47 |
homovulgaris |
I guess each constraint will have only one
evaluation method . So i guess fp would suffice. |
05:02.03 |
homovulgaris |
what exactly was the RTTI comment in Geometry
Service |
05:02.34 |
brlcad |
i'll be responding to those comments later,
probably friday |
05:02.50 |
homovulgaris |
k |
05:03.11 |
brlcad |
but basically as a pervasive adopted use
encouraged throughout the project contrasted with the maintenance
aspects it entails |
05:03.41 |
brlcad |
not so much the benefits/downsides from a
technical perspective -- there's good and bad things about it that
you could argue about indefinitely |
05:04.05 |
homovulgaris |
Sean, the arb implicit constraint you were
refering to , checking the faces, where would the code be located,
I did a brief lookaround.. couldnt locate it i think |
05:05.36 |
brlcad |
refresh my memory, that's only vaguely ringing
a bell |
05:06.33 |
homovulgaris |
quote : conditionally requiring that each face
on an arb be planar, connected, and enclose a volume |
05:08.20 |
brlcad |
homovulgaris: to the rtti point, the other
main issue is how using rtti pertains to container management --
since cases where rtti is used as a way to put N objects into one
container can often be more effectively achieved using separate
containers for each type or by using a data-driven approach where
some id (data) in the object indicates the type |
05:08.55 |
brlcad |
those are three pretty substantial differences
in approach that are non-trivial to unwire/change down the road
with various tradeoffs |
05:09.32 |
brlcad |
aside from several compilers only allowing you
to link against other "rtti-compatible/using" libs if you use
them |
05:10.29 |
homovulgaris |
hmm.. I am facing something similar .. the
container issue that is when thinking about the variable<T>
objects.. |
05:11.26 |
homovulgaris |
template specilaizations don't work with most
compilers i guess .. So i have to change the id setting according
to type somewhere |
05:12.11 |
brlcad |
from a technical perspective, this is a fairly
succint classic read that hints at some of the technical reasons
for/against it |
05:12.17 |
brlcad |
http://www.artima.com/intv/const2.html |
05:13.31 |
brlcad |
otherwise, though -- like I said, my point
wasn't so much the technical as the pragmatic and
maintainability/integratability aspects since it can be made to
work with or without |
05:13.58 |
brlcad |
and yes.. template specializations can be a
royal pita :) |
05:14.28 |
brlcad |
whic as always .. "it depends" on the
situation |
05:14.41 |
homovulgaris |
:| step by step i am detemplating almost
everything i templated :P |
05:15.44 |
brlcad |
hehe |
05:16.58 |
homovulgaris |
I'll go eat some junk food |
05:17.31 |
homovulgaris |
wants Math Virtual Machine to
be awesome |
05:18.12 |
brlcad |
too |
05:18.21 |
brlcad |
looks like you're heading that way, bit by bit
:) |
05:18.38 |
brlcad |
i like yac, looks like a good choice |
05:20.11 |
brlcad |
as good as it's likely going to get without
going through an existing language parser like tcl or
lisp |
05:22.16 |
homovulgaris |
yeah, I think it would be nice to have an
inhouse math expression parser/evaluator. |
05:22.22 |
homovulgaris |
always comes in handy |
05:23.45 |
homovulgaris |
considering "generality" of application should
i put mathvm and associated files somewhere outside libpc folder
? |
05:37.42 |
*** join/#brlcad poolio
(n=poolio@bz.bzflag.bz) |
05:37.42 |
*** join/#brlcad starseeker
(n=starseek@bz.bzflag.bz) |
05:37.42 |
*** join/#brlcad brlcad
(n=sean@bz.bzflag.bz) |
05:54.43 |
brlcad |
~botmail send homovulgaris mathvm does
probably belong outside of libpc -- libbn is the usual place for
our numerics facilities but if the implementation is C++ then of
course it'd probably be either a backend lib (with a C interface in
libbn) or something similar |
07:03.35 |
*** join/#brlcad clock_
(n=clock@84-72-91-240.dclient.hispeed.ch) |
07:15.52 |
*** join/#brlcad brlcad
(n=sean@bz.bzflag.bz) |
07:39.55 |
*** join/#brlcad archivist_ub
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
07:39.59 |
*** join/#brlcad archivist_emc
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
07:40.01 |
*** join/#brlcad archivist
(n=archivis@host81-149-119-172.in-addr.btopenworld.com) |
08:22.44 |
archivist_ub |
brlcad, re ran the autogen.sh and configure
script, that got it! |
08:25.46 |
mac`u |
re |
08:25.47 |
mac`u |
:) |
08:29.14 |
*** join/#brlcad Elperion
(n=Bary@p5B14CB5B.dip.t-dialin.net) |
09:38.20 |
archivist_ub |
i want mooore VGR performance metric of
1298 |
09:39.24 |
archivist_ub |
dual core opteron 2.2ghz and 2 gig ram but a
few things going on in the background |
09:56.46 |
CIA-23 |
BRL-CAD: 03homovulgaris * r32315
10/brlcad/trunk/src/ (4 files in 3 dirs): adding spirit::symbols
for MathVM |
10:34.48 |
*** join/#brlcad thing0
(n=ric@58.171.225.236) |
10:59.24 |
CIA-23 |
BRL-CAD: 03davidloman * r32316
10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/status/ (4
files): |
10:59.49 |
*** join/#brlcad elite01
(n=elite01@unaffiliated/elite01) |
11:01.25 |
CIA-23 |
BRL-CAD: 03davidloman * r32317
10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/regression/:
Library addition for GeometryService. |
11:03.52 |
CIA-23 |
BRL-CAD: 03davidloman * r32318
10/rt^3/trunk/src/geometryService/cpp/ (.cproject
.project): |
11:04.34 |
CIA-23 |
BRL-CAD: 03davidloman * r32319
10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/people/ (.
people.htm): Library addition for GeometryService. |
11:05.02 |
*** join/#brlcad mafm
(n=mafm@elnet-111.lip.pt) |
11:10.47 |
CIA-23 |
BRL-CAD: 03davidloman * r32320
10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/more/ (47 files
in 5 dirs): Library addition for GeometryService. |
11:21.14 |
mafm |
hihi |
12:12.03 |
CIA-23 |
BRL-CAD: 03homovulgaris * r32321
10/brlcad/trunk/src/libpc/ (Makefile.am pcMathVM.cpp pcMathVM.h
vm_test.cpp): adding some flesh to MathVM skeletons, copy
constructor for the stack; addition of vm_test for MathVM
tests |
12:19.07 |
*** join/#brlcad mac`u_
(i=mac@linux.slackware.in) |
12:55.35 |
CIA-23 |
BRL-CAD: 03mafm * r32322
10/rt^3/trunk/src/g3d/ (GuiWindowManager.cxx GuiWindowManager.h):
Fixing some of the problems of the taskbar, and some other
uninmportant changes |
12:58.46 |
CIA-23 |
BRL-CAD: 03davidloman * r32323
10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/libs/: |
13:01.20 |
CIA-23 |
BRL-CAD: 03homovulgaris * r32324
10/brlcad/trunk/src/libpc/ (pcMathVM.cpp pcMathVM.h): MathFunction
object definition |
13:02.37 |
CIA-23 |
BRL-CAD: 03davidloman * r32325
10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/libs/: Library
addition for GeometryService |
13:04.12 |
CIA-23 |
BRL-CAD: 03davidloman * r32326
10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/libs/: Library
addition for GeometryService. |
13:06.55 |
*** join/#brlcad Axman6
(n=Axman6@pdpc/supporter/student/Axman6) |
13:18.51 |
CIA-23 |
BRL-CAD: 03davidloman * r32327
10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/libs/ (397 files
in 57 dirs): Library addition for GeometryService. |
13:31.18 |
*** join/#brlcad prasad1
(n=psilva@static-70-108-244-218.res.east.verizon.net) |
13:31.27 |
mafm |
silent, busy programmers :) |
13:37.35 |
*** join/#brlcad
andrecastelo__ (n=chatzill@189.71.30.223) |
13:43.29 |
*** join/#brlcad thing1
(n=ric@58.171.255.243) |
13:45.15 |
brlcad |
mafm: heh, yep :) |
13:50.45 |
CIA-23 |
BRL-CAD: 03davidloman * r32328
10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/libs/ (714 files
in 45 dirs): Library addition for GeometryService. |
13:56.42 |
*** join/#brlcad geocalc
(n=geocalc@91-171-200-33.rev.libertysurf.net) |
14:10.22 |
*** join/#brlcad pacman_87
(n=timothy@71.170.63.120) |
14:12.01 |
pacman_87 |
exit |
14:12.37 |
CIA-23 |
BRL-CAD: 03mafm * r32329
10/rt^3/trunk/src/g3d/ (GuiBaseWindow.cxx GuiBaseWindow.h): Adding
method to retrieve base windows (necessary to attach buttons in
taskbars to these ones) |
14:27.07 |
*** join/#brlcad d_rossberg
(n=rossberg@bz.bzflag.bz) |
14:29.18 |
*** join/#brlcad pacman87
(n=timothy@71.170.63.120) |
14:54.41 |
CIA-23 |
BRL-CAD: 03homovulgaris * r32330
10/brlcad/trunk/src/libpc/ (pcMathVM.cpp pcMathVM.h vm_test.cpp):
MathF1 or unary mathematical function class added, display()
function added to MathVM for debugging purposes, testing addition
of Unary Math functions to the MathVM symbol table |
15:21.41 |
d_rossberg |
pacman87: how is you progress with the
revolve? what do you think you can reach this summer? |
15:48.48 |
CIA-23 |
BRL-CAD: 03davidloman * r32331
10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/libs/date_time/
(196 files in 17 dirs): Library addition for
GeometryService |
15:50.43 |
CIA-23 |
BRL-CAD: 03mafm * r32332
10/rt^3/trunk/src/g3d/ (GuiWindowManager.cxx GuiWindowManager.h):
Perfecting the taskbar, now it works much more closely to the Ideal
Operation Environment (IOE, see my wiki page for the video) that we
take as ideal interaction model |
15:53.40 |
CIA-23 |
BRL-CAD: 03davidloman * r32333
10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/libs/ (23 files
in 4 dirs): Library addition for GeometryService |
16:22.21 |
CIA-23 |
BRL-CAD: 03davidloman * r32334
10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/libs/ (789 files
in 99 dirs): Library addition for GeometryService |
17:01.37 |
*** join/#brlcad PrezKennedy
(i=Matthew@whitecalf.net) |
18:08.19 |
CIA-23 |
BRL-CAD: 03mafm * r32335
10/rt^3/trunk/src/g3d/GuiWidgetRotation.cxx: Enhancing the custom
widget |
18:10.23 |
CIA-23 |
BRL-CAD: 03brlcad * r32336
10/brlcad/trunk/doc/BRL-CAD.bib: denote utf-8 encoding for
emacs |
18:12.10 |
CIA-23 |
BRL-CAD: 03brlcad * r32337
10/brlcad/trunk/doc/BRL-CAD.bib: add ARL-TR-2396 to the
todo |
19:01.21 |
CIA-23 |
BRL-CAD: 03mafm * r32338
10/rt^3/trunk/src/g3d/ (GuiWidgetRotation.cxx GuiWidgetRotation.h):
Enhancing custom widget with a label and the numerical progress
(useful at least when testing) |
19:14.59 |
mafm |
have to go, laterz folkz |
19:15.01 |
mafm |
:) |
19:30.59 |
CIA-23 |
BRL-CAD: 03davidloman * r32339
10/rt^3/trunk/src/geometryService/cpp/boost_1_35_0/libs/gil/ (770
files in 5 dirs): Library addition for GeometryService |
19:41.44 |
CIA-23 |
BRL-CAD: 03brlcad * r32340
10/brlcad/trunk/BUGS: FB_FILE and -F option for specifying a remote
framebuffer was fixed. twas and off-by-one strlcpy in
src/libfb |
20:31.44 |
*** join/#brlcad jonored
(n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net) |
21:18.34 |
*** join/#brlcad Ralith
(n=ralith@c-71-197-213-172.hsd1.or.comcast.net) |
22:42.33 |
brlcad |
mmm.. the final stretch |
22:42.47 |
brlcad |
go go gadget gsoc |
22:45.56 |
pacman87 |
being in #brlcad and #bzflag means brlcad
comes through in stereo :) |
22:47.27 |
jonored |
seems to be having issues to
do with tcl... possibly mostly building with the one packaged with
brlcad and for the bit that's glitching trying to link against the
system's library. |
22:49.39 |
Ralith |
pacman87: #bzflag has something to do with
brlcad? |
22:49.42 |
Ralith |
oh wait |
22:49.45 |
Ralith |
brlcad himself |
22:49.46 |
Ralith |
lol |
22:50.01 |
Ralith |
wait, he's not there :| |
22:50.05 |
Ralith |
<-
confused. |
22:50.58 |
Ralith |
or he is. whois failed me. |
22:51.02 |
pacman87 |
brlcad (the person) said the same two
statements in #brlcad (the channel) and #bzflag (the
channel) |
22:51.26 |
Ralith |
you know, I'm just glad there's nobody named
'bzflag' too. |
22:54.48 |
andrecastelo |
hey guys |
22:54.58 |
pacman87 |
howdy andrecastelo |
23:24.24 |
*** join/#brlcad Twingy
(n=justin@74.92.144.217) |
23:53.27 |
brlcad |
pacman87: hehe |
23:54.08 |
brlcad |
Ralith: there is, he just rarely uses that
nick |
23:54.13 |
brlcad |
(bzflag) |
23:54.35 |
Ralith |
D: |