Yeah, well maybe...

[Peter]

I don't like you. Surely I hate you 10 times, no, moreso, but that is not 
the point. ? As the virus lives? It is that, huh. Didn't I fuck up then. 

Deprecated typedef

[Jacob Carlborg]

I know that this might be too late but wouldn't it be possible to defer 
the error message about typedef to later in the compile phase. Making it 
possible to put a typedef in a version statement, something like:


version (D_Version2) {}
else {
typedef int foo;
}

This would allow to both support D1 and D2 in a library without the need 
for string mixins. Obviously the compiler still knows about typedef 
since it can give a proper error message about it so I was hoping it 
wouldn't have to be as the case with the new D2 keywords which do 
require a string mixin if you're supporting both D1 and D2.


--
/Jacob Carlborg

Re: .dmg installer for OSX?

[Jacob Carlborg]

On 2011-12-15 21:53, Sean Kelly wrote:

On Dec 15, 2011, at 4:47 AM, Michel Fortin wrote:


On 2011-12-15 11:33:15 +, Ruslan Mullakhmetov  said:


Probably, Mac App Store instalation would be the best?
I don't know, do Apple policies allow to install a command line utilities via 
Macc App Store, but at least apple itself install OS X Lion and XCode via MAS. 
So, there is technical posibility to install arbitary toolset, not only pure 
GUI.app located in /Application.
What do you say?


Not a chance. The App Store is for applications. And applications are required 
to be self-contained, they are not allowed to use an installer. Apple is 
bypassing its own rules for Xcode.


There is some grey area here though.  TextMate, for example, is an application 
but has a preference that will put a link in /usr/bin to launch it from the 
command-line.  So apps are allowed to configure the environment on request.  
For DMD you'd probably really have to bundle it with an IDE to qualify it as an 
app store item though.




An alpha of TextMate 2 has recently been release and TextMate 2 will not 
be in the App Store because it would need to give up features.


The BBEdit editor is available on the App Store but:

"...BBEdit does not support automatic installation and updating of the 
bbedit, bbfind, and bbdiff command-line tools..."


--
/Jacob Carlborg

Re: What can be done to reduce executable size?

[Jonathan M Davis]

On Thursday, December 15, 2011 21:40:57 Andrei Alexandrescu wrote:
> On 12/10/11 9:39 AM, Bane wrote:
> > Short term and long term suggestions ? Anything we can do ? I heard it
> > is some problem with linking dead code?
> > 
> > 
> > 
> > import std.stdio;
> > int main(){
> > writefln("Hello Bloat!");
> > return 0;
> > }
> > 
> > dmd -release -O hello.d
> > 
> > On Windows:
> > v1.071 = 339 Kb
> > v2.056 = 1017 Kb
> > 
> > It looks very ugly and might distract some people.
> 
> In fact there was a low-hanging fruit, and I'm sure there are some more.
> This diff reduces the size of hello, world (compiled with -O -release
> -inline and after strip) from 700KB to 220 KB:
> 
> https://github.com/D-Programming-Language/phobos/commit/b7f42ec925fb1d64564d
> 48ea419e201bfc65ed53
> 
> Right now an executable starts at around 218KB, which includes druntime
> (gc, type info, the works). Importing std.stdio and using writeln() only
> adds a couple of KBs.

Simply making it so that std.file is only imported in std.stdio with 
version(unittest) cut off _that_ much?

- Jonathan M Davis

D branding (was Re: D1 to be discontinued on December 31, 2012)

[Gour]

On Thu, 15 Dec 2011 18:18:24 -0600
Andrei Alexandrescu  wrote:

> We need to contract D's brand. People who consider D need to
> contemplate one crisp and coherent offer.

Mine would be to write general-purpose multi-platform GUI application,
but it seems it's dependant on other offerings.

Moreover, I'll help/work on some GUI bindings and build-tool support
(either/both pushing Cmake & premake upstream).


Sincerely,
Gour


-- 
But a person free from all attachment and aversion and able 
to control his senses through regulative principles of 
freedom can obtain the complete mercy of the Lord.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature

Re: D1 to be discontinued on December 31, 2012

[Gour]

On Thu, 15 Dec 2011 17:52:48 -0600
Andrei Alexandrescu  wrote:

> It is reasonable to expect that people with an interest in D have had
> all chances to see it and sufficient channels to chime in.

Sure. It is unreasonable that someone should knock on every D1 user out
here, asking about their opinion.

The project is open-source, there are no paying customers buying D1
support, so pls. move and spare (electronic) ink.

I'm not favoring democracy, but competency...Let those who know better
decide and let me do that what I can the best.


Sincerely,
Gour


-- 
Never was there a time when I did not exist, 
nor you, nor all these kings; nor in the future 
shall any of us cease to be.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature

Re: D1 to be discontinued on December 31, 2012

[Gour]

On Thu, 15 Dec 2011 16:42:26 -0800
Walter Bright  wrote:

> Right. And we make D2 work or we fail completely.

Please, make it work!



Sincerely,
Gour


-- 
As a strong wind sweeps away a boat on the water, 
even one of the roaming senses on which the mind 
focuses can carry away a man's intelligence.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature

Re: What can be done to reduce executable size?

[Andrei Alexandrescu]

On 12/10/11 9:39 AM, Bane wrote:

Short term and long term suggestions ? Anything we can do ? I heard it
is some problem with linking dead code?



import std.stdio;
int main(){
writefln("Hello Bloat!");
return 0;
}

dmd -release -O hello.d

On Windows:
v1.071 = 339 Kb
v2.056 = 1017 Kb

It looks very ugly and might distract some people.


In fact there was a low-hanging fruit, and I'm sure there are some more. 
This diff reduces the size of hello, world (compiled with -O -release 
-inline and after strip) from 700KB to 220 KB:


https://github.com/D-Programming-Language/phobos/commit/b7f42ec925fb1d64564d48ea419e201bfc65ed53

Right now an executable starts at around 218KB, which includes druntime 
(gc, type info, the works). Importing std.stdio and using writeln() only 
adds a couple of KBs.



Andrei

auto testing (was: Bug Prediction at Google)

[Brad Roberts]

On Thu, 15 Dec 2011, Andrew Wiley wrote:

> On Thu, Dec 15, 2011 at 6:04 PM, Robert Clipsham
>  wrote:
> > I really think github needs built in review tools (more advanced than just
> > pull requests) to allow things like the auto-tester to be run, or algorithms
> > like this to be used for manual review and so on.
> 
> Well, Github does have an API to allow that sort of thing to happen.
> In theory, a bot could examine a pull request, merge it and run tests,
> and post back the results.

I'm 90% done with adding pull testing to the existing auto-tester fleet.  
It's based on the work that Daniel did.

The basic overview:

server:

  every 10 minutes, check github for changes to pull requests
(if they had notifications for pull changes, I'd use it instead)

  every time a trunk commit notification is received, check github for
changes to pull requests


client:

  forever {
check for trunk build
if yes { build trunk; continue }
check for pull build
if yes { build pull; continue }
sleep 1m
  }


Left to do:

  1) deploy changes to the tester hosts (it's on 2 already)

  2) finish the ui

  3) trigger pull rebuilds when trunk is updated

  4) add back in support for related pull requests (ie, two pulls that
 separately fail but together succeed)

  5) consider adding updating the pull request on github with tester 
 results.  This one needs to be very carefully done to not spam the 
 report every time a build fails or succeeds.

  6) update the auto-tester grease monkey script to integrate the pull 
 tester results with github's ui.

I'll hopefully finish 1 and 2 tonight.  I can do 3 manually until it's 
automated.  I'm not sure about the ordering of 4-6.  They're nice to haves 
rather than must haves.

