Re: Build Master: Scheduling

[Jacob Carlborg]

On 2013-11-15 00:36, Nick wrote:

I have no idea what everyone is getting worked up about. My
understanding of the plan is that there are biannual major releases,
with bug fix releases in-between, for those people/companies who need
stability/dependability.

In addition to that we have monthly 'beta' releases for those who want
the latest and greatest but know that a few things may get changed
around between the releases that break code and that there are likely to
be more bugs.

So all the passionate D devs here get their monthly releases, and the
people who want maximum stability get a biannual, LTS release along with
some bug fix releases.


The opposite of an LTS release is _not_ a beta release. It's a regular 
release. It seems it would be better if the beta release were regular 
releases and the releases were LTS releases.


I'm having a hard time requiring my users to use anything that is not a 
release (that is, a beta).


--
/Jacob Carlborg

Re: Build Master: Scheduling

[Jacob Carlborg]

On 2013-11-15 02:33, Jesse Phillips wrote:


How? It is the same as Tyro[17] describes only with 2 month rather than
6 month releases. The page just goes into great detail about how to
achieve it, which is complex.


Yeah, it has all the git commands, you don't have to read those.

--
/Jacob Carlborg

Re: DIP 50 - AST macros

[Jacob Carlborg]

On 2013-11-14 21:54, Walter Bright wrote:


If it is powerful enough to do async/await but look like normal D
syntax, then is going to suffer from these faults.


I don't think so. The idea is to have it look consistent within the 
language. Take a look at __traits. It looks just like a function call, 
but it's far from being a function call. Classes and structs look very 
similar, only the keyword is different, but they are very different.


--
/Jacob Carlborg

Re: Ehem, ARM

[Jacob Carlborg]

On 2013-11-15 02:50, Michel Fortin wrote:


Still no modern runtime support I'd guess? With support only for the
legacy runtime you're stuck compiling for 32-bit OS X only; 32-bit iOS
uses the modern runtime.


Right, I forgot about that. I haven't done a single thing on this since 
the last time I announced it.



And since the DMD backend won't emit ARM code, if I were still working
on this the first thing I'd do is rebase everything to work on top of LDC.


I think that would be quite difficult. Although it would probably be 
easier to get 64bit and modern runtime support. An advantage of doing it 
in DMD (except that it's already in DMD) is that it's probably a bigger 
chance of it being officially added to D and not just an extension to 
LDD. If it's added to DMD it will automatically be merged by both LDC 
and GDC.


Another idea would be to add it to DMD with the current platform 
support. Then when it's merged with LDC, let them add support for ARM, 
64bit and modern runtime.


BTW, do you automatically scan the newsgroups for 
"http://michelf.ca/projects/d-objc/"; :)


--
/Jacob Carlborg

Re: DIP 45 - approval discussion

[Walter Bright]

On 11/14/2013 5:31 AM, Benjamin Thaut wrote:

Am 14.11.2013 11:28, schrieb Walter Bright:


This of course means that functions may wind up going through the
dllimport indirection even for calling functions in the same dll, but it
should work.


Also our suggested approach would not have this downside.

Think about phobos. All of phobos and druntime will be littered with export
attributes. Do you really want all phobos and druntime from within the same dll
to go through dll indirections? And what would happen when building phobos as
static library? With your suggested behavior (export=dllimport if not specified
otherwise) this would mean that even the phobos static library would have those
indirections.



It's not that bad. Phobos can be built by specifying all the files on the 
command line.


Also, at least on Windows, you can call functions in a DLL without saying 
dllimport on them and suffering a layer of indirection. The magic happens in the 
import library, which provides the relevant thunk. It's about 15 years since I 
worked on this stuff, so I might be a bit fuzzy on the details.

Re: Ehem, ARM

[Jacob Carlborg]

On 2013-11-15 00:35, Manu wrote:


Very good point. I wonder if there's room to make a push for this in 2.065.


Highly  unlikely. It seems like Walter wanted us to first implement ARC, 
to not be worse the Objective-C currently is. But we haven't been able 
to come to an agreement on how to do that.


As Michel noted it currently only supports 32bit and the legacy runtime. 
Although I think it still would be usable to include, even without ARC 
and 64bit/modern runtime. It will just get harder to keep up to date the 
longer time it takes.


http://forum.dlang.org/thread/kq7li9$2j9v$1...@digitalmars.com?page=4#post-kqcm79:241eqf:241:40digitalmars.com

http://forum.dlang.org/thread/l34lei$255v$1...@digitalmars.com

--
/Jacob Carlborg

Re: DIP 45 - approval discussion

[Walter Bright]

On 11/14/2013 3:37 AM, Benjamin Thaut wrote:

Am 14.11.2013 11:28, schrieb Walter Bright:

On 11/12/2013 2:23 PM, Martin Nowak wrote:

One possibility is modules listed on the command line are regarded as
export==dllexport, and other modules as export==dllimport.

This of course means that functions may wind up going through the
dllimport indirection even for calling functions in the same dll, but it
should work.


That doesns't work for the case where a dll "A" uses a dll "B".
In that case export has to mean "dllexport" for all modules of A but "dllimport"
for all modules of B.


I don't follow. If you're compiling A, you're specifying A modules on the 
command line, and those will regard the B modules as dllimport.

Re: Ehem, ARM

[Paulo Pinto]

On Friday, 15 November 2013 at 06:18:00 UTC, Joakim wrote:

On Friday, 15 November 2013 at 00:18:50 UTC, Martin Nowak wrote:

On 11/14/2013 05:14 PM, Kai Nacke wrote:
But this is only half of the story. My target is Linux/ARM 
which is
already supported by druntime/phobos. If you target a 
smartphone then
you also have to add Android or iOS support to 
druntime/phobos.


Currently version (linux) in druntime is equivalent to glibc.
Porting druntime to bionic or newlib might be quite an effort 
but I have no concrete idea what issues to expect.


