www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - libarary haeder

reply "ElfQT" <dethjunk yahoo.com> writes:
What is the best way to provide a D library with a D header (well, I've read 
"there's no need of headers in D"... but there is so it seems).
Do we still have to keep the D source, and a separate (manualy extracted) D 
declaration with a lib?

ElfQT 
Sep 06 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
ElfQT wrote:
 What is the best way to provide a D library with a D header (well, I've read 
 "there's no need of headers in D"... but there is so it seems).
 Do we still have to keep the D source, and a separate (manualy extracted) D 
 declaration with a lib?
 
 ElfQT 
 
 

It is technically possible to add support for headerlessness (that's a mouthful!) in D. But such a feature has not yet been implemented yet. Until such a time, nobody should be bragging about D having such capabilities. :-) -JJR
Sep 06 2005
parent reply "ElfQT" <dethjunk yahoo.com> writes:
I suspected that.
OK, what can I do with the next:

I have a library. That's a D lib. With .d "headers".
Then I have some samples. These should share some common files. (This all 
caomes from c++, yeah). The original layout would be:
MyLibProjFolder
MyLibProjFolder\Main                        -- this is the lib with all the 
D files and lib output
MyLibProjFolder\Samples                   -- containing the following:
MyLibProjFolder\Samples\Common    -- comon files, mostly declarations, used 
by all sample (as source, not lib or anything)
MyLibProjFolder\Sample1                   -- D files compiling into exe
MyLibProjFolder\SampleN                  -- detto

The problem is with imports.
MyLibProjFolder\Samples\Common\all.d or similar should contain all the 
imports needed for the samples using the Main lib.
I don't know how to import any Common module or even Main lib module into 
Sample1.
I get errors like
"ExampleApplication.d(21): module all cannot read file 'all.d'"

How to properly do the layout? What am I missing from the great importing 
schema?

ElfQT


"John Reimer" <brk_6502 yahoo.com> wrote in message 
news:dfku2c$1lat$1 digitaldaemon.com...
 ElfQT wrote:
 What is the best way to provide a D library with a D header (well, I've 
 read "there's no need of headers in D"... but there is so it seems).
 Do we still have to keep the D source, and a separate (manualy extracted) 
 D declaration with a lib?

 ElfQT

It is technically possible to add support for headerlessness (that's a mouthful!) in D. But such a feature has not yet been implemented yet. Until such a time, nobody should be bragging about D having such capabilities. :-) -JJR

Sep 06 2005
parent reply clayasaurus <clayasaurus gmail.com> writes:
ElfQT wrote:
 I suspected that.
 OK, what can I do with the next:
 
 I have a library. That's a D lib. With .d "headers".
 Then I have some samples. These should share some common files. (This all 
 caomes from c++, yeah). The original layout would be:
 MyLibProjFolder
 MyLibProjFolder\Main                        -- this is the lib with all the 
 D files and lib output
 MyLibProjFolder\Samples                   -- containing the following:
 MyLibProjFolder\Samples\Common    -- comon files, mostly declarations, used 
 by all sample (as source, not lib or anything)
 MyLibProjFolder\Sample1                   -- D files compiling into exe
 MyLibProjFolder\SampleN                  -- detto
 
 The problem is with imports.
 MyLibProjFolder\Samples\Common\all.d or similar should contain all the 
 imports needed for the samples using the Main lib.
 I don't know how to import any Common module or even Main lib module into 
 Sample1.
 I get errors like
 "ExampleApplication.d(21): module all cannot read file 'all.d'"
 
 How to properly do the layout? What am I missing from the great importing 
 schema?

Given ... samples\common\all.d samples\sample.d -- all.d -- module common.all; -- -- sample.d -- import common.all; --
 
 ElfQT
 
 
 "John Reimer" <brk_6502 yahoo.com> wrote in message 
 news:dfku2c$1lat$1 digitaldaemon.com...
 
ElfQT wrote:

What is the best way to provide a D library with a D header (well, I've 
read "there's no need of headers in D"... but there is so it seems).
Do we still have to keep the D source, and a separate (manualy extracted) 
D declaration with a lib?

ElfQT

It is technically possible to add support for headerlessness (that's a mouthful!) in D. But such a feature has not yet been implemented yet. Until such a time, nobody should be bragging about D having such capabilities. :-) -JJR


Sep 06 2005
parent reply "ElfQT" <dethjunk yahoo.com> writes:
(I've just noticed I've mistyped the subject, sorry (library header), that 
must be the painkiller I took. (Not because of the confusing import stuff ;) 
don't worry.))
So, the starting point of dmd.exe (or working directory or whatever) _has_ 
to be a common root?
All imports will be looked in the folder (directory) with corresponding 
name?

So it is impossible (or real hard for a mortal like me) to compile from a 
child folder? Well, I don't need that anyway.
But what about another sample exe somewhere else on the harddisk, which 
would like to use the original sample\common (and the Main lib)?

Sorry for being confused :p, if you can point me to a more described place 
than the dm original doc, that would be welcome. (... err, well and if there 
is no any then maybe there should be... something like "module organization, 
referencing modules and libraries")

Thanks,
 ElfQT 
Sep 06 2005
next sibling parent Carlos Santander <csantander619 gmail.com> writes:
ElfQT escribió:
 (I've just noticed I've mistyped the subject, sorry (library header), that 
 must be the painkiller I took. (Not because of the confusing import stuff ;) 
 don't worry.))
 So, the starting point of dmd.exe (or working directory or whatever) _has_ 
 to be a common root?
 All imports will be looked in the folder (directory) with corresponding 
 name?
 
 So it is impossible (or real hard for a mortal like me) to compile from a 
 child folder? Well, I don't need that anyway.
 But what about another sample exe somewhere else on the harddisk, which 
 would like to use the original sample\common (and the Main lib)?
 
 Sorry for being confused :p, if you can point me to a more described place 
 than the dm original doc, that would be welcome. (... err, well and if there 
 is no any then maybe there should be... something like "module organization, 
 referencing modules and libraries")
 
 Thanks,
  ElfQT 
 
 

dmd (arguments) -Ipath_to_files -Ianother_path -- Carlos Santander Bernal
Sep 06 2005
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 7 Sep 2005 00:53:59 +0200, ElfQT <dethjunk yahoo.com> wrote:
 (I've just noticed I've mistyped the subject, sorry (library header),  
 that
 must be the painkiller I took. (Not because of the confusing import  
 stuff ;)
 don't worry.))
 So, the starting point of dmd.exe (or working directory or whatever)  
 _has_
 to be a common root?
 All imports will be looked in the folder (directory) with corresponding
 name?

Have a look in sc.ini in the dmd\bin directory. It has a line which reads: DFLAGS="-I% P%\..\src\phobos" the -I tells the D compiler where to look for imports. The % p% refers to the dmd\bin directory. I have added the following ";% P%\..\..\src" giving: DFLAGS="-I% P%\..\src\phobos;% P%\..\..\src" which tells the compiler to look in 2 directories for imports.
 So it is impossible (or real hard for a mortal like me) to compile from a
 child folder?

You can compile from anywhere (assuming you put dmd\bin in the PATH enviroment variable). It will only look for imports where you tell it to. If you want it to look for imports from the current directory you should be able to add -I. or -I.\ or -I./ to the command line you type (I haven't tried this, you could probably put it in sc.ini and have it always do it if you wanted) Regan
Sep 06 2005
next sibling parent reply Derek Parnell <Derek_member pathlink.com> writes:
In article <opswpfgoya23k2f5 nrage.netwin.co.nz>, Regan Heath says...

you could probably put it in sc.ini and have it always do it  
if you wanted)

While this is true in theory, each new download of DMD replaces any changes you have made to sc.ini with the defaults again. This is why the Build utility uses an additional optional configuration file which supplements sc.ini. It would be useful if DMD could use sc.ini and also use sc_user.ini if it exists...or something like that. We could then maintain our sc_user.ini without new releases messing things up. -- Derek Melbourne, Australia
Sep 06 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 7 Sep 2005 05:57:38 +0000 (UTC), Derek Parnell  
<Derek_member pathlink.com> wrote:
 In article <opswpfgoya23k2f5 nrage.netwin.co.nz>, Regan Heath says...

 you could probably put it in sc.ini and have it always do it
 if you wanted)

While this is true in theory, each new download of DMD replaces any changes you have made to sc.ini with the defaults again. This is why the Build utility uses an additional optional configuration file which supplements sc.ini. It would be useful if DMD could use sc.ini and also use sc_user.ini if it exists...or something like that. We could then maintain our sc_user.ini without new releases messing things up.

This is true. I have a backup copy which is copied by my script for downloading and extracting the latest dmd.zip and dmc.zip. Having a 'user' config file would be nice. So might a per-project/per-library config file. ;) Regan
Sep 06 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
Regan Heath wrote:
 On Wed, 7 Sep 2005 05:57:38 +0000 (UTC), Derek Parnell  
 <Derek_member pathlink.com> wrote:
 
 In article <opswpfgoya23k2f5 nrage.netwin.co.nz>, Regan Heath says...

 you could probably put it in sc.ini and have it always do it
 if you wanted)

While this is true in theory, each new download of DMD replaces any changes you have made to sc.ini with the defaults again. This is why the Build utility uses an additional optional configuration file which supplements sc.ini. It would be useful if DMD could use sc.ini and also use sc_user.ini if it exists...or something like that. We could then maintain our sc_user.ini without new releases messing things up.

This is true. I have a backup copy which is copied by my script for downloading and extracting the latest dmd.zip and dmc.zip. Having a 'user' config file would be nice. So might a per-project/per-library config file. ;) Regan

Are you using Linux? On linux symbolic linking makes things so much easier to work with than on windows. Urg... I had to change the spelling on this post title... it was getting distracting. -JJR
Sep 07 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 07 Sep 2005 12:03:49 -0700, John Reimer <brk_6502 yahoo.com> wrote:
 Regan Heath wrote:
 On Wed, 7 Sep 2005 05:57:38 +0000 (UTC), Derek Parnell   
 <Derek_member pathlink.com> wrote:

 In article <opswpfgoya23k2f5 nrage.netwin.co.nz>, Regan Heath says...

 you could probably put it in sc.ini and have it always do it
 if you wanted)

While this is true in theory, each new download of DMD replaces any changes you have made to sc.ini with the defaults again. This is why the Build utility uses an additional optional configuration file which supplements sc.ini. It would be useful if DMD could use sc.ini and also use sc_user.ini if it exists...or something like that. We could then maintain our sc_user.ini without new releases messing things up.

downloading and extracting the latest dmd.zip and dmc.zip. Having a 'user' config file would be nice. So might a per-project/per-library config file. ;) Regan

Are you using Linux?

No.
 On linux symbolic linking makes things so much easier to work with than  
 on windows.

Yeah, they're a cool feature.
 Urg... I had to change the spelling on this post title... it was getting  
 distracting.

LOL.. I hadn't even noticed. Regan
Sep 07 2005
parent reply pragma <pragma_member pathlink.com> writes:
In article <opswq2onpm23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 Urg... I had to change the spelling on this post title... it was getting  
 distracting.

LOL.. I hadn't even noticed.

Neither did I, which isn't suprising since we're all developers.
 Real Programmers don't eat quiche. In fact, real programmers don't know how to
SPELL quiche. They eat Twinkies, and Szechwan food.

(more here: http://www.codeproject.com/scrapbook/realprog.asp) - EricAnderton at "never installed his textpad dictionary... ever".
Sep 07 2005
next sibling parent "ElfQT" <dethjunk yahoo.com> writes:
 Urg... I had to change the spelling on this post title... it was getting
 distracting.

LOL.. I hadn't even noticed.

Neither did I, which isn't suprising since we're all developers.
 Real Programmers don't eat quiche. In fact, real programmers don't know 
 how to SPELL quiche. They eat Twinkies, and Szechwan food.


Well, I've already told, that it is caused most likely by a strong painkiller. Those I take a lot after my small tooth surgery. So this real programmer doesn't eat much these days, only painkillers (and baby food) ;) ElfQT
Sep 07 2005
prev sibling parent John Reimer <terminal.node gmail.com> writes:
pragma wrote:
 In article <opswq2onpm23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 
Urg... I had to change the spelling on this post title... it was getting  
distracting.

LOL.. I hadn't even noticed.

Neither did I, which isn't suprising since we're all developers.
Real Programmers don't eat quiche. In fact, real programmers don't know how to
SPELL quiche. They eat Twinkies, and Szechwan food.

(more here: http://www.codeproject.com/scrapbook/realprog.asp) - EricAnderton at "never installed his textpad dictionary... ever".

He he... I guess I haven't evolved into a "real" developer yet.. ;). Spelling is typically one of my stronger suits... that is until I try to type on a keyboard. After hitting the "post" button, I'm usually gasping at all the errors I've made. -JJR
Sep 07 2005
prev sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
Derek Parnell wrote:
 In article <opswpfgoya23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 
 
you could probably put it in sc.ini and have it always do it  
if you wanted)

While this is true in theory, each new download of DMD replaces any changes you have made to sc.ini with the defaults again. This is why the Build utility uses an additional optional configuration file which supplements sc.ini. It would be useful if DMD could use sc.ini and also use sc_user.ini if it exists...or something like that. We could then maintain our sc_user.ini without new releases messing things up.

I just make the unzip selective. That is, when I use 7zip to unzip the dmd package to c:\, it asks me if I want to overwrite the files. I say "No" for sc.ini and then say "All" for the rest of the archive (which lets it continue unzipping without further ado). It's pretty easy. -JJR
Sep 07 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 07 Sep 2005 11:59:27 -0700, John Reimer wrote:

 Derek Parnell wrote:
 In article <opswpfgoya23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 
 
you could probably put it in sc.ini and have it always do it  
if you wanted)

While this is true in theory, each new download of DMD replaces any changes you have made to sc.ini with the defaults again. This is why the Build utility uses an additional optional configuration file which supplements sc.ini. It would be useful if DMD could use sc.ini and also use sc_user.ini if it exists...or something like that. We could then maintain our sc_user.ini without new releases messing things up.

I just make the unzip selective. That is, when I use 7zip to unzip the dmd package to c:\, it asks me if I want to overwrite the files. I say "No" for sc.ini and then say "All" for the rest of the archive (which lets it continue unzipping without further ado). It's pretty easy.

And pretty error prone ;-) Is the suggested change to DMD a good or bad idea? -- Derek Parnell Melbourne, Australia 8/09/2005 6:30:42 AM
Sep 07 2005
next sibling parent John Reimer <terminal.node gmail.com> writes:
Derek Parnell wrote:
 On Wed, 07 Sep 2005 11:59:27 -0700, John Reimer wrote:

I just make the unzip selective.  That is, when I use 7zip to unzip the 
dmd package to c:\, it asks me if I want to overwrite the files.  I say 
"No" for sc.ini and then say "All" for the rest of the archive (which 
lets it continue unzipping without further ado).

It's pretty easy.

And pretty error prone ;-) Is the suggested change to DMD a good or bad idea?

Oh sorry... it's a good idea. I just got distracted describing the solution I've been using. Man... can't a guy be self-centered for even a moment? <grin> JJR
Sep 07 2005
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:1ozziah803bsi$.wu7z9zwa837r$.dlg 40tude.net...
 Is the suggested change to DMD a good or bad idea?

I suppose if and IDE existed for D, this would pretty much be a nonissue, as the IDE would keep track of the global import paths. Hopefully that's what'll happen.
Sep 07 2005
parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Jarrett Billingsley wrote:
 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1ozziah803bsi$.wu7z9zwa837r$.dlg 40tude.net...
 
Is the suggested change to DMD a good or bad idea?

I suppose if and IDE existed for D, this would pretty much be a nonissue, as the IDE would keep track of the global import paths. Hopefully that's what'll happen.

SCons) can take care of that. -- Bruno Medeiros Computer Science/Engineering student
Sep 09 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 09 Sep 2005 11:08:36 +0100, Bruno Medeiros wrote:

 Jarrett Billingsley wrote:
 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1ozziah803bsi$.wu7z9zwa837r$.dlg 40tude.net...
 