All these extra builds are going to cost a lot of time.  There's about 100 
open pull requests right now.  The fastest runs are on the order of 10 
minutes.  That's 6 per hour or roughly 17 hours.  The slowest are closer 
to an hour.  So, obviously there's some growing pains to deal with.  I'll 
probably add a way for github committers to prioritize pull requests so 
they build first.

Luckily this stuff is trivial to throw hardware at.. it's super 
parallelizeable.  Also the hardware I have for those long runs is super 
old.  I think the freebsd/32 box is p4 era box.  The win/32 is my asus eee 
atom based netbook.

If anyone wants to volunteer build hardware, particularly for the 
non-linux platforms, please contact me via email (let's not clutter up the 
newsgroup with that chatter).

Requirements:
  I need to be able to access it remotely.

  It needs to be have reliable connectivity (bandwidth is pretty much a 
  non-issue.. it doesn't need much at all).

  It needs to be hardware you're willing to have hammered fairly hard at 
  random times.

I'll almost certainly write some code during the holiday to fire up and 
use ec2 nodes for windows and linux builds.  With the application of just 
a little money, all of those runs could be done fully parallel.. which 
would just be sweet to see.  Ok, I admit it.. I love working at amazon on 
ec2.. and I'm happy to finally have a project that could actually use it.

Later,
Brad

Re: Any plans to make it possible to call C++ functions that reside in a namespace?

[Walter Bright]

On 12/14/2011 1:47 PM, Dejan Lekic wrote:

As subject says. I am pretty much happy with the current C++ support. The
only thing I need is to be able to call functions from namespace(s). Any
plans to add this feature?


I hadn't planned to, but it's a good idea. I suggest adding it as an enhancement 
request on bugzilla.

Re: D1 to be discontinued on December 31, 2012

[Walter Bright]

On 12/15/2011 4:18 PM, Andrei Alexandrescu wrote:

People who consider D need to contemplate one
crisp and coherent offer.


Right. And we make D2 work or we fail completely.

Re: Bug Prediction at Google

[Andrew Wiley]

On Thu, Dec 15, 2011 at 6:04 PM, Robert Clipsham
 wrote:
> I just read this pretty interesting article on the Google Engineering Tools
> website, thought it might interest some people here:
>
> http://google-engtools.blogspot.com/2011/12/bug-prediction-at-google.html
>
> ( http://goo.gl/2O6YT <= a short link in case the above one gets wrapped)
>
> It basically describes a new process in place at Google whereby each file
> within a project is assigned a rating saying how likely the given file is to
> have a bug in it compared to everything else. This can be used by code
> reviewers so they can take extra care when reviewing certain changes.
>
> I really think github needs built in review tools (more advanced than just
> pull requests) to allow things like the auto-tester to be run, or algorithms
> like this to be used for manual review and so on.
>

Well, Github does have an API to allow that sort of thing to happen.
In theory, a bot could examine a pull request, merge it and run tests,
and post back the results.

Re: D1 to be discontinued on December 31, 2012

[Andrei Alexandrescu]

On 12/15/11 11:44 AM, Mattbeui wrote:

I am C programmer, but I had already did a little OO programming in
Python and Delphi. So after look for a growth in my studies and enter
definetly in OO programming, I found a video on youtube from Andrei
Alexandrescu. And I got hooked since then.

But that was just the beginning, until I discover that there are D1 and
D2, tango and phobos Et cetera. Many options to get lost.

I've had a great help from the d-guys at #d channel on IRC. But
anyway... I think choosing one language is the right choice for
everyone, mainly for the new users. And you need simplify the entry of
the new users.

In some cases you need sacrifice something. For example, I love work on
Visual Studio 7.0 (The old one without framework or ..net), but they
(irc guys) told me that I need move on to the free version of VS 2010 to
use VisualD. Yes for me as new member this is a small sacrifice, but for
you, the D1 guys, you should think for the benefits of D2 for all
community, and not for what you will lost but what you will get from now
on.

PS: Sorry my bad english.

Matt.


I quote all this post because I so strongly agree with it.

Lately Walter and I have been increasingly thinking about the steps we 
need to take to improve adoption of D. Things have improved dramatically 
on the technical front, and we think going forward implementation 
quality and library coverage must remain the most important focus points.


However, without a comprehensive PR strategy we risk at being all 
dressed up and nowhere to go. It's particularly important to work on it 
now, not later, because such things take months and years to catch on.


The reason for the recent move, which Matt pointed very well, has to do 
with brand specialization. Years ago I've read a book recommended by a 
successful entrepreneur: "The 22 immutable laws of branding". By utter 
coincidence Walter mentioned he's reading it right now (which gives a 
good insight into our preoccupation).


That book has quite a few interesting and somewhat non-intuitive notions 
(see e.g. a slide deck at 
http://www.slideshare.net/sjhus/22-immutable-laws-of-branding). Among 
these was "the law of contraction", the idea that a brand gets stronger 
as you narrow its focus. The book gives good examples: Starbucks 
specializing on coffee when one could find coffee virtually on every 
block in Seattle; FedEx competing with subsidized postal office but 
specializing in overnight delivery; Colgate winning the "toothpaste war" 
of the 70s with fewer, not more, offerings than Procter & Gamble; and more.


We need to contract D's brand. People who consider D need to contemplate 
one crisp and coherent offer.



Andrei

Re: D1 to be discontinued on December 31, 2012

[Hans Uhlig]

On 12/14/2011 1:16 AM, Jacob Carlborg wrote:

On 2011-12-14 10:08, Long Chang wrote:

I use dwt and tango for some project recent.


Cool to here that's someone is using DWT.


Before dwt2 and minid and other cool project is ready for d2, I will
still need D1.


Exactly and see, the D1 users start to pop up.


There have been 3.




On 13 December 2011 21:52, Don wrote:

On 10.12.2011 22:19, Andrei Alexandrescu wrote:


In order to increase focus and unity in the language, we are
discontinuing support for D1 on December 31, 2012. That's more than one
year away, which gives enough time to D1 users to migrate libraries and
applications to D2.



I thought we had moved away from these kinds of unilateral decisions.
I strongly oppose this decision. In particlar, I find the lack of
community
consulatation deplorable.

Bug Prediction at Google

[Robert Clipsham]

I just read this pretty interesting article on the Google Engineering 
Tools website, thought it might interest some people here:


http://google-engtools.blogspot.com/2011/12/bug-prediction-at-google.html

( http://goo.gl/2O6YT <= a short link in case the above one gets wrapped)

It basically describes a new process in place at Google whereby each 
file within a project is assigned a rating saying how likely the given 
file is to have a bug in it compared to everything else. This can be 
used by code reviewers so they can take extra care when reviewing 
certain changes.


I really think github needs built in review tools (more advanced than 
just pull requests) to allow things like the auto-tester to be run, or 
algorithms like this to be used for manual review and so on.


--
Robert
http://octarineparrot.com/

Re: D1 to be discontinued on December 31, 2012

[Andrei Alexandrescu]

On 12/15/11 3:50 PM, Bane wrote:

Anyways, D "community" can't really speak its mind here. Here it is
5-10 regular users that are persistent enough to dig trough loads of
mixed information, some important, most of it not, on this NG. Most
users have no time to check this place every other day so they can
say 'please, don't discontinue D1, I am using it' or anything like
that when important matter arises.

Sending question to users is more correct way to obtain opinions than
to wait people to stumble on this thread here. It won't happen for
most D users. Ever.


This is the case with all language communities I've interacted with 
(C++, Perl, TeX). For all its hoards of users, C++ has a small but 
extremely influential community hanging out on two Usenet newsgroups: 
comp.lang.c++.moderated and comp.std.c++. Needless to say, both are free 
and open for anyone to join. But these groups are the closest it gets to 
pure meritocracy - people could earn huge amounts of clout simply by 
making good quality posts. In fact my first ever invited conference talk 
was solely on account of my newsgroup contributions.


The traffic on either of these groups is comparable to that on the D 
newsgroups. There are few official "well, let's ask the community" polls 
but by and large the trends reflected by these groups are fairly 
influential. I'm not saying that's good or bad, I'm just saying it is, 
and also that D's community dynamics is no different in that regard from 
at least a few others.


Regarding this particular announcement, there's no need to dig for it. I 
sent it not only to this group, but also to D_programming's 805 Twitter 
followers, my 1215 Twitter followers, my 3661 Facebook subscribers, 
reddit, and by extension to D's homepage and my own homepage. It is 
reasonable to expect that people with an interest in D have had all 
chances to see it and sufficient channels to chime in.


True, the announcement was a done deal and not a question. I very 
strongly think it didn't need to be a question, for reasons I expanded 
upon in other posts in this thread.



Thanks,

Andrei

Dot syntax to access static variables of functions

[bearophile]

In some cases I use a global variable only from a small small number of 
functions, like foo() and main() here:


import std.stdio;
__gshared static int x = 10;
void foo() {
// uses x
writeln("foo");
}
void main() {
auto fptr = &foo;
fptr();
auto y = x; // uses x
}


To write more tidy code in some of those situations I'd like a dot syntax to 
access static variables of a function:

void foo() {
__gshared static int x = 10;
// uses x
writeln("foo");
}
void main() {
auto fptr = &foo;
fptr();
auto y = foo.x; // uses foo.x
}



Its semantics is similar to just a struct with a static field and a static 
opCall:


import std.stdio;
struct Foo {
__gshared static int x = 10;
static void opCall() {
// uses x
writeln("foo");
}
}
void main() {
auto y = Foo.x;
auto fptr = &Foo.opCall;
fptr();
}


The advantage of using the dot syntax is that I don't need to modify the 
function code and turn it into a struct, with uppercase name, etc.

Bye,
bearophile

Re: .dmg installer for OSX?

[Michel Fortin]

On 2011-12-15 20:53:23 +, Sean Kelly  said:


There is some grey area here though.  TextMate, for example, is an
application but has a preference that will put a link in /usr/bin to
launch it from the command-line.  So apps are allowed to configure the
environment on request.  For DMD you'd probably really have to bundle it
with an IDE to qualify it as an app store item though.


But TextMate is not available on the Mac App Store. It probably 
wouldn't be allowed in the store if the version submitted to Apple had 
this feature.


To give you an idea of the mindset, Apple is currently trying to force 
Mac developers to sandbox their apps (similar to how apps are isolated 
on iOS) as a requirement to be available on the Mac App Store. 
Currently this requirement isn't enforced: it was scheduled to be 
enforced starting in november but this got pushed to march 2012… we'll 
see how well it goes. No doubt many apps will go out of the store when 
this becomes a requirement and they don't relax those rules.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: 64-bit DMD for windows?

[Mehrdad]

On 12/15/2011 3:20 PM, Trass3r wrote:
dealbreaker - i'd love to use D for my scientific programming, but my 
datasets often reach several GB...


my computer has 16GB and i intend to make use of them.


Scientific programming on Windoze? You can't be serious :P


lol, that's not even the only issue.

32-bit programs can't show 64-bit dialogs. So "Open this file..." 
actually shows the SysWOW64 folder instead of the System32 folder, and 
there's _no way_ to bypass this unless you build a 64-bit app.

Re: 64-bit DMD for windows?

[Trass3r]

dealbreaker - i'd love to use D for my scientific programming, but my  
datasets often reach several GB...


my computer has 16GB and i intend to make use of them.


Scientific programming on Windoze? You can't be serious :P

Re: Java Backend?

[maarten van damme]

How far did you got? if you have something you should post it on github.
I think android could be one of those places where D really shines.
You have the speed of native code without added complexity and memory
management where needed. It's imho superiour to java in any way.

Re: D1 to be discontinued on December 31, 2012

[Bane]

> Forum/Registered Users, Unless you are regularly cleaning out inactives 
> this number means nothing about a current userbase.

Purpose is not evaluating size of community but to be able to keep in touch 
with it.

> 
> pool/email pool? Are people emailing that I havent heard of. I am on a 
> quite a few mailing lists I cant remove myself from due to lost 
> passwords, or just a lack of caring.

Any decent forum has unsubscribe link in each email it sends. Password is not 
required.

> Alot of times I just feed them to 
> my spam filter and they stop showing up anymore. I am still a registered 
> user though. This number means nothing.

Interesting. Answering on email pool would be too much effort. Writing comment 
on newsgroup isn't.

Anyways, D "community" can't really speak its mind here. Here it is 5-10 
regular users that are persistent enough to dig trough loads of mixed 
information, some important, most of it not, on this NG. Most users have no 
time to check this place every other day so they can say 'please, don't 
discontinue D1, I am using it' or anything like that when important matter 
arises.

Sending question to users is more correct way to obtain opinions than to wait 
people to stumble on this thread here. It won't happen for most D users. Ever.

Re: 64-bit DMD for windows?

[F i L]

On Thursday, 15 December 2011 at 21:05:05 UTC, captaindet wrote:

On 2011-12-15 04:47, torhu wrote:

On 14.12.2011 12:54, dmd.20.browse...@xoxy.net wrote:


Hi,

Is there a 64-bit version of DMD for windows?

The download page offers only an x86 version. Or am I reading 
too

much into that?

Cheers, buk



There's not much you would need a 64-bit compiler for on 
Windows.

What are you going to use it for?


now what is this for a strange comment? you need 64bit for 
windows for the same reasons than for any other platform: 
accessing loads of mem. yes, for some this is really important! 
for me it is actually a dealbreaker - i'd love to use D for my 
scientific programming, but my datasets often reach several 
GB...


my computer has 16GB and i intend to make use of them.

det


Use Linux.. it's better for your health ;p

jk, I'm eagerly awaiting a Win64 DMD as well.

Re: 64-bit DMD for windows?

[Jonathan M Davis]

On Wednesday, December 14, 2011 11:54:41 dmd.20.browse...@xoxy.net wrote:
> Hi,
> 
> Is there a 64-bit version of DMD for windows?
> 
> The download page offers only an x86 version. Or am I reading too much
> into that?

The linker on Windows is currently only 32-bit, so the rest of the toolchain 
is 32-bit only. Linux was the first to get 64-bit support, because it was by 
far the easiest (since it uses gcc rather than dmc and optlink). FreeBSD and 
now Mac OS X have it as well. Windows will get it eventually, but it's a lot 
more work, so it could be a while.

- Jonathan M Davis

Re: 64-bit DMD for windows?

[captaindet]

On 2011-12-15 04:47, torhu wrote:

On 14.12.2011 12:54, dmd.20.browse...@xoxy.net wrote:


Hi,

Is there a 64-bit version of DMD for windows?

The download page offers only an x86 version. Or am I reading too
much into that?

Cheers, buk



There's not much you would need a 64-bit compiler for on Windows.
What are you going to use it for?


now what is this for a strange comment? you need 64bit for windows for the same 
reasons than for any other platform: accessing loads of mem. yes, for some this 
is really important! for me it is actually a dealbreaker - i'd love to use D 
for my scientific programming, but my datasets often reach several GB...

my computer has 16GB and i intend to make use of them.

det

Re: D1 to be discontinued on December 31, 2012

[Hans Uhlig]

On 12/13/2011 1:59 PM, Bane wrote:

Walter Bright Wrote:


On 12/13/2011 12:52 PM, Jacob Carlborg wrote:

On 2011-12-13 19:55, Walter Bright wrote:

On 12/13/2011 9:47 AM, Jacob Carlborg wrote:

If I recall correctly Walter has said he will continue to support D1
as long as
there are users.


Yes, I did say that. For some time now, I've been releasing D1 betas and
have not received any response to them. I haven't noticed new bug
reports for D1. I haven't seen posts here about D1. I announced the D1
1.072 release a few days ago, and there wasn't a single comment on it.


Yeah, I noticed that. I'm still using D1. I usually don't have time to try all
beta versions or releases for that matter. Your making solid improvements in
every release and I'm grateful for that. I apologize if I haven't shown any
gratitude.



It's not really about gratitude, but just letting me know that there's a point
to doing those releases.




  Forum, registered users, pool/email pool = feedback :)




Forum/Registered Users, Unless you are regularly cleaning out inactives 
this number means nothing about a current userbase.


pool/email pool? Are people emailing that I havent heard of. I am on a 
quite a few mailing lists I cant remove myself from due to lost 
passwords, or just a lack of caring. Alot of times I just feed them to 
my spam filter and they stop showing up anymore. I am still a registered 
user though. This number means nothing.

Re: .dmg installer for OSX?

[Sean Kelly]

On Dec 15, 2011, at 4:47 AM, Michel Fortin wrote:

> On 2011-12-15 11:33:15 +, Ruslan Mullakhmetov  said:
> 
>> Probably, Mac App Store instalation would be the best?
>> I don't know, do Apple policies allow to install a command line utilities 
>> via Macc App Store, but at least apple itself install OS X Lion and XCode 
>> via MAS. So, there is technical posibility to install arbitary toolset, not 
>> only pure GUI.app located in /Application.
>> What do you say?
> 
> Not a chance. The App Store is for applications. And applications are 
> required to be self-contained, they are not allowed to use an installer. 
> Apple is bypassing its own rules for Xcode.

There is some grey area here though.  TextMate, for example, is an application 
but has a preference that will put a link in /usr/bin to launch it from the 
command-line.  So apps are allowed to configure the environment on request.  
For DMD you'd probably really have to bundle it with an IDE to qualify it as an 
app store item though.

Re: D1 to be discontinued on December 31, 2012

[Jacob Carlborg]

On 2011-12-15 20:41, Walter Bright wrote:

On 12/15/2011 9:49 AM, Robert Clipsham wrote:

* Do it all in one go, and DO NOT GET DISTRACTED. The moment you start
trying to
clean up code as well as finish porting it you introduce lots of issues


I've done many projects that translated code from one language to
another, some were pretty large. The One Big Most Important Rule is:


 DO NOT REFACTOR/ENHANCE/IMPROVE/FIX/CLEANUP THE CODE WHILE
TRANSLATING 


I know how tempting it is. It's incredibly tempting. It's a huge mistake.

The method that works is to turn your brain off, and simply translate.
Strive for a 1:1 correspondence between the original code and the
translated code. Do not divert from this until after your translation is
done, and it behaves identically to the original.

The reason is that the translated version inevitably will not behave
like the original. A lot of things will be broken. If you did a 1:1
translation, you can instrument both, find where the translation
diverges, and fix it in a fairly quick and straightforward manner. If
you changed the way it is organized or works, then you have no idea if
it is a translation error or your changes broke it, and you have a much,
much harder time fixing it.


Having ported the Mac OS X version of SWT from Java to D (and a couple 
of other code bases) I completely agree with everything above. You just 
have to turn your mind off and work like a machine when porting. It's 
extremely tempting do some small fixes here and there but restrain 
yourself, you'll thank yourself in the end.


--
/Jacob Carlborg

Re: DMD 1.072 and DMD 2.057 64bit on Mac OS X

[Walter Bright]

On 12/15/2011 4:40 AM, Michel Fortin wrote:

It's one thing to ask developers to use 64-bit machines for development, it's
another to say to developers they can't target 32-bit users if they choose to
use DMD. Even Apple ships everything with dual architecture binaries these days,
and some of Apple's apps also keep PowerPC support, iTunes for instance.


I think it's fair to continue with 32 bit dev support for now.



And also iOS is 32-bit.


I didn't know that.

Re: D1 to be discontinued on December 31, 2012

[Walter Bright]

On 12/15/2011 9:49 AM, Robert Clipsham wrote:

* Do it all in one go, and DO NOT GET DISTRACTED. The moment you start trying to
clean up code as well as finish porting it you introduce lots of issues


I've done many projects that translated code from one language to another, some 
were pretty large. The One Big Most Important Rule is:



 DO NOT REFACTOR/ENHANCE/IMPROVE/FIX/CLEANUP THE CODE WHILE TRANSLATING 


I know how tempting it is. It's incredibly tempting. It's a huge mistake.

The method that works is to turn your brain off, and simply translate. Strive 
for a 1:1 correspondence between the original code and the translated code. Do 
not divert from this until after your translation is done, and it behaves 
identically to the original.


The reason is that the translated version inevitably will not behave like the 
original. A lot of things will be broken. If you did a 1:1 translation, you can 
instrument both, find where the translation diverges, and fix it in a fairly 
quick and straightforward manner. If you changed the way it is organized or 
works, then you have no idea if it is a translation error or your changes broke 
it, and you have a much, much harder time fixing it.

Re: D1 to be discontinued on December 31, 2012

[Walter Bright]

On 12/15/2011 6:33 AM, bearophile wrote:

I should add that the XMM register support is for 64 bit targets, and also
the register allocator will enregister float and double variables in XMM
registers.<

Will DMD use 8 XMM registers in 32 bit code too?


We'll see, but it's a harder problem.


Putting the compiler in D would make it difficult to integrate the D front
end into the C/C++ back ends of gcc and llvm.<


Writing the reference front-end in D has some advantages: - Other people have
lot of C/C++ code; if they want to use D they will probably want to interface
C/C++ with D code. So writing the compiler front-end in D is a way to eat
some of the D dog food, and see/test how much good such interfacing is, and
eventually it's a push to improve it.


D is designed to use C libraries. It is not designed to be a library accessible 
from C - D wants to be in charge of the startup.



If some parts of the D2 language are badly designed or they
lead to low performance (like fixed sized array assignment) this is a good
way to spot such problems and a way to push to fix them.


That isn't the issue.

Re: Export and Protected Scoping in Dynamic Libraries

[deadalnix]

Le 15/12/2011 09:52, Jonathan M Davis a écrit :

On Thursday, December 15, 2011 09:32:37 deadalnix wrote:

The same goes for private virtual methods actually. They cannot be
called, but they can be reimplemented in subclasses.

If you put that detail asside, this is a neat idea. I'd love to see that
in D.


http://d.puremagic.com/issues/show_bug.cgi?id=4542


This is not the same problem, but close. I think both are important to 
solve. I do agree with your comments on this bugs.

Re: DMD 1.072 and DMD 2.057 64bit on Mac OS X

[Alex Rønne Petersen]

On 15-12-2011 18:04, Somedude wrote:

Le 14/12/2011 11:07, Alex Rønne Petersen a écrit :


No point maintaining something that won't be used. I would also imagine
that it can't be long before Windows stops supporting 32-bit.

- Alex


You imagine wrong. A large percentage of Windows users are still on Win
XP 32 bits (like me).


Amount of users has nothing to do with whether Microsoft will continue 
to support it. Microsoft has well-defined lifecycles for support on 
their products. I'm not sure what you being on a 32-bit OS from 2001 has 
to do with my imagination of the future in 2011. :)


There are many reasons a company like Microsoft would want to let 32-bit 
x86 die; only having to maintain one platform being one of such. It is 
undeniable that the trend is going towards 64-bit (and this is a Good 
Thing, obviously).


- Alex

Re: D1 to be discontinued on December 31, 2012

[Andrej Mitrovic]

Also, port from the smallest module to the largest, OR the ones that
have the least dependencies towards those that have more.

Basically, you want to be able to unittest your modules as soon as you
port them, so the modules that import these newly tested modules will
call into functions that you know will work.

Re: D1 to be discontinued on December 31, 2012

[Robert Clipsham]

On 15/12/2011 00:32, Jakob Bornecrantz wrote:

On Wednesday, 14 December 2011 at 18:55:23 UTC, Walter Bright wrote:

On 12/14/2011 10:28 AM, Jakob Bornecrantz wrote:

I don't know where the D1 community is, or even if it exists anymore.


I'm here!


Thanks for speaking up.


np.


Anyways couldn't you just do releases less often or only when there
is something to release? Like every other D2 release to
lessen the burden?


Can I turn that around and ask what issues there are with migrating
your code base to D2?


In short it can be answered with the questions "Can you
guarantee it work?" and "Can I justify the amount of work I have
to put in for the gain?", the thing is I have a had a lot of
problems with D1 toolchain, I have fixed or worked around these
issues and I'm wondering if I have to work around those or other
again. I am currently supporting 3 platforms (Mac, Linux &
Windows), so that factors in as well (me having fixed some
issues on Mac for D1).

My current code base is 40Kloc's where about 8Kloc of those
are library bindings, on top of that it also includes a couple
of C projects sources (expat, lua and some other misc
libraries). So I would have to convert all that code to D2 and
also fix any issues that might arise from that conversion.
That said I think that it would mostly running the code
through dmd2 and just fix any cases where it complains. But it
probably wouldn't be a trivial amount of work.


Having migrated a far smaller codebase from D1/Tango to D2/Phobos, here 
are some tips/things I encountered:


* Most of the effort in porting was dealing with the lack of features in 
phobos, this sounds like it wouldn't be an issue for you though since 
you're using D1/Phobos.
* Make sure all your code is thoroughly unittested - my code had a 
reasonable amount of unittests, but I was still discovering subtle bugs 
months later that were caused by the transition
* Do it all in one go, and DO NOT GET DISTRACTED. The moment you start 
trying to clean up code as well as finish porting it you introduce lots 
of issues
* Some things will inevitably have to change to get them working... 
Don't make the changes while you're porting, just drop in a /* TODO: 
 */ comment and come back to it later. 
Get it compiling first, then go through and sort things out later.


Hope this helps, should you decide to transition :)