As Kai says, has anyone worked on getting D running on Android 
before?  I've been thinking about attempting an Android port 
for years.  I thought I'd spin up some x86 VMs this weekend and 
take a crack at getting D working on Android/x86 
(http://www.android-x86.org/) as a first step.  If anyone has 
started on this already, I could chip in on their branch.


Also, does dmd have any support for cross-compilation or is it 
better to stick to ldc/gdc when cross compiling to Android?


On a related note, it looks like Rust was ported to Android/ARM 
earlier this year:


https://github.com/mozilla/rust/wiki/Doc-building-for-android


Yes, have a look at an initial port of GDC to Android

https://bitbucket.org/goshawk/gdc/wiki/GDC%20on%20Android

Re: Look and think good things about D

[qznc]

On Friday, 15 November 2013 at 01:09:53 UTC, bearophile wrote:
I have created two interesting D entries for this Rosettacode 
Task, is someone willing to create a Reddit entry for this? 
They show very different kinds of code in D.


http://rosettacode.org/wiki/Look-and-say_sequence#D


The fast version is nearly functional, too. Since memory 
management is not considered a side effect there is only the 
printfs. If the printfs are wrapped into "debug", the function is 
pure.

Re: DIP 45 - approval discussion

[Benjamin Thaut]

Am 15.11.2013 00:38, schrieb Rainer Schuetze:


Maybe. Another rule might be that only the declarations actually
annotated with "export" gets exported with the instantiation, so you
could add "export" to the whole class or only some declaraations.



I don't think this is a good idea. It should be possible to put 
"export:" on top of a file and just export everything. If you limit it 
to decelerations the following would work:


export __gshared int g_var;

but the following wouldn't:

export __gshared int g_var = 0;

Although it would really produce equivalent code.



compiling c and d as single files will silently generate different code,
because when compiling d, the export alias is never seen.

(this cannot happen with standard variables, only when declared multiple
times, but differently, with extern(C/C++/System)).


And do you already have a idea how we could work around this problem?

Kind Regards
Benjamin Thaut

buffer overflow detected __fortify_fail when building dmd from source

[Timothee Cour]

on one ubuntu64 box (ubuntu 12.04) (call it A), compiling from source (from
 dmd.2.064.2.zip and following http://dlang.org/dmd-linux.html), I get:

$cd src/dmd
$make -f posix.mak -j8
*fatal: Not a git repository (or any of the parent directories): .git*
#but compiles ok
$cd ../druntime
$make -f posix.mak -j8 DMD=../dmd/dmd
#ok...
$cd ../phobos
$make -f posix.mak -j8 DMD=../dmd/dmd
*awk: cannot open ../dmd/VERSION (No such file or directory) *#repeated
several times
The 'crc32' module has been scheduled for *deprecation*. Please use
'std.digest.crc' instead.
std.md5 is scheduled for *deprecation*. Please use std.digest.md instead

and indeed, VERSION is in ../VERSION, not ../dmd/VERSION


on another ubuntu64 box (call it B), I cannot even compile from source
unless I pass DEBUG=1 flag;

without DEBUG=1 I get (after cleaning up everything):

$cd src/dmd
$make -f posix.mak -j8
#ok till this point
$cd ../druntime
$make -f posix.mak -j8 DMD=../dmd/dmd
../dmd/dmd -lib -oflib/libdruntime-linuxdefault.a -Xfdruntime.json ...#etc

*** *buffer overflow detected* ***: ../dmd/dmd terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6
#also shows those symbols:
__fortify_fail
_IO_default_xsputn
_IO_vfprintf
__vsprintf_chk
__sprintf_chk
../dmd/dmd
__libc_start_main
../dmd/dmd
=== Memory map: 

I get the same from git master.


with DEBUG=1 it works (but with same quirks as above)

Re: Ehem, ARM

[Joakim]

On Friday, 15 November 2013 at 00:18:50 UTC, Martin Nowak wrote:

On 11/14/2013 05:14 PM, Kai Nacke wrote:
But this is only half of the story. My target is Linux/ARM 
which is
already supported by druntime/phobos. If you target a 
smartphone then

you also have to add Android or iOS support to druntime/phobos.


Currently version (linux) in druntime is equivalent to glibc.
Porting druntime to bionic or newlib might be quite an effort 
but I have no concrete idea what issues to expect.


As Kai says, has anyone worked on getting D running on Android 
before?  I've been thinking about attempting an Android port for 
years.  I thought I'd spin up some x86 VMs this weekend and take 
a crack at getting D working on Android/x86 
(http://www.android-x86.org/) as a first step.  If anyone has 
started on this already, I could chip in on their branch.


Also, does dmd have any support for cross-compilation or is it 
better to stick to ldc/gdc when cross compiling to Android?


On a related note, it looks like Rust was ported to Android/ARM 
earlier this year:


https://github.com/mozilla/rust/wiki/Doc-building-for-android

Re: DIP 50 - AST macros

[dennis luehring]

Am 14.11.2013 21:54, schrieb Walter Bright:

(A lot of the C++ macro abuse looks like normal syntax to the user, but it
behaves in a way that the casual user would find completely unexpected.


same can be said about Boost Spirit templates

Re: Look and think good things about D

[bearophile]

Meta:

I didn't look that closely at the imperative code, but it seems 
to be quite a bit longer than most of the other imperative 
examples. Is this because it's super-optimized?


Yes, it's longer because it's optimized.

Bye,
bearophile

Re: Look and think good things about D

[Meta]

On Friday, 15 November 2013 at 01:09:53 UTC, bearophile wrote:
I have created two interesting D entries for this Rosettacode 
Task, is someone willing to create a Reddit entry for this? 
They show very different kinds of code in D.


http://rosettacode.org/wiki/Look-and-say_sequence#D

Bye,
bearophile


I didn't look that closely at the imperative code, but it seems 
to be quite a bit longer than most of the other imperative 
examples. Is this because it's super-optimized?

Re: Look and think good things about D

[bearophile]

Rob T:


Timings for short functional version vs fast would be nice.


Below the two I have added a note to compare the run-times.

Bye,
bearophile

Re: Look and think good things about D

[bearophile]

OK. On the other hand regarding speed the fast version is in 
another world. So the speed comparison will become a little 
silly.


The first program doesn't even compile with ldc2 v.2.063.2, and 
the two programs are quite different in scope...


Bye,
bearophile

Re: Ehem, ARM

[Michel Fortin]

On 2013-11-14 19:14:03 +, Jacob Carlborg  said:


On 2013-11-14 17:21, Chris wrote:


Thanks for your reply, Kai. That's good news, however iOS and Android
support is crucial. I hope D can soon be ported to ARM, it's just too
important.


If you want to do anything useful on iOS you need to use Objective-C 
libraries, for that you bascilly need this:


http://michelf.ca/projects/d-objc/

Latest update, but still quite outdated: 
https://github.com/jacob-carlborg/dmd/tree/d-objc


Still no modern runtime support I'd guess? With support only for the 
legacy runtime you're stuck compiling for 32-bit OS X only; 32-bit iOS 
uses the modern runtime.


And since the DMD backend won't emit ARM code, if I were still working 
on this the first thing I'd do is rebase everything to work on top of 
LDC.


Once upon a time, I did port a D game to iOS. I translated it to C++. 
But the amount of Objective-C code was pretty minimal at the end. If I 
had an ARM-capable D compiler at that time, even with no Objective-C 
support, I could have lived happily with D.

http://michelf.ca/projects/tumiki-fighters/

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

Re: Look and think good things about D

[bearophile]

Rob T:


Timings for short functional version vs fast would be nice.


OK. On the other hand regarding speed the fast version is in 
another world. So the speed comparison will become a little silly.


--

Martin Nowak:


len.uninitializedArray ? Isn't this too much UFCS?


I think it's just enough of UFCS.

Bye,
bearophile

Re: Does 2.064 support shared libraries?

[Martin Nowak]

On 11/14/2013 07:32 PM, Frusdrated wrote:

First: Does 2.064 fully support shared libraries? It seems there were
previous indications that it would.
Not ready yet. You can use link against shared libraries and the 
low-level support for dynamic loading is done.

Re: Build Master: Scheduling

[Jesse Phillips]

On Friday, 15 November 2013 at 00:30:09 UTC, Martin Nowak wrote:

On 11/14/2013 09:18 AM, tn wrote:
What is wrong with the process that is described in the wiki 
(and that I

thought you already agreed on)? See

http://wiki.dlang.org/Development_and_Release_Process


It's too complex.


How? It is the same as Tyro[17] describes only with 2 month 
rather than 6 month releases. The page just goes into great 
detail about how to achieve it, which is complex.

Re: Look and think good things about D

[Rob T]

On Friday, 15 November 2013 at 01:09:53 UTC, bearophile wrote:
I have created two interesting D entries for this Rosettacode 
Task, is someone willing to create a Reddit entry for this? 
They show very different kinds of code in D.


http://rosettacode.org/wiki/Look-and-say_sequence#D

Bye,
bearophile


Using the LDC2 compiler with n=70 the run-time is about 3.74 
seconds.


Timings for short functional version vs fast would be nice.

--rt

Re: Look and think good things about D

[Martin Nowak]

On 11/15/2013 02:09 AM, bearophile wrote:

I have created two interesting D entries for this Rosettacode Task


len.uninitializedArray ? Isn't this too much UFCS?

Re: Build Master: Scheduling

[Rob T]

On Thursday, 14 November 2013 at 20:30:40 UTC, Dicebot wrote:

On Thursday, 14 November 2013 at 20:27:23 UTC, Rob T wrote:
Bug fixes should be as frequent as possible. To understand 
why, just try and find a good reason to artificially hold back 
a bug fix.


Code breakage. DMD has good amount of accepts-invalid bugs.


Code that is invalid but compiles is already broken by 
definition. These are potentially silent bugs in the code base, 
which are never good for anyone. I'd rather know about 
accepted-invalid code sooner in a development environment than 
later in an production environment.


Furthermore, holding back on fixing accepts-invalid will allow 
more invalid code to sneak into the ever expanding code base, 
making the problem worse over time.


--rt

Look and think good things about D

[bearophile]

I have created two interesting D entries for this Rosettacode 
Task, is someone willing to create a Reddit entry for this? They 
show very different kinds of code in D.


http://rosettacode.org/wiki/Look-and-say_sequence#D

Bye,
bearophile

Re: Build Master: Scheduling

[Martin Nowak]

On 11/15/2013 12:36 AM, Nick wrote:

I have no idea what everyone is getting worked up about. My
understanding of the plan is that there are biannual major releases,
with bug fix releases in-between, for those people/companies who need
stability/dependability.

In addition to that we have monthly 'beta' releases for those who want
the latest and greatest but know that a few things may get changed
around between the releases that break code and that there are likely to
be more bugs.

So all the passionate D devs here get their monthly releases, and the
people who want maximum stability get a biannual, LTS release along with
some bug fix releases.


I too think it's a good plan. Many new features need a few month until 
they are stable.

Also the 6 month nicely match our deprecation cycle.
There is only one maintenance release in parallel to the master/beta 
branch which reduces the backporting effort.

We still need automate more of the release building.

Re: Build Master: Scheduling

[Martin Nowak]

On 11/14/2013 09:18 AM, tn wrote:

What is wrong with the process that is described in the wiki (and that I
thought you already agreed on)? See

http://wiki.dlang.org/Development_and_Release_Process


It's too complex.

Re: Cache prefetching

[Marco Leise]

Am Fri, 15 Nov 2013 00:31:40 +0100
schrieb "bearophile" :

> A simple article that shows a nice usage of __builtin_prefetch:
> 
> http://www.naftaliharris.com/blog/2x-speedup-with-one-line-of-code/
> 
> Bye,
> bearophile

Whenever I try that it doesn't seem to do anything :-(
Good to see that others have more luck. And always remember
that x86 has multiple prefetchers that detect sequential
memory access in either direction. So in theory you only need
manual prefetching if you have random access and still have
some CPU cycles to fill with calculations on the current data
before you need the next block.

-- 
Marco

Re: [Poll] On Linux, what should we commonly use as sub-directory name for D?

[Marco Leise]

Am Fri, 15 Nov 2013 00:03:42 +0100
schrieb Marco Leise :

> Am Thu, 14 Nov 2013 21:35:22 +0100
> schrieb Johannes Pfau :
> 
> > AFAIK you can't put shared libraries into a different folder.
> > The runtime linker must be able to find the libraries so the folders
> > have to be registered in ld.so.conf. But ld 'virtually merges' all
> > directories so you still can't have libraries with the same name &
> > version in different folders. There are some tricks (rpath,
> > LD_LIBRARY_PATH) but this won't work well in a large scale scenario.
> 
> That explains why Haskell's Cabal is installing libraries with
> compiler AND library version in the file name :-/

That doesn't read too bad:
http://en.wikipedia.org/wiki/Rpath#GNU_ld.so
So -rpath basically just hints at the library location.
CMake has more or less direct support for it:
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")

The other option would be to install a symlink foo.so into the
compiler specific lib directory that links
to /usr/lib/foo-dmd.so.X.Y that has an soname of "foo.so.X".
But I feel that would confuse the pants off of people.

-- 
Marco

Re: Ehem, ARM

[Martin Nowak]

On 11/14/2013 05:14 PM, Kai Nacke wrote:

But this is only half of the story. My target is Linux/ARM which is
already supported by druntime/phobos. If you target a smartphone then
you also have to add Android or iOS support to druntime/phobos.


Currently version (linux) in druntime is equivalent to glibc.
Porting druntime to bionic or newlib might be quite an effort but I have 
no concrete idea what issues to expect.

Re: DIP 45 - approval discussion

[Rainer Schuetze]

On 14.11.2013 18:25, Benjamin Thaut wrote:

Am 14.11.2013 08:36, schrieb Rainer Schuetze:




As far as I understand, the optimization avoids generating code for
template instances only _created_ (not defined) by imported modules,
e.g. when needed for semantic analysis inside the imported module, but
never actually referenced by generated code by the root modules.

[OT: The problem of the current implementation is the detection of
"only" in that definition, it fails too often leading to linker errors
and the addition of that terrible -allinst switch. I had to disable the
optimization for me before addition of that switch.]

With respect to export I guess the optimization doesn't change much as
multiple instances of the same template instance still can be found in
different object files (maybe even less predictable).

To avoid the trouble with templates, here is an idea for discussion:

- templates definitions by themselves are never dllexport/dllimport

- template instances are dllexport/dllimport with the proposed semantics
of normal functions/variables if they are explicitely declared as
"export" by an alias statement, e.g.

   export alias templ!int exported_tmpl_int;

- implicitely created template instances don't create dllexport
versions, and use dllimport semantics if the declaration above is found
in an import.


I actually like this idea. Everytime I actually had to dllexport /
dllimport templates in C++ I knew beforehand which types I need the
template exported for.

But what would should in a case like this:

class WeakReferenced(T)
{
   export __gshared WeakReferenced!T[] m_weakTable;
}


According to the rule above "export" on the template definition has no 
effect, only when it is instantiated with


export alias WeakReferenced!int WeakRefIntArray;



Note that the export is not applied to the template directly but instead
to a specific member inside the template.

Should this be an error?


Maybe. Another rule might be that only the declarations actually 
annotated with "export" gets exported with the instantiation, so you 
could add "export" to the whole class or only some declaraations.






- It's worse for the dllimport case, as data accesses to template
variables will sometimes use the additional indirection, sometimes not.


Why exactly is that? Would that also be the case with the system
proposed by the DIP? The dip never actually uses dllimport, so shouldn't
it just work (tm)?



The problem is that the template instantiation can exist without the 
compiler seeing the alias:


---
module a;
class tmpl(T) { static shared int var; }

---
module b;
import a;
export alias tmpl!int tmpl_int;

---
module c;
import b;
int func() { return tmpl!int.var; } // uses dllimport access with 
indirection


---
module d;
import a;
int fund() { return tmpl!int.var; } // uses standard access without 
indirection


compiling c and d as single files will silently generate different code, 
because when compiling d, the export alias is never seen.


(this cannot happen with standard variables, only when declared multiple 
times, but differently, with extern(C/C++/System)).

Re: Build Master: Scheduling

[Nick]

I have no idea what everyone is getting worked up about. My 
understanding of the plan is that there are biannual major 
releases, with bug fix releases in-between, for those 
people/companies who need stability/dependability.


In addition to that we have monthly 'beta' releases for those who 
want the latest and greatest but know that a few things may get 
changed around between the releases that break code and that 
there are likely to be more bugs.


So all the passionate D devs here get their monthly releases, and 
the people who want maximum stability get a biannual, LTS release 
along with some bug fix releases.

Re: Qt5 and D

[Xavier Bigand]

Le 14/11/2013 13:03, Russel Winder a écrit :

Has anyone done any work with QML and D?

Gustavo Niemeyer is creating a QML package for Go and it is already
getting a lot of traction.

I have a little pet project where I am comparing PyQt5 and Go, and I
would like to try using D as a third variant, but I don't wan't to have
to use Gtk for the D version I want to use the same UI for all variants.

Thanks.


What do you mean exactly by same UI? Same QML files directly?

Because it's hard to port/Wrap Qt to D, I am working on a project that 
is based on QML principles (Property binding, Components,...). It's 
called DQuick.


It's only a prototype for the moment, and it will certainly never 
compatible with QML files. But if you are only interested by property 
binding and the composition system of QML, DQuick will make you happy.

Re: Ehem, ARM

[Manu]

On 15 November 2013 05:14, Jacob Carlborg  wrote:

> On 2013-11-14 17:21, Chris wrote:
>
>  Thanks for your reply, Kai. That's good news, however iOS and Android
>> support is crucial. I hope D can soon be ported to ARM, it's just too
>> important.
>>
>
> If you want to do anything useful on iOS you need to use Objective-C
> libraries, for that you bascilly need this:
>
> http://michelf.ca/projects/d-objc/
>
> Latest update, but still quite outdated: https://github.com/jacob-
> carlborg/dmd/tree/d-objc


Very good point. I wonder if there's room to make a push for this in 2.065.

Cache prefetching

[bearophile]

A simple article that shows a nice usage of __builtin_prefetch:

http://www.naftaliharris.com/blog/2x-speedup-with-one-line-of-code/

Bye,
bearophile

Re: Build Master: Scheduling

[Xavier Bigand]

Le 14/11/2013 09:39, luka8088 a écrit :

On 14.11.2013. 5:29, Tyro[17] wrote:

On 11/13/13, 11:06 PM, Brad Roberts wrote:

On 11/13/13 7:13 PM, Tyro[17] wrote:

On 11/13/13, 9:46 PM, Brad Roberts wrote:

On 11/13/13 4:37 PM, Tyro[17] wrote:

I'm of the opinion, however, that
the cycle should be six months long. This particular schedule is not
of my own crafting but I
believe it to be sound and worthy of emulation:


I think 6 months between releases is entirely too long.  I'd really
like
us to be back closer to the once every month or two rather than only
twice a year.  The pace of change is high and increasing (which is a
good thing).  Release early and often yields a smoother rate of
introducing those changes to the non-bleeding-edge part of the
community.  The larger the set of changes landing in a release the more
likely it is to be a painful, breaking, experience.


Surely for those of us that live on the edge, it is fun to be able to
use the latest and greatest.
Hence the reason for monthly release of betas. Within a month
(sometimes shorter) of any new feature
being implemented in the language, you'll be able to download the
binaries for your favorite distro
and begin testing it.

The side effect is that there is more time to flesh out a particular
implementation and get it
corrected prior to it being an irreversible eyesore in the language.
You also have a greater play in
the filing bug reports as to aid in minimizing the number of bugs that
make it into the final release.

Unlike us adventurers however, companies require a more stable
environment to work in. As such, the
six month cycle provides a dependable time frame in which they can
expect to see only bugfixes in to
the current release in use.

I think this release plan is a reasonable compromise for both parties.


Companies that don't want frequent changes can just skip releases, using
whatever update frequency meets their desires.  Companies do this
already all the time.  That only issue there is how long we continue to
backport fixes into past releases.  So far we've done very minimal
backporting.




And what I am proposing is that we start backporting to stable releases
and with subsequent bugfix releases.

I'm also suggesting that for people interested in a more frequent
release will have at least five, if not more, such releases (betas)
prior to the official release. Live on the edge... use the beta. That's
what we do now.

At the moment there's nothing that make dmd.2.064.2 any more bug free
than its previously released counterparts. Very few people participated
in the review of the betas which were released arbitrarily (when the
time seemed right). We simply call on of those betas dmd.2.064.2 and
moved on. It still has a slew of bugs and more are discovered daily as
people start to finally use the so called  "release".

I'm saying we are go about it a little different. We get more people
involved in the testing process by providing more frequent release of
betas and getting much of the bugs identified fixed before designating a
release. To me you get what your are after a faster turnaround on fixes
(monthly). And the broader customer base gets a more stable product with
less bugs.



Just a wild thought...

Maybe we can have monthly release and still keep it stable. Imagine this
kind of release schedule:

Month #  11  12  1   2   3

  2.064   2.065   2.066   2.067   2.068
  2.065rc22.066rc22.067rc22.068rc22.069rc2
  2.066rc12.067rc12.068rc12.069rc12.070rc1
  2.067b2 2.068b2 2.069b2 2.070b2 2.071b2
  2.068b1 2.069b1 2.070b1 2.071b1 2.072b1
  2.069alpha  2.070alpha  2.071alpha  2.072alpha  2.073alpha

Where new features are only added to alpha release. And bug fixes are
added to all releases.

This way new bug fixes and new features would be released every month
but there would be a 5 month delay between the time that feature A is
added to the alpha release and the time feature A is propagated to the
stable release. But during this period feature A would be propagated
through releases and there would be plenty of opportunity to test it and
clear it of bugs. I am not a fan of such delay but I don't see any other
way new features could be added without higher risk of bugs.

Also vote up for daily snapshots.

As pure D user, I am not really comfortable with having to wait 6 months 
between releases. I like the idea to get new small features regularly 
(phobos API enhancement,...), and on some release getting a long wait 
hudge feature like Allocators.
Small releases will help to community to live with D. It's important to 
make noise regularly around the "product". Users will also xp more 
progressively in their development.


There is a lot of development I am waiting for my project, I'll really 
be happy to see one come before the next summer :

 - std.logger
 - std.serializatio

Re: [Poll] On Linux, what should we commonly use as sub-directory name for D?

[Marco Leise]

Am Thu, 14 Nov 2013 21:35:22 +0100
schrieb Johannes Pfau :

> AFAIK you can't put shared libraries into a different folder.
> The runtime linker must be able to find the libraries so the folders
> have to be registered in ld.so.conf. But ld 'virtually merges' all
> directories so you still can't have libraries with the same name &
> version in different folders. There are some tricks (rpath,
> LD_LIBRARY_PATH) but this won't work well in a large scale scenario.

That explains why Haskell's Cabal is installing libraries with
compiler AND library version in the file name :-/
 
> In the end all D compilers have to produce ABI compatible
> shared libraries. The runtime implementation may be different, but the
> ABI has to match. Unfortunately ABI compatibility is still in a distant
> future but there's no other way to solve the library issue.

That would be helpful. In the meantime I'll read up on how
dynamic linking works and what options I have.

-- 
Marco

Re: DIP 50 - AST macros

[deadalnix]

On Thursday, 14 November 2013 at 21:12:11 UTC, Walter Bright 
wrote:

On 11/14/2013 11:40 AM, deadalnix wrote:

This is not proposing to configure syntax.


Right, it is about inserting arbitrarily different meaning into 
existing syntax.




Yes, but EXPLICITELY.

(Also, a popular way of encrypting communications is to have 
private meanings for phrases like "my cat ate my homework" 
meaning "initiate Operation X".)




Note that you do not pretend that sentence with "THIS IS AN 
ENCRYPTED SENTENCE, HERE TO DECRYPT IT DO XXX".


Now, let's take the AST macros, and pass it "4+3". Apparently 
is a feature that the macro can transform this to produce 
"hello" as the result. The result is that although the language 
looks the same, there is no "anchor" a person can rely on to 
indicate the meaning. The meaning of "fine" is reversed, so to 
speak.




mymacro(4+3); // <= can be "hello"
myfunction(4+3); // <= can be "hello as well"

Quite frankly, this isn't really convincing.

The riposte is, of course, every feature can be abused and good 
programmers won't do that. Unfortunately, it's IN THE VERY 
NATURE of macros to be abusive, and even the very best 
programmers can and will take it to the limit. They will see 
and decry the abuse in everyone else's code but their own, 
which they will justify. As I said, I see this over and over 
again.




I can find article on the internet saying the exact same thing 
for any feature ever invented. You'll find quite easily some 
about templates or operator overloading, but if you go in 
Functionnalland, you'll find the same about virtual dispatch and 
inheritance. If you go in OOPland, you'll find the exact same 
argument for monads.


You are qualifying the nature of macro here, that is not an 
argument. "Macros are bad, so I conclude macro are bad."


On the other hand, with string mixins, it is immediately 
obvious that one is dealing with different syntax, and so 
expect something different to happen.


string mixins + a CTFE usable lexer+parser+D codegen from AST 
would achieve something close to the macros proposed here. This 
would obviously require quite a lot of work and is doomed to be 
dramatically slow and resources hungry, less hygienic (as 
identifier are implicitly resolved in the mixed in scope rather 
than explicitly) but quite close in term of capabilities.


You can't argue that string mixin is good while AST macro is bad.

Re: Review of std.signal

[Dicebot]

On Thursday, 14 November 2013 at 21:48:16 UTC, John Colvin wrote:

On Thursday, 14 November 2013 at 21:13:24 UTC, Robert wrote:

enum Protection { protected_, private_, none }
alias protected_ = Protection.protected_;
alias private_ = Protection.private_;
alias none = Protection.none;

Best of both worlds?


I thought of this too and it does seem to be a viable 
solution. I personally really don't mind the string parameter, 
after all it is a string mixin and it has a default value. But 
I have to admit, seeing it right in front of me, you got me 
there, I might like it.


The only argument against it is namespace pollution.


There is no such problem in D.

Re: Review of std.signal

[John Colvin]

On Thursday, 14 November 2013 at 21:13:24 UTC, Robert wrote:

enum Protection { protected_, private_, none }
alias protected_ = Protection.protected_;
alias private_ = Protection.private_;
alias none = Protection.none;

Best of both worlds?


I thought of this too and it does seem to be a viable solution. 
I personally really don't mind the string parameter, after all 
it is a string mixin and it has a default value. But I have to 
admit, seeing it right in front of me, you got me there, I 
might like it.


The only argument against it is namespace pollution.

Re: Thoughts about D package management on Gentoo

[Marco Leise]

Am Sat, 9 Nov 2013 01:38:10 +0100
schrieb Marco Leise :

I abandoned my "gdc" ebuild and instead just copied
the original gcc ebuild and augmented it with a specific
checkout of gdc from Github. This means that you can freely
slot it with your existing gcc installation(s) or replace it
entirely. This lets us work with it as if D was already
officially included in gcc.
Currently there is gcc 4.8.1 with front-end version 2.063.2.
gcc 4.8.2 will have the 2.064.2 integration.
Libraries compiled with gdc will be placed in the existing
version specific gcc directory
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/
to avoid collisions with the same .so files compiled with
other D compilers.

-- 
Marco

Re: DIP 50 - AST macros

[Zsombor Barna]

On Thursday, 14 November 2013 at 21:12:11 UTC, Walter Bright 
wrote:

On 11/14/2013 11:40 AM, deadalnix wrote:

This is not proposing to configure syntax.


Right, it is about inserting arbitrarily different meaning into 
existing syntax.


For example, I have a friend from the middle east who worked at 
Microsoft. His english was excellent. But sometimes he'd get 
tripped up - for example, he'd take his idea to his boss, who'd 
discuss it, and then say:


"fine"

He took that to mean "my boss approves of my great idea!" 
Unfortunately, "fine" has undergone a meaning reversal 
colloquially, and actually means "your idea sux". This wound up 
getting him into trouble. There were a few other phrases like 
this with unintentionally hilarious misunderstandings.


(Also, a popular way of encrypting communications is to have 
private meanings for phrases like "my cat ate my homework" 
meaning "initiate Operation X".)


Now, let's take the AST macros, and pass it "4+3". Apparently 
is a feature that the macro can transform this to produce 
"hello" as the result. The result is that although the language 
looks the same, there is no "anchor" a person can rely on to 
indicate the meaning. The meaning of "fine" is reversed, so to 
speak.


The riposte is, of course, every feature can be abused and good 
programmers won't do that. Unfortunately, it's IN THE VERY 
NATURE of macros to be abusive, and even the very best 
programmers can and will take it to the limit. They will see 
and decry the abuse in everyone else's code but their own, 
which they will justify. As I said, I see this over and over 
again.


On the other hand, with string mixins, it is immediately 
obvious that one is dealing with different syntax, and so 
expect something different to happen.


You have a point with the example, but just as with templates ( 
the distinctive binary ! operator), making macros not to look 
first class language elements when called does great job with 
readability. #-s or ×-s are just good for this, even if it look 
very foreign.


#loop ( ) {
  -- code --
}

Maybe for macros that return macros it would be ugly:
#(#macro1(params1))(params2);

But just as in C where the -> operator automatically dereferences 
pointers, it could be solved.

# macro1(params1) =#= (params2);
(Just for fun)

Re: Build Master: Scheduling

[Dicebot]

On Thursday, 14 November 2013 at 20:53:05 UTC, deadalnix wrote:

...


Hush-hush :) I was simply answering a question "Why may someone 
refuse to move to minor release that contains only bug fixes". 
Nothing more, nothing less, no hidden implications :)

Re: DIP 50 - AST macros

[Dicebot]

On Thursday, 14 November 2013 at 21:12:11 UTC, Walter Bright 
wrote:
On the other hand, with string mixins, it is immediately 
obvious that one is dealing with different syntax, and so 
expect something different to happen.


This is exactly the reason why I have been asking to make 
denoting macro usage with explicit keyword mandatory, like it is 
done with mixins.


It does not change much about the concept itself and is not worth 
fixating upon as a blocker.

Re: DIP 50 - AST macros

[H. S. Teoh]

On Thu, Nov 14, 2013 at 01:12:11PM -0800, Walter Bright wrote:
> On 11/14/2013 11:40 AM, deadalnix wrote:
> >This is not proposing to configure syntax.
> 
> Right, it is about inserting arbitrarily different meaning into
> existing syntax.
[...]
> Now, let's take the AST macros, and pass it "4+3". Apparently is a
> feature that the macro can transform this to produce "hello" as the
> result. The result is that although the language looks the same,
> there is no "anchor" a person can rely on to indicate the meaning.
> The meaning of "fine" is reversed, so to speak.
[...]
> On the other hand, with string mixins, it is immediately obvious
> that one is dealing with different syntax, and so expect something
> different to happen.

What if macros adopted an overtly different syntax?


T

-- 
English has the lovely word "defenestrate", meaning "to execute by
throwing someone out a window", or more recently "to remove Windows from
a computer and replace it with something useful". :-) -- John Cowan

Re: [Poll] On Linux, what should we commonly use as sub-directory name for D?

[Iain Buclaw]

On Nov 14, 2013 8:40 PM, "Johannes Pfau"  wrote:
>
> Am Thu, 14 Nov 2013 20:02:46 +0100
> schrieb Marco Leise :
>
> > Am Thu, 14 Nov 2013 19:11:17 +0100
> > schrieb "Dejan Lekic" :
> >
> > > On Wednesday, 13 November 2013 at 13:50:45 UTC, Marco Leise wrote:
> > > >
> > > > I don't want to be limited to one installation of Phobos.
> > > > That's why there is no "none" option. It is required to have
> > > > e.g.:
> > > > /usr/include/dlang/dmd-1.076/druntime
> > > > /usr/include/dlang/dmd-2.063/druntime
> > > > /usr/include/dlang/dmd-2.064/druntime
> > > > /usr/include/dlang/ldc-0.12.0/druntime
> > > > and
> > > > /usr/lib/dlang/dmd-2.063/phobos.a
> > > > /usr/lib/dlang/dmd-2.064/phobos.a
> > >
> > > You should be clearn that you were asking about where to put
> > > Phobos, not various D import files (from other D packages).
> >
> > Both actually. This was just an example with no bike-shedding
> > potential.
> >
> > > For Phobos import path, again, I would go for
> > > /usr/include/d/{dmd*|ldc*|gdc*}
> > >
> > > For the libraries, I also follow the same approach ArchLinux
> > > packages do. Honestly, no need for /usr/lib/dlang/blabla . Keep
> > > them all in the /usr/lib or /usr/lib{32|64} depending on distro...
> >
> > In fact there is a need for it as soon as you install them once
> > for each compiler. And that's where I want to go.
> > Alternatively suffixes could be used, but that makes it more
> > difficult to find the correct library name. So I went for
> > sub-directories.
> >
>
> AFAIK you can't put shared libraries into a different folder.
> The runtime linker must be able to find the libraries so the folders
> have to be registered in ld.so.conf. But ld 'virtually merges' all
> directories so you still can't have libraries with the same name &
> version in different folders. There are some tricks (rpath,
> LD_LIBRARY_PATH) but this won't work well in a large scale scenario.
>
> In the end all D compilers have to produce ABI compatible
> shared libraries. The runtime implementation may be different, but the
> ABI has to match. Unfortunately ABI compatibility is still in a distant
> future but there's no other way to solve the library issue.

And you can make a start in the direction of ABI compatibility by dropping
the D calling convention.  :-)

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Re: DIP 50 - AST macros

