"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374364869616319@news.digitalmars.com...

> On Fri, 28 Jun 2002 10:34:13 -0700 "Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote:
>
> >    The bottomline is that it would be best if paths were normalized to
using
> > forward-slashes only. But that's bad for Windows. I don't think there's
a
>
> Why is it bad for Windows? It works, after all...a

   For example: Have you never copy-pasted a path from an explorer window's
address toolbar? Or from the file properties dialog? Or from a thousand
other different places? They all come with back-slashes...

   In general, it's bad when you want to transfer a path from another
program or file. I do that often enough.

Salutaciones,
                         JCAB

Because it makes *my* life easier to be able to avoid using a makefile entirely.  And to do that I have to tell the compiler where to find my modules.  That can be done either in the IDE or in the source files.

Maybe they could give you a command line option such as

dmd -remap("oldpath.oldmodule", "newpath.newsubdir.newmodule")

for moving other people's modules around without global search and replace. Not that you couldn't easily find a global search and replace tool that could replace all

    import oldpath.oldmodule;

with

    import newpath.newsubdir.newmodule;

If you like makefiles, you'll love command line tools.  I personally despise both as historical artifacts.  I want modern tools that automate this crap or at least put a pretty interface on it.

Sean

"Richard Krehbiel" <rich@kastle.com> wrote in message news:afpp21$2hr4$1@digitaldaemon.com...
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374387634624421@news.digitalmars.com...
> > On Mon, 1 Jul 2002 09:05:34 -0400 "Richard Krehbiel" <rich@kastle.com>
> wrote:
> >
> > > It's mostly a mindset thing, since both work fine with the file system
> APIs;
> > > however, forward slashes really don't work with most Windows
> command-line
> > > tools, so if you get used to using them as path separators, and then
you
> > > need to spawn a tool or script with a file name, you might be in for a surprise.
> >
> > I am aware of that. However, we were discussing the import statement (and its C++ #include analogue), which relies on API, and supports back slashes quite happily. In fact, using \ in pathnames in #include is considered bad practice even om Windows (or so I heard). At least / works everywhere. As for system() and alike, well, it has platform-dependent behaviour by design, I guess.
>
> Yeah, well, I'm still voting not to introduce the notion of file system
path
> in import directives.  I want to be able to take a project whose
components
> exists in seventeen different places, .ZIP it, carry it somewhere, expand
it
> to a single directory, and build it.  I have done things like this, for on-site customer support (carry with me a dev environment and a project's sources on a CD).
>
> If the language allows specific paths in import directives, then I'll be able to carry *my* projects around like this (because I'm careful to avoid explicit paths), but not *yours* (which my manager will dump into my lap when you quit).  I've already got languages which subject me to this; why should I adopt D if it's no better?
>
> --
> Richard Krehbiel, Arlington, VA, USA
> rich@kastle.com (work) or krehbiel3@comcast.net  (personal)

On Mon, 1 Jul 2002 10:23:08 -0700 "Juan Carlos Arevalo Baeza" <jcab@roningames.com> wrote:

>    For example: Have you never copy-pasted a path from an explorer window's
> address toolbar? Or from the file properties dialog? Or from a thousand
> other different places? They all come with back-slashes...
> 
>    In general, it's bad when you want to transfer a path from another
> program or file. I do that often enough.

Since I do almost everything in console, I don't really use explorer address field or file property dialog that often. =) Besides, you get an absolute path, which is not suitable anyhow, and you have to strip it - so why not replace \ with / as well.

.. or write a preprocessor script (gema rules!).

On Mon, 1 Jul 2002 10:37:25 -0400 "Richard Krehbiel" <rich@kastle.com> wrote:

> Yeah, well, I'm still voting not to introduce the notion of file system path in import directives.  I want to be able to take a project whose components exists in seventeen different places, .ZIP it, carry it somewhere, expand it to a single directory, and build it.  I have done things like this, for on-site customer support (carry with me a dev environment and a project's sources on a CD).

Since most D implementations are going to implement packages using
directories (it just seems to be most logical solution), I guess
it won't be possible that easy. Only maybe if Walter allows us to
alias modules? Or some alternative way to define packages (like, say,
a .dpk file which is just a list of modules).

But then again, I also think that it's better to think in terms
of modules and packages rather than files and directories. It's
more abstract. While I wouldn't mind using / to separate package
names in import directive (even though it _might_ be completely
unrelated to directories in some implementations), but dot also okay.

Pavel Minayev wrote:

> Since most D implementations are going to implement packages using
> directories (it just seems to be most logical solution), I guess
> it won't be possible that easy. Only maybe if Walter allows us to
> alias modules? Or some alternative way to define packages (like, say,
> a .dpk file which is just a list of modules).

This seems an excellent idea, a simple (ascii) file which maps the module/package to a specific file would be an excellent method of solving the problem.  For example (in myProject.dpk).

