My Parrot 0.7.0 patches (cygwin)

[Reini Urban]

2008/8/17 Reini Urban <[EMAIL PROTECTED]>:
> FYI:
> The cygwin release for parrot-0.7.0-1 will contain the following yet
> unapplied patches to make it work:
>
> (in this order from my quilt series file)
> 39742-installed-conflict.patch
> 56544-install_files.patch
> 57006-opengl-cyg.patch -p0

I've fixed another linking issue here.

> 58034-config_args.patch
> 56554-make-install-lang.patch

This is now finished.

> 56998-cygdll_versioning.patch -p0
> 51944-README_cygwin.patch
>
> These were applied:
> 57476-pdb-version.patch
> 57546-tags-xemacs.patch
>
> These are not stable enough:
> 56996-fhs-runtime.patch
>  Still working on library.c getting the interpreter
>  interpreter INTERPINFO_RUNTIME_PREFIX or CONFIG_HASH and check
>  for the new "installed" key if present.

This is in, but the new features to make it faster are ifdef'ed out.

> 57548-CONDITIONED_LINE_enh.patch
>  too early
>
> TODO: I'm not yet sure about these patches of mine. Most likely they are
> already applied.
> 56562-implib.patch
> 57110-ncurses-cygwin.patch
> 57112-pg-cygwin.patch
> 57114-urm-RealBin.patch

These are already in.

As my number of patches is too big, and the size is too big,
I update them only in my public SVN repo, not in the tickets anymore.
And the order in which they should be applied is important.

See
http://code.google.com/p/cygwin-rurban/source/browse/#svn/trunk/release/parrot/patches

http://code.google.com/p/cygwin-rurban/source/browse/trunk/release/parrot/patches/series
defines the order.

Esp. the 39742-installed-conflict.patch and
56554-make-install-lang.patch are big.

