www.digitalmars.com         C & C++   DMDScript  

D - DMD 0.75 release

reply "Walter" <walter digitalmars.com> writes:
This includes the new library layout. It's a bit of a nuisance to update
source code, but the good news is the compiler error messages will help out
a lot. Also, there's /dmd/bin/replace.exe, which is a handy tool for global
search and replace. Use it like:

    replace *.d
    String to be replaced (80 characters max)?
    import c.stdio
    Replacement string?
    import std.c.stdio

etc. which should make short work of most of it.


http://www.digitalmars.com/d/changelog.html
Nov 04 2003
next sibling parent reply "Lars Ivar Igesund" <larsivi stud.ntnu.no> writes:
From the docs:

    std.c.windows.linux

??

Lars Ivar Igesund

"Walter" <walter digitalmars.com> wrote in message
news:boa8ki$1g9u$1 digitaldaemon.com...

 This includes the new library layout. It's a bit of a nuisance to update
 source code, but the good news is the compiler error messages will help


out

 a lot. Also, there's /dmd/bin/replace.exe, which is a handy tool for


global

 search and replace. Use it like:

     replace *.d
     String to be replaced (80 characters max)?
     import c.stdio
     Replacement string?
     import std.c.stdio

 etc. which should make short work of most of it.


 http://www.digitalmars.com/d/changelog.html
Nov 04 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Lars Ivar Igesund" <larsivi stud.ntnu.no> wrote in message
news:boa9sp$1i2u$1 digitaldaemon.com...

 From the docs:

     std.c.windows.linux

 ??

 Lars Ivar Igesund


Typo. Should be std.c.linux
Nov 05 2003
parent reply Elias Martenson <elias-m algonet.se> writes:
Walter wrote:


 Typo. Should be std.c.linux


I asked this on the wiki but no answer still, so I'm sorry for intruding...

I'm qurious, why std.c.linux? Shouldn't it be std.c.unix? Or 
std.c.posix? There aren't very much linux-specific stuff in there is it?

Elias
Nov 05 2003
next sibling parent reply Mark T <Mark_member pathlink.com> writes:
In article <boapcb$28cj$1 digitaldaemon.com>, Elias Martenson says...


I'm qurious, why std.c.linux? Shouldn't it be std.c.unix? Or 
std.c.posix? There aren't very much linux-specific stuff in there is it?


I had the same thought myself. I guess because Walter only supports two
platforms:
x86 Win32
x86 Linux

Probably should have been std.c.unix for UNIX/POSIX stuff and std.c.unix.linux
for Linux only specific stuff (if any).  I don't think Walter uses any other
UNIX besides Linux so he may not feel comfortable in this area.
Nov 05 2003
parent "Julio César Carrascal Urquijo" <adnoctum phreaker.net> writes:
"Mark T" <Mark_member pathlink.com> wrote in message
news:bobgd9$9ic$1 digitaldaemon.com...


 Probably should have been std.c.unix for UNIX/POSIX stuff and


std.c.unix.linux

 for Linux only specific stuff (if any).  I don't think Walter uses any


other

 UNIX besides Linux so he may not feel comfortable in this area.


There's a problem right there. The current implementation doesn't allow a .d
module and a folder with the same name. It's imposible to have std/c/unix.d
and std/c/unix/linux.d becouse the compiler will complain with:

C:\dmd\test.d(2): import unix package and module have the same name
Nov 05 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Elias Martenson" <elias-m algonet.se> wrote in message
news:boapcb$28cj$1 digitaldaemon.com...

 I asked this on the wiki but no answer still, so I'm sorry for


intruding...

You're not intruding. Ask away!


 I'm qurious, why std.c.linux? Shouldn't it be std.c.unix? Or
 std.c.posix? There aren't very much linux-specific stuff in there is it?


Good question. The answer is that there are several different families of
unix, of which linux is one. There's BSD unix, SCO unix, etc. When D is
implemented on them, I can see an std.c.bsdunix, etc., being made for it. I
don't see a problem with the likelihood of the bsdunix and linux files being
90% the same.
Nov 05 2003
next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Perhaps there should be a std.c.unix, containing all the "common" unix
functionality, as well as std.c.linux, which has Linux-specific variants.

