Re: [OpenSCAD] insights for openscad and pyopenscad from the libre 15.6in laptop project
Hmmm. Where to start.
Firstly, if you haven't subscribed yet, Your post is still flagged as "This
post has NOT been accepted by the mailing list yet", so nobody gets it
unless they look.
You need to subscribe to the mailing list
http://forum.openscad.org/mailing_list/MailingListOptions.jtp?forum=1 ,
and respond to the registration email.
I'll quote the full OP below for those only on the mailing-list.
"however that the openscad language is not NP-complete" - that do you mean
by that?
'btw in the vein of "stark simplicity", i noticed that the latest version
of openscad (which i couldn't use because of severe useability flaws
in the frame-rate rendering, due to known bugs in libqt5) has a toolbar.
PLEASE MAKE THIS OPTIONAL.' - View/Hide-Toolbars
"my recommendation to you therefore would be to CUT the in-tool editor
entirely." There are many types and levels of OpenSCAD users (and operating
systems used). I don't think not having an editor would be helpful to many.
IMO
Others may have something to comment on below.
lkcl wrote
hi folks,
i just wanted to let you - especially the developers - know that i've been
using openscad (and something called pyopenscad) for the past fifteen
months to develop an extremely complex GPLv3+ project containing over
35 separate parts: a libre 15.6in laptop. the source code is currently
almost five THOUSAND lines long (excluding support libraries).
to say that i am extremely grateful that openscad exists would be a
huge understatement. i am a big fan of simplicity (zero cruft) and
high bang-per-buck ratio tools. i tried mm3d once, and stopped
after manually adding 2,500 points by hand with a mouse. that
experience was enough of a stark contrast to make me deeply
appreciate the power of parametric design.
so after fifteen months of near-continuous use i have some insights
that i'd like to share with you.
the key critical advantage of being able to use a text-based parametric
design i find is that i can use git revision control. i recently needed
to
revert a modification involving magnetic catches in the lid, and it was
a simple matter of "git log | grep -10 magnet" to find out what i had
done, because i am regularly committing with descriptive comments for
exactly this purpose.
the key critical advantage of using pyopenscad is however that the
openscad language is not NP-complete, and i can neither recommend
to the developers that they even remotely contemplate making the
openscad language NP-complete (why would you ever want to both
create and maintain an obscure programming language when there
exist perfectly good ones already?), nor, even if the openscad language
were made NP-complete would i ever consider using it directly.
the reason: python is a well-known, extremely comprehensive language
with object-orientated features. i use it because it's easier to do so.
now, in an earlier incarnation of my programming history i would have
advocated or suggested adding language bindings to openscad, but
honestly, i feel that the openscad language itself - when combined
with language translators (such as pyopenscad) is perfectly suited to
the task. pyopenscad is "another tool based on the unix principle",
whilst openscad is likewise, and the same with python.
... why make openscad complex? the moment you add language
bindings for python, the .NET developers will want one too. and perl.
and everyone else, and that just opens the floodgates and you'll be
making language bindings forever instead of focussing on improving
openscad.
btw in the vein of "stark simplicity", i noticed that the latest version
of openscad (which i couldn't use because of severe useability flaws
in the frame-rate rendering, due to known bugs in libqt5) has a toolbar.
PLEASE MAKE THIS OPTIONAL. screen real-estate is critical to me,
and there is literally nothing on the toolbar that i need or will need...
EVER. i use a single-key vim macro to run the python program that
auto-generates the openscad output; this in turn triggers openscad
to reload that output and automatically generate the render. following
that, i can press F6, and if the CGAL looks good i can export to STL.
there is ZERO need in this scenario for an in-tool editor (nothing beats
vim or emacs or the end-user's editor of choice: i'm curious to know
why openscad even has a built-in editor at all - it breaks the unix
principle "do one thing and do it well"). example: you're never going
to duplicate the vim "colour syntax highlighting" capabilities, and even
if you do they will never be as good (or as customisable) as vim. even
if you did duplicate the full set of vim "colour syntax highlighting"
which is so advantageous an aid to programming, you would now be
vim contributors... not openscad developers. my recommendation to
you therefore would be to CUT the in-tool editor entirely. make it
a completely separate program in order to keep people happy who
currently use it... but advise them that it has become a "non-maintained"
external tool that will be deprecated within the next 18-24 months.
there is also zero need (except when there are CGAL "invalid manifold"
errors) for the console - i hide that. likewise, i notice the addition
of a tree-view in the latest version. whilst i can see its potential for
small-scale objects (especially if combined for example with object
highlighting, which i have to say would be incredibly useful even
and especially with massively-complex objects), again it is something
that, for the most part, just takes up screen real-estate. so it too
is gone: off.
basically i would be happy if there was literally no menu, that there
was pretty much a single window, and for accessing the menu the
only way to do so was by right-mouse context-menu. given that
scroll-wheel equals the same functionality as middle-wheel
press-and-drag, and dual left-and-right button is the same as
left-button, there is room here to jig things around, move the entire
menu onto right-mouse button, and save some screen real-estate.
honestly, though, the size of the menus (and the status bar),
UNLIKE the new toolbar, are small enough in font size that they are
really no bother, and the change in UI expectations is a definite
barrier. the new toolbar however, as it uses massively oversized
icons, HAS TO GO. if i absolutely have to upgrade any time soon,
i will actually download the source, hack the toolbar OUT, and use
a modified self-maintained version, it's that serious an impediment
to useability.
on the subject of focussing your efforts to make specialist "do one
thing and do it well" style improvements to the actual core function
of what openscad does, i would recommend looking up the reasons
why julia longtin completely reimplemented openscad in haskell.
the two key reasons are: to add an automatic "rounding corners"
feature to union and intersection (by way of a parameter). this
extra parameter basically caused special (spherical at corners,
cylindrical at edges) "fuzzing" joins that save a vast amount of
futzing about, as well as make parts that properly fit together,
and make 3D-printing of parts come out without the usual
"blobbing" at corners. 3D print-heads do not turn right-angles
on a dime, so it is necessary to add "curvature". julia made it
unnnbelievably simple to do that: add a cube to a union with
the "rounding" parameter set to exactly how much curvature you'd
like, and... job's done: the cube comes out with rounded edges
and corners. this turns out to be really critical when doing
lostPLA aluminium casting [which is what julia's doing, and is the
whole reason why she rewrote openscad in haskell].
second thing: when two objects are mathematically exactly lined up
and touching, openscad (actually probably libCGAL) sometimes
decides that the objects are separate, and sometimes decides that
they are one object. the fact that there is indecision is itself
the problem. it's critical that openscad decide to be one or the
other, not either. honestly i feel that you should either generate
a compile error or decide to bite the bullet and fix this one (as it's
"core functionality"). forcing users to make their openscad
source code that much more complex - by forcing them to add in
"overlap" - isn't a nice thing to do to them! even adding an extra
parameter to union and intersect etc. to say "these two objects
are definitely, definitely part of the same one object, ALTER THE
OBJECT to make ABSOLUTELY sure that's the case, or if you
genuinely can't programmatically work out what faces are actually
touching, to within a reasonable (and very very small) margin,
throw a compile error".
personally i would set this parameter to default to "True" and i
would strongly recommend that it be set to "True" on union (etc.)
but even if you didn't, because i am using pyopenscad i could
get pyopenscad to auto-generate scad files that override
whatever default behaviour you chose.
so, if this parameter was set on a union, openscad would go,
"hey, these two faces are pretty close (to within the
accuracy of floating-point precision) - let me just work out
the intersect space and EXTEND one of the objects INTO
the other AUTOMATICALLY for the user, so that they don't
have to do that themselves in a non-standard, tiresome,
laborious, code-complicating and code-untidy way".
one last thing: i noted from discussions on debian bugs that there has
been a decision made to track the highly-unstable libqt5. code has
been specifically added to take into account severe useability
flaws inherent in libqt5 that render openscad completely and
utterly unusable. given that it was possible to simply recompile the
entire [latest] codebase to use libqt4, and a significant speed-increase
was noted when doing so (over the previous stable debian version
of openscad), i can only ask why the developers would effectively
poison the openscad codebase with fatally-flawed workarounds
to use completely-non-production-ready code from a third party?
surely it would make far more sense to make a bugreport to those
third party developers, and say "hey guys, libqt5 is just not ready
for production, we're not going to use it, here's a full detailed
report including repro-code instructions, go fix it, we'll use libqt5
only when it's ready".
in essence, other people's problem code isn't your responsibility,
so why make life difficult for yourself and the sorts of end-users
who don't have the ability to compile or modify code [i say this
to deliberately exclude myself from this question, as i can
both modify and compile up code].
that's basically it - i believe that's everything from the
[near-full-time]
use of openscad for the past 15 months. you're welcome to listen
or not to anything i've said above: i am perfectly happy with the
setup that i have. if you'd like to follow what i'm doing or take a
look at the results, details are here:
https://www.youmagine.com/designs/libre-hardware-licensed-parametric-laptop-design
and, once things get up-and-running financially, i promise i'll make
sure you get some financial compensation. like many software
libre developers who have done key strategic work and not been
in the slightest bit adequately financially rewarded, i recognise
keenly the importance of financially rewarding people for the
service that they provide... despite the fact that libre software
licenses actively prohibit the usual well-recognised method of
compensation: sale of goods/services.
l.
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/insights-for-openscad-and-pyopenscad-from-the-libre-15-6in-laptop-project-tp16150p16245.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Julia Longtin isn't the original author of ImplicitCAD. Credit should go to
Christopher Olah, who wrote it in 2011. Julia's contribution, while
important, is AFAIK some much needed bug fixing and maintenance during
2014-2015.
On 25 February 2016 at 17:10, MichaelAtOz oz.at.michael@gmail.com wrote:
Hmmm. Where to start.
Firstly, if you haven't subscribed yet, Your post is still flagged as "This
post has NOT been accepted by the mailing list yet", so nobody gets it
unless they look.
You need to subscribe to the mailing list
http://forum.openscad.org/mailing_list/MailingListOptions.jtp?forum=1 ,
and respond to the registration email.
I'll quote the full OP below for those only on the mailing-list.
"however that the openscad language is not NP-complete" - that do you
mean
by that?
'btw in the vein of "stark simplicity", i noticed that the latest version
of openscad (which i couldn't use because of severe useability flaws
in the frame-rate rendering, due to known bugs in libqt5) has a toolbar.
PLEASE MAKE THIS OPTIONAL.' - View/Hide-Toolbars
"my recommendation to you therefore would be to CUT the in-tool editor
entirely." There are many types and levels of OpenSCAD users (and operating
systems used). I don't think not having an editor would be helpful to many.
IMO
Others may have something to comment on below.
lkcl wrote
hi folks,
i just wanted to let you - especially the developers - know that i've
been
using openscad (and something called pyopenscad) for the past fifteen
months to develop an extremely complex GPLv3+ project containing over
35 separate parts: a libre 15.6in laptop. the source code is currently
almost five THOUSAND lines long (excluding support libraries).
to say that i am extremely grateful that openscad exists would be a
huge understatement. i am a big fan of simplicity (zero cruft) and
high bang-per-buck ratio tools. i tried mm3d once, and stopped
after manually adding 2,500 points by hand with a mouse. that
experience was enough of a stark contrast to make me deeply
appreciate the power of parametric design.
so after fifteen months of near-continuous use i have some insights
that i'd like to share with you.
the key critical advantage of being able to use a text-based parametric
design i find is that i can use git revision control. i recently needed
to
revert a modification involving magnetic catches in the lid, and it was
a simple matter of "git log | grep -10 magnet" to find out what i had
done, because i am regularly committing with descriptive comments for
exactly this purpose.
the key critical advantage of using pyopenscad is however that the
openscad language is not NP-complete, and i can neither recommend
to the developers that they even remotely contemplate making the
openscad language NP-complete (why would you ever want to both
create and maintain an obscure programming language when there
exist perfectly good ones already?), nor, even if the openscad language
were made NP-complete would i ever consider using it directly.
the reason: python is a well-known, extremely comprehensive language
with object-orientated features. i use it because it's easier to do so.
now, in an earlier incarnation of my programming history i would have
advocated or suggested adding language bindings to openscad, but
honestly, i feel that the openscad language itself - when combined
with language translators (such as pyopenscad) is perfectly suited to
the task. pyopenscad is "another tool based on the unix principle",
whilst openscad is likewise, and the same with python.
... why make openscad complex? the moment you add language
bindings for python, the .NET developers will want one too. and perl.
and everyone else, and that just opens the floodgates and you'll be
making language bindings forever instead of focussing on improving
openscad.
btw in the vein of "stark simplicity", i noticed that the latest version
of openscad (which i couldn't use because of severe useability flaws
in the frame-rate rendering, due to known bugs in libqt5) has a toolbar.
PLEASE MAKE THIS OPTIONAL. screen real-estate is critical to me,
and there is literally nothing on the toolbar that i need or will need...
EVER. i use a single-key vim macro to run the python program that
auto-generates the openscad output; this in turn triggers openscad
to reload that output and automatically generate the render. following
that, i can press F6, and if the CGAL looks good i can export to STL.
there is ZERO need in this scenario for an in-tool editor (nothing beats
vim or emacs or the end-user's editor of choice: i'm curious to know
why openscad even has a built-in editor at all - it breaks the unix
principle "do one thing and do it well"). example: you're never going
to duplicate the vim "colour syntax highlighting" capabilities, and even
if you do they will never be as good (or as customisable) as vim. even
if you did duplicate the full set of vim "colour syntax highlighting"
which is so advantageous an aid to programming, you would now be
vim contributors... not openscad developers. my recommendation to
you therefore would be to CUT the in-tool editor entirely. make it
a completely separate program in order to keep people happy who
currently use it... but advise them that it has become a "non-maintained"
external tool that will be deprecated within the next 18-24 months.
there is also zero need (except when there are CGAL "invalid manifold"
errors) for the console - i hide that. likewise, i notice the addition
of a tree-view in the latest version. whilst i can see its potential for
small-scale objects (especially if combined for example with object
highlighting, which i have to say would be incredibly useful even
and especially with massively-complex objects), again it is something
that, for the most part, just takes up screen real-estate. so it too
is gone: off.
basically i would be happy if there was literally no menu, that there
was pretty much a single window, and for accessing the menu the
only way to do so was by right-mouse context-menu. given that
scroll-wheel equals the same functionality as middle-wheel
press-and-drag, and dual left-and-right button is the same as
left-button, there is room here to jig things around, move the entire
menu onto right-mouse button, and save some screen real-estate.
honestly, though, the size of the menus (and the status bar),
UNLIKE the new toolbar, are small enough in font size that they are
really no bother, and the change in UI expectations is a definite
barrier. the new toolbar however, as it uses massively oversized
icons, HAS TO GO. if i absolutely have to upgrade any time soon,
i will actually download the source, hack the toolbar OUT, and use
a modified self-maintained version, it's that serious an impediment
to useability.
on the subject of focussing your efforts to make specialist "do one
thing and do it well" style improvements to the actual core function
of what openscad does, i would recommend looking up the reasons
why julia longtin completely reimplemented openscad in haskell.
the two key reasons are: to add an automatic "rounding corners"
feature to union and intersection (by way of a parameter). this
extra parameter basically caused special (spherical at corners,
cylindrical at edges) "fuzzing" joins that save a vast amount of
futzing about, as well as make parts that properly fit together,
and make 3D-printing of parts come out without the usual
"blobbing" at corners. 3D print-heads do not turn right-angles
on a dime, so it is necessary to add "curvature". julia made it
unnnbelievably simple to do that: add a cube to a union with
the "rounding" parameter set to exactly how much curvature you'd
like, and... job's done: the cube comes out with rounded edges
and corners. this turns out to be really critical when doing
lostPLA aluminium casting [which is what julia's doing, and is the
whole reason why she rewrote openscad in haskell].
second thing: when two objects are mathematically exactly lined up
and touching, openscad (actually probably libCGAL) sometimes
decides that the objects are separate, and sometimes decides that
they are one object. the fact that there is indecision is itself
the problem. it's critical that openscad decide to be one or the
other, not either. honestly i feel that you should either generate
a compile error or decide to bite the bullet and fix this one (as it's
"core functionality"). forcing users to make their openscad
source code that much more complex - by forcing them to add in
"overlap" - isn't a nice thing to do to them! even adding an extra
parameter to union and intersect etc. to say "these two objects
are definitely, definitely part of the same one object, ALTER THE
OBJECT to make ABSOLUTELY sure that's the case, or if you
genuinely can't programmatically work out what faces are actually
touching, to within a reasonable (and very very small) margin,
throw a compile error".
personally i would set this parameter to default to "True" and i
would strongly recommend that it be set to "True" on union (etc.)
but even if you didn't, because i am using pyopenscad i could
get pyopenscad to auto-generate scad files that override
whatever default behaviour you chose.
so, if this parameter was set on a union, openscad would go,
"hey, these two faces are pretty close (to within the
accuracy of floating-point precision) - let me just work out
the intersect space and EXTEND one of the objects INTO
the other AUTOMATICALLY for the user, so that they don't
have to do that themselves in a non-standard, tiresome,
laborious, code-complicating and code-untidy way".
one last thing: i noted from discussions on debian bugs that there has
been a decision made to track the highly-unstable libqt5. code has
been specifically added to take into account severe useability
flaws inherent in libqt5 that render openscad completely and
utterly unusable. given that it was possible to simply recompile the
entire [latest] codebase to use libqt4, and a significant speed-increase
was noted when doing so (over the previous stable debian version
of openscad), i can only ask why the developers would effectively
poison the openscad codebase with fatally-flawed workarounds
to use completely-non-production-ready code from a third party?
surely it would make far more sense to make a bugreport to those
third party developers, and say "hey guys, libqt5 is just not ready
for production, we're not going to use it, here's a full detailed
report including repro-code instructions, go fix it, we'll use libqt5
only when it's ready".
in essence, other people's problem code isn't your responsibility,
so why make life difficult for yourself and the sorts of end-users
who don't have the ability to compile or modify code [i say this
to deliberately exclude myself from this question, as i can
both modify and compile up code].
that's basically it - i believe that's everything from the
[near-full-time]
use of openscad for the past 15 months. you're welcome to listen
or not to anything i've said above: i am perfectly happy with the
setup that i have. if you'd like to follow what i'm doing or take a
look at the results, details are here:
and, once things get up-and-running financially, i promise i'll make
sure you get some financial compensation. like many software
libre developers who have done key strategic work and not been
in the slightest bit adequately financially rewarded, i recognise
keenly the importance of financially rewarding people for the
service that they provide... despite the fact that libre software
licenses actively prohibit the usual well-recognised method of
compensation: sale of goods/services.
l.
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the
Public Domain; to the extent possible under law, I have waived all
copyright and related or neighbouring rights to this work. Obviously
inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it!
http://www.ourfairdeal.org/ time is running out!
View this message in context:
http://forum.openscad.org/insights-for-openscad-and-pyopenscad-from-the-libre-15-6in-laptop-project-tp16150p16245.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org