Name resolution different on different PCs.
I think the problem is caused by the used modules being stored in a
std:unordered_set and iterated over with a for loop. Surely that doesn't
have a deterministic order?
On Mon, 20 Jan 2020 at 10:03, nop head nop.head@gmail.com wrote:
The work I did was on dependency tracking of uses and includes in order to
decide what needs to be re-parsed and compiled to update the preview. It is
a much earlier phase than module instantiation name lookup. I am struggling
to understand how that works.
On Mon, 20 Jan 2020 at 09:51, MichaelAtOz oz.at.michael@gmail.com wrote:
You did some work on caching the use/include files IIRC, did that have any
debug calls that could help, ie command line --debug?
Admin - email* me if you need anything, or if I've done something
stupid...
- click on my MichaelAtOz label, there is a link to email me.
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.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Mon, Jan 20, 2020 at 11:27:49AM +0000, nop head wrote:
I think the problem is caused by the used modules being stored in a
std:unordered_set and iterated over with a for loop. Surely that doesn't
have a deterministic order?
I think the earlier definition should always be overridden, so the intent
was to simply overwrite the older definition.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
To make it so the later used files are searched first I think the container
needs to be a vector and insertion needs a check that it is not already
there, if so remove it. The for loop then needs to iterate backwards when
searching for modules and functions.
On Mon, 20 Jan 2020 at 11:47, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:
On Mon, Jan 20, 2020 at 11:27:49AM +0000, nop head wrote:
I think the problem is caused by the used modules being stored in a
std:unordered_set and iterated over with a for loop. Surely that doesn't
have a deterministic order?
I think the earlier definition should always be overridden, so the intent
was to simply overwrite the older definition.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
**
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Mon, Jan 20, 2020 at 01:23:26PM +0000, nop head wrote:
To make it so the later used files are searched first I think the container
needs to be a vector and insertion needs a check that it is not already
there, if so remove it. The for loop then needs to iterate backwards when
searching for modules and functions.
My guess is that in an earlier implementation the previous definition
was simply overwritten. As the new implementation often/usually
provided the same result, testing didn't notice that something had
changed.
The "if exists remove it" would work.
If you want to keep the old definition for some reason (e.g. if you
want to be able to say file1::m1() at one point in the future) then it
would work to keep a "definition counter" global in the insertion
code. Increment on each insertion (no matter what). Copy the current
count into the definition-structure when storing the definition. A
lookup should then normally select the one with the highest insertion
number.
This will fail after 2^31 or 2^32 definitions. Acceptable for
now. (this should last us until computers no longer HAVE a 32bit
integer datatype :-) ).
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
It isn't that complicated. All it needs to do is remember the order of the
uses and when resolving a module name look in the current file first and
then in all the used files in reverse order until it finds the module.
I doubt it has changed, it just isn't tested. I only recently started
making use of this and noticed it was different on my two PCs running the
same version of OpenSCAD. Prior to that I used the file with the defaults
and then overrode them in the main file. It was only when my main file
started getting too big that I split into a file for each panel and used
them.
I have managed to hit upon an order that works on this machine but I expect
it will be wrong on my desktop when I get home in March.
On Mon, 20 Jan 2020 at 14:29, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:
On Mon, Jan 20, 2020 at 01:23:26PM +0000, nop head wrote:
To make it so the later used files are searched first I think the
container
needs to be a vector and insertion needs a check that it is not already
there, if so remove it. The for loop then needs to iterate backwards when
searching for modules and functions.
My guess is that in an earlier implementation the previous definition
was simply overwritten. As the new implementation often/usually
provided the same result, testing didn't notice that something had
changed.
The "if exists remove it" would work.
If you want to keep the old definition for some reason (e.g. if you
want to be able to say file1::m1() at one point in the future) then it
would work to keep a "definition counter" global in the insertion
code. Increment on each insertion (no matter what). Copy the current
count into the definition-structure when storing the definition. A
lookup should then normally select the one with the highest insertion
number.
This will fail after 2^31 or 2^32 definitions. Acceptable for
now. (this should last us until computers no longer HAVE a 32bit
integer datatype :-) ).
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
**
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Storing the used files in a vector instead of an unordered set fixes it for
me. I will prepare a PR when I have time.
I don't think this was ever correct on any platform. It seems to be the
case that unordered_set gives approximately reverse order of insertion for
a small number of files on some platforms. In my real case example there
were a lot of used files but it only one needed to be before some of the
others.
On Mon, 20 Jan 2020 at 15:42, nop head nop.head@gmail.com wrote:
It isn't that complicated. All it needs to do is remember the order of the
uses and when resolving a module name look in the current file first and
then in all the used files in reverse order until it finds the module.
I doubt it has changed, it just isn't tested. I only recently started
making use of this and noticed it was different on my two PCs running the
same version of OpenSCAD. Prior to that I used the file with the defaults
and then overrode them in the main file. It was only when my main file
started getting too big that I split into a file for each panel and used
them.
I have managed to hit upon an order that works on this machine but I
expect it will be wrong on my desktop when I get home in March.
On Mon, 20 Jan 2020 at 14:29, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:
On Mon, Jan 20, 2020 at 01:23:26PM +0000, nop head wrote:
To make it so the later used files are searched first I think the
container
needs to be a vector and insertion needs a check that it is not already
there, if so remove it. The for loop then needs to iterate backwards
when
searching for modules and functions.
My guess is that in an earlier implementation the previous definition
was simply overwritten. As the new implementation often/usually
provided the same result, testing didn't notice that something had
changed.
The "if exists remove it" would work.
If you want to keep the old definition for some reason (e.g. if you
want to be able to say file1::m1() at one point in the future) then it
would work to keep a "definition counter" global in the insertion
code. Increment on each insertion (no matter what). Copy the current
count into the definition-structure when storing the definition. A
lookup should then normally select the one with the highest insertion
number.
This will fail after 2^31 or 2^32 definitions. Acceptable for
now. (this should last us until computers no longer HAVE a 32bit
integer datatype :-) ).
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110
**
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233
**
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Fix here https://github.com/openscad/openscad/pull/3196
On Thu, 23 Jan 2020 at 14:26, nop head nop.head@gmail.com wrote:
Storing the used files in a vector instead of an unordered set fixes it
for me. I will prepare a PR when I have time.
I don't think this was ever correct on any platform. It seems to be the
case that unordered_set gives approximately reverse order of insertion for
a small number of files on some platforms. In my real case example there
were a lot of used files but it only one needed to be before some of the
others.
On Mon, 20 Jan 2020 at 15:42, nop head nop.head@gmail.com wrote:
It isn't that complicated. All it needs to do is remember the order of
the uses and when resolving a module name look in the current file first
and then in all the used files in reverse order until it finds the module.
I doubt it has changed, it just isn't tested. I only recently started
making use of this and noticed it was different on my two PCs running the
same version of OpenSCAD. Prior to that I used the file with the defaults
and then overrode them in the main file. It was only when my main file
started getting too big that I split into a file for each panel and used
them.
I have managed to hit upon an order that works on this machine but I
expect it will be wrong on my desktop when I get home in March.
On Mon, 20 Jan 2020 at 14:29, Rogier Wolff R.E.Wolff@bitwizard.nl
wrote:
On Mon, Jan 20, 2020 at 01:23:26PM +0000, nop head wrote:
To make it so the later used files are searched first I think the
container
needs to be a vector and insertion needs a check that it is not already
there, if so remove it. The for loop then needs to iterate backwards
when
searching for modules and functions.
My guess is that in an earlier implementation the previous definition
was simply overwritten. As the new implementation often/usually
provided the same result, testing didn't notice that something had
changed.
The "if exists remove it" would work.
If you want to keep the old definition for some reason (e.g. if you
want to be able to say file1::m1() at one point in the future) then it
would work to keep a "definition counter" global in the insertion
code. Increment on each insertion (no matter what). Copy the current
count into the definition-structure when storing the definition. A
lookup should then normally select the one with the highest insertion
number.
This will fail after 2^31 or 2^32 definitions. Acceptable for
now. (this should last us until computers no longer HAVE a 32bit
integer datatype :-) ).
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ **
+31-15-2049110 **
** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233
**
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org