Mailing List Archive

> From: Raphael Manfredi <ram@hptnos02.grenoble.hp.com>
>
> Quoting Tony Sanders:
> :Have you seen anything like this come around?
> :I looked (CPAM, etc) but didn't find anything.
>
> Please fetch:
> ftp://franz.ww.tu-berlin.de/pub/authors/id/RAM/Storable-0.1.tar.gz
>
And check the module list:

FreezeThaw bdpf Convert arbitrary objects to/from strings ILYAZ
Persistent adpO Creates persistent hashrefs or arrayrefs JPC +
Storable adcr Persistent data structure mechanism RAM +
Marshal::
::Dispatch cdpO Convert arbitrary objects to/from strings MUIR +
::Packed cdpO Run-length coded version of Marshal module MUIR +
::Eval cdpO Undo serialization with eval MUIR +


> I hope this extension will become part of standard perl5.002, but so far
> I have only seen Tom being enthusiastic about it ;-)

I don't think extensions should become part of the standard distribution
until the interface and functionality has been widely discussed and
some concensus reached.

Storable is actually doing two things that (I believe) should be split
into two modules. The good work of Ilya Zakharevich, David Muir Sharnoff
and Jan-Pieter Cornet needs to be considered.

Tim.

On Fri, 13 Oct 1995 13:43:45 BST, Raphael Manfredi wrote:
>Quoting Tony Sanders:
>:Have you seen anything like this come around?
>:I looked (CPAM, etc) but didn't find anything.
>
>Please fetch:
>
> ftp://franz.ww.tu-berlin.de/pub/authors/id/RAM/Storable-0.1.tar.gz
>
[...]
>
>I hope this extension will become part of standard perl5.002, but so far
>I have only seen Tom being enthusiastic about it ;-)
>
>Raphael
>

If you're counting the fans, I'm very happy with the Storable package
also. I had done some work along the same lines (mostly for persistence of
Tk interfaces), but I think Storable needs to support more base types in
order to be generic enough.

Let me know if you have stopped working on Storable. I can easily adopt/
maintain it and add the (rather disorganized stuff) I now have into it.


- Sarathy.
gsar@engin.umich.edu

Quoting Tony Sanders:
:Have you seen anything like this come around?
:I looked (CPAM, etc) but didn't find anything.

Please fetch:

ftp://franz.ww.tu-berlin.de/pub/authors/id/RAM/Storable-0.1.tar.gz

It enables you to store whole hierarchies of objects, and then retrieve
it at a later time.

It's really fast because it cheats: it's written in C and it does not
always use the standard perl5 interfaces to create objects when that
would have noticeable performance impact.

You use it as:

use Storable;

store(\@objects, "file"); # Stores the array recursively!
...
$aryref = retrieve("file"); # Retrieves the whole hierarchy

I hope this extension will become part of standard perl5.002, but so far
I have only seen Tom being enthusiastic about it ;-)

Raphael

Raphael Manfredi writes:
>
> I hope this extension will become part of standard perl5.002, but so far
> I have only seen Tom being enthusiastic about it ;-)
>

I will be enthusiastic too if it:

a) Is not persistent, just gives string representation of an
object, that _may_ be pulled and pushed to/from file;
b) Works with circular dependencies;
c) is easy extendable to classes;
d) is easily extendable to classes with circular dependencies;
e) Will die on objects created with xsubpp typemaps (if
needed).

My implementation FreezeThaw does not touch e) and slightly goofes on
d).

Ilya

> From: Ilya Zakharevich <ilya@math.ohio-state.edu>
>
> Raphael Manfredi writes:
> >
> > I hope this extension will become part of standard perl5.002, but so far
> > I have only seen Tom being enthusiastic about it ;-)
>
> I will be enthusiastic too if it:
>
> a) Is not persistent, just gives string representation of an
> object, that _may_ be pulled and pushed to/from file;
> b) Works with circular dependencies;
> c) is easy extendable to classes;
> d) is easily extendable to classes with circular dependencies;
> e) Will die on objects created with xsubpp typemaps (if
> needed).

