> Not great, but not the end of the world. Reason it's not const? Reason it's
> not named "dbip" instead of "db"?
Changed. Sorry for the bad naming.
> Both of those structures do not have a dbip as they don't belong to any
> particular dbi and conceivably could belong to many simultaneously.
On Sep 3, 2013, at 11:48 PM, Clifford Yapp wrote:
> On Tue, Sep 3, 2013 at 5:48 AM, phoenix <284281...@qq.com> wrote:
>> Hi!
>>
>> I'm implementing rt_comb_brep() which is going to convert a COMB to BREP
>> with NURBS boolean evaluations. But currently I have to pass in a db_i
>> pointer every t
Kesha,
I noticed the recent questions on your dev log. Below are some additional
answers following our previous discussion.
On Sep 3, 2013, at 11:55 PM, Christopher Sean Morrison wrote:
> On Sep 2, 2013, at 2:32 PM, Kesha Shah wrote:
>
>> Hi Sean,
>>
>> I found a simple .dxf geometry file on
On Tue, Sep 3, 2013 at 5:48 AM, phoenix <284281...@qq.com> wrote:
> Hi!
>
> I'm implementing rt_comb_brep() which is going to convert a COMB to BREP
> with NURBS boolean evaluations. But currently I have to pass in a db_i
> pointer every time because the tree only stores names in its leaves, so we
This sets an interesting precedent. Do we want third-party documentation in
our doc/ directory? I think most of our dependencies retain their
documentation in their respective src/other subdirectory.
I'd claim that external dependencies are not ours to document; they're merely
included for do
On Tue, Sep 3, 2013 at 11:05 PM, Christopher Sean Morrison
wrote:
> Popt is probably sufficient. Another possibly worth considering is the
> header-only TCLAP
> ( http://tclap.sourceforge.net/ ) library. I've also been fond of 'argtable'
> in the past, but
> think we should try to get a BSD/M
On Sep 3, 2013, at 9:10 PM, Clifford Yapp wrote:
> Even if we use popt I imagine we'll eventually hide it behind some
> sort of libbu wrapper, so the ideal thing would be to figure that out
> and only link popt in through libbu - I'm not sure how or if that
> factors in to what your working on To
On Tue, Sep 3, 2013 at 4:00 PM, Tom Browder wrote:
> I'm fairly well along in my auto-man-page project and am on the final, and
> most complicated, part: option handling. As my own opt description language
> gets more complex, I see now that it would be very helpful to use the
> facilities of the
I'm fairly well along in my auto-man-page project and am on the final, and
most complicated, part: option handling. As my own opt description
language gets more complex, I see now that it would be very helpful to use
the facilities of the popt option-handling library.
Can we go ahead and integrat
I added sign-up / sign-in feature and basic CSS to geometry viewer.
Check here: http://202.164.53.122/~harman/geometry_viewer/accounts/landing.php
--
Harmanpreet Singh
Blog: http://singhharman.wordpress.com/
--
Learn the
On Sat, Aug 31, 2013 at 10:17 AM, Clifford Yapp wrote:
> On Sat, Aug 31, 2013 at 7:46 AM, Tom Browder
> wrote:
> > Cliff, I've taken the liberty of starting style sheets for the article
> type
> > and added two files:I saw - I've taken a slightly different approach.
> Let me know if
>
...
> it
2013/9/1 Vlad Bogolin :
>
> Finally, I tried to see how a framebuffer window should be embedded. The
> first problem that comes in mind is the framebuffer: which one should I use?
> I saw that creating a new Qt framebuffer was another GSoC proposed idea so
> the ideal solution (a Qt framebuffer) ca
Hi!
I'm implementing rt_comb_brep() which is going to convert a COMB to BREP with
NURBS boolean evaluations. But currently I have to pass in a db_i pointer every
time because the tree only stores names in its leaves, so we have to look up
the database and find the solids referred to in the COMB
Hi,
I am currently implementing the pull_leaf() routine which pulls a
primitive. Since I am to support all existing primitives. I would need some
mathematical guidance for the following 26 primitives.
TOR, SUPERELL, METABALL, ARB8, ARS, HALF, GRIP, POLY, BSPLINE, BREP, EBM,
VOL, HF, ARBN, PIPE, RP
14 matches
Mail list logo