Re: Why I chose D over Ada and Eiffel

[Timon Gehr]

On 08/21/2013 07:17 PM, deadalnix wrote:


You want no bugs ? Go for Haskell.


If you want no bugs, go for formal correctness proof.


But you'll get no convenience


Yes you do. A lot.


or performance.


Let's say "easily predictable performance".


The good thing if that if it does compile, you are pretty
sure that it does the right thing.

Re: Why I chose D over Ada and Eiffel

[Timon Gehr]

On 08/21/2013 07:12 PM, Andrei Alexandrescu wrote:


The deduper would be insensitive to alpha renaming, e.g. "int a = 10;"
and "int b = 10;" would be identical.


This is not alpha renaming, it is just renaming. :o)

Eg. "{int a = 10; foo(a);}" and "{int b = 10; foo(b);}" would be identical.

Re: OT; Will MS kill .NET ?

[PauloPinto]

On Thursday, 22 August 2013 at 01:40:05 UTC, Gambler wrote:

On 8/20/2013 3:18 PM, Paulo Pinto wrote:

On Tuesday, 20 August 2013 at 16:07:00 UTC, Kagamin wrote:

http://msdn.microsoft.com/en-us/library/system.type.makegenerictype.aspx
How would you implement this in native code?


Like we use to do in the old days when we were forced to 
rewrite

Assembly on the fly.

Allocate a memory buffer with the required sizes and perform 
the

required set of initializations.

This is no different than constructing C++ classes during 
runtime,
initializing the required helper structures like vtbl and 
calling

constructors.

Nothing that cannot be done with either a set of helper 
functions on the

language runtime, or generating inline code.

Yes, I am aware that this requires the ability to execute code 
from the

data segment.

--
Paulo


Isn't the approach you're describing *much* more error-prone 
than the

example above?


It is the compiler that generates the code, what is error prone 
about it?



--
Paulo

Re: Why I chose D over Ada and Eiffel

[PauloPinto]

On Thursday, 22 August 2013 at 05:22:17 UTC, deadalnix wrote:

On Wednesday, 21 August 2013 at 17:45:29 UTC, Ramon wrote:
Moor's law is kaput, finish, niet, we don't know how to use 
the extra transistor.


Even if that were true, we have gone quite some distance. Not 
even talking about Sparc T4 or 8-core X86, my smartphone is 
more powerful than what I had as computer 10 years or so ago.




Just read this this : 
ftp://ftp.cs.utexas.edu/pub/dburger/papers/ISCA11.pdf and come 
back informed.


A vast amount of software is written in javascript, java, C#, 
PHP and many "safe" languages, and still are crippled with 
bugs.


Do I get you right considering js, java, C# and PHP being 
"safe" languages?




They are dramatically superior to C in term of safety.



Like Modula-2, Pascal dialects (mainly Turbo/Apple Pascal) and
Ada are, but lost their place in developer's hearts.

Now with D, Rust and even Go we can have another go at making
system programming a better world.

--
Paulo

Re: Why I chose D over Ada and Eiffel

[deadalnix]

On Wednesday, 21 August 2013 at 17:45:29 UTC, Ramon wrote:
Moor's law is kaput, finish, niet, we don't know how to use 
the extra transistor.


Even if that were true, we have gone quite some distance. Not 
even talking about Sparc T4 or 8-core X86, my smartphone is 
more powerful than what I had as computer 10 years or so ago.




Just read this this : 
ftp://ftp.cs.utexas.edu/pub/dburger/papers/ISCA11.pdf and come 
back informed.


A vast amount of software is written in javascript, java, C#, 
PHP and many "safe" languages, and still are crippled with 
bugs.


Do I get you right considering js, java, C# and PHP being 
"safe" languages?




They are dramatically superior to C in term of safety.

Some codebase are trully scary. Look at gdb's source code or 
gtk's.


Written in C/C++ ...



Well look at phpBB's source code then. Horrible codebase isn't 
language specific.


You want no bugs ? Go for Haskell. But you'll get no 
convenience or performance. The good thing if that if it does 
compile, you are pretty sure that it does the right thing.


Why should I? Isn't that what D promises, too (and probably is 
right)?




D promise a pragmatic balance between safety, performance, ease 
of use, productivity, etc . . .


On another perspective: Consider this question "Would you be 
willing to have all your software (incl. OS) running 10% or 
even 20% slower but without bugs, leaks, (unintended) backdoors 
and the like?"


My guess: Upwards of 80% would happily chime "YES!".


Would you accept it if it means a 3x slowdown and no real time 
capabilities (no video games for instance) ?

Re: Download page needs a tidy up

[Tyler Jameson Little]

On Thursday, 22 August 2013 at 03:33:38 UTC, Manu wrote:

On 22 August 2013 13:18, Brad Anderson  wrote:


On Thursday, 22 August 2013 at 03:07:39 UTC, Manu wrote:


So I'm trying to find windows binaries for GDC and LDC...

First place I look is dlang.org/download. Appears to be for 
DMD... keep

looking.

I look at the GDC/LDC wiki pages. No links to binaries 
anywhere.

GDC and LDC home pages... no links to binaries.
Github doesn't host binaries anymore...

Where are they?

Turns out there are links to the GDC binaries (hosted on 
bitbucket) on

dlang.org/download.
...I didn't previously notice they were there, never scrolled 
down far
enough. The impression you get from the top of the page is 
that
dlang.orgis just DMD related, and I quickly dismissed it 
previously


 _<




But there's still no LDC binary there... where is it?

This needs to be fixed. You can argue I'm retarded and 
ignorant, but as an
end user, it should take me no more than 5 seconds to find 
the download

button.

I suggest, on the front page of dlang.org, there should be a 
MASSIVE
button: "DOWNLOAD D COMPILERS", and the download page should 
be tweaked to

be more obviously compiler agnostic.

D1 and DMC consume an unreasonable amount of realestate, 
hiding GDC/LDC
(surely basically nobody is looking for those?), perhaps they 
should be
reduced to small test links with the other links down the 
bottom of the

page?
This will allow room to present GDC and LDC without scrolling.

And why is there no LDC binary?



I tried to fix some of these problems here[1].  Maybe someone 
can take

what I did and fix it up enough to be used.

1. 
https://github.com/D-**Programming-Language/dlang.**org/pull/304




Definitely an improvement!
Although if I were to be critical, I'd say when scrolling the 
page, I find
the almost random layout of the bright red buttons scattered 
all over the

place to be rather overwhelming.

I was also briefly confused by the 32bit/64bit scattered 
everywhere. My

initial assumption was that it specified the toolchain's target
architecture :/
But since it's the compiler's host arch, I'd say that for 
Windows where
32bit binaries will run on any version of windows and no 64bit 
binary is
offered, and OSX which has only ever been 64bit, there's no 
need to write

it for those platforms. It's just confusing.


Why not sniff the platform? I think Firefox & Dart websites do 
this. This can be retrieved with navigator.platform: 
https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.platform


Of course, the others should be easily accessible.

Re: Download page needs a tidy up

[Manu]

On 22 August 2013 13:23, Manu  wrote:

> I got the latest GDC from dlang.org/download, but it doesn't work.
> libiconv-2.dll (and possibly others?) is not included in the package.
>
> If this depends on another package being present, there is no text
> anywhere along the download path to inform the user.
>

And if I try the older 4.6.1 toolchain, it complains about libgmp-3.dll
missing (and maybe others).

On 22 August 2013 13:07, Manu  wrote:
>
>> So I'm trying to find windows binaries for GDC and LDC...
>>
>> First place I look is dlang.org/download. Appears to be for DMD... keep
>> looking.
>>
>> I look at the GDC/LDC wiki pages. No links to binaries anywhere.
>> GDC and LDC home pages... no links to binaries.
>> Github doesn't host binaries anymore...
>>
>> Where are they?
>>
>> Turns out there are links to the GDC binaries (hosted on bitbucket) on
>> dlang.org/download.
>> ...I didn't previously notice they were there, never scrolled down far
>> enough. The impression you get from the top of the page is that dlang.orgis 
>> just DMD related, and I quickly dismissed it previously >_<
>>
>> But there's still no LDC binary there... where is it?
>>
>> This needs to be fixed. You can argue I'm retarded and ignorant, but as
>> an end user, it should take me no more than 5 seconds to find the download
>> button.
>>
>> I suggest, on the front page of dlang.org, there should be a MASSIVE
>> button: "DOWNLOAD D COMPILERS", and the download page should be tweaked to
>> be more obviously compiler agnostic.
>>
>> D1 and DMC consume an unreasonable amount of realestate, hiding GDC/LDC
>> (surely basically nobody is looking for those?), perhaps they should be
>> reduced to small test links with the other links down the bottom of the
>> page?
>> This will allow room to present GDC and LDC without scrolling.
>>
>> And why is there no LDC binary?
>>
>
>

Re: Download page needs a tidy up

[Manu]

On 22 August 2013 13:37, Tyler Jameson Little  wrote:

> On Thursday, 22 August 2013 at 03:07:39 UTC, Manu wrote:
>
>> But there's still no LDC binary there... where is it?
>>
>
>> This needs to be fixed. You can argue I'm retarded and ignorant, but as an
>> end user, it should take me no more than 5 seconds to find the download
>> button.
>>
>
> Agreed. Some may not be as persistent as you...


