Re: Had another 48hr game jam this weekend...

[Kapps]

On Sunday, 1 September 2013 at 04:36:46 UTC, Manu wrote:
I'm really don't like bugzilla as an end-user, but I'm not 
performing

searching actions.
As a reporter, I find it's needless friction between me and 
reporting bugs,
and I consequently report perhaps half as many bugs as I would 
otherwise,
because I need to open a slow website, and login with yet 
another account...


I've always found Bugzilla to be terrible. I *still* have no clue 
how to actually find the latest opened issues. For my own 
personal stuff I use Jira ($10 for up to 10 users or free for 
open source projects) and I find it to be an excellent issue 
tracking system. The ability to create an issue just by simply 
pressing 'c' on any page is wonderful and things load fairly fast 
from my experiences. That being said, I don't see D changing away 
from bugzilla any time soon, if ever. And honestly, there are 
much bigger priorities.

Re: Had another 48hr game jam this weekend...

[Kapps]

On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
The only compiler you can realistically use productively in 
windows is

DMD-Win64, and that doesn't work out of the box.
We needed to mess with sc.ini for quite some time to get the 
stars aligned

such that it would actually compile and find the linker+libs.


I also spent a decent bit of effort getting Win64 to work, and I 
agree that this is something that DMD should attempt to bundle. 
It may not need to go as far as downloading VC express for you, 
but it should allow integration of an existing install during 
installation (and ideally post-installation as well). This is a 
pretty big deal IMO. When I was a newbie, issues with COFF vs 
OMF, coffimplib confusion, etc, were almost deal-breakers to me. 
I just couldn't get things easily working, and I'm sure many 
others see it the same way. Having Win64 gives us a chance to fix 
that, but it *has* to be integrated into the installer. The 
compiler should ideally detect that the VS linker / libraries are 
missing when you use -m64, and tell you how to download VS 
Express as well as directing you to a batch file bundled with DMD 
to update sc.ini. Going a step further, it'd be even nicer if 
-m64 was default but that's not feasible with external 
dependencies. However when it detects a library in an invalid 
format, it should inform you about the existence of coffimplib 
and a download link, as well as how this is necessary only when 
compiling 32-bit executables. I don't think that the core 
contributors realize how incredibly frustrating these issues are 
to beginners, and thus feel as if it's not something that needs 
to be solved.



Getting a workable environment:

Unsurprisingly, the Linux user was the only person happy work 
with a
makefile. Everybody else wanted a comfortable IDE solution (and 
the linux

user would prefer it too).

!
This has to be given first-class attention!
I am completely and utterly sick of this problem. Don made a 
massive point
of it in his DConf talk, and I want to 
re-re-re-re-re-re-re-stress how

absolutely important this is.
!


I have to say, I don't see why you find this to be such a large 
issue. DMD is unique in the sense that it's the only thing I've 
ever been able to compile on Windows without running into many 
issues. So long as you have DMC installed, it just works. I've 
never had any makefile related issues on any platform. This is a 
big deal, as DMD evolves so rapidly that users should be able to 
get the git version with minimal effort, without having to 
download an IDE for it.


Overwhelmingly, the biggest complaint was a lack of symbolic 
information to
assist with auto-completion. Visual-D tries valiantly, but it 
falls quite

short of the mark.
This goes back to the threads where the IDE guys are writing 
their own
parsers, when really, DMD should be able to be built as a lib, 
with an API

designed for using DMD as a lib/plugin.
I think continuous code compilation for auto-completion and 
syntax
highlighting purposes should be a service offered and 
maintained by DMD.
That way it will evolve with the language, and anyone can use 
it without

reinventing the wheel.


While yes, it would be wonderful if we could get DMD to do this 
(again, I don't think a lot of the core contributors realize just 
how incredibly important IDEs and perfect auto-completion are), 
it doesn't seem to be something likely in the short-term. That 
being said, I've actually found Mono-D to be excellent recently. 
It doesn't handle things like CTFE properly and other similar 
issues, but for my purposes it's worked rather well (that being 
said, I avoid mixins for the most part, largely due to this). 
Despite all this, I'm actually quite happy with Mono-D lately.


One thing I've toyed with is the idea of using reflection for 
getting auto-complete information. I made a runtime reflection 
module (has a fair few issues still), and I wonder if it would be 
possible to use something similar for this purpose. Most modules 
could be cached, allowing us to build only the module you're 
altering. On top of that, some real-time parsing could be done 
for code modified since the last recompile (really it would need 
to primarily handle scanning for methods and variables). History 
completion from the current file, such as what editors like 
Sublime Text do, could perhaps be integrated to completely 
eliminate the issue of not being able to find a symbol in your 
auto-complete list. That would likely only kick in when it finds 
no results for anything else. Plus since you're recompiling 
frequently in the background, you would get early notifications 
of errors/warnings like you would in C#/Java. Ultimately though, 
I'm not sure if this would be updated fast enough (depends how 
long compiles take) to be feasible.




Debugging:

