On Wed, Oct 23, 2013 at 1:21 AM, Clifford Yapp wrote:
> I'm working on 03 currently - some preliminary commits will be coming
> soon, but really getting this right will take some trial and error.
I mentioned it in the commit message, but let me emphasize it on the
list too to avoid some well int
On Wed, Oct 23, 2013 at 12:13 AM, Christopher Sean Morrison
wrote:
>
> We have a lot to do to get ready for GCI, and outstandingly a lot of mentor
> interest. In
> preparation, we need those of you that are interested in mentoring to help
> get everything
> ready. Here's a list of some things
I forgot to mention one thing. Since there is substantial interest from a
number of people that do not have commit access established, I suggest going
through at least one GCI task to be familiar with the work, ideally two that
are different types. The list of open and completed tasks from las
We have a lot to do to get ready for GCI, and outstandingly a lot of mentor
interest. In preparation, we need those of you that are interested in
mentoring to help get everything ready. Here's a list of some things we need
to do in advance, please tackle any or all of them:
01) Post+announce
On Oct 22, 2013, at 10:27 PM, Clifford Yapp wrote:
> This has considerable appeal - what technical approach did you have in mind?
Basically just running a lintian program (probably astyle) during non-release
compilation. If it doesn't pass, report and halt the build. Most likely
easiestly ho
On Tue, Oct 22, 2013 at 10:27 PM, Clifford Yapp wrote:
> On Tue, Oct 22, 2013 at 9:06 PM, Christopher Sean Morrison
> wrote:
>>
>> I propose in advance of GCI that we establish style enforcement as part of
>> the build so that we don't have to personally discuss / explain style
>> issues. Basica
On Tue, Oct 22, 2013 at 9:06 PM, Christopher Sean Morrison
wrote:
>
> I propose in advance of GCI that we establish style enforcement as part of
> the build so that we don't have to personally discuss / explain style
> issues. Basically, we'd integrate a style check that would run during
> compil
I propose in advance of GCI that we establish style enforcement as part of the
build so that we don't have to personally discuss / explain style issues.
Basically, we'd integrate a style check that would run during compilation. If
a file fails our style check, it results in a compilation erro
On Mon, Oct 21, 2013 at 11:03 PM, Christopher Sean Morrison
wrote:
> Google Code-In is set to begin in a few weeks and I will be applying for
> BRL-CAD to participate. Friends at Google made it very clear that they were
> happy with our participation last year and we should definitely apply aga
On Dec 13, 2011, at 11:44 AM, Daniel Roßberg wrote:
> I promised to write down some thoughts about the NMG primitive I got
> during writing a C++ interface class for it. Well, here they are:
I've had this gold nugget tucked away for a while, but it's particularly
relevant now as I had several
On Mon, Oct 21, 2013 at 11:03 PM, Christopher Sean Morrison
wrote:
> Google Code-In is set to begin in a few weeks and I will be applying for
> BRL-CAD to participate. Friends at Google made it very clear that they
> were happy with our participation last year and we should definitely apply
> aga
On Oct 21, 2013 11:04 PM, "Christopher Sean Morrison"
wrote:
>
>
> Google Code-In is set to begin in a few weeks and I will be applying for
BRL-CAD to participate. Friends at Google made it very clear that they
were happy with our participation last year and we should definitely apply
again. So
On Oct 22, 2013, at 6:18 AM, Tom Browder wrote:
>> It should mirror what the rest of BU does with two separate code
>> initializers including an _INIT_ZERO static initializer and a regular INIT()
>> function.
>
> But isn't that for heap-type inits? This version doesn't use heap memory.
It's
On Tue, Oct 22, 2013 at 7:16 AM, Daniel Roßberg
wrote:
>
> I'll join you.
I will also be there.
--
H.S.Rai
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
On Tue, Oct 22, 2013 at 8:22 AM, Christopher Sean Morrison
wrote:
> On Oct 22, 2013, at 5:56 AM, Tom Browder wrote:
>> Hm, how about strtok vs. strsep? That was really the motivation
>> behind my choice in asc2g.c. If we have a preponderance of strtoks
>> then that should be preferred over strs
On Oct 22, 2013, at 5:56 AM, Tom Browder wrote:
>> On Tue, Oct 22, 2013 at 7:42 AM, Christopher Sean Morrison
>> wrote:
>> Not a big deal, but it introduces an inconsistency.
>>
>> There are dozens of strtoks, maybe hundreds, throughout the code. Even in
>> that one file, you only got some
On Tue, Oct 22, 2013 at 8:01 AM, Christopher Sean Morrison
wrote:
>> The r58250 fix works but IMHO it's a little wordier than my original
>> version..
>>
>> I have reverted the init stuff in my working copy and moved the
>> xferbuf init from the header ("= {0}") to the BU_* init macro.
>>
>> That
On Oct 22, 2013, at 4:39 AM, Tom Browder wrote:
> The r58250 fix works but IMHO it's a little wordier than my original version..
>
> I have reverted the init stuff in my working copy and moved the
> xferbuf init from the header ("= {0}") to the BU_* init macro.
>
> That gives a good compile.
>On Tue, Oct 22, 2013 at 7:42 AM, Christopher Sean Morrison
>wrote:
> Not a big deal, but it introduces an inconsistency.
>
> There are dozens of strtoks, maybe hundreds, throughout the code. Even in
> that one file, you only got some of them
Hm, how about strtok vs. strsep? That was really t
On Oct 22, 2013, at 2:46 AM, Tom Browder wrote:
> My bad, good catch. Actually I did compile but didn't catch the error
> in the log--I've been watching the overwhelming warnings and missed
> the error.
>
> I didn't think it was needed but didn't think it would hurt.
Not a big deal, but it i
The r58250 fix works but IMHO it's a little wordier than my original version..
I have reverted the init stuff in my working copy and moved the
xferbuf init from the header ("= {0}") to the BU_* init macro.
That gives a good compile. Opinion?
Best,
-Tom
P.S. I haven't finished fleshing out t
On Mon, Oct 21, 2013 at 9:56 PM, Nicholas Reed wrote:
> I'll presume to call it then. Remove %V at your leisure Tom.
Thanks, Nicholas.
Cheers!
-Tom
--
October Webinars: Code for Performance
Free Intel webinars can help
On Mon, Oct 21, 2013 at 11:55 PM, wrote:
> Revision: 58252
> http://sourceforge.net/p/brlcad/code/58252
> Author: brlcad
> Date: 2013-10-22 04:55:26 + (Tue, 22 Oct 2013)
> Log Message:
> ---
> hmm, implies this hasn't even been compilation-tested. seems unnecessary
>
23 matches
Mail list logo
