Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
2008/6/22 jerry gay <[EMAIL PROTECTED]>: > On Sun, Jun 22, 2008 at 3:38 AM, Bernhard Schmalhofer > <[EMAIL PROTECTED]> wrote: >> James Keenan via RT schrieb: >>> >>> On Fri Jul 13 09:58:33 2007, bernhard wrote: >>> There are several config probes that are only used for language implementations. Examples are config/auto/m4.pm and config/auto/python.pm. >>> >>> Please find attached two files. The first greps the repository for >>> mentions of 'm4'. The second is a patch which eliminates >>> config/auto/m4.pm and the associated test file and updates the MANIFEST. >>> >>> Configure.pl, make and make test all perform without error after this >>> config step is eliminated. When I switch into languages/m4, then call >>> 'make' and 'make test', I get the same test failures in >>> t/regex/002_tokens.t either way. So my belief is that removing this >>> step causes no harm to the m4 language implementation itself. >>> >>> I will apply this patch to trunk in about 2 days if there is no objection. >>> >>> Thank you very much. >>> >>> kid51 >>> >>> >> >> AFAIK 'languages/m4/config/makefiles/root.in' is the only place where the >> config entry 'has_gnu_m4' is used. >> It is meant as a doublecheck of the 'm4' tests. If 'GNU m4' is available >> then the m4 tests should be run with 'GNU m4' as well. >> This should make sure that the Parrot implementation behaves the same way as >> the reference implementation. >> >> So 'has_gnu_m4' is not essential to the implementation of 'Parrot m4'. In >> r28633 I removed the use of 'has_gnu_m4' and the config step auto::m4.pm can >> now be removed. >> >> But the real scope of ticket RT#43857 is something different. Language >> implementations may need config probes that >> are only relevant for that particular language. Therefore there should be >> some kind of infrastructure set up, >> so that those probes can be placed within the language dir. Taking >> 'Plumhead' as an example, >> I would have liked to set up probes checking for 'phc', 'antlr' and >> 'xsltproc'. I didn't do so because I didn't want to clutter the Parrot >> config. >> > languages/dotnet/ has its own configure.pl, and m4, plumhead, etc. > should follow that model. if there are things that can be done to make > the process of developing a language-specific configure engine easier, > i'd love to hear them. I outlined a Parrot/Install core library for library/languages support in the latest pdd30_install draft. For me a language is nothing more than a parrot library. The languages soon need their own Configure/Makefile support, when core throws them out. It could be driven with a perl5 lib/Parrot/Install.pm library for now, and later with runtime/parrot/library/Parrot/Install.pir or a perl6 library, which should do something along the lines of ExtUtils::MakeMaker. Frontend: parrot Makefile.pir loads Parrot/Install and defines the Makefile methods and properties, with the possibility to start a seperate configure step to check for external bins, libs and headers. RunConfigure() WriteMakefile() Defining the hash entries for the subs in PIR syntax is awful. So I envision Makefile.pl, Makefile.nqp or Makefile.p6 for this syntax. For p6 we must ensure that every parrot package has a perl6 also then. Not good. So pl, pir or the simple nqp. -- Reini
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
James Keenan via RT schrieb: I'm trying to see if we can move this ticket toward resolution. I think that it has remained unresolved for so long because the original post originally called for two steps: (a) removal from Configure.pl of configuration steps which probed for features only used in specific language implementations; (b) development of a way to conduct such language-specific probes in the language directory trees after 'perl Configure.pl' and 'make' have been run. There were two specific steps cited for removal per (a): auto::python and auto::m4. By June of this year I had removed both of those from Parrot configuration. So that leaves us with (b). particle wrote: "languages/dotnet/ has its own configure.pl, and m4, plumhead, etc. should follow that model." Barney responded: "One thing that held me back from using something like 'dotnet/Configure.pl' was that 'dotnet/Configure.pl' currently needs to be explicitly called after the main 'Configure.pl' has run. This is bad for universal languages testing." And that's where discussion left off three months ago. I am recommending the following: (1) Mark this ticket resolved. (2) Conduct discussion on list or IRC as to the best architecture/model for language-specific probes. (3) Once we've come to such resolution on (2), open a new RT to implement what we've decided. particle, Barney: Any objections? Sounds good. An example for a language specific config probe could be put mk_language_shell.pl. Regards, Bernhard Thank you very much. kid51
[perl #52778] [RFC] Are resizable arrays too Perlish?
On Mon Sep 08 22:54:28 2008, [EMAIL PROTECTED] wrote: > Patrick R. Michaud wrote: > > > > Fixing this shouldn't be all that difficult -- in particular, > > I think that src/pmc/resizablepmcarray.pmc lines 205-206 should > > be changed from > > > > - if (key >= PMC_int_val(SELF)) > > - SELF.set_integer_native(key+1); > > > > to something like > > > > + if (key >= PMC_int_val(SELF)) > > + return PMCNULL; > > > > I haven't tested this -- there may be other things that need > > to change as well. > > > > Hope this helps, > > > > Pm > > > > It turns out that no further changes were needed to implement this > behavior. > The attached patch fixes this (and two incorrect ResizableBooleanArray > tests). > With the patch applied, all tests in make test pass. If this is > what we > want Parrot to do, I'll apply the patch and add tests to > Resizable*Array to > make sure the behavior stays consistent. I'm going to give this until next Tuesday for comment, at which point I'll commit the patch and mark this ticket as resolved.
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
Reini Urban via RT schrieb: Defining the hash entries for the subs in PIR syntax is awful. So I envision Makefile.pl, Makefile.nqp or Makefile.p6 for this syntax. For p6 we must ensure that every parrot package has a perl6 also then. Not good. So pl, pir or the simple nqp. The libs and scripts could be written in Perl 6 and compiled to bytecode. In this way the languages would need no full Perl 6, just some *.pbc files. Regards, Bernhard
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
>> Defining the hash entries for the subs in PIR syntax is awful. >> So I envision Makefile.pl, Makefile.nqp or Makefile.p6 for this syntax. >> For p6 we must ensure that every parrot package has a perl6 also then. Not >> good. >> So pl, pir or the simple nqp. > > The libs and scripts could be written in Perl 6 and compiled to bytecode. > In this way the languages would need no full Perl 6, just some *.pbc files. That can open a can of worms. The .pbc generated from perl6 will need installed perl6 .pbc files for perl6 objects, builtins, who knows what more. Worse, it can use eval'ed strings that needs the compiler. It will not be nice to talk about language neutrality while requiring perl6 to install a completely unrelated language. -- Salu2
[perl #43857] [TODO] Refactor config probes that are used only by language implementation
On Fri Sep 12 02:18:57 2008, bernhard wrote: > James Keenan via RT schrieb: > > I'm trying to see if we can move this ticket toward resolution. > > > > And that's where discussion left off three months ago. I am > > recommending the following: > > > > (1) Mark this ticket resolved. > > (2) Conduct discussion on list or IRC as to the best architecture/model > > for language-specific probes. > > (3) Once we've come to such resolution on (2), open a new RT to > > implement what we've decided. > > > > particle, Barney: Any objections? > > > Sounds good. Per feedback from particle and Barney, I am resolving this ticket. Per above recommendations: Reini, Notfound, et.al.: Can you please do a new post to the list to discuss new issues or implementation ideas? We should not have further posts to this RT. Thank you very much. kid51
[perl #43857] [TODO] Refactor config probes that are used only by language implementation
Resolved.
Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.
chromatic wrote:
Just for clarification, it attached patch is actually what this ticket
about?
Yes, that's correct.
Ok, so I go ahead and try to fix more pmcs. There is single line patch
for float.
--
Bacek
diff --git a/src/pmc/float.pmc b/src/pmc/float.pmc
index d315627..fa03356 100644
--- a/src/pmc/float.pmc
+++ b/src/pmc/float.pmc
@@ -466,7 +466,7 @@ Return a new PMC of the type of C with I(value) of SELF.
METHOD atan2(PMC *val) {
PMC * const d = pmc_new(INTERP, VTABLE_type(INTERP, SELF));
-PMC_num_val(d) = atan2(SELF.get_number(), PMC_num_val(val));
+PMC_num_val(d) = atan2(SELF.get_number(), VTABLE_get_number(INTERP, val));
RETURN(PMC *d);
}
Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.
chromatic wrote:
Yes, that's correct.
There is 2 patches:
1. complex.pmc single replacement of PMC_str_val.
2. string.pmc.
Replaces PMC_str_val;
Replace VTABLE_get_string(INTERP, SELF) with SELF.get_string();
In set_*_keyed change logick to invoke VTABLE_set_string_native
instead of replacing in place.
--
Bacek.
diff --git a/src/pmc/complex.pmc b/src/pmc/complex.pmc
index b147e88..74e61fe 100644
--- a/src/pmc/complex.pmc
+++ b/src/pmc/complex.pmc
@@ -328,7 +328,7 @@ C object according to 2.1. Built-in Functions.
PMC * const arg = REG_PMC(interp, 5);
if (arg->vtable->base_type == enum_class_String)
-VTABLE_set_string_native(INTERP, res, PMC_str_val(arg));
+VTABLE_set_string_native(INTERP, res, VTABLE_get_string(interp, arg));
else
RE(res) = VTABLE_get_number(INTERP, arg);
}
commit 377da82bd0a527193d684dc211007839785f2409
Author: Vasily Chekalkin <[EMAIL PROTECTED](none)>
Date: Sat Sep 13 10:05:30 2008 +1000
Use less PMC_str_val in favour of VTABLE_get_string. Replace VTABLE_get_string(INTERP, SELF) with SELF.get_string() for readablity sake
diff --git a/src/pmc/string.pmc b/src/pmc/string.pmc
index 6cac0e9..ced7562 100644
--- a/src/pmc/string.pmc
+++ b/src/pmc/string.pmc
@@ -89,7 +89,7 @@ Creates a copy of the string.
VTABLE PMC *clone() {
PMC * const dest = pmc_new_noinit(INTERP, SELF->vtable->base_type);
PObj_custom_mark_SET(dest);
-PMC_str_val(dest) = string_copy(INTERP, VTABLE_get_string(INTERP, SELF));
+PMC_str_val(dest) = string_copy(INTERP, SELF.get_string());
return dest;
}
@@ -104,7 +104,7 @@ Returns the integer representation of the string.
*/
VTABLE INTVAL get_integer() {
-STRING * const s = (STRING *)VTABLE_get_string(INTERP, SELF);
+STRING * const s = SELF.get_string();
return string_to_int(INTERP, s);
}
@@ -119,7 +119,7 @@ Returns the floating-point representation of the string.
*/
VTABLE FLOATVAL get_number() {
-STRING * const s = (STRING*) VTABLE_get_string(INTERP, SELF);
+STRING * const s = SELF.get_string();
return string_to_num(INTERP, s);
}
@@ -134,7 +134,7 @@ Returns the big numbers representation of the string.
*/
VTABLE PMC *get_bignum() {
-STRING * const s = VTABLE_get_string(INTERP, SELF);
+STRING * const s = SELF.get_string();
PMC *ret = pmc_new(INTERP, enum_class_BigInt);
VTABLE_set_string_native(INTERP, ret, s);
return ret;
@@ -166,7 +166,7 @@ Returns the boolean value of the string.
*/
VTABLE INTVAL get_bool() {
-STRING * const s = VTABLE_get_string(INTERP, SELF);
+STRING * const s = SELF.get_string();
return string_bool(INTERP, s);
}
@@ -251,7 +251,7 @@ the specified C PMC.
VTABLE void set_string_same(PMC *value) {
PMC_str_val(SELF) =
-string_set(INTERP, PMC_str_val(SELF), PMC_str_val(value));
+string_set(INTERP, SELF.get_string(), VTABLE_get_string(INTERP, value));
}
/*
@@ -632,26 +632,28 @@ Replace the string at C with the chr of C.
*/
VTABLE STRING *get_string_keyed(PMC *key) {
-STRING * const s = PMC_str_val(SELF);
+STRING * const s = SELF.get_string();
const INTVAL k = key_integer(INTERP, key);
return string_substr(INTERP, s, k, 1, NULL, 0);
}
VTABLE INTVAL get_integer_keyed(PMC *key) {
-STRING * const s = PMC_str_val(SELF);
+STRING * const s = SELF.get_string();
return string_ord(INTERP, s, key_integer(INTERP, key));
}
void set_string_keyed(PMC *key, STRING * const value) {
-STRING * const s = PMC_str_val(SELF);
+STRING * const s = SELF.get_string();
const INTVAL len = string_length(INTERP, value);
string_replace(INTERP, s, key_integer(INTERP, key), len, value, NULL);
+VTABLE_set_string_native(INTERP, SELF, s);
}
VTABLE void set_integer_keyed(PMC *key, INTVAL value) {
-STRING * const s = PMC_str_val(SELF);
+STRING * const s = SELF.get_string();
STRING * const c = string_chr(INTERP, (UINTVAL) value);
string_replace(INTERP, s, key_integer(INTERP, key), 1, c, NULL);
+VTABLE_set_string_native(INTERP, SELF, s);
}
/*
Re: [svn:parrot] r31046 - in trunk: languages/perl6 languages/perl6/src/builtins languages/perl6/src/parser runtime/parrot/library
On Fri, Sep 12, 2008 at 05:03:20PM -0700, [EMAIL PROTECTED] wrote: > [...] > (2) Test.pm gets Object rather than Any on its multis; > this may or may not be the Right Thing. perl6-language may end up disagreeing with me on this, but I would much prefer things (from a implementation bootstrapping perspective) if Test.pm didn't rely on type checking and Junctions in order to work properly. So, until we hear otherwise, it might be better to not require Object on parameters here. > (3) Because Parrot doesn't yet give us a way to type-map MultiSub, > and because we're not using .HLL yet anyway, we need to do a > workaround in a block's loadinit. Instead of having a special '!TOPERL6MULTISUB' function, could this be done instead with 'morph'? If that doesn't work, perhaps we could get it to work using the 'add_sub' method on NameSpace PMCs (and perhaps this should be part of a Perl6NameSpace class)? Pm
Re: [svn:parrot] r31045 - trunk/languages/perl6/src/classes
On Fri, Sep 12, 2008 at 04:55:39PM -0700, [EMAIL PROTECTED] wrote: > Log: > [rakudo] If we are calling ACCEPTS in a multi-dispatch to do a > type-check, then because blocks are not differentiated from > regexes at the moment we get exceptions when trying to store $/. > This patch wraps that code up in a handler. I'd be happy to get PGE to attach whatever attributes or re-bless the subs it generates to be Regex subs if we can come up with a reasonably clean way to do that. Pm
Re: [svn:parrot] r31042 - trunk/languages/perl6/src/classes
On Fri, Sep 12, 2008 at 04:41:38PM -0700, [EMAIL PROTECTED] wrote: > [rakudo] Constraints in a signature should actually be represented > as an all Junction, not an array. You may have thought of this already, but it'd be worthwhile to consider how we might handle infix: (added to the Synopses this past week). The infix: operator creates an "ordered Junction". Pm
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
On Fri, Sep 12, 2008 at 03:47:27PM +0200, NotFound wrote: > >> Defining the hash entries for the subs in PIR syntax is awful. > >> So I envision Makefile.pl, Makefile.nqp or Makefile.p6 for this syntax. > >> For p6 we must ensure that every parrot package has a perl6 also then. Not > >> good. > >> So pl, pir or the simple nqp. > > > > The libs and scripts could be written in Perl 6 and compiled to bytecode. > > In this way the languages would need no full Perl 6, just some *.pbc files. > > That can open a can of worms. The .pbc generated from perl6 will need > installed perl6 .pbc files for perl6 objects, builtins, who knows what > more. Worse, it can use eval'ed strings that needs the compiler. > > It will not be nice to talk about language neutrality while requiring > perl6 to install a completely unrelated language. Agreed. This is exactly the niche that NQP is meant to fill. If we need to add some features to NQP to make this possible, then that can be done. Pm
[perl #58812] Tcl Segfaults parrot
# New Ticket Created by Will Coleda # Please include the string: [perl #58812] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=58812 > After many weeks away from tcl, I tried to do a make test today (r31046) and found a segfault. I can't easily generate PIR to narrow it down, because even the --pir option is segfaulting. doing a build and just running "../../parrot tcl.pbc" is enough to trigger the segfault (that should drop you into an interpreter.) I'll post more details tomorrow if I can. Here's a backtrace from gdb. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb6c708d0 (LWP 426)] 0xb7ca4e33 in pmc_new_noinit (interp=0x804f040, base_type=81) at src/pmc.c:300 300 PMC *const classobj = interp->vtables[base_type]->pmc_class; (gdb) bt #0 0xb7ca4e33 in pmc_new_noinit (interp=0x804f040, base_type=81) at src/pmc.c:300 #1 0xb7c7113b in Parrot_register_HLL_type (interp=0x804f040, hll_id=2, core_type=67, hll_type=81) at src/hll.c:362 #2 0xb7dd875e in Parrot_ParrotInterpreter_thawfinish (interp=0x804f040, pmc=0x8220e9c, info=0xbfdc1aa8) at ./src/pmc/parrotinterpreter.pmc:670 #3 0xb7ca44dc in visit_loop_todo_list (interp=0x804f040, current=0x8220e9c, info=0xbfdc1aa8) at src/pmc_freeze.c:1609 #4 0xb7ca46a6 in run_thaw (interp=0x804f040, image=0x8215114, what=VISIT_THAW_NORMAL) at src/pmc_freeze.c:1700 #5 0xb7ca4920 in Parrot_thaw (interp=0x804f040, image=0x8215114) at src/pmc_freeze.c:1820 #6 0xb7c9f4a0 in PackFile_Constant_unpack_pmc (interp=0x804f040, constt=0x8229408, self=0x8229698, cursor=0xb7b12ba8) at src/packfile.c:3588 #7 0xb7c9f3f8 in PackFile_Constant_unpack (interp=0x804f040, constt=0x8229408, self=0x8229698, cursor=0xb7b129e8) at src/packfile.c:3542 #8 0xb7c9f0fc in PackFile_ConstTable_unpack (interp=0x804f040, seg=0x8229408, cursor=0xb7b129e4) at src/packfile.c:3338 #9 0xb7c9c81a in PackFile_Segment_unpack (interp=0x804f040, self=0x8229408, cursor=0xb7b129e0) at src/packfile.c:1614 #10 0xb7c9cd3e in directory_unpack (interp=0x804f040, segp=0x8229270, cursor=0xb7b129d0) at src/packfile.c:1808 #11 0xb7c9c81a in PackFile_Segment_unpack (interp=0x804f040, self=0x8229270, cursor=0xb7b12040) at src/packfile.c:1614 #12 0xb7c9b773 in PackFile_unpack (interp=0x804f040, self=0x8229270, packed=0xb7b12000, packed_size=8000) at src/packfile.c:877 #13 0xb7c60ba5 in Parrot_readbc (interp=0x804f040, fullname=0xbfdc39e0 "tcl.pbc") at src/embed.c:506 #14 0xb7eb6e0b in imcc_run (interp=0x804f040, sourcefile=0xbfdc39e0 "tcl.pbc", argc=1, argv=0xbfdc1e88) at compilers/imcc/main.c:1051 #15 0x08048978 in main (argc=1, argv=0xbfdc1e88) at src/main.c:61 -- Will "Coke" Coleda
Re: [perl #58812] Tcl Segfaults parrot
On Friday 12 September 2008 19:48:30 Will Coleda wrote: > After many weeks away from tcl, I tried to do a make test today > (r31046) and found a segfault. > > I can't easily generate PIR to narrow it down, because even the --pir > option is segfaulting. > > doing a build and just running "../../parrot tcl.pbc" is enough to > trigger the segfault (that should drop you into an interpreter.) > > I'll post more details tomorrow if I can. Here's a backtrace from gdb. > > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb6c708d0 (LWP 426)] > 0xb7ca4e33 in pmc_new_noinit (interp=0x804f040, base_type=81) at > src/pmc.c:300 300 PMC *const classobj = > interp->vtables[base_type]->pmc_class; (gdb) bt > #0 0xb7ca4e33 in pmc_new_noinit (interp=0x804f040, base_type=81) at > src/pmc.c:300 > #1 0xb7c7113b in Parrot_register_HLL_type (interp=0x804f040, > hll_id=2, core_type=67, hll_type=81) > at src/hll.c:362 Rough guess: you have a HLL type map before you load Tcl's dynpmcs. If so, change the order of operations as a workaround. I think that might "fix" Lua too. -- c
Re: Iterator semantics
Hi Larry,
# from Larry Wall
# on Thursday 11 September 2008 12:13:
>So when you put something into a list context, some of the values
>will be considered "easy", and some will be considered "hard".
>The basic question is whether we treat those the same or differently
>from a referential point of view. ...
>The easy ones are the values that have already been calculated,
>presumably...
>
>Suppose we have
>
> my @a = 1..10; # assume easy
> my @b = =$socket; # assume hard
>
> for @a,@b {...}
>
>If the for list sees @b as hard and just copies @b's iterator into its
>own list for lazy evaluation, then it's going to end up iterating the
>socket without loading @b. Contrariwise if @b is eagerly evaluated it
>might clobber the other iterator in the for list. So those iterators
>must be kept unified. It's not enough to copy out the iterators
>from the array; access to the hard elements of the array must still
>be modulated by the array container. A snapshot of the array
> container will not do in this case.
If a lazy list is an array with an iterator welded onto the end, then:
1 .. 10 is just: 1, 2, 3, weld_here iter(4, thru => 10)
1 .. * is just: 1, 2, 3, weld_here iter(4)
And because an iterator doesn't go backwards, the array has to remember
the previous values to allow me to maintain the "just an array"
abstraction, so after I asked for @a[3], the internal state is like:
1 .. * becomes: 1, 2, 3, 4, weld_here iter(5)
>As a first shot at that definition, I'll submit:
>
> 1 .. $n # easy
> 1 .. * # hard
>
>On the other hand, I can argue that if the first expression is easy,
>then the first $n elements of 1..* should also be considered easy, and
>it's not hard till you try to get to the *. :)
>
>It could also be that I'm confusing things here, of course, and that
>1..* is something easy and immutable that nevertheless cannot be
>calculated eagerly.
But you can take a copy of the "@a = 1 .. *" however you like as long
as "just an array" holds such that @a[41] is always the same regardless
of whether you (internally) have to kick the welded-on iter 27 times to
get that element or have already passed it. So in this case you could
(internally) end up with two copies each holding their own iter() in
different states while still giving the same result at the "just an
array" level. But this is just an optimization on the general case you
stated of "must be modulated by the array container" and it is an
optimization which is only possible for predictable iters.
So, perhaps the case is:
1 .. $n # bounded and predictable
1 .. * # unbounded and predictable
=$handle # bounded and unpredictable
=$socket # unbounded and unpredictable
By "unpredictable", I'm meaning simply that the value of a given element
cannot be calculated independently by replicating a (pure) function
f($i). Perhaps a filehandle isn't a thorough example of that though?
What about:
my @a = 1..*;
my @b = =$socket;
for @a,@b {...; @a = something(); ...}
or:
my @a = 1..*;
my @b = =$socket;
my @c = (@a, @b);
for @c {...; @a = something(); ...}
In the first case, changing @a changes the for() iterator but in the
second, the for() will still be nibbling on 1..*, right? So the
welded-on-iter is basically by-reference until I do something under
the "just an array" paradigm which breaks the weld?
@a = 1..*;
@a[-1] = 9; # @a = (9) now ?
That's just my thoughts from what I understand and sorry if introducing
welding into the analogy causes bits of molten metal to go flying
around ;-)
--Eric
--
"You can't win. You can't break even. You can't quit."
--Ginsberg's Restatement of the Three Laws of Thermodynamics
---
http://scratchcomputing.com
---
[perl #38764] [BUG] Test results of parrot on Freebsd
On our Smolder site, we're getting test results on FreeBSD (or, at least, i386-freebsd-64int) approximately every 70 minutes. Is there any reason to keep this ticket open? Thank you very much. kid51
[perl #38764] [BUG] Test results of parrot on Freebsd
On Fri Sep 12 20:24:06 2008, [EMAIL PROTECTED] wrote: > On our Smolder site, we're getting test results on FreeBSD (or, at > least, i386-freebsd-64int) approximately every 70 minutes. > > Is there any reason to keep this ticket open? > E ... we *were* getting hourly reports on FreeBSD up thru Sept 6. It appears that the bot that was generating all those *BSD reports is not currently operating. But that might not be a reason to not close this ticket.
Re: Iterator semantics
Qui, 2008-09-11 às 12:13 -0700, Larry Wall escreveu:
> And I guess the fundamental underlying constraint is that a list cannot
> be considered immutable unless its feeds can be considered immutable,
> at least in some kind of idempotent sense. This conflicts with the
> whole point of reactive programming, which is that you have to react
> because don't know what's coming.
This is actually something I was talking in the IRC this week. The
amount of polymorphism Perl 6 supports makes it quite impossible to
detect if the feeds can be considered immutable or not (in terms of
concept, I mean, runtime tips could allow optimizations).
But one thing needs to be clear, "List" is immutable as a type, meaning
that the API for List only allows you to read from it, not write to it,
but it doesn't necessarily means that it is immutable as an instance,
because the List might have a "live" backend.
Since List is not a native type, the interpreter doesn't really have any
control on what it does to provide its values, and that's what I mean by
saying that we can't infer if the feeds can or cannot be considered
immutables.
> This seems like it's close to the fundamental difficulty we're trying
> to solve here. And maybe the solution is much like the value/object
> distinction, where lists get to *decide* for themselves where they
> switch from easy eager immutable semantics to hard lazy reactive semantics.
> And if we're pretty clear about the boundary between those, it
> could work out much like the boundary between DFAable regexes and
> side-effectful regexes as defined in S05. And maybe it's even the
> same boundary in some theoretical sense.
The problem is that this concept should apply to the entire chain, this
means that it can only be considered easy if all the feeds on the chain
are easy, and it is too easy for it to be considered hard... for
instance, is a 'map' considered easy or hard?
In the end, that means that most of the time "easy" feeds will be made
dirty by hard feeds and all the chain will be made lazy, so we have
little gain.
In SMOP, I'm probably going to presume that everything needs to be lazy,
then even:
my @o = grep { /\d+/ } =$*IN;
my @a = (1,2,(3,4,@o));
my @b = (1,2,(3,4,@a));
Will still allow @b to be seen in slice context, where you would see @a
also in slice context, because @a was not eagerly evaluated when
composing @b, and eventually @o might never be evaluated.
I think this is consistent with the spec that says somewhere that the
only operators that imply eager evaluation are the short-circuit boolean
operators (besides the 'eager' operator, of course, and the use of lazy
values in void context).
Of course the spec only says that it should be lazy with the feed
operators, but in SMOP I tend to think that all this evaluation will be
lazy.
daniel
Re: Iterator semantics
On Fri, Sep 12, 2008 at 11:33 AM, Daniel Ruoso <[EMAIL PROTECTED]> wrote:
> In SMOP, I'm probably going to presume that everything needs to be lazy,
> then even:
>
> my @o = grep { /\d+/ } =$*IN;
> my @a = (1,2,(3,4,@o));
> my @b = (1,2,(3,4,@a));
Can only one array "have" the iterator? If not, that makes for =$*IN {
=$*IN if $needs_skipping } look like a forbidden idiom. On the other
hand, if it's really really lazy, then I could run the following two
statements without reading anything out of the iterator
my @digitlike = grep { /\d+/ } =$*IN;
my @hexlike = grep { /+/ } =$*IN;
But, if the taking of an iterator causes the array to autoactualize
(made this word up to parallel autovivify), what happens to the other
lazy array? Does the iterator buffer its contents to be served up to
other readers, or is the $iterator.next function
first-come-first-serve? Or is there some possible "batching" behavior
that allows one of the iterators to gobble more than is used?
given a non-deterministic iterator which would return <1 2 3 a b c 5 6
7 d e f 8 9 0>
say @digitlike[0..4];
say @hexlike[0..4]; # what's this? <1 2 3 a b> or <7 d e f 8> or
<> or undefined behavior?
In the event you picked <1 2 3 a b>, when did the @hexlike grep block
get called?
- Ashley Winters
