spyce-users — Spyce user community

Re: [Spyce-users] documentation error, new module

[Rimon B. <ba...@cs...>]

Hi Rien,

Good questions!

>it seems there is an error in the documentation concerning the writing of
>new modules. The first basic example is written this way:
[...]
>from what i read in the source of standard spyce modules, shouldn't it be
>written that way ?
>    class myModule(spyceModule):
[..] ^^^^^

Yes, that's a typo, and has been corrected. It will be in the next
release.

>now, i need more informations on modules:
>in this documentation page, you say:
>"Do not override the __init__(...) method because it is inherited from
>spyceModule and has an fixed signature that is expected by the Spyce module
>loader"
>
>if we write something this way:
>    class myModule(spyceModule):
>        def __init__(self, request, response, wrapper, server):
>            spyceModule.__init__(self, request, response, wrapper, server)
>            #some module inits here...
>
>        def foo(self):
>            #some use of the module inits here...
>            self.response.write('foo called')
>will this be correct ?

This will work, yes. But why not just insert your code
  #some module inits here...
into the start() function? Both the __init__() and the start() methods are
called at the beginning of *each* request.

>also, you told me that the start method of a module is called each time a
>module directive reference this module. so, the init method is called
>only once at server initialization ? or is init called for each request ?
>said differently: can we use the init method for some module level
>initializations and start for request level initializations ?

No. Both methods are called on each request. If there are some complex
computations that you would like to cache, then use the pool module. ie.
Calculate the variables, if they do not already exist, and store them in
the server 'pool' for subsequent requests. You could also use the server
object directly; see how the 'pool' module does this. Said another way,
modules are associated with the request, not with the server.

>ps: as you see, i started writing my own modules... very interesting
>feature, which allows great flexibility !

Yes, I know! :) I'm hoping that more people will start writing modules,
and we'll really see the functionality grow rapidly. Can you give me an
example of what you are trying to do?

All the best,
Rimon.
-- 
 * Rimon Barr       Ph.D. candidate, Computer Science, Cornell University
 | ba...@cs... - http://www.cs.cornell.edu/barr - Y!IM: batripler
 |
 | Understanding is a kind of ecstasy.
 +----                                   -- Carl Sagan

[Spyce-users] documentation error, new module

[Adrien P. <sto...@cl...>]

Hello !

it seems there is an error in the documentation concerning the writing of
new modules.
The first basic example is written this way:

    def myModule(spyceModule):
        def foo(self):
            self.response.write('foo called')

from what i read in the source of standard spyce modules, shouldn't it be
written that way ?

    class myModule(spyceModule):
        def foo(self):
            self.response.write('foo called')

now, i need more informations on modules:
in this documentation page, you say:
"Do not override the __init__(...) method because it is inherited from
spyceModule and has an fixed signature that is expected by the Spyce module
loader"

if we write something this way:
    class myModule(spyceModule):
        def __init__(self, request, response, wrapper, server):
            spyceModule.__init__(self, request, response, wrapper, server)
            #some module inits here...

        def foo(self):
            #some use of the module inits here...
            self.response.write('foo called')
will this be correct ?

also, you told me that the start method of a module is called each time a
module directive reference this module. so, the init method is called only
once at server initialization ? or is init called for each request ?
said differently: can we use the init method for some module level
initializations and start for request level initializations ?

thank you.

--
rien

ps: as you see, i started writing my own modules... very interesting
feature, which allows great flexibility !

Re: [Spyce-users] import problems

[Rimon B. <ba...@cs...>]

Hi Rien,

>I would like to have more information on the 'include' module. it seems
>that the include directive diverge from the include module by that the
>directive it interpreted at compile time, and the module at runtime (if
>we can speak of runtime and compile time). so, a script included by the
>include module seems not inherit the behavior from it's parent: like a
>specified compression, a declared stdout module... so, do I have to
>repeat the 'module' directives in the included file ?

Yes.

Let me first get some terminology straight. I will talk about an
"including" and an "included" file. The [[.include]] directive does static
inclusion. Think of this as you would of a #include directive in C/C++.
The actual text of the file is pasted in that location, by the
preprocessor before compilation. The include module (specifically, the
include.spyce()  function) performs a dynamic include. It will run the
included Spyce in a new environment. All the output from the included
Spyce processing will be output at the include location of the including
Spyce. Also, any modifications made by the included Spyce to the response
headers will be made to the original response of the including Spyce.

>btw, i used the compress module. it's fine, but missing one other
>function: compress.lines(), to remove EOLs so that there is no more
>spaces. Rimon, beware if you want to implement that, i think you will
>have to replace the EOLs by a spaces, not only strip them (EOLs are
>whitespaces).