[Walter Bright]

On 11/14/2013 11:40 AM, deadalnix wrote:

This is not proposing to configure syntax.


Right, it is about inserting arbitrarily different meaning into existing syntax.

For example, I have a friend from the middle east who worked at Microsoft. His 
english was excellent. But sometimes he'd get tripped up - for example, he'd 
take his idea to his boss, who'd discuss it, and then say:


"fine"

He took that to mean "my boss approves of my great idea!" Unfortunately, "fine" 
has undergone a meaning reversal colloquially, and actually means "your idea 
sux". This wound up getting him into trouble. There were a few other phrases 
like this with unintentionally hilarious misunderstandings.


(Also, a popular way of encrypting communications is to have private meanings 
for phrases like "my cat ate my homework" meaning "initiate Operation X".)


Now, let's take the AST macros, and pass it "4+3". Apparently is a feature that 
the macro can transform this to produce "hello" as the result. The result is 
that although the language looks the same, there is no "anchor" a person can 
rely on to indicate the meaning. The meaning of "fine" is reversed, so to speak.


The riposte is, of course, every feature can be abused and good programmers 
won't do that. Unfortunately, it's IN THE VERY NATURE of macros to be abusive, 
and even the very best programmers can and will take it to the limit. They will 
see and decry the abuse in everyone else's code but their own, which they will 
justify. As I said, I see this over and over again.