I agree. Certainly a) and b) are vital.

I'd also add that the string representation should be self delimiting.
In other words it should be possible to read an object from a stream
without reading beyond the end of the object data:

$obj1 = read-obj-from-socket(SOCK);
$obj2 = read-obj-from-socket(SOCK);
$other = read-other-data-from-socket(SOCK);

Storable, like the other presistence related modules, needs more work.
Raphael, have you studied Ilya's work? Was there a specific reason
why you didn't just convert FreezeThaw to XS code?

Come on guys, work together on this. Agree on the required functionality
and then agree on an interface. If you want to have competing
implementations that's fine but let's get the requirements and interface
sorted first.

Tim.

> From: Raphael Manfredi <ram@hptnos02.grenoble.hp.com>
>
> Quoting Tim Bunce:
> :
> :I don't think extensions should become part of the standard distribution
> :until the interface and functionality has been widely discussed and
> :some concensus reached.
>
> That reminds me of some class, yes!, FileHandle is the name I think... ;-)

:-)

> :Storable is actually doing two things that (I believe) should be split
> :into two modules. The good work of Ilya Zakharevich, David Muir Sharnoff
> :and Jan-Pieter Cornet needs to be considered.
>
> Good work should always be considered. I'm considering FreezeThaw
> integration within Storable so that it can benefit from the fast C engine.

That would be great.

> I don't know about the other extensions but I'll surely look at them
> when I have some time.
>
> The main problem with a Perl solution to the persistency problem is speed.
> I was only able to get decent performance with C here, sorry! But since
> I'm dealing with data of about 500K, speed is of the utmost importance.
> (My Perl solution took 20 secs for 250K, and Storable takes less than 1 sec).

I have absolutely no problem with you implementing a solution in C (XS).
I'd expect Perl marshaling/persistance to end up in C at some point.

I care very little about implementations since they can easily be changed.
I do care a lot about interfaces since they are *much* harder to change.

I have a problem with people, in general, who work hard in isolation
to create something which others have already addressed. It's sad.

I really don't understand why people can't stop at the design or prototype
stage and post a message saying "any comments on this?".

