reg. bug in a skill program

N

noreply

Guest
Dear all,
I was running an skill program for doing some automation in layout.
I'm actually stuck with a part of the program where i have to move a
path using "leStretchShape". But when i load the script i got the
following message in CIW window
"*Error* leStretchShape: argument #1 should be a database object (type
template = "dllg") - nil "
and my command was looking like:
leStretchShape(car(geGetSelSet()) list(RLdiff 0) list(t t t t) t)

When i tried to debug it, the corresponding path was actually selected
in the layout and if i manually copy paste the above line in icfb
window, the command gets executed smoothly..
Any idea what the problem is?
* Hey and also how to clear the value of the variables that are stored
in the CIW window. I get stumped by this most of the times.. Like for
instance in MATLAB we have "clear all". What would be the
corresponding command in skill?
Thanks and regards,
Lokesh rajendran.
 
Hi Lokesh,

1. Although it is very fine to use the geGetSelSet() function in Skill
codes, I generally tend not to. I prefer to grab the ID and pass it to
the code. Also, check the ID is a valid non nil.
Anyway, please post your code so we could give it a look. A Skill bug
is very unlikely I should admit.

2. I don't know of an equivalent of the Matlab clear all in Skill. I
think it is a bit dangerous in the Skill case because many global
variables are there and need to be set up until the end.
You can unbound a variable though:
CIW> myVariable = t
CIW> myVariable = 'unbound
CIW> myVariable
*Error* toplevel: undefined variable - myVariable

Cheers,
Riad.
 
Riad KACED wrote, on 09/11/09 12:47:
Hi Lokesh,

1. Although it is very fine to use the geGetSelSet() function in Skill
codes, I generally tend not to. I prefer to grab the ID and pass it to
the code. Also, check the ID is a valid non nil.
Anyway, please post your code so we could give it a look. A Skill bug
is very unlikely I should admit.

2. I don't know of an equivalent of the Matlab clear all in Skill. I
think it is a bit dangerous in the Skill case because many global
variables are there and need to be set up until the end.
You can unbound a variable though:
CIW> myVariable = t
CIW> myVariable = 'unbound
CIW> myVariable
*Error* toplevel: undefined variable - myVariable

Cheers,
Riad.
Agreed. The trouble is that it's very hard to know which variables are yours,
and which are ours - so there doesn't exist any kind of "clear all" command.

Regards,

Andrew.

--
Andrew Beckett
Senior Solution Architect - Cadence Design Systems Ltd (UK)
 
