Re: r25642 - in Ploneboard/trunk: . content

On Fri, 30 Jun 2006 19:22:56 -0700, optilude  
<svn-changes-z4DKO/sx8wnYtjvyW6yDsg@...> wrote:

> o There seems to be some race condition in the code that affects the  
> ordering
> of comments coming out of getComments(). Basically, 'created' only goes  
> down
> to the hour and minute (?) and so the ordering is wrong in some cases.  
> This
> is affecting the ftests so you may get random failures 

If I remember correctly, this is because Zope only indexes to the minute,  
not seconds - which seems stupid to me, but probably has some  
justification somewhere. Maybe somebody else knows more about this. :)

--

-- 
_____________________________________________________________________

      Alexander Limi · Chief Architect · Plone Solutions · Norway

  Consulting · Training · Development · http://www.plonesolutions.com
_____________________________________________________________________

       Plone Co-Founder · http://plone.org · Connecting Content
   Plone Foundation · http://plone.org/foundation · Protecting Plone

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

severe unicode problem using 2.5, LinguaPlone, Zope2.9.3

Hi there,
when using a language that has non ascii characters in its name
Plone dies with an Unicode error on start up. (in languageSelectorData)

this happens when using  Zope2.9.3

the reason is, that the old not five based PTS does not  return Unicode.
it could be instructed to do so, but Five does not allow to pass the 
extra parameter.

a possible (albeit primitive) fix would be to check to wrap the 
translations in languageSelectorData
in a try/except block as follows

Robert

/## Script (Python) "languageSelectorData"/
/##bind container=container/
/##bind context=context/
/##bind namespace=/
/##bind script=script/
/##bind subpath=traverse_subpath/
/##parameters=/
/##title=/
/##/
results = []

translations = {} /# lang:[object, wfstate]/
*if* context.isTranslatable():
    translations = context.getTranslations()

Re: severe unicode problem using 2.5, LinguaPlone, Zope2.9.3

Hi.

I removed the Unicode conversion for the language names and couldn't
find a scenario anymore where you would get a UnicodeDecodeError now.

Could you please try again (svn trunk of LP) and report back?

Thx,
Hanno

robert rottermann wrote:
> Hi there,
> when using a language that has non ascii characters in its name
> Plone dies with an Unicode error on start up. (in languageSelectorData)
> 
> this happens when using  Zope2.9.3
> 
> the reason is, that the old not five based PTS does not  return Unicode.
> it could be instructed to do so, but Five does not allow to pass the
> extra parameter.
> 
> a possible (albeit primitive) fix would be to check to wrap the
> translations in languageSelectorData
> in a try/except block as follows
> 
> Robert
> 
>    /# PloneLanguageTool returns the language names in utf-8 right now/
>    *if* *not* isinstance(name, unicode):
>        name = unicode(name, 'utf-8')

Re: severe unicode problem using 2.5, LinguaPlone, Zope2.9.3

hanno,
it works, partially.
I can now start the site and navigate within it.

(I still have a problem, but that seems to stem from my tinkering, I 
absolutely HATE Unicode and its its tracebacks)

robert

Hanno Schlichting wrote:

> Hi.
>
> I removed the Unicode conversion for the language names and couldn't
> find a scenario anymore where you would get a UnicodeDecodeError now.
>
> Could you please try again (svn trunk of LP) and report back?
>
> Thx,
> Hanno
>
> robert rottermann wrote:
>   
>> Hi there,
>> when using a language that has non ascii characters in its name
>> Plone dies with an Unicode error on start up. (in languageSelectorData)
>>
>> this happens when using  Zope2.9.3
>>
>> the reason is, that the old not five based PTS does not  return Unicode.

Re: severe unicode problem using 2.5, LinguaPlone, Zope2.9.3

robert rottermann wrote:
> hanno,
> it works, partially.
> I can now start the site and navigate within it.
>
> (I still have a problem, but that seems to stem from my tinkering, I 
> absolutely HATE Unicode and its its tracebacks)
the problem happens thus:
when  i try to open the languages configlet, languageSelectorData is 
called with portal_languages as its context.
as portal_languages defines its own isTranslatable which needs an object 
as parameter.

I dont know why this happens with this site.
however I think it would be fine when the LinguaPlone would tolerate 
this with:
try:
    if context.isTranslatable():
        translations = context.getTranslations()
excetp TypeError: # we are tickling portal_language
        translations = {}

I can live with the things as they are now, as I can set the languages 
trough the ZMI

thanks
robert

>
> robert

Re: r25642 - in Ploneboard/trunk: . content