--
Robert
http://octarineparrot.com/

Re: D1 to be discontinued on December 31, 2012

[Mattbeui]

I am C programmer, but I had already did a little OO programming 
in Python and Delphi. So after look for a growth in my studies 
and enter definetly in OO programming, I found a  video on 
youtube from Andrei Alexandrescu. And I got hooked since then.


But that was just the beginning, until I discover that there are 
D1 and D2, tango and phobos Et cetera. Many options to get lost.


I've had a great help from the d-guys at #d channel on IRC. But 
anyway... I think choosing one language is the right choice for 
everyone, mainly for the new users. And you need simplify the 
entry of the new users.


In some cases you need sacrifice something. For example, I love 
work on Visual Studio 7.0 (The old one without framework or 
.net), but they (irc guys) told me that I need move on to the 
free version of VS 2010 to use VisualD. Yes for me as new member 
this is a small sacrifice, but for you, the D1 guys, you should 
think for the benefits of D2 for all community, and not for what 
you will lost but what you will get from now on.


PS: Sorry my bad english.

Matt.

Re: SDC & ddmd

[Timon Gehr]

On 12/15/2011 05:47 PM, Don wrote:

On 10.12.2011 12:17, Timon Gehr wrote:

On 12/10/2011 10:54 AM, Bernard Helyer wrote:

On Saturday, 10 December 2011 at 09:47:14 UTC, Timon Gehr wrote:

On 12/10/2011 10:40 AM, Bernard Helyer wrote:

We intend to be compatible with DMD to a point. Where we are not, will
be through omission. Off the top of my head:
[...]
*D's forward reference and module order bugs will not be supported.

[snip.]



How is that an 'omission'?


Just my lame attempt at humour. :P


Should have thought of that. =)
Do you already have a working design? I think what Don suggested
(process static if and mixins in sequence, everything else on by need
basis) does not work in the general case because you can have static if
and mixin declaration dependencies across module import cycles.


Do you have an example? Would be good to discuss.


OK:

---
module a;
import b;

static if(!is(typeof(be))){
enum not_be=1;
pragma(msg,"not to be!");
}
---
---
module b;
import a;

static if(!is(typeof(not_be))){
enum be=1;
pragma(msg,"to be!");
}
---
---
$ dmd a b -o-
to be!
$ dmd b a -o-
not to be!
---


The compiler should reject it. There is no correct way to compile it.

Re: DMD 1.072 and DMD 2.057 64bit on Mac OS X

[Somedude]

Le 14/12/2011 11:07, Alex Rønne Petersen a écrit :
> 
> No point maintaining something that won't be used. I would also imagine
> that it can't be long before Windows stops supporting 32-bit.
> 
> - Alex

