pas-dev

Re: [Pas-dev] Precompiling psp's

[Kyle R . B. <mo...@vo...>]

> After I make the metadata contain perlcode you can eval instead of being a
> flat file list, I'm going to write a tool to compile psp's. Sort of like
> jspc or whatever.

Why have the meta data contain perlcode?  Oh, wait, I think I get it.  We
make the meta data an object, so it can store _more_ information than just
includes (in the future of course).  So the pageObject.pm.deps becomes
pageObject.pm.meta, which is just a serialized Org::Bgw::Pas::Psp::PageMeta
object?  That way in the code we can:

  use Data::Dumper;
  $self->writeFile( $metaData, Dumper( $metaData ) );

and:

  my $metaData = do $metaData;

Then as we update the PageMeta object, everything continues to work?

What about version differences?  We have issues either if we use a 
syntax for the meta data file, or if we use serialized perl -- we 
might add/remove/rename properties of the PageMeta object.  Which would
break old versions of the .meta files.

Maybe we should store a version as the first thing in the meta file:

  use Data::Dumper;
  $self->writeFile( $metaData, "V" . $Org::Bgw::Psp::PageMeta::VERSION . "\n" . Dumper( $metaData ) );

hrm, but that prevents us from just using "do $file;" to re-gen the 
file iteself...


Oh, wait, we can store the version as a data element of the PageMeta object.
Then after we re-load it:

  my $metaData = do $metaData;
  if( $metaData->versionMisMatch() ) {
    # throw out this meta data, and try to recompile the page to 
    # bring the meta data up to date because versions changed...
    $self->warning("Meta version mismatch, attempting to recompile.\n");
  }

> Actually, I should write an antlike tool for the site and call it pants 
> :)

I get "Perl Ant", but whats the 's' stand for?

There is already an attempt at a build tool in the bin directory.  Though
compared to the new features you're adding, it's lacking.

Oh, another thing -- we should look at refactoring your chagnes into the
compiler itself.  I think it'd be more widely useable if the dependency 
checking were part of the compiler -- it doesn't feel like it should be
pat of the request handler.


k


-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

Re: [Pas-dev] Precompiling psp's

[Mental <Me...@Ne...>]

On Fri, Mar 01, 2002 at 01:49:55PM -0500, Kyle R . Burton wrote:
> Why have the meta data contain perlcode?  Oh, wait, I think I get it.  We
> make the meta data an object, so it can store _more_ information than just
> includes (in the future of course).  So the pageObject.pm.deps becomes
> pageObject.pm.meta, which is just a serialized Org::Bgw::Pas::Psp::PageMeta
> object?  That way in the code we can:
> 
>   use Data::Dumper;
>   $self->writeFile( $metaData, Dumper( $metaData ) );
> 
> and:

I was thinking just using perl code. I'm on the fence about using objects.
I suppose it wouldnt be a big deal either way. But if the dep file
contained an array called @includes you could find the includes. If I had
a hash called %metatags you could do something with that. I'm not sure
what else we'd put in it, but this leaves the door open.

> 
>   my $metaData = do $metaData;
> 
> Then as we update the PageMeta object, everything continues to work?
> 
> What about version differences?  We have issues either if we use a 
> syntax for the meta data file, or if we use serialized perl -- we 
> might add/remove/rename properties of the PageMeta object.  Which would
> break old versions of the .meta files.


In my mind, needing ot flush the cache when you upgrade pas isnt a _huge_
deal. In fact, the app could tell if the page object needed rebuilt by
doing an eval on the .dep(meta) file. I refuse to let a little thing like
backwards compatibility deter improoved functionality. Safve that mindset
for windows :)


> 
> Maybe we should store a version as the first thing in the meta file:
> 
>   use Data::Dumper;
>   $self->writeFile( $metaData, "V" . $Org::Bgw::Psp::PageMeta::VERSION . "\n" . Dumper( $metaData ) );
> 
> hrm, but that prevents us from just using "do $file;" to re-gen the 
> file iteself...
> 
> 

Overkill. Just flush it if you cant eval it. Its generated crud. No user
data is in there, so nothing is lost. Brute force good. Thinking bad.