I still have issues with the language installables requiring
úninstalled files (pbc's from compiler),
so the cygwin release will need more time.
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

Re: [perl #58034] [TODO] save config_args for make reconfig

[Reini Urban]

2008/8/17 Reini Urban <[EMAIL PROTECTED]>:
> James Keenan via RT schrieb:
>>
>> Reini,
>>
>> I would argue that we take a different approach with 'make reconfig'. We
>> need to get rid of it entirely.  In Parrot years, it's ancient code:
>>
>> $ svn blame config/gen/makefiles/root.in | grep -n -A 3 reconfig
>> ...
>> --
>> 708:  4916   boemmels   @echo "  reconfig:  'clean' and redo
>> configuration."
>> ...
>> --
>> 1769:  7554   bernhard reconfig : clean
>> 1770- 22967   bernhard  $(PERL) Configure.pl
>>
>> And it doesn't DWIM.  Nowadays, if you want to redo configuration, you
>> need to call 'make realclean', as 'make clean' does not delete the files
>> created by Configure.pl.  (If you want to re-run one particular
>> configuration step, use tools/dev/reconfigure.pl.)
>>
>> I guess that the existence of 'make reconfig' completely escaped me.  If
>> I had known about it, I would have recommended excising it, as it's
>> inconsistent with the way Configure.pl has worked for at least two years.
>>
>> Now, there may very well be other reasons to retain the command-line
>> options.  Parrot::Configure::Options processes those options, and the
>> most important of them are available for the lifetime of the
>> Parrot::Configure object.  Given that, the question arises as to whether
>> they should be retained in the Makefile and/or in Parrot::Config.  I'm
>> now developing file-based configuration in a branch, and in that branch
>> I've chosen to store the parsed version of that file in Parrot::Config.
>>
>> So, my recommendation is to hold off on deciding how to store
>> command-line options for the next week.  After I present this patch for
>> file-based configuration, we'll be in a better position to decide
>> how/where to store the command-line options data.
>
> Hmm,
> Attached is my improved version which got the GEN_CONFIG dependencies right.
>
> My goal is to get rid of the required make clean and to get all dependencies
> right. With a required make clean we are loosers.
> The GEN_CONFIG target does not need clean anymore. It needs to be more
> fine-tuned though.
>
> This solves the Makefile problem.
> What you plan with the perl libraries is fine, but the driver for the
> dependencies to finally get rid of make clean should be the Makefiles.
> The toolkit could be Parrot::Config a la tools/dev/reconfigure.pl
>
> I got rid of "[perl #39742] [BUG] installed parrot conflicts with dev
> parrot" with my 39742-installed-conflict.patch.
> Now just the proper dependencies and install are missing.

Attached is the version which is in the cygwin 0.7.0 package.

CONFIGURE_GENERATED_FILES should use it,
The GEN_CONFIGS dep is commented out, because it's not 100% safe yet.

-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/
2008-08-17 [EMAIL PROTECTED]

make reconfig ignores the given Configure.pl command-line args.
We need to save the config_args somewhere to be able to do 
make reconfig like 

CONFIG_ARGS = @config_args@

$(CONFIGURE_GENERATED_FILES) : Configure.pl
	$(PERL) Configure.pl $(CONFIG_ARGS)

We really should track all dependencies and do a make reconfig automatically.

The CONFIG_ARGS should be stored in Makefile.
config_args should be stored in config_lib.pasm as in perl5 also.

Index: parrot-svn/config/gen/makefiles/root.in
===
--- parrot-svn.orig/config/gen/makefiles/root.in
+++ parrot-svn/config/gen/makefiles/root.in
@@ -19,6 +19,7 @@
 DEVEL   = @DEVEL@
 VERSION = @[EMAIL PROTECTED](DEVEL)
 SOVERSION   = @VERSION@
+CONFIG_ARGS = @config_args@
 
 # Override at least PREFIX with the install location if you're going
 # to be using this outside of your build area.
@@ -999,6 +1000,20 @@ $(INC_DIR)/oplib/ops.h lib/Parrot/OpLib/
 lib/Parrot/OpsFile.pm lib/Parrot/Op.pm $(OPS_DIR)/ops.num $(OPS_DIR)/ops.skip
 	$(PERL) $(BUILD_TOOLS_DIR)/ops2pm.pl $(OPS_FILES)
 
+# FIXME: This creates a cycle sometimes
+#lib/Parrot/Config/Generated.pm \
+#$(SRC_DIR)/platform.c \
+##CONDITIONED_LINE(platform_asm):$(SRC_DIR)/platform_asm.s \
+##CONDITIONED_LINE(has_opengl):config/gen/call_list/opengl.in \
+##CONDITIONED_LINE(has_glut):$(SRC_DIR)/glut_callbacks.c \
+#config_lib.pasm \
+#$(BUILD_TOOLS_DIR)/dynpmc.pl \
+#$(BUILD_TOOLS_DIR)/dynoplibs.pl \
+# : Configure.pl lib/Parrot/Configure.pm \
+#   lib/Parrot/Configure/Step/List.pm lib/Parrot/Configure/Step/Methods.pm
+#	@echo "  Makefile out-of-date: reconfigure"
+#	$(PERL) Configure.pl $(CONFIG_ARGS)
+
 ###
 #
 # Examples (Assembly):
@@ -1774,7 +1789,7 @@ svnclobber : .svn
 	$(PERL) tools/dev/svnclobber.pl
 
 reconfig : clean
-	$(PERL) Configure.pl
+	$(PERL) Configure.pl $(CONFIG_ARGS)
 
 manitest :
 	$(PERL) tools/dev/manicheck.pl
Index: parrot-svn/Configure.pl
===
--- parrot-svn.orig/Configure.pl
+++ parr

Re: [perl #56996] [TODO] remove non FHS-compliant searchpaths

[Reini Urban]

This is where I stand now, and as it is in the 0.7.0 cygwin package.

It works fine, but slow.
There's a new installed key in the config hash, and the code to check this in
library.c is ifdef'ed out as it generates a VM out of memory error.


2008/8/9 Reini Urban <[EMAIL PROTECTED]>:
> Reini Urban schrieb:
>>
>> Reini Urban schrieb:
>>>
>>> Geoffrey Broadwell via RT schrieb:

 On Sun, 2008-07-27 at 13:13 +0200, Reini Urban wrote:
>
> +stat $I0, conf_file, 0
> +if $I0 goto conf
> ++# If installed into /usr/lib/parrot, not /usr/runtime/parrot
> +# This logic has to be reversed when installed versions should
> run faster
> +# than source builds.

 Reverse it now; we'll never remember to get back to this in the future.

> +conf_file = interpinfo .INTERPINFO_RUNTIME_PREFIX
> +conf_file .= "/lib/parrot/include/config.fpmc"
> +conf:

> +name = interpinfo .INTERPINFO_RUNTIME_PREFIX
> +concat name, "lib/parrot/dynext/"
> concat name, request

 Since we're using PIR in both places, we should probably use the .=
 sugar in both places.  Yes, I know the second file has some 'concat's in
 it already.  Here's an opportunity to fix that.  :-)
>>>
>>> Ok. concat to .= is easy.
>>>
>>> Why I don't want to fix that as you suggest is that I wait for feedback
>>> how it was designed to be. This patch is just a intermediate hack. Someone
>>> like particle or Allison should comment on that.
>>>
>>> It is fine for benchmarks that the source build uses
>>> runtime/parrot/include/config.fpmc.
>>> But the installed version either should NOT need to load the frozen
>>> config file when it is already linked in, or check with some global or
>>> interpinfo magic and look up the right prefix then.
>>> No useless stats please.
>>
>> My current plan is this:
>>
>> Source builds should be allowed to access
>> runtime/parrot/include/config.fpmc and the various other config fpmc's, but
>> the installable version, linked to install_config.fpmc must change its
>> lib_path to allow only FHS-compliant paths,
>> i.e remove runtime/parrot and runtime/parrot/include in favor of
>> lib/parrot and lib/parrot/include.
>>
>> This must be fixed in config.pir, parrotlib.pir and src/library.c with
>> this ticket. (Hope I forgot no other file)
>> I'll work on that, but I have a business trip for the next two weeks.
>>
>> An optimization for another ticket would be to remove the run-time access
>> to include/config.pir for linked installable's, where the frozen config.fpmc
>> is already linked. There the sub _config should use some config detection
>> logic (suggestion: new config key 'installed') to omit .include
>> "library/config.pir"
>> See the ticket perl #57418 [TODO] optimize _config to omit .include
>> "library/config.pir" on installables
>
> Attached is an improved version with a fix in src/library.c, to decide
> between installed and not installed configs.
> This solves at least the /usr/runtime problem.
>
> However config.pir still unnecessarily tries to access some runtime files,
> esp. "interpinfo.pasm" to get the index of .INTERPINFO_RUNTIME_PREFIX
> I'm toying with the idea to fill that macro in parrotlib.pir and config.pir
> with config/gen/parrot_include.pm.

-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/
Remove stats to /usr/runtime/parrot at installed versions
("/usr" being the prefix).
Check the config_hash for the installed key and the 
interpreter INTERPINFO_RUNTIME_PREFIX or CONFIG_HASH if present.

The library.c code is not working yet with ENABLE_PARROT_LIBRARY_INSTALLED
Parrot VM: PANIC: Out of mem!
Not enough tuits yet to fix and debug it.

Index: parrot-svn/runtime/parrot/library/config.pir
===
--- parrot-svn.orig/runtime/parrot/library/config.pir
+++ parrot-svn/runtime/parrot/library/config.pir
@@ -48,12 +48,28 @@ undefined values) is undefined, and may 
 .sub _config
 .local pmc CONF
 .local string conf_file
+
+#unless find_sub('_config') goto runtime
+#$P0 = _config()
+#.return( $P0 )
+
+runtime:
+# conf_file = Parrot_locate_runtime_file_str(interp, "config.fpmc", 2)
 conf_file = interpinfo .INTERPINFO_RUNTIME_PREFIX
 conf_file .= "/runtime/parrot/include/config.fpmc"
+stat $I0, conf_file, 0
+if $I0 goto conf
 
+# If installed into /usr/lib/parrot, not /usr/runtime/parrot
+# This logic has to be reversed when installed versions should run faster
+# than source builds.
+conf_file = interpinfo .INTERPINFO_RUNTIME_PREFIX
+conf_file .= "/lib/parrot/include/config.fpmc"
+conf:
 open CONF, conf_file, "<"
 $I0 = defined CONF
 if $I0 goto ok1
+
 printerr "Can't read '"
 printerr conf_file
 printerr "': "
Index: parrot-svn/runtime/parrot/library/parrotlib.pir
===
--- parrot-svn.orig/run

Re: [perl #39742] [BUG] installed parrot conflicts with dev parrot.

[Reini Urban]

Attached is my latest version.

make works with already installed shared lib,

make installable fails on some languages with already installed
/usr/lib/parrot and /usr/include/parrot.
Fixing make installable belongs to a new ticket, as there's more involved.

2008/8/3 Reini Urban <[EMAIL PROTECTED]>:
> Reini Urban schrieb:
>> Andy Dougherty schrieb:
>>> On Sat, 14 Jun 2008, James Keenan via RT wrote:

 Can we get an update as to the issues raised in this ticket?
>>>
>>> The general issue
>>>"installeld parrot conflicts with dev parrot"  -- at least when a
>>> shared libparrot.so is used
>>>
>>> is, as far as I know, unsolved.  A longer discussion can be found here
>>> (and the surrounding thread):
>>>
>>>
>>>  http://www.nntp.perl.org/group/perl.perl6.internals/2006/03/msg33340.html
>>
>> It should be added that this does not affect cygwin and mingw.
>> just shared a libparrot.so
>>
>> It is still true that
>>  gcc ... -L/usr/local/lib ... -L.../blib/lib -lparrot -L/usr/local/lib
>> -lgmp -lreadline
>> would prefer a /usr/local/lib/libparrot.dll.a if there would be some,
>> (there is even a /usr/lib/libparrot.dll.a)
>> but the nature of this import lib is affected by PATH,
>> which is so constructed that blib/lib prepends the installed libparrot.
>>
>> Just the perl5 ldflags setting have to fixed in the config hints step.
>> -L/usr/local/lib can be stripped at all, if some parrot lib pulls that in.
>> If not it has to be put after -lparrot.
>
> With the recent merge which changed the exception handling,
> I was able to reproduce and fix the problem not being able to compile a
> fresh parrot with an already installed shared libparrot.
> So my previous comment was wrong.
>
> The reason for the problem is simple and two-fold:
> 1. libs belongs to the end.
>
> first LDFLAGS, then LD_LOAD_FLAGS, then libparrot,
> then LIBS + EXTRALIBS.
>
> dynpmc got this wrong.
> It had LIBS at the front.
>  a. One should not put libs before the LDFLAGS.
>  b. One should reverse the LIBS line in order of dependencies.
> We have the problem that the libs line is generated automatically and
> may contain -L/usr/lib (pulled in from libicu) and -L/usr/local/lib, so the
> already installed -lparrot will be found.
>
> So our -Lblib/lib should be at the front, best in LDFLAGS.
> Note that parrot.pc got that right:
>  Libs: -L${libdir} -lparrot @icu_shared@ @libs@
>
> 2. remove the perl5 -L/usr/local/lib LDFLAGS which would pull in
>   a shared /usr/local/lib/libparrot.so before checking -Lblib/lib
>  -lparrot.
>
> One fix could be to check this in Configure and move all -L from LDFLAGS
> to the LIBS flag at the front.
>
> The other fix would be to explicitly link to blib/lib/libparrot.so,
> without path hacks, which could be easily fooled.
>
> This patch adds PATH resp. LD_RUN_PATH to the parrot invocations, similar as
> in perl5.
> It moves a -L from @ldflags@ to @libs@ in config.
> It also adds emacs/vim modes to the Makefiles.
> It also adds Makefile targets to regenerate the Makefiles automatically.

-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/
-*- diff -*-
The reason for the problem to make shared libparrot with an already installed 
shared libparrot is simple and has several reasons:

1. libs belongs to the end. 

first LDFLAGS, then LD_LOAD_FLAGS, then libparrot, 
then LIBS + EXTRALIBS.

dynpmc got this wrong. 
It had LIBS at the front. 
  a. One should not put libs before the LDFLAGS.
  b. One should reverse the LIBS line in order of dependencies.
 We have the problem that the libs line is generated automatically 
 and may contain -L/usr/lib (pulled in from libicu) and -L/usr/local/lib, 
 so the already installed -lparrot will be found. 

So our -Lblib/lib should be at the front, best in LDFLAGS.
Note that parrot.pc got that right:
  Libs: -L${libdir} -lparrot @icu_shared@ @libs@

2. remove the perl5 -L/usr/local/lib LDFLAGS which would pull in 
   a shared /usr/local/lib/libparrot.so before checking -Lblib/lib
  -lparrot.

One fix could be to check this in Configure and move all -L from LDFLAGS
to the LIBS flag at the front. I went this way.

The other fix would be to explicitly link to blib/lib/libparrot.so,
without -L path hacks.

3. Now an already installed libparrot.dll/.so does not conflict with make anymore.
   The remaining problem is at make installable esp. for the languages 
   and already installed /usr/lib/parrot, /usr/include/parrot and
   /usr/lib/libparrot.dll.a

This patch adds PATH resp. LD_RUN_PATH to the parrot invocations, similar as in perl5.
It moves a -L from @ldflags@ to @libs@ in config.
It also adds emacs/vim modes to the Makefiles.
It also adds Makefile targets to regenerate the Makefiles automatically.

Index: parrot-svn/config/gen/makefiles/dynpmc_pl.in
===
--- parrot-svn.orig/config/gen/makefiles/dynpmc_pl.in
+++ parrot-svn/config/gen/makefiles/dynpmc_pl.in
@@ -72,8 +72,15 @@ sub partia

Re: My Parrot 0.7.0 patches (cygwin)

[Allison Randal]

Reini Urban wrote:


As my number of patches is too big, and the size is too big,
I update them only in my public SVN repo, not in the tickets anymore.
And the order in which they should be applied is important.

See
http://code.google.com/p/cygwin-rurban/source/browse/#svn/trunk/release/parrot/patches

http://code.google.com/p/cygwin-rurban/source/browse/trunk/release/parrot/patches/series
defines the order.


What are we lacking to get the stable patches from this set merged in? 
Do we need a code review? Testing on other platforms to make sure they 
don't cause problems elsewhere?


Allison

[svn:parrot-pdd] r30437 - trunk/docs/pdds

[kjs]

Author: kjs
Date: Fri Aug 22 03:59:58 2008
New Revision: 30437

Modified:
   trunk/docs/pdds/pdd19_pir.pod

Log:
[pdd19] add a note about not-allowing space around the method-call dot.

Modified: trunk/docs/pdds/pdd19_pir.pod
==
--- trunk/docs/pdds/pdd19_pir.pod   (original)
+++ trunk/docs/pdds/pdd19_pir.pod   Fri Aug 22 03:59:58 2008
@@ -805,6 +805,9 @@
 Internally, the call stack doesn't increase because of a tail call, so
 you can write recursive functions and not have stack overflows.
 
+Whitespace surrounding the dot ('.') that separates the object from the
+method is not allowed.
+
 =back
 
 =head2 Assignment and Morphing

Re: [CAGE] clean up stray test files

[Allison Randal]

James E Keenan wrote:


Are these happening notwithstanding the patches I applied for RTs 57956, 
57958 and 58036?


The stray test files are gone now, and not recreated by 'make test', 
'perl Configure.pl', or 'perl Configure.pl --test=configure'.


Thanks!
Allison

Damian Conway interview

[Will Coleda]

http://perlbuzz.com/2008/08/big-interview-with-damian-conway.html

Talk at one point goes to perl6, and pugs vs. rakudo, and then talk
about parrot.

I am now officially warm and fuzzy for the next five minutes.

-- 
Will "Coke" Coleda

[perl #58250] [TODO] Generate callgrind output

[via RT]

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


Provide a mechanism (for example, compiling with
-DPARROT_CALLGRIND)[1], that forces each Sub invocation to be reported
in a standard callgrind output
(http://valgrind.org/docs/manual/cl-format.html).

Future bonus points for providing similar support for opcodes
(probably replacing the -p option).

Double future super bonus points for combining the output of the
C-level callgrind output (available from valgrind) with the parrot sub
and opcode information into a single report.

[1] chromatic's original suggestion was an alternate runcore. I think
this suggestion makes more sense since we want this for more than
opcode dispatch, but I could be wrong.
-- 
Will "Coke" Coleda

gsoc_nci merge

[Kevin Tew]

The merge has happened.

Developers/Users should see no visible changes.
Please build and test, should you have any problems, just yell at me on 
#irc or parrot-porters.

Regression test cases will be appreciated. :)
I'll try to be available until 3:00pm MDT and later this evening 
9:00pmMDT -> until my eyelids close.


NOTE:
Jitted nci stubs are supported now on i386 linux and win32.
However jitted nci stubs are DISABLED by default.
Once we have this initial merge completed and everyone happy, I will 
enable jitted nci stubs as the default, accompanied by another message 
to parrot-porters
If you want to test jitted nci stubs uncomment tools/build 
cs/nativecall.pl:308, make realclean, rinse, etc
Jitted nci stubs for x86_64 and i386 OSX are in the works but not 
present in this current merge.
i386 OSX doesn't work with the current patch because it requires a 16 
byte aligned stack.

Don't worry, by default configure disables jit on OSX.

Things that have changed under the covers:
1) a new makefile is being generated
+++ config/gen/makefiles.pm (working copy)
@@ -41,6 +41,8 @@
conditioned_lines => 1,
},

+'compilers/ncigen/Makefile'  =>
+{ SOURCE => 'compilers/ncigen/config/makefiles/ncigen.in' },

2) nci c function stub generation has changed slightly


Kevin

Re: My Parrot 0.7.0 patches (cygwin)

[Reini Urban]

2008/8/22 Allison Randal <[EMAIL PROTECTED]>:
>> As my number of patches is too big, and the size is too big,
>> I update them only in my public SVN repo, not in the tickets anymore.
>> And the order in which they should be applied is important.
>>
>> See 
>> http://code.google.com/p/cygwin-rurban/source/browse/#svn/trunk/release/parrot/patches
>>
>> http://code.google.com/p/cygwin-rurban/source/browse/trunk/release/parrot/patches/series
>> defines the order.
>
> What are we lacking to get the stable patches from this set merged in?

All the ones from the series file are current and stable. The others
are outdated.

> Do we need a code review?

For 56996-fhs-runtime.patch.

> Testing on other platforms to make sure they don't cause
> problems elsewhere?

Sure. That would be nice.
But cygwin is usually less forgiving than other platforms, so I'm pretty
sure it should work elsewhere.
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

Re: [svn:parrot] r30436 - trunk/compilers/pirc/new

[Allison Randal]

[EMAIL PROTECTED] wrote:
>
> {WS}"."{WS} means concatenation (as in $P0 . $P1)
> {WS}"." means concatenation (as in $P0 .$P1)
> "."{WS} means concatenation (as in $P0. $P1)
> "." means method call (as in $P0.$P1)

You can simplify even further and make these two syntax errors:

 {WS}"." means concatenation (as in $P0 .$P1)
 "."{WS} means concatenation (as in $P0. $P1)

Allison

Re: My Parrot 0.7.0 patches (cygwin)

[Moritz Lenz]

Reini Urban wrote:
 > See
> http://code.google.com/p/cygwin-rurban/source/browse/#svn/trunk/release/parrot/patches
> 
> http://code.google.com/p/cygwin-rurban/source/browse/trunk/release/parrot/patches/series
> defines the order.

I tried to apply those patches stupidly both against HEAD and against
parrot-0.7.0, and both had some failures:

parrot-0.7.0:
cat ../patch-list | while read i; do echo $i; pa
tch -p1  < ../parrot-patches/$i; done
39742-installed-conflict.patch
patching file config/gen/makefiles/dynpmc_pl.in
patching file config/gen/makefiles/dynpmc.in
patching file config/gen/makefiles/nqp.in
patching file config/gen/makefiles/parrot_embed.in
patching file config/gen/makefiles/pct.in
patching file config/gen/makefiles/pge.in
patching file config/gen/makefiles/pirc.in
patching file config/gen/makefiles/tge.in
patching file config/gen/makefiles/editor.in
patching file config/gen/makefiles/ext.in
patching file config/gen/makefiles/json.in
patching file config/gen/makefiles/root.in
Hunk #7 FAILED at 820.
Hunk #9 succeeded at 1018 (offset -2 lines).
1 out of 9 hunks FAILED -- saving rejects to file
config/gen/makefiles/root.in.r

Against which svn revision should I apply those patches for testing?

Cheers,
Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Re: gsoc_nci merge

[Kevin Tew]

Looks like a weird linking error,

I can reproduce it.
cc -o examples/pasm/hello examples/pasm/hello.o src/exec_start.o 
src/parrot_config.o -Wl,-rpath=/home/tewk/srcs/nci/blib/lib 
-L/home/tewk/srcs/nci/blib/lib -lparrot -lm -L/usr/lib  -licuuc 
-licudata -lm -ldl -lm -lpthread -lcrypt -lrt -lgmp -lreadline -lpcre 
-lglut -lGLU -lGL -lcrypto  -L/usr/local/lib -Wl,-E

src/exec_start.o: In function `set_nci_I':
/home/tewk/srcs/nci/src/jit_emit.h:96: undefined reference to 
`Parrot_store_arg'

src/exec_start.o: In function `set_nci_N':
/home/tewk/srcs/nci/src/jit_emit.h:107: undefined reference to 
`Parrot_store_arg'

src/exec_start.o: In function `set_nci_S':
/home/tewk/srcs/nci/src/jit_emit.h:118: undefined reference to 
`Parrot_store_arg'

src/exec_start.o: In function `set_nci_P':
/home/tewk/srcs/nci/src/jit_emit.h:129: undefined reference to 
`Parrot_store_arg'

collect2: ld returned 1 exit status
make[1]: *** [exec] Error 1

What puzzles me is that Parrot_store_arg is in libparrot

13:38:58 [EMAIL PROTECTED]: ~/srcs/nci(nci)$ nm blib/lib/libparrot.so.0.7.0 |grep 
store_arg

0015a810 t Parrot_store_arg
0015a760 t store_arg
13:39:20 [EMAIL PROTECTED]: ~/srcs/nci(nci)$ nm blib/lib/libparrot.a |grep 
store_arg
1840 T Parrot_store_arg
1790 t store_arg
U Parrot_store_arg
U Parrot_store_arg
U Parrot_store_arg
U Parrot_store_arg
U Parrot_store_arg
U Parrot_store_arg

Ideas, Kevin

François Perrad wrote:

2008/8/22 Kevin Tew <[EMAIL PROTECTED]>:
  

The merge has happened.




The target 'hello' seems broken :

src/exec_start.o: In function `set_nci_I':
/home/fperrad/checkout/parrot/src/jit_emit.h:96: undefined reference
to `Parrot_store_arg'
src/exec_start.o: In function `set_nci_N':
/home/fperrad/checkout/parrot/src/jit_emit.h:107: undefined reference
to `Parrot_store_arg'
src/exec_start.o: In function `set_nci_S':
/home/fperrad/checkout/parrot/src/jit_emit.h:118: undefined reference
to `Parrot_store_arg'
src/exec_start.o: In function `set_nci_P':
/home/fperrad/checkout/parrot/src/jit_emit.h:129: undefined reference
to `Parrot_store_arg'
collect2: ld returned 1 exit status

Francois.

  

Developers/Users should see no visible changes.
Please build and test, should you have any problems, just yell at me on #irc
or parrot-porters.
Regression test cases will be appreciated. :)
I'll try to be available until 3:00pm MDT and later this evening 9:00pmMDT
-> until my eyelids close.

