# New Ticket Created by Will Coleda
# Please include the string: [perl #46933]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46933 >
Currently, Data::Dumper treats Undef pmcs like any other pmcs. When dumping,
then, i
tem:
# TODO: Use Data::Dumper
This is in the context of looking for missing files from the MANIFEST and
extra files not found in the MANIFEST. Exactly how Data::Dumper is
supposed to help here isn't 100% clear to me, however it might to someone
else I hope.
A brief look at this makes me
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46901]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46901 >
In tools/dev/manicheck.pl there is the todo item:
# TODO: Use Data::Dumper
This
Mark Glines via RT wrote:
I didn't hear back from kid51.
Mark, I was satisfied with your response but didn't have time to comment
further. My thoughts were 'qualms' rather than 'objections'. Practice
will provide better evidence to evaluate the change.
kid51
I didn't hear back from kid51. I believe data portability doesn't
matter in this case; all that matters is that Storable at the current
rev on the current platform is able to read it's own data for the next
10 seconds or so, which seems like a valid assumption. Pmichaud and
chromatic seem to agre
ttp://search.cpan.org/dist/Storable/Storable.pm#FORWARD_COMPATIBILITY).
> I have never heard such compatibility issues with respect to
> Data::Dumper. This is not a killer objection, but it should be
> considered.
>
> (2) Not that I'm opposed to Storable entirely. Hey, I u
ted with different versions
of Perl 5.8 (not to mention 5.6). Some of these issues are alluded to
in the POD
(http://search.cpan.org/dist/Storable/Storable.pm#FORWARD_COMPATIBILITY).
I have never heard such compatibility issues with respect to
Data::Dumper. This is not a killer objection, but it s
tch.
Mark
Index: lib/Parrot/Pmc2c/Pmc2cMain.pm
===
--- lib/Parrot/Pmc2c/Pmc2cMain.pm (revision 20762)
+++ lib/Parrot/Pmc2c/Pmc2cMain.pm (working copy)
@@ -4,7 +4,7 @@
use strict;
use warnings;
use FindBin;
-use Data::Dumper;
+use S
On Monday 20 August 2007 16:49:53 Mark Glines wrote:
> With this patch, parrot rebuilds for me in 1 minute 41 seconds, plus or
> minus a few seconds. That's almost 80 seconds faster; a 45% improvement
> in build time.
>
> For reference, I also tried YAML::Syck, which built in 1 minute 55
> seconds
On Mon Aug 20 16:49:53 2007, [EMAIL PROTECTED] wrote:
> With ccache, HEAD rebuilds for me in a little less than 3 minutes.
> (2:57, on average.)
>
> With this patch, parrot rebuilds for me in 1 minute 41 seconds, plus or
> minus a few seconds. That's almost 80 seconds faster; a 45% improvement
> i
Pmc2c/Pmc2cMain.pm
===
--- lib/Parrot/Pmc2c/Pmc2cMain.pm (revision 20738)
+++ lib/Parrot/Pmc2c/Pmc2cMain.pm (working copy)
@@ -4,7 +4,7 @@
use strict;
use warnings;
use FindBin;
-use Data::Dumper;
+use Storable;
use Parrot::Vtable;
use Parrot::PMC;
use Parrot::Pmc2c::VTable
s a line that has $Data::Dumper::VERSION in it. ExtUtils::Makemaker
has the same problem, because PAUSE and Makemaker look for
/([\$*])(([\w\:\']*)\bVERSION)\b.*\=/ in the source.
In the two places I saw $Data::Dumper::VERSION, Parrot really just
wants to know if Data::Dumper has Sortkeys(). J
# New Ticket Created by Will Coleda
# Please include the string: [perl #38252]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=38252 >
> [1:37p] audreyt : chromatic: there is already PIR binding for
> libsyck's parsing p
Data::Dumper now checks to see if a special case for a particular PMC is
implemented, and if
not, the code falls back to a generic implementation for each of array, hash,
string, integer,
and float.
Added in string, integer, and float does types to pmc2c.pl and the various
core/perl types
On Jul 23, 2005, at 23:14, Will Coleda (via RT) wrote:
With a check first to see if the pmc/object that was passed
implemented a "dump" method.
The opcode C does exist, as well as interface names like 'hash'
or 'array'.
new P0, .Hash
does I0, P0, 'hash'
print I0
See also
perldoc bui
# New Ticket Created by Will Coleda
# Please include the string: [perl #36641]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36641 >
It would be nice if, rather than the various "pmcPerlHash" and
"pmcPerlArray" variants
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> this patch adds support for the String PMC to Data/Dumper/Default.imc. It is
> treated just like the PerlString PMC.
Thanks, applied.
leo
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #32434]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32434 >
Hi,
this patch adds support for the String PMC to Data/Dumper/Default.
# New Ticket Created by Will Coleda
# Please include the string: [perl #31861]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31861 >
(I'm sure there are other new PMCs missing as well)
On Sunday, April 25, 2004, at 03:34 PM, Jens Rieks wrote:
(1) Tell me the indent level, so I can handle it manually.
Oh, this is not documented yet :-(
Perfect, thank you.
--
Will "Coke" Coledawill at coleda
dot com
Hi!
On Sunday 25 April 2004 17:01, Will Coleda wrote:
> I'm adding an object or two, and wanted to write my own __dump() method
> so I can be dumped out by Data::Dumper.
>
> Right now, there doesn't seem to be a way to integrate nicely with the
> indent level of the data
I'm adding an object or two, and wanted to write my own __dump() method
so I can be dumped out by Data::Dumper.
Right now, there doesn't seem to be a way to integrate nicely with the
indent level of the data structure I'm embedded in, so I see things
like:
PerlArray (size:2
Jens Rieks <[EMAIL PROTECTED]> wrote:
> the attached patch fixes null PMC dumping and adds a test for it.
Thanks, applied.
leo
push array, "0"
+
+null temp
+push array, temp
+
+new temp, .PerlInt
+set temp, 0
+push array, temp
+
+new temp, .PerlString
+set temp, "0"
+push array, temp
+
+_dumper( "array", array )
+end
+.end
+.include "library/dumpe
Jens Rieks <[EMAIL PROTECTED]> wrote:
> Hmm... no idea what went wrong. I've attached the whole file...
Thanks, applied.
leo
Hi,
On Sunday 14 March 2004 18:55, Leopold Toetsch wrote:
> Jens Rieks <[EMAIL PROTECTED]> wrote:
> > here is ready-for-commit version of Data::Dumper.
>
> Committed (forgot description and credits - sorry).
>
> Two tests are failing here
> t/pmc/dumper.t2
Jens Rieks <[EMAIL PROTECTED]> wrote:
> here is ready-for-commit version of Data::Dumper.
Committed (forgot description and credits - sorry).
Two tests are failing here
t/pmc/dumper.t2 512122 16.67% 8 12
Could be whitespace problem.
Thanks for the first OO app,
leo
Hi all,
here is ready-for-commit version of Data::Dumper.
Not everything is documented yet, but the original interface is still
functional.
Most of the code is now loaded with load_bytecode, which reduces memory usage
if several loaded modules are using the dumper.
New/modified things:
- the
Hi,
On Thursday 11 March 2004 16:31, Leopold Toetsch wrote:
> Jens Rieks <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > attached is an object orientated version of library/dumper.imc.
> > (it needs libraray/objecthacks.imc from yesterday)
>
> Should that still get applied? Major object syntax impr
Jens Rieks <[EMAIL PROTECTED]> wrote:
> Hi all,
> attached is an object orientated version of library/dumper.imc.
> (it needs libraray/objecthacks.imc from yesterday)
Should that still get applied? Major object syntax improvements are now
in. It should get much cleaner and simpler now.
leo
ch
small test adjustments
- library/dumper.imc
a compatibility interface
- library/Data/Dumper.imc
the Data::Dumper class
- library/Data/Dumper/Base.imc
base class for Dumper frontends
- library/Data/Dumper/Default.imc
default Dumper frontend
Comments welcome!
jens
dumper.tgz
Description: application/tgz
So it would be really nice to have a "Data::Dumper" be able to sort
> the keys, like the Perl one now can.
That's not specific to Data::Dumper. We are just lacking a sort routine.
> Tim.
leo
On Thu, Feb 05, 2004 at 02:35:38PM +0100, Leopold Toetsch wrote:
> Jens Rieks <[EMAIL PROTECTED]> wrote:
>
> > Here is a first version of a "Data::Dumper" i've written to be able to dump
> > the AST of my C parser.
>
> Wow, fine.
>
> > A
Am Donnerstag, 5. Februar 2004 16:25 schrieb Jens Rieks:
> Am Donnerstag, 5. Februar 2004 14:35 schrieb Leopold Toetsch:
> > Jens Rieks <[EMAIL PROTECTED]> wrote:
> > > Here is a first version of a "Data::Dumper" i've written to be able to
> > >
Am Donnerstag, 5. Februar 2004 14:35 schrieb Leopold Toetsch:
> Jens Rieks <[EMAIL PROTECTED]> wrote:
> > Here is a first version of a "Data::Dumper" i've written to be able to
> > dump the AST of my C parser.
>
> Wow, fine.
>
> > A dumpertes
Jens Rieks <[EMAIL PROTECTED]> wrote:
> Here is a first version of a "Data::Dumper" i've written to be able to dump
> the AST of my C parser.
Wow, fine.
> A dumpertest.imc is included, which shows the dumper in action.
s/included/missing/ :)
> I'am so
Here is a first version of a "Data::Dumper" i've written to be able to dump
the AST of my C parser.
A dumpertest.imc is included, which shows the dumper in action.
I'am sorry, but I have no idea how to convert this to a test. BTW, is the
order of the hash elements guarantee
37 matches
Mail list logo