[.ooops, I seem to have climbed onto a soap box. Sorry. I'll get down.]

Actually, having said "I care very little about implementations since they
can easily be changed." I'll make the point that once an implementation has
moved from Perl to C the author will be much more reluctant to make any given
change. Another good reason to discuss the interface and functionality early.

Software reuse is difficult. Getting interfaces right early is crucial.

[I'm right down now :-]

> However, you're raising an important point here Tim. It's about
> standardization. Given the abundance of modules available from CPAN
> today, it's inevitable that fewer and fewer ones will be picked for
> standard distribution. And that the criteria for the aforementionned
> inclusion will become stricter and stricter...
>
> ...which means modules will have to get all the more broader.

I don't quite follow you here Raphael.

Tim.

Quoting Tim Bunce:
:And check the module list:
:
:FreezeThaw bdpf Convert arbitrary objects to/from strings ILYAZ
:Persistent adpO Creates persistent hashrefs or arrayrefs JPC +
:Storable adcr Persistent data structure mechanism RAM +
:Marshal::
:::Dispatch cdpO Convert arbitrary objects to/from strings MUIR +
:::Packed cdpO Run-length coded version of Marshal module MUIR +
:::Eval cdpO Undo serialization with eval MUIR +
:
:I don't think extensions should become part of the standard distribution
:until the interface and functionality has been widely discussed and
:some concensus reached.

That reminds me of some class, yes!, FileHandle is the name I think... ;-)

:Storable is actually doing two things that (I believe) should be split
:into two modules. The good work of Ilya Zakharevich, David Muir Sharnoff
:and Jan-Pieter Cornet needs to be considered.

Good work should always be considered. I'm considering FreezeThaw
integration within Storable so that it can benefit from the fast C engine.
I don't know about the other extensions but I'll surely look at them
when I have some time.

The main problem with a Perl solution to the persistency problem is speed.
I was only able to get decent performance with C here, sorry! But since
I'm dealing with data of about 500K, speed is of the utmost importance.
(My Perl solution took 20 secs for 250K, and Storable takes less than 1 sec).

However, you're raising an important point here Tim. It's about
standardization. Given the abundance of modules available from CPAN
today, it's inevitable that fewer and fewer ones will be picked for
standard distribution. And that the criteria for the aforementionned
inclusion will become stricter and stricter...

...which means modules will have to get all the more broader.

Raphael

Tim Bunce writes:
> Storable, like the other presistence related modules, needs more work.
> Raphael, have you studied Ilya's work? Was there a specific reason
> why you didn't just convert FreezeThaw to XS code?
>
> Come on guys, work together on this. Agree on the required functionality
> and then agree on an interface. If you want to have competing
> implementations that's fine but let's get the requirements and interface
> sorted first.
>
> Tim.
>

Well, the only reason why I actually _coded_ FreezeThaw is to check
that the interface was doable. (And it was not. ;-) Current
implementation is still buggy, but I think that it may be fixed to
conform to the (newer) interface.

Ilya

> From: Ilya Zakharevich <ilya@math.ohio-state.edu>
>
> Tim Bunce writes:
> > Storable, like the other presistence related modules, needs more work.
> > Raphael, have you studied Ilya's work? Was there a specific reason
> > why you didn't just convert FreezeThaw to XS code?
> >
> > Come on guys, work together on this. Agree on the required functionality
> > and then agree on an interface. If you want to have competing
> > implementations that's fine but let's get the requirements and interface
> > sorted first.
>
> Well, the only reason why I actually _coded_ FreezeThaw is to check
> that the interface was doable. (And it was not. ;-) Current
> implementation is still buggy, but I think that it may be fixed to
> conform to the (newer) interface.

Is that a 'newer' interface that has the best of FreezeThaw & Storable etc?

Raphael mentioned that he was integrating with FreezeThaw. I guess
(and hope) you're coordinating with each other. I look forward with
interest to a new module that you're both happy with.

Tim.

On Tue, 17 Oct 1995 13:15:25 BST, Tim Bunce wrote:
>
>I care very little about implementations since they can easily be changed.
>I do care a lot about interfaces since they are *much* harder to change.
>
>I have a problem with people, in general, who work hard in isolation
>to create something which others have already addressed. It's sad.
>

I think I am guilty of said charges :-), since I have a Persist/TkPersist
module that was developed as part of another project several months ago
(when I was still new to perl-porters). I mentioned it on a few occasions,
but with characteristic laziness, didn't followup. I haven't revisited this
in quite some time, but I did talk to Raphael about sending it over to him
for possible incorporation into Storable (well, one of these days).

>I really don't understand why people can't stop at the design or prototype
>stage and post a message saying "any comments on this?".

My problem is the ever-dwindling "play-time". I usually don't wan't to
invite discussion unless I am able to follow up with well-considered replies
(something I unfortunately cannot do, given the rate at which my mail volume
and work-load have been increasing, lately).

Hmm, maybe we should divvy-up p5p into a zillion little mailing lists. I
hate to suggest this, though (if you can only see my faltering typing).

