[perl #38480] [PATCH] Slight improvements to documenting run cores

[via RT]

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


I thought I'd try the ackermann "shootout" function, but alas ran into

./parrot -Oc -C ack.pir 11
Couldn't find init_func for core 6

The following patch would have made it slightly easier for me to figure it 
out (mostly by assuring that the same abbreviations are used consistently 
so that grep helps you finds the relevant documents more quickly.)

diff -ru parrot-current/docs/porting_intro.pod 
parrot-andy/docs/porting_intro.pod
--- parrot-current/docs/porting_intro.pod   Wed Oct  5 03:15:03 2005
+++ parrot-andy/docs/porting_intro.pod  Fri Feb 10 09:36:31 2006
@@ -13,7 +13,7 @@
 internals.  For each feature, a brief description of its purpose, hints on
 helping to port it, and pointers to more information are included.
 
-=head1 CGoto
+=head1 CGoto or CGP (CGoto Predereferenced)
 
 =head2 What it is
 
diff -ru parrot-current/docs/running.pod parrot-andy/docs/running.pod
--- parrot-current/docs/running.pod Sun Dec  4 03:15:02 2005
+++ parrot-andy/docs/running.podFri Feb 10 10:04:46 2006
@@ -133,6 +133,8 @@
 
 =head2 Run Core Options
 
+TODO:  The default run core should be indicated.
+
 =over 4
 
 =item -b, --bounds-checks, --slow-core
@@ -141,7 +143,7 @@
 
 =item -C, --CGP-core
 
-Select the CGP (CGoto Predereferenced) core.
+Select the CGP (CGoto Predereferenced) core (if available).
 
 =item -f, --fast-core
 
@@ -149,19 +151,19 @@
 
 =item -g, --computed-goto-core
 
-Select the CGoto core.
+Select the CGoto core (if available).
 
 =item -j, --jit-core
 
-Run with the JIT subsystem.
+Run with the JIT subsystem (if available).
 
 =item -p, --profile
 
-Run with the slow core and do print an execution profile.
+Run with the slow core and print an execution profile.
 
-=item -P, --predereferenced-core
+=item -S, --switched-core
 
-Predereference opcode function arguments on the fly.
+TODO:  This needs to be documented briefly here and also in glossary.pod.
 
 =item -t, --trace
 
--- parrot-current/src/parrot.c Sun Apr 10 11:15:05 2005
+++ parrot-andy/src/parrot.cFri Feb 10 10:17:02 2006
@@ -8,7 +8,8 @@
 
 =head1 DESCRIPTION
 
-THIS FILE IS NOT USED.
+THIS FILE IS NOT USED.  
+The main function for parrot is found in ../compilers/imcc/main.c.
 
 =cut
 

-- 
Andy Dougherty  [EMAIL PROTECTED]

[perl #38479] Tiny MANIFEST patch

[via RT]

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


I needed the following patch today with a fresh copy of 
parrot-latest.tar.gz.  

I noted the following comment at the top of MANIFEST:
# Please re-sort this file after *EVERY* modification

I tried it, but the resulting patch was 1968 lines long, so I didn't 
attach it here.  Presumably stuff is out of order for a reason, so I 
didn't want to mess with it.

--- parrot-current/MANIFEST Thu Feb  9 19:15:10 2006
+++ parrot-andy/MANIFESTFri Feb 10 10:14:08 2006
@@ -1835,6 +1835,7 @@
 src/pdb.c []
 src/pdump.c   []
 src/pic.c []
+src/pic_jit.c []
 src/pmc.c []
 src/pmc_freeze.c  []
 src/register.c[]

-- 
Andy Dougherty  [EMAIL PROTECTED]

Re: pod syntax fix

[jerry gay]

On 2/10/06, Stig Brautaset <[EMAIL PROTECTED]> wrote:
> Stig
>
applied already in r11502.
thanks for reporting.
~jerry

pod syntax fix

[Stig Brautaset]

pod.patch
Description: Binary data



Stig

[perl #38482] [PATCH] Update Solaris status in PLATFORMS

[via RT]

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


Good news -- this platform is now mostly working again.

--- parrot-current/PLATFORMSFri Feb  3 19:15:04 2006
+++ parrot-andy/PLATFORMS   Fri Feb 10 13:41:00 2006
@@ -34,8 +34,8 @@
 openbsd  YY/5  Y Y   -   YY
 openbsd_beta_3.5-vax Y*4  Y/26
 os2
-solaris8-sparc-cc   B--- -   -   --20051202
-solaris8-sparc-gcc3.4.3 B--- -   -   --20051202
+solaris8-sparc-cc   B--- -   -   YY/7  20060210
+solaris8-sparc-gcc3.4.3 B--- -   -   YY/6  20060210
 solaris9-sparc-gcc3.3.2 B-Y/2  - Y   YY/2  20050814
 solaris10-sparc-gcc3.4.3 B   Y*7  Y/1  20050804
 tru64-alpha-gcc  8   Y   YY

-- 
Andy Dougherty  [EMAIL PROTECTED]

Re: [perl #38480] [PATCH] Slight improvements to documenting run cores

[Leopold Toetsch]

On Feb 10, 2006, at 16:35, Andy Dougherty (via RT) wrote:

The following patch would have made it slightly easier for me to 
figure it
out (mostly by assuring that the same abbreviations are used 
consistently

so that grep helps you finds the relevant documents more quickly.)


Thanks, applied - r11507.
leo

Re: [perl #38482] [PATCH] Update Solaris status in PLATFORMS

[Leopold Toetsch]

On Feb 10, 2006, at 19:42, Andy Dougherty (via RT) wrote:


Good news -- this platform is now mostly working again.


Thanks, applied - r11508.
leo

Re: What am I doing wrong? (Perl, UTF-8 and cyrillic)

[avtanski]

Hello again,

Just wanted to tell you guys that, with your help. I got everything
working fine. Currently I'm using this:

  use open ':utf8';
  use utf8;

This fixed reading from file.  The next problem I encountered was when
reading a string from a POST request, but this was easy, and now I'm
using "utf8::decode()" to convert it properly.

Thanks,

- Alex

[perl #38486] [TODO] -Sj and -Cj runcore testing

[via RT]

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


I'd like to have Parrot::Test support for testing the predereferenced 
-> JIT recompiling feature. Both depend on the availability of the JIT 
runcore (has_jit), the latter also on computed goto (cg_flag).

Tests should be skipped if the architecture doesn't provide necessary 
support.

Thanks,
leo

Re: Testing module name/interface advice

[A. Pagaltzis]

Hi Mattia,

* Mattia Barbon <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> [2006-02-08 17:30]:
>I recently fell in love with Test::Base and I decided to use it
>at $work. Since the 'run filter, compare output' mode of T::B
>did not fit my needs, I wrote a small wrapper (Test::XXX for
>now...) that enables to check/establish preconditions, run one
>or more actions and check postconditions, for each block,
>depending on the sections that are present.

I tried to understand what Test::Base offers, but the POD is not
very good at selling the module… :-)  So I’m not sure what it
does nor what happens in your example.

Purely by your description, though – how about
Test::Base::PrePostConditions?

Regards,
-- 
Aristotle Pagaltzis // 

Find a multi-method/multi-sub by name and signature

[Jonathan Worthington]

Hi,

The .NET translator ambles on and I can now translate a lot of stuff 
relating to the .NET object model.  Recently I've been working on mapping 
.NET's static method overloading onto Parrot's MMD.  With some evil tricks I 
got it to work - almost.


The real issue is that .NET knows what method will be called statically.  It 
doesn't do the whole "find what to call at runtime" thing Parrot does, but 
of course if I want to interoperate with other languages (which is the whole 
point of my project) then I need to translate the code in such a way that it 
works using Parrot primitives.  So using Parrot's MMD it is.


The problem I've hit is that dispatch is based on the runtime type of 
objects being passed.  That's fine, until the object we're passing is null, 
then it's just a null PMC with no relation whatsoever to a particular 
ParrotClass, and so the dispatch fails.  I don't see any way of "creating" a 
null of a particular type, but please do correct me if I'm missing something 
here.


This problem would go away if I had a way of doing a find_global or 
findmethod but also specifying the types that make up the signature.  Kinda 
like those find ops but taking an extra PMC which would be a string array of 
type names.  In fact, I think we're going to need this for Perl 6 anyway, 
since there you can use &sub_name to get a reference to one of 
a number of multi-subs.  This solves my problem because the "dispatch" then 
depends on the static types, and passing a null will be fine.


Anyway, if this sounds sane my plan is to implement ops as I described. 
I'll do them in my .NET dynops, but if it's agreed they're wanted in Parrot 
itself and are blessed with names, I'll happily move them into the core 
Parrot ops.


Comments most welcome,

Jonathan 

Re: namespaces and classes

[Jonathan Worthington]

"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:

I'm still having troubles, when thinking about namespace PMCs and
implementation thereof.
Especially the relationship of class namespaces and the store_global
opcode.

We have e.g. this PIR snippets:

  .sub main :main
 cl = newclass 'Foo'   # a class isa/hasa namespace ?!
That's an interesting question.  It seems we've gone down the Perl5-esque 
line of thought to some degree (e.g. we do objects by associating some 
"thing" with a particular namespace).  At the moment it feels to me like a 
class is associated with some namespace N that contains the methods and 
globals (static attributes) associated with that class, but the class is 
conceptually "in" the parent namespace of N.  Whether that's the Right 
Thing, I'm not sure.  If it's not, then we're going to need some seperate 
way of associating methods with a particular class.  I think that's an 
argument for maintaining the status quo...



 ...
   .end

   .namespace ['Foo']  # namespace 'Foo'

   .sub __init :method # a method &Foo::__init
   ...
   .end

Currently '__init' is stored with:

  store_global "Foo', '__init', $PSub

(Actually, if the class already exists, the C vtable is
used, but that just does C too) But usually, this happens at 
compile-time,

or PBC-load-time, when the class 'Foo' doesn't yet exist.

Therefore C can't be stored into the proposed 
class->vtable->namespace,

as there is no such class (yet).

To actually implement this (and assuming that my thoughts so far are 
correct)

I was thinking about this strategy:

The usage of the C<.namespace> directive causes the creation of a new
namespace PMC with that name. Additionally the namespace PMC is registered
as a type. This needs a bit of additional code that prevents instantiation
of namespaces.

How would this intereact with, say, getclass?  Would getclass only actually 
find real classes, not just anything registred as a type?



When now at runtime C is executed, we find the existing
namespace PMC (with all the statically visible methods inside) and just
promote the namespace PMC into a class PMC.

Is this sane?
I'd really like a way of just saying I want the methods in a class PMC 
statically too - I guess if we had that this problem goes away?  But it's 
also helpful for other reasons.  If you're loading a huge class library, 
having to have a :load sub that does many hundreds of newclass calls really 
slows down startup.  (I've been there and done it.  A PBC that contains just 
empty method bodies for .NET's System.dll took several seconds to do that. 
Admittedly, one :load sub per class, which sucks.  But not having to do 
newclass at all by having all the ParrotClass PMCs created and frozen at 
compile time for the statically known classes would be better.)


Hope this helps,

Jonathan 

Assertion failure in r11509 when throwing an error

[Bob Rogers]

   Unfortunately, I do not know what this means, so I haven't been able
to extract a simple test case.  FWIW, this didn't happen in r11470,
though r11470 has a different problem relating to error handling --
signalling an error corrupts a Sub PMC, trashing its vtable slot.

   Any and all hints gratefully accepted.

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


(gdb) r toy-lisp.pbc
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /usr/src/parrot/parrot toy-lisp.pbc
[New Thread 16384 (LWP 14491)]
[New Thread 32769 (LWP 14492)]
[New Thread 16386 (LWP 14493)]
[New Thread 32771 (LWP 14494)]
* x
Read: X
parrot: src/inter_call.c:899: process_args: Assertion `idx >= 0' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 16384 (LWP 14491)]
0x404b5b71 in kill () from /lib/i686/libc.so.6
(gdb) bt
#0  0x404b5b71 in kill () from /lib/i686/libc.so.6
#1  0x40315cf1 in pthread_kill () from /lib/i686/libpthread.so.0
#2  0x4031600b in raise () from /lib/i686/libpthread.so.0
#3  0x404b5904 in raise () from /lib/i686/libc.so.6
#4  0x404b6e8c in abort () from /lib/i686/libc.so.6
#5  0x404aee84 in __assert_fail () from /lib/i686/libc.so.6
#6  0x4009164d in process_args (interpreter=0x8051430, st=0xb210, 
action=0x4023dbf1 "params", err_check=1) at src/inter_call.c:899
#7  0x40091eec in parrot_pass_args_to_result (interpreter=0x8051430, 
sig=0x4025b849 "PS", dest=0x402a93a4, old_ctxp=0x80e5300, ap=0xb2f8 "")
at src/inter_call.c:1190
#8  0x401e4b20 in pass_exception_args (interpreter=0x8051430, 
sig=0x4025b849 "PS", dest=0x402a93a4, old_ctx=0x80e5300)
at exception_handler.pmc:33
#9  0x401e4d38 in Parrot_Exception_Handler_invoke (interpreter=0x8051430, 
pmc=0x82d70a0, ex=0x82d64d0) at exception_handler.pmc:105
#10 0x4008d740 in throw_exception (interpreter=0x8051430, exception=0x82d64d0, 
dest=0x402a84bc) at src/exceptions.c:412
#11 0x4010df87 in Parrot_throw_p (cur_opcode=0x402a84b4, interpreter=0x8051430)
at core.ops:706
#12 0x400a16f5 in runops_slow_core (interpreter=0x8051430, pc=0x402a84b4)
at src/runops_cores.c:157
#13 0x4008ef8d in runops_int (interpreter=0x8051430, offset=3788)
at src/interpreter.c:775
#14 0x4009364c in runops (interpreter=0x8051430, offs=3788)
at src/inter_run.c:81
#15 0x40093863 in runops_args (interpreter=0x8051430, sub=0x82379e8, 
obj=0x808d750, meth=0x0, sig=0x402443c2 "vP", 
ap=0xb4ac "¸y#\b\030õÿ¿\220Ò") at src/inter_run.c:180
#16 0x40093967 in Parrot_runops_fromc_args (interpreter=0x8051430, 
sub=0x82379e8, sig=0x402443c2 "vP") at src/inter_run.c:274
#17 0x400dcc8c in Parrot_runcode (interpreter=0x8051430, argc=1, 
argv=0xb568) at src/embed.c:801
#18 0x0804a8d9 in main (argc=1, argv=0xb568) at compilers/imcc/main.c:655
(gdb) f 6
#6  0x4009164d in process_args (interpreter=0x8051430, st=0xb210, 
action=0x4023dbf1 "params", err_check=1) at src/inter_call.c:899
(gdb) p idx
$2 = -1
(gdb) p st->dest.i
$3 = 1
(gdb) p st->dest.sig
$4 = 1
(gdb) p state
$5 = 0
(gdb) p st->named_done
$6 = 134550576
(gdb) p st->first_named
$7 = -1
(gdb) p st->name
$8 = (STRING *) 0x0
(gdb) p st->dest.u.op.pc
$9 = (opcode_t *) 0x402a93ac
(gdb) 

Re: [perl #38476] [PATCH] De-tab nativecall.pl

[Matt Diephouse]

via RT Brad Bowman <[EMAIL PROTECTED]> wrote:
> The patch turns the mix of 4-tabs, 8-tabs and spaces in
> nativecall.pl into just spaces.  Only whitespace changes.

Applied, thanks.

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

Building parrot-0.4.1 on Win32

[Sisyphus]

Hi,

My first post here. First up, is there a better place to ask questions
relating to the building of parrot  ? If so ... where ? If not ... read on.

I'm on Windows 2000, and parrot-0.4.1 builds straight out of the box using
MSVC++ 7.0 (.NET) and nmake. But there's a couple of issues when using MinGW
(gcc-3.4.4) and mingw32-make.

In config/gen/makefiles/root.in I find the line:

MINIPARROT= $(CUR_DIR)/miniparrot$(EXE)

Using MSVC++ and nmake, somewhere along the way, that forward slash gets
converted to a backslash (which is what needs to happen). But using gcc and
mingw32-make, the backslash stays as is. Put simply the problem is that, in
the cmd.exe shell, while '.\some.exe' works fine, './some.exe' always
produces the error:

'.' is not recognized as an internal or external command, operable program
or batch file.

How is that '/' to '\' conversion effected - so that I might apply it to the
MinGW build  ?

As a quick hack, when building with MinGW, I simply first change the above
line in 'root.in' to:

MINIPARROT= miniparrot$(EXE)

That avoids the './miniparrot.exe ' problem I initially experienced, but
the mingw32-make process still fails. Here's how it finishes:

miniparrot.exe config_lib.pasm > runtime/parrot/include/config.fpmc
F:\Perl58_M\5.8.8\bin\perl.exe tools/build/parrot_config_c.pl > \
src/parrot_config.c
src/parrot_config.c
F:\Perl58_M\5.8.8\bin\perl.exe tools/build/parrotdef.pl
gcc -o
rrot.exe -s -L"F:\Perl58_M\5.8.8\lib\CORE" -L"F:\MinGW\lib"   -Wl,--out-impl
ib,parrot.a \
compilers/imcc/main.o

blib/lib/libparrot.a  -lmsvcrt -lmoldname -lkernel32 -luser32 -lgdi32 -lwins
pool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -l
ws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lgmp \
src/parrot_config.o parrot.def
Cannot export Parrot_PMC_get_intval: symbol not defined
Cannot export Parrot_PMC_typenum: symbol not defined
Cannot export Parrot_call_method: symbol not defined
Cannot export Parrot_call_sub: symbol not defined
Creating library file: parrot.a
collect2: ld returned 1 exit status
mingw32-make: *** [parrot.exe] Error 1

The failing command invokes 'gcc' because that's how 'root.in' evaluates
${link}. As a guess, I set ${link} to 'g++', but the error is still the
same.

When building with MSVC++ and nmake, the corresponding command is:

link -out:.\parrot.exe -nologo -nodefaultlib -debug -machine:x86  -debug
compilers\imcc\main.obj  blib\lib\libparrot_s.lib  oldnames.lib kernel32.lib
user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib
ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib
version.lib odbc32.lib odbccp32.lib msvcrt.lib
 src\parrot_config.obj -def:parrot.def

Comparing the two, I can't really see why the former would fail while the
latter succeeds. I don't think the forward slashes in the former should
matter ... and I don't think the absence of '-lgmp' in the latter accounts
for the difference.

Any advice on how to proceed with this ?

Cheers,
Rob