Oh my god,
That's really bad, the cadence doesn't have "clear all" command. Hope
they do it in the future version release of cadence.
(I'm sure the MATLAB developers must have faced the very bad need of
clearing temporary variables and thats why they came up with "clear
all").
And Riad thanks for the tip,
may be some people who are planning to develop the above said 'clear
all' stuff, Will be having your tip in their mind.
Thanks and regards,
Lokesh rajendran.


On Sep 14, 3:46 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:
Riad KACED wrote, on 09/11/09 12:47:



Hi Lokesh,

1. Although it is very fine to use the geGetSelSet() function in Skill
codes, I generally tend not to. I prefer to grab the ID and pass it to
the code. Also, check the ID is a valid non nil.
Anyway, please post your code so we could give it a look. A Skill bug
is very unlikely I should admit.

2. I don't know of an equivalent of the Matlab clear all in Skill. I
think it is a bit dangerous in the Skill case because many global
variables are there and need to be set up until the end.
You can unbound a variable though:
CIW> myVariable = t
CIW> myVariable = 'unbound
CIW> myVariable
*Error* toplevel: undefined variable - myVariable

Cheers,
Riad.

Agreed. The trouble is that it's very hard to know which variables are yours,
and which are ours - so there doesn't exist any kind of "clear all" command.

Regards,

Andrew.

--
Andrew Beckett
Senior Solution Architect - Cadence Design Systems Ltd (UK)
 
Hi Lokesh,

I think you misunderstood something ....
'The tip' I have given you is actually something very well known at
Cadence, they have made it after all :)
I don't think the Matlab idea is feasible in Cds although I have no
reason to spak on behalf Cadence (I'm not a Cadence employee BTW).
In Cadence, you may have:

1. Variables from the Cadence tools, i.e DFII, ADE ... and any other
loaded CDS tools.
2. Vraibles from third party tools. i.e. Calibre, Synchronicity ...
etc
3. Variables from your site settings.
4. Variables from your PDK settings
5. Variables from your Project settings
6. Your Own variables ... etc.

These are different classes of variables you may consider here.
Just type in the following into your CIW to have an idea on how much
you have got to deal with:
CIW> printVariables("a")

One day, one of the guys in my group has inaverttently deleted that
variable that serves as the IPC process ID for our design management
tool. Needless to tell you all the mess and hassle it did generate.

Cheers,
Riad.
 
Riad KACED wrote, on 09/15/09 12:31:
Hi Lokesh,

I think you misunderstood something ....
'The tip' I have given you is actually something very well known at
Cadence, they have made it after all :)
I don't think the Matlab idea is feasible in Cds although I have no
reason to spak on behalf Cadence (I'm not a Cadence employee BTW).
In Cadence, you may have:

1. Variables from the Cadence tools, i.e DFII, ADE ... and any other
loaded CDS tools.
2. Vraibles from third party tools. i.e. Calibre, Synchronicity ...
etc
3. Variables from your site settings.
4. Variables from your PDK settings
5. Variables from your Project settings
6. Your Own variables ... etc.

These are different classes of variables you may consider here.
Just type in the following into your CIW to have an idea on how much
you have got to deal with:
CIW> printVariables("a")

One day, one of the guys in my group has inaverttently deleted that
variable that serves as the IPC process ID for our design management
tool. Needless to tell you all the mess and hassle it did generate.

Cheers,
Riad.
Exactly. There is too much scope to screw things up to have a clear all command.

The _right_ thing to do is to not define any global variables in your own code
in the first place. That way you won't ever need to do a "clear all"!

Matlab is a different kind of beast. It's much less likely to keep persistent
data in global variables.

And the 'unbound thing is in the manual. It's in the documentation for the
boundp() function, amongst other places.


Regards,

Andrew.
 
Oh my god!!!,
Hey riad, I understood the pain about temprovary variables(I will
never run the command
printVariables("a") again.
It was one good nightmare).
And thank you guys for the wonderful discussion(And thats what they
call it,its "learning", its awesome).
regards,
Lokesh


On Sep 15, 10:27 pm, Andrew Beckett <andr...@DcEaLdEeTnEcTe.HcIoSm>
wrote:
Riad KACED wrote, on 09/15/09 12:31:



Hi Lokesh,

I think you misunderstood something ....
'The tip' I have given you is actually something very well known at
Cadence, they have made it after all :)
I don't think the Matlab idea is feasible in Cds although I have no
reason to spak on behalf Cadence (I'm not a Cadence employee BTW).
In Cadence, you may have:

1. Variables from the Cadence tools, i.e DFII, ADE ... and any other
loaded CDS tools.
2. Vraibles from third party tools. i.e. Calibre, Synchronicity ...
etc
3. Variables from your site settings.
4. Variables from your PDK settings
5. Variables from your Project settings
6. Your Own variables ... etc.

These are different classes of variables you may consider here.
Just type in the following into your CIW to have an idea on how much
you have got to deal with:
CIW> printVariables("a")

One day, one of the guys in my group has inaverttently deleted that
variable that serves as the IPC process ID for our design management
tool. Needless to tell you all the mess and hassle it did generate.

Cheers,
Riad.

Exactly. There is too much scope to screw things up to have a clear all command.

The _right_ thing to do is to not define any global variables in your own code
in the first place. That way you won't ever need to do a "clear all"!

Matlab is a different kind of beast. It's much less likely to keep persistent
data in global variables.

And the 'unbound thing is in the manual. It's in the documentation for the
boundp() function, amongst other places.

Regards,

Andrew.
 

Welcome to EDABoard.com

Sponsor

Back
Top