There is an equivalent for Windows... some API's only existed on older OS,
some only exist on newer OS.  .NET is almost an entirely new platform!

Sean

"Walter" <walter digitalmars.com> wrote in message
news:bobguh$ae4$1 digitaldaemon.com...

 "Elias Martenson" <elias-m algonet.se> wrote in message
 news:boapcb$28cj$1 digitaldaemon.com...

 I asked this on the wiki but no answer still, so I'm sorry for


 intruding...

 You're not intruding. Ask away!


 I'm qurious, why std.c.linux? Shouldn't it be std.c.unix? Or
 std.c.posix? There aren't very much linux-specific stuff in there is it?


 Good question. The answer is that there are several different families of
 unix, of which linux is one. There's BSD unix, SCO unix, etc. When D is
 implemented on them, I can see an std.c.bsdunix, etc., being made for it.


I

 don't see a problem with the likelihood of the bsdunix and linux files


being

 90% the same.
Nov 05 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bocged$1q8f$1 digitaldaemon.com...

 Perhaps there should be a std.c.unix, containing all the "common" unix
 functionality, as well as std.c.linux, which has Linux-specific variants.


I could see an std.c.posix at some point.


 There is an equivalent for Windows... some API's only existed on older OS,
 some only exist on newer OS.


Microsoft may deprecate APIs, but they are still supported in all versions
of win32. Perhaps you're thinking of win16 (which D doesn't support anyway).


 .NET is almost an entirely new platform!


Yup. There will likely eventually be a std.dotnet.
Nov 05 2003
next sibling parent reply "Julio César Carrascal Urquijo" <adnoctum phreaker.net> writes:
Except that maybe they'll be droping lots of API functions for Longhorn:

"Win32 has like 76,000 APIs, and they're taking it down to 8,000 with
Longhorn technology," said one source familiar with the plans.

http://www.wininsider.com/news/comments.aspx?mid=4982





"Walter" <walter digitalmars.com> wrote in message
news:bochg4$1rtc$1 digitaldaemon.com...

 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bocged$1q8f$1 digitaldaemon.com...

 Perhaps there should be a std.c.unix, containing all the "common" unix
 functionality, as well as std.c.linux, which has Linux-specific




variants.

 I could see an std.c.posix at some point.


 There is an equivalent for Windows... some API's only existed on older




OS,

 some only exist on newer OS.


 Microsoft may deprecate APIs, but they are still supported in all versions
 of win32. Perhaps you're thinking of win16 (which D doesn't support


anyway).

 .NET is almost an entirely new platform!


 Yup. There will likely eventually be a std.dotnet.
Nov 06 2003
parent "Walter" <walter digitalmars.com> writes:
I don't know how they plan to do that without breaking existing apps. If
they do actually remove 90% of the APIs, then that would be essentially a
quite different operating system, and so would merit a different package
name entirely.

"Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
news:boefio$1o8e$1 digitaldaemon.com...

 Except that maybe they'll be droping lots of API functions for Longhorn:

 "Win32 has like 76,000 APIs, and they're taking it down to 8,000 with
 Longhorn technology," said one source familiar with the plans.

 http://www.wininsider.com/news/comments.aspx?mid=4982





 "Walter" <walter digitalmars.com> wrote in message
 news:bochg4$1rtc$1 digitaldaemon.com...

 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bocged$1q8f$1 digitaldaemon.com...

 Perhaps there should be a std.c.unix, containing all the "common" unix
 functionality, as well as std.c.linux, which has Linux-specific




 variants.

 I could see an std.c.posix at some point.


 There is an equivalent for Windows... some API's only existed on older




 OS,

 some only exist on newer OS.


 Microsoft may deprecate APIs, but they are still supported in all




versions

 of win32. Perhaps you're thinking of win16 (which D doesn't support


 anyway).

 .NET is almost an entirely new platform!


 Yup. There will likely eventually be a std.dotnet.
Nov 06 2003
prev sibling parent reply Mark T <Mark_member pathlink.com> writes:
In article <bochg4$1rtc$1 digitaldaemon.com>, Walter says...

