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
------------------------------------------------------------------------------