openscad.isRender()
 openscad.isPreview()

 and later...

 env.platform()
 env.date()

I'll vote for $render, since I think this variable is not so different from $t and others. The implementation will need a way to determine if $render is referenced by the code, since it (allegedly) affects caching. With $render, the information is available early, at parse time, before the script is evaluated. If the information is referenced by passing a run time value to the system() function, then the information might not be available until after script evaluation is complete. (I'm assuming that there could be multiple strings you can pass to system(), and not all of them have an impact on caching.) So the choice of syntax puts constraints on the caching implementation. I'm voting for $render because it places the fewest constraints on the implementation. I'm also thinking about what constraints we may be placing on future implementations, since the caching implementation could change. It's also the simplest design. See also what Nop Head says about inventing a whole new syntax for such a simple feature. On 9 January 2016 at 18:57, MichaelAtOz <oz.at.michael@gmail.com> wrote: > I'd go with a built-in function, > > var = system("render"); // boolean - in this case > > Initial set of options; > "preview" boolean > "render" boolean > "mainfilename" string > "datetime" string, YYYYMMDDHHMMSSmmd, mm=millisec, d=0-6 (day of week) > "GUI" boolean - false if command line > > I was going to suggest the following, but that is too late, the compiling > has been done. Unless an auto-rerender concept...?? > "export" [ returns the export type, > "STL","OFF","AMF","DXF","SVG","CSG","PNG"] > > Note other discussion here > <https://github.com/openscad/openscad/issues/907> , some idiot ;) > suggested; > > openscad.isRender() > openscad.isPreview() > > and later... > > env.platform() > env.date() > > So perhaps > > var=openscad.system(as per above); > > You don't need a separate env > > > > > > ----- > Newly minted 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/Variable-for-render-mode-tp5340p15604.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.isRender()
 openscad.isPreview()

 and later...

 env.platform()
 env.date()

Can you explain what the issue with caching is please? How is a variable that aromatically changes once at the start of a preview / render a problem compared to me manually changing it or $t which is also a variable that changes automatically. On 10 January 2016 at 00:36, doug moen <doug@moens.org> wrote: > I'll vote for $render, since I think this variable is not so different > from $t and others. > > The implementation will need a way to determine if $render is referenced > by the code, since it (allegedly) affects caching. With $render, the > information is available early, at parse time, before the script is > evaluated. If the information is referenced by passing a run time value to > the system() function, then the information might not be available until > after script evaluation is complete. (I'm assuming that there could be > multiple strings you can pass to system(), and not all of them have an > impact on caching.) So the choice of syntax puts constraints on the caching > implementation. I'm voting for $render because it places the fewest > constraints on the implementation. I'm also thinking about what constraints > we may be placing on future implementations, since the caching > implementation could change. > > It's also the simplest design. See also what Nop Head says about inventing > a whole new syntax for such a simple feature. > > On 9 January 2016 at 18:57, MichaelAtOz <oz.at.michael@gmail.com> wrote: > >> I'd go with a built-in function, >> >> var = system("render"); // boolean - in this case >> >> Initial set of options; >> "preview" boolean >> "render" boolean >> "mainfilename" string >> "datetime" string, YYYYMMDDHHMMSSmmd, mm=millisec, d=0-6 (day of week) >> "GUI" boolean - false if command line >> >> I was going to suggest the following, but that is too late, the compiling >> has been done. Unless an auto-rerender concept...?? >> "export" [ returns the export type, >> "STL","OFF","AMF","DXF","SVG","CSG","PNG"] >> >> Note other discussion here >> <https://github.com/openscad/openscad/issues/907> , some idiot ;) >> suggested; >> >> openscad.isRender() >> openscad.isPreview() >> >> and later... >> >> env.platform() >> env.date() >> >> So perhaps >> >> var=openscad.system(as per above); >> >> You don't need a separate env >> >> >> >> >> >> ----- >> Newly minted 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/Variable-for-render-mode-tp5340p15604.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.isRender()
 openscad.isPreview()

 and later...

 env.platform()
 env.date()