On the other hand, with string mixins, it is immediately obvious that one is 
dealing with different syntax, and so expect something different to happen.

Re: Review of std.signal

[Robert]

enum Protection { protected_, private_, none }
alias protected_ = Protection.protected_;
alias private_ = Protection.private_;
alias none = Protection.none;

Best of both worlds?


I thought of this too and it does seem to be a viable solution. I 
personally really don't mind the string parameter, after all it 
is a string mixin and it has a default value. But I have to 
admit, seeing it right in front of me, you got me there, I might 
like it.

Re: DIP 50 - AST macros

[Walter Bright]

On 11/14/2013 11:18 AM, Jacob Carlborg wrote:

AST macros cannot change the syntax or introduce new syntax. C preprocessor
macros and AST macros are not the same. I'm starting to regret that I called it
"macros".


If it is powerful enough to do async/await but look like normal D syntax, then 
is going to suffer from these faults.


(A lot of the C++ macro abuse looks like normal syntax to the user, but it 
behaves in a way that the casual user would find completely unexpected. In the 
same vein, macro assembler abuse of macros did not introduce new syntax - the 
syntax for the macros was straightforward. It was what those macros *did* that 
made them incomprehensible.)

Re: Build Master: Scheduling

[deadalnix]

On Thursday, 14 November 2013 at 20:30:40 UTC, Dicebot wrote:

On Thursday, 14 November 2013 at 20:27:23 UTC, Rob T wrote:
Bug fixes should be as frequent as possible. To understand 
why, just try and find a good reason to artificially hold back 
a bug fix.


Code breakage. DMD has good amount of accepts-invalid bugs.


Right now I have 15 tests failing in SDC test suite because of 
DMD messing up with closures.


This is certainly not an option to wait 6 month that way. Accept 
invalid is certainly not something you can stick in patches 
release, but invalid codegen is.


I fairly bummed by code breakage being raised as a excuse to not 
do anything. As a matter of fact, I have to work with my own 
homebrew version of DMD half of the time. One release out of 2 
has introduced unacceptable regression.


Now I'm ready to hear that people don't want to spend time 
publishing a minor version of DMD because they don't have time or 
whatever. But this breaking code bullshit must stop.


Every single release of DMD break my code, 1 release out of 2 
break it by introducing regression, not because of accept-invalid 
(which I'm happy to fix).


We need these minor release. Anyone that have a reasonably sized 
D codebase knows it. In fact I'm pretty sure that anyone having a 
reasonably sized D codebase is using some homebrew version of DMD 
most of the time, as waiting 6 month is usually not an option.

Re: Build Master: Scheduling

[Xinok]

On Thursday, 14 November 2013 at 00:37:38 UTC, Tyro[17] wrote:

Greetings,

I have accepted the responsibility of preparing the builds for 
DMD and would like to engage in conversation about the way 
ahead.


The first concern I have is about the build cycle. Presently, 
it is nonexistent. There is no rhyme or reason regarding when 
releases are produced. The v2.065 agenda (first attempt of its 
kind) suggests that the next release will occur sometime in 
March 2014. I'm of the opinion, however, that the cycle should 
be six months long. This particular schedule is not of my own 
crafting but I believe it to be sound and worthy of emulation:


...

Your thoughts and concerns please.


I think this is perfect. It's essentially what I would do. Ever 
since Google defined their six week release schedule for Chrome, 
people think quick release cycles are the next great thing. It 
was such an effective marketing strategy that Firefox had to jump 
the bandwagon. The truth is though, it doesn't cater well to 
large corporations. That's why Firefox also has ESR (Extended 
Support Release) for corporations which are older versions 
maintained for longer, only being updated for new bug and 
security fixes.


I think the majority of people active on these forums are 
hardcore D enthusiasts so they're eager to have the latest and 
greatest. However, we're not hearing the voice of those on the 
outside. I'm willing to bet if we were to post this as news on 
Reddit, we'd be getting praise from those who aren't actively 
involved in the development of D.



I do have a few ideas:

I'm one who favors having different version numbers for beta and 
stable releases. Given the version number scheme that DMD 
follows, a simple numbering scheme to follow is odd- and 
even-numbered versions: odd-numbered versions, starting with 
2.065, would be beta, and even-numbered versions, like 2.066, 
would be stable.


I would define two periods during the release cycle: Early on, 
when it's okay to introduce new features and changes which may 
break code, and later on when we should be concentrating on 
testing, fixing bugs, and generally working towards a stable 
release.


Finally, I think after every stable release, we should define an 
agenda, i.e. what are our goals for the next version? My current 
impression is that pull requests are incorporated into master 
whenever they're deemed ready. If we have a clear agenda, then we 
could collectively focus our efforts into a few areas for 
development.

Re: [Poll] On Linux, what should we commonly use as sub-directory name for D?

[Johannes Pfau]

Am Thu, 14 Nov 2013 20:02:46 +0100
schrieb Marco Leise :