"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bocged$1q8f$1 digitaldaemon.com...

 Perhaps there should be a std.c.unix, containing all the "common" unix
 functionality, as well as std.c.linux, which has Linux-specific variants.


I could see an std.c.posix at some point.


Hopefully sooner than later, then most people could use std.c.posix instead of
std.c.linux, so in the future when D for SPARC/Solaris is released there will be
minimal code changes. 

Having lived through the UNIX "wars" of the late 1980's and early 1990's, I
think it is better to start with a standard API and only deviate as necessary
for a specific platform.
Nov 12 2003
parent "Julio César Carrascal Urquijo" <adnoctum phreaker.net> writes:
I could see an std.c.posix at some point.




Well, I think there could be a std.c.posix that just do a public import of
std.c.linux.
Nov 12 2003
prev sibling parent reply Elias Martenson <elias-m algonet.se> writes:
Walter wrote:


 "Elias Martenson" <elias-m algonet.se> wrote in message
 news:boapcb$28cj$1 digitaldaemon.com...
 

I asked this on the wiki but no answer still, so I'm sorry for


 
 intruding...
 
 You're not intruding. Ask away!


Thanks. :-)  It feels a bit scary commenting on the language design of a 
language I just started to learn. :-)


I'm qurious, why std.c.linux? Shouldn't it be std.c.unix? Or
std.c.posix? There aren't very much linux-specific stuff in there is it?


 
 Good question. The answer is that there are several different families of
 unix, of which linux is one. There's BSD unix, SCO unix, etc. When D is
 implemented on them, I can see an std.c.bsdunix, etc., being made for it. I
 don't see a problem with the likelihood of the bsdunix and linux files being
 90% the same.


I'd like to argue that it's more like 99% the same. In fact, I have a 
hard time remembering if I ever write a C program that used 
Linux-specific functionality.

Having whatever Linux specific stuff in std.c.linux is good in my mind, 
but it would feel a lot better to use std.c.posix for the 99% which isn't.

Other than that, thanks a lot of your work, it's appreciated! (even 
though I do some C++ programming at work, I can't say I like it. I'd 
love to see D replace both C and C++ as a popular systems language).
Nov 06 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Elias Martenson" <elias-m algonet.se> wrote in message
news:bod2c5$2m03$1 digitaldaemon.com...

I'm qurious, why std.c.linux? Shouldn't it be std.c.unix? Or
std.c.posix? There aren't very much linux-specific stuff in there is it?


 Good question. The answer is that there are several different families




of

 unix, of which linux is one. There's BSD unix, SCO unix, etc. When D is
 implemented on them, I can see an std.c.bsdunix, etc., being made for




it. I

 don't see a problem with the likelihood of the bsdunix and linux files




being

 90% the same.


 I'd like to argue that it's more like 99% the same. In fact, I have a
 hard time remembering if I ever write a C program that used
 Linux-specific functionality.


It probably is 99% the same. One of the other problems I didn't mention,
though, is the problem of updating it. Suppose D supports a dozen unix
variants with the same module. I don't have access to all these variants. I
update the module for abcunix, and inadvertently break xyzunix which does it
differently.

I'd rather have abcunix and xyzunix as separate modules, so that presumably
whoever is updating xyzunix is doing it on an xyzunix box and won't be
breaking any of the other unix support. Then, maintainers of each of the
unix variants can fold/test the changes in when convenient.


 Having whatever Linux specific stuff in std.c.linux is good in my mind,
 but it would feel a lot better to use std.c.posix for the 99% which isn't.

 Other than that, thanks a lot of your work, it's appreciated! (even
 though I do some C++ programming at work, I can't say I like it. I'd
 love to see D replace both C and C++ as a popular systems language).


Thanks! I would, too!
Nov 06 2003
next sibling parent Elias Martenson <elias-m algonet.se> writes:
Walter wrote:


 It probably is 99% the same. One of the other problems I didn't mention,
 though, is the problem of updating it. Suppose D supports a dozen unix
 variants with the same module. I don't have access to all these variants. I
 update the module for abcunix, and inadvertently break xyzunix which does it
 differently.