No idea where "aromatically" came from! On 10 January 2016 at 07:39, nop head <nop.head@gmail.com> wrote: > Can you explain what the issue with caching is please? How is a variable > that aromatically changes once at the start of a preview / render a problem > compared to me manually changing it or $t which is also a variable that > changes automatically. > > On 10 January 2016 at 00:36, doug moen <doug@moens.org> wrote: > >> I'll vote for $render, since I think this variable is not so different >> from $t and others. >> >> The implementation will need a way to determine if $render is referenced >> by the code, since it (allegedly) affects caching. With $render, the >> information is available early, at parse time, before the script is >> evaluated. If the information is referenced by passing a run time value to >> the system() function, then the information might not be available until >> after script evaluation is complete. (I'm assuming that there could be >> multiple strings you can pass to system(), and not all of them have an >> impact on caching.) So the choice of syntax puts constraints on the caching >> implementation. I'm voting for $render because it places the fewest >> constraints on the implementation. I'm also thinking about what constraints >> we may be placing on future implementations, since the caching >> implementation could change. >> >> It's also the simplest design. See also what Nop Head says about >> inventing a whole new syntax for such a simple feature. >> >> On 9 January 2016 at 18:57, MichaelAtOz <oz.at.michael@gmail.com> wrote: >> >>> I'd go with a built-in function, >>> >>> var = system("render"); // boolean - in this case >>> >>> Initial set of options; >>> "preview" boolean >>> "render" boolean >>> "mainfilename" string >>> "datetime" string, YYYYMMDDHHMMSSmmd, mm=millisec, d=0-6 (day of week) >>> "GUI" boolean - false if command line >>> >>> I was going to suggest the following, but that is too late, the compiling >>> has been done. Unless an auto-rerender concept...?? >>> "export" [ returns the export type, >>> "STL","OFF","AMF","DXF","SVG","CSG","PNG"] >>> >>> Note other discussion here >>> <https://github.com/openscad/openscad/issues/907> , some idiot ;) >>> suggested; >>> >>> openscad.isRender() >>> openscad.isPreview() >>> >>> and later... >>> >>> env.platform() >>> env.date() >>> >>> So perhaps >>> >>> var=openscad.system(as per above); >>> >>> You don't need a separate env >>> >>> >>> >>> >>> >>> ----- >>> Newly minted 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/Variable-for-render-mode-tp5340p15604.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 >> >> >

nophead wrote > "aromatically" Smells like sh---...garbage... ----- Newly minted 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/Variable-for-render-mode-tp5340p15617.html Sent from the OpenSCAD mailing list archive at Nabble.com.

 openscad.isRender()
 openscad.isPreview()

 and later...

 env.platform()
 env.date()

If the variable aromatically changes, then the problem is code smell. On Sunday, 10 January 2016, nop head <nop.head@gmail.com> wrote: > Can you explain what the issue with caching is please? How is a variable > that aromatically changes once at the start of a preview / render a problem > compared to me manually changing it or $t which is also a variable that > changes automatically. > > On 10 January 2016 at 00:36, doug moen <doug@moens.org > <javascript:_e(%7B%7D,'cvml','doug@moens.org');>> wrote: > >> I'll vote for $render, since I think this variable is not so different >> from $t and others. >> >> The implementation will need a way to determine if $render is referenced >> by the code, since it (allegedly) affects caching. With $render, the >> information is available early, at parse time, before the script is >> evaluated. If the information is referenced by passing a run time value to >> the system() function, then the information might not be available until >> after script evaluation is complete. (I'm assuming that there could be >> multiple strings you can pass to system(), and not all of them have an >> impact on caching.) So the choice of syntax puts constraints on the caching >> implementation. I'm voting for $render because it places the fewest >> constraints on the implementation. I'm also thinking about what constraints >> we may be placing on future implementations, since the caching >> implementation could change. >> >> It's also the simplest design. See also what Nop Head says about >> inventing a whole new syntax for such a simple feature. >> >> On 9 January 2016 at 18:57, MichaelAtOz <oz.at.michael@gmail.com >> <javascript:_e(%7B%7D,'cvml','oz.at.michael@gmail.com');>> wrote: >> >>> I'd go with a built-in function, >>> >>> var = system("render"); // boolean - in this case >>> >>> Initial set of options; >>> "preview" boolean >>> "render" boolean >>> "mainfilename" string >>> "datetime" string, YYYYMMDDHHMMSSmmd, mm=millisec, d=0-6 (day of week) >>> "GUI" boolean - false if command line >>> >>> I was going to suggest the following, but that is too late, the compiling >>> has been done. Unless an auto-rerender concept...?? >>> "export" [ returns the export type, >>> "STL","OFF","AMF","DXF","SVG","CSG","PNG"] >>> >>> Note other discussion here >>> <https://github.com/openscad/openscad/issues/907> , some idiot ;) >>> suggested; >>> >>> openscad.isRender() >>> openscad.isPreview() >>> >>> and later... >>> >>> env.platform() >>> env.date() >>> >>> So perhaps >>> >>> var=openscad.system(as per above); >>> >>> You don't need a separate env >>> >>> >>> >>> >>> >>> ----- >>> Newly minted 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/Variable-for-render-mode-tp5340p15604.html >>> Sent from the OpenSCAD mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> >