> Am Thu, 14 Nov 2013 19:11:17 +0100
> schrieb "Dejan Lekic" :
> 
> > On Wednesday, 13 November 2013 at 13:50:45 UTC, Marco Leise wrote:
> > >
> > > I don't want to be limited to one installation of Phobos.
> > > That's why there is no "none" option. It is required to have
> > > e.g.:
> > > /usr/include/dlang/dmd-1.076/druntime
> > > /usr/include/dlang/dmd-2.063/druntime
> > > /usr/include/dlang/dmd-2.064/druntime
> > > /usr/include/dlang/ldc-0.12.0/druntime
> > > and
> > > /usr/lib/dlang/dmd-2.063/phobos.a
> > > /usr/lib/dlang/dmd-2.064/phobos.a
> > 
> > You should be clearn that you were asking about where to put 
> > Phobos, not various D import files (from other D packages).
> 
> Both actually. This was just an example with no bike-shedding
> potential.
> 
> > For Phobos import path, again, I would go for 
> > /usr/include/d/{dmd*|ldc*|gdc*}
> > 
> > For the libraries, I also follow the same approach ArchLinux 
> > packages do. Honestly, no need for /usr/lib/dlang/blabla . Keep 
> > them all in the /usr/lib or /usr/lib{32|64} depending on distro...
> 
> In fact there is a need for it as soon as you install them once
> for each compiler. And that's where I want to go.
> Alternatively suffixes could be used, but that makes it more
> difficult to find the correct library name. So I went for
> sub-directories.
> 

AFAIK you can't put shared libraries into a different folder.
The runtime linker must be able to find the libraries so the folders
have to be registered in ld.so.conf. But ld 'virtually merges' all
directories so you still can't have libraries with the same name &
version in different folders. There are some tricks (rpath,
LD_LIBRARY_PATH) but this won't work well in a large scale scenario.

In the end all D compilers have to produce ABI compatible
shared libraries. The runtime implementation may be different, but the
ABI has to match. Unfortunately ABI compatibility is still in a distant
future but there's no other way to solve the library issue.

Re: Build Master: Scheduling

[Dicebot]

On Thursday, 14 November 2013 at 20:27:23 UTC, Rob T wrote:
Bug fixes should be as frequent as possible. To understand why, 
just try and find a good reason to artificially hold back a bug 
fix.


Code breakage. DMD has good amount of accepts-invalid bugs.

Re: DIP 45 - approval discussion

[deadalnix]

OK, I missed the point where everything started back again. This 
is being ridiculous.

Re: Build Master: Scheduling

[Rob T]

On Thursday, 14 November 2013 at 00:37:38 UTC, Tyro[17] wrote:
[...]

Your thoughts and concerns please.


Please do not mix together bugs fix releases with enhancement/new 
addition releases, those represent two different types of release 
that serve two entirely different purposes.


Bug fixes should be as frequent as possible. To understand why, 
just try and find a good reason to artificially hold back a bug 
fix.


As for feature enhancements and new additions to the language, 
delays tend to be a good thing, allowing time for fine tuning 
reflection and beta testing - but please take note that the 
current process lacks a public beta release cycle, and we can see 
the results each time there's been a new release, with weird 
version number mix ups, and embarrassing bugs that would have 
been detected had there been a real public beta release posted on 
the main download page.


--rt

Re: [Poll] On Linux, what should we commonly use as sub-directory name for D?

[Joseph Rushton Wakeling]

On 12/11/13 20:50, Marco Leise wrote:

I've seen people use both 'd' and 'dlang' now, so I created a
poll. Everyone assembling Linux packages is then free use the
results to create a similar experience on all distributions.


I'm not sure a poll is the appropriate way to decide this, to be honest.  The 
decision should be based on something very simple -- is there anything else out 
there that is using 'd' as subdirectory name?


If there's no precedent of some other project using 'd', why not stake the 
claim?

Re: DIP 45 - approval discussion

[Benjamin Thaut]

Am 14.11.2013 20:54, schrieb deadalnix:

On Thursday, 14 November 2013 at 13:31:30 UTC, Benjamin Thaut wrote:

Am 14.11.2013 11:28, schrieb Walter Bright:


This of course means that functions may wind up going through the
dllimport indirection even for calling functions in the same dll, but it
should work.


Also our suggested approach would not have this downside.

Think about phobos. All of phobos and druntime will be littered with
export attributes. Do you really want all phobos and druntime from
within the same dll to go through dll indirections? And what would
happen when building phobos as static library? With your suggested
behavior (export=dllimport if not specified otherwise) this would mean
that even the phobos static library would have those indirections.


This thread have reached some end.

It has been shown in the beginning that linkers know how to get rid of
the indirection here. If we are going to discuss the same thing again
and again without even doing some experiment for the reality check, then
we can stop right here.


No, linkers can not get of this indirection. Only whole program 
optimization can, and that won't happen in D (at least dmd) for quite 
some time. We had exactly that discussion in the old thread about the 
export attribute. See here: 
http://forum.dlang.org/thread/kvhu2c$2ikq$1...@digitalmars.com#post-kvhu2c:242ikq:241:40digitalmars.com


But because Walter does not agree with the way we solved the problem in 
DIP 45 we have to go through everything again from the beginning.
And I'm certenly not going to accept a solution where we rely on some 
non implemented feature to remove indirections which will most likely 
not happen in the near future. The same already happend for virtual 
functions. The documentation states that the compiler might optimize 
them away, but in pratice this still does not happen, and most likely 
never will.


With DIP 45 we setteled for additional indirections to achive better 
usability and I'm ok with that. But what Walter suggests esentially 
means even more indirections and worse usability. And I'm not ok with that.


I also don't like that we have to go through everything again we already 
discussed in the old thread, but if Walter doesn't agree it has to be 
that way. So please try to contribute in a constructive manner, or leave 
out comments entierly.


Kind Regards
Benjamin Thaut

Re: DIP 45 - approval discussion

[deadalnix]

On Thursday, 14 November 2013 at 13:31:30 UTC, Benjamin Thaut 
wrote:

Am 14.11.2013 11:28, schrieb Walter Bright:


This of course means that functions may wind up going through 
the
dllimport indirection even for calling functions in the same 
dll, but it

should work.


Also our suggested approach would not have this downside.

Think about phobos. All of phobos and druntime will be littered 
with export attributes. Do you really want all phobos and 
druntime from within the same dll to go through dll 
indirections? And what would happen when building phobos as 
static library? With your suggested behavior (export=dllimport 
if not specified otherwise) this would mean that even the 
phobos static library would have those indirections.


This thread have reached some end.

It has been shown in the beginning that linkers know how to get 
rid of the indirection here. If we are going to discuss the same 
thing again and again without even doing some experiment for the 
reality check, then we can stop right here.

Re: DIP 50 - AST macros

[Rob T]

On Thursday, 14 November 2013 at 18:23:20 UTC, Andrei 
Alexandrescu wrote:

[...]


Natural languages are "humans complete" because they are the 
one vehicle we use to describe and manipulate our understanding 
of the entire reality. If configurable syntax was something 
necessary to model the world, it would have inevitably occurred 
in natural languages one way or another. Instead, all human 
languages (with no exception I know of) have fixed syntax and 
prefer to add modeling power in other ways. There must be 
something about this.



Andrei


Not an unreasonable assumption to make, so assuming it's true, 
then we need a fixed way to deal with a certain set of problems 
that so far cannot be done reasonably (or at all) in current D.


One case, which I also so happen to want to solve, is the 
async/await type of problem. There's simply no reasonable 
solution available other than through extensions to the language, 
which may or may not ever materialize. It's very frustrating when 
you want to explore possibilities today rather than wait for an 
extension that may never arrive.


Adding in the async/await extensions can help solve only that 
specific problem, but how many other types of problems that are 
similar to this one will programmers still want to solve? A more 
general solution would seem to be far more useful.


The other simple problem I encountered, at first seems like a 
mixin can deal with or perhaps a template, but current D simply 
cannot do it in a reasonable way that I'm aware of.


I want to be able to pass an argument to an "inspect" function, 
that will log or display the symbol name of the top-level 
argument and it's corresponding value.


Example:

int a = 300;
inspect( a ); // or inspect!a;

The only way I can do this is through double entry of the item to 
inspect

eg

inspect( a.stringof, a ); // error prone and irritatingly 
redundant


I can get some success using an alias template parameter, but it 
does not work in general, only in a few cases will it work, so 
templates are not a solution without some additional enhancements.


May be by adding in something like __ARGS__, or expanding 
on__traits can solve this type of problem, but there's no doubt 
many other scenarios that will require similar extensions that 
users of the language cannot implement. There's no end to this 
without much better access to reflection.


--rt

Re: DIP 50 - AST macros

[Zsombor Barna]

On Thursday, 14 November 2013 at 18:23:20 UTC, Andrei 
Alexandrescu wrote:

On 11/14/13 2:17 AM, Walter Bright wrote:

On 11/14/2013 2:07 AM, Chris Cain wrote:
I guess I would have thought the exact opposite from you... 
that this is
precisely something that *should* be done with a 
library-defined macro.


Again, I reiterate what experience shows happens with macro 
systems in

the long term.


FWIW Walter talked me back around 2005-2006 into abandoning my 
own ideas about languages with configurable syntax.


There are quite a few failings about comparing programming 
languages against natural languages, but here's one that I 
think does have value: fixed syntax is ingrained into people's 
notion of language, and swapping syntax within an otherwise 
identical linguistic context is extremely taxing on the brain. 
Anyone who's read with a C or C++ codebase full of macros and 
#if-driven code can attest how unbelievably difficult 
juxtapositions of the normal syntax with preprocessor syntax 
can quickly become. That's part of why "static if" has been so 
successful in D - it drives new semantics but within the same 
syntax.


Natural languages are "humans complete" because they are the 
one vehicle we use to describe and manipulate our understanding 
of the entire reality. If configurable syntax was something 
necessary to model the world, it would have inevitably occurred 
in natural languages one way or another. Instead, all human 
languages (with no exception I know of) have fixed syntax and 
prefer to add modeling power in other ways. There must be 
something about this.



Andrei


D's syntax remains the same ( statements, expressions, function 
calling, numbers etc. ). These AST manipulation tools just define 
new words or language constructs. Human languages tend to be 
altered as times passes and the needs change. That's why new 
words appear. Even the grammar is not the same as the one my 
grandparents used.

Re: DIP 50 - AST macros

[deadalnix]

On Thursday, 14 November 2013 at 18:23:20 UTC, Andrei 
Alexandrescu wrote:

On 11/14/13 2:17 AM, Walter Bright wrote:

On 11/14/2013 2:07 AM, Chris Cain wrote:
I guess I would have thought the exact opposite from you... 
that this is
precisely something that *should* be done with a 
library-defined macro.


Again, I reiterate what experience shows happens with macro 
systems in

the long term.


FWIW Walter talked me back around 2005-2006 into abandoning my 
own ideas about languages with configurable syntax.




This is not proposing to configure syntax.

There are quite a few failings about comparing programming 
languages against natural languages, but here's one that I 
think does have value: fixed syntax is ingrained into people's 
notion of language, and swapping syntax within an otherwise 
identical linguistic context is extremely taxing on the brain. 
Anyone who's read with a C or C++ codebase full of macros and 
#if-driven code can attest how unbelievably difficult 
juxtapositions of the normal syntax with preprocessor syntax 
can quickly become. That's part of why "static if" has been so 
successful in D - it drives new semantics but within the same 
syntax.




C macro can introduce new syntax. This cannot.

Natural languages are "humans complete" because they are the 
one vehicle we use to describe and manipulate our understanding 
of the entire reality. If configurable syntax was something 
necessary to model the world, it would have inevitably occurred 
in natural languages one way or another. Instead, all human 
languages (with no exception I know of) have fixed syntax and 
prefer to add modeling power in other ways. There must be 
something about this.



Andrei


I think this very post pretty much show that you missed the point 
of the DIP.

Re: D parsing

[Timon Gehr]

On 11/11/2013 12:37 AM, Andrei Alexandrescu wrote:

On 11/10/13 3:21 PM, Timon Gehr wrote:

On 11/10/2013 11:43 PM, Andrei Alexandrescu wrote:


It seems we could even get rid of __FILE__,__LINE__,__MODULE__ with AST
macros.


This would be a very small advantage. The special variables hardly cause
any trouble.

Andrei


The trouble is that there are too few of them to (efficiently) reflect
all the information about the calling context one may be interested in.
I don't see the point in adding them one after another in an
unprincipled ad-hoc fashion instead of actually thinking up a good API
coupled with some more expressive power.


But the API would add them in exactly the same rote manner.


No, it would be (close to) exhaustive from the beginning. That is the 
point. I assume the problem is that there have not yet been very 
specific proposals.



I really don't see an advantage here.


It's the difference between having an universal language, and a language 
that has a finite and fixed set of words (without any methods of 
combination).




An argument for macros would have to do a
lot more than "we don't need __FILE__ etc. anymore".
...


Obviously, but I was not making this argument, and as far as I can see 
nobody else was either.

Re: DIP 50 - AST macros

[Meta]

On Thursday, 14 November 2013 at 19:27:42 UTC, simendsjo wrote:
At the top of the page you should have "view mode" links which 
supports a threaded view.


Neat. I have my browser set up to auto-login, so I rarely, if 
ever, have to look up there.

Re: D parsing

[Timon Gehr]

On 11/12/2013 09:14 AM, Andrei Alexandrescu wrote:

On 11/12/13 12:09 AM, Jacob Carlborg wrote:

...

"An argument for macros would have to do a
lot more than 'we don't need __FILE__ etc. anymore'"

...


It's very simple.  Timon got into that part as if it were important. I pointed out it's 

not important.

..


This is a misrepresentation. I'll just answer that post.

Re: DIP 50 - AST macros

[simendsjo]

On Thursday, 14 November 2013 at 19:22:08 UTC, Meta wrote:
On Thursday, 14 November 2013 at 17:55:57 UTC, Walter Bright 
wrote:

On 11/14/2013 9:08 AM, Meta wrote:
What kind of macro systems are you talking about? C-like 
macros? Assembly
macros? Lisp-like macros? It seems that Jacob's proposed 
system is similar to

none of these.


See my first comment in this thread - it's an ancestor to this 
one.


I'm using the website forum, so I see posts in a continuous 
format, not a threaded view.


Anyway, it seems like assembly macros are actually quite 
similar to Lisp macros. Again, it seems like what Jacob 
proposes is not really much like Lisp macros, nor C macros.


At the top of the page you should have "view mode" links which 
supports a threaded view.

Re: DIP 50 - AST macros

[Meta]

On Thursday, 14 November 2013 at 17:55:57 UTC, Walter Bright 
wrote:

On 11/14/2013 9:08 AM, Meta wrote:
What kind of macro systems are you talking about? C-like 
macros? Assembly
macros? Lisp-like macros? It seems that Jacob's proposed 
system is similar to

none of these.


See my first comment in this thread - it's an ancestor to this 
one.


I'm using the website forum, so I see posts in a continuous 
format, not a threaded view.


Anyway, it seems like assembly macros are actually quite similar 
to Lisp macros. Again, it seems like what Jacob proposes is not 
really much like Lisp macros, nor C macros.

Re: DIP 50 - AST macros

[Jacob Carlborg]

On 2013-11-14 19:23, Andrei Alexandrescu wrote:


FWIW Walter talked me back around 2005-2006 into abandoning my own ideas
about languages with configurable syntax.

There are quite a few failings about comparing programming languages
against natural languages, but here's one that I think does have value:
fixed syntax is ingrained into people's notion of language, and swapping
syntax within an otherwise identical linguistic context is extremely
taxing on the brain. Anyone who's read with a C or C++ codebase full of
macros and #if-driven code can attest how unbelievably difficult
juxtapositions of the normal syntax with preprocessor syntax can quickly
become. That's part of why "static if" has been so successful in D - it
drives new semantics but within the same syntax.


AST macros cannot change the syntax or introduce new syntax. C 
preprocessor macros and AST macros are not the same. I'm starting to 
regret that I called it "macros".


--
/Jacob Carlborg

Re: Ehem, ARM

[Jacob Carlborg]

On 2013-11-14 17:21, Chris wrote:


Thanks for your reply, Kai. That's good news, however iOS and Android
support is crucial. I hope D can soon be ported to ARM, it's just too
important.


If you want to do anything useful on iOS you need to use Objective-C 
libraries, for that you bascilly need this:


http://michelf.ca/projects/d-objc/

Latest update, but still quite outdated: 
https://github.com/jacob-carlborg/dmd/tree/d-objc


--
/Jacob Carlborg

Re: obliterate

[Brad Roberts]

On 11/14/13 1:36 AM, monarch_dodra wrote:

On Wednesday, 13 November 2013 at 01:37:15 UTC, Jonathan M Davis wrote:

Except that pretty most of your examples don't seem like they would fail any
more than T.init would. int.max / 2 in so no more valid or invalid than 0. The
only difference I see would be that by setting pointers/references/arrays to a
weird value rather than null, they'll be treated as if they have a value and
then blow up rather than blowing up on a null value. For all the built-in
types, T.init is essentially supposed to be as invalid as the type can get
without pointing off into memory that it shouldn't be addressing.

So, the only thing I see that this suggestion does over using T.init is that
on pointers/references/arrays, you won't end up with code that checks for null
and avoids blowing up. Code that checks for null would then blow up just as
much as code that assumes that the pointer/reference/array was non-null. But
that's the only difference I see, since none of the other types end up with
values that are any more invalid than T.init.

- Jonathan M Davis


+1. Essentially, I don't see how any of this is better than .init.

What about user defined types? How do you want to deal with those? Recursively 
search all basic
types and set them to the above mentioned values?


It can be nice to distinguish between initial state and final state.

Re: dmd 2.065 - Agenda

[Brad Roberts]

On 11/14/13 10:23 AM, Dejan Lekic wrote:

Scrum etc is for commercial software development. It does not really work for 
Open Source
development, because people will always work on what they personally consider 
most important and
most interesting. In the agile world there is a customer, who prioritizes work 
items. This cannot
be applied here.

Bugzilla votes and stuff are nice to let devs know about bugs, but not 
necessarily motivates to
fix them.


My Scrum experience tells me to humbly disagree because Scrum like all other 
agile process tools is
all about experimentation. Almost all Scrum practices are applicable in 
open-source world. No Scrum
team works the same as the other, they all have different ways of applying 
Scrum (that is why it is
called a "process tool", not a methodology as many people use to call it).

Kanban is (IMHO) even more applicable in the open-source world as it has only 
two prescribed
practices, the rest is up to the team to apply any agile practice they think 
will help the project...

Take a look how "big open-source guys" do things. Their core team (typically 
full-time employed)
works on whatever is on the sprint backlog, while contributors all around the 
world take whatever
they like working on (with help of mentors quite often). So, it is possible to 
have a nicely
organised open-source project, if people are willing to do so.


Which is pretty much exactly what we have.  All the paid developers (no one) follow a core mission, 
and all the volunteers scratch the itch they want to address the most.


More seriously, can you look at the linux kernel, or any of the major browser projects, or any of 
the major gui tool kits, or... and find a nice clear list of what's going to be in them before they 
release?  Maybe close to the end of the release, but before or at the beginning of the cycle?


More organization would be nice, but let's not ascribe too much faith that we're all _that_ 
different from many other projects.  I think a key difference is that we have so many more big 
things that aren't near where we want them to be that it's easier to be unhappy.

Re: [Poll] On Linux, what should we commonly use as sub-directory name for D?

[Marco Leise]

Am Thu, 14 Nov 2013 19:11:17 +0100
schrieb "Dejan Lekic" :

> On Wednesday, 13 November 2013 at 13:50:45 UTC, Marco Leise wrote:
> >
> > I don't want to be limited to one installation of Phobos.
> > That's why there is no "none" option. It is required to have
> > e.g.:
> > /usr/include/dlang/dmd-1.076/druntime
> > /usr/include/dlang/dmd-2.063/druntime
> > /usr/include/dlang/dmd-2.064/druntime
> > /usr/include/dlang/ldc-0.12.0/druntime
> > and
> > /usr/lib/dlang/dmd-2.063/phobos.a
> > /usr/lib/dlang/dmd-2.064/phobos.a
> 
> You should be clearn that you were asking about where to put 
> Phobos, not various D import files (from other D packages).

Both actually. This was just an example with no bike-shedding
potential.

> For Phobos import path, again, I would go for 
> /usr/include/d/{dmd*|ldc*|gdc*}
> 
> For the libraries, I also follow the same approach ArchLinux 
> packages do. Honestly, no need for /usr/lib/dlang/blabla . Keep 
> them all in the /usr/lib or /usr/lib{32|64} depending on distro...

In fact there is a need for it as soon as you install them once
for each compiler. And that's where I want to go.
Alternatively suffixes could be used, but that makes it more
difficult to find the correct library name. So I went for
sub-directories.

-- 
Marco

Re: Build Master: Scheduling

[Andrej Mitrovic]

On 11/14/13, Sönke Ludwig  wrote:
> Just a little personal impression - it seems like during 2.064's
> development, more people than ever have switched to DMD HEAD instead of
> the last release version. This made it much more burdensome to support
> public libraries, because compiler induced breakage was much more frequent.

And a 6 month release schedule means you have to keep around and
implement workarounds in your libraries for old bugs. You can't just
target git-head for your users, you have to target the latest stable
version.

The release cycle right now is so slow that most of the time I'm just
using git-head, but I still end up having to implement workarounds for
the last stable version when I publish code. If the release cycles
were more frequent then I wouldn't have to use bleeding-edge.

Does 2.064 support shared libraries?

[Frusdrated]

First: Does 2.064 fully support shared libraries? It seems there 
were previous indications that it would.


Second: is it possible to change forum name, or will the 
automatic spam filters object?

Re: DIP 50 - AST macros

[Andrei Alexandrescu]

On 11/14/13 2:17 AM, Walter Bright wrote:

On 11/14/2013 2:07 AM, Chris Cain wrote:

I guess I would have thought the exact opposite from you... that this is
precisely something that *should* be done with a library-defined macro.


Again, I reiterate what experience shows happens with macro systems in
the long term.


FWIW Walter talked me back around 2005-2006 into abandoning my own ideas 
about languages with configurable syntax.


There are quite a few failings about comparing programming languages 
against natural languages, but here's one that I think does have value: 
fixed syntax is ingrained into people's notion of language, and swapping 
syntax within an otherwise identical linguistic context is extremely 
taxing on the brain. Anyone who's read with a C or C++ codebase full of 
macros and #if-driven code can attest how unbelievably difficult 
juxtapositions of the normal syntax with preprocessor syntax can quickly 
become. That's part of why "static if" has been so successful in D - it 
drives new semantics but within the same syntax.


Natural languages are "humans complete" because they are the one vehicle 
we use to describe and manipulate our understanding of the entire 
reality. If configurable syntax was something necessary to model the 
world, it would have inevitably occurred in natural languages one way or 
another. Instead, all human languages (with no exception I know of) have 
fixed syntax and prefer to add modeling power in other ways. There must 
be something about this.



Andrei

Re: dmd 2.065 - Agenda

[Dejan Lekic]

Scrum etc is for commercial software development. It does not 
really work for Open Source development, because people will 
always work on what they personally consider most important and 
most interesting. In the agile world there is a customer, who 
prioritizes work items. This cannot be applied here.


Bugzilla votes and stuff are nice to let devs know about bugs, 
but not necessarily motivates to fix them.


