Re: [PATCH] Three pushaction bugs
On Jan 5, 2006, at 3:26, Bob Rogers wrote: This patch fixes two find_exception_handler bugs, and identifies a third, all related to executing pushaction subs: Applied - r10902 1. It is necessary to wait until after popping the action before calling it, lest the signalling of another error during action execution causes you to lose, and lose, and lose, . . . Good catch. 2. Even without an error, it seems that actions could sometimes be run twice because stack_pop compared entry-cleanup to 0 instead of STACK_CLEANUP_NULL. (I can't reproduce this now, so it probably depended on something else as well.) Well, STACK_CLEANUP_NULL is ((Stack_cleanup_method)NULLfunc), which is the same as 0 on all current platforms (AFAIK), but your patch is of course correct. 3. Actions are not run at all if the context is skipped by calling a continuation. This is a deeper problem, so I've just added a TODO test in order to document it as a known problem; I hope to fix this in the course of implementing dynamic binding. It should work, when implementing the stack unwinding in Continuation.invoke (which is also called by Exception_handler.invoke). Now the question arises: what to do on the 2nd time the sub is running. There are probably 2 options: a) user code has to reenable exception handlers and cleanup actions, i.e. above stack unwinding is permanent b) the control stack remains unchanged, all exception handlers and cleanup actions are still in place. TIA, I thank you, leo
Revisiting parrot_get_config_string
Guys,
I shall shortly update the relevant calls, but I'd just like to check
a few things first.
These patches update the patches in #37303 and #36836, relating to
parrot_get_config_string and cygwin dynclasses.
The first patch modifies the parrot VM so as not to call
parrot_get_config_string on startup, which currently resides in the
calling executable. Instead, the executable (optionally) calls
Parrot_set_config_hash to set the config environment.
A couple of questions arise:
* Currently only the interpreter that is explicitly created by the
application will have configuration settings. What's the best way to
make sure that each interpreter will have access to it? Will future
Interpreters clone the environment, or will it explicitly need to be
set on each new interpreter? (If need be, I can preserve the hash in
the VM and seed future interpreters with it)
* The function call parrot_get_config_hash is shared between the
*_config.o object files and the calling executable (but *not* the VM
itself). What's the most suitable header file to declare it in?
There was talk the other day about whether install_config.o needed to
be distributed in a dev distribution, and while the answer is still
yes, after these changes it becomes up to the application as to
whether it needs to link with it.
A solution to the dynclasses on cygwin (and mingw?) [#36836] issue
becomes possible with these patches, and yesterday's shared library
work. Since (as far as I'm aware) cygwin doesn't have rpath
functionality, it is necessary to add blib/lib to the PATH for it to
find the parrot DLL.
Cheers,
Nick
Index: src/pbc_merge.c
===
--- src/pbc_merge.c (revision 10901)
+++ src/pbc_merge.c (working copy)
@@ -37,7 +37,9 @@
#include parrot/embed.h
#include parrot/oplib/ops.h
+extern PMC* parrot_get_config_hash(Interp* interpreter);
+
/* This struct describes an input file. */
struct pbc_merge_input
{
@@ -725,6 +727,8 @@
Parrot_init(interpreter);
Parrot_block_DOD(interpreter);
+Parrot_set_config_hash (interpreter, parrot_get_config_hash (interpreter));
+
/* Get options, ensuring we have at least one input
file and an output file. */
if (argc 4) {
Index: src/global_setup.c
===
--- src/global_setup.c (revision 10901)
+++ src/global_setup.c (working copy)
@@ -28,21 +28,6 @@
/* These functions are defined in the auto-generated file core_pmcs.c */
extern void Parrot_initialize_core_pmcs(Interp *interp);
-static void
-create_config_hash(Interp *interpreter, PMC *iglobals)
-{
-STRING *config = parrot_get_config_string(interpreter);
-PMC *hash;
-
-if (config) {
-hash = Parrot_thaw(interpreter, config);
-}
-else
-hash = pmc_new(interpreter, enum_class_Hash);
-VTABLE_set_pmc_keyed_int(interpreter, iglobals,
-(INTVAL) IGLOBALS_CONFIG_HASH, hash);
-
-}
/*
=item Cvoid init_world(Interp *interpreter)
@@ -63,8 +48,8 @@
void
init_world(Interp *interpreter)
{
-PMC *iglobals;
PMC *self, *pmc;
+PMC *iglobals, *config_hash;
#ifdef PARROT_HAS_PLATFORM_INIT_CODE
Parrot_platform_init_code();
@@ -91,11 +76,14 @@
PMC_data(self) = interpreter;
VTABLE_set_pmc_keyed_int(interpreter, iglobals,
(INTVAL) IGLOBALS_INTERPRETER, self);
+
+/* Initialise the Interpreter with an empty config
+ hash. Applications will call Parrot_set_config_hash */
+config_hash = pmc_new(interpreter, enum_class_Hash);
+VTABLE_set_pmc_keyed_int(interpreter, iglobals,
+(INTVAL) IGLOBALS_CONFIG_HASH, config_hash);
+
/*
- * create runtime config hash
- */
-create_config_hash(interpreter, iglobals);
-/*
* HLL support
*/
if (interpreter-parent_interpreter)
@@ -121,6 +109,16 @@
IGLOBALS_DYN_LIBS, pmc);
}
+
+void Parrot_set_config_hash(Interp* interpreter, PMC * config_hash)
+{
+PMC *iglobals = interpreter-iglobals;
+
+VTABLE_set_pmc_keyed_int(interpreter, iglobals,
+(INTVAL) IGLOBALS_CONFIG_HASH, config_hash);
+}
+
+
/*
=back
Index: tools/build/parrot_config_c.pl
===
--- tools/build/parrot_config_c.pl (revision 10901)
+++ tools/build/parrot_config_c.pl (working copy)
@@ -7,7 +7,7 @@
=head1 NAME
-tools/build/parrot_config_c.pl - Create src/parrot_config.c
+tools/build/parrot_config_c.pl - Create src/parrot_config.c and variants
=head1 SYNOPSIS
@@ -17,18 +17,22 @@
=head1 DESCRIPTION
-Create Fsrc/parrot_config.c with relevant runtime fro the config
-process. The created string contains a frozen image of the config hash.
+Create Fsrc/parrot_config.c with relevant runtime for the config
+process.
-For miniparrot a fake config file is written that contains just the interface.
+Calling the generated
Re: Revisiting parrot_get_config_string
Nick Glencross wrote: Guys, I shall shortly update the relevant calls, but I'd just like to check a few things first. These patches update the patches in #37303 and #36836, relating to parrot_get_config_string and cygwin dynclasses. The first patch modifies the parrot VM so as not to call parrot_get_config_string on startup, which currently resides in the calling executable. Instead, the executable (optionally) calls Parrot_set_config_hash to set the config environment. Looks good. A couple of questions arise: * Currently only the interpreter that is explicitly created by the application will have configuration settings. What's the best way to make sure that each interpreter will have access to it? Will future Interpreters clone the environment, or will it explicitly need to be set on each new interpreter? (If need be, I can preserve the hash in the VM and seed future interpreters with it) This question of course arises with a lot more interpreter structures, the config hash is just one of these. For the config hash my answer is: config is read-only, non-mutable, therefore it should be created as a constant, read-only hash, which of course means that keys and values are also constant and read-only. The little problem is that we don't have interfaces yet and the necessary API calls, to create such a hash. Anyway, read-only items can easily be shared between multiple interpreters and threads. * The function call parrot_get_config_hash is shared between the *_config.o object files and the calling executable (but *not* the VM itself). What's the most suitable header file to declare it in? There should be just one API call ... Parrot_set_config_hash (interpreter); ... which calls parrot_get_config_* [1], the prototype should be in embed.h. [1] It's probably simpler to just return the config bytes and the length, so that parrot_config.c doesn't need any parrot headers (which possibly pull in some extern globals like _environ). That is Parrot_set_config_hash() calls parrot_get_config_bytes, converts to string, thaws it and sets the config hash. There was talk the other day about whether install_config.o needed to be distributed in a dev distribution, and while the answer is still yes, after these changes it becomes up to the application as to whether it needs to link with it. Good. A solution to the dynclasses on cygwin (and mingw?) [#36836] issue becomes possible with these patches, and yesterday's shared library work. Since (as far as I'm aware) cygwin doesn't have rpath functionality, it is necessary to add blib/lib to the PATH for it to find the parrot DLL. Or set LD_LIBRARY_PATH ? Cheers, Nick leo
Re: Revisiting parrot_get_config_string
On 1/5/06, Leopold Toetsch [EMAIL PROTECTED] wrote: Nick Glencross wrote: The first patch modifies the parrot VM so as not to call parrot_get_config_string on startup, which currently resides in the calling executable. Instead, the executable (optionally) calls Parrot_set_config_hash to set the config environment. Looks good. Thanks. As an aside, I noticed that Darwin was initially a bit funny about this yesterday, but managed to overcome it with a linker flag. A couple of questions arise: snip... * The function call parrot_get_config_hash is shared between the *_config.o object files and the calling executable (but *not* the VM itself). What's the most suitable header file to declare it in? There should be just one API call ... Parrot_set_config_hash (interpreter); ... which calls parrot_get_config_* [1], the prototype should be in embed.h. Ah, but that's reverting it back to how it was, as the parrot VM is calling back out again to a function in user code. I certainly considered having the *_config.c files continue to return the config bytes, but this felt nicer to me. How about I meet you half way: * The *_config.c files give access to the config bytes * The harness calls the VM with the bytes (which can now be done before the interpreter starts up) * The VM records a pointer to the bytes (and length) * When an interpreter starts, it can either create its own hash, or refer to one hanging off another interpreter (whichever model ends up being used) Since (as far as I'm aware) cygwin doesn't have rpath functionality, it is necessary to add blib/lib to the PATH for it to find the parrot DLL. Or set LD_LIBRARY_PATH ? LD_LIBRARY_PATH is used by dlopen, but not for DLLs that you are directly linked against by the looks of it. I'll cut another patch when I've made some changes... Nick
[perl #38156] [PATCH] Shared libraries on MacOS
# New Ticket Created by Nick Glencross
# Please include the string: [perl #38156]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38156
Thanks to everyone, particularly rafl, for getting shared libraries
in. I hope that it hasn't been too painful, and that we get support
for most platforms.
Here's a patch which provides initial support for Darwin. I've only
just got a Mac, so am learning as I go along (e.g.
http://fink.sourceforge.net/doc/porting/porting.en.html)
I've basically added a way to suppress the -rpath flag when building
shared libraries, and done a -install_name to do the rpath
functionality (but on the library, not the executable that links with
it; hence the inconsistency that I'm going to mention now).
For simplicity, I've gone and broken my own naming convention for
config variables. In the next day or so I'll probably submit a patch
to change some of the names,
e.g. libparrot_soname - ld_libparrot_share_flags
rpath_blib - link_libparrot_share_executable
[or /something/ like that]
Hence they describe where they are used, not what they contain.
Cheers,
Nick
Index: config/inter/libparrot.pm
===
--- config/inter/libparrot.pm (revision 10892)
+++ config/inter/libparrot.pm (working copy)
@@ -51,7 +51,7 @@
);
$conf-data-set(
-rpath_blib = ($libparrot_is_shared)
+rpath_blib = ($libparrot_is_shared) $conf-data-get('rpath')
?
$conf-data-get('rpath') .
$conf-data-get('build_dir') .
Index: config/init/hints/darwin.pm
===
--- config/init/hints/darwin.pm (revision 10892)
+++ config/init/hints/darwin.pm (working copy)
@@ -34,10 +34,21 @@
load_ext= '.bundle',
link= 'c++',
ld = 'c++',
-ld_share_flags = '-dynamiclib',
+ld_share_flags = '-dynamiclib -undefined suppress',
ld_load_flags = '-bundle -undefined suppress',
memalign= 'some_memalign',
-libparrot_is_shared = 0,
+libparrot_is_shared = 1,
+rpath = '',
+
+# This variable needs renaming to be more general
+libparrot_soname= -install_name .
+ $conf-data-get('build_dir') .
+ $conf-data-get('slash') .
+ $conf-data-get('blib_dir') .
+ $conf-data-get('slash') .
+ libparrot .
+ $conf-data-get('share_ext')
+
);
}
libparrot improvements
Hello Guys, Yesterday I commited some changes to the libparrot handling. Those introduced the behavior to only build a static XOR a shared library. This may break other related software that relies upon blib/lib/libparrot.a. Also it's an advantage to have both static and shared libraries installed. Executables are linked against one of them, preferably the shared one. Here's a patch that addresses this issue that ^conner already raised when Nick Glencross posted his initial libparrot improvement patches to p6i. http://files.perldition.org/libparrot.diff Comments welcome, Flo -- BOFH excuse #30: positron router malfunction signature.asc Description: Digital signature
[perl #38158] [PATCH] A small update to CREDITS
# New Ticket Created by Nick Glencross # Please include the string: [perl #38158] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38158 Index: CREDITS === --- CREDITS (revision 10905) +++ CREDITS (working copy) @@ -335,11 +335,11 @@ D: Building and platform compat and more. N: Nick Glencross -D: Bugfixes to trace and more. -D: fixes file perms for hpux cygwin in config/gen/makefiles/dynclasses_pl -D: A patch to skip tests that hang on hp-ux in t/pmc/nci.t -D: The example circle.pir +D: Various low hanging bug fixes +D: Build and smoke fixes for HP-UX and cygwin +D: Some examples, such as circle.pir and MD5.pir E: [EMAIL PROTECTED] +E: [EMAIL PROTECTED] N: Nick Kostirya D: Win32, FreeBSD build fixes People have been kind enough to add me to the Credits, but I think that it's time to paraphrase things, Cheers, Nick
Re: Junctions again (was Re: binding arguments)
On 1/4/06, Luke Palmer [EMAIL PROTECTED] wrote:
Of course, this was introduced for a reason:
sub min($x,$y) {
$x = $y ?? $x !! $y
}
sub min2($x, $y) {
if $x = $y { return $x }
if $x $y { return $y }
}
In the presence of junctions, these two functions are not equivalent.
In fact, it is possible that both or neither of the conditionals
succeed in min2(), meaning you could change the order of the if
statements and it would change the behavior. This is wacky stuff, so
we said that you have to be aware that you're using a junction for
safety.
But now I'm convinced, but I've failed to convince anyone else, that
the behavior's being wacky doesn't mean that it should be declared,
but that the behavior is just plain wrong. I figure that if something
says it's totally ordered (which junctions do simply by being allowed
arguments to the = function), both of these functions should always
be the same. The fact is that junctions are not totally ordered, and
they shouldn't pretend that they are.
To me, this implies that junctions don't have a complete definition.
Either they're ordered or they're not. Either I can put them in a =
expression and it makes sense or I can't. If it makes sense, then that
implies that if $x = $y is true, then $x $y is false. Otherwise,
the definitions of = and have been violated.
And, if I can't put them in a =, then Perl should complain very
loudly, just as if I put something else that shouldn't be put into =,
like a Person object. If I call min() or min2() with a Person object
and an array, I should expect loud complaints from the runtime. If a
junction cannot behave itself in a numeric comparison, then similar
complaints should be made.
Rob
Re: libparrot improvements
On 1/5/06, Florian Ragwitz [EMAIL PROTECTED] wrote: Hello Guys, Yesterday I commited some changes to the libparrot handling. Those introduced the behavior to only build a static XOR a shared library. This may break other related software that relies upon blib/lib/libparrot.a. Also it's an advantage to have both static and shared libraries installed. Executables are linked against one of them, preferably the shared one. Here's a patch that addresses this issue that ^conner already raised when Nick Glencross posted his initial libparrot improvement patches to p6i. The patch looks good, and an improvement. The only slight gotcha I can see by skimming it, it that it is possible to do a build with a shared parrot, rerun Configure choosing static (without doing a make clean), but the old shared library might be left behind and parrot will link to it. I can see that it can be more important to provide both libraries (and things can be worked around), so I give the thumbs up. Nick
Re: pkgsrc build
On Tue, Jan 03, 2006 at 03:33:36PM -0800, jerry gay wrote: On 1/3/06, Leopold Toetsch [EMAIL PROTECTED] wrote: Recently on IRC: Debolaz leo: You can see the patches I made at http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/parrot/patches/ Debolaz The only one that's really needed to make things compile is patch-ac, but patch-ad might be of some interest. Folks, please check these patches and consider issues integration into parrot trunk. patch-aa (to MANIFEST) performs some well-needed cleanup, and seems accurate. i suggest it gets applied. I also thought that way and applied it. patch-ab (to MANIFEST.generated) removes some filenames of files that are not built by the default make target, but are built by the parrot_utils target. i believe these files should not be removed from MANIFEST.generated. the remainder of the patch performs necessary cleanup, and should be applied. I applied the cleanup part. The *_shared entries aren't in MANIFEST.generated anymore. They are replaced by installable_* which may be shared or static, depending on the configuration. patch-ac is freebsd-specific, i have no reason to disagree with it's accuracy or appropriateness. if it works, it should be applied. I don't have a clue about freebsd. Can some freebsd people confirm that it works and is portable enough? i have no comment on patch-ad. i have no idea what the naming conventions for shared binaries should be. We don't have *_shared executables anymore. This patch isn't needed anymore. Regards, Flo -- BOFH excuse #146: Communications satellite used by the military for star wars. signature.asc Description: Digital signature
Re: Junctions again (was Re: binding arguments)
Rob Kinyon wrote:
To me, this implies that junctions don't have a complete definition.
Either they're ordered or they're not. Either I can put them in a =
expression and it makes sense or I can't. If it makes sense, then that
implies that if $x = $y is true, then $x $y is false. Otherwise,
the definitions of = and have been violated.
I'll beg to differ. If you insist on that kind of restriction on
Junctions, they won't be able to serve their original (and primary)
purpose of aggragating comparison tests together. Remember:
if $x = 1 5 {...}
is intended to be 'shorthand' for
if $x = 1 $x = 5 {...}
Therefore,
$x = 3;
if $x = 1 5 {say 'smaller'}
if $x 1 5 {say 'larger'}
should produce exactly the same output as
$x = 3;
if $x = 1 $x = 5 {say 'smaller'}
if $x 1 $x 5 {say 'larger'}
If it doesn't, then Junctions are useless and should be stricken from Perl 6.
And the definition of '' is greater than, not not (less than or
equal to). The latter is a fact derived from how numbers and letters
behave, not anything inherent in the comparison operator. Just like
'=' is less than or equal to, as opposed to not greater than.
You aren't violating the definitions of = and by failing to insist
that they be logical negations of each other; you're only violating
the common wisdom.
--
Jonathan Dataweaver Lang
Re: binding arguments
Ingo Blechschmidt skribis 2005-12-25 17:37 (+0100): I disagree about binding only being a language thing: I fail to see how your example code illustrates your disagreement. return 42 if (my $short := $long_parameter_name) == $specialcase; That's terribly horrible style! push @foo, (my $head := pop @grtz); A bit better style, but I'd still recommend against it. (Unless of course, you consider this to be obfuscation.) Not obfuscation, but horrible style. You're doing something in an expression that has no effect on what happens in the expression itself. ($bar = $foo) =~ s/// is useful because you need a copy, and the inline copying is a clear indication of $bar's function: to be $foo in its state after s///. The same thing with := instead of = would be horrible, because $bar and $foo would be the same thing, during and after the expression, and the aliasing itself had nothing to do with the substitution. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Problem with string operations
I wonder if anyone has any ideas how I can track down the source of a problem that I am having. I have a pir file that runs fine under 0.4.0, but under the latest svn fails with this message: parrot: src/string.c:448: string_append: Assertion `b-encoding b-charset !(((b)-obj.flags) b_PObj_on_free_list_FLAG)' failed. If I insert print instructions into the pir file, the point at which the program fails changes arbitrarily. If I run the program with --no-gc, it runs normally. If I run it with -t, it fails consistently right near the beginning: $ parrot -t string_operations.pir 3 warningson 255 5 store_global _argv, P0 - , P0=SArray=PMC(0x8ae4610) 8 newclass P0, ANY - P0=SArray=PMC(0x8ae4610), 11 getclass P1, Amber_INTEGER - P1=PMCNULL, 14 getclass P1, Amber_BOOLEAN - P1=parrot: src/string.c:448: string_append: Assertion `b-encoding b-charset !(((b)-obj.flags) b_PObj_on_free_list_FLAG)' failed. Aborted The program exercises a whole load of string functions (appending, repeating, substringing etc) If anyone wants to try running the pir, it's here: http://xamber.org/temp/string_operations.pir (first build the pmcs: cd languages/amber make all) but really I'd be grateful for any tips about how to locate the problem. Regards, Roger Browne
Re: [PATCH] Shared libraries on MacOS
On Jan 5, 2006, at 3:45, Nick Glencross wrote: Thanks to everyone, particularly rafl, for getting shared libraries in. I hope that it hasn't been too painful, and that we get support for most platforms. Fighting with Win32 still ... Here's a patch which provides initial support for Darwin. Not directly applied - shared config items already changed, but I've extracted (hopefully) relevant settings. Anyway, it works now, but ... e.g. libparrot_soname - ld_libparrot_share_flags rpath_blib - link_libparrot_share_executable ... especially 'rpath_blib' is really a hack now, it's just -L. Thanks, leo
[perl #38164] Re: [PATCH] Shared libraries on MacOS
# New Ticket Created by Leopold Toetsch # Please include the string: [perl #38164] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38164 On Jan 5, 2006, at 3:45, Nick Glencross wrote: Thanks to everyone, particularly rafl, for getting shared libraries in. I hope that it hasn't been too painful, and that we get support for most platforms. Fighting with Win32 still ... Here's a patch which provides initial support for Darwin. Not directly applied - shared config items already changed, but I've extracted (hopefully) relevant settings. Anyway, it works now, but ... e.g. libparrot_soname - ld_libparrot_share_flags rpath_blib - link_libparrot_share_executable ... especially 'rpath_blib' is really a hack now, it's just -L. Thanks, leo
Re: binding arguments
Hi,
Juerd wrote:
Ingo Blechschmidt skribis 2005-12-25 17:37 (+0100):
I disagree about binding only being a language thing:
I fail to see how your example code illustrates your disagreement.
return 42
if (my $short := $long_parameter_name) == $specialcase;
I inferred that you think/thought that binding should/can't be used in
expressions:
Juerd wrote:
That works very well, because binding as an expression makes no sense
anyway, it being a language thing.
Thus I wanted to demonstrate that binding as an expression does make
sense (to me at least).
Sorry if I misinterpreted your post.
push @foo, (my $head := pop @grtz);
A bit better style, but I'd still recommend against it.
Consider:
my @sites = abc.org def.org ghi.org ;
loop {
push @sites, (my $site := shift @sites);
check_for_updates($sites);
sleep ...;
}
You're doing something in an expression that has no effect on what
happens in the expression itself.
Right; but I don't consider this as bad style or as problematic.
Consider a perhaps more usual example:
# Perl 5
while(...) {
process($tasks[$i++]);
# The ++ does not have an effect on the expression itself,
# writing process($tasks[$i]) wouldn't make any difference.
if(...) { $i-- } # redo the last task
if(...) { $i = 0 } # redo all tasks
if(...) { $i++ } # skip next task
}
--Ingo
Re: binding arguments
Ingo Blechschmidt skribis 2006-01-05 18:32 (+0100):
Juerd wrote:
Ingo Blechschmidt skribis 2005-12-25 17:37 (+0100):
I disagree about binding only being a language thing:
I fail to see how your example code illustrates your disagreement.
return 42
if (my $short := $long_parameter_name) == $specialcase;
I inferred that you think/thought that binding should/can't be used in
expressions
No, that's not what I meant.
A language thing means it's mostly relevant for the way you write
something as a result of the feature. In case of binding, the most used
application is aliasing: getting a second way to address the same
variable -- probably because the alias is less typing.
push @foo, (my $head := pop @grtz);
A bit better style, but I'd still recommend against it.
Consider:
my @sites = abc.org def.org ghi.org ;
loop {
push @sites, (my $site := shift @sites);
check_for_updates($sites);
sleep ...;
}
my $site := shift @sites;
push @sites, $site;
check_for_updates($sites);
Although in Perl 6 I'd be much tempted to do:
given shift @sites {
push @sites, $_;
check_for_updates($_);
}
Because $_ is visually easy to recognise, making it immediately obvious
that it's the same thing in both lines.
(This is also my main argument against any style that ALWAYS provides an
explicit loop variable: $_ is easy to spot, and thus is more than just
easy to type.)
Consider a perhaps more usual example:
while(...) {
process($tasks[$i++]);
if(...) { $i-- } # redo the last task
if(...) { $i = 0 } # redo all tasks
if(...) { $i++ } # skip next task
}
As ugly. In fact, using an index is the ugliest part of your example.
Still, separately, $i++ in the process() instruction is bad style IMO.
Incrementing $i is important for program flow, and should be its own
statement, directly following indentation.
Also, if you remove process() here, the entire program is broken,
because there was an important but easy to overlook subexpression was in
it.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
[perl #38167] [TODO] Tests - Calling Conventions/HLL Mappings
# New Ticket Created by Will Coleda # Please include the string: [perl #38167] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38167 Tests need to be written to verify that HLL mappings are properly used for :slurpy syntax. Something like: .HLL 'Foo', 'foo_group' .sub 'main' :main joe(1,2,3,4) .end .sub 'joe' .param pmc argv :slurpy $S0 = typeof argv print $S0 print_newline .end which would print whatever the type of the ResizablePMCArray mapping for the HLL 'Foo' was. (This also requires a HLL mapping for a language, preferably via the C-level API vs. PIR-only)
[perl #38168] [TODO] - Tcl - :slurpy HLL mappings
# New Ticket Created by Will Coleda # Please include the string: [perl #38168] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38168 Make TclList properly map to a ResizablePMCArray so that lib/commands/list.pir can be simplified to: .namespace [ Tcl ] .sub list .param pmc argv :slurpy .return(argv) .end (There are probably several other places in the code where this would save us a painful conversion from one type to another. At this point, PMCs can only map one HLL: this is probably just a limitation of the pmc2c.pl script that can be resolved with some perl. (pmc2c doesn't err, but silently omits additional maps directives from the generated C) TclList may also need some more methods to compliant with a ResizablePMCArray - it is not currently resizable. [[ I tried swapping out the mapping in my sandbox, and got: push_pmc () not implemented in class 'TclFloat' ]]
Re: Problem with string operations
On Jan 5, 2006, at 17:04, Roger Browne wrote: I wonder if anyone has any ideas how I can track down the source of a problem that I am having. I have a pir file that runs fine under 0.4.0, but under the latest svn fails with this message: parrot: src/string.c:448: string_append: Assertion `b-encoding b-charset !(((b)-obj.flags) b_PObj_on_free_list_FLAG)' failed. This means that at that line a GC-collected strings is used - the RHS of concat is dead (on the free list). If I insert print instructions into the pir file, the point at which the program fails changes arbitrarily. That's the nice thing with GC bugs ;-) If I run the program with --no-gc, it runs normally. The bad news is I can't reproduce this with trunk, all combinations of -t, --gc-debug are working. There is another issue though 'make all' inside amber currently needs a statically linked parrot. I don't know, if this is amber- or parrot-related though. Regards, Roger Browne leo
Re: [perl #38168] [TODO] - Tcl - :slurpy HLL mappings
On Jan 5, 2006, at 18:50, Will Coleda (via RT) wrote:
At this point, PMCs can only map one HLL: this is probably just a
limitation of the pmc2c.pl script that can be resolved with some
perl. (pmc2c doesn't err, but silently omits additional maps
directives from the generated C)
Err, what should that sentence mean?
Parrot is creating a slurpy array on behalf of the HLL currently in
scope, it consults the mapping table:
HLL_info[$hll_id]{'ResizablePMCArray' = 'foo'} # basically
and selects excatly one mapped type ('foo' above). At any time for one
HLL and one type, there can just be one HLL type (which one would you
select, if there were more).
leo
Re: Junctions again (was Re: binding arguments)
On 1/4/06, Luke Palmer wrote: The other thing that is deeply disturbing to me, but apparently not to many other people, is that I could have a working, well-typed program with explicit annotations. I don't think it disturbs me... but that might just be because I don't really understand it. I could remove those annotations and the program would stop working! If it changes how the program works, then by definition doesn't that mean it wasn't really an annotation to begin with? As far as specifying Junction in signatures to control auto-threading, that always felt funny to me anyway, because it's not consistent with the normal meaning of specifying a parameter type. I would've expected is threaded or is junctive or is junctothreaded or something. I'm not sure if this is (part of) what you're getting at or not. In a strongly-typed language, can you always remove the typing from a working program without changing it? Or maybe just particular strongly-typed languages... in Perl, typing can be used to provide bonus information (say, as optimisation hints); but it can also be used for multiple-dispatch, so I certainly wouldn't expect a program to continue working properly if I changed *that* information. (Assuming well-typed refers to the former, but not the latter -- hope I've got that straight.) In that vein, I think of junctions as a sort of implicit polymorphism: I define sub foo(Int $a) and also get sub foo(Junction of Ints $j) for free. Which is why acting wacky doesn't bother me -- numbers may be well-ordered, but junctions aren't, and there are two different 's at work. Arguably, different functions should have different names to avoid confusion, but I think that calling the junctive less-than something other than would be even more confusing. (Certainly it would be too unDWIMilly pedantic to be Perl.) Of course, I was also never bothered by using + to mean numeric addition and string concatenation. Come to think of it, perhaps that's because languages which do that are picky about distinguishing strings from numbers -- in Basic, 123 + 123 will get you a type-mismatch error, but to Perl, 123 and 123 are the same thing, so you need a numeric == and a stringic 'eq'. But Perl does know the difference between a number and a junction. That means the programmer has to follow along at home, but ok, sometimes you just gotta be aware of what your code is doing. I think I understand your Functor proposal, and it does have a certain appeal for me... but along with the advantage of making it clearer when junctions are being used, it carries the disadvantage of *requiring* you to know when junctions are being used. I can't just say if $x3 ... and expect it to Do the Right Thing regardless of whether $x happens to be an ordinary number or a junction -- I have to split up the two cases and handle them separately. That's surely going to reduce the happy-go-lucky usefulness of junctions. Besides, don't we have a no junctions pragma that you can stick into any scope where you need exact mathematical purity? -David
Re: Problem with string operations
On Jan 5, 2006, at 19:32, Leopold Toetsch wrote: There is another issue though 'make all' inside amber currently needs a statically linked parrot. I don't know, if this is amber- or parrot-related though. Works with tcl - so it's probably an amber Makefile issue. leo
[perl #38168] [TODO] - Tcl - :slurpy HLL mappings
I have TclList. I want it to map to ResizablePMCArray, maybe Array, and
possibly others of the remaining 14 parrot array variants.
Right now, the pmc syntax only lets you pick ONE parrot type for hll PMC.
So if I want TclList to map to more than one builtin type, I have to fix
pmc2c.pl
to support this.
Regards.
[leo - Thu Jan 05 10:42:23 2006]:
On Jan 5, 2006, at 18:50, Will Coleda (via RT) wrote:
At this point, PMCs can only map one HLL: this is probably just a
limitation of the pmc2c.pl script that can be resolved with some
perl. (pmc2c doesn't err, but silently omits additional maps
directives from the generated C)
Err, what should that sentence mean?
Parrot is creating a slurpy array on behalf of the HLL currently in
scope, it consults the mapping table:
HLL_info[$hll_id]{'ResizablePMCArray' = 'foo'} # basically
and selects excatly one mapped type ('foo' above). At any time for one
HLL and one type, there can just be one HLL type (which one would you
select, if there were more).
leo
Re: Junctions again (was Re: binding arguments)
HaloO,
Jonathan Lang wrote:
Rob Kinyon wrote:
To me, this implies that junctions don't have a complete definition.
Either they're ordered or they're not.
So, is there a number between 0 and 1? Shades between black and white?
When is a 360 degree turn not returning a system into its initial state?
What has a 720 degree turn to do with sign reversal, negation and
twisted arms? Anyone know the Eisenstein integers? Is 5 a prime complex
number? What is its quadratic residue?
(-1)**2 == -i**2 == +1
\
?--0 # if =
/
i**2 == -1
-- mirror symmetry axis
j**2 == -1
\
!--0 # unless =
/
(-1)**2 == -j**2 == +1
But note that *same* symmetrie is broken! Ever wondered why a mirror
changes left and right, but not up and down? And what has all that
to do with anagrams like 'OTTO' and 'TOOT' or with bits '.**.' and
'*..*'? Or the range operators ^..^ .^^.?
Conceptually the 0 has no sign unless you want it to be junctive ;)
if you rotate the above vector diagrams by 120 degrees endlessly
clockwise and counter clockwise you get
upper: ...,0, 1,-1,0,...
lower: ...,0,-1, 1,0,...
which when superimposed additively lets the infinity of the
lists nicely vanish. But not the same is not true if one is
shifted, the other squared and then subtracted, or some such.
The thing is you end up with the infinte list (...,!0,!0,...).
The net effect is the same as reading the list's string representations
in opposite directions. There is no dark side of the moon really!
Here's the same in another ascii picture:
i\+/+
-\+ +\-2**-=+**2+/+ -/-
-/-\-i**2
center stage we find = which returns one(-1,0,+1) or rotations
thereof: one(0,+1,-1) or one(+1,-1,0). Or the odd permutations
one(0,-1,+1), one(-1,+1,0) and one(+1,0,-1). In other words three
pairs of ones that cancel each other if zipped additively. The only
thing we need is a neutral element to get a group. Let's take the
empty one() junction. But an empty any() would do as well. These
sort of represent no comparison at all and a comparison you don't
care to constrain any further! In the latter case an undef return
value is not unexpected, I hope.
This is how that looks in an example:
'foo' cmp 'bor'
-- f o o »cmp« b o r --
-- (-1, +0, +1) | (+1, -0, -1) --
The arrows indicate reading direction of the respective string.
In a optimised implementation the outer f/b and and r/o give
the invariant relative positions of one('foo','oof') and
one('bor','rob') in the order of strings in viewing direction.
At least that is the observable behaviour. Endianess of the
machine, representation of junctions and what not may differ
for concrete implementations of Perl6 :)
Note that
[?] (-1, +0, +1) »+« (+1, -0, -1)
-- [?] (0,0,0)
-- false
With (-++) and (+--) beeing dual Minkowski metrics.
Either I can put them in a =
expression and it makes sense or I can't.
HiHi, this is a statement about the programmer's abilities...
not about Perl 6 the language!
If it makes sense, then that
implies that if $x = $y is true, then $x $y is false. Otherwise,
the definitions of = and have been violated.
I'll beg to differ. If you insist on that kind of restriction on
Junctions, they won't be able to serve their original (and primary)
purpose of aggragating comparison tests together. Remember:
if $x = 1 5 {...}
is intended to be 'shorthand' for
if $x = 1 $x = 5 {...}
I beg to differ, two err too. I mean potentially from both depending
on what they intented to say and how I understood them.
My point is that the junctive case sort of means:
if $x.all:{=}(1,5) {...}
where :{=} receives similar meta treatment as [=] reduce would.
BTW, isn't bareword suffixing {=} reserved for type theoretic
manipulations? I still regard the junctions as Code subtypes and
thus any{=} and friends as parametric meta operation.
Therefore,
$x = 3;
if $x = 1 5 {say 'smaller'}
if $x 1 5 {say 'larger'}
should produce exactly the same output as
$x = 3;
if $x = 1 $x = 5 {say 'smaller'}
This is slightly untrue. because if the junction contains two
identical values or an undef ordered object the part is
essentially stripped away:
if $x = 5 $x = 5 {say 'smaller'}
can be permuted into
if $x = 5 5 $x {say 'smaller'}
and optimized to
if $x == 5 {say 'smaller'}
if $x 1 $x 5 {say 'larger'}
If it doesn't, then Junctions are useless and should be stricken from Perl 6.
And the definition of '' is greater than, not not (less than or
equal to). The latter is a fact derived from how numbers and letters
behave, not anything inherent in the comparison operator.
The complete group of comparison operators imposes the order on the
underlying uninterpreted set of
Re: Problem with string operations
On Thu, 2006-01-05 at 20:00 +0100, Leopold Toetsch wrote: There is another issue though 'make all' inside amber currently needs a statically linked parrot. I don't know, if this is amber- or parrot-related though. Works with tcl - so it's probably an amber Makefile issue. Thanks for trying this, Leo. What is a non-statically-linked parrot? Is it what I get by giving the --parrot_is_shared argument to Configure.pl? The amber PMCs build for me with or without this option. How does it fail when you build the PMCs without a statically linked parrot? (might be a clue to my other problem). Regards, Roger Browne
Re: Problem with string operations
On Jan 5, 2006, at 21:37, Roger Browne wrote: What is a non-statically-linked parrot? Is it what I get by giving the --parrot_is_shared argument to Configure.pl? I did $ ./doit $ cd languages/amber $ make clean all and got an error (Makefile related) - then: $ ./doit --parrot_is_shared=0 $ cd languages/amber $ make all and amber worked. ./doit is basically 'perl Configure.pl $@ make all test' e.g. perl Configure.pl --maintainer --icuheaders=/usr/include $@ --icushared='-licuuc -licudata' nice make -s all test Regards, Roger Browne leo
Re: [perl #37303] [PATCH] Relaxing parrot dependency on parrot_config
Guys,
I've been wanting to relax the dependency that parrot's core has on
parrot_config. As things stand at the moment, src/global_setup.c makes
a call to parrot_get_config which is linked into the executable itself
by selecting either null_config.o, parrot_config.o or
install_config.o.
Quite a bit of time has passed since I originally set about writing this
patch! I've made some more tweaks and wish for it to be considered for
inclusion. It can certainly wait until after the next release.
Any executable (currently only main.c and pbc_merge.c) which needs the
embedded config environment should call Parrot_set_config_hash /before/
creating an Interpreter. This function is contained in *_config.o, and
so will also need to be linked with.
It shouldn't ever now really be necessary to link with null_config.o,
although miniparrot does for technical reasons (the same code is used
for miniparrot, parrot and installable_parrot).
I am finding that I'm hopeless at coming up with variable and function
names, so you won't get any resistance if they are renamed.
Cheers,
Nick
p.s. This patch has changed quite a bit since a version that would core
dump. If this does core dump for anyone let me see a backtrace -- I did
see one core dump in the thawing calling, so it may be necessary to do
something with the garbage collection.
Index: src/pbc_merge.c
===
--- src/pbc_merge.c (revision 10929)
+++ src/pbc_merge.c (working copy)
@@ -720,6 +720,8 @@
struct PackFile *merged;
int i;
+Parrot_set_config_hash ();
+
/* Create a Parrot interpreter. */
interpreter = make_interpreter(NULL, PARROT_NO_FLAGS);
Parrot_init(interpreter);
Index: src/global_setup.c
===
--- src/global_setup.c (revision 10929)
+++ src/global_setup.c (working copy)
@@ -28,21 +28,69 @@
/* These functions are defined in the auto-generated file core_pmcs.c */
extern void Parrot_initialize_core_pmcs(Interp *interp);
-static void
-create_config_hash(Interp *interpreter, PMC *iglobals)
+static const unsigned char* parrot_config_stored = NULL;
+static unsigned int parrot_config_size_stored = 0;
+
+
+/*
+
+=item Cvoid
+Parrot_set_config_hash_internal (const unsigned char* parrot_config,
+ unsigned int parrot_config_size)
+
+Called by Parrot_set_config_hash with the serialised hash which
+will be used in subsequently created Interpreters
+
+=cut
+
+*/
+
+void
+Parrot_set_config_hash_internal (const unsigned char* parrot_config,
+ unsigned int parrot_config_size)
{
-STRING *config = parrot_get_config_string(interpreter);
-PMC *hash;
+parrot_config_stored = parrot_config;
+parrot_config_size_stored = parrot_config_size;
+}
-if (config) {
-hash = Parrot_thaw(interpreter, config);
+/*
+
+=item Cvoid parrot_set_config_hash_interpreter (Interp* interpreter)
+
+
+Used internally to associate the config hash with an Interpreter
+using the last registered config data.
+
+=cut
+
+*/
+
+static void parrot_set_config_hash_interpreter (Interp* interpreter)
+{
+PMC *iglobals = interpreter-iglobals;
+
+PMC *config_hash = NULL;
+
+if (parrot_config_size_stored 1)
+{
+STRING *config_string =
+string_make_direct(interpreter,
+ parrot_config_stored, parrot_config_size_stored,
+ PARROT_DEFAULT_ENCODING, PARROT_DEFAULT_CHARSET,
+ PObj_external_FLAG|PObj_constant_FLAG);
+
+config_hash = Parrot_thaw(interpreter, config_string);
}
else
-hash = pmc_new(interpreter, enum_class_Hash);
+{
+config_hash = pmc_new(interpreter, enum_class_Hash);
+}
+
VTABLE_set_pmc_keyed_int(interpreter, iglobals,
-(INTVAL) IGLOBALS_CONFIG_HASH, hash);
+ (INTVAL) IGLOBALS_CONFIG_HASH, config_hash);
+}
-}
+
/*
=item Cvoid init_world(Interp *interpreter)
@@ -91,11 +139,10 @@
PMC_data(self) = interpreter;
VTABLE_set_pmc_keyed_int(interpreter, iglobals,
(INTVAL) IGLOBALS_INTERPRETER, self);
+
+parrot_set_config_hash_interpreter (interpreter);
+
/*
- * create runtime config hash
- */
-create_config_hash(interpreter, iglobals);
-/*
* HLL support
*/
if (interpreter-parent_interpreter)
@@ -121,6 +168,7 @@
IGLOBALS_DYN_LIBS, pmc);
}
+
/*
=back
Index: tools/build/parrot_config_c.pl
===
--- tools/build/parrot_config_c.pl (revision 10929)
+++ tools/build/parrot_config_c.pl (working copy)
@@ -7,7 +7,7 @@
=head1 NAME
-tools/build/parrot_config_c.pl - Create src/parrot_config.c
+tools/build/parrot_config_c.pl - Create src/parrot_config.c
Re: [PATCH] Three pushaction bugs
From: Leopold Toetsch [EMAIL PROTECTED] Date: Thu, 5 Jan 2006 11:38:04 +0100 On Jan 5, 2006, at 3:26, Bob Rogers wrote: 2. Even without an error, it seems that actions could sometimes be run twice because stack_pop compared entry-cleanup to 0 instead of STACK_CLEANUP_NULL. (I can't reproduce this now, so it probably depended on something else as well.) Well, STACK_CLEANUP_NULL is ((Stack_cleanup_method)NULLfunc), which is the same as 0 on all current platforms (AFAIK), but your patch is of course correct. Then this doesn't explain how I fixed the double invocation problem. It could be that the problem itself was just a figment of my imagination, an artifact of hastily rewriting the test case (my vote), or something I had introduced temporarily while reordering find_exception_handler code. Oh, well. 3. Actions are not run at all if the context is skipped by calling a continuation. This is a deeper problem, so I've just added a TODO test in order to document it as a known problem; I hope to fix this in the course of implementing dynamic binding. It should work, when implementing the stack unwinding in Continuation.invoke (which is also called by Exception_handler.invoke). Now the question arises: what to do on the 2nd time the sub is running. There are probably 2 options: a) user code has to reenable exception handlers and cleanup actions, i.e. above stack unwinding is permanent b) the control stack remains unchanged, all exception handlers and cleanup actions are still in place. If I had to choose between these two, I'd say that 'b' is easier, because popping is easier than repushing. But it would be much nicer if the dynamic state were automagically restored to the same exact state as when the closure was taken; then, no adjustments are necessary in PIR code. This can be done if the continuation stores some notion of the binding_stack state at that time. I am expecting to argue (when I have time to complete the research) that dynamic bindings should also be kept on the control stack; if that happens, then the rezipping process can also do the right thing wrt restoring exception and action state, almost for free. That's why I didn't want to try to fix the continuation-unwinding issue now; I am hoping to get multiple birds with a single stone. How convenient for all this that Exception_handler is a subclass of Continuation. It's always good to Do The Right Thing, but much easier if you can simply inherit it. -- Bob
[svn ci] svn metadata cleanup
for those of you who might be updating your working copies from svn (post r10933) and wondering why so many files are changing, i did some svn metadata cleanup today. ~ the set svn:mime-type property should now be set appropriately based on file extension. i paid close attention to .t, .xml, .png (and other image formats), .z3. i may have missed some filetypes, but they should have the same properties they had before, which may already have been correct. ~ the svn:keywords property should now be standardized to Author Date Id Revision for all text files. ~ removed mistaken svn:keyword properties from files that had this typo-ed property. i've tested on i386-win32-cl and i386-linux-gcc successfully. if you notice anything unusual, please report any bugs to the usual place ([EMAIL PROTECTED]) ~jerry
Re: Junctions again (was Re: binding arguments)
Me no follow. Please use smaller words? -- Jonathan Dataweaver Lang
