Hello, everyone. I've just created a pull request for export() function - lt was strange for me that a language has import() and doesn't have an export() operation, although it's available from GUI. So, I've extended export.cc module to make it support calls for export(file="test.dxf") ....; Example: export(file="testcube.dxf") projection(cut=true) translate([0,0,-1]) cube([2,2,2]); There is a pull request on github on this topic - https://github.com/openscad/openscad/pull/1534 -- View this message in context: http://forum.openscad.org/export-function-tp15428.html Sent from the OpenSCAD mailing list archive at Nabble.com.

Hello, I asked for such a functionality in a previous thread. Now only a "function" to check for the existence of a file is missing. Please note that the code I presented then did not intend to be exact, it was only to express an idea. And the idea was the capability of some automation from within the code to achieve a fluid view and manipulation of complex multi-part objects. Explaining briefly: rendering a multi-part complex object can make us loose many minutes if not hours every time we start an editing session. When we start assembling a multi-part object it happens frequently that some modules are not at the right positions or that we forgot some details, so we need to look to the object from several angles to understand better what to do. If not rendered the set is almost impossible to move or rotate on the view-port, the time lag is enormous. My solution would be: the modules that are important for the assembly would verify for a previously exported .stl file with the same name of the module. If the file exist then that part is imported, else the code would be compiled and exported as an .stl file. Since the code bellow is already possible, module ABC() { import("ABC.stl"); } ABC(); The only thing missing after having the export functionality working would be a function returning a flag signaling the existence of a file. I know it is possible to have a fluid view done from outside the script, even to have a second instance of OpenSCAD open with all stls imported, but it's not practical. It implies that the code is distributed into several files and somehow the feel of unity of the object weakens. Now with the OpenSCAD lexer presented by runsun (thank you runsun) for the SinWrite editor, we have already the facility to better navigate in a more "complex" code and we do not need to separate the code into several files if we are not planning for code reuse, for that I would build a library. I read this comment by doug.moen a few hours ago. "An export command with a file name argument permits a malicious OpenSCAD script to clobber any file in the file system for which it has write permissions. OpenSCAD is intentionally designed so that it isn't a general purpose language like Python, and it doesn't suffer from this kind of security issue." What if limiting the file name parameter to a couple of known pacific extensions? As I said in thread above I'm not a software guy nor an OpenSCAD expert and I'm not a native english speaker either, so please understand that. Happy new year jpmendes <http://forum.openscad.org/How-to-check-if-a-file-exist-Why-not-export-from-code-td14982.html#a14995> -- View this message in context: http://forum.openscad.org/export-function-tp15428p15437.html Sent from the OpenSCAD mailing list archive at Nabble.com.

