Re: Building Parrot with MinGW, ActivePerl & command.com

[François PERRAD]

At 12:19 10/06/2005 +0200, you wrote:

On Saturday 04 June 2005 20:29, Clement Cherlin wrote:
> I include a patch I made for the above problems. Some of the changes are
> kind of kludgey, so I would appreciate comments and suggestions on how to
> improve them.
Thanks, applied.


Please, revert this patch (r8298)
With MinGW & cmd.exe :
$ make test
perl.exe t\harness --gc-debug --running-make-test  t\library\*.t 
t\op\*.t t\pmc\*.t t\native_pbc\*.t imcc\t\*\*.t t\dynclass\*.t t\src\*.t 
t\perl\*.t

FAILED--no tests were run for some reason.

In its initial mail, Clement Cherlin wrote : "I still haven't gotten 
compilation to finish ..."


Francois Perrad.


jens

PDD03: The new boss

[Bob Rogers]

   From: Chip Salzenberg <[EMAIL PROTECTED]>
   Date: Tue, 14 Jun 2005 00:04:54 +0200

   . . . you probably want to read it, if only because it will point you
   to AN UPDATED PDD.  Really.

Great!  Pardon the typing; it's hard when my head is spinning . . .

   FWIW, there is one thing that jumps out at me:

   It looks to me like the "Required features are missing:" items are
mostly things that would require the compiler for a given language to
generate code for each particular case.  There may be partial exceptions
for different languages, but defaulting in particular is almost
certainly going to involve conditional evaluation of application code
(e.g. it does in Lisp).

   So, IMHO, it seems more versatile to have these opcodes operate on
one arg/return at a time, instead of monolithically on the whole list:

set_arg , , 
set_return , , 
 = get_param , 
 = get_result , 

where  can be an Ireg or a constant.  This makes it easier to
extend .  It also leaves room for such things as:

flatten_arg , , 
foldup_return , , 
 = foldup   ## same; need another for returns?

rather than encoding these in .  (With the objection that
flatten_arg in the middle of the list screws up indexing for the rest of
the args.)

   To ignore a parameter, simply don't fetch it.  To ignore a return,
simply don't supply a register for it.

   One still needs something equivalent to argc (but probably only one),
in order to find out what needed defaulting.  To see if whether or not
the Nth argument was supplied [1], just compare N to argc.

   I would also argue that the generated PIR should be in charge of
signalling language-specific "too few/many" args errors.  (The language
may be required to do so in any case.)

   If we wanted to be really radical (is my head still spinning?), we
could promote call frames to first-class objects.  That way, compilers
could easily overlap the assembly of nested calls, as for a stack
machine.  If frames were implemented as array-like PMCs, then C
would be a natural way to add the next arg, but it's not clear to me how
to provide separate indexing cleanly for calls and returns.  (Use the
sign of the index?  Yuck.)  In any case, I'm sure something like this
has been done before, but I'm not enough of a compiler/architecture geek
to know.

   If I've gone too far out on a limb [2], then I apologize; I'll let my
head slow down a bit before I post again.  ;-}

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

[1]  Common Lisp allows a "supplied-p-parameter" variable to be bound
 for optional and keyword arguments; see
 http://www.lispworks.com/documentation/HyperSpec/Body/03_da.htm for
 details.

[2]  Is GMP going too far out on a libm?  Oh, it must be past time for
 bed . . .

[perl #36277] [TODO] Tcl's [interpinfo name]

[via RT]

# New Ticket Created by  Will Coleda 
# Please include the string:  [perl #36277]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=36277 >


Need parrot support before this can be implemented.

Re: Hackathon Day 2+3 Report

[Bill Coffman]

On 6/13/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> 
> I've posted a report on the Hackathon Days 2+3 as a journal entry on
> use.perl.org :
> 
> http://use.perl.org/~chip/journal/25182
> 
> I'm not going to copy it here, but you probably want to read it, if
> only because it will point you to AN UPDATED PDD. Really.
> --
> Chip Salzenberg <[EMAIL PROTECTED]>


Chip,

This is really great to see! The whole continuations/regalloc thing is being 
addressed! It's great to see this kind of progress. Implementing this kind 
of register allocator could be tricky, for a number of reasons, but it's 
great that there is a direction now. OTOH, a minimally functional version of 
this architecture can be created by, as you say, just by register 
renumbering. Anything beyond that is premature optimization, at this point.

Thanks for moving on this, and Kudos to you and Leo!
Bill

Re: Perl defined Object, Array, Hash classes

[Larry Wall]

You shouldn't be able to reopen/clobber an existing class/module unless
you specify

class Object is augmented {...}
class Object is replaced {...}

or some such (the trait names are still negotiable).  In general,
private classes should start with "my" or "our", though I don't know
if Pugs handles inner classes yet.  Also note that only the class
definition needs special scope annotation, since (unlike Perl 5), Perl
6 searches upward/outward for matching class names when you mention
something like "Object".  You can still get in trouble with an inner
Object hiding an outer Object, but at least you aren't clobbering
everyone's Object definition that way, and global Objects created
outside the scope of your private Object still know which kind of
Object they are.

Larry

Perl defined Object, Array, Hash classes

[Eric]

Hey,

Found out this morning that wizard.p6 suddenly stopped wondering and I was 
stumped as to why. The autrijus came along and pointed out that i was 
defineing an Object class of my own. This was obliterating the built in 
class causing all other classes to fail to work at all. It would seem from 
my point of view then that adding class definitions like that through the 
language should not be done in the root namespace. By putting them there we 
obliterate any user defined classes (or vice versa in this case). I think it 
would be much better to instead put those internal definitions in there own 
namespace or seperate them out in some similar manner. That way in the 
future the language can add its own classes without fear of conflicts with 
user defined classes. After all there is no reason to paint ourselves into 
that corner so early, no one wants to have to fight for new internal classes 
because every added class could possibly compromise existing code. 

Well that is my 2 cents and my first post here so please forgive anything 
that apears rude or stupid and guide me on how to improve future posts.

Thanks,

__
Eric Hodges

Hackathon Day 2+3 Report

[Chip Salzenberg]

I've posted a report on the Hackathon Days 2+3 as a journal entry on
use.perl.org:

http://use.perl.org/~chip/journal/25182

I'm not going to copy it here, but you probably want to read it, if
only because it will point you to AN UPDATED PDD.  Really.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: State of Design Documents

[Patrick R. Michaud]

On Mon, Jun 13, 2005 at 02:22:59PM -0500, Patrick R. Michaud wrote:
> On Fri, Jun 10, 2005 at 02:36:52PM -0400, Joshua Gatcomb wrote:
> 
> > I have included a sample framework for chapter 17.  Theoretically,
> > someone could then go search the archives for decision points in any
> > of those headings and fill in the blanks.  

Since it might not have been clear from my earlier post -- I've
now committed the S17 framework draft into the repository.  Thanks.

Pm

Re: State of Design Documents

[Patrick R. Michaud]

On Mon, Jun 13, 2005 at 02:22:59PM -0500, Patrick R. Michaud wrote:
> On Fri, Jun 10, 2005 at 02:36:52PM -0400, Joshua Gatcomb wrote:
> > Ok, are there any guidelines for what should and should not be put
> > forward as a patch.  
> [...]
> For anything that doesn't come from @Larry or $Larry, I think we can
> perhaps provide a notation that the item is "draft" or "proposed" status
> if there's any doubt about its ultimate acceptance in Perl 6.  It's again
> much easier to do a "grep draft" on the design document files to find
> potentially unblessed items than it is to search through the p6l archives.

FWIW, Larry also responded on perlmonks:

However, there are no general guidelines for how to document 
the as-yet undesigned parts of the design. The best you can do 
is to make a guess consistent with the current design and see if 
anyone carps about it. A certain willingness to be sincerely 
misguided goes with the territory. :-)