compress.spaces() should already take care of this. If you have an
instance where it does not, please email me an example, and I will fix it.

>also, how does the compress module behave with <PRE> tags (and the
>compact directive too) ? i think we will have to abandon any behavior
>with the PRE tag, because of CSSs. there is a CSS selector called
>'white-space' which if set to the value 'pre' allows any html tag to
>bahave like PRE. so I don't think you will be able to parse any css,
>because it would be a useless time consuming operation. this have to be
>thought...

The <pre> tag is completely ignored by both the dynamic and static
compation/compression methods. I am already aware of this "problem", and
may address it in the future, though it is unlikely. The reason that I
have not implemented a simple heuristic is because it is difficult
(discussed below), and it would be difficult for the user to understand
what is going on.

In the static case, it is difficult to implement because I only analyze
static strings.  I have no idea what text the dynamic parts will generate.
If it's a <pre> tag that comes out of some 'print' statement, I have no
way of knowing. On the bright side, the user could always protect a <pre>
section of the file as follows:

  [[.compact mode=off]]
  <pre>
    text that is
    preformatted
  </pre>
  [[.compact]]

Therefore, I do not consider this to be a significant problem, because a)
it is not possible to solve in general, statically, b) it is easy enough
to achieve the <pre> functionality you desire by changing the compacting
mode, and c) you could always turn off compaction altogether and save the
hassle -- this is just a small bandwidth optimisation.

In the dynamic case, the entire output passes before the dynamic filter.
That includes any <pre> tags that are dynamically generated at the server.
But there is a different form of dynamicity. What about Javascript code
that dynamically generates text at the client? Incidentally, I am also
removing spaces inside <script>, and that's a potentially much bigger
problem! Secondly, as you state, the CSS allows other tags to have <pre>
behaviour, and I'm certainly not going to parse CSS to find out which
ones. My response in this case, is similar to the static case. If you
can't remove every last space (it's not that much, once you have done
static compression), what's the big deal? I just don't consider this to be
a huge functionality hit. Correctness is far more important, and by
keeping the space-elimination algorithms very simple, I ensure that users
are not confused. If the algorithm does not apply (ie. is harmful) then
simply do not use it. But I want users to clearly understand what it is
doing, so that they can make that decision correctly.

On the other hand, we're not talking about some language feature here.
We're talking about a runtime function in a module! If you want two space
compaction functions, you can have two, or as many as you like. Rien, I
encourage you to write more sophisticated space elimination functions in
your own runtime modules. You are not restricted to using my simple ones.
Just have a look at how the 'compress' module works and copy it. After
creating your own module, with an improves compaction algorithm, simply
drop it in the current Spyce directory and you can use it like a standard
module. If you come up with a really nice algorithm, perhaps I could add
it to the standard compress module, and we would have both.

Thanks for the feedback.

All the best,
Rimon.
-- 
 * Rimon Barr       Ph.D. candidate, Computer Science, Cornell University
 | ba...@cs... - http://www.cs.cornell.edu/barr - Y!IM: batripler
 |
 | Understanding is a kind of ecstasy.
 +----                                   -- Carl Sagan

[Spyce-users] include, compress and the like...

[Adrien P. <sto...@cl...>]

Hello !

Here it is ! I started playing again with spyce !

I would like to have more information on the 'include' module.
it seems that the include directive diverge from the include module by that
the directive it interpreted at compile time, and the module at runtime (if
we can speak of runtime and compile time).
so, a script included by the include module seems not inherit the behavior
from it's parent: like a specified compression, a declared stdout module...

so, do I have to repeat the 'module' directives in the included file ?

thanks

btw, i used the compress module. it's fine, but missing one other function:
compress.lines(), to remove EOLs so that there is no more spaces. Rimon,
beware if you want to implement that, i think you will have to replace the
EOLs by a spaces, not only strip them (EOLs are whitespaces).
also, how does the compress module behave with <PRE> tags (and the compact
directive too) ? i think we will have to abandon any behavior with the PRE
tag, because of CSSs. there is a CSS selector called 'white-space' which if
set to the value 'pre' allows any html tag to bahave like PRE. so I don't
think you will be able to parse any css, because it would be a useless time
consuming operation. this have to be thought...

--
rien

[Spyce-users] spyce v1.1.39

[Rimon B. <ba...@cs...>]

Spyce v1.1.39 released 25 Aug 2002

Get it at:
  http://spyce.sourceforge.net

After a long hiatus, a rather big release...
Biggest changes documented at:
  http://spyce.sourceforge.net/doc_mod_compress.html
  http://spyce.sourceforge.net/doc_conf_proxy.html
  http://spyce.sourceforge.net/doc_lang_runtime.html