My Scrum experience tells me to humbly disagree because Scrum 
like all other agile process tools is all about experimentation. 
Almost all Scrum practices are applicable in open-source world. 
No Scrum team works the same as the other, they all have 
different ways of applying Scrum (that is why it is called a 
"process tool", not a methodology as many people use to call it).


Kanban is (IMHO) even more applicable in the open-source world as 
it has only two prescribed practices, the rest is up to the team 
to apply any agile practice they think will help the project...


Take a look how "big open-source guys" do things. Their core team 
(typically full-time employed) works on whatever is on the sprint 
backlog, while contributors all around the world take whatever 
they like working on (with help of mentors quite often). So, it 
is possible to have a nicely organised open-source project, if 
people are willing to do so.

Re: [Poll] On Linux, what should we commonly use as sub-directory name for D?

[Dejan Lekic]

On Wednesday, 13 November 2013 at 13:50:45 UTC, Marco Leise wrote:

Am Wed, 13 Nov 2013 13:23:17 +0100
schrieb "Dejan Lekic" :

On Tuesday, 12 November 2013 at 19:50:32 UTC, Marco Leise 
wrote:

> I've seen people use both 'd' and 'dlang' now, so I created a
> poll. Everyone assembling Linux packages is then free use the
> results to create a similar experience on all distributions.
>
> http://www.easypolls.net/poll.html?p=52828149e4b06cfb69b97527

You should have "None above" as an option. Once you do have, 
that will be my choice, for now, for Phobos certainly.


I don't want to be limited to one installation of Phobos.
That's why there is no "none" option. It is required to have
e.g.:
/usr/include/dlang/dmd-1.076/druntime
/usr/include/dlang/dmd-2.063/druntime
/usr/include/dlang/dmd-2.064/druntime
/usr/include/dlang/ldc-0.12.0/druntime
and
/usr/lib/dlang/dmd-2.063/phobos.a
/usr/lib/dlang/dmd-2.064/phobos.a


You should be clearn that you were asking about where to put 
Phobos, not various D import files (from other D packages).


For Phobos import path, again, I would go for 
/usr/include/d/{dmd*|ldc*|gdc*}


For the libraries, I also follow the same approach ArchLinux 
packages do. Honestly, no need for /usr/lib/dlang/blabla . Keep 
them all in the /usr/lib or /usr/lib{32|64} depending on distro...

Re: What’s Wrong with OOP and FP

[Andrei Alexandrescu]

On 11/14/13 1:37 AM, Don wrote:

I just can't escape the feeling that class-based runtime polyphorphism
is almost never an ideal solution, and that most of the benefits and
success of OOP languages comes from things other than OOP itself. And I
think it's because OOP is philosophically nonsense -- in the real world,
similarities between things are everywhere, but almost none of them are
is-A relationships.


Compilers (ours included) are a good example where OOP (with some 
visitor pizzazz) is a good fit. There are obvious hierarchies (addition 
is-a expression etc).


Andrei

Re: DIP 50 - AST macros

[Dejan Lekic]

1. I've seen very heavy use of such macros in macro assemblers. 
What happens is people use it to invent their own (very 
baroque) language on top of the existing assembler one. Anyone 
trying to read the code has to learn this new unique language, 
and given the limitations of the macro capability, it often 
comes with unfixable bizarre corner cases and limitations.




Metaprogramming (almost) does the same. At least that is my 
impression. Sometimes I have to go through hundreds of lines of 
templated D code to understand what a single line does...

Re: DIP 50 - AST macros

[Walter Bright]

On 11/14/2013 9:08 AM, Meta wrote:

What kind of macro systems are you talking about? C-like macros? Assembly
macros? Lisp-like macros? It seems that Jacob's proposed system is similar to
none of these.


See my first comment in this thread - it's an ancestor to this one.

Re: Vibe.d & DUB

[Jordi Sayol]

El 14/11/13 17:48, Chris ha escrit:
> On Thursday, 14 November 2013 at 16:42:05 UTC, Chris wrote:
>> On Thursday, 14 November 2013 at 16:32:59 UTC, Sönke Ludwig wrote:
>>> Am 14.11.2013 16:54, schrieb Chris:
 Excuse me my ignorance. I haven't used DUB for a while now. Don't know
 what's wrong. Found no hint on the (h)internet. I it that the latest
 version of dmd is "too high" for dub? Use dmd2.063 instead?

 $ dub upgrade
 Upgrading project in /home/path/to/project
 Triggering update of package vibe-d
 Geting package metadata for vibe-d failed, exception:
 object.Exception@source/dub/project.d(460): Could not find package
 candidate for vibe-d >=0.7.12
 (...)
>>>
>>> Judging by the line number of the exception, you are using DUB 0.9.13. 
>>> There have been a number of changes since then, including how version 
>>> numbers are validated. It's possible that the reason for the error is the 
>>> latest vibe.d version "0.7.18-beta.1".
>>>
>>> I'd recommend to upgrade to 0.9.19 - everything is working there AFAICS.
>>
>> Thanks for the answer. I tried to update dub, but it says that "dub is 
>> already the newest version.", which is hard for me to believe.
> 
> Ubuntu 12.04 LTS
> 

What says last line of

$ dub help

-- 
Jordi Sayol

Re: DIP 45 - approval discussion

[Benjamin Thaut]

Am 14.11.2013 08:36, schrieb Rainer Schuetze:




As far as I understand, the optimization avoids generating code for
template instances only _created_ (not defined) by imported modules,
e.g. when needed for semantic analysis inside the imported module, but
never actually referenced by generated code by the root modules.

[OT: The problem of the current implementation is the detection of
"only" in that definition, it fails too often leading to linker errors
and the addition of that terrible -allinst switch. I had to disable the
optimization for me before addition of that switch.]

With respect to export I guess the optimization doesn't change much as
multiple instances of the same template instance still can be found in
different object files (maybe even less predictable).

To avoid the trouble with templates, here is an idea for discussion:

- templates definitions by themselves are never dllexport/dllimport

- template instances are dllexport/dllimport with the proposed semantics
of normal functions/variables if they are explicitely declared as
"export" by an alias statement, e.g.

   export alias templ!int exported_tmpl_int;

- implicitely created template instances don't create dllexport
versions, and use dllimport semantics if the declaration above is found
in an import.


I actually like this idea. Everytime I actually had to dllexport / 
dllimport templates in C++ I knew beforehand which types I need the 
template exported for.


But what would should in a case like this:

class WeakReferenced(T)
{
  export __gshared WeakReferenced!T[] m_weakTable;
}

Note that the export is not applied to the template directly but instead 
to a specific member inside the template.


Should this be an error?



- It's worse for the dllimport case, as data accesses to template
variables will sometimes use the additional indirection, sometimes not.


Why exactly is that? Would that also be the case with the system 
proposed by the DIP? The dip never actually uses dllimport, so shouldn't 
it just work (tm)?


Kind Regards
Benjamin Thaut

Re: Vibe.d & DUB

[Sönke Ludwig]

Am 14.11.2013 17:42, schrieb Chris:

On Thursday, 14 November 2013 at 16:32:59 UTC, Sönke Ludwig wrote:

Am 14.11.2013 16:54, schrieb Chris:

Excuse me my ignorance. I haven't used DUB for a while now. Don't know
what's wrong. Found no hint on the (h)internet. I it that the latest
version of dmd is "too high" for dub? Use dmd2.063 instead?

$ dub upgrade
Upgrading project in /home/path/to/project
Triggering update of package vibe-d
Geting package metadata for vibe-d failed, exception:
object.Exception@source/dub/project.d(460): Could not find package
candidate for vibe-d >=0.7.12
(...)


Judging by the line number of the exception, you are using DUB 0.9.13.
There have been a number of changes since then, including how version
numbers are validated. It's possible that the reason for the error is
the latest vibe.d version "0.7.18-beta.1".

I'd recommend to upgrade to 0.9.19 - everything is working there AFAICS.


Thanks for the answer. I tried to update dub, but it says that "dub is
already the newest version.", which is hard for me to believe.


You'll probably have to download the latest binary from 
, but the APT repository on 
 should also be up to date.

Re: Review of std.signal

[John Colvin]

On Thursday, 14 November 2013 at 15:40:49 UTC, Robert wrote:


Enums in D may be scoped. There is nothing that prevents you 
from declaring your enum thus:


enum { protected_, private_, none }

making the shorter version perfectly legal.

mixin(signal!(string, int)("valueChanged", protected_));

Your concern about extra typing by always needing to specify 
the scope is thus unwarranted.


This would work, but would make the protection parameter an 
int. Not really any more beautiful than a string. The advantage 
of the enum for me was, that it is clear from the signature 
what are valid protections, this advantage gets lost with an 
anonymous enum.


The only remaining advantage would be tool support for 
completion, but I don't think it is worth it.


enum Protection { protected_, private_, none }
alias protected_ = Protection.protected_;
alias private_ = Protection.private_;
alias none = Protection.none;

Best of both worlds?

Re: DIP 50 - AST macros

[Meta]

On Thursday, 14 November 2013 at 09:12:38 UTC, Walter Bright 
wrote:
I do understand this. I've not only extensively used macro 
systems, I've designed two successful ones and implemented 
other peoples' designs.


I've also seen the sheer awfulness of what happens with these 
systems over the long term. The fascinating thing about this 
awfulness is people are well aware of it in everyone's macro 
libraries but their own.


What kind of macro systems are you talking about? C-like macros? 
Assembly macros? Lisp-like macros? It seems that Jacob's proposed 
system is similar to none of these.

Re: Vibe.d & DUB

[Chris]

On Thursday, 14 November 2013 at 16:42:05 UTC, Chris wrote:
On Thursday, 14 November 2013 at 16:32:59 UTC, Sönke Ludwig 
wrote:

Am 14.11.2013 16:54, schrieb Chris:
Excuse me my ignorance. I haven't used DUB for a while now. 
Don't know
what's wrong. Found no hint on the (h)internet. I it that the 
latest

version of dmd is "too high" for dub? Use dmd2.063 instead?

$ dub upgrade
Upgrading project in /home/path/to/project
Triggering update of package vibe-d
Geting package metadata for vibe-d failed, exception:
object.Exception@source/dub/project.d(460): Could not find 
package

candidate for vibe-d >=0.7.12
(...)


Judging by the line number of the exception, you are using DUB 
0.9.13. There have been a number of changes since then, 
including how version numbers are validated. It's possible 
that the reason for the error is the latest vibe.d version 
"0.7.18-beta.1".


I'd recommend to upgrade to 0.9.19 - everything is working 
there AFAICS.


Thanks for the answer. I tried to update dub, but it says that 
"dub is already the newest version.", which is hard for me to 
believe.


Ubuntu 12.04 LTS

Re: Vibe.d & DUB

[Chris]

On Thursday, 14 November 2013 at 16:32:59 UTC, Sönke Ludwig wrote:

Am 14.11.2013 16:54, schrieb Chris:
Excuse me my ignorance. I haven't used DUB for a while now. 
Don't know
what's wrong. Found no hint on the (h)internet. I it that the 
latest

version of dmd is "too high" for dub? Use dmd2.063 instead?

$ dub upgrade
Upgrading project in /home/path/to/project
Triggering update of package vibe-d
Geting package metadata for vibe-d failed, exception:
object.Exception@source/dub/project.d(460): Could not find 
package

candidate for vibe-d >=0.7.12
(...)


Judging by the line number of the exception, you are using DUB 
0.9.13. There have been a number of changes since then, 
including how version numbers are validated. It's possible that 
the reason for the error is the latest vibe.d version 
"0.7.18-beta.1".


I'd recommend to upgrade to 0.9.19 - everything is working 
there AFAICS.


