parseperl-discuss — Parse::Perl Discussion List

[Parseperl-discuss] Hello && PPI Unicode && overload

[Chris D. <ch...@ch...>]

Hi all,

I'm new to the PPI project -- Adam just added me to the sourceforge  
CVS committers list.

I started work on a Unicode improvement yesterday to support basic  
UTF-8 I18N .pm files (see RT for more detail).  At Adam's suggestion  
I was supposed to commit it to a branch, but I mistakenly committed  
it to the CVS trunk.  Not a glorious beginning for me...  Well, at  
least the changes were all well tested.  Question: should I leave it,  
or back it out and re-commit on the branch I already created?

I also am making a trivial change to extend the PPI::Element overload  
to include '!=' and 'ne' in addition to '==' and 'eq'.  This one I  
will deliberately post to the trunk (since it's easy and obvious) as  
soon as I get an answer for the above question.

Chris

--
Chris Dolan, Software Developer, www.chrisdolan.net
Public key: http://www.chrisdolan.net/public.key

Re: [Parseperl-discuss] determining object types w/o executing???

[Mark E. T. <ma...@zz...>]

Which is partly why I just made Variable::Strongly::Typed.  With a touch 
more overhead ya can turn some of your variables into pre-known types.
Of course if you roll your own type via a sub. then all bets are off.
	Mark

SYNOPSIS

     use Variable::Strongly::Typed;

     my $int             :TYPE('int');       # must have an 'int' value
     my $float           :TYPE('float');     # must have a 'float' value
     my $string          :TYPE('string');    # must not be a reference
     my $file            :TYPE('IO::File');  # must be an IO::File
     my @array_of_ints   :TYPE('int');       # Each slot must contain an int
     my %hash_of_floats  :TYPE('float');     # Each value must be a float

     my @array_of_rgb :TYPE(\&red_green_blue); # my enumerated type

     # ... and later ...

     $int = 23;          # All is well
     $int = 'howdy!';    # This line will croak with a good error message

     $float = 3.23;              # All is well, nothing to see here
     $float = new XML::Parser;   # croak!

     $array_of_ints[23] = 44;    # Groovy
     $array_of_ints[12] = 'yah'; # croak!

     $hash_of_floats{pi} = 3.14159;      # no problem
     $hash_of_floats{e}  = new IO::File; # croak!

     # Return 1 if this val is RED, BLUE, or GREEN
     #   0 otherwise
     sub red_green_blue {
         local $_ = shift;

         /\A RED \z/xms || /\A BLUE \z/xms || /\A GREEN \z/xms;
     }

     $array_of_my_very_own_types[23] = 99;       # croak!
     $array_of_my_very_own_types[2] = 'BLUE';    # OK!



Adam Kennedy wrote:
> 
> 
> Mark Ethan Trostler wrote:
> 
>> Howdy All,
>>     A very strange conglomeration events has led me here....
>> I'm very interested in attempting to determine what the type of an 
>> object would be at runtime - without actually having to run the 
>> program - say to determine available methods from a debugger (as 
>> mentioned in the recent article on perl.com).
> 
> 
> Because Perl is loosely types, you can't really do this. A variable 
> could contain just about anything.
> 
>>     Clearly the code must be run to the point where the object is in 
>> the code to then 'ref' it to find out it's type - then something like 
>> PPI can be used to walk up the inheiritance tree collecting possible 
>> subroutines.
> 
> 
> If you already have the the code loaded, then something like 
> Class::Inspector does a pretty good job of working out the available 
> methods by walking the ISA tree.
> 
>>     Actually executing the program/script everytime just to determine 
>> the type of the object is a bummer - as who knows what the 
>> side-effects are of running & re-running the code over & over.
> 
> 
> Right. It's generally considered dangerous.
> 
>>     Have you guys thought about how to tackle this?  It does seem the 
>> code has to be re-run everytime you would want to know the type of an 
>> object.
>>     I have a bizarro solution involving attributed-'my' variables to 
>> determine object types (replete w/code instrumentation via PPI) BUT 
>> re-running the code everytime sucks.
>>     Other then detecting whether the code has been modified before 
>> having to re-run it again have you guys come up with something to 
>> determine varaible types?
>>     It can't be possible... right???
> 
> 
> Technically no, it's impossible. But then PPI is about dealing with the 
> impossible :)
> 
> To repeat something you're going to be repeating quite a bit when people 
> ask "can I" questions, if YOU (as a person) can look at a piece of code 
> in a document and know what it is, then you should be able to write code 
> with PPI to work it out programmatically.
> 
> But take something like
> 
> package Foo;
> 
> sub foo {
>     my $self = shift;
>     my $param = shift;
>     ...
> }
> 
> Can you tell me what those are? You can probably guess that $self is 
> going to be an object of type 'Foo' (or a subclass). But what is $param? 
> You can't tell.
> 
> There's a range of situations in which you can guess reasonably well, 
> for example...
> 
> my $foo = My::Class->new;
> 
> But in general, Perl vars are untyped, so no you can't tell.
> 
> Adam K
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Parseperl-discuss mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/parseperl-discuss
> 

