I Blame .HLL and PBC (Fixing Tcl)

[chromatic]

I've just convinced myself that Tcl's problem is an interaction with the .HLL 
directive and PBC.  That is to say, the assumption that you can freeze PMC 
Subs and thaw them in a different process is broken.

Why?

Subs may have an association with a HLL.  Right now, that's an integer--the 
unique identifier of that HLL: PMC_sub(sub)->HLL_id.

Where does that integer come from?  It's in src/hll.c, specifically 
Parrot_register_HLL().  The integer is an offset into an array of HLL 
information.

(At this point, you should be thinking "Hmm, arrays are first-come 
first-served!  What if you load several PBCs which each have HLL information 
and which were all created independent of each other?  Those unique 
identifiers are only unique within that process!"  You'd be right, too.)

Upshot: if I modify src/tclsh.pir by changing all occurrences of 'pbc' 
to 'pir' and run Tcl tests via parrot src/tclsh.pir instead of parrot 
tcl.pbc, I don't get the mysterious errors.

This means: we ought to be using the unique HLL names as HLL identifiers 
throughout the system, because they're less likely to overlap.

(I did think of doing fixups when loading bytecode... but ow, yuck.)

This means: a rewrite of src/hll.c is in the works.  Fortunately, there's a 
workaround for Tcl.

-- c

Re: Need JIT help please - JIT broken with optimized build on Windows (VC)

[Paolo Molaro]

On 08/16/07 Ron Blaschke wrote:
> > This optimization reaches likely back to times, when the opcode engine was 
> > designed. It's saving one interpreter push statement [1] per JIT calling 
> > one 
> > external function, and I've always thought of it as a very cool (and valid) 
> > thingy, when I first realized, why the interpreter is the second argument 
> > in 
> > opcode functions ;)
> 
> I think it's a really cool idea, too.  I'd like to have a way to disable
> it, though, to measure its effect, and maybe to "work around" compilers
> like VC (at least until a better solution comes around).

