Feature Requests

Hello,

First i have to say, that openscad is a really good cad tool if you come
from the programmers side, i love it :-)

But while using it, it noticed a few things which are missing for me.
- a square root function.
- else clauses.
- a way to modify variables in if clauses.
- better editor, or a way to integrate openscad into other editors, so
you can get syntacs highlighting and other common features.

Also the way you have to use assign() to get local variables in a loop
seems strange. Couldnt that be done more similar to C ?

would be very nice if some of this could be improved.

thanks for all your good work,
Dominik Wenger

Hey Dominik,

Square root is just "pow(someNumber,0.5)".

Andrew.

On 10-Feb-10, at 7:47 AM, Dominik Wenger wrote:

--

Makerbot Number Nine... #9... 0x09... 0o11... 0b1001...

On Feb 10, 2010, at 13:47 , Dominik Wenger wrote:

> - a square root function.

Added in subversion, will be there in the next snapshot build.

> - better editor, or a way to integrate openscad into other editors, so
> you can get syntacs highlighting and other common features.

We've been dicussing this, and so far it looks like the best way to go  
is to use an external editor and rather provide a way of communication  
with OpenSCAD from an external program.
In external editors, I use C syntax highlighting and autoindenting and  
it works ok in most cases.
In the development snapshot (for Mac OS X only), it's also possible to  
issue an AppleScript command 'tell application "OpenSCAD" to reload',  
from an external editor to ease the integration a bit. This is purely  
experimental though and might be removed/changed later on.

Alternatively, if there exist a god Qt-based source code editor which  
is easy to intergrate, we'll look into that. So far I've only looked  
at QCodeEdit, but that one is quite immature and don't have any  
development momentum atm.
In the meantime, if you have easy to implement feature request for the  
builtin editor, please post them and we might fix it.

> - else clauses.

I agree.

> - a way to modify variables in if clauses.
> Also the way you have to use assign() to get local variables in a loop
> seems strange. Couldnt that be done more similar to C ?
>
Not sure how easy this is due to the current parser design. Clifford?

~/= Marius

--
We are Elektropeople for a better living.

Hi,

On Wed, Feb 10, 2010 at 06:36:44PM +0100, Marius Kintel wrote:
> > - a way to modify variables in if clauses.
> > Also the way you have to use assign() to get local variables in a loop
> > seems strange. Couldnt that be done more similar to C ?
> >
> Not sure how easy this is due to the current parser design. Clifford?

support local variables, function and modules in every { } block is on the
todo list for a longer time now. unfortunately I hardly get time to read my
email atm - not talking about answering them or writing OpenSCAD code..

so don't hold your breath but it is somethiung that will be implemented
once I happen to have some time to spend on openscad again..

yours,
 - clifford

--
"... one of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination of
their C programs." - Robert Firth.

On Feb 10, 2010, at 13:47 , Dominik Wenger wrote:

> - else clauses.

This is now implemented and committed to subversion.

~/= Marius

--
We are Elektropeople for a better living.

I wonder if an Eclipse plug-in might be one way to go- that would give
a nice external editor withe capability for syntax highlighting, etc.
I would say emacs could do the same, but that would label me as
impossibly old-school...

-Mark

On Fri, Feb 12, 2010 at 8:21 AM, Marius Kintel <[hidden email]> wrote:


--
| R. Mark Adams, Ph.D.       |   "Information is light.      |
| Computational Biologist    |    Information in itself,     |
| http://www.epotential.com  |    about anything, is light." |
| [hidden email]     |       - Tom Stoppard          |

On Feb 12, 2010, at 19:19 , R. Mark Adams, PhD wrote:

> I wonder if an Eclipse plug-in [...] I would say emacs could do the  
> same [...]


I use Emacs for everything but Java, for which I use Eclipe ;)
I agree that external editors is the way to go.
I implemented an extremely quick and dirty AppleScript hack for  
reloading an externally edited file in OpenSCAD. It's very painful to  
implement this for Qt apps, so if there exist a multi-plaform way of  
talking to an (Qt) app from the outside, I'd be interested in any  
pointers.

~/= Marius

--
We are Elektropeople for a better living.

On Feb 13, 2010, at 00:08, Marius Kintel wrote:

On Unix operating systems (i.e. all except Windows), you could use a  
Unix domain socket in the user's home directory and send commands  
through this socket. I have code for that, if you want it.

