Re: pdd17pmc branch review

[chromatic]

On Friday 07 March 2008 19:24:53 Bob Rogers wrote:

>From: "Will Coleda" <[EMAIL PROTECTED]>
>Date: Tue, 4 Mar 2008 19:48:09 -0500
>
>I wanted to call attention to part of today's Parrot Sketch:
>
> - Otherwise, the PMC branch is ready for language testing,
>will plan to merge it back into trunk next weekend.
>
> Using pdd17pmc, Kea-CL passes all tests (after s/DYNSELF/SELF/g, of
> course), with no regression on either of the memory bugs reported
> recently.

Let it be known that Kea-CL gets the Official chromatic Seal of Much Approval!

-- c

Character sets PDD ready for review

[Simon Cozens]

Hi folks,
	I think I've finished doing what I can with 
docs/pdds/draft/pdd28_character_sets.pod for the time being.
	Please have a look at it, and let me know if there's anything wrong, 
anything unclear, anything missing or anything objectionable about it. 
Character set and encoding support is an absolute nightmare to get 
right, but I feel the stuff in this PDD gives us a good basis to work from.
	If there's no major problems with it, I'll pass it on to Allison for 
editing.


Simon

--
"If that makes any sense to you, you have a big problem."
-- C. Durance, Computer Science 234

Re: pdd17pmc branch review

[Klaas-Jan Stol]

Hi,

I'm on win32 xp pro, msvc express

Punie, Pynie, ecmascript are passing tests.