version Windows {
        module phobos = "c:\dmd\import\phobos";
        /* etcetra */
}
version Unix {
        module phobos = "//usr/import/phobos";
        /* etcetra */
}

If a format similar to this was used it would be easy to modify for a new
operating system without having to modify the source and as the syntax is
similar to the D syntax virtually no extra learning is necessary.  All the
compiler would have to do is check for a .dpk file in the directory it was
compiling and then parse that file, if the .dpk file was not present it
would use the default options, environment variable or simply report a
module not found error.

> But then again, I also think that it's better to think in terms
> of modules and packages rather than files and directories. It's
> more abstract. While I wouldn't mind using / to separate package
> names in import directive (even though it _might_ be completely
> unrelated to directories in some implementations), but dot also okay.

Since we are already using a full stop (.) in import declarations, I see no
reason to change - it is a well though out,  platform independent and
consistant with the remainder of the D language.

C 2002/7/2

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:afek1t$pev$1@digitaldaemon.com...
> You know what?   SCREW OS/390.
>
> Sean

LOL. Some things are rightfully left in the dustbin of history, worthy of maintaining existing support but not worthy of crippling new designs. These include:

1) 16 bit architectures
2) CPUs with no hardware stack
3) non-IEEE floating point (i.e. VAX floating point)
4) non-2's complement arithmetic
5) EBCDIC

etc.

Yes, you're right.


"Pavel Minayev" <evilone@omen.ru> wrote in message
news:CFN374338619483102@news.digitalmars.com...
Hmm... I thought there are packages for this:
import engine.gravity;
import engine.ai;
import objects.monsters.orc;

"C.R.Chafer" <blackmarlin@nospam.asean-mail.com> wrote in message news:afeolg$tnn$1@digitaldaemon.com...
> Agreed, but please please please do not use back slashes (use forward slashes instead, or colons).  The backslash key on each of my 6 keyboard
is
> in a different place - and on one it is completely absent.

When I recently replaced my keyboard, the new one had the [Enter] key with a bulge on the top that replaced the \ key. This caused me no end of grief, because I'd mean to type things like:

    rm foo\abc.def

but would hit enter instead of the \, resulting in:

    rm foo

which would wipe out the directory. Similar disastrous problems happen with the copy command and several others. After a week of this, I finally scrounged around till I found the older style (from IBM) with the small [Enter] key and the \ in the right place!

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:afhnhj$1qkr$1@digitaldaemon.com...
> Personally I do not see why all OS'es, Windows as well
> as all the others don't just make both characters valid?

The reason that Windows is backwards is because in the bad old DOS days, Microsoft decided to use / as the switch character, rather than -. (The / is used as a switch in DEC operating systems, which DOS mimics.) Then, when subdirectories were added in DOS 2, Microsoft was stuck, and so decided to use \ for the path separator.

It's caused problems ever since.

Many Windows programs and some operating system APIs do accept both \ and /, but support is erratic and unreliable. What Microsoft should have done is deprecate the / as a switch when they came out with NT, but they missed that opportunity, and XP continues to use / as a switch.

Walter wrote:
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message
> news:afek1t$pev$1@digitaldaemon.com...
> 
>>You know what?   SCREW OS/390.
>>

hehe

>>Sean
> 
> 
> LOL. Some things are rightfully left in the dustbin of history, worthy of
> maintaining existing support but not worthy of crippling new designs. These
> include:
> 
> 1) 16 bit architectures

+1

> 2) CPUs with no hardware stack

+1

> 3) non-IEEE floating point (i.e. VAX floating point)

+1

> 4) non-2's complement arithmetic

not sure about that one...What will you do when a (moderately mass produced) processor based on
positive, negative, neutral charge (or + & minus) or something of the such comes a long and does something like this:

0000 = 0
0001 = 1
0002 = 2
0010 = 3

This seems like it may end up being an evolutionary rather than revolutionary step in processor technology.

> 5) EBCDIC
> 

+1 - You do realize you're risking mass hordes of true IBMers coming after you in mobs...

> etc.
> 
> 

On that note.  I'm curious why the "extended" datatype.  I find it a bit queer in reference to the other datatypes.  I understand its purpose, but it seems directly counter to the other datatypes.  I think I'd rather see "extended80" and "extended96" or something of the such with an eye towards processor optimization.  Meaning while extended80 would be a native processor implemnetation on an intel chip, it might not be on another, but would be defined solidly.  The "extended96" would of course would be implemented by the software and not the hardware on an intel chip.  (and its just a guess as to what an extended type might be on some other platform).

I have the same concern with wchar.  It seems to me more logical to provide a defined datatype, and let those who know that its 16 bit on windows and who want to optimize for windows, use the wchar16.  If you don't know, or you don't care, etc, then you'll just choose what's appropriate and perhaps miss the fact that you could have done it more efficiently otherwise.

Does that make sense?

-Andy