On Thu, Feb 11, 2010 at 04:53:37PM +0000, Tim Bunce wrote:
> 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.
It's neither tested nor documented currently :-)
It's probably as easy to yank it, and note where to find it in version control
history if one needs it back.
> > > > 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.
Yes, that's the bind.
> > > > 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.
My time might be about to go away, in that there's likely to soon be a more
important project for me to work on, and I don't know if that will be weeks,
or a couple of months, and what proportion of my time it will eat.
> 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.
Possibly a release. I don't think that I have any bugs fixed locally.
You're welcome to, but I'm not prepared to sign up to the github T&Cs
(specifically F3). So if that happens, I won't be committing directly any
longer. The denizens of IRC are probably biased, but at least a subset of
us seem to think that shadowcat's git server is more reliable than "slowhub".
I'm actually using git-svn locally to talk to Google code, so I'd prefer a
move to git.
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]