Poor debugging experience wastes your time every 5 minutes.
I can only speak for the Windows experience (since we failed to 
get OSX

Re: Had another 48hr game jam this weekend...

[Manu]

On 1 September 2013 12:57, Andrej Mitrovic wrote:

> On 9/1/13, Manu  wrote:
> > The only compiler you can realistically use productively in windows is
> > DMD-Win64 **
>
> Why? Win32 works fine for me and many others. If you run into
> Optlink-related bugs it's usually the compiler's fault. It might
> generate a bad object file and cause Optlink to crash (Unilink is
> better for diagnosing what went wrong).
>
> I'd imagine in a game-jam you won't be making a huge codebase, so you
> might as well stick with 32bit?
>

** If you want to link against any other libraries. Ie, if your eco-system
is not completely self-contained.
Libs in windows are compiled with VC. It's the de facto standard.

In our context, libs include: D3D, OpenGL, DirectSound, XAudio,
DirectInput, XInput, zlib, libpng, libjpeg, libmad, libogg, libvorbis,
AssImp, etc.

> We needed to mess with sc.ini for quite some time to get the stars aligned
> > such that it would actually compile and find the linker+libs.
> >
> > Walter: DMD needs to internally detect installations of various versions
> of
> > VisualStudio, and either 'just work', or amend sc.ini on its own.
>
> I provided a setup script once to retrieve the VC paths, which could
> then be invoked by some other process (perhaps even DMD itself when it
> reads sc.ini), but nothing seems to have come out of it yet:
>
>
> http://forum.dlang.org/thread/50dad8ba.8030...@digitalmars.com?page=2#post-CAJ85NXCKNnKMjVKpk9wSWOrGdAhJFCWa_n:2BkjCZpjJOBC5u-bQ:40mail.gmail.com
>
> Recently Nick has been working on making release scripts which will
> package dmd.zip automatically, I hope we can work on better VC
> integration after that work is done.
>
> > I suggest:
> >  * These should be made central D community projects.
>
> Most of us are happy enough with syntax-highlighted text editors, so
> we likely wouldn't touch any IDE code. I'm not sure what the above
> political move would do. There was a period when DWT was elected as
> the "official" D GUI, but nothing came out of it. So these political
> moves don't really mean a thing.
>

Most of who? The D devs? You all reject auto-complete and debuggers? How do
you get any work done?
Most of the D developers don't seem to be like most of the commercial
software dev's I've ever worked with.
I can't explain this, but I think it's a big problem that the development
community experience has very little on common with the end-user experience.

The reason for the political move would be in the inclusion of all of their
bugs into the main bug tracker, and consequently included in any reporting
and trend data.
It would also give end-users the right to come into the D forums and
complain about the IDE integration's directly. It's a central part of the
language experience, and should be taken as first-class criticism.

>- Deprecate DMD makefiles. Seriously! Insist that contributors use the
> > IDE bindings to work on DMD.
>
> Not gonna happen.
>

Reconsider.

>- The fact that you all laughed at the prior point suggests clearly why
> > it needs to be done. It will cease to be a problem when all the
> > druntime/phobos contributors are suffering the end-user experience.
>
> Slowing us down won't help anyone.
>

I'd argue that it would; inflicting the pain of trying to be a productive D
user on the developers will certainly highlight the importance of the issue.
I'm sure the only reason it can remain in such a feeble state for so many
years, is because the few people that write D code every day and could be
focusing attention on it aren't exposed to it.

>  * They should receive bugs in the main github bug-tracker, so EVERY D
> > contributor can see them, and how many there are.
>
> Bugzilla is better than whatever github has to offer. It's fast and
> its very searchable. Github just seems to introduce more and more
> useless features every other day (but I can't even search the damn
> pull request section, even though there's a "global" search..).
>

Well bugzilla then, wherever.. Just in the same place.

I'm really don't like bugzilla as an end-user, but I'm not performing
searching actions.
As a reporter, I find it's needless friction between me and reporting bugs,
and I consequently report perhaps half as many bugs as I would otherwise,
because I need to open a slow website, and login with yet another account...

> This goes back to the threads where the IDE guys are writing their own
> > parsers, when really, DMD should be able to be built as a lib, with an
> API
> > designed for using DMD as a lib/plugin.
> > I think continuous code compilation for auto-completion and syntax
> > highlighting purposes should be a service offered and maintained by DMD.
> > That way it will evolve with the language, and anyone can use it without
> > reinventing the wheel.
>
> This has been said a million times, but it's a very slow evolution
> turning an application into a library, especially one like DMD. The
> C++ => D migration process of DMD could maybe help us mo

Re: DMD 2.064 alpha windows build

[dennis luehring]

Am 31.08.2013 20:58, schrieb Temtaime:

You can get DMD source on DMD's github.

I've read DMD backend license, so it forbids to distribute DMD
itself.

I've removed the archive. I'll investigate in LDC.



btw: nedmalloc stated on its own homepage...
http://www.nedprod.com/programs/portable/nedmalloc/

"If you're running on an older operating system (e.g. Windows XP, Linux 
2.4 series, FreeBSD 6 series, Mac OS X 10.4 or earlier) you will 
probably find it significantly improves your application's performance 
(Windows 7, Linux 3.x, FreeBSD 8, Mac OS X 10.6 all contain 
state-of-the-art allocators and no third party allocator is likely to 
significantly improve on them in real world results)."


so you're running an older OS?

Re: Replacing std.xml

[deadalnix]

On Thursday, 29 August 2013 at 18:58:57 UTC, H. S. Teoh wrote:
On Thu, Aug 29, 2013 at 01:38:23PM -0400, Jonathan M Davis 
wrote:

[...]
Well, as I said, I couldn't remember exactly what the XML 
standard said about encodings, but if it can contain non-ASCII 
characters, then my first inclination is to say that it has to 
be UTF-8, UTF-16, or UTF-32 based on the fact that that's what 
we support in the language and in Phobos


Take a look here:

http://www.w3schools.com/xml/xml_encoding.asp

XML files can have *any* valid encoding, including nastiness 
like
windows-1252 and relics like iso-8859-1. Unfortunately, I don't 
think we
have a way around this, since existing XML files out there 
probably
already have all of these encodings are more, and std.xml is 
gonna hafta
support 'em all. Otherwise we're gonna get irate users 
complaining "why
can't std.xml parse my oddly-encoded-but-standards-compliant 
XML file?!"




As this is not the first time I see it used as a reliable source, 
no, w3school is full of shit. Don't use that website when looking 
for precise high quality information.

Re: DMD 2.064 alpha windows build

[dennis luehring]

Am 31.08.2013 20:58, schrieb Temtaime:

You can get DMD source on DMD's github.

I've read DMD backend license, so it forbids to distribute DMD
itself.

I've removed the archive. I'll investigate in LDC.



it seems that the old malloc implementation was the source of
the 2x speed difference between dmc and msvc build

http://forum.dlang.org/thread/ktju8h$efb$1...@digitalmars.com

so you're tcmalloc version is 2x faster or 4x?

Re: Had another 48hr game jam this weekend...

[Rikki Cattermole]

On Sunday, 1 September 2013 at 03:17:29 UTC, Trent wrote:

On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
We have to get the user experience and first impressions under 
control...


I'd really love to to see a general roadmap and list of 
priorities. Even if

goals are high-level, they might help direct focus?

So I had another game-jam this weekend with a bunch of friends 
who are all

industry professionals.
The point of a 48 hour game jam is to prioritise productivity 
and

creativity.
Choosing a language like D here makes sense from a 
productivity point of

view... that is, if it 'JUST WORKS'™.

There were 7 programmers, they were all using D for the first 
time (except

me).

Most running windows, one on OSX, one on Linux.
We ran into the same problems old that have been giving me the 
shits as

long as I've been using D.

Configuring compilers:

Naturally, this is primarily a problem with the windows 
experience, but
it's so frustrating that it is STILL a problem... how many 
years later?
People don't want to 'do work' to install a piece of software. 
Rather, they
expect it to 'just work'. We lost about 6 hours trying to get 
everyone's

machines working properly.
In the context of a 48 hour game jam, that's a terrible sign! 
I just kept
promising people that it would save time overall... which I 
wish were true.


The only compiler you can realistically use productively in 
windows is

DMD-Win64, and that doesn't work out of the box.
We needed to mess with sc.ini for quite some time to get the 
stars aligned

such that it would actually compile and find the linker+libs.

Walter: DMD needs to internally detect installations of 
various versions of
VisualStudio, and either 'just work', or amend sc.ini on its 
own. Or the
installer needs to amend sc.ini. Either way, leaving it to a 
user to fiddle
with an ini file just isn't acceptable. We had to google 
solutions to this
problem, and even then, we had trouble with the paths we added 
to sc.ini;

are spaces acceptable? Do they have quites around them?...
I might also suggest that Microsoft supplied (ie, 'standard'), 
libraries
should be automatically detected and path entries added in 
there too:

 C:\Program Files (x86)\Microsoft SDKs\...
 C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...
These are on basically every windows developers machine, and 
each of us had

to configure them ourselves.


Getting a workable environment:

Unsurprisingly, the Linux user was the only person happy work 
with a
makefile. Everybody else wanted a comfortable IDE solution 
(and the linux

user would prefer it too).

!
This has to be given first-class attention!
I am completely and utterly sick of this problem. Don made a 
massive point
of it in his DConf talk, and I want to 
re-re-re-re-re-re-re-stress how

absolutely important this is.
!

I have come to the conclusion that treating IDE integration as 
ancillary
projects maintained by usually just one single member of the 
community has

absolutely failed.
I suggest:
* These should be made central D community projects.
* I think they should be hosted in the same github 
organisation as DMD.
*** As many contributors as possible should be encouraged to 
work with

them every day.
  - Deprecate DMD makefiles. Seriously! Insist that 
contributors use the

IDE bindings to work on DMD.
  - The fact that you all laughed at the prior point suggests 
clearly why

it needs to be done. It will cease to be a problem when all the
druntime/phobos contributors are suffering the end-user 
experience.
* They should receive bugs in the main github bug-tracker, so 
EVERY D

contributor can see them, and how many there are.

IDE integration absolutely needs to be considered a first 
class feature of

D.
I also suggest that the IDE integration downloads should be 
hosted on the
dlang download page so they are obvious and available to 
everyone without
having to go looking, and also as a statement that they are 
actually
endorsed by the dlanguage authorities. As an end-user, you're 
not left

guessing which ones are good/bad/out of date/actually work/etc.

Obviously, we settled on Visual-D (Windows) and Mono-D 
(OSX/Linux); the
only realistic choices available. The OSX user would have 
preferred an

XCode integration.

Overwhelmingly, the biggest complaint was a lack of symbolic 
information to
assist with auto-completion. Visual-D tries valiantly, but it 
falls quite

short of the mark.
This goes back to the threads where the IDE guys are writing 
their own
parsers, when really, DMD should be able to be built as a lib, 
with an API

designed for using DMD as a lib/plugin.
I think continuous code compilation for auto-completion and 
syntax
highlighting purposes should be a service offered and 
maintained by DMD.
That way it will evolve with the language, and anyone can use 
it without

reinventing the wheel.


Debugging:

Poor debugging experience wastes your time every 5 minutes.
I can only speak for

Re: Had another 48hr game jam this weekend...

[Jakob Ovrum]

Sorry about the nonsensical reply, the web interface was acting 
up... this is the intended reply.


On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
The only compiler you can realistically use productively in 
windows is

DMD-Win64, and that doesn't work out of the box.


Why didn't you go with DMD-Win32? Because of OMF? implib and/or 
objconv is a hassle but probably less of a hassle than using the 
nascent DMD-Win64.


Overwhelmingly, the biggest complaint was a lack of symbolic 
information to
assist with auto-completion. Visual-D tries valiantly, but it 
falls quite

short of the mark.
This goes back to the threads where the IDE guys are writing 
their own
parsers, when really, DMD should be able to be built as a lib, 
with an API

designed for using DMD as a lib/plugin.


Although I'm not convinced auto-completion is a vital feature 
(Microsoft's C++ IntelliSense is shit too), I agree that any time 
spent on custom parsers and best-effort semantic analysis is a 
complete waste of time. The only semantic analysis engine that is 
going to be sufficiently good for D is one from a compiler 
front-end. Apart from DMD, it's worth taking a look at SDC for 
this.



some windows dev's want a CHM that looks like
the typical Microsoft doc's people are used to. Those that 
aren't familiar
with the CHM viewer; it's just HTML but with a nice index + 
layout tree.


dmd2\windows\bin\d.chm

The question came up multiple times; "I don't think this should 
be an

array... what containers can I use, and where are they?"...
Also, nobody could work out how to remove an arbitrary item 
from an array,

or an item from an AA by reference/value (only by key).

This code:
  foreach(i, item; array)
if(item == itemToRemove)
  array = array[0..i] ~ array[i+1..$];
Got a rather 'negative' reaction from the audience to put it 
lightly...


`std.algorithm.remove` provides both stable (preserves order, 
shuffles entire array down) and unstable (swaps with last element 
and shrinks by one) removal. However, Phobos does not make a 
habit of providing helpers for strictly O(n) algorithms, so the 
O(n) nature has to be made explicit by first getting the index 
with `std.algorithm.countUntil`.


Removing a pair from an AA by value is also an exercise in linear 
search, and as such will not get a deceptive helper function. 
However, once range interfaces for AAs mature, such an algorithm 
can be composed trivially.


Yes, we hit DMD bugs, like the one with opaque structs which 
required

extensive work-arounds.
  struct MyStruct;
  MyStruct*[] = new MyStruct*[n];


I'm not sure this is a bug. How do you default initialize an 
array of structs you don't know the .init values of?

Re: Had another 48hr game jam this weekend...

[Froglegs]

 Yes IDE should be built with the language :)

D has bad IDE support that is why I read about D but don't 
actually use it...

Re: Had another 48hr game jam this weekend...

[Michel Fortin]

On 2013-09-01 02:05:39 +, Manu  said:


I might re-iterate my feeling that external IDE integration projects should
be claimed by the community officially


In my opinion the community is just too short on man-hours.

I did integrate D with Xcode at one point (no autocompletion though) 
and created an all-in-one installer for the compiler and the Xcode 
plugin. It just worked. I don't maintain it anymore and Xcode 4 broke 
it. It's open source so anyone in the community could have taken it 
further, but so far this hasn't happened.


I'm not using D anymore. I realized that with the time required to 
maintain the toolset (including installer and Xcode plugin) plus the 
time it'd take to make the language suitable to my needs (Objective-C 
integration, perhaps ARM support for iOS), all that by itself would 
probably be more than one full-time job. As all this meta-work would 
seriously get in the way of my actual work, I let it go. I'm not 
regretting that move.


So I'm no longer using D, but I'm still hanging around here from time 
to time because there's always something interesting to read.



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

Re: Had another 48hr game jam this weekend...

[Jakob Ovrum]

On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
We have to get the user experience and first impressions under 
control...


I'd really love to to see a general roadmap and list of 
priorities. Even if

goals are high-level, they might help direct focus?

So I had another game-jam this weekend with a bunch of friends 
who are all

industry professionals.
The point of a 48 hour game jam is to prioritise productivity 
and

creativity.
Choosing a language like D here makes sense from a productivity 
point of

view... that is, if it 'JUST WORKS'™.

