Am Sat, 09 Feb 2013 22:41:18 +0100
schrieb "Peter Alexander" :
> On Saturday, 9 February 2013 at 21:11:36 UTC, Marco Leise wrote:
> > If people who want or have to stick with D1 make pull requests
> > for bugs they fixed that's good. Just keep them open I'd say
> > unless they require a new featur
On Sunday, 10 February 2013 at 03:20:26 UTC, David Nadlinger
wrote:
That post is over a year old, and the point was precisely that
recent development activity seemed to contradict this statement.
The D Progamming Language book discusses this decision as well.
On Saturday, 9 February 2013 at 23:08:55 UTC, Andrei Alexandrescu
wrote:
http://forum.dlang.org/post/jc0ic5$18bv$2...@digitalmars.com
That post is over a year old, and the point was precisely that
recent development activity seemed to contradict this statement.
Looking forward to see you all
On Saturday, 9 February 2013 at 22:30:01 UTC, Walter Bright wrote:
D1 is no longer officially supported. There are a couple users
of D1 still (like Don), and it would be discourteous to try to
purge D1. The point of using git is that branches can exist and
be amended if a reason comes up to do
On Fri, 08 Feb 2013 18:53:30 -0500, Robert wrote:
Ok. Here finally it is:
http://wiki.dlang.org/DIP26
Wow. So you simply want to go back to D1-style properties.
It would have been simpler to just specify that we define a property like
this:
// this is a property
int foo() {...}
-Steve
On Fri, 08 Feb 2013 16:45:58 -0500, Robert wrote:
First of all, thanks for this very insight full discussion. I start to
understand the other side. :-)
You are welcome! I also am learning things and shaping my opinions based
on these discussions.
On Fri, 2013-02-08 at 15:13 -0500, Steve
On Sunday, February 10, 2013 00:26:41 Dmitry Olshansky wrote:
> 09-Feb-2013 19:46, Andrei Alexandrescu пишет:
> > On 2/9/13 10:37 AM, Jacob Carlborg wrote:
> >> On 2013-02-09 16:10, Andrei Alexandrescu wrote:
> >>> Requiring a random-access range of ubyte with a terminating zero may be
> >>> the mo
On Saturday, February 09, 2013 14:56:56 Andrei Alexandrescu wrote:
> On 2/9/13 2:21 PM, Jonathan M Davis wrote:
> > Getting rid of @property will mean allowing stupid stuff like
> >
> > range.popFrontN = 5;
>
> No. This again conflates getters with the setter syntax.
How? If you don't have expli
On Saturday, February 09, 2013 14:22:44 Walter Bright wrote:
> On 2/9/2013 8:33 AM, Peter Alexander wrote:
> > Quite a few of the older bugs are D1 only. Given that D1 is no longer
> > supported, should these just be closed?
> >
> > e.g. http://d.puremagic.com/issues/show_bug.cgi?id=309
>
> No.
On Sat, 09 Feb 2013 23:54:09 +0100
Jacob Carlborg wrote:
> On 2013-02-09 21:51, Nick Sabalausky wrote:
>
> > I think that's asking for confusion to have different visibility
> > rules inside and outside typeof().
> >
> > The typical way to access private members when really needed is via
> > a r
On Saturday, 9 February 2013 at 22:50:18 UTC, Walter Bright wrote:
People who are interested in D1 are welcome to submit pulls for
them, and I'll pull them.
This shouldn't affect anyone else. That's the whole point of
using git.
If it uses up your time then it affects everyone using D2 becau
On 2/9/13 5:09 PM, David Nadlinger wrote:
On Saturday, 9 February 2013 at 18:04:29 UTC, Russel Winder wrote:
On Sat, 2013-02-09 at 18:30 +0100, Andrej Mitrovic wrote:
Walter is still working on D1, as shown:
https://github.com/D-Programming-Language/dmd/commits/dmd-1.x
We're all baffled as to
On 2/9/13, Walter Bright wrote:
> This shouldn't affect anyone else. That's the whole point of using git.
How does it not affect us if *you* are taking the time to port D2 fixes to D1?
The whole announcement that D1 support is over after December 31st was
clearly completely pointless and a lie.
On 2/9/2013 2:39 PM, Peter Alexander wrote:
On Saturday, 9 February 2013 at 22:30:01 UTC, Walter Bright wrote:
D1 is no longer officially supported.
What does that actually mean?
Specifically:
- Will there be more D1 releases?
- Will D1 bug fixes be pulled?
- Should people still file D1 bugs
On 2013-02-09 21:51, Nick Sabalausky wrote:
I think that's asking for confusion to have different visibility rules
inside and outside typeof().
The typical way to access private members when really needed is via a
reflection mechanism, and we already have a way to do that as two
people have men
On Saturday, 9 February 2013 at 22:30:01 UTC, Walter Bright wrote:
D1 is no longer officially supported.
What does that actually mean?
Specifically:
- Will there be more D1 releases?
- Will D1 bug fixes be pulled?
- Should people still file D1 bugs?
- Should people care about D1 when submitti
On 2/9/2013 2:09 PM, David Nadlinger wrote:
The worst part is that there wasn't even an official announcement regarding the
status of D1.
D1 is no longer officially supported. There are a couple users of D1 still (like
Don), and it would be discourteous to try to purge D1. The point of using g
On 2/9/2013 8:33 AM, Peter Alexander wrote:
Quite a few of the older bugs are D1 only. Given that D1 is no longer supported,
should these just be closed?
e.g. http://d.puremagic.com/issues/show_bug.cgi?id=309
No.
On Saturday, 9 February 2013 at 18:04:29 UTC, Russel Winder wrote:
On Sat, 2013-02-09 at 18:30 +0100, Andrej Mitrovic wrote:
Walter is still working on D1, as shown:
https://github.com/D-Programming-Language/dmd/commits/dmd-1.x
We're all baffled as to why he's still wasting time on D1,
when i
On Saturday, 9 February 2013 at 18:47:00 UTC, SomeDude wrote:
On Monday, 4 February 2013 at 06:11:49 UTC, Maxim Fomin wrote:
On Sunday, 3 February 2013 at 12:53:19 UTC, SomeDude wrote:
It seems to me that the C experts crowd is the most
conservative crowd you can find, and one that loves to imp
On Saturday, 9 February 2013 at 21:11:36 UTC, Marco Leise wrote:
If people who want or have to stick with D1 make pull requests
for bugs they fixed that's good. Just keep them open I'd say
unless they require a new feature to be implemented.
I thought the point of discontinuing support was so t
Am Sat, 09 Feb 2013 17:33:39 +0100
schrieb "Peter Alexander" :
> Quite a few of the older bugs are D1 only. Given that D1 is no
> longer supported, should these just be closed?
>
> e.g. http://d.puremagic.com/issues/show_bug.cgi?id=309
If people who want or have to stick with D1 make pull reque
On 2/9/13 3:49 PM, Walter Bright wrote:
On 2/9/2013 12:43 PM, Walter Bright wrote:> Perhaps we can formalize
this a bit. Define a SentinelInputRange, which has an
> additional manifest constant with the name 'sentinel'. empty becomes
defined as:
>
> empty = front == sentinel;
>
> popFront()
On Sat, 9 Feb 2013 21:34:54 +0100
Andrej Mitrovic wrote:
> On 2/9/13, kenji hara wrote:
> > It's introduced by fixing issue 5385, so at least not a regression
>
> Perhaps we could relax the rule and allow bypassing access
> restrictions when using typeof().
I think that's asking for confusion
On 2/9/2013 12:43 PM, Walter Bright wrote:> Perhaps we can formalize this a bit.
Define a SentinelInputRange, which has an
> additional manifest constant with the name 'sentinel'. empty becomes defined
as:
>
> empty = front == sentinel;
>
> popFront() does not advance if empty. Advancing ov
On 2/9/2013 6:37 AM, Andrei Alexandrescu wrote:
On 2/9/13 3:07 AM, Jonathan M Davis wrote:
On Friday, February 08, 2013 23:48:50 Walter Bright wrote:
On 2/8/2013 12:01 AM, Jonathan M Davis wrote:
It's not quite a use case where
ranges shine - especially when efficiency is a top priority.
A m
On 2/9/13, kenji hara wrote:
> It's introduced by fixing issue 5385, so at least not a regression
Perhaps we could relax the rule and allow bypassing access
restrictions when using typeof().
There are similar bugs opened about purity, where e.g. you can't check
the length of an impure static arr
09-Feb-2013 23:20, SomeDude пишет:
On Friday, 8 February 2013 at 16:00:05 UTC, Dmitry Olshansky wrote:
08-Feb-2013 19:52, Iain Buclaw пишет:
That's still lies. :o)
g++ ? :)
--
Iain Buclaw
*(p < e ? p++ : p) = (c & 0x0f) + '0';
I'd think it's built by DMC++, Digital Mars C++ compiler
09-Feb-2013 19:46, Andrei Alexandrescu пишет:
On 2/9/13 10:37 AM, Jacob Carlborg wrote:
On 2013-02-09 16:10, Andrei Alexandrescu wrote:
Requiring a random-access range of ubyte with a terminating zero may be
the most general approach to a fast lexer - and that's fine.
Requiring a random-acce
I already thought about this too, good enough that D choose not to use
final for const variables like Java does.
On Sat, 2013-02-09 at 12:54 -0500, Michel Fortin wrote:
> On 2013-02-09 15:22:28 +, Jacob Carlborg said:
>
> > I completely agree, I really like it. Do we want to be able to use
On Sat, 2013-02-09 at 16:17 +0100, deadalnix wrote:
> Also, you don't address most of the point Jonathan
> raises, and that should probably be a sign that you are not
> mastering the topic enough.
Funny enough, when I read your posts I get the feeling you did not even
read the DIP. Enough insult
On 2/9/13 2:21 PM, Jonathan M Davis wrote:
Getting rid of @property will mean allowing stupid stuff like
range.popFrontN = 5;
No. This again conflates getters with the setter syntax.
Andrei
On Friday, 8 February 2013 at 16:00:05 UTC, Dmitry Olshansky
wrote:
08-Feb-2013 19:52, Iain Buclaw пишет:
That's still lies. :o)
g++ ? :)
--
Iain Buclaw
*(p < e ? p++ : p) = (c & 0x0f) + '0';
I'd think it's built by DMC++, Digital Mars C++ compiler.
On Saturday, February 09, 2013 09:48:23 Andrei Alexandrescu wrote:
> On 2/9/13 5:31 AM, Jonathan M Davis wrote:
> > With any API that templates use, the exact syntax of the functions or
> > properties used must be defined. Otherwise, you're going to be screwed by
> > things like a templated functio
On Monday, 4 February 2013 at 06:11:49 UTC, Maxim Fomin wrote:
On Sunday, 3 February 2013 at 12:53:19 UTC, SomeDude wrote:
It seems to me that the C experts crowd is the most
conservative crowd you can find, and one that loves to impose
its own masochism to the rest of the world.
Good catch.
On Sat, 2013-02-09 at 18:30 +0100, Andrej Mitrovic wrote:
[…]
> Don't shoot the messenger. :)
Indeed, sorry for any such behaviour.
(I had thought of getting into some black humour about shootings but
restrained myself.)
> Walter is still working on D1, as shown:
>
> https://github.com/D-Progra
On 2013-02-09 15:22:28 +, Jacob Carlborg said:
I completely agree, I really like it. Do we want to be able to use
attributes like "final", and perhaps others, when declaring a property
field:
@property final int a;
The lowered functions would have the "final" attribute attached to them
On 2013-02-09 15:30:13 +, "deadalnix" said:
On Saturday, 9 February 2013 at 12:44:35 UTC, Michel Fortin wrote:
I believe both module-level properties and UFCS properties to be
desirable. So is the idea put forward in DIP26 that reduces boilerplate
code. The question is how do we put all t
On 2/9/13, Russel Winder wrote:
> On Sat, 2013-02-09 at 17:48 +0100, Andrej Mitrovic wrote:
> […]
>> From what I can tell bug fixes are still ported to D1, only
>> enhancements are not.
>
> As of 2013-01-01 D1 is supposed to be having no work done on it. To have
> the prospect of future D1 release
On Sat, 2013-02-09 at 17:48 +0100, Andrej Mitrovic wrote:
[…]
> From what I can tell bug fixes are still ported to D1, only
> enhancements are not.
As of 2013-01-01 D1 is supposed to be having no work done on it. To have
the prospect of future D1 releases having said there would be none is
giving
On 2/9/13, Peter Alexander wrote:
> Quite a few of the older bugs are D1 only. Given that D1 is no
> longer supported, should these just be closed?
>
> e.g. http://d.puremagic.com/issues/show_bug.cgi?id=309
>
>From what I can tell bug fixes are still ported to D1, only
enhancements are not.
On Saturday, 9 February 2013 at 15:52:04 UTC, Benjamin Thaut
wrote:
Am 09.02.2013 16:40, schrieb kenji hara:
You can use built-in 'tupleof' property, which still bypass
access
modifier.
Will they continue to do so, or will this also be fixed? We
should at least have some way to do low lev
Am 09.02.2013 16:40, schrieb kenji hara:
You can use built-in 'tupleof' property, which still bypass access
modifier.
Will they continue to do so, or will this also be fixed? We should at
least have some way to do low level work like serialization.
Kind Regards
Benjamin Thaut
On 2013-02-09 16:46, Andrei Alexandrescu wrote:
You require it. It's client's burden.
Ok, I see.
--
/Jacob Carlborg
On 2/9/13 10:38 AM, Jacob Carlborg wrote:
On 2013-02-09 15:37, Andrei Alexandrescu wrote:
That's not a problem. You may require that the input has a terminating
zero.
You cannot just append a terminating zero in the lexer if it's a range?
You require it. It's client's burden.
Andrei
On 2/9/13 10:37 AM, Jacob Carlborg wrote:
On 2013-02-09 16:10, Andrei Alexandrescu wrote:
Requiring a random-access range of ubyte with a terminating zero may be
the most general approach to a fast lexer - and that's fine.
Requiring a random-access range probably makes it easier. People here
On 2013-02-09 16:20, Benjamin Thaut wrote:
Has this been "fixed" intentionally? Or is this a regression? If it has
been "fixed" what would be a workaround to get the type of Foo.i
(outside of the b module) ?
The workaround would be to use .tupleof:
https://github.com/jacob-carlborg/orange/blo
2013/2/10 Benjamin Thaut
> The following reduced source code would compile just fine with dmd 2.060
> but does no longer compile with dmd 2.061:
>
> file a.d:
> module a;
>
> import b;
>
> template getType(T)
> {
> alias typeof(T.i) getType;
> }
>
> void main(string[] args)
> {
> alias getTyp
On 2013-02-09 16:10, Andrei Alexandrescu wrote:
Requiring a random-access range of ubyte with a terminating zero may be
the most general approach to a fast lexer - and that's fine.
Requiring a random-access range probably makes it easier. People here
seems to try to support ranges with less f
On 2013-02-09 15:37, Andrei Alexandrescu wrote:
That's not a problem. You may require that the input has a terminating
zero.
You cannot just append a terminating zero in the lexer if it's a range?
--
/Jacob Carlborg
On Saturday, 9 February 2013 at 12:44:35 UTC, Michel Fortin wrote:
One problem we currently have is that the way properties are
defined with @property is that there's no way to distinguish
module-level properties from UFCS properties. Instead of fixing
that, many people are trying to disallow o
On 2013-02-09 04:13, Michel Fortin wrote:
This is pretty much exactly how I think properties should work. There's
two possible benefits you may to have overlooked…
One benefit of the "@property T foo;" syntax that does the boilerplate
code for you over using a plain variable: the getter and set
The following reduced source code would compile just fine with dmd 2.060
but does no longer compile with dmd 2.061:
file a.d:
module a;
import b;
template getType(T)
{
alias typeof(T.i) getType;
}
void main(string[] args)
{
alias getType!Foo t;
}
file b.d:
module b;
struct Foo
{
priv
On 2013-02-09 10:57, Tove wrote:
@property int a;
I would prefer if @property simply disallows '&' then it doesn't have to
be lowered into anything and can stay a field... if you later decide to
add a "real" getter/setter, it still would be source compatible and you
wouldn't have to refactor th
On Saturday, 9 February 2013 at 09:45:25 UTC, Robert wrote:
I am claiming that if we restrict ourselves to the property
concept
explained in the DIP, then the range API would no longer depend
on front
being a property, it can also be a function returning ref,
which is
perfectly legal for UFCS.
On 2/9/13 10:05 AM, Jacob Carlborg wrote:
On 2013-02-09 09:05, Jonathan M Davis wrote:
The lexer that I'm writing doesn't even support pure input ranges,
because it
has to be able to save to do what it does, and the only reason that
decodeFront exists is because I wrote it to support that use c
On 2013-02-08 17:35, Brian Schott wrote:
On Friday, 8 February 2013 at 15:35:55 UTC, Dmitry Olshansky wrote:
Would be intereesting to try gdc as dmd on linux uses gcc.
GDC decided to randomly not fail to build on my system, so it's time for
MOAR CHARTS.
dmd -inline -noboundscheck -O -w -wi -m
On 2013-02-09 09:05, Jonathan M Davis wrote:
The lexer that I'm writing doesn't even support pure input ranges, because it
has to be able to save to do what it does, and the only reason that
decodeFront exists is because I wrote it to support that use case. And needing
to operate on ranges of co
On 2013-02-08 18:00, Stewart Gordon wrote:
But this would be a breaking change
This can be solved by moving the functionality to a new function, say
"isValid", which returns a boolean. The implementation of "check" would
then call "isValid" and throw an exception if it returns false.
-
On 2/9/13 5:31 AM, Jonathan M Davis wrote:
With any API that templates use, the exact syntax of the functions or
properties used must be defined. Otherwise, you're going to be screwed by
things like a templated function using parens to access a property working in
some cases and not in others (be
On 2/9/13 6:31 AM, FG wrote:
On 2013-02-09 11:31, Jonathan M Davis wrote:
I just went over this with Kenji in his thread "Partial modification
of DIP23
to allow module level property." You _must_ be able to rely on front
being a
property.
front getter MUST be a property... as in RFC2119's MUST
On 2/9/13 3:07 AM, Jonathan M Davis wrote:
On Friday, February 08, 2013 23:48:50 Walter Bright wrote:
On 2/8/2013 12:01 AM, Jonathan M Davis wrote:
It's not quite a use case where
ranges shine - especially when efficiency is a top priority.
A more problematic case is dmd's lexer relies on a 0
I wrote:
I believe both module-level properties and UFCS properties to be
desirable. So is the idea put forward in DIP26 that reduces boilerplate
code. The question is how do we put all that together.
Andrei just made me realize that I overlooked this part of DIP26 which
actually solve the m
On Thu, 2013-02-07 at 17:20 -0800, H. S. Teoh wrote:
> How cool would that be??
Awesome!
On Sat, 2013-02-09 at 08:28 +0100, deadalnix wrote:
> Taking the address of a property <= no. It I take the address of
> an int, I get an int* or an error because it is invalid. Not a
> delegate !
> No UFCS for properties <= no.
> Behaviour like functions <= WTF should properties behave
> diffe
I am going to consider these. Thanks!
On Fri, 2013-02-08 at 22:13 -0500, Michel Fortin wrote:
> On 2013-02-08 23:53:30 +, Robert said:
>
> > Ok. Here finally it is:
> >
> > http://wiki.dlang.org/DIP26
>
> This is pretty much exactly how I think properties should work. There's
> two possibl
Two more things:
Disable a read/write propa like int getSetSomeInteger(int).
int getSomeInteger() and void setSomeIntger(int) only allowed.
And disable default parameter for setter.
The DIP actually solves this.
On Sat, 2013-02-09 at 02:31 -0800, Jonathan M Davis wrote:
> I just went over this with Kenji in his thread "Partial modification
> of DIP23
> to allow module level property." You _must_ be able to rely on front
> being a
> property.
>
> With any API that templates
I added sections
- Upgrade path
- Conclusion
to better prove my point and the concept as such.
On Sat, 2013-02-09 at 04:12 -0800, Jonathan M Davis wrote:
> It fails miserably when the element type of a range is callable.
> That's the
> main reason that @property was introduced in the first place.
It does not, you would have to do:
front()();
Always! front is guaranteed to be a function, (I
On 2013-02-09 11:58:23 +, Jonathan M Davis said:
You must be able to rely on front always being used without parens, and you
must be able to rely on front() doing a call on the return value rather than
simply calling front. Otherwise, you're going to have problems with code
erroneously usin
On 2013-02-09 12:57, Robert wrote:
As you can't actually encapsulate the array with free functions just do:
ref T front(T)(T[] arr);
There is no value in using an actual setter.
Ah, sorry, you're right. It's an lvalue, so no setter is needed.
On Saturday, February 09, 2013 13:01:58 Robert wrote:
> > arrays are by far the most common type of range, I think that it's
> > just asking
> > for trouble to allow their front or back to be used with parens.
>
> Except you ebrace the idea that front is a function (property or not)
> and make par
> arrays are by far the most common type of range, I think that it's
> just asking
> for trouble to allow their front or back to be used with parens.
Except you ebrace the idea that front is a function (property or not)
and make parens work in all cases. Why not do it the other way round,
front
On Saturday, February 09, 2013 12:31:14 FG wrote:
> On 2013-02-09 11:31, Jonathan M Davis wrote:
> > I just went over this with Kenji in his thread "Partial modification of
> > DIP23 to allow module level property." You _must_ be able to rely on
> > front being a property.
>
> front getter MUST be
As you can't actually encapsulate the array with free functions just do:
ref T front(T)(T[] arr);
There is no value in using an actual setter.
If you really want encapsulation, just do:
struct EncapsulatedArray(T) {
T front() @property;
void front(T value) @property;
private T[] arr_;
}
On Sat
On 2013-02-09 12:32, Robert wrote:
Has anyone actually read the DIP?
Simply don't call it property.
Fine for getters but this time it will break things for setters:
@property void front(T)(T[] arr, T elem) {...}
and either all code with assignments would have to be changed
or assignments
On 2013-02-09 11:31, Jonathan M Davis wrote:
I just went over this with Kenji in his thread "Partial modification of DIP23
to allow module level property." You _must_ be able to rely on front being a
property.
front getter MUST be a property... as in RFC2119's MUST??
So all those 75 std @proper
Has anyone actually read the DIP?
Simply don't call it property.
On Sat, 2013-02-09 at 08:45 +0100, FG wrote:
> On 2013-02-09 08:19, Dmitry Olshansky wrote:
> >> NoUFCS for properties
> >
> >> Properties protect the access to a field of an entity
> >> (class/struct/module),
> >> so they actually
On Saturday, February 09, 2013 10:45:13 Robert wrote:
> I am claiming that if we restrict ourselves to the property concept
> explained in the DIP, then the range API would no longer depend on front
> being a property, it can also be a function returning ref, which is
> perfectly legal for UFCS.
>
On Feb 9, 2013 8:01 AM, "Walter Bright" wrote:
>
> On 2/4/2013 7:19 PM, Brian Schott wrote:
>>
>> Still only half speed. I'm becoming more and more convinced that Walter
is
>> actually a wizard.
>
>
> I worship the Dark Arts.
More like cursed the god's when you wrote it. :-)
On Saturday, 9 February 2013 at 03:13:47 UTC, Michel Fortin wrote:
It's really great to not have to write boilerplate functions
when default behaviour is perfectly fine. I've been using
Objective-C for a while now and the recent changes where it
automatically synthesize a variable, a getter, an
On Friday, 8 February 2013 at 23:53:40 UTC, Robert wrote:
Ok. Here finally it is:
http://wiki.dlang.org/DIP26
Best regards,
Robert
Why I should write fun()() when property returns a delegate?
Additional () should not be necessary.
Also combo properties like int get_set_IntValue(int) I thin
I am claiming that if we restrict ourselves to the property concept
explained in the DIP, then the range API would no longer depend on front
being a property, it can also be a function returning ref, which is
perfectly legal for UFCS.
I am further claiming that properties via get/set methods don't
On Saturday, 9 February 2013 at 07:45:05 UTC, FG wrote:
On 2013-02-09 08:19, Dmitry Olshansky wrote:
NoUFCS for properties
Properties protect the access to a field of an entity
(class/struct/module),
so they actually have to be defined within the entity they
belong to, just as
a field would
On Friday, February 08, 2013 23:48:50 Walter Bright wrote:
> On 2/8/2013 12:01 AM, Jonathan M Davis wrote:
> > It's not quite a use case where
> > ranges shine - especially when efficiency is a top priority.
>
> A more problematic case is dmd's lexer relies on a 0 byte at the end to be a
> "sentin
On Saturday, February 09, 2013 08:19:33 deadalnix wrote:
> So, std.utf.decodeFront pop or not the utf character. And in case
> it does not, you ends up having to do extra hanky panky (and
> duplicate logic in std.utf to know if it does pop or not, which
> is likely to be very bug prone).
Well, wit
On 2/4/2013 7:19 PM, Brian Schott wrote:
Still only half speed. I'm becoming more and more convinced that Walter is
actually a wizard.
I worship the Dark Arts.
88 matches
Mail list logo