NOTE:
Jitted nci stubs are supported now on i386 linux and win32.
However jitted nci stubs are DISABLED by default.
Once we have this initial merge completed and everyone happy, I will enable
jitted nci stubs as the default, accompanied by another message to
parrot-porters
If you want to test jitted nci stubs uncomment tools/build
cs/nativecall.pl:308, make realclean, rinse, etc
Jitted nci stubs for x86_64 and i386 OSX are in the works but not present in
this current merge.
i386 OSX doesn't work with the current patch because it requires a 16 byte
aligned stack.
Don't worry, by default configure disables jit on OSX.

Things that have changed under the covers:
1) a new makefile is being generated
+++ config/gen/makefiles.pm (working copy)
@@ -41,6 +41,8 @@
   conditioned_lines => 1,
   },

+'compilers/ncigen/Makefile'  =>
+{ SOURCE => 'compilers/ncigen/config/makefiles/ncigen.in' },

2) nci c function stub generation has changed slightly


Kevin

Re: gsoc_nci merge

[Kevin Tew]

Uh duh,

start_exec.c includes jit_emit.h

0015a810 t Parrot_store_arg
little t means its not exported.

set_nci_* functions should probably be moved elsewhere.
as well as the Parrot_jit_build_call_func
I found Parrot_jit_build_call_func   in   src/jit/i386/jit_emit.h, so I 
made my changes in place.


Suggestions about where these functions should go and how?

Kevin


Kevin Tew wrote:

Looks like a weird linking error,

I can reproduce it.
cc -o examples/pasm/hello examples/pasm/hello.o src/exec_start.o 
src/parrot_config.o -Wl,-rpath=/home/tewk/srcs/nci/blib/lib 
-L/home/tewk/srcs/nci/blib/lib -lparrot -lm -L/usr/lib  -licuuc 
-licudata -lm -ldl -lm -lpthread -lcrypt -lrt -lgmp -lreadline -lpcre 
-lglut -lGLU -lGL -lcrypto  -L/usr/local/lib -Wl,-E

src/exec_start.o: In function `set_nci_I':
/home/tewk/srcs/nci/src/jit_emit.h:96: undefined reference to 
`Parrot_store_arg'

src/exec_start.o: In function `set_nci_N':
/home/tewk/srcs/nci/src/jit_emit.h:107: undefined reference to 
`Parrot_store_arg'

src/exec_start.o: In function `set_nci_S':
/home/tewk/srcs/nci/src/jit_emit.h:118: undefined reference to 
`Parrot_store_arg'

src/exec_start.o: In function `set_nci_P':
/home/tewk/srcs/nci/src/jit_emit.h:129: undefined reference to 
`Parrot_store_arg'

collect2: ld returned 1 exit status
make[1]: *** [exec] Error 1

What puzzles me is that Parrot_store_arg is in libparrot

13:38:58 [EMAIL PROTECTED]: ~/srcs/nci(nci)$ nm blib/lib/libparrot.so.0.7.0 
|grep store_arg

0015a810 t Parrot_store_arg
0015a760 t store_arg
13:39:20 [EMAIL PROTECTED]: ~/srcs/nci(nci)$ nm blib/lib/libparrot.a |grep 
store_arg

1840 T Parrot_store_arg
1790 t store_arg
U Parrot_store_arg
U Parrot_store_arg
U Parrot_store_arg
U Parrot_store_arg
U Parrot_store_arg
U Parrot_store_arg

Ideas, Kevin

François Perrad wrote:

2008/8/22 Kevin Tew <[EMAIL PROTECTED]>:
 

The merge has happened.




The target 'hello' seems broken :

src/exec_start.o: In function `set_nci_I':
/home/fperrad/checkout/parrot/src/jit_emit.h:96: undefined reference
to `Parrot_store_arg'
src/exec_start.o: In function `set_nci_N':
/home/fperrad/checkout/parrot/src/jit_emit.h:107: undefined reference
to `Parrot_store_arg'
src/exec_start.o: In function `set_nci_S':
/home/fperrad/checkout/parrot/src/jit_emit.h:118: undefined reference
to `Parrot_store_arg'
src/exec_start.o: In function `set_nci_P':
/home/fperrad/checkout/parrot/src/jit_emit.h:129: undefined reference
to `Parrot_store_arg'
collect2: ld returned 1 exit status

Francois.

 

Developers/Users should see no visible changes.
Please build and test, should you have any problems, just yell at me 
on #irc

or parrot-porters.
Regression test cases will be appreciated. :)
I'll try to be available until 3:00pm MDT and later this evening 
9:00pmMDT

-> until my eyelids close.

NOTE:
Jitted nci stubs are supported now on i386 linux and win32.
However jitted nci stubs are DISABLED by default.
Once we have this initial merge completed and everyone happy, I will 
enable

jitted nci stubs as the default, accompanied by another message to
parrot-porters
If you want to test jitted nci stubs uncomment tools/build
cs/nativecall.pl:308, make realclean, rinse, etc
Jitted nci stubs for x86_64 and i386 OSX are in the works but not 
present in

this current merge.
i386 OSX doesn't work with the current patch because it requires a 
16 byte

aligned stack.
Don't worry, by default configure disables jit on OSX.

Things that have changed under the covers:
1) a new makefile is being generated
+++ config/gen/makefiles.pm (working copy)
@@ -41,6 +41,8 @@
   conditioned_lines => 1,
   },

+'compilers/ncigen/Makefile'  =>
+{ SOURCE => 
'compilers/ncigen/config/makefiles/ncigen.in' },


2) nci c function stub generation has changed slightly


Kevin

Re: gsoc_nci merge

[NotFound]

On Fri, Aug 22, 2008 at 9:51 PM, Kevin Tew <[EMAIL PROTECTED]> wrote:

> 0015a810 t Parrot_store_arg
> little t means its not exported.
>
> set_nci_* functions should probably be moved elsewhere.
> as well as the Parrot_jit_build_call_func
> I found Parrot_jit_build_call_func   in   src/jit/i386/jit_emit.h, so I made
> my changes in place.

Parrot_store_arg lacked the PARROT_API attribute. Fixed in r30457

-- 
Salu2

Re: gsoc_nci merge

[Kevin Tew]

I still think too much junk is in jit_emit.h

The patch attached shows how I would re-factor it.

Kevin

NotFound wrote:

On Fri, Aug 22, 2008 at 9:51 PM, Kevin Tew <[EMAIL PROTECTED]> wrote:

  

0015a810 t Parrot_store_arg
little t means its not exported.

set_nci_* functions should probably be moved elsewhere.
as well as the Parrot_jit_build_call_func
I found Parrot_jit_build_call_func   in   src/jit/i386/jit_emit.h, so I made
my changes in place.



Parrot_store_arg lacked the PARROT_API attribute. Fixed in r30457

  


