discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Re: [OpenSCAD] Variable for render mode

S
shadowwynd
Sat, Jan 9, 2016 3:03 AM

I agree that this would be a useful tool to have.  It would mean we could
code a "visual representation" (F5), and a "layout for 3D printing" that is
automatically generated on F6.

--
View this message in context: http://forum.openscad.org/Variable-for-render-mode-tp5340p15580.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

I agree that this would be a useful tool to have. It would mean we could code a "visual representation" (F5), and a "layout for 3D printing" that is automatically generated on F6. -- View this message in context: http://forum.openscad.org/Variable-for-render-mode-tp5340p15580.html Sent from the OpenSCAD mailing list archive at Nabble.com.
NH
nop head
Sat, Jan 9, 2016 10:14 AM

Yes that is exactly how I would use it.

When I press F5 I want this

And when I press F6 I want this


... without having to modify the file and remember to put it restore it
when I check it in. Accidentally pressing F6 with the assembly view
selected can bring my PC to its knees if it is a complicated assembly.
Novice uses trying to build Mendel90 often make this mistake.

On 9 January 2016 at 03:03, shadowwynd shadowwynd@gmail.com wrote:

I agree that this would be a useful tool to have.  It would mean we could
code a "visual representation" (F5), and a "layout for 3D printing" that is
automatically generated on F6.

--
View this message in context:
http://forum.openscad.org/Variable-for-render-mode-tp5340p15580.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 that is exactly how I would use it. When I press F5 I want this And when I press F6 I want this ​ ... without having to modify the file and remember to put it restore it when I check it in. Accidentally pressing F6 with the assembly view selected can bring my PC to its knees if it is a complicated assembly. Novice uses trying to build Mendel90 often make this mistake. On 9 January 2016 at 03:03, shadowwynd <shadowwynd@gmail.com> wrote: > I agree that this would be a useful tool to have. It would mean we could > code a "visual representation" (F5), and a "layout for 3D printing" that is > automatically generated on F6. > > > > > -- > View this message in context: > http://forum.openscad.org/Variable-for-render-mode-tp5340p15580.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 >
TP
Torsten Paul
Sat, Jan 9, 2016 1:40 PM

There's a by now quite old github issue for that:
https://github.com/openscad/openscad/issues/149

There's a by now quite old github issue for that: https://github.com/openscad/openscad/issues/149
M
MichaelAtOz
Sat, Jan 9, 2016 10:44 PM

tp3 wrote

There's a by now quite old github issue for that:
https://github.com/openscad/openscad/issues/149

Surprising it hasn't been tackled as it has a $100 bounty.


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-tp5340p15598.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

tp3 wrote > There's a by now quite old github issue for that: > https://github.com/openscad/openscad/issues/149 Surprising it hasn't been tackled as it has a $100 bounty. ----- 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-tp5340p15598.html Sent from the OpenSCAD mailing list archive at Nabble.com.
M
MichaelAtOz
Sat, Jan 9, 2016 10:45 PM

Oh, that was nophead, just now...


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-tp5340p15599.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Oh, that was nophead, just now... ----- 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-tp5340p15599.html Sent from the OpenSCAD mailing list archive at Nabble.com.
TP
Torsten Paul
Sat, Jan 9, 2016 10:53 PM

On 01/09/2016 11:45 PM, MichaelAtOz wrote:

Oh, that was nophead, just now...

Yep, actually I wanted to do that some time ago, but after discussion
with Marius it turned out, it might not be as easy as it sounds.
The feature itself is clear and very useful, but main concern was
the internal caching I think.
I'm still not sure we'll run into issues with a fixed value for each
new evaluation (except maybe using more cache memory, but that would
not be much different from just changing the value manually). I guess
we'll find out, hopefully soon :-).

Any ideas how to name it? I think it would make sense to

a) not introduce more $ variables as this also makes no sense for
a fixed value

b) maybe have something like ENV.something that can then be extended
for similar things like access to some system information as
requested in other issues.

ciao,
Torsten.

On 01/09/2016 11:45 PM, MichaelAtOz wrote: > Oh, that was nophead, just now... > Yep, actually I wanted to do that some time ago, but after discussion with Marius it turned out, it might not be as easy as it sounds. The feature itself is clear and very useful, but main concern was the internal caching I think. I'm still not sure we'll run into issues with a fixed value for each new evaluation (except maybe using more cache memory, but that would not be much different from just changing the value manually). I guess we'll find out, hopefully soon :-). Any ideas how to name it? I think it would make sense to a) not introduce more $ variables as this also makes no sense for a fixed value b) maybe have something like ENV.something that can then be extended for similar things like access to some system information as requested in other issues. ciao, Torsten.
M
MichaelAtOz
Sat, Jan 9, 2016 11:57 PM

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.

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.
M
MichaelAtOz
Sat, Jan 9, 2016 11:59 PM

It could also be used to deprecate $vpr etc.


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-tp5340p15606.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

It could also be used to deprecate $vpr etc. ----- 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-tp5340p15606.html Sent from the OpenSCAD mailing list archive at Nabble.com.
NH
nop head
Sun, Jan 10, 2016 12:12 AM

Not sure how caching is a problem. I currently have if(0) ... else ... that
I manually change to if(1) when I switch from F6 to F5. How is automating
that so if can do if(preview()) going to affect the cache or cause any
other problems? It is just automating what I have to do manually.

