On Thu, Feb 11, 2010 at 01:35:25PM +0000, Nicholas Clark wrote:
> 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:
> > >
> > > 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.
Doesn't seem like a very compelling reason to create, document and test
a public API.
> > > 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.
I don't see as much value in avoiding perl-isms on the reading side.
Though I guess allowing perl-isms on the reading side implies having
separate libraries for writing and reading, which probably isn't
worthwhile.
> > > 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.
If you're confident you'll have the time to tease it apart then I'd be
happy for it to go in that way.
Though we should probably do a release first and let the dust settle on
that. Umm, I wonder if it would be worthwhile to move the code to github.
Tim.
--
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]