> Oh, wait, we can store the version as a data element of the PageMeta object.
> Then after we re-load it:
> 
>   my $metaData = do $metaData;
>   if( $metaData->versionMisMatch() ) {
>     # throw out this meta data, and try to recompile the page to 
>     # bring the meta data up to date because versions changed...
>     $self->warning("Meta version mismatch, attempting to recompile.\n");
>   }
> 
> > Actually, I should write an antlike tool for the site and call it pants 
> > :)
> 
> I get "Perl Ant", but whats the 's' stand for?
> 

It stand for a word that starts with s. And sounds funny. :)
Whats awk stand for? If you answer that I'll shoot you :)

> There is already an attempt at a build tool in the bin directory.  Though
> compared to the new features you're adding, it's lacking.
> 

So? Its a start and can be all smothered in fixed.

> Oh, another thing -- we should look at refactoring your chagnes into the
> compiler itself.  I think it'd be more widely useable if the dependency 
> checking were part of the compiler -- it doesn't feel like it should be
> pat of the request handler.
>


I figured the opposite. The RequestHandler knows and cares about where
stuff is and how it should be used and if it should be served up. The
Compiler is stupid. 

RequestHandler says "Do this", compiler does as its told. If its asked for
dependency data, it'll provide it. Otherwise why should it care? What ifd
dynamic recompile is off? What if... I dunno. I just dont see the harm of
leting RequestHandler decide on what The Right Thing is and telling the
compiler how (and when) to do it.

But, if you want to move it thats fine. I just figured the RequestHandler
was already doing the time checks (and so will our precompiler). The time
doesnt affect _how_ a psp is compiled, so why shoulld it matter to the
compiler? gcc doesnt look at mtime, make does.


--
Mental (Me...@Ne...)

It's a small world, but I wouldn't want to have to paint it.
--Steven Wright

GPG public key: http://www.neverlight.com/Mental.asc

Re: [Pas-dev] Precompiling psp's

[Kyle R . B. <mo...@vo...>]

> I was thinking just using perl code. I'm on the fence about using objects.
> I suppose it wouldnt be a big deal either way. But if the dep file
> contained an array called @includes you could find the includes. If I had
> a hash called %metatags you could do something with that. I'm not sure
> what else we'd put in it, but this leaves the door open.

I preferr objects to naked data structures.  An object's methods are in
at least a small part documentation about what they are -- if we keep
following the convention of POD documenting all of the methods, then 
any data element that shows up in the .meta file can be tracked directly
back to some human readable documentation.  If it's a naked hash the elements
have absolutely no meaning.  Objects are much more opaque, which actualy
aids in understanding of what's going on.

Object methods also represent actions, behavior.  Data structures don't
represent anyting other than a grouping of dta elements.  That might
beon one of the core reasons OO is [generaly] considered easier to 
understand than procedural programming.  Especially as things scale
up.

> In my mind, needing ot flush the cache when you upgrade pas isnt a _huge_
> deal. In fact, the app could tell if the page object needed rebuilt by
> doing an eval on the .dep(meta) file. I refuse to let a little thing like
> backwards compatibility deter improoved functionality. Safve that mindset
> for windows :)

Yeah, but if we include a data member VERSION from the start, we can have
the app self check itself.  We like self checking/verifying code right?  
It's like a unit test.  It might not need to be part of the request handler,
but we could make it part of the build tool, or part of a system check 
program that users are supposed to run between upgrades.

If we do it we have the opportunity to win, even if we decide not to
do it.  If we don't do it, we have no opportunity to win.  Is it worth
the extra effort?  I think it is.

> > hrm, but that prevents us from just using "do $file;" to re-gen the 
> > file iteself...
> 
> Overkill. Just flush it if you cant eval it. Its generated crud. No user
> data is in there, so nothing is lost. Brute force good. Thinking bad.
> 

> It stand for a word that starts with s. And sounds funny. :)
> Whats awk stand for? If you answer that I'll shoot you :)

Aho, Weinberger and Kernighan (see man awk).  It's the initials of the
authors of the tool. X-)

> I figured the opposite. The RequestHandler knows and cares about where
> stuff is and how it should be used and if it should be served up. The
> Compiler is stupid. 

Uhm, it's the compiler that decides how to turn a psp file path into a
package name, and then turn a package name into a psp-cache file name.

I'm not talking about coding the behavior of deciding to recompile into
the compiler -- just the functionality your patch added - functions that
check for file existance, for the ctime critera, for the dependency 
ctime criteria.  Let the external caller decide if compilation should be
done or not, but the compiler should be the thing that answers the 
folowing questions:

  "does the compiled page exist"
  "is the psp newer than the compiled page"
  "are any of the includes newer than the cmpiled page"