You imagine wrong. A large percentage of Windows users are still on Win
XP 32 bits (like me).

Re: SDC & ddmd

[Don]

On 10.12.2011 12:17, Timon Gehr wrote:

On 12/10/2011 10:54 AM, Bernard Helyer wrote:

On Saturday, 10 December 2011 at 09:47:14 UTC, Timon Gehr wrote:

On 12/10/2011 10:40 AM, Bernard Helyer wrote:

We intend to be compatible with DMD to a point. Where we are not, will
be through omission. Off the top of my head:
[...]
*D's forward reference and module order bugs will not be supported.

[snip.]



How is that an 'omission'?


Just my lame attempt at humour. :P


Should have thought of that. =)
Do you already have a working design? I think what Don suggested
(process static if and mixins in sequence, everything else on by need
basis) does not work in the general case because you can have static if
and mixin declaration dependencies across module import cycles.


Do you have an example? Would be good to discuss.

Re: D1 to be discontinued on December 31, 2012

[Timon Gehr]

On 12/15/2011 04:37 PM, bearophile wrote:

Timon Gehr:


Fixed array assignment certainly won't cause any trouble.<


I don't know about the D front end, but those arrays have caused performance 
problems in my D2 code. Later I have taken more care, assigning items one after 
the other, writing:

int[3] a = void;
a[0] = ...
a[1] = ...
a[2] = ...

Instead of:
int[3] a = [..., ..., ...];



I usually use:

static _a = [1, 2, 3];
int[3] a = _a;

This certainly should be fixed, what I wanted to say is, there are not 
many fixed size arrays in a compiler front-end.





An issue is that 32 bit x86 architectures do not necessarily provide any SSE 
support.


Most PCs have SSE2 support. Lot of PCs today have SSE3 too.



GCC will not use XMM registers by default either.


LLVM-GCC (and probably Clang too) use SSE registers on default on 32 bit 
Windows. And with modern GCC-MinGW I usually compile code with those registers 
too on 32 bit Windows, using the right compiler switches.

Re: D1 to be discontinued on December 31, 2012

[bearophile]

Timon Gehr:

> Fixed array assignment certainly won't cause any trouble.<

I don't know about the D front end, but those arrays have caused performance 
problems in my D2 code. Later I have taken more care, assigning items one after 
the other, writing:

int[3] a = void;
a[0] = ...
a[1] = ...
a[2] = ...

Instead of:
int[3] a = [..., ..., ...];


> An issue is that 32 bit x86 architectures do not necessarily provide any SSE 
> support.

