Input / Output encoding filters.

[Steve Gunnell]

Hi People,

Back in December I asked a question about utf8 I/O. Leo responded
pointing me at the encoding filters. I then published a possible
implementation of PIO_utf8_read with a request for comments.

Since that time I have been thinking about the testing and
implementation of I/O filters. Actually I started thinking about how to
create a suitable test set for the fragment I had written which fed back
various shortcomings of the implementation and led to wider thinking of
the entire process. I am primarily thinking about file I/O but I can see
no reason why this scheme cannot apply to any other form of I/O.

1) The immediate result returned by the lowest level of a read operation
is an undifferentiated type which I am going to call "bytestream". This
type makes no assumptions about the internal encoding of its contents.

2) Trans-encoding from a bytestream string to a named charset and
encoding involves:
2.a) confirming that the bytestream converts to an integral number of
characters in the target encoding. The trans-encoding function should
return any trailing character fragments as a bytestream string. 
2.b) labelling the (possibly) truncated string with the target charset
and encoding.

3) I feel that it would be preferable if the read opcode specified N
characters to be read rather than N bytes. However to implement this the
PIO_*_read call would have to pass down the maximum byte size of a
character as well as the character count to the fundamental operation.
If N stays as bytes then the implementation will return a trans-encoding
dependent integral number of characters derived from no more than N
bytes of source data. It may also be desirable to limit the returned
string to also retuning no more than N bytes.

4) PIO_*_peek needs to include a parameter to specify the maximum byte
length of one character in the target charset / encoding so that the
fundamental operation can guarantee returning enough bytes to return a
character after trans-encoding.

5) Seeking through an encoding filter could be highly problematic.
Filters such as "utf8" that have a non-deterministic byte per character
ratio should politely refuse seeks.

6) Use of escape codes also adds a non-deterministic level to character
counts. The generation and normalisation of escape codes during
trans-encoding is very DWIM but the documents need to explicitly set a
policy on this behaviour. In general the use of HTML style entity codes
is preferable to using C style \nnn code as they can be normalised to
any encoding that supports them rather than requiring the programmer to
have to guess the original encoding.

7) The line buffered read function should be removed from the
fundamental operations and made into a filter layer similar to the "buf"
layer. There is no guarantee that the underlying data source is going to
conform to the line end notions of the current system and this should be
able to be compensated for.

8) There would be advantages to having a PIO_*_get_encoding function in
the I/O interface to allow enquiries about the returned encoding from
lower levels.

Okay some examples ...

$P0 = open "foo"
push $P0, 'ascii'
push $P0, 'by_line'
This would be a standard line oriented read/write.

$P0 = open "foo"
push $P0, 'utf16'
push $P0, 'by_line'
push $P0, 'utf8'
This could be used to read a Windows unicode file while all internal
processing is done using utf8 encodings. 'by_line' would need
initialisation with a non default line end marker.

$P0 = open "foo"
push $P0, 'ebcdic'
push $P0, 'ascii'
For mainframes.

$P0 = open "foo"
push $P0, 'encrypt_blowfish'
push $P0, 'adaptive_huffman'
push $P0, 'escaped_ascii'
push $P0, 'utf8'
You can figure it out  


Cheers,

Steve Gunnell

Re: Q: interpreter->stash and namespaces

[Chip Salzenberg]