Most, I'd imagine. Especially if they're a new user (the most important
kind!) who don't have a vested interest in D.


 I suggest, on the front page of dlang.org, there should be a MASSIVE
>> button: "DOWNLOAD D COMPILERS", and the download page should be tweaked to
>> be more obviously compiler agnostic.
>>
>
> I'm not too sure about this. DMD is the reference compiler, so people
> should be using that for learning, then graduate to GDC or LDC if they need
> something faster.


So put it first, but the others should be visible.
The other compilers need to be used. How will people find/report bugs if
they don't use them?

I've also heard many argue that LDC should be the reference compiler. And
I'm inclined to agree.
Either way, they need prominent placement so people know they exist, and
they get tested.

Re: Download page needs a tidy up

[Tyler Jameson Little]

On Thursday, 22 August 2013 at 03:07:39 UTC, Manu wrote:

So I'm trying to find windows binaries for GDC and LDC...

First place I look is dlang.org/download. Appears to be for 
DMD... keep

looking.

I look at the GDC/LDC wiki pages. No links to binaries anywhere.
GDC and LDC home pages... no links to binaries.
Github doesn't host binaries anymore...

Where are they?

Turns out there are links to the GDC binaries (hosted on 
bitbucket) on

dlang.org/download.
...I didn't previously notice they were there, never scrolled 
down far

enough. The impression you get from the top of the page is that
dlang.orgis just DMD related, and I quickly dismissed it 
previously

_<


Also, where's the Linux (FreeBSD?, Mac OS X?) downloads for GDC? 
I get it through my package manager, but it seems there should be 
a download for it as well. If not a binary, then at least a 
tar.gz...



But there's still no LDC binary there... where is it?

This needs to be fixed. You can argue I'm retarded and 
ignorant, but as an
end user, it should take me no more than 5 seconds to find the 
download

button.


Agreed. Some may not be as persistent as you...

I suggest, on the front page of dlang.org, there should be a 
MASSIVE
button: "DOWNLOAD D COMPILERS", and the download page should be 
tweaked to

be more obviously compiler agnostic.


I'm not too sure about this. DMD is the reference compiler, so 
people should be using that for learning, then graduate to GDC or 
LDC if they need something faster.


D1 and DMC consume an unreasonable amount of realestate, hiding 
GDC/LDC
(surely basically nobody is looking for those?), perhaps they 
should be
reduced to small test links with the other links down the 
bottom of the

page?
This will allow room to present GDC and LDC without scrolling.


+1

Do we really want D1 compilers that easily accessable? I assume 
everyone relying on them already has a copy, and even if they 
need another, they can click on an "Archive" link or something...



And why is there no LDC binary?

Re: Download page needs a tidy up

[Manu]

On 22 August 2013 13:18, Brad Anderson  wrote:

> On Thursday, 22 August 2013 at 03:07:39 UTC, Manu wrote:
>
>> So I'm trying to find windows binaries for GDC and LDC...
>>
>> First place I look is dlang.org/download. Appears to be for DMD... keep
>> looking.
>>
>> I look at the GDC/LDC wiki pages. No links to binaries anywhere.
>> GDC and LDC home pages... no links to binaries.
>> Github doesn't host binaries anymore...
>>
>> Where are they?
>>
>> Turns out there are links to the GDC binaries (hosted on bitbucket) on
>> dlang.org/download.
>> ...I didn't previously notice they were there, never scrolled down far
>> enough. The impression you get from the top of the page is that
>> dlang.orgis just DMD related, and I quickly dismissed it previously
>>
>>  _<
>>>
>>
>> But there's still no LDC binary there... where is it?
>>
>> This needs to be fixed. You can argue I'm retarded and ignorant, but as an
>> end user, it should take me no more than 5 seconds to find the download
>> button.
>>
>> I suggest, on the front page of dlang.org, there should be a MASSIVE
>> button: "DOWNLOAD D COMPILERS", and the download page should be tweaked to
>> be more obviously compiler agnostic.
>>
>> D1 and DMC consume an unreasonable amount of realestate, hiding GDC/LDC
>> (surely basically nobody is looking for those?), perhaps they should be
>> reduced to small test links with the other links down the bottom of the
>> page?
>> This will allow room to present GDC and LDC without scrolling.
>>
>> And why is there no LDC binary?
>>
>
> I tried to fix some of these problems here[1].  Maybe someone can take
> what I did and fix it up enough to be used.
>
> 1. 
> https://github.com/D-**Programming-Language/dlang.**org/pull/304
>

Definitely an improvement!
Although if I were to be critical, I'd say when scrolling the page, I find
the almost random layout of the bright red buttons scattered all over the
place to be rather overwhelming.

I was also briefly confused by the 32bit/64bit scattered everywhere. My
initial assumption was that it specified the toolchain's target
architecture :/
But since it's the compiler's host arch, I'd say that for Windows where
32bit binaries will run on any version of windows and no 64bit binary is
offered, and OSX which has only ever been 64bit, there's no need to write
it for those platforms. It's just confusing.

Re: Download page needs a tidy up

[Manu]

I got the latest GDC from dlang.org/download, but it doesn't work.
libiconv-2.dll (and possibly others?) is not included in the package.

If this depends on another package being present, there is no text anywhere
along the download path to inform the user.


On 22 August 2013 13:07, Manu  wrote:

> So I'm trying to find windows binaries for GDC and LDC...
>
> First place I look is dlang.org/download. Appears to be for DMD... keep
> looking.
>
> I look at the GDC/LDC wiki pages. No links to binaries anywhere.
> GDC and LDC home pages... no links to binaries.
> Github doesn't host binaries anymore...
>
> Where are they?
>
> Turns out there are links to the GDC binaries (hosted on bitbucket) on
> dlang.org/download.
> ...I didn't previously notice they were there, never scrolled down far
> enough. The impression you get from the top of the page is that dlang.orgis 
> just DMD related, and I quickly dismissed it previously >_<
>
> But there's still no LDC binary there... where is it?
>
> This needs to be fixed. You can argue I'm retarded and ignorant, but as an
> end user, it should take me no more than 5 seconds to find the download
> button.
>
> I suggest, on the front page of dlang.org, there should be a MASSIVE
> button: "DOWNLOAD D COMPILERS", and the download page should be tweaked to
> be more obviously compiler agnostic.
>
> D1 and DMC consume an unreasonable amount of realestate, hiding GDC/LDC
> (surely basically nobody is looking for those?), perhaps they should be
> reduced to small test links with the other links down the bottom of the
> page?
> This will allow room to present GDC and LDC without scrolling.
>
> And why is there no LDC binary?
>

Re: Download page needs a tidy up

[Brad Anderson]

On Thursday, 22 August 2013 at 03:07:39 UTC, Manu wrote:

So I'm trying to find windows binaries for GDC and LDC...

First place I look is dlang.org/download. Appears to be for 
DMD... keep

looking.

I look at the GDC/LDC wiki pages. No links to binaries anywhere.
GDC and LDC home pages... no links to binaries.
Github doesn't host binaries anymore...

Where are they?

Turns out there are links to the GDC binaries (hosted on 
bitbucket) on

dlang.org/download.
...I didn't previously notice they were there, never scrolled 
down far

enough. The impression you get from the top of the page is that
dlang.orgis just DMD related, and I quickly dismissed it 
previously

_<


But there's still no LDC binary there... where is it?

This needs to be fixed. You can argue I'm retarded and 
ignorant, but as an
end user, it should take me no more than 5 seconds to find the 
download

button.

I suggest, on the front page of dlang.org, there should be a 
MASSIVE
button: "DOWNLOAD D COMPILERS", and the download page should be 
tweaked to

be more obviously compiler agnostic.

D1 and DMC consume an unreasonable amount of realestate, hiding 
GDC/LDC
(surely basically nobody is looking for those?), perhaps they 
should be
reduced to small test links with the other links down the 
bottom of the

page?
This will allow room to present GDC and LDC without scrolling.

And why is there no LDC binary?


I tried to fix some of these problems here[1].  Maybe someone can 
take what I did and fix it up enough to be used.


1. https://github.com/D-Programming-Language/dlang.org/pull/304

Re: Range interface for std.serialization

[Tyler Jameson Little]

On Wednesday, 21 August 2013 at 20:21:49 UTC, Dicebot wrote:

My 5 cents:

On Wednesday, 21 August 2013 at 18:45:48 UTC, Jacob Carlborg 
wrote:
If this alternative is chosen how should the range for the 
XmlArchive work like? Currently the archive returns a string, 
should the range just wrap the string and step through 
character by character? That doesn't sound very effective.


It should be range of strings - one call to popFront should 
serialize one object from input object range and provide 
matching string buffer.


I don't like this because it still caches the whole object into 
memory. In a memory-restricted application, this is unacceptable.


I think one call to popFront should release part of the 
serialized object. For example:


struct B {
int c, d;
}

struct A {
int a;
B b;
}

The JSON output of this would be:

{
a: 0,
b: {
c: 0,
d: 0
}
}

There's no reason why the serializer can't output this in chunks:

Chunk 1:

{
a: 0,

Chunk 2:

b: {

Etc...

Most archive formats should support chunking. I realize this may 
be a rather large change to Orange, but I think it's a direction 
it should be headed.



Alternative AO2:

Another idea is the archive is an output range, having this 
interface:


auto archive = new XmlArchive!(char);
archive.writeTo(outputRange);

auto serializer = new Serializer(archive);
serializer.serialize(new Object);

Use the output range when the serialization is done.


I can't imagine a use case for this. Adding ranges just because 
you can is not very good :)


I completely agree.

A problem with this, actually I don't know if it's considered 
a problem, is that the following won't be possible:


auto archive = new XmlArchive!(InputRange);
archive.data = archive.data;


What this snippet should do?

Which one would usually expect from an OO API. The problem 
here is that the archive is typed for the original input range 
but the returned range from "data" is of a different type.


Range-based algorithms don't assign ranges. Transferring data 
from one range to another is done via copy(sourceRange, 
destRange) and similar tools.


This is just a read-only property, which arguably doesn't break 
misconceptions. There should be no reason to assign directly to a 
range.


It looks like difficulties come from your initial assumption 
that one call to serialize/deserialize implies one object - in 
that model ranges hardly are useful. I don't think it is a 
reasonable restriction. What is practically useful is 
(de)serialization of large list of objects lazily - and this is 
a natural job for ranges.


I agree that (de)serializing a large list of objects lazily is 
important, but I don't think that's the natural interface for a 
Serializer. I think that each object should be lazily serialized 
instead to maximize throughput.


If a Serializer is defined as only (de)serializing a single 
object, then serializing a range of Type would be as simple as 
using map() with a Serializer (getting a range of Serialize). If 
the allocs are too much, then the same serializer can be used, 
but serialize one-at-a-time.


My main point here is that data should be written as it's being 
serialized. In a networked application, it may take a few packets 
to encode a larger object, so the first packets should be sent 
ASAP.


As usual, feel free to destroy =D

Download page needs a tidy up

[Manu]

So I'm trying to find windows binaries for GDC and LDC...

First place I look is dlang.org/download. Appears to be for DMD... keep
looking.

I look at the GDC/LDC wiki pages. No links to binaries anywhere.
GDC and LDC home pages... no links to binaries.
Github doesn't host binaries anymore...

Where are they?

Turns out there are links to the GDC binaries (hosted on bitbucket) on
dlang.org/download.
...I didn't previously notice they were there, never scrolled down far
enough. The impression you get from the top of the page is that
dlang.orgis just DMD related, and I quickly dismissed it previously
>_<

But there's still no LDC binary there... where is it?

This needs to be fixed. You can argue I'm retarded and ignorant, but as an
end user, it should take me no more than 5 seconds to find the download
button.

I suggest, on the front page of dlang.org, there should be a MASSIVE
button: "DOWNLOAD D COMPILERS", and the download page should be tweaked to
be more obviously compiler agnostic.

D1 and DMC consume an unreasonable amount of realestate, hiding GDC/LDC
(surely basically nobody is looking for those?), perhaps they should be
reduced to small test links with the other links down the bottom of the
page?
This will allow room to present GDC and LDC without scrolling.

And why is there no LDC binary?

Re: Why I chose D over Ada and Eiffel

[bearophile]

Tyler Jameson Little:

It also has generics, which are runtime generics if I'm not 
mistaken.


- templates instead of generics (little reason to take a 
performance hit)


As far as I know Rust uses monomorphization just like C++ and D 
for generics. The difference in generics between D and Rust is 
that Rust has them strongly typed with type classes (this means 
inside a function templated on an argument, you can't do on that 
argument operations that are not specified in its static type 
class). But unlike the type classes of Haskell, the Rust ones are 
designed to have no run-time hit (but this makes them currently 
less powerful. Some persons are trying to improve this in Rust). 
Perhaps the original poster of this thread is looking for this.


Bye,
bearophile

Re: Why I chose D over Ada and Eiffel

[Dicebot]

On Thursday, 22 August 2013 at 02:06:13 UTC, Tyler Jameson Little 
wrote:
It also has generics, which are runtime generics if I'm not 
mistaken.


Both.

Re: Why I chose D over Ada and Eiffel

[Tyler Jameson Little]

On Wednesday, 21 August 2013 at 17:45:29 UTC, Ramon wrote:

On Wednesday, 21 August 2013 at 17:17:52 UTC, deadalnix wrote:
You want no bugs ? Go for Haskell. But you'll get no 
convenience or performance. The good thing if that if it does 
compile, you are pretty sure that it does the right thing.


Why should I? Isn't that what D promises, too (and probably is 
right)?


On another perspective: Consider this question "Would you be 
willing to have all your software (incl. OS) running 10% or 
even 20% slower but without bugs, leaks, (unintended) backdoors 
and the like?"


My guess: Upwards of 80% would happily chime "YES!".


Have you looked at Rust? It promises to solve a few of the 
memory-related problems mentioned:


- no null pointer exceptions
- deterministic free (with owned pointers)
- optional garbage collection

It also has generics, which are runtime generics if I'm not 
mistaken. It doesn't have inheritance in the traditional OO 
sense, so you may not like that. I really like that it's LLVM 
compiled, so performance and cross-compiling should be pretty 
much solved problems.


There are still things that keep me here with D though:

- templates instead of generics (little reason to take a 
performance hit)

- CTFE
- inheritance (though I hardly use classes, they're handy 
sometimes)

- community
- array operations (int[] a; int[]b; auto c = a * b;)
  - I don't think these are automagically SIMD'd, but there's 
always hope =D

- similar to C++, so it's easy to find competent developers

Re: OT; Will MS kill .NET ?

[Gambler]

On 8/20/2013 3:18 PM, Paulo Pinto wrote:
> On Tuesday, 20 August 2013 at 16:07:00 UTC, Kagamin wrote:
>> http://msdn.microsoft.com/en-us/library/system.type.makegenerictype.aspx
>> How would you implement this in native code?
> 
> Like we use to do in the old days when we were forced to rewrite
> Assembly on the fly.
> 
> Allocate a memory buffer with the required sizes and perform the
> required set of initializations.
> 
> This is no different than constructing C++ classes during runtime,
> initializing the required helper structures like vtbl and calling
> constructors.
> 
> Nothing that cannot be done with either a set of helper functions on the
> language runtime, or generating inline code.
> 
> Yes, I am aware that this requires the ability to execute code from the
> data segment.
> 
> -- 
> Paulo

Isn't the approach you're describing *much* more error-prone than the
example above?

Re: Component programming

[H. S. Teoh]

On Mon, Aug 19, 2013 at 01:26:42PM +0200, Chris wrote:
> On Monday, 12 August 2013 at 12:28:36 UTC, Jason den Dulk wrote:
[...]
> Btw, I got an error message compiling dcal.d with ldmd2
> 
> dcal.d(34): Error: no property 'recurrence' for type 'Date'
> 
> It compiles with dmd and works.

What version of ldmd2 are you using? Looks like my code is incompatible
with earlier versions of the compiler. :-( I'd like to fix that, if
possible.


T

-- 
Meat: euphemism for dead animal. -- Flora

Re: Benchmarking a SIMD implementation of dot product

[Manu]

Me...


On 22 August 2013 07:11, Andrei Alexandrescu
wrote:

> On 8/21/13 1:58 PM, Walter Bright wrote:
>
>> http://www.reddit.com/r/**programming/comments/1ktue0/**
>> benchmarking_a_simd_**implementation_of_dot_product/
>>
>
> Loosely related question I've always been curious about: are there people
> who follow this newsgroup but not the announce group?
>
> Andrei
>
>

Re: GPGPU and D

[John Colvin]

On Sunday, 18 August 2013 at 08:40:33 UTC, Russel Winder wrote:

Luminousone, Atash, John,

Thanks for the email exchanges on this, there is a lot of good 
stuff in
there that needs to be extracted from the mail threads and 
turned into a
"manifesto" type document that can be used to drive getting a 
design and
realization together. The question is what infrastructure would 
work for
us to collaborate. Perhaps create a GitHub group and a 
repository to act

as a shared filestore?

I can certainly do that bit of admin and then try and start a 
document
summarizing the email threads so far, if that is a good way 
forward on

this.


Just a small update:
I'm working my way through the source of cl4d, cleaning up some 
things, reformatting to phobos style, taking advantage of some 
improvements in dmd etc.


https://github.com/John-Colvin/cl4d

Re: DQuick a GUI Library (prototype)

[Sebastian Graf]

On Wednesday, 21 August 2013 at 18:12:32 UTC, Michael wrote:

Lua itself can be embedded into any system.
At least we need a gui library that written in purely D way.

+1  Lua for scripting.


+1 from me too.
I had exactly the same idea some time ago, but was overwhelmed by 
the shear complexity.
If you go the lua route, you should look into MoonScript.org 
(CoffeeScript for lua => nicer function literals) and dig into 
reactive programming and my take on it: 
https://github.com/sgraf812/push

Re: A Discussion of Tuple Syntax

[Michel Fortin]

On 2013-08-21 16:59:17 +, Andrei Alexandrescu 
 said:



On 8/20/13 8:25 PM, Michel Fortin wrote:

On 2013-08-21 00:38:30 +, Andrei Alexandrescu
 said:


1. What do we need?


I think D needs less tuples. It has two kinds (language kind and
Phobos's kind), which is confusing. It should have just one that covers
most use cases.


Yah, fewer tuples (or assigning distinct names to what we call today 
such) would be awesome.


That seems like the only thing everyone agrees with. :-)


I'm unfortunately lost already. I was discussing tuples as in 
"anonymous structs", not as in "template tuples".


Well, the original post that started this discussion talked about both. 
I don't think narrowing it only to "anonymous structs" is going to 
solve the syntax problem as a whole.




 int a, b, c, d, e, f;
 swap(...(a, c, e), ...(b, d, f));


This looks like an example taken from a book in which "..." means some 
stuff is omitted.


Seriously, the major issue with tuples is a conceptual one. No pretty 
syntax is going to fix it alone. Unfortunately, talking about concepts 
requires inventing a syntax for them. The syntax then immediately get 
dismissed as ugly/impractical and no thought is given to what's under 
it. No wonder this is getting nowhere for the nth time when everyone 
thinks so superficially.


Just disregard the "..." syntax. It makes sense in the context of my 
other post. There's no way to appreciate it without that context (and 
even then, it can surely be improved).