Most PCs have SSE2 support. Lot of PCs today have SSE3 too.


> GCC will not use XMM registers by default either.

LLVM-GCC (and probably Clang too) use SSE registers on default on 32 bit 
Windows. And with modern GCC-MinGW I usually compile code with those registers 
too on 32 bit Windows, using the right compiler switches.

Bye,
bearophile

Re: D1 to be discontinued on December 31, 2012

[Gour]

On Thu, 15 Dec 2011 10:37:58 +0100
Stephan  wrote:

> Why is it not ? I am using it regularly. Ok it is broken now since
> the new release... but b4

How are you, in general, satisfied with DWT2?

How it compares with qt/wx/gtk+ ?


Sincerely,
Gour


-- 
As the embodied soul continuously passes, in this body, 
from boyhood to youth to old age, the soul similarly passes 
into another body at death. A sober person is not bewildered 
by such a change.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature

Re: D1 to be discontinued on December 31, 2012

[Timon Gehr]

On 12/15/2011 03:33 PM, bearophile wrote:

Regarding some things said by Walter in this Reddit thread:
http://www.reddit.com/r/programming/comments/nbndg/fedora_17_will_include_support_for_the_d/


I should add that the XMM register support is for 64 bit targets, and also the 
register allocator will enregister float and double variables in XMM registers.<


Will DMD use 8 XMM registers in 32 bit code too?



An issue is that 32 bit x86 architectures do not necessarily provide any 
SSE support. GCC will not use XMM registers by default either.

Re: D1 to be discontinued on December 31, 2012

[Timon Gehr]

On 12/15/2011 03:33 PM, bearophile wrote:

Regarding some things said by Walter in this Reddit thread:
http://www.reddit.com/r/programming/comments/nbndg/fedora_17_will_include_support_for_the_d/


I should add that the XMM register support is for 64 bit targets, and also the 
register allocator will enregister float and double variables in XMM registers.<


Will DMD use 8 XMM registers in 32 bit code too?



Putting the compiler in D would make it difficult to integrate the D front end 
into the C/C++ back ends of gcc and llvm.<


Writing the reference front-end in D has some advantages:
- Other people have lot of C/C++ code; if they want to use D they will probably 
want to interface C/C++ with D code. So writing the compiler front-end in D is 
a way to eat some of the D dog food, and see/test how much good such 
interfacing is, and eventually it's a push to improve it.


I agree.


- It's a way to eat some D dog food in general, because a compiler front-end is 
a medium-sized project that requires some performance. If some parts of the D2 
language are badly designed or they lead to low performance (like fixed sized 
array assignment) this is a good way to spot such problems and a way to push to 
fix them.


The only performance problem is the GC, and that could just be turned 
off (as DMD handles it ;)). Fixed array assignment certainly won't cause 
any trouble.



- I have now understood that if you want a safe&  reliable language you need a 
reliable compiler too. Because a very safe and very well designed language produces 
buggy and unsafe programs if the compiler is buggy. Writing the front-end in D 
allows to avoid several compiler bugs from the beginning.
- Writing the front-end in D is probably going to speed up a bit the 
development of the D compiler, with more expressiveness, less code, more 
readable code, less bug-prone code, etc.


Exactly. But that front-end needs to be written from scratch.



Bye,
bearophile

Re: D1 to be discontinued on December 31, 2012

[bearophile]

Regarding some things said by Walter in this Reddit thread:
http://www.reddit.com/r/programming/comments/nbndg/fedora_17_will_include_support_for_the_d/

>I should add that the XMM register support is for 64 bit targets, and also the 
>register allocator will enregister float and double variables in XMM 
>registers.<

Will DMD use 8 XMM registers in 32 bit code too?


>Putting the compiler in D would make it difficult to integrate the D front end 
>into the C/C++ back ends of gcc and llvm.<

Writing the reference front-end in D has some advantages:
- Other people have lot of C/C++ code; if they want to use D they will probably 
want to interface C/C++ with D code. So writing the compiler front-end in D is 
a way to eat some of the D dog food, and see/test how much good such 
interfacing is, and eventually it's a push to improve it.
- It's a way to eat some D dog food in general, because a compiler front-end is 
a medium-sized project that requires some performance. If some parts of the D2 
language are badly designed or they lead to low performance (like fixed sized 
array assignment) this is a good way to spot such problems and a way to push to 
fix them.
- I have now understood that if you want a safe & reliable language you need a 
reliable compiler too. Because a very safe and very well designed language 
produces buggy and unsafe programs if the compiler is buggy. Writing the 
front-end in D allows to avoid several compiler bugs from the beginning.
- Writing the front-end in D is probably going to speed up a bit the 
development of the D compiler, with more expressiveness, less code, more 
readable code, less bug-prone code, etc.

Bye,
bearophile

Re: Java Backend?

[Manu]

On 15 December 2011 12:02, maarten van damme wrote:

>
> 2011/12/15 Andrea Fontana 
>
>> **
>> Maybe a dalvik bytecode (not compatible with "official"  jvm bytecode)
>> generator could help us developing apps for android?
>>
>>
> I've been looking at beeing able to write android apps in D. there is an
> ndk but it's c(++) only.
> I've read a blog report here:
> http://interaxiom.blogspot.com/2011/07/running-d-programming-language-on.html 
> with
> some interesting stuff here : https://bitbucket.org/serotonin
> never tried it though
>

I've been trying to get an Android toolchain happening, but I keep having
troubles building it... I'm not a building-GCC export >_<
It would be a bit of fun to implement (wrap) the android libs in D.

Re: Java Backend?

[maarten van damme]

no problem but tell me if it works :)

Re: D1 to be discontinued on December 31, 2012

[Vladimir Panteleev]

On Thursday, 15 December 2011 at 10:37:00 UTC, Mirko Pilger wrote:

http://store.steampowered.com/app/18600/?snr=1_200_200_254_13


does anybody know if and when how this game makes use of the 
steamworks framework, which is a c++ library provided by valve 
for using the steam game services. the only solution would be 
to write a plain c wrapper around it, right?


Have a look at Open Steamworks. It's a C API which returns 
interfaces, similar to DirectX APIs. These are easily usable from 
both C (structs with function pointers) and C++ (classes with 
pure-virtual functions).

Re: Java Backend?

[Chad J]

On 12/15/2011 05:02 AM, maarten van damme wrote:
> 
> 2011/12/15 Andrea Fontana  >
> 
> __
> Maybe a dalvik bytecode (not compatible with "official"  jvm
> bytecode) generator could help us developing apps for android?
> 
> 
> I've been looking at beeing able to write android apps in D. there is an
> ndk but it's c(++) only.
> I've read a blog report
> here: 
> http://interaxiom.blogspot.com/2011/07/running-d-programming-language-on.html 
> with
> some interesting stuff here : https://bitbucket.org/serotonin
> never tried it though 

Fuck. Yes.

I really want this.  Thank you!

Re: .dmg installer for OSX?

[Michel Fortin]

On 2011-12-15 11:33:15 +, Ruslan Mullakhmetov  said:


Probably, Mac App Store instalation would be the best?

I don't know, do Apple policies allow to install a command line 
utilities via Macc App Store, but at least apple itself install OS X 
Lion and XCode via MAS. So, there is technical posibility to install 
arbitary toolset, not only pure GUI.app located in /Application.


What do you say?


Not a chance. The App Store is for applications. And applications are 
required to be self-contained, they are not allowed to use an 
installer. Apple is bypassing its own rules for Xcode.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: DMD 1.072 and DMD 2.057 64bit on Mac OS X

[Michel Fortin]

On 2011-12-14 18:28:07 +, Walter Bright  said:


On 12/14/2011 3:09 AM, Jacob Carlborg wrote:

On 2011-12-14 11:54, Walter Bright wrote:

It makes me wonder if we need to support 32 bit generation on OSX at all.

Yeah, I wonder that too. But does it hurt/cause problems to do? I mean, it's
already supported.


There's the ongoing effort to support dynlibs.


It's one thing to ask developers to use 64-bit machines for 
development, it's another to say to developers they can't target 32-bit 
users if they choose to use DMD. Even Apple ships everything with dual 
architecture binaries these days, and some of Apple's apps also keep 
PowerPC support, iTunes for instance.


And also iOS is 32-bit.

--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: DMD 1.072 and DMD 2.057 64bit on Mac OS X

[Michel Fortin]

On 2011-12-15 07:22:47 +, Jacob Carlborg  said:


On 2011-12-14 19:28, Walter Bright wrote:

On 12/14/2011 3:09 AM, Jacob Carlborg wrote:

On 2011-12-14 11:54, Walter Bright wrote:

It makes me wonder if we need to support 32 bit generation on OSX at
all.

Yeah, I wonder that too. But does it hurt/cause problems to do? I
mean, it's
already supported.


There's the ongoing effort to support dynlibs.


But as Michel mentioned, iPhone is 32bit and I think that is a good point.


And I believe DMD can already create executables that would work on the 
iPhone simulator, since those are simply 32-bit Mac OS X executables 
linked to a different set of frameworks.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: .dmg installer for OSX?

[Jacob Carlborg]

On 2011-12-15 12:33, Ruslan Mullakhmetov wrote:

On 2011-12-11 22:10:37 +, Peter Alexander said:


On 11/12/11 9:29 PM, Andrei Alexandrescu wrote:

There's something missing from the download page (to which I just added
some nice logos):

http://www.d-programming-language.org/download.html

That would be an OSX .dmg. Is a member of the community interested in
taking up such a project?


Thanks,

Andrei


A .dmg isn't an installer. It's just an archive containing files.
Usually it contains an application package that the window background
instructs you to drag into the Applications folder... but that isn't
applicable to DMD.

Perhaps a .pkg would be more appropriate?

http://en.wikipedia.org/wiki/.dmg
http://en.wikipedia.org/wiki/.pkg


Probably, Mac App Store instalation would be the best?

I don't know, do Apple policies allow to install a command line
utilities via Macc App Store, but at least apple itself install OS X
Lion and XCode via MAS. So, there is technical posibility to install
arbitary toolset, not only pure GUI.app located in /Application.

What do you say?


I don't think command line tools are allowed.

--
/Jacob Carlborg

Re: .dmg installer for OSX?

[Ruslan Mullakhmetov]

On 2011-12-11 22:10:37 +, Peter Alexander said:


On 11/12/11 9:29 PM, Andrei Alexandrescu wrote:

There's something missing from the download page (to which I just added
some nice logos):

http://www.d-programming-language.org/download.html

That would be an OSX .dmg. Is a member of the community interested in
taking up such a project?


Thanks,

Andrei


A .dmg isn't an installer. It's just an archive containing files. 
Usually it contains an application package that the window background 
instructs you to drag into the Applications folder... but that isn't 
applicable to DMD.


Perhaps a .pkg would be more appropriate?

http://en.wikipedia.org/wiki/.dmg
http://en.wikipedia.org/wiki/.pkg


Probably, Mac App Store instalation would be the best?

I don't know, do Apple policies allow to install a command line 
utilities via Macc App Store, but at least apple itself install OS X 
Lion and XCode via MAS. So, there is technical posibility to install 
arbitary toolset, not only pure GUI.app located in /Application.


What do you say?
--
BR, Ruslan Mullakhmetov

Re: 64-bit DMD for windows?

[Alex Rønne Petersen]

On 15-12-2011 11:47, torhu wrote:

On 14.12.2011 12:54, dmd.20.browse...@xoxy.net wrote:


Hi,

Is there a 64-bit version of DMD for windows?

The download page offers only an x86 version. Or am I reading too much
into that?

Cheers, buk



There's not much you would need a 64-bit compiler for on Windows. What
are you going to use it for?


Um, to build 64-bit programs? What else...

- Alex

Re: 64-bit DMD for windows?

[torhu]

On 14.12.2011 12:54, dmd.20.browse...@xoxy.net wrote:


Hi,

Is there a 64-bit version of DMD for windows?

The download page offers only an x86 version. Or am I reading too much
into that?

Cheers, buk



There's not much you would need a 64-bit compiler for on Windows.  What 
are you going to use it for?

Re: D1 to be discontinued on December 31, 2012

[Mirko Pilger]

http://store.steampowered.com/app/18600/?snr=1_200_200_254_13


does anybody know if and when how this game makes use of the steamworks 
framework, which is a c++ library provided by valve for using the steam 
game services. the only solution would be to write a plain c wrapper 
around it, right?

Re: D1 to be discontinued on December 31, 2012

[Stephan]

On 14.12.2011 23:19, torhu wrote:

On 14.12.2011 22:26, Andrej Mitrovic wrote:

On 12/14/11, torhu wrote:

DWT for D2 is not in a usable state yet.


It has a few build issues but most samples work. I've never used it
for any projects yet though.


It doesn't work for much besides the samples.


thats plain wrong

Re: Java Backend?

[maarten van damme]

2011/12/15 Andrea Fontana 

> **
> Maybe a dalvik bytecode (not compatible with "official"  jvm bytecode)
> generator could help us developing apps for android?
>
>
I've been looking at beeing able to write android apps in D. there is an
ndk but it's c(++) only.
I've read a blog report here:
http://interaxiom.blogspot.com/2011/07/running-d-programming-language-on.html
with
some interesting stuff here : https://bitbucket.org/serotonin
never tried it though

Re: D1 to be discontinued on December 31, 2012

[Stephan]

On 14.12.2011 21:32, torhu wrote:

On 14.12.2011 14:05, Gour wrote:

On Wed, 14 Dec 2011 11:15:58 +0100
Jacob Carlborg wrote:


I don't know if all of them are successful but important: Tango, DWT,
Minid, Orange,


Not to say those are not important, but there are, afaict, falling in
the category of D1's ecosystem, not end-user apps.

Otoh Tango is ported to D2, Minid has moved to Croc, while DWT& Orange
have D2 ports.


DWT for D2 is not in a usable state yet. I'd assume the same goes for
Tango.


Why is it not ? I am using it regularly. Ok it is broken now since the 
new release... but b4

Re: Any plans to make it possible to call C++ functions that reside in a namespace?

