Zugg Software :: View topic - [2.13] Compiled variable reference confusion

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I am seeing this in the compiled tab for one of my new functions.

Apprentice Joined: 03 Nov 2007 Posts: 132

Hmm, what should that class be referencing? All of mine look like the following:

0000 PUSHEXP 0016
0008 JUMP 0084
0016 VARREF @AfflictionList <AfflictionList> (class Lusternia)
0048 FUNCREF numitems (1)
0060 INT 0
0068 GT
0072 SETEXP 0 0
0084 PUSHLOC 0100
0092 JUMP 0160
0100 PUSHEXP 0116
0108 JUMP 0148
0116 USERFUNC @CureAttempt (0) <cureAttempt> (class Lusternia)
0148 CMD call (1)
0160 PUSHLOC 0176
0168 JUMP 0208
0176 STR 'CureAlarm'
0196 CMD t- (1)
0208 CMD if (3)

The "class Lusternia" it's referring to must be my main session window though I have no actual settings in that class. All of my settings are in a seperate package. Is this how it's supposed to be?

Posted: Wed Nov 28, 2007 12:36 am

That isn't the "location" of the variable. That is showing what the "default class" was when the script was compiled. Since a variable reference depends upon the current class, CMUD has to store it to determine if the current class has changed. When it executes the VARREF code, it checks the current class against the stored current class, and if they are the same, then it uses the fast numeric index stored for the variable. If they are different, then it re-searches for the variable name using the new current class.

This current class is stored as a numeric reference to a record in the database. It shouldn't be able to show the name if the record was deleted. You might open the package in a SQLite database viewer to see if there is still a record with that name somewhere.

In the VARASSIGN code you are seeing the raw numbers for the stored variable reference and the stored current class. I've fixed this in 2.14 so that it will expand these numbers in the disassembler just like VARREF does. But this helps illustrate what is actually stored. The 1757 is the internal record pointer to the @CommandPretext variable, and 1929 is the internal record pointer to whatever the current class was.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

This actually does point out a way that a duplicate variable could be created, which I have actually seen happen finally. It would be very dependent on how you placed the critical sections. The script is compiled the first time it is called. Between the class location of the variable being checked and the variable being set another thread starts. The second thread doesn't finish, before the first thread gets control back. It sets the variable, but the class location is no longer valid because the second thread changed it. Just a guess.

I am still concerned with how that name 'achaea_def.mud' is being pulled out after I have renamed both the window and the package that originally had that name. I might be able to believe that there is some hidden name field that is being displayed instead of the current name.

I am also actually more concerned now by that 1929, since that compiled code came from launching, offline load, open PE, look at compiled tab. This means that 1929 equates to the root of my main window. That number actually puts it practically at the end of all of my settings, onLoad testing shows that window as being created before anything else though. It seems a bit of a problem to have that setting placed both first and last depending on circumstances. Perhaps you are willing to share how onLoad goes to shed some light on my confusion.

Posted: Wed Nov 28, 2007 5:11 am

The 1929 is a pointer into an index that is sorted by different things, so it doesn't have anything to do with a record "number" or anything like that. Also, it's a pointer into the main database cache which contains *all* packages that are currently loaded into memory. But if you don't think you have a total of 1929 settings between all of your packages, then it might be a problem.

It's displaying the value of the "Name" field, which is actually the "text" field of the database, rather than the shorter "IDName" field. So it's possible that only the IDName field of your module/window got changed and not the Name field. This would be pretty obvious when viewed in an SQLite viewer. I'll look into it.

Your idea on the duplicate variable is an interesting possibility. Looking at the code, I don't have a lock between when it looks for the variable and when it creates a variable, so your scenario is definitely possible. I'll fix that and see if it helps.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I finally found a database editor that works happily with the packages. It isn't the prettiest, but it works. A link to what I am using is here. The reason I am providing a link is because the editor provides a 'cleanup' feature that reduced my .pkg from 2Mb to 250Kb. I still haven't tested the modified package, but this seems right since I moved the difference into other packages.

I did find that the displayed field was still the old value. So perhaps changing both fields makes sense when naming windows and modules. That or just making the displayed field the one we will see and set elsewhere makes the most sense.

I am still not any closer to finding a replication on the duplicate variables. I don't actually have any of my new threaded scripts active yet, so the one time I saw it was probably a fluke.

Posted: Fri Nov 30, 2007 9:03 am

SQL Administrator was referenced on the forums a while back. I have a copy here on my PC, but I've never used it clean up feature.

It's pretty solid way to examine the db's though.

Posted: Fri Nov 30, 2007 5:29 pm

I use SQLite Administrator here too. It's what I always use when I'm looking for obscure package database issues. I know that SQLite Admin is written in Delphi and also uses the same ZeosLib that I do for the database. Does anyone know how they might be doing the "Cleanup" feature? It might be something that I can build into CMUD in the future.

Back to the original topic: Yes, I just need to change it to display the IDName instead of the Name. CMUD does try to keep the two fields in sync. The only time the fields should be different is when triggers since the IDName can only hold the first 64 characters (so it can be indexed) whereas the Name field hold the entire trigger pattern.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I did a bit of poking around and found out that they are just using a command that is an SQLite extension to the SQL language. A short document on it can be found at http://www.sqlite.org/lang_vacuum.html

Posted: Fri Nov 30, 2007 11:49 pm

Cool, thanks for finding that link! I'll try to put that into a future version to help avoid constantly growing package sizes.