The idea (in my other post) was to un-cripple language-level tuples 
with one simple fundamental change: allow them to be packed and 
expanded. With that you can cover 99% of what you want from a tuple 
struct using the built-in language-level tuple. Plus you can do some 
other things like the swap of aliases to variables shown above.


There is no reason for template-argument-tuples to be auto-expanding. 
If you fix that, as I proposed in my other post, you'll almost never 
need a library struct template to represent a tuple anymore. Thus, 
fewer tuples.


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

Re: A Discussion of Tuple Syntax

[Walter Bright]

On 8/20/2013 1:10 PM, Jonathan M Davis wrote:

On Tuesday, August 20, 2013 13:06:27 H. S. Teoh wrote:

On Tue, Aug 20, 2013 at 11:53:50AM -0700, Andrei Alexandrescu wrote:

Somebody shoot me.


[...]

BANG!


Don't kill him. He hasn't finished the allocators yet! ;)


Don't worry, we'll keep sliding food under his door!

Re: Benchmarking a SIMD implementation of dot product

[Andrei Alexandrescu]

On 8/21/13 1:58 PM, Walter Bright wrote:

http://www.reddit.com/r/programming/comments/1ktue0/benchmarking_a_simd_implementation_of_dot_product/


Loosely related question I've always been curious about: are there 
people who follow this newsgroup but not the announce group?


Andrei

Re: A possible suggestion for the Foreach loop

[Dylan Knutson]

On Wednesday, 21 August 2013 at 10:02:33 UTC, Tommi wrote:


Why not just do this:

import std.typetuple;

T foo(T)(ref T thing)
{
thing++; return thing * 2;
}

unittest
{
foreach(Type; TypeTuple!(int, long, uint))
{
{
Type tmp = 5;
assert(foo(tmp) == 12);
}

{
Type tmp = 0;
foo(tmp);
assert(tmp == 1);
}
}
}


Well, that's one way to go about doing it. But, this seems 
sub-optimal because a defining trait of unittests is that they're 
as small and focused on a single behavior for an 
object/function/whatever as possible. Grouping all testing into a 
single unittest breaks this convention.


Not to mention, we've got 'static if', and 'static assert', which 
can exist outside of function bodies and operate on compile time 
determinable values. It seems like a strange exception for 
foreach (which can already operate on compile time values) to be 
excluded from this group.

Benchmarking a SIMD implementation of dot product

[Walter Bright]

http://www.reddit.com/r/programming/comments/1ktue0/benchmarking_a_simd_implementation_of_dot_product/

Re: A possible suggestion for the Foreach loop

[Dylan Knutson]

On Wednesday, 21 August 2013 at 18:52:56 UTC, bearophile wrote:

Dicebot:


This bugzilla entry is on slightly related but different topic.

"declaration foreach" != "static foreach"


I think a well implemented "static foreach" is able to do 
anything a "declaration foreach" could do, and more. (If you 
don't think so, please show what's missing).


Bye,
bearophile


I do like the idea of it being called 'static foreach' instead of 
'foreach', to keep in step with how the rest of the language 
handles other compile time constructs (static assert). Plus, as 
you said in your bugreport, visual disambiguation between that 
and a runtime foreach is nice feedback for the programmer to pick 
up instantly.

Re: Range interface for std.serialization

[Dicebot]

My 5 cents:

On Wednesday, 21 August 2013 at 18:45:48 UTC, Jacob Carlborg 
wrote:
If this alternative is chosen how should the range for the 
XmlArchive work like? Currently the archive returns a string, 
should the range just wrap the string and step through 
character by character? That doesn't sound very effective.


It should be range of strings - one call to popFront should 
serialize one object from input object range and provide matching 
string buffer.



Alternative AO2:

Another idea is the archive is an output range, having this 
interface:


auto archive = new XmlArchive!(char);
archive.writeTo(outputRange);

auto serializer = new Serializer(archive);
serializer.serialize(new Object);

Use the output range when the serialization is done.


I can't imagine a use case for this. Adding ranges just because 
you can is not very good :)


A problem with this, actually I don't know if it's considered a 
problem, is that the following won't be possible:


auto archive = new XmlArchive!(InputRange);
archive.data = archive.data;


What this snippet should do?

Which one would usually expect from an OO API. The problem here 
is that the archive is typed for the original input range but 
the returned range from "data" is of a different type.


Range-based algorithms don't assign ranges. Transferring data 
from one range to another is done via copy(sourceRange, 
destRange) and similar tools.



... snip


It looks like difficulties come from your initial assumption that 
one call to serialize/deserialize implies one object - in that 
model ranges hardly are useful. I don't think it is a reasonable 
restriction. What is practically useful is (de)serialization of 
large list of objects lazily - and this is a natural job for 
ranges.

Re: A possible suggestion for the Foreach loop

[bearophile]

Dicebot:


They are orthogonal and not exclusive.

"declaration foreach" can appear whenever declaration can 
appear and insert new declarations, contrary to statements of 
normal foreach. "static foreach" is simply an improvement over 
existing "tuple foreach concept" which allows it to work with a 
wider variety of input. Former is about context of  foreach 
itself, latter - about behavior of the loop.


They are the same thing, in Issue 4085 the step n.6 covers that.

Bye,
bearophile

Re: Add duration parsing to core.time?

[Brad Anderson]

On Wednesday, 21 August 2013 at 06:46:49 UTC, Jonathan M Davis 
wrote:
In general, I'm very much opposed to functions which try and 
parse arbitrary
strings as they're incredibly error-prone and have to guess at 
what you mean.
In pretty much any case where the string was emitted by a 
computer in the first
place rather than a human, that's just plain sloppy, and 
ideally, a human
would be required to put a string in a standard format when 
inputting it (or
input the values separately rather than as a string) in order 
to avoid

intepretation errors.

- Jonathan M Davis


I agree completely and can speak from experience.  We used 
wxWidget's wxDateTime class for years at work and its 
ParseDateTime which allows free format strings. It was a source 
of never ending problems for us until we finally stopped using 
it.  The implementation was fine, it's just that dates are not 
amenable to unstructured reading. Date strings with locale 
information embedded in them may be doable but they are basically 
nonexistent.


Date strings are a lot like string encodings.  They are unsafe to 
use without knowing a definitive format/encoding.

Re: Thoughts on possible tuple semantics

[Dicebot]

On Wednesday, 21 August 2013 at 19:18:52 UTC, Andrei Alexandrescu 
wrote:

void foo(T...)(T args)
{
static assert(is(T == ctseq(int, string)));


There's going to be significant difficulty with this. This 
would be much easier:


  static assert(is(ctseq(T) == ctseq(int, string)));


It is not easier, it is returning to current issue I was trying 
to address - question "what is T and how it is related to 
existing type system".



Right now "T" as above has no type of its own


Then why it can be aliased?

If "T" is a type then "args" has a type and then we're back to 
asking ourselves whether writeln(args) passes one argument or 
more to writeln.


If we assume they auto-expansion is out, it is straightforward:
writeln(args) passes one argument, writeln(args.expand) - 
multiple.


I do agree that we could take a different route if we designed 
the type system today, but we aren't. Current design is a 
legacy/liability.


Then, as I have already said, we can hardly do anything better 
than renaming TypeTuple and abandoning any hope to remove 
confusion. Well, maybe one can add some syntax sugar to make it 
more powerful, but built-ins will remain same weirdos.


And this is a time to step down for a moment and ask "is 
cumulative cost of documentation efforts and learning issues 
during all D lifespan worse than one hard by finite deprecation 
process?".


Current design is so hacky that we can't really do anything about 
it without breakage.



static assert(is(typeof(args) == T));
assert(args == tuple(1, "2"));


So it seems the relationship between ctseq and tuple is that 
typeof(tuple(x, y. z)) is ctseq(typeof(x), typeof(y), 
typeof(z)). This leaves out of the discussion things like 
ctseq(1, "2") which contain compile-time values, not types. In 
that regard I'd prefer the two being entirely distinct.


They can't be distinct as both are accepted in one template 
argument list and this mandates that both must be able to be 
aliased. That makes them types. In my proposal ctseq(1, "2") also 
becomes a type, one that contains only meta-data and can't be 
instantiated.

Re: s/type tuple/template pack/g please

[captaindet]

On 2013-08-21 13:36, Meta wrote:

On Wednesday, 21 August 2013 at 18:26:42 UTC, Andrei Alexandrescu
wrote:

We much more need to get "type" out of the name. Those aren't
types.


I think this is part of the problem. Nobody can agree on what they
should be called because it's so hard to classify them. They're not
types, they're not values, they're this weird in-between thing that
can be either one, or the other, or both. Therefore anything
containing Type or Value in the name will not describe exactly what
this thing is. Neither will Symbol, nor Expression, as it can contain
both of those again, but not exclusively. We may as well call it by
some name that is completely unrelated to what it can contain, as it
can contain pretty much *everything*. How about KitchenSinkquence?


abstract tuples they are.

(we have to alias them to maintain their full function)

i don't mind them being called ...tuples, to me it looks and feels enough like 
a tuple to be called this way. (Type... is very confusing though).

concerning the other typecons.Tuple: i think of this being more an issue of 
insufficient/bad/confusing documentation.

/det

Re: s/type tuple/template pack/g please

[Brad Anderson]

On Wednesday, 21 August 2013 at 19:19:35 UTC, Andrei Alexandrescu 
wrote:

On 8/21/13 12:01 PM, Brad Anderson wrote:
On Wednesday, 21 August 2013 at 18:17:03 UTC, David Nadlinger 
wrote:

Personally, I like using "Seq" as the name for the constructor
template, as do a few other of the GitHub/NG regulars, so 
maybe
"(parameter/variadic/…) sequence" would be an alternative 
worth

discussing?


"Seq" is nice too because it has no baggage that comes with 
terms like
"type", "tuple", or "template".  It's its own thing which 
hasn't been
used to mean anything but what people are proposing (at least 
in the

context of D).

I think I actually like "Seq" better than "parameter/variadic 
sequence"
for this reason.  Neologism is a perfectly valid option (isn't 
that

right, trie?).


"Seq" has the problem that it's not an actual word or phrase 
and as such is difficult to talk about.


Andrei


Nobody seems to know how to say "trie" either but it's successful 
enough (look at this show of hands: 
http://www.youtube.com/watch?v=RlVpPstLPEc&feature=youtu.be&t=50m46s 
).  I would just pronounce it like abbreviated "sequence" so IPA: 
sikw.  Anyway, I think an neologism is something to consider even 
if it isn't Seq.

Re: A Discussion of Tuple Syntax

[bearophile]

Zach the Mystic:

I agree. The negative space *around* the bikeshed should be 
used...


Andrei missed the point of that part of the discussion. That was 
not an explanation of the usefulness of wildcards, it was a small 
explanations of why probably you can't use '_' as wildcard 
symbol. The examples I have shown were not meant to show why 
wildcards are very useful in a rounded tuple design.




auto (void, void, x) = t1;

(Just an idea I had. Don't know whether it's technically sound. 
It just seemed so funny to me that the idea popped into my head 
as soon as you said "rainbow". Not trying to waste time. )


That is perhaps technically acceptable, but it's longer.

Bye,
bearophile

Re: A Discussion of Tuple Syntax

[bearophile]

H. S. Teoh:

This is adequately taken care of by std.typecons.Tuple, isn't 
it?


You can't make 'i' a runtime value because D is a 
statically-typed language.


Yep. (From several persons explaining me similar things in 
answers to my posts it seems I am not expressing well that I know 
what I am discussing about. In future I will add notes to avoid 
this).




Currently you could do:

Tuple!(...) t1;
auto a = t1[0];
auto b = t1[1];

Not as nice, certainly, but I wouldn't consider it a 
deal-breaker.



Currently we have:

auto mult = (Tuple!(int,int) t) => t[0] * t[1];

Not as pretty, but surely still readable and usable? Or am I 
missing

something?


I didn't look in detail at your red-black tree example, or the 
Huffman
encoding example, but it would seem that currently, 
std.typecons.Tuple
more-or-less suffices for your needs, right? Except for some 
syntactic unpleasantness, that is.


Or is there something that *can't* be expressed in an adequate 
way by the current Tuple that I missed?


See what I wrote at the beginning of the post:


We can live fine without a syntax to manage tuples, so strictly
speaking we need nothing


The semantics of tuples is simple and everything you can do when 
them is very easy to do in a language like C. The point of having 
tuples is to write code that is more readable, shorter, more 
expressive, a bit higher level. std.typecons.Tuple misses some 
expressiveness that some programmers think is handy to have, that 
I have listed in my post.



What should happen if s is a runtime variable that may not have 
the same
number of words as the number of elements in the tuple on the 
left-hand

side? A runtime error?


Again, what should happen if at runtime the lines have more or 
less

elements than the tuple on the left-hand side? A runtime error?


The answer I wrote in another post:

Runtime boundary checks and tests are not needed if you unpack 
a fixed-sized array:


auto tup = Tuple!(int, string[2])(1, ["red", "blue"]);
auto {x, [c1, c2]} = tup;

Regarding the de-structuring of dynamic arrays, I think it's 
not too much different than this:


void main() {
int[] a = [10, 20, 30];
int[2] b = a;
}

If you compile and run it without switches, you get at run-time:

object.Error: lengths don't match for array copy, 2 = 3


While I receive no run-time errors if I compile with 
-noboundscheck.




Isn't this an auto-expanding tuple that Andrei didn't like?


I don't know. Ask to him.

Bye,
bearophile

Re: A possible suggestion for the Foreach loop

[Dicebot]

On Wednesday, 21 August 2013 at 13:18:22 UTC, bearophile wrote:

Dylan Knutson:

I'd like to open up discussion regarding allowing foreach 
loops which iterate over a tuple of types to exist outside of 
function bodies. I think this would allow for templating 
constants and unittests easier.


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

Bye,
bearophile


This bugzilla entry is on slightly related but different topic.

"declaration foreach" != "static foreach"

Re: A possible suggestion for the Foreach loop

[bearophile]

Dylan Knutson:

I'd like to open up discussion regarding allowing foreach loops 
which iterate over a tuple of types to exist outside of 
function bodies. I think this would allow for templating 
constants and unittests easier.


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

Bye,
bearophile

Re: Possible solution to template bloat problem?

[Dicebot]

Politeness will kill western civilization one day :)

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

[Dicebot]

On Wednesday, 21 August 2013 at 06:55:56 UTC, Jacob Carlborg 
wrote:
Yes, but now there have been quite a lot suggestions for how 
the range API should look like that I'm even more confused. 
I'll think a start a new thread for this.


Sure. I have already written my opinion on this but getting 
attention / opinion of some Phobos developers on this topic could 
have been valuable.

Re: A Discussion of Tuple Syntax

[Dicebot]

On Wednesday, 21 August 2013 at 03:39:32 UTC, Jonathan M Davis 
wrote:
But I see no reason to try and combine any of that with Tuple, 
as Tuple and

TypeTuple do fundamentally different things.


TypeTuple does not cover all built-in tuple cases. There is also 
built-in expression/run-time tuple which is also native to 
language but differs from library std.typecons.Tuple _only_ with 
lack of ABI.


You may underestimate the mess here.

Re: Why I chose D over Ada and Eiffel

[Joseph Rushton Wakeling]

On 20/08/13 23:43, H. S. Teoh wrote:

And now I know who to blame^W I mean, praise, for the names of .front
and .back:

http://forum.dlang.org/post/gaf59c$on7$1...@digitalmars.com

In any case, I'm impressed by the sheer volume of bikeshedding going on
in that thread! It almost puts to shame our rainbow-free discussions
these days. :-P


Fantastic to get this insight into D's history. :-)

Re: DQuick a GUI Library (prototype)

[Flamaros]

I may forget to tell that we want to be able to reload the GUI 
dynamically for the editor. It have to be possible to edit a 
property binding code without reloading the application.

Re: Why I chose D over Ada and Eiffel

[Joseph Rushton Wakeling]

On 20/08/13 22:43, Andrei Alexandrescu wrote:

It's a common omission to equate D's ranges with pipes/filters. That misses the
range categorization, which is inspired from C++ iterators.

A relatively accurate characterization of D ranges is a unification of C++
iterators with pipes/filters.


I'm not sure I quite follow this point.  The Clojure sequence API has all the 
stuff you'd expect from the range interface -- empty?, first (front), next 
(popFront), nnext (popFrontN), last (back), drop-last (popBack), ...


Is the point here that in Clojure these are all implemented as pipes/filters on 
top of singly-linked lists, whereas in D range interfaces are a "first-class" 
part of the language that is agnostic about the underlying data structures?

Re: A possible suggestion for the Foreach loop

[Dicebot]

While you example can be re-written in a similar fashion with no 
major issues, it would have been a very useful tool to solve the 
problem with recursive template instantiation to embed 
declarations.


Compare those two and count template instances:

---

mixin template head(T)
{
mixin(generateCode!T);
}

mixin template list(T...)
if (T.length >= 1)
{
mixin head!(T[0]);
static if (T.length > 1)
mixin list!(T1..$]);
}

struct Test
{
mixin list!(int, string, double);
}

---

struct Test
{
foreach (T; TypeTuple!(int, string, double))
{
mixin(generateCode!T));
}
}

---

I remember Andrei reacting quite positively to this proposal when 
talking on #d channel.

Re: DQuick a GUI Library (prototype)

[Flamaros]