On Thu, Jan 26, 2006 at 02:12:41AM +0100, Leopold Toetsch wrote:
> On Jan 25, 2006, at 21:21, Chip Salzenberg wrote:
> >On Tue, Jan 24, 2006 at 05:43:25PM +0100, Leopold Toetsch wrote:
> >>*) what is vtable->package? A pointer to the namespace PMC of this
> >>class? (It's currently unused)
> >
> >Beats me.  Vtables don't have namespaces.
> 
> Given that in P6 speak ...
> 
> 00:27 < stevan> Class.isa(Package)
> 00:27 < stevan> Class.isa(Module), Module.isa(Package), Package.isa(Object)
> 
> See also pugs/trunk/src/PIL/Native/Bootstrap/*.pil
> 
> ... and a package/module is a namespace, it would make some sense, that 
> a vtable (which is part of the PMC class scheme) has a 'namespace' 
> field (as it already has 'class' and 'mro' fields).
> 
> Well, there is another vtable function that is very much related with 
> that: C currently used just for an extra 
> indirection to burn some CPU cycles in method lookup.

Ah yes, of *course*. PMCs have methods, and the methods need to be found
somewhere, so the default place to look should be vtable->namespace.

Is there a problem with killing vtable->namespace_name and replacing its
usages with the existing vtable->namespace?
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: Test Script Best-Practices

[James E Keenan]

Tyler MacDonald wrote:

Jeffrey Thalhammer <[EMAIL PROTECTED]> wrote:
[snip] 

* When run outside of 'make test', should the test
script force modules to load from the distro's lib or
blib directory by default?  Or should it just load
from the user's existing @INC (whatever it may be).



The convention in running tests is to use the 'prove' command;

prove t/01_class.t

That should take care of blib for you.



Not quite.  You need to call the -b option to get prove to read from 
blib.  When I've been revising one of my already installed modules I've 
gotten burned by failing to explicitly call:


prove -b t/01_class.t

(Additional note:  I like to see the test messages, so 99% of the time 
what I actually call is:  prove -vb t/01_class.t)


See 'perldoc prove'.

Jim Keenan

perl6-all@perl.org

[Jonathan Lang]

Larry Wall wrote:
> But my hunch is that it's
> a deep tagmemic/metaphorical problem we're trying to solve here.
> Such issues arise whenever you start making statements of the form
> "I want to use an A as if it were a B."  The problem is much bigger
> than just how do I translate Perl 5 to Perl 6.  It's questions like:
>
> What makes a particular metaphor work?
> Will the cultural context support use of an A as if it were a B?
> How do we translate the user's thoughts to the computer's thoughts?
> How do we translate one user's thoughts to another user's thoughts?
> How do we know when such a translation is "good enough"?
> How do we know when our mental model of an object is adequate?
> How do we know when the computer's mental model of an object is adequate?
> What does adequate mean in context?
> Will the culture support partially instantiated objects?  :-)
>
> That's tagmemics, folks.  The main problem with tagmemics is that, while
> it helps you ask good questions, it doesn't give you easy answers for 'em...

Let me take a (feeble) crack at this:

It sounds like we're talking about something vaguely akin to C++'s
typecasting, where you treat an object of a given class as if it were
an object of a different class.  Another way to phrase this is that
you temporarily want to add role to the object.  "but" doesn't work
because you don't want the new role's default behavior to clobber
existing behavior that the object already has.  Perhaps "like"
instead, with the understanding that "$obj like Hash" means "try
$obj's dispatching first; if that doesn't work, try Hash's
dispatching".

The role in question needs to be an emulator, in that its methods
should have defaults that will make sense when mixed into the object
in question.  Therefore, Hash probably _wouldn't_ work, since Hash
probably isn't set up to work with $obj's internals.  You'd either
have to explicitly provide an appropriate emulator, or implicitly have
Hash find it (i.e., maintain a list of roles that do Hash, along with
a way to test each against $obj's class for compatability).  The
latter is probably a bit too much effort.

Or am I completely missing the point?

> But we'll not get true AI until a computer can understand a sentence like
>
>In a hole in the ground there lived a hobbit.
>
> as if it were a human.  A human has the ability to execute "new Hobbit"
> before "class Hobbit" is even defined!

The essence of this is that you don't need to know everything about
class Hobbit in order to make use of it.  As with Stevan Little's
reference to "lazy objects", you only need to know as much about
Hobbit as is to be used to complete your current task.  In this case,
you don't need to know _anything_ about a Hobbit, yet.  By the time
you _do_ need to know something about it (such as how to form a mental
image of one), the script will presumably have given you the
neccessary information.  If not, you're likely to say something like
"what's a Hobbit?"

a.k.a. "forward referencing".  :)

--
Jonathan Lang

Re: Object initialization protocol breakage?

[Bob Rogers]

   From: Leopold Toetsch <[EMAIL PROTECTED]>
   Date: Wed, 25 Jan 2006 16:54:59 +0100

   Bob Rogers wrote:
   >Sometime between r11268 (probably) and 11276, there was a change to
   > the way that initialization methods get called, regardless of whether
   > "__init" or a 'BUILD' property is used.  If I do
   > 
   >.local pmc foo, hash
   >.local int foo_class
   >foo_class = find_type "User::Foo"
   >foo = new foo_class, hash
   > 
   > to construct the object, the build method gets ".param pmc hash" bound
   > to the hash, as happened in earlier versions, and it works.  If I
   > instantiate the same class without a hash via a string constant:
   > 
   >.local pmc foo
   >foo = new "User::Foo"
   > 
   > then the build method sees self in the hash parameter, and dies.  It's
   > not obvious to me how this is happening.  Are these somehow getting
   > treated differently by the new argument passing code?  TIA,

   I've added a test using __init with and w/o an argument and it works
   as expected (see t/pmc/objects.t - last one).

Great; thanks.

   As the __init function is called with differing args, it has to have
   a signature:

   .sub __init :method
   .param pmc arg :optional

I notice that using an :opt_flag here also works now; it didn't seem to
before.  You may or may not want to include the extra test (attached).

   It's of course debatable, if we should consider an argument as
   flattening by default and call init with a signature

  "vO%"  or "vO@"

   where '%' and '@' denote flattening hash or array respectively.

That would be closer to HLL semantics.  On the other hand, the current
implementation avoids repeated slurping and re-flattening when a series
of related __init methods call each other -- which in turn allows them
to communicate by modifying the hash/array, instead of just the object.
So, if it ain't broke, don't fix it?

   (Your test is hard to follow and it takes a lot of time to dig through 
   all the method calls)

Very true; I produced it via C&P from my compiler output, and didn't
want to invest the time to pretty it up without discussion.

   Ome remark: I don't see any advantage in using the BUILD property - just 
   the opposite - it's the only builtin method call that can be given 
   another name, it complicates the object creation code, well and it's for 
   sure a lot slower then just using __init.

   I'm in favour of removing it.

   leo

That would suit me.  I wrote the code that generated that nearly a year
ago; I probably ought to rewrite it to emit __init methods in any case.

-- Bob

Index: t/pmc/objects.t
===
--- t/pmc/objects.t (revision 11353)
+++ t/pmc/objects.t (working copy)
@@ -6,7 +6,7 @@
 use warnings;
 use lib qw( . lib ../lib ../../lib );
 use Test::More;
-use Parrot::Test tests => 63;
+use Parrot::Test tests => 64;
 
 =head1 NAME
 
@@ -1952,5 +1952,40 @@
 ok 1
 ok 2
 OUTPUT
-
-
+
+pir_output_is(<<'CODE', <<'OUTPUT', "init with and w/o arg, using :opt_flag");
+.sub 'main' :main
+.local pmc cl, o, h, a
+cl = newclass "Foo"
+addattribute cl, "a"
+o = new 'Foo'
+a = getattribute o, "a"
+print a
+h = new .Hash
+$P0 = new .PerlString
+$P0 = "ok 2\n"
+h['a'] = $P0
+$I0 = find_type 'Foo'
+o  = new $I0, h
+a = getattribute o, "a"
+print a
+.end
+
+.namespace ["Foo"]
+.sub __init :method
+.param pmc args :optional
+.param int args_p :opt_flag
+unless args_p goto set_default
+$P0 = args['a']
+setattribute self, 'a', $P0
+.return ()
+
+set_default:
+$P0 = new .PerlString
+$P0 = "ok 1\n"
+setattribute self, 'a', $P0
+.end
+CODE
+ok 1
+ok 2
+OUTPUT

Re: Q: interpreter->stash and namespaces

[Leopold Toetsch]

On Jan 25, 2006, at 21:21, Chip Salzenberg wrote:


On Tue, Jan 24, 2006 at 05:43:25PM +0100, Leopold Toetsch wrote:



*) what is vtable->package? A pointer to the namespace PMC of this
class? (It's currently unused)


Beats me.  Vtables don't have namespaces.  Pleaes just comment it as 
"WTF?"

(or equivalent :-)).


Given that in P6 speak ...

00:27 < stevan> Class.isa(Package)
00:27 < stevan> Class.isa(Module), Module.isa(Package), 
Package.isa(Object)


See also pugs/trunk/src/PIL/Native/Bootstrap/*.pil

... and a package/module is a namespace, it would make some sense, that 
a vtable (which is part of the PMC class scheme) has a 'namespace' 
field (as it already has 'class' and 'mro' fields).


Well, there is another vtable function that is very much related with 
that: C currently used just for an extra 
indirection to burn some CPU cycles in method lookup.


But without further separation of the objects vs class semantics of a 
PMC and w/o interfaces probably not ;)


leo

Re: File pmc, OS pmc, Path pmc and others

[Chip Salzenberg]

On Wed, Jan 25, 2006 at 10:24:51PM +, Alberto Simões wrote:
> Chip:
> >The above-quoted example is only plausible if it's shorthand for, e.g.:
> >
> >$P1 = $P0.stat   # or lstat
> >$P1.is_dir()
> >$P1.is_file()
> >
> 
> Looking to this code, $P0.stat should return a Stat PMC object, so we 
> can call is_dir and is_file.
> Other option is to specify that 'is_dir' and 'is_file' stat the file 
> everytime they are called.

(Call this paragraph "A")

I wouldn't call this 'another option'.  Your two proposals in paragraph "A"
are compatible with each other.

> For me, both options are reasonable. Chip's proposal have the advantage 
> of caching the info.

Oh dear, I goofed in my example.  What I meant is actually compatible with
what you write in paragraph "A" above, namely, that:

   $P0.stat

works, and

   $P0.is_dir
   $P0.is_file

is shorthand for

   $P1 = $P0.stat
   $P1.is_dir()
   $P1 = $P0.stat   # NOTE IMPORTANT SECOND CALL THAT I FORGOT LAST TIME, GRRR
   $P1.is_file()

-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [PROPOSAL] File pmc, OS pmc, Path pmc and others

[Alberto Simões]

It is necessary that Parrot's filesystem interface make user-visible the
_event_ of measuring the attributes of a path _or_ an already open
filesystem object (e.g. calling stat() or fstat()).  It must also represent
the bundle of measurements returned as some kind of PMC.  (handwave handwave)


I agree with that.


Perl 5 does this (fairly crudely) by returning a list of values from stat()
or lstat() which you can examine at leisure, and by special-casing the "_"
filehandle to mean "results of last stat".


We have stat() and lstat() working as well as perl 5 stat and lstat.


The above-quoted example is only plausible if it's shorthand for, e.g.:

$P1 = $P0.stat   # or lstat
$P1.is_dir()
$P1.is_file()



Looking to this code, $P0.stat should return a Stat PMC object, so we 
can call is_dir and is_file.
Other option is to specify that 'is_dir' and 'is_file' stat the file 
everytime they are called.


For me, both options are reasonable. Chip's proposal have the advantage 
of caching the info. Using is_dir and is_file to stat everytime, have 
the advantage of not having a specific Stat PMC object.

Other option, is having one is_dir() and one cached_is_dir().


--
Alberto Simões - Departamento de Informática - Universidade do Minho
 Campus de Gualtar - 4710-057 Braga - Portugal

Re: [PROPOSAL] File pmc, OS pmc, Path pmc and others

[Chip Salzenberg]

Without -yet- commenting on the File/OS/Filesystem issue, this bit of code
is either substantially wrong or just a convenience wrapper around what's
really going on:

On Wed, Jan 25, 2006 at 09:10:50PM +, Alberto Simões wrote:
> $P0 = new .Path("/foo/bar")
[...]
> $P0.is_dir()
> $P0.is_file()

It is necessary that Parrot's filesystem interface make user-visible the
_event_ of measuring the attributes of a path _or_ an already open
filesystem object (e.g. calling stat() or fstat()).  It must also represent
the bundle of measurements returned as some kind of PMC.  (handwave handwave)

Perl 5 does this (fairly crudely) by returning a list of values from stat()
or lstat() which you can examine at leisure, and by special-casing the "_"
filehandle to mean "results of last stat".

The above-quoted example is only plausible if it's shorthand for, e.g.:

$P1 = $P0.stat   # or lstat
$P1.is_dir()
$P1.is_file()

-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [PROPOSAL] File pmc, OS pmc, Path pmc and others

[Alberto Simões]

Nicholas Clark wrote:

Is your implementation going to cope with one OS having several different
types of file systems mounted, that might have different specific behaviours?

I know that HFS+, ufs and ext3 all have various forms of flags/extended
attributes, and in turn I'd assume that a FileSystem PMC would have some
way of accessing them. So I'd assume that parrot has to cope gracefully with
this, and allow full access, although maybe not as far as automatic
detection.


That is a problem I've thought about, but that I don't know how to 
solve. In fact, I'm offering to implement most of this PMC file, but I 
can't go for those details (at least now) as I miss the knowledge :)


cheers
Alberto

--
Alberto Simões - Departamento de Informática - Universidade do Minho
 Campus de Gualtar - 4710-057 Braga - Portugal

Re: [PROPOSAL] File pmc, OS pmc, Path pmc and others

[Nicholas Clark]

On Wed, Jan 25, 2006 at 09:10:50PM +, Alberto Simões wrote:

> 2) What it might be.
> 
> My first idea is to join both PMCs, and create a FileSystem PMC. The 
> main problem is its name. After looking to Python discussion, and 
> thinking a little on the PIR syntax, I would call it Path.

> 3) Implementation
> 
> Some discussion have taken place before regarding copy and rename 
> implementation. I think we can subclass this PMC for specific OSes, and 
> specific FileSystems if needed.

Is your implementation going to cope with one OS having several different
types of file systems mounted, that might have different specific behaviours?

I know that HFS+, ufs and ext3 all have various forms of flags/extended
attributes, and in turn I'd assume that a FileSystem PMC would have some
way of accessing them. So I'd assume that parrot has to cope gracefully with
this, and allow full access, although maybe not as far as automatic
detection.

Nicholas Clark

Re: ff and fff [Was: till (the flipflop operator, formerly ..)]

[Nicholas Clark]

On Wed, Jan 25, 2006 at 02:49:51PM -0600, Jonathan Scott Duff wrote:
> On Wed, Jan 25, 2006 at 11:37:42AM -0800, Larry Wall wrote:
> > I've changed the flipflop operator/macro to "ff", short for "flipflop".
> 
> Two questions: 
> 
> 1) Will ff (and fff) require whitespace around them?
> 2) Do we get a more punctuationish unicode equivalent?

Sadly I can only find

1D191;MUSICAL SYMBOL FORTE;So;0;L;N;

It sems that fortissimo doesn't appear to have a single code point, let alone
fff

Nicholas Clark

Re: ff and fff [Was: till (the flipflop operator, formerly ..)]

[Juerd]

Jonathan Scott Duff skribis 2006-01-25 14:49 (-0600):
> 1) Will ff (and fff) require whitespace around them?

I hope it will be exactly like x and xx. They need whitespace around
them if otherwise it'd be part of an identifier. 

> 2) Do we get a more punctuationish unicode equivalent?

I fear someone will suggest the ff ligature.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

[PROPOSAL] File pmc, OS pmc, Path pmc and others

[Alberto Simões]

Hi

After some discussion on #parrot, and after Leo direct me to this link:
http://mail.python.org/pipermail/python-dev/2006-January/060026.html
Follows some discussion on File.pmc.


1) What it is now.

At the moment we have two OS dependent PMCs: OS and File.

OS includes stat, mkdir, remove, link, symlink, umask, chdir.
File includes is_dir, is_file, is_link, copy, rename

Both PMCs are static classes (no objects, just methods)


2) What it might be.

My first idea is to join both PMCs, and create a FileSystem PMC. The 
main problem is its name. After looking to Python discussion, and 
thinking a little on the PIR syntax, I would call it Path.


That way, we could have things like:

$P0 = new .Path("/foo/bar")
$P0.mkdir()
$P0.remove()
$P0.link("new/file") ## or $P0.link($P1) where $P1 is a Path 
object, or both

$P0.symlink("new/file")
...
$P0.is_dir()
$P0.is_file()
$P0.copy("copy")

and so on.
I am not sure, but I think it would be also possible to:

$S0 = $P0 # get filename
$P0 = $S1 # change object... similar to 'new .Path($S1)'

If we want to mask dos/linux/mac, we can use

$P0 = new .Path("foo","bar")

so that Parrot uses the correct separator.


3) Implementation

Some discussion have taken place before regarding copy and rename 
implementation. I think we can subclass this PMC for specific OSes, and 
specific FileSystems if needed.



Cheers
ambs
--
Alberto Simões - Departamento de Informática - Universidade do Minho
 Campus de Gualtar - 4710-057 Braga - Portugal

Re: ff and fff [Was: till (the flipflop operator, formerly ..)]

[Jonathan Scott Duff]

On Wed, Jan 25, 2006 at 11:37:42AM -0800, Larry Wall wrote:
> I've changed the flipflop operator/macro to "ff", short for "flipflop".

Two questions: 

1) Will ff (and fff) require whitespace around them?
2) Do we get a more punctuationish unicode equivalent?

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Q: interpreter->stash and namespaces

[Chip Salzenberg]

On Tue, Jan 24, 2006 at 05:43:25PM +0100, Leopold Toetsch wrote:
> *) what is Stash.parent_stash? (It's currently unused)

Historically, "stash" is perl5-guts-speak for "namespace".  However, I see
in Parrot the Stash structure which seems quite different.  From its usage,
I gather it's an attempt at layered or translucent namespaces -- where one
namespace underlies another and is only consulted when the top one does not
contain the name being searched for.  Interesting, but puzzling.  Let it
live.  For now.

> *) I presume that the stash_hash is the thing, that holds the top-level 
> namespace.

Each stash_hash should now hold a pointer to a namespace.  But why call it
"top-level"?  It seems to me, based on its construction, that a Stash could
refer to any namespace, not just the top-level one.

> *) what is vtable->package? A pointer to the namespace PMC of this 
> class? (It's currently unused)

Beats me.  Vtables don't have namespaces.  Pleaes just comment it as "WTF?"
(or equivalent :-)).

> *) what is Parrot_Context.current_package? Shoudn't that better be a 
> PMC* current_namespace (if we want to cache the current_subs's namespace)?

Yes, it should be current_namespace.  And I think the 'getpackage' and
'setpackage' opcodes are going away, to be replaced with more robust
namespace operations.  (I have no idea why anybody [even Dan :-)] would have
thought that caching the current package's *name* would be particularly wise
or useful.  Names change, but a PMC* is forever.)
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: ff and fff [Was: till (the flipflop operator, formerly ..)]

[Rob Kinyon]

On 1/25/06, Juerd <[EMAIL PROTECTED]> wrote:
> Patrick R. Michaud skribis 2006-01-25 13:47 (-0600):
> > On Wed, Jan 25, 2006 at 11:37:42AM -0800, Larry Wall wrote:
> > > I've changed the flipflop operator/macro to "ff", short for "flipflop".
> > > This has several benefits.  ...
> > ...another of which is that we can use "ff" and "fff" to mean "loud"
> > and "really loud" in our perl poetr^H^H^H^H^Hmusic.  :-)
>
> We need pp and ppp for balance.

/me wonders who signed up "The Little Einsteins"(tm) for P6l ...

Re: ff and fff [Was: till (the flipflop operator, formerly ..)]

[Juerd]

Patrick R. Michaud skribis 2006-01-25 13:47 (-0600):
> On Wed, Jan 25, 2006 at 11:37:42AM -0800, Larry Wall wrote:
> > I've changed the flipflop operator/macro to "ff", short for "flipflop".
> > This has several benefits.  ...
> ...another of which is that we can use "ff" and "fff" to mean "loud" 
> and "really loud" in our perl poetr^H^H^H^H^Hmusic.  :-)

We need pp and ppp for balance.


Juerd
-- 
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html 
http://convolution.nl/gajigu_juerd_n.html

Re: Supporting safe managed references

[Chip Salzenberg]

On Tue, Jan 24, 2006 at 09:19:48AM -0800, Larry Wall wrote:
> On Tue, Jan 24, 2006 at 01:04:10PM -, Jonathan Worthington wrote:
> : Looking at what Chip said though, it would appear that the much cleaner 
> : solution I was hoping to find exists and can be found in lex pad stuff, 
> : which I need to go stare at for a bit before replying.  :-)
> 
> This is tangentially related, but we might need to think about
> something like typed references in any event to enable various forms
> of round-trip language interoperability.  That is, we could have
> references that are polymorphic depending on language context,
> so that different behaviors can be emulated depending on which
> facilities are native to the language and which are "borrowed" from
> some other language.  Think of something which is simultaneously a
> P5 and a P6 object.

An interesting idea.  Should be easy enough to do with existing facilities,
switching behavior at runtime based on  CALLER.sub.hll .
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [perl #38229] [TODO] Make all pod documents(such as README's) end in .pod

[Will Coleda]

Already checked, it's not linked to.

Any missing docs on the website, please open a fresh ticket.

Regards.

On Jan 25, 2006, at 10:08 AM, Bernhard Schmalhofer via RT wrote:


jisom did most of the renaming in r11180.
I renamed README.win32 in r11351.

So it looks like everything is taken care of and I close this ticket.

coke: If README.win32 is on parrotcode.org, it propably needs to be
renamed as well.

--
/* [EMAIL PROTECTED] */

Re: ff and fff [Was: till (the flipflop operator, formerly ..)]

[Patrick R. Michaud]

On Wed, Jan 25, 2006 at 11:37:42AM -0800, Larry Wall wrote:
> I've changed the flipflop operator/macro to "ff", short for "flipflop".
> This has several benefits.  ...

...another of which is that we can use "ff" and "fff" to mean "loud" 
and "really loud" in our perl poetr^H^H^H^H^Hmusic.  :-)

