Re: Nested modules
Damian Conway wrote: Larry wrote: This kind of behaviour is more useful for nested classes, I suspect, but it should certainly be available for nested modules as well. So, what's the difference between a module and a class, and why would you want dynamic namespaces? Isn't that something you'd use a class for? I'm a bit confused. (-: - Joe
Re: Nested modules
Larry wrote:
In theory I suppose you could have objects with module attributes:
class Foo {
has module .Bar { ... }
}
Just don't ask me what it means...
Of course, Larry's just joking there...he knows precisely what it means.
It means that every object of class Foo has its own private version of
the .Bar module which in turn has its own private namespace. So that, for
example, any reference to a package variable of that module:
method Foo::baz {
$.Bar::qux++;
}
refers to the $qux variable belonging to the .Bar module belonging to the Foo
object on which the &baz method was invoked.
This kind of behaviour is more useful for nested classes, I suspect, but
it should certainly be available for nested modules as well.
Damian
Re: reducing size of the Devel::Cover html report
Personally, I find the POD useful when I'm going thru a Devel::Cover run. I interleave POD with functions and I like to refer to my docs. Well, since POD is intended to be documentation (not code or even comments) it seems reasonable to omit it from a coverage report. That said, if I can find a clean way to make it an option, I'll do so. If I've got docs for a function, then I want to see them while I'm considering the code. Code and documentation are, especially w/POD, interconnected. That's the beautiful thing about POD. -- Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: PATCH: (unofficial) Make Devel::Cover use Storable
On 11/3/2003 12:20 PM, Tim Bunce wrote: > On Tue, Oct 28, 2003 at 05:33:09PM +, [EMAIL PROTECTED] wrote: >> >> Right now, if your cover_db holds data for a dozen files, but you test them >> one at a time, you have to read and write *all* the coverage data (as well >> as have the RAM to hold it). That's a lot of unnecessary work and wasted >> memory. > > Generally there'll be a set of driving scripts (eg test scripts) and a bunch > of modules being used by the driving script. Coverage for most of the module > source files would be generated by most of the tests. Or am I missing > something (I've not looked closely, still). I probably just have a different perspective. Right now, I'm writing an application that's broken into a dozen or so modules. The test suite shares a common cover_db, and reading and rewriting the data for the modules I'm not currently testing takes extra time. To some degree, my position is just based on good software design -- don't use a bunch of memory or do a bunch of work if you don't need to. It might not matter for small dbs, but it doesn't scale. -mjc
Re: reducing size of the Devel::Cover html report
On 10/31/2003 8:08 AM, Andy Lester wrote: > > Personally, I find the POD useful when I'm going thru a Devel::Cover run. I > interleave POD with functions and I like to refer to my docs. Well, since POD is intended to be documentation (not code or even comments) it seems reasonable to omit it from a coverage report. That said, if I can find a clean way to make it an option, I'll do so. -mjc
Re: Nested modules
On Sun, Nov 02, 2003 at 07:50:05PM -0700, Luke Palmer wrote:
: So, we can have :: in names, but that doesn't represent any inherent
: relationship between the module before the :: and the one after. I
: think this is an important thing to keep.
:
: However, will it be possible to, for example, do:
:
: module Foo;
:
: module Bar { ... }
That just makes another global module named Bar. To get an inner
module, you'd have to use what we already use to get "packaged"
names of variables:
module Foo;
our module Bar { ... }
: And refer to the inner module as, say, Foo.Bar.
Its full name would be Foo::Bar. The other would be a Bar method
call on class Foo, presumably.
: A more interesting
: concept, can one use variables as modules, like:
:
: ::($foo)::somefunc();
:
: Or some awful thing like that?
Yes, there's going to be a ::() interpolation syntax for names.
: And of course this would imply the existance of anonymous modules. Yay.
Yes, and you left out lexical modules:
module Foo;
my module Bar { ... }
In theory I suppose you could have objects with module attributes:
class Foo {
has module .Bar { ... }
}
Just don't ask me what it means...
Larry
Re: Hoplites: Watch for "each"
On Mon, Nov 03, 2003 at 09:33:56AM -0600, Andy Lester wrote: > >But rather than post emails with such guidelines, only for them to > >be lost in the sands of time, wouldn't it be better to update the > >web site? > > Yeah, it would. I'd like to come up with a list of guidelines of > things to watch for. Lately, I've been spending my free time on prove > and Test::Harness. *cough*wiki*cough* ;) -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Stupid am I? Stupid like a fox!
This week's summary
The Perl 6 Summary of the week ending 20031102 It's Monday morning, the croissants have been baked, the focaccia is glistening with all the extra virgin olive oil I poured on it as it left the oven and, in the airing cupboard, a raisin borodinsky slouches towards full proof (thought at the rate it's currently rising it'll probably be Tuesday before I can bake it off), what better time could there be to pause and write a summary? So, I'll kick off with perl6-internals because, well, it's on the summary checklist (which goes something like: 1. Wibble about the weather or something before; 2. Start with perl6-internals; 3. Continue with perl6-language if it saw any traffic; 4. Make announcements, suggest people give money to the Perl Foundation; 5. Make sure Leon Brocard gets a mention; 6. Aspell; 7. Mail PODs to http://perl.com and a text version to perl6-announce; 8. Profit!) NULL Px Proposal Right at the end of the previous week, Melvin Smith suggested having the initial 'empty' PMC registers all point at a global PMCNull which would throw an exception if you tried to invoke any of its methods. Which sounds weird, but it does mean that you get a real exception instead of a segfault, and exceptions are so much more trappable. Dan liked the idea. Melvin later posted a patch implementing the idea, which Leo TÃtsch fixed up slightly an applied. http://xrl.us/2w8 http://xrl.us/2w9 Parrot Calling Convention Confusion Steve Fink is having problems using an unprototyped call to a prototyped function, which he thinks is a reasonable thing to do (and I think I agree with him; I can imagine cases where you have a function pointer or something where you don't know its exact prototype, but you do want to make a call to it so you'd be forced to make an unprototyped call.). Melvin Smith disagrees with him. Steve then went on to point out that he's still getting failures when the function is both declared and called in an unprototyped fashion. According to Leo, this is because unprototyped returns are neither defined nor implemented. Which is odd really -- I thought they were exactly the same as an unprototyped call, but you invoke the return continuation (P1) instead of P0, the other registers are set up exactly as if you were making an unprototyped function call. http://xrl.us/2xa A clash of symbols Arthur Bergman, Ponie stablemaster, popped up to point out that definitions like #define version obj.version (found in include/parrot/pobj.h if you're interested) did some scary things to "Perl_utilize" in the Perl 5 core. Steve Fink stuck his hand up to being the person who added the version field (which is apparently rather handy if you're debugging the Garbage Collection (GC) system. Leo fixed things by applying a "s/version/pobj_version/g" patch. http://xrl.us/2xb Storing external data in PMCs Arthur popped up again asking for help with implementing a Perl5LVALUE PMC. It turns out that the API doesn't quite support what he needs. After a certain amount of discussion of various options Arthur proposed a "Parrot_PMC_attach_data(Parrot, PMC, *void)" extension to the API. He didn't *quite* get what he wanted, but he got something very like it later in the week. I did like Arthur's reasons for starting the serious Ponie effort by working on Perl5LVALUEs though: "[because] it is so obscure that it's hardly used anywhere and is limited to a few small areas in the core". http://xrl.us/2xc Screaming Pumpkins Ahoy! On Monday, Leo declared that yes, Melvin Smith's proposed Halloween 'Screaming Pumpkin' Parrot release would be happening. Various people promised extra goodies, and a few problems were sorted out with some platforms. Features were frozen on Wednesday and Parrot 0.0.13 "Screaming Pumpkin" was released upon a cowering world at 2003103114:11:46 precisely. For all the astonishing speed of the release cycle, there's a lot of good stuff to be had in the screaming pumpkin, check out Leo's announcement for details. http://xrl.us/2xd http://xrl.us/2xe -- Leo's announcement Header Dependencies JÃrgen BÃmmels wasn't entirely happy with the way Parrot's headers are set up. Apparently there are some nasty dependency (and crypto dependency) issues. He proposed fixing up the headers as much as possible to eliminate these issues. Dan and Leo thought it would be nice, but Dan thought there wouldn't be that much point in doing it as things would probably decay, and pretty much everything internal should just be using parrot.h, and everything external should be using extend.h or embed.h. http://xrl.us/2xf Tinderboxen JÃrgen BÃmmels triggered a quick bout of tinderbox fixing, as various differe
Re: PATCH: (unofficial) Make Devel::Cover use Storable
On Tue, Oct 28, 2003 at 05:33:09PM +, [EMAIL PROTECTED] wrote: > Tim Bunce <[EMAIL PROTECTED]> wrote: > > On Tue, Oct 28, 2003 at 02:37:29PM +, [EMAIL PROTECTED] wrote: > >> > >> I ran some more tests, some of which might be more significant: > >> > >>time(sec) db size (kB)peak RAM (MB) > >> no coverage 15 --- ~ 10 > >> Data::Dumper+eval246 245 ~ 23.4 > >> Storable 190 60 ~ 19.7 > >> no storage 184 --- ~ 18 > > > > Excellent. From 23.4-18 to 19.7-18 is 5.4 to 1.7. So Storable is > > taking only 30% of the time that Data::Dumper+eval took. > > You're looking at the column for peak RAM usage. D'oh. One of those days. Still, taking only 30% of the RAM is also good :) > The time difference is > 62 (246-184) vs 6 (190-184). So Storable is taking about 10% of the time > that Dumper+eval took. File IO is now pretty insignificant next to the > overhead of doing coverage. Hopefully that number will come down some, > eventually. Yeap. > >> Eventually, I think that a transition to a real database (where > >> you can read/write only the portions of interest) would be good. > > > > How would you define "portions of interest"? > > The files you're actually adding/updating coverage for. Right now, if > your cover_db holds data for a dozen files, but you test them one at a > time, you have to read and write *all* the coverage data (as well as > have the RAM to hold it). That's a lot of unnecessary work and wasted > memory. Generally there'll be a set of driving scripts (eg test scripts) and a bunch of modules being used by the driving script. Coverage for most of the module source files would be generated by most of the tests. Or am I missing something (I've not looked closely, still). Tim.
[perl #24400] Failure Letter
# New Ticket Created by "Microsoft Network System" # Please include the string: [perl #24400] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=24400 > file attachment: gerb.exe This e-mail in its original form contained one or more attached files that were infected with the [EMAIL PROTECTED] virus or worm. They have been removed. For more information on Road Runner's virus filtering initiative, visit our Help & Member Services pages at http://help.rr.com, or the virus filtering information page directly at http://help.rr.com/faqs/e_mgsp.html. -- attachment 1 -- url: http://rt.perl.org/rt2/attach/67011/50007/b4061f/DELETED0.TXT file attachment: gerb.exe This e-mail in its original form contained one or more attached files that were infected with the [EMAIL PROTECTED] virus or worm. They have been removed. For more information on Road Runner's virus filtering initiative, visit our Help & Member Services pages at http://help.rr.com, or the virus filtering information page directly at http://help.rr.com/faqs/e_mgsp.html.
Re: docs
Simon Glover <[EMAIL PROTECTED]> writes: > On Mon, 3 Nov 2003, Dan Sugalski wrote: > > > On Mon, 3 Nov 2003, Nick Kostirya wrote: > > > > > Catalog docs\ops is empty in 0.0.13 version. > > > Is it bug? > > > > I think that's leftover cruft. > > Well, we used to generate a .pod file for each .ops file, at build time, > which lived in here. However, we don't appear to be doing this anymore > (although I'm not sure when this changed). It's some left over error from "The Great Move". The ops files were searched at the root of parrot not in the new ops directory. I'm just testing a fix, if it works I will commit it. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
From the "Interesting, but is it useful?" department
I've been playing with an "uncommitted" op version of invoke
that takes a method or sub by name like below:
invoke "foo", 0
The 0 is irrelevant to the eye, but it is a placeholder for the self-modifying
instruction. Upon call, invoke by name does:
op invoke(STR, INT)
PMC sub
if($2 == 0) {
sub = lookup $1
$2 = sub # store the ref in the immediate data of the instruction
}
else {
sub = (PMC*)$2
}
sub->vtable->invoke()
}
Basically it is just caching the lookup into the immediate data portion
of the bytecode instruction.
It isn't really anything new, this has been done before in VMs, but
the problem becomes the PMC that is stored in the bytecode is unknown
to the GC/DOD. Easy enough to fix, rather than store the PMC * itself,
simply keep a method_cache[] that the DOD can traverse, and store
only the array slot in the bytecode.
Maybe this is only syntactic sugar, I don't know.
The case is a win for loops that call the same method.
P0 = find_method "foo" # Lookup by name
LOOP:
invoke P0
if something goto LOOP
becomes:
LOOP
invoke "foo" # Lookup by name only the 1st execution
if something goto LOOP
There is no register usage for the method PMC.
Already, we are going to have a method_cache[] structure, so it follows
that we could allow for this shortcut simply to hide the cache for some
cases. This shortcut has the same challenges as the non-shortcut with
notifiying/invalidating PMC method references, so the same solutions apply.
The other question is: does this little trick apply to other things that do
lookups by name with constant strings?
-Melvin
Re: How to get environment variables?
I tried this one-line programme for example:
my %e = %ENV;
and got this (parrot-0.0.13/perl are built under mandrake linux):
Global '_HV_ENV' not found
Error: '/parrot-0.0.13/parrot -r env.imc ' failed with exit code 1
Stopped at /parrot-0.0.13/languages/perl6/perl6 line 339
main::mydie(256,'/parrot-0.0.13/parrot -r env.imc ') called at
/parrot-0.0.13/languages/perl6/perl6 line 819
main::pass4('env.imc','env.warn') called at
/parrot-0.0.13/languages/perl6/perl6 line 741
main::pass2('env.imc','env.warn') called at
/parrot-0.0.13/languages/perl6/perl6 line 435
main::output_tree('P6C::prog=ARRAY(0x8ef6e5c)','env.p6','env.warn')
called at /parrot-0.0.13/languages/perl6/perl6 line 500
main::pass1('Parse::RecDescent=HASH(0x8f2ed70)','env.p6','env.warn','undef') called at /parrot-0.0.13/languages/perl6/perl6 line 562
main::run() called at /parrot-0.0.13/languages/perl6/perl6 line 219
Are you sure you're using the Perl 6 hash syntax? (%ENV{FOO} rather than Perl
5-style $ENV{FOO})
What version of Perl 6 are you using?
Re: docs
On Mon, 3 Nov 2003, Dan Sugalski wrote: > On Mon, 3 Nov 2003, Nick Kostirya wrote: > > > Catalog docs\ops is empty in 0.0.13 version. > > Is it bug? > > I think that's leftover cruft. Well, we used to generate a .pod file for each .ops file, at build time, which lived in here. However, we don't appear to be doing this anymore (although I'm not sure when this changed). Simon
Re: Hoplites: Watch for "each"
At 17:51 +0100 11/3/03, Rafael Garcia-Suarez wrote: Elizabeth Mattijsen wrote: > Just wondering, is keys() optimized for void context? Perlfunc only states: > As a side effect, calling keys() resets the HASHâ¤_s internal iterator... Yes, it is. Ok, so it is indeed "cheap"! > If keys() _is_ optimized for void context, a change in the > perlfunc.pod seems to be in order. Thanks, applied as #21644 :) No, thank _you_! ;-) Liz
Re: [perl #24257] [PATCH] Integration of ICU to the build system
"Jürgen" "Bömmels" (via RT) <[EMAIL PROTECTED]> writes: > The attached patch makes it an optional part of the normal build > system. By using the switch --buildicu the ./configure of icu/source > is run and the makefile is extended with rules for building and > cleaning icu. This option is not enabled by default. Solving Warnocks dilemma by appling the patch. boe
Re: Hoplites: Watch for "each"
Elizabeth Mattijsen wrote: > Just wondering, is keys() optimized for void context? Perlfunc only states: > > As a side effect, calling keys() resets the HASHâ¤_s internal iterator... Yes, it is. > If keys() _is_ optimized for void context, a change in the > perlfunc.pod seems to be in order. Thanks, applied as #21644 :) --8<-- As a side effect, calling keys() resets the HASH's internal iterator, -see L. +see L. (In particular, calling keys() in void context resets +the iterator with no other overhead.) -->8--
Re: docs
On Mon, 3 Nov 2003, Nick Kostirya wrote: > Hello. > I have several questions about parrot dosc. > > I have noticed that docs\parrot_assembly.pod is old version of > \docs\pdds\pdd06_pasm.pod file. > Will these files be distinguished in the future? And they're both wrong, unfortunately. :( pdd06 is supposed to be canonical, so parrot_assembly.pod will be going away at some point. And PDD06 will be updated. > Catalog docs\ops is empty in 0.0.13 version. > Is it bug? I think that's leftover cruft. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Hoplites: Watch for "each"
At 14:06 + 11/3/03, Tim Bunce wrote: Its cheap to reset an itterator, just do keys %foo; before the C loop. Just wondering, is keys() optimized for void context? Perlfunc only states: As a side effect, calling keys() resets the HASH⤁s internal iterator... If it is _not_ optimized for void context, I think it's "easy" to reset rather than "cheap" ;-) If keys() _is_ optimized for void context, a change in the perlfunc.pod seems to be in order. Liz
docs
Hello. I have several questions about parrot dosc. I have noticed that docs\parrot_assembly.pod is old version of \docs\pdds\pdd06_pasm.pod file. Will these files be distinguished in the future? Catalog docs\ops is empty in 0.0.13 version. Is it bug? Nick.
Re: Hoplites: Watch for "each"
On Mon, Nov 03, 2003 at 02:06:01PM +, Tim Bunce wrote: > A separate issue with C is that code using it generally assumes > that the has itterator is at the start of the hash. If it's not > (because an C loop somewhere terminated early, for example) > then some items of the hash will be skipped. A very hard to find bug. > Its cheap to reset an itterator, just do > keys %foo; > before the C loop. Similarly, I had a nasty bug in Class::DBI for a while where a reference to the hash being iterated over was being passed off to another method inside that loop. When the method being called did anything with the hash it reset the loop ... Tony
Re: Hoplites: Watch for "each"
But rather than post emails with such guidelines, only for them to be lost in the sands of time, wouldn't it be better to update the web site? Yeah, it would. I'd like to come up with a list of guidelines of things to watch for. Lately, I've been spending my free time on prove and Test::Harness. xoa -- Andy Lester [EMAIL PROTECTED], AIM:petdance http://petdance.com/ http://use.perl.org/~petdance/
Re: [perl #24392] [PATCH] P6C xor really does return a value
applied thanks. /s
Re: [perl #24391] [PATCH] P6C closures use 'newsub' instead of assigning integer address
thanks, applied. /s
Re: How to get environment variables?
[EMAIL PROTECTED] (Andrew Shitov) writes:
> Is it possible to get environment variables from perl6 programme? It
> failes when I try to use perl5 hash %ENV. Thanks.
Are you sure you're using the Perl 6 hash syntax? (%ENV{FOO} rather than Perl
5-style $ENV{FOO})
What version of Perl 6 are you using?
--
"The C Programming Language -- A language which combines the power of
assembly language with the flexibility of assembly language."
[perl #24396] FAIL parrot-0.0.13 MSWin32-x86-multi-thread
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #24396] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=24396 > ... t\src\io..NOK 9# Failed test (t\src\io.t at line 242) # got: '"temp.file" ">" should have opened # "temp.file" ">>" should have opened # "temp.file" "+<" should have opened # "temp.file" "+>" should have opened # "does_not_exist" ">>" should have opened # "does_not_exist" "+<" should have opened # "does_not_exist" "+>" should have opened # done # ' # expected: 'done # ' t\src\io..NOK 10# Failed test (t\src\io.t at line 293) # got: 'should have read "." not ".☺/"done # ' # expected: 'done # ' t\src\io..ok 16/16# Looks like you failed 2 tests of 16. t\src\io..dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 9-10 Failed 2/16 tests, 87.50% okay (less 1 skipped test: 13 okay, 81.25%) t\src\listok t\src\manifestok 2/4 skipped: No CVS version t\src\sprintf.ok Failed Test Stat Wstat Total Fail Failed List of Failed --- t\src\io.t 2 512162 12.50% 9-10 5 subtests skipped. Failed 1/9 test scripts, 88.89% okay. 2/59 subtests failed, 96.61% okay. NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0xff' Stop. Summary of my parrot 0.0.13 configuration: configdate='Mon Nov 3 06:07:45 2003' Platform: osname=MSWin32, archname=MSWin32-x86-multi-thread jitcapable=1, jitarchname=i386-MSWin32, jitosname=MSWIN32, jitcpuarch=i386 execcapable=0 perl=C:\Perl\bin\perl.exe Compiler: cc='cl', ccflags='-nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT ', Linker and Libraries: ld='link', ldflags='-nologo', cc_ldflags='/link', libs='oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib' Dynamic Linking: so='.dll', ld_shared='-dll', ld_shared_flags='-def:libparrot.def' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=4 byteorder=1234, nv=double, numvalsize=8, doublesize=8 __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/
Re: Hoplites: Watch for "each"
On Sun, Nov 02, 2003 at 12:20:11AM -0600, Andy Lester wrote:
> >>Anything that uses the C operator is a prime candidate for
> >>bugginess. Please keep an eye out for them as you do your testing.
> >>Any function that contains C oughta be heavily checked.
> >>
> >>Ditto anything that uses C or C without a sort.
>
> Elaborating: Code that uses C, C or C may have
> worked in the past because the order of elements would be the same
> between runs. For instance, you have one hash, and then another hash
> with the same keys, and the code relies on those keys being in the same
> order between the hashes. This reliance might be explicit or
> accidental. Now, with 5.8.1 randomizing hashes, that code may break.
>
> Also, in .t files, it'd be a good thing to not rely on each/keys/values
> when determining the order of tests, because subsequent test runs might
> not be in the same order. For example:
>
> my %tests = ( test1 => 'foo', test2 => 'bar', etc );
>
> while ( my($key,$val) = each %tests ) {
> # do a test
> }
>
> The order in which these tests are done will be different between runs
> of the code...
A separate issue with C is that code using it generally assumes
that the has itterator is at the start of the hash. If it's not
(because an C loop somewhere terminated early, for example)
then some items of the hash will be skipped. A very hard to find bug.
Its cheap to reset an itterator, just do
keys %foo;
before the C loop.
But rather than post emails with such guidelines, only for them to
be lost in the sands of time, wouldn't it be better to update the
web site?
Tim.
Strings PDD
In an attempt to understand what the plan is with regard to ICU and Parrot strings in general, I've been gathering together links to previous bits of discussion on: http://www.vendian.org/parrot/wiki/bin/view.cgi/Main/ ParrotDistributionUnicodeSupport Obviously what is still needed is a Strings PDD. I wonder could we write it interactively on the wiki? Mike On 3 Nov 2003, at 11:17, Peter Gibbs wrote: Whilst attempting to implement DBCS encoding, I have discovered that skip_backward cannot be implemented for this encoding style, due to the mixture of 1-byte and 2-byte characters. Some of the available options: 1) Throw an exception if somebody tries to skip_backward in a DBCS string 2) Standardise on a single Unicode format for all internal string processing 3) Convert all strings in DBCS encoding to another format, either always or only when skip_backward is invoked 4) Pass additional context information to skip_backward, so it can fall back to counting forward when required 5) Remove skip_backward completely 6) Do not support DBCS encoding 7) Create an index for DBCS strings (i.e. a map of character offset versus byte offset) - this would also require that skip_backward receive additional data More options, preferences, comments, etc all welcome. Regards Peter Gibbs EmKel Systems
[perl #24392] [PATCH] P6C xor really does return a value
# New Ticket Created by Allison Randal # Please include the string: [perl #24392] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=24392 > This patch changes the test instead of the code. The code is actually correct. (We decided earlier this year that xor should be consistent with the other binary logical operators and return the value of the operand when it evalates as true.) The symbol '~~' is out-of-date, it should be '^^' now, but that's better fixed in one sweeping operator update patch. This is the last failing test except for the regex tests. I'm leaving that section assuming Steve's changes will make it obsolete. Allison -- attachment 1 -- url: http://rt.perl.org/rt2/attach/66980/49982/ee2905/p6c_xor_returns_value.patch Index: languages/perl6/t/compiler/basic.t === RCS file: /cvs/public/parrot/languages/perl6/t/compiler/basic.t,v retrieving revision 1.1 diff -d -u -r1.1 basic.t --- languages/perl6/t/compiler/basic.t 13 Oct 2003 17:00:57 - 1.1 +++ languages/perl6/t/compiler/basic.t 3 Nov 2003 01:32:16 - @@ -154,8 +154,8 @@ 0 -1 -1 +2 +2 0 0 0
[perl #24391] [PATCH] P6C closures use 'newsub' instead of assigning integer address
# New Ticket Created by Allison Randal
# Please include the string: [perl #24391]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=24391 >
Several tests in t/compiler/call.t were failing with the error:
set_integer_native() not implemented in class 'Sub'
and t/compiler/exceptions.t with the error:
set_integer_native() not implemented in class 'Continuation'
These are resolved by using the 'newsub' syntax instead of assigning an
integer address to the Sub/Continuation PMCs.
Allison
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/66978/49979/bb19f7/p6c_newsub_syntax.patch
Index: languages/perl6/P6C/IMCC.pm
===
RCS file: /cvs/public/parrot/languages/perl6/P6C/IMCC.pm,v
retrieving revision 1.28
diff -d -u -r1.28 IMCC.pm
--- languages/perl6/P6C/IMCC.pm 13 Oct 2003 17:00:41 - 1.28
+++ languages/perl6/P6C/IMCC.pm 3 Nov 2003 00:38:07 -
@@ -1868,10 +1868,8 @@
# Create a closure.
set_function($ofunc);
$ret = newtmp 'Sub';
- my $itmp = gentmp 'int';
code(<{ctx});
}
Index: languages/perl6/P6C/IMCC/prefix.pm
===
RCS file: /cvs/public/parrot/languages/perl6/P6C/IMCC/prefix.pm,v
retrieving revision 1.17
diff -d -u -r1.17 prefix.pm
--- languages/perl6/P6C/IMCC/prefix.pm 13 Oct 2003 17:00:48 - 1.17
+++ languages/perl6/P6C/IMCC/prefix.pm 3 Nov 2003 00:38:07 -
@@ -747,14 +747,12 @@
my $catch;
my $result;
my $ret = gentmp 'pmc';
-my $addr = newtmp 'int';
if ($catcher) {
$catch = genlabel 'catch';
$label = $catch;
}
code(<
DBCS versus skip_backward
Whilst attempting to implement DBCS encoding, I have discovered that skip_backward cannot be implemented for this encoding style, due to the mixture of 1-byte and 2-byte characters. Some of the available options: 1) Throw an exception if somebody tries to skip_backward in a DBCS string 2) Standardise on a single Unicode format for all internal string processing 3) Convert all strings in DBCS encoding to another format, either always or only when skip_backward is invoked 4) Pass additional context information to skip_backward, so it can fall back to counting forward when required 5) Remove skip_backward completely 6) Do not support DBCS encoding 7) Create an index for DBCS strings (i.e. a map of character offset versus byte offset) - this would also require that skip_backward receive additional data More options, preferences, comments, etc all welcome. Regards Peter Gibbs EmKel Systems
How to get environment variables?
Is it possible to get environment variables from perl6 programme? It failes when I try to use perl5 hash %ENV. Thanks.
Re: Nested modules
Luke Palmer wrote:
So, we can have :: in names, but that doesn't represent any inherent
relationship between the module before the :: and the one after. I
think this is an important thing to keep.
However, will it be possible to, for example, do:
module Foo;
module Bar { ... }
And refer to the inner module as, say, Foo.Bar.
Kinda like an inner class in Java?
A more interesting
concept, can one use variables as modules, like:
::($foo)::somefunc();
except dynamic?
(On a side note, that syntax doesn't seem right, although I can't
fathom what is...)
Or some awful thing like that?
And of course this would imply the existance of anonymous modules. Yay.
How... would that be useful? What would one use an anonymous
module for that they couldn't do with an anonymous class? I
thought a module was more of a compiletime distinction, while
a class was a runtime + compiletime (i.e. all encompassing)
one.
- Joe
