On Monday, 24 June 2013 at 08:52:47 UTC, OlliP wrote:
This is now a bit confusing to me. I just made up my mind to go
with D instead of Go, because Go is too simplistic in my
opinion.
Furthermore, calling C from D is a lot easier than from Go. And
now this ... I have too little understanding
On 2013-06-24 23:33, JS wrote:
Having one file to share is better than many. It makes it easier to
version, easier to maintain, and easier to distribute.
It is better than just zipping the collection of files, e.g. jar's,
because it allows for better structural encoding but is effectively the
On Tuesday, 25 June 2013 at 09:35:52 UTC, Jacob Carlborg wrote:
On 2013-06-24 23:33, JS wrote:
Having one file to share is better than many. It makes it
easier to
version, easier to maintain, and easier to distribute.
It is better than just zipping the collection of files, e.g.
jar's,
It should be possible to export(or rather share) types,
mixins, templates, generic unit tests, etc. (shared compile time
constructs would just be copied to a shared library as they
can't be compiled)
All public compilable constructs should be automatically
exported. A shared keyword added to a
On Monday, 24 June 2013 at 01:20:46 UTC, Martin Nowak wrote:
On 06/24/2013 02:23 AM, Martin Nowak wrote:
exports for anyhow.
for Windows that is
And Aix, unless they have adopted the more common UNIX model
meanwhile.
This is now a bit confusing to me. I just made up my mind to go
with D instead of Go, because Go is too simplistic in my opinion.
Furthermore, calling C from D is a lot easier than from Go. And
now this ... I have too little understanding of D to see what the
impact of this build time issue is.
On Mon, Jun 24, 2013 at 1:52 AM, OlliP jeti...@web.de wrote:
This is now a bit confusing to me. I just made up my mind to go
with D instead of Go, because Go is too simplistic in my opinion.
Furthermore, calling C from D is a lot easier than from Go. And
now this ... I have too little
On 6/24/13 1:52 AM, OlliP wrote:
This is now a bit confusing to me. I just made up my mind to go
with D instead of Go, because Go is too simplistic in my opinion.
Furthermore, calling C from D is a lot easier than from Go. And
now this ... I have too little understanding of D to see what the
On 2013-06-24 09:35, JS wrote:
It should be possible to export(or rather share) types,
mixins, templates, generic unit tests, etc. (shared compile time
constructs would just be copied to a shared library as they
can't be compiled)
These are compile time entities. I don't see why they need to
On Monday, 24 June 2013 at 20:48:49 UTC, Jacob Carlborg wrote:
On 2013-06-24 09:35, JS wrote:
It should be possible to export(or rather share) types,
mixins, templates, generic unit tests, etc. (shared compile
time
constructs would just be copied to a shared library as they
can't be
On 06/22/2013 11:20 AM, Dicebot wrote:
D has export keyword that I always expected to do exactly this until
have found out it is actually platform-dependent and useless.
It's buggy and useful.
http://d.puremagic.com/issues/show_bug.cgi?id=9816
We should try to strive for -fvisibility=hidden on
On 06/22/2013 06:45 AM, Timothee Cour wrote:
Example2:
auto foo(){return import std.stdio;;}
mixin(foo);
void fun2(){import b;}
void main(){writeln(ok);}
lazy semantic analysis will analyze main, foo but not fun2, which is not
used. foo is analyzed because it is used in a module-level
On 06/24/2013 02:23 AM, Martin Nowak wrote:
exports for anyhow.
for Windows that is
On Sun, Jun 23, 2013 at 5:36 PM, Martin Nowak c...@dawg.eu wrote:
On 06/22/2013 06:45 AM, Timothee Cour wrote:
Example2:
auto foo(){return import std.stdio;;}
mixin(foo);
void fun2(){import b;}
void main(){writeln(ok);}
lazy semantic analysis will analyze main, foo but not
Timothee Cour:
C)
*caveats:*
this works when compiling *binaries*, as we know which symbols
end up in the final binary for compiling libraries
(-shared/-static), it works if we have a way to specify which
symbols are meant to be exported (eg
D has export keyword that I always expected to do exactly this
until have found out it is actually platform-dependent and
useless.
A)
Currently, D suffers from a high degree of interdependency between modules;
when one wants to use a single symbol (say std.traits.isInputRange), we
pull out all of std.traits, which in turn pulls out all of
std.array,std.string, etc. This results in slow compile times (relatively
to the case
17 matches
Mail list logo
