OpenSCAD release: 2013.06

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

OpenSCAD release: 2013.06

kintel
Administrator
Dear OpenSCAD users and developers,

OpenSCAD 2013.06 has just been released!

The source code, as well as binaries for Mac OS X, Windows and Linux can be downloaded from http://openscad.org.

Thanks goes to everyone who's contributed to this release, through development, bug reports, email discussions and being willing to use development snapshots.

As usual, we've added and modified a few language features, as well as added functionality in the GUI and cmd-line tools, as well as a long list of bugfixes and stability improvements.

A summary of changes since last release follows.

Take care,

 -Marius

Language Features:
o linear_extrude now takes a scale parameter:
  linear_extrude(height=a, slices=b, twist=c, scale=[x,y])
o Recursive use of modules is now supported (including cascading child() operations):
  https://github.com/openscad/openscad/blob/master/examples/example024.scad
o Parameter list values can now depend on earlier values, e.g. for (i=[0:2], j=[0:i]) ..
o value assignments in parameters can now depend on already declared parameters
o Added resize() module:
  http://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Transformations#resize

Program Features:
o Added basic syntax highlighting in the editor
o There is now a built-in library path in user-space:
  http://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Libraries#Library_Locations
o Commandline output to PNG, with various camera and rendering settings.        
  Run openscad -h to see usage info or see the OpenSCAD wiki user manual.