(c99 does not, but that's not different from trunk.)

kjs

On Wed, Mar 5, 2008 at 1:48 AM, Will Coleda <[EMAIL PROTECTED]> wrote:
> I wanted to call attention to part of today's Parrot Sketch:
>
>   - Otherwise, the PMC branch is ready for language testing,
>  will plan to merge it back into trunk next weekend.
>
>  So, language developers (and others); please grab a copy of
>  https://svn.perl.org/parrot/branches/pdd17pmc and check out the
>  languages to see how they fare compared to their counterparts in
>  trunk.
>
>  Thanks!
>
>  --
>  Will "Coke" Coleda
>

Parrot at YAPC::NA::2008 in Chicago June 16-18

[James E Keenan]

A couple of points about YAPC:

1.  It's almost two weeks earlier this year than it has been in the past 
three years.  So if your mental clock has been set to "3 days of YAPC + 
2 days of hackathon + 3-day 4th-of-July weekend" (as mine has), please 
reset it whenever you (or, at least, those of you in NA) set your clocks 
ahead this weekend.


2.  Consequentially, the deadline for submissions is earlier this year. 
 In fact, it's just 7 days away:  Saturday, March 15.  So what 
Parrot-related submissions do we have?


3.  YAPC is trying out a new format for some time slots this year.  Josh 
McAdams writes on use.perl.org:


"This year we are also planning on introducing more hands-on 
workshop-style tracks to the conference. These sessions will typically 
be a little longer than a normal presentation and will be much more 
informal. During the workshops, conference attendees will be able to 
interact with presenters to actually do things like compile Parrot or 
create a hello world program in Perl 6. If you are involved in a project 
and would like to host a workshop, please contact Josh McAdams directly 
at joshua dot mcadams at gmail dot com."


So, we've been all but commissioned to do a presentation in this 
workshop format.  My hunch is that if we can get participants to get to 
Hello World in Perl 6 and some other languages, we'll be much 
appreciated.  We could also lead people through the mechanics of 
downloading Parrot via tarball or SVN and building it.  If we could 
encourage people to bring laptops loaded with OSes that normally don't 
get much attention, we could get some instant feedback about what's working.


Who would like to work on something like this?

kid51

Scheduler, Timer and DOD

[Ron Blaschke]

Hi,

I've been looking into a failure of F on Windows, 
but I don't think the problem is limited to that platform.


$ prove t\dynoplibs\myops.t
t\dynoplibs\myops..5/10
t\dynoplibs\myops..6/10 #   Failed test 'three alarm'
#   at t\dynoplibs\myops.t line 118.
# Exited with error code: 255
# Received:
# alarm1
# alarm2
# alarm3
#
# Expected:
# /alarm1
# alarm2
# alarm3/
#

The test output is good, but the error code is 255.  Actually, the test 
exits with an access violation.


After stepping through things a couple of times with a debugger I think 
the cause for this is that through the final DOD run (Parrot_exit -> 
Parrot_really_destroy -> Parrot_do_dod_run) the scheduler is destroyed 
*before* the last task.


When the task is finally destroyed, the scheduler is already 0xdeadbeef. 
 Here's the final stack trace.


Parrot_cx_delete_task
Parrot_Timer_destroy
Parrot_dod_free_pmc
Parrot_dod_sweep
Parrot_dod_ms_run
Parrot_do_dod_run
Parrot_really_destroy
Parrot_exit

At this line in Parrot_cx_delete_task.

VTABLE_delete_keyed_int(interp, interp->scheduler, tid);


That's as far as I got.  I don't know enough about the DOD details to 
make a good guess on the cause.  Maybe both scheduler and task are 
determined to be not-reachable, but the destruction sequence is not ordered?


Ron

Re: Scheduler, Timer and DOD

[James E Keenan]

Ron Blaschke wrote:

Hi,

I've been looking into a failure of F on Windows, 
but I don't think the problem is limited to that platform.


$ prove t\dynoplibs\myops.t
t\dynoplibs\myops..5/10
t\dynoplibs\myops..6/10 #   Failed test 'three alarm'
#   at t\dynoplibs\myops.t line 118.
# Exited with error code: 255


A friend on Win32 reported a failure in this test on March 1, but the 
only output presented was:


t/dynoplibs/myops.t(Wstat: 256 Tests: 10 Failed: 1)
  Failed test:  5
  Non-zero exit status: 1


I was unable to reproduce the error on either Darwin or Linux.


kid51

[perl #50920] [BUG]: t/compilers/imcc/syn/macro.t failing

[James Keenan via RT]

rblasch has marked this test as TODO as of r26267.  So the file as a
whole is passing (and, at least on Linux, make test is passing), but the
underlying problem is not solved.

Re: Scheduler, Timer and DOD

[chromatic]

On Saturday 08 March 2008 07:31:08 Ron Blaschke wrote:

> I've been looking into a failure of F on Windows,
> but I don't think the problem is limited to that platform.
>
> $ prove t\dynoplibs\myops.t
> t\dynoplibs\myops..5/10
> t\dynoplibs\myops..6/10 #   Failed test 'three alarm'
> #   at t\dynoplibs\myops.t line 118.
> # Exited with error code: 255
> # Received:
> # alarm1
> # alarm2
> # alarm3
> #
> # Expected:
> # /alarm1
> # alarm2
> # alarm3/
> #
>
> The test output is good, but the error code is 255.  Actually, the test
> exits with an access violation.
>
> After stepping through things a couple of times with a debugger I think
> the cause for this is that through the final DOD run (Parrot_exit ->
> Parrot_really_destroy -> Parrot_do_dod_run) the scheduler is destroyed
> *before* the last task.
>
> When the task is finally destroyed, the scheduler is already 0xdeadbeef.
>   Here's the final stack trace.
>
> Parrot_cx_delete_task
> Parrot_Timer_destroy
> Parrot_dod_free_pmc
> Parrot_dod_sweep
> Parrot_dod_ms_run
> Parrot_do_dod_run
> Parrot_really_destroy
> Parrot_exit
>
> At this line in Parrot_cx_delete_task.
>
>  VTABLE_delete_keyed_int(interp, interp->scheduler, tid);
>
>
> That's as far as I got.  I don't know enough about the DOD details to
> make a good guess on the cause.  Maybe both scheduler and task are
> determined to be not-reachable, but the destruction sequence is not
> ordered?

The destruction sequence is not ordered, so if a task happens to have a PMC 
header created prior to the scheduler's PMC header, then this problem will 
occur.  (We reuse PMC headers, so this can happen in not-easily-deterministic 
ways.)

Making the scheduler a constant PMC would likely fix this, but then anything 
to which the scheduler points also has to be constant.

It might be possible to finish the scheduled tasks prior to destroying all 
PMCs.

-- c

Re: [perl #51478] PDD17PMC : argument doesn't array

[chromatic]

On Thursday 06 March 2008 06:22:21 Will Coleda wrote:

> in PDD17, the following program (which prints "b\n" in trunk), dies:
>
> $ ../../parrot tcl.pbc -e "puts [concat {expand}[lindex {a b} 1]]"
> argument doesn't array.

Ha.  The problem's not Parrot (as far as I can tell) but Tcl.  {a b} is a 
two-element list, right?

Take t/cmd_expr.t, which sets a variable named TODO:

set TODO {TODO "correct precision"}

# math functions, happy path
is [expr abs(-1)]   1
is [expr abs(1)]1
is [expr abs(1.0)]  1.0
is [expr abs(-1.0)] 1.0
is [expr acos(0)]   1.5707963267948966 {} $TODO
is [expr asin(1)]   1.5707963267948966 {} $TODO

The acos() and asin() tests cause an abort in Parrot, with the "argument 
doesn't array" message.  This makes sense; is() expects that the fourth 
argument is a two-element list:

proc is {value expected {description ""} {special {}}}  {

However, if you dump this code to PIR, you'll see:

   $P102 = new 'TclString'
assign $P102, "TODO"
$P103 = new 'TclString'
assign $P103, "TODO \"correct precision\""
  if epoch != 0 goto dynamic_109
  .local pmc a_varName_108
a_varName_108 = $P102
  .local pmc a_newValue_108
a_newValue_108 = $P103
.local pmc temp

  if null a_newValue_108 goto read_var_108

  .local pmc set_108
  set_108 = get_root_global ['_tcl'], '__set'
  $P104 = set_108(a_varName_108, a_newValue_108)

... which indicates to me that TODO gets stored as a string, not a list.

-- c

Re: pdd17pmc branch review

[Allison Randal]

chromatic wrote:



... I have to ask, if we switched to METHOD instead of PCCMETHOD, why
do we have PCCRETURN instead of RETURN? =-)


Hysterical raisins, as far as I know.


Largely because I forgot to mention PCCRETURN in that step of the 
migration plan. Committed fix in r26268.


Allison

Re: pdd17pmc branch review

[Bob Rogers]

   From: chromatic <[EMAIL PROTECTED]>
   Date: Sat, 8 Mar 2008 01:03:12 -0800

   On Friday 07 March 2008 19:24:53 Bob Rogers wrote:

   > Using pdd17pmc, Kea-CL passes all tests (after s/DYNSELF/SELF/g, of
   > course), with no regression on either of the memory bugs reported
   > recently.

   Let it be known that Kea-CL gets the Official chromatic Seal of Much
   Approval!

   -- c

Thanks!  Does that come with a check?  If so, I should be sure to
deposit it before you see my next GC bug report . . .  ;-}

-- Bob

Re: [perl #51478] PDD17PMC : argument doesn't array

[Will Coleda]

On Sat, Mar 8, 2008 at 2:59 PM, chromatic <[EMAIL PROTECTED]> wrote:
> On Thursday 06 March 2008 06:22:21 Will Coleda wrote:
>
>
> > in PDD17, the following program (which prints "b\n" in trunk), dies:
>  >
>  > $ ../../parrot tcl.pbc -e "puts [concat {expand}[lindex {a b} 1]]"
>  > argument doesn't array.
>
>  Ha.  The problem's not Parrot (as far as I can tell) but Tcl.  {a b} is a
>  two-element list, right?

No. {a b} is a string with no interpolation done.

>
>  Take t/cmd_expr.t, which sets a variable named TODO:
>
>  set TODO {TODO "correct precision"}
>
>  # math functions, happy path
>  is [expr abs(-1)]   1
>  is [expr abs(1)]1
>  is [expr abs(1.0)]  1.0
>  is [expr abs(-1.0)] 1.0
>  is [expr acos(0)]   1.5707963267948966 {} $TODO
>  is [expr asin(1)]   1.5707963267948966 {} $TODO
>
>  The acos() and asin() tests cause an abort in Parrot, with the "argument
>  doesn't array" message.  This makes sense; is() expects that the fourth
>  argument is a two-element list:
>
>  proc is {value expected {description ""} {special {}}}  {

This syntax means that is takes four arguments. the last two,
description and special, both have default values, which are both the
empty string, but are confusingly specified as "" and {}. (like using
'' and "" in perl}

When we say [llength $special] in the body of is, this takes the PMC
argument (variable named special), and calls the builtin converter
'__list' on it. List converts the PMC in place to a list if possible,
and with the string {a b}, that converts to a two element list, as
expected: but this isn't done at compile time.

>  However, if you dump this code to PIR, you'll see:
>
>$P102 = new 'TclString'
> assign $P102, "TODO"
> $P103 = new 'TclString'
> assign $P103, "TODO \"correct precision\""
>   if epoch != 0 goto dynamic_109
>   .local pmc a_varName_108
>  a_varName_108 = $P102
>   .local pmc a_newValue_108
>  a_newValue_108 = $P103
>  .local pmc temp
>
>   if null a_newValue_108 goto read_var_108
>
>   .local pmc set_108
>   set_108 = get_root_global ['_tcl'], '__set'
>   $P104 = set_108(a_varName_108, a_newValue_108)
>
>  ... which indicates to me that TODO gets stored as a string, not a list.

Yes, exactly right.

>  -- c

-- 
Will "Coke" Coleda

Re: [perl #51478] PDD17PMC : argument doesn't array

[Will Coleda]

On Thu, Mar 6, 2008 at 3:03 PM, chromatic <[EMAIL PROTECTED]> wrote:
> On Thursday 06 March 2008 11:47:41 Will Coleda wrote:
>
>  > Sure. Take the original:
>  > >  > $ ../../parrot tcl.pbc -e "puts [concat {expand}[lindex {a b} 1]]"
>  >
>  > and just tack a --pir on the end: I verified that saving that out to a
>  > .pir file and running *that* through parrot generates the same error.
>
>  Okay, here's what I've found.  The attached PIR file runs fine on trunk, but
>  fails in the branch.  The problem comes at line 36, where the code calls
>  &concat on a TclConst, attempting to flatten it.
>
>  The TclConst comes from a previous __list call.  I don't know enough about 
> the
>  details of Tcl right now to see if there's some different kind of PMC
>  returned from trunk/branch, but does this help at all?
>
>  If you can tell me what seems to be different, I can check the C code.
>
>  -- c
>

This seems to behave identically (except for being able to array) in
trunk, sorry.

-- 
Will "Coke" Coleda