Re: [Parseperl-discuss] determining object types w/o executing???

[Adam K. <ad...@ph...>]

Mark Ethan Trostler wrote:
> Howdy All,
>     A very strange conglomeration events has led me here....
> I'm very interested in attempting to determine what the type of an 
> object would be at runtime - without actually having to run the program 
> - say to determine available methods from a debugger (as mentioned in 
> the recent article on perl.com).

Because Perl is loosely types, you can't really do this. A variable 
could contain just about anything.

>     Clearly the code must be run to the point where the object is in the 
> code to then 'ref' it to find out it's type - then something like PPI 
> can be used to walk up the inheiritance tree collecting possible 
> subroutines.

If you already have the the code loaded, then something like 
Class::Inspector does a pretty good job of working out the available 
methods by walking the ISA tree.

>     Actually executing the program/script everytime just to determine 
> the type of the object is a bummer - as who knows what the side-effects 
> are of running & re-running the code over & over.

Right. It's generally considered dangerous.

>     Have you guys thought about how to tackle this?  It does seem the 
> code has to be re-run everytime you would want to know the type of an 
> object.
>     I have a bizarro solution involving attributed-'my' variables to 
> determine object types (replete w/code instrumentation via PPI) BUT 
> re-running the code everytime sucks.
>     Other then detecting whether the code has been modified before 
> having to re-run it again have you guys come up with something to 
> determine varaible types?
>     It can't be possible... right???

Technically no, it's impossible. But then PPI is about dealing with the 
impossible :)

To repeat something you're going to be repeating quite a bit when people 
ask "can I" questions, if YOU (as a person) can look at a piece of code 
in a document and know what it is, then you should be able to write code 
with PPI to work it out programmatically.

But take something like

package Foo;

sub foo {
	my $self = shift;
	my $param = shift;
	...
}

Can you tell me what those are? You can probably guess that $self is 
going to be an object of type 'Foo' (or a subclass). But what is $param? 
You can't tell.

There's a range of situations in which you can guess reasonably well, 
for example...

my $foo = My::Class->new;

But in general, Perl vars are untyped, so no you can't tell.

Adam K

[Parseperl-discuss] determining object types w/o executing???

[Mark E. T. <ma...@zz...>]

Howdy All,
	A very strange conglomeration events has led me here....
I'm very interested in attempting to determine what the type of an 
object would be at runtime - without actually having to run the program 
- say to determine available methods from a debugger (as mentioned in 
the recent article on perl.com).
	Clearly the code must be run to the point where the object is in the 
code to then 'ref' it to find out it's type - then something like PPI 
can be used to walk up the inheiritance tree collecting possible 
subroutines.
	Actually executing the program/script everytime just to determine the 
type of the object is a bummer - as who knows what the side-effects are 
of running & re-running the code over & over.
	Have you guys thought about how to tackle this?  It does seem the code 
has to be re-run everytime you would want to know the type of an object.
	I have a bizarro solution involving attributed-'my' variables to 
determine object types (replete w/code instrumentation via PPI) BUT 
re-running the code everytime sucks.
	Other then detecting whether the code has been modified before having 
to re-run it again have you guys come up with something to determine 
varaible types?
	It can't be possible... right???
		thanks!
			Mark