On 01/10/2016 08:39 AM, nop head wrote: > Can you explain what the issue with caching is please? How > is a variable that aromatically changes once at the start > of a preview / render a problem compared to me manually > changing it or $t which is also a variable that changes > automatically. > No, as I said before, I'm not sure myself. However I can show an example where caching was broken, even when the user changes the scad script. When toying with a loft() module I did pass the function parameter to loft() via strings, so it looked like: https://gist.githubusercontent.com/t-paul/7171783/raw/loft-5.png function path(t) = [ 0, 0, 80 + 80 * cos(180 * t) ]; loft(path = "path") circle(1); Due to the cache key for the loft module only having the name of the function, it can't detect changes in the actual values returned. To fix that, the cache key for the module would also need to include the full function definition to pick up changes at this point of the script. Anyway, I've tried a simple way of injecting a $render variable. This is currently only working for GUI, it's a bit more complex to get it working for command line too, but I guess we do want this for command line too. Both $t and the $vpX variables are currently GUI-only features and are never set when running from command line. For now I don't see any issues. I'll talk to Marius and see if he can give some more insight into the concerns. ciao, Torsten.

If you want to set it from the command line you can presumably with -D. On 10 January 2016 at 16:14, Torsten Paul <Torsten.Paul@gmx.de> wrote: > On 01/10/2016 08:39 AM, nop head wrote: > > Can you explain what the issue with caching is please? How > > is a variable that aromatically changes once at the start > > of a preview / render a problem compared to me manually > > changing it or $t which is also a variable that changes > > automatically. > > > No, as I said before, I'm not sure myself. > > However I can show an example where caching was broken, > even when the user changes the scad script. > > When toying with a loft() module I did pass the function > parameter to loft() via strings, so it looked like: > > https://gist.githubusercontent.com/t-paul/7171783/raw/loft-5.png > > function path(t) = [ 0, 0, 80 + 80 * cos(180 * t) ]; > loft(path = "path") circle(1); > > Due to the cache key for the loft module only having the > name of the function, it can't detect changes in the actual > values returned. To fix that, the cache key for the module > would also need to include the full function definition to > pick up changes at this point of the script. > > Anyway, I've tried a simple way of injecting a $render > variable. This is currently only working for GUI, it's > a bit more complex to get it working for command line > too, but I guess we do want this for command line too. > Both $t and the $vpX variables are currently GUI-only > features and are never set when running from command > line. > > For now I don't see any issues. I'll talk to Marius and > see if he can give some more insight into the concerns. > > ciao, > Torsten. > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

On 01/10/2016 05:28 PM, nop head wrote: > If you want to set it from the command line you can > presumably with -D. > Sure, without additional safeguards, you can even set it in the script itself (unfortunately). Although at least for the PNG export there's a separate render mode setting, so I guess that should be considered. For STL export it's of cause always fixed to true. ciao, Torsten.

Yes it would make sense if it was set for everything except PNG. On 10 January 2016 at 16:32, Torsten Paul <Torsten.Paul@gmx.de> wrote: > On 01/10/2016 05:28 PM, nop head wrote: > > If you want to set it from the command line you can > > presumably with -D. > > > Sure, without additional safeguards, you can even set it > in the script itself (unfortunately). > > Although at least for the PNG export there's a separate > render mode setting, so I guess that should be considered. > For STL export it's of cause always fixed to true. > > ciao, > Torsten. > > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >