perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerald Richter" <>
Subject Re: What's going on with Embperl???
Date Fri, 26 Sep 2003 04:23:09 GMT

Neil Gunton wrote:
> Can you give me specifics as to what is needed most at the moment
> regarding documentation? If you have something in particular that you
> would like done, let me know.

Basicly all documentation for 2.0 is there, so everything should be
documented somewhere. Of course it could be improved. That is something what
could be best done from a perspective of a user, because you know what and
where you are searching for.

The best starting point for 2.0 users is IntroEmbperl2.pod.

> Otherwise I can do one of two things:
> Either start on parsing out the new features in 2.0 (which I admit I
> haven't really had time to do much of yet) and/or start looking at
> bugs (which I have never done on Embperl).
> If you have any initial pointers regarding the previous nested <DL>
> bug
> then I would be willing to look into that.

This is a very complex thing (otherwise I had already fixed it). The problem
is the way Embperl 2 internaly works. It builds a tree of nodes and
Perlcode, both are synced and when the page is executed the Perlcode
modifies the tree of nodes to build the output. These tree of nodes is
stored in a very compact way, which tries to avoid duplication, to save
memory resources. The Perlcode has something inside that are called
checkpoints, which tells the perlcode which part of the tree is to modify.
The problem is that something is going wrong when modifieing the tree
structure, I assume because when iterating over some html, only modified
nodes are stored, while all other are kept. This desgin make Embperl storage
very memory efficient but also very complex (and I think about some
simplyfication for 2.1).

The other problem is the print OUT, which has basicly the same source of

Additional, and this is the most simplest thing to fix (but also the most
user visible), does make test fail on RedHat 9. As far as I see so far, only
the error output is a little different, so the files that are used to
compare the result of the test has to be adapted.

> Looks interesting... I didn't know about this. If it lets us simply
> keep track of bug status then that would be useful, so that people
> don't
> start working on the same thing at the same time, thus wasting effort.
> It would also just be useful for people who reported bugs to see
> what's
> been resolved. I know some others on this list disagree that this
> concept is of any use to anybody, but I really am just going from
> personal experience working on distributed software projects. I think
> being able to see what bugs are outstanding can't do any harm, and is
> in
> fact of great use, but I guess some people just have very hardline
> views
> on the subject (as seems to be the case quite often in the technical
> community!)...

I think when more than one developer is working on bugs a bug tracking
system is usefull,  until now my TODO file was enough for me.

>> So if you can do anything for Embperl, let me/us know. I would be
>> very happy if Embperl is build on more shoulders than just mine.
> If you can direct me (act as a kind of technical team leader) toward
> what needs doing then that would be helpful. You know the code inside
> out. Are there any specific tasks that you need done, and you know in
> a general sense where to look but just don't have the time do do it?
> If
> you're willing to give me pointers then I'd be happy to have a go if
> it
> will help get 2.0 stable more quickly. I am never actually
> participated
> in the open source development process, so I hope you'll forgive my
> inexperience with that - but I have been programming for 20 years and
> C++ since 1989, Perl since 2000, so perhaps I can be of some use.
> Also, obviously, documentation. I'd like to think about an Embperl
> book in
> English.

The other thing that needs to be done, is to check for memory leaks. Embperl
has alreadysome support for it. YOu can run

make test TESTARGS="-hlv"

and make test will loop and show you the memory usage of the httpd process.
To debug this compile with

perl Makefile.PL dmalloc

which will compile in the dmalloc library and log some memory statistics to
the logfile, along with linenumber where the memory is allocated.

Writeing a book would be great. That's up to you.


Gerald Richter     ecos electronic communication services gmbh
IT-Securitylösungen * dynamische Webapplikationen * Consulting

Post:       Tulpenstrasse 5          D-55276 Dienheim b. Mainz
E-Mail:          Voice:   +49 6133 939-122
WWW:      Fax:     +49 6133 939-333
|   ECOS BB-5000 Firewall- und IT-Security Appliance:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message