There were 7 programmers, they were all using D for the first 
time (except

me).

Most running windows, one on OSX, one on Linux.
We ran into the same problems old that have been giving me the 
shits as

long as I've been using D.

Configuring compilers:

Naturally, this is primarily a problem with the windows 
experience, but
it's so frustrating that it is STILL a problem... how many 
years later?
People don't want to 'do work' to install a piece of software. 
Rather, they
expect it to 'just work'. We lost about 6 hours trying to get 
everyone's

machines working properly.
In the context of a 48 hour game jam, that's a terrible sign! I 
just kept
promising people that it would save time overall... which I 
wish were true.


The only compiler you can realistically use productively in 
windows is

DMD-Win64, and that doesn't work out of the box.
We needed to mess with sc.ini for quite some time to get the 
stars aligned

such that it would actually compile and find the linker+libs.

Walter: DMD needs to internally detect installations of various 
versions of
VisualStudio, and either 'just work', or amend sc.ini on its 
own. Or the
installer needs to amend sc.ini. Either way, leaving it to a 
user to fiddle
with an ini file just isn't acceptable. We had to google 
solutions to this
problem, and even then, we had trouble with the paths we added 
to sc.ini;

are spaces acceptable? Do they have quites around them?...
I might also suggest that Microsoft supplied (ie, 'standard'), 
libraries
should be automatically detected and path entries added in 
there too:

  C:\Program Files (x86)\Microsoft SDKs\...
  C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...
These are on basically every windows developers machine, and 
each of us had

to configure them ourselves.


Getting a workable environment:

Unsurprisingly, the Linux user was the only person happy work 
with a
makefile. Everybody else wanted a comfortable IDE solution (and 
the linux

user would prefer it too).

!
This has to be given first-class attention!
I am completely and utterly sick of this problem. Don made a 
massive point
of it in his DConf talk, and I want to 
re-re-re-re-re-re-re-stress how

absolutely important this is.
!

I have come to the conclusion that treating IDE integration as 
ancillary
projects maintained by usually just one single member of the 
community has

absolutely failed.
I suggest:
 * These should be made central D community projects.
 * I think they should be hosted in the same github 
organisation as DMD.
 *** As many contributors as possible should be encouraged to 
work with

them every day.
   - Deprecate DMD makefiles. Seriously! Insist that 
contributors use the

IDE bindings to work on DMD.
   - The fact that you all laughed at the prior point suggests 
clearly why

it needs to be done. It will cease to be a problem when all the
druntime/phobos contributors are suffering the end-user 
experience.
 * They should receive bugs in the main github bug-tracker, so 
EVERY D

contributor can see them, and how many there are.

IDE integration absolutely needs to be considered a first class 
feature of

D.
I also suggest that the IDE integration downloads should be 
hosted on the
dlang download page so they are obvious and available to 
everyone without
having to go looking, and also as a statement that they are 
actually
endorsed by the dlanguage authorities. As an end-user, you're 
not left

guessing which ones are good/bad/out of date/actually work/etc.

Obviously, we settled on Visual-D (Windows) and Mono-D 
(OSX/Linux); the
only realistic choices available. The OSX user would have 
preferred an

XCode integration.

Overwhelmingly, the biggest complaint was a lack of symbolic 
information to
assist with auto-completion. Visual-D tries valiantly, but it 
falls quite

short of the mark.
This goes back to the threads where the IDE guys are writing 
their own
parsers, when really, DMD should be able to be built as a lib, 
with an API

designed for using DMD as a lib/plugin.
I think continuous code compilation for auto-completion and 
syntax
highlighting purposes should be a service offered and 
maintained by DMD.
That way it will evolve with the language, and anyone can use 
it without

reinventing the wheel.


Debugging:

Poor debugging experience wastes your time every 5 minutes.
I can only speak for the Windows experience (since we failed to 
get OS

Re: Had another 48hr game jam this weekend...

[Trent]

On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
We have to get the user experience and first impressions under 
control...


I'd really love to to see a general roadmap and list of 
priorities. Even if

goals are high-level, they might help direct focus?

So I had another game-jam this weekend with a bunch of friends 
who are all

industry professionals.
The point of a 48 hour game jam is to prioritise productivity 
and

creativity.
Choosing a language like D here makes sense from a productivity 
point of

view... that is, if it 'JUST WORKS'™.

There were 7 programmers, they were all using D for the first 
time (except

me).

Most running windows, one on OSX, one on Linux.
We ran into the same problems old that have been giving me the 
shits as

long as I've been using D.

Configuring compilers:

Naturally, this is primarily a problem with the windows 
experience, but
it's so frustrating that it is STILL a problem... how many 
years later?
People don't want to 'do work' to install a piece of software. 
Rather, they
expect it to 'just work'. We lost about 6 hours trying to get 
everyone's

machines working properly.
In the context of a 48 hour game jam, that's a terrible sign! I 
just kept
promising people that it would save time overall... which I 
wish were true.


The only compiler you can realistically use productively in 
windows is

DMD-Win64, and that doesn't work out of the box.
We needed to mess with sc.ini for quite some time to get the 
stars aligned

such that it would actually compile and find the linker+libs.

Walter: DMD needs to internally detect installations of various 
versions of
VisualStudio, and either 'just work', or amend sc.ini on its 
own. Or the
installer needs to amend sc.ini. Either way, leaving it to a 
user to fiddle
with an ini file just isn't acceptable. We had to google 
solutions to this
problem, and even then, we had trouble with the paths we added 
to sc.ini;

are spaces acceptable? Do they have quites around them?...
I might also suggest that Microsoft supplied (ie, 'standard'), 
libraries
should be automatically detected and path entries added in 
there too:

  C:\Program Files (x86)\Microsoft SDKs\...
  C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...
These are on basically every windows developers machine, and 
each of us had

to configure them ourselves.


Getting a workable environment:

Unsurprisingly, the Linux user was the only person happy work 
with a
makefile. Everybody else wanted a comfortable IDE solution (and 
the linux

user would prefer it too).

!
This has to be given first-class attention!
I am completely and utterly sick of this problem. Don made a 
massive point
of it in his DConf talk, and I want to 
re-re-re-re-re-re-re-stress how

absolutely important this is.
!

I have come to the conclusion that treating IDE integration as 
ancillary
projects maintained by usually just one single member of the 
community has

absolutely failed.
I suggest:
 * These should be made central D community projects.
 * I think they should be hosted in the same github 
organisation as DMD.
 *** As many contributors as possible should be encouraged to 
work with

them every day.
   - Deprecate DMD makefiles. Seriously! Insist that 
contributors use the

IDE bindings to work on DMD.
   - The fact that you all laughed at the prior point suggests 
clearly why

it needs to be done. It will cease to be a problem when all the
druntime/phobos contributors are suffering the end-user 
experience.
 * They should receive bugs in the main github bug-tracker, so 
EVERY D

contributor can see them, and how many there are.

IDE integration absolutely needs to be considered a first class 
feature of

D.
I also suggest that the IDE integration downloads should be 
hosted on the
dlang download page so they are obvious and available to 
everyone without
having to go looking, and also as a statement that they are 
actually
endorsed by the dlanguage authorities. As an end-user, you're 
not left

guessing which ones are good/bad/out of date/actually work/etc.

Obviously, we settled on Visual-D (Windows) and Mono-D 
(OSX/Linux); the
only realistic choices available. The OSX user would have 
preferred an

XCode integration.

Overwhelmingly, the biggest complaint was a lack of symbolic 
information to
assist with auto-completion. Visual-D tries valiantly, but it 
falls quite

short of the mark.
This goes back to the threads where the IDE guys are writing 
their own
parsers, when really, DMD should be able to be built as a lib, 
with an API

designed for using DMD as a lib/plugin.
I think continuous code compilation for auto-completion and 
syntax
highlighting purposes should be a service offered and 
maintained by DMD.
That way it will evolve with the language, and anyone can use 
it without

reinventing the wheel.


Debugging:

Poor debugging experience wastes your time every 5 minutes.
I can only speak for the Windows experience (since we failed to 
get OS

Re: Had another 48hr game jam this weekend...

[Andrej Mitrovic]

On 9/1/13, Manu  wrote:
> The only compiler you can realistically use productively in windows is
> DMD-Win64

Why? Win32 works fine for me and many others. If you run into
Optlink-related bugs it's usually the compiler's fault. It might
generate a bad object file and cause Optlink to crash (Unilink is
better for diagnosing what went wrong).

I'd imagine in a game-jam you won't be making a huge codebase, so you
might as well stick with 32bit?

> We needed to mess with sc.ini for quite some time to get the stars aligned
> such that it would actually compile and find the linker+libs.
>
> Walter: DMD needs to internally detect installations of various versions of
> VisualStudio, and either 'just work', or amend sc.ini on its own.

I provided a setup script once to retrieve the VC paths, which could
then be invoked by some other process (perhaps even DMD itself when it
reads sc.ini), but nothing seems to have come out of it yet:

http://forum.dlang.org/thread/50dad8ba.8030...@digitalmars.com?page=2#post-CAJ85NXCKNnKMjVKpk9wSWOrGdAhJFCWa_n:2BkjCZpjJOBC5u-bQ:40mail.gmail.com

Recently Nick has been working on making release scripts which will
package dmd.zip automatically, I hope we can work on better VC
integration after that work is done.

> I suggest:
>  * These should be made central D community projects.

Most of us are happy enough with syntax-highlighted text editors, so
we likely wouldn't touch any IDE code. I'm not sure what the above
political move would do. There was a period when DWT was elected as
the "official" D GUI, but nothing came out of it. So these political
moves don't really mean a thing.

>- Deprecate DMD makefiles. Seriously! Insist that contributors use the
> IDE bindings to work on DMD.

Not gonna happen.

>- The fact that you all laughed at the prior point suggests clearly why
> it needs to be done. It will cease to be a problem when all the
> druntime/phobos contributors are suffering the end-user experience.

Slowing us down won't help anyone.

>  * They should receive bugs in the main github bug-tracker, so EVERY D
> contributor can see them, and how many there are.

Bugzilla is better than whatever github has to offer. It's fast and
its very searchable. Github just seems to introduce more and more
useless features every other day (but I can't even search the damn
pull request section, even though there's a "global" search..).

> This goes back to the threads where the IDE guys are writing their own
> parsers, when really, DMD should be able to be built as a lib, with an API
> designed for using DMD as a lib/plugin.
> I think continuous code compilation for auto-completion and syntax
> highlighting purposes should be a service offered and maintained by DMD.
> That way it will evolve with the language, and anyone can use it without
> reinventing the wheel.

This has been said a million times, but it's a very slow evolution
turning an application into a library, especially one like DMD. The
C++ => D migration process of DMD could maybe help us move into this
direction.

> There were many instances of people wasting their time chasing bugs in
> random places when it was simply a case of the debugger lying about the
> value of variables to them, and many more cases where the debugger simply
> refused to produce values for some variables at all.

That sucks.

> Documentation:
>
> Okay for the most part, but some windows dev's want a CHM that looks like
> the typical Microsoft doc's people are used to.

It's in the windows/bin folder. It's a poor place to put it, it should
better be put in a 'doc' folder or something, and it should be noted
somewhere on the website.

> This code:
>   foreach(i, item; array)
> if(item == itemToRemove)
>   array = array[0..i] ~ array[i+1..$];
> Got a rather 'negative' reaction from the audience to put it lightly...

That will allocate a new array. It could have been:

foreach(i, item; array)
if (item == itemToRemove)
array = array.remove(i);

or even:

auto idx = array.countUntil(item);
if (idx != -1)
array = array.remove(idx);

Although it's still not very pretty. I'm surprised you're using
allocation like that for game development! :)

> It is how quickly classes became disorganised and difficult to navigate
> (like Java and C#).
> We all wanted to ability to define class member functions outside the class
> definition:
>   class MyClass
>   {
> void method();
>   }
>
>   void MyClass.method()
>   {
> //...
>   }
>
> It definitely cost us time simply trying to understand the class layout
> visually (ie, when IDE support is barely available).
> You don't need to see the function bodies in the class definition, you want
> to quickly see what a class has and does.

I think Andrei mentioned once that this might be a good idea, but it
needs a DIP and formal reviewing, not to mention a solid
implementation. Only this time, no more back-channel introduction of
features like UDAs, please. We ended up having a deprecation for

Re: obsolete D libraries/modules

[Jonathan M Davis]

On Saturday, August 31, 2013 19:18:11 Andrei Alexandrescu wrote:
> I remember sitting next to Kirk McDonald at the D conference in 2007 as
> he was showing me Python's argparse. I personally found pretty much any
> example we could think of more verbose and uglier than std.getopt.

std.getopt is definitely lacking some nice-to-have features (like automatically 
generating --help from the options), but for the most part, I don't think that 
it can be improved much without seriously complicating it. I think that it's 
about at the limit of what can be done and still have it be simple, and it 
works really well for the most part, so if we haven't hit the sweet spot, 
we're at least close. I've toyed with trying to figure out how to improve it, 
but I think that doing so cleanly would be very hard.

The main thing that I'd really like to see changed is the exception types that 
it throws, because I'd very much like to be able to have code which can give 
specific information about how the flags were incorrectly used and whatnot, and 
ConvException (which is usually what you get) doesn't cut it for that. You'd 
need getopt-specific exceptions for that. But we can fix that without changing 
the API. It's just that doing so would likely break code which was catching 
ConvException explicitly, so if we do that, we might be forced to introduce 
getOpt to replace getopt or something like that. But even if we did that, the 
basic design wouldn't change, just what it's throwing on failure.

- Jonathan M Davis

Re: obsolete D libraries/modules

[Andrei Alexandrescu]

On 8/31/13 4:37 PM, Peter Williams wrote:

On 01/09/13 03:11, Andrei Alexandrescu wrote:

Haven't seen Tango's arguments parser, but it's a given getopt can be
improved in any number of ways. Yet the way I see it, with command line
parsing, the margin between a good enough argument parser and a terrific
one is razor thin. One parses arguments by definition once in every
program, and things like checking against limits and constraints across
multiple arguments can be easily done after basic parsing.



The Python Standard Library's argparse module
 would be a good model
to base an improved option parsing module on.  I've used it a lot in
Python and it's very useful.

Peter


I remember sitting next to Kirk McDonald at the D conference in 2007 as 
he was showing me Python's argparse. I personally found pretty much any 
example we could think of more verbose and uglier than std.getopt.



Andrei

Had another 48hr game jam this weekend...

[Manu]

We have to get the user experience and first impressions under control...

I'd really love to to see a general roadmap and list of priorities. Even if
goals are high-level, they might help direct focus?

So I had another game-jam this weekend with a bunch of friends who are all
industry professionals.
The point of a 48 hour game jam is to prioritise productivity and
creativity.
Choosing a language like D here makes sense from a productivity point of
view... that is, if it 'JUST WORKS'™.

There were 7 programmers, they were all using D for the first time (except
me).

Most running windows, one on OSX, one on Linux.
We ran into the same problems old that have been giving me the shits as
long as I've been using D.

Configuring compilers:

Naturally, this is primarily a problem with the windows experience, but
it's so frustrating that it is STILL a problem... how many years later?
People don't want to 'do work' to install a piece of software. Rather, they
expect it to 'just work'. We lost about 6 hours trying to get everyone's
machines working properly.
In the context of a 48 hour game jam, that's a terrible sign! I just kept
promising people that it would save time overall... which I wish were true.

The only compiler you can realistically use productively in windows is
DMD-Win64, and that doesn't work out of the box.
We needed to mess with sc.ini for quite some time to get the stars aligned
such that it would actually compile and find the linker+libs.

Walter: DMD needs to internally detect installations of various versions of
VisualStudio, and either 'just work', or amend sc.ini on its own. Or the
installer needs to amend sc.ini. Either way, leaving it to a user to fiddle
with an ini file just isn't acceptable. We had to google solutions to this
problem, and even then, we had trouble with the paths we added to sc.ini;
are spaces acceptable? Do they have quites around them?...
I might also suggest that Microsoft supplied (ie, 'standard'), libraries
should be automatically detected and path entries added in there too:
  C:\Program Files (x86)\Microsoft SDKs\...
  C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...
These are on basically every windows developers machine, and each of us had
to configure them ourselves.


Getting a workable environment:

Unsurprisingly, the Linux user was the only person happy work with a
makefile. Everybody else wanted a comfortable IDE solution (and the linux
user would prefer it too).

!
This has to be given first-class attention!
I am completely and utterly sick of this problem. Don made a massive point
of it in his DConf talk, and I want to re-re-re-re-re-re-re-stress how
absolutely important this is.
!

I have come to the conclusion that treating IDE integration as ancillary
projects maintained by usually just one single member of the community has
absolutely failed.
I suggest:
 * These should be made central D community projects.
 * I think they should be hosted in the same github organisation as DMD.
 *** As many contributors as possible should be encouraged to work with
them every day.
   - Deprecate DMD makefiles. Seriously! Insist that contributors use the
IDE bindings to work on DMD.
   - The fact that you all laughed at the prior point suggests clearly why
it needs to be done. It will cease to be a problem when all the
druntime/phobos contributors are suffering the end-user experience.
 * They should receive bugs in the main github bug-tracker, so EVERY D
contributor can see them, and how many there are.

IDE integration absolutely needs to be considered a first class feature of
D.
I also suggest that the IDE integration downloads should be hosted on the
dlang download page so they are obvious and available to everyone without
having to go looking, and also as a statement that they are actually
endorsed by the dlanguage authorities. As an end-user, you're not left
guessing which ones are good/bad/out of date/actually work/etc.

Obviously, we settled on Visual-D (Windows) and Mono-D (OSX/Linux); the
only realistic choices available. The OSX user would have preferred an
XCode integration.

Overwhelmingly, the biggest complaint was a lack of symbolic information to
assist with auto-completion. Visual-D tries valiantly, but it falls quite
short of the mark.
This goes back to the threads where the IDE guys are writing their own
parsers, when really, DMD should be able to be built as a lib, with an API
designed for using DMD as a lib/plugin.
I think continuous code compilation for auto-completion and syntax
highlighting purposes should be a service offered and maintained by DMD.
That way it will evolve with the language, and anyone can use it without
reinventing the wheel.


Debugging:

Poor debugging experience wastes your time every 5 minutes.
I can only speak for the Windows experience (since we failed to get OSX
working); there are lots of problems with the debugging experience under
visual studio...
I haven't logged bugs yet, but I intend to.

Re: obsolete D libraries/modules

[Peter Williams]

On 01/09/13 03:11, Andrei Alexandrescu wrote:

Haven't seen Tango's arguments parser, but it's a given getopt can be
improved in any number of ways. Yet the way I see it, with command line
parsing, the margin between a good enough argument parser and a terrific
one is razor thin. One parses arguments by definition once in every
program, and things like checking against limits and constraints across
multiple arguments can be easily done after basic parsing.



The Python Standard Library's argparse module 
 would be a good model 
to base an improved option parsing module on.  I've used it a lot in 
Python and it's very useful.


Peter

Re: Help?

[Manu]

On 31 August 2013 04:59, Johannes Pfau  wrote:

> Am Sat, 31 Aug 2013 04:09:10 +1000
> schrieb Manu :
>
> > So should I extern(C) the forward declaration?
>
> Sometimes
> ---
> struct MyStruct {}
> ---
> is used as a workaround, but that may have other issues.
>

Yeah, that's no good. That certainly opens up more problems.
The point is that it is an undefined struct, and it can only be used to
type a pointer. It's pretty much impossible to extern to a lot of C code if
this doesn't work properly.

Re: obsolete D libraries/modules

[Flamaros]

On Saturday, 31 August 2013 at 23:03:48 UTC, Andrej Mitrovic 
wrote:

On 9/1/13, Flamaros  wrote:

I am a Windows user, but I don't understand why others
platforms are forgotten.


I think it's because win32 is the easiest to create a native 
library
for, since the standard API functions for creating windows and 
widgets
has been the same for many years. On OSX you probably have to 
interact
with Objective-C code, which IIRC is hard to do from D without 
some

extra language support (there's some pull request for it).

And on Posix you basically don't have a standard API, so 
front-end

libraries typically use GTK or Qt as the backend.


Yep, I know that for linux it's hard to use X11 or XCB direcly.
Today linux window manager (unity, KDE) seems want migrate form 
gtk to QML that can interact efficiently with modern window 
compositors (wayland, Mir).
Old GUI systems are to different on platforms that why we made 
the choice of doing something like QML which is based on a 3D 
renderer.
If I am not wrong that so much hard to wrap native GUI systems in 
a portable way than QtWidgets is manually written to mimic native 
GUI.

Re: assert() vs. enforce(), invariant() vs. ... ?

[Andrei Alexandrescu]

On 8/31/13 2:57 PM, Brian Rogoff wrote:

On Saturday, 31 August 2013 at 21:30:40 UTC, Andrei Alexandrescu wrote:


http://stackoverflow.com/questions/4711309/meaning-of-scope-in-d-for-a-parameter



That use will stay and is useful and uncontested.

Andrei


Sure, but my complaint is that that useful style is cramped by the
inability to have scope on *local variables*.


Oh I see. Yes, if we do find a way to define scope to provide 
guarantees, that would be awesome.


Andrei

Re: obsolete D libraries/modules

[Andrej Mitrovic]

On 9/1/13, Flamaros  wrote:
> I am a Windows user, but I don't understand why others
> platforms are forgotten.

I think it's because win32 is the easiest to create a native library
for, since the standard API functions for creating windows and widgets
has been the same for many years. On OSX you probably have to interact
with Objective-C code, which IIRC is hard to do from D without some
extra language support (there's some pull request for it).

And on Posix you basically don't have a standard API, so front-end
libraries typically use GTK or Qt as the backend.

Re: obsolete D libraries/modules

[Flamaros]

On Saturday, 31 August 2013 at 19:11:25 UTC, Ramon wrote:
On Saturday, 31 August 2013 at 18:44:52 UTC, Brad Anderson 
wrote:

On Friday, 30 August 2013 at 12:28:42 UTC, Wyatt wrote:

On Thursday, 29 August 2013 at 19:18:48 UTC, H. S. Teoh wrote:


Right now, having no way to actually update that site to add 
a

notice to this effect


On this point, when's the last time someone tried pinging him 
via email?  Is the whois for the domain not current?


-Wyatt


His email is supposedly brad at dsource.org.  I know people 
have had difficulty contacting him in the past but I've never 
tried myself.


And just to clarify, I'm not the same Brad Anderson that runs 
DSource (which has caused some confusion in the past).  I'm 
pretty sure neither of us talk in the third person.


He, the dsource guy, is Brad AndersEn from Atlanta, GA, 
according

to what little info is available. His whois email is at some
company that seems to have gone away or changed name or ...
dsource seems to be on a VPS at slicehost and, so it seems, just
one in some more sites on that virtual host.

It seems we shouldn't hold our breath to hear from Mr. Andersen,
unless someone here knows him personally and is in contact with
him.

But then, most people looking for D arrive here at dlang anyway.
I think, we should simply put some kind of marker here concering
dsource being comatose.

A+ -R


By reading this thread I just learn that dsource.org is "dead".

And by going deeper in the wiki I found a page that replace 
dsource.org as an entry point to D related projects :

http://wiki.dlang.org/Libraries_and_Frameworks

I think this page should be more visible on dlang to show how 
much the community is large to the newcomers.


Maybe a Dquick will have a little place near others GUI Libraries 
when it will be more than a protytpe. I can see that all 
multi-platforms ones are wrappers and others only support 
Windows. I am a Windows user, but I don't understand why others 
platforms are forgotten.

Re: assert() vs. enforce(), invariant() vs. ... ?

[Brian Rogoff]

On Saturday, 31 August 2013 at 21:30:40 UTC, Andrei Alexandrescu 
wrote:



http://stackoverflow.com/questions/4711309/meaning-of-scope-in-d-for-a-parameter


That use will stay and is useful and uncontested.

Andrei


Sure, but my complaint is that that useful style is cramped by 
the inability to have scope on *local variables*. I understand 
that scope on function parameters will stay. If you're saying 
that scope on local variables for delegates will stay, then 
disregard all I've written here, I'm happy! :-).


If you look at the code I posted, try removing scope from the 2-D 
integrate and from the local variable declarations in the main() 
function, and the program hits the GC, with the scopes, they 
don't. The problem occurs when I create the local variables to 
name an anonymous function. I tested this with Adam Ruppe's code 
which halts when the GC is called.


As I said, I'm not arguing for scope on objects, but for 
contrivances which allow me to program easily with downward 
funargs and not hit the GC. D goes further than most languages in 
this and it would be a shame if this capability is removed with 
no substitute.


For those who want to test on their systems, here are the trivial 
unitCircle and unitSphere I omitted.



float unitCircle(float x) {
  float x2 = x * x;
  if (x2 < 1.0) {
return sqrt(1.0 - x2);
  } else {
return 0.0;
  }
}

float unitSphere(float x, float y) {
  float sum = x*x + y*y;
  if (sum <= 1.0) {
return sqrt(1.0 - sum);
  } else {
return 0.0;
  }
}


-- Brian

Re: Front-end release.NEXT

[H. S. Teoh]

On Sat, Aug 31, 2013 at 01:27:09PM -0700, Walter Bright wrote:
> On 8/31/2013 1:00 PM, H. S. Teoh wrote:
> >Oh, you mean the D equivalent of dlopen/dlsym/dlclose? That would be
> >*very* nice, if it can be made to work.
> 
> 
> It certainly can be made to work. Martin Nowak is close to getting it
> done.

Excellent! I presume it will be type-safe and support all the usual D
idioms? (I.e., none of that ugly mess with dlsym and C++, where casting
void* returned by dlsym() to a func ptr is undefined behaviour according
to the C++ spec).


T

-- 
The two rules of success: 1. Don't tell everything you know. -- YHL

Re: assert() vs. enforce(), invariant() vs. ... ?

[Andrei Alexandrescu]

On 8/31/13 1:34 PM, Brian Rogoff wrote:

On Friday, 30 August 2013 at 21:11:32 UTC, Andrei Alexandrescu wrote:

* scope: cute and dangerous in equal proportions - great for a movie
character, terrible for language design.


I'll argue for it and others can then destroy.

IME, a lot of the value of functional programming (by which I mean,
programming with higher order functions) can be had with downward
funargs, as found in Pascal (and more recently, Ada), which don't
require garbage collection.

The D language expresses closures and higher order functions as
delegates, and uses the heap to manage these. I had assumed that we
could use 'scope' on the delegate being passed to prevent it's heap
allocation, as discussed here:

http://stackoverflow.com/questions/4711309/meaning-of-scope-in-d-for-a-parameter


That use will stay and is useful and uncontested.

Andrei

Re: assert() vs. enforce(), invariant() vs. ... ?

[Brian Rogoff]

On Friday, 30 August 2013 at 21:11:32 UTC, Andrei Alexandrescu 
wrote:
* scope: cute and dangerous in equal proportions - great for a 
movie character, terrible for language design.


I'll argue for it and others can then destroy.

IME, a lot of the value of functional programming (by which I 
mean, programming with higher order functions) can be had with 
downward funargs, as found in Pascal (and more recently, Ada), 
which don't require garbage collection.


The D language expresses closures and higher order functions as 
delegates, and uses the heap to manage these. I had assumed that 
we could use 'scope' on the delegate being passed to prevent it's 
heap allocation, as discussed here:


  
http://stackoverflow.com/questions/4711309/meaning-of-scope-in-d-for-a-parameter


I wrote a small test case to try this out, in which I construct a 
2-D integration function from a 1-D one, and I use Adam Ruppe's 
nogc code to seg fault when the GC is hit. Without using a 
'scope' on a local variable, I'm forced to pile up the anonymous 
function calls to get the behavior I want.


import std.stdio, std.math;

// int delegate(int) adder(int a) { return (int b) { return a + 
b;}; }


float integrate(scope float delegate(float x) f, float lo, float 
hi, size_t n) {

  float result = 0.0;
  float dx = (hi - lo) / n;
  for (size_t i = 0; i < n; i++) {
result += f(lo + i * dx) * dx;
  }
  return result;
}

float integrate(scope float delegate(float, float) f,
 float x0, float x1,
 float y0, float y1,
 size_t nX, size_t nY) {
  scope auto f_y = delegate float(float y) =>
integrate(delegate(float x) => f(x,y), x0, x1, nX);

  return integrate(f_y, y0, y1, nY);

  // I'll have to write it like this to avoid heap allocation 
without

  // local variable scope
  // return integrate((y) => integrate((x) =>f(x,y), x0, x1, nX), 
y0, y1, nY);

}

The code to test demonstrates the issue better, as I'm forced to 
use inline anonymous functions everywhere to avoid the GC calls 
(unitCircle and unitSphere omitted for brevity)



void main() {
  scope auto funcX_1 = delegate float(float x) => unitCircle(x);
  float result1 = integrate(funcX_1 /* (x) => unitCircle(x) */, 
-1.0, 1.0, 500);

  writefln("integrate(func1, -1.0, 1.0, 500) = %g", result1);

  scope auto funcXY_1 = delegate float(float x, float y) => 
unitSphere(x,y);
  result1 = integrate(funcXY_1 /* (x,y) => unitSphere(x,y) */, 
-1.0, 1.0,  -1.0, 1.0, 100, 100);
  writefln("integrate(funcXY_1, -1.0, 1.0,  -1.0, 1.0, 100, 100) 
= %g", result1);

}

Yes, it's a toy example, but I do program with higher order 
functions a lot in OCaml and I'd probably use them quite a bit in 
D, especially if I could avoid impacting the GC.


If scope on local variables is going away, it would be nice if 
the compiler could figure out when I'm using delegate args in a 
'downward, non escaping' way and not heap allocate. My tests with 
DMD indicate that without those 'scope' on the local variable the 
GC does in fact get hit, and with them it does not.


-- Brian

PS: I don't really use classes much, so I have little to say 
about scope on objects


PPS: If my missive made little sense,

https://en.wikipedia.org/wiki/Funarg_problem
http://stackoverflow.com/questions/581182/what-are-downward-funargs

Re: assert() vs. enforce(), invariant() vs. ... ?

[Andrej Mitrovic]

On 8/31/13, Piotr Szturmaj  wrote:
> On 31.08.2013 21:52, Andrej Mitrovic wrote:
>> On 8/31/13, Jacob Carlborg  wrote:
>>> T delegate (Args) dg = &result.__ctor;
>>> dg(args);
>>
>> Ah, pretty cool workaround.
>
> Then, why not close that old bug?
>

It needs to be fixed first.

Re: Front-end release.NEXT

[Walter Bright]

On 8/31/2013 1:00 PM, H. S. Teoh wrote:

Oh, you mean the D equivalent of dlopen/dlsym/dlclose? That would be
*very* nice, if it can be made to work.



It certainly can be made to work. Martin Nowak is close to getting it done.

Re: Replacing std.xml

[Walter Bright]

On 8/29/2013 12:25 AM, w0rp wrote:

Hello everybody. I've been wondering, what are the current plans to replace
std.xml? I'd like to help with the effort to get a final XML library in phobos.
So, I have a few questions.

First, and most importantly, what do we except out of a D XML library? I'd
really like to have a discussion of the form, "Here is exactly the interface the
structs/classes need to implement, go forth and implement." The general idea in
my mind is "something SAX-like, with something a little DOM-like." I'm aware
that std.xml has some issues support different encodings, so obvious that's
included.

Second, is there an existing library that has gotten close to meeting whatever
we need for the first point? If so, how far away is it from being able to meet
all of the requirements and become the standard library version?


The Tango implementation of XML has been very well received. I haven't looked at 
it, but it was designed to do no memory allocation - it just did slices over the 
input.


I don't believe it should make any attempt at decoding. Decoding entails both 
performance loss and memory consumption. If the user wants to do decoding, they 
can layer it on the output.


And lastly, it should of course sport a range interface.

Re: assert() vs. enforce(), invariant() vs. ... ?

[Piotr Szturmaj]

On 31.08.2013 21:52, Andrej Mitrovic wrote:

On 8/31/13, Jacob Carlborg  wrote:

T delegate (Args) dg = &result.__ctor;
dg(args);


Ah, pretty cool workaround.


Then, why not close that old bug?

Re: std.serialization: pre-voting review / discussion

[Dicebot]

On Saturday, 31 August 2013 at 19:37:34 UTC, Jacob Carlborg wrote:

On 2013-08-31 20:51, Dicebot wrote:

Great. No hurry here, there is no hard deadline for voting - 
I'll put it
on pause until you are ready. Just doing some personal 
bookkeeping. No

pressure, just write me an e-mail when ready for next stage.


What I mean is that we usual have a couple of weeks for 
reviewing and then about one week for voting. I don't want to 
put the whole review queue on hold.


You won't. Reviewing is not a blocking operation, if anyone wants 
to acts as a review manager for some other contribution, nothing 
prevents from doing it right now. I have simply marked 
`std.serialization` as "Incorporating review comments" in wiki 
and given no new comments this round of review can be considered 
finished.

Re: Front-end release.NEXT

[H. S. Teoh]

On Sat, Aug 31, 2013 at 11:10:54AM -0700, Walter Bright wrote:
> On 8/31/2013 4:24 AM, Jacob Carlborg wrote:
> >On 2013-08-30 21:50, Walter Bright wrote:
> >
> >>I think it's a good idea.
> >>
> >>The only further enhancement I really want to get in this release is
> >>DLL support for Linux.
> >
> >Do you mean loading DLL's completely at runtime, i.e. using dlopen?
> >We have already shipped Phobos as a DLL.
> >
> 
> I mean that from a C or D program, being able to dynamically load
> and unload DLLs at runtime.

Oh, you mean the D equivalent of dlopen/dlsym/dlclose? That would be
*very* nice, if it can be made to work.


T

-- 
Many open minds should be closed for repairs. -- K5 user

Re: assert() vs. enforce(), invariant() vs. ... ?

[Andrej Mitrovic]

On 8/31/13, Jacob Carlborg  wrote:
> T delegate (Args) dg = &result.__ctor;
> dg(args);

Ah, pretty cool workaround.

Re: Replacing std.xml

[Jacob Carlborg]

On 2013-08-31 20:53, Michel Fortin wrote:


[^1]: IMHO, PullParser isn't a really good term for something that does
not conform to the requirements of a parser in the XML spec. Tokenizer
is a better term.


I guess "Pull" is the key here. That it is the client's responsibility 
to fetch the next token, not the other way around.


--
/Jacob Carlborg

Re: assert() vs. enforce(), invariant() vs. ... ?

[Jacob Carlborg]

On 2013-08-31 20:28, Andrej Mitrovic wrote:


Hmm... I hope this can actually work when there are multiple ctors,
how would the compiler know which of the ctors dg should be assigned
to?


Apparently you cannot use "auto" when having an overloaded symbol, so 
just use an explicit type:


T delegate (Args) dg = &result.__ctor;
dg(args);

--
/Jacob Carlborg

Re: Front-end release.NEXT

[Jacob Carlborg]

On 2013-08-31 20:10, Walter Bright wrote:


I mean that from a C or D program, being able to dynamically load and
unload DLLs at runtime.


I see.

--
/Jacob Carlborg

Re: std.serialization: pre-voting review / discussion

[Jacob Carlborg]

On 2013-08-31 20:51, Dicebot wrote:


Great. No hurry here, there is no hard deadline for voting - I'll put it
on pause until you are ready. Just doing some personal bookkeeping. No
pressure, just write me an e-mail when ready for next stage.


What I mean is that we usual have a couple of weeks for reviewing and 
then about one week for voting. I don't want to put the whole review 
queue on hold.


--
/Jacob Carlborg

Re: obsolete D libraries/modules

[Ramon]

On Saturday, 31 August 2013 at 18:44:52 UTC, Brad Anderson wrote:

On Friday, 30 August 2013 at 12:28:42 UTC, Wyatt wrote:

On Thursday, 29 August 2013 at 19:18:48 UTC, H. S. Teoh wrote:


Right now, having no way to actually update that site to add a
notice to this effect


On this point, when's the last time someone tried pinging him 
via email?  Is the whois for the domain not current?


-Wyatt


His email is supposedly brad at dsource.org.  I know people 
have had difficulty contacting him in the past but I've never 
tried myself.


And just to clarify, I'm not the same Brad Anderson that runs 
DSource (which has caused some confusion in the past).  I'm 
pretty sure neither of us talk in the third person.


He, the dsource guy, is Brad AndersEn from Atlanta, GA, according
to what little info is available. His whois email is at some
company that seems to have gone away or changed name or ...
dsource seems to be on a VPS at slicehost and, so it seems, just
one in some more sites on that virtual host.

It seems we shouldn't hold our breath to hear from Mr. Andersen,
unless someone here knows him personally and is in contact with
him.

But then, most people looking for D arrive here at dlang anyway.
I think, we should simply put some kind of marker here concering
dsource being comatose.

A+ -R

Re: DMD 2.064 alpha windows build

[Andrej Mitrovic]

On 8/31/13, Temtaime  wrote:
> You can get DMD source on DMD's github.

I'm asking about the modified version which uses tcmalloc. You've said
it compiles 2x faster, but faster to what? The regular MSVC build is
already known to be 2x faster than the one built with DMC.

Re: DMD 2.064 alpha windows build

[Temtaime]

You can get DMD source on DMD's github.

I've read DMD backend license, so it forbids to distribute DMD 
itself.


I've removed the archive. I'll investigate in LDC.

Re: std.serialization: pre-voting review / discussion

[Dicebot]

On Saturday, 31 August 2013 at 17:58:57 UTC, Jacob Carlborg wrote:

My todo list looks like this:

- write an overview documentation
- improve the documentation for std.serialization.serializable 
to indicate it's not required

- implement a convenience function for serializing
- implement a convenience function for serializing to a file
- remove Serializeable
- check only for "toData" when serializing
- check only for "fromData" when deserializing
- split Serializer in to two parts
- make the parts structs
- possibly provide class wrappers
- split Archive in two parts
- add range interface to Serializer and Archive
- rename all archives to archivers
- replace ddoc comments with regular comments for all package 
protected symbols


Although I'm guessing I won't be able to finish it in time for 
voting. How much time is it left anyway?


Great. No hurry here, there is no hard deadline for voting - I'll 
put it on pause until you are ready. Just doing some personal 
bookkeeping. No pressure, just write me an e-mail when ready for 
next stage.

Re: Replacing std.xml

[Michel Fortin]

On 2013-08-31 15:43:00 +, "ilya-stromberg" 
 said:



On Thursday, 29 August 2013 at 07:53:46 UTC, Tobias Pankrath wrote:
There is http://dsource.org/projects/xmlp, which at some point has been 
proposed for std.xml2. But that stalled for some time now.


Also, we have Tango Xml:
https://github.com/SiegeLord/Tango-D2/tree/d2port/tango/text/xml

It's the fastest Xml parser in the world, so may be you can find it useful:
dotnot.org/blog/archives/2008/03/10/xml-benchmarks-parsequerymutateserialize/
dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-parsing-xml/


Someone should benchmark it against the XML implementation I made. It 
has many of the same characteristics.


For instance, Tango's SaxParser is based on its PullParser. This design 
requires the use a dynamic array to maintain a stack of opened 
elements. While not a huge performance hit, you don't need that if you 
use recursion, which you can do with my implementation. You can do that 
even though you can also use it as a pull tokenizer[^1] when needed 
(recursion is optional on a token-by-token basis).


[^1]: IMHO, PullParser isn't a really good term for something that does 
not conform to the requirements of a parser in the XML spec. Tokenizer 
is a better term.


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

Re: Can not override template and nontemplate function

[Timon Gehr]

On 08/31/2013 06:39 PM, monarch_dodra wrote:



Although arguably, since foo is already in a parameterized context,
*ideally* it should already be infered (but that is not the case today).


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

Re: obsolete D libraries/modules

[Brad Anderson]

On Friday, 30 August 2013 at 12:28:42 UTC, Wyatt wrote:

On Thursday, 29 August 2013 at 19:18:48 UTC, H. S. Teoh wrote:


Right now, having no way to actually update that site to add a
notice to this effect


On this point, when's the last time someone tried pinging him 
via email?  Is the whois for the domain not current?


-Wyatt


His email is supposedly brad at dsource.org.  I know people have 
had difficulty contacting him in the past but I've never tried 
myself.


And just to clarify, I'm not the same Brad Anderson that runs 
DSource (which has caused some confusion in the past).  I'm 
pretty sure neither of us talk in the third person.

Re: obsolete D libraries/modules

[Andrei Alexandrescu]

On 8/31/13 11:12 AM, Jacob Carlborg wrote:

On 2013-08-31 19:11, Andrei Alexandrescu wrote:


Haven't seen Tango's arguments parser, but it's a given getopt can be
improved in any number of ways. Yet the way I see it, with command line
parsing, the margin between a good enough argument parser and a terrific
one is razor thin. One parses arguments by definition once in every
program, and things like checking against limits and constraints across
multiple arguments can be easily done after basic parsing.


I don't want this to start a huge argument about Tango versus Phobos.
But Tango supports this _now_, out of the box, Phobos doesn't. No need
to do any post processing. It's that simple.


I agree with the sentiment, but not with the example. It's just petty. 
There's no out-of-the-box vs it-could-be-built, it's just a difference 
without a distinction. We're talking about a few lines per application.



Again I don't understand why some people having so much trouble that
some developers here are using Tango.


In this case you're seeing things where they aren't. Speaking only for 
myself I think Tango is a fine library and I'm glad it's keeping 
traction in D.



Andrei

Re: assert() vs. enforce(), invariant() vs. ... ?

[Andrej Mitrovic]

On 8/31/13, Jacob Carlborg  wrote:
> Replace that line with:
>
> auto dg = &result.__ctor;
> dg(args);

Hmm... I hope this can actually work when there are multiple ctors,
how would the compiler know which of the ctors dg should be assigned
to?

Re: assert() vs. enforce(), invariant() vs. ... ?

[Andrej Mitrovic]

On 8/31/13, Andrei Alexandrescu  wrote:
> Library issues are a lot easier to deal with than core language issues.

Not when you have Kenji around!

Re: DMD 2.064 alpha windows build

[Andrej Mitrovic]

Do you have a source for this? I don't trust random binaries,
especially ones that are hosted on an .ru site..

On 8/31/13, Temtaime  wrote:
> Hi, guys!
> I've made DMD build using MSVC(ICC has some performance troubles)
> and tcmalloc, so it can compile more than 2x faster.
>
> http://acomirei.ru/u/dmd.7z
> It uses lastest DMD, druntime and Phobos.
>

Re: obsolete D libraries/modules

[Jacob Carlborg]

On 2013-08-31 19:11, Andrei Alexandrescu wrote:


Haven't seen Tango's arguments parser, but it's a given getopt can be
improved in any number of ways. Yet the way I see it, with command line
parsing, the margin between a good enough argument parser and a terrific
one is razor thin. One parses arguments by definition once in every
program, and things like checking against limits and constraints across
multiple arguments can be easily done after basic parsing.


I don't want this to start a huge argument about Tango versus Phobos. 
But Tango supports this _now_, out of the box, Phobos doesn't. No need 
to do any post processing. It's that simple. Again I don't understand 
why some people having so much trouble that some developers here are 
using Tango.


--
/Jacob Carlborg

Re: Can not override template and nontemplate function

[Jacob Carlborg]

On 2013-08-31 14:19, monarch_dodra wrote:


While we are at it, this is also the way to "force" attribute inference
on a function.


And force a function to appear with its implementation in interface 
files. Useful for CTFE.


--
/Jacob Carlborg

Re: Front-end release.NEXT

[Walter Bright]

On 8/31/2013 4:24 AM, Jacob Carlborg wrote:

On 2013-08-30 21:50, Walter Bright wrote:


I think it's a good idea.

The only further enhancement I really want to get in this release is DLL
support for Linux.


Do you mean loading DLL's completely at runtime, i.e. using dlopen? We have
already shipped Phobos as a DLL.



I mean that from a C or D program, being able to dynamically load and unload 
DLLs at runtime.

Re: assert() vs. enforce(), invariant() vs. ... ?

[Jacob Carlborg]

On 2013-08-31 14:03, Andrej Mitrovic wrote:


How will you pass a pointer to a constructor?


No, you invoke the constructor via a pointer.

https://github.com/D-Programming-Language/phobos/blob/master/std/conv.d#L4391

Replace that line with:

auto dg = &result.__ctor;
dg(args);

The static-if needs to be adjusted as well.

--
/Jacob Carlborg

Re: Replacing std.xml

[Jacob Carlborg]

On 2013-08-31 17:43, ilya-stromberg wrote:


Also, we have Tango Xml:
https://github.com/SiegeLord/Tango-D2/tree/d2port/tango/text/xml

It's the fastest Xml parser in the world, so may be you can find it useful:
dotnot.org/blog/archives/2008/03/10/xml-benchmarks-parsequerymutateserialize/

dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-parsing-xml/


Unfortunately the Tango XML package will never end up in Phobos due to 
licensing issues.


--
/Jacob Carlborg

Re: std.serialization: pre-voting review / discussion

[Jacob Carlborg]

On 2013-08-31 14:11, Dicebot wrote:

Jacob, what are your current plans on this (considering recent range API
discussion thread)?


My todo list looks like this:

- write an overview documentation
- improve the documentation for std.serialization.serializable to 
indicate it's not required

- implement a convenience function for serializing
- implement a convenience function for serializing to a file
- remove Serializeable
- check only for "toData" when serializing
- check only for "fromData" when deserializing
- split Serializer in to two parts
- make the parts structs
- possibly provide class wrappers
- split Archive in two parts
- add range interface to Serializer and Archive
- rename all archives to archivers
- replace ddoc comments with regular comments for all package protected 
symbols


Although I'm guessing I won't be able to finish it in time for voting. 
How much time is it left anyway?


--
/Jacob Carlborg

DMD 2.064 alpha windows build

[Temtaime]

Hi, guys!
I've made DMD build using MSVC(ICC has some performance troubles) 
and tcmalloc, so it can compile more than 2x faster.


http://acomirei.ru/u/dmd.7z
It uses lastest DMD, druntime and Phobos.

Re: obsolete D libraries/modules

[Andrei Alexandrescu]

On 8/31/13 4:21 AM, Jacob Carlborg wrote:

On 2013-08-30 20:19, Ramon wrote:


Thanks for the information and your thoughts. I'd like to ask one
more question on that, as I happened to work a little with
phobos' getopt and looked at your code and happened to notice
(your use of) tangos arg parsing/handling:
Why do you consider tangos arg parsing being better? Could you
kindly elaborate that somewhat? (Because I, possibly due to my
newbness, failed to see striking advantages in tangos arg parsing
when looking at Dstep).


I think the Tango version is more flexible and has more features.

With the Tango argument parser you can:

* Restrict values
* Specify the min and max number of arguments a given flag need to have
* Aliases
* Default value
* Conflict handling


Haven't seen Tango's arguments parser, but it's a given getopt can be 
improved in any number of ways. Yet the way I see it, with command line 
parsing, the margin between a good enough argument parser and a terrific 
one is razor thin. One parses arguments by definition once in every 
program, and things like checking against limits and constraints across 
multiple arguments can be easily done after basic parsing.



The Phobos version accepts weird syntax's like:

--t 4


Only if you tell it to!


Andrei

Re: assert() vs. enforce(), invariant() vs. ... ?

[Andrei Alexandrescu]

On 8/31/13 2:46 AM, Andrej Mitrovic wrote:

On 8/30/13, Andrei Alexandrescu  wrote:

* typedef: it was so ill defined, bringing it any closer to sanity
would've broken someone's code.


So it had to be properly defined in the spec and implemented.
Meanwhile we're fighting with the Phobos Typedef and it has way more
problems right now, some of which will likely be unsolvable. Bug
reports:

http://d.puremagic.com/issues/show_bug.cgi?id=10872
http://d.puremagic.com/issues/show_bug.cgi?id=10871
http://d.puremagic.com/issues/show_bug.cgi?id=10778
http://d.puremagic.com/issues/show_bug.cgi?id=8618
http://d.puremagic.com/issues/show_bug.cgi?id=
http://d.puremagic.com/issues/show_bug.cgi?id=7737


Most of these look approachable, and there are workarounds for the 
others. Granted, the UDT can't be made 100% like the old typedef (and 
probably that would be bad, too :o)).