In a more general environment (if you want the same code on all  
platforms), you could use a TCP or UDP socket on 127.0.0.1 for the  
communication. OpenSCAD would bind to a port where it listens and  
write the port number to a file in a well known location (e.g. the  
user's home).

I should have old code snippets for that, too...

It's even possible to cope with multiple instances of OpenSCAD running  
under the same user ID. Just append the PID to the file/socket name.  
The client library can then look for any file/socket or address a  
particular PID.

Ciao -- Christian.

--
DI Christian Starkjohann <[hidden email]>
OBJECTIVE DEVELOPMENT Software GmbH

I like the TCP socket idea- that would work great.  I have to admit that
what I had in mind was also the Unix domain socket- since I use Linux
and OSX, it would work for both, but I was missing the Windows
interoperability.

As for integrating Eclipse, here is a pointer to a good description of
how to integrate new programming languages like OpenSCAD into the
Eclipse platform:

http://www.informit.com/articles/article.aspx?p=370625

I have not done it before, but I am going to hack around a bit to see if
I can get at least the first couple layers working...

Thanks!
-Mark

Christian Starkjohann wrote:
--
| R. Mark Adams, Ph.D.       |   "Information is light.      |
| Computational Biologist    |    Information in itself,     |
| http://www.epotential.com  |    about anything, is light." |
| [hidden email]     |       - Tom Stoppard          |

On Sat, Feb 13, 2010 at 3:08 PM, Christian Starkjohann <[hidden email]> wrote:

> I should have old code snippets for that, too...

Or you can simply watch a particular dir from openscad.
Like /home/user/.config/openscad/commands_to_execute/X

Where X is a number.

And you simply write a new file containing the commands.
Once openscad discovers it has a new file in the dir, it executes it,
and delete.
You can even implement a queue mechanism.

On linux there is a kernel support to discover file changes, so no need to poll
every second.

I think it is the easiest solution. And it is very scriptable
friendly. Even a bash
script can control openscad.

Best regards,
 Laszlo

Hi,

On Sun, Feb 14, 2010 at 04:56:03AM +0100, Laszlo KREKACS wrote:
> Or you can simply watch a particular dir from openscad.
> Like /home/user/.config/openscad/commands_to_execute/X
>
> ...
>
> On linux there is a kernel support to discover file changes, so no need
> to poll every second.

btw: windows and mac osx also have APIs for this:
FileSystemWatcher (Win32) and FSEvents (OSX)

> I think it is the easiest solution. And it is very scriptable
> friendly. Even a bash script can control openscad.

its a bit hackish but I like it because of its simplicity..

as long as there is no need to read back information from openscad this
sounds like a good solution for me.

yours,
 - clifford

--
"The generation of random numbers is too important to be left to chance."
 - Robert R. Coveyou, Oak Ridge National Laboratory.

On Sun, Feb 14, 2010 at 10:29:49AM +0100, Clifford Wolf wrote:
A mechanism like this needs a staging directory -- where the command
file is written and then moved to the final directory watched by the
consuming program (openscad). Otherwise you have a race-condition: The
program still writing the file may not yet be ready when the file is
already consumed by openscad. Given this complication I'd vote for a TCP
connection, this can also return results to the calling process.

Creating a simple command-line utility that can be used in shellscripts
for sending commands to openscad would make that method equally easy to
use.

Ralf
--
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  Fax:   +43/2243/26465-23
Reichergasse 131                        www:   http://www.runtux.com
A-3411 Weidling                         email: [hidden email]
osAlliance member                       email: [hidden email]

On Sun, Feb 14, 2010 at 10:29 AM, Clifford Wolf <[hidden email]> wrote:
> as long as there is no need to read back information from openscad this
> sounds like a good solution for me.

Read back information is not a problem. As we can output the result as
input_filename_RESULT.txt

The real problem starts, when we need back and forth communicate.

Best regards,
 Laszlo

There are a few separate components to this.

1) The commands/queries we want to send to OpenSCAD are not  
(primarily) OpenSCAD commands, but application/GUI controls; opening/
saving files, reloading, render, export, edit text. Since OpenSCAD  
either can have multiple open documents or multiple instances  
(depending on whether the user prefers MDI mode or not), we also need  
to be able to query/select the correct document/window/instance.
-> We need to expose some kind of DOM for the application.

