A. Pagaltzis wrote:
* Jim Cromie <[EMAIL PROTECTED]> [2003-11-14 17:43]:
Its not 'particular' to C, except in reduce(), the last step,
which acts on the detected redundancies. As I outlined, a Perl
version could move chunks into strings, then eval that in the
many places its needed.
Then
Hi,
I'm trying to contact the owner of the IPC::Shareable module.
There's a minor bug that I'd like to fix, but the email listed on cpan
rejects all my mails.
http://theoryx5.uwinnipeg.ca/mod_perl/cpan-search?new=Search;filetype=%20dis
tribution%20name%20or%20description;join=and;age=;ar
On Fri, Nov 14, 2003 at 02:19:44PM -0600, Eric Wilhelm wrote:
> > The following was supposedly scribed by
> > Mark Stosberg
> > on Friday 14 November 2003 02:02 pm:
>
> >Still that leaves the issue of naming it. It's still best described as
> >"a module for building CGI applications Mark's way".
> The following was supposedly scribed by
> Mark Stosberg
> on Friday 14 November 2003 02:02 pm:
>Still that leaves the issue of naming it. It's still best described as
>"a module for building CGI applications Mark's way". I could give it
>some generic name like "CGI::Application::TurboCharge", b
On Fri, Nov 14, 2003 at 01:33:01PM -0600, Eric Wilhelm wrote:
>
> >I think I have a similar concern. Here's my own case: I use a custom
> >sub-class of CGI::Application that I base most of my web-applications
> >on. Eventually, I would like to distribute some of these on CPAN, with
> >several of t
* On 14-Nov-2003 at 11:03AM PST, [EMAIL PROTECTED] said:
>
> > And because 'shred' is open-source, and part of the Linux vs
> > SCO drama, it serves as something of a touchstone - By
> > understanding the algorithm, you know its
> > advantages/disadvantages; fast but naive compared to parsing to
>
> The following was supposedly scribed by
> Mark Stosberg
> on Friday 14 November 2003 09:00 am:
>I think I have a similar concern. Here's my own case: I use a custom
>sub-class of CGI::Application that I base most of my web-applications
>on. Eventually, I would like to distribute some of these on
* Jim Cromie <[EMAIL PROTECTED]> [2003-11-14 17:43]:
> Its not 'particular' to C, except in reduce(), the last step,
> which acts on the detected redundancies. As I outlined, a Perl
> version could move chunks into strings, then eval that in the
> many places its needed.
Then maybe it should be s
A. Pagaltzis wrote:
* Jim Cromie <[EMAIL PROTECTED]> [2003-11-14 09:35]:
My version has a different focus, namely to find duplicate code
chunks, write macros for them, and invoke those macros. So
maybe a different name is appropriate.
So it is aimed at processing C sources? Then File:: is
From: A. Pagaltzis [EMAIL PROTECTED]
> I wasn't saying the code was trash - but a carelessly chosen name
> and no documentation do make it clutter..
I agree it's clutter that's why I'd like it not to be included when people
search. The name is chosen for my convenience and mine only. As Mark
menti
On Fri, Nov 14, 2003 at 08:57:28AM -0500, [EMAIL PROTECTED] wrote:
>
> Original Message:
> -
> From: Struan Donald [EMAIL PROTECTED]
>
> > And if you're including the code in several CPAN modules then
> > shouldn't the code be up to standard for general use? Just because you
> > c
* Jim Cromie <[EMAIL PROTECTED]> [2003-11-14 09:35]:
> My version has a different focus, namely to find duplicate code
> chunks, write macros for them, and invoke those macros. So
> maybe a different name is appropriate.
So it is aimed at processing C sources? Then File:: is the wrong
TLNS for it
* Fergal Daly <[EMAIL PROTECTED]> [2003-11-14 13:10]:
> But what about code that is shared by several CPAN modules but
> which I don't consider to be worth getting up to standard for
> general use. It's not that the code is "trash", it's fine I
> just can't see anyone else wanting to use it, even i
Original Message:
-
From: Struan Donald [EMAIL PROTECTED]
> And if you're including the code in several CPAN modules then
> shouldn't the code be up to standard for general use? Just because you
> can't see anyone wanting to use it doesn't mean it shouldn't be
> documented.
The
Title: RE: Author's namespace
> * at 14/11 10:25 + Fergal Daly said:
> > But what about code that is shared by several CPAN modules
> but which I
> > don't consider to be worth getting up to standard for general use.
> > It's not that the code is "trash", it's fine I just can't see anyone
* at 14/11 10:25 + Fergal Daly said:
> But what about code that is shared by several CPAN modules but which I
> don't consider to be worth getting up to standard for general use.
> It's not that the code is "trash", it's fine I just can't see anyone
> else wanting to use it, even if it was full
But what about code that is shared by several CPAN modules but which I don't
consider to be worth getting up to standard for general use. It's not that
the code is "trash", it's fine I just can't see anyone else wanting to use
it, even if it was fully documented.
I suppose I'll just have to upload
Hi folks,
Ive written a module which implements Eric Raymonds 'shred'
program, which is pretty well described here.
http://www.arstechnica.com/archive/news/1063140308.html
File::Shred is my working name
My version has a different focus, namely to find duplicate code chunks,
write macros for them
18 matches
Mail list logo