That shouldn't really happen, if the functionality on std.c.posix is 
limited to the stuff that is in the Open Groups "Single UNIX 
Specification". After all, that's the document that defines what UNIX 
is. In fact, even Windows implements it through Cygwin, I believe.

The full contents of the specification is available online at: 
http://www.unix-systems.org/version3/online.html


 I'd rather have abcunix and xyzunix as separate modules, so that presumably
 whoever is updating xyzunix is doing it on an xyzunix box and won't be
 breaking any of the other unix support. Then, maintainers of each of the
 unix variants can fold/test the changes in when convenient.


This would only apply to the system specific parts, and I think 
everybody agrees that those really do belong in a different package.

Oh well. In the end I'm sure it'll work out fine. For the most part it 
already has. :-)

Elias
Nov 07 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Why are there so many Unix variants?   Isn't there some sort of standard?
;)

Sean

"Walter" <walter digitalmars.com> wrote in message
news:boe8kj$1dpa$2 digitaldaemon.com...

 It probably is 99% the same. One of the other problems I didn't mention,
 though, is the problem of updating it. Suppose D supports a dozen unix
 variants with the same module. I don't have access to all these variants.


I

 update the module for abcunix, and inadvertently break xyzunix which does


it

 differently.

 I'd rather have abcunix and xyzunix as separate modules, so that


presumably

 whoever is updating xyzunix is doing it on an xyzunix box and won't be
 breaking any of the other unix support. Then, maintainers of each of the
 unix variants can fold/test the changes in when convenient.
Nov 09 2003
parent Elias Martenson <elias-m algonet.se> writes:
Sean L. Palmer wrote:


 Why are there so many Unix variants?   Isn't there some sort of standard?
 ;)


Yes, there is. It's called the Single Unix Specification. It used to be 
called POSIX and is still usually referred to by that name. Hence the 
suggestion to put ann of the standard stuff in std.os.posix.

You can read all about it on http://www.opengroup.org/ or the more 
direct link: http://www.unix.org/. the standard itself can be found at: 
http://www.unix.org/version3/online.html

Elias
Nov 10 2003
prev sibling next sibling parent reply "Y.Tomino" <demoonlit inter7.jp> writes:
It's glad for me that almost "import" were set to "private".
Why are these "public" still ?

random.d:
import std.c.linux.linux;

thread.d
import std.c.windows.windows;

YT
Nov 05 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Y.Tomino" <demoonlit inter7.jp> wrote in message
news:boar82$2auv$1 digitaldaemon.com...

 It's glad for me that almost "import" were set to "private".
 Why are these "public" still ?

 random.d:
 import std.c.linux.linux;

 thread.d
 import std.c.windows.windows;

 YT


Sloth on my part. They should be private.
Nov 05 2003
parent reply J C Calvarese <jcc7 cox.net> writes:
Walter wrote:


 "Y.Tomino" <demoonlit inter7.jp> wrote in message
 news:boar82$2auv$1 digitaldaemon.com...
 

It's glad for me that almost "import" were set to "private".
Why are these "public" still ?

random.d:
import std.c.linux.linux;

thread.d
import std.c.windows.windows;

YT


 
 
 Sloth on my part. They should be private.
 
 


Is is necessary for std.stream to import two modules at the end of the 
stream.d file?  (I'd think it would be better for the individual 
programmer to explicitly import them.)

import std.string;
import std.file;

Just checking...

Justin
Nov 05 2003
parent "Walter" <walter digitalmars.com> writes:
"J C Calvarese" <jcc7 cox.net> wrote in message
news:boci9u$1st3$1 digitaldaemon.com...

 Is is necessary for std.stream to import two modules at the end of the
 stream.d file?  (I'd think it would be better for the individual
 programmer to explicitly import them.)

 import std.string;
 import std.file;

 Just checking...


I don't know. I didn't write stream.d.
Nov 05 2003
prev sibling next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <boa8ki$1g9u$1 digitaldaemon.com>, Walter says...

This includes the new library layout.