* scope: cute and dangerous in equal proportions - great for a movie
character, terrible for language design.


scoped() has its own quirks, for example:
http://d.puremagic.com/issues/show_bug.cgi?id=4636
http://d.puremagic.com/issues/show_bug.cgi?id=5115
http://d.puremagic.com/issues/show_bug.cgi?id=10921

And this last bug that was filed (10921) was a bug that was known since 2010:
http://d.puremagic.com/issues/show_bug.cgi?id=5115#c6

So 3 years later, and it's still an issue. I don't even see how Issue
4636 can even be fixed, there's no way for a template in another
module to get private access to the class constructor.

---

Anyway, we've deprecated old keywords, and introduced half-implemented
library replacements. I don't see how we stand any better today than
we did before.


Library issues are a lot easier to deal with than core language issues.


Andrei

Re: assert() vs. enforce(), invariant() vs. ... ?

[Andrei Alexandrescu]

On 8/30/13 9:55 PM, Maxim Fomin wrote:

On Friday, 30 August 2013 at 21:11:32 UTC, Andrei Alexandrescu wrote:


* typedef: it was so ill defined, bringing it any closer to sanity
would've broken someone's code.


I haven't heard about any specific troubles with typedef which are
reason to depreciate the feature.


The problem is nobody could agree whether typedef was a supertype or a 
subtype of its original type. It was just a bizarre teratoma grown by 
happenstance.



