- Zope-Dev - Zope lists

Next steps on Zope 2.6 plan
by Brian Lloyd 21 Mar '02

21 Mar '02

Hi all, As talked about last week, I've updated the proposed features document for Zope 2.6: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures ...to cut out those proposals without volunteers. Now comes the hard part :^) There are quite a few proposals there. The current list is still a "laundry list" - it reflects every idea that someone had and volunteered for without any consideration of whether the proposals are good / bad / indifferent. Now we need to do a "quality chop" to turn the laundry list into an actual project plan consisting of only things that: 1 Have volunteers committed to producing the code AND associated documentation 2 Are generally agreed to be good ideas, for some definition of "generally" and "good" :) 3 Can realistically be completed (code and docs) by the May 1 target we are setting for 2.6 alpha 1. Getting from laundry list to project plan is made a bit harder this time around because this is the first really community-driven release, and we don't have any real process in place for getting there :( I think that we have #1 above under control, and #3 does not bother me that much, but #2 is a tough cookie. Right now, the laundry list includes some "competing" proposals (things that solve the same or similar problems in different ways), as well as some "better XXX" proposals that "compete" with things already in the core and some pretty big "overhaul XXX" proposals with wide ranging non-trivial impacts on documentation, packaging and other non-software concerns. Somehow we need to get to resolution on these things. I know that realistically we'll be winging it for 2.6 (there's no way that we could get any sort of well-thought-out generally agreed upon process in place in time). But while we're winging it, I'd like for us to be starting to think about these things and putting pieces in place as we're able. One suggestion Casey had was to start to codify a set of rules that features have to abide by to be considered for inclusion. Some examples here would be: - A feature that is a "better X than X" (where X is a feature or component already in Zope), has a much higher bar to jump over since it will almost never be worth the user confusion and extra documenation burden to add another component that does almost (but not quite!) the same thing as an existing builtin component. For example, if you have a "better Folder" implementation, the right approach is to add your betterness to the current builtin Folder, because Zope is not going to ship with two kinds of Folder (with the associated two sets of docs, etc.) without a very, very good reason *. * Exhibit A for multiple similar objects causing confusion: DTML Document and DTML Method. - A feature release should never contain more than one blow-it- up-and-redo-it type project (such as radical changes to key parts of packaging or infrastructure). For example, it would probably be a bad idea to totally redo the ZODB, packaging and installation and the security system all in one release (unless it is a major release like Zope2 -> Zope3). The aggregate impact in terms of obsoleting existing knowledge and documentation is too great to do many of these at once. It takes time for users and developers to catch up after something major is refactored, and we need to keep this in mind. - Features or components added to the Zope core should address a clear and generally agreed-upon need. Otherwise, accumulation of components over time will become a significant support burden for the zope maintainers. - Features that affect the security system face a higher analysis, design and documentation burden :^) I'm sure there are many other good guidelines, but you get the idea. Having a set of ground rules that everyone agrees on will make it easier to keep focused on arguing edge cases (instead of every detail) when it's time to define a release. Thoughts? I'll volunteer to maintain the guidelines document on dev.zope.org if folks can send their guideline suggestions. Brian Lloyd brian(a)zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com

3 3

PageTemplate Internet Explorer error
by Terry Kerr 21 Mar '02

21 Mar '02

Hi, I have the latest PageTemplates, ZTUtils, and TAL installed on Zope 2.4.3 with python 2.1.1 on Linux. Whenever I try to create or edit a PageTemplate using IE5.5 or IE6 on windows I get the following error. It works fine however when I use Netscape or Mozilla on windows or linux. I have seen some other emails about this error, but none seemed to suggest that the problem was ever solved. Is somebody working on this, or has somebody found a solution? terry kerr Site Error An error was encountered while publishing this resource. Error Type: Undefined Error Value: "manage_page_header" not found in "here/manage_page_header" ---------------------------------------------------------------------------- ---- Troubleshooting Suggestions The URL may be incorrect. The parameters passed to this resource may be incorrect. A resource that this resource relies on may be encountering an error. For more detailed information about the error, please refer to the HTML source for this page. If the error persists please contact the site maintainer. Thank you for your patience. Traceback (innermost last): File /home/zope/Zope/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /home/zope/Zope/lib/python/ZPublisher/Publish.py, line 187, in publish File /home/zope/Zope/lib/python/Zope/__init__.py, line 226, in zpublisher_exception_hook File /home/zope/Zope/lib/python/ZPublisher/Publish.py, line 171, in publish File /home/zope/Zope/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: ptAdd) File /home/zope/Zope/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: ptAdd) File /home/zope/Zope/lib/python/Shared/DC/Scripts/Bindings.py, line 324, in __call__ (Object: ptAdd) File /home/zope/Zope/lib/python/Shared/DC/Scripts/Bindings.py, line 354, in _bindAndExec (Object: ptAdd) File /home/zope/Zope/lib/python/Products/PageTemplates/PageTemplateFile.py, line 163, in _exec (Object: ptAdd) File /home/zope/Zope/lib/python/Products/PageTemplates/PageTemplate.py, line 156, in pt_render (Object: ptAdd) (Info: {'container': <__FactoryDispatcher__ instance at 90c56d8>, 'here': <__FactoryDispatcher__ instance at 90c56d8>, 'modules': <Products.PageTemplates.ZRPythonExpr._SecureModuleImporter instance at 0x95dabdc>, 'nothing': None, 'options': {'args': ()}, 'request': <h3>form</h3><table></table><h3>cookies</h3><table></table><h3>other</h3><ta ble><tr valign="top" align="left"><th>AUTHENTICATION_PATH</th><td>''</td></tr><tr valign="top" align="left"><th>URL3</th><td>'http://orgazmo.adroit:8080'</td></tr><tr valign="top" align="left"><th>URL0</th><td>'http://orgazmo.adroit:8080/manage_addProduct/ PageTemplates/ptAdd'</td></tr><tr valign="top" align="left"><th>URL1</th><td>'http://orgazmo.adroit:8080/manage_addProduct/ PageTemplates'</td></tr><tr valign="top" align="left"><th>BASE3</th><td>'http://orgazmo.adroit:8080/manage_addProduct /PageTemplates'</td></tr><tr valign="top" align="left"><th>URL2</th><td>'http://orgazmo.adroit:8080/manage_addProduct' </td></tr><tr valign="top" align="left"><th>BASE1</th><td>'http://orgazmo.adroit:8080'</td></tr><tr valign="top" align="left"><th>traverse_subpath</th><td>[]</td></tr><tr valign="top" align="left"><th>SERVER_URL</th><td>'http://orgazmo.adroit:8080'</td></tr><t r valign="top" align="left"><th>PUBLISHED</th><td><PageTemplateFile instance at 91b4888></td></tr><tr valign="top" align="left"><th>URL</th><td>'http://orgazmo.adroit:8080/manage_addProduct/P ageTemplates/ptAdd'</td></tr><tr valign="top" align="left"><th>AUTHENTICATED_USER</th><td>Anonymous User</td></tr><tr valign="top" align="left"><th>BASE2</th><td>'http://orgazmo.adroit:8080/manage_addProduct '</td></tr><tr valign="top" align="left"><th>TraversalRequestNameStack</th><td>[]</td></tr><tr valign="top" align="left"><th>BASE0</th><td>'http://orgazmo.adroit:8080'</td></tr><tr valign="top" align="left"><th>BASE4</th><td>'http://orgazmo.adroit:8080/manage_addProduct /PageTemplates/ptAdd'</td></tr><tr valign="top" align="left"><th>URL0</th><td>http://orgazmo.adroit:8080/manage_addProduct/P ageTemplates/ptAdd</td></tr><tr valign="top" align="left"><th>URL1</th><td>http://orgazmo.adroit:8080/manage_addProduct/P ageTemplates</td></tr><tr valign="top" align="left"><th>URL2</th><td>http://orgazmo.adroit:8080/manage_addProduct</ td></tr><tr valign="top" align="left"><th>URL3</th><td>http://orgazmo.adroit:8080</td></tr><tr valign="top" align="left"><th>BASE0</th><td>http://orgazmo.adroit:8080</td></tr><tr valign="top" align="left"><th>BASE1</th><td>http://orgazmo.adroit:8080</td></tr><tr valign="top" align="left"><th>BASE2</th><td>http://orgazmo.adroit:8080/manage_addProduct< /td></tr><tr valign="top" align="left"><th>BASE3</th><td>http://orgazmo.adroit:8080/manage_addProduct/ PageTemplates</td></tr><tr valign="top" align="left"><th>BASE4</th><td>http://orgazmo.adroit:8080/manage_addProduct/ PageTemplates/ptAdd</td></tr></table><h3>environ</h3><table><tr valign="top" align="left"><th>HTTP_ACCEPT_ENCODING</th><td>'gzip, deflate'</td></tr><tr valign="top" align="left"><th>channel.creation_time</th><td>1016684537</td></tr><tr valign="top" align="left"><th>SERVER_PROTOCOL</th><td>'HTTP/1.1'</td></tr><tr valign="top" align="left"><th>SERVER_PORT</th><td>'8080'</td></tr><tr valign="top" align="left"><th>PATH_INFO</th><td>'/manage_addProduct/PageTemplates/ptAdd'< /td></tr><tr valign="top" align="left"><th>HTTP_HOST</th><td>'orgazmo.adroit:8080'</td></tr><tr valign="top" align="left"><th>REQUEST_METHOD</th><td>'GET'</td></tr><tr valign="top" align="left"><th>PATH_TRANSLATED</th><td>'/manage_addProduct/PageTemplates/p tAdd'</td></tr><tr valign="top" align="left"><th>SCRIPT_NAME</th><td>''</td></tr><tr valign="top" align="left"><th>SERVER_SOFTWARE</th><td>'Zope/(Zope 2.4.1 (source release, python 2.1, linux2), python 2.1.1, linux2) ZServer/1.1b1'</td></tr><tr valign="top" align="left"><th>HTTP_ACCEPT_LANGUAGE</th><td>'en- au'</td></tr><tr valign="top" align="left"><th>HTTP_ACCEPT</th><td>'image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*'</td></tr><tr valign="top" align="left"><th>REMOTE_ADDR</th><td>'10.0.0.22'</td></tr><tr valign="top" align="left"><th>SERVER_NAME</th><td>'orgazmo.adroit'</td></tr><tr valign="top" align="left"><th>GATEWAY_INTERFACE</th><td>'CGI/1.1'</td></tr><tr valign="top" align="left"><th>HTTP_USER_AGENT</th><td>'Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)'</td></tr><tr valign="top" align="left"><th>CONNECTION_TYPE</th><td>'Keep-Alive'</td></tr></table>, 'root': <Application instance at 8ddcc90>, 'template': <PageTemplateFile instance at 91b4888>, 'traverse_subpath': [], 'user': Anonymous User}) File /home/zope/Zope/lib/python/TAL/TALInterpreter.py, line 229, in __call__ File /home/zope/Zope/lib/python/TAL/TALInterpreter.py, line 262, in interpret File /home/zope/Zope/lib/python/TAL/TALInterpreter.py, line 503, in do_insertStructure_tal File /home/zope/Zope/lib/python/Products/PageTemplates/TALES.py, line 297, in evaluate Undefined: (see above)

1 0

Structured text issues (again?)
by jlagarde＠bigfoot.com 21 Mar '02

21 Mar '02

How extensively is STX actually used? I've been looking at it myself recently, and the whole system seem rather simplistic to me in how it parses the text. I'm talking specifically of the STX version currently standard in Zope 2.5 (and 2.4 I think), which I believe is STXNG; I haven't gone back to look at how the previous version worked. I have looked at some of the past mailing list posts on this topic, and although it is clear that things have been improved a lot, I am surprised that not more was done so far. I explain the problems I see next, followed by a proposed algorithm change and some rough code to make things "better". I'm doing this now for two reasons: First, if I'm missing something important wrt the reasons things are as they are, I'm obviously interested to know before I spend any more time on this. Second, maybe these proposed changes are actually a step in the right direction, or might help someone else do what they need, so I'm providing the code of what I've done so far, as is, in case it can be of help (I am unlikely to have the time to come up with a polished set of changes myself any time soon). Or I guess what I'm saying is (wink wink nudge nudge): If someone else feels like picking up on this and finishing it up so I don't have to, feel free ;-) The biggest problem I see is that the various text types are given somewhat arbitrary preference from the order in which they appear in the text_types list. Given that the patterns in text_types are looked at in order, with the first match breaking the raw string in half, then any other structure that would have spanned a larger part of the string but is lower in the text_types list is effectively ignored. For example, since doc_strong is currently listed before doc_emphasize, "*emphasized **strong** emphasized*" does enclose "strong" in <strong> tags, but completely ignores the single *'s because they do not form a matching pair (because the parsing of **strong** breaks the rest in two separate strings "*emphasized " and " emphasized*"). Following the same reasoning, I assumed that **strong *emphasized* strong** would work better, but it did not! This time, it's because the regexp for doc_strong is rather simplistic, as it does not allow ANY '*' within (strongem_punc), whereas it should only care to not allow the specific pattern '**' inside. In this case, wouldn't the easiest solution be to simply use the non-greedy matching? i.e replace: r'\*\*([%s%s%s\s]+?)\*\*' % (letters, digits, strongem_punc) with: r'\*\*(.*?)\*\*' or actually better: r'(?!\*\*\*)\*\*(?<!\*\*\*)(.*?)(?!\*\*\*)\*\*(?<!\*\*\*)' I think the last pattern is best because it will not recognize the middle **** as anything in "**this: **** does not matter**", as I think should normally be expected. BTW, I make no claim that the regexp above is either the most elegant or the most efficient; this is the first one I came up with that did what I wanted ;-) Now, back to the problem with the ordered nature of text_types (the reason "*emphasized **strong** emphasized*" does not work as expected). Besides the extra computing required, any reason why the structures with the largest span shouldn't be recognized first, regardless of the order of text_types? I.E. what I propose is to go through all the text_types, collecting the matching patterns, and only once this is done choose the one with the largest span. Then proceed recursively with the enclosed text until no pattern matches. This permits to succeed in quoting structured text patterns: "'**not bold**'", and bolding quoted text: "** some text '<this is quoted>' **". With the current implementation, none of those work, i.e. "'**not bold**'" ends up being bolded and not quoted, and "** some text '<this is quoted>' **" is a total mess because the text in <> is interpreted as SGML instead of being quoted as requested. The changes I have made so far (all in DocumentClass.py): The simplest are the few regexp changes I have made for doc_strong, doc_emphasize, and doc_literal (actually doc_literal probably doesn't matter (I used the pattern proposed by someone else on this list to make the quoting more obvious), but the changes to doc_strong and doc_emphasize are required to make my other changes work). doc_strong becomes: r'(?!\*\*\*)\*\*(?<!\*\*\*)(.*?)(?!\*\*\*)\*\*(?<!\*\*\*)' doc_emphasize becomes: r'(?!\*\*)\*(?<!\*\*)(.*?)(?!\*\*)\*(?<!\*\*)' and doc_literal becomes: r"(\W+|^)``([%s%s%s\s]+)''([%s]+|$)" % (letters, digits, literal_punc, phrase_delimiters) The big changes are to the parse and color_text methods. Parse now only returns the first match found of a type rather than all of them, and it returns the start and end indices of the match so that the span size can be computed in color_text: def parse(self, raw_string, text_type, type=type, st=type(''), lt=type([])): """ Parse accepts a raw_string, an expr to test the raw_string, and the raw_string's subparagraphs. Parse will continue to search through raw_string until all instances of expr in raw_string are found. NOT!!! If no instances of expr are found, raw_string is returned. Otherwise a list of substrings and A SINGLE instance is returned """ tmp = [] # the list to be returned if raw_string is split append=tmp.append if type(text_type) is st: text_type=getattr(self, text_type) start = end = 0 # because I'm returning those now while 1: t = text_type(raw_string) if not t: break #an instance of expr was found t, start, end = t if start: append(raw_string[0:start]) tt=type(t) if tt is st: # if we get a string back (when would this happen?), add it to text to be parsed raw_string = t+raw_string[end:len(raw_string)] # should I break or not here? If I break, same as removing the while else: if tt is lt: # is we get a list, append it's elements tmp[len(tmp):]=t else: # normal case, an object append(t) #Do not keep processing once a match found! raw_string = raw_string[end:len(raw_string)] break if not tmp: return (raw_string,0,0) # nothing found if raw_string: append(raw_string) elif len(tmp)==1: return (tmp[0],start,end) return (tmp,start,end) In color_text, instead of looping over the text_types only once, I loop over all of them for every recursive pass. For any pass, I select the match (no matter what type) with the largest span, and recurse on its content. I think that the code could be made a lot more efficient (as long as they are not overlapping, I should be able to collect more than one match in a single pass, among other things), but I just wanted to see if the result of the parsing would give the results I wanted for now, and it seems it does (but I repeat, I haven't tested extensively so far). def color_text(self, str, types=None): """Search the paragraph for each special structure """ if types is None: types=self.text_types if type(str) is StringType: max = 0 parsed = 0 for text_type in types: res, start, end = self.parse(str,text_type) if res != str: parsed = 1 # keep the option with the largest span only if end-start >= max: finalres = res max = end-start if parsed and type(finalres) is ListType: # *** this may cause other problems ** return self.color_text(finalres) else: return finalres # end recursion elif type(str) is ListType: res = [] for sub in str: subres = self.color_text(sub) if type(subres) is not ListType: subres = [subres] res += subres return res else: res = map(self.color_text,str.getColorizableTexts()) # To avoid stuff like StructuredTextSGML(StructuredTextSGML('<I>')) if len(res) == 0 or type(res[0]) != type(str) or \ res[0].getColorizableTexts() != str.getColorizableTexts(): str.setColorizableTexts(res) return str So there you have it. I find that the results produced by this code make a lot more sense than what is produced by the current implementation. I guess one problem with structured text may be that there are differences of opinion as to what the actual rules and output should be (e.g. should list items be singly spaced or double spaced), but I really don't see who could argue that a preference in the order of markup like emphasis, strong, and underline makes any sense. Or am I missing something? Cheers, Jean

3 2

Flush memory from product
by de ZORZI Frederic 20 Mar '02

20 Mar '02

Hello zopers, I'm writing a product with a relational database mapping. When I launch loading procedures, the product creates ~ 50000 instances. I regulary do a get_transaction().commit(), but memory still increase constantly (more than 300 megs for python processes) How can I flush memory ? Tested with : gnu/linux debian potato, zope 2.3.3 gnu/linux debian woody, zope 2.5.0

1 1

RE: Object links/references
by Brian Lloyd 20 Mar '02

20 Mar '02

> You told us that you will be refining Zope 2.6 plan. > ProposedFeatures table contains an " Implement links > (object references)" entry by Mario Valente. I've created > SoftLink proposal in ProposalsWiki . These works appear > related. We (Mario and me) discussed and decided that > we can dedicate some efforts to make it working (Mario > has working code already). The plan is to release Patch-like > product for Zope 2.3, 2.4 and 2.5 to get feedback. And to > incorporate functionality into Zope 2.6 without patching > functionality. > > Please give us your recommendations / feedback / instructions for us, To be honest, I'm a little worried about the approach. Links can be very, very hard to get right (which is why they are not in the core now), especially with regard to security issues. Creating an object that "impersonates" another object is tough, because there a potentially unknown number of contracts that the impersonator must fulfill. This usually leads to problems :( For the SoftLink proposal in particular, the main problem you note in the proposal is that you want to avoid 404's when people go to a resource that has been moved. It seems to me that the best way to address that problem is to have a "RedirectObject" that you could add with the name of the object that was moved. It would _not_ try to impersonate the moved object, but when you went to "view" the object, you would be automatically redirected to the new location. That would avoid a lot of the problems of the link approach, with little overhead. Note that I'm not saying that object links are not a valid requirement, but it sounds like the problem you want to solve is definitely different than Mario's. In many ways, the "correct" required behavior of a link depends on what you expect to be able to do with it (the problem you are trying to solve). I can easily imagine that "right" behavior of a link if your main goal is to avoid 404s will _not_ be right if you are using the link in other ways. For example, if you went to a URL that had been moved, what is the right "context" that it should render itself in? I highly suspect that the right context is the place that it was moved to, rather than the context where the link lives (redirect semantics). That is basically the opposite of another possible usage of a link, where you would want to use the link to "virtually include" an object into a different context. I submit that trying to do both is too complex and probably too insecure as well (as managers of security would have to evaluate N possible security scenarios, most of which are not readily visible to them at the time they are setting up security). I think that the "RedirectObject" approach could sidestep all of these issues and provide an incremental step while still solving your problem. Brian Lloyd brian(a)zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com

2 1

ZMI: IE6 TextArea width bug: fix on tap for 2.6?
by Jeff Kowalczyk 20 Mar '02

20 Mar '02

I was wondering if there was any consensus on how best to fix or compensate for the unfortunate behaviour of IE6 with regards to the width calculation of textarea boxes. For anyone who hasn't seen it, the full-width texareas that are everywhere in the ZMI suddenly started pushing the width out in IE6, causing the horizontal scrollbar to become active, and generally making ZMI editing life miserable. Would it be possible to include in 2.6 (or 2.5.1, even better) a user preference, sitewide configuration setting, or other means of suppressing a few pixels/percent of that default width? I'm loathe to apply a massive search-replace to put "95%" in my local ZMI source, and IE6 must be a common enough platform for Zope users to warrant a workaround. I wouldn't hold my breath that MS would fix IE or anything sensible like that. It would be a shame to slow the whole thing down with browser detection logic for this one bug, unless that opened up the door for some of the Javascript/DHTML editors as a per-user preference for editing certain metatypes.

3 2

manage frame change
by seb bacon 20 Mar '02

20 Mar '02

anyone object to changing the text at in the top ZMI frame to "Logged in as <user> on <machine>?" Or is there a better place to put that info? I find it useful when I've got several windows open to different servers. seb

4 3

Restricting Sub-Objects in Folders DYNAMICALLY?
by Brian Oliver 19 Mar '02

19 Mar '02

I would like to restrict the types of objects (from a python-based product) that may be placed in Folders, or any other dumb container, based on certain conditions. For example: I'd like to restrict the number of a certain type of object that may appear in a folder. The end-user can add up to the limit, and afterwards the object type should NO LONGER APPEAR in the "Add List". I've thought about building a specialized folder, but I'd rather not. Zope already has a good folder with all the things I need. What Zope 2.4+ really needs to do is callback a provided function to determine if a particular class is allowed in a specified container instance (or class) Using the "implements" parameter of the registerClass method is not enough as it only permits static checking. Any help would be greatly appreciated. Regards -- Brian _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

4 3

Re: [Zope-dev] A thought for 2.6 about various leaks and memory problems
by Anthony Baxter 19 Mar '02

19 Mar '02

>>> "Adrian Hungate" wrote > moved to a different thread or earlier, before the fork, so that we could > simply kill senile threads without killing the entire shooting match? unfortunately apache does this with seperate processes, not threads. memory corruption and leaks aren't solved by offing threads, unfortunately. the equivalent would be to start a bunch of single threaded zeo clients on a machine, with a loadbalancer in front of them, and periodically off one. the only decent loadbalancers I've seen, however, are pretty heavy weight, flaky, limited in functionality, or some combination of all three. also, the start time for a new ZEO client is non-trivial. Anthony

5 4

Impact of additional protocols handled by Zope?
by Jeff Kowalczyk 19 Mar '02

19 Mar '02

I'm curious what the impact on overall performance would be if products eventually came into existence that extended Zope to directly handle additional protocols and their data requirements, primarily intended for low-volume workgroup kind of traffic. Jabber, IMAP and LDAP are the ones that come to mind immediately, since you'd be that much closer to having Zope fulfill a role that MS Exchange really doesn't; inexpensive, easily maintained groupware for small organizations that need custom workflow app development. Is it practical to consider that Zope might extend into other protocols this way, and can it be done with modular products, or does integration require deep Zope modifications (beyond adding a few lines to Z2.py?) Just a hypothetical, I guess. FWIW, it would be really cool to see a general, host-a-protocol-here hook for plugin products as Zope3 takes shape, configuration in the ZMI if the product writer goes that far. Something that would define a standard interface for Zope3 events to respond to signals the protocol handler might generate, and vice-versa.

5 4