Anyone used LocalVar?

Dr_Acula

I have been getting errors when copying PUBs from the main routine into an object, with the compiler saying that variables in the PUB are already in use. Obviously those variable names are not in the main routine but somewhere in the new object.

I think there might be a solution in the v 1.2 manual - it says this section is "improved" so I'm not sure how new this is.

PUB Name (Param ,Param…) :RValue | LocalVar [Count ] ,LocalVar [Count ]…
SourceCodeStatements
LocalVar is a name for a local variable (optional). LocalVar must not have the same symbol name as any VAR or CON symbol, but other methods may also use the same symbol name. All local variables are of size long (four bytes) and are left uninitialized upon each call to the method. Methods can contain zero or more comma-delimited local variables.

However I can't find any examples in the manual, and adding something (just a guess) like

PUB mymethod | LocalVar myvariable

gives an error.

(those  ?chinese language blocks in the copy/paste above are sort of angle brackets in the propeller manual, but it is hard to work out what they actually mean, especially as they don't don't seem to be ascii characters between 32 and 126)

Would some kind soul be able to point me in the direction of the correct syntax?

Also, a more general question - having copied all my methods into an object with the aim of making it self contained, I found it created errors because there are multiple references to a string object.

This is fairly basic I know, but I just want to check - if I declare a string object in the main routine, I can't use methods in that string object from within other objects, right?

Yes, I could declare that string object again within the sub object, but I believe that is going to use up a whole lot more memory.

The workaround seems to be to keep the bulk of the code in the "main" routine and only farm out to objects the PUBs that are self contained.

But this does seem to be a limitation to the way Spin works. Strings for instance are a really useful part of a language, and it would be handy to be able to use them all through a program. I guess it is a matter of philosophy - if you see strings as a core element to a language you would make them accessible from anywhere, but if you see them as part of an object that has to be formally declared, then if that object is not declared in the OBJ section of the object you are working from then you can't use strings in that object.

I think I might be missing something in the concept of objects. If an object is declared in the 'main' routine the compiler would know about the code associated with that object regardless of where it is called from, and ought to have enough information to glue everything together.

Or to put it another way, the language seems to be forcing the code I am writing into putting everything in the "main" function and not even using objects. I can do that, but at the same time, I kind of like the idea of an 'object' that can run a display.

Any gentle guidance from Spin experts would be most appreciated!

Heater.

LocalVar is not any keyword to be used in your program. It's just a place holder for the name of a localvariable in the syntax description. Hence the angle brackets. So just remove "LocalVar" from your example and it should compile.You then have myvariable for use inside the method.

MagIO2

The problem is, that a local variable in you PUB has the same name as a variable in the VAR- or DAT-block of the object to which you moved the PUB. I'm not sure whether parameter names also count here.

Heater.

Also if you want multiple local vars use a coma to seperate them:
PUB myMethod | localX, localY, localZ

If you use the same object multiple times in your program the compiler only includes one copy of it's code and DAT in the resulting binary. There will be multiple copies of its VAR section though.

MagIO2

About the string:
Creating a string object in each sub-object where it's needed does not cost to much memory if your string-object has no VAR section. Only the VAR sections are duplicated per object. PUB/PRI and DAT are shared among all the string objects.
My expectation for a usefull string-object is that you have a lot of functions supporting string-handling, but for each function you have to pass the pointer to the string. So, there should not be a need for having a VAR in this.

Another possibility would be to work like in the good old DOS-days (INT 13 - if I remember right). This interrupt was used to call functions and the parameters had to be placed in a defined set of registers. Translated to propeller: Have a string-processing-COG which runs all the functions. It's waiting for a the parameters and a function-number in a global memory location. So, each sub-object that wants to call a string function simply has to put the right parameters into these memory positions. But I'm not sure if we should really reanimate those kind of ancient coding practices?! ;o)

Heater.

That is no ancient obsolete coding practice. That is how many objects communicate with their COG running parts. Not sure if you would want to do it for just string handling functions though.

Dr_Acula

Thanks everyone for all the answers - I'll change the variables in the VAR and DAT blocks. A cog based string parser sounds interesting.

My expectation for a usefull string-object is that you have a lot of functions supporting string-handling, but for each function you have to pass the pointer to the string

Correct. For many string functions you might pass Source, Destination and one or more numbers.

Only the VAR sections are duplicated per object. PUB/PRI and DAT are shared among all the string objects.

Ah, that could save some memory. Thanks!

Toby Seckshund

I have been playing about with a Tux Graphics Ethernet (homemade) copy and when I tried to put more than the initial packet buffer could stand it would serve up those boxed characters on the web pages.