Re: [ggt-devel] GMTL, State of the library

[Kevin M. <ke...@su...>]

Fine by me if you fork into a modern source control like github, keep the
same license, etc...

You might want to first check with the maintainers of vrjuggler, in case
maybe they feel like they own/maintain the gmtl stuff now.   They may want
to control the fork onto github, control who has access, etc...   To get
vrjuggler to switch to the newer gmtl will be a separate discussion.  Maybe
check their mailing list.

I have been out of gmtl dev for a while, so not sure I want to be the one
to greenlight this.   But generally forks of LGPL stuff is pretty easy...
In theory, I like the idea of github, it can even start as a proposal for
these new changes - pull requests make that super easy to collab on new
proposals - https://help.github.com/articles/creating-a-pull-request/.  I'm
on github as https://github.com/subatomicglue .

- Kevin

---
kevin meinert | http://www.subatomiclabs.com

On Mon, Aug 8, 2016 at 1:48 PM, Sebastian Messerschmidt <
seb...@gm...> wrote:

>
>
> Am 08.08.2016 um 19:57 schrieb Kevin Meinert:
>
> Hi I am an original author of gmtl.  Forks of course you're always free to
> do.  For including it in juggler, to reduce users of gmtl, you'd want to
> get one of the current maintainers of juggler to weigh in on that (not sure
> at the moment who that is)
>
> I'd like to see it moved to github or any other "modern" version control.
> A
>
>
> What types of breaking changes to gmtl do you want?  Got a list?
>
> Basically the changes are "minimal" but breaking existing code.
> A small mind dump:
> - unify parameters for intersection to match the input type
> (e.g. Rayd intersection using float for t0,t1 intersection point)
> - template-version of epsilons (currently all epsilons are float)
> - gmtl::make for precision casts (e.g .
> - namespace collision with boost::static_assert (not gmtl's problem)
> - meta-programming optimizations
>
> The main point however is to have a bit more flexibility in terms of
> driving development. But this requires at least someone to maintain the
> trunk and managing releases/pull requests. I could spare some extra cycles
> to do at least the trunk maintenance as long as I can synchronize with the
> main users (juggler).
>
>
>
> Personally I use the bullet physics math library (Sony vector math lib)
> these days...  Nice SSE support
>
> That's a thing (the SSE) better left to the compiler in my experience. Due
> to the clean meta-programming friendly structure GMTL is really efficient
> when compiled with AVX. Most assignments are collapsed to mov ops and even
> matrix initializations (filling with zeros and filling the diagonal with 1
> is collapsed to a single constant load. I was really surprised how fast it
> is. I've compared this with some handwritten code, and usually the
> gmtl-based code won the compiler/optimizer race. Anyways, thanks for the
> advice, but I like gmtl because it supports bounding volumes and generic
> NxM math.
>
> Cheers
> Sebastian
>
>
>
>
> Kevin
>
> On Monday, August 8, 2016, Sebastian Messerschmidt <
> seb...@gm...> wrote:
>
>> Hi Todd,
>>
>> We use it, and VR Juggler heavily depends on it.  Would it make sense to
>> bring it under the VR Juggler umbrella on GitHub?
>> https://github.com/vrjuggler
>>
>>
>> That might be an option. As long as we can create a fork and possibly
>> improve it.
>> If i understand this correctly, VRJuggler was one of the main drivers for
>> GMTL's development, so it makes sense.
>> Are you in contact with the original authors?
>>
>> Cheers
>> Sebastian
>>
>>
>> -Todd
>>
>> On Mon, Aug 8, 2016 at 4:39 AM, Sebastian Messerschmidt <
>> seb...@gm...> wrote:
>>
>>> Hi folks,
>>>
>>> Just wanted to know if there is still some people actively using gmtl in
>>> their day to day coding?
>>>
>>> We've contributed some changes/bugfixes in the past and like to present
>>> some new ones.
>>> Some of them will however break existing code (due to renaming and use
>>> of different types etc.) and the community doesn't seem very active :-(
>>>
>>> So basically the question which came to my mind if there are any
>>> inclinations is to create a fork on github where we could maintain a new
>>> set of gmtl-features, changes and fixes.
>>>
>>> Who is the current project lead and who could sign off a fork, so we
>>> don't infringe any copyright etc.
>>>
>>>
>>> Cheers
>>>
>>> Sebastian
>>>
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> _______________________________________________
>>> ggt-devel mailing list
>>> ggt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
>> patterns at an interface-level. Reveals which users, apps, and protocols are
>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>> planning reports. http://sdm.link/zohodev2dev
>>
>> _______________________________________________
>> ggt-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>
>> -- Sent from Gmail Mobile
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
>
> _______________________________________________
> ggt-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
>
> ------------------------------------------------------------
> ------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
>