>
>[.ooops, I seem to have climbed onto a soap box. Sorry. I'll get down.]
>
>Actually, having said "I care very little about implementations since they
>can easily be changed." I'll make the point that once an implementation has
>moved from Perl to C the author will be much more reluctant to make any given
>change. Another good reason to discuss the interface and functionality early.
>
>Software reuse is difficult. Getting interfaces right early is crucial.
>

Very true.

>
>Tim.
>

- Sarathy.
gsar@engin.umich.edu

Tim Bunce writes:
> I really don't understand why people can't stop at the design or prototype
> stage and post a message saying "any comments on this?".
>

I had exactly the same feeling in spring, wrote .pod and posted it to
p5-p. No followup.

Now I've changed a lot :-(.

Ilya

tim> Storable is actually doing two things that (I believe) should be split
tim> into two modules. The good work of Ilya Zakharevich, David Muir Sharnoff
tim> and Jan-Pieter Cornet needs to be considered.

gsar> If you're counting the fans, I'm very happy with the Storable package
gsar> also. I had done some work along the same lines (mostly for persistence of
gsar> Tk interfaces), but I think Storable needs to support more base types in
gsar> order to be generic enough.

gsar> Let me know if you have stopped working on Storable. I can easily adopt/
gsar> maintain it and add the (rather disorganized stuff) I now have into it.

Hm... where are we on this?

Is there a good answer for people wanting to save complex stuff
to disk?

--tom

On Thu, 26 Oct 1995 07:27:53 MDT, Tom Christiansen wrote:
>tim> Storable is actually doing two things that (I believe) should be split
>tim> into two modules. The good work of Ilya Zakharevich, David Muir Sharnoff
>tim> and Jan-Pieter Cornet needs to be considered.
>
>gsar> If you're counting the fans, I'm very happy with the Storable package
>gsar> also. I had done some work along the same lines (mostly for persistence of
>gsar> Tk interfaces), but I think Storable needs to support more base types in
>gsar> order to be generic enough.
>
>gsar> Let me know if you have stopped working on Storable. I can easily adopt/
>gsar> maintain it and add the (rather disorganized stuff) I now have into it.
>
>Hm... where are we on this?
>
>Is there a good answer for people wanting to save complex stuff
>to disk?
>

I haven't tested Storable extensively, but I think it should work for
people who only need to store basic types. The stuff I worked on (about
4 months ago) attempted to be more generic and provided some support for
storing Tk state as well. Tk has evolved much since then, and this will
take some reworking also. One sticky issue is storing content of subs
inside eval's. (esp. since Tk uses a lot of callbacks, which used to be
declared inside evals).

Assuming I clear the mountain of work debris that just fell on me this week
on time, I should have something to say about this in three weeks.

- Sarathy.
gsar@engin.umich.edu

Gurusamy Sarathy writes:
>
> I haven't tested Storable extensively, but I think it should work for
> people who only need to store basic types. The stuff I worked on (about
> 4 months ago) attempted to be more generic and provided some support for
> storing Tk state as well. Tk has evolved much since then, and this will
> take some reworking also. One sticky issue is storing content of subs
> inside eval's. (esp. since Tk uses a lot of callbacks, which used to be
> declared inside evals).
>

The best thing I could think out of me was to have
$SIG{__EVALSUB__} = \&store_string;
that will give store_string the evaled string and (possibly) offset of
the start of the sub. On the other hand, if store_string is XSUB, it
may hook into parser and try to get the info out of it directly. The
string ref should be saved in some field of the subroutine, so that it
may be destroyed when (not) needed.
On the other hand, it may go into the core as well, given
current compile_tree/source ratio 8/1.

Ilya

On Thu, 26 Oct 1995 15:50:30 EDT, Ilya Zakharevich wrote:
>Gurusamy Sarathy writes:
>> One sticky issue is storing content of subs
>> inside eval's. (esp. since Tk uses a lot of callbacks, which used to be
>> declared inside evals).
>
>The best thing I could think out of me was to have
> $SIG{__EVALSUB__} = \&store_string;
>that will give store_string the evaled string and (possibly) offset of
>the start of the sub. On the other hand, if store_string is XSUB, it
>may hook into parser and try to get the info out of it directly. The
>string ref should be saved in some field of the subroutine, so that it
>may be destroyed when (not) needed.
> On the other hand, it may go into the core as well, given
>current compile_tree/source ratio 8/1.
>

I would prefer that the body of the sub is maintained in the CV itself
based on a -DS flag that can also be set via $^D inside perl code.
This allows caching subs only where required.

- Sarathy.
gsar@engin.umich.edu

