Emacs mode for SKILL

[jmss]

Hi,

I've read through many discussions on this topic in the last two weeks
or so.

In fact, in my case emacs' lisp-mode is OK for SKILL except when I use
C function calling syntax instead of Lisp's. This ruins indentation
completely.

Is there any small change to make in order to get the correct code
indentation for SKILL scripts?

Using the emacs-skill-mode package (which is somewhat hard to find and
download) demands for root privileges and is kind of an overkill for
my problem.

Any insight will be very appreciated.

Best regards,
Joăo M. S. Silva

 

[Edward]

On Aug 17, 11:04 am, jmss <joao.m.santos.si...@gmail.com> wrote:

Hi,

I've read through many discussions on this topic in the last two weeks
or so.

In fact, in my case emacs' lisp-mode is OK for SKILL except when I use
C function calling syntax instead of Lisp's. This ruins indentation
completely.

Hi Joăo,

I had the same problem. I get around this by using Lisp sexp notation
for nearly everything. The Cadence SKILL docs recommend sticking with
only one style or the other, but I cheat a little here and there with
structures like, "obj~>property~>subproperty."

But now you have me curious. Which C-function syntaxes do you find to
be worth the trouble? I haven't found one C-function syntax I like
better now that I'm familiar with using the Lisp-function syntax.

Edward

 

[Svenn Are Bjerkem]

On Aug 18, 1:01 am, Edward <edward.do...@gmail.com> wrote:

On Aug 17, 11:04 am, jmss <joao.m.santos.si...@gmail.com> wrote:

Hi,

I've read through many discussions on this topic in the last two weeks
or so.

In fact, in my case emacs' lisp-mode is OK for SKILL except when I use
C function calling syntax instead of Lisp's. This ruins indentation
completely.

If you are not completely tied to emacs, then maybe nedit can help you
out. There is a skill mode for nedit available from the nedit
homepage, just type "skill" in the page search box. If you search this
group on nedit syntax highlight, you will find more help and advices.
There is even a little generator to convert the finder short help into
nedit calltips. Nedit starts fast and is nice as a (set edit "nedit")
companion in CIW.

Hi Joăo,

I had the same problem. I get around this by using Lisp sexp notation
for nearly everything. The Cadence SKILL docs recommend sticking with
only one style or the other, but I cheat a little here and there with
structures like, "obj~>property~>subproperty."

In my opinion the -> and ~> notations are more readable than their
lisp cousins. A deep access can become very ugly. I would not consider
this as cheating even if it is.

But now you have me curious. Which C-function syntaxes do you find to
be worth the trouble? I haven't found one C-function syntax I like
better now that I'm familiar with using the Lisp-function syntax.

I agree even if I bite my butt on those closing parenthesis, specially
on setq. the infix assignment a= is a bit less error-prone. If Cadence
would have enforced a space after the ( and before the ) the code
would have been more readable. A syntactical correct lisp code must
have more air than a syntactical correct c-like code, which helps
readability, specially within environments where more people develop
code. It is, of course, always possible to use the pp() function for
pretty-printing own code.....

--
Svenn

 

[jmss]

I had the same problem. I get around this by using Lisp sexp notation
for nearly everything. The Cadence SKILL docs recommend sticking with
only one style or the other, but I cheat a little here and there with
structures like, "obj~>property~>subproperty."

Ok. I hadn't realized that the ~> notation was C-like.

But now you have me curious. Which C-function syntaxes do you find to
be worth the trouble? I haven't found one C-function syntax I like
better now that I'm familiar with using the Lisp-function syntax.

The problem is that I'm changing code originally wrote by a co-worker.
Moreover, it is probable that in the future this same code will be
changed by someone else. So, changing the function calling syntax
isn't advisable.

Right now the code is a bit irregular in indentation, so I would like
to select all code and 'indent-region' but that doesn't work well with
the different calling syntaxes.

 

[jmss]

If you are not completely tied to emacs, then maybe nedit can help you
out. There is a skill mode for nedit available from the nedit
homepage, just type "skill" in the page search box. If you search this
group on nedit syntax highlight, you will find more help and advices.
There is even a little generator to convert the finder short help into
nedit calltips. Nedit starts fast and is nice as a (set edit "nedit")
companion in CIW.

Well, nedit is kind of the standard here but I'm used to emacs (for
development and comprehensive text editing) or vi (for fast jobs).

I agree even if I bite my butt on those closing parenthesis, specially
on setq. the infix assignment a= is a bit less error-prone. If Cadence
would have enforced a space after the ( and before the ) the code
would have been more readable. A syntactical correct lisp code must
have more air than a syntactical correct c-like code, which helps
readability, specially within environments where more people develop
code. It is, of course, always possible to use the pp() function for
pretty-printing own code.....

Well, it is relatively easy to insert a blank space after the ( and
before the ) with a regular expression replacement. What intrigues me
most is why there isn't a simple 2 minute fix for the indentation
problem, but I guess that messes with the syntactic analyser of emacs
mode which is not trivial to tweak.

 

[Edward]