Alexander Limi wrote:
> On Fri, 30 Jun 2006 19:22:56 -0700, optilude  
> <svn-changes-z4DKO/sx8wnYtjvyW6yDsg@...> wrote:
> 
>> o There seems to be some race condition in the code that affects the  
>> ordering
>> of comments coming out of getComments(). Basically, 'created' only goes  
>> down
>> to the hour and minute (?) and so the ordering is wrong in some cases.  
>> This
>> is affecting the ftests so you may get random failures 
> 
> If I remember correctly, this is because Zope only indexes to the minute,  
> not seconds - which seems stupid to me, but probably has some  
> justification somewhere. Maybe somebody else knows more about this. :)
> 

in a test environment you may need sub second granularity to order by time.

iirc rob ran into this problem in the wicked tests and solved it by 
temporarily substituting a FieldIndex for the usual DateTimeIndex in the 
the tests.

-w

--

-- 

  | david "whit" morriss
  |
  | contact :: http://public.xdi.org/=whit

Re: r25642 - in Ploneboard/trunk: . content

Exactly, speed was the issue in introducing the DateTimeIndex in ZCatalog 
in the first place.  FieldIndexes with their finer time resolution were 
used for dates/times just fine before DateTimeIndexes came into use 
specifically to run queries faster and with less overhead.
+lupa+

At 10:04 PM 7/1/2006 -0500, whit wrote:
>Alexander Limi wrote:
> > On Fri, 30 Jun 2006 19:22:56 -0700, optilude  wrote:
> >
> >> o There seems to be some race condition in the code that affects the
> >> ordering
> >> of comments coming out of getComments(). Basically, 'created' only goes
> >> down
> >> to the hour and minute (?) and so the ordering is wrong in some cases.
> >> This
> >> is affecting the ftests so you may get random failures 
> >
> > If I remember correctly, this is because Zope only indexes to the minute,
> > not seconds - which seems stupid to me, but probably has some
> > justification somewhere. Maybe somebody else knows more about this. :)
> >
>
>in a test environment you may need sub second granularity to order by time.
>
>iirc rob ran into this problem in the wicked tests and solved it by
>temporarily substituting a FieldIndex for the usual DateTimeIndex in the
>the tests.
>
>-w

Re: r25642 - in Ploneboard/trunk: . content

Previously +lupa+ wrote:
> Exactly, speed was the issue in introducing the DateTimeIndex in ZCatalog 
> in the first place.  FieldIndexes with their finer time resolution were 
> used for dates/times just fine before DateTimeIndexes came into use 
> specifically to run queries faster and with less overhead.

What makes it faster to use minute-resolution? I don't see why comparing
a standard unix timestamp in second-resolution would be slowed than
comparing timestamps in minute-resolution.

Wichert.

--

-- 
Wichert Akkerman <wichert@...>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: r25642 - in Ploneboard/trunk: . content

At 02:09 PM 7/2/2006 +0200, Wichert Akkerman wrote:
>Previously +lupa+ wrote:
> > Exactly, speed was the issue in introducing the DateTimeIndex in ZCatalog
> > in the first place.  FieldIndexes with their finer time resolution were
> > used for dates/times just fine before DateTimeIndexes came into use
> > specifically to run queries faster and with less overhead.
>
>What makes it faster to use minute-resolution? I don't see why comparing
>a standard unix timestamp in second-resolution would be slowed than
>comparing timestamps in minute-resolution.
>
>Wichert.

1.  I may be way off base here, I posted from memory.  I know nothing of a 
"DateTimeIndex" in Zope.  (see below)

2.  Wiggy is right that "faster" was inappropriate in my post.  What I was 
referring to was the introduction of the DateIndex and DateRangeIndex in 
Zope, the code for which is found in /Products/PluginIndexes/DateIndex (and 
/DateRangeIndex), and the README for those suggests that "DateTime 
instances are *huge*, both in RAM and on disk," making them performance 
hogs for catalogs with lots of indexed values of these 
attributes.  DateIndex stores integers instead of DateTime instances, with 
approximately one minute resolution.  However, the performance appears to 
be a memory space issue, rather than a speed issue, as I suggested.

+lupa+

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier

Re: r25642 - in Ploneboard/trunk: . content

--On 2. Juli 2006 14:02:13 -0400 +lupa+ <lupa@...> wrote:

> attributes.  DateIndex stores integers instead of DateTime instances,
> with  approximately one minute resolution.  However, the performance
> appears to  be a memory space issue, rather than a speed issue, as I
> suggested.
>

DateTimeIndexes are more efficient both for performance and memory usage.
A DateTime pickle is very large (I think 120 bytes or more) compared to a 
Python int pickle which will allocate some bytes. DateTimeIndexes are 
likely more efficient on compare operations since you compare ints against 
ints. In DateTime comparison operaitons  you compare floats with floats 
which likely less efficient (but I don't have any numbers).

-aj

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

_______________________________________________
Plone-developers mailing list
Plone-developers@...
https://lists.sourceforge.net/lists/listinfo/plone-developers