yuck, you didn't go far enough, "we" kind expected
that when you said the python lib would be a good model...
changes are irrelevant! basically no structure changes
just naming...
I'm not sure this is going to help to promote submissions
by independent volunteer contributions... a missed opportunity.

<joke> well, what could we expected from a guy that
calls "this" to ctor?</joke> :)


It's a bit of a nuisance to update
source code, but the good news is the compiler error messages will help out
a lot. Also, there's /dmd/bin/replace.exe, which is a handy tool for global
search and replace. Use it like:

    replace *.d
    String to be replaced (80 characters max)?
    import c.stdio
    Replacement string?
    import std.c.stdio


Can this be put into a batch/shell file with all the import changes?
like:
replace *.d "import c.stdio" "import std.c.stdio"
replace *.d "import path" "import std.path"

if somebody started that and post it here others could add to it
and soon we would have a conversion tool.

Ant
Nov 05 2003
parent Ant <Ant_member pathlink.com> writes:
In article <bob35u$2m4j$1 digitaldaemon.com>, Ant says...

In article <boa8ki$1g9u$1 digitaldaemon.com>, Walter says...

This includes the new library layout.


yuck, you didn't go far enough,
... a missed opportunity.


I glad nobody agrees with me! probably means that I'm wrong
and we are on the right track after all...

Ant
Nov 05 2003
prev sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Walter wrote:

 This includes the new library layout. It's a bit of a nuisance to update
 source code, but the good news is the compiler error messages will help out
 a lot. ...
 


I've been trying to get DIG (Carlos's modified version of 0.0.14) to 
compile with the new phobos structure in DMD 0.75, so I've gone through 
and changed all the phobos imports that I could find.

Some of the error message seem to indicate there might be some small 
problems with phobos.  (But I may just be clueless.)  In any case, these 
changes seemed to help my situation, so I'm submitting them for your 
consideration:

phobos\internal\gc\gc.d (change line 16):
import internal.gc.gcx;

phobos\internal\gc\gcx.d (change line 33):
import internal.gc.gcbits;

phobos\std\gcx.d (change line 40):
    import internal.gc.win32;

phobos\internal\gc\gcbits.d (inserted line at top):
module internal.gc.gcbits;

phobos\std\intrinsic.d (change line 11):
module std.intrinsic;  /+ was std.math! +/

phobos\std\c\windows\windows.d (inserted line at top):
module std.c.windows.windows;

phobos\std\ctype.d (inserted line at top):
module std.ctype;

phobos\std\windows\syserror.d (inserted line at top):
module std.windows.syserror;



My latest error message is:
net\BurtonRadons\dig\windows\frame.d(9): module gc is in multiple 
packages std.gc

where the offending line is:
private import std.gc;

If I change it to:
private import internal.gc.gc;

My new error message is:
net\BurtonRadons\dig\windows\base.d(7): import std conflicts with 
windows.std at net\BurtonRadons\dig\windows\windows.d(7)

net\BurtonRadons\dig\windows\windows.d(7):
import std.c.windows.windows;

net\BurtonRadons\dig\windows\base.d(7):
import std.ctype;

I'm running around in circles at this point (I don't even know what 
direction I should be going).  Any ideas, hints, tips, pointers, etc. 
would be must appreciated.


Justin
http://jcc_7.tripod.com/d/
Nov 05 2003
parent reply "Walter" <walter digitalmars.com> writes:
"J C Calvarese" <jcc7 cox.net> wrote in message
news:boca86$1gn4$1 digitaldaemon.com...

 I've been trying to get DIG (Carlos's modified version of 0.0.14) to
 compile with the new phobos structure in DMD 0.75, so I've gone through
 and changed all the phobos imports that I could find.

 Some of the error message seem to indicate there might be some small
 problems with phobos.  (But I may just be clueless.)  In any case, these
 changes seemed to help my situation, so I'm submitting them for your
 consideration:

 phobos\internal\gc\gc.d (change line 16):
 import internal.gc.gcx;

 phobos\internal\gc\gcx.d (change line 33):
 import internal.gc.gcbits;

 phobos\std\gcx.d (change line 40):
     import internal.gc.win32;

 phobos\internal\gc\gcbits.d (inserted line at top):
 module internal.gc.gcbits;