On Aug 20, 2:31 am, jmss <joao.m.santos.si...@gmail.com> wrote:
<snip>

The problem is that I'm changing code originally wrote by a co-worker.
Moreover, it is probable that in the future this same code will be
changed by someone else. So, changing the function calling syntax
isn't advisable.

This is unfortunate. However, if this is likely to come up often in
the course of your work, you might consider writing your own format
translator. That way you can translate code from the faux C-style to
mostly Lispish, indent the code, and then translate it back. I
already do something like this with regexp-replace (Emacs) when I
decide to adopt a useful swath of code in SKILL's less-than-useful
format.

Of course, this may require more work/risk than you're willing to
take on for a simple one-off, but it could prove useful as a tool for
long-term development. Additionally, I thought I read somewhere that
SKILL translates to sexp notation before executing anyway. Perhaps
Mr. Beckett or someone with more experience can point out a way to tap
that functionality.

Right now the code is a bit irregular in indentation, so I would like
to select all code and 'indent-region' but that doesn't work well with
the different calling syntaxes.

Now that I think of it, there is a fellow on the group who works for
a company that sells & supports something akin to SKILL mode. Wish I
could remember the name now. However, I think he is more interested
in corporate sales than sales to individuals.

Good luck,

Edward

 

[jmss]

This is unfortunate. However, if this is likely to come up often in
the course of your work, you might consider writing your own format
translator. That way you can translate code from the faux C-style to
mostly Lispish, indent the code, and then translate it back. I
already do something like this with regexp-replace (Emacs) when I
decide to adopt a useful swath of code in SKILL's less-than-useful
format.

I just tried that but more unfortunately the function calling syntax
is not always the same throughout the code, not even the amount of
space used :\

Of course, this may require more work/risk than you're willing to
take on for a simple one-off, but it could prove useful as a tool for
long-term development. Additionally, I thought I read somewhere that
SKILL translates to sexp notation before executing anyway. Perhaps
Mr. Beckett or someone with more experience can point out a way to tap
that functionality.

I found out that the emacs automatic indentation, although somehow
exaggerated, is not so bad. Now I have an highlighting problem
concerning the vertical OR bars. Is looks like emacs thinks everything
between | | are comments. But I'll manage that.

Looks like the skill-mode package would really be unnecessary.

Thanks for your help.
Joăo M. S. Silva

 

[Svenn Are Bjerkem]

On Aug 21, 11:56 am, jmss <joao.m.santos.si...@gmail.com> wrote:

This is unfortunate. However, if this is likely to come up often in
the course of your work, you might consider writing your own format
translator. That way you can translate code from the faux C-style to
mostly Lispish, indent the code, and then translate it back. I
already do something like this with regexp-replace (Emacs) when I
decide to adopt a useful swath of code in SKILL's less-than-useful
format.

I just tried that but more unfortunately the function calling syntax
is not always the same throughout the code, not even the amount of
space used :\

Of course, this may require more work/risk than you're willing to
take on for a simple one-off, but it could prove useful as a tool for
long-term development. Additionally, I thought I read somewhere that
SKILL translates to sexp notation before executing anyway. Perhaps
Mr. Beckett or someone with more experience can point out a way to tap
that functionality.

I found out that the emacs automatic indentation, although somehow
exaggerated, is not so bad. Now I have an highlighting problem
concerning the vertical OR bars. Is looks like emacs thinks everything
between | | are comments. But I'll manage that.

Looks like the skill-mode package would really be unnecessary.

Did you try the pretty-print function pp()? Give it a function of
yours, and it will format it, unfortunately not anymore in lisp, but a
quite readable c-style code. (Nice space before and after = and the
closing )'s nicely aligned with the opening ones.
--
Svenn

 

[jmss]

Did you try the pretty-print function pp()? Give it a function of
yours, and it will format it, unfortunately not anymore in lisp, but a
quite readable c-style code. (Nice space before and after = and the
closing )'s nicely aligned with the opening ones.

Yes. The only problem I see with it is that it receives functions but
not files. So if I wanted to prettify an entire file I would have to
make some manual work.

Emacs Lisp mode is not perfect but it's the best I can get with the
amount of effort I can afford. So I'll stick to it until it gives me
problems.

Anyway, SKILL will probably be replaced by Python in the future. Isn't
it?

Thanks for you help.

 

[Jean-Marc Bourguet]

jmss <joao.m.santos.silva@gmail.com> writes:

Did you try the pretty-print function pp()? Give it a function of
yours, and it will format it, unfortunately not anymore in lisp, but a
quite readable c-style code. (Nice space before and after = and the
closing )'s nicely aligned with the opening ones.

Yes. The only problem I see with it is that it receives functions but
not files. So if I wanted to prettify an entire file I would have to
make some manual work.

Emacs Lisp mode is not perfect but it's the best I can get with the
amount of effort I can afford. So I'll stick to it until it gives me
problems.

Anyway, SKILL will probably be replaced by Python in the future. Isn't
it?

Why do you think that? IMHO, there is too much Skill internally at Cadence
and externally at customers' sites to think about replacing it.