>I would prefer that the body of the sub is maintained in the CV itself
>based on a -DS flag that can also be set via $^D inside perl code.

Hm... the tchrist grammar bot finds itself highly confused by that
sequence of tenses, but I think I know what you meant. The combo of a
subordinate clause with a governing "prefer" and a conditional tense in
the first clause all really demand that a subjunctive be used in the
second:

<conditional> => <past subjunctive>
I would prefer that the body were maintained...
I would prefer if the body were maintained...
IF <past subjunctive> => <conditional>
If the body were maintained, I would prefer it.

or <present indicative> => <present subjunctive>
I prefer that the body be maintained...
or
I prefer that the body should be maintained...

Or so that you don't need to know Latin grammar just to
write proper English, merely elide the whole subordinate clause:

I'd prefer the body maintained...

--tom "i am just a bot" christiansen

On Thu, 26 Oct 1995 15:07:20 MDT, Tom "the bot" Christiansen wrote:
>>I would prefer that the body of the sub is maintained in the CV itself
>>based on a -DS flag that can also be set via $^D inside perl code.
>
>Hm... the tchrist grammar bot finds itself highly confused by that
>sequence of tenses, but I think I know what you meant. The combo of a
>subordinate clause with a governing "prefer" and a conditional tense in
>the first clause all really demand that a subjunctive be used in the
>second:
>
><conditional> => <past subjunctive>
> I would prefer that the body were maintained...

I would prefer that it had been written as above :-)

> I would prefer if the body were maintained...
>IF <past subjunctive> => <conditional>
> If the body were maintained, I would prefer it.
>
>or <present indicative> => <present subjunctive>
> I prefer that the body be maintained...
>or
> I prefer that the body should be maintained...
>
>Or so that you don't need to know Latin grammar just to
>write proper English, merely elide the whole subordinate clause:
>
> I'd prefer the body maintained...
>
>--tom "i am just a bot" christiansen
>

I knew it was only a matter of time before I incurred the wrath of the bot,
when I started flaunting my compound constructs with mixed tenses under its
very nose.

Then again, (as is well known among the natives of the Indian subcontinent)
it is impossible to think straight in "correct" English all the time. :-)
But please don't say that to my english teacher-bot of old.

- Sarathy.
gsar@engin.umich.edu

Maybe somebody should unsubscribe the tom-bot from the list. People keep
mistaking it for Tom.

What this has to do with "persistent perl5 objects" is beyond me, unless
the tom-bot happens to be one. Hmm...

Larry

In <199510262034.QAA10469@aatma.engin.umich.edu>
On Thu, 26 Oct 1995 16:34:40 -0400
Gurusamy Sarathy <gsar@engin.umich.edu> writes:
>On Thu, 26 Oct 1995 15:50:30 EDT, Ilya Zakharevich wrote:
>>Gurusamy Sarathy writes:
>>> One sticky issue is storing content of subs
>>> inside eval's. (esp. since Tk uses a lot of callbacks, which used to be
^^^^^^^^^^
>>> declared inside evals).

But are now done saving closures in globs...

my $xxx = ...
*subname = sub { ... $xxx ...};

In <5914.814800458@mox>
On Fri, 27 Oct 95 07:27:38 MDT
Tom Christiansen <tchrist@mox.perl.com> writes:
>>But are now done saving closures in globs...
>
>>my $xxx = ...
>>*subname = sub { ... $xxx ...};
>
>um, why do you do that?
>

The 'methods' in quesion are 'aliases' to messy Tcl API.

e.g. rather than having to write :

$widget->winfo('width');

I want to write:

$widget->width;

I used to do:

my $meth
foreach $meth (qw(width heigth ...))
{
eval "sub $meth { shift->winfo($meth, \@_) }";
}

Now I do :

my $meth
foreach $meth (qw(width heigth ...))
{
*{$meth} = sub { shift->winfo($meth, @_) };
}

Which was originaly to avoid the eval "" leak, but should
also be faster.