Re: [Parseperl-discuss] [Fwd: Fwd: Eclipse Languages Symposium]

[Adam K. <ad...@ph...>]

err... that would be Ottawa

Adam Kennedy wrote:
> 
> Hi folks
> 
> Allison Randal has gotten a request for someone Perl-related and 
> interested in Eclipse to go speak more or less on this group's behalf in 
> Orrawa in October, is there anyone interested and available?
> 
> Would this be something of a conflict of interest for you Eric? :)
> 
> Adam K
> 
> --------------------------------------------
> 
> Do you know anyone who might be interested in attending this? It'd be
> good to have someone there.
> 
> Allison
> 
> Begin forwarded message:
> 
>> From: "Mike Milinkovich" <mik...@ec...>
>> Date: August 26, 2005 18:49:31 BDT
>> To: "'Allison Randal'" <al...@or...>
>> Cc: "'Bjorn Freeman-Benson'" <bjo...@ec...>
>> Subject: Eclipse Languages Symposium
>> Reply-To: <mik...@ec...>
>>
>>
>>
>> Allison,
>>
>> During the week of 24-28th of October in Ottawa we are planning to  
>> have a
>> one or two day technical meeting on how to implement more language
>> environments on top of Eclipse. We've already invited David Ascher  from
>> Python and hope to have someone from PHP as well.
>>
>> If you or someone else from Perl would be interested in attending,  we 
>> would
>> be very happy to have your input.
>>
>> Bjorn Freeman-Benson will be organizing this event. Please let us  
>> know if
>> there is any interest.
>>
>> Thanks.
>>
>> Mike Milinkovich
>> Executive Director,
>> Eclipse Foundation, Inc.
>> Office: 613-224-9461 x228
>> Cell: 613-220-3223
>> mik...@ec...
>>
>> blog: http://milinkovich.blogspot.com/
>>
>>
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Parseperl-discuss mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/parseperl-discuss

[Parseperl-discuss] [Fwd: Fwd: Eclipse Languages Symposium]

[Adam K. <ad...@ph...>]

Hi folks

Allison Randal has gotten a request for someone Perl-related and 
interested in Eclipse to go speak more or less on this group's behalf in 
Orrawa in October, is there anyone interested and available?

Would this be something of a conflict of interest for you Eric? :)

Adam K

--------------------------------------------

Do you know anyone who might be interested in attending this? It'd be
good to have someone there.

Allison

Begin forwarded message:

> From: "Mike Milinkovich" <mik...@ec...>
> Date: August 26, 2005 18:49:31 BDT
> To: "'Allison Randal'" <al...@or...>
> Cc: "'Bjorn Freeman-Benson'" <bjo...@ec...>
> Subject: Eclipse Languages Symposium
> Reply-To: <mik...@ec...>
>
>
>
> Allison,
>
> During the week of 24-28th of October in Ottawa we are planning to  
> have a
> one or two day technical meeting on how to implement more language
> environments on top of Eclipse. We've already invited David Ascher  
> from
> Python and hope to have someone from PHP as well.
>
> If you or someone else from Perl would be interested in attending,  
> we would
> be very happy to have your input.
>
> Bjorn Freeman-Benson will be organizing this event. Please let us  
> know if
> there is any interest.
>
> Thanks.
>
> Mike Milinkovich
> Executive Director,
> Eclipse Foundation, Inc.
> Office: 613-224-9461 x228
> Cell: 613-220-3223
> mik...@ec...
>
> blog: http://milinkovich.blogspot.com/
>
>

[Parseperl-discuss] [Introduction] About myself

[Jeffrey G. <dr...@po...>]

As near as I can remember I've been writing Perl since...'96 or so. 
Since then I've written a few articles for O'Reilly and managed the 
first few Parrot releases after Simon passed on the torch. More to the 
point, I've been fiddling with a pure-Perl vim-style editor for some 
months in Curses and POE.

Once I've gotten a visual mode done (or have given up and hacked 
vim+perlinterp sufficently) I'd like to see (for instance, I've got 
other ideas) a ':Makesub' macro come out of this, that takes a block of 
code, picks out the free variables and creates a 'sub foo { my 
($free_1,$free_2) = @_; my @internal_array = @$free_2; 
code_block_here() }' text block in a separate buffer that they can 
paste into another file and replace the original code block with a call 
to the procedure.

