On Monday, November 25, 2002, 7:59:01 PM, you (mailto:[EMAIL PROTECTED])
wrote:
>> you'll have to write the code so that compiler knows how to handle
>> it. While not overly hard, I think its a little much for something
>> that should be provided in the core. I think the design team should
>> at
On Mon, Nov 25, 2002 at 10:06:13AM -0800, Michael Lazzaro wrote:
: With clarifications, and additional syntactic edge cases.
:
: The last remaining known "numeric literals" issue is whether we want to
: allow '.' in explicit radix, e.g. 10#1.234, or whether we want to
: disallow it as being Way
On Mon, Nov 25, 2002 at 09:01:36AM -0800, Michael Lazzaro wrote:
> (Umm... what's a better name than "coloned form"? That term sounds
> really... um... bad.)
How about:
- explicit radix
- dotted notation
- DSD (Dot Separated Digits)
--Dks
On Mon, 2002-11-25 at 13:06, Michael Lazzaro wrote:
> 0x0 # ok, == 0
> 0x0.0 # ok
> 0x.0# ok
Given that .1 is wrong (from above), I would disallow it here simply for
consistency sakes.
> 0d1.1E5 # WRONG, exp not allowed in shorthand radix
>
> 0B0110
> Date: Mon, 25 Nov 2002 14:49:25 -0500
> From: "Joseph F. Ryan" <[EMAIL PROTECTED]>
>
> I think "easy enough with a grammar munge" gets tossed around way too
> often; don't forget, in addition to having to know how to hack the core
> grammer (which I assume won't be for the novice;
It's not for t
Michael Lazzaro wrote:
Hmm, that's not overpoweringly ugly. Looks nice, even. The fact that
it doesn't generalize is a little awkward.
I'm still thinking that, unless someone comes up with a really
compelling real-world reason to *have* floats in bases other than 10,
we shouldn't ask the
On Mon, Nov 25, 2002 at 09:25:32AM -0800, Michael Lazzaro wrote:
> (Ooooh, there's another idea we _SHOULDN'T_ pursue... adding postfix
> '%' to mean 'percent', but in any radix. So 0x80% of 0x10 would be
> 0x08 !)
And here you give the PERFECT example as to why this idea shouldn't be
pursued.
With clarifications, and additional syntactic edge cases.
The last remaining known "numeric literals" issue is whether we want to
allow '.' in explicit radix, e.g. 10#1.234, or whether we want to
disallow it as being Way Too Creepy. This version assumes that '.' is
allowed, but exponential not
On Mon, Nov 25, 2002 at 09:01:36AM -0800, Michael Lazzaro wrote:
>>> 256#0_253_254_255 # base 256, NOT identical!
>>
>> is actually not allowed, no?
>
> Correct. It's an error, because radix > 36 mandates coloned form, and
> the colon-form digit 253254255 cannot exist in base 256. AND since
On Sunday, November 24, 2002, at 04:16 AM, Richard J Cox wrote:
We could adopt the C99 version and use "p" or "P" for hex decimal
values (this, reportedly, allows certain values not expressible in
decimal for floats to be specified).
Thus
0x.4Ap10
0xA.BCDp-15
(The exponent cannot be i
On Friday, November 22, 2002, at 03:31 AM, Anton Berezin wrote:
This:
- radix > 36, only colon form is allowed, not alpha digits
implies that this:
256#0_253_254_255 # base 256, NOT identical!
is actually not allowed, no?
Correct. It's an error, because radix > 36 mandates coloned
On Wednesday, November 20, 2002, 6:16:41 PM, you (mailto:[EMAIL PROTECTED])
wrote:
> On Monday, November 18, 2002, at 08:34 PM, Martin D Kealey wrote:
>> On Tue, 2002-11-19 at 08:28, Michael Lazzaro wrote:
>>> - floating point becomes allowed in explicit radix (and 0b,0c,0x)
>>
>> How can one h
On Thu, Nov 21, 2002 at 01:02:57PM -0800, Michael Lazzaro wrote:
This:
> - radix > 36, only colon form is allowed, not alpha digits
implies that this:
> 256#0_253_254_255 # base 256, NOT identical!
is actually not allowed, no?
%Anton.
--
| Anton Berezin| FreeBSD: The
On Friday, November 22, 2002, at 03:31 AM, Anton Berezin wrote:
This:
- radix > 36, only colon form is allowed, not alpha digits
implies that this:
256#0_253_254_255 # base 256, NOT identical!
is actually not allowed, no?
Ick, good point. In theory, the second of those was suppose
On Thursday, November 21, 2002, at 04:41 PM, Andrew Wilson wrote:
On Thu, Nov 21, 2002 at 01:02:57PM -0800, Michael Lazzaro wrote:
_01.23 # wrong
01.23_ # wrong
Is _ not space eater, or was that not decided? If it is then aren't
these two just literals with space eaters.
Y
On Thu, Nov 21, 2002 at 01:02:57PM -0800, Michael Lazzaro wrote:
>_01.23 # wrong
>01.23_ # wrong
Is _ not space eater, or was that not decided? If it is then aren't
these two just literals with space eaters.
andrew
--
Capricorn: (Dec. 22 - Jan. 19)
You will soon be unwillingly
With the very latest corrections. The last remaining known "numeric
literals" issue is whether we want to allow '.' in explicit radix, e.g.
10#1.234, or whether we want to disallow it as being Way Too Creepy.
Am I missing anything else, or is this part done?
--- Numeric Literals ---
decimal
On Wed, Nov 20, 2002 at 01:23:04PM -0800, Dave Whipp wrote:
>
> "Larry Wall" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > On Wed, Nov 20, 2002 at 11:57:33AM -0800, Michael Lazzaro wrote:
> > : and _I'm_ trying to promote the reuse of the old "oct/hex
On Wed, Nov 20, 2002 at 12:11:21PM -0800, Larry Wall wrote:
> On Wed, Nov 20, 2002 at 11:57:33AM -0800, Michael Lazzaro wrote:
> : and _I'm_ trying to promote the reuse of the old "oct/hex"
> : functions to do a similar both-way thing, such that:
>
> What's a two-way function supposed to ret
On Thu, 2002-11-21 at 09:54, Luke Palmer wrote:
> I've always wanted to meet The Devil. :)
You're welcome :-)
> Honestly, I can't tell by looking at that what those are supposed to
> mean. And I'm not putting any numbers that ugly into my Perl soup.
> Perl 6 is trying to I obfuscation.
I was af
"Martin D Kealey" <[EMAIL PROTECTED]> wrote
> I would suggest that exponent-radix should default to the same as radix.
>
> So
>
> 10:1.2.3:4.5:6== 12345
> 2:1:1:1110== 0x6000
> 60:22.0.-27::-2 == 21.9925
>
For some reason, I find those almost impossible to read.
We have co
"Larry Wall" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> On Wed, Nov 20, 2002 at 11:57:33AM -0800, Michael Lazzaro wrote:
> : and _I'm_ trying to promote the reuse of the old "oct/hex"
> : functions to do a similar both-way thing, such that:
>
> What's
From: Luke Palmer [mailto:[EMAIL PROTECTED]]
> > From: Martin D Kealey <[EMAIL PROTECTED]>
> > 10:1.2.3:4.5:6== 12345
> > 2:1:1:1110== 0x6000
> > 60:22.0.-27::-2 == 21.9925
>
> I've always wanted to meet The Devil. :)
>
> Honestly, I can't tell by looking at that what thos
On Wednesday, November 20, 2002, at 12:54 PM, Luke Palmer wrote:
My opinion: don't allow floating point arbitrary radix. It's uncommon
enough that it could be done with a module. It would be trivial with
a grammar munge.
I tend to agree. The amount of time you're going to want to use
float
On Wednesday, November 20, 2002, at 12:11 PM, Larry Wall wrote:
On Wed, Nov 20, 2002 at 11:57:33AM -0800, Michael Lazzaro wrote:
: and _I'm_ trying to promote the reuse of the old "oct/hex"
: functions to do a similar both-way thing, such that:
What's a two-way function supposed to return
> Date: Wed, 20 Nov 2002 10:54:18 -0800
> From: Michael Lazzaro <[EMAIL PROTECTED]>
>
> exponential notation:
> -1.23e4 # num
> -1.23E4 # num (identical)
> 1.23_e_4# wrong
Lord Larry has ruled that _ can only appear between digits. I, for
one, do not see the reasoning beh
> From: Martin D Kealey <[EMAIL PROTECTED]>
> Date: 18 Nov 2002 11:50:14 +1300
>
> On Sat, 2002-11-16 at 07:37, Michael Lazzaro wrote:
> > Due to ambiguities, the proposal to allow floating point in bases other
> > than 10 is therefore squished. If anyone still wants it, we can ask
> > the desi
From: Michael Lazzaro [mailto:[EMAIL PROTECTED]]
>
> and _I'm_ trying to promote the reuse of the old "oct/hex"
> functions to do a similar both-way thing, such that:
[...]
> but people just aren't biting, so far. Don't see why
> not, I think it's keen.
There's the problem Larry ment
On Wed, Nov 20, 2002 at 10:16:41AM -0800, Michael Lazzaro wrote:
: We probably couldn't get away with it, though I guess the only one that
: really changes is binary. Of course, as you pointed out, we don't
: _need_ to have 0b, 0x at all, they're just for backwards brain
: compatibility. I thi
On Wed, Nov 20, 2002 at 10:31:06AM -0800, Michael Lazzaro wrote:
:
: On Tuesday, November 19, 2002, at 10:26 PM, Dave Storrs wrote:
: >I would assume that 0B0110, 0C0123, and 0X00FF are all equivalent to
: >the forms with lower-case base markers, right?
:
: Huh, dunno. Let's ask for a ruling on
On Wed, Nov 20, 2002 at 11:57:33AM -0800, Michael Lazzaro wrote:
: and _I'm_ trying to promote the reuse of the old "oct/hex"
: functions to do a similar both-way thing, such that:
What's a two-way function supposed to return if you pass it something
that has both a string and a numeric valu
On Sat, 2002-11-16 at 07:37, Michael Lazzaro wrote:
> Due to ambiguities, the proposal to allow floating point in bases other
> than 10 is therefore squished. If anyone still wants it, we can ask
> the design team to provide a final ruling.
Why are we so hung up on spelling floating-point lite
On Tue, 2002-11-19 at 08:28, Michael Lazzaro wrote:
> - floating point becomes allowed in explicit radix (and 0b,0c,0x)
How can one have floating point if "E" is a valid digit?
0x1.0e1 # 1.054931640625 or 16 ?
Has any consideration been given to using letters other than a~f in the
second pos
On Wednesday, November 20, 2002, at 11:01 AM, Dave Storrs wrote:
Actually, this would be a good reason to have a function called
"literal" -- if it went both ways. So, I could do this:
print literal(200+55):hex; # == print "0xff";
print literal("0xff)); # == print 255;
[EMAIL PROTE
Attributions getting confusing, so I have snipped and rewritten:
Dave Storrs writes:
> > Actually, this would be a good reason to have a function called
> > "literal" -- if it went both ways. So, I could do this:
> >
> >print literal(200+55):hex; # == print "0xff";
> >print litera
With the latest corrections:
--- Numeric Literals ---
decimal notation:
123 # int 123
0123 # int 123
123.0 # num 123.0
-123 # int -123
0_1.2_3 # ok
_01.23 # wrong
01.23_ # wrong
01_._23 # wrong
1__2# wrong
exponen
On Tuesday, November 19, 2002, at 10:26 PM, Dave Storrs wrote:
I would assume that 0B0110, 0C0123, and 0X00FF are all equivalent to
the forms with lower-case base markers, right?
Huh, dunno. Let's ask for a ruling on that.
-0xff # ok
-0x00ff # ok
Are these two identical?
On Monday, November 18, 2002, at 08:34 PM, Martin D Kealey wrote:
On Tue, 2002-11-19 at 08:28, Michael Lazzaro wrote:
- floating point becomes allowed in explicit radix (and 0b,0c,0x)
How can one have floating point if "E" is a valid digit?
0x1.0e1 # 1.054931640625 or 16 ?
Oops, sorry
Dave Storrs writes:
> On Fri, Nov 15, 2002 at 11:50:52PM +0200, [EMAIL PROTECTED] wrote:
> > Michael Lazzaro writes:
> > depending on WYW . or the casting may be let to happen in two stages
> > : string -> num -> specific num type ,e.g. uint16
>
> How about if we got adverbial on the probl
On Mon, Nov 18, 2002 at 10:57:10AM -0800, Michael Lazzaro wrote:
>
> --- Numeric Literals ---
>
> bin/oct/hex notation:
>
> 0b0110 # bin
> 0c0123 # oct
> 0x00ff # hex
> 0x00fF # hex, == 0x00ff
> 0x00FF # hex, == 0x00ff
I would assume that 0B0110, 0C0
On Fri, Nov 15, 2002 at 11:50:52PM +0200, [EMAIL PROTECTED] wrote:
> Michael Lazzaro writes:
> > Let's summarize some of the string-to-num issues:
> >
> >my int $i = literal "0xff"; # 255
> >
> >
> > (3) -- We want to be able to parse a string as a number using a very
> > _specific
On Monday, November 18, 2002, at 10:57 AM, Michael Lazzaro wrote:
--- Numeric Literals ---
62:zZ # base 62 (?)
62:z.Z # base 62 (identical?)
62:z_Z # base 62 (identical?)
62:Zz # base 62 (not identical?)
Doh! That shouldn't be in there anymore... for bases
I've updated the literals tests to fully account for the radix notation;
and I've also updated the tests to use the new radix#(number):(number)
notation. Let me know if anyone finds any errors.
Find them at:
http://jryan.perlmonk.org/images/literals.tar.gz
Michael Lazzaro wrote:
--- Numeric L
On Monday, November 18, 2002, at 12:48 PM, Garrett Goebel wrote:
I went back through those posts, and I found where you suggested
0c0123... but I can't find a post from Larry confirming it.
It's not confirmed, just wild speculation. If we're reasonably sure we
don't have any gaping errors in
From: Michael Lazzaro [mailto:[EMAIL PROTECTED]]
> On Monday, November 18, 2002, at 11:37 AM, Garrett Goebel wrote:
> > In perl5, octal is signified by the leading zero. There is no 0c0123
> > notation.
>
> Right, but on p6l we had been talking about eliminating the assumed
> octalness of 0123,
On Monday, November 18, 2002, at 11:37 AM, Garrett Goebel wrote:
In perl5, octel is signified by the leading zero. There is no 0c0123
notation.
Right, but on p6l we had been talking about eliminating the assumed
octalness of 0123, therefore requiring us to come up with an alternate
syntax, e
Michael Lazzaro wrote:
>
> decimal notation:
> 123 # int 123
> 0123 # int 123
[...]
> 0c0123 # oct
[...]
> - need to verify that 0b1, 0c1, 0x1 are still allowed
Found a problem:
perl -e "print 0123"
gives: 83
perl -e "print 0c0123"
gives:
Bareword found
On Monday, November 18, 2002, at 10:57 AM, Michael Lazzaro wrote:
Eek, that one was short-lived! No problem: if Larry decides on Ada
syntax, the following changes happen:
s/:/#/ (for explicit radix)
s/./:/ (for dotted -- er, coloned -- form)
- floating point becomes allowed in
--- Numeric Literals ---
decimal notation:
123 # int 123
0123 # int 123
123.0 # num 123.0
-123 # int -123
0_1.2_3 # ok
_01.23 # wrong
01.23_ # wrong
01_._23 # wrong
1__2# wrong
exponential notation:
-1.23e4
On Monday, November 18, 2002, at 07:14 AM, Graham Barr wrote:
Are we not just getting too carried away with all this base
of literals.
I also think -documentation is the wrong place to discuss this.
Yep. I'll try and come up with a summary today or tomorrow that marks
all the *known* behavi
On Mon, Nov 18, 2002 at 03:14:52PM +, Graham Barr wrote:
> On Sat, Nov 16, 2002 at 11:12:15PM -0800, Dave Storrs wrote:
> > 24*60*60:10 # one day in seconds, easy representation
>
> And the advantage of that over 24*60*60*10 would be ?
Well, for one thing, my version means 1 day
On Mon, Nov 18, 2002 at 10:47:17AM -0600, Garrett Goebel wrote:
> I've tried asking if lists are literals or not... but I've been Warnock'd.
I have comments to make on several things posted recently. I'm waiting
for my boss to ask our legal department if I can contribute. There may
be others doi
Graham Barr wrote:
> On Sat, Nov 16, 2002 at 11:12:15PM -0800, Dave Storrs wrote:
> > Or how about run-time evaluated versions?
> >
> > # Set a timer to run for either a day or an hour, depending
> > $timer = 60*60*($use_days ? 24 : 1):10
>
> Then it is no longer a literal is it.
True. But t
On Sat, Nov 16, 2002 at 11:12:15PM -0800, Dave Storrs wrote:
> Hmm, interesting. Just as an aside, this gives me an idea: would it be
> feasible to allow the base to be specified as an expression instead of
> a constant? (I'm pretty sure it would be useful.) For example:
>
> 4294967296:1.2.3.4
On Sun, Nov 17, 2002 at 08:13:58PM -0700, Luke Palmer wrote:
> > Date: Sun, 17 Nov 2002 18:51:05 -0800
> > From: Dave Storrs <[EMAIL PROTECTED]>
> >
> > Therefore, in base 1, you can only use the digit 0. (Actually, I
> > think base 1 is a corner case--you only get one digit, but that digit
> > is
> Date: Sun, 17 Nov 2002 18:51:05 -0800
> From: Dave Storrs <[EMAIL PROTECTED]>
>
> Therefore, in base 1, you can only use the digit 0. (Actually, I
> think base 1 is a corner case--you only get one digit, but that digit
> is 1, so you can represent any number N by making N tally marks.)
Well, if
On Sun, Nov 17, 2002 at 03:01:08PM +0200, Markus Laire wrote:
> On 15 Nov 2002 at 12:02, Dave Whipp wrote:
>
> > A couple more corner cases:
> >
> > $a = 1:0; #error? or zero
>
> Shouldn't base-1 be:
>
> 1:0 == 10:0
> 1:1 == 10:1
> 1:11 == 10:2
> 1:111 == 10:3
> 1:1010111 == 10:5
> etc..
Nope
On 15 Nov 2002 at 12:02, Dave Whipp wrote:
> A couple more corner cases:
>
> $a = 1:0; #error? or zero
Shouldn't base-1 be:
1:0 == 10:0
1:1 == 10:1
1:11 == 10:2
1:111 == 10:3
1:1010111 == 10:5
etc..
Also 0:0 == 10:0
--
Markus Laire 'malaire' <[EMAIL PROTECTED]>
Dave Storrs wrote:
[...] Just as an aside, this gives me an idea: would it be
feasible to allow the base to be specified as an expression instead of
a constant? (I'm pretty sure it would be useful.) For example:
4294967296:1.2.3.4 # working with a really big base, hard to grok
2**32:1.2.3
On Fri, Nov 15, 2002 at 12:02:02PM -0800, Dave Whipp wrote:
> $b = 4294967296:1.2.3.4 # base 2**32
Hmm, interesting. Just as an aside, this gives me an idea: would it be
feasible to allow the base to be specified as an expression instead of
a constant? (I'm pretty sure it would be useful.) Fo
On Thu, Nov 14, 2002 at 01:33:31PM -0600, Jonathan Scott Duff wrote:
> On Thu, Nov 14, 2002 at 10:28:38AM -0800, Michael Lazzaro wrote:
>
> > 1.23_e_4# ok?
>
> Hrm. This one is annoying, but I think it should be okay.
Are you sure? If so, can you explain why for me, because I don't
thin
Michael Lazzaro writes:
> Let's summarize some of the string-to-num issues:
>
>my int $i = literal "0xff"; # 255
>
>
> (3) -- We want to be able to parse a string as a number using a very
> _specific_ rule; for example, if a user is expected to enter a value in
> a specific forma
Let's summarize some of the string-to-num issues:
(1) -- A number is just a number, regardless of how it's put in.
Therefore:
my int $i = 0xff;
my int $i = 255;
result in the identical number, 255, being placed in $i. Once it's in
there, there's no way to tell what format it originally
A couple more corner cases:
$a = 1:0; #error? or zero
$b = 4294967296:1.2.3.4 # base 2**32
printf "%32x", $b;
0001000200030004
Dave.
On Friday, November 15, 2002, at 10:51 AM, Dave Whipp wrote:
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote
1.5e1 == 15
16:1.5e1 != (1 + 5/16) * 16
Due to ambiguities, the proposal to allow floating point in bases
other
than 10 is therefore squished. If anyone still wants it, we can ask
the de
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote
> > 1.5e1 == 15
> > 16:1.5e1 != (1 + 5/16) * 16
>
> Due to ambiguities, the proposal to allow floating point in bases other
> than 10 is therefore squished. If anyone still wants it, we can ask
> the design team to provide a final ruling.
So what about
On Thursday, November 14, 2002, at 01:27 PM, Dave Whipp wrote:
And now I know why we can't use C<.> as a floating point in base 16:
1.5e1 == 15
16:1.5e1 != (1 + 5/16) * 16
Due to ambiguities, the proposal to allow floating point in bases other
than 10 is therefore squished. If anyone still
Dave Whipp writes:
> Richard Nuttall wrote:
>
> > How about
> >
> > my $a = 256:192.169.34.76;
> > my $b = $a.base(10);
> > my $c = '34:13.23.0.1.23.45'.base(16);
>
> This coupling makes me nervous. A number is a number: its value is not
> effected by its representation.
>
> I can
Richard Nuttall wrote:
How about
my $a = 256:192.169.34.76;
my $b = $a.base(10);
my $c = '34:13.23.0.1.23.45'.base(16);
This coupling makes me nervous. A number is a number: its value is not
effected by its representation.
I can see that, in some scripts, it might be useful to define a prope
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote
> exponential:
> -1.23e4 # num
> -1.23E4 # num (identical)
And now I know why we can't use C<.> as a floating point in base 16:
1.5e1 == 15
16:1.5e1 != (1 + 5/16) * 16
There would be an ambiguity as to the meaning of 'e', so it should p
0x00ff # hex value ff
'0x00ff'# integer value 0, with trailing 'x00ff'
I think ways to solve this should be open to discussion. Hopefully
Luke can give us some proposals, since he's writing that part.
The behavior described there should stay. If you want literal-like
int
On Thu, Nov 14, 2002 at 12:22:03PM -0700, Luke Palmer wrote:
> The behavior described there should stay. If you want literal-like
> interpretations of strings, use the C function. The name of that
> function should probably be changed to something more appropriate.
>
> C, C, C (ambiguous?), C, e
On Thu, Nov 14, 2002 at 10:28:38AM -0800, Michael Lazzaro wrote:
> 01_._23 # wrong?
this one has to be wrong by Larry's decree that _ is only valid
between "digits" (hexits?)
> 1.23_e_4# ok?
Hrm. This one is annoying, but I think it should be okay.
> 20:1.G.K# base 20 (i
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Thu, 14 Nov 2002 10:28:38 -0800
> From: Michael Lazzaro <[EMAIL PROTECTED]>
>
> Of course, a key issue is that, in perl5, the treatment of numeric
> literals is not at all the same as the treatment of stringified
> numerics. For exa
On Thursday, November 14, 2002, at 10:37 AM, Angel Faus wrote:
I thought that bin/oct/hex literals where deprecated in favour of
explicit radix notation. But maybe I am wrong. I am?
AFAIK, I don't think it has been decided. Some people like the old
format, some people like the radix format,
> bin/oct/hex literals:
>
> 0b0110 # bin
> 0c0123 # oct
> 0x00ff # hex
> 0x00fF # hex, == 0x00ff
> 0x00FF # hex, == 0x00ff
>
> 0xf_f # ok
> 0x_ff # ok
>
I thought that bin/oct/hex literals where deprecated in favour of
explicit rad
On Thursday, November 14, 2002, at 10:28 AM, Michael Lazzaro wrote:
W/ regards to numeric literals, here are a number of
examples/proposals that we should verify the behavior of. Anything I
missed?
Oh, this is ignoring the issue of floats in bases other than 10. I'm
not dissing the idea, i
W/ regards to numeric literals, here are a number of examples/proposals
that we should verify the behavior of. Anything I missed?
decimal: (meaning?)
123 # int 123
0123 # int 123
123.0 # num 123.0
-123 # int -123
0_1.2_3 # ok
_01.23
78 matches
Mail list logo