Is the suggested change to DMD a good or bad idea?

I suppose if and IDE existed for D, this would pretty much be a nonissue, as the IDE would keep track of the global import paths. Hopefully that's what'll happen.


Build,
 SCons) can take care of that.

;-) -- Derek Parnell Melbourne, Australia BUILD v2.09 is now available. http://www.dsource.org/projects/build/ 9/09/2005 8:17:42 PM
Sep 09 2005
parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Derek Parnell wrote:
You don't need a full IDE just for that, just a build tool (make, Ant, 

Build,
SCons) can take care of that.

;-)

Nope, your (ineptly named :) ) tool named Build is not a build tool. It may help acomplish some basic objectives of a build process, but it is nowhere (in nature) like make, Ant, SCons,etc. . Not that it should be btw, it's purpose is fine, and it acomplishes it quite well. I myself use Build with an Ant script, like I posted some time ago, and I find all this worrying about using or preservering sc.ini senseless, I mean, even Build's response files by themselves could handle that. -- Bruno Medeiros Computer Science/Engineering student
Sep 10 2005
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
news:dfrmoc$1jn3$1 digitaldaemon.com...
 You don't need a full IDE just for that, just a build tool (make, Ant, 
 SCons) can take care of that.

I suppose if you like using command lines, that'll work for you. I prefer a nice, clean IDE. Reminds me of programming lab (I'm taking Java this semester). For some reason, we do our development on Sun workstations - yeah, I know, Sun makes Java and all, but it's not like it'll run any differently on other computers. But the teacher honestly expects us to use this editor called "pico" to write our programs. You can't even use the mouse in this absolutely primitive editor, and none of the shortcut keys make any sense (Use pgup and pgdown to page up and page down? Why do that when you can use ^Y and ^V?). Not to mention that the Solaris 9 GUI is ripped straight from Windows 3.1. I feel like I'm in 1990. Way to throw away 15 years of progress, Sun.
Sep 09 2005
next sibling parent reply Chris Sauls <ibisbasenji gmail.com> writes:
Jarrett Billingsley wrote:
 "Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
 news:dfrmoc$1jn3$1 digitaldaemon.com...
 
