On Thu, Feb 11, 2010 at 11:06:38AM +0000, Tim Bunce wrote:
> On Tue, Feb 09, 2010 at 06:11:13PM +0000, Nicholas Clark wrote:
> > On Tue, Feb 09, 2010 at 05:46:23PM +0000, Tim Bunce wrote:
> > > On Tue, Feb 09, 2010 at 03:33:53PM +0000, Nicholas Clark wrote:
> > > >
> > > > I'm just not yet sure about the C source file names. I assume that the
> > > > file
> > > > handle XS stays in Devel::NYTProf::FileHandle, so it's a name for the
> > > > low(er)
> > > > level IO code, such as output_int() and friends.
> > >
> > > Seems reasonable. Though perhaps FileHandle should disappear and the
> > > guts of it become private to the new higher-level interface.
> > > Trying to keep FileHandle around may give more pain for little gain.
> >
> > There seem to be several parts. And I'm not sure how to name them
> >
> > 1: The C functions in FileHandle.xs, prefixed NYTP_, which deal with the low
> > level operations of moving data in and out of files
> > 2: The building blocks immediately on top of them (output_{int,nv,str})
> > currently in NYTProf.xs
> > 3: The higher level abstractions (that don't yet exist) - a subroutine per
> > tag type that we need to output
> > 4: Potentially a C callback based input parser
> > (With NYTProf.xs refactored to supply callbacks to read the data)
> >
> > There would need to be XS wrappers to (at least) the open and close
> > functions
> > in (1), and everything in (3).
>
> Yes, though 3 should probably encapsulate the open and close functions in 1.
> So 1 would then be completely hidden.
>
> > (2) is what nytprofmerge currently uses. In theory we could abolish
> > wrappers of (2), *but* it would be useful to keep them to facilitate
> > prototyping and doing things outside the current applications.
>
> Umm, seems like YAGNI to me at the moment. Got a use-case?
Regression testing - writing partially well formed files.
> > So in theory all of the above C functions could be in one file.
> > Or in two. (1) vs (2,3,4)
> > Or in two. (1,2) vs (3,4)
> >
> > I'm not sure which.
>
> I'd be happy with one for the C code, generating an nytprofio library,
> and one, or more, for the read/write XS interface(s) to that library.
>
> > And I'm not sure whether the XS wrappers go in the same file, or a different
> > file. And 1 namespace or several.
>
> I can see strategic value in having XS wrappers in a separate file.
> In that keeping the C code separate and free from perl-isms would move
> us closer to being able to generate data for NYTProf from other sources.
Removing perl-isms would require rewriting read_str(), as it returns an SV.
That's not a problem - it just means thinking about what's the best way to
represent a string that may (or may not) be UTF-8 encoded.
> > Or what names anything has. Particularly as "profile" could mean the
> > abstract
> > concept of a profile, or routines to manipulate a file on disk in our
> > format.
> > [ie (2,3,4) above]
>
> 'nytprofio' seems like a reasonable name for the C code implementing the I/O.
For now I have a local branch with everything in FileHandle.xs, which I was
proposing to push upstream as a first step. My thought was that it will be
easier to see how to tease it apart once it's all there.
Nicholas Clark
--
You've received this message because you are subscribed to
the Devel::NYTProf Development User group.
Group hosted at: http://groups.google.com/group/develnytprof-dev
Project hosted at: http://perl-devel-nytprof.googlecode.com
CPAN distribution: http://search.cpan.org/dist/Devel-NYTProf
To post, email: [email protected]
To unsubscribe, email: [email protected]
