PySphere Options

[Shadowlord]

For those who don't know, PySphere is a program which lets you script for Sphere in a language like Python. It works by compiling your .py scripts to ordinary .scp files (when you run it).

To get it, click the 'www' button on any of my posts, you'll be taken to my site.

Benifits of using PySphere:

- Python is easier to code in, and is easier and quicker to write and read in general than SphereScript (Or JavaScript for that matter). You don't need ENDIFs (Like spherescript), or {}s (like in JavaScript) to designate where structures (like IF, While, etc) start and end.
- Your PySphere code will work in multiple sphere versions (If you avoid certain things, like explicitly referencing argv to get the arguments. That breaks support for 55i.). Things like on=@userdclick, finduid, etc, are translated properly when compiling to 55i.
- You can use while loops and for loops easily, in any supported sphere version (Currently 55i, 99u, 99v, and 99w).
- You don't have to deal with as many <>s, but you can still use <>s if you need them (For advanced coding, such as passing the name of a variable to a function as a reference to the variable, instead of passing the value of the variable and then storing a value in that variable by reference: =something).
- PySphere knows when it needs to use tryp, about uid.somevarname.whatever, about using 0s before variable names in 55i, how to pass parameters in 55i, how to write efficient (As efficient as possible anyways) while and for loops in 55i, etc. Even if you don't know how to, PySphere does. It also makes it much faster (But I said this already) to make while and for loops, especially for 55i.
- I'm sure I've forgotten some.


Cons:

- PySphere doesn't support actually using true Python code - There are some differences. For instance, you can't use self, there are no classes, there are structures for itemdefs, etc, which do not exist in ordinary Python, and <>s and other symbols (such as {}) are legal in places where they aren't in ordinary Python. All this is by necessity.
- There are a few things you can't do in PySphere still. For instance... Well, DORAND was my example before, but it is supported now.
- You have the extra step of needing to compile your .py scripts to .scp scripts with PySphere before Sphere can use them. Luckily, this is fairly fast.
- You have to worry whether PySphere compiled them right. This isn't too big of an issue, since it does almost everything right. The few things that it doesn't are often things like this: bob.function (abcd). It'll get confused by the space. It doesn't get confused by bob.function( abcd ) though.
- I'm sure I've forgotten some.


Changelog for Release 9a:


- The pattern-parsers were made to check the produce-readable-code flag, and now use alternate
patterns specified for each sphere version, if they exist, to produce readable code. The alternate patterns are named
'99wreadable' instead of '99w', etc.
- Alternate patterns were defined for local and localset for every sphere version, and also for forrange and forarray
for 99w.
- In all sphere versions, #produce-readable-code now transforms local.foo into var.foo.
- In short, #produce-readable-code now works again. (In Release 9, #produce-readable-code was unsupported, because
it had to be re-coded. Why? Here's a little history of local variables and #produce-readable-code.)

Release 1: PySphere's first release. And local variables existed, and were handled by renaming them from
'local.foo' to 'var.py__moduleName__functionName__foo'.

Release 2: The pattern parser is coded, and the basic patterns for compiling to 99u and 55i are completed.

Releases 3-7: Much work on making everything functional and stable. I would call release 7 the first 'stable'
release. Stable, in this case, means it works most of the time.
I.E. Releases 1-6 didn't really work all that great, particularly with 55i.

Release 8: #produce-readable-code is added. In releases 1-7, a function is called to return the 'header',
which is 'var.py__'+self.moduleName+'__'+self.functionName+'__'. In release 7, this function will return 'var.'
instead if the compiler has been directed to 'produce readable code'.

Release 9: Sphere 99w comes out, with local variable support via a function named ARG. The local-header function
is insufficient to support 99w hardcoded local variables, and so patterns are written for retrieving and setting
local variables, for sphere 55i, 99u, 99v, and 99w. The 99w patterns require the introduction of new pattern
metacommands. In addition, the local var support necessitates changing the 99w forarray and forrange patterns to make
use of it. The local-header function is no longer used, replaced by functions named generateLocalGet and
generateLocalSet, which use the pattern parser to generate code.
However, the produce-readable-code feature was only a part of the local-header function, and impossible to code
in the same manner in the generateLocalGet/Set functions. So, produce-readable-code is not supported in Release 9.

Release 9a: produce-readable-code again works, as new patterns (optional, unlike all the others) were added
which are used instead of the ordinary patterns whenever PySphere has been directed to produce readable code.
Where the patterns for p-r-c aren't defined, PySphere simply uses the ordinary ones, assuming that p-r-c needs
no alternate patterns there. These alternate patterns are coded for every local/localset pattern, and for
99w's forarray and forrange patterns. No other patterns need them.

[Shadowlord]

Release 9b is up.