So, this sounds to me like framework patches could be useful and helpful.
It's also a useful reminder that none of use completely knows where the 
Perl 6 design will end up, so guesses -- even incorrect ones -- are a
often a step forward.

Going a bit further than this... On #perl6 today we observed that 
it might be helpful to know which parts of the documents others,
especially members of @Larry, already have designs upon (i.e., have
a strong desire or intention to write that section because of its
potential impacts to other parts of Perl 6 design).  This would help
potential contributors to know which sections are already being
"thought about" by the design team, even if they're not being turned
into documents yet, and which sections might be open for contributions
from the community at large.  Even a simple "section authorship claimed 
by so-and-so" notation in placeholder documents would be helpful.

At any rate, I'll moderate patches to the design documents along these
lines, unless/until someone tells me not to do it.  :-)  And if any of
@Larry can let me know of any sections they feel strongly about, I'll
build and maintain notations to that effect in the documents.

Pm

Re: [perl #36269] Alignment problems with doubles on SPARC.

[Andy Dougherty]

On Mon, 13 Jun 2005, Leopold Toetsch via RT wrote:

> Chip Salzenberg wrote:
> > On Mon, Jun 13, 2005 at 02:57:09PM -0400, Andy Dougherty wrote:
> 
> >>Yes.  The compiler does the right thing.  It sensibly reports 
> >>that sizeof(PMC) = 24 for SPARC.
> > 
> > Then I remain puzzled how Parrot could ever misalign a double.
> 
> Yes. So I am. Could somone please run this PASM snippet in a debugger so 
> that we can see, where it fails.

Here's where it fails:

(dbx) run ../num2.pasm
(process id 7721)
[EMAIL PROTECTED] ([EMAIL PROTECTED]) signal BUS (invalid address alignment) in 
Parrot_set_n_nc (optimized) at line 149 in file "set.ops"
149 goto NEXT();
(dbx) where
current thread: [EMAIL PROTECTED]
=>[1] Parrot_set_n_nc(cur_opcode = ???, interpreter = ???) (optimized), at 
0xa9160 (line ~149) in "set.ops"
[2] runops_slow_core(interpreter = ???, pc = ???) (optimized), at 0xdd2a0 (line 
~105) in "runops_cores.c"
[3] runops_int(interpreter = ???, offset = ???) (optimized), at 0xdbc70 (line 
~657) in "interpreter.c"
[4] runops(interpreter = ???, offs = ???) (optimized), at 0xdc6d4 (line ~40) in 
"inter_run.c"
[5] Parrot_runcode(interpreter = ???, argc = ???, argv = ???) (optimized), at 
0x8482c (line ~757) in "embed.c"
[6] Parrot_runcode(interpreter = ???, argc = ???, argv = ???) (optimized), at 
0x846ac (line ~757) in "embed.c"
[7] main(argc = ???, argv = ???) (optimized), at 0x68058 (line ~448) in "main.c"

Alas, since this is an optimized compile, there is no single stepping in the 
debugger.

-- 
Andy Dougherty  [EMAIL PROTECTED]

Re: [perl #36269] Alignment problems with doubles on SPARC.

[Leopold Toetsch]

Chip Salzenberg wrote:

On Mon, Jun 13, 2005 at 02:57:09PM -0400, Andy Dougherty wrote:


Yes.  The compiler does the right thing.  It sensibly reports 
that sizeof(PMC) = 24 for SPARC.



Then I remain puzzled how Parrot could ever misalign a double.


Yes. So I am. Could somone please run this PASM snippet in a debugger so 
that we can see, where it fails.


leo

Re: State of Design Documents

[Patrick R. Michaud]

On Fri, Jun 10, 2005 at 02:36:52PM -0400, Joshua Gatcomb wrote:
> Ok, are there any guidelines for what should and should not be put
> forward as a patch.  I can see 3 key areas of concern:
> 
> 1.  Framework for unwritten Synopses (so we know what goes where)
> 2.  Heading placeholders for written Synopses with missing information
> 3.  Decisions rendered by @larry (or should it only be $larry) on the
> list that are not yet in the corresponding Synopsis

I think any of these are candidates for patches.  Certainly it's easier
for others to respond to (and suggest further patches to) specific written
proposed documents than it is to try to find things in the mailing list
threads.

For anything that doesn't come from @Larry or $Larry, I think we can
perhaps provide a notation that the item is "draft" or "proposed" status
if there's any doubt about its ultimate acceptance in Perl 6.  It's again
much easier to do a "grep draft" on the design document files to find
potentially unblessed items than it is to search through the p6l archives.

> I have included a sample framework for chapter 17.  Theoretically,
> someone could then go search the archives for decision points in any
> of those headings and fill in the blanks.  Is this what you envisioned
> or were you thinking only minor tweaks to existing documents?

I'm envisioning anything that helps advance the state of the documentation
and Perl 6 development.  In that sense, I think that even templates and 
placeholders can be helpful as long as they don't lead people down the 
wrong path (or as long as they're fairly up front about "this might be 
the wrong path").

Pm

Re: [perl #36269] Alignment problems with doubles on SPARC.

[Chip Salzenberg]

On Mon, Jun 13, 2005 at 02:57:09PM -0400, Andy Dougherty wrote:
> On Mon, 13 Jun 2005, Chip Salzenberg via RT wrote:
> 
> > On Mon, Jun 13, 2005 at 08:38:30PM +0200, Leopold Toetsch wrote:
> > > Chip Salzenberg wrote:
> > > >On Mon, Jun 13, 2005 at 07:29:53PM +0200, Leopold Toetsch wrote:
> > > >>The PMC allocation area is a big bunch of memory, where PMC-sized
> > > >>pieces are carved out by the memory allocation system. There is no
> > > >>union or compiler bug involved.
> > > >
> > > >But "PMC-sized" is defined in terms of the C sizeof operator, right?
> > > 
> > > Yes. And the size can be 20 or better it is with --optimize on an 32-bit 
> > > system, which places every second PMC->num_val on an "odd" boundary.
> > 
> > If architecture X requires N-byte alignment for type T; and any
> > compiler for architecture X defines any structure containing a member
> > of type T as having a total structure size that is not a multiple of
> > N, then that compiler really is buggy.  It's an inevitable consequence
> > of how array allocation and pointer arithmetic are defined.
> 
> Yes.  The compiler does the right thing.  It sensibly reports 
> that sizeof(PMC) = 24 for SPARC.

Then I remain puzzled how Parrot could ever misalign a double.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [perl #36269] Alignment problems with doubles on SPARC.

[Andy Dougherty]

On Mon, 13 Jun 2005, Chip Salzenberg via RT wrote:

> On Mon, Jun 13, 2005 at 08:38:30PM +0200, Leopold Toetsch wrote:
> > Chip Salzenberg wrote:
> > >On Mon, Jun 13, 2005 at 07:29:53PM +0200, Leopold Toetsch wrote:
> > >>The PMC allocation area is a big bunch of memory, where PMC-sized
> > >>pieces are carved out by the memory allocation system. There is no
> > >>union or compiler bug involved.
> > >
> > >But "PMC-sized" is defined in terms of the C sizeof operator, right?
> > 
> > Yes. And the size can be 20 or better it is with --optimize on an 32-bit 
> > system, which places every second PMC->num_val on an "odd" boundary.
> 
> If architecture X requires N-byte alignment for type T; and any
> compiler for architecture X defines any structure containing a member
> of type T as having a total structure size that is not a multiple of
> N, then that compiler really is buggy.  It's an inevitable consequence
> of how array allocation and pointer arithmetic are defined.

Yes.  The compiler does the right thing.  It sensibly reports 
that sizeof(PMC) = 24 for SPARC.

-- 
Andy Dougherty  [EMAIL PROTECTED]

Re: [perl #36269] Alignment problems with doubles on SPARC.

[Chip Salzenberg]

On Mon, Jun 13, 2005 at 08:38:30PM +0200, Leopold Toetsch wrote:
> Chip Salzenberg wrote:
> >On Mon, Jun 13, 2005 at 07:29:53PM +0200, Leopold Toetsch wrote:
> >>The PMC allocation area is a big bunch of memory, where PMC-sized
> >>pieces are carved out by the memory allocation system. There is no
> >>union or compiler bug involved.
> >
> >But "PMC-sized" is defined in terms of the C sizeof operator, right?
> 
> Yes. And the size can be 20 or better it is with --optimize on an 32-bit 
> system, which places every second PMC->num_val on an "odd" boundary.

If architecture X requires N-byte alignment for type T; and any
compiler for architecture X defines any structure containing a member
of type T as having a total structure size that is not a multiple of
N, then that compiler really is buggy.  It's an inevitable consequence
of how array allocation and pointer arithmetic are defined.

Of course, there's more than one definition of "requires" that makes
sense.  Compilers are allowed to generate slow code, just not broken.
AFAIK, Intel doesn't actually require any particular alignment of
doubles, but what IK on the subject isn't much.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [perl #36269] Alignment problems with doubles on SPARC.

[Andy Dougherty]

On Mon, 13 Jun 2005, Leopold Toetsch via RT wrote:

> Chip Salzenberg wrote:
> > On Mon, Jun 13, 2005 at 07:12:48PM +0200, Leopold Toetsch wrote:
> > 
> >>Andy Dougherty (via RT) wrote:
> >>
> >>>...  On SPARC, doubles should be aligned on 8-bit boundaries.
> >>>The speculation is that the _num_val part of the UnionVal in the PMC
> >>>ends up unaligned.  However, I couldn't follow where that happened, so I 
> >>>can't suggest a patch.
> >>
> >>It happends directly in the PMC memory arena. Whenever the PMC size % 8 
> >>isn't zero.

Yes, I saw this bit in include/parrot/pobj.h:

/* Parrot Object - base class for all others */
typedef struct pobj_t {
UnionVal u;
Parrot_UInt flags;
#if ! DISABLE_GC_DEBUG
UINTVAL _pobj_version;
#endif /* ! DISABLE_GC_DEBUG */
} pobj_t;

In an optimized compile, sizeof(pobj_t) is 16, and sizeof(PMC) is 
24, both of which are nice multiples of 8.

> > That's gotta be a compiler bug.  When a structure contains a member
> > that needs N-byte alignment, and sizeof(structure) % N is not zero,
> > the compiler is busted.  (Have they never heard of _arrays_?)
> 
> The PMC allocation area is a big bunch of memory, where PMC-sized pieces 
> are carved out by the memory allocation system. There is no union or 
> compiler bug involved. It's caused by the memory allocator and the GC 
> system.

That's what I couldn't follow.  Where are PMC-sized pieces carved out
that aren't carved out using sizeof(PMC)?

-- 
Andy Dougherty  [EMAIL PROTECTED]

Re: [perl #36269] Alignment problems with doubles on SPARC.

[Leopold Toetsch]

Chip Salzenberg wrote:

On Mon, Jun 13, 2005 at 07:29:53PM +0200, Leopold Toetsch wrote:


The PMC allocation area is a big bunch of memory, where PMC-sized
pieces are carved out by the memory allocation system. There is no
union or compiler bug involved.



But "PMC-sized" is defined in terms of the C sizeof operator, right?


Yes. And the size can be 20 or better it is with --optimize on an 32-bit 
system, which places every second PMC->num_val on an "odd" boundary.


leo

Re: Anonymous macros?

[Larry Wall]

On Mon, Jun 13, 2005 at 05:25:59PM +0200, Ingo Blechschmidt wrote:
: just checking: Are anonymous macros allowed?

I have no problem with macros being first-class objects during
the compile.  Though the macro itself may have a problem with your
passing it '3' when it is likely expecting an AST.  But maybe 3 can
be taught how to be an AST if it needs to.  Probably means macros
are not only first class but MMD too.  :-)

Larry

Re: BEGIN {...} and IO

[Autrijus Tang]

On Mon, Jun 13, 2005 at 10:48:47AM -0700, chromatic wrote:
> >   # Problem;
> >   my $fh = BEGIN { open "some_file" err... };
> >   # Compile-time filehandle leaked into runtime!
> >   say =$fh;
> 
> Perhaps I'm being very naive, but why is this a problem?  Maybe it's not
> the best way to do something, but I can see it being useful in some
> circumstances.

Er.  The BEGIN{} time thing is a FileHandle.

When compilation finishes, this program is saved as a .ast, or a .pbc,
or a .hs, or a .c file.

On runtime, $fh is supposed to contain a immutable constant value,
much as like if we had said:

my $compile_time = BEGIN { time() };

Except it involves external resources.

Thanks,
/Autrijus/


pgpBuu8g9rXCt.pgp
Description: PGP signature

Re: BEGIN {...} and IO

[Ingo Blechschmidt]

Hi,

chromatic wrote:
> On Mon, 2005-06-13 at 17:07 +0200, Ingo Blechschmidt wrote:
>>   # No problem:
>>   my $data = BEGIN {
>> my $fh = open "some_file" err...;
>> =$fh;
>>   };
>> 
>>   # Problem;
>>   my $fh = BEGIN { open "some_file" err... };
>>   # Compile-time filehandle leaked into runtime!
>>   say =$fh;
> 
> Perhaps I'm being very naive, but why is this a problem?  Maybe it's
> not the best way to do something, but I can see it being useful in
> some circumstances.

sorry I was unclear, the problem is:

Consider you want to first compile a program to a .pbc on host1, and
then run it on host2:

  host1 $ echo hi > some_file  # Make sure "some_file"
   # exists on host1.
  host1 $ cat > program.p6
  my $fh = BEGIN { open "some_file" err... };
  say =$fh
  ^D
  host1 $ pugs -o program.pbc program.p6   # Hypothetical syntax
  # "some_file" is opened at compile-time, and an IO handle object
  # is returned. $fh contains an IO object now.
  # In the resulting program.pbc, there's no call to open() [1].
  host1 $ scp program.pbc host2:.  # Copy program.pbc to host2

  # "some_file" does not exist on host2:
  host2 $ ls -l some_file
  ls: some_file: No such file or directory
  host2 $ parrot program.pbc
  # XXX! Tries to readline() from an invalid filehandle!
  # Additionally, "some_file" doesn't exist on host2...

Do you see the problem? IO objects are only valid in the same process.
But the compiler process and the execution process are/may be
decoupled, or may even be on different computers.


--Ingo

[1] Similar as in this example:
  my $compiled_at = BEGIN { time };
  say "I was compiled at $compiled_at seconds after the epoch.";
If you compile this to a .pbc, there won't be a call to time(),
but the whole BEGIN block is substituted by the return value of
time(). So, what the Perl 6 compiler will actually compile to
PIR is:
  my $compiled_at = 172001560.613011;
  say "I was compiled at $compiled_at seconds after the epoch.";
(Of course, a smart compiler can optimize this further.)

-- 
Linux, the choice of a GNU | To understand recursion, you must first
generation on a dual AMD   | understand recursion.
Athlon!| 

Re: BEGIN {...} and IO

[chromatic]

On Mon, 2005-06-13 at 17:07 +0200, Ingo Blechschmidt wrote:

>   # No problem:
>   my $data = BEGIN {
> my $fh = open "some_file" err...;
> =$fh;
>   };
> 
>   # Problem;
>   my $fh = BEGIN { open "some_file" err... };
>   # Compile-time filehandle leaked into runtime!
>   say =$fh;

Perhaps I'm being very naive, but why is this a problem?  Maybe it's not
the best way to do something, but I can see it being useful in some
circumstances.

Are you worried about using up resources?  If you don't refer to $fh
elsewhere, GC will take care of it.  (If you really worried about it,
you'd explicitly close it somewhere.)

-- c

Re: [perl #36269] Alignment problems with doubles on SPARC.

[Chip Salzenberg]

On Mon, Jun 13, 2005 at 07:29:53PM +0200, Leopold Toetsch wrote:
> The PMC allocation area is a big bunch of memory, where PMC-sized
> pieces are carved out by the memory allocation system. There is no
> union or compiler bug involved.

But "PMC-sized" is defined in terms of the C sizeof operator, right?
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [perl #36269] Alignment problems with doubles on SPARC.

[Leopold Toetsch]

Chip Salzenberg wrote:

On Mon, Jun 13, 2005 at 07:12:48PM +0200, Leopold Toetsch wrote:


Andy Dougherty (via RT) wrote:


...  On SPARC, doubles should be aligned on 8-bit boundaries.
The speculation is that the _num_val part of the UnionVal in the PMC
ends up unaligned.  However, I couldn't follow where that happened, so I 
can't suggest a patch.


It happends directly in the PMC memory arena. Whenever the PMC size % 8 
isn't zero.



That's gotta be a compiler bug.  When a structure contains a member
that needs N-byte alignment, and sizeof(structure) % N is not zero,
the compiler is busted.  (Have they never heard of _arrays_?)


The PMC allocation area is a big bunch of memory, where PMC-sized pieces 
are carved out by the memory allocation system. There is no union or 
compiler bug involved. It's caused by the memory allocator and the GC 
system.


leo

Re: [perl #36269] Alignment problems with doubles on SPARC.

[Chip Salzenberg]

On Mon, Jun 13, 2005 at 07:12:48PM +0200, Leopold Toetsch wrote:
> Andy Dougherty (via RT) wrote:
> >...  On SPARC, doubles should be aligned on 8-bit boundaries.
> >The speculation is that the _num_val part of the UnionVal in the PMC
> >ends up unaligned.  However, I couldn't follow where that happened, so I 
> >can't suggest a patch.
> 
> It happends directly in the PMC memory arena. Whenever the PMC size % 8 
> isn't zero.

That's gotta be a compiler bug.  When a structure contains a member
that needs N-byte alignment, and sizeof(structure) % N is not zero,
the compiler is busted.  (Have they never heard of _arrays_?)
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [perl #36269] Alignment problems with doubles on SPARC.

[Leopold Toetsch]

Andy Dougherty (via RT) wrote:


...  On SPARC, doubles should be aligned on 8-bit boundaries.
The speculation is that the _num_val part of the UnionVal in the PMC
ends up unaligned.  However, I couldn't follow where that happened, so I 
can't suggest a patch.


It happends directly in the PMC memory arena. Whenever the PMC size % 8 
isn't zero. CUrrently we'd need to make the PMC structure bigger by one 
word in that case.


include/parrot/pobj.h:84 - the _pobj_version is not in the structure if 
optimizing.


leo

[perl #36269] Alignment problems with doubles on SPARC.

[via RT]

# New Ticket Created by  Andy Dougherty 
# Please include the string:  [perl #36269]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=36269 >


As discussed in 
http://www.nntp.perl.org/group/perl.perl6.internals/29984
a parrot configured withConfigure.pl --optimize  dumps
core with a bus alignment error on second line in the following simple 
program

set N0, 42.0
set N1, N0
print   N1
print   "\n"
end

on SPARC.  On SPARC, doubles should be aligned on 8-bit boundaries.
The speculation is that the _num_val part of the UnionVal in the PMC
ends up unaligned.  However, I couldn't follow where that happened, so I 
can't suggest a patch.

-- 
Andy Dougherty  [EMAIL PROTECTED]

Re: Attack of the fifty foot register allocator vs. the undead continuation monster

[Autrijus Tang]

On Mon, Jun 13, 2005 at 06:52:35PM +0200, Chip Salzenberg wrote:
> > > Isn't this *exactly* why Perl 6 is requiring you to mark tied
> > > variables when they're declared?
> > 
> > Yes.
> 
> Um:
> 
>my $x is tied;
>tied $x, SomePackage;
>unsuspecting_victim(\$x);   # ???

Hmm, you can't say "is tied"; it must be something that actually
actively implementing the Tieable role (see S06):

my $x is DB_File;

but regardless, the DB_File thing can't invoke a full CC, so this is
orthogonal to the problem we're talking about; sorry.

Thanks,
/Autrijus/


pgpYbgQOB1Hqb.pgp
Description: PGP signature

Re: Attack of the fifty foot register allocator vs. the undead continuation monster

[Chip Salzenberg]

On Tue, Jun 14, 2005 at 12:37:52AM +0800, Autrijus Tang wrote:
> On Mon, Jun 13, 2005 at 09:21:00AM -0700, Brent 'Dax' Royal-Gordon wrote:
> > On 6/13/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > > Oh no ... it's even worse than you think.  Almost *any* opcode that
> > > operates on a PMC can trigger a continuation.  And I only need two
> > > words to prove it:
> > > 
> > > "Tied variables."
> > 
> > Isn't this *exactly* why Perl 6 is requiring you to mark tied
> > variables when they're declared?
> 
> Yes.

Um:

   my $x is tied;
   tied $x, SomePackage;
   unsuspecting_victim(\$x);   # ???

-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: Attack of the fifty foot register allocator vs. the undead continuation monster

[Chip Salzenberg]

On Mon, Jun 13, 2005 at 09:21:00AM -0700, Brent 'Dax' Royal-Gordon wrote:
> On 6/13/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > Oh no ... it's even worse than you think.  Almost *any* opcode that
> > operates on a PMC can trigger a continuation.  And I only need two
> > words to prove it:
> > 
> > "Tied variables."
> 
> Isn't this *exactly* why Perl 6 is requiring you to mark tied
> variables when they're declared?

Well, that doesn't help you in and of itself, unless every reference
that could point to a tied variable was also marked.  And I don't see
it happening.

That said, I was just informed on IRC that it's already established
that once you descend into a PMC vtable entry or anything else in
Parrot that's written in C (or could be), you're not allowed to jump
sideways with a full continuation, but only upward in the style of
an escape continuation (e.g. throwing an exception).

So consider me unpanicked.  About PMCs vs. register allocation,
anyway.  I'm still a bit on edge about this "Perl 6" thingy.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: Attack of the fifty foot register allocator vs. the undead continuation monster

[Autrijus Tang]

On Mon, Jun 13, 2005 at 09:21:00AM -0700, Brent 'Dax' Royal-Gordon wrote:
> On 6/13/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > Oh no ... it's even worse than you think.  Almost *any* opcode that
> > operates on a PMC can trigger a continuation.  And I only need two
> > words to prove it:
> > 
> > "Tied variables."
> 
> Isn't this *exactly* why Perl 6 is requiring you to mark tied
> variables when they're declared?

Yes.   And tied vars invoking full continuations is something that
we can just document out of existence.

Thanks,
/Autrijus/


pgpihHbq4msqs.pgp
Description: PGP signature

Re: Attack of the fifty foot register allocator vs. the undead continuation monster

[Brent 'Dax' Royal-Gordon]

On 6/13/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> Oh no ... it's even worse than you think.  Almost *any* opcode that
> operates on a PMC can trigger a continuation.  And I only need two
> words to prove it:
> 
> "Tied variables."

Isn't this *exactly* why Perl 6 is requiring you to mark tied
variables when they're declared?

In this thread and the other one, I'm seeing a lot of people getting
scared of the degenerate case, which is the most dynamic behavior
possible.  But the degenerate case is rarely the common one, and we
always knew it would come at a speed penalty.  More importantly, the
degenerate case can be ruled out pretty well by a fairly simple
lexical analysis.

In the common case of no tied variables, I think we can assume that
PMC code isn't going to do zany things like invoking some random
continuation.  If there are tied variables present which might do
strange things like that, the compiler should emit a PIR directive
saying "anything goes in this section".  Perhaps some languages will
always do that, but that's the price of working in those languages.

-- 
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker

Re: Attack of the fifty foot register allocator vs. the undead continuation monster

[Chip Salzenberg]

On Sun, Jun 12, 2005 at 09:41:05PM -0700, Bill Coffman wrote:
> Continuations can be taken from within any sub, and possibly even
> when appending to a list, if you're using lazy list eval.

Oh no ... it's even worse than you think.  Almost *any* opcode that
operates on a PMC can trigger a continuation.  And I only need two
words to prove it:

"Tied variables."

Ouch ouch ouch.

Sounds to me like register allocation is effectively dead, and all
that's left is register renumbering.

The only exception (ahem) I can think of is if we start supporting,
and compilers start emitting, continuation resets (i.e. protected
areas that guarantee that continuations won't propagate out; kind of
like the effect of C< eval BLOCK > on Perl's die).  But even then, it
might not be worth the effort just to get a little tiny bit of reuse
out of an effectively infinite register set.

> There are also some issue about changing variables through continuations, 
> like you can only change PMC integers, which point to some fixed location, 
> containing the int, i.e. you can only use references. These parts make less 
> sense to me, but the issue is basically, some registers are restored, and 
> some are kept safe? Well, that issue hasn't been quite resolved either.

I think that's been answered: We don't have to save & restore
anything, because it's all automatically saved by virtue of being in
memory as the state of a *virtual* machine.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Anonymous macros?

[Ingo Blechschmidt]

Hi,

just checking: Are anonymous macros allowed?

  my $macro = macro ($x) { "100$x" };
  say $macro(3); # 1003

Of course, anonymous macros can't be called at compile-time, like normal
macros:
  my $macro = rand < 0.5
?? macro ($x) { "100$x" }
:: macro ($x) { "200$x" };
  say $macro(3); # 1003 or 2003?

But they're still useful if I want to work with $macro references and
store them later, at compile-time, in a &-var:
  my ¯o = BEGIN {
rand < 0.5
  ?? macro ($x) { "100$x" }
  :: macro ($x) { "200$x" };
  };
  say macro 3; # reduced at compile-time to either 1003 or 2003


--Ingo

-- 
Linux, the choice of a GNU | The computer revolution is over. The
generation on a dual AMD   | computers won. -- Eduard Bloch <[EMAIL PROTECTED]>
Athlon!| 

Re: Parrot and features (was Re: [RELEASE] Pugs 6.2.7 is released!)

[Autrijus Tang]

On Mon, Jun 13, 2005 at 10:32:05AM -0400, Rob Kinyon wrote:
> > That statement talks about Parrot.  As soon as Pugs targets Parrot --
> > which is what I'm working on right now -- you can run cross-compiled
> > Perl 6 program s on PocketPC.
> 
> Question: Given that Parrot isn't complete, will there be a time where
> certain Pugs features are available when targeting GHC, but not when
> targeting Parrot?

Sure.  Currently, like, almost all of them.

It is my hope this week to make sure that all GHC runtime primitives we
use in Pugs can be expressed, or at least emulated, in Parrot; if not 
directly, then at least available as libraries with a well-defined
interface.

Thanks,
/Autrijus/


pgpRIT1rnM2wF.pgp
Description: PGP signature

BEGIN {...} and IO

[Ingo Blechschmidt]

Hi,

  # No problem:
  my $data = BEGIN {
my $fh = open "some_file" err...;
=$fh;
  };

  # Problem;
  my $fh = BEGIN { open "some_file" err... };
  # Compile-time filehandle leaked into runtime!
  say =$fh;

In Perl 5, this wasn't a problem, as compilation and execution happended
(most of the time) in the same process.

But in Perl 6, compilation and execution can happen in different
processes or even on different computers, so probably the snippet
should raise an error, preferably at compile-time.

My real question: How do I raise an error if objects of my own classes
leak into runtime? I.e.:
  # This should work:
  my $foo = BEGIN { MyClass.new.get_some_value };

  # But this shouldn't:
  my $foo = BEGIN { MyClass.new }.get_some_value;

I can see some possibly answers:

* There should be some bool $?COMPILING:

  class MyClass {
has Bool $.created_at_compile_time;

submethod BUILD () {
  $.created_at_compile_time = $?COMPILING;
}

method get_some_value () {
  if $.created_at_compile_time and not $?COMPILING {
die "...";
  } else {
...;
  }
}
  }

  Pro: Great flexibility (maybe there're two methods, from which only
   one has the restriction that the object may not leak into
   runtime).
  But: The compiler can't check at compile-time if leaking into
   runtime is allowed.

* There should be a special role:

  class MyClass does dont_leak_into_runtime {
method get_some_value () {...}
  }

  Pro: The compiler can check at compile-time if leakinto into runtime
   is allowed.
  But: You don't have as much flexibility as with $?COMPILING.

* There's a boolean property may_leak_into_runtime every object has,
  with a default of true.
  BEGIN and CHECK then check if the object they're about to return has
  .may_leak_into_runtime set to false -- if that's the case, die:

  class MyClass does may_leak_into_runtime(false) {
method get_some_value () {...}
  }

  my $foo = BEGIN { MyClass.new }.get_some_value; # really means
  my $foo = BEGIN {
my $result = MyClass.new;
$result.may_leak_into_runtime ?? $result :: die "...";
  }.get_some_value;

  Pro: Great flexibility, easy to use


FWIW, I like #3 the best.


--Ingo

-- 
Linux, the choice of a GNU | Perfection is reached, not when there is no
generation on a dual AMD   | longer anything to add, but when there is
Athlon!| no longer anything to take away.   

Parrot and features (was Re: [RELEASE] Pugs 6.2.7 is released!)

[Rob Kinyon]

> That statement talks about Parrot.  As soon as Pugs targets Parrot --
> which is what I'm working on right now -- you can run cross-compiled
> Perl 6 program s on PocketPC.

Question: Given that Parrot isn't complete, will there be a time where
certain Pugs features are available when targeting GHC, but not when
targeting Parrot?

Rob

Re: [RELEASE] Pugs 6.2.7 is released!

[vadim]

В Пнд, 13.06.2005, в 09:23, Autrijus Tang пишет:
> On Mon, Jun 13, 2005 at 05:18:38PM -0400, vadim wrote:
> > interesting read, thank you a lot. But few questions however. A
> > following page:
> > http://pugscode.org/talks/apw/slide14b.html#end
> > 
> > states that "Faster: JIT compiled; run in embedded machines"
> > Is it ever possible to run pugs on PocketPC?
> > Or I misunderstand point of statement?
> 
> That statement talks about Parrot.  As soon as Pugs targets Parrot --
> which is what I'm working on right now -- you can run cross-compiled
> Perl 6 program s on PocketPC.

I suspect "parrot" is not possible on PocketPC.
In order to do this some efforts should be made.
As a starting point, perl5 on PocketPC is possible.

Does parrot supports any cross-compiling, right now?

Vadim.

Re: [RELEASE] Pugs 6.2.7 is released!

[Autrijus Tang]

On Mon, Jun 13, 2005 at 05:18:38PM -0400, vadim wrote:
> interesting read, thank you a lot. But few questions however. A
> following page:
> http://pugscode.org/talks/apw/slide14b.html#end
> 
> states that "Faster: JIT compiled; run in embedded machines"
> Is it ever possible to run pugs on PocketPC?
> Or I misunderstand point of statement?

That statement talks about Parrot.  As soon as Pugs targets Parrot --
which is what I'm working on right now -- you can run cross-compiled
Perl 6 program s on PocketPC.

> Another item on this page "Friendlier: Call Perl5/C/Tcl/Python libraries
> directly" -- how do I link with tcl libraries?

Again, through Parrot.

Thanks,
/Autrijus/


pgpRD22DEz8zS.pgp
Description: PGP signature

Re: [RELEASE] Pugs 6.2.7 is released!

[vadim]

...

> Most of this release's development happened without my direct input,
> since I was busily writing a talk and a paper about Pugs:
> 
> http://pugscode.org/talks/apw/slide1.html

interesting read, thank you a lot. But few questions however. A
following page:
http://pugscode.org/talks/apw/slide14b.html#end

states that "Faster: JIT compiled; run in embedded machines"
Is it ever possible to run pugs on PocketPC?
Or I misunderstand point of statement?

I have perl5 and HUGS working on my PocketPC, but have no chance running
GHC there...


Another item on this page "Friendlier: Call Perl5/C/Tcl/Python libraries
directly" -- how do I link with tcl libraries?

Vadim.

Re: Optimisations (was Re: How much do we close over?)

[Luke Palmer]

On 6/13/05, Paul Johnson <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 13, 2005 at 11:24:07AM +, Luke Palmer wrote:
> >Back when I wrote an
> > back-chaining system in perl, I used tied variables in order to
> > determine when I needed to solve for something.  A standard idiom was:
> >
> > rule \$var, sub {
> > $a and $b and $c;
> > $var = 1;
> > };
> >
> > And damnit, $c would never be solved for, because it was optimized
> > away by Perl.
> 
> I'm not sure that short circuiting operators can be called an
> optimisation.  Aren't they more part of the language definition?  I
> assume Perl 6 isn't doing away with short circuiting operators.

Oh, sorry, I was unclear.  Perl 6 will not do away with
short-circuiting operators, of course.  I meant that if $a and $b both
ended up being true, $c still would not be evaluated, because Perl
determined that I wasn't doing anything with the value once it was
returned.

> > To sum up, optimizations are nice, and it's nice to have optimizations
> > on by default for PR reasons, but you have to be able to turn them
> > off.
> 
> One of the things that has been on the Perl 5 wishlist for a while is a
> way to turn off the optimisations, but really that would only be for the
> benefit of people and modules that mess with the op tree.  Again, I
> submit that an optimisation that changes normal behaviour is broken and
> that, in general, programmers shouldn't need to worry about what
> optimisations are going on under the covers.

Yeah, but in a language with 'eval', and otherwise as dynamic as (or
moreso than) Perl 5, optimizations that don't change *somebody's*
semantics are hard to come by.  Most optimizations give you speed
benefit at the loss of some flexibility.  For instance, early binding,
which can have quite large benefits, but disables redefinition at
runtime.

Luke

Re: [RELEASE] Pugs 6.2.6 is released!

[Ingo Blechschmidt]

Hi, 
 
Autrijus Tang  autrijus.org> writes: 
> I'm happy to announce Pugs 6.2.7, with much improved parser speed and 
> error reporting, as well as rudimentary (source filter style) macro  
> support: 
 
and, as usual, here's the Subversion revision graph, showing 
the growth of the number of commits and commiters: 
  http://linide.sourceforge.net/pugs-svngraph-6.2.7.png 
 
The minimalistic Pugs Live CD was updated to contain the new 
Pugs 6.2.7 and latest Parrot: 
  http://linide.sourceforge.net/pugs-livecd-6.2.7.iso 
 
 
--Ingo 
 
--  
Linux, the choice of a GNU | Black holes result when God divides the 
generation on a dual AMD   | universe by zero.   
Athlon!|  

[RELEASE] Pugs 6.2.7 is released!

[Autrijus Tang]

(Sorry. Wrong subject last time...)

I'm happy to announce Pugs 6.2.7, with much improved parser speed and
error reporting, as well as rudimentary (source filter style) macro 
support:

http://pugscode.org/dist/Perl6-Pugs-6.2.7.tar.gz
SIZE = 1157780
SHA1 = fc8d80c05a5c896693e395f830d10e85a62f2747

Most of this release's development happened without my direct input,
since I was busily writing a talk and a paper about Pugs:

http://pugscode.org/talks/apw/slide1.html
http://perlcabal.org/~autrijus/hw2005.pdf

I sincerely recommend both of them to people interested in Pugs.
Taken together, they cover most of what Pugs Apocryphon 2's scope,
and corrects many outdated and incorrect sections in Pugs Apocryphon 1.

My focus for 6.2.8 is compiling Pugs to Parrot.  With Leo and Chip's
help, I hope to release it before the YAPC::NA hackathon.

Again, thanks to all lambdacamels for making this release possible.

Enjoy,
/Autrijus/

== Changes for 6.2.7 (r4612) - June 13, 2005

=== Pugs Internals

* Add `::?CLASS`, `::?ROLE`, and `::?PACKAGE` magicals
* Allow bypassing the Standard Prelude by setting `$ENV`
* Experimental heredoc support via `qq:to/END/ ... END`
* Implement `is required` for subroutine parameters
* New builtins: `caller`, `Carp::longmess`, `Scalar::as`
* Obsolete the old `open` builtin in favor of Prelude's `File::open()`
* Rudimentary, source-filter-like macro support added
* Speed up parsing for 2x by caching dynamic grammar rules
* Support for lvalue `substr()`
* `:coerce` and other A12 catgories are parsed in sub names
* `is unsafe` trait to mark subs unavailable in safe mode
* `method foo ($.x) {}` now sets `$.x`
* `undef($x)` is now spelled `undefine($x)`

=== Bundled Modules

* New modules added:
** `FindBin`
** `File::Find`
** `HTTP::Message`
** `POE` (experimental)
** `URI::Escape`
* Extended tests for `Tree`

=== Tests, Examples and Documentations

* APW talk: "Apocalypse Now" in `docs/talks/Apocalypse_Now.spork`
* APW talk: "Eine Einfuehrung in Perl 6" in `docs/talks/perl6-apw2005/`
* Documentation of how to execute Pugs in `lib/pugs/run.pod`
* Examples of writing nested loops in `examples/nested_loops`
* Haskell Workshop paper on Pugs in `docs/talks/hw2005.tex`
* Overview of Pugs source tree in `lib/pugs/hack.pod`
* Overview of Rules bootstrapping plan in `/docs/other/rules_bootstrap`
* Some new test and several tests refactored, we now have 7600+ tests
* Unit manipulation and converstions examples in `units.p6`
* `examples/algorithms` subdir now unifies algorithmics examples

=== Bug Fixes

* '\' protects delimiters in rules
* Chained comparisons now work again (were broken in 6.2.6)
* Critical evals (`use`, `require`, `prelude`) now raise parsefail exceptions
* Fix `[].method` and `{}.method` to call `Array::method` and `Hash::method`
* Fixed `~{1=>2}` to stringify to `"1\t2\n"` correctly   
* Parse errors inside blocks are now reported on the occuring position
* Parse for array and hash captures in rules
* `Test::is()` now shows the expected result correctly again
* `module Foo {...}` now parses correctly


pgprUoMEugGzQ.pgp
Description: PGP signature

[RELEASE] Pugs 6.2.6 is released!

[Autrijus Tang]

I'm happy to announce Pugs 6.2.7, with much improved parser speed and
error reporting, as well as rudimentary (source filter style) macro 
support:

http://pugscode.org/dist/Perl6-Pugs-6.2.7.tar.gz
SIZE = 1157780
SHA1 = fc8d80c05a5c896693e395f830d10e85a62f2747

Most of this release's development happened without my direct input,
since I was busily writing a talk and a paper about Pugs:

http://pugscode.org/talks/apw/slide1.html
http://perlcabal.org/~autrijus/hw2005.pdf

I sincerely recommend both of them to people interested in Pugs.
Taken together, they cover most of what Pugs Apocryphon 2's scope,
and corrects many outdated and incorrect sections in Pugs Apocryphon 1.

My focus for 6.2.8 is compiling Pugs to Parrot.  With Leo and Chip's
help, I hope to release it before the YAPC::NA hackathon.

Again, thanks to all lambdacamels for making this release possible.

Enjoy,
/Autrijus/

== Changes for 6.2.7 (r4612) - June 13, 2005

=== Pugs Internals

* Add `::?CLASS`, `::?ROLE`, and `::?PACKAGE` magicals
* Allow bypassing the Standard Prelude by setting `$ENV`
* Experimental heredoc support via `qq:to/END/ ... END`
* Implement `is required` for subroutine parameters
* New builtins: `caller`, `Carp::longmess`, `Scalar::as`
* Obsolete the old `open` builtin in favor of Prelude's `File::open()`
* Rudimentary, source-filter-like macro support added
* Speed up parsing for 2x by caching dynamic grammar rules
* Support for lvalue `substr()`
* `:coerce` and other A12 catgories are parsed in sub names
* `is unsafe` trait to mark subs unavailable in safe mode
* `method foo ($.x) {}` now sets `$.x`
* `undef($x)` is now spelled `undefine($x)`

=== Bundled Modules

* New modules added:
** `FindBin`
** `File::Find`
** `HTTP::Message`
** `POE` (experimental)
** `URI::Escape`
* Extended tests for `Tree`

=== Tests, Examples and Documentations

* APW talk: "Apocalypse Now" in `docs/talks/Apocalypse_Now.spork`
* APW talk: "Eine Einfuehrung in Perl 6" in `docs/talks/perl6-apw2005/`
* Documentation of how to execute Pugs in `lib/pugs/run.pod`
* Examples of writing nested loops in `examples/nested_loops`
* Haskell Workshop paper on Pugs in `docs/talks/hw2005.tex`
* Overview of Pugs source tree in `lib/pugs/hack.pod`
* Overview of Rules bootstrapping plan in `/docs/other/rules_bootstrap`
* Some new test and several tests refactored, we now have 7600+ tests
* Unit manipulation and converstions examples in `units.p6`
* `examples/algorithms` subdir now unifies algorithmics examples

=== Bug Fixes

* '\' protects delimiters in rules
* Chained comparisons now work again (were broken in 6.2.6)
* Critical evals (`use`, `require`, `prelude`) now raise parsefail exceptions
* Fix `[].method` and `{}.method` to call `Array::method` and `Hash::method`
* Fixed `~{1=>2}` to stringify to `"1\t2\n"` correctly   
* Parse errors inside blocks are now reported on the occuring position
* Parse for array and hash captures in rules
* `Test::is()` now shows the expected result correctly again
* `module Foo {...}` now parses correctly


pgpaTYPVzLs3x.pgp
Description: PGP signature

Optimisations (was Re: How much do we close over?)

[Paul Johnson]

On Mon, Jun 13, 2005 at 11:24:07AM +, Luke Palmer wrote:

> I just have to say that it's really annoying running into
> optimizations when I don't want them.

Isn't the whole point of optimisations that you shouldn't have to worry
about whether you hit one or not, otherwise the optimisation would seem
to be broken.

>Back when I wrote an
> back-chaining system in perl, I used tied variables in order to
> determine when I needed to solve for something.  A standard idiom was:
> 
> rule \$var, sub {
> $a and $b and $c;
> $var = 1;
> };
> 
> And damnit, $c would never be solved for, because it was optimized
> away by Perl.

I'm not sure that short circuiting operators can be called an
optimisation.  Aren't they more part of the language definition?  I
assume Perl 6 isn't doing away with short circuiting operators.

>I ran into that problem rather quickly, and I knew a
> "no optimizations" would do the trick, if it existed.  But no such
> luck, so I always had to add an "and 1" on the end.  Funny thing is,
> that should have been optimized away too, but it wasn't, because Perl
> wasn't that good at optimizations.  So now I have to know about the
> capabilities of the language I'm using in order to program.

I'm not sure about the premise, but I agree with the conclusion.

> To sum up, optimizations are nice, and it's nice to have optimizations
> on by default for PR reasons, but you have to be able to turn them
> off.

One of the things that has been on the Perl 5 wishlist for a while is a
way to turn off the optimisations, but really that would only be for the
benefit of people and modules that mess with the op tree.  Again, I
submit that an optimisation that changes normal behaviour is broken and
that, in general, programmers shouldn't need to worry about what
optimisations are going on under the covers.

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

Re: How much do we close over?

[Luke Palmer]

On 6/12/05, Piers Cawley <[EMAIL PROTECTED]> wrote:
> Chip and I have been having a discussion. I want to write:
> 
> sub foo { my $x = 1; return sub { eval $^codestring } }
> say foo()("$x");
> 
> I claim that that should print 1. Chip claims it should throw a warning about
> because of timely destruction. My claim is that a closure should close over 
> the
> entire lexical stack, and not simply those things it uses statically. Chip
> claims the opposite, arguing that timely destruction implies that this is
> absolutely the right thing to do. It's also quicker.

I just have to say that it's really annoying running into
optimizations when I don't want them.  Back when I wrote an
back-chaining system in perl, I used tied variables in order to
determine when I needed to solve for something.  A standard idiom was:

rule \$var, sub {
$a and $b and $c;
$var = 1;
};

And damnit, $c would never be solved for, because it was optimized
away by Perl.  I ran into that problem rather quickly, and I knew a
"no optimizations" would do the trick, if it existed.  But no such
luck, so I always had to add an "and 1" on the end.  Funny thing is,
that should have been optimized away too, but it wasn't, because Perl
wasn't that good at optimizations.  So now I have to know about the
capabilities of the language I'm using in order to program.

I ran into a related problem when I was writing Class::Closure, that
dealt with freeing lexical variables when they weren't used anymore. 
But I was closing over lexicals as my member variables, so things were
getting destroyed much too early.

To sum up, optimizations are nice, and it's nice to have optimizations
on by default for PR reasons, but you have to be able to turn them
off.

And yes, you could mark "eval" as "lexically dirty" so that you
wouldn't optimize when there's one in sight.  But that solution is
quite pessimistic, as you would have to mark every late-bound sub call
as dirty too, given caller introspection.

Luke

Re: Attack of the fifty foot register allocator vs. the undead continuation monster

[Nicholas Clark]

On Sun, Jun 12, 2005 at 03:03:24PM -0400, Matt Fowles wrote:

> 3) Chip is right, Piers is right. The two of you have are working from
> a different base set of definitions/axioms or misunderstood each other
> in some other way.

Historically, (pre Perl 6 actually) I think that this scenario was the
biggest cause of arguments on perl5-porters.

It's an important one for people to be able to recognise.

Nicholas Clark

[perl #36266] [BUG] perldoc -d

[via RT]

# New Ticket Created by  Leopold Toetsch 
# Please include the string:  [perl #36266]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=36266 >


perldoc -ud packfile-c.pod ../src/packfile.c
Unknow option -d

leo

Re: How much do we close over?

[Piers Cawley]

Rod Adams <[EMAIL PROTECTED]> writes:

> Piers Cawley wrote:
>
>>Chip and I have been having a discussion. I want to write:
>>
>>sub foo { my $x = 1; return sub { eval $^codestring } }
>>say foo()("$x");
>>
>>I claim that that should print 1. Chip claims it should throw a warning about
>>because of timely destruction. My claim is that a closure should close over 
>>the
>>entire lexical stack, and not simply those things it uses statically. Chip
>>claims the opposite, arguing that timely destruction implies that this is
>>absolutely the right thing to do. It's also quicker.
>>  
>>
> I'm going to have to side with Piers on this one. My feeling is that having a
> reference to a closure accessible in memory should keep all the possible
> lexicals it can access in memory as well. That said, I can the compiler
> optimizing memory consumption by destroying all the outer lexicals that it can
> prove will never be used by the inner closure. However, the presence of an
> eval' in the closure makes such a proof tenuous at best.
>
> On the other hand, one could easily view the eval as constructing yet another
> closure, and it's unclear if we wish for that closure to be able to "skip" the
> first level outer closure to directly access the 2nd level outer lexicals. In
> that respect, I could see things Chip's way.
>
> As for the warning, it should only be a warning if strictures are on, for 
> using
> the now undeclared '$x' inside the eval.
>
>>But dammit, I'm doing runtime evaluation of code strings, I don't care about
>>quicker.
>>
>>If it's not the default can it please be mandated that there be some way of
>>doing:
>>
>>sub foo { my $x = 1; return sub is lexically_greedy {eval $^codestring} }
>>
>>in other words, some way of declaring that a subroutine wants to hang onto
>>every lexical it can see in its lexical stack, not matter what static analysis
>>may say.
>>
>>  
>>
> Well, you could always do something like:
>
> sub foo { my $x = 1; return sub {my $x := $OUTER::x; eval $^codestring} }
>
> But I'm spending too much time in other languages lately to remember exactly
> how "$OUTER::x" is spelled for certain. One could probably even write a macro
> that auto-binds all the lexicals in the outer scope to the current scope.

Only if I actually know what variables which were within scope when that inner
sub was compiled are going to be used by my passed in code string. I really
don't want to have to write a macro to walk the OUTER:: chain in order to build
a something like:

   sub { my $foo = $OUTER::foo;
 my $bar = $OUTER::OUTER::bar;
 ...;
 eval $^codestring }

Just to pull everything into scope.

And even if I could do that, what I actually want to be able to do is something
like this:

$continuation.bindings.eval_in_this_scope($^codestring);

Which can be done today in Ruby and which is one of the enabling technologies
for tools like Rails.

Re: How much do we close over?

[Piers Cawley]

Rob Kinyon <[EMAIL PROTECTED]> writes:

>> Piers Cawley said:
>> in other words, some way of declaring that a subroutine wants to hang onto
>> every lexical it can see in its lexical stack, not matter what static 
>> analysis
>> may say.
>
> I'm not arguing with the idea, in general. I just want to point out
> that this implies that you're going to hold onto every single
> file-scoped lexical, leading to quite a bit of action-at-a-distance.

Well, duh. If eval string isn't a hearty pointer to the "This subroutine
deliberately takes advantage of action at a distance" then I don't know what
is.


> Maybe, instead, you should say "sub is lexical_stack(N)" where N is
> the number of scoping levels it will hold onto in addition to any
> lexical it actually refers to. I would have 0 be the innermost scope,
> 1 be the enclosing scope, etc.

Which is all very well, but you don't necessarily know how deep in the stack
you are. I want to be able to write something in such a way that evalling the
string works in exactly the same way as it would if I had just written a do
block in the first place.

sub foo { my $x; ...; return sub { do {...} } }

It's an introspection thing. Most of the time you don't want it, but sometimes
you do and we really shouldn't be making that impossible.