o Attempting to open or drag&drop dxf, off or stl files in the GUI will now create an import statement.
o The preview operator (%) will now preserve any manually set color
o The highlight operator (#) will now color the object in transparent red
o Mac: Added document icon
o Mac: Added auto-update check
o Windows: Better cmd-line support using the openscad.com executable

Bugfixes:
o Importing files is now always relative to the importing script, also for libraries
o We didn't always print a warning when CSG normalization created too many elements
o Binary STLs can now be read on big endian architectures
o Some binary STLs couldn't be read
o Fixed some issues related to ARM builds
o CGAL triangulation more lenient - enables partial rendering of 'bad' DXF data
o The Automatic Reload feature is now more robust
o If a file couldn't be saved it no longer fails silently
o Fixed a number of crashes related to CGAL and OpenCSG rendering or complex models
o The lookup() function had bad boundary condition behavior
o The surface() module failed when the .dat file lacked a trailing newline
o The hull() module could crash if any of the children were empty objects
o Some problems using unicode filenames have been fixed

Misc:
o Build scripts have been further improved
o Regression test now creates single monolithic .html file for easier uploading
o Regression test auto-starts & stops Xvfb / Xvnc if on headless unix machine
o The backend is finally independent of Qt
o Windows: We now have a 64-bit version

Known Bugs:
o Linux: command-line png rendering on Gallium is flaky.
  Workaround: use CGAL --render or hardware rendering.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD release: 2013.06

devlaam
Thank you for this release!

As far as i can see it works great on my designs. Awesome!!

Ruud



On 19-06-13 05:43, Marius Kintel wrote:

> Dear OpenSCAD users and developers,
>
> OpenSCAD 2013.06 has just been released!
>
> The source code, as well as binaries for Mac OS X, Windows and Linux can be downloaded from http://openscad.org.
>
> Thanks goes to everyone who's contributed to this release, through development, bug reports, email discussions and being willing to use development snapshots.
>
> As usual, we've added and modified a few language features, as well as added functionality in the GUI and cmd-line tools, as well as a long list of bugfixes and stability improvements.
>
> A summary of changes since last release follows.
>
> Take care,
>
>   -Marius
>
> Language Features:
> o linear_extrude now takes a scale parameter:
>    linear_extrude(height=a, slices=b, twist=c, scale=[x,y])
> o Recursive use of modules is now supported (including cascading child() operations):
>    https://github.com/openscad/openscad/blob/master/examples/example024.scad
> o Parameter list values can now depend on earlier values, e.g. for (i=[0:2], j=[0:i]) ..
> o value assignments in parameters can now depend on already declared parameters
> o Added resize() module:
>    http://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Transformations#resize
>
> Program Features:
> o Added basic syntax highlighting in the editor
> o There is now a built-in library path in user-space:
>    http://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Libraries#Library_Locations
> o Commandline output to PNG, with various camera and rendering settings.
>    Run openscad -h to see usage info or see the OpenSCAD wiki user manual.
> o Attempting to open or drag&drop dxf, off or stl files in the GUI will now create an import statement.
> o The preview operator (%) will now preserve any manually set color
> o The highlight operator (#) will now color the object in transparent red
> o Mac: Added document icon
> o Mac: Added auto-update check
> o Windows: Better cmd-line support using the openscad.com executable
>
> Bugfixes:
> o Importing files is now always relative to the importing script, also for libraries
> o We didn't always print a warning when CSG normalization created too many elements
> o Binary STLs can now be read on big endian architectures
> o Some binary STLs couldn't be read
> o Fixed some issues related to ARM builds
> o CGAL triangulation more lenient - enables partial rendering of 'bad' DXF data
> o The Automatic Reload feature is now more robust
> o If a file couldn't be saved it no longer fails silently
> o Fixed a number of crashes related to CGAL and OpenCSG rendering or complex models
> o The lookup() function had bad boundary condition behavior
> o The surface() module failed when the .dat file lacked a trailing newline
> o The hull() module could crash if any of the children were empty objects
> o Some problems using unicode filenames have been fixed
>
> Misc:
> o Build scripts have been further improved
> o Regression test now creates single monolithic .html file for easier uploading
> o Regression test auto-starts & stops Xvfb / Xvnc if on headless unix machine
> o The backend is finally independent of Qt
> o Windows: We now have a 64-bit version
>
> Known Bugs:
> o Linux: command-line png rendering on Gallium is flaky.
>    Workaround: use CGAL --render or hardware rendering.
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
> http://openscad.org - https://flattr.com/thing/121566
>

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD release: 2013.06

chrysn
In reply to this post by kintel
hello marius and all other openscad developers,

On Tue, Jun 18, 2013 at 11:43:12PM -0400, Marius Kintel wrote:
> OpenSCAD 2013.06 has just been released!

congratulations, it looks like a good release.


i'm in the progress of updating the debian package, and some questions
came to my mind:

* there have again been some files of dubious origin --
  not that i'd assume that anything is *wrong* license-wise, but i have to
  show that it is *right* license-wise for inclusion in debian, and
  files like scripts/LogicLib.nsh and scripts/git-archive-all.py make
  that difficult. as i'm already removing the flattr.png logo from the
  tarball, i decided to drop the whole scripts/ directory for debian,
  as it's maintenance stuff only anyway.

  (ok, that's not really a question, more of an observation -- if it
  were a question, it'd be "is there anything important in there?")

* the resize module is a great addition, and it changes the way i view
  openscad. before, it was like openscad fed its object and
  transformation tree into cgal/opencsg, and waited for the result to
  render or to be exported. now that there is an obvious way to get
  information back, i'd love to have a

  * bbox() {... children ...} function that returns a [[xmin, ymin,
    zmin], [xmax, ymax, zmax]] bounding box of the contained objects.

    (or is the distinction between functions and modules that strong?
    it might easily be, given that it is now for the first time that
    information from an object flows back into openscad space. in that
    case, we should think something up to make it possible.)

    with that function (and a parameter bbox(hide=1) that measures but
    does not render), a resize module could be written in pure openscad.

  * absolute_coords() function that returns the [x, y, z] coordinates of
    the current coordinate origin, and a transformation_matrix()
    function that returns the current projective matrix that would be
    applied to other objects in the same scope. with non-singular
    projective matrices, it'd be even possible to get
    absolute_rotation() information out.

    even though these functions are not in the same difficulty class as
    bbox (given the function/module dichotomy), they would be the first
    time that the result of a function operation is only available
    inside the scope of a module, and the need for a way to pass
    information out of a module again would arise. whatever solves the
    `x = bbox() {};` issue could solve this too, as that would be a way
    to pass information back out again.

  all together, this could be used to implement things like a
  `looking_at(coords) { }` module.

  i know i'm taking a single idea very far, but this is something i've
  been missing in earlier projects, so there's another idea that would
  now first become realistic:

  the echo() calls to stdout can usually only be captured when running,
  for example, a dxf export. back in 2010, i suggested to have a `null
  output operator`, ie a way to run openscad executing all the code, but
  neither exporting a dxf nor creating another form of output. with the
  information available now, this would again be more useful in
  calculations.

* now that there is a png export, can we drop the statically linked
  regression test stuff? we might not have the cgal tree output in the
  main binary, but that could be added easily -- the png output has
  always been the reason why there are individual tools for that.

  (the echotest would be equivalent to the `null output operator` i
  suggested above.)

  running the main openscad binary in the regresion tests would give a
  smaller code base and a better coverage of the code base. also, the
  amount of code needed to actually run the tests would become so small
  i could ship it with the normal openscad packages, giving everyone the
  chance to run the tests on their graphics card. some minor adaptions
  would be needed, because the cgalpngtest and openscad -o ....png have
  slightly different camera defaults.

* autoupdater: i appreciate that the auto updater utilizes the operating
  system's available mechanisms and does not try to implement another
  broken updater; in particular, i'd have to at least re-configure an
  update mechanism to only notify on request anyway for debian policy
  compliance. (linux distributions update independtly of the software).
  however, i'd like to suggest hiding the "update" tab in the
  preferences window if no mechanism is provided for the current os.

* test procedures: i guess you are aware that test_pretty_print.cc is a
  crude hack, but ... why?

  may i suggest a much easier way around this: openscad could, when
  built inside a git repository, and when it's not a release build, add
  a "(git XXXXXX)" (for XXXXX being the current git head id) version
  suffix. thus, tools like test_pretty_print.py could just include the
  output of `openscad --version` and need not be bothered with build
  directory locations. distribution packages, which are usually not even
  built inside a git checkout (at least in debian), would use the same
  field to indicate their complete version number (`qmake
  VERSION=2013.06 VERSIONSUFFIX='(debian package 2013.06+dfsg-1)'`), so
  whichever kind of build something is, `openscad --version`'s output
  would be meaningful to developers who try to evaluate a failing
  regression test.

the packages are still building on my box for tests for the moment;
given some transitions are currently in progress, openscad won't hit
debian unstable right away, but rather go to experimental -- but i'll
send an update once new packages are uploaded anyway.


best regards
chrysn

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD release: 2013.06

donbright

i am on openscad vacation for a while but ill hit some of these since i kinda uhm, worked on them.

* there have again been some files of dubious origin --
  not that i'd assume that anything is *wrong* license-wise, but i have to
  show that it is *right* license-wise for inclusion in debian, and
  files like scripts/LogicLib.nsh
 

logiclib.nsh should be under the same license as mingw-file-association.nsh since it was pulled off the nsis wiki site
same for the other nsis file x64.nsh

 
* the resize module is a great addition, and it changes the way i view
  openscad. before, it was like openscad fed its object and
  transformation tree into cgal/opencsg, and waited for the result to
  render or to be exported. now that there is an obvious way to get
  information back, i'd love to have a


adding  'resize' was somewhat easy compared to implementing a bbox() that returns height,width,length. resize is just a re-working of scale() in the code path as it exists....... but actually having a openscad-module "return" a vector of numbers (width, height) is a big rewrite of how the code works. Marius has discussed this elsewhere in more detail.
 

* test procedures: i guess you are aware that test_pretty_print.cc is a
  crude hack, but ... why?


cmake had an "upgrade" to their newest version that broke something that we, and many other programs, depend on, namely the use of CTEST_CUSTOM_POST_TEST with multiple arguments. they did this because some file paths in windows have spaces and they cant tell the diff between spaces in pathnames and a separator between arguments. theres a bug filed with cmake but i dont think they are going to do anything about this.

-DB

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD release: 2013.06

chrysn
On Thu, Jun 20, 2013 at 08:09:41PM -0500, Don Bright wrote:
> logiclib.nsh should be under the same license as mingw-file-association.nsh
> since it was pulled off the nsis wiki site
> same for the other nsis file x64.nsh

didn't find it in the wiki -- but generally, i don't think it's worth
tracking down every single file of those, as long as you don't consider
them an integral part of openscad.

> adding  'resize' was somewhat easy compared to implementing a bbox() that
> returns height,width,length. resize is just a re-working of scale() in the
> code path as it exists....... but actually having a openscad-module
> "return" a vector of numbers (width, height) is a big rewrite of how the
> code works. Marius has discussed this elsewhere in more detail.

yeah, but at least the information is there. maybe a debug_bbox() /
debug_current_matrix() would be a start, like echo, so it only gets
written to stdout.

> > * test procedures: i guess you are aware that test_pretty_print.cc is a
> >   crude hack, but ... why?
>
> cmake had an "upgrade" to their newest version that broke something that
> we, and many other programs, depend on, namely the use of
> CTEST_CUSTOM_POST_TEST with multiple arguments. they did this because some
> file paths in windows have spaces and they cant tell the diff between
> spaces in pathnames and a separator between arguments. theres a bug filed
> with cmake but i dont think they are going to do anything about this.

i see that there are difficulties with ctest. my point was rather that
we wouldn't need to send the information about the compile time path via
a c file compilation, but have openscad report its version in all detail
that would otherwise be queried using git from the build directory.


speaking of paths in the context of testing: the echotest test module
behaves different from openscad when it comes to relative paths. (this
only bites me (and people who want to test it from debian) and not the
other testers, because i had to modify the test scripts for relative
paths since i ship an openscad-testing package with which users can run
the tests out of tree).

the example is:

$ ./echotest ../testdata/scad/misc/dim-all.scad /dev/stdout
WARNING: Can't open DXF file '/usr/share/openscad/testdata/scad/misc/../testdata/scad/misc/dim-all.dxf'.
WARNING: Can't find dimension 'linearX' in '/usr/share/openscad/testdata/scad/misc/../testdata/scad/misc/dim-all.dxf', layer ''!
ECHO: linearX = undef
[...]

vs:

$ openscad ../testdata/scad/misc/dim-all.scad -o test.png
WARNING: Unsupported DXF Entity 'LEADER' (1) in "dim-all.dxf".
ECHO: linearX = 51.4496
[...]

which is a good case for the null output operator (with current syntax,
i propose -o null, which won't cause conflicts as it doesn't have an
extension to guess the file type) and for droping echotest in favor of
running the original openscad binary.

(for the time being, i'm patching my way around the path issues, so no
need for anything but The Good Once And For All Solution. i've got
issues left, but didn't track them down that far yet.)


best regards
chrysn

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD release: 2013.06

kintel
Administrator
In reply to this post by chrysn
My few cents,

On 2013-06-20, at 19:44 , chrysn wrote:

> now that there is an obvious way to get  information back, i'd love to have a
>
>  * bbox() {... children ...} function that returns a [[xmin, ymin,
>    zmin], [xmax, ymax, zmax]] bounding box of the contained objects.
>
You still cannot get information back. resize() doesn't query, it just dictates. The actual geometry evaulation happens in a separate pass, where the echo to the console is done before that pass happens.

To do what you suggest, we need to perform these passes synchronously, which is a bit of a refactoring job.

> * now that there is a png export, can we drop the statically linked
>  regression test stuff?

We already perform duplicate tests using the openscad binary vs. cgaltest and opencsgtest, checking against the same test results. This has been working for a while, so it should be safe to turn off those two tests, and start the same process for other tests.

As always, this is a lot of work, and it will only make sense if it saves significant time in the longer run, or if someone new decides to jump in and lend a pair of hands.

Related to this, the entire build system script setup could benefit from a thorough refactoring. What we've got now works, but there is lots of duplicate and unused code. It's pretty tricky to develop good build systems though, and time consuming to test them..

> * autoupdater: […]i'd like to suggest hiding the "update" tab in the
>  preferences window if no mechanism is provided for the current os.
>
Good point - issue added.

Cheers,

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD release: 2013.06

kintel
Administrator
In reply to this post by chrysn
On 2013-06-20, at 19:44 , chrysn wrote:
> i decided to drop the whole scripts/ directory for debian,
>  as it's maintenance stuff only anyway.
>
Don't you need some of those scripts to build the debian package?
..or are build scripts duplicated somewhere in the debian packaging system?

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD release: 2013.06

kintel
Administrator
In reply to this post by chrysn
On 2013-06-21, at 13:18 , chrysn wrote:
>
> speaking of paths in the context of testing: the echotest test module
> behaves different from openscad when it comes to relative paths. (this
> only bites me (and people who want to test it from debian) and not the
> other testers, because i had to modify the test scripts for relative
> paths since i ship an openscad-testing package with which users can run
> the tests out of tree).
>
The tests are dependent of being passed an absolute path to the files in question.
This is a remnant of past limitations, and I guess we could fix this now.

I think what we need is a good writeup on the procedure you use for packaging and testing under Debian - it's becoming a bit hard to follow your suggestions, and in the end we need to be able to reproduce your setup to be able to fix these issues.

 -Marius
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD release: 2013.06

chrysn
In reply to this post by kintel
On Fri, Jun 21, 2013 at 01:45:31PM -0400, Marius Kintel wrote:
> On 2013-06-20, at 19:44 , chrysn wrote:
> > i decided to drop the whole scripts/ directory for debian,
> >  as it's maintenance stuff only anyway.
>
> Don't you need some of those scripts to build the debian package?
> ..or are build scripts duplicated somewhere in the debian packaging system?

no build scripts are needed on debian -- the debhelper detects that it's
a qmake project and runs qmake-qt4 / make / make install with the
appropriate parameters automatically. the dependencies mustn't be
fetched individually, but are declared in a descriptive file
(debian/control).

for what i saw, the scripts are more concerned with release management,
website updating and other operating system installers anyway, neither
of which is a concern for debian.

best regards
chrysn

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD release: 2013.06

chrysn
In reply to this post by kintel
On Fri, Jun 21, 2013 at 01:43:31PM -0400, Marius Kintel wrote:
> You still cannot get information back. resize() doesn't query, it just dictates. The actual geometry evaulation happens in a separate pass, where the echo to the console is done before that pass happens.
>
> To do what you suggest, we need to perform these passes synchronously, which is a bit of a refactoring job.

ok -- having the resize command seems stranger to me then, but i see
that under those circumstances, the other suggested functions would
still be as difficult as before.

> > * now that there is a png export, can we drop the statically linked
> >  regression test stuff?
>
> We already perform duplicate tests using the openscad binary vs. cgaltest and opencsgtest, checking against the same test results. This has been working for a while, so it should be safe to turn off those two tests, and start the same process for other tests.
>
> As always, this is a lot of work, and it will only make sense if it saves significant time in the longer run, or if someone new decides to jump in and lend a pair of hands.

i can't promise anything, but that's enough of a statement to me that
i'll look into reworking this if the path issues become too much of a
hassle.

thanks for your replies
chrysn

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD release: 2013.06

chrysn
In reply to this post by kintel
On Fri, Jun 21, 2013 at 02:17:33PM -0400, Marius Kintel wrote:
> The tests are dependent of being passed an absolute path to the files in question.
> This is a remnant of past limitations, and I guess we could fix this now.
>
> I think what we need is a good writeup on the procedure you use for packaging and testing under Debian - it's becoming a bit hard to follow your suggestions, and in the end we need to be able to reproduce your setup to be able to fix these issues.

yes, my mail was not a full bug report -- i haven't tracked down where i
broke things vs. where things are limited in the first place.

while the out-of-tree testing i'm workin on is debian specific for the
moment (as i rely on features of debian's build system to patch the
ctest files), i want to simplify it far enough so it can work with every
build.

with both the currently developed packages and the ones in debian,
running the tests is a matter of

$ sudo aptitude install openscad-testing
$ openscad-testrun

which generates a timestamped openscad-testing folder and runs
everything in it, but not all tests pass yet. (code[1], man page[2] --
but more of it is the removal of dependence on paths and on the source
tree)

best regards
chrysn

[1] http://gitorious.org/openscad-debian/openscad/blobs/debian/debian/openscad-testrun
[2] http://gitorious.org/openscad-debian/openscad/blobs/debian/debian/openscad-testrun.1

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD release: 2013.06

chrysn
On Sat, Jun 22, 2013 at 12:48:27PM +0200, chrysn wrote:
> no build scripts are needed on debian -- the debhelper detects that it's
> a qmake project and runs qmake-qt4 / make / make install with the
> appropriate parameters automatically. the dependencies mustn't be
> fetched individually, but are declared in a descriptive file
> (debian/control).

On Sat, Jun 22, 2013 at 01:21:44PM +0200, chrysn wrote:
> while the out-of-tree testing i'm workin on is debian specific for the
> moment (as i rely on features of debian's build system to patch the
> ctest files), i want to simplify it far enough so it can work with every
> build.

i guess that came over a little contradictory -- just to clarify:
nothing out of scripts like scripts/installer-linux.sh is needed on
debian, because all of that follows trivially from the qmake files,
scripts/openscad-linux is not needed due to use of default paths, etc.

there are script lines in the debian/rules file[1], but they are for
things like telling the system that it's ok to use hardening flags and
parallel building, how to build the tests/ stuff for path independent
use, and how to actually run the tests at build time.

best regards
chrysn

[1] http://gitorious.org/openscad-debian/openscad/blobs/debian/debian/rules

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD release: 2013.06

kintel
Administrator
In reply to this post by chrysn
On 2013-06-22, at 07:21 , chrysn wrote:
>
> with both the currently developed packages and the ones in debian,
> running the tests is a matter of
>
> $ sudo aptitude install openscad-testing
> $ openscad-testrun
>
Nice - it is possible to somehow run that process against a local copy of the openscad source code for testing?

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD release: 2013.06

chrysn
On Sat, Jun 22, 2013 at 12:16:59PM -0400, Marius Kintel wrote:
> > $ sudo aptitude install openscad-testing
> > $ openscad-testrun
>
> Nice - it is possible to somehow run that process against a local copy of the openscad source code for testing?

none that i thought of so far, but PATH=$PWD:$PATH openscad-testrun would
do the trick.

best regards
chrysn

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (853 bytes) Download Attachment
Ivo
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD release: 2013.06

Ivo
In reply to this post by kintel
Thanks !

The OPENSCADPATH enviroment variable allowed me to really clean up the scripts i use and put them under source control in a central location.
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD release: 2013.06

chrysn
In reply to this post by kintel
On Fri, Jun 21, 2013 at 02:17:33PM -0400, Marius Kintel wrote:
> The tests are dependent of being passed an absolute path to the files in question.
> This is a remnant of past limitations, and I guess we could fix this now.

i'm hacking around removing one testing-specific binary after the other,
and the number of issues with out-of-tree testing has already decreased.
(so far, dumptest, moduledumptest, echotest and cgalpngtest are gone;
some adaptions in the unit test results are needed as the code bases
have already started to diverge).

i'm stuck with a output option for the csg terms (-o my_csg.term),
mainly resulting from me not knowing any significant c++ (which is bad
when one tries to deal with shared_ptr and stuff).

attached, there is my working copy of `src/openscad.cc`, do you easily
spot the mistake that makes gcc claim "invalid use of incomplete type
‘class CSGTerm’" after "forward declaration of ‘class CSGTerm’";
culprits are expected in lines 413 and 425. could one of you c++ users
have a look and hint me to what i'm doing wrong?

(yes, there might be unnecessary includes, i'll try to get them minimal
again when things work. the file has a proper git history, and when it's
done, i'll submit it as a proper patch.)

thanks in advance
chrysn

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

openscad.cc (17K) Download Attachment
signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD release: 2013.06

nophead
Should be shared_ptr<CSGTerm> instead of shared_ptr<class CSGTerm> I think.


On 25 June 2013 00:36, chrysn <[hidden email]> wrote:
On Fri, Jun 21, 2013 at 02:17:33PM -0400, Marius Kintel wrote:
> The tests are dependent of being passed an absolute path to the files in question.
> This is a remnant of past limitations, and I guess we could fix this now.

i'm hacking around removing one testing-specific binary after the other,
and the number of issues with out-of-tree testing has already decreased.
(so far, dumptest, moduledumptest, echotest and cgalpngtest are gone;
some adaptions in the unit test results are needed as the code bases
have already started to diverge).

i'm stuck with a output option for the csg terms (-o my_csg.term),
mainly resulting from me not knowing any significant c++ (which is bad
when one tries to deal with shared_ptr and stuff).

attached, there is my working copy of `src/openscad.cc`, do you easily
spot the mistake that makes gcc claim "invalid use of incomplete type
‘class CSGTerm’" after "forward declaration of ‘class CSGTerm’";
culprits are expected in lines 413 and 425. could one of you c++ users
have a look and hint me to what i'm doing wrong?

(yes, there might be unnecessary includes, i'll try to get them minimal
again when things work. the file has a proper git history, and when it's
done, i'll submit it as a proper patch.)

thanks in advance
chrysn

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD release: 2013.06

kintel
Administrator
In reply to this post by chrysn
On 2013-06-24, at 19:36 , chrysn wrote:
>
> i'm hacking around removing one testing-specific binary after the other,

Thanks for helping out!

> attached, there is my working copy of `src/openscad.cc`, do you easily
> spot the mistake that makes gcc claim "invalid use of incomplete type
> ‘class CSGTerm’" after "forward declaration of ‘class CSGTerm’";
> culprits are expected in lines 413 and 425. could one of you c++ users
> have a look and hint me to what i'm doing wrong?
>
$ diff -u openscad.cc openscad.cc.works
--- openscad.cc 2013-06-24 20:16:19.000000000 -0400
+++ openscad.cc.works 2013-06-24 20:16:07.000000000 -0400
@@ -45,6 +45,7 @@
 #include "rendersettings.h"
 
 #ifdef ENABLE_OPENCSG
+#include "csgterm.h"
 #include "CSGTermEvaluator.h"
 #include "OpenCSGRenderer.h"
 #include <opencsg.h>
@@ -410,7 +411,7 @@
  std::vector<shared_ptr<CSGTerm> > background_terms;
 
  CSGTermEvaluator csgrenderer(tree, &psevaluator);
- shared_ptr<class CSGTerm> root_raw_term = csgrenderer.evaluateCSGTerm(*root_node, highlight_terms, background_terms);
+ shared_ptr<CSGTerm> root_raw_term = csgrenderer.evaluateCSGTerm(*root_node, highlight_terms, background_terms);
 
  fs::current_path(original_path);
  std::ofstream fstream(term_output_file);

Cheers,

 -Marius



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (210 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD release: 2013.06

donbright
In reply to this post by chrysn



On Fri, Jun 21, 2013 at 12:18 PM, chrysn <[hidden email]> wrote:
On Thu, Jun 20, 2013 at 08:09:41PM -0500, Don Bright wrote:
> logiclib.nsh should be under the same license as mingw-file-association.nsh
> since it was pulled off the nsis wiki site
> same for the other nsis file x64.nsh

didn't find it in the wiki -- but generally, i don't think it's worth
tracking down every single file of those, as long as you don't consider
them an integral part of openscad.


ok my bad, its not on the wiki but...

logiclib.nsh is part of nsis itself. which has a big zlib license notice on it.
x64.nsh is as well.

confirmable by downloading nsis source code.

-DB



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

no-testprograms branch (was: Re: OpenSCAD release: 2013.06)

chrysn
In reply to this post by kintel
On Mon, Jun 24, 2013 at 08:17:32PM -0400, Marius Kintel wrote:
> +#include "csgterm.h"

thanks, that was what i missed.

i've created a pull request [1] for the first steps removing the test
programs. summarizing what i wrote in `doc/testing.txt`:

* i dropped moduledumptest, csgtermtest, cgalpngtest and opencsgtest;
  for moduledumptest, there is a new `-o someting.ast` option in the
  main binary that does what `Design/Display AST` does, for csgtermtest
  there is `.term` analogous to `Design/Display CSG tree`, and
  cgalpngtest and opencsgtest utilize the png export functions that are
  built in since 2013.06.

* echotest (`-o null`, newly added) and dumptest (`-o something.csg`)
  got replaced with little shell helper scripts, which work around the
  remaining issues that result from the binary not being built with
  OPENSCAD_TESTING any more.  in particular, this affects floating point
  precision, but that seems to be less of an issue since 8e4bc5d598cd.
  some of the normalizations ("-0" -> "0" and "-nan" -> "nan") i moved
  out of the conditional, so they apply always now -- personally, i'd
  rather have everything that converts floats to ascii output the full
  number (0.8000000000000004), but if we do take the step of trimming
  around so that people need not be aware of the nature of floats, we
  can just as well do that.

  as we're already outputting trimmed floats, i suggest dropping the
  whole OPENSCAD_TESTING ifdef from src/value.cc, and declaring that
  everything below 1e-12 is too smal to be output (beware that's a
  completely different issue than the "math bug" discussed somewhere
  else -- these values are meant to be end results, and due to the
  trimming unsuitable for further computation anyway).

  i chose not to do this in the pull request, as i'd prefer to get some
  feedback of whether the current output is really platform independent
  before changing it further.

* csgtexttest, throwntogethertest and cgalstlsanitytest are yet to be
  converted.

  * csgtexttest -- what does that actually do, why is it there, and what
    does it do that csgtermtest together with dumptest can not verify?

  * throwntogethertest -- i'd be glad if whoever did the original png
    exporting thing could add a flag --throwntogether (like --render)
    that provides the export function

  * cgalstlsanitytest -- is this really all about no NaN showing up? if
    so, a) why don't we just do a regression test on the stl file, and
    if that's because the stl export is volatile, b) would it be
    sufficient to export it to a stl file and verify using grep whether
    or not a NaN occurs?

* modulecachetest and cgalcachetest are built by CMakeList.txt but not
  used -- is that a thing at all, what does it do and can what it does
  be reasonably output by openscad?

  (if it, reports some kinds of statistics about the cache usage in an
  openscad run, we could have a `--cache-report report.txt` option; that
  would also be useful for people running openscad batch processes for
  rendering things and notifying people if they overstress the server's
  resources).

please merge the pull request[1] and let me know if it fails on other
platforms, and how (sequence possibly reversed depending on your
development model).


i haven't yet looked into the absolute path stuff yet, but at least
out-of-tree tests with openscad-testrun do now work.

best regards
chrysn

[1] https://github.com/openscad/openscad/pull/421

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

signature.asc (853 bytes) Download Attachment
12