On Wednesday, 21 August 2013 at 11:44:19 UTC, Jacob Carlborg 
wrote:

On 2013-08-21 12:30, Andrej Mitrovic wrote:

I still don't understand what DQuick has to do with D if you 
end up
having to use a separate scripting language to use it. 
Wouldn't it
then be more appropriate to post about DQuick in the Lua 
newsgroups?


I assume:

A. It's written in D
B. You can write GUI code in D as well. This syntax is just 
something that should be easier, possibly something that a GUI 
builder can generate and parse


D syntax isn't an issue. We want do a GUI editor that can 
generate and parse GUI files.


We need take a deeper look to your proposition.

Re: DQuick a GUI Library (prototype)

[Flamaros]

On Wednesday, 21 August 2013 at 11:28:23 UTC, dennis luehring 
wrote:

Am 21.08.2013 13:18, schrieb Flamaros:

On Wednesday, 21 August 2013 at 10:30:59 UTC, Andrej Mitrovic
wrote:

On 8/21/13, dennis luehring  wrote:

why use scripting at all - D is blasting fast compiled - so
whats the
benefit of using "another" language - i understand the need
for C++
based systems but in D...


I still don't understand what DQuick has to do with D if you
end up
having to use a separate scripting language to use it. 
Wouldn't

it
then be more appropriate to post about DQuick in the Lua
newsgroups?


DQuick is for D applications, scripts are just for interfaces.


and why not use D as the scripting language as the remedygames 
guys do?

or just using Lua because its already running?



The remedy solution isn't portable and/or to hard to put in place 
for a prototype.

Yes Lua is a easier to use for us.

Re: A possible suggestion for the Foreach loop

[monarch_dodra]

On Wednesday, 21 August 2013 at 11:34:29 UTC, Kiith-Sa wrote:
On Wednesday, 21 August 2013 at 10:40:10 UTC, monarch_dodra 
wrote:
On Wednesday, 21 August 2013 at 02:46:06 UTC, Dylan Knutson 
wrote:

Hello,

I'd like to open up discussion regarding allowing foreach 
loops which iterate over a tuple of types to exist outside of 
function bodies. I think this would allow for templating 
constants and unittests easier. Take, for instance, this 
hypothetical example:


--
T foo(T)(ref T thing)
{
thing++; return thing * 2;
}

foreach(Type; TupleType!(int, long, uint))
{
unittest
{
Type tmp = 5;
assert(foo(tmp) == 12);
}

unittest
{
Type tmp = 0;
foo(tmp);
assert(tmp == 1);
}
}
--

Without the ability to wrap all of the unittests in a 
template, one would have to wrap the bodies of each unittest 
in an individual foreach loop. This is not only repetitive 
and tedious, but error prone, as changing the types tested 
then requires the programmer to change *every* instance of 
the foreach(Type; TupleType).


A similar pattern already exists in Phobos, for testing all 
variants of strings (string, dstring, and wstring) and char 
types, as eco brought to my attention. After taking a look at 
some of the unittests that employ this pattern, I'm certain 
that code clarity and unittest quality could be improved by 
simply wrapping all of the individual unittests themselves in 
a foreach as described above.


Now, I'm certainly no D expert, but I can't think of any 
breakages this change might impose on the language itself. 
So, I'd like to hear what the benevolent overlords and 
community think of the idea.


This makes sense to me. After all, a static foreach no 
different in its result from a static if. Here is an example 
usecase:


//
foreach(T)(TypeTuple!(float, double, real))
{
   void someFunction(T val)
   {some_body;}
}
//

This, contrary to making someFunction a template, eagerly 
compiles someFunction. This makes it "ship-able" in a library.


Also, it avoid "over instantiations": More often than not, for 
example, a template will be instantiated with "double", but 
also "const double" and "immutable double".


It also avoids having to over-think the template restraints.

This is just one example, but I can *definitly* see it making 
sense in over ways.




Also, I find it strange that the above is not legal, but that 
this works:


//
import std.stdio, std.typecons;

alias cases = TypeTuple!(2, 3, 4, 7, 8);

void main()
{
   int i = 7;
   switch(i)
   {
   //cases defined
   foreach (v; cases)
   {
   case v:
   }
   {
   writeln("match");
   }
   break;

   default:
   writeln("no match");
   }
}
//



In a previous project I needed exactly this (I needed to 
declare various class data members based on a large tuple of 
types.) I ended up having to use string mixins, which was 
pretty unreadable. So I think it is a good idea, although I 
have no idea how viable/nonintrusive is it to add this to the 
language.


I wish I could tell you a template mixin would have done the job, 
but these tend to have trouble once overloads come into play.


//
mixin template someFunctionDeclare(T)
{
void someFunction(T val)
{}
}
mixin someFunctionDeclare!float;
mixin someFunctionDeclare!double;
mixin someFunctionDeclare!real;

void main()
{
someFunction(5.5);
}
//
main.someFunctionDeclare!double.someFunction at hello.d(7) 
conflicts with main.someFunctionDeclare!real.someFunction at 
hello.d(7)
main.someFunctionDeclare!double.someFunction at hello.d(7) 
conflicts with main.someFunctionDeclare!float.someFunction at 
hello.d(7)

//

That said, now that we have parameterizable enums, and with 
compile time format and token strings, the syntax to do things 
with string mixins isn't *that* horrible:


enum someFunctionDeclare(T) =
format(q{

void someFunction(%1$s val)
{
writeln(val);
}

}, T.stringof);

mixin(someFunctionDeclare!float);
mixin(someFunctionDeclare!double);
mixin(someFunctionDeclare!real);

void main()
{
someFunction(5.5);
}

Re: A possible suggestion for the Foreach loop

[John Colvin]

On Wednesday, 21 August 2013 at 02:46:06 UTC, Dylan Knutson wrote:

Hello,

I'd like to open up discussion regarding allowing foreach loops 
which iterate over a tuple of types to exist outside of 
function bodies.


I would *LOVE* to have this.

however, once we go down that route, it would be very tempting to 
allow a whole lot of other compile-time imperative style 
programming. Which would be awesome.


I don't know how the compiler works with templates, but if it 
could be made to move linearly through them then we could 
potentially do this:


template allSatisfy(alias F, T...)
{
foreach(t; T)
{
static if(!F!t)
{
static return false;
//alternatively:
//  enum allSatify = False;
//  static return;
}
}
static return true;
}

which could be extended to allow static break, static continue 
etc. This does rather make the argument for allowing "static 
foreach" as valid, but not required syntax.


Or... even allow enum and alias values to be manipulated at CT:

template staticMap(alias F, T...)
{
static if(T.length == 0)
{
alias staticMap = TypeTuple!();
static return;
}
alias map = F!(T[0]);
foreach(t; T)
{
map = TypeTuple!(map, F!t);
}
alias staticMap = map;
static return;
}

I'm favouring the 2-step eponymous thing in order to prevent any 
alias/enum ambiguities. Another alternative would be

static return alias blah;
static return enum blah;


Apologies for the bike-shedding, but if some thing like this 
worked properly, it would be a complete game-changer.
We'd be light-years ahead of anyone else’s compile-time 
reflection.

Re: DQuick a GUI Library (prototype)

[Jacob Carlborg]

On 2013-08-21 13:42, Jacob Carlborg wrote:


This is a complete example:

http://pastebin.com/2C4Z2wFR


I'm using the Orange library to perform the actual serialization:

https://github.com/jacob-carlborg/orange

--
/Jacob Carlborg

Re: DQuick a GUI Library (prototype)

[Jacob Carlborg]

On 2013-08-21 12:30, Andrej Mitrovic wrote:


I still don't understand what DQuick has to do with D if you end up
having to use a separate scripting language to use it. Wouldn't it
then be more appropriate to post about DQuick in the Lua newsgroups?


I assume:

A. It's written in D
B. You can write GUI code in D as well. This syntax is just something 
that should be easier, possibly something that a GUI builder can 
generate and parse


--
/Jacob Carlborg

Re: DQuick a GUI Library (prototype)

[Jacob Carlborg]

On 2013-08-21 11:50, Flamaros wrote:


I am not sure to understand correctly your suggestion, I don't see how
the application will be able to create GUI items from "foo.d". Need
"foo.d" embed a code to serialize the GUI items structure to a file that
the application will load?


This is a complete example:

http://pastebin.com/2C4Z2wFR

Which will print this:

http://pastebin.com/Tj1vVHsF

If we look at the code above, evertyrthing below the "main" function 
would be in a separate module, "dquick.dls" for example. The string 
"code" contains the D script, corresponding to the Lua code. That would 
be in its own file, imported using:


import("filename.d");

The tool currently executing the Lua code would instead generate a new 
file with the "main" and "executeScript" functions as above. Then it 
will proceed as I described in my previous post.


--
/Jacob Carlborg

Re: A possible suggestion for the Foreach loop

[Kiith-Sa]

On Wednesday, 21 August 2013 at 10:40:10 UTC, monarch_dodra wrote:
On Wednesday, 21 August 2013 at 02:46:06 UTC, Dylan Knutson 
wrote:

Hello,

I'd like to open up discussion regarding allowing foreach 
loops which iterate over a tuple of types to exist outside of 
function bodies. I think this would allow for templating 
constants and unittests easier. Take, for instance, this 
hypothetical example:


--
T foo(T)(ref T thing)
{
thing++; return thing * 2;
}

foreach(Type; TupleType!(int, long, uint))
{
unittest
{
Type tmp = 5;
assert(foo(tmp) == 12);
}

unittest
{
Type tmp = 0;
foo(tmp);
assert(tmp == 1);
}
}
--

Without the ability to wrap all of the unittests in a 
template, one would have to wrap the bodies of each unittest 
in an individual foreach loop. This is not only repetitive and 
tedious, but error prone, as changing the types tested then 
requires the programmer to change *every* instance of the 
foreach(Type; TupleType).


A similar pattern already exists in Phobos, for testing all 
variants of strings (string, dstring, and wstring) and char 
types, as eco brought to my attention. After taking a look at 
some of the unittests that employ this pattern, I'm certain 
that code clarity and unittest quality could be improved by 
simply wrapping all of the individual unittests themselves in 
a foreach as described above.


Now, I'm certainly no D expert, but I can't think of any 
breakages this change might impose on the language itself. So, 
I'd like to hear what the benevolent overlords and community 
think of the idea.


This makes sense to me. After all, a static foreach no 
different in its result from a static if. Here is an example 
usecase:


//
foreach(T)(TypeTuple!(float, double, real))
{
void someFunction(T val)
{some_body;}
}
//

This, contrary to making someFunction a template, eagerly 
compiles someFunction. This makes it "ship-able" in a library.


Also, it avoid "over instantiations": More often than not, for 
example, a template will be instantiated with "double", but 
also "const double" and "immutable double".


It also avoids having to over-think the template restraints.

This is just one example, but I can *definitly* see it making 
sense in over ways.




Also, I find it strange that the above is not legal, but that 
this works:


//
import std.stdio, std.typecons;

alias cases = TypeTuple!(2, 3, 4, 7, 8);

void main()
{
int i = 7;
switch(i)
{
//cases defined
foreach (v; cases)
{
case v:
}
{
writeln("match");
}
break;

default:
writeln("no match");
}
}
//



In a previous project I needed exactly this (I needed to declare 
various class data members based on a large tuple of types.) I 
ended up having to use string mixins, which was pretty 
unreadable. So I think it is a good idea, although I have no idea 
how viable/nonintrusive is it to add this to the language.

Re: DQuick a GUI Library (prototype)

[dennis luehring]

Am 21.08.2013 13:18, schrieb Flamaros:

On Wednesday, 21 August 2013 at 10:30:59 UTC, Andrej Mitrovic
wrote:

On 8/21/13, dennis luehring  wrote:

why use scripting at all - D is blasting fast compiled - so
whats the
benefit of using "another" language - i understand the need
for C++
based systems but in D...


I still don't understand what DQuick has to do with D if you
end up
having to use a separate scripting language to use it. Wouldn't
it
then be more appropriate to post about DQuick in the Lua
newsgroups?


DQuick is for D applications, scripts are just for interfaces.


and why not use D as the scripting language as the remedygames guys do?
or just using Lua because its already running?


Interfaces have to be separate from the application to be edited
by artists or other non developer persons.


but trivial D code looks like trivial Lua code


Here is a link to our model (QtQuick samples) :
http://www.youtube.com/watch?v=8G4U7QWRajg

The main advantage of D is the traits that simplify the binding
of D objects to the script language. Qt use moc to do this and
it's really intrusive, because it extend the c++ syntax. Our
solution is directly based on primitive types of D. Instead of
QtQuick if DQuick isn't ported to a platform, it will easier to
use the native GUI library for this particular platform. With Qt
wrappers have to be create to convert types (QList =>
std::list,...)


thats nice

Re: DQuick a GUI Library (prototype)

[Flamaros]

On Wednesday, 21 August 2013 at 10:30:59 UTC, Andrej Mitrovic 
wrote:

On 8/21/13, dennis luehring  wrote:
why use scripting at all - D is blasting fast compiled - so 
whats the
benefit of using "another" language - i understand the need 
for C++

based systems but in D...


I still don't understand what DQuick has to do with D if you 
end up
having to use a separate scripting language to use it. Wouldn't 
it
then be more appropriate to post about DQuick in the Lua 
newsgroups?


DQuick is for D applications, scripts are just for interfaces.

Interfaces have to be separate from the application to be edited 
by artists or other non developer persons.


Here is a link to our model (QtQuick samples) :
http://www.youtube.com/watch?v=8G4U7QWRajg

The main advantage of D is the traits that simplify the binding 
of D objects to the script language. Qt use moc to do this and 
it's really intrusive, because it extend the c++ syntax. Our 
solution is directly based on primitive types of D. Instead of 
QtQuick if DQuick isn't ported to a platform, it will easier to 
use the native GUI library for this particular platform. With Qt 
wrappers have to be create to convert types (QList => 
std::list,...)

question regarding math.d and magic numbers

[dennis luehring]

i see many many const values for bitmasking in math.d - wouldn't it be 
better to reduce this magic values down to float traits (and start using 
them)?

Re: Why I chose D over Ada and Eiffel

[Andrej Mitrovic]

On 8/21/13, Jesse Phillips  wrote:
> I don't frown on copy-paste code because "it's the thing to do"
> or because it causes more typing. copy-paste is bad because your
> logic is now duplicated and requires twice (on a good day) the
> updates.

Speaking of which someone should try and make a D de-duplication
project (perhaps using Dscanner[1]), which would print out all the
duplicated code segments in a D codebase. I think it would be a neat
thing to have.

[1] : https://github.com/Hackerpilot/Dscanner

Re: A possible suggestion for the Foreach loop

[monarch_dodra]

On Wednesday, 21 August 2013 at 02:46:06 UTC, Dylan Knutson wrote:

Hello,

I'd like to open up discussion regarding allowing foreach loops 
which iterate over a tuple of types to exist outside of 
function bodies. I think this would allow for templating 
constants and unittests easier. Take, for instance, this 
hypothetical example:


--
T foo(T)(ref T thing)
{
thing++; return thing * 2;
}

foreach(Type; TupleType!(int, long, uint))
{
unittest
{
Type tmp = 5;
assert(foo(tmp) == 12);
}

unittest
{
Type tmp = 0;
foo(tmp);
assert(tmp == 1);
}
}
--

Without the ability to wrap all of the unittests in a template, 
one would have to wrap the bodies of each unittest in an 
individual foreach loop. This is not only repetitive and 
tedious, but error prone, as changing the types tested then 
requires the programmer to change *every* instance of the 
foreach(Type; TupleType).


A similar pattern already exists in Phobos, for testing all 
variants of strings (string, dstring, and wstring) and char 
types, as eco brought to my attention. After taking a look at 
some of the unittests that employ this pattern, I'm certain 
that code clarity and unittest quality could be improved by 
simply wrapping all of the individual unittests themselves in a 
foreach as described above.


Now, I'm certainly no D expert, but I can't think of any 
breakages this change might impose on the language itself. So, 
I'd like to hear what the benevolent overlords and community 
think of the idea.


This makes sense to me. After all, a static foreach no different 
in its result from a static if. Here is an example usecase:


//
foreach(T)(TypeTuple!(float, double, real))
{
void someFunction(T val)
{some_body;}
}
//

This, contrary to making someFunction a template, eagerly 
compiles someFunction. This makes it "ship-able" in a library.


Also, it avoid "over instantiations": More often than not, for 
example, a template will be instantiated with "double", but also 
"const double" and "immutable double".


It also avoids having to over-think the template restraints.

This is just one example, but I can *definitly* see it making 
sense in over ways.




Also, I find it strange that the above is not legal, but that 
this works:


//
import std.stdio, std.typecons;

alias cases = TypeTuple!(2, 3, 4, 7, 8);

void main()
{
int i = 7;
switch(i)
{
//cases defined
foreach (v; cases)
{
case v:
}
{
writeln("match");
}
break;

default:
writeln("no match");
}
}
//

Re: Fixing "toStringz"

[Andrej Mitrovic]

On 8/21/13, monarch_dodra  wrote:
> I'm looking for ideas though on being able to detect
> if a string *is* a manifest constant string?

I've proposed once to allow declaring an enum parameter, e.g.:

void foo(enum string input) { }

This would only allow foo to be called with a manifest constant (e.g.
a string literal). This way you could overload functions and perform
optimizations in some overloads.

Note that we already have a special way to e.g. mark a function to
only take a null literal, by making the parameter "typeof(null)". But
using typeof("") wouldn't quite work here, so if there's a language
enhancement to be made I'm in favor of the enum approach.

Btw this thread has already popped up before, e.g.:
http://forum.dlang.org/thread/j0ie3e$18mh$1...@digitalmars.com where I
showed the problem of toStringz:

-
import std.string;
import std.stdio;

struct A
{
immutable char[2] foo;
char[2] bar;
}

void main()
{
auto a = A("aa", "\0b");   // embed \0 in the second field

// toStringz picks up \0 from the 'bar' field, does not allocate
auto charptr = toStringz(a.foo[]);

a.bar = "bo";  // remove embedded \0 from second field
printf(charptr);  // prints two chars and then garbage
}
-

Couldn't this also have security issues? I think we definitely have to
fix toStringz, the look-ahead for \0 is an over-reaching optimization,
and at best it should be selectable behavior in the same way as we
have assumeUnique for arrays.

