00:00.32 |
Notify |
03BRL-CAD:brlcad * 68682
(brlcad/trunk/src/libdm/dm-X.c brlcad/trunk/src/libdm/dm-generic.c
and 9 others): reduce the number of Tcl symbols in libdm. don't
need to be using TCL_OK/ERROR when we have equivalent
API. |
00:44.20 |
*** join/#brlcad
dzbybkubocwmtqdy
(~armin@dslb-088-066-144-194.088.066.pools.vodafone-ip.de) |
01:00.12 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
04:54.22 |
*** join/#brlcad tandoorichick
(b64b2d01@gateway/web/freenode/ip.182.75.45.1) |
06:47.24 |
*** join/#brlcad teepee_
(~teepee@unaffiliated/teepee) |
08:09.41 |
*** join/#brlcad sniok
(~sniok@89.252.2.135) |
08:18.15 |
*** join/#brlcad Caterpillar2
(~caterpill@unaffiliated/caterpillar) |
08:53.04 |
*** join/#brlcad tandoorichick
(3d0c28b1@gateway/web/freenode/ip.61.12.40.177) |
09:35.01 |
*** join/#brlcad merzo
(~merzo@92.60.189.225) |
09:35.01 |
*** join/#brlcad teepee]
(bc5c2134@gateway/web/freenode/ip.188.92.33.52) |
10:58.26 |
*** join/#brlcad asad_
(~asad00@host10-2.natpool.mwn.de) |
12:13.23 |
*** join/#brlcad sniok
(~sniok@89.252.2.135) |
12:58.34 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
14:04.27 |
*** join/#brlcad amarjeet
(~amarjeet@101.211.212.152) |
14:35.26 |
Notify |
03BRL-CAD:starseeker * 68683
brlcad/trunk/regress/repository.cmake: set up so we can run all
tests with a single variable define. |
14:48.02 |
Notify |
03BRL-CAD:starseeker * 68684
brlcad/trunk/regress/repository.cmake: printing tweaks |
14:49.13 |
Caterpillar2 |
[16:06] <starseeker> fyi - there was
apparently some interest in an openNURBS package back in 2011:
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/thread/JP2RTIBREMZ5SIFMJ35AHXXQDJHQPQLX/ |
14:50.02 |
Caterpillar2 |
hi, I have just contacted Jiri about
openNURBS. He told me he gave up due opennurbs shipping zlib
library. I think it is quite easy to unbundle it, I had a similar
experience while packaging darktable software |
14:51.45 |
Caterpillar2 |
(zlib is already shipped in Fedora and its
version is 1.2.8) |
14:56.39 |
Notify |
03BRL-CAD:starseeker * 68685
brlcad/trunk/regress/repository.cmake: More logic tweaks. |
14:56.49 |
Caterpillar2 |
if you have free time, / if you want, we
could work together on packaging all libraries and finally
brl-cad |
14:57.29 |
Caterpillar2 |
if not, I can do it, but it will require an
undefinite amount of time |
15:01.30 |
Notify |
03BRL-CAD:brlcad * 68686
brlcad/trunk/regress/repository.sh: all hial hiaku |
15:03.23 |
brlcad |
Caterpillar2: happy to support you in any way
we can |
15:04.06 |
brlcad |
Caterpillar2: regarding opennurbs, is it not
enough to simply ensure that opennurbs' bundled zlib is not
compiled -- that it's using the system/package-installed
zlib? |
15:04.43 |
brlcad |
that said, our bundling of openNURBS has zlib
stripped out (because we already bundle it) ;) |
15:05.29 |
brlcad |
you could probably just turn our
src/other/openNURBS directory into a package |
15:05.46 |
brlcad |
that would solve two problems |
15:06.22 |
Caterpillar2 |
[17:05] <brlcad> you could probably just
turn our src/other/openNURBS directory into a package |
15:06.35 |
Caterpillar2 |
no the Fedora policy says that you must take
the upstream package |
15:06.56 |
Caterpillar2 |
[17:04] <brlcad> Caterpillar2: regarding
opennurbs, is it not enough to simply ensure that opennurbs'
bundled zlib is not compiled -- that it's using the
system/package-installed zlib? |
15:07.00 |
Caterpillar2 |
yeah it should work |
15:09.28 |
brlcad |
I'm suggesting that there is no upstream, that
you are defining upstream |
15:10.14 |
Caterpillar2 |
brlcad: mmh can you rewrite your statement?
Sorry, English is not my first language ;-) |
15:10.16 |
brlcad |
dumping a tarball on a website without any
support hardly makes for your traditional "upstream"
supplier |
15:11.52 |
brlcad |
Caterpillar2: you're talking about pulling a
tarball from a URL, applying a set of patches (to remove zlib,
apply other fixes) |
15:13.00 |
brlcad |
all I was suggesting is changing the URL
(e.g., to a fork we can put on github) so you don't have to
patch |
15:13.21 |
brlcad |
it doesn't matter, just offering options
:) |
15:13.45 |
Caterpillar2 |
brlcad: is https://www.rhino3d.com/en/opennurbs
the upstream developer of openNURBS? |
15:14.44 |
brlcad |
depends how you define upstream, but sure --
that's certainly where we forked from |
15:15.41 |
brlcad |
Caterpillar2: hablas español? what's your
native language? |
15:15.49 |
Caterpillar2 |
brlcad: Italian |
15:17.07 |
brlcad |
ah, molto bene ... tranne il mio italiano é
terrible :) |
15:17.36 |
Caterpillar2 |
brlcad: ehhe |
15:18.18 |
Caterpillar2 |
https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplication_of_system_libraries |
15:18.23 |
brlcad |
ho studiato per un paio di anni |
15:18.39 |
brlcad |
ma ho dimenticato .. tutti |
15:18.40 |
Caterpillar2 |
di dove sei? |
15:19.27 |
brlcad |
depende lo che cuenta |
15:19.43 |
Caterpillar2 |
? |
15:19.43 |
brlcad |
vivo in us |
15:19.46 |
Caterpillar2 |
ah ok |
15:20.36 |
brlcad |
fully fluent in spanish, but also rusty
writing it |
15:21.44 |
Caterpillar2 |
nice |
15:21.57 |
brlcad |
anyways... so yeah, rhino3d are the main
opennurbs developers but we have a fork that is improved, in ways
they will not integrate |
15:22.52 |
brlcad |
we have fixes that they don't care about
(we've pushed them upstream), we have other changes they
specifically exclude for business reasons |
15:23.06 |
brlcad |
they sell a product containing the same
modifications we make |
15:24.07 |
Caterpillar2 |
brlcad: ok, so I have to ask to Fedora
Packaging Committee if they give me an exception to the rules.
There is a specific ticket system for such problems |
15:24.09 |
brlcad |
so we could treat our version as a completely
separate fork (e.g., Xorg vs X11 or ECGS vs GCC or thunderbird vs
firefox, etc) |
15:24.31 |
Caterpillar2 |
brlcad: interesting |
15:24.53 |
brlcad |
either way, we need the patches we made --
geometry fails to render correctly without at least one of
them |
15:25.14 |
brlcad |
rendering is something they don't
support |
15:26.16 |
brlcad |
if needed, we can set up a proper repository
just for our fork, or we can revisit discussions with the rhino
folks (we don't really want to maintain a fork) |
15:27.15 |
Caterpillar2 |
brlcad: if you revisit discussions with the
rhino folks it would be perfect |
15:28.37 |
brlcad |
we can try, but it will probably take a while
to sort out succinct patches again for discussion |
15:28.58 |
brlcad |
starseeker: care to try upgrading opennurbs
next? :) |
15:29.09 |
Caterpillar2 |
brlcad: yeah I can imagine |
15:32.35 |
Notify |
03BRL-CAD:starseeker * 68687
brlcad/trunk/regress/repository.cmake: start working on new regex
match |
15:38.17 |
Caterpillar2 |
brlcad: I have to go out home in a few
minutes, for any question you can send me an e-mail or just wait
for me to get back later :-)) |
15:45.33 |
*** join/#brlcad asad_
(~asad00@host10-2.natpool.mwn.de) |
15:56.04 |
brlcad |
starseeker: I note that [# ] != [[:space:]#]
... you want something like [ \t\r\n\f#] if it doesn't support the
posix classes |
15:59.04 |
Notify |
03BRL-CAD:starseeker * 68688
brlcad/trunk/regress/repository.cmake: Make the cmake outputs a bit
closer to the repository.sh output. CMake matching is slower than
repository.h, but we're also catching some cases like
src/mged/qray.h:38: #ifndef _WIN32 that I'm not seeing in the
repository.sh output. Maybe it's time to see if the unifdef program
can be used to do the symbol extraction piece, rather than
cobbling |
15:59.06 |
Notify |
together regex patterns... |
15:59.08 |
Notify |
... |
16:05.35 |
*** join/#brlcad amarjeet
(~amarjeet@101.211.209.70) |
16:14.47 |
brlcad |
starseeker: matching that qray.h line is
technically an incorrect match for that regular
expression |
16:17.55 |
brlcad |
obviously a desirable match in this particular
instance, but not what the regular expression says -- it says match
platform symbol followed by a non A-Z character (and there are no
more chars on that line) |
16:18.53 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
16:24.56 |
starseeker |
brlcad: no argument |
16:25.35 |
starseeker |
brlcad: I can take a run at openNURBS,
sure |
16:25.59 |
starseeker |
be a little bit - want to get this repository
symbol stuff sorted if we can... |
16:27.09 |
starseeker |
brlcad: I'm trying an experiment with unifdef,
which is showing a bit of promise |
17:00.20 |
*** join/#brlcad ickby
(~stefan@x5d84498e.dyn.telefonica.de) |
17:27.25 |
*** join/#brlcad sniok
(~sniok@89.252.2.135) |
17:36.53 |
*** join/#brlcad ickby
(~stefan@x5d84498e.dyn.telefonica.de) |
19:16.55 |
Notify |
03BRL-CAD:starseeker * 68689
brlcad/trunk/regress/repository.cmake: Tweak regex, fix quick test
for line |
19:23.13 |
*** join/#brlcad sniok
(~sniok@89.252.2.135) |
19:36.35 |
Notify |
03BRL-CAD:brlcad * 68690
(brlcad/trunk/regress/repository.cmake
brlcad/trunk/regress/repository.sh): tweak the regex to match
symbols ending on the end of line. remove MACH as it's really a
hardware platform. |
19:36.42 |
brlcad |
starseeker: why in the world are there two
platform lists already?? :) |
19:39.33 |
*** join/#brlcad Caterpillar2
(~caterpill@unaffiliated/caterpillar) |
19:39.38 |
Caterpillar2 |
back again |
19:40.08 |
brlcad |
seems like premature complication... |
19:40.12 |
brlcad |
hi Caterpillar2 |
19:44.53 |
brlcad |
starseeker: is doing the two non-regex MATCHES
followed by the regex MATCHES actually faster? that's a bit
surprising |
19:46.13 |
brlcad |
also, how can I manually test it? get error
with this: |
19:46.14 |
brlcad |
agua:brlcad.trunk morrison$ cmake -P
regress/repository.cmake |
19:46.14 |
brlcad |
CMake Error at regress/repository.cmake:97
(list): |
19:46.15 |
brlcad |
<PROTECTED> |
19:56.25 |
Notify |
03BRL-CAD Wiki:Tandoorichick * 9815
/wiki/User:Tandoorichick/GSoC2016/Logs: /* Development Logs
*/ |
20:07.17 |
Caterpillar2 |
brlcad: so, I will wait for your news before
doing anything with openNURBS |
20:09.03 |
brlcad |
well assume all goes perfectly or poorly, I'm
not sure it changes much from a packaging perspective unless we
host a fully managed fork ourselves |
20:09.24 |
brlcad |
and the only incentive for doing that right
now would be for packaging |
20:09.53 |
Caterpillar2 |
ok |
20:11.39 |
brlcad |
so you're either waiting to hear if we need to
fork (less work for you, more work for us) or package them as-is
(more work for you, less work for us), yes? |
20:13.59 |
Caterpillar2 |
Rather than forking, we were talking about you
revisiting discussions with Rhino guys |
20:14.05 |
Caterpillar2 |
I am not in a hurry, so we can take all the
time we need. |
20:18.56 |
brlcad |
yes we revisit discussions with rhino guys,
that wasn't in question :) |
20:19.31 |
brlcad |
you said you would wait ... I'm trying to
understand why you'd need to wait as the outcomes of good or bad
discussions may be the same (for you) |
20:19.43 |
brlcad |
it's only different if we fork |
20:27.46 |
Caterpillar2 |
brlcad: the difference for me is:
if your openNURB patches will be accepted upstream, I can
simply take the new & patched upstream openNURBS code and
package it into Fedora. If those patches are not
accepted by upstream, I will have to package BRL-CAD modified
version of openNURBS, I will be trapped for some weeks into Fedora
burocracy emails, explaining and asking permissions to Fedora
Packaging |
20:27.48 |
Caterpillar2 |
Committee, etc. |
20:30.32 |
Caterpillar2 |
but the final result should be almost the
same |
20:44.36 |
Caterpillar2 |
now I have to go to bed, see you
tomorrow! |
20:46.47 |
Stragus |
ponders regex with JIT
compilation of SSE 4.2 string operations |
21:06.44 |
*** join/#brlcad infobot
(ibot@rikers.org) |
21:06.44 |
*** topic/#brlcad is BRL-CAD
release 7.26.0 is out! More than 150 user-visible changes including
6 major efforts! || GSoC 2016 is coming to a close, showcase
forthcoming || Help needed reviewing and integrating 700+ GCI tasks
|| Logs: http://ibot.rikers.org/%23brlcad/ |
21:15.52 |
Notify |
03BRL-CAD:starseeker * 68691
(brlcad/trunk/misc/tools/CMakeLists.txt
brlcad/trunk/regress/repository.cmake): Use a customized version of
unifdef to identify and report symbols in the source code. Appears
to be both fast and robust. |
21:19.48 |
Notify |
03BRL-CAD:starseeker * 68692
brlcad/trunk/misc/tools/unifdef/platform_symbols.h: remove MACH
from os platform symbols list |
21:21.29 |
starseeker |
brlcad: to manually test, it's cmake
-DSOURCE_DIR=/path/to/brlcad
-DUNIFDEF_EXEC=/path/to/customized/unifdef -DRUN_ALL_TESTS=1 -P
repository.cmake |
21:22.34 |
starseeker |
(sorry, wasn't watching channel) |
23:13.43 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
23:15.49 |
brlcad |
starseeker: I still get the subfilter
error |
23:16.12 |
brlcad |
is that perhaps using some >3.3 cmake
feature? |
23:52.31 |
Notify |
03BRL-CAD Wiki:Sean * 9816
/wiki/Example_db_walk_tree: merge in the void* update from
asad |
23:52.45 |
Notify |
03BRL-CAD Wiki:Sean * 0 /wiki/Db_walk_tree:
not needed, merged with main |