November 1999 - Zope-Dev

OT: inferno
by Simon Michael 11 Nov '99

11 Nov '99

Patrick Phalen <zope(a)teleo.net> writes: > Q. Why didn't Inferno kick Java's ass before Java got so much hype > and attention? > A. Because Lucent's CEO didn't even know it existed until well after > the WWW got big. :( His finding out about it stopped it dead, as far we and the world at large is concerned - it's a commercial asset now. We'll see it again in 5 years, perhaps. :) so-it-seems-ly-yrs, -Simon

1 0

Re: [Zope-dev] Character codes
by sergey2b 11 Nov '99

11 Nov '99

add in z2.py #z2.py import locale locale.setlocale(locale.LC_ALL, "fr") -----Original Message----- From: Hannu Krosing <hannu(a)tm.ee> To: Alexandre Ratti <alex(a)gabuzomeu.net> Cc: zope-dev(a)zope.org <zope-dev(a)zope.org> Date: 11 ноября 1999 г. 21:56 Subject: Re: [Zope-dev] Character codes >Alexandre Ratti wrote: >> >> Hello, >> >> when displaying the raw content of a list with this code: >> >> <dtml-call "REQUEST.set('myOptionList',['И', 'Ю', 'Ы', 'Х'])"> >> <dtml-var myOptionList> >> >> (The list values are extended characters for French accented letters. They >> may not display correctly in your mailer.) >> >> I get this output: >> >> ['\351', '\340', '\371', '\350'] > >I guess it is called iso-8559-1 ? > >what you see are octal (NON)ASCII codes for the characters. > >The list is composed of 4 one-character strings, each shown as its octal >code if outside the range 32 <= x < 127 > >----------------- >Hannu > >_______________________________________________ >Zope-Dev maillist - Zope-Dev(a)zope.org >http://lists.zope.org/mailman/listinfo/zope-dev > No cross posts or HTML encoding! >(Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > > >

2 1

Re: [Zope-dev] Character codes
by Alexandre Ratti 11 Nov '99

11 Nov '99

Hi Hannu, Thanks for this information. I didn't notice it was ASCII char value in octal form. Cheers. Alexandre At 10:57 11/11/1999 -0800, you wrote: >Date: Thu, 11 Nov 1999 20:49:04 +0200 >From: Hannu Krosing <hannu(a)tm.ee> >To: Alexandre Ratti <alex(a)gabuzomeu.net> >Cc: zope-dev(a)zope.org >Subject: Re: [Zope-dev] Character codes > >Alexandre Ratti wrote: (snip) >I guess it is called iso-8559-1 ? > >what you see are octal (NON)ASCII codes for the characters. > >The list is composed of 4 one-character strings, each shown as its octal >code if outside the range 32 <= x < 127

1 0

Re: [Zope-dev] Zope-beta failure on OSF/Alpha
by Janko Hauser 11 Nov '99

11 Nov '99

Gilles lavaux writes: > Hello, > > I run Zope on alpha, but on linux alpha(RH5.1 and RH6.0) > Zope1.10.3b1 works fine, and we have developped a lot of things on it: > inventory database, user helpdesk ticket system, team activity monitoring. > All this with a Postgresql database( which is wonderfull). > > But with Zope2 I had problems, things like confera or squishdot doesn't > works(impossible to posr a article) and the soft we have in zope1 doesn't > run completly. On this topic I have a request for the DC guys: you should do > a 'test script' to allow the new users to test a Zope installation (all the > DC products & functionalitys). This way it would be easy to be shure that > everything if ok. > > My personal conclusion is: running on alpha add some troubles. and Jeff Rush writes: > Sorry to hear of your problem. Are you by chance running > Red Hat Linux/Alpha? I do know that Red Hat took my Zope > RPMs, rebuilt them (w/o change) on an Alpha and they said > it all worked fine. Personally I've never seen an Alpha so I > can't speak with authority but it -ought- to work. > > Or are you running the 2.1.0 beta 1 release? > I use the 2.1.0 Beta, but had a similar problem with the stable source, although I didn't looked further back than. According to the wonderful platform.py the system is 'OSF1-V4.0-alpha-alpha'. The exact error is: Stack overflow: pid 26669, proc python, addr 0x140889ff8, pc 0x120049ef0 Python runs fine on normal stuff, although I haven't tested the threading stuff. Is there a simple test for threading alone (python make test works for threads)? I have in the meantime compiled the extensions without optimization, which does not change anything. Is it ok to assume that one can conclude from the fact that zope runs under redhat there are no inherent problems with 64 bit machines? Something more suspicious. I can't lookup documents past the initial screen over http but can do this over ftp. Can one assume that the ZODB subsystem is working, can I test this in other ways? Thanks nevertheless, __Janko