If I changed $fn on the state then it might use more cache, but again it is
only automating what some people do manually.

I don't care what sort of variable it is communicated with as I can just
wrap it in my own function called preview(). It seems odd to start
inventing new syntax for such a simple feature. That seems to be why it has
never been implemented. I can't see why another $variable or built in
function is a bad thing. Especially as user variables and functions
override built in ones, so even if someone uses the same name it gets
overridden.

The same applies to my proposal for export, it just automates what people
do manually, with ! and * and the export menu.

On 9 January 2016 at 22:53, Torsten Paul Torsten.Paul@gmx.de wrote:

On 01/09/2016 11:45 PM, MichaelAtOz wrote:

Oh, that was nophead, just now...

Yep, actually I wanted to do that some time ago, but after discussion
with Marius it turned out, it might not be as easy as it sounds.
The feature itself is clear and very useful, but main concern was
the internal caching I think.
I'm still not sure we'll run into issues with a fixed value for each
new evaluation (except maybe using more cache memory, but that would
not be much different from just changing the value manually). I guess
we'll find out, hopefully soon :-).

Any ideas how to name it? I think it would make sense to

a) not introduce more $ variables as this also makes no sense for
a fixed value

b) maybe have something like ENV.something that can then be extended
for similar things like access to some system information as
requested in other issues.

ciao,
Torsten.


OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Not sure how caching is a problem. I currently have if(0) ... else ... that I manually change to if(1) when I switch from F6 to F5. How is automating that so if can do if(preview()) going to affect the cache or cause any other problems? It is just automating what I have to do manually. If I changed $fn on the state then it might use more cache, but again it is only automating what some people do manually. I don't care what sort of variable it is communicated with as I can just wrap it in my own function called preview(). It seems odd to start inventing new syntax for such a simple feature. That seems to be why it has never been implemented. I can't see why another $variable or built in function is a bad thing. Especially as user variables and functions override built in ones, so even if someone uses the same name it gets overridden. The same applies to my proposal for export, it just automates what people do manually, with ! and * and the export menu. On 9 January 2016 at 22:53, Torsten Paul <Torsten.Paul@gmx.de> wrote: > On 01/09/2016 11:45 PM, MichaelAtOz wrote: > > Oh, that was nophead, just now... > > > Yep, actually I wanted to do that some time ago, but after discussion > with Marius it turned out, it might not be as easy as it sounds. > The feature itself is clear and very useful, but main concern was > the internal caching I think. > I'm still not sure we'll run into issues with a fixed value for each > new evaluation (except maybe using more cache memory, but that would > not be much different from just changing the value manually). I guess > we'll find out, hopefully soon :-). > > Any ideas how to name it? I think it would make sense to > > a) not introduce more $ variables as this also makes no sense for > a fixed value > > b) maybe have something like ENV.something that can then be extended > for similar things like access to some system information as > requested in other issues. > > ciao, > Torsten. > > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >
TP
Torsten Paul
Sun, Jan 10, 2016 12:35 AM

On 01/10/2016 12:57 AM, MichaelAtOz wrote:

Note other discussion  here
https://github.com/openscad/openscad/issues/907  , some idiot ;)
suggested;

Oi, someone reading the Debian bugtracker? ;-)

Right, that openscad.isRender() vs. env.platform()
was mainly to have some kind of logical grouping.
It's not strictly needed.

On 01/10/2016 01:12 AM, nop head wrote:

I can't see why another $variable or built in function is
a bad thing. Especially as user variables and functions
override built in ones, so even if someone uses the same
name it gets overridden.

For just one, that probably does not matter too much, but
there's lots of more stuff requested. Having like 20
global $variables for various stuff that could even
be overwritten in user assignments clutters the global
namespace quite a bit.
Having constants as $ variable also seems quite strange
in itself.

Also the dot notation is existing already (even if it's
just for some obscure special case) and that's the proposed
style for a possible OpenSCAD future.

The function notation might work too. This could automatically
clarify the values are just returned and can't be overwritten
and maybe even allow additional parameters like a format
string for the date.

I think it makes sense to think about the style that
will allow implementing the other issues in the same
way, even if this specific issue will just add one
small part.

ciao,
Torsten.

On 01/10/2016 12:57 AM, MichaelAtOz wrote: > Note other discussion here > <https://github.com/openscad/openscad/issues/907> , some idiot ;) > suggested; > Oi, someone reading the Debian bugtracker? ;-) Right, that openscad.isRender() vs. env.platform() was mainly to have some kind of logical grouping. It's not strictly needed. On 01/10/2016 01:12 AM, nop head wrote: > I can't see why another $variable or built in function is > a bad thing. Especially as user variables and functions > override built in ones, so even if someone uses the same > name it gets overridden. > For just one, that probably does not matter too much, but there's lots of more stuff requested. Having like 20 global $variables for various stuff that could even be overwritten in user assignments clutters the global namespace quite a bit. Having constants as $ variable also seems quite strange in itself. Also the dot notation is existing already (even if it's just for some obscure special case) and that's the proposed style for a possible OpenSCAD future. The function notation might work too. This could automatically clarify the values are just returned and can't be overwritten and maybe even allow additional parameters like a format string for the date. I think it makes sense to think about the style that will allow implementing the other issues in the same way, even if this specific issue will just add one small part. ciao, Torsten.