You don't need a full IDE just for that, just a build tool (make, Ant, 
SCons) can take care of that.

I suppose if you like using command lines, that'll work for you. I prefer a nice, clean IDE.

I like my nice, clean command line, personally. I use the Build utility (see dsource.org) and don't have hardly any issues. Even some of my more massive projects, such as Rouge (a server platform) are handled with command lines like: $ build rouge_debug $ build rouge_unittest $ build rouge_release Prettyness. But then, even simple programs get compiled with just: $ build myapp Yay. :) I do like a decent IDE (I'm personally a fan of Borland's *Builder series) but the command line isn't quite the evil creature it once was. I mean heck, I first learned Java working with just Notepad and a command prompt. -- Chris Sauls
Sep 09 2005
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Chris Sauls" <ibisbasenji gmail.com> wrote in message 
news:dfsm1a$2ih1$1 digitaldaemon.com...
 I like my nice, clean command line, personally.  I use the Build utility 
 (see dsource.org) and don't have hardly any issues.  Even some of my more 
 massive projects, such as Rouge (a server platform) are handled with 
 command lines like:

 $ build  rouge_debug
 $ build  rouge_unittest
 $ build  rouge_release

 Prettyness.  But then, even simple programs get compiled with just:

 $ build myapp

 Yay.  :)  I do like a decent IDE (I'm personally a fan of Borland's 
 *Builder series) but the command line isn't quite the evil creature it 
 once was.  I mean heck, I first learned Java working with just Notepad and 
 a command prompt.

 -- Chris Sauls

