Name resolution different on different PCs.

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Name resolution different on different PCs.

nophead
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
rew
Reply | Threaded
Open this post in threaded view
|

Re: Name resolution different on different PCs.

rew
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.

--
** [hidden email] ** 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Name resolution different on different PCs.

nophead
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 <[hidden email]> 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.

--
** [hidden email] ** 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
rew
Reply | Threaded
Open this post in threaded view
|

Re: Name resolution different on different PCs.

rew
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.


--
** [hidden email] ** 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Name resolution different on different PCs.

nophead
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 <[hidden email]> 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.


--
** [hidden email] ** 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Name resolution different on different PCs.

nophead
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 <[hidden email]> 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 <[hidden email]> 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.


--
** [hidden email] ** 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Name resolution different on different PCs.

nophead

On Thu, 23 Jan 2020 at 14:26, nop head <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.


--
** [hidden email] ** 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
12