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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
