00:04.56 |
maths22 |
Take a look at my latest ctest run
http://brlcad.org/CDash/viewBuildError.php?onlydeltap&buildid=44 |
00:19.17 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
01:26.31 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
01:58.33 |
Notify |
03BRL-CAD:starseeker * 64617
brlcad/trunk/src/libgcv/screened_poisson.cpp: More setup for
screened poisson testing. This might actually have some potential
when it comes to level-of-detail rendering - a low-point-count fast
raytrace that is wrapped in a mesh, stepping up the number of
points for more detail... |
03:54.47 |
*** join/#brlcad pujani
(~pujani@202.164.53.117) |
04:07.35 |
*** join/#brlcad sofat
(~androirc@106.192.152.52) |
04:09.18 |
*** join/#brlcad sofat
(~androirc@106.192.152.52) |
05:19.05 |
*** join/#brlcad sofat
(~androirc@106.192.152.52) |
06:08.58 |
*** join/#brlcad hiteshsofat
(~androirc@106.192.152.52) |
06:10.15 |
*** join/#brlcad dracarys983
(dracarys98@nat/iiit/x-bbmqbnibtotcmixx) |
06:30.25 |
*** join/#brlcad teepee
(~teepee@unaffiliated/teepee) |
06:42.20 |
*** join/#brlcad luca79
(~luca@host200-107-dynamic.15-87-r.retail.telecomitalia.it) |
07:34.37 |
*** join/#brlcad merzo
(~merzo@user-94-45-58-141.skif.com.ua) |
07:38.05 |
*** join/#brlcad luca79
(~luca@host200-107-dynamic.15-87-r.retail.telecomitalia.it) |
08:02.01 |
*** join/#brlcad sofat
(~androirc@106.192.152.52) |
08:05.10 |
*** join/#brlcad teepee--
(bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
08:09.10 |
*** join/#brlcad alisha
(~quassel@115.184.117.219) |
08:15.01 |
*** join/#brlcad merzo
(~merzo@user-94-45-58-141.skif.com.ua) |
08:19.36 |
*** join/#brlcad hiteshsofat
(~androirc@106.192.156.26) |
08:26.09 |
*** join/#brlcad andrei_il
(~andrei@109.100.128.78) |
08:43.32 |
*** join/#brlcad merzo
(~merzo@user-94-45-58-141.skif.com.ua) |
08:45.20 |
*** join/#brlcad sofat
(~androirc@183.87.15.45) |
09:01.19 |
*** join/#brlcad alisha
(~quassel@115.184.117.219) |
09:02.04 |
*** join/#brlcad ejno_
(~ejno@unaffiliated/kazaik) |
09:35.31 |
*** join/#brlcad sofat
(~androirc@223.225.249.12) |
10:07.17 |
*** join/#brlcad sofat
(~androirc@223.225.249.12) |
10:19.23 |
*** join/#brlcad sofat
(~androirc@223.225.249.12) |
11:04.30 |
*** join/#brlcad alisha
(~quassel@115.184.117.219) |
11:28.06 |
*** join/#brlcad
unicodesnowman
(~unicodesn@wikipedia/unicodesnowman) |
11:32.14 |
*** join/#brlcad alisha
(~quassel@101.60.239.155) |
12:06.54 |
*** join/#brlcad sofat
(~androirc@223.225.249.12) |
12:10.25 |
*** join/#brlcad luca79
(~luca@host151-108-dynamic.15-87-r.retail.telecomitalia.it) |
12:11.26 |
*** join/#brlcad andrei_il
(~andrei@109.100.128.78) |
12:18.34 |
*** join/#brlcad
unicodesnowman (~unicodesn@167.160.164.140) |
12:39.53 |
*** join/#brlcad Stragus
(~alexis@modemcable090.29-19-135.mc.videotron.ca) |
12:48.47 |
*** join/#brlcad sofat
(~androirc@183.87.15.45) |
13:39.36 |
*** join/#brlcad FreezingCold
(~FreezingC@135.0.41.14) |
13:47.38 |
*** join/#brlcad sofat
(~androirc@183.87.15.45) |
13:52.17 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
14:26.10 |
Notify |
03BRL-CAD:carlmoore * 64618
brlcad/trunk/src/libgcv/screened_poisson.cpp: remove trailing
blanks/tabs |
14:43.05 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
15:04.03 |
Notify |
03BRL-CAD:starseeker * 64619
brlcad/trunk/src/libgcv/screened_poisson.cpp: Make a bit more
progress towards running the mesh build |
15:12.49 |
*** join/#brlcad dracarys983
(dracarys98@nat/iiit/x-bwmcpykdyaqeaqxr) |
16:12.42 |
*** join/#brlcad pujani
(~pujani@202.164.45.204) |
16:17.08 |
*** join/#brlcad pujani
(~pujani@202.164.45.204) |
16:23.21 |
*** join/#brlcad pujani
(~pujani@202.164.45.204) |
16:23.22 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
16:26.05 |
*** join/#brlcad pujani
(~pujani@202.164.45.204) |
16:29.37 |
*** join/#brlcad sofat
(~androirc@223.225.218.165) |
17:03.36 |
*** join/#brlcad pujani
(~pujani@202.164.45.212) |
17:13.50 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
17:29.58 |
*** join/#brlcad
unicodesnowman
(~unicodesn@2602:ffea:1001:1fa::97d2) |
17:30.02 |
*** join/#brlcad sofat
(~androirc@223.225.218.165) |
17:30.23 |
*** join/#brlcad alisha
(~quassel@101.60.158.242) |
17:30.55 |
*** part/#brlcad
unicodesnowman
(~unicodesn@2602:ffea:1001:1fa::97d2) |
17:46.09 |
*** join/#brlcad alisha_
(~quassel@101.60.158.242) |
17:50.11 |
*** join/#brlcad luca79
(~luca@adsl-ull-249-43.44-151.net24.it) |
18:08.44 |
*** join/#brlcad sofat
(~androirc@223.225.218.165) |
18:09.06 |
sofat |
starseeker, hello |
18:11.50 |
sofat |
I am working on mged html tutorial. I am
converting these document into xml. I want ask question regarding
this. There i found one folder animation. In this folder i see more
files that files are part of this tutorial or its different from
them ? |
18:12.40 |
sofat |
It is articles or book ? |
18:19.59 |
sofat |
brlcad, you know about this? |
18:22.52 |
*** join/#brlcad teepee_
(~teepee@unaffiliated/teepee) |
18:28.35 |
*** join/#brlcad pujani
(~pujani@202.164.45.204) |
18:33.37 |
*** join/#brlcad dracarys983
(dracarys98@nat/iiit/x-polzkqkkestrjqce) |
18:35.22 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
18:48.23 |
Notify |
03BRL-CAD:starseeker * 64620
(brlcad/trunk/src/libgcv/CMakeLists.txt
brlcad/trunk/src/libgcv/gcv_private.h and 2 others): First
successful generation of a bot primitive using screened poisson
reconstruction. Quite a bit more to do here, but this establishes a
proof-of-concept. |
18:50.06 |
*** join/#brlcad albertcoder
(caa42dcc@gateway/web/freenode/ip.202.164.45.204) |
18:56.43 |
*** join/#brlcad pujani
(~pujani@202.164.45.212) |
18:57.48 |
pujani |
hi albertcoder, |
19:07.05 |
*** join/#brlcad pujani
(~pujani@1.39.34.227) |
19:07.37 |
albertcoder |
Hi pujani I have accepted your pull request
but I think you should work on some serious improvement like
improving import / export (XML). |
19:09.52 |
pujani |
Okay What can I do? Please tell me
about |
19:13.39 |
albertcoder |
Alright. I have been working on improving
export of mysql data in JSON and CSV and my recent commit at github
should reflect the changes I did. Did you do "git pull"? |
19:14.28 |
pujani |
Yes |
19:16.30 |
albertcoder |
Alright. Now see how the code of export works
and then try to improve XML export. I guess it has something to
improve. Just try export XML and see what it does. |
19:17.47 |
pujani |
Okay I will try and report |
19:19.37 |
pujani |
One more thing, images in MenuBar are not
visible and source path is set in skins folder. Why is
that? |
19:20.27 |
dracarys983 |
brlcad, I didn't find anything that supports
surface normals in DXF export for BoTs. Should I just throw an
error then or should I output the normals as comments after each
3DFACE if the option is set? |
19:20.42 |
albertcoder |
Yeah the path is to be changed there. I set
the path in skins folder earlier because I think it is a standard
way of doing. |
19:22.27 |
pujani |
But I think I think images should be in
extension folder |
19:23.14 |
albertcoder |
yes pujani you can do that. It is not a big
issue. |
19:26.52 |
pujani |
albertcoder, Okay I will start on work of
XML |
19:27.22 |
albertcoder |
pujani: (y) |
20:10.55 |
*** join/#brlcad ``Erik
(~erik@pool-96-244-200-66.bltmmd.fios.verizon.net) |
20:10.58 |
brlcad |
dracarys983: stuffing the data into a comment
is creative, but I think it'd be ultimately
self-defeating |
20:11.26 |
brlcad |
users would have requested normals and then
been surprised when that dxf file imported into something else
didn't have normals |
20:12.12 |
brlcad |
an error is sufficient |
20:12.58 |
dracarys983 |
brlcad, Yes, that would be an issue. Okay,
error it is then :) |
20:13.04 |
brlcad |
if there were some means to store the normal
data in dxf entities, even in raw form, that would something to
consider, but don't think we need to dwell on this point too
much |
20:13.21 |
brlcad |
it's more important to have normal support for
all the formats that support normals first |
20:13.29 |
maths22 |
brlcad: did you see the errors I linked to
last night? |
20:14.30 |
dracarys983 |
brlcad, Yeah, we have surface normal support
for OBJ, STL and SAT at this point for BoTs. :D |
20:15.15 |
dracarys983 |
In OBJ we need to request for the normals. STL
and SAT output them by default. |
20:17.55 |
brlcad |
maths22: huh, those are news to me -- looks
like clang bugs |
20:18.09 |
brlcad |
https://llvm.org/bugs/show_bug.cgi?id=17788 |
20:19.07 |
brlcad |
dracarys983: that inconsistency is
bothersome |
20:19.58 |
brlcad |
from an interface perspective, it should
output them by default if the model has them calculated, and there
should be options for turning them on or off |
20:20.12 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
20:20.58 |
brlcad |
maths22: huh, apparently it's not a new issue
either:
http://webcache.googleusercontent.com/search?q=cache:vs1kzTKBXnEJ:lists.freebsd.org/pipermail/svn-src-head/2013-October/052722.html+&cd=3&hl=en&ct=clnk&gl=us |
20:21.05 |
maths22 |
is the default gcc clang on bz now |
20:21.41 |
maths22 |
I should say cc |
20:21.48 |
``Erik |
default is clang, you can always do "cc
-v" |
20:22.06 |
maths22 |
when did that change? |
20:22.14 |
``Erik |
with fbsd 10 |
20:22.30 |
``Erik |
bz went from 9 to 10 43 days ago |
20:23.29 |
``Erik |
gcc is still in the base system
(/usr/bin/gcc), um, -DCMAKE_C_COMPILER=/usr/bin/gcc
-DCMAKE_CXX_COMPILER=/usr/bin/g++ I think? |
20:23.43 |
*** join/#brlcad pujani
(~pujani@202.164.45.212) |
20:23.48 |
dracarys983 |
brlcad, I guess in STL and SAT we can't turn
it OFF. We can turn normals ON/OFF in OBJ. |
20:24.38 |
dracarys983 |
I can make normals default in OBJ as well, to
get consistency in normals being outputted by default, maybe?
:) |
20:26.10 |
brlcad |
maths22: it's definitely possible to get a
clang bulid |
20:27.10 |
brlcad |
can either disable strict, add
-Wno-c11-extensions as a build flag, or read up on the math.h
header to see if there's some way to get at isinf() without the
next _Generic() construct getting involved |
20:27.16 |
brlcad |
s/next/new/ |
20:28.28 |
brlcad |
dracarys983: not true, stl at least lets you
set normal to 0,0,0 |
20:28.39 |
brlcad |
implying that normals have not yet been
calculated |
20:29.12 |
brlcad |
for obj, it's just a matter of not outputting
vn lines iirc |
20:29.34 |
maths22 |
``Erik: thanks |
20:30.08 |
brlcad |
``Erik: you see the 8088 on HN? |
20:30.28 |
dracarys983 |
brlcad, Ah-ha! Okay, that's good news
:) |
20:32.19 |
dracarys983 |
brlcad, I'll check up on SAT then whether it's
possible to turn normals off for it. |
20:37.01 |
maths22 |
I'm now re-running with gcc |
20:37.12 |
maths22 |
I'll think about what was going on there
later |
20:43.02 |
Stragus |
FreeBSD followed OSX down the path of clang
decadence and decay? Tssk |
20:43.50 |
brlcad |
dracarys983: you'll also want to look more
closely at the obj and other file formats -- some like obj have a
variety of normal mechanisms |
20:44.45 |
brlcad |
Stragus: most of the BSDs embraced the
BSD-licensed compiler. shocking? :) |
20:45.06 |
dracarys983 |
brlcad, You mean I add all those formats that
support normals (maybe like OBJ)? :) |
20:45.21 |
brlcad |
they want a bsd stack as much as debian folks
want a gpl stack |
20:46.16 |
maths22 |
brlcad: The issues seems to be fully on
clang's end |
20:46.31 |
brlcad |
dracarys983: I mean if you're going to be
mucking with formats, you should have a specific goal in mind that
is applied consistently across all formats so that the
usability/interface is the top priority, and that any changes are
made while consulting the format specifications |
20:47.22 |
brlcad |
maths22: sure, but they are minor issues that
we are exagerrating in our build |
20:47.35 |
brlcad |
by turning warnings into errors -- that's
basically a new warning |
20:47.59 |
brlcad |
isinf() and friends are usually implemented as
macros |
20:48.54 |
maths22 |
brlcad: I wonder if -std=c99 would fix
it |
20:48.59 |
brlcad |
someone wrapped those macros with the
_Generic() construct, which is a new c11 feature that lets the
compiler bind calls to things like isinf() to different functions
based on the type of macro argument |
20:49.45 |
maths22 |
Look at the condition in math.h |
20:49.53 |
brlcad |
highly powerful, but the problem is that 1)
it's reporting a warning on a system header that it probably
shouldn't and 2) that c11 construct is being used in C compilation
mode which it probably shouldn't |
20:50.36 |
maths22 |
by default, both gcc and llvm build according
to the latest c standard |
20:50.54 |
maths22 |
see http://clang.llvm.org/compatibility.html#inline |
20:51.50 |
dracarys983 |
brlcad: Okay. :) |
20:52.42 |
brlcad |
maths22: this isn't an inline issue |
20:52.59 |
brlcad |
but is related to the fact that c11 is now
default |
20:53.41 |
maths22 |
Right |
20:53.51 |
maths22 |
Inline just had the quote |
20:54.56 |
brlcad |
it's mostly #1 -- it shouldn't be reporting
issues in system headers |
20:55.13 |
maths22 |
Correct |
20:55.14 |
brlcad |
if I request -std=c89, I shouldn't get system
header warnings about using c11 constructs |
20:55.46 |
brlcad |
the system header should deal with the
appropriate switching or the compiler should be aware it's parsing
a system header (it usually does) |
20:56.29 |
maths22 |
Have you looked at the condition in
math.h? |
20:56.50 |
brlcad |
clang is probably blaming the libc/libm guys
and the libc/libm guys are probably blaming clang (as both are
deficient), or it's simply not gotten much attention yet |
20:56.55 |
brlcad |
yes |
20:57.58 |
maths22 |
The issue seems to be that is a macro, so when
llvm gets to looking at it, it does not realize it came from a
system header |
20:58.03 |
brlcad |
if STDC is C11 and we're clang ... or
has_extension(c_generic_selections) .. so the latter is
succeeding |
20:59.30 |
brlcad |
nah, llvm knows when it's parsing constructs
and where they came from -- very good at managing all
that |
21:00.25 |
brlcad |
it's just naive simple logic coupled with a
generic warning check |
21:00.43 |
*** join/#brlcad pujani
(~pujani@202.164.45.204) |
21:01.01 |
*** join/#brlcad FreezingCold
(~FreezingC@135.0.41.14) |
21:01.52 |
brlcad |
the header literally and simply says "if I
have _Generic(), use it" .. |
21:01.58 |
brlcad |
the compiler says "if I see _Generic, warn
about it (-Wc11-extensions) because I was told to compile in c89
mode" |
21:02.18 |
brlcad |
brl-cad is saying compile in c89 mode and
treat warnings as errors |
21:02.50 |
brlcad |
trifecta resulting in the build error --
fixing any of the three makes the problem go away |
21:02.52 |
maths22 |
See
http://clang.llvm.org/docs/LanguageExtensions.html#feature-checking-macros |
21:03.05 |
maths22 |
I'm not sure why has_extension would
pass |
21:04.20 |
``Erik |
brlcad: no... musta missed it, url? (8088 on
hn) |
21:04.36 |
maths22 |
brlcad: we need to pass the -pendantic-errors
flag |
21:04.38 |
maths22 |
that fixes it |
21:05.08 |
brlcad |
``Erik:
http://trixter.oldskool.org/2015/04/07/8088-mph-we-break-all-your-emulators/ |
21:05.44 |
brlcad |
that would have blown my mind, seeing that
many colors on a cga monitor |
21:06.37 |
``Erik |
all hail dithering... lots of c64 games looked
like that and the video capabilities were ... strange :D |
21:07.40 |
``Erik |
cga was 4 color? huh, thought it was
16 |
21:08.37 |
brlcad |
he's doing more than dithering iirc |
21:10.32 |
teepee |
hey, I saw that on live stream, the sound was
a bit funny :) |
21:10.32 |
brlcad |
4 colors at 320x200, 16 colors at
160x100 |
21:10.42 |
brlcad |
hardware color-mapping |
21:12.01 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
21:12.08 |
Stragus |
Was that hardware where you could change the
palette between scanlines? |
21:13.04 |
teepee |
you can on lots of hardware, for atari 2600
that even was the way to generate the image ;) |
21:14.03 |
teepee |
checks if the video from the
opengl shader live coding competition is already
online... |
21:18.06 |
brlcad |
from the same competition, in 64k https://www.youtube.com/watch?v=mEjTnstaMLM |
21:20.07 |
teepee |
ahh, that one is awesome |
21:20.38 |
teepee |
I did like the oldskool ones too :) |
21:20.57 |
Stragus |
I must be too young to fully appreciate these
old demos |
21:21.30 |
Stragus |
I grew up with a 386 66mhz, writing true 32
bits protected code code with DJGPP |
21:21.51 |
brlcad |
Stragus: that last link was not an old
demo... |
21:21.52 |
teepee |
yeah, I guess it helps having programmed on a
system with like 16k or 64k ram |
21:22.05 |
Stragus |
I was watching the 8088 one |
21:22.13 |
brlcad |
ah |
21:22.39 |
brlcad |
8088 was in the PC category, I think 504 kb or
something |
21:23.06 |
brlcad |
in some ways the 64kb category winner is more
impressive (and definitely more visually impressive) |
21:23.11 |
teepee |
likeley "wild" where any system is allowed
with one "normal" medium |
21:23.24 |
brlcad |
all the artwork, music, and code are included
in that 64kb limit |
21:23.45 |
brlcad |
64kb binary on disk, run it :) |
21:24.13 |
Stragus |
I wrote a little game for a 64kb compo many
years ago |
21:24.18 |
Stragus |
64kb is a ton of memory :p |
21:25.03 |
brlcad |
for a game sure :) |
21:25.03 |
teepee |
not so much for full-hd video with textures. I
guess that's pretty much all precedural stuff |
21:25.51 |
brlcad |
for a 5 minute video with custom scene
animations (all displaying in real time) with custom artwork and
music, much more impressive I think |
21:26.12 |
teepee |
all video (hopefully soon) at https://www.youtube.com/user/RevisionParty/videos |
21:27.00 |
teepee |
I found most impressive what some did in the
25 minutes live coding session |
21:27.15 |
brlcad |
cool |
21:27.35 |
teepee |
like shader toy, but 2 people live on stage
with the huge splitscreen in the background |
21:28.27 |
brlcad |
I would totally love to attend one of those if
one were nearby |
21:29.08 |
teepee |
seems to be mostly european locations http://www.demoparty.net/ |
21:29.33 |
teepee |
oh, one east and one west coast US |
21:30.06 |
Stragus |
Here's something I had written for a 64kb x86
asm compo: http://www.rayforce.net/raptor000.png |
21:30.21 |
Stragus |
Game was infinite and getting harder
indefinitely, with bosses and such |
21:30.25 |
teepee |
looks like los angels and boston |
21:30.42 |
*** join/#brlcad andrei_il
(~andrei@109.100.128.78) |
21:31.28 |
brlcad |
Stragus: that looks fun :) like an old
nintendo game |
21:31.50 |
Stragus |
Yup that was the idea :) |
21:31.54 |
brlcad |
teepee: yeah, boston .. huh |
21:32.11 |
teepee |
still too far away? |
21:32.50 |
brlcad |
'bout 8 hours |
21:32.57 |
teepee |
and LA? |
21:33.09 |
brlcad |
'bout 8 hours ;) |
21:33.19 |
teepee |
haha, no demo party then |
21:33.28 |
teepee |
well, none they list on demoparty.net that
is |
21:33.32 |
brlcad |
ones a car ride, the other a flight |
21:33.54 |
Stragus |
And work won't reimburse that flight? :) Come
on, it's a conference |
21:34.04 |
teepee |
I guess I could reach all of the 40 EU parties
in that time :P |
21:34.06 |
brlcad |
would be cool to host a cademoparty |
21:34.30 |
teepee |
and live shader coding would still almost
fit |
21:34.31 |
brlcad |
model something impressive in just a couple
days |
21:34.39 |
teepee |
the software is on github |
21:34.55 |
teepee |
https://github.com/Gargaj/Bonzomatic |
21:36.24 |
brlcad |
that's awesome |
21:36.32 |
``Erik |
cga was 4 color? huh, thought it was
16 |
21:36.38 |
``Erik |
woops |
21:37.11 |
brlcad |
glitch in the matrix |
21:37.35 |
brlcad |
maths22: that's really odd that switching to
pedantic errors fixed it! |
21:37.52 |
Stragus |
blames
clang |
21:38.44 |
maths22 |
http://clang.llvm.org/docs/LanguageExtensions.html#feature-checking-macros |
21:38.57 |
maths22 |
See the comment about
pendantic-error |
21:43.03 |
*** join/#brlcad andrei__
(050cdda5@gateway/web/freenode/ip.5.12.221.165) |
21:45.57 |
brlcad |
maths22: yeah, that explains it .. interesting
way to handle it |
21:47.32 |
maths22 |
Its not necessarily a bad flag
anyway |
21:47.54 |
brlcad |
the fact that it fixes this specific case is
still kind of an unintended consequence |
21:47.55 |
maths22 |
what is this code from:
src/libgcv/poissonrecon/? |
21:48.00 |
maths22 |
That is true |
21:48.08 |
maths22 |
about the unintended consequence |
21:48.10 |
brlcad |
it's the fact that there's a mismatch with the
header and its logic |
21:48.34 |
maths22 |
the header should be using __has_feature
can |
21:48.42 |
maths22 |
I mean __has_feature |
21:48.53 |
maths22 |
not __has_extension |
21:50.05 |
brlcad |
yeah, there needs to be a README in that
directory and authorship info |
21:50.25 |
brlcad |
it's from http://www.cs.jhu.edu/~misha/Code/PoissonRecon/Version6.13/ |
21:51.07 |
maths22 |
Is it permissible to edit that code in any
way? |
21:51.07 |
brlcad |
bsd licensed code |
21:51.20 |
maths22 |
http://www.cs.jhu.edu/~misha/Code/PoissonRecon/license.txt |
21:51.24 |
maths22 |
Yep |
21:52.00 |
brlcad |
can you drop that in the directory? |
21:52.22 |
brlcad |
surprised starseeker would put that in there
without proper docs, but he is working on that stuff now |
21:52.59 |
Notify |
03BRL-CAD:maths22 * 64621
brlcad/trunk/src/libgcv/poissonrecon/SparseMatrix.inl: added
license file for possionrecon |
21:53.00 |
maths22 |
Each file includes the license at the
top |
21:54.37 |
Notify |
03BRL-CAD:maths22 * 64622
(brlcad/trunk/src/libgcv/poissonrecon/BSplineData.h
brlcad/trunk/src/libgcv/poissonrecon/Factor.h and 2 others): added
newlines to end of possionrecon source |
22:00.46 |
brlcad |
huh, except the random one that I picked to
check, Hash.h |
22:01.08 |
brlcad |
I meant just adding a license.txt file there
so it's explicit |
22:01.28 |
maths22 |
I did |
22:01.42 |
brlcad |
cool, thanks |
22:02.30 |
brlcad |
how about a README citing the
source? |
22:02.38 |
*** join/#brlcad teepee
(~teepee@unaffiliated/teepee) |
22:03.17 |
maths22 |
Can do soon |
22:03.30 |
starseeker |
brlcad: sorry 'bout that - license info is in
the src files, forgot to add a separate file |
22:03.53 |
brlcad |
starseeker: not in the one I randomly picked
:) |
22:04.03 |
starseeker |
figures |
22:06.18 |
starseeker |
if this approach proves useful, maybe need to
do some siginficant rework on the code - right now it needs OpenMP
for parallelism, so we're compiling it in serial mode |
22:07.35 |
starseeker |
not sure how turning on OpenMP would play with
our own threading |
22:09.29 |
brlcad |
ugh |
22:11.59 |
brlcad |
for a self-contained gcv plugin,
maybe |
22:12.31 |
brlcad |
for a library (including libgcv or librt), I
wouldn't be in favor |
22:23.33 |
Notify |
03BRL-CAD:maths22 * 64623
brlcad/trunk/src/libgcv/screened_poisson.cpp: removed unnecessary
semicolons (pedantic error) |
22:31.37 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
22:31.51 |
maths22 |
brlcad: Is it OK to commit the following?
http://paste.ubuntu.com/10777205/ |
23:13.28 |
brlcad |
maths22:
misc/CMake/BRLCAD_CompilerFlags.cmake |
23:13.39 |
brlcad |
probably belongs there as that's where
strictness is enabled |
23:13.44 |
brlcad |
see pedantic |
23:13.47 |
maths22 |
Ok. |
23:13.52 |
brlcad |
probably good to just use both :) |
23:14.18 |
maths22 |
I'll move it. |
23:14.49 |
brlcad |
if you can, make sure it compiles with gcc
too |
23:15.03 |
brlcad |
that's going to be almost certain to fail
something somewhere |
23:20.03 |
brlcad |
darn I don't have part 21 handy |
23:22.08 |
maths22 |
Of what? |
23:22.21 |
maths22 |
Running with GCC now |
23:45.46 |
brlcad |
part 21 of the step standard, stepcode bug
reported but don't know what the spec says |
23:48.33 |
maths22 |
http://brlcad.org/CDash/viewBuildError.php?buildid=46 |