and ultimately:
  "is the compiled page out of date"

Regardless of these answers, the request handler, or the build tool [pants]
will be the thing that decides if the page should be recompiled or not.
I just think we should hide all of this behavior behind an interface -- the
compiler feels like the right place to do that.  The request handler shold
be just that -- a request handler.  It might check for recompilation, but
it shouldn't have to figure out dependency relationships (that's the comilers
job).  At least in my opinion.

> RequestHandler says "Do this", compiler does as its told. If its asked for
> dependency data, it'll provide it. Otherwise why should it care? What ifd
> dynamic recompile is off? What if... I dunno. I just dont see the harm of
> leting RequestHandler decide on what The Right Thing is and telling the
> compiler how (and when) to do it.
> 
> But, if you want to move it thats fine. I just figured the RequestHandler
> was already doing the time checks (and so will our precompiler). The time
> doesnt affect _how_ a psp is compiled, so why shoulld it matter to the
> compiler? gcc doesnt look at mtime, make does.

Thats right.  I think we're kind of saying the smae thing.  Just from
different approaches.  If we create the build tool as an object so either
the request handler, _or_ some command line tool can invoke it to 
both decide if a file should be recompiled, and recompile it, then great.

I just don't want duplicated code/behavior -- since both the build tool
and the request handler have to perform the 'is out fo date' check based
on dep information, the compiler feels like the right place to put it for
now.  Though a build tool as an object would be better.

k

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------

[Mental@NeverLight.com: Re: [Pas-dev] Precompiling psp's]

[Mental <Me...@Ne...>]

On Fri, Mar 01, 2002 at 03:01:19PM -0500, Kyle R . Burton wrote:
> Thats right.  I think we're kind of saying the smae thing.  Just from
> different approaches.  If we create the build tool as an object so either
> the request handler, _or_ some command line tool can invoke it to 
> both decide if a file should be recompiled, and recompile it, then great.
> 
> I just don't want duplicated code/behavior -- since both the build tool
> and the request handler have to perform the 'is out fo date' check based
> on dep information, the compiler feels like the right place to put it for
> now.  Though a build tool as an object would be better.
> 

I was thinking of having the build tool invoke the RequestHandler. But now
that I think aobut it we could do what you're talking about in the
compiler. But I still think the compiler should just compile. 

Maybe the request handler should talk to an object broker that knows how
to talk to the compiler (if it thinks it needs to). This way both the
build tool and the request handler share the same code (the object
broker) and the compiler stays a compiler. My fear is that we'll wind up
over engineering the compiler and wind up with emacs. :)

I just want something that compiles stuff. I have no problems at all with
asking Org::Bgw::Pas::ObjectBroker for an object. In fact, I could care
less what it does to get me the object, so long as it tells me where it
is.

Besides, then we'll be all buzz word compliant :)

At least I think so. Seems to fit the definition:

In brokering a client request, an ORB may provide all of these services:

    * Life cycle services, which define how to create, copy, move, and
    * delete a component
    * Persistence service, which provide the ability to store data on
    * object database, , and plain files
    * Naming service, which allows a component to find another component
    * by name and also supports existing naming systems or directories,
    * including DCE, , and Sun's NIS (Network Information System).
    * Event service, which lets components specify events that they want
    * to be notified of
    * Concurrency control service, which allows an ORB to manage locks to
    * data that transactions or threads may compete for
    * transaction service, which ensures that when a transaction is
    * completed, changes are committed, or that, if not, database changes
    * are restored to their pre-transaction state
    * Relationship service, which creates dynamic associations between
    * components that haven't "met" before and for keeping track of these
    * associations
    * Externalization service, which provides a way to get data to and
    * from a component in a "stream"
    * Query service, which allows a component to query a database. This
    * service is based on the SQL3 specification and the Object Database
    * Management Group's (ODMG) Object Query Language (OQL).
    * Licensing service, which allows the use of a component to be
    * measured for purposes of compensation for use. Charging can be done
    * by session, by node, by instance creation, and by site.
    * Properties service, which lets a component contain a
    * self-description that other components can use.


Maybe my definition is a bit off, but you get teh idae. 

I hope.

--
Mental (Me...@Ne...)

I watched the Indy 500, and I was thinking that if they left
earlier they wouldn't have to go so fast.
--Steven Wright

GPG public key: http://www.neverlight.com/Mental.asc