The optimization done by the parrot jit is invalid for the x86 C calling
convention: the area of memory containing the passed arguments
can be used as scratch space by the called function.
If you can make sure it's not harmful that way you could still use it
when calling parrot's own jitted functions which could use a different
calling convention, but it is wrong when interoperating with other code
(gcc can generate the same issues, so it's not just VC).

lupus

-- 
-
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better

Re: Need JIT help please - JIT broken with optimized build on Windows (VC)

[Joshua Isom]

On Aug 16, 2007, at 5:25 AM, Paolo Molaro wrote:


On 08/16/07 Ron Blaschke wrote:
The optimization done by the parrot jit is invalid for the x86 C 
calling

convention: the area of memory containing the passed arguments
can be used as scratch space by the called function.
If you can make sure it's not harmful that way you could still use it
when calling parrot's own jitted functions which could use a different
calling convention, but it is wrong when interoperating with other code
(gcc can generate the same issues, so it's not just VC).

lupus

--
-
[EMAIL PROTECTED] debian/rules
[EMAIL PROTECTED] Monkeys do it better



Let's go with a Microsoft blog about it, 
.  
With __stdcall, the callee cleans the stack.  With __cdecl(used 
everywhere else, and in part of windows), the caller cleans the stack.  
If the ops are converted to __cdecl, it should help fix it(since the 
function shouldn't logically assume anything about how much stack space 
is available for clobbering).  I'm having trouble finding anything 
about who owns the stack space.  My personal view is that the caller 
owns that stack space, since it can also be used to store local 
variables, i.e. don't move around data that's in order for calling a 
function.

Re: [perl #44663] [PATCH] [CAGE] Change Test::* Namespaces to Use Keys

[Badai Aqrandista]

Changed [ 'Test::More' ] to [ 'Test'; 'More' ]


 Patch  level 1
Source: 4c149bba-1ebb-4b29-940e-6c2cefc7587e:/parrot/local:599
Target: d31e2699-5ff4-0310-a27c-f18f2fbe73fe:/trunk:20643
(https://svn.perl.org/parrot/trunk)
Log:
 [EMAIL PROTECTED]:  cheepy | 2007-07-14 05:14:58 -0400
 Created a local copy of parrot code
 [EMAIL PROTECTED]:  cheepy | 2007-08-16 23:34:43 -0400
 Modified 'Test::More' to [ 'Test'; 'More' ]
 [EMAIL PROTECTED]:  cheepy | 2007-08-16 23:41:59 -0400
 Modified all 'Test::More' to [ 'Test'; 'More' ] in all test files in t/
 [EMAIL PROTECTED]:  cheepy | 2007-08-17 07:00:45 -0400
 Modified all other occurences of 'Test::More' to [ 'Test'; 'More' ] in code 
part outside 't/' 

=== runtime/parrot/include/test_more.pir
==
--- runtime/parrot/include/test_more.pir(revision 20643)
+++ runtime/parrot/include/test_more.pir(patch 
rt44663-cage-test-more-namespace-to-keys level 1)
@@ -12,7 +12,7 @@
 # get the testing functions
 .local pmc exports, curr_namespace, test_namespace
 curr_namespace = get_namespace
-test_namespace = get_namespace [ "Test::More" ]
+test_namespace = get_namespace [ 'Test'; 'More' ]
 exports = split " ", "plan diag ok is is_deeply like isa_ok"
 
 test_namespace."export_to"(curr_namespace, exports)
=== runtime/parrot/library/Test/More.pir
==
--- runtime/parrot/library/Test/More.pir(revision 20643)
+++ runtime/parrot/library/Test/More.pir(patch 
rt44663-cage-test-more-namespace-to-keys level 1)
@@ -10,7 +10,7 @@
 # get the testing functions
 .local pmc exports, curr_namespace, test_namespace
 curr_namespace = get_namespace
-test_namespace = get_namespace [ "Test::More" ]
+test_namespace = get_namespace [ 'Test'; 'More' ]
 exports = split " ", "plan diag ok is is_deeply like isa_ok"
 
 test_namespace."export_to"(curr_namespace, exports)
@@ -61,7 +61,7 @@
 
 =cut
 
-.namespace [ 'Test::More' ]
+.namespace [ 'Test'; 'More' ]
 
 .sub _initialize :load
 load_bytecode 'library/Test/Builder.pir'
=== src/pmc/exporter.pmc
==
--- src/pmc/exporter.pmc(revision 20643)
+++ src/pmc/exporter.pmc(patch rt44663-cage-test-more-namespace-to-keys 
level 1)
@@ -13,7 +13,7 @@
  .sub main :main
  load_bytecode 'Test/More.pir'
  .local pmc exporter, test_ns
- test_ns = get_namespace ['Test::More']
+ test_ns = get_namespace [ 'Test'; 'More' ]
  exporter = new 'Exporter'
  exporter.'import'( test_ns :named('source'), 'plan ok' :named('globals') )
  plan(1)
=== t/pmc/random.t
==
--- t/pmc/random.t  (revision 20643)
+++ t/pmc/random.t  (patch rt44663-cage-test-more-namespace-to-keys level 1)
@@ -23,7 +23,7 @@
 # get the testing functions
 .local pmc exports, curr_namespace, test_namespace
 curr_namespace = get_namespace
-test_namespace = get_namespace [ "Test::More" ]
+test_namespace = get_namespace [ 'Test'; 'More' ]
 exports = split " ", "plan diag ok is is_deeply like isa_ok"
 
 test_namespace."export_to"(curr_namespace, exports)
=== t/pmc/parrotrunningthread.t
==
--- t/pmc/parrotrunningthread.t (revision 20643)
+++ t/pmc/parrotrunningthread.t (patch rt44663-cage-test-more-namespace-to-keys 
level 1)
@@ -23,7 +23,7 @@
 # get the testing functions
 .local pmc exports, curr_namespace, test_namespace
 curr_namespace = get_namespace
-test_namespace = get_namespace [ "Test::More" ]
+test_namespace = get_namespace [ 'Test'; 'More' ]
 exports = split " ", "plan diag ok is is_deeply like isa_ok"
 
 test_namespace."export_to"(curr_namespace, exports)
=== t/pmc/stmref.t
==
--- t/pmc/stmref.t  (revision 20643)
+++ t/pmc/stmref.t  (patch rt44663-cage-test-more-namespace-to-keys level 1)
@@ -23,7 +23,7 @@
 # get the testing functions
 .local pmc exports, curr_namespace, test_namespace
 curr_namespace = get_namespace
-test_namespace = get_namespace [ "Test::More" ]
+test_namespace = get_namespace [ 'Test'; 'More' ]
 exports = split " ", "plan diag ok is is_deeply like isa_ok"
 
 test_namespace."export_to"(curr_namespace, exports)
=== t/pmc/role.t
==
--- t/pmc/role.t(revision 20643)
+++ t/pmc/role.t(patch rt44663-cage-test-more-namespace-to-keys level 1)
@@ -26,7 +26,7 @@
 # get the testing functions
 .local pmc exports, curr_namespace, test_namespace
 curr_namespace = get_namespace
-test_namespace = get_namespace [ "Test::More" ]
+test_namespace = get_namespace [ 'Test'; 'More' ]
 exports = 

Re: [perl #44663] [PATCH] [CAGE] Change Test::* Namespaces to Use Keys

[Badai Aqrandista]

Hi,

Sorry I just read the docs/submissions.pod and realized I shouldn't
have submit the patch here. I'll resubmit it in proper way to
parrotbug.

-- 
Thanks,
Badai Aqrandista (cheepy)

Re: [perl #44663] [PATCH] [CAGE] Change Test::* Namespaces to Use Keys

[chromatic]

On Thursday 16 August 2007 15:50:25 Badai Aqrandista via RT wrote:

> Sorry I just read the docs/submissions.pod and realized I shouldn't
> have submit the patch here. I'll resubmit it in proper way to
> parrotbug.

It's fine here; don't worry.

-- c

Re: [perl #44657]

[arocker]

> Apparently the plan is to go in the opposite direction, i.e., getting that
> stuff out of the Parrot distribution and into Bundle::Parrot on CPAN.

How would the naming work there? I was trying to reduce the amount of
keying required to invoke functions, and to keep their invocation the same
as if they had been installed "normally". That would eliminate the need
for any additional documentation, (other than perhaps a statement that "if
you install this, you will have Foo::Bing, Bar::*, and  Bam::Bam
available", or something similar).

Re: [perl #44663] [PATCH] [CAGE] Change Test::* Namespaces to Use Keys

[chromatic]

On Friday 17 August 2007 04:24:10 Badai Aqrandista wrote:

> Changed [ 'Test::More' ] to [ 'Test'; 'More' ]

Thanks, applied as r20648.

By the way, the justification for this is that PDD 15 says (or at least 
should) that the proper approach to namespace nesting is to use keys, not 
n-delimited strings.  Of course, keyed nesting didn't work when I wrote this 
library, so it had a workaround until now

-- c

Re: [perl #44607] [CAGE] Hoist slurp_file() into Parrot::Util

[James E Keenan]

[EMAIL PROTECTED] wrote:
>> Apparently the plan is to go in the opposite direction, i.e., 
getting that

>> stuff out of the Parrot distribution and into Bundle::Parrot on CPAN.
>
> How would the naming work there?

Not exactly certain what naming you're referring to ...

> I was trying to reduce the amount of
> keying required to invoke functions, and to keep their invocation the 
same

> as if they had been installed "normally". That would eliminate the need
> for any additional documentation, (other than perhaps a statement 
that "if

> you install this, you will have Foo::Bing, Bar::*, and  Bam::Bam
> available", or something similar).
>

Since I only became aware of the existence of Bundle::Parrot a couple of 
days ago, I can't speak authoritatively (particle, your cue).  But here 
is my surmise.


Over the years Parrot developers have, on the one hand, wanted to take 
full advantage of the functionality developed by the Perl 5 community 
and found on CPAN and, on the other, to avoid piling ever more 
dependencies onto Parrot.  Of necessity, this means some hard choices 
from time to time.  Earlier this year, for example, we finally bit the 
bullet and said that to build Parrot you need Perl 5.8; Perl 5.6.1 would 
no longer suffice.


When it comes to non-core CPAN modules, I know of 3 different situations:

(1) They have more or less been fully included.  I think Class::Struct 
falls into this category (but since I don't know it that well, don't 
quote me).


(2) Significant components have been included as packages under lib/. 
For testing purposes, I added Parrot::IO::Capture::Mini, which holds the 
key elements of CPAN distribution IO::Capture.


(3) Individual subroutines which are either directly from CPAN modules 
or provide similar functionality are stuck in various places in the 
Parrot distribution.  This is the case with slurp_file(), which is 
similar to non-core CPAN module File::Slurp and whose inappropriate 
placement in Parrot::Test started this thread/RT out.


We could go in one of two directions:

(4) Either pull all the odds and ends into a Parrot::Util (fka 
Parrot::YetToBeNamed) module as Andy and I originally suggested; or


(5) Rip out from the Parrot distribution all Perl 5 code which 
unnecessarily replicates functionality found in well tested, non-core 
CPAN modules.  Place those modules in a CPAN bundle.  Tell all Parrot 
developers that they need that in addition to Perl 5.8 in order to 
configure, build and test Parrot.  This was the approach that particle 
began (but didn't sufficiently publicize) and, on reflection, I think 
it's the direction we should take.


To move forward, we need someone -- who very well could be you, Ms. or 
Mr. Newcomer -- to:


(6) Identify all that non-Perl 5 core functionality currently stashed 
away in the Perl 5 components of Parrot.


(7) Determine what parts of that functionality are not yet found in 
Bundle::Parrot and add them thereto.


(8) Propose a patch to Parrot that shows what parts need deleting, what 
changes need to be made in files in docs/, etc.  My hunch is that a 
branch in our repository would be the best way to proceed.


(9) Pester the committers/core developers to review the patch.  (Now 
*that's* the hard part!)


HTH

kid51

(Alan:  I merged 2 RT tickets; that's why I'm replying to your post in 
this thread.)