Pm

ff and fff [Was: till (the flipflop operator, formerly ..)]

[Larry Wall]

I've changed the flipflop operator/macro to "ff", short for "flipflop".
This has several benefits.  It's a doubled char like other short-circuit
operators.  It lets us add an "fff" to be equivalent to p5's scalar
... operator, and either of them can take the ^ modifiers to exclude
endpoints.  In trying to explain p5's flipflip operator, GrandFather
on perlmonks just abbreviated it as "f/f", so it seems pretty natural
that way.  Also, upon a bit of psychological reflection, it's probably
actually *good* for this operator to be an obscure one, because
the very readability of "till" would tend to give people the false
impression they know what's going on.  Much better to send them to
the manual to look up what "ff" means than to have them guessing wrong.
(And being alphabetic it's easier to look up than a doubled punctuation
character would be, if we had any punctuation characters to spare for
a rare operator, which we don't.)

Larry

Re: pdd21 notes

[Chip Salzenberg]

On Tue, Jan 24, 2006 at 12:34:28PM -0800, Chip Salzenberg wrote:
> add_scalar(STRING, PMC*)
> add_array(STRING, PMC*)
> add_hash(STRING, PMC*)

WRT namespaces, I'm starting to think we should replace each *_var()
functions with three functions *_scalar(), *_array(), and *_hash().  Parrot
is ingrained with the idea that values can be unkeyed, integer-keyed, or
string-keyed.  More complex keys are also available, of course, but those
three are privileged (and for good reason).

Perlish languages will want the distinction (thus the change is helpful),
and Pythonish languages won't care -- everything is unprefixed (thus the
change does no harm).
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: Q: pdd21 relative vs absolute