--
Jean-Marc

 

[jmss]

Why do you think that? IMHO, there is too much Skill internally at Cadence
and externally at customers' sites to think about replacing it.

You are certainly right.

I'm relatively new to SKILL but, for instance, the way one designs
forms in SKILL (with the x,y coordinates, etc.) is somewhat archaic.
In some time, I think it will be better to start developing in python,
affording to loose some time in the migration process, than to loose
some time with SKILL forms or training someone to learn Lisp/SKILL.

I don't know. I'm just speculating.

 

[Svenn Are Bjerkem]

On Aug 22, 10:57 am, jmss <joao.m.santos.si...@gmail.com> wrote:

Why do you think that? IMHO, there is too much Skill internally at Cadence
and externally at customers' sites to think about replacing it.

You are certainly right.

I'm relatively new to SKILL but, for instance, the way one designs
forms in SKILL (with the x,y coordinates, etc.) is somewhat archaic.
In some time, I think it will be better to start developing in python,
affording to loose some time in the migration process, than to loose
some time with SKILL forms or training someone to learn Lisp/SKILL.

I don't know. I'm just speculating.

Andrew Beckett clearly states that SKILL will not be replaced. It may
get augmented with other scripting languages, but not replaced. This
quesiton came up on this group earlier, and I am suprised that this
question came up again so quickly.

SKILL is not about forms, SKILL is about design automation. Python is
wrapping the crappy GUI toolkits like GTK into a "pythonic" object
layer hiding the gory deatils from you.
--
Svenn

 

[Pete nospam Zakel]

In article <1187773076.290290.205090@l22g2000prc.googlegroups.com> jmss <joao.m.santos.silva@gmail.com> writes:

I'm relatively new to SKILL but, for instance, the way one designs
forms in SKILL (with the x,y coordinates, etc.) is somewhat archaic.

The form design has nothing to do with the Skill language. Were the form
design to be updated, it would not require a language change, and moving the
API to another language would just entail having the same API in another
language.

Note that 1D forms don't require an x/y position, you just don't get 2D
placement -- everything is vertically laid out in the order specified.

Please don't confuse the base language with the provided APIs.

-Pete Zakel
(phz@seeheader.nospam)

"Hell hath no fury like a bureaucrat scorned."

-Milton Friedman

 

[Andrew Beckett]

On Tue, 21 Aug 2007 11:35:38 -0000, Svenn Are Bjerkem
<svenn.bjerkem@googlemail.com> wrote:

On Aug 21, 11:56 am, jmss <joao.m.santos.si...@gmail.com> wrote:
This is unfortunate. However, if this is likely to come up often in
the course of your work, you might consider writing your own format
translator. That way you can translate code from the faux C-style to
mostly Lispish, indent the code, and then translate it back. I
already do something like this with regexp-replace (Emacs) when I
decide to adopt a useful swath of code in SKILL's less-than-useful
format.

I just tried that but more unfortunately the function calling syntax
is not always the same throughout the code, not even the amount of
space used :\

Of course, this may require more work/risk than you're willing to
take on for a simple one-off, but it could prove useful as a tool for
long-term development. Additionally, I thought I read somewhere that
SKILL translates to sexp notation before executing anyway. Perhaps
Mr. Beckett or someone with more experience can point out a way to tap
that functionality.

I found out that the emacs automatic indentation, although somehow
exaggerated, is not so bad. Now I have an highlighting problem
concerning the vertical OR bars. Is looks like emacs thinks everything
between | | are comments. But I'll manage that.

Looks like the skill-mode package would really be unnecessary.

Did you try the pretty-print function pp()? Give it a function of
yours, and it will format it, unfortunately not anymore in lisp, but a
quite readable c-style code. (Nice space before and after = and the
closing )'s nicely aligned with the opening ones.

You can get it in LISP format by doing:

sstatus(printinfix nil)
pp(yourFuncName)

The parser effectively converts all infix-style (i.e. C-style) syntax into LISP
first. You can see this by doing:

expr='(1+2*3-4)
procedure(abRecursivePrint(lst "l")
printf("(")
foreach(item lst
if(listp(item) then
abRecursivePrint(item)
else
printf("%L " item)
)
)
printf(")\n")
t
)

abRecursivePrint(expr)

outputs:

(difference (plus 1 (times 2 3 )
)
4 )


(not particularly nicely formatted - just gives you the idea)

Once the function is first executed, it's converted into a byte-code
representation - and then pp() decompiles that byte code back into
familiar syntax (or at least something approximating to familar syntax ;-> )

Regards,

Andrew.

--
Andrew Beckett
Senior Solution Architect
Cadence Design Systems, UK.

 

[jmss]

You can get it in LISP format by doing:

(...)

Once the function is first executed, it's converted into a byte-code
representation - and then pp() decompiles that byte code back into
familiar syntax (or at least something approximating to familar syntax ;-> )

I used a regular expression replacement in emacs to switch from
function( to (function and further replaced the &&, ||, etc. symbols
with the corresponding expressions and then I ran emacs indent-region.

It is now ok.