Thanks for the answer. I tried to update dub, but it says that 
"dub is already the newest version.", which is hard for me to 
believe.

Re: Vibe.d & DUB

[Sönke Ludwig]

Am 14.11.2013 16:54, schrieb Chris:

Excuse me my ignorance. I haven't used DUB for a while now. Don't know
what's wrong. Found no hint on the (h)internet. I it that the latest
version of dmd is "too high" for dub? Use dmd2.063 instead?

$ dub upgrade
Upgrading project in /home/path/to/project
Triggering update of package vibe-d
Geting package metadata for vibe-d failed, exception:
object.Exception@source/dub/project.d(460): Could not find package
candidate for vibe-d >=0.7.12
(...)


Judging by the line number of the exception, you are using DUB 0.9.13. 
There have been a number of changes since then, including how version 
numbers are validated. It's possible that the reason for the error is 
the latest vibe.d version "0.7.18-beta.1".


I'd recommend to upgrade to 0.9.19 - everything is working there AFAICS.

Re: Vibe.d & DUB

[Chris]

On Thursday, 14 November 2013 at 15:54:09 UTC, Chris wrote:
Excuse me my ignorance. I haven't used DUB for a while now. 
Don't know what's wrong. Found no hint on the (h)internet. I it 
that the latest version of dmd is "too high" for dub? Use 
dmd2.063 instead?


$ dub upgrade
Upgrading project in /home/path/to/project
Triggering update of package vibe-d
Geting package metadata for vibe-d failed, exception: 
object.Exception@source/dub/project.d(460): Could not find 
package candidate for vibe-d >=0.7.12


dub(pure @safe bool std.exception.enforce!(bool).enforce(bool, 
lazy const(char)[], immutable(char)[], uint)+0x2c) [0x81bd8f4]
dub(bool 
dub.project.Project.gatherMissingDependencies(dub.packagesupplier.PackageSupplier[], 
dub.dependency.DependencyGraph).int __foreachbody4035(ref 
immutable(char)[], ref 
dub.dependency.RequestedDependency)+0x20f) [0x81b852f]

dub(_aaApply2+0x4f) [0x8232f8f]
dub(bool 
dub.project.Project.gatherMissingDependencies(dub.packagesupplier.PackageSupplier[], 
dub.dependency.DependencyGraph)+0xe0) [0x81b8288]
dub(dub.project.Action[] 
dub.project.Project.determineActions(dub.packagesupplier.PackageSupplier[], 
int)+0x9f) [0x81b7877]
dub(bool dub.dub.Dub.update(dub.project.UpdateOptions)+0x54) 
[0x82262c4]

dub(_Dmain+0x735) [0x81a0d41]
dub(extern (C) int rt.dmain2._d_run_main(int, char**, extern 
(C) int function(char[][])*).void runMain()+0x10) [0x82341d4]
dub(extern (C) int rt.dmain2._d_run_main(int, char**, extern 
(C) int function(char[][])*).void tryExec(scope void 
delegate())+0x18) [0x8233e80]
dub(extern (C) int rt.dmain2._d_run_main(int, char**, extern 
(C) int function(char[][])*).void runAll()+0x32) [0x8234212]
dub(extern (C) int rt.dmain2._d_run_main(int, char**, extern 
(C) int function(char[][])*).void tryExec(scope void 
delegate())+0x18) [0x8233e80]

dub(_d_run_main+0x121) [0x8233e51]
dub(main+0x14) [0x8233d24]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3) 
[0xb74cc4d3]

Could not resolve dependencies
The dependency graph could not be filled.
The following changes could be performed:
Failure vibe-d >=0.7.12, projectLocal
Issued by:
 TTSServer: >=0.7.12


Forgot to mention that it's the same for 0.7.17

Re: Ehem, ARM

[Chris]

On Thursday, 14 November 2013 at 16:14:16 UTC, Kai Nacke wrote:

On Thursday, 14 November 2013 at 14:47:47 UTC, Chris wrote:
I know, I know, this question has been asked many times 
before. But it came up in a meeting the other day: is there 
any work being done on making D an ARM citizen so that 
_non-trivial_ D code can be ported to smartphones and the 
like? If so, what it the rough time frame?


Hi Chris!

LDC can generate binaries for ARM but still has a major bug 
which prevents working exception handling. My new developer 
board arrived this week so I hope to solve this issue soon.


But this is only half of the story. My target is Linux/ARM 
which is already supported by druntime/phobos. If you target a 
smartphone then you also have to add Android or iOS support to 
druntime/phobos. I don't know if somebody is working on this 
topic.


Regards,
Kai


Thanks for your reply, Kai. That's good news, however iOS and 
Android support is crucial. I hope D can soon be ported to ARM, 
it's just too important.

Re: Ehem, ARM

[Kai Nacke]

On Thursday, 14 November 2013 at 14:47:47 UTC, Chris wrote:
I know, I know, this question has been asked many times before. 
But it came up in a meeting the other day: is there any work 
being done on making D an ARM citizen so that _non-trivial_ D 
code can be ported to smartphones and the like? If so, what it 
the rough time frame?


Hi Chris!

LDC can generate binaries for ARM but still has a major bug which 
prevents working exception handling. My new developer board 
arrived this week so I hope to solve this issue soon.


But this is only half of the story. My target is Linux/ARM which 
is already supported by druntime/phobos. If you target a 
smartphone then you also have to add Android or iOS support to 
druntime/phobos. I don't know if somebody is working on this 
topic.


Regards,
Kai

Vibe.d & DUB

[Chris]

Excuse me my ignorance. I haven't used DUB for a while now. Don't 
know what's wrong. Found no hint on the (h)internet. I it that 
the latest version of dmd is "too high" for dub? Use dmd2.063 
instead?


$ dub upgrade
Upgrading project in /home/path/to/project
Triggering update of package vibe-d
Geting package metadata for vibe-d failed, exception: 
object.Exception@source/dub/project.d(460): Could not find 
package candidate for vibe-d >=0.7.12


dub(pure @safe bool std.exception.enforce!(bool).enforce(bool, 
lazy const(char)[], immutable(char)[], uint)+0x2c) [0x81bd8f4]
dub(bool 
dub.project.Project.gatherMissingDependencies(dub.packagesupplier.PackageSupplier[], 
dub.dependency.DependencyGraph).int __foreachbody4035(ref 
immutable(char)[], ref dub.dependency.RequestedDependency)+0x20f) 
[0x81b852f]

dub(_aaApply2+0x4f) [0x8232f8f]
dub(bool 
dub.project.Project.gatherMissingDependencies(dub.packagesupplier.PackageSupplier[], 
dub.dependency.DependencyGraph)+0xe0) [0x81b8288]
dub(dub.project.Action[] 
dub.project.Project.determineActions(dub.packagesupplier.PackageSupplier[], 
int)+0x9f) [0x81b7877]
dub(bool dub.dub.Dub.update(dub.project.UpdateOptions)+0x54) 
[0x82262c4]

dub(_Dmain+0x735) [0x81a0d41]
dub(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) 
int function(char[][])*).void runMain()+0x10) [0x82341d4]
dub(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) 
int function(char[][])*).void tryExec(scope void 
delegate())+0x18) [0x8233e80]
dub(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) 
int function(char[][])*).void runAll()+0x32) [0x8234212]
dub(extern (C) int rt.dmain2._d_run_main(int, char**, extern (C) 
int function(char[][])*).void tryExec(scope void 
delegate())+0x18) [0x8233e80]

dub(_d_run_main+0x121) [0x8233e51]
dub(main+0x14) [0x8233d24]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0xb74cc4d3]
Could not resolve dependencies
The dependency graph could not be filled.
The following changes could be performed:
Failure vibe-d >=0.7.12, projectLocal
Issued by:
 TTSServer: >=0.7.12

Re: Review of std.signal

[Robert]

Enums in D may be scoped. There is nothing that prevents you 
from declaring your enum thus:


enum { protected_, private_, none }

making the shorter version perfectly legal.

mixin(signal!(string, int)("valueChanged", protected_));

Your concern about extra typing by always needing to specify 
the scope is thus unwarranted.


This would work, but would make the protection parameter an int. 
Not really any more beautiful than a string. The advantage of the 
enum for me was, that it is clear from the signature what are 
valid protections, this advantage gets lost with an anonymous 
enum.


The only remaining advantage would be tool support for 
completion, but I don't think it is worth it.

Re: Ehem, ARM

[Chris]

On Thursday, 14 November 2013 at 15:31:25 UTC, eles wrote:

On Thursday, 14 November 2013 at 14:47:47 UTC, Chris wrote:
I know, I know, this question has been asked many times 
before. But it came up in a meeting the other day: is there 
any work being done on making D an ARM citizen so that 
_non-trivial_ D code can be ported to smartphones and the 
like? If so, what it the rough time frame?


A D.arm or D.ports group?


Yes. Mobile devices cannot be ignored.

Re: Ehem, ARM

[eles]

On Thursday, 14 November 2013 at 14:47:47 UTC, Chris wrote:
I know, I know, this question has been asked many times before. 
But it came up in a meeting the other day: is there any work 
being done on making D an ARM citizen so that _non-trivial_ D 
code can be ported to smartphones and the like? If so, what it 
the rough time frame?


A D.arm or D.ports group?

Re: Is there any chance of htod being improved or ported to other platforms?

[eles]

On Thursday, 14 November 2013 at 15:25:37 UTC, Dicebot wrote:
On Thursday, 14 November 2013 at 15:22:28 UTC, Gary Willoughby 
wrote:
Is there any chance of htod being improved or ported to other 
platforms?


http://dlang.org/htod.html

Is this tool still capable or is it a legacy tool now?


It does not reliably work even on Windows. Legacy.

Use dstep (https://github.com/jacob-carlborg/dstep)


Shall replace the above link towards htod with one towards dstep 
or at least add a big red message at the top of the htod page.

Re: Is there any chance of htod being improved or ported to other platforms?

[Dicebot]

On Thursday, 14 November 2013 at 15:22:28 UTC, Gary Willoughby 
wrote:
Is there any chance of htod being improved or ported to other 
platforms?


http://dlang.org/htod.html

Is this tool still capable or is it a legacy tool now?


It does not reliably work even on Windows. Legacy.

Use dstep (https://github.com/jacob-carlborg/dstep)

Is there any chance of htod being improved or ported to other platforms?

[Gary Willoughby]

Is there any chance of htod being improved or ported to other 
platforms?


http://dlang.org/htod.html

Is this tool still capable or is it a legacy tool now?

Ehem, ARM

[Chris]

I know, I know, this question has been asked many times before. 
But it came up in a meeting the other day: is there any work 
being done on making D an ARM citizen so that _non-trivial_ D 
code can be ported to smartphones and the like? If so, what it 
the rough time frame?

Re: [Poll] On Linux, what should we commonly use as sub-directory name for D?

[Joseph Rushton Wakeling]

On 12/11/13 21:06, Dicebot wrote:

"dlang" should supersede "d" in all domains, it is a simple matter of ambiguity
(I, personally, won't change it whatever poll results are)


I suggest the opposite -- if "d" is up for grabs, we should grab it and hold on 
to it.  Ambiguity is best overcome by creating a situation where d definitely 
means D. ;-)

Re: [Poll] On Linux, what should we commonly use as sub-directory name for D?

[Dicebot]

On Wednesday, 13 November 2013 at 15:07:57 UTC, Iain Buclaw wrote:
That requires co-operation from upstream compiler projects... 
distributors
are free to have local patches by all means to force the 
compilers to look

in non-standard directories. ;-)


Well, you have co-operated with me willingly to help me write 
those patches some time ago if you remember that ;)