[Matt Diephouse]

Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> A bunch of namespace opcodes and methods could work absolute or
> relative. E.g.
>
>$P0 = get_namespace ["Foo"; "Bar"]
>
> Where should the lookup start?

Absolute. If people want relative lookups, I'd consider adding another opcode:

  $P1 = get_namespace # this exists - get the current namespace
  $P2 = get_namespace $P1, ["Foo"; "Bar"] # this doesn't - lookup
Foo::Bar in $P1 (the current namespace)

--
matt diephouse
http://matt.diephouse.com

Re: Q: pdd21 relative vs absolute

[Joshua Isom]

Having it be absolute makes more sense to me, but there likely will be 
people who want relative.  Maybe something like:


$P0 = get_namespace[;"Foo";"Bar"]

Where the empty part mean "current namespace here."  Of course, then 
it'd be really confusing because it's the opposite of pathnames on 
unix.  Although if [;"Foo";"Bar"] is absolute, it makes sense as well 
because the default namespace is "unnamed" and it'd be more convenient 
than writing ["";"Foo";"Bar].


On Jan 25, 2006, at 9:01 AM, Leopold Toetsch wrote:

A bunch of namespace opcodes and methods could work absolute or 
relative. E.g.


  $P0 = get_namespace ["Foo"; "Bar"]

Where should the lookup start?

Is this to be considered absolute (from namespace root), absolute from 
the current HLL setting, or relative from the current namespace?


Thanks,
leo

Re: [perl #38288] [PATCH] Change Parrot_call to Parrot_call_sub in pdd11

[Leopold Toetsch]

Brad Bowman (via RT) wrote:


-=item C
+=item C


This still doesn't reflect src/extend.c usage. But don't worry too much 
about pdds/clip/* - these are being reworked.


Thanks,
leo

Re: [perl #38281] [PATCH] Remove cache.* reference from pobj.h comments

[Leopold Toetsch]

Brad Bowman (via RT) wrote:


Looking through pobj.h, I found what seems to be a dated
comment referring to "cache.*".  I don't think this exists
anymore, unless it's referring to hashval in some oblique way.


Sorry for the delay, I must have missed it. Anyway, your observations 
are correct, thanks, applied - r11346.


leo

Re: Object initialization protocol breakage?

[Leopold Toetsch]

Bob Rogers wrote:

   Sometime between r11268 (probably) and 11276, there was a change to
the way that initialization methods get called, regardless of whether
"__init" or a 'BUILD' property is used.  If I do

.local pmc foo, hash
.local int foo_class
foo_class = find_type "User::Foo"
foo = new foo_class, hash

to construct the object, the build method gets ".param pmc hash" bound
to the hash, as happened in earlier versions, and it works.  If I
instantiate the same class without a hash via a string constant:

.local pmc foo
foo = new "User::Foo"

then the build method sees self in the hash parameter, and dies.  It's
not obvious to me how this is happening.  Are these somehow getting
treated differently by the new argument passing code?  TIA,


I've added a test using __init with and w/o an argument and it works as 
expected (see t/pmc/objects.t - last one). As the __init function is 
called with differing args, it has to have a signature:


.sub __init :method
   .param pmc arg :optional

It's of course debatable, if we should consider an argument as 
flattening by default and call init with a signature


  "vO%"  or "vO@"

where '%' and '@' denote flattening hash or array respectively.

(Your test is hard to follow and it takes a lot of time to dig through 
all the method calls)


Ome remark: I don't see any advantage in using the BUILD property - just 
the opposite - it's the only builtin method call that can be given 
another name, it complicates the object creation code, well and it's for 
sure a lot slower then just using __init.


I'm in favour of removing it.



-- Bob Rogers
   http://rgrjr.dyndns.org/


leo

Q: pdd21 relative vs absolute

[Leopold Toetsch]

A bunch of namespace opcodes and methods could work absolute or 
relative. E.g.


  $P0 = get_namespace ["Foo"; "Bar"]

Where should the lookup start?

Is this to be considered absolute (from namespace root), absolute from 
the current HLL setting, or relative from the current namespace?


Thanks,
leo

Perl 6 Summary for 2006-01-10 though 2006-01-24

[Bob Rogers]

   From: Matt Fowles <[EMAIL PROTECTED]>
   Date: Tue, 24 Jan 2006 21:50:47 -0500

   Perl 6 Summary for 2006-01-10 though 2006-01-24

 Perl 6 Internals

  Clean Up After Yourself
   Bob Rogers provided a patch which makes " examples/pir/io.pir " clean up
   its temp file. Warnock applies.

   

FWIW, this was applied by Bernhard on 2006-01-15, but he replied
off-list.  (The other two warnocked patches I submitted are still
warnocked.)

-- Bob

Re: Perl 6 Summary for 2006-01-10 though 2006-01-24

[Klaas-Jan Stol]

Matt Fowles wrote:


  LuaNil Morphing
   Klaas-Jan Stol proffered a patch which changed LuaNil from a singleton
   and made it morph to other Lua types when asked. Warnock applies.

 

Actually, François Perrad applied this patch, but I think he only sent a 
reply to me.



   

  LuaTable Loving
   Klaas-Jan Stol also provided a patch making LuaTable more correct.
   Warnock applies.
 


Same here.

kjs