Release 9b allows you to add plevel blocks to specify what plevel commands are for.

- Code like this is now supported:

QUOTE

plevel(1): somecommand someothercommand

- Fixed an odd bug involving local variables and if statements.

[Shadowlord]

And now Release 10 is up.

It isn't a big change, but it is a very useful change.


Release 10 allows you to use defnames as arrays.

- Defnames can be used as arrays. See def_array.py for an example.

This greatly simplifies using arrays of defnames.

[Underdog]

What might help everyone more than anything, is the location of the file?

[Shadowlord]

Click the www button on any of my posts.

[Shadowlord]

Release 11 will be out within a few days. I'm testing it right now.

[Shadowlord]

Okay, Release 11 is on my site (www button on any of my posts).


Supports 99x, GetCount, doswitch, and dorand.

[Shadowlord]

Release 12 is on my site. Since we're on the new forums, the button is [Http://] instead of [www] now. Mmm....

QUOTE

Improves support for using <>s for additional evaluation, and fixes a couple bugs (Most importantly, variables with numbers in their names, such as more2, are compiled properly now).

[Shadowlord]

Release 13 is up!

QUOTE

Release 13 has a number of improvements, it can automatically resync Sphere at the proper time, it can handle for...range statements with steps (either positive or negative), it supports +=, -=, *=, /=, %=, and will use # in 99x for local variables (But not var or tag, at this time).

And it fixes a bug.

[Shadowlord]

Release 14 is up:

QUOTE

Release 14 greatly speeds up and improves PySphere, by caching defnames that're defined SCP files, and by only compiling files that've been modified since the last compilation. PySphere no longer recompiles scripts that have not been changed since the last compilation. This greatly speeds up compilation, as if you've only changed two files out of 50, only those 2 are recompiled. If you want PySphere to recompile EVERY .py file, not just ones that've changed since the last compilation, you can change enableTimeChecking to 0. That's near the top of pysphere.py. Rather than saying 'precompiling,' PySphere now says what it's actually doing, which is parsing .py scripts for function definitions. It does this for every .py file, even ones it will not be compiling, because functions in one may be called by another. Luckily, this stage is extremely fast. PySphere no longer parses .scp files for defnames every time it runs. Instead, the first time you run Release 14 (or newer), it will look through them and write a list of defnames to defs.ini. After that, it will load that list, rather than parsing the .scp files. This greatly improves PySphere's speed. In addition, several new options have been added to PySphere, for which you would have to change a variable at the beginning of the program. To make PySphere NOT use the preceding feature, change useScpDefNameList to 0. If you do that, it will still not parse .scp files for defnames every time, unless you also change enableScpDefNameChecking to 1. Defname checking is done so that things like this work: src.act.flags=(src.act.flags|statf_conjured)|statf_pet. Without it, you would have to write src.act.flags=src.act.flags|'statf_conjured')|'statf_pet'. If you want to disable defname checking entirely, you can, by setting enableDefNameChecking to 1. Fixed a bug where PySphere was not closing every file it opened after it was done with it. This doesn't seem to have caused errors, but probably Python or the OS was fixing the situation behind my back.

[Drac]

Just a thought, make it be able to change sphere scripts into python files, so it can then be used as a 55i --> 99xx script converted as well :D

[Shadowlord]

I believe in rewriting things from scratch without merely copying/translating the original every so often, as I've noticed that this tends to, at least for me, result in a better version.

Which is why all the 55i scripts that I want for 99*-1.0 are being rewritten manually instead of converted.

And ATM PySphere's transformation is one-way. (And this wouldn't be as easy to change as one would think.)

[Tracker]

Yeah, it'd be much harder to go from sphere-->pysphere then to go from pysphere-->sphere.

[Shadowlord]

Release 15 is up!

In addition to being able to get it from the normal place (Where the 'http' button on all my posts leads), from now on you'll also be able to get the latest version here.


Release 15 (April, 2003)