Enjoy,
Rimon.
----

Partial change log:

v1.1.39
  modified how filter module injects itself into output stream
  added response.addFilter() to allow piped functionality
    on the output stream, modules can insert write, writeStatic,
    writeExpr, flush and clear handlers
  added compress module for dynamic compression functionality
  compress module documentation
  renamed filter module to transform (name conflict with Python builtin)
  sys.path forced to be absolute before changing directory in CGI mode
  bugfix - spyce path trimmed to just filename when directory changed for
    CGI processing
  bugfix - spyce web server closes sockets

v1.1.38
  spyce can now run as a (proxy) web server
    spyce -l [-p port] <server root>

v1.1.37
  spyceDone exception to stop spyce processing
    raise spyceDone, see gif.spy, fileupload.spy examples
  response.close() deprecated
    not needed with spyceDone functionality
  cPickle used in session module
    improved session serialization performance

v1.1.36
  redirect.externalRefresh now has url= in string
  internal redirect fixed
  bug fix - consecutive compact line removal now possible
  examples added: hello2.spy, form.spy
  handle ISINDEX CGI queries that have extra command-line parameters
  Status CGI header used for spyce redirect return codes

v1.1.35
  bug - fixed cgi chdir in case of local directory
  request - invoke spyce engine programmatically with spyce string
  source tarball does not contain extra CVS junk

v1.1.34
  fixed apache config bug in windows installer

...

Re: [Spyce-users] import problems

[Rimon B. <ba...@cs...>]

Hi Rien,

> ok, i found the problem, MySQLdb module needs a threadless python to run
> under mod_python. sorry, spyce has no problem !

Good to hear! Problem resolutions like that are the best kind. :-)

> i read the documentation about the compact directive better than the first
> time, and now i understand how it is supposed to work. in fact i was not
> expecting this behavior, especially for the full compact mode. in full
mode,
> i was expecting spyce to remove *all* non visible whitespaces, that is,
> replacing all consecutive whitespace (by whitespace, i mean tab newline
and
> space) by a single space character. that's why i was thinking it was not
> working.

Full compact mode *does* replace "all non-visible whitespaces" in static
strings. The problem that you may be running into is as follows. Let's say
that you have the following code:

[[ for i in range(10): { ]]
  [[=i]]
[[ } ]]