You should not need to do any of this. The makefile to build internal\gc is
\internal\gc\win32.mak, and internal\gc should be the default directory when
it is built.


 phobos\std\intrinsic.d (change line 11):
 module std.intrinsic;  /+ was std.math! +/

 phobos\std\c\windows\windows.d (inserted line at top):
 module std.c.windows.windows;

 phobos\std\ctype.d (inserted line at top):
 module std.ctype;

 phobos\std\windows\syserror.d (inserted line at top):
 module std.windows.syserror;



 My latest error message is:
 net\BurtonRadons\dig\windows\frame.d(9): module gc is in multiple
 packages std.gc

 where the offending line is:
 private import std.gc;

 If I change it to:
 private import internal.gc.gc;

 My new error message is:
 net\BurtonRadons\dig\windows\base.d(7): import std conflicts with
 windows.std at net\BurtonRadons\dig\windows\windows.d(7)

 net\BurtonRadons\dig\windows\windows.d(7):
 import std.c.windows.windows;

 net\BurtonRadons\dig\windows\base.d(7):
 import std.ctype;

 I'm running around in circles at this point (I don't even know what
 direction I should be going).  Any ideas, hints, tips, pointers, etc.
 would be must appreciated.


Generally, the way to isolate these problems is to produce a minimal .d
source file that reproduces them.
Nov 05 2003
parent J C Calvarese <jcc7 cox.net> writes:
Walter wrote:


 "J C Calvarese" <jcc7 cox.net> wrote in message
 news:boca86$1gn4$1 digitaldaemon.com...
 

I've been trying to get DIG (Carlos's modified version of 0.0.14) to
compile with the new phobos structure in DMD 0.75, so I've gone through
and changed all the phobos imports that I could find.

Some of the error message seem to indicate there might be some small
problems with phobos.  (But I may just be clueless.)  In any case, these
changes seemed to help my situation, so I'm submitting them for your
consideration:

phobos\internal\gc\gc.d (change line 16):
import internal.gc.gcx;

phobos\internal\gc\gcx.d (change line 33):
import internal.gc.gcbits;

phobos\std\gcx.d (change line 40):
    import internal.gc.win32;

phobos\internal\gc\gcbits.d (inserted line at top):
module internal.gc.gcbits;


 
 
 You should not need to do any of this. The makefile to build internal\gc is
 \internal\gc\win32.mak, and internal\gc should be the default directory when
 it is built.


Okay, nevermind.


 
 

phobos\std\intrinsic.d (change line 11):
module std.intrinsic;  /+ was std.math! +/




^ I still think I found something here.

It probably doesn't matter, but math.d is already called std.math, so I 
think intrinsic.d should be called std.intrinsic.


phobos\std\c\windows\windows.d (inserted line at top):
module std.c.windows.windows;

phobos\std\ctype.d (inserted line at top):
module std.ctype;

phobos\std\windows\syserror.d (inserted line at top):
module std.windows.syserror;



My latest error message is:
net\BurtonRadons\dig\windows\frame.d(9): module gc is in multiple
packages std.gc

where the offending line is:
private import std.gc;

If I change it to:
private import internal.gc.gc;

My new error message is:
net\BurtonRadons\dig\windows\base.d(7): import std conflicts with
windows.std at net\BurtonRadons\dig\windows\windows.d(7)

net\BurtonRadons\dig\windows\windows.d(7):
import std.c.windows.windows;

net\BurtonRadons\dig\windows\base.d(7):
import std.ctype;

I'm running around in circles at this point (I don't even know what
direction I should be going).  Any ideas, hints, tips, pointers, etc.
would be must appreciated.


 
 
 Generally, the way to isolate these problems is to produce a minimal .d
 source file that reproduces them.
 


Thanks, that's a good approach.  I posted because so many files are 
involved and the error message is so mysterious to me.  I thought that 
someone might have an idea what the root cause was.  (I've probably bit 
off more than I can chew here.)

If I can cut it down to a simple example, I'll post it, but this seems 
to be one of those problems that disappears when the complicated stuff 
is taken out.

Justin
Nov 05 2003