diff --git a/config/auto/jit.pm b/config/auto/jit.pm
index 8897dc3..702bdbd 100644
--- a/config/auto/jit.pm
+++ b/config/auto/jit.pm
@@ -108,7 +108,7 @@ sub runstep {
 jitcapable  => 1,
 cc_hasjit   => " -DHAS_JIT -D\U$jitcpuarch",
 TEMP_jit_o =>
-'$(SRC_DIR)/jit$(O) $(SRC_DIR)/jit_cpu$(O) $(SRC_DIR)/jit_debug$(O) $(SRC_DIR)/jit_debug_xcoff$(O)'
+'$(SRC_DIR)/jit$(O) $(SRC_DIR)/jit_cpu$(O) $(SRC_DIR)/jit_build_call$(O) $(SRC_DIR)/jit_debug$(O) $(SRC_DIR)/jit_debug_xcoff$(O)'
 );
 
 my $execcapable = $self->_first_probe_for_exec(
diff --git a/config/gen/makefiles/root.in b/config/gen/makefiles/root.in
index bc2bc15..aeed059 100644
--- a/config/gen/makefiles/root.in
+++ b/config/gen/makefiles/root.in
@@ -223,6 +223,7 @@ GEN_SOURCES = \
 $(SRC_DIR)/nci.c \
 $(SRC_DIR)/core_ops_switch.c \
 $(SRC_DIR)/jit_cpu.c \
+$(SRC_DIR)/jit_build_call.c \
 $(SRC_DIR)/parrot_config.c \
 $(SRC_DIR)/null_config.c \
 $(SRC_DIR)/install_config.c \
@@ -1053,6 +1054,8 @@ $(SRC_DIR)/jit_debug_xcoff$(O) : $(GENERAL_H_FILES)
 
 $(SRC_DIR)/jit_cpu$(O) : $(GENERAL_H_FILES) $(SRC_DIR)/jit_emit.h
 
+$(SRC_DIR)/jit_build_call$(O) : $(GENERAL_H_FILES) $(SRC_DIR)/jit_emit.h
+
 $(SRC_DIR)/exec$(O) : $(GENERAL_H_FILES) @TEMP_exec_h@ $(SRC_DIR)/jit_emit.h
 
 $(SRC_DIR)/exec_dep$(O) : $(GENERAL_H_FILES) @TEMP_exec_h@ $(SRC_DIR)/jit_emit.h
@@ -1243,6 +1246,8 @@ $(SRC_DIR)/jit_emit.h : $(SRC_DIR)/jit/@jitcpuarch@/jit_emit.h
 	$(CP) $(SRC_DIR)/jit/@jitcpuarch@/jit_emit.h $(SRC_DIR)/jit_emit.h
 $(SRC_DIR)/exec_dep.h : $(SRC_DIR)/jit/@jitcpuarch@/exec_dep.h
 	$(CP) $(SRC_DIR)/jit/@jitcpuarch@/exec_dep.h $(SRC_DIR)/exec_dep.h
+$(SRC_DIR)/jit_build_call.c : $(SRC_DIR)/jit/@jitcpuarch@/jit_build_call.c
+	$(CP) $(SRC_DIR)/jit/@jitcpuarch@/jit_build_call.c $(SRC_DIR)/jit_build_call.c
 $(SRC_DIR)/jit_cpu.c : lib/Parrot/OpLib/core.pm $(SRC_DIR)/jit_emit.h \
 $(SRC_DIR)/jit/@jitcpuarch@/core.jit $(JIT_BUILD_TOOL)
 	$(PERL) $(JIT_BUILD_TOOL) @jitcpuarch@ $(SRC_DIR)/jit_cpu.c
@@ -1669,6 +1674,7 @@ archclean: dynoplibs-clean dynpmc-clean dynext-clean
 $(SRC_DIR)/asmfun.s \
 $(SRC_DIR)/jit_emit.h \
 $(SRC_DIR)/jit_cpu.c \
+$(SRC_DIR)/jit_build_call.c \
 $(SRC_DIR)/exec_cpu.c \
 $(SRC_DIR)/exec_start$(O) \
 install_config.fpmc \
diff --git a/include/parrot/nci.h b/include/parrot/nci.h
index 1b85a73..10a133a 100644
--- a/include/parrot/nci.h
+++ b/include/parrot/nci.h
@@ -17,6 +17,27 @@
 
 void *build_call_func(PARROT_INTERP, SHIM(PMC *pmc_nci), NOTNULL(STRING *signature), NOTNULL(int *jitted));
 
+/*
+ * helper funcs - get argument n
+ */
+INTVAL get_nci_I(PARROT_INTERP, ARGMOD(call_state *st), int n);
+FLOATVAL get_nci_N(PARROT_INTERP, ARGMOD(call_state *st), int n);
+
+PARROT_WARN_UNUSED_RESULT
+PARROT_CANNOT_RETURN_NULL
+STRING* get_nci_S(PARROT_INTERP, ARGMOD(call_state *st), int n);
+
+PARROT_WARN_UNUSED_RESULT
+PARROT_CANNOT_RETURN_NULL
+PMC* get_nci_P(PARROT_INTERP, ARGMOD(call_state *st), int n);
+
+/*
+ * set return value
+ */
+void set_nci_I(PARROT_INTERP, ARGOUT(call_state *st), INTVAL val);
+void set_nci_N(PARROT_INTERP, ARGOUT(call_state *st), FLOATVAL val);
+void set_nci_S(PARROT_INTERP, ARGOUT(call_state *st), STRING *val);
+void set_nci_P(PARROT_INTERP, ARGOUT(call_state *st), PMC* val);
 #endif /* PARROT_NCI_H_GUARD */
 
 /*
diff --git a/src/jit/i386/jit_build_call.c b/src/jit/i386/jit_build_call.c
new file mode 100644
index 000..94e2e57
--- /dev/null
+++ b/src/jit/i386/jit_build_call.c
@@ -0,0 +1,367 @@
+#include "parrot/parrot.h"
+#include "parrot/hash.h"
+#include "parrot/oplib/ops.h"
+#include "jit.h"
+#define JIT_EMIT 1
+#include "jit_emit.h"
+
+static size_t
+calc_signature_needs(const char *sig, int *strings)
+{
+size_t stack_size = 0;
+while (*sig) {
+switch (*sig) {
+case 't':
+(*strings)++;
+stack_size +=4;
+break;
+case 'd':
+stack_size +=8;
+break;
+default:
+stack_size +=4;
+break;
+}
+sig++;
+}
+return stack_size;
+
+}
+/*
+ * The function generated here is called as func(interp, nci_info)
+ * interp   ...  8(%ebp)
+ * nci_info ... 12(%ebp)
+ *
+ * The generate function for a specific signature looks quite similar to
+ * an optimized compile of src/nci.c:pcf_x_yy(). In case of any troubles
+ * just compare the disassembly.
+ */

Re: [perl #58170] Exception Handler Issues

[Allison Randal]

Stephen Weeks (via RT) wrote:


There are some issues that need to be resolved for resumable exceptions.

The first issue I've run into is that Parrot_cx_find_handler_local marks
the exception handler as used when it finds it and ignores already-used
exception handlers.


This is an intentional feature for backward-compatibility, but not one 
we'll be keeping permanently.


[...]


Parrot_cx_find_handler_local uses an iterator for handlers for
Exceptions, but just walks all the handlers ignoring used ones for
everything else.  It looks like maybe if everything stored their
handlers in an iterator, as the comment suggest is possible, we could
discard the used check?


The handlers are stored in an iterator so 'rethrow' knows to pick up the 
next handler. Making non-exception events and tasks store an iterator 
for their handlers wouldn't make any difference here, since the problem 
is specifically with exceptions getting the wrong handler.


Handlers aren't marked as used to allow a single exception to iterate 
through them, they're marked as used because the existing PIR code using 
exceptions has a nasty habit of falling into infinite loops when an 
exception is thrown in the middle of handling another exception.



A few experiments into this turn up segfaults and other odd behavior.


If you dig into them, you'll find that they're caused by exception 
handlers catching exceptions that they didn't expect, and just assuming 
it's the anticipated exception. What's needed is a sweeping revision to 
existing uses of exceptions to make them check the type of the exception 
they're passed and rethrow anything they can't handle.



Maybe we need to have a 'cleanup' function for exception handlers to
call instead?


We have 'pop_eh' to manually remove exception handlers. Are you thinking 
of some other cleanup behavior? If so, what?


Allison

new method question

[Xiao Yafeng]

There are no barewords in Perl 6, but it seems new method is an exception:

class Dog {

has $name;
method bark () {
say $name;
}
}
my $p = Dog.new($name => 'boo');
  $p.bark;#error!
my $p = Dog.new( name => 'boo');
  $p.bark#say boo

more confused:

class Dog {

has @names;
method bark () {
say @names;
}
}
my $p = Dog.new(names => 'boo');
  $p.bark;#nothing but passed.

So, how set array attribute of a class by new method?

[perl #58236] [TODO][PDD19] make decision on open issue on .return directive in pdd19

[via RT]

# New Ticket Created by  Klaas-Jan Stol 
# Please include the string:  [perl #58236]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=58236 >


PDD19, line 791 reads:

The parentheses surrounding the arguments are mandatory. Besides making
sequence break more conspicuous, this is necessary to distinguish this
syntax from other uses of the C<.return> directive that will be probably
deprecated.


The open issue of the 'probably deprecation' should be decided on; what
.return directive is meant here that supposedly would be deprecated?
Will it? (any need?)

kjs

[perl #58252] [TODO][PIR] finalize open issue with "pmc" type in .const definitions

[via RT]

# New Ticket Created by  Klaas-Jan Stol 
# Please include the string:  [perl #58252]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=58252 >


The following issues are not entirely clear from PDD19:

[1]
according to PDD19 (PIR) you can declare a .const as follows:

=item .const   = 

Define a constant named I of type I and assign value
I to it. The I may be either an integer value or a string
constant. The constant is stored in the constant table of the current
bytecode file.

 stands for "int", "num", "string" or "pmc". However, writing "pmc"
does not make any sense, because  must be some literal constant, such
as 42, 3.14 or "hello"; it doesn't make sense to write:

.const pmc x = "hi" # what type will x be?

THerefore, should we allow "pmc" as a type here? I see 2 reasonable
solutions:
1: disallow "pmc" altogether
2: based on the type of the constant (int-constant, num-constant or string
constant), make the variable (eh, constant) a constant of one of the
standard types (Integer, Float or String , respectively).

[2]
you can declare a .const using a PMC class type id:

.const .Sub x = "foo"

AFAIU, type ids will be removed altogether (is this true?).
If so, then the above would be invalid.
Instead, we might allow for writing:

.const "Sub" x = "foo".

Which seems a nice enough solution, but this solution is rather limited, in
that you can't create, for instance, an Array constant:

.const "Array" a = "foo" # doesn't make sense.

I know the creation of Sub constants is useful, so we definitely should keep
something like this around.

I see the following solutions:

1: only allow pmc types that are reasonable:
- .const "Integer" x = 42
- .const "Float" PI = 3.14
- .const "String" message = "hi there"
- .const "Sub" x = "foo"

and report an error message if you would do something weird as ".const 'Env'
e = 10".

2: extend syntax for other variants, for instance, to initialize arrays and
hashtables:
- .const "Array" a = (1, 2, 3, 4) # creates a constant array with 4
elements, nrs 1 to 4
- .const "Hash" h1 = {"x"=>42, "y"=>10} ## using syntactic sugar form that
is used for named arguments as well
- .const "Hash" h2 = { 42 :named("x"), 10 :named("y") } ## to be consistent
with the above, using syntax well-known in named-arguments.

Not sure if this would be helpful/possible, but just some thoughts.

comments welcome.
kjs

Re: gsoc_nci merge

[François Perrad]

2008/8/22 Kevin Tew <[EMAIL PROTECTED]>:
> The merge has happened.
>

The target 'hello' seems broken :

src/exec_start.o: In function `set_nci_I':
/home/fperrad/checkout/parrot/src/jit_emit.h:96: undefined reference
to `Parrot_store_arg'
src/exec_start.o: In function `set_nci_N':
/home/fperrad/checkout/parrot/src/jit_emit.h:107: undefined reference
to `Parrot_store_arg'
src/exec_start.o: In function `set_nci_S':
/home/fperrad/checkout/parrot/src/jit_emit.h:118: undefined reference
to `Parrot_store_arg'
src/exec_start.o: In function `set_nci_P':
/home/fperrad/checkout/parrot/src/jit_emit.h:129: undefined reference
to `Parrot_store_arg'
collect2: ld returned 1 exit status

Francois.

> Developers/Users should see no visible changes.
> Please build and test, should you have any problems, just yell at me on #irc
> or parrot-porters.
> Regression test cases will be appreciated. :)
> I'll try to be available until 3:00pm MDT and later this evening 9:00pmMDT
> -> until my eyelids close.
>
> NOTE:
> Jitted nci stubs are supported now on i386 linux and win32.
> However jitted nci stubs are DISABLED by default.
> Once we have this initial merge completed and everyone happy, I will enable
> jitted nci stubs as the default, accompanied by another message to
> parrot-porters
> If you want to test jitted nci stubs uncomment tools/build
> cs/nativecall.pl:308, make realclean, rinse, etc
> Jitted nci stubs for x86_64 and i386 OSX are in the works but not present in
> this current merge.
> i386 OSX doesn't work with the current patch because it requires a 16 byte
> aligned stack.
> Don't worry, by default configure disables jit on OSX.
>
> Things that have changed under the covers:
> 1) a new makefile is being generated
> +++ config/gen/makefiles.pm (working copy)
> @@ -41,6 +41,8 @@
>conditioned_lines => 1,
>},
>
> +'compilers/ncigen/Makefile'  =>
> +{ SOURCE => 'compilers/ncigen/config/makefiles/ncigen.in' },
>
> 2) nci c function stub generation has changed slightly
>
>
> Kevin
>
>