2 1

Re: [Zope-dev] Zope-beta failure on OSF/Alpha
by Gilles lavaux 11 Nov '99

11 Nov '99

Hello all -Jeff Rush wrote: > > I know little about alphas but one question, if I may. Did you compile > the Zope yourself from the source tarball or use the RPMs that Red Hat > makes available for Linux/Alpha? > > The reason I ask is that I created the RPMs and Red Hat then tested > them on all of their platforms and reported that it works on all. Now > I'm wondering whether their testing was extensive enough and > they really don't work on an alpha. > I compiled the Zope2 from source myself, I also have compiled the new python(1.5.2). I didn't know that Red-hat has a RPM for the version 2 of Zope, where is it?? Anyway I think that it can not works directly out of the Red-hat instalation because of the fact that pyhton with red-hat 6.0 is version 1.5.10 whithout thread. So you have to recompile or reinstall python. For Zope itself, a lot of things works on 64bits, ZODB ,DA , ftp access, http,etc.. The only2 problems I have seen is the failure during a posting of article in confera/sqhisdot: ############################################ Zope Error Zope has encountered an error while publishing this resource. Error Type: SystemError Error Value: NULL result without error in call_object ---------------------------------------------------------------------------- ---- Troubleshooting Suggestions ........ Traceback (innermost last): File /home/dev/Zope/lib/python/ZPublisher/Publish.py, line 214, in publish_module File /home/dev/Zope/lib/python/ZPublisher/Publish.py, line 179, in publish File /home/dev/Zope/lib/python/Zope/__init__.py, line 201, in zpublisher_exception_hook (Object: ElementWithAttributes) File /home/dev/Zope/lib/python/ZPublisher/Publish.py, line 165, in publish File /home/dev/Zope/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: addMessage) File /home/dev/Zope/lib/python/ZPublisher/Publish.py, line 102, in call_object (Object: addMessage) File lib/python/Products/Confera/Confera.py, line 310, in addMessage (Object: ElementWithAttributes) File lib/python/Products/Confera/Confera.py, line 196, in setItem (Object: ElementWithAttributes) SystemError: (see above) #################################### And also inside  loops or accessing images/documents properties(but it's maybe my code which is non Zope2 compatible). If someone doesn't have this confera error on RedHat 6.0/digital alpha linux 2-2.5-16/python1.5.2, please let me know. Thanks Gilles

2 1

RE: [Zope-dev] Passing arguments to external methods
by Brian Lloyd 11 Nov '99

11 Nov '99

> I'm currently trying to play with external methods using the > How-To written > by "brian". > > cf. http://www.zope.org/Documentation/How-To/ExternalMethods > > When I'm trying to pass the REQUEST object to my external method, Zope > complains: > > Zope has encountered an error while publishing this resource. > > Error Type: TypeError > Error Value: not enough arguments; expected 2, got 1 > > The method definition looks like "def helloWorld(self, > REQUEST)". And the > call to the external methods looks like "<dtml-var > "helloWorld(REQUEST)">". > So it looks to me like Zope is asking for the "self" > variable, which is a > bit strange since this argument is supposed to be implicit. You aren't trying to call it from another External Method by any chance, are you? Can you post the code/dtml that you are actually using to call the helloWorld method? Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

1 0

RE: [Zope-dev] Passing arguments to external methods
by Emmanuel Rousselle 11 Nov '99

