On 04/02/2011 20:55, bearophile wrote:
Bruno Medeiros:
That language ecosystems are what matter, not just the language itself.
This is true, but only once your language is already very good :-)
Bye,
bearophile
I disagree. I think an average language with an average toolchain (I'm
not
On Wednesday, February 16, 2011 09:23:04 Bruno Medeiros wrote:
On 04/02/2011 20:55, bearophile wrote:
Bruno Medeiros:
That language ecosystems are what matter, not just the language itself.
This is true, but only once your language is already very good :-)
Bye,
bearophile
I
Wed, 16 Feb 2011 17:23:04 +, Bruno Medeiros wrote:
On 04/02/2011 20:55, bearophile wrote:
Bruno Medeiros:
That language ecosystems are what matter, not just the language
itself.
This is true, but only once your language is already very good :-)
Bye,
bearophile
I disagree. I think
Daniel Gibson wrote:
When you're learning a language, you want to get familiar with it before
starting to fix stuff.
I tend to learn things by fixing them :-)
On Mon, 07 Feb 2011 01:06:46 -0800
Walter Bright newshou...@digitalmars.com wrote:
I tend to learn things by fixing them :-)
Heh...this is called 'engineer'. ;)
Sincerely,
Gour
--
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
On 02/07/2011 10:06 AM, Walter Bright wrote:
Daniel Gibson wrote:
When you're learning a language, you want to get familiar with it before
starting to fix stuff.
I tend to learn things by fixing them :-)
¡ great !
Though original authors often do not appreciate this attitude very much,
2011/2/4 Bruno Medeiros brunodomedeiros+spam@com.gmail:
language ecosystems are what matter, not just the language itself. At least
for most programmers, what you want is to develop software, software that is
useful or interesting, it's not about staring at the beauty of your code and
that's
On 18/01/2011 05:20, Walter Bright wrote:
http://urbanhonking.com/ideasfordozens/2011/01/18/what-makes-a-programming-language-good/
I quit being a professional programmer.
I usually avoid discussions and dismiss out of hand opinions about
software development from those who no longer
I quit being a professional programmer.
I usually avoid discussions and dismiss out of hand opinions about
software development from those who no longer develop code (did that
recently with my boss, to cut off a discussion). Mostly for time saving,
it's not that I think they automatically
Bruno Medeiros:
That language ecosystems are what matter, not just the language itself.
This is true, but only once your language is already very good :-)
Bye,
bearophile
On 02/04/2011 09:55 PM, bearophile wrote:
Bruno Medeiros:
That language ecosystems are what matter, not just the language itself.
This is true, but only once your language is already very good :-)
A key point is, imo, whether the eco-system grows, and how harmoniously, is
completely
Le 18/01/2011 11:45, bearophile a écrit :
Vladimir Panteleev:
So, you want D to force people to do more work, out of no practical reason?
When you develop a large system, the nice hand holding that works with small
systems often stops working (because the whole language ecosystem is often
Le 19/01/2011 20:20, Nick Sabalausky a écrit :
nedbrek nedb...@yahoo.com wrote in message
news:ih6o0g$2geu$1...@digitalmars.com...
Vladimir Panteleev vladi...@thecybershadow.net wrote in message
news:op.vpjlwrletuz...@cybershadow.mshome.net...
On Wed, 19 Jan 2011 08:09:11 +0200, Austin
Le 18/01/2011 13:01, Vladimir Panteleev a écrit :
On Tue, 18 Jan 2011 13:27:56 +0200, bearophile
bearophileh...@lycos.com wrote:
Vladimir Panteleev:
It also demotivates and alienates programmers.
I don't believe so. I've never seen any C++ programmer who has worked on
other languages
Am 29.01.2011 21:21, schrieb el muchacho:
Le 18/01/2011 13:01, Vladimir Panteleev a écrit :
On Tue, 18 Jan 2011 13:27:56 +0200, bearophile
bearophileh...@lycos.com wrote:
Vladimir Panteleev:
It also demotivates and alienates programmers.
I don't believe so. I've never seen any C++
Daniel Gibson Wrote:
Am 29.01.2011 21:21, schrieb el muchacho:
Le 18/01/2011 13:01, Vladimir Panteleev a écrit :
On Tue, 18 Jan 2011 13:27:56 +0200, bearophile
bearophileh...@lycos.com wrote:
Vladimir Panteleev:
It also demotivates and alienates programmers.
I don't believe
On Thu, 2011-01-20 at 19:24 +0100, Lutger Blijdestijn wrote:
[ . . . ]
Do you have an opinion for the .NET world? I'm currently just using MSBuild,
but know just enough to get it working. It sucks.
I thought .NET was dominated by NAnt -- I have no direct personal
experience, so am
On 2011-01-19 21:13, Adam Ruppe wrote:
Vladimir Panteleev wrote:
Your tool will just download the latest version of Y and the
whole thing crashes and burns.
My problem is I don't see how that'd happen in the first place. Who
would distribute something they've never compiled?
If they compiled
In digitalmars.D, you wrote:
The two most frustrating aspects were documentation and deployment.
The documents were sparse and useless and deployment was the
hugest headache I've ever experienced, in great part due to Rubygems
not working properly!
They've probably improved it a lot since
On Wed, 19 Jan 2011 19:40:49 +0100
Jacob Carlborg d...@me.com wrote:
1. it uses python, yet another dependency
True, but it brings more features over e.g. cmake 'cause you have full
language on disposal.
2. it seems complicated
Well, build systems are complex... ;)
Sincerely,
Gour
--
I missed a lot of this thread and coming in part way through may miss
lots of past nuances, or even major facts.
On Thu, 2011-01-20 at 10:19 +0100, Gour wrote:
On Wed, 19 Jan 2011 19:40:49 +0100
Jacob Carlborg d...@me.com wrote:
1. it uses python, yet another dependency
True, but it
On Thu, 20 Jan 2011 10:13:00 +
Russel Winder rus...@russel.org.uk wrote:
SCons, Waf, and Gradle are currently the tools of choice.
Gradle is (mostly) for Java-based projects, afaict?
Sincerely,
Gour
--
Gour | Hlapicina, Croatia | GPG key: CDBF17CA
On Thu, 2011-01-20 at 12:32 +0100, Gour wrote:
On Thu, 20 Jan 2011 10:13:00 +
Russel Winder rus...@russel.org.uk wrote:
SCons, Waf, and Gradle are currently the tools of choice.
Gradle is (mostly) for Java-based projects, afaict?
It is the case that there are two more or less
Am 20.01.2011 00:54, schrieb Adam D. Ruppe:
Jesse Phillips wrote:
You can have the author release packaged libraries for developers
to use and the author should do this. So this begs the question of
what is the repository for?
It's so you have a variety of libraries available at once with
Pre-built libs aren't all that useful anyway, for several reasons:
By pre-built I mean all the source is in one place, so the
compile Just Works, not necessarily being pre-compiled.
So if you downloaded mylib.zip, every file it needs is in there. No
need to separately hunt down
Am 20.01.2011 14:48, schrieb Adam Ruppe:
Pre-built libs aren't all that useful anyway, for several reasons:
By pre-built I mean all the source is in one place, so the
compile Just Works, not necessarily being pre-compiled.
So if you downloaded mylib.zip, every file it needs is in there. No
However, when there are breaking changes, random.garbage needs a new
version (e.g. 0.6.etc instead of 0.5.etc).
IMO the best way to do that would be to get everyone in the habit
of including the version in their modules.
module random.garbage.0.6;
import random.garbage.0.6;
That way, it is
On Thu, 20 Jan 2011 16:30:40 +0200, Adam Ruppe destructiona...@gmail.com
wrote:
IMO the best way to do that would be to get everyone in the habit
of including the version in their modules.
module random.garbage.0.6;
import random.garbage.0.6;
Even better, we could enforce this to only
When you compile, you have to provide a path anyhow, less hostile to
user and you don't have to change the code.
One of the things implicit in the thread now is removing the
need to provide a path - the compiler can (usually) figure it
out on its own. Try dmd -v and search for import lines.
On Thu, 20 Jan 2011 09:58:17 -0500, Adam Ruppe destructiona...@gmail.com
wrote:
When you compile, you have to provide a path anyhow, less hostile to
user and you don't have to change the code.
One of the things implicit in the thread now is removing the
need to provide a path - the compiler
Russel Winder wrote:
On Thu, 2011-01-20 at 12:32 +0100, Gour wrote:
On Thu, 20 Jan 2011 10:13:00 +
Russel Winder rus...@russel.org.uk wrote:
SCons, Waf, and Gradle are currently the tools of choice.
Gradle is (mostly) for Java-based projects, afaict?
It is the case that there are
On 2011-01-20 10:19, Gour wrote:
On Wed, 19 Jan 2011 19:40:49 +0100
Jacob Carlborgd...@me.com wrote:
1. it uses python, yet another dependency
True, but it brings more features over e.g. cmake 'cause you have full
language on disposal.
I would go with a tool that uses a dynamic language
On 2011-01-20 13:12, Daniel Gibson wrote:
Am 20.01.2011 00:54, schrieb Adam D. Ruppe:
Jesse Phillips wrote:
You can have the author release packaged libraries for developers
to use and the author should do this. So this begs the question of
what is the repository for?
It's so you have a
On 2011-01-20 15:58, Adam Ruppe wrote:
When you compile, you have to provide a path anyhow, less hostile to
user and you don't have to change the code.
One of the things implicit in the thread now is removing the
need to provide a path - the compiler can (usually) figure it
out on its own. Try
On 01/18/2011 07:10 PM, bearophile wrote:
spir:
The D styleguide requires on one hand capitalised names for types, and
lowercase for filenames on the other. How are we supposed to make them
match?
Why do you want them to match?
Because when a module defines a type Foo (or rather, it's what
On 01/19/2011 05:16 AM, Jesse Phillips wrote:
This is what the Open Scalable Language Toolchains talk is about
http://vimeo.com/16069687
The idea is that the compile has the job of compiling the program and
providing information about the program to allow other tools to make use
of the
spir:
Because when a module defines a type Foo (or rather, it's what is
exported), I like it to be called Foo.d.
Generally D modules contain many types.
Bye,
bearophile
Am 19.01.2011 07:35, schrieb Vladimir Panteleev:
On Wed, 19 Jan 2011 08:09:11 +0200, Austin Hastings ah0801...@yahoo.com wrote:
On 1/19/2011 12:50 AM, Vladimir Panteleev wrote:
On Wed, 19 Jan 2011 07:16:40 +0200, Austin Hastings
ah0801...@yahoo.com wrote:
None of them worked.
Most of
On Wed, 19 Jan 2011 12:57:42 +0200, spir denis.s...@gmail.com wrote:
Because when a module defines a type Foo (or rather, it's what is
exported), I like it to be called Foo.d. A module called doFoo.d would
certainly mainly define a func doFoo. So, people directly know what's in
there (and
On 2011-01-19 06:55, Andrei Alexandrescu wrote:
On 1/18/11 11:37 PM, Vladimir Panteleev wrote:
On Tue, 18 Jan 2011 22:17:08 +0200, Walter Bright
newshou...@digitalmars.com wrote:
Vladimir Panteleev wrote:
IMO, sticking to the C-ism of one object file at a time and
dependency on external
On 2011-01-18 17:29, Andrei Alexandrescu wrote:
On 1/18/11 6:36 AM, Lutger Blijdestijn wrote:
Vladimir Panteleev wrote:
On Tue, 18 Jan 2011 13:35:34 +0200, Lutger Blijdestijn
lutger.blijdest...@gmail.com wrote:
I'm pretty happy that my Fedora repositories are just a handful,
most of
which
Vladimir Panteleev vladi...@thecybershadow.net wrote in message
news:op.vpjlwrletuz...@cybershadow.mshome.net...
On Wed, 19 Jan 2011 08:09:11 +0200, Austin Hastings ah0801...@yahoo.com
wrote:
On 1/19/2011 12:50 AM, Vladimir Panteleev wrote:
Actually, you're probably right here. To my
On 01/19/2011 12:56 PM, bearophile wrote:
spir:
Because when a module defines a type Foo (or rather, it's what is
exported), I like it to be called Foo.d.
Generally D modules contain many types.
Yep, but often one is the main exported element. When there are several,
hopefully sensibly
On Wed, 19 Jan 2011 14:07:27 +0100
Jacob Carlborg d...@me.com wrote:
I'm not an expert but I've been thinking for a while about doing a
package system for D, basically RubyGems but for D.
Have you thought about waf (which already has some support for D as
build system) and it is intended to
Jim wrote:
I never claimed that file storage was an optimisation. The compiler
can optimise better by seeing more source code (or a greater AST if
you will) at compile time. Inlining, for example, can only occur
within a compilation unit. I'm arguing that a file is not the optimal
compilation
Andrei wrote:
We need a package system that takes Internet distribution
into account.
Do you think something like my simple http based system would work?
Fetch dependencies. Try to compile. If the linker complains about
missing files, download them from http://somewebsite/somepath/filename,
Am 19.01.2011 14:56, schrieb Adam Ruppe:
Andrei wrote:
We need a package system that takes Internet distribution
into account.
Do you think something like my simple http based system would work?
Fetch dependencies. Try to compile. If the linker complains about
missing files, download them
Daniel Gibson wrote:
That'd suck horribly for bigger projects, and also when
you've got a lot of dependencies, I guess
Maybe, especially if the dependencies have dependencies (it'd
have to download one set before knowing what to look for for
the next set), but that is a one time cost - after
On 1/19/11 7:56 AM, Adam Ruppe wrote:
Andrei wrote:
We need a package system that takes Internet distribution
into account.
Do you think something like my simple http based system would work?
Fetch dependencies. Try to compile. If the linker complains about
missing files, download them
On 2011-01-19 14:39, Gour wrote:
On Wed, 19 Jan 2011 14:07:27 +0100
Jacob Carlborgd...@me.com wrote:
I'm not an expert but I've been thinking for a while about doing a
package system for D, basically RubyGems but for D.
Have you thought about waf (which already has some support for D as
On 2011-01-19 14:56, Adam Ruppe wrote:
Andrei wrote:
We need a package system that takes Internet distribution
into account.
Do you think something like my simple http based system would work?
Fetch dependencies. Try to compile. If the linker complains about
missing files, download them
On 2011-01-19 18:44, Jacob Carlborg wrote:
On 2011-01-19 14:39, Gour wrote:
On Wed, 19 Jan 2011 14:07:27 +0100
Jacob Carlborgd...@me.com wrote:
I'm not an expert but I've been thinking for a while about doing a
package system for D, basically RubyGems but for D.
Have you thought about waf
nedbrek nedb...@yahoo.com wrote in message
news:ih6o0g$2geu$1...@digitalmars.com...
Vladimir Panteleev vladi...@thecybershadow.net wrote in message
news:op.vpjlwrletuz...@cybershadow.mshome.net...
On Wed, 19 Jan 2011 08:09:11 +0200, Austin Hastings ah0801...@yahoo.com
wrote:
On 1/19/2011
spir denis.s...@gmail.com wrote in message
news:mailman.710.1295434677.4748.digitalmar...@puremagic.com...
On 01/18/2011 07:10 PM, bearophile wrote:
spir:
The D styleguide requires on one hand capitalised names for types, and
lowercase for filenames on the other. How are we supposed to make
Wed, 19 Jan 2011 13:56:17 +, Adam Ruppe wrote:
Andrei wrote:
We need a package system that takes Internet distribution
into account.
Do you think something like my simple http based system would work?
Fetch dependencies. Try to compile. If the linker complains about
missing files,
retard wrote:
A build tool without any kind of dependency versioning support is a
complete failure.
You just delete the old files and let it re-download them to
update. If the old one is working for you, simply keep it.
spir:
Yep, but often one is the main exported element.
That's not true for Phobos, my dlibs1, and lot of my code that uses those libs.
When there are several, hopefully sensibly related, exported things, then it's
easy to indicate: mathFuncs, stringTools, bitOps... while still following D
Wed, 19 Jan 2011 19:41:47 +, Adam Ruppe wrote:
retard wrote:
A build tool without any kind of dependency versioning support is a
complete failure.
You just delete the old files and let it re-download them to update. If
the old one is working for you, simply keep it.
I meant that if
On Wed, 19 Jan 2011 21:41:47 +0200, Adam Ruppe destructiona...@gmail.com
wrote:
retard wrote:
A build tool without any kind of dependency versioning support is a
complete failure.
You just delete the old files and let it re-download them to
update. If the old one is working for you, simply
I meant that if the latest version 0.321 of the project 'foobar'
depends on 'bazbaz 0.5.8.2'
Personally, I'd just prefer people to package their damned
dependencies with their app
But, a configuration file could fix that easily enough. Set one up
like this:
bazbaz =
Wed, 19 Jan 2011 20:01:28 +, Adam Ruppe wrote:
I meant that if the latest version 0.321 of the project 'foobar'
depends on 'bazbaz 0.5.8.2'
Personally, I'd just prefer people to package their damned dependencies
with their app
But, a configuration file could fix that easily
Vladimir Panteleev wrote:
Your tool will just download the latest version of Y and the
whole thing crashes and burns.
My problem is I don't see how that'd happen in the first place. Who
would distribute something they've never compiled?
If they compiled it, it would have downloaded the other
Meh.
Just give us File access in CTFE and we'll be done talking about build
tools. Just run DMD on the thing and the app automagically tracks and
downloads all of its dependencies.
Im kidding. But file access in CTFE would be so damn cool. :)
Adam Ruppe Wrote:
Vladimir Panteleev wrote:
Your tool will just download the latest version of Y and the
whole thing crashes and burns.
My problem is I don't see how that'd happen in the first place. Who
would distribute something they've never compiled?
If they compiled it, it would
retard wrote:
How it goes is you come up with more and more features if you spend
sometime THINKING about the possible functionality for such a tool.
It, as written now, does everything I've ever wanted. If I try
to do every possible function, it'll never be done. The question
is what's
Jesse Phillips wrote:
But if they haven't done any development on it for the last year, but
the library it depends on has...
Unless you give library authors write access to your hard drive,
it doesn't matter. They can't make your old, saved version
magically disappear. If you then distribute
Am 19.01.2011 21:22, schrieb Andrej Mitrovic:
Meh.
Just give us File access in CTFE and we'll be done talking about build
tools. Just run DMD on the thing and the app automagically tracks and
downloads all of its dependencies.
Im kidding. But file access in CTFE would be so damn cool. :)
What
Adam Ruppe Wrote:
Jesse Phillips wrote:
But if they haven't done any development on it for the last year, but
the library it depends on has...
Unless you give library authors write access to your hard drive,
it doesn't matter. They can't make your old, saved version
magically disappear.
Mafi Wrote:
Am 19.01.2011 21:22, schrieb Andrej Mitrovic:
Meh.
Just give us File access in CTFE and we'll be done talking about build
tools. Just run DMD on the thing and the app automagically tracks and
downloads all of its dependencies.
Im kidding. But file access in CTFE would
Adam D. Ruppe Wrote:
Jesse Phillips wrote:
You can have the author release packaged libraries for developers
to use and the author should do this. So this begs the question of
what is the repository for?
It's so you have a variety of libraries available at once with
minimal hassle when
Jesse Phillips Wrote:
DSSS seemed to provide a great amount of simplicity and power... the problem
is that it didn't always work.
I always wondered what happened to that boy. He had impressive coding skills
and lots of pragmatic common sense. There was at least one weakness in his
persona
Nick Sabalausky a@a.a wrote in message
news:ih7dj0$s4j$1...@digitalmars.com...
nedbrek nedb...@yahoo.com wrote in message
news:ih6o0g$2geu$1...@digitalmars.com...
Vladimir Panteleev vladi...@thecybershadow.net wrote in message
news:op.vpjlwrletuz...@cybershadow.mshome.net...
On Wed, 19
On 1/19/11 9:04 PM, Gary Whatmore wrote:
Jesse Phillips Wrote:
DSSS seemed to provide a great amount of simplicity and power... the problem is
that it didn't always work.
I always wondered what happened to that boy. He had impressive coding skills
and lots of pragmatic common sense. There
On Tue, 18 Jan 2011 07:20:56 +0200, Walter Bright
newshou...@digitalmars.com wrote:
http://urbanhonking.com/ideasfordozens/2011/01/18/what-makes-a-programming-language-good/
So, why do users still get a scary linker error when they try to compile a
program with more than 1 module?
IMO
Vladimir Panteleev wrote:
On Tue, 18 Jan 2011 07:20:56 +0200, Walter Bright
newshou...@digitalmars.com wrote:
http://urbanhonking.com/ideasfordozens/2011/01/18/what-makes-a-programming-language-good/
So, why do users still get a scary linker error when they try to compile
a program
On Tue, 18 Jan 2011 11:11:01 +0200, Vladimir Panteleev
vladi...@thecybershadow.net wrote:
a) does not indicate what exactly is wrong (module not passed to
linker, not that the linker knows that)
By the way, disregarding extern(C) declarations et cetera, the compiler
has the ability to
On Tue, 18 Jan 2011 11:05:34 +0200, Walter Bright
newshou...@digitalmars.com wrote:
Vladimir Panteleev wrote:
On Tue, 18 Jan 2011 07:20:56 +0200, Walter Bright
newshou...@digitalmars.com wrote:
http://urbanhonking.com/ideasfordozens/2011/01/18/what-makes-a-programming-language-good/
So
Vladimir Panteleev:
IMO, sticking to the C-ism of one object file at a time and dependency
on external build tools / makefiles is the biggest mistake DMD did in this
regard.
A Unix philosophy is to create tools that are able to do only one thing well,
and rdmd uses DMD to do its job of
Vladimir Panteleev vladi...@thecybershadow.net wrote:
- I must stress that having a shared community-wide style to write D
code helps a lot when you want to use in your program modules written
by other people. Otherwise your program looks like a patchwork of
wildly different styles.
I
Vladimir Panteleev:
Forcing a code repository is bad.
In this case I was not suggesting to force things :-) But having a place to
find reliable modules is very good.
This is not practical.
It works in Python, Ruby and often in Perl too, so I don't agree.
I assume you mean naming
-a-programming-language-good/
So, why do users still get a scary linker error when they try to
compile a program with more than 1 module?
What is that message?
C:\Temp\D\Build dmd test1.d
OPTLINK (R) for Win32 Release 8.00.8
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http
On Tue, 18 Jan 2011 10:32:53 + (UTC)
Trass3r u...@known.com wrote:
We must avoid having the same disastrous situation like C/C++ where
everyone uses a different system, CMake, make, scons, blabla.
I agree (planning not to use blabla build system, but waf).
Otoh, I hope D2 will also be
Vladimir Panteleev wrote:
On Tue, 18 Jan 2011 12:10:25 +0200, bearophile bearophileh...@lycos.com
wrote:
Walter:
http://urbanhonking.com/ideasfordozens/2011/01/18/what-makes-a-
programming-language-good/
It's a cute blog post. It suggests that it will be good to:
Getting Code:
1) Have
On Tue, 18 Jan 2011 13:28:32 +0200, Walter Bright
newshou...@digitalmars.com wrote:
What is that message?
C:\Temp\D\Build dmd test1.d
OPTLINK (R) for Win32 Release 8.00.8
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
test1.obj(test1)
On Tue, 18 Jan 2011 13:27:56 +0200, bearophile bearophileh...@lycos.com
wrote:
Vladimir Panteleev:
Forcing a code repository is bad.
In this case I was not suggesting to force things :-) But having a place
to find reliable modules is very good.
This is not practical.
It works in
On Tue, 18 Jan 2011 13:35:34 +0200, Lutger Blijdestijn
lutger.blijdest...@gmail.com wrote:
I'm pretty happy that my Fedora repositories are just a handful, most of
which are setup out of the box. It's a big time saver, one of it's best
features. I would use / evaluate much less software if I
Vladimir Panteleev:
I think we have a misunderstanding, then? Who ensures that the modules
just work? If someone breaks something, are they thrown out of The Holy
Repository?
There is no single solution to such problems. It's a matter of creating rules
and lot of work to enforce them as
Vladimir Panteleev wrote:
On Tue, 18 Jan 2011 13:35:34 +0200, Lutger Blijdestijn
lutger.blijdest...@gmail.com wrote:
I'm pretty happy that my Fedora repositories are just a handful, most of
which are setup out of the box. It's a big time saver, one of it's best
features. I would use /
On Tue, 18 Jan 2011 14:30:53 +0200, bearophile bearophileh...@lycos.com
wrote:
Vladimir Panteleev:
I think we have a misunderstanding, then? Who ensures that the modules
just work? If someone breaks something, are they thrown out of The
Holy
Repository?
There is no single solution to
On Tue, 18 Jan 2011 14:36:43 +0200, Lutger Blijdestijn
lutger.blijdest...@gmail.com wrote:
Vladimir Panteleev wrote:
On Tue, 18 Jan 2011 13:35:34 +0200, Lutger Blijdestijn
lutger.blijdest...@gmail.com wrote:
I'm pretty happy that my Fedora repositories are just a handful, most
of
which
dmd @cmd
The only limit is the amount of memory in your system.
That's not what I meant - I meant it doesn't scale as far as user effort
in concerned. There is no reason why D should force users to maintain
response files, make files, etc. D (the language) doesn't need them,
On Tue, 18 Jan 2011 14:47:29 +0200, Jim bitcir...@yahoo.com wrote:
I imagine such a compiler could also do some interesting optimisations
based on its greater perspective.
Compiling the entire program at once opens the door to much more than just
optimizations. You could have virtual
Vladimir Panteleev wrote:
On Tue, 18 Jan 2011 14:36:43 +0200, Lutger Blijdestijn
lutger.blijdest...@gmail.com wrote:
Vladimir Panteleev wrote:
On Tue, 18 Jan 2011 13:35:34 +0200, Lutger Blijdestijn
lutger.blijdest...@gmail.com wrote:
I'm pretty happy that my Fedora repositories are just
Jim wrote:
Why can't the compiler traverse this during compilation in order to
find all relevant modules and compile them if needed?
How will it find all the modules? Since modules and files don't
have to have matching names, it can't assume import foo; will
necessarily be found in foo.d. I use
Interestingly, my own experience with Ruby, a few years ago, was
almost 180 degrees opposite of the blogger's.
The two most frustrating aspects were documentation and deployment.
The documents were sparse and useless and deployment was the
hugest headache I've ever experienced, in great part due
On Tue, 18 Jan 2011 15:51:58 +0200, Adam Ruppe destructiona...@gmail.com
wrote:
Jim wrote:
Why can't the compiler traverse this during compilation in order to
find all relevant modules and compile them if needed?
How will it find all the modules? Since modules and files don't
have to have
Vladimir Panteleev:
I think [file/module name mismatches] is a misfeature.
Maybe. 9/10 times they match anyway, but I'd be annoyed if
the package names had to match the containing folder.
Here's what I think might work: just use the existing import
path rule. If it gets a match, great. If not,
On 1/18/11, Walter Bright newshou...@digitalmars.com wrote:
You can put
hundreds if you like.
DMD can, but Optlink can't handle long arguments.
On 1/18/11, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
On 1/18/11, Walter Bright newshou...@digitalmars.com wrote:
You can put
hundreds if you like.
DMD can, but Optlink can't handle long arguments.
Although now that I've read the error description I might have passed
a wrong
On Tue, 18 Jan 2011 16:58:31 +0200, Adam Ruppe destructiona...@gmail.com
wrote:
Yeah, makefiles and build scripts are adequately fit already.
Then the question is: does the time you spent writing and maintaining
makefiles and build scripts exceed the time it would take you to set up a
1 - 100 of 126 matches
Mail list logo
