Re: [perl #35980] [PATCH] configure GMP with MinGW32
At 17:07 26/05/2005 +0200, you wrote: François PERRAD (via RT) wrote: This small patch allows the configuration of GMP with MinGW32. And tests are OK. But only on MinGW32 maybe ;-) On my linux box gmp isn't linked in any more. I'd say keep the OS test as is, but exclude MinGW. And there are a lot compilers that aren't gcc but need -lgmp. OK, a new version of this patch. leo gmp2.patch Description: Binary data
RE: (OT) Re: Perl development server
Icelandic: laukur (Incidentally, none of you will ever guess how to correctly pronounce that.) Russian: luk (pronounced similar to English look). For some reason, Icelandic translation of onion is much closer to Russian than any other variants...
darcs patch: Make Pugs.AST.Internals compilation more... (and 1 more)
Thu May 26 22:49:09 EDT 2005 Samuel Bronson [EMAIL PROTECTED]
* Make Pugs.AST.Internals compilation more bearable
Thu May 26 22:52:31 EDT 2005 Samuel Bronson [EMAIL PROTECTED]
* Make Pugs.Parser compilation more bearable
New patches:
[Make Pugs.AST.Internals compilation more bearable
Samuel Bronson [EMAIL PROTECTED]**20050527024909] {
hunk ./src/Pugs/AST/Internals.hs 3
+{-# OPTIONS_GHC -v -O0 #-}
}
[Make Pugs.Parser compilation more bearable
Samuel Bronson [EMAIL PROTECTED]**20050527025231] {
hunk ./src/Pugs/Parser.hs 3
+{-# OPTIONS_GHC -v -O0 #-}
}
Context:
[r3955
[EMAIL PROTECTED]**20050527022613]
[r3954
[EMAIL PROTECTED]**20050527021922]
[r3953
[EMAIL PROTECTED]**20050527021800]
[r3952
[EMAIL PROTECTED]**20050527021426]
[r3951
[EMAIL PROTECTED]**20050527020947]
[r3950
[EMAIL PROTECTED]**20050527020607]
[r3948
[EMAIL PROTECTED]**20050527020429]
[r3947
[EMAIL PROTECTED]**20050527014235]
[r3946
[EMAIL PROTECTED]**20050527014006]
[r3945
[EMAIL PROTECTED]**20050527013738]
[r3944
[EMAIL PROTECTED]**20050527012834]
[r3943
[EMAIL PROTECTED]**20050527011621]
[r3942
[EMAIL PROTECTED]**20050527010053]
[r3941
[EMAIL PROTECTED]**20050527004220]
[r3940
[EMAIL PROTECTED]**20050527003948]
[r3939
[EMAIL PROTECTED]**20050527003615]
[r3938
[EMAIL PROTECTED]**20050527002617]
[r3937
[EMAIL PROTECTED]**20050527000944]
[r3936
[EMAIL PROTECTED]**2005052746]
[r3935
[EMAIL PROTECTED]**20050526235227]
[r3934
[EMAIL PROTECTED]**20050526233135]
[r3933
[EMAIL PROTECTED]**20050526230821]
[r3932
[EMAIL PROTECTED]**20050526225348]
[r3931
[EMAIL PROTECTED]**20050526224648]
[r3930
[EMAIL PROTECTED]**20050526224524]
[r3929
[EMAIL PROTECTED]**20050526223615]
[r3928
[EMAIL PROTECTED]**20050526223447]
[r3927
[EMAIL PROTECTED]**20050526223111]
[r3926
[EMAIL PROTECTED]**20050526221642]
[r3925
[EMAIL PROTECTED]**20050526221516]
[r3924
[EMAIL PROTECTED]**20050526215518]
[r3923
[EMAIL PROTECTED]**20050526215336]
[r3922
[EMAIL PROTECTED]**20050526214850]
[r3921
[EMAIL PROTECTED]**20050526214158]
[r3920
[EMAIL PROTECTED]**20050526213604]
[r3919
[EMAIL PROTECTED]**20050526211142]
[r3918
[EMAIL PROTECTED]**20050526152418]
[r3917
[EMAIL PROTECTED]**20050526145341]
[r3916
[EMAIL PROTECTED]**20050526145216]
[r3915
[EMAIL PROTECTED]**20050526145054]
[r3914
[EMAIL PROTECTED]**20050526144915]
[r3913
[EMAIL PROTECTED]**20050526143145]
[r3912
[EMAIL PROTECTED]**20050526135026]
[r3911
[EMAIL PROTECTED]**20050526123936]
[r3910
[EMAIL PROTECTED]**20050526113739]
[r3909
[EMAIL PROTECTED]**20050526113052]
[r3908
[EMAIL PROTECTED]**20050526103902]
[r3905
[EMAIL PROTECTED]**20050526095904]
[r3904
[EMAIL PROTECTED]**20050526095743]
[r3903
[EMAIL PROTECTED]**20050526083223]
[r3902
[EMAIL PROTECTED]**20050526040759]
[r3901
[EMAIL PROTECTED]**20050526035906]
[r3899
[EMAIL PROTECTED]**20050526022326]
[* r3894
[EMAIL PROTECTED]**20050526032842]
Patch bundle hash:
c52fb51ff57292535c161cba6d8a8d2b9852d6ea
[perl #35997] [PATCH] configure gdbm with MinGW32
# New Ticket Created by Franois PERRAD # Please include the string: [perl #35997] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=35997 This patch allows configuration of gdbm with MinGW32. Francois Perrad gdbm.patch Description: Binary data
[perl #35994] [PATCH] p6rules named capture tests
# New Ticket Created by Dino Morelli
# Please include the string: [perl #35994]
# in the subject line of all future correspondence about this issue.
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=35994
Added tests in t/p6rules/capture.t for named alias captures.
file:
t/p6rules/capture.t
-Dino
--
.~.Dino Morelli
/V\email: [EMAIL PROTECTED]
/( )\ weblog: http://categorically.net/d/blog/
^^-^^ preferred distro: Debian GNU/Linux http://www.debian.orgIndex: t/p6rules/capture.t
===
--- t/p6rules/capture.t (revision 8172)
+++ t/p6rules/capture.t (working copy)
@@ -1,6 +1,9 @@
-use Parrot::Test tests = 34;
+use strict;
+use warnings;
+use Parrot::Test tests = 38;
use Parrot::Test::PGE;
+
p6rule_is ('zzzabcdefzzz', '(a.)..(..)', 'basic match');
p6rule_like('zzzabcdefzzz', '(a.)..(..)', qr/mob: abcdef @ 3/, 'basic $0');
p6rule_like('zzzabcdefzzz', '(a.)..(..)', qr/mob 0: ab @ 3/, 'basic $1');
@@ -56,6 +59,15 @@
p6rule_like('abcdefg', '$1:=[ (.) (.) (.) ] (.)', qr/mob 5: d @ 3/,
'perl5 numbered captures $1');
+p6rule_like(' abc = 123', ':w $key:=[\w+] = $val:=[\S+]',
+qr/mobkey: abc @ 3/, 'named capture');
+p6rule_like(' abc = 123', ':w $key:=[\w+] = $val:=[\S+]',
+qr/mobval: 123 @ 9/, 'named capture');
+p6rule_like(' abc def ghi', ':w (\w+) $foo:=(\w+) (\w+)',
+qr/mobfoo: def @ 7/, 'mixing named and unnamed capture');
+p6rule_like(' abc def ghi', ':w (\w+) $foo:=(\w+) (\w+)',
+qr/mob 1: ghi @ 11/, 'mixing named and unnamed capture');
+
p6rule_is ('bookkeeper', '[(.)$0]+', 'backreference');
p6rule_like('bookkeeper', '[(.)$0]+',
qr/mob 0 0: o @ 1/, 'backref $1');
@@ -65,8 +77,7 @@
qr/mob 0 2: e @ 5/, 'backref $1');
p6rule_like('123x', '(.)*x',
-qr/mob: 123x @ 0/, 'repeated dot capture')
+qr/mob: 123x @ 0/, 'repeated dot capture');
-
-# dont forget to change the number of test :-)
+# Don't forget to change the number of test :-)
Re: Syntax of using Perl5 modules?
You get all those possibilities whenever you install any new version of a module you get from someone else, regardless of a p5-p6 hop. In p6, when you say use Digest;, you are specifically asking for what p6 considers the latest version. In p5, it was first match on libpath. Except that within Perl 5, there is an general expectation that the same API will exist across multiple module versions. It is assumed that newer versions of a module will continue to work the same as older ones, with API breakages being a bad and rare thing. The 6 month long mod_perl Apache::-Apache2:: argument was over this very thing. There is a huge difference between an API version and a module (implementation) version. As far as I'm aware, there is no expectation that *every* module in Perl 6 that shares a name with a module in Perl 5 will merely be a re-implementation of the same API in Perl6. If I am expected to reimplement all my Perl 5 modules in Perl 6 without the opportunity to do a better job and take advantage of new Perl 6 API-related features, could someone please point my boot in the general direction of the ass of whoever came up with that idea. Adma K
Re: Sets (was: Reductions, junctions, hashslices, and cribbage scoring)
On Thu, 26 May 2005, Patrick R. Michaud wrote: The continuing exchanges regarding junctions, and the ongoing tendency by newcomers to think of them and try to use them as sets, makes me feel that it might be worthwhile to define and publish a standard CSet class and operations sooner rather than later in Perl 6 development. This might reduce the tendency to confuse junctions I fully second that. You can search the archives for my own thoughts on the subject. Michele -- you'll see that it shouldn't be so. AND, the writting as usuall is fantastic incompetent. To illustrate, i quote: - Xah Lee trolling in clpmisc, perl bug File::Basename and Perl's nature
Re: Syntax of using Perl5 modules?
Adam Kennedy wrote: You get all those possibilities whenever you install any new version of a module you get from someone else, regardless of a p5-p6 hop. In p6, when you say use Digest;, you are specifically asking for what p6 considers the latest version. In p5, it was first match on libpath. Except that within Perl 5, there is an general expectation that the same API will exist across multiple module versions. It is assumed that newer versions of a module will continue to work the same as older ones, with API breakages being a bad and rare thing. The 6 month long mod_perl Apache::-Apache2:: argument was over this very thing. There is a huge difference between an API version and a module (implementation) version. As far as I'm aware, there is no expectation that *every* module in Perl 6 that shares a name with a module in Perl 5 will merely be a re-implementation of the same API in Perl6. If I am expected to reimplement all my Perl 5 modules in Perl 6 without the opportunity to do a better job and take advantage of new Perl 6 API-related features, could someone please point my boot in the general direction of the ass of whoever came up with that idea. soapbox Across all languages, libraries, modules, applications, operating systems, and most everything else in the computer world, I expect interoperability to remain mostly the same across minor version numbers, but anything goes when a new major version comes out. Now, I'm not terribly active in the CPAN arena, but I think it's short sighted to expect the API from version 1.1.5 to still be there in 2.7.1. This phenomenon is why it's fairly common to see the last minor version of the previous major version still around and available in many areas. Major changes in usage and syntax are what major version jumps are all about. /soapbox As an alternative, the URI field of the module version could be extended to have the API version mixed somehow, maybe cpan:JRANDOM#1.5.6. But that gets non-intuitive and ugly very quickly. Part of the p5 problem is that module upgrades were all or nothing. In p6, you'll be able to load both the old version and the new version, at the same time. Or just tell the old apps that you don't have time to fix to use versions 2.0.0, and the new apps to use version = 2.0.0. Another part of the problem with p5 is that while there was the ability to spec a version in a 'use' call, it was only a lower bound. You couldn't specify an upper bound as well, to tell people that you weren't ready for a new API/semantics. (To my knowledge, _nobody_ overrides the VERSION method) Personally, I would prefer having to track which major version number I'm using over the mess that's in CPAN, where it seems like the standard way to introduce a new API is to come up with a new name for the module that means the same thing. However, as I pointed out before, since in p5 there is no notion of an author URI, haveing that become the string 'perl5' makes sense, and could be matched against, both positively and negatively. -- Rod Adams
Re: BigInt.pmc patch
Kevin Tew [EMAIL PROTECTED] wrote: Adds tests and fixes incorrect implementation. Thanks, applied - 8173 leo
Re: wanted: hash stress tests
Bob Rogers [EMAIL PROTECTED] wrote: This patch adds deletion to the same case. Testing also caught a missing label in the original version, for a branch that was never taken. Thanks, applied - 8175 leo
Re: [perl #35959] index opcode fails with large negative offset
Roger Browne [EMAIL PROTECTED] wrote: This pasm fragment... index I1, u, t, -123456 print I1 print \n end ...prints -32 instead of the expected -1. ... or somethin else, start wasn't verfied properly. Fixed (r8176), thanks for testing. leo
Re: [perl #35980] [PATCH] configure GMP with MinGW32
François PERRAD [EMAIL PROTECTED] wrote: a new version of this patch. Thanks, applied - 8174 leo
Re: [perl #35997] [PATCH] configure gdbm with MinGW32
François PERRAD [EMAIL PROTECTED] wrote: This patch allows configuration of gdbm with MinGW32. Thanks, applied - 8177 leo
[perl #36003] Opcode 'mod' fails for negative integers
# New Ticket Created by Roger Browne # Please include the string: [perl #36003] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36003 The following pir program: .sub test @MAIN $I1 = mod 3, 3 print 3 mod 3 = print $I1 print \n $I1 = mod -3, 3 print -3 mod 3 = print $I1 print \n $I1 = mod 3, -3 print 3 mod -3 = print $I1 print \n $I1 = mod -3, -3 print -3 mod -3 = print $I1 print \n end .end ...prints this: 3 mod 3 = 0 -3 mod 3 = 3 3 mod -3 = -3 -3 mod -3 = 0 ...but I believe it should print this: 3 mod 3 = 0 -3 mod 3 = 0 3 mod -3 = 0 -3 mod -3 = 0 ...according to the documentation at http://www.parrotcode.org/docs/ops/math.html and according to this discussion from 2001: http://www.nntp.perl.org/group/perl.perl6.internals/5496 Regards, Roger Browne [EMAIL PROTECTED]
Re: darcs patch: Make Pugs.AST.Internals compilation more... (and 1 more)
On Thu, May 26, 2005 at 10:58:12PM -0400, Samuel Bronson wrote: Thu May 26 22:49:09 EDT 2005 Samuel Bronson [EMAIL PROTECTED] * Make Pugs.AST.Internals compilation more bearable Thu May 26 22:52:31 EDT 2005 Samuel Bronson [EMAIL PROTECTED] * Make Pugs.Parser compilation more bearable Er, no, you can use make unoptimised (or make unoptimized) instead. Pugs.AST.Internals is the core of Pugs data types, so it needs to be fast. One thing we can do to improve the compilation speed is by factoring out that module into more Pugs.AST.* modules; patches welcome on that front. Thanks, /Autrijus/ pgpgbCwRJQzRB.pgp Description: PGP signature
Re: [perl #36003] Opcode 'mod' fails for negative integers
Roger Browne (via RT) wrote: The following pir program: [ ... ] ...but I believe it should print this: 3 mod 3 = 0 -3 mod 3 = 0 3 mod -3 = 0 -3 mod -3 = 0 IMHO too. I've updated intval_mod to consider the case of zero reminder with negative args (rev 8178). Thanks for testing, leo
Re: (1,(2,3),4)[2]
Markus Laire wrote:
@m[0;1] is a multidim deref, referencing the 4.
Referencing the 2, I hope?
Doh!
Yes, the 2.
Really?
I consider this puzzling indicative that the (,) vs. [,] distinction
in Perl6 falls into the same category as e.g. starting the capture
variables at $1.
@m here has _single_ array-ref so
@m[0] returns that single array-ref - [[1,2],[3,4]]
@m[0;1] then returns array-ref [3,4]
@m[0;0] would return [1,2]
@m[0;0;1] would return 2
Yea, that's the---in my eyes unfortunate---preservation of
reference level depending on the left side of assignment.
Or stated the other way round, the auto-referencing when
the lhs is a $ variable. BTW, are lvalue subs handled the
same as $ vars here?
Could the ones who know it, enlighten me *why* it has to be so?
What does it buy the newbie, average, expert Perl6 programmer?
The answer that's how Perl5 did it is a good default, but
never hindered @Larry to change things.
Here are some speculations from me:
1) On one hand @a shall be a single handle to an array but
always writing a total slice, or flattener when you want
to replace the array as a whole is considered cumbersome
or redundant. Thus @a = 1 is basically a shortcut for
@a[] = 1 or [EMAIL PROTECTED] = 1. Note that for keeping some of the
existing values one has to use a non-total index/slice
like @a[42] = 1.
Question: With @a = (0,1,2,3,4,5), what does @a[2..4] = 7 mean?
@a == (0,1,7,5)? @a == (0,1,7,7,7,5)? I think it's the former,
and the latter actually is written @a[2..4] »=« 7.
How about: @a[1] = @b? Is that storing a ref to @b in @a at
position 1? Then @a[1] = 23 puts the 23 into @b at position 0?
So to get it back one has to use @a[1][0]?
2) Since a distinction between (,) and [,] for arrays and
( = , = ) and { = , = } for hashes is /syntactically/ possible
it is used to separate values from refs. But context spills
over from the lhs, though. I wouldn't unify these directly but
through the following typing:
(,) -- Eager (but not flattening nested Lazy stuff)
.. -- Lazy
= -- Pair
( = , = ) -- Eager of Pair
[] -- Array (this actually doesn't need the comma op)
{} -- Hash (actually Code, but evaluated immediately if
recognizeable at compile time)
3) The example in 1) might actually be wrong if @a = 1 sets
the size of the array. I see a tendency in perlkind to
have special cases like it's a number assigned to an array,
so the size changes. The assignment is smutten with these
special meanings because an imperative language is built
around it. E.g. ($x,$y) = (1,2) falls in this category as
well. In a purer setting it could be required to write
($x,$y) »=« (1,2) as it is for ($x,$y) »+« (1,2). Hmm,
then this is ultra-pure: @a[] »=« (1,2,3). Note that when @a
always denotes a single handle @a »=« (1,2,3) could be expanded
to (@a = 1, @a = 2, @a = 3) not (@a[0] = 1, @a[1] = 2, @a[2] = 3).
4) I guess not many want @a = \1 to be valid. But why not?
prefix:{'\'}:( Any $x : -- Ref of $x.type ) could build
an anonymous Ref of Int and then that is assigned to the
array on the left making it two-dimensional because of the
reference. Thus getting back the 1 needs one of the following
forms: @a[0][0], @a[0][], [EMAIL PROTECTED] or [EMAIL PROTECTED] The first
three forms
assume that postcircumfix:[ ] is supported by the Ref type.
I'm still arguing in favor of a---possibly strictly compiler enforced---
least upper bound typing of plain sigil expressions:
-- Code
$ -- Item (if that is the name now)
@ -- Array
% -- Hash
The strict type enforcement would prevent things like
@foo = sub (Int $x) { return $x * $x }
say @foo(13); # prints 169
OTOH without it, going almost sigilless would just be
my foo = 3;
my bar = HaloO;
if foo 2 { say bar }
my array is Array;
array[12] = 17;
My line of thought might actually be easier to understand if
you treat = as a normally dispatched infix operator without any
special significance. The two operators ::= and := are *not*
dispatched. They are macros or a direct part of the grammar.
::= is mostly syntactic sugar for a BEGIN block and := is basically
compiled to the engine level destructive assignment operation.
But this view might also be completely wrong.
Regards,
--
TSa (Thomas Sandlaß)
Re: (1,(2,3),4)[2]
Juerd wrote:
From S02: Array and hash variable names in scalar context
automatically produce references.
Since [...] produces a scalar arrayref, we end up with an arrayref one
both sides of the =.
No.
There is no scalar context on the LHS of the assignment operator.
And, assigning to a reference is impossible, as a reference is a VALUE,
not a VARIABLE (container).
This argumentation breaks down as soon as you regard infix:{'='} as
an operator like many others. How do you derive context for the lhs
and rhs of infix:{'+'} or infix:{'*~*'}? From its invocant part of
the signature? With the sigil giving the default overrideable with the
'is context' param trait? Or does only the slurpy indicator * enforce
list context?
But then there might be a little bootstrapping problem with MMD if
both contexts are defined. How does one dispatch an Array then?
Junctively flattened and unflattened?
And another oddity is that the compiler has potentially to go back
and re-compile some code with invocations of ops if it later sees more
overloaded definitions of these ops that have other context traits in
their signature. It's much easier to just compile to MMD code and leave
the rest to the runtime dispatch. But this requires a self-contained
definition of the meaning of @a and [] as described by Rod.
--
TSa (Thomas Sandlaß)
Unicode Operators cheatsheet, please!
I would love to see a document (one per editor) that describes the Unicode characters in use and how to make them. The Set implementation in Pugs uses (at last count) 20 different Unicode characters as operators. While I'm sure these documents exist on the web somewhere, since P6 is the first time most of us will be using these operators, it'd be nice if P6 provided a nice cheatsheet for them. Thanks, Rob
Re: (1,(2,3),4)[2]
Juerd wrote:
And, assigning to a reference is impossible, as a reference is a VALUE,
not a VARIABLE (container).
What should hinder infix:{'='}:(Ref, Int: -- Int) to exist and be
usefull at least if the Ref is known to something that derefs it
and then finds the new referee? On the Perl6 language level references
are a means to share values. Don't mix that with the implementation
level references---which should be called pointers---that allow an
efficient implementation of handling heavyweight data.
--
TSa (Thomas Sandlaß)
Re: (1,(2,3),4)[2]
TSa (Thomas Sandlaß) skribis 2005-05-27 16:22 (+0200):
This argumentation breaks down as soon as you regard infix:{'='} as
an operator like many others.
Which we don't, making this discussion much easier for everyone.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: (1,(2,3),4)[2]
TSa (Thomas Sandlaß) skribis 2005-05-27 15:44 (+0200): Could the ones who know it, enlighten me *why* it has to be so? What does it buy the newbie, average, expert Perl6 programmer? The answer that's how Perl5 did it is a good default, but never hindered @Larry to change things. Because the alternative is to drop context. If we drop context, we have to use an array where we now use a list. And list automatically becomes an alias for array in our jargon. Also, arrays will then probably no longer have any referenceless version, and always be objects and thus references. Then we lose the point for having different sigils, and everything gets a dollar sign. The end result is very different from Perl, and can no longer be thought of even as derrived from Perl, in my opinion. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
tracing and debugging
Parrot's capabalities are increasing steadily, programs written for Parrot especially those emitted from compilers are getting bigger and bigger. Debugging Parrot programs didn't keep up with the pace and is becoming a PITA. Some notes. *) tracing or debugging an interpreter shall not influence that debugee. This implies that any code executed during tracing or debugging is run in a distinct interpreter. [1] [2] This leads to some questions of how we created interpreter clones or better: which interpreter vars and structures are how global. [3] *) we should have distinct trace flag options, e.g. --trace HLL_src | PIR_src | opcodes | subroutines *) getting HLL source into Parrot This is basically the same scheme as used for PASM/PIR source code. - the lexer parses #line file comments - this info is stored in a 2nd debug segment *) src/debug.c and ops/debug.ops I don't think that we should reinvent wheels and have a separate command language for debugging (e.g. PDB_cond). Instead I'm in favor of having just one opcode: debug_break and a Debugger PMC with methods to get e.g. register contents/lexicals/globals from the debugee. E.g. a conditional break point hook: # break if I5 == 5 .sub break_i5 method i = getattribute self, debugee $I0 = self.get_reg(i, I5) unless $I0 == 5 goto cont self.break() cont: cc = getattribute self, cont i.cc() # invoke return continuation in debugee .end *) pdb - the interactive debugger [4] pdb is basically unmaintained, buggy and outdated. leo [1] e.g. trace_op_dump uses PIO_eprintf which allocates mainly STRING* resources which changes DOD/GC counts of the interpreter. This can lead to the execution of different code paths and thus influences the running interpreter. [2] see USE_TRACE_DEBUG in src/runops_cores.c [3] src/global_setup.c:init_world() [4] make world or make pdb
Re: tracing and debugging
Leopold Toetsch wrote: [2] see USE_TRACE_DEBUG in src/runops_cores.c USE_TRACE_INTERP sorry, leo
Declarations of constants
Hi,
# Way 1
my $MEANING_OF_LIFE is constant = 42;
# Way 2
my MEANING_OF_LIVE = - () { 42 };
# or
sub MEANING_OF_LIVE () { 42 }
# Then one can use sigilless constants:
say MEANING_OF_LIVE;
# Way 3 (still possible?)
use constant MEANING_OF_LIVE = 42;
# Way 4 (evil?)
macro MEANING_OF_LIVE { 42 }
# Way 5 (overloading of the numification of Class -- evil)
Class does role {
method *prefix:+ (MEANING_OF_LIVE $class:) {
42;
}
}
class MEANING_OF_LIVE {}
say +MEANING_OF_LIVE;
# Please add more ways :)
--Ingo
--
Linux, the choice of a GNU | Black holes result when God divides the
generation on a dual AMD | universe by zero.
Athlon!|
Re: Declarations of constants
Ingo Blechschmidt wrote: # Please add more ways :) enum MEANING_OF_LIVE:(42); my MEANING_OF_LIVE = 42; # But might be considered evil sigilless mode -- TSa (Thomas Sandlaß)
Re: RFC - Class::Agreement
On 5/26/05, Adrian Howard [EMAIL PROTECTED] wrote:
-No class invariants?
Soon!
-You do mention that tweaking @_ in the pre/post blocks will
affect the @_ passed to the method. You don't say that having pre/
posts that have side effects is evil. You probably should :-)
Reflecting upon this, I'm not even sure why I'd want argument
modification as a feature. (Maybe I still had Hook::LexWrap on the
brain.) I might just take this out.
-It's not immediately obvious to me from reading the docs that
doing:
{ package SomeSubclass;
use base 'SomeClass'; # from your example
sub choose_word { return -1 };
}
would fail since choose_word should still be bound by the
SomeClass precondition. I'm assuming you're doing something clever
with INIT blocks or something so this does work.
INIT blocks? Nope, nothing clever. If you use a class' method before a
precondition statement, that method will simply not be bound to a
contract.
-On How can I type less?. I'm curious as to whether you
considered adding an automatic $self to match the $r/@r ?
When you say automatic, I think of source filtering. Do you simply
mean an alias for the first argument? If so, I think it's best to
leave that up to the programmer. You can always use shift.
-I'd want a global way of switching off contracts without having
to change the code. $ENV{ClassAgreementDisabled} = 1 or something.
Arg! This is a biggie. If used properly, you shouldn't need, let alone
*want*, to turn contracts off. Class::Agreement doesn't do any deep
cloning like Class::Contract. Class::Agreement's contracts should be
nearly as light as putting die unless in your methods.
I'll include that feature, but not without a big disclaimer such as the above.
-I had to read What do you mean, ``There's a problem with the
heirarchy?'' three times. More paragraphs and an example for the
slow of thinking like me please :-)
Definitely. More examples on the way.
Thanks, Adrian. This is much appreciated.
--
Ian Langworth
Re: (1,(2,3),4)[2]
HaloO Juerd, you wrote: Because the alternative is to drop context. ... Then we lose the point for having different sigils, and everything gets a dollar sign. Isn't the strong type system adequate compensation? Especially when the sigils denote the level below which you can't go in untypedness or unspecificity? The two new list types Eager and Lazy nicely fit the jargon term. Actually you could e.g. apply them to complete files and view them as a list of lines if that suites a certain task. OTOH, some classes might like to travel in variables with the @ and % sigil. E.g. my @data is DatabaseTable; my %tree is StructuredDocument; -- TSa (Thomas Sandlaß)
Re: Declarations of constants
Hi, TSa (Thomas Sandla) wrote: my MEANING_OF_LIVE = 42; # But might be considered evil sigilless mode is that allowed (as 42 is a Num (or an Int), not a Code)? Do (most of) the basic types morph themselves into Codes, when needed? say 42();# 42? say Perl();# Perl? say [1,2,3].does(Code) # true? Or did you simply forget the braces around 42? :) --Ingo -- Linux, the choice of a GNU | Wer die Freiheit aufgibt, um Sicherheit zu generation on a dual AMD | gewinnen, der wird am Ende beides Athlon!| verlieren -- Benjamin Franklin
Re: Declarations of constants
Ingo Blechschmidt wrote:
is that allowed (as 42 is a Num (or an Int), not a Code)?
I don't know, but guess not.
Do (most of) the basic types morph themselves into Codes, when needed?
I don't consider it type morphing. If your examples parse
at all they will be dispatched as usual
say 42();# 42?
postfix:.( ):( Int :)
say Perl();# Perl?
postfix:.( ):( Str :)
say [1,2,3].does(Code) # true?
Depends on the type of [] which is Ref of Array or so.
But I think it should be false.
Or did you simply forget the braces around 42? :)
No, it was intented for seeing what the reactions will be :)
Just using foo as unsigiled variable. This might need
my foo is rw;
But then I presume you could say:
foo = 17;
if foo 8
{
@a[foo] = 8;
}
We could call that a codeless lvalue sub ;)
--
TSa (Thomas Sandla)
Re: [perl #35976] [PATCH] Add Unicode, Hex, and Octal escapes to Tcl
Will Coleda [EMAIL PROTECTED] wrote: The attached patch provides a (possibly naive) implementation of the remaining escape characters from: http://www.tcl.tk/man/tcl8.5/TclCmd/Tcl.htm#M16 that were missing, namely \ooo (octal) \xhh (hex) and \u (unicode) Supplied as a patch as I know someone's in the middle of working on the parser right now. That was me. I've just checked in this patch (slightly altered) as part of my refactor (r8181). Thanks! :-) -- matt diephouse http://matt.diephouse.com
Re: Unicode Operators cheatsheet, please!
On Fri, May 27, 2005 at 10:29:39AM -0400, Rob Kinyon wrote: I would love to see a document (one per editor) that describes the Unicode characters in use and how to make them. The Set implementation in Pugs uses (at last count) 20 different Unicode characters as operators. Good idea. A modest start is at docs/quickref/unicode . -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: Declarations of constants
Hi,
TSa (Thomas Sandla) wrote:
Ingo Blechschmidt wrote:
Or did you simply forget the braces around 42? :)
No, it was intented for seeing what the reactions will be :)
:)
Just using foo as unsigiled variable. This might need
my foo is rw;
I don't think this will DWYW, as firstly is rw is the default
on vars declared with my(), and secondly foo will be undef, not some
kind of Proxy object. To do what you want, you'd have to write (I
think):
my foo = new_codeless_lvalue_sub();
sub new_codeless_lvalue_sub {
my $var;
return {
new Proxy: FETCH = { $var }, STORE = - $new { $var = $new };
};
}
But then I presume you could say:
foo = 17;
if foo 8
{
@a[foo] = 8;
}
We could call that a codeless lvalue sub ;)
This indeed looks very slick! I wouldn't use it for normal vars, though.
--Ingo
--
Linux, the choice of a GNU | The next statement is not true.
generation on a dual AMD | The previous statement is true.
Athlon!|
Re: Module suggestion
Jim,
test in what sense? Is this supposed to be a module like Test::More
or Test::Deep which builds on Test::Builder and which will ultimately
generate an 'ok'? If so, what does the interface for that look like?
It'll look like this: (in a Test::Unit::TestCase subclass)
my $fh =CGI::Filehandle-new_tie('/var/www/testdata/MA/qc_report1');
CGI-param('file', $fh);
...
#Invoke CGI processing
...
my $filename = CGI-param('file');
my $firstLine = $filename;
$self-assert_equals($filename, 'qc_report1');
$self-assert_equals($firstLine, QC report header):
Hmmm. I read in the docs on IO::WrapTie:
This is currently Alpha code, released for comments.
How would your module react if IO::WrapTie's code changed significantly
between alpha and beta?
I don't expect it to change much, because it's doing one very specific
thing in a very straightforward way.
Simon
--
Simon (Vsevolod ILyushchenko) [EMAIL PROTECTED]
http://www.simonf.com
Terrorism is a tactic and so to declare war on terrorism
is equivalent to Roosevelt's declaring war on blitzkrieg.
Zbigniew Brzezinski, U.S. national security advisor, 1977-81
Re: [S29] uniq
Luke Palmer wrote:
So I suppose that's my proposal. Allow, even encourage, overloading
of =:=, but only for value types. I've been thinking that we ought to
provide a standard role for making something a value type. Maybe it
would require definition of =:=.
I would like to propose something slightly different:
1) Let =:= be non-overloadable purely macro/grammar based
--- same could be applied to ::= and := I think
2) the implementation of =:= then checks type homogenity
as a precondition and calls the type specific EQUAL
submethod or some such
The rational is that type homogenity is a necessary condition
for identity and thus allows to return false when violated.
The EQUAL class/type submethod could be used as the default for
the == and eq operators as long as subtype homogenity for both
sides holds. Well, or the operator name is a parameter to the
parametric role:
role Identity[ eq_op:( ::?CLASS, ::?CLASS: -- bit ) = $::CLASS::EQUAL ]
does Identity[ ::?CLASS ] # F-bounded
{
...
}
which is implicitly forced into every class definition by virtue of
role Any does Identity;
In particular we have:
class Num does Identity[ infix:{'=='} ] {...}
class Str does Identity[ infix:{'eq'} ] {...}
To what exteent in canbe auto-generated with dispatching to
the respective methods of all elements defined into the class'
value environment, I can't say.
--
TSa (Thomas Sandlaß)
Re: RFC - Class::Agreement
--- Ian Langworth [EMAIL PROTECTED] wrote: Reflecting upon this, I'm not even sure why I'd want argument modification as a feature. (Maybe I still had Hook::LexWrap on the brain.) I might just take this out. I vote for taking it out. I view contracts to be similar to exceptions in one respect: when implemented properly, removing them from the code should not affect the normal operation of the code (sweeping a few things under the rug there). Thus, argument modification is a no-no. Some might argue against the bondage and discipline, but they're probably not going to be using Class::Agreement anyway :) Class::Agreement's contracts should be nearly as light as putting die unless in your methods. What? I had no idea. Was that in the docs and I overlooked it? To me, this is probably one of the strongest features of Class::Agreement and should definitely be hyped. Many aren't going to use Class::Contract due to the performance hit. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: RFC - Class::Agreement
On 5/27/05, Ovid [EMAIL PROTECTED] wrote: Class::Agreement's contracts should be nearly as light as putting die unless in your methods. What? I had no idea. Was that in the docs and I overlooked it? To me, this is probably one of the strongest features of Class::Agreement and should definitely be hyped. Many aren't going to use Class::Contract due to the performance hit. Argle -- I've forgotten to explain the whole joke! An agreement is lighter than a contract. Hence, Class::Agreement. Har, har. -- Ian Langworth
Re: Module suggestion
Vsevolod (Simon) Ilyushchenko wrote: Hi, I'd like to suggest a module that I came up with to test CGI file uploading logic. I have not found anything else like it. have you seen Apache-Test yet? http://search.cpan.org/dist/Apache-Test/ I find it hard to understand modules like this anymore - why use some funky tie interface and a bunch of other hoops to fake a live environment when you can really upload a file to a real webserver and run your tests there? --Geoff
Re: RFC - Class::Agreement
On 27 May 2005, at 16:21, Ian Langworth wrote:
[snip]
When you say automatic, I think of source filtering. Do you simply
mean an alias for the first argument? If so, I think it's best to
leave that up to the programmer. You can always use shift.
Fair enough. I just hate having the duplication arguments in the pre/
post/method blocks.
-I'd want a global way of switching off contracts without having
to change the code. $ENV{ClassAgreementDisabled} = 1 or something.
Arg! This is a biggie. If used properly, you shouldn't need, let alone
*want*, to turn contracts off. Class::Agreement doesn't do any deep
cloning like Class::Contract. Class::Agreement's contracts should be
nearly as light as putting die unless in your methods.
[snip]
Depends. I've seen some darn complex contracts in my time that have
significant runtime costs. When you have postconditions like 'must
return same result as old hideously ineffective system' or 'identical
result to simpler, but slow algorithm' keeping the contracts running
can have a massive cost.
[snip]
Thanks, Adrian. This is much appreciated.
Y'welcome :-)
Adrian
darcs patch: Add export list to Pugs.Types
Fri May 27 14:04:13 EDT 2005 Samuel Bronson [EMAIL PROTECTED]
* Add export list to Pugs.Types
New patches:
[Add export list to Pugs.Types
Samuel Bronson [EMAIL PROTECTED]**20050527180413] {
hunk ./src/Pugs/Types.hs 13
-module Pugs.Types where
+module Pugs.Types (
+Type(..), mkType, anyType, showType,
+ClassTree,
+
+Cxt(..),
+cxtItem, cxtSlurpy, cxtVoid, cxtItemAny, cxtSlurpyAny,
+typeOfCxt, isSlurpyCxt, isItemCxt, isVoidCxt,
+enumCxt, cxtEnum,
+
+Var,
+
+VStr, VBool, VInt, VRat, VNum, VComplex, VHandle, VSocket,
+VThread(..), VRule(..),
+
+MatchPGE(..)
+) where
}
Context:
[r3981
[EMAIL PROTECTED]**20050527163721]
[r3980
[EMAIL PROTECTED]**20050527163242]
[r3979
[EMAIL PROTECTED]**20050527150515]
[r3978
[EMAIL PROTECTED]**20050527144850]
[r3977
[EMAIL PROTECTED]**20050527143854]
[r3975
[EMAIL PROTECTED]**20050527143719]
[r3973
[EMAIL PROTECTED]**20050527142559]
[r3972
[EMAIL PROTECTED]**20050527140621]
[r3971
[EMAIL PROTECTED]**20050527104120]
[r3970
[EMAIL PROTECTED]**20050527101825]
[r3969
[EMAIL PROTECTED]**20050527083017]
[r3968
[EMAIL PROTECTED]**20050527082750]
[r3967
[EMAIL PROTECTED]**20050527082628]
[r3966
[EMAIL PROTECTED]**20050527081315]
[r3965
[EMAIL PROTECTED]**20050527075850]
[r3964
[EMAIL PROTECTED]**20050527064422]
[r3963
[EMAIL PROTECTED]**20050527063204]
[r3962
[EMAIL PROTECTED]**20050527060715]
[r3961
[EMAIL PROTECTED]**20050527032409]
[r3960
[EMAIL PROTECTED]**20050527025129]
[r3959
[EMAIL PROTECTED]**20050527025007]
[r3958
[EMAIL PROTECTED]**20050527024740]
[r3957
[EMAIL PROTECTED]**20050527024515]
[r3956
[EMAIL PROTECTED]**20050527023307]
[r3955
[EMAIL PROTECTED]**20050527022613]
[r3954
[EMAIL PROTECTED]**20050527021922]
[r3953
[EMAIL PROTECTED]**20050527021800]
[r3952
[EMAIL PROTECTED]**20050527021426]
[r3951
[EMAIL PROTECTED]**20050527020947]
[r3950
[EMAIL PROTECTED]**20050527020607]
[r3948
[EMAIL PROTECTED]**20050527020429]
[r3947
[EMAIL PROTECTED]**20050527014235]
[r3946
[EMAIL PROTECTED]**20050527014006]
[r3945
[EMAIL PROTECTED]**20050527013738]
[r3944
[EMAIL PROTECTED]**20050527012834]
[r3943
[EMAIL PROTECTED]**20050527011621]
[r3942
[EMAIL PROTECTED]**20050527010053]
[r3941
[EMAIL PROTECTED]**20050527004220]
[r3940
[EMAIL PROTECTED]**20050527003948]
[r3939
[EMAIL PROTECTED]**20050527003615]
[r3938
[EMAIL PROTECTED]**20050527002617]
[r3937
[EMAIL PROTECTED]**20050527000944]
[r3936
[EMAIL PROTECTED]**2005052746]
[r3935
[EMAIL PROTECTED]**20050526235227]
[r3934
[EMAIL PROTECTED]**20050526233135]
[r3933
[EMAIL PROTECTED]**20050526230821]
[r3932
[EMAIL PROTECTED]**20050526225348]
[r3931
[EMAIL PROTECTED]**20050526224648]
[r3930
[EMAIL PROTECTED]**20050526224524]
[r3929
[EMAIL PROTECTED]**20050526223615]
[r3928
[EMAIL PROTECTED]**20050526223447]
[r3927
[EMAIL PROTECTED]**20050526223111]
[r3926
[EMAIL PROTECTED]**20050526221642]
[r3925
[EMAIL PROTECTED]**20050526221516]
[r3924
[EMAIL PROTECTED]**20050526215518]
[r3923
[EMAIL PROTECTED]**20050526215336]
[r3922
[EMAIL PROTECTED]**20050526214850]
[r3921
[EMAIL PROTECTED]**20050526214158]
[r3920
[EMAIL PROTECTED]**20050526213604]
[r3919
[EMAIL PROTECTED]**20050526211142]
[r3918
[EMAIL PROTECTED]**20050526152418]
[r3917
[EMAIL PROTECTED]**20050526145341]
[r3916
[EMAIL PROTECTED]**20050526145216]
[r3915
[EMAIL PROTECTED]**20050526145054]
[r3914
[EMAIL PROTECTED]**20050526144915]
[r3913
[EMAIL PROTECTED]**20050526143145]
[r3912
[EMAIL PROTECTED]**20050526135026]
[r3911
[EMAIL PROTECTED]**20050526123936]
[r3910
[EMAIL PROTECTED]**20050526113739]
[r3909
[EMAIL PROTECTED]**20050526113052]
[r3908
[EMAIL PROTECTED]**20050526103902]
[r3905
[EMAIL PROTECTED]**20050526095904]
[r3904
[EMAIL PROTECTED]**20050526095743]
[r3903
[EMAIL PROTECTED]**20050526083223]
[r3902
[EMAIL PROTECTED]**20050526040759]
[r3901
[EMAIL PROTECTED]**20050526035906]
[r3899
[EMAIL PROTECTED]**20050526022326]
[* r3894
[EMAIL PROTECTED]**20050526032842]
Patch bundle hash:
3870252d158ef04169ce0cfadf157d497b6f33f0
Transparent / Opaque references
When we heard that Larry didn't acutally want $$foo to infinitely dereference, some of us were overjoyed, and others severely disappointed. Both transparent dereferencing (infinite $$foo) and opaque dereferencing (one-level $$foo) have their uses, but they are definitely distinct. Instead of adding different syntax for each kind, I'll propose something different: two types of references: Opaque and transparent. Opaque references always need to be explicitly dereferenced (except for binding an array to an array reference, etc.). Transparent references always automatically dereference. The decision of what type of dereferencing will go on is left up to the reference taker. What I can't decide is which one \ will create, and how you will create the other kind. Also, I can't decide how to one-level dereference the transparent references so that you can change them. Luke
Default invocant of methods
Hi,
what is the default invocant of methods?
method blarb ($normal_param) {...}
# Same as
method blarb (Class | ::?CLASS $invocant: $normal_param) {...}
# or
method blarb (::?CLASS $invocant: $normal_param) {...}
# ?
I prefer the latter, as then one can't accidentally call a instance
method on the class -- i.e.
Foo.blarb # will die.
You can always specify Class as invocant, if you want to have a class
method.
Opinions?
--Ingo
--
Linux, the choice of a GNU | Elliptic paraboloids for sale.
generation on a dual AMD |
Athlon!|
Re: RFC - Class::Agreement
On 27 May 2005, at 18:25, Ovid wrote: --- Ian Langworth [EMAIL PROTECTED] wrote: Reflecting upon this, I'm not even sure why I'd want argument modification as a feature. (Maybe I still had Hook::LexWrap on the brain.) I might just take this out. I vote for taking it out. I view contracts to be similar to exceptions in one respect: when implemented properly, removing them from the code should not affect the normal operation of the code (sweeping a few things under the rug there). Thus, argument modification is a no-no. Some might argue against the bondage and discipline, but they're probably not going to be using Class::Agreement anyway :) 100% agreement. I can't think of a single scenario where argument modification would be a good thing for contracts. AOP maybe. DbC nope. Adrian
Re: darcs patch: Add export list to Pugs.Types
On Fri, May 27, 2005 at 02:05:46PM -0400, Samuel Bronson wrote: Fri May 27 14:04:13 EDT 2005 Samuel Bronson [EMAIL PROTECTED] * Add export list to Pugs.Types Thanks, applied -- I've sent an invitation for you to become a committer, too. Welcome aboard! /Autrijus/ pgpWkQV3jHQmd.pgp Description: PGP signature
Re: Transparent / Opaque references
Luke Palmer skribis 2005-05-27 20:59 (+):
Opaque references always need to be explicitly dereferenced (except
for binding an array to an array reference, etc.). Transparent
references always automatically dereference. The decision of what
type of dereferencing will go on is left up to the reference taker.
The way I see things, an opaque reference is a value, while a
transparent reference is a name. And thus we already have both.
The name $foo points to a container, and so does \bar. However, to get
at the container using $foo, you use simply $foo. To get at the
container using the reference to bar, you have to dereference explicitly
with another $.
To bind a name (and thus have a transparent reference), we can either
declare the name, creating the variable at that point, or use some other
means of creating the variable, and use := to bind it later.
There are named arrays, @foo, and anonymous arrays, [].
There are named hashes, %foo, and anonymous hashes, {}.
There are only anonymous pairs. You can't dereference a pair, or bind a
name to it.
What I can't decide is which one \ will create, and how you will
create the other kind. Also, I can't decide how to one-level
dereference the transparent references so that you can change them.
The only real problem with having only infix := for binding, is that you
can't easily use an alias (aka transparent reference) in a list. You can
have an array of aliases, but it's harder to have an array or hash in
which one element is an alias. Binding can be done explicitly:
%hash = { key = undef, foo = 'bar' };
%hashkey := $variable;
%hashkey = 5; # $variable is now 5 too
But there is no way to set the transparent reference (aka alias)
initially, because we lack a \-like syntax.
So I propose that := becomes a prefix operator as well as an infix one,
allowing:
%hash = { key = := $variable, foo = 'bar' };
%hashkey = 5; # $variable is now 5 too
(This almost makes \ want to be \=, and $foo \= $bar to be what we now
write as $foo = \$bar, and $foo = := $bar to be the same as $foo :=
$bar, and stacked :=s to be irrelevant... But let's not think about this
too much...)
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Transparent / Opaque references
Juerd skribis 2005-05-28 1:15 (+0200):
There are named arrays, @foo, and anonymous arrays, [].
There are named hashes, %foo, and anonymous hashes, {}.
There are only anonymous pairs. You can't dereference a pair, or bind a
name to it.
I forgot an important one:
There are named scalars, $foo, and anonymous scalars, but they are
'literals', and read only, like 42.
There is no way to get an anonymous rw scalar, is there?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
darcs patch: export withArgs from Main
Fri May 27 15:45:12 EDT 2005 Samuel Bronson [EMAIL PROTECTED]
* export withArgs from Main
New patches:
[export withArgs from Main
Samuel Bronson [EMAIL PROTECTED]**20050527194512] {
hunk ./src/Main.hs 17
-module Main where
+module Main (module Main, withArgs) where
}
Context:
[r3981
[EMAIL PROTECTED]**20050527163721]
[r3980
[EMAIL PROTECTED]**20050527163242]
[r3979
[EMAIL PROTECTED]**20050527150515]
[r3978
[EMAIL PROTECTED]**20050527144850]
[r3977
[EMAIL PROTECTED]**20050527143854]
[r3975
[EMAIL PROTECTED]**20050527143719]
[r3973
[EMAIL PROTECTED]**20050527142559]
[r3972
[EMAIL PROTECTED]**20050527140621]
[r3971
[EMAIL PROTECTED]**20050527104120]
[r3970
[EMAIL PROTECTED]**20050527101825]
[r3969
[EMAIL PROTECTED]**20050527083017]
[r3968
[EMAIL PROTECTED]**20050527082750]
[r3967
[EMAIL PROTECTED]**20050527082628]
[r3966
[EMAIL PROTECTED]**20050527081315]
[r3965
[EMAIL PROTECTED]**20050527075850]
[r3964
[EMAIL PROTECTED]**20050527064422]
[r3963
[EMAIL PROTECTED]**20050527063204]
[r3962
[EMAIL PROTECTED]**20050527060715]
[r3961
[EMAIL PROTECTED]**20050527032409]
[r3960
[EMAIL PROTECTED]**20050527025129]
[r3959
[EMAIL PROTECTED]**20050527025007]
[r3958
[EMAIL PROTECTED]**20050527024740]
[r3957
[EMAIL PROTECTED]**20050527024515]
[r3956
[EMAIL PROTECTED]**20050527023307]
[r3955
[EMAIL PROTECTED]**20050527022613]
[r3954
[EMAIL PROTECTED]**20050527021922]
[r3953
[EMAIL PROTECTED]**20050527021800]
[r3952
[EMAIL PROTECTED]**20050527021426]
[r3951
[EMAIL PROTECTED]**20050527020947]
[r3950
[EMAIL PROTECTED]**20050527020607]
[r3948
[EMAIL PROTECTED]**20050527020429]
[r3947
[EMAIL PROTECTED]**20050527014235]
[r3946
[EMAIL PROTECTED]**20050527014006]
[r3945
[EMAIL PROTECTED]**20050527013738]
[r3944
[EMAIL PROTECTED]**20050527012834]
[r3943
[EMAIL PROTECTED]**20050527011621]
[r3942
[EMAIL PROTECTED]**20050527010053]
[r3941
[EMAIL PROTECTED]**20050527004220]
[r3940
[EMAIL PROTECTED]**20050527003948]
[r3939
[EMAIL PROTECTED]**20050527003615]
[r3938
[EMAIL PROTECTED]**20050527002617]
[r3937
[EMAIL PROTECTED]**20050527000944]
[r3936
[EMAIL PROTECTED]**2005052746]
[r3935
[EMAIL PROTECTED]**20050526235227]
[r3934
[EMAIL PROTECTED]**20050526233135]
[r3933
[EMAIL PROTECTED]**20050526230821]
[r3932
[EMAIL PROTECTED]**20050526225348]
[r3931
[EMAIL PROTECTED]**20050526224648]
[r3930
[EMAIL PROTECTED]**20050526224524]
[r3929
[EMAIL PROTECTED]**20050526223615]
[r3928
[EMAIL PROTECTED]**20050526223447]
[r3927
[EMAIL PROTECTED]**20050526223111]
[r3926
[EMAIL PROTECTED]**20050526221642]
[r3925
[EMAIL PROTECTED]**20050526221516]
[r3924
[EMAIL PROTECTED]**20050526215518]
[r3923
[EMAIL PROTECTED]**20050526215336]
[r3922
[EMAIL PROTECTED]**20050526214850]
[r3921
[EMAIL PROTECTED]**20050526214158]
[r3920
[EMAIL PROTECTED]**20050526213604]
[r3919
[EMAIL PROTECTED]**20050526211142]
[r3918
[EMAIL PROTECTED]**20050526152418]
[r3917
[EMAIL PROTECTED]**20050526145341]
[r3916
[EMAIL PROTECTED]**20050526145216]
[r3915
[EMAIL PROTECTED]**20050526145054]
[r3914
[EMAIL PROTECTED]**20050526144915]
[r3913
[EMAIL PROTECTED]**20050526143145]
[r3912
[EMAIL PROTECTED]**20050526135026]
[r3911
[EMAIL PROTECTED]**20050526123936]
[r3910
[EMAIL PROTECTED]**20050526113739]
[r3909
[EMAIL PROTECTED]**20050526113052]
[r3908
[EMAIL PROTECTED]**20050526103902]
[r3905
[EMAIL PROTECTED]**20050526095904]
[r3904
[EMAIL PROTECTED]**20050526095743]
[r3903
[EMAIL PROTECTED]**20050526083223]
[r3902
[EMAIL PROTECTED]**20050526040759]
[r3901
[EMAIL PROTECTED]**20050526035906]
[r3899
[EMAIL PROTECTED]**20050526022326]
[* r3894
[EMAIL PROTECTED]**20050526032842]
Patch bundle hash:
b8dd80b7d469df8bd5cc99d09522ea6811a99a55
Re: darcs patch: export withArgs from Main
Um, don't worry about this one. I sent it in before I got commit access. On 27/05/05, Samuel Bronson [EMAIL PROTECTED] wrote: Fri May 27 15:45:12 EDT 2005 Samuel Bronson [EMAIL PROTECTED] * export withArgs from Main
Re: Transparent / Opaque references
On 5/27/05, Juerd [EMAIL PROTECTED] wrote:
There is no way to get an anonymous rw scalar, is there?
Can't the [] and {} syntaxes be considered aliases for new Array(...)
and new Hash(...)?
my $x := new int = 10; # looks like it should work
Ashley Winters
Re: comprehensive list of perl6 rule tokens
In regards to http://www.nntp.perl.org/group/perl.perl6.language/21120 which discusses character class syntax in Perl 6, I have some comments to make. First, I've been very interested in seeing proper set notation for char classes in Perl 5. I was pretty vocal about it during TPC in 2002, I think, and have since added some features that are in Perl 5 now that allow you to define your own Unicode properties with not only + and - and ! but as well. If we want to treat character classes as sets, then we should try to use notation that reads properly. I don't see how '+' and '|' are any different in this case: +Foo +Bar and Foo | Bar should produce the same results always. I suppose the + is helpful in distinguishing a character class assertion from any other, though. To *complement* a character class, I think the character ~ is appropriate. Intersection should be done with . Subtraction can be provided with -, although it's really just a shorthand: A - B is really A ~B... but I suppose huffman encoding tells us we should provide the - sign. Here are some examples, then: +alpha -vowelsall alphabetic characters except vowels +alpha ~vowels same thing [a..z] -[aeiou] all characters 'a' through 'z' minus vowels [a..z] ~[aeiou] same thing ~(X Y) | Z all characters not in X-and-Y, or in Z The last example shows ~ which is currently unclaimed as far as assertions go. Since I'd be advocating the removal of a unary - in character classes (to be replaced by ~), I think this would be ok. The allowance for a unary + in character classes has already been justified. For the people who are really going to use it, the notation won't be foreign. And I'd expect most people who'd use it would actually abstract a good portion of it away into their own property definitions, so that ~(X Y) | Z would actually just be +My_XYZ_Property which would be defined elsewhere. What say you? -- Jeff japhy Pinyan % How can we ever be the sold short or RPI Acacia Brother #734 % the cheated, we who for every service http://japhy.perlmonk.org/ % have long ago been overpaid? http://www.perlmonks.org/ %-- Meister Eckhart
Re: State of ParTcl [r8193]
Thanks very much to Matt for his recent checkins, cleaning up tclparser.pmc,
and eliminating a bit of unnecessary code.
The compiler broke after some recent checkins (not Matt's fault). I've added a
test for this which is now passing, which should hopefully *keep* it passing.
=-)
With Matt's recent cleanup to tclparser, I'm now seeing 100% success on the tcl
test suite. Even
env TEST_PROG_ARGS=--gc-debug make test
is working:
All tests successful.
Files=39, Tests=236, 70 wallclock secs (29.83 cusr + 14.04 csys = 43.87 CPU)
I've also added tests for inline (unique to ParTcl), which lets you do:
puts This is Tcl
inline PASM {
print This is PASM\n
}
as well as some other minor missing tests.
William Coleda wrote:
With Leo's recent fixes to compile, the following now works:
.sub main @MAIN
load_bytecode languages/tcl/lib/tcllib.pbc
.local pmc tcl_compiler,compiled_sub
tcl_compiler = compreg TCL
compiled_sub = compile tcl_compiler, puts {ok 1}
compiled_sub()
.end
Additionally, at Leo's suggestion, I've just removed quite a bit of
duplicated code from languages/tcl/classes/ - now that multiple
inheritance is working, we can simply inherit these methods. There are
some methods that are still there that I don't think are tcl-specific -
if anyone can do more cleanup here (esp. in tcllist.pmc), I'd appreciate
it.
I currently have one failing test (cmd_continue, test 2) - this is, I
think, the same test that leo had been reporting as failing for a while.
I have some other pending code which seems to be tickling this GC bug.
Hopefully I'll be able to track this down.