11 Nov '99

At 01:50 PM 11/11/99 -0500, Brian Lloyd wrote: >You aren't trying to call it from another External Method >by any chance, are you? Can you post the code/dtml that >you are actually using to call the helloWorld method? I'm using a DTML Document:  <h2></h2> <p> This is the  Document. </p> <p><dtml-var "helloWorld(REQUEST)"></p>  and it is generating the error I described. On the other hand if I use: <dtml-var "helloWorld(this(),REQUEST)"> instead of: <dtml-var "helloWorld(REQUEST)"> (as recommended by sergey2b(a)mail.ru in a previous post - thanks by the way ...) all work perfectly. -- Emmanuel

1 0

Character codes
by Alexandre Ratti 11 Nov '99

11 Nov '99

Hello, when displaying the raw content of a list with this code: <dtml-call "REQUEST.set('myOptionList',['é', 'à', 'ù', 'è'])"> <dtml-var myOptionList> (The list values are extended characters for French accented letters. They may not display correctly in your mailer.) I get this output: ['\351', '\340', '\371', '\350'] So internally these characters are mapped to character codes. Where can I find reference information about this mapping system? Thanks. Alexandre

2 1

Re: [Zope-dev] Re: [Zope] DTML Syntax contd. + rant
by Simon Michael 11 Nov '99

11 Nov '99

Fully agree with this and the original posting.. after a year on and off zoping, DTML is still hard. And while I may be using it the "wrong way", as it stands every other zope beginner will do the same. What can be done ? NB I post these 2 cents to stimulate ideas and don't imply that DC folk haven't already thought through this whole issue thoroughly. 1. documentation Documenting high-level design patterns and low-level code snippets will definitely help, but I foresee an explosion of recipes. You know something is not optimal when you find yourself saving every useful snippet because you know it will be hard to reinvent. 2. clearer partitioning Clearer partitioning of functionality should clarify the learning curve and reduce frustration. 3. something else What's the ideal situation from user's point of view ? <handwaving> I've heard smalltalk, particularly squeak smalltalk, described as "liquid" and "transparent", meaning you can change things from the application level right down to virtual machine and it's completely consistent. There are no steep jumps in the learning curve requiring a new mindset, language, etc. I'm also reminded of Lucent's inferno where /*everything*/is/in/one/access-controlled/namespace. For zope to be more like this (it already goes a long way), I guess it would be python all the way, with a single conceptually-simple namespace that is always available, from bottom to top. Python is too hard for some ? Keep a limited DTML as an alternative. But to python users we will say: forget dtml; use python, use this single zope namespace, and you can do anything you want, things will work as you expect. Is this (a) what we have already ? (b) attainable ? (c) unrealistic ? Comments welcome. Regards, -Simon

2 1

ngDTML (aka "PSP" or ZScript?) proposal
by Phillip J. Eby 11 Nov '99

11 Nov '99

