- Bad MEL

[stunndman]

the MEL interpreter tells you that you were trying to redeclare a variable with a different data type as it was previously declared

you are most probably playing around in the script editor - a variable declared in the script editor (and not within a procedure) is global and once declared cannot be redeclared

just put your script in a proc and call the function

like


proc test() { float $a = 2.2; print($a); }
test;

[CIM]

So, why can't I just use "Clear History" or something? You mean there's nothing like this?

Alias/wavefront needs to stop implementing half-assed features in Maya. :rolleyes:

[wrend]

it isnt half arsed, its handy. and there would be a global variable flush if you need it. just popping {} around your tests should surfice to keep them local.

[bentllama]

Originally posted by CIM
Alias/wavefront needs to stop implementing half-assed features in Maya. :rolleyes:

No need for biting the hand that feeds you... :D ...if variables could be "cleaned and reset" you would run into many potential problems...

Why not just make it a global variable, that would allow you to "reset" your $a every time you declare it globally...

...or I suggest you look at your env, getenv and putenv commands when trying to manage your variables...


:beer:

[mark_wilkins]

It's to keep you from using the same variable name to mean two different things by mistake in the same block of code, thus redefining it back and forth while trashing its contents each time, which is a common programming error in languages that don't do this.

As the previous poster suggested, by putting curly brackets around your experiments you can get around this... any variable defined within a pair of curly brackets is only valid within those brackets.

So, for example:

{
float $a = 5.0;
print ($a + "\n");
{
int $a = 10;
print ($a + "\n");
}

print ($a + "\n");
}

This will print 5.0, 10, 5.0. Note that the float-valued $a variable in the outer set of brackets hangs around, but it's not accessible once the integer-valued $a is defined in the inner set of brackets, until that block of code ends.

This isn't MEL-specific behavior. All of this is borrowed from C.

-- Mark

[mark_wilkins]

Bent: Actually I completely agree that there should be something like the "clear" command that completely undefines a variable. After all, the main reason for this syntactic rule is to ensure that you don't screw up, and if you're going to go so far as to deliberately undefine a varable name, you presumably think you know what you're doing...

Using getenv and putenv like you suggest is probably a mistake, as environment variables have all kinds of system-specific limitations, can only contain strings, are usually limited in length and number, and might already be reserved for another use by your system configuration.

-- Mark

[bentllama]

I dont disagree with being able to reset/clean single variables...but I took CIM's statement to lead towards a blanket cleaning...oops.

I usually use getenv to double check on variable names.

hey, you learn something new everyday. ;)
as always, thanks for your input Mark.

:beer:


as an aside: when I name variables I use very specific names to describe the function or data it relates to, that way I dont get burned by mistakenly re-declaring a variable that I needed

ie: string $markJustTaughtMeSomethingYetAgainHoorayForMEL = "a long variable name" :)

[CIM]

Hm, ok. I still think there should be some kind of clear when you hit "Clear History', for example. I must be too used to LScripts way of doing things. :buttrock:

Great book, Mark! I've been going through it lately. :applause:

[playmesumch00ns]

Clearing the global variables if you clear the history is completely nonsensical - there are many many times when you want to keep global variables between runs of a script, this is not just handy, it is expected behaviour. If global variables were cleared every time you hit delete history, I would be on the phone to A|W telling them to pull their act together.

As someone already said, there's really no point in implementing a clear variable function when you can just write an extra 5 chars of code to fix it for you. You'll be asking for a "make dinosaur" button next :rolleyes:

[mark_wilkins]

As someone already said, there's really no point in implementing a clear variable function when you can just write an extra 5 chars of code to fix it for you. You'll be asking for a "make dinosaur" button next

That's pointlessly harsh. After all, there are fundamental differences between the way variables are used in a command-line environment vs. in a compiled language like C, so why should the one-data-type-is-forever rule necessarily carry over?

Again, I think a "clear variable" function would be a useful addition to MEL, except for the distinct possibility that people would start to use it in their scripts rather than by hand, on the command line. Anyway, the "clear" function for arrays is a similar (though meaningfully different) precedent, so you can't even argue that it's philosophically out of whack with MEL.

-- Mark

[alexx]

i have to say, that i missed the clear command for variables a lot as well.

yes:
you can write all in {} or even in procedures..

but where is the problem about it?
like betlama said: you can run into many potential problems...
you can run into problems a lot, when you don´t know what you are doing in mel or programming in general..

i just guess the one that cleans out a global variable knows what he is doing and if not it is not a problem either: he can restart maya to clean the variables like it has to be done right now.. ;)

it´s just a command that anyone who wants to can use.. and i would want to sometimes.. since quite often i seem not to know what i am doing :rolleyes:

cheers

alexx

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.