In addition to typedef some other
features are also experiencing troubles (shared, ref, properties,
invariants,..) yet they are not deprecated.


That's not an argument.


* delete: a festering dung of unsafety straight in the middle of the
language.


It was useful to delete class objects at the time where programmer knew
that he can delete safely to mitigate the problem of dangling references
upon class finalization (by invoking dtor when objects are alive). Right
now there is no way to do that. By the way, currently dmd accepts
putting @safe attribute on class dtor definitions which access GC
objects - this is a hole in @safety (accessing such elements is not a
sufficient reason to be hole in safity, but not reseting pointers to
null is).


That would be a bug.


If there's enough argument that the functionality of delete is
actually desirable we can always add a function for that.


Probably yes.


* scope: cute and dangerous in equal proportions - great for a movie
character, terrible for language design.


Andrei


I cannot remember any feature implemented in phobos that was better then
built-in language construct, including scope. Hasn't C++ followed the
same policy and at the end it was considered as mistake?


Not sure I understand.


At least D has
many built-in features comparing to C++ and this is advertized as an
advantage.


I don't think that's how I see things.


Andrei

Re: Can not override template and nontemplate function

[monarch_dodra]

On Saturday, 31 August 2013 at 16:39:22 UTC, monarch_dodra wrote:
It's a trick that is useful when doing non-template functions 
inside a templated struct. EG:


struct S(T)
{
T t;
T foo()
{
return t;
}
}

Here, we don't know if foo is nothrow, as the postblit could 
throw, for example. If we make it a template, then the compiler 
deduces it for us.


Bad example, the "correct" example is one that uses voldermort 
typing:


auto foo(T)()
{
struct S //S is not a template
{
void bar(){}
}
return S();
}

void main() pure nothrow @system
{
auto s = foo!int();
s.bar(); //Error here!
}

but, again, arguably, that should have "just worked" (tm)

Re: Can not override template and nontemplate function

[monarch_dodra]

On Saturday, 31 August 2013 at 12:53:17 UTC, ilya-stromberg wrote:
On Saturday, 31 August 2013 at 12:19:17 UTC, monarch_dodra 
wrote:
While we are at it, this is also the way to "force" attribute 
inference on a function.


Can you print any code example, please?


//This function is @system, not pure, and throws.
void foo()
{}

//This function is @safe, pure and nothrow.
void bar()()


It's a trick that is useful when doing non-template functions 
inside a templated struct. EG:


struct S(T)
{
T t;
T foo()
{
return t;
}
}

Here, we don't know if foo is nothrow, as the postblit could 
throw, for example. If we make it a template, then the compiler 
deduces it for us.


Although arguably, since foo is already in a parameterized 
context, *ideally* it should already be infered (but that is not 
the case today).

