phpwiki-talk

[Phpwiki-talk] PCRE memory problem at php core found

[Reini U. <ru...@x-...>]

finally someone found a PCRE memory problem at php core.
 
http://viewcvs.php.net/viewcvs.cgi/php-src/NEWS.diff?r1=1.1247.2.724&r2=1.1247.2.714
(php-4.3.9RC2)

Hope this fixes our ConvertOldMarkup problem.
I'm investigating.


BTW: I found now a better job.
They pay better and they need phpwiki... Very good!
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] todo, [confirmed] PCRE memory problem at php core found

[Reini U. <ru...@x-...>]

Reini Urban schrieb:

> finally someone found a PCRE memory problem at php core.
> 
> http://viewcvs.php.net/viewcvs.cgi/php-src/NEWS.diff?r1=1.1247.2.724&r2=1.1247.2.714 
> 
> (php-4.3.9RC2)
> 
> Hope this fixes our ConvertOldMarkup problem.
> I'm investigating.

Yes, it was indeed our problem. 4.3.9 or later is recommended.
   http://www.php.net/release_4_3_9.php

It only happens on low memory systems (esp. --with-memory-limit),
and actions which require a lot of memory.
The php GC is no GC, not even their reference counting is reliable.

There are known workarounds (turning off html caching) described at
http://phpwiki.org/KnowBugs

config.ini:
   USECACHE = 0
   WIKIDB_NOCACHE_MARKUP = 1

The system tries to avoid most such issues in broken systems by 
automatically turning on paging with limit=50, when there are more then 
400 pages. But we don't turn off html caching so far automatically. 
you'll see it when you are hit by this problem, and then just turn it off.
There's still some room for improvements memory-wise.
(avoiding meta data and content retrieval, when not requested)

now only a few minor things are left:
   == TODO ==
fix:
* javascript search&replace
* test httpauth, and reported personalpage auth problems
* test against php-5.0.2
* test against apache2
do all unit tests:
   all langs, all db backends, all pages import and export
improvements:
* PageChangeNotification other actions also (rename, remove).
   better subject on create.
* collapse page change notification on LoadAny
* restrict certain action to groups: RawHtml (could be a define)
* db.timeout: force mysql.connect_timeout = 60
* rewrite OldTextFormattingRules, AnciennesR%E8glesDeFormatage
   for proper importing
* test WikiPluginCached support for image maps and svg, swf, eps, ...
   defer header logic
* don't print php notices and warnings as red errors.
   just green or grey
maybe (probably defer):
* iniconfig helpers (create config.ini, installer)
* and and fix more wikilens libs and plugins, layout improvements
* format=rdf and a new owl PageType (similar to InterWikiMap)
   to statically define predicates used by PhpWiki:SemanticWeb
   (semantically enriched links, like interwiki links).
* SqlResult paging
* plugin\WikiAdminSetAclSimple
* plugin\NewUserWelcomePage.php
* plugin\SearchHighlight
* logfile stuff:
*   plugin\RecentReferrers
*   WikiAccessRestrictions
* PageModeration
* SpamAssassinIntegration

already done lately:
* pdf button when an external html2pdf app is defined
   (enabled at PhpWikiDemo)
* enhanced WikiPluginCached (static, ondemand)
* added LdapSearchPlugin

shout now or be quiet until 1.4.0
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] todo, [confirmed] PCRE memory problem at php core found

[Reini U. <ru...@x-...>]

Reini Urban schrieb:
> now only a few minor things are left:
>   == TODO ==
> fix:
> * javascript search&replace
> * test httpauth, and reported personalpage auth problems
> * test against php-5.0.2
> * test against apache2
> do all unit tests:
>   all langs, all db backends, all pages import and export
> improvements:
> * PageChangeNotification other actions also (rename, remove).
>   better subject on create.

done for remove and rename.

> * collapse page change notification on LoadAny

done on create, missing on remove and rename.

> * restrict certain action to groups: RawHtml (could be a define)
> * db.timeout: force mysql.connect_timeout = 60
> * rewrite OldTextFormattingRules, AnciennesR%E8glesDeFormatage
>   for proper importing
> * test WikiPluginCached support for image maps and svg, swf, eps, ...
>   defer header logic
> * don't print php notices and warnings as red errors.
>   just green or grey

done

> already done lately:
> * pdf button when an external html2pdf app is defined
>   (enabled at PhpWikiDemo)
> * enhanced WikiPluginCached (static, ondemand)
> * added LdapSearchPlugin

and something more important:
* more PageList options: cols, paging, azhead, comma, commasep, ordered.
   automatically enabled for most pagelist outputting plugins.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] todo, javascript buttons &safari

[aphid <sp...@ap...>]

Not sure if this is the same problem or not but the javascript markup 
buttons on the edit page do not appear to be working in Safari, though 
they do in Firefox/Mozilla/etc.

On Sep 24, 2004, at 10:20 AM, Reini Urban wrote:
>
> * javascript search&replace

Re: [Phpwiki-talk] todo, javascript buttons &safari

[Reini U. <ru...@x-...>]

aphid schrieb:
> Not sure if this is the same problem or not but the javascript markup 
> buttons on the edit page do not appear to be working in Safari, though 
> they do in Firefox/Mozilla/etc.

why and how? Sorry, I cannot test this.

Don't they show up at all (which would be good)

Do they show up, but you cannot click on them (which would be not good, 
but ok)

Do they show up, you can click, but nothing happens (which would be bad)

The buttons are created by document.write().
so if the brwoser has poor javascript support, they will not show up at 
all. all html editor scripts do it like that.

> On Sep 24, 2004, at 10:20 AM, Reini Urban wrote:
>> * javascript search&replace




-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] todo, javascript buttons &safari

[aphid <sp...@ap...>]

The buttons show up, can be clicked, but nothing happens.  Also, Safari 
puts a thin border that signifies that the edit window has typing-scope 
- this disappears from the edit window when the buttons are clicked, 
and then nothing happens.

A


On Sep 25, 2004, at 12:07 PM, Reini Urban wrote:

> aphid schrieb:
>> Not sure if this is the same problem or not but the javascript markup 
>> buttons on the edit page do not appear to be working in Safari, 
>> though they do in Firefox/Mozilla/etc.
>
> Do they show up, you can click, but nothing happens (which would be 
> bad)