Fwd: status of STEP Class Library in BRL-CAD
Bryan Bishop
From: Mark <mpi...@gmail.com>
Date: Wed, Jul 6, 2011 at 4:18 PM
Subject: [brlcad-devel] status of STEP Class Library in BRL-CAD
To: brlcad...@lists.sourceforge.net
I worked with SCL a few years ago, and there has been renewed interest in it from various parties. As a result, I copied my version of the source from google code to github( https://github.com/mpictor/StepClassLibrary ). Today I was searching for more users of scl, and found out that BRL-CAD uses it - a fact that I had not been aware of, in spite of adding information to the wiki page http://brlcad.org/w/index.php?title=STEP ! (When I added the info I thought, mistakenly, that I was the only one working with SCL.)
_______________________________________________
BRL-CAD Developer mailing list
brlcad...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
--
- Bryan
http://heybryan.org/
1 512 203 0507
Clifford Yapp
> * What license are the devs using for SCL? Sourceforge says the project is
> LGPL/BSD, but I wasn't sure if that was a dual license, or if portions of it
> were released under one license and portions under another.
The LGPL license is the primary license for BRL-CAD as a whole, which
is why you see it on the sourceforge page. Our build system is BSD
licensed. SCL is more properly regarded as a subproject we include
for build convenience - it happens to be the primary repository for us
since as far as we knew at the time we were the only interested
developers, so we haven't yet made a separate project for just the
SCL.
> http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/other/step/CMakeLists.txt?revision=43301&view=markup seems
> to imply that SCL is (C) US ARL, which does not make sense to me.
SCL itself is of course from NIST, and not copyright by ARL. We have
added new build logic, both the autotools logic and the newer CMake
logic. The CMake logic itself is thus copyright by ARL, but that does
not imply that the copyright applies to the remainder of SCL. The
status of the broader SCL code is indicated by the COPYING file in our
repository - if I recall correctly, aside from build logic the main
differences in our repository from the NIST original are the
application of all the compile fixes we could scare up or make at the
time we imported the repository. The subversion history will show
what we did - I tried to make that history reflect the various steps
from the NIST code to the current BRL-CAD repository.
> * Have you been able to use SCL with modern EXPRESS schemas? I've run into
> trouble with most of the ones I've tried with my version of SCL, but I don't
> know a lot about EXPRESS or parsers and haven't found the cause.
I believe the developer who did the primary development work for our
converter found he had to get a newer schema working, but I don't
recall the details - I'd have to scan the commit history.
> * What are your future plans for SCL? Have you generated all the code you
> will ever need, meaning that you won't ever have reason to work on SCL
> again?
We will definitely have reason to work on SCL - the code base needs
quite a lot of modernization (they predate a lot of the modern C++
STL, and we need to scrub out the custom one-off string handling (just
to pick one glaring example) in favor of using STL.) In fact,
scrubbing the SCL code was one of our proposed GSoC activities.
I'm currently exploring options for how to approach SCL from a code
generating standpoint - personally I loathe including machine
generated code in repositories for anything except bootstrapping and
have been exploring cross platform ways to integrate the code
generating process into the CMake build. That's got a ways to go (I'm
currently learning about the re2c lexer and lemon parser, which both
seem to be cross platform and may be a way to move the express
lex/yacc logic to something we can use on Windows). I think our
step-g converter is currently using a tweaked version of SCL's
generated code, but that's not what we (or I at least) want to do long
term.
BRL-CAD is moving to it because we must support MSVC Windows building
and CMake allows us to do it from a single set of build files. Going
forward BRL-CAD will be using CMake to build SCL, so from our
standpoint our SCL autotools build logic is on its way out.
> Or do you intend to support more or newer STEP APs?
It's not an immediate short term goal - 203 is our main focus at this
time, but certainly others are of longer term interest if they
describe geometry (214 I believe is one of the others...)
> If the former, I'd like to integrate your work on SCL into my project - assuming the license is compatible.
I'm not recalling anything we put into the SCL code that would dictate
LGPL licensing - certainly we haven't tossed an LGPL on the whole of
our version of the NIST repository. I don't recall if we made any
non-bug-fix changes that might raise the issue for any code in there.
Certainly the build logic is BSD license - that's standard for all
BRL-CAD's build logic that we have written. If there is any concern I
can check with our project lead to confirm that our SCL is BSD clear.
> If the latter, perhaps we can collaborate.
We are certainly very interested in collaborating!
> Thomas Paviot, who created
> OpenCASCADE Community Edition, rounded up a group of people interested in
> SCL. The group includes people who help run PDES and CAX-IF - if we get SCL
> to work with new schemas, there should be a lot of people willing to test
> and improve it.
What specific schemas did you want to target? Are they online?
Cheers,
CY
Bryan Bishop
From: Christopher Sean Morrison <brl...@mac.com>
Date: Thu, Jul 7, 2011 at 9:59 AM
Subject: Re: [brlcad-devel] status of STEP Class Library in BRL-CAD
To: BRL-CAD Developer Mailing List <brlcad...@lists.sourceforge.net>
I worked with SCL a few years ago, and there has been renewed interest in it from various parties. As a result, I copied my version of the source from google code to github( https://github.com/mpictor/StepClassLibrary ). Today I was searching for more users of scl, and found out that BRL-CAD uses it - a fact that I had not been aware of, in spite of adding information to the wiki page http://brlcad.org/w/index.php?title=STEP ! (When I added the info I thought, mistakenly, that I was the only one working with SCL.)
* What license are the devs using for SCL?
http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/other/step/CMakeLists.txt?revision=43301&view=markup seems to imply that SCL is (C) US ARL, which does not make sense to me.
* Have you been able to use SCL with modern EXPRESS schemas?
* What are your future plans for SCL? Have you generated all the code you will ever need, meaning that you won't ever have reason to work on SCL again? Or do you intend to support more or newer STEP APs?
If the latter, perhaps we can collaborate.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
BRL-CAD Developer mailing list
brlcad...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
Mark
We not only use it, but per prior talks with some of the original NIST developers, we had taken over maintainership of SCL. Given our need for robust import/export of AP202 & AP214 geometry and lack of activity elsewhere, it was a natural fit. We just hadn't gotten around to publishing an updated standalone SCL release outside our repo.
* What license are the devs using for SCL?We haven't changed the original SCL licensing terms. Portions of the BRL-CAD repo are under different license terms.If I recall correctly, the majority of the NIST-developed code is BSD or public domain. Our additions, such as the build system file you reference is BSD just so it matches the rest of the build system. We strictly interact only with OSI licenses that are unincumbering and readily incorporateable into derivative and collective works, or public domain code. ;-)http://brlcad.svn.sourceforge.net/viewvc/brlcad/brlcad/trunk/src/other/step/CMakeLists.txt?revision=43301&view=markup seems to imply that SCL is (C) US ARL, which does not make sense to me.
# C M A K E L I S T S . T X T
# SCL
#
# Copyright (c) 2010 United States Government as represented by
# the U.S. Army Research Laboratory.
I beleive so but that would have been work done several years ago. We have already made quite a number of mods over the past few years since the takeover so best way to find out is to try one. You have a particular AP in mind besides 11/203/214 files?* Have you been able to use SCL with modern EXPRESS schemas?
We're definitely not done. ARL funded the development of an initial working STEP-to-BRL-CAD importer over a year ago. More work on that importer is going on now and I'm hoping we'll get to an exporter sometime next year.* What are your future plans for SCL? Have you generated all the code you will ever need, meaning that you won't ever have reason to work on SCL again? Or do you intend to support more or newer STEP APs?
Cliff mentioned several of the SCL dev tasks currently on our radar. Code modernization, new build system, and portability to Windows being key efforts we need. Restablishing a new project home is another as we get closer to pushing out an updated SCL release.
Collaboration sounds fantastic. I view STEP as our preferred import/export format for BRL-CAD given the breadth of entities it supports. It is the only open format I'm aware of capable of representing the majority of BRL-CAD entity types and operations.If the latter, perhaps we can collaborate.
Cheers!Sean