On 01/03/2016 07:26 PM, jpmendes wrote: > My solution would be: the modules that are important for the assembly would > verify for a previously exported .stl file with the same name of the module. > If the file exist then that part is imported, else the code would be > compiled and exported as an .stl file. Since the code bellow is already > possible, > A persistent cache (I think there's already an issue on github for that) could solve this specific issue too and in a way that does not need much user interaction. Having scad code to check for files and then automatically use those will cause lots of headaches with outdated files that need to be updated manually. If you open the the scad file in two instances of OpenSCAD, funny things will happen and there might also be cross-platform issues. How is the difference between preview and render mode handled with export()? Will that always force the mesh generation and export the file on F5? How will that interact with animation? In essence, my totally personal opinion is that OpenSCAD itself should focus on the model description part and not try to become a general programming language. There's a huge amount of improvements possible for making the model generation easier and more powerful. Note that my view of model description includes (not yet available) markup to define such things a multiple objects from one script that could be exported in one step. But that would be a feature of the GUI, not the description language. ciao, Torsten.

In https://github.com/openscad/openscad/issues/1437 clothbot and I propose to add a persistent caching option to 'render'. This can address both jpmendes and Mihail's problem. If we add export *and* a function for testing file existence, then openscad starts to become a scripting language for automating file management workflow. The security problem becomes worse because now you can determine what operating system is running, by testing for the existence of system files, and now you know which files to clobber using 'export', for maximum damage. On Sunday, 3 January 2016, jpmendes <jpmendes54@gmail.com <javascript:_e(%7B%7D,'cvml','jpmendes54@gmail.com');>> wrote: > Hello, > > I asked for such a functionality in a previous thread. > Now only a "function" to check for the existence of a file is missing. > Please note that the code I presented then did not intend to be exact, it > was only to express an idea. > > And the idea was the capability of some automation from within the code to > achieve a fluid view and manipulation of complex multi-part objects. > Explaining briefly: rendering a multi-part complex object can make us loose > many minutes if not hours every time we start an editing session. When we > start assembling a multi-part object it happens frequently that some > modules > are not at the right positions or that we forgot some details, so we need > to > look to the object from several angles to understand better what to do. If > not rendered the set is almost impossible to move or rotate on the > view-port, the time lag is enormous. > My solution would be: the modules that are important for the assembly would > verify for a previously exported .stl file with the same name of the > module. > If the file exist then that part is imported, else the code would be > compiled and exported as an .stl file. Since the code bellow is already > possible, > > module ABC() { > import("ABC.stl"); > } > ABC(); > > The only thing missing after having the export functionality working would > be a function returning a flag signaling the existence of a file. > > I know it is possible to have a fluid view done from outside the script, > even to have a second instance of OpenSCAD open with all stls imported, but > it's not practical. It implies that the code is distributed into several > files and somehow the feel of unity of the object weakens. > Now with the OpenSCAD lexer presented by runsun (thank you runsun) for the > SinWrite editor, we have already the facility to better navigate in a more > "complex" code and we do not need to separate the code into several files > if we are not planning for code reuse, for that I would build a library. > > I read this comment by doug.moen a few hours ago. > > "An export command with a file name argument permits a malicious OpenSCAD > script to clobber any file in the file system for which it has write > permissions. OpenSCAD is intentionally designed so that it isn't a general > purpose language like Python, and it doesn't suffer from this kind of > security issue." > > What if limiting the file name parameter to a couple of known pacific > extensions? > > As I said in thread above I'm not a software guy nor an OpenSCAD expert and > I'm not a native english speaker either, so please understand that. > > Happy new year > > jpmendes > < > http://forum.openscad.org/How-to-check-if-a-file-exist-Why-not-export-from-code-td14982.html#a14995 > > > > > > -- > View this message in context: > http://forum.openscad.org/export-function-tp15428p15437.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 > > >

Yes persistent caching gets my vote as there are no changes to the language, it just gets faster. To export multiple objects from my files I simply call them something_stl(). I have a python script that finds them and invokes the command line to export them. That would also get much faster with a persistent cache. On 3 January 2016 at 20:26, doug moen <doug@moens.org> wrote: > In https://github.com/openscad/openscad/issues/1437 clothbot and I > propose to add a persistent caching option to 'render'. This can address > both jpmendes and Mihail's problem. > > If we add export *and* a function for testing file existence, then > openscad starts to become a scripting language for automating file > management workflow. The security problem becomes worse because now you can > determine what operating system is running, by testing for the existence of > system files, and now you know which files to clobber using 'export', for > maximum damage. > > On Sunday, 3 January 2016, jpmendes <jpmendes54@gmail.com> wrote: > >> Hello, >> >> I asked for such a functionality in a previous thread. >> Now only a "function" to check for the existence of a file is missing. >> Please note that the code I presented then did not intend to be exact, it >> was only to express an idea. >> >> And the idea was the capability of some automation from within the code to >> achieve a fluid view and manipulation of complex multi-part objects. >> Explaining briefly: rendering a multi-part complex object can make us >> loose >> many minutes if not hours every time we start an editing session. When we >> start assembling a multi-part object it happens frequently that some >> modules >> are not at the right positions or that we forgot some details, so we need >> to >> look to the object from several angles to understand better what to do. If >> not rendered the set is almost impossible to move or rotate on the >> view-port, the time lag is enormous. >> My solution would be: the modules that are important for the assembly >> would >> verify for a previously exported .stl file with the same name of the >> module. >> If the file exist then that part is imported, else the code would be >> compiled and exported as an .stl file. Since the code bellow is already >> possible, >> >> module ABC() { >> import("ABC.stl"); >> } >> ABC(); >> >> The only thing missing after having the export functionality working >> would >> be a function returning a flag signaling the existence of a file. >> >> I know it is possible to have a fluid view done from outside the script, >> even to have a second instance of OpenSCAD open with all stls imported, >> but >> it's not practical. It implies that the code is distributed into several >> files and somehow the feel of unity of the object weakens. >> Now with the OpenSCAD lexer presented by runsun (thank you runsun) for the >> SinWrite editor, we have already the facility to better navigate in a more >> "complex" code and we do not need to separate the code into several files >> if we are not planning for code reuse, for that I would build a library. >> >> I read this comment by doug.moen a few hours ago. >> >> "An export command with a file name argument permits a malicious OpenSCAD >> script to clobber any file in the file system for which it has write >> permissions. OpenSCAD is intentionally designed so that it isn't a general >> purpose language like Python, and it doesn't suffer from this kind of >> security issue." >> >> What if limiting the file name parameter to a couple of known pacific >> extensions? >> >> As I said in thread above I'm not a software guy nor an OpenSCAD expert >> and >> I'm not a native english speaker either, so please understand that. >> >> Happy new year >> >> jpmendes >> < >> http://forum.openscad.org/How-to-check-if-a-file-exist-Why-not-export-from-code-td14982.html#a14995 >> > >> >> >> >> -- >> View this message in context: >> http://forum.openscad.org/export-function-tp15428p15437.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 >> >> >> > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

May be it's safe enought to permit only files with names, derived from original script name. 3 янв. 2016 г. 11:40 PM пользователь "nop head" <nop.head@gmail.com> написал: > Yes persistent caching gets my vote as there are no changes to the > language, it just gets faster. > > To export multiple objects from my files I simply call them > something_stl(). I have a python script that finds them and invokes the > command line to export them. That would also get much faster with a > persistent cache. > > On 3 January 2016 at 20:26, doug moen <doug@moens.org> wrote: > >> In https://github.com/openscad/openscad/issues/1437 clothbot and I >> propose to add a persistent caching option to 'render'. This can address >> both jpmendes and Mihail's problem. >> >> If we add export *and* a function for testing file existence, then >> openscad starts to become a scripting language for automating file >> management workflow. The security problem becomes worse because now you can >> determine what operating system is running, by testing for the existence of >> system files, and now you know which files to clobber using 'export', for >> maximum damage. >> >> On Sunday, 3 January 2016, jpmendes <jpmendes54@gmail.com> wrote: >> >>> Hello, >>> >>> I asked for such a functionality in a previous thread. >>> Now only a "function" to check for the existence of a file is missing. >>> Please note that the code I presented then did not intend to be exact, it >>> was only to express an idea. >>> >>> And the idea was the capability of some automation from within the code >>> to >>> achieve a fluid view and manipulation of complex multi-part objects. >>> Explaining briefly: rendering a multi-part complex object can make us >>> loose >>> many minutes if not hours every time we start an editing session. When we >>> start assembling a multi-part object it happens frequently that some >>> modules >>> are not at the right positions or that we forgot some details, so we >>> need to >>> look to the object from several angles to understand better what to do. >>> If >>> not rendered the set is almost impossible to move or rotate on the >>> view-port, the time lag is enormous. >>> My solution would be: the modules that are important for the assembly >>> would >>> verify for a previously exported .stl file with the same name of the >>> module. >>> If the file exist then that part is imported, else the code would be >>> compiled and exported as an .stl file. Since the code bellow is already >>> possible, >>> >>> module ABC() { >>> import("ABC.stl"); >>> } >>> ABC(); >>> >>> The only thing missing after having the export functionality working >>> would >>> be a function returning a flag signaling the existence of a file. >>> >>> I know it is possible to have a fluid view done from outside the script, >>> even to have a second instance of OpenSCAD open with all stls imported, >>> but >>> it's not practical. It implies that the code is distributed into several >>> files and somehow the feel of unity of the object weakens. >>> Now with the OpenSCAD lexer presented by runsun (thank you runsun) for >>> the >>> SinWrite editor, we have already the facility to better navigate in a >>> more >>> "complex" code and we do not need to separate the code into several >>> files >>> if we are not planning for code reuse, for that I would build a library. >>> >>> I read this comment by doug.moen a few hours ago. >>> >>> "An export command with a file name argument permits a malicious OpenSCAD >>> script to clobber any file in the file system for which it has write >>> permissions. OpenSCAD is intentionally designed so that it isn't a >>> general >>> purpose language like Python, and it doesn't suffer from this kind of >>> security issue." >>> >>> What if limiting the file name parameter to a couple of known pacific >>> extensions? >>> >>> As I said in thread above I'm not a software guy nor an OpenSCAD expert >>> and >>> I'm not a native english speaker either, so please understand that. >>> >>> Happy new year >>> >>> jpmendes >>> < >>> http://forum.openscad.org/How-to-check-if-a-file-exist-Why-not-export-from-code-td14982.html#a14995 >>> > >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.openscad.org/export-function-tp15428p15437.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 >>> >>> >>> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

Hello, For me persistent cache is welcome as I seldom make complex multi-part objects. For the guys tackling several projects a time it can be very hard disk consuming. However with the limitation of the names and extensions of the exports, and placing the exported files inside the project directory, I cannot figure out where could be risk for malware propagation. For the guys not wanting to use the export functionality the language would not be different. And what if we had a GUI more like an IDE with a project tree, where the files could be added from other project dirs and made available locally, and all (except calls to libraries) would be kept under the project directory? jpmendes -- View this message in context: http://forum.openscad.org/export-function-tp15428p15448.html Sent from the OpenSCAD mailing list archive at Nabble.com.

On Sun, 3 Jan 2016 14:59:13 -0700 (MST) jpmendes <jpmendes54@gmail.com> wrote: > Hello, > > For me persistent cache is welcome as I seldom make complex multi-part > objects. For the guys tackling > several projects a time it can be very hard disk consuming. Its usually going to be smaller and easier to manage than having loads of saved export files you have to keep remembering to clean up by hand. It's a model that works well and has a very simple interface ("Size ?"). All the web browsers use it for example. Alan

I pray for the persistent cache location to be user defined. Please!!! jpmendes -- View this message in context: http://forum.openscad.org/export-function-tp15428p15455.html Sent from the OpenSCAD mailing list archive at Nabble.com.

On 01/04/2016 01:30 AM, jpmendes wrote: > I pray for the persistent cache location to be user defined. Please!!! > One option would be the use of memcached, in that case OpenSCAD would not specify a path for the actual storage. ciao, Torsten.