Mailing List Archive: [1.3b2] Silent death, noisy death; CMS extensions

[1.3b2] Silent death, noisy death; CMS extensions

Mar 31, 2000, 11:46 AM

Post #1 of 7 (2363 views)

I am porting my source code archive browser presentation system, Safari,
to be able to use Embperl. I like it: it took all of 10 lines of code to
make a filter out of it. Safari now uses it for building it's "header"
and "footer" html, and it can be used to process source files before
display. <BRAG>Both uses are seen in this little test case:

http://slaysys.com/saf_dev/-/embperl/index.epl

Here, the output of the Embperl filter that processed index.epl is sent
through a syntax highlighter:

http://slaysys.com/saf_dev/s/embperl/index.epl
</BRAG>

1. Silent death

In so doing, I inserted some perl code containing '[*]' in a [! ... !]
block. It was in the middle of several hundred lines, and I didn't notice
it :-(.

Anyway, I suddenly got "document contained no data", rather than some form
of warning or error. Would it be possible to generate an error in this case?

Just stick a '[*]' (quotes optional) in a [!...!] block and you should be
able to reproduce it. Here's the backtrace, FWIW:

(gdb) bt
#0 0x400ed8a7 in memcpy (dstpp=0x87d2c04, srcpp=0x87b69a3, len=4294967295) at ../sysdeps/generic/memcpy.c:55
#1 0x401cc0aa in EMBPERL_owrite ()
#2 0x401d17f6 in EMBPERL_EvalMain ()
#3 0x401cafb6 in ProcessFile ()
#4 0x401cb6a7 in EMBPERL_ExecuteReq ()
#5 0x401c4f97 in XS_HTML__Embperl__Req_ExecuteReq ()
#6 0x80872d6 in Perl_pp_entersub ()
#7 0x80b114d in Perl_runops_standard ()
#8 0x8059308 in perl_run ()
#9 0x805789f in main ()

2. Noisy death

I still didn't see the problem after a reread, so I reached behind my seat
for the shotgun and added "debug => 0xFFFF," to
HTML::Embperl::Execute( { ... } ) to see what might be going on.

After removing enough chunks of code that I found my [*] and [[*]]ed it,
Embperl then coughed up this:

Usage: HTML::Embperl::logevalerr(r,sText) at /usr/lib/perl5/site_perl/5.005/i686-linux/HTML/Embperl.pm line 409.

3. CMS extensions

On another topic, a couple of things that might make it nicer for
embedding in Content Management Systems (a la Zope, or the Perlian
Iajutsu (uses Wardley's toolkit, Jellybeans, Safari: building Perlish
CMSs is quite popular right now). Please forgive me if these already
exist and I missed them in the docs or the sources.

A. Being able to flush the output half way through when an output_func is
defined. When creating a really large bolus of HTML, or when about to
embark on a time consuming query, it'd be nice to be able to send what's
accumulated so far to the output_func. I looked at the source code with
an eye toward patching, but this seemed a bit non trivial, and I'm not
at all sure how it would interact with the commit/rollback code in the
io module.

B. An easy way to export variables and functions to the package containing
a page, so that I could export Safari's $context object in to a page's
namespace easily without having to add code to the page. Currently I can
import things in to the page and pass things in via @param, but that means
all such pages need that extra little bit of boilerplate.

C. Access to %udat and %mdat from outside the pages.

D. Some way of implementing inheritence on %mdat and perhaps %udat.
The idea here being able to implement attribute inheritence that kicks
in when a key doesn't exist in the hash. Whether this would be better
done in Embperl.pm or EmbperlObject.pm, I haven't figured out.

Anyway, thanks for a great module && keep up the good work!

- Barrie

RE: [1.3b2] Silent death, noisy death; CMS extensions [ In reply to ]

richter at ecos

Apr 2, 2000, 4:56 AM

Post #2 of 7 (2308 views)

Permalink

> I am porting my source code archive browser presentation system, Safari,
> to be able to use Embperl. I like it: it took all of 10 lines of code to
> make a filter out of it. Safari now uses it for building it's "header"
> and "footer" html, and it can be used to process source files before
> display. <BRAG>Both uses are seen in this little test case:
>
> http://slaysys.com/saf_dev/-/embperl/index.epl
>
> Here, the output of the Embperl filter that processed index.epl is sent
> through a syntax highlighter:
>
> http://slaysys.com/saf_dev/s/embperl/index.epl
> </BRAG>
>

:-)

>
> 1. Silent death
>
> In so doing, I inserted some perl code containing '[*]' in a [! ... !]
> block. It was in the middle of several hundred lines, and I didn't notice
> it :-(.
>
> Anyway, I suddenly got "document contained no data", rather than some form
> of warning or error. Would it be possible to generate an error
> in this case?
>

Yes, of course there should be an error message. Embperl treats the [*] as
the start of a [* *], which is parsed out before anything else, so it's also
found inside other block. This is of course not the intened behaviour and
should be treated as a bug!
[* *] still experimental. I am currently start working on Embperl 2.0, for
which I do a complete rewrite of the parser and I will surly adress this
issue there...

> Just stick a '[*]' (quotes optional) in a [!...!] block and you should be
> able to reproduce it. Here's the backtrace, FWIW:
>

I try to fix at least this SIGSEGV soon.

>
> 2. Noisy death
>
> I still didn't see the problem after a reread, so I reached behind my seat
> for the shotgun and added "debug => 0xFFFF,"

Don't do this. At least you should _never_ set dbgCacheDisable = 32768,
because it does very inpreditable thing (I really have to remove it from
Embperl, it's very old and I haven't done anything on it for a long time)

> to
> HTML::Embperl::Execute( { ... } ) to see what might be going on.
>
> After removing enough chunks of code that I found my [*] and [[*]]ed it,
> Embperl then coughed up this:
>
> Usage: HTML::Embperl::logevalerr(r,sText) at
> /usr/lib/perl5/site_perl/5.005/i686-linux/HTML/Embperl.pm line 409.
>

That is because of the dbgCacheDisable = 32768, so set debug to 0x7fff and
this error will disapear.

>
> 3. CMS extensions
>
> On another topic, a couple of things that might make it nicer for
> embedding in Content Management Systems (a la Zope, or the Perlian
> Iajutsu (uses Wardley's toolkit, Jellybeans, Safari: building Perlish
> CMSs is quite popular right now). Please forgive me if these already
> exist and I missed them in the docs or the sources.
>
> A. Being able to flush the output half way through when an output_func is
> defined. When creating a really large bolus of HTML, or when about to
> embark on a time consuming query, it'd be nice to be able to send what's
> accumulated so far to the output_func. I looked at the source code with
> an eye toward patching, but this seemed a bit non trivial, and I'm not
> at all sure how it would interact with the commit/rollback code in the
> io module.
>

So you want to have output_func called multiple times for a document?
Currently it's only called after the end of the request and you are right
that's not total trivial to change this. If you send your output directly to
the browser, you could set optEarlyHttpHeader in your httpd.conf, then all
output is send directly to the browser, without buffering it.

> B. An easy way to export variables and functions to the package containing
> a page, so that I could export Safari's $context object in to a page's
> namespace easily without having to add code to the page. Currently I can
> import things in to the page and pass things in via @param, but that means
> all such pages need that extra little bit of boilerplate.
>

That's already on the todo list

> C. Access to %udat and %mdat from outside the pages.
>

Also on the todo list

> D. Some way of implementing inheritence on %mdat and perhaps %udat.
> The idea here being able to implement attribute inheritence that kicks
> in when a key doesn't exist in the hash. Whether this would be better
> done in Embperl.pm or EmbperlObject.pm, I haven't figured out.
>

That's a good idea. The question is how how should this inherence work?
Where in which %mdat/%udat should Embperl look next when a key doesn't
exist?

Gerald

-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------

Re: [1.3b2] Silent death, noisy death; CMS extensions [ In reply to ]

barries at slaysys

Apr 2, 2000, 8:29 AM

Post #3 of 7 (2303 views)

Permalink

Gerald Richter wrote:
>
> [* *] still experimental. I am currently start working on Embperl 2.0, for
> which I do a complete rewrite of the parser and I will surly adress this
> issue there...

Are you moving to parser generator, like lex/yacc, or hand coded?

> I try to fix at least this SIGSEGV soon.

Thanks.

> "debug => 0xFFFF,"
>
> Don't do this.

Ok :-).

> So you want to have output_func called multiple times for a document?
> Currently it's only called after the end of the request and you are right
> that's not total trivial to change this. If you send your output directly to
> the browser, you could set optEarlyHttpHeader in your httpd.conf, then all
> output is send directly to the browser, without buffering it.

The reason I want this is so that when I'm sending output downstream to
another filter (like the syntax highligher example above, or something
like GzipChan), it can move in smaller chunks and not consume huge tracts
of VM.

> That's already on the todo list
...
> Also on the todo list

Cool!

> > D. Some way of implementing inheritence on %mdat and perhaps %udat.
> > The idea here being able to implement attribute inheritence that kicks
> > in when a key doesn't exist in the hash. Whether this would be better
> > done in Embperl.pm or EmbperlObject.pm, I haven't figured out.
> >
>
> That's a good idea. The question is how how should this inherence work?
> Where in which %mdat/%udat should Embperl look next when a key doesn't
> exist?

Cop out: just let the caller provide a "keyfault" function for each
of the hashes that gets called on a FETCH or STORE with non existent
keys. Maybe that isn't such a good mechanism: how would you iterate
over the keys?

Anyway, some uses for inheritence might be

- inheriting attributes for a display object, like what format to put
dates in or how to diplay a month (%mdat) for a calander display
object.

- inheriting permissions from groups (%udat)

- inheriting preferences from profiles (%udat, %mdat)

The kind of up-the-dir-tree inheritence implemented by EmbperlObject
is nice for displayable resources, but implementing a type tree or
a permissions tree that is independant of the file structure layout
would be handy.

Perhaps a get()/set() API would be better than tie()in the hashes,
though.

Just some thoughts.

- Barrie

RE: [1.3b2] Silent death, noisy death; CMS extensions [ In reply to ]

richter at ecos

Apr 2, 2000, 10:48 AM

Post #4 of 7 (2301 views)

Permalink

>
> Are you moving to parser generator, like lex/yacc, or hand coded?
>

I currently evaluate if there is something that can handle my ideas, but I
think I will create on of my own.

>
> The reason I want this is so that when I'm sending output downstream to
> another filter (like the syntax highligher example above, or something
> like GzipChan), it can move in smaller chunks and not consume huge tracts
> of VM.
>

Embperl 2.0 will be much better for chaining things. I will keep your ideas
in mind, when I make the final design.

>
> > > D. Some way of implementing inheritence on %mdat and perhaps %udat.
> > > The idea here being able to implement attribute inheritence that kicks
> > > in when a key doesn't exist in the hash. Whether this would be better
> > > done in Embperl.pm or EmbperlObject.pm, I haven't figured out.
> > >
> >
> > That's a good idea. The question is how how should this inherence work?
> > Where in which %mdat/%udat should Embperl look next when a key doesn't
> > exist?
>
> Cop out: just let the caller provide a "keyfault" function for each
> of the hashes that gets called on a FETCH or STORE with non existent
> keys. Maybe that isn't such a good mechanism: how would you iterate
> over the keys?
>
> Anyway, some uses for inheritence might be
>
> - inheriting attributes for a display object, like what format to put
> dates in or how to diplay a month (%mdat) for a calander display
> object.
>

There it would make sense to me to have the same inherence tree like
EmbperlObject has, kind of up-the-dir-tree

> - inheriting permissions from groups (%udat)
>

How do we create a group? A user for %udat, is just a session key. Maybe
there could be a function that defines: This user is of group X. This
function has to be called from the user page?

> - inheriting preferences from profiles (%udat, %mdat)
>
> The kind of up-the-dir-tree inheritence implemented by EmbperlObject
> is nice for displayable resources, but implementing a type tree or
> a permissions tree that is independant of the file structure layout
> would be handy.
>

yes, of course, but I still have no good idea how define the inherence tree.
Ok, we could provide the keyfault callback, then it would be up to the user
to define his own inherence schema. I keep it in mind.

> Perhaps a get()/set() API would be better than tie()in the hashes,
> though.
>

The tied hash interface is shorter to write. You could always say

$obj = tied (%udat) ;
$obj -> FETCH ('foo') ;

then you have an get API, but what do you gain by that?

Gerald

-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------

Re: [1.3b2] Silent death, noisy death; CMS extensions [ In reply to ]

barries at slaysys

Apr 2, 2000, 2:27 PM

Post #5 of 7 (2307 views)

Permalink

Gerald Richter wrote:
>
> yes, of course, but I still have no good idea how define the inherence tree.
> Ok, we could provide the keyfault callback, then it would be up to the user
> to define his own inherence schema. I keep it in mind.

Thanks. I think leaving up to the CMS author to define varied and wondrous
forms of inheritence is good, though the more obvious forms (up-the-dir-tree
and some type of type based inheritence) should be built in or easily doable.

>
> > Perhaps a get()/set() API would be better than tie()in the hashes,
> > though.
> >
>
> The tied hash interface is shorter to write. You could always say
>
> $obj = tied (%udat) ;
> $obj -> FETCH ('foo') ;
>
> then you have an get API, but what do you gain by that?

The thought behinbd set/get API is that if you have a hash interface
with the keyfault callback: how do you implement key iteration?

set()/get() doesn't imply key iteration. And people could inherit
from Embperl to provide them instead of callbacks.

I'm not really concerned with the API form, just the generic
functionality. I think Embperl is ideally positioned to capture
a large core of the Perl based CMS arena, just by providing easy
hooks for CMS authors to implement whatever inheritence and
contextualality they desire.

Just my 0.02c, of course.

- Barrie

RE: [1.3b2] Silent death, noisy death; CMS extensions [ In reply to ]

richter at ecos

Apr 3, 2000, 9:02 PM

Post #6 of 7 (2315 views)

Permalink

> >
> > The tied hash interface is shorter to write. You could always say
> >
> > $obj = tied (%udat) ;
> > $obj -> FETCH ('foo') ;
> >
> > then you have an get API, but what do you gain by that?
>
> The thought behinbd set/get API is that if you have a hash interface
> with the keyfault callback: how do you implement key iteration?
>

That would be hard of course, but you don't have a good idea how to make key
iteration, you can simply replace it by a warn "Not possible" and write it
in the docs!

> set()/get() doesn't imply key iteration. And people could inherit
> from Embperl to provide them instead of callbacks.
>

You can inherit from HTML::Embperl::Session and overwrite the FETCH and
STORE and so on. Currently there is no way to tell Embperl to use your new
class, but this could be changed.

> I'm not really concerned with the API form, just the generic
> functionality. I think Embperl is ideally positioned to capture
> a large core of the Perl based CMS arena, just by providing easy
> hooks for CMS authors to implement whatever inheritence and
> contextualality they desire.
>

I agree

Gerald

RE: Overwrite Session handling (was: [1.3b2] Silent death, noisy death; CMS extensions) [ In reply to ]

richter at ecos

Apr 13, 2000, 2:39 PM

Post #7 of 7 (2318 views)

Permalink

>
> I'm not really concerned with the API form, just the generic
> functionality. I think Embperl is ideally positioned to capture
> a large core of the Perl based CMS arena, just by providing easy
> hooks for CMS authors to implement whatever inheritence and
> contextualality they desire.
>
You may take a look at the CVS Version of Embperl I just commited, it allows
you to overwrite the default session handling class (HTML::Embperl::Session)
and give the new name via EMBPERL_SESSION_HANDLER_CLASS to Embperl.

Gerald