01:00.10 |
*** join/#brlcad mohitdhingras
(~root@14.139.128.12) |
01:32.05 |
starseeker |
crdueck: feel free to experiment |
02:10.22 |
*** part/#brlcad louipc
(~louipc@archlinux/fellow/louipc) |
02:24.02 |
starseeker |
crdueck: we have to carefully manage search
paths when specifying 32 vs 64 bit building, since CMake's default
search routines don't check to make sure a library found is built
for the correct word size |
02:49.33 |
starseeker |
on most of the systems I have tested to date,
64 bit libs went into lib64 - if we have lib32 32 bit, lib64 64
bit, and lib uncertain there is a mess to resolve |
03:01.47 |
crdueck |
starseeker: i asked in my distro's channel and
the ambiguity is because 32-bit support was implemented as an
afterthought, and so the default is 64-bit. the file path problem
would very likely only affect archlinux users |
03:46.01 |
*** join/#brlcad abhi2011
(~chatzilla@209.201.113.2) |
03:54.51 |
*** join/#brlcad dtidrow
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
04:57.08 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
05:05.16 |
*** join/#brlcad jordisayol1
(~jordisayo@188.119.210.222.dynamic.eurona.net) |
05:05.17 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
05:07.45 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
05:10.01 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
05:19.36 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
05:30.43 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
05:48.09 |
*** join/#brlcad abhi2011
(~chatzilla@209.201.113.2) |
06:09.29 |
*** join/#brlcad d_rossberg
(~rossberg@BZ.BZFLAG.BZ) |
06:31.52 |
*** join/#brlcad pawleeq
(~pawleeq@core1.humlnet.cz) |
08:05.08 |
*** join/#brlcad stas
(~stas@82.208.133.12) |
09:04.06 |
*** join/#brlcad kane_
(~Mesut@dslb-084-063-241-201.pools.arcor-ip.net) |
10:38.03 |
*** join/#brlcad jordisayol
(~jordisayo@188.119.210.222.dynamic.eurona.net) |
10:38.06 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
10:57.36 |
*** part/#brlcad mohitdhingras
(~root@14.139.128.12) |
10:59.42 |
*** join/#brlcad Jak_o_Shadows
(~Fake@unaffiliated/jak-o-shadows/x-0479135) |
11:51.05 |
*** join/#brlcad kane__
(~Mesut@dslb-088-078-198-057.pools.arcor-ip.net) |
11:56.09 |
*** join/#brlcad kane_
(~Mesut@dslb-088-078-198-057.pools.arcor-ip.net) |
13:08.19 |
``Erik |
starseeker: 3 off by many on solids |
13:08.36 |
starseeker |
otherwise it builds? |
13:09.02 |
``Erik |
um, with everything bundled, it still flipped
out about finding the macports png.h, so I turned strict off and it
built |
13:09.05 |
starseeker |
(make -k I think should proceed with running
the rest of 'em...) |
13:09.17 |
starseeker |
oh, right - you also need to add...
letsee... |
13:09.53 |
starseeker |
-DCMAKE_SEARCH_OSX_PATHS=SYSTEM |
13:16.54 |
``Erik |
still seems to pull the macports
png.h |
13:17.17 |
starseeker |
growl. |
13:17.42 |
starseeker |
ok, nevermind - may need some of the
improvements in trunk to avoid that issue |
13:58.13 |
``Erik |
only regress issues are the old 3 off by many
solids and 'gui' in mged |
14:00.15 |
starseeker |
O.o |
14:00.19 |
starseeker |
what's up with gui? |
14:08.19 |
CIA-128 |
BRL-CAD: 03starseeker * r50367
10/brlcad/branches/STABLE/CMakeLists.txt: Correct typo. |
14:09.16 |
``Erik |
looks like a lib mismatch, X from macports vs
GL from system |
14:09.48 |
starseeker |
oh, right |
14:10.01 |
starseeker |
ok, that's specific to the macports |
14:10.07 |
starseeker |
tries on his non-macports
mac |
14:10.15 |
``Erik |
does that commit allow total exclusion of
macports shtuff? |
14:10.34 |
starseeker |
which, 50367? |
14:10.41 |
starseeker |
that's just a Windows thing |
14:10.58 |
starseeker |
ignoring all macports stuff requires include
dir order sorting |
14:35.44 |
CIA-128 |
BRL-CAD: 03starseeker * r50368
10/brlcad/branches/STABLE/src/other/CMakeLists.txt: Don't use
numbers for bools |
15:06.36 |
CIA-128 |
BRL-CAD: 03starseeker * r50369
10/brlcad/branches/STABLE/src/other/step/src/express/
(CMakeLists.txt expprint.c): Remove this file - removed in trunk,
not needed, causing build issue on mac for release build. |
15:10.48 |
CIA-128 |
BRL-CAD: 03starseeker * r50370
10/brlcad/branches/STABLE/src/other/libz/CMakeLists.txt: Add
workaround for MSVC2010 64 bit and zlib from trunk r49887 |
15:12.08 |
``Erik |
building system X instead of macports fixes
that mged gui issue |
17:12.15 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
17:22.01 |
kanzure |
decided to take a break on nurbs :p |
17:22.03 |
kanzure |
http://heybryan.org/shots/2012-04-30-1131-nanoengineer-chroot.png |
17:33.23 |
*** join/#brlcad milamber1
(~devlin@d118-75-244-176.try.wideopenwest.com) |
17:48.11 |
*** join/#brlcad milamber
(~devlin@d118-75-244-176.try.wideopenwest.com) |
17:50.13 |
*** join/#brlcad milamber1
(~devlin@d118-75-244-176.try.wideopenwest.com) |
18:00.19 |
CIA-128 |
BRL-CAD: 03starseeker * r50371
10/brlcad/trunk/misc/CMake/FindX11.cmake: Tweak search paths for
X11 |
18:00.58 |
starseeker |
crdueck: Does r50371 help on
archlinux? |
18:07.58 |
brlcad |
kanzure: nifty -- you ever attend the
molecular modeling BoF? |
18:08.06 |
kanzure |
BoF? |
18:08.21 |
brlcad |
birds of a feather, at a conference |
18:08.26 |
brlcad |
siggraph for example |
18:08.28 |
kanzure |
hrm. never heard of it |
18:08.32 |
kanzure |
nope have't been to siggraph |
18:08.42 |
kanzure |
http://github.com/kanzure/nanoengineer#readme |
18:12.05 |
brlcad |
love the animations |
18:12.28 |
kanzure |
downside: this code base suffers from bit
rot |
18:12.44 |
kanzure |
the last known working distro to run it was
ubuntu 7.04 |
18:12.58 |
kanzure |
soo i created a chroot .tar.gz
http://groups.google.com/group/nanoengineer-dev/browse_thread/thread/48a3fa9291f81f41 |
18:13.13 |
kanzure |
now i guess i need to start upgrading to
successive ubuntu versions, run the tests and fix bugs |
18:17.59 |
brlcad |
it's not easy to write code that specific that
cannot be trivially updated.. ;) |
18:18.33 |
kanzure |
huh? |
18:18.54 |
kanzure |
i think you mean "it's not easy to write code
that specicfic that *can* be trivially upgraded" |
18:18.57 |
kanzure |
*speciic |
18:19.00 |
kanzure |
*specific jeeze |
18:19.46 |
kanzure |
or "it's easy to write specific code that
cannot be trivially updated" |
18:30.53 |
crdueck |
starseeker: r50371 finds the correct libraries
and builds fine now |
18:39.35 |
starseeker |
crdueck: awesome |
18:40.43 |
kanzure |
starseeker: hihi |
18:47.03 |
starseeker |
kanzure: howdy |
18:47.17 |
starseeker |
kanzure: gave up on NURBS for a while
eh? |
18:50.45 |
CIA-128 |
BRL-CAD: 03starseeker * r50372
10/brlcad/trunk/misc/CMake/FindX11.cmake: Note that archlinux
prompted the tweak to X11 search paths. |
18:51.29 |
kanzure |
starseeker: heh well not really. just doing
other things |
18:54.49 |
starseeker |
nanoengineer looked cool, but would have taken
quite a lot of work to polish up iirc |
18:57.30 |
starseeker |
would be awesome to see someone bring it back
to life |
18:57.48 |
starseeker |
it was/is GPL? |
19:01.55 |
brlcad |
kanzure: actually, I meant the opposite ..
:) |
19:02.32 |
kanzure |
starseeker: gpl 2 and gpl 3 (wtf?) |
19:02.33 |
brlcad |
I can usually get code to compile on linux I
wrote 10 years ago in just a few minutes (on ANY distro) |
19:02.45 |
kanzure |
brlcad: i would greatly appreciate your help,
then |
19:02.46 |
brlcad |
the harder ports are to a different
OS |
19:02.55 |
kanzure |
again, i made a chroot to get it running from
the original packages |
19:02.59 |
kanzure |
but i would love for it to work on modern
systems |
19:03.10 |
kanzure |
then i can package up a .deb or
something |
19:03.36 |
brlcad |
what's the history of that code, you write
most of it? |
19:03.56 |
kanzure |
nope |
19:04.06 |
kanzure |
mark sims founded nanorex inc.
2004-2009 |
19:04.12 |
kanzure |
dumped about a million/year on 10
developers |
19:04.27 |
kanzure |
v1.0.0 released march 2008, v1.0.1 the
following month |
19:04.36 |
kanzure |
v1.1.1 is the current release |
19:05.40 |
kanzure |
in 2010 mark gave me the source
codde |
19:05.47 |
kanzure |
well, he gave me the repository i
mean |
19:05.58 |
kanzure |
and i converted from cvs->svn->git and
preserved the history |
19:07.07 |
brlcad |
hm, gplv2+, shame.. :/ |
19:07.08 |
CIA-128 |
BRL-CAD: 03starseeker * r50373
10/brlcad/branches/STABLE/ChangeLog: Tack on the other changes to
ChangeLog |
19:07.28 |
kanzure |
brlcad: technically, nanorex can relicense
this code base |
19:07.34 |
kanzure |
and mark is still around.. Mark Sims
<mark@nanorex.com> |
19:09.00 |
starseeker |
kanzure: that'd probably be essential before
we could do much of anything with it... |
19:09.27 |
kanzure |
mark is really nice and obviously an awesome
person for even making this open source |
19:09.55 |
kanzure |
so if you want to put some effort into getting
it licensed more appropriately, i'd be willing to help
out |
19:10.47 |
starseeker |
brlcad: what do you think? any chance
molecular engineering capabilities would be of interest to
BRL-CAD? |
19:11.20 |
kanzure |
heh |
19:12.04 |
kanzure |
modularizing nanoengineer and breaking it up
into stuff that brlcad could cannibalize would be a great outcome,
in my opinion |
19:12.05 |
brlcad |
there's a reason I've attended nearly every
molecular engineering bof at siggraph .. it's on the very fringe of
our domain but a philosphical fit |
19:12.53 |
kanzure |
(there are already modules, but i mean
"releasable" modules or "separable" modules) |
19:13.30 |
brlcad |
I'd love to get to the point where I can model
something at a macroscopic scale, but then keep zooming in to
see/modify underlying molecular structure |
19:13.56 |
kanzure |
the data structures for that would be a bit
wonky |
19:14.01 |
brlcad |
csg lends itself very well for compactness of
representation that would be needed |
19:14.11 |
kanzure |
there's no reason you need to have precise
atomic definition of your curve.. but at the same time, it's not an
infinite curve either |
19:14.46 |
brlcad |
I'm more interested from a materials science
perspective |
19:15.17 |
brlcad |
create a metal plate for example and simulate
it getting cracked |
19:15.34 |
brlcad |
now change the molecular structure to a
different configuration, what's the effect? |
19:16.31 |
brlcad |
could compare different alloys, represent
non-homogenous regions (like bone), accurate anatomical
modeling |
19:17.34 |
kanzure |
ah i see, sure |
19:17.46 |
kanzure |
most of nanoengineer uses pdb files |
19:17.53 |
kanzure |
so you can import basically any molecule from
pubchem or ncbi |
19:18.11 |
brlcad |
nods |
19:18.15 |
starseeker |
kanzure: is nanorex (the company) still
active? That may be a factor in whether they'd consider non-GPL
licensing - a fair number of companies use GPL because it preserves
(practically speaking) the possibility of also selling commercial
licensing for a fee |
19:18.15 |
kanzure |
one of the features on the wishlist is the
ability to model large systems like those in the concept
video: |
19:18.23 |
kanzure |
http://www.youtube.com/watch?v=vEYN18d7gHg |
19:18.36 |
brlcad |
I started on a pdb-g a few years ago, but
didn't finish it in my afternoon playing around |
19:18.37 |
kanzure |
starseeker: the company is not active, but
mark has been paying the hosting bills so the sites are still
up |
19:20.36 |
starseeker |
well... the most straightforward way would be
for someone to email and ask... |
19:21.12 |
kanzure |
sure |
19:22.19 |
starseeker |
brlcad: you want to, or should I? |
19:22.22 |
kanzure |
i wonder how large-scale molecular machines
would be modeled.. storing atom positions for everything is
unwise |
19:22.41 |
kanzure |
starseeker: if you or brlcad choose to send
that email, can you email me a draft first? Bryan Bishop
<kanzure@gmail.com> |
19:23.07 |
starseeker |
kanzure: I assume you prefer one of us to ask
instead of doing so yourself? |
19:24.01 |
kanzure |
uhh, i am still sorting through my feelings
haha |
19:24.10 |
starseeker |
heh |
19:24.14 |
kanzure |
i really wanted to get nanoengineer working on
modern distros before i pinged mark again |
19:24.47 |
starseeker |
ah - have some concrete benefits in
hand? |
19:25.01 |
brlcad |
a tit for tat is in order, have something to
show what the value is |
19:25.10 |
kanzure |
yeah.. so far the majority of the work i have
done is converting old cvs/svn repos to git |
19:25.25 |
brlcad |
maybe starseeker you could give the compile a
go on gentoo |
19:25.32 |
starseeker |
nods |
19:25.43 |
starseeker |
that'd be the best place for sure, for
something like this |
19:26.05 |
starseeker |
I tried once some time ago, but don't recall
now what the issues were |
19:26.05 |
brlcad |
if it compiles/compiled on ubuntu, should just
be build system issues, dependencies, minor code
assumptions |
19:26.31 |
starseeker |
kanzure: what GUI library does it
use? |
19:26.37 |
kanzure |
pyqt 4.3.3 |
19:26.41 |
brlcad |
I can probably give it a go in a week or
two |
19:26.52 |
kanzure |
here is how i built the ubuntu
chroot |
19:26.52 |
kanzure |
http://diyhpl.us/~bryan/irc/nanoengineer/nanoengineer-chroot-debootstrap |
19:27.01 |
kanzure |
or you can download it in the parent
directory |
19:27.04 |
starseeker |
I'll take a quick wack at it tonight and see
how it looks |
19:27.08 |
kanzure |
coolio |
19:27.33 |
starseeker |
kanzure: fair warning - if I get serious about
it the build system's converting to CMake :-) |
19:27.45 |
kanzure |
aww but the build system actually
/works/ |
19:27.53 |
kanzure |
this is the one part of it that is functioning
:P |
19:28.01 |
starseeker |
on MSVC too? |
19:28.11 |
kanzure |
uh good question, i don't have that
environment setup for testing at all |
19:29.43 |
starseeker |
a working build system is actually the best
starting point |
19:30.20 |
kanzure |
there are also some unit tests |
19:31.52 |
starseeker |
hasn't tangled with pyqt for
a while... |
19:32.18 |
starseeker |
remember glancing at what they were doing to
make that linkage work and going a bit pale |
19:33.01 |
starseeker |
ah, crud |
19:33.16 |
starseeker |
now I remember - PyQt is GPL |
19:33.31 |
starseeker |
nuts |
19:34.20 |
starseeker |
speaking of software that likes to preserve
licensing opportunities... |
19:34.40 |
starseeker |
kanzure: how heavily is the nanoengineer code
invested in PyQt? |
19:35.28 |
kanzure |
i don't know what to tell you |
19:36.03 |
kanzure |
there's lots of code that relies on it in
cad/src/ |
19:36.22 |
starseeker |
nods - it's a tough question
to answer without digging |
19:36.31 |
starseeker |
didn't know how far into the code you had
gotten |
19:36.49 |
kanzure |
i have poked around a bit but i'm not ready to
delete or rewrite large portions :) |
19:37.15 |
starseeker |
nods - it's stuck at GPL then
unless/until it looks viable to not rely on PyQt |
19:38.51 |
starseeker |
looks like PySide is the LGPL alternative, but
I have no idea how comparable the two are |
19:39.38 |
starseeker |
cross platform looks a bit iffy... |
19:39.50 |
kanzure |
holy crap what the hell is
cad/src/platform_dependent/gpl_only.py |
19:39.58 |
kanzure |
the message is menacing |
19:40.42 |
kanzure |
ah it might have been qt3 leftovers |
19:40.59 |
kanzure |
"Here are those functions we can't allow Qt3
Windows users to run:" |
19:41.55 |
starseeker |
yeah, back in the day (IIRC) Windows Qt was
even more restricted than other platforms |
19:42.03 |
kanzure |
libpython23.a.gz and libpython24.a.gz in the
repo.. not cool |
19:42.53 |
starseeker |
yeah, PyQt is probably the biggest GPL
anchor |
19:43.00 |
starseeker |
heh - ouch |
19:43.55 |
starseeker |
PyQt is like SISL - they have a good sound
reason not to ever go LGPL |
19:44.25 |
CIA-128 |
BRL-CAD: 03starseeker * r50374
10/brlcad/tags/rel-7-20-6/: Tag 7.20.6 |
19:46.09 |
starseeker |
kanzure: hmm - http://qt-project.org/wiki/Differences_Between_PySide_and_PyQt |
19:47.06 |
kanzure |
that doesn't look too horrible |
19:47.26 |
kanzure |
"Supporting Both APIs" now that's
neat.. |
19:47.44 |
kanzure |
https://github.com/epage/PythonUtils/blob/master/util/qt_compat.py |
19:47.51 |
kanzure |
"qt_compat.py [github.com] is an example of
centralizing the knowledge of PySide and PyQt without using
monkey-patching. It serves both to point out what differences exist
as well as keeping your code binding-agnostic." |
19:47.58 |
kanzure |
"This is important for when needing to support
both bindings, usually when transitioning from one to the other and
needing to continue to support older distributions that do not yet
come with PySide." |
19:48.15 |
kanzure |
starseeker: the other issue is that i would
really like to make sure i get contributor license
agreements |
19:48.28 |
starseeker |
hmm? |
19:48.41 |
starseeker |
in what sense? |
19:48.42 |
kanzure |
there is lots and lots of value with making
sure someone actually owns the copyright of this, even if it's an
organization somewhere |
19:48.53 |
kanzure |
well for instane, all apache contributors sign
documents before their code is accepted |
19:49.12 |
starseeker |
yeah, and it's one of the major hurdles to
contributing to Apache projects |
19:49.40 |
starseeker |
I don't think even Qt itself requires
that... |
19:49.52 |
kanzure |
really? how does trolltech keep the licensing
straight |
19:50.59 |
starseeker |
hmm... I guess they do, actually - they just
don't require copyright assignment |
19:51.04 |
starseeker |
http://qt-project.org/legal.html |
19:51.06 |
kanzure |
fascinating. |
19:51.26 |
kanzure |
*instance |
19:53.44 |
starseeker |
kanzure: to be honest, I doubt I'd bother with
a setup that requires a contributor agreement under normal
circumstances, particularly when copyright assignment is required -
there are too many interesting things to work on that don't require
the hoop jumping |
19:54.23 |
kanzure |
yeah, i could be convinced to agree with that
pretty easily |
19:54.49 |
starseeker |
kanzure: brlcad would have more insight on the
fine points of our own setup |
19:58.12 |
starseeker |
oh, here it is - "Authors and other BRL-CAD
contributors must comply with the copyright |
19:58.15 |
starseeker |
terms for their respective contributions
unless otherwise noted or |
19:58.18 |
starseeker |
arranged. This includes an implicit
assignment of copyright for any |
19:58.20 |
starseeker |
and all contributions being made." |
19:59.03 |
kanzure |
hey if that's good enough for the legal
experts in the military.. then it's good enough for me |
19:59.25 |
starseeker |
kanzure: again, better to ask brlcad about all
that - he was there :-) It was before my time |
19:59.45 |
starseeker |
was just looking at our own COPYING
file |
20:03.01 |
brlcad |
for most matters of rights management, it's
more an issue of what your goals are -- whether you're more
interested in growing your community or protecting your
asset(s) |
20:04.14 |
brlcad |
no protection is foolproof, there's always
legal risk so it's really about levels of risk assessment and
cost |
20:05.50 |
brlcad |
of course explicit copyright assignment is
better for a litigeous perspective than implicit assignment, that's
intuitive but then there's a cost associated |
20:06.37 |
brlcad |
explicit assignment via forms will invariably
reduce contributions from the global pool of candidate
contributors |
20:07.18 |
brlcad |
if reaching the most contributors were your
only goal, no assignment would fit just fine |
20:08.24 |
brlcad |
if protecting your already-widely-popular
asset (e.g., apache) was the most important, go for the
forms |
20:09.46 |
kanzure |
right, i suppose so |
20:09.54 |
kanzure |
i don't have a strong opinion either way on
nanoengineer |
20:09.54 |
brlcad |
we're in the middle willing to take on a
little risk, protecting our assets but encoruaging
contributors |
20:10.18 |
brlcad |
yeah, someone might argue that they never
explicitly agreed to our terms even though we usually have an audit
trail, but then our response can always be to yank their
contributions entirely |
20:10.23 |
brlcad |
no code is sacred ;) |
20:10.37 |
starseeker |
kanzure: you mentioned "lots and lots of
value" earlier - what did you have in mind there? |
20:11.06 |
brlcad |
then the only risk is *their* contributions
causing financial harm, which is incredibly hard to demonstrate
with open source not being sold for a profit |
20:11.25 |
kanzure |
starseeker: a managing organization can do
more if it knows its permissions |
20:12.13 |
brlcad |
that's a problem of documentation |
20:12.21 |
brlcad |
it should be stated very clearly (and
explicitly) |
20:12.42 |
brlcad |
and reiterated in dialog so you have
audit |
20:21.41 |
starseeker |
kanzure: "do more" - do *what* more? Did you
have something specific in mind? |
20:22.43 |
kanzure |
nope :) |
20:23.13 |
kanzure |
i guess people worry about companies like
nanorex owning their contributions, and then making money on their
"open source" work |
20:23.28 |
kanzure |
i mean, asymmetrically |
20:23.32 |
brlcad |
it's all about being sued or wanting to
sue |
20:23.48 |
kanzure |
if it was bsd, then anyone would be able to
setup a similar operation |
20:23.51 |
kanzure |
etc. etc. |
20:24.10 |
brlcad |
and would you *really* care |
20:24.18 |
brlcad |
and would that harm you |
20:25.12 |
kanzure |
stop asking hard questions! |
20:25.15 |
kanzure |
haha |
20:25.51 |
starseeker |
kanzure: Oddly enough, you can find a few
instances where the Modified BSD/MIT style licenses actually end up
getting more commercial support, because companies aren't scared of
using the code |
20:26.15 |
starseeker |
clang/llvm being one of the more recent large
scale instances - webkit is another |
20:26.45 |
brlcad |
what could someone do to your
contribution/code/creation/whatever that might cause you to sue
them for damages -- if you would very unlikely take the efforts to
sue, then you only have to be concerned with others suing
you |
20:28.56 |
kanzure |
starseeker: yep, i'm aware and see why that
happens |
20:43.45 |
*** join/#brlcad DarkCalf
(DC@173.231.40.98) |
20:48.19 |
starseeker |
kanzure: generally speaking, grabbing BSD code
and closing it up is helpful to an organization only when they
can't share improvements to the original code without exposing
trade secrets or "giving the competition a leg up", so to speak.
There *are* instances where those concerns are legitimate, but any
company parting ways with the original codebase is taking the full
burden of supporting that code |
20:49.26 |
starseeker |
internal forks of that nature have a nasty
tendency to diverge from the original code base, and subsequent
integrations get progressively more difficult if there is no code
sharing going on |
20:49.49 |
starseeker |
all of which is non-revenue-generating work
for the company |
20:51.06 |
kanzure |
opencascade recently released their own
"community version" git repo.. it's pretty funny |
20:51.10 |
kanzure |
it has no revision history really |
20:51.17 |
kanzure |
i guess they were scared about
oce.git |
20:51.52 |
starseeker |
yeah, I remember seeing that. They also want
forms signed from contributors, and the oce crowd didn't react well
to the idea |
20:52.12 |
starseeker |
they also balked (again) at the notion of
using a standard license |
20:54.25 |
starseeker |
shrugs - we'll just keep
going our own way. Personally I'd be much more inclined to pick
apart Ayam and Varkon than opencascade |
20:54.43 |
kanzure |
yeah, i tried picking apart opencascade and
it's not worth it, <standard rant goes here> |
20:55.39 |
starseeker |
brlcad figured that out a long time ago - I
took a bit longer (ooo, shiny pictures) but figured it out
eventually |
20:56.55 |
starseeker |
The FreeCAD guys are welcome to it -
personally I hope they succeed - compeition/alternatives are always
a good thing |
21:21.30 |
kanzure |
something is fundamentally very wrong with
opencascade if *none* of their programmers have the chops to
prevent code massacre on their scale |
21:31.33 |
*** join/#brlcad stas
(~stas@188.24.35.114) |
22:29.19 |
*** join/#brlcad andrei_
(~andrei@188.25.159.184) |
22:31.15 |
*** join/#brlcad crdueck_
(~cdk@d173-238-127-19.home4.cgocable.net) |
22:32.51 |
*** join/#brlcad crdueck__
(~cdk@d173-238-127-19.home4.cgocable.net) |
22:35.25 |
*** join/#brlcad crdueck
(~cdk@d173-238-127-19.home4.cgocable.net) |
22:36.16 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
23:32.40 |
*** join/#brlcad crdueck_
(~cdk@d173-238-127-19.home4.cgocable.net) |
23:32.59 |
*** join/#brlcad crdueck
(~cdk@d173-238-127-19.home4.cgocable.net) |
23:37.37 |
*** join/#brlcad DarkCalf
(~DC@173.231.40.98) |
23:45.24 |
starseeker |
wow nanoengineer is a big repo - looks like
you really did preserve the history :-) |
23:47.40 |
kanzure |
yes :) |
23:47.44 |
kanzure |
that was very important to me |
23:48.09 |
kanzure |
however.. there's also some random large
binary files in there that i forgot to remove before everyone
cloned |
23:48.19 |
starseeker |
winces |
23:48.41 |
starseeker |
yeah... might be worth redoing it without
those, if that's practical |
23:48.59 |
kanzure |
everyone would have to update their git
repos |
23:53.00 |
starseeker |
kanzure: might be worth it? |
23:53.18 |
starseeker |
otherwise we're stuck with this huge download
forevermore |
23:58.12 |
kanzure |
hrmmmm |
23:58.13 |
*** join/#brlcad juanman
(~quassel@unaffiliated/juanman) |
23:58.35 |
kanzure |
starseeker: well let's look at how much space
would be cleared up exactly |
23:59.21 |
kanzure |
find . | grep gz |
23:59.26 |
kanzure |
these are all 40 kilobyte files |
23:59.41 |
kanzure |
cad/src/ is 42 MB |