"Ignoring unknown variable" issue...
All,
I am running into an weird issue in a small project with include files,
where I want to override variables defined in the includes...
I eventually made a very simple testcase to illustrate what is happening, it
turns out it is linked to the sequence variables are first defined.
Here is my test case:
Testcase 1:
a = 1;
b = 2;
b = a; // Works, b gets 1
echo(a,b);
This works as well and prints
ECHO: 1, 1
Testcase 2:
a = 1;
b = 2;
a = b; // Problem: WARNING: Ignoring unknown variable 'b'.
// a gets undef
echo(a,b)
This will generate a warning and print:
WARNING: Ignoring unknown variable 'b'.
ECHO: undef, 2
I understand that a variable in OpenSCAD is a compile time thing and does
not change at runtime, but I would have expected that the parser would know
the 'last' value/state of all variables before resolving the dependencies...
Any comment / explanation on the above behavior?
--
View this message in context: http://forum.openscad.org/Ignoring-unknown-variable-issue-tp13156.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
The explanation is OpenScad uses the last value assigned all the way
through the script because a variable only ever has one value. So a=1 gets
replaced by a= b but b isn't defined at that point.
On 15 July 2015 at 10:07, Amedee openscad@e.bulles.eu wrote:
All,
I am running into an weird issue in a small project with include files,
where I want to override variables defined in the includes...
I eventually made a very simple testcase to illustrate what is happening,
it
turns out it is linked to the sequence variables are first defined.
Here is my test case:
Testcase 1:
a = 1;
b = 2;
b = a; // Works, b gets 1
echo(a,b);
This works as well and prints
ECHO: 1, 1
Testcase 2:
a = 1;
b = 2;
a = b; // Problem: WARNING: Ignoring unknown variable 'b'.
// a gets undef
echo(a,b)
This will generate a warning and print:
WARNING: Ignoring unknown variable 'b'.
ECHO: undef, 2
I understand that a variable in OpenSCAD is a compile time thing and does
not change at runtime, but I would have expected that the parser would know
the 'last' value/state of all variables before resolving the
dependencies...
Any comment / explanation on the above behavior?
--
View this message in context:
http://forum.openscad.org/Ignoring-unknown-variable-issue-tp13156.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
nophead wrote
The explanation is OpenScad uses the last value assigned all the way
through the script because a variable only ever has one value.
Yes, I understand that
nophead wrote
So a=1 gets replaced by a= b but b isn't defined at that point.
I see as well what is happening here, but it is a bit in opposition with the
first part where we say "OpenScad uses the last value assigned all the way
through"
I appreciate compiler and dependencies are complex things, but at the time
we resolve a=b we should already know b is defined (and has no
dependencies)...
--
View this message in context: http://forum.openscad.org/Ignoring-unknown-variable-issue-tp13156p13159.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Perhaps it is more correct to say the "variables" (actually named
constants) only have one value throughout their lexical scope and that is
the value assigned last. Yes the compiler could work out the value of b but
the point is it isn't in scope at the first point a is defined, so using it
breaks the scope rules.
It isn't my design, I am just describing what it does.
On 15 July 2015 at 11:32, Amedee openscad@e.bulles.eu wrote:
nophead wrote
The explanation is OpenScad uses the last value assigned all the way
through the script because a variable only ever has one value.
Yes, I understand that
nophead wrote
So a=1 gets replaced by a= b but b isn't defined at that point.
I see as well what is happening here, but it is a bit in opposition with
the
first part where we say "OpenScad uses the last value assigned all the way
through"
I appreciate compiler and dependencies are complex things, but at the time
we resolve a=b we should already know b is defined (and has no
dependencies)...
--
View this message in context:
http://forum.openscad.org/Ignoring-unknown-variable-issue-tp13156p13159.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
That is QUITE a different description than the one that is usually
offered. And much more helpful. Thank you very much!
On 7/15/2015 7:13 AM, nop head wrote:
Perhaps it is more correct to say the "variables" (actually named
constants) only have one value throughout their lexical scope and that
is the value assigned last. Yes the compiler could work out the value
of b but the point is it isn't in scope at the first point a is
defined, so using it breaks the scope rules.
It isn't my design, I am just describing what it does.
On 15 July 2015 at 11:32, Amedee <openscad@e.bulles.eu
mailto:openscad@e.bulles.eu> wrote:
nophead wrote
The explanation is OpenScad uses the last value assigned all the way
through the script because a variable only ever has one value.
Yes, I understand that
nophead wrote
So a=1 gets replaced by a= b but b isn't defined at that point.
I see as well what is happening here, but it is a bit in
opposition with the
first part where we say "OpenScad uses the last value assigned
all the way
through"
I appreciate compiler and dependencies are complex things, but at
the time
we resolve a=b we should already know b is defined (and has no
dependencies)...
--
View this message in context:
http://forum.openscad.org/Ignoring-unknown-variable-issue-tp13156p13159.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto: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
No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 2015.0.6081 / Virus Database: 4392/10231 - Release Date: 07/14/15
FWIW I get around this problem by making a new variable and assigning the right value to it in the scope where I need it.
I.e. don't reuse variables as assignments don't work like programming languages.
For me the mental trick is to realise you are writing something that - when evaluated - describes a scene. It just happens to look like a program.
Its like "for" loops. Each one creates an object (probably), if you try to assign an object to a variable in a loop - its not going to do that.
On 7/15/2015 11:13 PM, nop head wrote:
Perhaps it is more correct to say the "variables" (actually named constants) only have one value throughout their lexical scope and that is the value assigned last. Yes the compiler could work out the value of b but the point is it isn't in scope at the first point a is defined, so using it breaks the scope rules.
It isn't my design, I am just describing what it does.
On 15 July 2015 at 11:32, Amedee <openscad@e.bulles.eu> wrote:
nophead wrote
> The explanation is OpenScad uses the last value assigned all the way
> through the script because a variable only ever has one value.Yes, I understand that
nophead wrote
> So a=1 gets replaced by a= b but b isn't defined at that point.I see as well what is happening here, but it is a bit in opposition with the
first part where we say "OpenScad uses the last value assigned all the way
through"I appreciate compiler and dependencies are complex things, but at the time
we resolve a=b we should already know b is defined (and has no
dependencies)...--
View this message in context: http://forum.openscad.org/Ignoring-unknown-variable-issue-tp13156p13159.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<pre wrap="">_______________________________________________ OpenSCAD mailing list <a class="moz-txt-link-abbreviated" href="mailto:Discuss@lists.openscad.org">Discuss@lists.openscad.org</a> <a class="moz-txt-link-freetext" href="http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org">http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org</a>No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6081 / Virus Database: 4392/10233 - Release Date: 07/15/15
nophead wrote
It isn't my design, I am just describing what it does.
Yes, thank you for clarifying the process
Neon22 wrote
FWIW I get around this problem by making a new variable and
assigning the right value to it in the scope where I need it.
I.e. don't reuse variables as assignments don't work like
programming languages.
Functional languages require a mental switch ;)
Just as background info, this is what brought me to this issue: I have
separated parts of my little project into several include files, so that I
could work on these parts separately with smaller files.
In each file I typically never have raw numbers in the modules, I only use
'variables' defined at the top of these files, so it is fully parametric.
For a full assembly, I have a 'main' file which includes all the 'part'
files and call the different modules.
When I want to 'customize' the model, I assign new values to the variables
in the 'main' file; that way I don't touch the parts, and it works well due
to the way variables are working in OpenSCAD (Last value overrides).
What putted me in trouble was that I wanted to have a variable from file A
derived from a variable from file B. Sometimes it worked, and sometimes not,
depending on the include order -- which is the issue I described here.
Now I appreciate that a better solution would be to use module parameters
with default values, but I didn't wanted to end up with modules having a
huge list of parameters (maybe I should...)
--
View this message in context: http://forum.openscad.org/Ignoring-unknown-variable-issue-tp13156p13163.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
The way to avoid long parameter lists is to represent properties of an
object with a named list and just pass that. For example I have
M3_cap_screw, etc, and pass that along with its length to module screw(),
which draws it and functions like screw_clearance_radius().
On 15 July 2015 at 13:50, Amedee openscad@e.bulles.eu wrote:
nophead wrote
It isn't my design, I am just describing what it does.
Yes, thank you for clarifying the process
Neon22 wrote
FWIW I get around this problem by making a new variable and
assigning the right value to it in the scope where I need it.
I.e. don't reuse variables as assignments don't work like
programming languages.
Functional languages require a mental switch ;)
Just as background info, this is what brought me to this issue: I have
separated parts of my little project into several include files, so that I
could work on these parts separately with smaller files.
In each file I typically never have raw numbers in the modules, I only use
'variables' defined at the top of these files, so it is fully parametric.
For a full assembly, I have a 'main' file which includes all the 'part'
files and call the different modules.
When I want to 'customize' the model, I assign new values to the variables
in the 'main' file; that way I don't touch the parts, and it works well due
to the way variables are working in OpenSCAD (Last value overrides).
What putted me in trouble was that I wanted to have a variable from file A
derived from a variable from file B. Sometimes it worked, and sometimes
not,
depending on the include order -- which is the issue I described here.
Now I appreciate that a better solution would be to use module parameters
with default values, but I didn't wanted to end up with modules having a
huge list of parameters (maybe I should...)
--
View this message in context:
http://forum.openscad.org/Ignoring-unknown-variable-issue-tp13156p13163.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
Can you point to an example of this style please.
I have tried to use named lists but gave up trying to work out how to get the values out again.
So I've tended towards the module with named arguments approach.
On 7/16/2015 12:58 AM, nop head wrote:
The way to avoid long parameter lists is to represent properties of an object with a named list and just pass that. For example I have M3_cap_screw, etc, and pass that along with its length to module screw(), which draws it and functions like screw_clearance_radius().
On 15 July 2015 at 13:50, Amedee <openscad@e.bulles.eu> wrote:
nophead wrote
> It isn't my design, I am just describing what it does.Yes, thank you for clarifying the process
Neon22 wrote
> FWIW I get around this problem by making a new variable and
> assigning the right value to it in the scope where I need it.
> I.e. don't reuse variables as assignments don't work like
> programming languages.Functional languages require a mental switch ;)
Just as background info, this is what brought me to this issue: I have
separated parts of my little project into several include files, so that I
could work on these parts separately with smaller files.
In each file I typically never have raw numbers in the modules, I only use
'variables' defined at the top of these files, so it is fully parametric.For a full assembly, I have a 'main' file which includes all the 'part'
files and call the different modules.
When I want to 'customize' the model, I assign new values to the variables
in the 'main' file; that way I don't touch the parts, and it works well due
to the way variables are working in OpenSCAD (Last value overrides).What putted me in trouble was that I wanted to have a variable from file A
derived from a variable from file B. Sometimes it worked, and sometimes not,
depending on the include order -- which is the issue I described here.Now I appreciate that a better solution would be to use module parameters
with default values, but I didn't wanted to end up with modules having a
huge list of parameters (maybe I should...)--
View this message in context: http://forum.openscad.org/Ignoring-unknown-variable-issue-tp13156p13163.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<pre wrap="">_______________________________________________ OpenSCAD mailing list <a class="moz-txt-link-abbreviated" href="mailto:Discuss@lists.openscad.org">Discuss@lists.openscad.org</a> <a class="moz-txt-link-freetext" href="http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org">http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org</a>No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6081 / Virus Database: 4392/10233 - Release Date: 07/15/15
Neon22 wrote
FWIW I get around this problem by making a new variable and
assigning the right value to it in the scope where I need it.
I use the /hash parameter model/ (see my signature) and just
update the value whenever I want, so I hardly encounter this issue.
Another benefit of the hash parameter model is that you will be able
to pack similar or related parameters in one junk so the name space
won't be packed with tons of vars.
$ Runsun Pan, PhD
$ -- OpenScad_DocTest ( Thingiverse ), faces , Offliner
$ -- hash parameter model: here , here
$ -- Linux Mint 17.1 Rebecca x64 + OpenSCAD 2015.03.15/2015.04.01.nightly
--
View this message in context: http://forum.openscad.org/Ignoring-unknown-variable-issue-tp13156p13166.html
Sent from the OpenSCAD mailing list archive at Nabble.com.