whats wrong with this code?

[Andy Colson]

Hi List --

I'v started playing around with perl 6, and I am having problems with 
this example:


use v6;

sub xsum (@list)
{
my $i = 0;
print "summing: ";
for @list
{
$i += $_;
print $_,",";
}
say " = $i";
return $i;
}
say "sum = ", xsum( (1,2,3,4,5) );

It returns this:

summing: 1 2 3 4 5, = -1.2289e+09
sum = -1.2289e+09


Looks like the "for @list" has one element in it, "1 2 3 4 5".

I'v tried:

say "sum = ", xsum( (1,2,3,4,5) );

and

say "sum = ", xsum( [1,2,3,4,5] );

and

my @x = (1,2,3,4,5);
say "sum = ", xsum( @x );

I'm using:
This is Rakudo Perl 6, revision 30434 built on parrot 0.7.0-devel

Thanks,

-Andy

Re: [perl #58252] [TODO][PIR] finalize open issue with "pmc" type in .const definitions

[Will Coleda]

On Fri, Aug 22, 2008 at 11:06 AM, via RT Klaas-Jan Stol
<[EMAIL PROTECTED]> wrote:
> # New Ticket Created by  Klaas-Jan Stol
> # Please include the string:  [perl #58252]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=58252 >
>
>
> The following issues are not entirely clear from PDD19:
>
> [1]
> according to PDD19 (PIR) you can declare a .const as follows:
>
> =item .const   = 
>
> Define a constant named I of type I and assign value
> I to it. The I may be either an integer value or a string
> constant. The constant is stored in the constant table of the current
> bytecode file.
>
>  stands for "int", "num", "string" or "pmc". However, writing "pmc"
> does not make any sense, because  must be some literal constant, such
> as 42, 3.14 or "hello"; it doesn't make sense to write:
>
> .const pmc x = "hi" # what type will x be?
>
> THerefore, should we allow "pmc" as a type here? I see 2 reasonable
> solutions:
> 1: disallow "pmc" altogether
> 2: based on the type of the constant (int-constant, num-constant or string
> constant), make the variable (eh, constant) a constant of one of the
> standard types (Integer, Float or String , respectively).
>
> [2]
> you can declare a .const using a PMC class type id:
>
> .const .Sub x = "foo"
>
> AFAIU, type ids will be removed altogether (is this true?).

Yes.

> If so, then the above would be invalid.
> Instead, we might allow for writing:
>
> .const "Sub" x = "foo".

I believe this syntax already works in the branch dedicated to
destroying type ids.

> Which seems a nice enough solution, but this solution is rather limited, in
> that you can't create, for instance, an Array constant:
>
> .const "Array" a = "foo" # doesn't make sense.

I just tripped over this description of the :immediate modifier in PDD19:

=item :immediate

Execute this subroutine immediately after being compiled, which is analogous
to C in Perl 5.

In addition, if the sub returns a PMC value, that value replaces the sub in
the constant table of the bytecode file.



It goes on to describe how we can use this to create an constant PMC
of arbitrary type at compile time; I'd just advertise this method,
then we don't need any additional sugar.

> I know the creation of Sub constants is useful, so we definitely should keep
> something like this around.
>
> I see the following solutions:
>
> 1: only allow pmc types that are reasonable:
> - .const "Integer" x = 42
> - .const "Float" PI = 3.14
> - .const "String" message = "hi there"
> - .const "Sub" x = "foo"
>
> and report an error message if you would do something weird as ".const 'Env'
> e = 10".
>
> 2: extend syntax for other variants, for instance, to initialize arrays and
> hashtables:
> - .const "Array" a = (1, 2, 3, 4) # creates a constant array with 4
> elements, nrs 1 to 4
> - .const "Hash" h1 = {"x"=>42, "y"=>10} ## using syntactic sugar form that
> is used for named arguments as well
> - .const "Hash" h2 = { 42 :named("x"), 10 :named("y") } ## to be consistent
> with the above, using syntax well-known in named-arguments.
>
> Not sure if this would be helpful/possible, but just some thoughts.
>
> comments welcome.
> kjs
>



-- 
Will "Coke" Coleda

[perl #58258] The Rakudo REPL has no long-term memory

[Carl Mäsak]

# New Ticket Created by  "Carl Mäsak" 
# Please include the string:  [perl #58258]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=58258 >


Variables are not kept from one line to the other.

r30452:
$ ./perl6
> my $greeting = "hello";
> say $greeting;
Scope not found for PAST::Var '$greeting'

This breaks the rule of least surprise. It also makes the REPL a whole
lot less useful.

[perl #58246] Arrays not interpolating correctly

[via RT]

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



my @a = < 1 2 3 >;
say "@a[]";

>  "@a[]"


Broken in version 29834


clint

Re: new method question

[Moritz Lenz]

Xiao Yafeng wrote:
> There are no barewords in Perl 6, but it seems new method is an exception:
> 
> class Dog {
> 
> has $name;

Attributes need to have a twigil, so it would be
  has $.name

> method bark () {
> say $name;
> }
> }
> my $p = Dog.new($name => 'boo');

You haven't defined a variable $name in this scope, so you can't use on.

>   $p.bark;#error!
> my $p = Dog.new( name => 'boo');
>   $p.bark#say boo

the => automatically quotes the left hand side, just like in perl 5. I
see no barewords here.

This works fine with current rakudo:

class Dog {
has $.name;
method bark() {
say $.name;
}
}

my $x = Dog.new(name => 'boo');
$x.bark;

> more confused:
> 
> class Dog {
> 
> has @names;
> method bark () {
> say @names;
> }
> }
> my $p = Dog.new(names => 'boo');
>   $p.bark;#nothing but passed.
> 
> So, how set array attribute of a class by new method?

I'd expect this to work:

class Dog {
has @.names;
method bark() {
say @.names.join(', ');
}
}

my $x = Dog.new(:names);
# or: Dog.new(name => ('foo', 'bar'))
$x.bark;

but currently it doesn't in rakudo (in does in pugs though)

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Re: whats wrong with this code?

[Moritz Lenz]

Hi Andy,

you seem to have discovered a whole bunch of bugs at once :/


Andy Colson wrote:
> Hi List --
> 
> I'v started playing around with perl 6, and I am having problems with 
> this example:
> 
> use v6;
> 
> sub xsum (@list)
> {
>  my $i = 0;
>  print "summing: ";
>  for @list
>  {
>  $i += $_;
>  print $_,",";
>  }
>  say " = $i";
>  return $i;
> }
> say "sum = ", xsum( (1,2,3,4,5) );
> 
> It returns this:
> 
> summing: 1 2 3 4 5, = -1.2289e+09
> sum = -1.2289e+09
> 
> 
> Looks like the "for @list" has one element in it, "1 2 3 4 5".

Not quite. When you add these lines:
say @list.elems;
say @list.WHAT
at the start of the sub, you'll get 5 as the answer for the count, which
seems correct, and 'List' as the type, which seems weird, but I'm not
sure if it's actually wrong (normally something that starts with an @
should be an Array, but since it's a subroutine argument it's read only.
So List might be fine).

The 'for' in conjunction with this weird List is broken. This works:
my @list = (1, 2, 3, 4, 5); my @x = @list; for @x { .say }
(prints all numbers on separate lines)
but this is broken:
sub a(@b) { for @b { .say } }; my @x = (1, 2, 3); a(@x)
prints all at once.

The second problem is the result of the += operation, which does
something really weird.
When you write it as $i = $i + 1, it gives you 5, which is the number of
items in the Array $i (which is correct, if we accept the previous bug
for the moment)

I'll write bug reports for both problems to [EMAIL PROTECTED]



The recommended way to write such a sub is

sub xsum([EMAIL PROTECTED]) { ... }
xsum(1, 2, 3);

With the * before the @list it is "slurpy", which means that it doesn't
expect one list as the argument, but rather an arbitrary number of items.
If you happen to have an Array already, you can interpolate it:
my @x = 1, 2, 3;
xsum(|@x);


HTH,
Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Re: whats wrong with this code?

[Andy Colson]

Moritz Lenz wrote:

Hi Andy,

you seem to have discovered a whole bunch of bugs at once :/


Andy Colson wrote:

Hi List --

I'v started playing around with perl 6, and I am having problems with 
this example:


use v6;

sub xsum (@list)
{
 my $i = 0;
 print "summing: ";
 for @list
 {
 $i += $_;
 print $_,",";
 }
 say " = $i";
 return $i;
}
say "sum = ", xsum( (1,2,3,4,5) );

It returns this:

summing: 1 2 3 4 5, = -1.2289e+09
sum = -1.2289e+09


Looks like the "for @list" has one element in it, "1 2 3 4 5".


Not quite. When you add these lines:
say @list.elems;
say @list.WHAT
at the start of the sub, you'll get 5 as the answer for the count, which
seems correct, and 'List' as the type, which seems weird, but I'm not
sure if it's actually wrong (normally something that starts with an @
should be an Array, but since it's a subroutine argument it's read only.
So List might be fine).

The 'for' in conjunction with this weird List is broken. This works:
my @list = (1, 2, 3, 4, 5); my @x = @list; for @x { .say }
(prints all numbers on separate lines)
but this is broken:
sub a(@b) { for @b { .say } }; my @x = (1, 2, 3); a(@x)
prints all at once.

The second problem is the result of the += operation, which does
something really weird.
When you write it as $i = $i + 1, it gives you 5, which is the number of
items in the Array $i (which is correct, if we accept the previous bug
for the moment)

I'll write bug reports for both problems to [EMAIL PROTECTED]



The recommended way to write such a sub is

sub xsum([EMAIL PROTECTED]) { ... }
xsum(1, 2, 3);

With the * before the @list it is "slurpy", which means that it doesn't
expect one list as the argument, but rather an arbitrary number of items.
If you happen to have an Array already, you can interpolate it:
my @x = 1, 2, 3;
xsum(|@x);


HTH,
Moritz



Cool, thanks for the help there.

> The recommended way to write such a sub is
>
> sub xsum([EMAIL PROTECTED]) { ... }
> xsum(|@x);

Ahh, but, if I already had a list, would that flatten and then rebuild 
the list, correct? (and would, effectively, make a copy of the list?) 
(vs. just passing the list?) (just passing a list like that passes a 
reference, right? and wont make a new copy?)


Thanks,

-Andy

Re: [perl #58246] Arrays not interpolating correctly

[Patrick R. Michaud]

On Fri, Aug 22, 2008 at 07:05:00AM -0700, Clinton Gormley wrote:
> 
> my @a = < 1 2 3 >;
> say "@a[]";
> >  "@a[]"
> 
> Broken in version 29834

Correct, rakudo doesn't yet know how to interpolate arrays
or hashes in double-quoted strings.  This requires a change
to the quote expression parser (which may or may not wait
for us to start using more STD.pm-like parsing).

However, curly interpolation *does* currently work, so one can do
the following instead:

> my @a = < 1 2 3 >; say "@a = [EMAIL PROTECTED]";
@a = 1 2 3

Pm

Re: [perl #58278] [BUG] Slurpy params give "Cannot morph a Perl6Scalar." error

[Moritz Lenz]

> r30449:
> 
>> sub a([EMAIL PROTECTED]) { say @b.elems }; a(1, 2, 3)
> Cannot morph a Perl6Scalar.
> 
> Note that the passing itself doesn't throw an error:
> 
>> sub a([EMAIL PROTECTED]) {  }; a(1, 2, 3)
>>
> 
> Clearly we need more tests...

Now added test in t/spec/S06-signature/slurpy-params.t which rakudo all
fails

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Re: whats wrong with this code?

[Patrick R. Michaud]

On Fri, Aug 22, 2008 at 04:34:04PM -0500, Andy Colson wrote:
> sub xsum (@list)
> {
> my $i = 0;
> print "summing: ";
> for @list
> {
> $i += $_;
> print $_,",";
> }
> say " = $i";
> return $i;
> }
> say "sum = ", xsum( (1,2,3,4,5) );
>
> It returns this:
>
> summing: 1 2 3 4 5, = -1.2289e+09
> sum = -1.2289e+09

I suspect that Rakudo is having trouble binding array parameters
at the moment -- so it's likely a bug in the parameter handling code
(which I'm expecting will need some refactoring soon anyway).  I'm
guessing that Rakudo is binding @list as if it is a Scalar Array,
and thus the for loop sees only one element.

This probably deserves a tracking ticket at <[EMAIL PROTECTED]>.

Pm

Re: whats wrong with this code?

[Moritz Lenz]

Patrick R. Michaud wrote:
> On Fri, Aug 22, 2008 at 04:34:04PM -0500, Andy Colson wrote:
>> sub xsum (@list)
>> {
>> my $i = 0;
>> print "summing: ";
>> for @list
>> {
>> $i += $_;
>> print $_,",";
>> }
>> say " = $i";
>> return $i;
>> }
>> say "sum = ", xsum( (1,2,3,4,5) );
>>
>> It returns this:
>>
>> summing: 1 2 3 4 5, = -1.2289e+09
>> sum = -1.2289e+09
> 
> I suspect that Rakudo is having trouble binding array parameters
> at the moment -- so it's likely a bug in the parameter handling code
> (which I'm expecting will need some refactoring soon anyway).  I'm
> guessing that Rakudo is binding @list as if it is a Scalar Array,
> and thus the for loop sees only one element.
> 
> This probably deserves a tracking ticket at <[EMAIL PROTECTED]>.

Already wrote one:

[perl #58276] AutoReply: [BUG] Can't iterate over list that was passed
as a subroutine argument

Cheers,
Moritz

-- 
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

Re: whats wrong with this code?

[Larry Wall]

On Fri, Aug 22, 2008 at 05:30:19PM -0500, Andy Colson wrote:
> Moritz Lenz wrote:
> > The recommended way to write such a sub is
> >
> > sub xsum([EMAIL PROTECTED]) { ... }
> > xsum(|@x);
>
> Ahh, but, if I already had a list, would that flatten and then rebuild  
> the list, correct? (and would, effectively, make a copy of the list?)  
> (vs. just passing the list?) (just passing a list like that passes a  
> reference, right? and wont make a new copy?)

If bound to a list context (such as provided in this case by the
slurpy parameter), the | is relatively useless, since the @x would
flatten anyway.  In other words, there's little difference between
xsum(@x) and xsum(1,2,3,4,5) unless the signature tries to bind the
first argument to a scalar.  Whether one syntax or the other would
result in less work, or whether it'd compile down to the same code,
probably depends on how much the compiler guesses about the eventual
signature at compile time, so I couldn't guess which would be faster.
I do think xsum(@x) is probably clearer, especially if you're already
thinking of it as slurpy.  The use of | generally means you're trying
to cheat on the scalar parameters somehow.  It's not needed in list
context.

Larry

[perl #58244] inheritance of attributes

[Stephen Simmons]

# New Ticket Created by  "Stephen Simmons" 
# Please include the string:  [perl #58244]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=58244 >


In Apocalypse 12, inheritance of attributes is described, though I couldn't
find it in Synopsis 12.  Since "inheritance" is on the list of things that
is now supported, I started playing around with it and found that
inheritance of methods is supported but that inheritance of attributes is
not.
The file inheritance bug 1 segfaults, but inheritance bug 2, which is a
simplified version, just produce an MMD function error.

Here is the output from 1:

sully:parrot-0.7.0 stephensimmons$ perl6 ../ooxp/inheritance_bug1.p6
3,4
4,4
3,
Now to try display_twice
4,4
4,4
,
1
MMD function __i_subtract not found for types (78, 92)
current instr.: 'parrot;Rectangle;size' pc 1309 (EVAL_15:415)
called from Sub '_block11' pc 308 (EVAL_15:89)
called from Sub 'parrot;PCT::HLLCompiler;eval' pc 806
(src/PCT/HLLCompiler.pir:481)
called from Sub 'parrot;PCT::HLLCompiler;evalfiles' pc 1078
(src/PCT/HLLCompiler.pir:610)
called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1257
(src/PCT/HLLCompiler.pir:699)
called from Sub 'parrot;Perl6::Compiler;main' pc 15352 (perl6.pir:172)
perl6(43278) malloc: *** error for object 0x3441d80: double free
*** set a breakpoint in malloc_error_break to debug
Segmentation fault


Here is the output from 2:

sully:parrot-0.7.0 stephensimmons$ perl6 ../ooxp/inheritance_bug2.p6
Classes defined.
Rectangle generated.
,
Rectangle displayed.
MMD function __i_subtract not found for types (78, 92)
current instr.: 'parrot;Rectangle;size' pc 755 (EVAL_15:236)
called from Sub '_block11' pc 141 (EVAL_15:43)
called from Sub 'parrot;PCT::HLLCompiler;eval' pc 806
(src/PCT/HLLCompiler.pir:481)
called from Sub 'parrot;PCT::HLLCompiler;evalfiles' pc 1078
(src/PCT/HLLCompiler.pir:610)
called from Sub 'parrot;PCT::HLLCompiler;command_line' pc 1257
(src/PCT/HLLCompiler.pir:699)
called from Sub 'parrot;Perl6::Compiler;main' pc 15352 (perl6.pir:172)


Machine details:
Darwin sully.local 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun  9 19:30:53
PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386

parrot revisions 30424 and 30440

Stephen Simmons


inheritance_bug1.p6
Description: Binary data


inheritance_bug2.p6
Description: Binary data

Re: new method question

[John M. Dlugosz]

Moritz Lenz moritz-at-casella.verplant.org |Perl 6| wrote:

Attributes need to have a twigil, so it would be
  has $.name

  


The syntax
   has $name;
with no twigil is legal according to S12.  Perhaps the original poster 
(Xiao Yafeng) might like to read 
.


--John

[perl #58238] [PROPOSAL][PIR] remove special handling of "addr" -> set_addr instruction mapping

[via RT]

# New Ticket Created by  Klaas-Jan Stol 
# Please include the string:  [perl #58238]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=58238 >


Parrot has an instruction called 'set_addr', that stores the address of a
label into an integer register.
IMCC (and pdd19_pir) defines a short-cut for this op, called 'addr'.

$I0 = addr XYZ


I propose to remove this shortcut; should anybody want to use it, just use
the full opname: $I0 = set_addr XYZ (or, which may look a bit better:
set_addr $I0, XYZ)
The rationale behind this proposal is as follows:

* This instruction is specially handled in the PIR compiler (IMCC). It is
true that IMCC needs to handle certain ops as a special case, where PASM and
PIR overlap; for instance, the 'if' op. No such overlap is present for
'addr'. Having special cases is fine if it's necessary, but otherwise it
makes the code more complex.
The rationale for having a special case for this instruction might lie in
the far history of Parrot; I seem to remember, years ago, that one needed
addresses to make sub calls. My memory may be wrong, though. Having a
special case for a much-used feature is, according to the Huffman coding
design principle, a good thing: make things that happen frequently
easier/shorter; but: (reason 2)

* A quick ack told me that this instruction is barely used, if any (did not
do any detailed inspection, though).

comments welcome, as always.
kjs

Re: [perl #53976] [PATCH] Remove tools/dev/ops_renum.mak

[Will Coleda]

On Sat, Aug 16, 2008 at 11:39 PM, James Keenan via RT
<[EMAIL PROTECTED]> wrote:
> The patch attached, diff.trunk.opsrenum.txt, is an improved solution to
> the problem posed by Coke in the OP of this RT.  Here are its features,
> working from the surface (e.g., file name changes) down to the method
> that does the renumbering of opcodes.
>
> 1.  Renames lib/Parrot/Ops2pm/Utils.pm to lib/Parrot/Ops2pm.pm.  Renames
> the directory where the tests for this package are found from
> t/tools/ops2pmutils/ to t/tools/ops2pm.  Makes appropriate changes in
> names within files.
>
> 2.  Takes the method that did -- and continues to do -- the rewriting of
> the ops.num file, renum_op_map_file(), out of lib/Parrot/Ops2pm.pm and
> places it in its own module, lib/Parrot/OpsRenumber.pm.  This is done so
> that the methods that are used in tools/build/ops2pm.pl are found in one
> package while the method used in tools/dev/opsrenumber.pl is placed in a
> package of its own.
>
> 3.  Two methods that are used in both lib/Parrot/Ops2pm.pm and
> lib/Parrot/OpsRenumber.pm are extracted and placed in a module of their
> own:  lib/Parrot/Ops2pm/Base.pm.  Those methods are new() (the
> constructor) and prepare_ops() (which invokes Parrot::OpsFile, which
> does the actual parsing of ops files).

So far, all generic refactoring which is fine.

> 4.  Parrot::OpsRenumber::renum_op_map_file() has been revised so that it
> will behave properly before Parrot 1.0 -- when deletion of opcodes is
> still permitted -- and after 1.0 -- when no deletions are permitted.
> This flexibility is attained by providing it with the Parrot major
> version as an argument.  This before-and-after functionality is tested
> in a heavily revised t/tools/ops2pm/05-renum_op_map_file.t.  Several new
> sample files used in testing have been added to the distribution.

I know you were implementing Jerry's requirement here, and that's good.

I do wonder what the plan is for opcodes that are marked deprecated
(which we can do today.) ; once they go past deprecated (before 1.0,
we'd just delete them), what will happen when they are executed? will
we add a :removed pragma on the opcode definition that will simply
throw an exception when they are invoked? Will we just silently
translate them to a noop?

What about the case when we experimentally add an opcode between
official releases, but back it out before the next release? What
counts as an official release? How are we going to number the
intervening releases? Do we have a version indicator to mark as
stable/unstable/experimental/Don't Touch This Without A Hazmat Suit?

What about experimental.ops? is that going to survive with its special
treatment into post-1.0?

I apologize for not asking these questions immediately following
Jerry's original post, but I thought I had until version 0.99 to think
about it. =-)

These questions asked... I'm don't think they block application of the
patch at all; I think these are all questions that should be answered
in a new docs/project/release_strategy.pod which can then spawn TODOs
as necessary.

> 5.  The name of the program that invokes Parrot::OpsRenumber is changed
> from tools/dev/ops_renum.mak to tools/dev/opsrenumber.pl.  It is, after
> all, a Perl 5 program, so we provide it with a file name extension
> consistent with other programs in tools/dev/.
>
> 6.  A new makefile target, renumberops, invokes tools/dev/opsrenumber.pl.
>
> Please review, particularly lib/Parrot/OpsRenumber.pm and
> t/tools/ops2pm/05-renum_op_map_file.t, which is where most of the really
> new stuff is found and/or demonstrated.

I don't have any questions regarding these tests that are unique to
these particular tests.

> This patch probably does not do
> what Coke requested in the OP, but I don't actually know how to do that.

That is lost in the mists of time, but I'm pretty sure I was looking
for a way to make the dependencies smarter here so we didn't have to
remember to run it. That probably conflicts with Jerry's post-1.0
strictures, however, so I'm not entirely sure that it's relevant
anymore. However, the fact that it's a standard perl script now
instead of a unixy makefile...

>  But this refactoring should get us closer to that objective.

...Exactly.

VMNWIHTEM[0]: The copyright in a lot of the new files seems to be
2007. Should it be 2008?

> Thank you very much.
> kid51
>
>

Thank you for digging into this.

[0] Very Minor Nit Which I Hate To Even Mention


-- 
Will "Coke" Coleda

Re: [perl #53976] [PATCH] Remove tools/dev/ops_renum.mak

[jerry gay]

On Fri, Aug 22, 2008 at 7:20 PM, Will Coleda <[EMAIL PROTECTED]> wrote:
> On Sat, Aug 16, 2008 at 11:39 PM, James Keenan via RT
>> 4.  Parrot::OpsRenumber::renum_op_map_file() has been revised so that it
>> will behave properly before Parrot 1.0 -- when deletion of opcodes is
>> still permitted -- and after 1.0 -- when no deletions are permitted.
>> This flexibility is attained by providing it with the Parrot major
>> version as an argument.  This before-and-after functionality is tested
>> in a heavily revised t/tools/ops2pm/05-renum_op_map_file.t.  Several new
>> sample files used in testing have been added to the distribution.
>
> I know you were implementing Jerry's requirement here, and that's good.
>
> I do wonder what the plan is for opcodes that are marked deprecated
> (which we can do today.) ; once they go past deprecated (before 1.0,
> we'd just delete them), what will happen when they are executed? will
> we add a :removed pragma on the opcode definition that will simply
> throw an exception when they are invoked? Will we just silently
> translate them to a noop?
>
> What about the case when we experimentally add an opcode between
> official releases, but back it out before the next release? What
> counts as an official release? How are we going to number the
> intervening releases? Do we have a version indicator to mark as
> stable/unstable/experimental/Don't Touch This Without A Hazmat Suit?
>
> What about experimental.ops? is that going to survive with its special
> treatment into post-1.0?
>
> I apologize for not asking these questions immediately following
> Jerry's original post, but I thought I had until version 0.99 to think
> about it. =-)
>
> These questions asked... I'm don't think they block application of the
> patch at all; I think these are all questions that should be answered
> in a new docs/project/release_strategy.pod which can then spawn TODOs
> as necessary.
>
agreed. we still have time to address these questions. it would be
nice if they weren't lost, though. i suggest a wiki page rather than a
mess of rt tickets for better tracking at this point. seems to me that
the wiki approach will allow us to collect and organize these thoughts
as they occur, and serve as a solid draft when we formalize them
later.

>> 5.  The name of the program that invokes Parrot::OpsRenumber is changed
>> from tools/dev/ops_renum.mak to tools/dev/opsrenumber.pl.  It is, after
>> all, a Perl 5 program, so we provide it with a file name extension
>> consistent with other programs in tools/dev/.
>>
>> 6.  A new makefile target, renumberops, invokes tools/dev/opsrenumber.pl.
>>
>> Please review, particularly lib/Parrot/OpsRenumber.pm and
>> t/tools/ops2pm/05-renum_op_map_file.t, which is where most of the really
>> new stuff is found and/or demonstrated.
>
> I don't have any questions regarding these tests that are unique to
> these particular tests.
>
it strikes me that the makefile target and the script name should be
the same. there's still too much irregularity in parrot's naming
conventions across the board--opcodes, pir syntax, makefiles, scripts,
directories, filenames, c functions, etc.

we'll concentrate on this in earnest as we approach our first general
availability release (whether we call that release 1.0 or 2009R1 or
"Ball of Mud"), however there's no reason to hold off. if anybody sees
anything that looks a bit out of place (e.g. dynops vs. dynoplibs)
take note of it by opening a CAGE ticket in rt. it may take some
project team input to settle upon the preferred naming convention, but
implementing that work can be done by any contributor and applied by
any committer.

~jerry