Linuxhead ;) Sorry, I'm a born-and-raised Windows user. Every time I've used any variation of Unix or Linux, I feel kind of slighted. Like whoever made the OS is sitting somewhere, laughing that I should be so inexperienced as to not know the cryptic names of a million and one command-line utilities for doing such simple tasks as _searching_. "grep"? WHO CAME UP WITH THAT?! What relation does its name have to searching? Why couldn't it be called "search," or would that make too much sense? I honestly feel like years of progress in graphical, input, and user interface technology is just completely thrown out the window (no pun intended) in favor of an interface which most people have been trying to get away from for a long time. Ignoring all the politics about the monopolistic practices of MS versus the open-source policies of Posix-based systems, I'd still say that Windows is a far easier-to-use OS with far easier-to-use software, and would prefer to use it any day. Period.
Sep 09 2005
next sibling parent Chris Sauls <ibisbasenji gmail.com> writes:
Jarrett Billingsley wrote:
 "Chris Sauls" <ibisbasenji gmail.com> wrote in message 
 news:dfsm1a$2ih1$1 digitaldaemon.com...
 
I like my nice, clean command line, personally.  I use the Build utility 
(see dsource.org) and don't have hardly any issues.  Even some of my more 
massive projects, such as Rouge (a server platform) are handled with 
command lines like:

$ build  rouge_debug
$ build  rouge_unittest
$ build  rouge_release

Prettyness.  But then, even simple programs get compiled with just:

$ build myapp

Yay.  :)  I do like a decent IDE (I'm personally a fan of Borland's 
*Builder series) but the command line isn't quite the evil creature it 
once was.  I mean heck, I first learned Java working with just Notepad and 
a command prompt.

-- Chris Sauls

Linuxhead ;) Sorry, I'm a born-and-raised Windows user.

Never used KDE or GNOME, did you? ;) (Especially recent iterations.) And actually, I'm a Gentoo-head, which is a sort of evil Linux-BSD hybrid creature, on some levels... though its still primarily Linux. Anyway, that said, Build is available for Windows and Linux both. So its off-topic. And for that matter, did I mention I'm sitting at a Win98 box typing this right now? Although of all the Win32 iterations, I still say Windows2000/AS (aka WinNT/5.x) is the best, despite SP2 being essentially broken. WinXP is cute... not wise, but cute. -- Chris Sauls P.S. -- For the record, our Windows boxes have to be rebooted at least once a week to keep in shape. None of our Linux boxes have been rebooted in several months now, and there's no issue. Not to mention I don't think I've ever seen the Blue Screen Of Death in Linux. ;) But let's not get into that.
Sep 10 2005
prev sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Jarrett Billingsley wrote:
 "Chris Sauls" <ibisbasenji gmail.com> wrote in message 
 news:dfsm1a$2ih1$1 digitaldaemon.com...
 
I like my nice, clean command line, personally.  I use the Build utility 
(see dsource.org) and don't have hardly any issues.  Even some of my more 
massive projects, such as Rouge (a server platform) are handled with 
command lines like:

$ build  rouge_debug
$ build  rouge_unittest
$ build  rouge_release

Prettyness.  But then, even simple programs get compiled with just:

$ build myapp

Yay.  :)  I do like a decent IDE (I'm personally a fan of Borland's 
*Builder series) but the command line isn't quite the evil creature it 
once was.  I mean heck, I first learned Java working with just Notepad and 
a command prompt.

-- Chris Sauls

Linuxhead ;) Sorry, I'm a born-and-raised Windows user. Every time I've used any variation of Unix or Linux, I feel kind of slighted. Like whoever made the OS is sitting somewhere, laughing that I should be so inexperienced as to not know the cryptic names of a million and one command-line utilities for doing such simple tasks as _searching_. "grep"? WHO CAME UP WITH THAT?! What relation does its name have to searching? Why couldn't it be called "search," or would that make too much sense?

search (g)lobally for matches to the (r)egular (e)xpression, and (p)rint lines where they are found
 
 I honestly feel like years of progress in graphical, input, and user 
 interface technology is just completely thrown out the window (no pun 
 intended) in favor of an interface which most people have been trying to get 
 away from for a long time.  Ignoring all the politics about the monopolistic 
 practices of MS versus the open-source policies of Posix-based systems, I'd 
 still say that Windows is a far easier-to-use OS with far easier-to-use 
 software, and would prefer to use it any day.  Period. 
 
 

Sep 10 2005
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"clayasaurus" <clayasaurus gmail.com> wrote in message 
news:dfuv1s$28eg$1 digitaldaemon.com...
 search (g)lobally for matches to the (r)egular (e)xpression, and (p)rint 
 lines where they are found