Of course, other transforms and, more importantly, the ability to 
perform dataflow tracing on code to determine whether a given variable 
is free or bound have to precede this. I've tried writing some simpler 
transforms, but these were with early versions of PPI, and if I 
remember, walking the internal data structures (which was required, as 
there weren't splicing operations that worked) was fraught with some 
peril.

In any case, with the new release I'll go back and revisit the old 
code, and hopefully make things work.
--
Jeff <dr...@po...>

[Parseperl-discuss] Re: [ANNOUNCE] Parse::Perl Planning Meeting: Saturday, August 27, 2005 at 07:00:00 UTC

[Paul B. <ma...@po...>]

On 20 Aug 2005, at 5:46 AM, Adam Kennedy wrote:

> Time:
> Saturday, August 27, 2005 at 07:00:00 UTC

I will, unfortunately, be camping.  And at that hour, semi-local  
wireless isn't an option.

Paul.

[Parseperl-discuss] [ANNOUNCE] Parse::Perl Planning Meeting: Saturday, August 27, 2005 at 07:00:00 UTC

[Adam K. <ad...@ph...>]

Greetings folks

I'd like to invite any and all Perl folks with an interest in PPI, 
Perl::BestPractice, the Perl::Editor API, currently working on a Perl 
editor project, or any other related topics, to the first official 
Parse::Perl project planning meeting.

Location:
irc://irc.perl.org/parseperl

Time:
Saturday, August 27, 2005 at 07:00:00 UTC

Given that that we've got people spread across US, Euro and AU, and with 
the help of dcnad, I've tried to pick a time that should be at least 
equally offensive for everybody.

Basically, late friday night US, earlyish Saturday EU, and Saturday 
afternoon in AU

For details on your time zone see

http://www.timeanddate.com/worldclock/fixedtime.html?year=2005&month=8&day=27&hour=7&min=0&sec=0

Agenda:
Since it's going to be pretty late US and early Saturday in the middle 
of the family-activities-month in Euro, we'll be running the meeting to 
a tight time table, and for no longer than an hour.

UTC-0700 Call to order, introductions all round
UTC-0710 Project Update and Questions (Adam K)
UTC-0720 Infrastructure Modules Planning and Discussion
          (document caches, metrics database etc)
UTC-0730 Editor Comparison and blue sky thoughts
UTC-0740 Perl::Editor feature discussion (given discussions on point 4.)
UTC-0750 PPI 1.100 Feature Requests, Perl::BestPractice discussion
UTC-0800 Meeting close - General discussion, hacking, and brainstorming

Coordination:
For coordination purposes, all events will be made within 1 minute of 
actual synchronized time. You may wish to turn up a little early to be 
certain.

Please note although I won't be moderating the channel, please limit any 
questions to on topic questions and please shut up if I tell you.

I might move ahead early if we exhaust a topic, but I don't plan on 
falling behind. Any remaining discussion at the end of each period can 
wait for until general discussion after the meeting.

At least a few people (including me) will be around for a number of 
hours afterwards working on various things, so there's plenty of time.

Minutes:
I won't be keeping minutes, but I'd it if someone could log the meeting, 
plus a while into the general discussion period, for the benefit of 
those that can't attend, and I'll summarize in my use.perl.org journal 
afterwards.

That's it, I hope to see you all there. Please feel free to forward this 
email to people or other mailing lists you think may be interested.

Adam K

[Parseperl-discuss] New member

[nadim <na...@kh...>]

Hi, I thought I'd present myself quickly and why I joined.

I'm nadim, (NKH on CPAN), I work as sytem architect in a telecom company in 
Sweden. I'm frustrated because I can't program so I do perl to calm my 
nerves. Sometimes lots of it.

I wanted to take sometime from my build system project so I decided to revive 
the editor project. I've been writting editors for quite a long time. Some 
have used perl. I've never taken the time to seriously write an editor in 
perl only but I have a lots I can refactor.

After the debate on the extremeperl, which I follow but not participate in, I 
decide the time was right as there's quite a few people working on this area 
right now. Ebug, PPI, gtk-perl, ...

Kaare Rasmusen and I have started Text::Editor::Vip which  aims at writting a 
text editor in perl that should be platform independant and fun to use. The 
main goal is supporting perl but other languages too.

We hope this will be the component of choice for an IDE (Matisse's IDE). We 
made a release a few days ago and things are going fine here on my computer.

My previous editor had a rather complete perl parser that I used for coloring. 
It's written in flex and goes through some post processing to be integrated 
in a C++ app. We have the choice of using that or, maybe, PPI. The 
lexer/hilighter is not part of the editor but an external component so it 
should be easy to go from one to the other.

In any case, Vip might be a good test bed for PPI.

Cheers, Nadim.


 

Re: [Parseperl-discuss] PPIx::Analyze?

[Adam K. <ad...@ph...>]

Don't know if he is on it. Only a new list, so not many people here yet.

I'll be nudging more people on as I get to it.

Adam K

Johan Lindstrom wrote:
> At 15:45 2005-07-11, Adam Kennedy wrote:
>=20
>> It's dan brooks' (broquaint) thingy for indexing the packages and subs=
=20
>> and variables and so on in a Document.
>>
>> I'm not sure what the final form of it will be, but I saw a very early=
=20
>> experimental version and it looked good.
>=20
>=20
> Ok, I'm doing similar things here (surprise! ;), so is there a time=20
> table, or preview anywhere or something? Is Dan on the list perhaps?
>=20
> I guess the problem space is small enough that things will be duplicate=
d=20
> until they are more public, so I'm looking forward to using this mailin=
g=20
> list to air what's going on around the PPI project. I hope that's fine?
>=20
> What I'm doing is tings like, finding used modules, finding base=20
> modules, finding subs, finding pod, in the class or base class etc..=20
> It's very specific to what I need to solve actual problems for=20
> navigating the source (including interpreting the source at a slightly=20
> higher level with heuristics for what source code "usually looks like")=
,=20
> but some of it is obviously a part of what the Analyze module probably=20
> does too.
>=20
>=20
> /J
>=20
> -------- ------ ---- --- -- --  --  -     -     -        -          -
> Johan Lindstr=F6m    Sourcerer @ Boss Casinos   johanl AT DarSerMan.com
>=20
> Latest bookmark: "TCP Connection Passing"
> http://tcpcp.sourceforge.net/
> dmoz: /Computers/Programming/Languages/JavaScript/ 12
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar=20
> happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dua=
l
> core and dual graphics technology at this free one hour event hosted by=
=20
> HP, AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebina=
r
> _______________________________________________
> Parseperl-discuss mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/parseperl-discuss

Re: [Parseperl-discuss] PPIx::Analyze?

[Johan L. <jo...@Da...>]

At 15:45 2005-07-11, Adam Kennedy wrote:
>It's dan brooks' (broquaint) thingy for indexing the packages and subs and 
>variables and so on in a Document.
>
>I'm not sure what the final form of it will be, but I saw a very early 
>experimental version and it looked good.

Ok, I'm doing similar things here (surprise! ;), so is there a time table, 
or preview anywhere or something? Is Dan on the list perhaps?

I guess the problem space is small enough that things will be duplicated 
until they are more public, so I'm looking forward to using this mailing 
list to air what's going on around the PPI project. I hope that's fine?

What I'm doing is tings like, finding used modules, finding base modules, 
finding subs, finding pod, in the class or base class etc.. It's very 
specific to what I need to solve actual problems for navigating the source 
(including interpreting the source at a slightly higher level with 
heuristics for what source code "usually looks like"), but some of it is 
obviously a part of what the Analyze module probably does too.


/J

-------- ------ ---- --- -- --  --  -     -     -        -          -
Johan Lindström    Sourcerer @ Boss Casinos   johanl AT DarSerMan.com

Latest bookmark: "TCP Connection Passing"
http://tcpcp.sourceforge.net/
dmoz: /Computers/Programming/Languages/JavaScript/ 12

Re: [Parseperl-discuss] PPIx::Analyze?

[Adam K. <ad...@ph...>]

It's dan brooks' (broquaint) thingy for indexing the packages and subs=20
and variables and so on in a Document.

I'm not sure what the final form of it will be, but I saw a very early=20
experimental version and it looked good.

I imagine when the time comes to add some "official" interface for doing=20
the logical structure of Perl things inside of documents, it will be=20
based on it.

Adam K

Johan Lindstr=F6m wrote:
> At http://use.perl.org/~Alias/journal/25621, an upcoming PPIx::Analyze=20
> module is mentioned. Is there anyone who knows more about what this=20
> module is about, or should I just wait until it's on CPAN?
>=20
>=20
> /J
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar=20
> happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dua=
l
> core and dual graphics technology at this free one hour event hosted by=
=20
> HP, AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebina=
r
> _______________________________________________
> Parseperl-discuss mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/parseperl-discuss

[Parseperl-discuss] PPIx::Analyze?

[Johan L. <jo...@Da...>]

At http://use.perl.org/~Alias/journal/25621, an upcoming PPIx::Analyze 
module is mentioned. Is there anyone who knows more about what this module 
is about, or should I just wait until it's on CPAN?


/J

Re: [Parseperl-discuss] PPI + Storable = ?

[Adam K. <ad...@ph...>]

Did a bit of rewriting and added a few more tests, but 17_storable.t now=20
passes.

Storable now works for PPI 1.000 (version updated in CVS now).

Adam K

Johan Lindstrom wrote:
> At 10:23 2005-07-08, Adam Kennedy wrote:
>=20
>> Write me a quick 17_storable.t test script (just copy one of the other=
=20
>> smaller test scripts) and attach it to a rt.cpan.org bug report, and=20
>> I'll handle the implementation for you. I probably should refactor=20
>> that bit a little anyway so it uses the same code as ->clone.
>=20
>=20
> Done. I'm in a hurry now, so take a brief look at the naming convention=
,=20
> it's not perfect.
>=20
>=20
> /J
>=20
> -------- ------ ---- --- -- --  --  -     -     -        -          -
> Johan Lindstr=F6m    Sourcerer @ Boss Casinos   johanl AT DarSerMan.com
>=20
> Latest bookmark: "TCP Connection Passing"
> http://tcpcp.sourceforge.net/
> dmoz: /Computers/Programming/Languages/JavaScript/ 12

Re: [Parseperl-discuss] PPI + Storable = ?

[Johan L. <jo...@Da...>]

At 10:23 2005-07-08, Adam Kennedy wrote:
>Write me a quick 17_storable.t test script (just copy one of the other 
>smaller test scripts) and attach it to a rt.cpan.org bug report, and I'll 
>handle the implementation for you. I probably should refactor that bit a 
>little anyway so it uses the same code as ->clone.

Done. I'm in a hurry now, so take a brief look at the naming convention, 
it's not perfect.


/J

-------- ------ ---- --- -- --  --  -     -     -        -          -
Johan Lindström    Sourcerer @ Boss Casinos   johanl AT DarSerMan.com

Latest bookmark: "TCP Connection Passing"
http://tcpcp.sourceforge.net/
dmoz: /Computers/Programming/Languages/JavaScript/ 12

Re: [Parseperl-discuss] PPI + Storable = ?

[Adam K. <ad...@ph...>]

Johan Lindstrom wrote:
> At 10:23 2005-07-08, Adam Kennedy wrote:
> 
>> Write me a quick 17_storable.t test script (just copy one of the other 
>> smaller test scripts) and attach it to a rt.cpan.org bug report, and 
>> I'll handle the implementation for you. I probably should refactor 
>> that bit a little anyway so it uses the same code as ->clone.
> 
> 
> Will do. (But I'm not sure I'll get the time until perhaps Sunday if 
> that has any impact you your scheduled release.)

Depends which country you are in, but it's fairly safe to say Sunday is 
fine as long as it's fairly early in the day. Saturday would be better, 
if possible.

It's a fairly standalone feature, so it won't get in the way of any of 
the other work though.

Adam K

Re: [Parseperl-discuss] PPI + Storable = ?

[Johan L. <jo...@Da...>]

At 10:23 2005-07-08, Adam Kennedy wrote:
>Write me a quick 17_storable.t test script (just copy one of the other 
>smaller test scripts) and attach it to a rt.cpan.org bug report, and I'll 
>handle the implementation for you. I probably should refactor that bit a 
>little anyway so it uses the same code as ->clone.

Will do. (But I'm not sure I'll get the time until perhaps Sunday if that 
has any impact you your scheduled release.)


Thanks,

/J

-------- ------ ---- --- -- --  --  -     -     -        -          -
Johan Lindström    Sourcerer @ Boss Casinos   johanl AT DarSerMan.com

Latest bookmark: "TCP Connection Passing"
http://tcpcp.sourceforge.net/
dmoz: /Computers/Programming/Languages/JavaScript/ 12

Re: [Parseperl-discuss] PPI + Storable = ?

[Adam K. <ad...@ph...>]

Yes.

PPI uses a weakref-based tree system.

Although the objects themselves are built using a normal non-recursive=20
structure, they look UP the tree by using the %PPI::Element::PARENT=20
hash, which contains a weak reference to their parent Node keyed by the=20
Scalar::Util::refaddr of the child object.

There's an entry in PARENT for every single child Element object.

So far as I'm aware, this is pretty much the ideal way of implementing=20
trees structures in Perl. It's fast as hell (and faster once we get a XS=20
version in PPI::XS), is completely immune from circular reference leaks,=20
and it even cleans itself properly when PPI::Document objects are=20
destroyed. It also handily makes everything look like plain trees in the=20
debugger.

The DESTROY method for each element cleans up it's entry in PARENT,=20
keeping the hash from exploding in size.

However, whenever you manipulate PDOM tree you have to keep the PARENT=20
refs up to date. Most of the time this is done for you transparently.

Take a look at the implementation of PPI::Document::clone.

It does a fast Clone::clone, and then walk the PDOM tree relinking all=20
of the children to the parents in the cloned copy.

In order to make PPI::Documents natively Storable-friendly, we probably=20
need a Storable Hook method to do the same sort of relinking process=20
when we thaw out the document.

Write me a quick 17_storable.t test script (just copy one of the other=20
smaller test scripts) and attach it to a rt.cpan.org bug report, and=20
I'll handle the implementation for you. I probably should refactor that=20
bit a little anyway so it uses the same code as ->clone.

Adam K

Johan Lindstr=F6m wrote:
> I'm trying to cache parsed PPI::Document objects by serializing them=20
> with Storable, but I see strange things. The objects before/after look=20
> the same, but e.g. a $node->statement doesn't work with the thawed obje=
ct.
>=20
> Is there any known reason it wouldn't "just work" to freeze/thaw a=20
> PPI::Document with it's nodes etc?
>=20
>=20
> /J
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar=20
> happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dua=
l
> core and dual graphics technology at this free one hour event hosted by=
=20
> HP, AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebina=
r
> _______________________________________________
> Parseperl-discuss mailing list
> Par...@li...
> https://lists.sourceforge.net/lists/listinfo/parseperl-discuss

[Parseperl-discuss] PPI + Storable = ?

[Johan L. <jo...@Da...>]

I'm trying to cache parsed PPI::Document objects by serializing them with 
Storable, but I see strange things. The objects before/after look the same, 
but e.g. a $node->statement doesn't work with the thawed object.

Is there any known reason it wouldn't "just work" to freeze/thaw a 
PPI::Document with it's nodes etc?


/J

[Parseperl-discuss] The future of Perl::Editor

[Johan L. <jo...@Da...>]

Since it's the same crowd behind PPI and Perl::Editor, could someone (Adam 
:) please elaborate a little on what Perl::Editor is about, the scope, a 
hint about the coming interface etc?

I'm curious because I'm also hacking on some PPI/Perl/Editor related stuff:
http://use.perl.org/~jplindstrom/journal/25373
http://use.perl.org/~jplindstrom/journal/25436


/J
-------- ------ ---- --- -- --  --  -     -     -        -          -
Johan Lindström    Sourcerer @ Boss Casinos   johanl AT DarSerMan.com

Latest bookmark: "TCP Connection Passing"
http://tcpcp.sourceforge.net/
dmoz: /Computers/Programming/Languages/JavaScript/ 12