2) We need a transport mechanism for sending these commands/queries to  
OpenSCAD. Domain sockets, TCP sockets, file monitoring has been  
mentioned as alternatives. On Mac, this is standardized using  
AppleEvents, which is a good solution for Mac since we can plug this  
directly into any other scripting framework already existing. For  
Windows and Linux I don't know about standardized ways of doing this.  
The MDI/pid case also complicates this.
-> It could make sense to decouple 1) from 2)

3) We might want a scripting language for sending the commands/queries  
in 1) over the transport in 2). bash was mentioned as an option. The  
questions is also whether we can keep the interpreter external or if  
we need to embed it into OpenSCAD. For the file monitoring solution,  
we probably need to embed. For the others, we could define some kind  
of text-based API and resolve the logic externally.

We could take a look at QtScript. It's included in Qt since Qt-4.3 and  
could be helpful in solving 1) and 3). It doesn't appear to target  
remote control of apps though.

Cheers,

~/= Marius

--
We are Elektropeople for a better living.

On Sun, Feb 14, 2010 at 03:42:11PM +0100, Marius Kintel wrote:
On Linux this is probably dbus. Whole applications are using this, e.g.
the farsight/telepathy framework for doing instant messaging and VoIP.
With that interface you can write a VoIP client that only uses services
via dbus.
But do you really want to go the route of having a different platform
specific communication mechanism for each architecture?

Ralf

--
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  Fax:   +43/2243/26465-23
Reichergasse 131                        www:   http://www.runtux.com
A-3411 Weidling                         email: [hidden email]
osAlliance member                       email: [hidden email]

On Feb 14, 2010, at 17:35 , Ralf Schlatterbeck wrote:

> On Linux this is probably dbus.
Qt offers some dbus support: http://doc.trolltech.com/4.6/qtdbus.html

> But do you really want to go the route of having a different platform
> specific communication mechanism for each architecture?
>
Applications are there to serve users, not the other way around, so  
yes, I believe this is in the interest of the users. It might very  
well triple the effort though, so I'd be happy with a (generic) multi-
platform fallback, hopefully with a design which opens up for platform-
tailored implementations.

Otoh, doing proper multi-platforms GUI's are not really feasible  
without using native GUI toolkits, but that's another story...

~/= Marius

--
We are Elektropeople for a better living.

On Feb 14, 2010, at 18:14, Marius Kintel wrote:


We are talking about the technical implementation, not user  
experience. [User experience is already broken when you use a cross  
platform GUI toolkit :-)]

Personally, I very much prefer to have the SAME code running on every  
platform. This saves me most of the testing on multiple platforms.

 From a previous mail:
> 3) We might want a scripting language for sending the commands/queries
> in 1) over the transport in 2). bash was mentioned as an option. The

I doubt we really need this. It's sufficient to send simple RPC  
commands to the server (OpenSCAD application). You need to define a  
method to name objects (application instances, windows etc.), though.  
I think the easiest would be to refer to application windows via the  
main source file. Commands could be sent to ALL OpenSCAD instances and  
the one which has the file open would interpret them, the others  
ignore them.

As far as transport is concerned, I would vote for TCP. It's most  
extensible, even cross-machine scripting would be possible. We could  
have a client library and a command line tool to send the RPC requests.

--
DI Christian Starkjohann <[hidden email]>
OBJECTIVE DEVELOPMENT Software GmbH

On Sun, 14 Feb 2010 15:42 +0100, "Marius Kintel" <[hidden email]>
wrote:
I'd vote for a text-based API of some sort.  Ideally with a really
simple consistent mapping from the interactive commands (which the user
learns first) to the corresponding script commands.  There should
definitely be an easy obvious way to send commands to openscad from bash
whether by invoking 'openscad --client' or writing to a pipe or socket.
This is how a person looking to do quick integration with their favorite
editor is going to want to do it.

It wouldn't be a tragedy to have script command "F4" mean "do what
happens when you press F4 in openscad".  This is how vim scripting
mostly works and it turns out to be sooo much easier than emacs (which I
used to program *a lot*) where you have to root around constantly to
find the underlying lisp API that you're actually supposed to use to do
something programmatically.

Let users learn first interactively then ditch the clunky mouse without
the trouble of learning a new API.

Britton