[mta`chrono]

Adding namespaces to C++ interfacing would be great. AFAIK you could
also create a linker file and rename the symbols before linking.

-- suggestion:

extern(C++, "MyNamespace") interface Foobar
{
 void foo();
 void bar();
}

Re: Export and Protected Scoping in Dynamic Libraries

[Jonathan M Davis]

On Thursday, December 15, 2011 09:32:37 deadalnix wrote:
> The same goes for private virtual methods actually. They cannot be
> called, but they can be reimplemented in subclasses.
> 
> If you put that detail asside, this is a neat idea. I'd love to see that
> in D.

http://d.puremagic.com/issues/show_bug.cgi?id=4542

Re: Second Round CURL Wrapper Review

[Jonathan M Davis]

Line# 235 is identical to line# 239. Shouldn't line# 235 be creating an Http 
object, not an Ftp object? That mistake definitely makes it look like download 
hasn't been properly tested.

You should create template similar to

template isCurlConn(Conn)
{
auto isCurlConn = is(Conn : Http) || is(Conn : Ftp) || is(Conn : 
AutoConnection);
}

It would reduce code duplication.

The functions which have a template parameter T = char really need to have 
that parameter properly explained in the documentation. From the 
documentation, I would have thought that it was any character type, but it's 
char or ubyte. There is no hint whatsoever in the documentation that ubyte 
would work. All of the parameters need to be made clear. That goes for all 
functions.

Is there a reason that the functions which have a template argument T which 
can be either a char or a ubyte can't work with immutable char? Glancing at 
_basicHttp, I don't see any reason why T couldn't be immutable char. Yes, it 
would require casting to immutable(char)[], but you're already casting to 
char[], and the data being returned appears to be unique such that it could be 
safely cast to immutable. That being the case, I'd encourage you to not only 
make it work with immutable char but to make immutable char the default 
instead of char.

Once you've fixed the exception types like I requested in my first review, you 
can and should use enforceEx!CurlException(cond, msg) instead of enforce(cond, 
new CurlException(msg)).

it may not matter, since we're dealing with strings here, but I'd argue that 
!empty should be used rather than length > 0 (e.g. line# 475). In stuff other 
than strings it definitely can be more efficient, and even with strings, it may 
be, since I think that checking whether the length is 0 (as empty does) is 
slightly more efficient than checking whether it's greater than 0.

Please make sure that opening braces on on their own line. That's the way that 
the rest of Phobos does it and it's one of the few formatting rules that we've 
been trying to use consistently throughout Phobos. For the most part, you get 
it right, but not everywhere - nested functions in particular seem to have 
braces on the same line for some reason.

It's not a big deal, but you should use auto more. For instance, lines #626, 
#638, and #640 don't use auto when they could.

I have no idea why you keep putting parens around uses of the in operator, but 
it's not necessary and makes the code harder to read IMHO. It's certainly not 
required that you change that, but I'd appreciate it if you did.

I see that regexes are used in the module. Please make sure that they still 
work correctly with the new std.regex. They probably do, but it's not 100% 
backwards compatible.

byLine's template constraint needs to verify that the types of Terminator and 
Char are valid. As it is, I could try and pass it something like an Http 
struct if I wanted to. In general, _all_ templates need to verify that their 
arguments are of the appropriate type for _all_ of their arguments.

It's odd that popFront (line #780) is not @safe when empty and front are. Does 
findSplit or findSplitAfter prevent it?

With a name like Char on byLine, I'd expect it to take any char type, but not 
only do you not verify the type (as previously mentioned), but you instantiate 
_basicHttp with it, which works with char and ubyte, not any char. If Char is 
going to take char and ubyte specifically, then Char is a bad name for it.

I'd suggest changing line# 823 to

auto result = get(url, isFtpUrl(url) ? FTP() : Http());

It would save several lines of code.

Line# 883 should be using +=.

This would be easier if I could comment on the code directly, but I don't seem 
to be able to with the link that dsimcha provided (probably because it's blob; 
there's probably another link which would allow direct commenting, but oh 
well). I'll comment more on the implementation later, but bed beckons...

- Jonathan M Davis

Re: Java Backend?

[Andrea Fontana]

Maybe a dalvik bytecode (not compatible with "official"  jvm bytecode)
generator could help us developing apps for android?

Il giorno mer, 14/12/2011 alle 22.01 +0100, maarten van damme ha
scritto:

> they've got c working on a jvm if I recall corectly so safeD should be
> possible.
> But then again, is it worth it?

Re: Export and Protected Scoping in Dynamic Libraries

[deadalnix]

Le 14/12/2011 20:41, Adam Wilson a écrit :

Hello Everyone,

I want to start this conversation by pointing out that I come from a
C/C++/C# background and my ideas and frustrations in this post will be
colored by that history.

When I first approached D, the idea of an 'export' confused me. I've
since figured out, at least in libraries, that in C# terms D's 'export'
means 'public'. However, this raise a problem, specifically, how do I
export a protected member from a dynamic library?

Here is a table of D's scoping system mapped to C#'s scoping system as I
understand it:

D C#
export public
public internal
protected internal protected
private private

I believe this illustrates the problem clearly. There is no protected
scope that is available to the outside world. The ONLY way to export a
function in D is to mark is as an export. I have tested this against
2.056 and without the export identifier, the function never makes it
into the .lib file. But Protected functions are clearly intended to be
used outside of the library that they are built in. Currently, D says
no; but without protected functions, inheritance becomes very
troublesome. Any library of decent size is going to want to allow it's
consumers to inherit from it at some point. For example, just yesterday
I wrote four functions that overrode protected functions in .NET's WPF
library. Without access to these protected functions I would have been
simply unable to solve the problem. And my boss would have been VERY
unhappy about that.

I think the way export should work is more like an attribute or note to
the compiler that says "Hey Mr. Compiler, here is this public function,
compile it. And while you're at it, I set this little flag over here
that says you should export it as well." It would look something like
'export public' or 'export protected'.

So the new D->C# scope mapping table might look like this:

D C#
export public public
public internal
export protected protected
protected internal protected
private private

This would completely solve the issue of protected scoping in dynamic
libraries. As a note, 'export private' should be a compiler error.

I know there is a lot of resistance to making design changes to D2 at
this point, and rightly so. The biggest issue I see here is that it
breaks with TDPL. However, this is a major issue and one that will block
many people from picking up D for serious work. Support for inheritance
from dynamic libraries is a MUST HAVE for dynamic libraries to be truly
useful. As for maintaining backwards compatibility, a function with just
'export' could be easily mapped to 'export public' as that is it's
current behavior. Also, please note that I am not married to that
syntax. But a solution is required and I think that this one represents
a good compromise. It doesn't introduce any new keywords, fixes a major
design issue, and increases expressiveness and readability.

Any thoughts, objections, rants, raves? Walter, Andrei, thoughts?



The same goes for private virtual methods actually. They cannot be 
called, but they can be reimplemented in subclasses.


If you put that detail asside, this is a neat idea. I'd love to see that 
in D.

Re: Any plans to make it possible to call C++ functions that reside in a namespace?

[deadalnix]

Le 14/12/2011 22:47, Dejan Lekic a écrit :

As subject says. I am pretty much happy with the current C++ support. The
only thing I need is to be able to call functions from namespace(s). Any
plans to add this feature?


That would be great. ATM, I just create dumb function in the global 
namespace and thoses functions forward to the function within the namespace.

Re: D1 to be discontinued on December 31, 2012

[Nick Sabalausky]

"Nick Sabalausky"  wrote in message 
news:jcc9d8$2bo5$1...@digitalmars.com...
> "Jesse Phillips"  wrote in message 
> news:20111214160926.7dcb@unknown...
>> On Wed, 14 Dec 2011 10:46:18 +0100
>> Gour  wrote:
>>
>>> Can you give me a list of some successful open-source projects written
>>> in D1 and/or some proprietary ones?
>>
>> http://store.steampowered.com/app/18600/?snr=1_200_200_254_13
>> http://en.wikipedia.org/wiki/ABA_Games
>
> A lot of the ABA Games stuff was actually from before the days of D1, like 
> v0.xxx. For whatever that's worth. (Just random trivia I guess...)

Nevermind. I should read the other replies before posting :) 

Re: D1 to be discontinued on December 31, 2012

[Nick Sabalausky]

"Jesse Phillips"  wrote in message 
news:20111214160926.7dcb@unknown...
> On Wed, 14 Dec 2011 10:46:18 +0100
> Gour  wrote:
>
>> Can you give me a list of some successful open-source projects written
>> in D1 and/or some proprietary ones?
>
> http://store.steampowered.com/app/18600/?snr=1_200_200_254_13
> http://en.wikipedia.org/wiki/ABA_Games

A lot of the ABA Games stuff was actually from before the days of D1, like 
v0.xxx. For whatever that's worth. (Just random trivia I guess...)