I have a proposal for a template language which (hopefully) won't be too difficult to create, building as it does on existing works. My proposal is specifically addressed towards making a scripting language that is amenable to learning, doing, and performance, at the expense of being itself valid HTML or XML, and sometimes at the expense of brevity of expression. The syntax I propose we steal from ASP+Python, with one minor alteration. I already have code (written almost 3 years ago and not interfaced to Zope) which parses this syntax, including the necessary machinations to compile out "end if", "end for", etc. and reformat the Python as indented, using the end statements as block delimiters. Such delimiters are necessary when embedding Python in arbitrary text, both for clarity and because indenting is a royal pain in embedded script. Anyway, a basic page might have something like: <% from _ import id, somesqlquery %> Information for <%= _(id) %> <table> <% for record in _(somesqlquery): %> <tr> <td><%= _(record.name1) %></td> <td><%= _(record.name2, fmt="%05.2d") %></td> </tr> <% end for %> </table> Let's go through this and look at the interesting bits. First, we use the name '_' to represent the current Zope namespace. Importing variables from it, or using it as a dictionary always returns those objects *uninterpreted*. However, calling _ with an unnamed first parameter will attempt to execute the object (if it is callable), and then take any keyword parameters as "var"-style formatting arguments. Let's get more specific about the execution part. The execution algorithm is: Push locals() onto the namespace stack, then: 1) If the object has isDocTemp==1, return the result of calling the object with (None,namespace) 2) Otherwise, use ZPublisher's "mapply" function so that the namespace stack can be passed through to the called object's parameters. Thus, if you call a Python function, SQL method, etc., its arguments can automatically be filled in for you as a timesaver. Note that one is under no obligation to use _() to render an object, and that if you want to prevent calling an object you wish to render in its "raw" form, you can simply use str() or repr() or `` on it first. (e.g. _(str(something),fmt="*%s*")) More interesting bits. The Python namespace takes precedence unless you specifically import or otherwise retrieve an object from _. _ itself, REQUEST and RESPONSE, however, are already in the namespace when your method starts, in addition to any parameters defined by the method (ala SQL methods.) There are some special aspects of how import should work. Importing a module should attempt to find an object of that name in the _ namespace, and check the current user's permissions for that object (taking proxy roles into account) before allowing the import. This would allow the use of "PythonModule" objects which you add to a Zope hierarchy and set permissions on. They would import modules only from the "safe" extension and product directories. Of course, any modules generally considered safe could be imported without a lookup/permissons check. Now on to the compilation and execution model. An ngDTML script is rewritten as straight Python code, replacing all <%= expr %> blocks with _.write(expr) and all non-Python text as _.write('text') statements. The resulting code is compiled, and the important aspects of both DTML and Evan Simpson's bytecode transforms and alteration of __builtins__ are performed, to render the resulting code safe for execution. The code block is set up as a function which does a "return _" if execution falls off the end of the script. (Thus, a method can return something instead of writing output, ala the DTML "return" tag.) The _ object would be able to render itself as a string by returning the accumulated writes, and thus when an ngDTML object is called by ZPublisher, its output will be properly sent to the RESPONSE. Whew. It's a long and tedious list of things that have to be implemented. However, it is clearly able to be implemented, and all the pieces already exist, although some bits may have to be re-implemented in order to be integrated. To sum up, the advantages of this language are: 1. It's Python, so the basic syntax is clean and simple. Plenty of books are out there on Python, and when it comes right down to it, we've been continuously extending DTML trying to make it more like Python, so why not just go there? 2. It's based on a well-established embedded scripting paradigm which is used in numerous other application environments including the giants ASP and PHP. It is easier to teach to someone coming over from one of those environments, and many editing tools can already cope with <% %> syntax. 3. All the bits of DTML which are really handy, such as auto-calling, namespace passing, formatting utilities, etc., are all tidily packaged into the "_" swiss-army knife, and there is no confusing Perl-ish automagic anywhere. (Note, by the way, that using _.string, _.None, etc. is not valid in ngDTML; these things should be imported with import. _ is for generally useful ngDTML utilities only.) What about disadvantages? Well, there's no "in" tag and all its goodies, although these could be conceivably implemented using an object that wrapped a sequence for you, and maybe even fitted in as another capability of the '_' object. I haven't given this one a great deal of thought yet. Also, doing things like the tree, sendmail, and sqlgroup tags are tricky unless you can ask the _ object to push and pop its write() buffer; then you can do something like: <% try: _.push() %>From: <%= sender %> To: <%= string.join(recipients,',') %> Subject: test Hi! <% somehost.sendmail(recipients,str(_)) finally: _.pop() %> Which, I have to admit is a lot messier than <dtml-sendmail></dtml-sendmail>. On the other hand, the above can also be written: <% somehost.sendmail(recipients,_(message)) %> Since one can define functions within the body of an ngDTML block, and pass them to utility routines, dtml-tree and other things that want blocks to render could be passed functions. This leaves text-transforming tags like sqlgroup, which are harder to manage in this form. Anyway, other than these points, I believe I have described here a language which is capable of doing anything the DTML core can do, while being much clearer and more consistent, and at the same time practical to implement. Comments, anyone?

1 0