You have _got_ to be kidding me. :)
Sep 10 2005
parent Derek Parnell <derek psych.ward> writes:
On Sat, 10 Sep 2005 16:48:46 -0400, Jarrett Billingsley wrote:

 "clayasaurus" <clayasaurus gmail.com> wrote in message 
 news:dfuv1s$28eg$1 digitaldaemon.com...
 search (g)lobally for matches to the (r)egular (e)xpression, and (p)rint 
 lines where they are found

You have _got_ to be kidding me. :)

Nope. To paraphrase the Indiana University Knowledge Base ... Global Regular Expression Print The 'grep' name comes from the command used by the 'ed' program (a simple and venerable Unix text editor) to print all lines matching a certain pattern: g/re/p -- Derek Parnell Melbourne, Australia 11/09/2005 9:30:39 AM
Sep 10 2005
prev sibling parent Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Jarrett Billingsley wrote:
 "Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
 news:dfrmoc$1jn3$1 digitaldaemon.com...
 
You don't need a full IDE just for that, just a build tool (make, Ant, 
SCons) can take care of that.

I suppose if you like using command lines, that'll work for you. I prefer a nice, clean IDE.

What I was saying, was that just for the part of keeping global import paths (and similar build management stuff) you don't need a full IDE, just a build tool. Of course that for everything else an IDE is quite better, nay, essential even! -- Bruno Medeiros Computer Science/Engineering student
Sep 10 2005
prev sibling next sibling parent "ElfQT" <dethjunk yahoo.com> writes:
Thanks Regan, and Carlos,
somehow I overlooked these settings.
ElfQT 
Sep 07 2005
prev sibling parent reply "ElfQT" <dethjunk yahoo.com> writes:
I still can't cope with importing :(
With the included little import testing layout I get:
"c:\D\MyD\Other\ImportTest\Main\all.d(4): module test1 is in multiple 
packages te
st1"
Where am I wrong?
ElfQT 
Sep 11 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Sun, 11 Sep 2005 22:55:55 +0200, ElfQT wrote:

 I still can't cope with importing :(
 With the included little import testing layout I get:
 "c:\D\MyD\Other\ImportTest\Main\all.d(4): module test1 is in multiple 
 packages te
 st1"
 Where am I wrong?
 ElfQT

You have got an incorrect 'module' statement. That is, you have an import statement that references a file whose module statement is either missing or not qualified enough, or just plain wrong. eg. import util.myfile; but the file "util/myfile" does NOT have the module statement ... module util.myfile; In other words, your import statements must match the imported files' module statement (explicit or implied). -- Derek Parnell Melbourne, Australia 12/09/2005 6:59:18 AM
Sep 11 2005
parent "ElfQT" <dethjunk yahoo.com> writes:
Oh my, you know what was the root of the problem? (Besides of me being silly 
;))
Character case. I typed "RenderTarget" as module name, and imported 
"rendertarget".
Also, this isn't always causes error - with another mis-cased module name it 
simply compiled. (?)

Well then, there's still a bug in D with importing - it gives a wrong (and 
misleading) error. I wonder if it is known?

Thanks Derek.
 ElfQT


"Derek Parnell" <derek psych.ward> wrote in message 
news:5k6qm7ztks4e$.bk5tgngz7xai.dlg 40tude.net...
 On Sun, 11 Sep 2005 22:55:55 +0200, ElfQT wrote:

 I still can't cope with importing :(
 With the included little import testing layout I get:
 "c:\D\MyD\Other\ImportTest\Main\all.d(4): module test1 is in multiple
 packages te
 st1"
 Where am I wrong?
 ElfQT

You have got an incorrect 'module' statement. That is, you have an import statement that references a file whose module statement is either missing or not qualified enough, or just plain wrong. eg. import util.myfile; but the file "util/myfile" does NOT have the module statement ... module util.myfile; In other words, your import statements must match the imported files' module statement (explicit or implied). -- Derek Parnell Melbourne, Australia 12/09/2005 6:59:18 AM

Sep 12 2005