To the untrained eye, it may seem like there should be exactly one space
between each number. That is NOT the case. There are two static strings
there. There is a static string that begins after the ]] on the first line,
and ends at the [[ on the second line. The second static string inside the
loop starts at the end of the ]] on the second line, and ends at the [[ on
the third line. The full compact mode compresses both of these strings down.
But it can never eliminate either one of them altogether. There will be, at
minimum, both strings to ensure that the semantics of the semantics of the
program is not changed. The compression is performed statically, not
dynamically. And static analysis can not do what you are requesting.

The point of the compact mode is that it saves a significant number of
spaces, with zero overhead. If you are looking for more compression, it can
be done at runtime. You can use the mod_gzip Apache module. Or, wait until I
(or you) write the compress Spyce module. That Spyce module will compress
output in various ways. The first is to dynamically search for all
consecutive spaces (and non-visible characters), and eliminate them. The
second option, if the browser can support it, is to use the zlib compression
on the output stream.

> another thing to explain: why can't we inherit the environment of
mod_python
> ? there is a mod_python directive that allows to import a module at
> interpreter initialization. but while it is imported into mod_python, it
is
> not imported into spyce. this could be very useful, since this import
allows
> to do some lengthy initialization tasks at server start, not at request
> time.

This is a good point, however, I do not want to implement it the way that
you are talking about. There is a dependence on mod_python there that I
don't like. In future, there will be a feature to perform some code at Spyce
startup. ie. there will be a startup function that you are able to write. As
it is, performance is not suffering greatly. If you would give me some
practical applications that necessitate this, I would be happy to move it up
higher on the priority list. As it stands, I don't see how it would be of
radical benefit.

> third thing, and last for today, how do we control the return code for a
> request ? returning a 400 OK is cool, returning 301 or 302 is great, but
> returning anything (from 100 to 505) is fantastic. note that i did not try
> to return those codes in the Status header field.

Ah, that is something I need to document better, and perhaps I should add a
function in the response module. For now, you can set the
response.returncode variable. It will be returned at the end of spyce
processing. I haven't tested it though. I'll look at it, and get back to
you.

> ha, i forgot a big problem: on windows, running spyce in a command line
does
> not produce any output.

Will check. Thanks for reporting this.

All the best,
Rimon.

Re: [Spyce-users] import problems

[Adrien P. <sto...@cl...>]

From: "Rimon Barr" <ba...@cs...>
> Glad to have you here. Perhaps you can report your problems to SourceForge
> so that they can improve their system. The mailing list is out of my
> control.

the problem is that when i want to send a mail to sourceforge, i get the
same problem as for subscribing to the mailing list. it's their whole smtp
server which sucks. but thankx anyway !

> The documentation the pages that you should read before writing a Spyce
> module are:
>   http://spyce.sourceforge.net/doc_mod.html
>   http://spyce.sourceforge.net/doc_mod_new.html
> and you should go and look at the existing modules, as examples. If you
> can make a suggestion on how to make this more obvious, I'd be happy to
> consider it.

ok, in fact i already had read some existing modules implementation. i was
just missing the web page.


> >the biggest one, and the only one i will submit today is: when i try to
> >import MySQLdb module from a spyce script, the module is corrupted and
> >all important methods, like Connect or such disappears (i mean,
> >dir(MySQLdb) does not show them), while this module works perfectly on a
> >python shell.

ok, i found the problem, MySQLdb module needs a threadless python to run
under mod_python. sorry, spyce has no problem !

now let's talk a bit using spyce.
i read the documentation about the compact directive better than the first
time, and now i understand how it is supposed to work. in fact i was not
expecting this behavior, especially for the full compact mode. in full mode,
i was expecting spyce to remove *all* non visible whitespaces, that is,
replacing all consecutive whitespace (by whitespace, i mean tab newline and
space) by a single space character. that's why i was thinking it was not
working.
another thing to explain: why can't we inherit the environment of mod_python
? there is a mod_python directive that allows to import a module at
interpreter initialization. but while it is imported into mod_python, it is
not imported into spyce. this could be very useful, since this import allows
to do some lengthy initialization tasks at server start, not at request
time.
third thing, and last for today, how do we control the return code for a
request ? returning a 400 OK is cool, returning 301 or 302 is great, but
returning anything (from 100 to 505) is fantastic. note that i did not try
to return those codes in the Status header field.

ha, i forgot a big problem: on windows, running spyce in a command line does
not produce any output.

cheers ! :)

--
rien

ps: (i have to stop criticizing everything i'm working with...)

Re: [Spyce-users] import problems

[Rimon B. <ba...@cs...>]

On Thu, 8 Aug 2002, Adrien Plisson wrote:

>Hello ! i'm finally here after having had many troubles subscribing to
>the list. (lists.sourceforge.net wants to be too RFC822 compliant so I
>had to cheat it...)

Hello Rien,

Glad to have you here. Perhaps you can report your problems to SourceForge
so that they can improve their system. The mailing list is out of my
control.

>I'm really new to spyce. It seemed to me to be a good way to achieve my
>goals, but i ran into trouble at first use. since the documentation is
>not complete (where is the spyceModule writer's guide i heard about ???),
>i can't find any solutions to my problems.

The documentation the pages that you should read before writing a Spyce
module are:
  http://spyce.sourceforge.net/doc_mod.html
  http://spyce.sourceforge.net/doc_mod_new.html
and you should go and look at the existing modules, as examples. If you
can make a suggestion on how to make this more obvious, I'd be happy to
consider it.

If you problems that you can't solve... That is what this list is for.

>the biggest one, and the only one i will submit today is: when i try to
>import MySQLdb module from a spyce script, the module is corrupted and
>all important methods, like Connect or such disappears (i mean,
>dir(MySQLdb) does not show them), while this module works perfectly on a
>python shell.

I'm not sure where the problem lies. I don't have enough information to
determine the exact cause. It might have something to do with the
mod_python environment. Have you tried to run the scripts via CGI, FastCGI
or even via the command-line just to test? This uses a standard Python
environment, not one that is embedded inside Apache, and may solve your
problem. If you can perform this test, then we will be able to further
narrow down the problem and hopefully understand the cause.

>here is my code:
>[[.compact mode='full']]
>[[.module name='stdout']]

And later you write...
>(btw, directive compact does not seem to work)

It seems to work for me, and a few others. Perhaps you have uncovered a
bug. Could you give an example of where this is not functioning? Input
file and output would be nice. If you are not using any browser
information, then you can even run it from the command-line:
  spyce foo.spy
If you switch between the different compacting modes you should be able to
see the difference in whitespace.

>[[\
> import MySQLdb
>
> db_con = MySQLdb.connect(user='user', passwd='passwd', db='dbname')
> db_cur = db_con.cursor()
>]]
>
><html>
> <body>
>  [[\
>   for i in range(db_cur.execute('SELECT  * FROM links;')):
>    name, href = db_cur.fetchone()
>    print '<A HREF="' + href + '">' + name + '</a><BR>'
>  ]]
> </body>
></html>
>
>and here is what i get:
>Spyce exception:
>  index2.html:5-10, in (main):
>    import MySQLdb
>
>db_con = MySQLdb.connect(user='user', passwd='passwd', db='dbname')
>db_cur = db_con.cursor()
>
>AttributeError: 'MySQLdb' module has no attribute 'connect'
>anyone see where the problem might be ?

Also, can you tell me what dir(MySQLdb) does show? Can you determine where
this module was loaded from? Are you sure this is the right module that
you expected?

All the best,
Rimon.
-- 
 * Rimon Barr       Ph.D. candidate, Computer Science, Cornell University
 | ba...@cs... - http://www.cs.cornell.edu/barr - Y!IM: batripler
 |
 | Understanding is a kind of ecstasy.
 +----                                   -- Carl Sagan

[Spyce-users] import problems

[Adrien P. <sto...@cl...>]

Hello !

i'm finally here after having had many troubles subscribing to the list.
(lists.sourceforge.net wants to be too RFC822 compliant so I had to cheat
it...)

I'm really new to spyce. It seemed to me to be a good way to achieve my
goals, but i ran into trouble at first use. since the documentation is not
complete (where is the spyceModule writer's guide i heard about ???), i
can't find any solutions to my problems.

the biggest one, and the only one i will submit today is:
when i try to import MySQLdb module from a spyce script, the module is
corrupted and all important methods, like Connect or such disappears (i
mean, dir(MySQLdb) does not show them), while this module works perfectly on
a python shell.

here is my code:
[[.compact mode='full']]
[[.module name='stdout']]

[[\
 import MySQLdb

 db_con = MySQLdb.connect(user='user', passwd='passwd', db='dbname')
 db_cur = db_con.cursor()
]]

<html>
 <body>
  [[\
   for i in range(db_cur.execute('SELECT  * FROM links;')):
    name, href = db_cur.fetchone()
    print '<A HREF="' + href + '">' + name + '</a><BR>'
  ]]
 </body>
</html>

and here is what i get:
Spyce exception:
  index2.html:5-10, in (main):
    import MySQLdb

db_con = MySQLdb.connect(user='user', passwd='passwd', db='dbname')
db_cur = db_con.cursor()

AttributeError: 'MySQLdb' module has no attribute 'connect'

anyone see where the problem might be ?
(btw, directive compact does not seem to work)

--
rien

ps: running apache 1.3.23, python 2.1, mod_python 2.7.4, and spyce 1.1.38

Re: [Spyce-users] [Q] Dictionary type

[Rimon B. <ba...@cs...>]

Aha... I see your problem now. Thank you for the code example, and sorry
for confusing lists and dictionaries in my earlier reply. This is not a
matter of grammar, but of function definition.

response.write behaves just like sys.stdout.write; it's a function of a
file type. You can not write() arbitrary types as parameters, only
strings. Numbers, dictionaries, lists, etc... will not work. This is the
standard Python convention, and Spyce adheres to it. (You can try doing
the same with sys.stdout in a python shell, and you'll see this.) The
reason that your second example works is because a[1] happens to be a
string.

There are many way to achieve what you are looking for:

1.  response.write(str(a))
 or
2.  [[=a]]
 or
3.  [[.module name=stdout]]
    [[print a,]]

The first alternative converts dictionary 'a' into a string first. The
second alternative, uses the Spyce expression evaluation syntax, and
prints out the (stringified) result of the expression 'a'. The third
alternative is to import the stdout module. This replaces sys.stdout with
response, and all print commands will output to the browser. Note that
there will be an extra space created by the print.

All the best,
Rimon.

On Sat, 3 Aug 2002, YOON, Joo-Yung wrote:

>I think [1,2,3] is a list type, not a dictionary.
>
>My code example is
>
>a = {1:'a', 2:'b', 3:'c'}
>response.write(a)
>
>Then the spyce says it has found a dictionary.
>
>But this works.
>response.write(a[1])
>
>Maybe I'm wrong in comprehending the spyce grammar.
>
>On Fri, Aug 02, 2002 at 07:35:42PM -0400, Rimon Barr wrote:
>>
>> >The dictionary type can not be printed (except by indexing) nor passed to
>> >my functions. I looked up at the documention, but could not find any
>> >valuable info on this.  Only it mentioned about the curly braces. Could
>> >anyone teach me where I can see the info on this matter?
>>
>> Can you give a code example that is giving you problems?
>>
>> Here is a short example that prints a dictionary type:
>>   [[=[1,2,3] ]]
>>
>> Type that into some file, say dict.spy, and type:
>>   spyce dict.spy
>>
>> You'll see that it works. The result is:
>>   [1, 2, 3]
>>
>> Make sure to separate the ']' and the ']]' with a space.
>>
>> Rimon.
>> --
>>  * Rimon Barr       Ph.D. candidate, Computer Science, Cornell University
>>  | ba...@cs... - http://www.cs.cornell.edu/barr - Y!IM: batripler
>>  |
>>  | Understanding is a kind of ecstasy.
>>  +----                                   -- Carl Sagan
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> Spyce-users mailing list
>> Spy...@li...
>> https://lists.sourceforge.net/lists/listinfo/spyce-users
>
>

-- 
 * Rimon Barr       Ph.D. candidate, Computer Science, Cornell University
 | ba...@cs... - http://www.cs.cornell.edu/barr - Y!IM: batripler
 |
 | Understanding is a kind of ecstasy.
 +----                                   -- Carl Sagan

Re: [Spyce-users] [Q] Dictionary type

[YOON, Joo-Y. <yjy...@ar...>]

I think [1,2,3] is a list type, not a dictionary.  

My code example is

a = {1:'a', 2:'b', 3:'c'}
response.write(a)

Then the spyce says it has found a dictionary.

But this works.
response.write(a[1])

Maybe I'm wrong in comprehending the spyce grammar.

On Fri, Aug 02, 2002 at 07:35:42PM -0400, Rimon Barr wrote:
> 
> >The dictionary type can not be printed (except by indexing) nor passed to
> >my functions. I looked up at the documention, but could not find any
> >valuable info on this.  Only it mentioned about the curly braces. Could
> >anyone teach me where I can see the info on this matter?
> 
> Can you give a code example that is giving you problems?
> 
> Here is a short example that prints a dictionary type:
>   [[=[1,2,3] ]]
> 
> Type that into some file, say dict.spy, and type:
>   spyce dict.spy
> 
> You'll see that it works. The result is:
>   [1, 2, 3]
> 
> Make sure to separate the ']' and the ']]' with a space.
> 
> Rimon.
> -- 
>  * Rimon Barr       Ph.D. candidate, Computer Science, Cornell University
>  | ba...@cs... - http://www.cs.cornell.edu/barr - Y!IM: batripler
>  |
>  | Understanding is a kind of ecstasy.
>  +----                                   -- Carl Sagan
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Spyce-users mailing list
> Spy...@li...
> https://lists.sourceforge.net/lists/listinfo/spyce-users

-- 
YOON, Joo-Yung  
yjy...@ar...
BooChun Korea

Re: [Spyce-users] [Q] Dictionary type

[Rimon B. <barr@CS.Cornell.EDU>]

>The dictionary type can not be printed (except by indexing) nor passed to
>my functions. I looked up at the documention, but could not find any
>valuable info on this.  Only it mentioned about the curly braces. Could
>anyone teach me where I can see the info on this matter?

Can you give a code example that is giving you problems?

Here is a short example that prints a dictionary type:
  [[=[1,2,3] ]]

Type that into some file, say dict.spy, and type:
  spyce dict.spy

You'll see that it works. The result is:
  [1, 2, 3]

Make sure to separate the ']' and the ']]' with a space.

Rimon.
-- 
 * Rimon Barr       Ph.D. candidate, Computer Science, Cornell University
 | ba...@cs... - http://www.cs.cornell.edu/barr - Y!IM: batripler
 |
 | Understanding is a kind of ecstasy.
 +----                                   -- Carl Sagan

[Spyce-users] [Q] Dictionary type

[YOON, Joo-Y. <yjy...@ar...>]

Hi, all!

The dictionary type can not be printed (except by indexing) nor passed
to my functions.  

I looked up at the documention, but could not find any valuable info on
this.  Only it mentioned about the curly braces. 

Could anyone teach me where I can see the info on this matter?
-- 
YOON, Joo-Yung  
yjy...@ar...
BooChun Korea

[Spyce-users] spyce v1.1.36

[Rimon B. <ba...@cs...>]

Spyce v1.1.36 released 1 Aug 2002

Get it at:
  http://spyce.sourceforge.net

Lots of little things that add up...
----

Partial change log:

v1.1.37
  spyceDone exception to stop spyce processing
  cPickle used in session module

v1.1.36
  redirect.externalRefresh now has url= in string
  internal redirect fixed
  bug fix - consecutive compact line removal now possible
  examples added: hello2.spy, form.spy
  handle ISINDEX CGI queries that have extra command-line parameters
  Status CGI header used for spyce redirect return codes

v1.1.35
  bug - fixed cgi chdir in case of local directory
  request - invoke spyce engine programmatically with spyce string
  source tarball does not contain extra CVS junk

v1.1.34
  fixed apache config bug in windows installer

v1.1.33
  appended current Spyce file's directory to sys.path

v1.1.32
  minor documentation tweaks
  names attribute added to [[.module ]] tag
  request.__getitem__() added
  chdir in cgi mode

v1.1.31
  windows installer improved: apache configuration and restart
  fixed - handling of initial spaces in multi-line strings in python
chunks

v1.1.30
  red page marker in docs
  created undefined windows lock variables

v1.1.29
  documentation split up
  rpm is now noarch

v1.1.28
  include.dump() now has binary option
  stdout changed to binary mode on windows for cgi purposes
  fixed session_dir handler bug on windows
...

[Spyce-users] spyce v1.1.29

[Rimon B. <barr@CS.Cornell.EDU>]

Spyce v1.1.29 released 16 Jul 2002

Get it at:
  http://spyce.sourceforge.net

Much since the previous release... split up the documentation. There is
now a Windows installer. Fixed some bugs on the Windows side and with the
session_dir handler. Implemented fcgi on Windows. (An Apache 2.0 mod_fcgi
is expected in the next few weeks.)
---

Partial change log:

v1.1.29
  documentation split up
  rpm is now noarch

v1.1.28
  include.dump() now has binary option
  stdout changed to binary mode on windows for cgi purposes
  fixed session_dir handler bug on windows

v1.1.27
  fcgi implemented on windows too
  windows installer

v1.1.26
  fixed - nasty bug with the new module behaviour
  small improvements to documentation and examples
  improved request.uri() function

v1.1.25
  fixed - fcgi module broke on windows

v1.1.24
  line compaction improved
  module behaviour on include.spyce() defined

v1.1.23
  lots of changes so that: it works on Python 1.5.2 now too!
  file-based session handler now uses pid, and file locks
  live examples on sourceforge
...

[Spyce-users] spyce v1.1.25

[Rimon B. <ba...@cs...>]

Spyce v1.1.25 released 10 Jul 2002

Get it at:
  http://spyce.sourceforge.net

Fixed a Windows bug that creeped in, improved the compaction algorithm,
defined module behaviour on includes, and put *live* examples up on
SourceForge using cgi-bin. (Another stable release... perhaps we'll go to
1.2.0 when I run out of steam.)
---

Partial change log:

v1.1.25
  fixed - fcgi module broke on windows

v1.1.24
  line compaction improved
  module behaviour on include.spyce() defined

v1.1.23
  lots of changes so that: it works on Python 1.5.2 now too!
  file-based session handler now uses pid, and file locks

v1.1.22
  fixed Python v2.1.1-related bugs.
  improved installation process and documentation
  rpm more likely to succeed - uses fcgi or drops back to cgi
  no longer mod_python based by default

v1.1.21 (faulty release)
  stochastic session clean up; no more threading dependency
  documentation: better installation notes
  peep-hole optimizer

...

[Spyce-users] spyce v1.1.23

[Rimon B. <ba...@cs...>]

Spyce v1.1.23 released 8 Jul 2002

Get it at:
  http://spyce.sourceforge.net

Works under Python 1.5.2 and up now, which means that it will run on a
fresh RedHat machine. Users are still recommended to use Python 2.1 or
higher, because nested scoping functionality simplifies some common
things. Only related documentation and code changes.
---

Partial change log:

v1.1.23
  lots of changes so that: it works on Python 1.5.2 now too!
  file-based session handler now uses pid, and file locks

v1.1.22
  fixed Python v2.1.1-related bugs.
  improved installation process and documentation
  rpm more likely to succeed - uses fcgi or drops back to cgi
  no longer mod_python based by default

v1.1.21 (faulty release)
  stochastic session clean up; no more threading dependency
  documentation: better installation notes
  peep-hole optimizer

v1.1.20 (faulty release)
  created explicit (swappable) cache infrastructure
  BUG ** Spyce also works on Python v2.1
  request - request.post(),post1() works in includes
  documentation: cheetah install, ...

v1.1.19
  filter module

...

[Spyce-users] spyce v1.1.22

[Rimon B. <ba...@cs...>]

Spyce v1.1.22 released 7 Jul 2002

Get it at:
  http://spyce.sourceforge.net

.20, and .21 were both faulty releases. This release looks to be much
better. My apologies. The default installation procedure has been improved
and should work automatically in more cases now. Basically, the dependence
on mod_python, which many users had trouble with, is now gone. Spyce still
works under mod_python, but this is not the .rpm method of installation.

Enjoy,
Rimon.
---

Partial change log:

v1.1.22
  fixed Python v2.1.1-related bugs.
  improved installation process and documentation
  rpm more likely to succeed - uses fcgi or drops back to cgi
  no longer mod_python based by default

v1.1.21 (faulty release)
  stochastic session clean up; no more threading dependency
  documentation: better installation notes
  peep-hole optimizer

v1.1.20 (faulty release)
  created explicit (swappable) cache infrastructure
  BUG ** Spyce also works on Python v2.1
  request - request.post(),post1() works in includes
  documentation: cheetah install, ...

v1.1.19
  filter module

v1.1.18
  fcgi support added
  X-Spyce header added
  documentation: how to write new modules

...

[Spyce-users] spyce v1.1.21

[Rimon B. <ba...@cs...>]

Spyce v1.1.21 released 7 Jul 2002

Get it at:
  http://spyce.sourceforge.net

---

Partial change log:

v1.1.21
  stochastic session clean up; no more threading dependency
  documentation: better installation notes
  peep-hole optimizer

v1.1.20
  created explicit (swappable) cache infrastructure
  Spyce also works on Python v2.1
  request - request.post(),post1() works in includes
  documentation: cheetah install, ...

v1.1.19
  filter module

v1.1.18
  fcgi support added
  X-Spyce header added
  documentation: how to write new modules

v1.1.17
  feature request - compaction algorithm improved

...

[Spyce-users] spyce v1.1.20

[Rimon B. <ba...@cs...>]

Spyce v1.1.20 released 7 Jul 2002

Get it at:
  http://spyce.sourceforge.net

---

Partial change log:

v1.1.20
  created explicit (swappable) cache infrastructure
  Spyce also works on Python v2.1
  request - request.post(),post1() works in includes
  documentation: cheetah install, ...

v1.1.19
  filter module

v1.1.18
  fcgi support added
  X-Spyce header added
  documentation: how to write new modules

v1.1.17
  feature request - compaction algorithm improved

v1.1.16
  generalised session.setHandler (session handler selection mechanism)
  gdbm, bsd db session handlers added

...

[Spyce-users] spyce v1.1.19

[Rimon B. <ba...@cs...>]

Spyce v1.1.19 released 5 Jul 2002

Get it at:
  http://spyce.sourceforge.net

---

Partial change log:

v1.1.19
  filter module

v1.1.18
  fcgi support added
  X-Spyce header added
  documentation: how to write new modules

v1.1.17
  feature request - compaction algorithm improved

v1.1.16
  generalised session.setHandler (session handler selection mechanism)
  gdbm, bsd db session handlers added

v1.1.15
  minor makefile and rpm script changes
  handling of multi-line strings in python code
  response.flush() added

...

[Spyce-users] spyce v1.1.18

[Rimon B. <ba...@cs...>]

Spyce v1.1.18 released 5 Jul 2002

Get it at:
  http://spyce.sourceforge.net

---

Partial change log:

v1.1.18
  fcgi support added
  X-Spyce header added
  documentation: how to write new modules

v1.1.17
  feature request - compaction algorithm improved

v1.1.16
  generalised session.setHandler (session handler selection mechanism)
  gdbm, bsd db session handlers added

v1.1.15
  minor makefile and rpm script changes
  handling of multi-line strings in python code
  response.flush() added

v1.1.14
  wrappers to check python version

...

[Spyce-users] spyce v1.1.17

[Rimon B. <ba...@cs...>]

Spyce v1.1.17 released yesterday (2 Jul 2002)

Get it at:
  http://spyce.sourceforge.net

---

Partial change log:

v1.1.17
  feature request - compaction algorithm improved

v1.1.16
  generalised session.setHandler (session handler selection mechanism)
  gdbm, bsd db session handlers added

v1.1.15
  minor makefile and rpm script changes
  handling of multi-line strings in python code
  response.flush() added

v1.1.14
  wrappers to check python version

...

[Spyce-users] spyce v1.1.16

[Rimon B. <ba...@cs...>]

Spyce v1.1.16 released on 2 July 2002

Get it at:
  http://spyce.sourceforge.net

---

Partial change log:

v1.1.16
  generalised session.setHandler (session handler selection mechanism)
  gdbm, bsd db session handlers added

v1.1.15
  minor makefile and rpm script changes
  handling of multi-line strings in python code
  response.flush() added

v1.1.14
  wrappers to check python version

v1.1.13
  added new language construct: "Python chunks"

...