Re: DQuick a GUI Library (prototype)

[Andrej Mitrovic]

On 8/21/13, dennis luehring  wrote:
> why use scripting at all - D is blasting fast compiled - so whats the
> benefit of using "another" language - i understand the need for C++
> based systems but in D...

I still don't understand what DQuick has to do with D if you end up
having to use a separate scripting language to use it. Wouldn't it
then be more appropriate to post about DQuick in the Lua newsgroups?

Re: A possible suggestion for the Foreach loop

[Tommi]

On Wednesday, 21 August 2013 at 02:46:06 UTC, Dylan Knutson wrote:

[..]
--
T foo(T)(ref T thing)
{
thing++; return thing * 2;
}

foreach(Type; TupleType!(int, long, uint))
{
unittest
{
Type tmp = 5;
assert(foo(tmp) == 12);
}

unittest
{
Type tmp = 0;
foo(tmp);
assert(tmp == 1);
}
}
--
[..]


Why not just do this:

import std.typetuple;

T foo(T)(ref T thing)
{
thing++; return thing * 2;
}

unittest
{
foreach(Type; TypeTuple!(int, long, uint))
{
{
Type tmp = 5;
assert(foo(tmp) == 12);
}

{
Type tmp = 0;
foo(tmp);
assert(tmp == 1);
}
}
}

Re: DQuick a GUI Library (prototype)

[dennis luehring]

Am 21.08.2013 11:10, schrieb Flamaros:

Markup languages can't be used in our case, we need to provide
scripting capabilities.
It's a prototype essentially cause of Lua, that why we think to
add a front-end to simplify the Lua syntax like removing
"function() ... end" for property binding.

For the moment we can't use D as script language for our project,
just because there is no API to parse and execute a d file as
script.


why use scripting at all - D is blasting fast compiled - so whats the 
benefit of using "another" language - i understand the need for C++ 
based systems but in D...


best sample of using D for scripting is Manu Evans (from 
http://remedygames.com/) Talk at DConf


http://dconf.org/talks/evans_1.pdf
http://www.youtube.com/watch?v=FKceA691Wcg

Re: DQuick a GUI Library (prototype)

[Flamaros]

On Wednesday, 21 August 2013 at 09:23:27 UTC, Jacob Carlborg 
wrote:

On 2013-08-21 11:10, Flamaros wrote:

For the moment we can't use D as script language for our 
project, just
because there is no API to parse and execute a d file as 
script.


You can do something like this:

import dquick.dsl;
import std.stdio;

void executeSciprt ()
{
mixin(import("foo.d"));
}

void main ()
{
initialize();
executeSciprt();
writeln(DQuickDsl.serialize());
}

When you want to "execute" the D script you use the above as a 
template and only need to replace the file name, in this case 
"foo.d", and create a file. Compile that file run the resulting 
executable, this is easily done using rdmd. Retrieve the 
serialized data, deserialized it and do want you need with the 
data structures.


Maybe something can be done with a load of a compiled dll 
resulting of the compilation of script files. But it doesn't 
seems to be a really good way.


I am not sure to understand correctly your suggestion, I don't 
see how the application will be able to create GUI items from 
"foo.d". Need "foo.d" embed a code to serialize the GUI items 
structure to a file that the application will load?

Re: DQuick a GUI Library (prototype)

[Chris]

On Wednesday, 21 August 2013 at 08:04:23 UTC, Jacob Carlborg 
wrote:

On 2013-08-20 23:22, Flamaros wrote:
I want to share a short presentation of the project I am 
working on with

friends. It's a prototype of a GUI library written in D.

This pdf contains our vision of what the project would be. 
Samples are
directly extracted from our prototype and works. We are not 
able to
share more than this presentation for the moment because a lot 
of things

are missing and it's plenty of bugs.

The development is really slow, so don't expect to see a real
demonstration a day.

The link :
https://docs.google.com/file/d/0BygGiQfhIcvGOGlrWlBFNWNBQ3M/edit?usp=sharing


I don't think Lua will work in this community. I've tried with 
Ruby and people didn't like it. Although it might be different 
with Lua. My experience is you have two choices: a markup 
language, i.e. JSON, YAML and so on or using D.


Great stuff! I am definitely in favor of a pure D GUI. And again, 
D has the benefit of hindsight.


Lua might work, because it's cross platform in the sense that you 
can deliver a stand alone interpreter, and it's fast. However, I 
wonder why this should be necessary. A pure D solution might be 
better.

Re: DQuick a GUI Library (prototype)

[Jacob Carlborg]

On 2013-08-21 11:10, Flamaros wrote:


For the moment we can't use D as script language for our project, just
because there is no API to parse and execute a d file as script.


You can do something like this:

import dquick.dsl;
import std.stdio;

void executeSciprt ()
{
mixin(import("foo.d"));
}

void main ()
{
initialize();
executeSciprt();
writeln(DQuickDsl.serialize());
}

When you want to "execute" the D script you use the above as a template 
and only need to replace the file name, in this case "foo.d", and create 
a file. Compile that file run the resulting executable, this is easily 
done using rdmd. Retrieve the serialized data, deserialized it and do 
want you need with the data structures.


--
/Jacob Carlborg

Re: DQuick a GUI Library (prototype)

[Flamaros]

On Wednesday, 21 August 2013 at 08:04:23 UTC, Jacob Carlborg 
wrote:

On 2013-08-20 23:22, Flamaros wrote:
I want to share a short presentation of the project I am 
working on with

friends. It's a prototype of a GUI library written in D.

This pdf contains our vision of what the project would be. 
Samples are
directly extracted from our prototype and works. We are not 
able to
share more than this presentation for the moment because a lot 
of things

are missing and it's plenty of bugs.

The development is really slow, so don't expect to see a real
demonstration a day.

The link :
https://docs.google.com/file/d/0BygGiQfhIcvGOGlrWlBFNWNBQ3M/edit?usp=sharing


I don't think Lua will work in this community. I've tried with 
Ruby and people didn't like it. Although it might be different 
with Lua. My experience is you have two choices: a markup 
language, i.e. JSON, YAML and so on or using D.


Markup languages can't be used in our case, we need to provide 
scripting capabilities.
It's a prototype essentially cause of Lua, that why we think to 
add a front-end to simplify the Lua syntax like removing 
"function() ... end" for property binding.


For the moment we can't use D as script language for our project, 
just because there is no API to parse and execute a d file as 
script.

Re: DQuick a GUI Library (prototype)

[Jacob Carlborg]

On 2013-08-20 23:22, Flamaros wrote:

I want to share a short presentation of the project I am working on with
friends. It's a prototype of a GUI library written in D.

This pdf contains our vision of what the project would be. Samples are
directly extracted from our prototype and works. We are not able to
share more than this presentation for the moment because a lot of things
are missing and it's plenty of bugs.

The development is really slow, so don't expect to see a real
demonstration a day.

The link :
https://docs.google.com/file/d/0BygGiQfhIcvGOGlrWlBFNWNBQ3M/edit?usp=sharing


I don't think Lua will work in this community. I've tried with Ruby and 
people didn't like it. Although it might be different with Lua. My 
experience is you have two choices: a markup language, i.e. JSON, YAML 
and so on or using D.


--
/Jacob Carlborg

Re: A Discussion of Tuple Syntax

[Zach the Mystic]

On Monday, 19 August 2013 at 20:46:02 UTC, Andrei Alexandrescu 
wrote:

void main() {
auto t1 = #(5, "hello", 1.5);
auto (?,  ?, x) = t1;
auto (?, gr, ?) = t1;
}

Bye,
bearophile


It's stuff like this that's just useless and gives a bad 
direction to the whole discussion. There's hardly anything 
wrong with auto x = t1[2] or auto gr = t1[1], but once the 
bikeshed is up for painting, the rainbow won't suffice.



Andrei


I agree. The negative space *around* the bikeshed should be 
used...


auto (void, void, x) = t1;

(Just an idea I had. Don't know whether it's technically sound. 
It just seemed so funny to me that the idea popped into my head 
as soon as you said "rainbow". Not trying to waste time. )

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

[ilya-stromberg]

On Wednesday, 21 August 2013 at 06:55:56 UTC, Jacob Carlborg 
wrote:

On 2013-08-21 02:09, Dicebot wrote:
P.S. Right now most important (and probably only really 
important) thing
is range API. I think it is worth focusing on it and getting 
through the
voting stage - actual merge can happen at any time you / 
Phobos devs are
satisfied with implementation state, it does not require major 
community

attention.


Yes, but now there have been quite a lot suggestions for how 
the range API should look like that I'm even more confused. 
I'll think a start a new thread for this.


Try to read the article:
http://wiki.dlang.org/Component_programming_with_ranges
It has got a lot of range examples, including std.range, 
std.algorithm and creation of new ranges.

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

[Jacob Carlborg]

On 2013-08-21 02:09, Dicebot wrote:

P.S. Right now most important (and probably only really important) thing
is range API. I think it is worth focusing on it and getting through the
voting stage - actual merge can happen at any time you / Phobos devs are
satisfied with implementation state, it does not require major community
attention.


Yes, but now there have been quite a lot suggestions for how the range 
API should look like that I'm even more confused. I'll think a start a 
new thread for this.


--
/Jacob Carlborg