On Wed, Sep 19, 2001 at 02:49:58PM +0100, Leon Brocard wrote:
Attached is a cute prime number printer.
It strikes me that we need a central place to put these things - it'd
really help people get stuck into the lowlevel stuff.
It wouldn't hurt to throw it in as a test. Probably the most
On Wed, Sep 19, 2001 at 01:40:31PM -0400, Pat Eyler wrote:
I realize that the $count inside the if block shown masks the $count
declared outside the while loop, but (to me) this would be easier to
understand if the inner $count where changed to $numParams -- it is more
obvious on casual
The internal do-op-loop runs until it sees a return value of zero from any
op-codes. The RETURN statement within basic_opcodes.ops is really a keyword
which gets parsed into an offset of the current PC counter based on the
internally calculated size of the instruction (known at Configure time
On Thu, Sep 20, 2001 at 12:42:13AM +0100, Robin Houston wrote:
I only had one real problem with Parrot on Darwin, which really has
nothing to do with Darwin at all. The first time I tried to make test
I got a slew of errors about Test::More, so I diligently went to CPAN
and downloaded the
On Thu, Sep 20, 2001 at 04:00:02AM -0400, Michael G Schwern wrote:
The latest version of the Test-More tarball should have blown up in
your face with a big Don't use this, download Test-Simple instead!
This is irrelevant in this case, because that's still a non-core module.
These actually
Oops; that'll teach me to submit things before a cvs update. The
generate.pl I just sent is out-of-date with regards to CVS. Attached
is an updated version.
(I haven't seen my prior mail go through yet; I'm guessing this is
the list being slow, but it might be a problem with my local mail
Brent Dax:
# I'll work on it later today.
Patch below sig. I don't know if (or even really think that) this will
apply cleanly--I haven't updated my CVS in a while--but I don't expect
this to go in until after 0.02. This is basically just to show you what
I'm thinking. Let me know if my
On Thu, Sep 20, 2001 at 01:50:04AM -0700, Brent Dax wrote:
+int main(int argc, char **argv) {
+ printf(%d/%d, sizeof(${iv}), sizeof(${nv}));
+ return 0;
+}
$Config{ivsize} not good enough for ya, then? :)
--
You are in a maze of little twisting passages, all alike.
On Thu, Sep 20, 2001 at 04:30:34AM -0400, Michael G Schwern wrote:
And all of the tests fail with This isn't Parrot bytecode!
That's what I like to see. Thanks.
--
I've looked at the listing, and it's right!
-- Joel Halpern
Simon Cozens:
# On Thu, Sep 20, 2001 at 01:50:04AM -0700, Brent Dax wrote:
# +int main(int argc, char **argv) {
# + printf(%d/%d, sizeof(${iv}), sizeof(${nv}));
# + return 0;
# +}
#
# $Config{ivsize} not good enough for ya, then? :)
No, because the user may have chosen a
On Thu, Sep 20, 2001 at 01:57:51AM -0700, Brent Dax wrote:
No, because the user may have chosen a different value for IV. For
Oh, yep, fair enough. That makes sense.
example, I may have chosen 'long long' in Perl 5 but 'long' in Parrot to
be safe (IIRC, we're still having 64-bit issues)
Attached are trivial comment fixes for two files.
As it so happens, it strikes me that CONCAT Sx, Sx isn't
three-register code. I'd be much happier with CONCAT Sx, Sx, Sx - it'd
make it easier to generate code for and would fit in with the rest of
the instructions. Comments?
Leon
ps should i
On Thu, Sep 20, 2001 at 10:05:00AM +0100, Leon Brocard wrote:
As it so happens, it strikes me that CONCAT Sx, Sx isn't
three-register code. I'd be much happier with CONCAT Sx, Sx, Sx - it'd
make it easier to generate code for and would fit in with the rest of
the instructions. Comments?
It
On Wed, Sep 19, 2001 at 10:32:18PM -0700, Dave Storrs wrote:
Ok, that was pretty much what I thought. But then what is the 'end'
opcode for? It does a 'RETURN 0', which would increment the PC by 0
opcodes...which either counts as an infinite loop or a no-op, and we've
already got a no-op
On Thursday 20 September 2001 05:12 am, Simon Cozens wrote:
On Thu, Sep 20, 2001 at 10:05:00AM +0100, Leon Brocard wrote:
As it so happens, it strikes me that CONCAT Sx, Sx isn't
three-register code. I'd be much happier with CONCAT Sx, Sx, Sx - it'd
make it easier to generate code for and
Simon --
But this still sucks:
while (code = code_start code (code_start + code_size) code-i) {
DO_OP(code, temp, func, interpreter);
}
Three tests and an addition each op. At the *very least*, we should store
code_end = code_start + code_size. And at best...
This:
On Thu, 20 Sep 2001, Michael G Schwern wrote:
But if we run Configure.pl with bleadperl that *does* use 64bit ints
and has debugging flags on, there's trouble.
And all of the tests fail with This isn't Parrot bytecode!
That's because assemble.pl hasn't been patched yet to use the right
Michael --
Thanks. Applied.
On Thu, 2001-09-20 at 04:00, Michael L Maraist wrote:
Guess you're the man to see about a zebra... Well, an equal sign if you don't
squint really hard.
Version 1.6 line 613
You have
$string =~
On Thu, Sep 20, 2001 at 09:03:45AM -0400, Andy Dougherty wrote:
On Thu, 20 Sep 2001, Michael G Schwern wrote:
But if we run Configure.pl with bleadperl that *does* use 64bit ints
and has debugging flags on, there's trouble.
And all of the tests fail with This isn't Parrot bytecode!
Don't forget that this patch requires the configure patch by Brent that was
just a couple of messages back.
-Original Message-
From: Michael G Schwern
To: Andy Dougherty
Cc: [EMAIL PROTECTED]
Sent: 9/20/2001 8:22 AM
Subject: Re: Complete failure on Linux/PowerPC with 64bit ints.
On
On Wed, Sep 19, 2001 at 02:51:19PM -0400, Andy Dougherty wrote:
This might help a bit.
It does; Parrot is now working to at least some degree on Tru64.
Andy, I love you and I want to have your children.
--
void russian_roulette(void) { char *target; strcpy(target, bullet); }
On Tue, 18 Sep 2001, H.Merijn Brand wrote:
[...]
it's only updated every 6th hour. Maybe I'll get time to get it to
update more often (but not create a snapshot) tonight.
From all my machines I get
i2:/l1/pro/3gl/CPAN/parrot 104 rsync -avz rsync://cvs.perl.org::parrot-HEAD/ .
failed
These are the minimal fixes for smoking to take effect.
After these are in, I'll release Parrot::Smoke
* Makefile.in
* it is $(INC)/config.h, not config.h
* .o = $(O)
* test_main.c
* _read was ok when it was inside
ifdef WIN32
now it must be read ( or it fails in
On Thu, Sep 20, 2001 at 09:22:50AM -0400, Michael G Schwern wrote:
That's because assemble.pl hasn't been patched yet to use the right
pack_type. You can either apply my patch from yesterday or you can
hand-patch the pack_type for 'i' to be 'q'.
This one?
http:[EMAIL
On Thu, Sep 20, 2001 at 09:00:20AM +0100, Simon Cozens wrote:
So, if you're running on one of the core platforms, please check out a *clean*
CVS copy, try and build and post the output of make test.
FWIW, here's the current state of Tru64:
Failed TestStat Wstat Total Fail Failed List of
Ok, I applied Damien's integer.t fix and we now get:
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/op/number.t7 1792237 30.43% 1 7 9 11 13 15 17
4 subtests skipped.
Failed 1/5 test
On Thu, 20 Sep 2001, Simon Cozens wrote:
On Wed, Sep 19, 2001 at 02:51:19PM -0400, Andy Dougherty wrote:
This might help a bit.
It does; Parrot is now working to at least some degree on Tru64.
Your job has just begun :-).
Seriously, some serious thought is needed about integral and
[EMAIL PROTECTED] (Andy Dougherty) writes:
[...]
That's because assemble.pl hasn't been patched yet to use the right
pack_type. You can either apply my patch from yesterday [...]
If you sign up for an account at http://dev.perl.org/auth/account I am
sure that Dan and Simon will let me flip
This patch does two only somewhat related things.
Parrot/Opcode.pm: Change the hard-wired assumption that sizeof(nv) =
2*sizeof(iv) to a PConfig-type computed value.
Parrot/Test.pm: Change it to run with the perl that was used to generate
this version of Parrot. This is useful if, for
[EMAIL PROTECTED] (Simon Cozens) writes:
[...]
So, if you're running on one of the core platforms, please check out a *clean*
CVS copy, try and build and post the output of make test.
On FreeBSD 4.x all passes (or skips) except the first t/op/integer
test. (as other people have mentioned).
On Thu, Sep 20, 2001 at 10:38:10AM -0400, Andy Dougherty wrote:
This patch does two only somewhat related things.
Parrot/Opcode.pm: Change the hard-wired assumption that sizeof(nv) =
2*sizeof(iv) to a PConfig-type computed value.
Parrot/Test.pm: Change it to run with the perl that was
I'm seriously investigating the possibility of changing IV and NV to something
more readable.
(But for those of you who are following language-dev, don't tell 'em because
then they'll think they've won. ;)
--
I don't understand how people can think SCSI is anything more quirky
than a genius
On Thu, 20 Sep 2001, Philip Kendall wrote:
What version of Perl are we requiring to bootstrap Parrot? At the
moment, things fail with 5.005 because:
2) The use of `!' to pack() in the assembler.
Oops. My fault. I forgot that was a new addition.
It's not really a big problem. You can
At 03:34 PM 9/20/2001 +0100, Simon Cozens wrote:
(But for those of you who are following language-dev, don't tell 'em because
then they'll think they've won. ;)
Ah, go ahead and tell them. I don't much care about who wins or loses if
the code's easier to maintain and runs fast. (Neither do I
At 03:59 PM 9/20/2001 +0200, Arthur Bergman wrote:
While it has been decided that perl should be using ithread like
threading, I guess that is irelevant at the parrot level. Are you
going to have one virtual cpu per thread with it's own set of registers
or are you going to context switch the
At 12:07 AM 9/20/2001 -0700, Damien Neil wrote:
I'm not at all certain what to do with things outside the opcodes
themselves. The .ops = .c conversion was clearly originally
concieved as translating one file into another. In order to dispatch
ops via a switch, you need to pull out only the
At 10:22 PM 9/19/2001 -0700, Dave Storrs wrote:
I'm working on documenting the opcodes, and I want to make sure that I
understand the 'RETURN' code properly. I've poked around a little bit to
see if I coudl figure it out, but I don't want to divert too much. Would
someone please explain to me
Simon Cozens [EMAIL PROTECTED] wrote:
I'm seriously investigating the possibility of changing IV and NV to something
more readable.
(But for those of you who are following language-dev, don't tell 'em because
then they'll think they've won. ;)
Some time ago I sugested that NV was a bad
On Thu, 20 Sep 2001, Andy Dougherty wrote:
On Thu, 20 Sep 2001, Philip Kendall wrote:
What version of Perl are we requiring to bootstrap Parrot? At the
moment, things fail with 5.005 because:
2) The use of `!' to pack() in the assembler.
Oops. My fault. I forgot that was a new
At 04:16 PM 9/20/2001 +0100, Dave Mitchell wrote:
Also, I think that IV needs splitting into two or more different
types.
There is the type that specifically fits in the Parrot integer registers
and is recognised by parrot ops;
Then there are all the other places within perl and parrot which
On Thu, Sep 20, 2001 at 11:39:52AM -0400, Dan Sugalski wrote:
I don't want to do int-pointer casts anywhere in the source if we can
possibly avoid it. Yech.
In which case, do we *need* a type that can hold both.
--
Darkly hinting of head hitting desk
-- Megahal (trained on asr),
On Thu, Sep 20, 2001 at 09:00:20AM +0100, Simon Cozens wrote:
So, if you're running on one of the core platforms, please check out a *clean*
CVS copy, try and build and post the output of make test.
FWIW, here's the current state of Linux/Sparc (ivsize=8, nvsize=8,
ptrsize=4)
Failed 4/5 test
At 04:38 PM 9/20/2001 +0100, Simon Cozens wrote:
On Thu, Sep 20, 2001 at 11:39:52AM -0400, Dan Sugalski wrote:
I don't want to do int-pointer casts anywhere in the source if we can
possibly avoid it. Yech.
In which case, do we *need* a type that can hold both.
I can't think of a reason, no.
I will be on vacation in Disney World from now until Sunday night.
Therefore, if you need me I won't be here :)
Tanton
This patch adds some more tidying-up to Makefile.in and t/Makefile.
The split between clean and realclean is absolutely arbitrary; season to
taste.
diff -r -u parrot/Makefile.in parrot-andy/Makefile.in
--- parrot/Makefile.in Wed Sep 19 12:48:28 2001
+++ parrot-andy/Makefile.in Thu Sep 20
On Thu 20 Sep 2001 15:49, Simon Cozens [EMAIL PROTECTED] wrote:
On Thu, Sep 20, 2001 at 09:00:20AM +0100, Simon Cozens wrote:
So, if you're running on one of the core platforms, please check out a *clean*
CVS copy, try and build and post the output of make test.
FWIW, here's the current
On Thu, 20 Sep 2001, Brent Dax wrote:
Damien Neil:
# RETURN(0); (written exactly like that, no variation permitted)
# is a special case, and terminates the runops loop. The only op
# which uses this is end, and it doesn't actually ever execute.
# Personally, I feel that this special case
AB == Arthur Bergman [EMAIL PROTECTED] writes:
AB In an effort to rest my braine from a coredumping perl5 I started
AB to think a bit on threading under parrot? While it has been
AB decided that perl should be using ithread like threading, I guess
AB that is irelevant at the parrot
On Thu, 20 Sep 2001, Dan Sugalski wrote:
At 04:38 PM 9/20/2001 +0100, Simon Cozens wrote:
On Thu, Sep 20, 2001 at 11:39:52AM -0400, Dan Sugalski wrote:
I don't want to do int-pointer casts anywhere in the source if we can
possibly avoid it. Yech.
In which case, do we *need* a type
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS I'm also seriously considering throwing *all* PerlIO code into separate
DS threads (one per file) as an aid to asynchrony.
but that will be hard to support on systems without threads. i still
have that internals async i/o idea floating in my
Automated smoke report for patch Sep 20 00:00:02 2001
v0.01 on MSWin32 using cl version
O = OK
F = Failure(s), extended report at the bottom
? = still running or test results not (yet) available
Build failures during: - = unknown
c = Configure, m = make, t = make
Configuration VC7 Normal is BROKEN.
Step: make test
STDOUT output:
C:\Perl\bin\perl.exe t/harness
t/op/basic..dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
Failed 1/2 tests, 50.00% okay (-1 skipped test: 0 okay, 0.00%)
t/op/integerdubious
DS I'm also seriously considering throwing *all* PerlIO code into
separate
DS threads (one per file) as an aid to asynchrony.
but that will be hard to support on systems without threads. i still
have that internals async i/o idea floating in my numb skull. it is an
api that would
On Thu, Sep 20, 2001 at 12:33:54PM -0700, Hong Zhang wrote:
DS I'm also seriously considering throwing *all* PerlIO code into
separate
DS threads (one per file) as an aid to asynchrony.
but that will be hard to support on systems without threads. i still
have that internals
Arthur Bergman wrote:
In an effort to rest my braine from a coredumping perl5 I started to think a bit on
threading under parrot?
While it has been decided that perl should be using ithread like threading, I guess
that is irelevant at the parrot level. Are you
going to have one virtual cpu
Arthur Bergman wrote:
In an effort to rest my braine from a coredumping perl5 I started to think a bit
on threading under parrot?
While it has been decided that perl should be using ithread like threading, I
guess that is irelevant at the parrot level. Are you
going to have one
Dan,
Could you explain again why you don't want char* anywhere, and prefer void*?
You answered this on language-dev, but went off on what seemed to be a tangent
about encodings.
Some ramblings of my own that may be confusing me, are:
char* doesn't necessarily mean a string.
would
On Thu, Sep 20, 2001 at 09:06:12AM -0500, Gibbs Tanton - tgibbs wrote:
Damien, is there any way we could get a similar fix for number.t? That
would make us at 100% on Tru64.
(Apologies if this shows up twice; something appears to be screwy with
my mail system.)
I'm currently getting
On Thu, Sep 20, 2001 at 11:11:42AM -0400, Dan Sugalski wrote:
Actually the ops=C conversion was conceived to do exactly what's being
done now--to abstract out the body of the opcodes so that they could be
turned into a switch, or turned into generated machine code, or TIL'd. If
you're
What we're going to do is fire up a new interpreter for each thread. (We
may have a pool of prebuilt interpreters hanging around for this
eventuality) Threading *is* essential at the parrot level, and there are
even a few (as yet undocumented) opcodes to deal with them, and some stuff
At 02:21 PM 9/20/2001 -0400, Andy Dougherty wrote:
On Thu, 20 Sep 2001, Dan Sugalski wrote:
At 04:38 PM 9/20/2001 +0100, Simon Cozens wrote:
On Thu, Sep 20, 2001 at 11:39:52AM -0400, Dan Sugalski wrote:
I don't want to do int-pointer casts anywhere in the source if we can
possibly
At 01:06 PM 9/20/2001 -0700, Robert Spier wrote:
Dan,
Could you explain again why you don't want char* anywhere, and prefer
void*?
Because for character data we're not sure char * is right. (Might be
wchar_t, __int16, __int32, or something else) It's also to shake off the
Oh, it's
At 01:08 PM 9/20/2001 -0700, Damien Neil wrote:
Another approach would be to include a means of defining information
that must be included by the file implementing the ops. For example:
HEADER {
#include math.h
}
This would then be placed into interp_guts.h. (Possibly surrounded
by a
Quoting Dan Sugalski [EMAIL PROTECTED]:
Could you explain again why you don't want char* anywhere, and
prefer
void*?
Because for character data we're not sure char * is right. (Might be
wchar_t, __int16, __int32, or something else) It's also to shake off the
Oh, it's character
On Thu, Sep 20, 2001 at 04:13:48PM -0400, Michael L Maraist wrote:
What we're going to do is fire up a new interpreter for each thread. (We
may have a pool of prebuilt interpreters hanging around for this
eventuality) Threading *is* essential at the parrot level, and there are
even a
At 12:33 PM 9/20/2001 -0700, Hong Zhang wrote:
DS I'm also seriously considering throwing *all* PerlIO code into
separate
DS threads (one per file) as an aid to asynchrony.
but that will be hard to support on systems without threads. i still
have that internals async i/o idea
At 04:36 PM 9/20/2001 -0400, Rocco Caputo wrote:
On Thu, Sep 20, 2001 at 04:13:48PM -0400, Michael L Maraist wrote:
What we're going to do is fire up a new interpreter for each thread. (We
may have a pool of prebuilt interpreters hanging around for this
eventuality) Threading *is*
At 01:53 PM 9/20/2001 -0700, Damien Neil wrote:
On Thu, Sep 20, 2001 at 04:38:57PM -0400, Dan Sugalski wrote:
Nope. Internal I/O, at least as the interpreter will see it is async. You
can build sync from async, it's a big pain to build async from sync.
Doesn't mean we actually get
Nope. Internal I/O, at least as the interpreter will see it is async. You
can build sync from async, it's a big pain to build async from sync.
Doesn't mean we actually get asynchrony, just that we can.
It is trivial to build async from sync, just using thread. Most Unix async
are built
Just a reminder--function names shouldn't exceed 31 characters. The C
standard doesn't guarantee anything past that...
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL
DN == Damien Neil [EMAIL PROTECTED] writes:
DN On Thu, Sep 20, 2001 at 04:57:44PM -0400, Dan Sugalski wrote:
For clarification: do you mean async I/O, or non-blocking I/O?
Async. When the interpreter issues a read, for example, it won't assume the
read completes immediately.
On Thu, Sep 20, 2001 at 05:09:52PM -0400, Dan Sugalski wrote:
Just a reminder--function names shouldn't exceed 31 characters. The C
standard doesn't guarantee anything past that...
You think that's bad? You aren't guaranteed more than six characters,
case-insensitive for external
test_main.c still seems to contain a call to _read(), rather than
read(). This breaks compilation under Tru64 for me; the attached
patch removes the _.
- Damien
Index: test_main.c
===
RCS file:
Arthur Bergman wrote:
Arthur Bergman wrote:
In an effort to rest my braine from a coredumping perl5 I started to think a bit
on threading under parrot?
While it has been decided that perl should be using ithread like threading, I
guess that is irelevant at the parrot level. Are
At 05:23 PM 9/20/2001 -0400, Michael L Maraist wrote:
There wasn't any code for CHECK_EVENTS w/in Parrot when I first read the
source-code. I merely assumed that it's role was not-yet determined, but
considered the possible uses. CHECK_EVENTS seems to be gone at the
moment, so it's a moot
At 02:04 PM 9/20/2001 -0700, Damien Neil wrote:
On Thu, Sep 20, 2001 at 04:57:44PM -0400, Dan Sugalski wrote:
For clarification: do you mean async I/O, or non-blocking I/O?
Async. When the interpreter issues a read, for example, it won't assume
the
read completes immediately.
That
At 04:54 PM 9/20/2001 -0500, Brian Wheeler wrote:
Since all benchmarks are crap anyway, I've written a test which tells
the average number of instructions per second. On my athlon 700 I get
3966053 instructions per second and on my PIII 866 I get 5081485
instructions per second. Do those sound
On Thu, 2001-09-20 at 16:46, Dan Sugalski wrote:
At 04:54 PM 9/20/2001 -0500, Brian Wheeler wrote:
Since all benchmarks are crap anyway, I've written a test which tells
the average number of instructions per second. On my athlon 700 I get
3966053 instructions per second and on my PIII 866 I
On Thu, Sep 20, 2001 at 04:54:21PM -0500, Brian Wheeler wrote:
Since all benchmarks are crap anyway, I've written a test which tells
the average number of instructions per second. On my athlon 700 I get
3966053 instructions per second and on my PIII 866 I get 5081485
instructions per second.
On Thu, Sep 20, 2001 at 11:52:50PM +0100, Tom Hughes wrote:
I have test.pasm reporting 7.14M ops/sec on a 200MHz K6 running
linux with the interpreter compiled -O3. That's about twice the
speed that I get without any optimisation.
Oh, right. Optimization.
I'm getting 2.67 MIPS with -O3.
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS There probably won't be any. The current thinking is that since
DS the ops themselves will be a lot smaller, we'll have an explicit
DS event checking op that the compiler will liberally scatter through
DS the generated code. Less overhead
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS Might sound that way, but it isn't. What I'm talking about is
DS something like:
DS READ S3, P1, I0
DS X: SLEEP 3
DS EQ I0, 0, X
DS PRINT S3
DS Where we issue the read on the filehandle in P1, telling it to
DS store
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrieving revision 1.11
diff -u -r1.11 Configure.pl
--- Configure.pl2001/09/20 13:35:26 1.11
+++ Configure.pl2001/09/20 19:49:03
@@ -105,7
On Thu, Sep 20, 2001 at 09:06:12AM -0500, Gibbs Tanton - tgibbs wrote:
Failed 1/5 test scripts, 80.00% okay. 7/74 subtests failed, 90.54% okay.
make: *** [test] Error 2
Damien, is there any way we could get a similar fix for number.t? That
would make us at 100% on Tru64.
I'm currently
Okay, this fixes the issues with changing your IV or NV size. It also
provides an early warning if your C compiler settings aren't okay. I've
also made the style of the code a little more consistent. I'm applying
this, but I figure people might as well check it over anyway.
--Brent Dax
[EMAIL
Damien Neil:
# test_main.c still seems to contain a call to _read(), rather than
# read(). This breaks compilation under Tru64 for me; the attached
# patch removes the _.
Since this (I think) has been submitted multiple times and never applied
(and no reason was given for not applying), I've
[EMAIL PROTECTED] (Mattia Barbon) writes:
Automated smoke report for patch Sep 20 00:00:02 2001
I've changed the .timestamp file to be UTC and include that
information.
--
ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
[EMAIL PROTECTED] (Brent Dax) writes:
+(@c{qw(ivsize opsize nvsize)})=split('/', `test$c{exe}`);
I changed this so it works without having . in $PATH.
- ask
--
ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
88 matches
Mail list logo
