FH
Father Horton
Thu, Oct 23, 2025 6:41 PM
I hope that’s not the explanation! That would be a memory leak of
horrendous proportions. But hey, at least it gives a reason to upgrade :)
On Thu, Oct 23, 2025 at 1:39 PM gene heskett gheskett@shentel.net wrote:
On 10/23/25 12:36, Father Horton wrote:
Technically the variable does not change even in a FOR loop. Each
which I assume then allocates more memory. Which could explain why, at
around a couple hundred renders as I write new code, things get funkity
& I have to save and restart OpenSCAD. I've only 32Gigs of main memory.
I've wondered why, now I know. Thank you. Must be time to get a new
main board and more memory. . .
On 10/23/25 12:12, Jordan Brown via Discuss wrote:
See also the first page of the manual:
The is one exception to that no changes rule. what ever you use for the
for(n=[ in a for loop, the n is a variable that can be used within the
scope of the for's { code list loop } which can even include another
"for" loop. I do that every time I render a threaded bolt.
Cheers, Gene Heskett, CET.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law
Cheers, Gene Heskett, CET.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.
I hope that’s not the explanation! That would be a memory leak of
horrendous proportions. But hey, at least it gives a reason to upgrade :)
On Thu, Oct 23, 2025 at 1:39 PM gene heskett <gheskett@shentel.net> wrote:
> On 10/23/25 12:36, Father Horton wrote:
> > Technically the variable does not change even in a FOR loop. Each
> iteration
> > is a new scope.
> which I assume then allocates more memory. Which could explain why, at
> around a couple hundred renders as I write new code, things get funkity
> & I have to save and restart OpenSCAD. I've only 32Gigs of main memory.
> I've wondered why, now I know. Thank you. Must be time to get a new
> main board and more memory. . .
> >
> > On Thu, Oct 23, 2025 at 11:28 AM gene heskett via Discuss <
> > discuss@lists.openscad.org> wrote:
> >
> >> On 10/23/25 12:12, Jordan Brown via Discuss wrote:
> >>> There's an FAQ entry:
> >>>
> >>
> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#Why_am_I_getting_an_error_when_writing_a_=_a_+_1
> >> ?
> >>> See also the first page of the manual:
> >>>
> >>
> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/General#Variables_cannot_be_changed
> >> The is one exception to that no changes rule. what ever you use for the
> >> for(n=[ in a for loop, the n is a variable that can be used within the
> >> scope of the for's { code list loop } which can even include another
> >> "for" loop. I do that every time I render a threaded bolt.
> >>> _______________________________________________
> >>> OpenSCAD mailing list
> >>> To unsubscribe send an email to discuss-leave@lists.openscad.org
> >> Cheers, Gene Heskett, CET.
> >> --
> >> "There are four boxes to be used in defense of liberty:
> >> soap, ballot, jury, and ammo. Please use in that order."
> >> -Ed Howdershelt (Author, 1940)
> >> If we desire respect for the law, we must first make the law
> respectable.
> >> - Louis D. Brandeis
> >> Don't poison our oceans, interdict drugs at the src.
> >>
> >> _______________________________________________
> >> OpenSCAD mailing list
> >> To unsubscribe send an email to discuss-leave@lists.openscad.org
> >>
>
> Cheers, Gene Heskett, CET.
> --
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law respectable.
> - Louis D. Brandeis
> Don't poison our oceans, interdict drugs at the src.
>
>
>
GH
gene heskett
Thu, Oct 23, 2025 7:06 PM
On 10/23/25 14:41, Father Horton wrote:
I hope that’s not the explanation! That would be a memory leak of
horrendous proportions. But hey, at least it gives a reason to upgrade :)
Well, considering my age of 91, and how long I can maintain this
charade, is probably a waste of resources. But I'll have to admit I have
enjoyed impressing all the frogs. Its the penultimate fun and that and
diabetes keeps me out of the bars. :o)>
On 10/23/25 12:36, Father Horton wrote:
Technically the variable does not change even in a FOR loop. Each
which I assume then allocates more memory. Which could explain why, at
around a couple hundred renders as I write new code, things get funkity
& I have to save and restart OpenSCAD. I've only 32Gigs of main memory.
I've wondered why, now I know. Thank you. Must be time to get a new
main board and more memory. . .
On 10/23/25 12:12, Jordan Brown via Discuss wrote:
See also the first page of the manual:
The is one exception to that no changes rule. what ever you use for the
for(n=[ in a for loop, the n is a variable that can be used within the
scope of the for's { code list loop } which can even include another
"for" loop. I do that every time I render a threaded bolt.
Cheers, Gene Heskett, CET.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law
Cheers, Gene Heskett, CET.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.
Cheers, Gene Heskett, CET.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.
On 10/23/25 14:41, Father Horton wrote:
> I hope that’s not the explanation! That would be a memory leak of
> horrendous proportions. But hey, at least it gives a reason to upgrade :)
Well, considering my age of 91, and how long I can maintain this
charade, is probably a waste of resources. But I'll have to admit I have
enjoyed impressing all the frogs. Its the penultimate fun and that and
diabetes keeps me out of the bars. :o)>
> On Thu, Oct 23, 2025 at 1:39 PM gene heskett <gheskett@shentel.net> wrote:
>
>> On 10/23/25 12:36, Father Horton wrote:
>>> Technically the variable does not change even in a FOR loop. Each
>> iteration
>>> is a new scope.
>> which I assume then allocates more memory. Which could explain why, at
>> around a couple hundred renders as I write new code, things get funkity
>> & I have to save and restart OpenSCAD. I've only 32Gigs of main memory.
>> I've wondered why, now I know. Thank you. Must be time to get a new
>> main board and more memory. . .
>>> On Thu, Oct 23, 2025 at 11:28 AM gene heskett via Discuss <
>>> discuss@lists.openscad.org> wrote:
>>>
>>>> On 10/23/25 12:12, Jordan Brown via Discuss wrote:
>>>>> There's an FAQ entry:
>>>>>
>> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#Why_am_I_getting_an_error_when_writing_a_=_a_+_1
>>>> ?
>>>>> See also the first page of the manual:
>>>>>
>> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/General#Variables_cannot_be_changed
>>>> The is one exception to that no changes rule. what ever you use for the
>>>> for(n=[ in a for loop, the n is a variable that can be used within the
>>>> scope of the for's { code list loop } which can even include another
>>>> "for" loop. I do that every time I render a threaded bolt.
>>>>> _______________________________________________
>>>>> OpenSCAD mailing list
>>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>> Cheers, Gene Heskett, CET.
>>>> --
>>>> "There are four boxes to be used in defense of liberty:
>>>> soap, ballot, jury, and ammo. Please use in that order."
>>>> -Ed Howdershelt (Author, 1940)
>>>> If we desire respect for the law, we must first make the law
>> respectable.
>>>> - Louis D. Brandeis
>>>> Don't poison our oceans, interdict drugs at the src.
>>>>
>>>> _______________________________________________
>>>> OpenSCAD mailing list
>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org
>>>>
>> Cheers, Gene Heskett, CET.
>> --
>> "There are four boxes to be used in defense of liberty:
>> soap, ballot, jury, and ammo. Please use in that order."
>> -Ed Howdershelt (Author, 1940)
>> If we desire respect for the law, we must first make the law respectable.
>> - Louis D. Brandeis
>> Don't poison our oceans, interdict drugs at the src.
>>
>>
>>
Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.
AM
Adrian Mariano
Thu, Oct 23, 2025 7:26 PM
I can't imagine that OpenSCAD keeps the n=1 scope in memory when it has
moved on to the n=2 scope. There is no way to ever access the n=1 scope at
this point. The C-style for loop enables you to define variables from the
n+1 scope based on the values in the n scope. But it's quirky and hard to
use due to its termination behavior, so I wouldn't generally recommend it
as the go-to solution for things.
Note that there are some ways you can create a new scope that can look like
redefinition of a variable.
module foo(a)
{
a = a / 2; // This "redefined" a is a different scope than the
parameter a, and this new a hides the parameter
etc...
function foo(a) =
let(a=2a) // creates a new scope with a new a that hides the parameter
let(a=2a) // creates a new scope with a newer a that hides the
previous a
let(a=2a) // creates a new scope with an even newer a that hides the
previous a
a; // return a, which is now 222(parameter scope a)
echo(foo(5)); // prints 40
I can't imagine that OpenSCAD keeps the n=1 scope in memory when it has
moved on to the n=2 scope. There is no way to ever access the n=1 scope at
this point. The C-style for loop enables you to define variables from the
n+1 scope based on the values in the n scope. But it's quirky and hard to
use due to its termination behavior, so I wouldn't generally recommend it
as the go-to solution for things.
Note that there are some ways you can create a new scope that can look like
redefinition of a variable.
module foo(a)
{
a = a / 2; // This "redefined" a is a different scope than the
parameter a, and this new a hides the parameter
etc...
function foo(a) =
let(a=2*a) // creates a new scope with a new a that hides the parameter
let(a=2*a) // creates a new scope with a newer a that hides the
previous a
let(a=2*a) // creates a new scope with an even newer a that hides the
previous a
a; // return a, which is now 2*2*2*(parameter scope a)
echo(foo(5)); // prints 40
JB
Jordan Brown
Thu, Oct 23, 2025 11:10 PM
On 10/23/2025 12:26 PM, Adrian Mariano via Discuss wrote:
I can't imagine that OpenSCAD keeps the n=1 scope in memory when it
has moved on to the n=2 scope.
It certainly isn't supposed to.
It does generate CSG tree nodes that stick around until the next run,
and large enough "for" loops could certainly cause memory problems
there. But that has nothing to do with scopes.
On 10/23/2025 12:26 PM, Adrian Mariano via Discuss wrote:
> I can't imagine that OpenSCAD keeps the n=1 scope in memory when it
> has moved on to the n=2 scope.
It certainly isn't supposed to.
It *does* generate CSG tree nodes that stick around until the next run,
and large enough "for" loops could certainly cause memory problems
there. But that has nothing to do with scopes.
GH
gene heskett
Thu, Oct 23, 2025 11:16 PM
On 10/23/25 15:27, Adrian Mariano via Discuss wrote:
I can't imagine that OpenSCAD keeps the n=1 scope in memory when it has
moved on to the n=2 scope. There is no way to ever access the n=1 scope at
this point. The C-style for loop enables you to define variables from the
n+1 scope based on the values in the n scope. But it's quirky and hard to
use due to its termination behavior, so I wouldn't generally recommend it
as the go-to solution for things.
Quirky termination? What I've done has worked quite precisely.
particularly for multiturn 2 start threads.
This discussion has been very informative. Thank you.
Note that there are some ways you can create a new scope that can look like
redefinition of a variable.
module foo(a)
{
a = a / 2; // This "redefined" a is a different scope than the
parameter a, and this new a hides the parameter
etc...
function foo(a) =
let(a=2a) // creates a new scope with a new a that hides the parameter
let(a=2a) // creates a new scope with a newer a that hides the
previous a
let(a=2a) // creates a new scope with an even newer a that hides the
previous a
a; // return a, which is now 222(parameter scope a)
echo(foo(5)); // prints 40
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Cheers, Gene Heskett, CET.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.
On 10/23/25 15:27, Adrian Mariano via Discuss wrote:
> I can't imagine that OpenSCAD keeps the n=1 scope in memory when it has
> moved on to the n=2 scope. There is no way to ever access the n=1 scope at
> this point. The C-style for loop enables you to define variables from the
> n+1 scope based on the values in the n scope. But it's quirky and hard to
> use due to its termination behavior, so I wouldn't generally recommend it
> as the go-to solution for things.
Quirky termination? What I've done has worked quite precisely.
particularly for multiturn 2 start threads.
This discussion has been very informative. Thank you.
> Note that there are some ways you can create a new scope that can look like
> redefinition of a variable.
>
> module foo(a)
> {
> a = a / 2; // This "redefined" a is a different scope than the
> parameter a, and this new a hides the parameter
>
> etc...
>
>
> function foo(a) =
> let(a=2*a) // creates a new scope with a new a that hides the parameter
> let(a=2*a) // creates a new scope with a newer a that hides the
> previous a
> let(a=2*a) // creates a new scope with an even newer a that hides the
> previous a
> a; // return a, which is now 2*2*2*(parameter scope a)
>
> echo(foo(5)); // prints 40
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.
L
larry
Fri, Oct 24, 2025 4:44 AM
On Thu, 2025-10-23 at 13:41 -0500, Father Horton via Discuss wrote:
I hope that’s not the explanation! That would be a memory leak of
horrendous proportions. But hey, at least it gives a reason to
upgrade :)
When I am iteratively designing something with OpenSCAD, I have to
watch my cache and program RAM usage very carefully or I find myself in
a situation where everything moves slower than molasses, and I have to
try to open a terminal and come back after an hour to kill OpenSCAD.
Selecting 'Flush Caches' does not help. Only killing OpenSCAD does.
On 10/23/25 12:36, Father Horton wrote:
Technically the variable does not change even in a FOR loop. Each
iteration
is a new scope.
which I assume then allocates more memory. Which could explain why,
at
around a couple hundred renders as I write new code, things get
funkity
& I have to save and restart OpenSCAD. I've only 32Gigs of main
memory.
I've wondered why, now I know. Thank you. Must be time to get a
new
main board and more memory. . .
On 10/23/25 12:12, Jordan Brown via Discuss wrote:
See also the first page of the manual:
Cheers, Gene Heskett, CET.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law
respectable.
- Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.
OpenSCAD mailing list
To unsubscribe send an email to
discuss-leave@lists.openscad.org
On Thu, 2025-10-23 at 13:41 -0500, Father Horton via Discuss wrote:
> I hope that’s not the explanation! That would be a memory leak of
> horrendous proportions. But hey, at least it gives a reason to
> upgrade :)
When I am iteratively designing something with OpenSCAD, I have to
watch my cache and program RAM usage very carefully or I find myself in
a situation where everything moves slower than molasses, and I have to
try to open a terminal and come back after an hour to kill OpenSCAD.
Selecting 'Flush Caches' does not help. Only killing OpenSCAD does.
> On Thu, Oct 23, 2025 at 1:39 PM gene heskett <gheskett@shentel.net>
> wrote:
> > On 10/23/25 12:36, Father Horton wrote:
> > > Technically the variable does not change even in a FOR loop. Each
> > > iteration
> > > is a new scope.
> > which I assume then allocates more memory. Which could explain why,
> > at
> > around a couple hundred renders as I write new code, things get
> > funkity
> > & I have to save and restart OpenSCAD. I've only 32Gigs of main
> > memory.
> > I've wondered why, now I know. Thank you. Must be time to get a
> > new
> > main board and more memory. . .
> > >
> > > On Thu, Oct 23, 2025 at 11:28 AM gene heskett via Discuss <
> > > discuss@lists.openscad.org> wrote:
> > >
> > > > On 10/23/25 12:12, Jordan Brown via Discuss wrote:
> > > > > There's an FAQ entry:
> > > > >
> > > > https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#Why_am_I_getting_an_error_when_writing_a_=_a_+_1
> > > > ?
> > > > > See also the first page of the manual:
> > > > >
> > > > https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/General#Variables_cannot_be_changed
> > > > The is one exception to that no changes rule. what ever you use
> > > > for the
> > > > for(n=[ in a for loop, the n is a variable that can be used
> > > > within the
> > > > scope of the for's { code list loop } which can even include
> > > > another
> > > > "for" loop. I do that every time I render a threaded bolt.
> > > > > _______________________________________________
> > > > > OpenSCAD mailing list
> > > > > To unsubscribe send an email to
> > > > > discuss-leave@lists.openscad.org
> > > > Cheers, Gene Heskett, CET.
> > > > --
> > > > "There are four boxes to be used in defense of liberty:
> > > > soap, ballot, jury, and ammo. Please use in that order."
> > > > -Ed Howdershelt (Author, 1940)
> > > > If we desire respect for the law, we must first make the law
> > > > respectable.
> > > > - Louis D. Brandeis
> > > > Don't poison our oceans, interdict drugs at the src.
> > > >
> > > > _______________________________________________
> > > > OpenSCAD mailing list
> > > > To unsubscribe send an email to
> > > > discuss-leave@lists.openscad.org
> > > >
> >
> > Cheers, Gene Heskett, CET.
> > _______________________________________________
> > OpenSCAD mailing list
> > To unsubscribe send an email to discuss-leave@lists.openscad.org
MH
Matthieu Hendriks
Fri, Oct 24, 2025 5:40 AM
Would be interesting to know if you experirence the same problems in de
python openscaD.
Met vriendelijke groet
Matthieu
larry via Discuss schreef op 2025-10-24 06:44:
On Thu, 2025-10-23 at 13:41 -0500, Father Horton via Discuss wrote:
I hope that's not the explanation! That would be a memory leak of
horrendous proportions. But hey, at least it gives a reason to
upgrade :)
When I am iteratively designing something with OpenSCAD, I have to
watch my cache and program RAM usage very carefully or I find myself in
a situation where everything moves slower than molasses, and I have to
try to open a terminal and come back after an hour to kill OpenSCAD.
Selecting 'Flush Caches' does not help. Only killing OpenSCAD does.
On Thu, Oct 23, 2025 at 1:39 PM gene heskett gheskett@shentel.net
wrote: On 10/23/25 12:36, Father Horton wrote: Technically the variable
does not change even in a FOR loop. Each
iteration
is a new scope. which I assume then allocates more memory. Which could
explain why,
at
around a couple hundred renders as I write new code, things get
funkity
& I have to save and restart OpenSCAD. I've only 32Gigs of main
memory.
I've wondered why, now I know. Thank you. Must be time to get a
new
main board and more memory. . .
On Thu, Oct 23, 2025 at 11:28 AM gene heskett via Discuss <
discuss@lists.openscad.org> wrote:
On 10/23/25 12:12, Jordan Brown via Discuss wrote: There's an FAQ
entry:
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#Why_am_I_getting_an_error_when_writing_a_=a+_1
? See also the first page of the manual:
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/General#Variables_cannot_be_changed
The is one exception to that no changes rule. what ever you use
for the
for(n=[ in a for loop, the n is a variable that can be used
within the
scope of the for's { code list loop } which can even include
another
"for" loop. I do that every time I render a threaded bolt.
OpenSCAD mailing list
To unsubscribe send an email to
discuss-leave@lists.openscad.org Cheers, Gene Heskett, CET.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law
respectable.
- Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.
OpenSCAD mailing list
To unsubscribe send an email to
discuss-leave@lists.openscad.org
Would be interesting to know if you experirence the same problems in de
python openscaD.
Met vriendelijke groet
Matthieu
larry via Discuss schreef op 2025-10-24 06:44:
> On Thu, 2025-10-23 at 13:41 -0500, Father Horton via Discuss wrote:
>
>> I hope that's not the explanation! That would be a memory leak of
>> horrendous proportions. But hey, at least it gives a reason to
>> upgrade :)
>
> When I am iteratively designing something with OpenSCAD, I have to
> watch my cache and program RAM usage very carefully or I find myself in
> a situation where everything moves slower than molasses, and I have to
> try to open a terminal and come back after an hour to kill OpenSCAD.
> Selecting 'Flush Caches' does not help. Only killing OpenSCAD does.
>
> On Thu, Oct 23, 2025 at 1:39 PM gene heskett <gheskett@shentel.net>
> wrote: On 10/23/25 12:36, Father Horton wrote: Technically the variable
> does not change even in a FOR loop. Each
> iteration
> is a new scope. which I assume then allocates more memory. Which could
> explain why,
> at
> around a couple hundred renders as I write new code, things get
> funkity
> & I have to save and restart OpenSCAD. I've only 32Gigs of main
> memory.
> I've wondered why, now I know. Thank you. Must be time to get a
> new
> main board and more memory. . .
> On Thu, Oct 23, 2025 at 11:28 AM gene heskett via Discuss <
> discuss@lists.openscad.org> wrote:
>
> On 10/23/25 12:12, Jordan Brown via Discuss wrote: There's an FAQ
> entry:
>
> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#Why_am_I_getting_an_error_when_writing_a_=_a_+_1
> ? See also the first page of the manual:
>
> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/General#Variables_cannot_be_changed
> The is one exception to that no changes rule. what ever you use
> for the
> for(n=[ in a for loop, the n is a variable that can be used
> within the
> scope of the for's { code list loop } which can even include
> another
> "for" loop. I do that every time I render a threaded bolt.
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to
> discuss-leave@lists.openscad.org Cheers, Gene Heskett, CET.
> --
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law
> respectable.
> - Louis D. Brandeis
> Don't poison our oceans, interdict drugs at the src.
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to
> discuss-leave@lists.openscad.org
Cheers, Gene Heskett, CET.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
GS
Guenther Sohler
Fri, Oct 24, 2025 7:11 AM
No,
The problem above:
p=0;
for(n=[1:1:10]){
p=1-p;
echo(p);
}
does not happen in python language. With python you get exactly what you expect.
In OpenSCAD SCAD language variables are immutable. Once set . they
cannot be altered. This is a very fundamental Concept of OpenSCAD
called 'Scopes'
You could workaround that in SCAD by using an hierarchical approach,
but it might obfuscate readability.
On Fri, Oct 24, 2025 at 7:41 AM Matthieu Hendriks via Discuss <
discuss@lists.openscad.org> wrote:
Would be interesting to know if you experirence the same problems in de
python openscaD.
Met vriendelijke groet
Matthieu
larry via Discuss schreef op 2025-10-24 06:44:
On Thu, 2025-10-23 at 13:41 -0500, Father Horton via Discuss wrote:
I hope that’s not the explanation! That would be a memory leak of
horrendous proportions. But hey, at least it gives a reason to
upgrade :)
When I am iteratively designing something with OpenSCAD, I have to
watch my cache and program RAM usage very carefully or I find myself in
a situation where everything moves slower than molasses, and I have to
try to open a terminal and come back after an hour to kill OpenSCAD.
Selecting 'Flush Caches' does not help. Only killing OpenSCAD does.
On Thu, Oct 23, 2025 at 1:39 PM gene heskett gheskett@shentel.net
wrote:
On 10/23/25 12:36, Father Horton wrote:
Technically the variable does not change even in a FOR loop. Each
iteration
is a new scope.
which I assume then allocates more memory. Which could explain why,
at
around a couple hundred renders as I write new code, things get
funkity
& I have to save and restart OpenSCAD. I've only 32Gigs of main
memory.
I've wondered why, now I know. Thank you. Must be time to get a
new
main board and more memory. . .
On Thu, Oct 23, 2025 at 11:28 AM gene heskett via Discuss <
discuss@lists.openscad.org> wrote:
On 10/23/25 12:12, Jordan Brown via Discuss wrote:
There's an FAQ entry:
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#Why_am_I_getting_an_error_when_writing_a_=a+_1
?
See also the first page of the manual:
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/General#Variables_cannot_be_changed
The is one exception to that no changes rule. what ever you use
for the
for(n=[ in a for loop, the n is a variable that can be used
within the
scope of the for's { code list loop } which can even include
another
"for" loop. I do that every time I render a threaded bolt.
OpenSCAD mailing list
To unsubscribe send an email to
discuss-leave@lists.openscad.org
Cheers, Gene Heskett, CET.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law
respectable.
- Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.
OpenSCAD mailing list
To unsubscribe send an email to
discuss-leave@lists.openscad.org
Cheers, Gene Heskett, CET.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
No,
The problem above:
p=0;
for(n=[1:1:10]){
p=1-p;
echo(p);
}
does not happen in python language. With python you get exactly what you expect.
In OpenSCAD SCAD language variables are immutable. Once set . they
cannot be altered. This is a very fundamental Concept of OpenSCAD
called 'Scopes'
You could workaround that in SCAD by using an hierarchical approach,
but it might obfuscate readability.
On Fri, Oct 24, 2025 at 7:41 AM Matthieu Hendriks via Discuss <
discuss@lists.openscad.org> wrote:
> Would be interesting to know if you experirence the same problems in de
> python openscaD.
>
>
> Met vriendelijke groet
> Matthieu
>
>
> larry via Discuss schreef op 2025-10-24 06:44:
>
> On Thu, 2025-10-23 at 13:41 -0500, Father Horton via Discuss wrote:
>
> I hope that’s not the explanation! That would be a memory leak of
> horrendous proportions. But hey, at least it gives a reason to
> upgrade :)
>
>
> When I am iteratively designing something with OpenSCAD, I have to
> watch my cache and program RAM usage very carefully or I find myself in
> a situation where everything moves slower than molasses, and I have to
> try to open a terminal and come back after an hour to kill OpenSCAD.
> Selecting 'Flush Caches' does not help. Only killing OpenSCAD does.
>
>
> On Thu, Oct 23, 2025 at 1:39 PM gene heskett <gheskett@shentel.net>
> wrote:
>
> On 10/23/25 12:36, Father Horton wrote:
>
> Technically the variable does not change even in a FOR loop. Each
> iteration
> is a new scope.
>
> which I assume then allocates more memory. Which could explain why,
> at
> around a couple hundred renders as I write new code, things get
> funkity
> & I have to save and restart OpenSCAD. I've only 32Gigs of main
> memory.
> I've wondered why, now I know. Thank you. Must be time to get a
> new
> main board and more memory. . .
>
>
> On Thu, Oct 23, 2025 at 11:28 AM gene heskett via Discuss <
> discuss@lists.openscad.org> wrote:
>
> On 10/23/25 12:12, Jordan Brown via Discuss wrote:
>
> There's an FAQ entry:
>
>
> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#Why_am_I_getting_an_error_when_writing_a_=_a_+_1
> ?
>
> See also the first page of the manual:
>
>
> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/General#Variables_cannot_be_changed
> The is one exception to that no changes rule. what ever you use
> for the
> for(n=[ in a for loop, the n is a variable that can be used
> within the
> scope of the for's { code list loop } which can even include
> another
> "for" loop. I do that every time I render a threaded bolt.
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to
> discuss-leave@lists.openscad.org
>
> Cheers, Gene Heskett, CET.
> --
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author, 1940)
> If we desire respect for the law, we must first make the law
> respectable.
> - Louis D. Brandeis
> Don't poison our oceans, interdict drugs at the src.
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to
> discuss-leave@lists.openscad.org
>
>
> Cheers, Gene Heskett, CET.
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
MK
Marius Kintel
Fri, Oct 24, 2025 7:39 AM
On Oct 24, 2025, at 06:44, larry via Discuss discuss@lists.openscad.org wrote:
When I am iteratively designing something with OpenSCAD, I have to
watch my cache and program RAM usage very carefully or I find myself in
a situation where everything moves slower than molasses, and I have to
try to open a terminal and come back after an hour to kill OpenSCAD.
Selecting 'Flush Caches' does not help. Only killing OpenSCAD does.
This is definitely a bug. If you have an easy way to reproduce this, please open a GitHub issue.
If this happens only with the CGAL, or Manifold backend (or with both), it would be great to include that info too.
-Marius
> On Oct 24, 2025, at 06:44, larry via Discuss <discuss@lists.openscad.org> wrote:
>
> When I am iteratively designing something with OpenSCAD, I have to
> watch my cache and program RAM usage very carefully or I find myself in
> a situation where everything moves slower than molasses, and I have to
> try to open a terminal and come back after an hour to kill OpenSCAD.
> Selecting 'Flush Caches' does not help. Only killing OpenSCAD does.
>
This is definitely a bug. If you have an easy way to reproduce this, please open a GitHub issue.
If this happens only with the CGAL, or Manifold backend (or with both), it would be great to include that info too.
-Marius