• PySphere now supports 99z and 99y. Unless you specify otherwise in your scripts (with #sphere-99x or whatever version you are using), it will compile for 99z by default.
  
• All versions have a flag indicating whether or not they support function parameters a la 99u+.
  
• All versions have a flag indicating whether or not s should be used instead of <>s.
  
• s are used when compiling for 99y and 99z; They work in all cases that <>s do, and some cases where <>s do not work.
  
• It is legal to have 'else :' now.
  
• If resyncing, PySphere will end the resync even if the compliation of the scripts fails.
  
• Cleaned up PySphere's code a bit.
  
• I had the year wrong for the last 6 releases of PySphere. It's really not 2002 anymore!
  
• Tabs no longer cause errors on lines with nothing but comments or whitespace.
  
• The patterns have been moved into a new file (Patterns.py).
  
• PySphere now works when there is a replacement WSOCK32.DLL in the Sphere folder (It did not in previous releases).
  
• PySphere correctly handles lines which have spaces or tabs at the end.
  
• PySphere has support for 'dialog' and 'dialogbutton' (see dialogs.py). It it recommended that you only try to do programmatic/imperative/dynamic dialogs (i.e. the ones you can do in 99z and up) in PySphere.
  
• The 99w patterns now use GetCount, since it appears to have been supported in 99w. The 99v patterns have been replaced with a copy of the 99u patterns, since the 99u patterns worked better for 99v than the 99v patterns did.
  
• The copyright notice you see when PySphere starts has been updated to say 2002-2003 instead of just 2002.
  

[Shadowlord]

Release 16 is up. To get it, go here and click the PySphere link: http://www.sphereserver.net/download.php?o...wdownload&cid=4

Release 16 (May 30, 2003)


This release adds support for contextmenu, menu, and menudialog. I strongly encourage looking at dialogs.py to see what Menudialog is, as it is a VERY useful tool.

• The proper date wasn't listed for when Release 15 came out.
  
• PySphere has support for 'contextmenu' (see dialogs.py). Keep in mind you can only have contextmenu items which are in the cliloc muls.
  
• PySphere has support for 'menu' (see dialogs.py). It is recommended that you use menudialog instead, as it works in all clients, and automatically handles multiple pages when necessary, whereas menu does not.
  
• PySphere has support for 'menudialog', but only type 2 menudialogs (see dialogs.py). The type 2 menudialog code in dialogs.py has been uncommented now that it is supported. Type 1 menudialogs are unsupported and thus still commented out. I haven't decided whether to support them or scrap them yet.
  
• GetCount is broken in 99z, so PySphere uses the (really) old method (while (strlen(%v))) for 99z and 99y (because it's easier to include 99y than not to ATM).
  

(The contents of this post have been automatically generated from the PySphere changes.html file by a nice little converter script I made a while back in Python.)

[Shadowlord]

Release 17 (June 22, 2003)


This release fixes several bugs.

• Several things were broken in R16, and possibly earlier versions. They've all been fixed. No new features have been added.
  

[Shadowlord]

Release 18 is out. Changes:

Release 18 (July 10, 2003)

This release adds several rev-o-lute-you-nary new features.

• Multidimensional arrays are handled simply by doing myArray[x][y][z] and so forth.
  
• SPHERE (99z5 tested) does not support multidimensional arrays, so all arrays are translated to _s. I.E. myArray___.
  
• You can choose NOT to evaluate a function call inside another. For instance, if you want to do region.sectors(season()), previously you had to do region.sectors('season('+local.season+')'), which looked like crap. Now, you can do region.sectors(season$(local.season)), which DOESN'T look like crap. The $( is the key.
  
• You can also specify not to evaluate a variable by placing a $ before it. For instance, local.region=findRes("area",$ss_Niveus_area[local.yp]) compiles to ARG(region,))
  
• For the meta-coding stuff, look at example_metascript.py and .scp. Basically, you can use it to write similar but repetitive scripts in few lines of code, assuming you're willing to write the basics (to be duplicated) in spherescript (for now). Note that if you pass a number to the metascript and it turns out to be 0, it will be written out as '00' instead of '0' - Why? Because Sphere seems to think 0 is really '00.' I don't know why, but it sure is annoying.
  
• All []s are translated to _ now, except for ARGV[x]. ARGV[x] was changed to ARGV(x) in 99z7, but haven't added a 99z7 pattern yet, because 99z7 is FUBAR and I'm hoping ARGV[x] comes back.
  
• Blank lines are inserted into compiled .scp files before [somedef] stuff, to make it more readable. (Does not apply to meta-code stuff because it skips the normal write checking entirely since it writes raw spherescript.)
  
• Tabs exist in compiled .scp files, and most of the time, they're good. But block-ending stuff tends not to be tabbed the way you'd expect. It's still more readable than having no tabs at all.
  
• If you're sadistic, you can try #sphere-arc. Your scripts will come out looking more like Arc's scripts than like ordinary PySphere compiled scripts. But it doesn't know when Arc likes things to be uppercase and when he likes them to be lowercase. Really, it just changes = to a space wherever it can get away with it.
  

You can get R18 from:

http://www.sphereserver.net/download.php?o...op=getit&lid=18

I have not updated my geocities site with it yet.

[Celeron]

QUOTE

Originally posted by Shadowlord If you're sadistic, you can try #sphere-arc. Your scripts will come out looking more like Arc's scripts than like ordinary PySphere compiled scripts. But it doesn't know when Arc likes things to be uppercase and when he likes them to be lowercase. Really, it just changes = to a space wherever it can get away with it.

Simply, lol.