TOPIC: BUG in compiling overloaded libraries
BUG in compiling overloaded libraries 3 Years, 6 Months ago
I wanted to simplify my modded stdlib code by using the underscore _ char before the class name so I could include in my library only the changed code. In this way I could move easly to the stdlib of the last Suneido release.
But the problem is that if you compile a class with an underscore '_' char before its name, then it turns out in a stack overflow error when you try to execute its code.

I think the problem is a bug in the string.Eval implementation, because you can reproduce the error in this way:

Let's suppose that in our custom library we have a class M defined as:




Now, in the WorkSpace:


myclass = "M".Eval()    //*** THIS GOES
myobj = new myclass()   //***   IN ERROR!

Re:BUG in compiling overloaded libraries 3 Years, 6 Months ago
I do not think it is related to Eval. You also get an error from just:

new M

The _Name facility was intended to let you reference the "previous" definition of a name from within an overloading definition of that name.

Your example tries to reference a previous definition of _Field_boolean but you are not overloading Field_boolean.

It is still a bug. Either this case should be illegal (syntax error) or else it should work.

This may be a different problem than compiling _Name.

I will have to go back to the C++ code and try to remember how it works :-)

Post edited by: andrew, at: 2007/02/06 16:14
Re:BUG in compiling overloaded libraries 3 Years, 6 Months ago
To understand what will work and what will not, you need to know how it is implemented.

The value of _Name is "grabbed" at compile time

If you are in the process of loading Name from the libraries (because something referenced Name) this will be ok - values are loaded starting with stdlib and proceeding through each of the other Use'd libraries. Therefore, when you reach a re-definition of Name there will be a previous value for Name.

But if you reference _OtherName from a definition of Name, the value of OtherName may be uninitialized (e.g. has not been used yet and therefore has not been loaded from the libraries) You will then get "can't find _Name".

Because of the way this works _Name will not work directly from Eval. (But code that is Eval'ed may use library definitions that use _Name.)

I've already made a small change so the error message will give the actual name instead of always saying "_Name".

There is another potential problem. Classes reference their base class "indirectly" through the global name. But _Name does not correspond with a single global name. To handle this, a new global slot is created, the previous definition is stored in it, and the class points to this new slot. The problem is that certain actions (e.g. Use'ing or Unuse'ing a library) clear out the entire global table. If a class with an _Name is running, then it's base class will no longer be available, and again you will get "can't find _Name". I have an idea how to fix this, but it has not been a big problem so far.

I think the solution to the other problems is to make it a syntax error to use _Name outside the (re)definition of Name (including from Eval).

This is probably confusing :( In practice, if you stick to what it was intended for, it works well.
Re:BUG in compiling overloaded libraries 3 Years, 6 Months ago
Hi Andrew. I haven't understood very well all the inner details but currently, in your opinion, is it possible to compile a class that is defined as _SomeStdlibClass?
The problem for me is just this, because I would like to reuse the unmodded stdlib code of last Suneido release along with my modded code, and I would like to compile my lib (which includes some modded stdlib classes) for deployment of an application. I wouldn't want that an end user could make a mod in the source code (for mistake or for whatever other reason), compromising all the app. Yes, I know he could still make troubles if he runs directly suneido.exe, but it is more difficult.

If I use uncompiled code, it works all right, but after I have compiled my lib, all the classes defined as _SomeStdlibClass don't work anymore.
Re:BUG in compiling overloaded libraries 3 Years, 6 Months ago
Sorry, no, it will not work, because the way _Name currently works is connected to how library records are compiled as they are loaded.

We would have to change how _Name is implemented to make it work when compiled.

We do not compile our libraries so it has not been an issue for us.

I will think about what we can do.

Post edited by: andrew, at: 2007/02/08 18:35