Re: Replacing std.xml

[ilya-stromberg]

On Thursday, 29 August 2013 at 07:53:46 UTC, Tobias Pankrath 
wrote:
There is http://dsource.org/projects/xmlp, which at some point 
has been proposed for std.xml2. But that stalled for some time 
now.


Also, we have Tango Xml:
https://github.com/SiegeLord/Tango-D2/tree/d2port/tango/text/xml

It's the fastest Xml parser in the world, so may be you can find 
it useful:

dotnot.org/blog/archives/2008/03/10/xml-benchmarks-parsequerymutateserialize/
dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-parsing-xml/

Re: Front-end release.NEXT

[David Nadlinger]

On Saturday, 31 August 2013 at 11:24:41 UTC, Jacob Carlborg wrote:
Do you mean loading DLL's completely at runtime, i.e. using 
dlopen? We have already shipped Phobos as a DLL.


Yep, see 
https://github.com/D-Programming-Language/druntime/pull/593 and 
linked pull requests.


David

Re: Can not override template and nontemplate function

[Dicebot]

On Saturday, 31 August 2013 at 12:53:17 UTC, ilya-stromberg wrote:
On Saturday, 31 August 2013 at 12:19:17 UTC, monarch_dodra 
wrote:
While we are at it, this is also the way to "force" attribute 
inference on a function.


Can you print any code example, please?


AFAIK template function attributes are always inferred. So 
converting normal function to parameter-less template function 
forces it.

Re: Can not override template and nontemplate function

[ilya-stromberg]

On Saturday, 31 August 2013 at 12:19:17 UTC, monarch_dodra wrote:
While we are at it, this is also the way to "force" attribute 
inference on a function.


Can you print any code example, please?

Re: Can not override template and nontemplate function

[monarch_dodra]

On Saturday, 31 August 2013 at 11:22:17 UTC, Sönke Ludwig wrote:
Also, for completeness, it's possible to work around it for now 
using a parameter-less template:


void foo()(bool param)
{
  // ...
}
void foo(bool param)()
{
  // ...
}


While we are at it, this is also the way to "force" attribute 
inference on a function.

Re: std.serialization: pre-voting review / discussion

[Dicebot]

Jacob, what are your current plans on this (considering recent 
range API discussion thread)?

Re: assert() vs. enforce(), invariant() vs. ... ?

[Andrej Mitrovic]

On 8/31/13, Jacob Carlborg  wrote:
> A delegate/function pointer will bypass the protection.

How will you pass a pointer to a constructor?

Re: Front-end release.NEXT

[Andrej Mitrovic]

On 8/30/13, Walter Bright  wrote:
> The only further enhancement I really want to get in this release is DLL
> support for Linux.

And if it's (mostly) done, we should put it in the changelog, since
it's a pretty big deal!

Re: assert() vs. enforce(), invariant() vs. ... ?

[Jacob Carlborg]

On 2013-08-31 11:46, Andrej Mitrovic wrote:


So 3 years later, and it's still an issue. I don't even see how Issue
4636 can even be fixed, there's no way for a template in another
module to get private access to the class constructor.


A delegate/function pointer will bypass the protection.

--
/Jacob Carlborg

Re: obsolete D libraries/modules

[Jacob Carlborg]

On 2013-08-30 20:19, Ramon wrote:


Thanks for the information and your thoughts. I'd like to ask one
more question on that, as I happened to work a little with
phobos' getopt and looked at your code and happened to notice
(your use of) tangos arg parsing/handling:
Why do you consider tangos arg parsing being better? Could you
kindly elaborate that somewhat? (Because I, possibly due to my
newbness, failed to see striking advantages in tangos arg parsing
when looking at Dstep).


I think the Tango version is more flexible and has more features.

With the Tango argument parser you can:

* Restrict values
* Specify the min and max number of arguments a given flag need to have
* Aliases
* Default value
* Conflict handling

The Phobos version accepts weird syntax's like:

--t 4

--
/Jacob Carlborg

Re: obsolete D libraries/modules

[Jacob Carlborg]

On 2013-08-30 18:55, Artur Skawina wrote:


The question was not about Tango.


Oh, my bad.

--
/Jacob Carlborg

Re: Front-end release.NEXT

[Jacob Carlborg]

On 2013-08-30 21:50, Walter Bright wrote:


I think it's a good idea.

The only further enhancement I really want to get in this release is DLL
support for Linux.


Do you mean loading DLL's completely at runtime, i.e. using dlopen? We 
have already shipped Phobos as a DLL.


--
/Jacob Carlborg

Re: Can not override template and nontemplate function

[Sönke Ludwig]

Am 31.08.2013 12:53, schrieb Andrej Mitrovic:

On 8/31/13, ilya-stromberg  wrote:

D can not override template and nontemplate function.


It was a long-standing bug which was fixed in git-head and will work
in the 2.064 release.



Also, for completeness, it's possible to work around it for now using a 
parameter-less template:


void foo()(bool param)
{
  // ...
}
void foo(bool param)()
{
  // ...
}

Re: Linking C & extern(C) on OS X: duplicate symbols not flagged

[Jacob Carlborg]

On 2013-08-30 16:10, "Luís Marques" " wrote:


That fails, as expected.


So DMD and Clang uses different sections? Have you tried GDC or LDC?

--
/Jacob Carlborg

Re: Can not override template and nontemplate function

[Andrej Mitrovic]

On 8/31/13, ilya-stromberg  wrote:
> D can not override template and nontemplate function.

It was a long-standing bug which was fixed in git-head and will work
in the 2.064 release.

Can not override template and nontemplate function

[ilya-stromberg]

D can not override template and nontemplate function:

void foo(bool param)
{
if(param)
{
//do something useful
}
else
{
//do something else
}
}

void foo(bool param)()
{
static if(param)
{
//do something useful
}
else
{
//do something else
}
}

void main()
{
}

dmd output:
src/main.d(13): Error: template main.foo(bool param)() conflicts 
with function main.foo at src/main.d(1)


Does exist any reason to deny this, or it's just compiler bug?
I think that compiler can always understand what I want:

//nontemplate function call
foo(true);
//template function call
foo!true();

Re: assert() vs. enforce(), invariant() vs. ... ?

[Andrej Mitrovic]

On 8/30/13, Andrei Alexandrescu  wrote:
> * typedef: it was so ill defined, bringing it any closer to sanity
> would've broken someone's code.

So it had to be properly defined in the spec and implemented.
Meanwhile we're fighting with the Phobos Typedef and it has way more
problems right now, some of which will likely be unsolvable. Bug
reports:

http://d.puremagic.com/issues/show_bug.cgi?id=10872
http://d.puremagic.com/issues/show_bug.cgi?id=10871
http://d.puremagic.com/issues/show_bug.cgi?id=10778
http://d.puremagic.com/issues/show_bug.cgi?id=8618
http://d.puremagic.com/issues/show_bug.cgi?id=
http://d.puremagic.com/issues/show_bug.cgi?id=7737

> * scope: cute and dangerous in equal proportions - great for a movie
> character, terrible for language design.

scoped() has its own quirks, for example:
http://d.puremagic.com/issues/show_bug.cgi?id=4636
http://d.puremagic.com/issues/show_bug.cgi?id=5115
http://d.puremagic.com/issues/show_bug.cgi?id=10921

And this last bug that was filed (10921) was a bug that was known since 2010:
http://d.puremagic.com/issues/show_bug.cgi?id=5115#c6

So 3 years later, and it's still an issue. I don't even see how Issue
4636 can even be fixed, there's no way for a template in another
module to get private access to the class constructor.

---

Anyway, we've deprecated old keywords, and introduced half-implemented
library replacements. I don't see how we stand any better today than
we did before.