Re: [Somewhat OT] Textadept 6.6 released

2013-08-22 Thread Michael

On Sunday, 2 June 2013 at 08:06:52 UTC, Michael wrote:

Looks good. Definitely will try.


up

Text Adept 7.0 beta 2 (11 Aug 2013) available ;)



Re: OT; Will MS kill .NET ?

2013-08-22 Thread 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

2013-08-22 Thread 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

2013-08-22 Thread 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: Why I chose D over Ada and Eiffel

2013-08-22 Thread 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: Range interface for std.serialization

2013-08-22 Thread Jacob Carlborg

On 2013-08-21 22:21, Dicebot wrote:


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


How should nesting been handled for a format like XML? Example:

class Bar
{
int a;
}

class Foo
{
int b;
Bar bar;
}

Currently the following XML is procured when serializing Foo:

object runtimeType=main.Foo type=main.Foo key=0 id=0
int key=b id=14/int
object runtimeType=main.Bar type=main.Bar key=bar id=2
int key=a id=33/int
/object
/object

If I shouldn't return the whole object, Foo, how can we know that when 
the string for Bar is returned it should actually be nested inside Foo?



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


Ok.


What this snippet should do?


That was just a dummy snippet to set the data. This is a slightly better 
example:


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

writeToFile(foo.xml, archive.data);

Now I want to deserialize the data back:

archive.data = readFromFile(foo.xml); // Error, cannot covert 
ReadFromFileRange to string



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


So how should the API look like for setting the data used when 
deserializing, like this?


auto data = readFromFile(foo.xml);
auto archive = new XmlArchive!(string);
copy(data, archive.data);


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.


It depends on how you look at it. Currently it's only possible to 
serialize a single object with a single call to serialize. So if you 
want to serialize multiple objects you do as you would do normally in 
your code, use an array, a linked list or similar. An array is still a 
single object, though it contains multiple objects, that is handled 
perfectly fine.


The question is if a range should be treated as multiple objects, and 
not a single object (which it really is). How should it be serialized?


* Something like an array, resulting in this XML:

array type=int length=5 key=0 id=0
int key=0 id=11/int
int key=1 id=22/int
int key=2 id=33/int
int key=3 id=44/int
int key=4 id=55/int
/array

* Or like calling serialize multiple times, resulting in this XML:

int key=0 id=01/int
int key=1 id=12/int
int key=2 id=23/int
int key=3 id=34/int
int key=4 id=45/int

* Or as a single object:

Then it would actually serialize the struct/class representing the range.

And the most important question, how should ranges be deserialized? One 
have to tell the serializer what type to return, otherwise it won't 
work. But the whole point of ranges is that you shouldn't need to know 
the type. Sometimes you cannot even name the type, i.e. Voldemort types.


--
/Jacob Carlborg


Re: Range interface for std.serialization

2013-08-22 Thread Jacob Carlborg

On 2013-08-22 05:13, Tyler Jameson Little wrote:


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


It need to store all serialized reference types, otherwise it cannot 
properly serialize a complete object graph. We don't want duplicates. 
Example:


The following code:

auto bar = new Bar;
bar.a = 3;

auto foo = new Foo;
foo.a = bar;
foo.b = bar;

Is serialized as:

object runtimeType=main.Foo type=main.Foo key=0 id=0
object runtimeType=main.Bar type=main.Bar key=a id=1
int key=a id=23/int
/object
reference key=b1/reference
/object

When foo.b is just serializes a reference, not the complete object, 
because that has already been serialized. The serializer needs to keep 
track of that.



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...


It seems hard to keep track of nesting. I can't see how pretty printing 
using this technique would work.



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


How should I set the data used for deserializing?


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


Again, how does one keep track of nesting in formats like XML, JSON and 
YAML?


--
/Jacob Carlborg


Re: Benchmarking a SIMD implementation of dot product

2013-08-22 Thread Jacob Carlborg

On 2013-08-22 02:24, Manu wrote:

Me...


I guess it's time you start :)

--
/Jacob Carlborg


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

2013-08-22 Thread Jacob Carlborg

On 2013-08-21 21:48, captaindet wrote:


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.


We could call the built-in ones for tuple and typecons.Tuple for 
anonymous structs.


--
/Jacob Carlborg


Re: DQuick a GUI Library (prototype)

2013-08-22 Thread Jacob Carlborg

On 2013-08-22 01:35, Sebastian Graf wrote:


+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


CoffeeScript is nice too. But I don't see a reason to use something 
other than a markup language if only a GUI builder should read and write 
those files.


--
/Jacob Carlborg


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

2013-08-22 Thread Jonathan M Davis
On Thursday, August 22, 2013 09:21:05 Jacob Carlborg wrote:
 On 2013-08-21 21:48, captaindet wrote:
  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.
 
 We could call the built-in ones for tuple and typecons.Tuple for
 anonymous structs.

Considering that std.typecons.Tuple actually acts like a full-on tuple (it 
actually nests) and the built-in tuple doesn't, that would be an odd choice 
IMHO.

- Jonathan M Davis


Re: Download page needs a tidy up

2013-08-22 Thread Jacob Carlborg

On 2013-08-22 05:07, Manu wrote:


Where are they?

Turns out there are links to the GDC binaries (hosted on bitbucket) on
dlang.org/download http://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.org http://dlang.org is just DMD related, and I quickly
dismissed it previously _


I had no idea there were GDC binaries on http://dlang.org/download.html


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


I don't know if they were recently added but they are below the GDC 
binaries.



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 http://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 agree. At the top, of the download page there should be three buttons, 
one for each compiler. Then JavaScript should be used to figure out the 
platform. Of course we need a fallback for when JavaScript is disabled 
or one wants to download for a different platform.


--
/Jacob Carlborg


Re: Download page needs a tidy up

2013-08-22 Thread Jacob Carlborg

On 2013-08-22 06:28, Tyler Jameson Little wrote:


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.


Or just using the user agent, since it has to work on all major browsers.

--
/Jacob Carlborg


Re: Download page needs a tidy up

2013-08-22 Thread Jacob Carlborg

On 2013-08-22 05:33, Manu wrote:


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.


The architecture are basically never mentioned for Mac OS X downloads. 
Because everyone assumes universal binaries that will work everywhere.


--
/Jacob Carlborg


Re: Download page needs a tidy up

2013-08-22 Thread Jacob Carlborg

On 2013-08-22 05:37, Tyler Jameson Little wrote:


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...


I don't think there have ever been any self contained packages for Posix 
with binaries for GDC.


--
/Jacob Carlborg


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

2013-08-22 Thread Jacob Carlborg

On 2013-08-22 09:29, Jonathan M Davis wrote:


Considering that std.typecons.Tuple actually acts like a full-on tuple (it
actually nests) and the built-in tuple doesn't, that would be an odd choice
IMHO.


I don't know the exact definition of tuple but what have nesting to do 
with it?


You can add names to the values using std.typecons.Tuple

alias Tuple!(int, index, string, value) Entry;
Entry e;
e.index = 4;
e.value = Hello;
assert(e[1] == Hello);
assert(e[0] == 4);

The above is basically exactly like an anonymous struct.

--
/Jacob Carlborg


Re: Why I chose D over Ada and Eiffel

2013-08-22 Thread qznc

On Wednesday, 21 August 2013 at 16:21:47 UTC, Ramon wrote:

As for generics, let me put it this way:
In Eiffel generics have been an integral part of the language 
design from the beginning. In D ways and mechanisms are 
provided to achieve what quite usually is the goal of generics, 
namely generic algorithms in way, i.e. by having to write code 
for an algorithm just once. That might seem to be a minor 
difference, in particular when looking from a Huh? I can get 
it done, so what's the fuss all about, eh? perspective.
Of course, there the C and successors worlds proponents are 
right, this incurs a price (which templates do, too ...) and, 
yes, in the end, somewhere someone or something must sort the 
types out anyway (because of the way CPUs work).


There are basically two ways to implement generics. Type erasure 
(Java,Haskell) or template instantiation (C++,D). Instantiation 
provides better performance, but sacrifices error messages 
(fixable?), binary code size, and compilation modularity 
(template implementation must be available for instantiation). 
Type safety is not a problem in either approach.


Longer form: http://beza1e1.tuxen.de/articles/generics.html

An interesting twist would be to use type erasure for reference 
types and instantiation for value types. Another idea could be to 
use instantiation selectively as an optimization and erasure in 
general.


Another example is data types, concretely integers. Ada offers 
a nice way do precisely nail down precision/storage. If I want 
to store days_of_month I can have an integer type holding ints 
between 1 and 31 (which, due to the way they implemented it can 
be a PITA). Eiffel gives me something quite similar (in a more 
elegant way) and additionally a dumb INTEGER (32 or 64 bit) 
and than a gazillion subtypes like INTEGER_16. That's great 
because in a quick and dirty script a plain integer (max size 
of CPU) is good enough and keeps life simple. If I need 
days_of_month I can very easily have that as int type.


In D you can use structs:

  struct days_of_month {
int day;
/* fill in operator overloading etc */
  }


Re: Why I chose D over Ada and Eiffel

2013-08-22 Thread PauloPinto

On Thursday, 22 August 2013 at 07:59:56 UTC, qznc wrote:

On Wednesday, 21 August 2013 at 16:21:47 UTC, Ramon wrote:

As for generics, let me put it this way:
In Eiffel generics have been an integral part of the language 
design from the beginning. In D ways and mechanisms are 
provided to achieve what quite usually is the goal of 
generics, namely generic algorithms in way, i.e. by having to 
write code for an algorithm just once. That might seem to be a 
minor difference, in particular when looking from a Huh? I 
can get it done, so what's the fuss all about, eh? 
perspective.
Of course, there the C and successors worlds proponents are 
right, this incurs a price (which templates do, too ...) and, 
yes, in the end, somewhere someone or something must sort the 
types out anyway (because of the way CPUs work).


There are basically two ways to implement generics. Type 
erasure (Java,Haskell) or template instantiation (C++,D). 
Instantiation provides better performance, but sacrifices error 
messages (fixable?), binary code size, and compilation 
modularity (template implementation must be available for 
instantiation). Type safety is not a problem in either approach.


Longer form: http://beza1e1.tuxen.de/articles/generics.html

An interesting twist would be to use type erasure for reference 
types and instantiation for value types. Another idea could be 
to use instantiation selectively as an optimization and erasure 
in general.


Which is the way .NET does it.

http://blogs.msdn.com/b/carlos/archive/2009/11/09/net-generics-and-code-bloat-or-its-lack-thereof.aspx




Another example is data types, concretely integers. Ada offers 
a nice way do precisely nail down precision/storage. If I want 
to store days_of_month I can have an integer type holding ints 
between 1 and 31 (which, due to the way they implemented it 
can be a PITA). Eiffel gives me something quite similar (in a 
more elegant way) and additionally a dumb INTEGER (32 or 64 
bit) and than a gazillion subtypes like INTEGER_16. That's 
great because in a quick and dirty script a plain integer (max 
size of CPU) is good enough and keeps life simple. If I need 
days_of_month I can very easily have that as int type.


In D you can use structs:

  struct days_of_month {
int day;
/* fill in operator overloading etc */
  }


Thanks for the Eiffel info.


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

2013-08-22 Thread Atash

On Wednesday, 21 August 2013 at 18:50:30 UTC, Ali Çehreli wrote:

On 08/21/2013 11:40 AM, Atash wrote:

 I don't see wording 'template pack' being problematic,
assuming that there's
 really no other way to use them but through templates (which
AFAIK they
 can't).

TypeTuple can represent function parameter lists and array 
literal lists as well:


Under the assumption that the following was meant to be a 
counterpoint...



import std.typetuple;

void func(int, int)
{}

struct S(int a, int b)
{}

void main()
{
alias tt = TypeTuple!(1, 2);


^ I'm not seeing the case given that TypeTuple is a template.

== What are we *actually* talking about?

I feel like this wasn't well defined, because now I'm feeling 
mildly confused with where the discussion has gone.


template Stuff(A...) { stuff } // a sequence/tuple of template 
parameters

alias TypeTuple!(stuff) B; // std.TypeTuple
TypeTuple!(stuff) C; // value tuple

I'm inclined to say that the debate is currently about A, but 
just to make sure... are we talking about A, B, C, or something 
else entirely?


== Annnddd more general stuff

Under the assumption that we are talking about A in the section 
above...


IMO, it's almost inevitable that whatever noun you guys decide on 
is going to be preceded by the word 'template' in conversation 
and in written communication if it isn't there already. While 
that sort of casual wording may be easily relegated to a synonym, 
it's still worth thinking about, methinks.


Re: DQuick a GUI Library (prototype)

2013-08-22 Thread Flamaros

On Thursday, 22 August 2013 at 07:24:10 UTC, Jacob Carlborg wrote:

On 2013-08-22 01:35, Sebastian Graf wrote:


+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


CoffeeScript is nice too. But I don't see a reason to use 
something other than a markup language if only a GUI builder 
should read and write those files.


The GUI editor will allow to write expression in addition of a 
classic value setter.


It's really useful to have few pieces of code directly on the GUI 
side notably when it's only related to the organisations of GUI 
elements.


Re: Possible solution to template bloat problem?

2013-08-22 Thread Regan Heath

On Wed, 21 Aug 2013 02:46:33 +0100, Ramon s...@thanks.no wrote:


On Tuesday, 20 August 2013 at 22:58:24 UTC, John Colvin wrote:

On Tuesday, 20 August 2013 at 22:49:40 UTC, Ramon wrote:
Happily I'm stupid and completely missed the condescending tone of an  
evident genius. Instead I'll just be grateful that it pleased one of  
the D masters to drop some statement down at me at all.



Awesome, thank you and keep destroying.


destroying??? Which part of not to bash it and of D means a lot  
to me and of D is, no doubts, an excellent and modern incarnation of  
C/C++. As

far as I'm concerned D is *the* best C/C++ incarnation ever,
hands down. was too complicated to understand for your genius brain?


I knew this would happen at some point:
Andrei uses destroy as a positive term to denote a well-reasoned  
powerful argument/response.


Chill :)


Uhum.

Well, where I live to destroy has a pretty clear and very negative  
meaning.
I took that post (of Mr. Alexandrescu) as very rude and condescending  
and I do not intend to change my communication habits so as to  
understand to destroy as a positive statement or even a compliment.


Have you heard the phrase when in Rome...  Seriously, you would rather  
assume a negative meaning/intent even after someone has taken the time to  
explain the intent/usage of the word/phrase in this grand forum?


I sense that you may be beyond reasonable advice at this point?  But, if  
not..


Always start by assuming good intent, if you're right (and you will be 90%  
of the time) no problem.  If you're wrong, well at least you've not gotten  
worked up about it (so they have failed in their goal) and chances are it  
will annoy the abuser even more that you haven't (so ultimately, you win).


Communication in written form is fraught with pitfalls, and this thread  
demonstrates how comments can be taken in completely the wrong way.   
Dicebot's I am dangerously close to hating you. was meant in a friendly  
way, /you/ decided not to read it that way.  Likewise Andrei's style is  
abrupt but there are good reasons for this, none of which include the goal  
of offending but /you/ have chosen to read them that way.


Sure, more effort could be taken to make it clearer with excess smileys  
etc.  But, that stuff isn't necessary for communicating the content, and  
isn't necessary between established forum members, and isn't necessary if  
everyone just assumes good intent from the outset.


All the best,
Regan

--
Using Opera's revolutionary email client: http://www.opera.com/mail/


Re: DQuick a GUI Library (prototype)

2013-08-22 Thread Jacob Carlborg

On 2013-08-22 10:29, Flamaros wrote:


The GUI editor will allow to write expression in addition of a classic
value setter.


What do you mean with expression ?

--
/Jacob Carlborg


Re: DQuick a GUI Library (prototype)

2013-08-22 Thread Flamaros

On Thursday, 22 August 2013 at 09:15:27 UTC, Jacob Carlborg wrote:

On 2013-08-22 10:29, Flamaros wrote:

The GUI editor will allow to write expression in addition of a 
classic

value setter.


What do you mean with expression ?


something like :
function()
   return parent.width
end

That the way of how works property binding.


Re: Why I chose D over Ada and Eiffel

2013-08-22 Thread Joseph Rushton Wakeling
On Wednesday, 21 August 2013 at 17:48:49 UTC, Andrei Alexandrescu 
wrote:
No random access. I didn't know about drop-last though - does 
it work in O(1)?


There is nth 
http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/nth 
but the O(n) cited there is rather disturbing.


More accurately was the point that Clojure's sequence API is 
(to the best of my understanding) only dealing with forward 
access, whereas D distinguishes between one-pass, forward, 
bidirectional, and random, and designs algorithms around these 
notions.


I'll check up with my friend on the forward access side.  What 
certainly seems to be true is that the API doesn't make the 
useful distinctions/classifications that D does.


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

2013-08-22 Thread Regan Heath
On Wed, 21 Aug 2013 18:53:06 +0100, Andrei Alexandrescu  
seewebsiteforem...@erdani.org wrote:


There's an inordinate amount of confusion around what we currently call  
type tuple (embodied in std's TypeTuple). I've been furious  
immediately as I got word that Walter called it that way, and it hasn't  
failed to make everybody else feel the same over the years.


So: shall we use template pack going forward exclusively whenever we  
refer to that stuff? That way we can unambiguously use tuple for  
value tuples, i.e. like mini-structs that group values together.


Destroy. I mean criticize.


After reading the thread I think it might help to try to define the  
important characteristics of them, and from that select the key


Using this as a reference to my understanding:
http://wiki.dlang.org/The_D_Programming_Language/Seq

In particular the section:
Q: What's the deal with auto-expansion?

I think .. type tuples are:
- Compile time
- A kind of (list, set, group, or collection) of (parameters/arguments,  
initialisers, parent classes)

- Flat i.e. auto expanded where used, not nested.
- An alias for the elements it contains
- A thing in which the ordering is important

I am leaning toward the fact that they are an alias being a key  
property, that and the fact that they are a list or set of things.   
Sequence may be even better than list as it imples more heavily that the  
ordering is important.


So, I am personally leaning toward dennis's suggestion of Alias Sequence.

But, I do worry a little about overloading the term alias.  However..  
TypeTuple is defined using alias so maybe they are the same thing  
after all.


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/


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

2013-08-22 Thread deadalnix
On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu 
wrote:
There's an inordinate amount of confusion around what we 
currently call type tuple (embodied in std's TypeTuple). I've 
been furious immediately as I got word that Walter called it 
that way, and it hasn't failed to make everybody else feel the 
same over the years.


So: shall we use template pack going forward exclusively 
whenever we refer to that stuff? That way we can unambiguously 
use tuple for value tuples, i.e. like mini-structs that 
group values together.


Destroy. I mean criticize.



Many people started to use the sequence term. I think we should 
stick for that one.


Pack is kind of misleading IMO, as they automagically unpack.

So template argument sequence. If they happen to all be 
types/alias/values, types/alias/values sequence.


Re: Why I chose D over Ada and Eiffel

2013-08-22 Thread John Colvin
On Thursday, 22 August 2013 at 02:06:13 UTC, Tyler Jameson Little 
wrote:

- 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


That isn't allowed. The memory for c must be pre-allocated, and 
the expression then becomes c[] = a[] * b[];


Is it SIMD'd?

It depends. There is a whole load of hand-written assembler for 
simple-ish expressions on builtin types, on x86. x86_64 is only 
supported with 32bit integer types because I haven't finished 
writing the rest yet...


However, I'm not inclined to do so at the moment as we need a 
complete overhaul of that system anyway as it's currently a 
monster*.  It needs to be re-implemented as a template 
instantiated by the compiler, using core.simd. Unfortunately it's 
not a priority for anyone right now AFAIK.



*
hand-written asm loops. If fully fleshed out there would be:
  ((aligned + unaligned + legacy mmx) * (x86 + x64) + fallback 
loop)

  * number of supported expressions * number of different types
of them. Then there's unrolling considerations. See 
druntime/src/rt/arrayInt.d


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

2013-08-22 Thread dennis luehring

Am 22.08.2013 12:05, schrieb Regan Heath:

On Wed, 21 Aug 2013 18:53:06 +0100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:


There's an inordinate amount of confusion around what we currently call
type tuple (embodied in std's TypeTuple). I've been furious
immediately as I got word that Walter called it that way, and it hasn't
failed to make everybody else feel the same over the years.

So: shall we use template pack going forward exclusively whenever we
refer to that stuff? That way we can unambiguously use tuple for
value tuples, i.e. like mini-structs that group values together.

Destroy. I mean criticize.


After reading the thread I think it might help to try to define the
important characteristics of them, and from that select the key

Using this as a reference to my understanding:
http://wiki.dlang.org/The_D_Programming_Language/Seq

In particular the section:
Q: What's the deal with auto-expansion?

I think .. type tuples are:
- Compile time
- A kind of (list, set, group, or collection) of (parameters/arguments,
initialisers, parent classes)
- Flat i.e. auto expanded where used, not nested.
- An alias for the elements it contains
- A thing in which the ordering is important

I am leaning toward the fact that they are an alias being a key
property, that and the fact that they are a list or set of things.
Sequence may be even better than list as it imples more heavily that the
ordering is important.

So, I am personally leaning toward dennis's suggestion of Alias Sequence.

But, I do worry a little about overloading the term alias.  However..
TypeTuple is defined using alias so maybe they are the same thing
after all.

R



~but~ an alias sequence item is different to an alias

an alias can't contain untyped values:

alias x = 5;
alias y = hallo;

an alias is an real accessible symbol - not just an position in a sequence

or am i wrong here?


Re: Thoughts on possible tuple semantics

2013-08-22 Thread deadalnix
So, I took some time to think about this. Let me propose 
something close, but different.


I'll try to define sequences more precisely and define some tools 
that allow to implement tuples in a nice way on top of it.


A sequence is an ordered set. You can have types, alias and 
values sequences. Values sequence can be runtime or compile time.


You can ask for sequences as parameter template using ... and 
using the regular template parameter syntax.


template(T) = template(T...)
template(alias T) = template(alias T...)
template(T U, T) = template(T U, T...)
template(T alias U) = template(T alias U..., T...)

Obviously, we want template(T...) to be a special for a 
transition period. T... being a subset of alias T..., we can 
start with a warning when the use it outside the subset.


It is a breaking change, but reduce the confusion by reusing the 
template parameter mechanism. Considering that most people here 
are very confused by type tuples, I highly doubt a lot of code is 
outside abusing this feature.


A type sequence can be used to define a value sequence :
auto foo(T...)(T args) { ... }

args is a value sequence. It isn't packed as a struct or 
anything, simply several values (here several function 
parameters) hidden behing one identifier. As a result, args do 
not have address or type.


typeof(args) returns T, which is a type sequence (not a type !)
typeid(args) is invalid.

Each member of args however have an address, a type and 
everything a function parameter have.


A sequence provide an access to its member via [index] and length 
to indicate its length. index need to be a compile time value, 
and length is a compile time value.


It is possible to use a sequence to define any ordered set of 
stuff (value sequence can be used for function call, type 
sequence to create multiple fields in a struct, etc . . .).


Right, most of what is described here is close from what we 
already have. Types sequence in a struct can be used to create 
tuples and IFTI can make it very handy.


Sequences can be built using the coma operator. int, float is a 
type sequence. args[0], args[1] is a value sequence. They can be 
returned from functions :


int, int foo() {
return 3, 4;
}

int, int a = foo();

However, due to syntax conflict, int, int a = 3, 4; is not 
possible (it the value on the right is an assignment, it conflict 
with multiple declarations). () can be used to disambiguate : 
int, int a = (3, 4);


The missing piece is an auto dispatch function. I propose here a 
simple rewrite rule, as this is simple to implement and can be 
really effective.


auto (a, b) = foo();

is rewritten as

auto tmp = foo(); // Here tmp is a sequence of declaration of 
value. No need to create lvalues (especially is a complex copy is 
involved).
assert(tmp.length == 2); // Should be removed anyway for 
sequences.

auto a = tmp[0];
auto b = tmp[1];

This allow to make any user type unpackable. Or even arrays, 
slices, randomAccessRanges, etc . . .


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

2013-08-22 Thread deadalnix
On Thursday, 22 August 2013 at 10:32:06 UTC, dennis luehring 
wrote:

~but~ an alias sequence item is different to an alias

an alias can't contain untyped values:

alias x = 5;
alias y = hallo;

an alias is an real accessible symbol - not just an position in 
a sequence


or am i wrong here?


Function literal are passed around via alias all over the place.


Re: DQuick a GUI Library (prototype)

2013-08-22 Thread Jacob Carlborg

On 2013-08-22 11:28, Flamaros wrote:


something like :
function()
return parent.width
end

That the way of how works property binding.


Can't you bind that to a named method in a controller, or similar? Then 
you would store the name of the controller/class and the name of the method.


--
/Jacob Carlborg


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

2013-08-22 Thread Tommi
On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu 
wrote:
So: shall we use template pack going forward exclusively 
whenever we refer to that stuff?


I think it should be called either a compile-time list or a 
static list, because it's a list of things which can be 
referred to at compile-time.


import std.typetuple;

void main()
{
int n;
alias T = TypeTuple!(int, 4, n);

static assert(T[1] == 4);
T[2]++;
assert(n == 1);
}


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

2013-08-22 Thread ilya-stromberg

On Sunday, 18 August 2013 at 19:46:00 UTC, Jacob Carlborg wrote:

If versioning is crucial it can be added.


Can std.serialization load data if class definition was changed?

For example, we have class Foo:

class Foo
{
int a;
int b;
}

and we serialize it in some file. After that class Foo was 
changed:


class Foo
{
int b;
int a;
}

Can std.serialization load data from old file to the new class?


Re: DQuick a GUI Library (prototype)

2013-08-22 Thread goughy

On Tuesday, 20 August 2013 at 21:22:48 UTC, 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

PS : Download it for a better quality


Could I recommend you evaluate IUP first?
(http://www.tecgraf.puc-rio.br/iup/)

It is cross-platform, MIT licensed, mature, and is by the same
guys that _wrote_ Lua.  Oh, and Lua is bundled already, of
course.  Plus it has a pure C interface (easy to wrap), canvas,
GL support, imaging, plotting, webkit, scintilla editor support
plus more.

I certainly don't want to discourage any input in pure D, but it
would be a much less daunting exercise, IMO.  I personally think
the way D has adopted the CURL library to gain some quick wins in
the network protocol area is probably a more sustainable model
given the size of the community.

Its gonna take a long time to get anywhere if everything is NIH.

Just my 2c.


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

2013-08-22 Thread Tommi

On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:

I think it should be called either a compile-time list ...


And if we go with compile-time list, then we can follow the 
example of std.regex.ctRegex and name the thing ctList.


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

2013-08-22 Thread Regan Heath
On Thu, 22 Aug 2013 11:32:06 +0100, dennis luehring dl.so...@gmx.net  
wrote:



Am 22.08.2013 12:05, schrieb Regan Heath:

On Wed, 21 Aug 2013 18:53:06 +0100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:


There's an inordinate amount of confusion around what we currently call
type tuple (embodied in std's TypeTuple). I've been furious
immediately as I got word that Walter called it that way, and it hasn't
failed to make everybody else feel the same over the years.

So: shall we use template pack going forward exclusively whenever we
refer to that stuff? That way we can unambiguously use tuple for
value tuples, i.e. like mini-structs that group values together.

Destroy. I mean criticize.


After reading the thread I think it might help to try to define the
important characteristics of them, and from that select the key

Using this as a reference to my understanding:
http://wiki.dlang.org/The_D_Programming_Language/Seq

In particular the section:
Q: What's the deal with auto-expansion?

I think .. type tuples are:
- Compile time
- A kind of (list, set, group, or collection) of (parameters/arguments,
initialisers, parent classes)
- Flat i.e. auto expanded where used, not nested.
- An alias for the elements it contains
- A thing in which the ordering is important

I am leaning toward the fact that they are an alias being a key
property, that and the fact that they are a list or set of things.
Sequence may be even better than list as it imples more heavily that  
the

ordering is important.

So, I am personally leaning toward dennis's suggestion of Alias  
Sequence.


But, I do worry a little about overloading the term alias.  However..
TypeTuple is defined using alias so maybe they are the same thing
after all.

R


an alias is an real accessible symbol - not just an position in a  
sequence


or am i wrong here?


That's not quite what I was trying to say.

I see it as the Alias Sequence being an alias for the entire sequence of  
symbols/expressions in the ordering in which they are given/defined.


That said, to actually use them as aliases you need to name them, with an  
alias expression, e.g.


// inspired by http://wiki.dlang.org/The_D_Programming_Language/Seq
import std.stdio;

template AliasSeqence(T...){ alias AliasSeqence = T; }

alias one = AliasSeqence!(1);
alias onetwo = AliasSeqence!(one,2);
alias parented = AliasSeqence!(B,C);
alias orphaned = AliasSeqence!();

// Parent list:
interface C { }
class B: orphaned { } // meaning: class B{ }
class A: parented // meaning: class A: B,C{ }
{
  this(int a, int b) { writefln(A.a = %d, A.b = %d, a, b); }
}

// Array literal element list:
int[] digits = [0,onetwo,3]; // meaning: [0,1,2,3]

void foo(int a, int b, int c)   { writefln(foo(%d,%d,%d), a, b, c); }
void Foo(int a, int b, int c)() { writefln(Foo(%d,%d,%d), a, b, c); }

void main()
{
  writefln(digits = %s, digits);

  // Function argument list (including struct constructor calls, excluding  
arguments to overloaded operators):

  foo(onetwo,3); // meaning: foo(1,2,3)

  // Template argument list (this is why you cannot have argument lists  
nested within argument lists).

  Foo!(0,onetwo)(); // meaning: Foo!(0,1,2)

  // Index argument list:
  int[] arr = new int[2];
  arr[one] = 2; // meaning: arr[1]
  writefln(arr[one]=%d, arr[one]);

  // New argument list(s):
  A a = new A(onetwo); // meaning new A(1,2)
}

R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/


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

2013-08-22 Thread Regan Heath

On Thu, 22 Aug 2013 12:55:55 +0100, Tommi tommitiss...@hotmail.com wrote:


On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:

I think it should be called either a compile-time list ...


And if we go with compile-time list, then we can follow the example of  
std.regex.ctRegex and name the thing ctList.


+1 I like this suggestion also.

R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/


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

2013-08-22 Thread Michel Fortin

On 2013-08-22 11:55:55 +, Tommi tommitiss...@hotmail.com said:


On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:

I think it should be called either a compile-time list ...


And if we go with compile-time list, then we can follow the example 
of std.regex.ctRegex and name the thing ctList.


Will .tupleof become .ctlistof?

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



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

2013-08-22 Thread John Colvin

On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote:
On 2013-08-22 11:55:55 +, Tommi 
tommitiss...@hotmail.com said:



On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:

I think it should be called either a compile-time list ...


And if we go with compile-time list, then we can follow the 
example of std.regex.ctRegex and name the thing ctList.


Will .tupleof become .ctlistof?


strictly speaking I think it would be an alias list, so perhaps 
.aliasList


Re: Possible solution to template bloat problem?

2013-08-22 Thread Ramon

On Thursday, 22 August 2013 at 09:10:33 UTC, Regan Heath wrote:
On Wed, 21 Aug 2013 02:46:33 +0100, Ramon s...@thanks.no 
wrote:



On Tuesday, 20 August 2013 at 22:58:24 UTC, John Colvin wrote:

On Tuesday, 20 August 2013 at 22:49:40 UTC, Ramon wrote:
Happily I'm stupid and completely missed the condescending 
tone of an evident genius. Instead I'll just be grateful 
that it pleased one of the D masters to drop some statement 
down at me at all.



Awesome, thank you and keep destroying.


destroying??? Which part of not to bash it and of D 
means a lot to me and of D is, no doubts, an excellent and 
modern incarnation of C/C++. As

far as I'm concerned D is *the* best C/C++ incarnation ever,
hands down. was too complicated to understand for your 
genius brain?


I knew this would happen at some point:
Andrei uses destroy as a positive term to denote a 
well-reasoned powerful argument/response.


Chill :)


Uhum.

Well, where I live to destroy has a pretty clear and very 
negative meaning.
I took that post (of Mr. Alexandrescu) as very rude and 
condescending and I do not intend to change my communication 
habits so as to understand to destroy as a positive 
statement or even a compliment.


Have you heard the phrase when in Rome...  Seriously, you 
would rather assume a negative meaning/intent even after 
someone has taken the time to explain the intent/usage of the 
word/phrase in this grand forum?


I sense that you may be beyond reasonable advice at this point?
 But, if not..

Always start by assuming good intent, if you're right (and you 
will be 90% of the time) no problem.  If you're wrong, well at 
least you've not gotten worked up about it (so they have failed 
in their goal) and chances are it will annoy the abuser even 
more that you haven't (so ultimately, you win).


Communication in written form is fraught with pitfalls, and 
this thread demonstrates how comments can be taken in 
completely the wrong way.  Dicebot's I am dangerously close to 
hating you. was meant in a friendly way, /you/ decided not to 
read it that way.  Likewise Andrei's style is abrupt but there 
are good reasons for this, none of which include the goal of 
offending but /you/ have chosen to read them that way.


Sure, more effort could be taken to make it clearer with excess 
smileys etc.  But, that stuff isn't necessary for communicating 
the content, and isn't necessary between established forum 
members, and isn't necessary if everyone just assumes good 
intent from the outset.


All the best,
Regan



Wow. Now I even get general advice for my life like Always start
by assuming good intent.

How about some honesty?

It happens to everybody of us. We hadn't any bad intentions but,
alas, someone feels offended, improperly treated, etc.
There is exactly 1 proper reaction for a responsible adult: To
honestly look Did I contribute to that? and if so, to explain
oneself.

It would have cost pretty nothing to Mr. A. to simply say OOps.
Didn't mean any bad. When I say 'destroy' it's actually in
between an invitation to continue hitting with constructive
criticism and a compliment. Weird habit of mine. Not even a
sorry would be needed.

Well, he didn't. Instead he relied on his alpha-dog factor and
the fact that there had already been some group members
explaining and excusing him (and, in fact and very funnily, when
he finally decided to comment he addressed not me but someone
else).

Meanwhile I'd be better placed to start trouble - if that ever
were my intention. I've read a good part of Mr. A's book, watched
quite some youtube, both with Mr. Bright and Mr. A. - and I have,
to put it in prosecutor like wording, generously enough material
in my hands (where Bright/AA basically say something I said too
and got bad reactions. But then, it's not really new that it
matters in social groups _who_ says sth.).

One simple example: Is Mr. A perfectly well capable to talk/write
within usual social limits? Yes, he is. His (btw. very well done,
if somewhat jumpy) book proves it. He just happens to feel free
to behave like an *** in this group, where he is an alpha and
where tough lingo and weird personal rites are part of the
culture - and glue - of this D crowd.

I don't feel hurt, I am not after Mr. A., I'm not looking for
trouble and I'm not in fight mode or anti-D or anything like
that. But would you (all) kindly refrain from playing your group
games with me and telling me bullsh*t? I'm not interested.
Mr. A. has written the book on D and he did that quite well. He
has largely contributed to D and he did that well and some of his
work is even brilliant (for scope alone I'd be willing to
praise him gleefully).
And he also happened to show himself capable of gross social and
human incompetence - and I don't care; I'm interested in his
work, not in his person.
If at all, I'd point out the professional component, i.e. the
question, if it is wise for a relatively new, unknown and little
used language to drive newcomers off rather 

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

2013-08-22 Thread Tommi

On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote:
On 2013-08-22 11:55:55 +, Tommi 
tommitiss...@hotmail.com said:



On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:

I think it should be called either a compile-time list ...


And if we go with compile-time list, then we can follow the 
example of std.regex.ctRegex and name the thing ctList.


Will .tupleof become .ctlistof?


I think it could be .fieldsof


Re: DQuick a GUI Library (prototype)

2013-08-22 Thread Andrej Mitrovic
On 8/22/13, goughy and...@goughy.org wrote:
 Could I recommend you evaluate IUP first?
 (http://www.tecgraf.puc-rio.br/iup/)

It doesn't seem to support OSX, Unicode, cascading menus:

http://www.tecgraf.puc-rio.br/iup/en/to_do.html

But otherwise I agree starting from scratch is really difficult.


Re: DQuick a GUI Library (prototype)

2013-08-22 Thread Andrej Mitrovic
On 8/22/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
 On 8/22/13, goughy and...@goughy.org wrote:
 Could I recommend you evaluate IUP first?
 (http://www.tecgraf.puc-rio.br/iup/)

 It doesn't seem to support OSX

I meant to say native OSX, It uses GTK on that platform.


Re: Why I chose D over Ada and Eiffel

2013-08-22 Thread Ramon

On Thursday, 22 August 2013 at 07:59:56 UTC, qznc wrote:

On Wednesday, 21 August 2013 at 16:21:47 UTC, Ramon wrote:

As for generics, let me put it this way:
In Eiffel generics have been an integral part of the language 
design from the beginning. In D ways and mechanisms are 
provided to achieve what quite usually is the goal of 
generics, namely generic algorithms in way, i.e. by having to 
write code for an algorithm just once. That might seem to be a 
minor difference, in particular when looking from a Huh? I 
can get it done, so what's the fuss all about, eh? 
perspective.
Of course, there the C and successors worlds proponents are 
right, this incurs a price (which templates do, too ...) and, 
yes, in the end, somewhere someone or something must sort the 
types out anyway (because of the way CPUs work).


There are basically two ways to implement generics. Type 
erasure (Java,Haskell) or template instantiation (C++,D). 
Instantiation provides better performance, but sacrifices error 
messages (fixable?), binary code size, and compilation 
modularity (template implementation must be available for 
instantiation). Type safety is not a problem in either approach.


Longer form: http://beza1e1.tuxen.de/articles/generics.html

An interesting twist would be to use type erasure for reference 
types and instantiation for value types. Another idea could be 
to use instantiation selectively as an optimization and erasure 
in general.


Another example is data types, concretely integers. Ada offers 
a nice way do precisely nail down precision/storage. If I want 
to store days_of_month I can have an integer type holding ints 
between 1 and 31 (which, due to the way they implemented it 
can be a PITA). Eiffel gives me something quite similar (in a 
more elegant way) and additionally a dumb INTEGER (32 or 64 
bit) and than a gazillion subtypes like INTEGER_16. That's 
great because in a quick and dirty script a plain integer (max 
size of CPU) is good enough and keeps life simple. If I need 
days_of_month I can very easily have that as int type.


In D you can use structs:

  struct days_of_month {
int day;
/* fill in operator overloading etc */
  }



Thank you.

Well in an OO language the actual type(s) is/are known. So real 
genericity boils done to whether an object has the required 
functions or not.


D has, obviously piously following the C++ way (which can be a 
good thing), chosen to go the template way, that is, to handle it 
compile time. Other languages have chosen to do it runtime which 
is no worse or better per se but happens to be more consistent 
with OO.


Some here argued that, well, in the end, say, a simple int and a 
bank account, need different data types and operations because it 
matters to CPUs whether it does sth. with a DWORD or a char[]. 
And, so they argued, therefore you have to pay a runtime penalty 
for real generics. I don't think so.
Sure, one evidently pays a penalty for OO in general (as opposed 
to simple scalars). But it's not the genericity that costs.


Last but not least, there simply isn't a either/or issue. Once 
can perfectly well have both. And no, that doesn't necessarily 
bring a performance penalty with it.


Another point of view that doesn't match precisely but may help 
to understand it is this:


True OOP is basically about It's the *data*! while systems 
programming understandably is closer to it's the *code*!
Where the former has data carrying the operations with them the 
latter has data as something that is fed in and processed and 
spit out by the machinery. And it's that what brings up the 
question Well, but how would the CPU know what kind of data it's 
working on? That requires expensive extra steps.


Again, for systems programming that's just fine. But the whole 
penalty assumption largely stems from looking at true OOP through 
the C/C++ model.


Re: Thoughts on possible tuple semantics

2013-08-22 Thread Dicebot

On Thursday, 22 August 2013 at 11:19:55 UTC, deadalnix wrote:
A sequence is an ordered set. You can have types, alias and 
values sequences. Values sequence can be runtime or compile 
time.



typeof(args) returns T, which is a type sequence (not a type !)
typeid(args) is invalid.


1) You propose typeof to result not a type entity. Well, if it 
can be result of typeof, can be used to declare variables and can 
be aliased - what makes it different from a type?


2) is(typeof(tuple(42, 42)) == typeof(ctseq(42, 42))) == ? 
(assuming typeof(args) == T and you don't make distinction 
between runtime and compile-time value sequences.


Also you don't seem to cover mixed sequences which are essential 
to D templates.


Re: Why I chose D over Ada and Eiffel

2013-08-22 Thread deadalnix

On Thursday, 22 August 2013 at 12:37:50 UTC, Ramon wrote:
Well in an OO language the actual type(s) is/are known. So real 
genericity boils done to whether an object has the required 
functions or not.




Polymorphism say no, you don't know the actual type, and this is 
the whole point of OOP : being able to interact with object of 
various type as long as they provide the needed interface to 
interact with.


D has, obviously piously following the C++ way (which can be a 
good thing), chosen to go the template way, that is, to handle 
it compile time. Other languages have chosen to do it runtime 
which is no worse or better per se but happens to be more 
consistent with OO.




D recognize that OO isn't the only paradigm on earth. And generic 
won't work with non OO code.


Some here argued that, well, in the end, say, a simple int and 
a bank account, need different data types and operations 
because it matters to CPUs whether it does sth. with a DWORD or 
a char[]. And, so they argued, therefore you have to pay a 
runtime penalty for real generics. I don't think so.
Sure, one evidently pays a penalty for OO in general (as 
opposed to simple scalars). But it's not the genericity that 
costs.




Indirections, opaque calls, and heap allocation are probably the 
3 first performance killers on modern architecture. OO embrace 
the 3 of them.


True OOP is basically about It's the *data*! while systems 
programming understandably is closer to it's the *code*!
Where the former has data carrying the operations with them 
the latter has data as something that is fed in and processed 
and spit out by the machinery. And it's that what brings up the 
question Well, but how would the CPU know what kind of data 
it's working on? That requires expensive extra steps.




No true OOP is about behavioral abstraction. See Liskov's 
substitution principle. Data is merely a tool and OOP promote its 
encapsulation. In other term, data is an implementation detail in 
OOP.


Again, for systems programming that's just fine. But the whole 
penalty assumption largely stems from looking at true OOP 
through the C/C++ model.


The whole penalty assumptions come from how actual compilers and 
CPU works. If you have new idea to revolution both and change the 
deal, great, but I highly doubt so.


Re: A possible suggestion for the Foreach loop

2013-08-22 Thread Timon Gehr

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

On 8/21/13 4:52 AM, John Colvin 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 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.


Not necessarily. We could allow static foreach as a functional
construct that binds in turn a symbol to each element in a collection.
...


Yup.


A static foreach in conjunction with string mixins would be great for
simplifying code generation, e.g. for each method in that class
generate a method here.



AFAIK one only reason why it hasn't made it in yet were implementation 
issues related to DMD internals? The design was discussed in 2007's 
dconf IIRC.




Andrei




We really need to define a consistent semantics for compile time symbol 
manipulation though.


Eg:

class C{
int a;
static foreach(x;__traits(allMembers,C)){
mixin(int ~__traits(identifier,x)~b;);
}
}

What is this supposed to do? class C{ int a,ab; }? Non-terminating 
compilation? Error?


My best guess is that the above code should be illegal, but there is a 
lot of similar code already out in the wild that works by chance. Eg. I 
guess some of Manu's bindings only work by luck. Thrift for D also 
contains one or two questionable constructs, as David has shown me 
recently. (It is possible that this is related to the recent breakage, 
DMD does not necessarily behave consistently w.r.t. to this kind of code 
across versions.)


Most of the times this has been brought up it was simply ignored, but it 
is a glaring hole in D's design.


Re: Why I chose D over Ada and Eiffel

2013-08-22 Thread Ramon

On Thursday, 22 August 2013 at 05:22:17 UTC, deadalnix wrote:
Just read this this : 
ftp://ftp.cs.utexas.edu/pub/dburger/papers/ISCA11.pdf and come 
back informed.


Well, I can give you a link to some paper that says that the 
world will break down and stop next tuesday. Interested?


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.


I know bridges in Siberia that are vastly superior to bridges 
in the Andes. Frankly, I'd prefer to use a european bridge.
And one *can* be in the C/C++ family and have a vastly safer 
system. Look at D.


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.


So? Is this a who knows most programs with lousy coding? 
contest?


All I see there is that programmers, in particular hobby hackers 
will spot - and use - any chance to wildly shoot around unless 
they are mildly (or less mildly) guided by a sound and safe 
system.


And I see (and confess for myself) that even seasoned programmers 
can very much profit from a system that makes it easier to do the 
right thing and harder to do the wrong thing.


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 . . .


Well, being a systems programming language D is condemned to keep 
quite some doors open. It seems (as far as I can that now) 
however to have done an excellent job in terms of safety (give or 
take some minor sins like '=' as assignment).


One might put Java against D. But frankly, I do not consider 
Javas approach Subdue them with pervert bureaucracy, hehe 
approach as acceptable (and it creates a whole set of problems, 
too).


Frankly, if I had to work on a highly safety critical and 
reliable project (say in the medical area) I would have a hard 
time to spot just 5 languages that I would consider. Ada comes to 
mind (but I don't like it) and Eiffel, which is great but that 
great pragmatically. I'm afraid I'd end up where I ended up in 
the first place: Eiffel vs. D.


I'm probably not counted as a happy D protagonist around here but 
I'd happily state that D is way ahead of 99% of the known 
languages. And that expressly includes safety.


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) ?


I refuse to answer that because it's way out of reality.


Re: DQuick a GUI Library (prototype)

2013-08-22 Thread Flamaros

On Thursday, 22 August 2013 at 11:39:29 UTC, Jacob Carlborg wrote:

On 2013-08-22 11:28, Flamaros wrote:


something like :
function()
   return parent.width
end

That the way of how works property binding.


Can't you bind that to a named method in a controller, or 
similar? Then you would store the name of the controller/class 
and the name of the method.


That not always so simple.

With DQuick the D application is like a slave that contains data, 
and the GUI is free to display the data in many ways.
Property binding act like a part of the controller if we are 
talking about the MVC model.
Notice that if a data in the application side change, depending 
properties binding will be updated, so the GUI too.


At my office we port an application from iOS to Android, Windows 
and MacOSX. We actually rewrite the GUI for other platforms in 
QtQuick, which allow us to let the main code has it. We only add 
few wrappers because QtQuick support only Qt types for objects we 
need to bind in QML (javascript language used for GUI).


Re: A possible suggestion for the Foreach loop

2013-08-22 Thread Timon Gehr

On 08/21/2013 09:17 PM, Dicebot wrote:


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.


I disagree. I think the relationship between foreach and static foreach 
should essentially mirror that of if and static if.


Re: Thoughts on possible tuple semantics

2013-08-22 Thread deadalnix

On Thursday, 22 August 2013 at 12:50:06 UTC, Dicebot wrote:

On Thursday, 22 August 2013 at 11:19:55 UTC, deadalnix wrote:
A sequence is an ordered set. You can have types, alias and 
values sequences. Values sequence can be runtime or compile 
time.



typeof(args) returns T, which is a type sequence (not a type !)
typeid(args) is invalid.


1) You propose typeof to result not a type entity. Well, if 
it can be result of typeof, can be used to declare variables 
and can be aliased - what makes it different from a type?




It is a sequence of types. It can be used to declare a sequence 
of variables.


2) is(typeof(tuple(42, 42)) == typeof(ctseq(42, 42))) == ? 
(assuming typeof(args) == T and you don't make distinction 
between runtime and compile-time value sequences.




In my proposal, tuple are a library construct. The proposal 
introduce the necessary tooling to implement them nicely.


is(typeof(42, 42) == (int, int));
is(typeof(tuple(42, 42)) == a library defined struct);

It could be defined as follow :

struct Tuple(T...) {
T expand;
alias expand this;
}

Also you don't seem to cover mixed sequences which are 
essential to D templates.


Theses are alias sequences.


Re: A possible suggestion for the Foreach loop

2013-08-22 Thread Timon Gehr

On 08/21/2013 10:53 PM, Dylan Knutson wrote:




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.


It's important to keep them separate regardless. static foreach is close 
to useless if it introduces a new scope for its body.


I.e.:

int main(){
foreach(_;Seq!int){
int x;
}
return x; // error
}

int main(){
static foreach(_;Seq!int){
int x;
}
return x; // ok
}


Re: A possible suggestion for the Foreach loop

2013-08-22 Thread Timon Gehr

On 08/22/2013 02:56 PM, Timon Gehr wrote:


AFAIK one reason why it hasn't made it in yet were implementation
issues related to DMD internals? The design was discussed in 2007's
dconf IIRC.


fixed.


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

2013-08-22 Thread deadalnix

On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote:
On 2013-08-22 11:55:55 +, Tommi 
tommitiss...@hotmail.com said:



On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:

I think it should be called either a compile-time list ...


And if we go with compile-time list, then we can follow the 
example of std.regex.ctRegex and name the thing ctList.


Will .tupleof become .ctlistof?


This feature should be dropped and provided as library using 
compile time reflection.


Re: DQuick a GUI Library (prototype)

2013-08-22 Thread Flamaros
On Thursday, 22 August 2013 at 12:34:20 UTC, Andrej Mitrovic 
wrote:

But otherwise I agree starting from scratch is really difficult.


That the reason we only tell that is a prototype, we firstly want 
to test the property binding concept, and we choose D because we 
like it.


Re: DQuick a GUI Library (prototype)

2013-08-22 Thread Jakob Ovrum

On Tuesday, 20 August 2013 at 21:22:48 UTC, 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

PS : Download it for a better quality


If you do decide to use Lua, I strongly recommend checking out 
LuaD[1]. Shameless self-promotion, yes; but the goal of LuaD is 
to be an uncompromising, superior alternative to using the Lua C 
API directly, for any project.


[1] https://github.com/JakobOvrum/LuaD


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

2013-08-22 Thread Timon Gehr

On 08/22/2013 03:07 PM, deadalnix wrote:

On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote:

On 2013-08-22 11:55:55 +, Tommi tommitiss...@hotmail.com said:


On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:

I think it should be called either a compile-time list ...


And if we go with compile-time list, then we can follow the example
of std.regex.ctRegex and name the thing ctList.


Will .tupleof become .ctlistof?


This feature should be dropped and provided as library using compile
time reflection.


How to bypass protection attributes?


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

2013-08-22 Thread Jacob Carlborg

On 2013-08-22 13:57, ilya-stromberg wrote:


Can std.serialization load data if class definition was changed?

For example, we have class Foo:

class Foo
{
 int a;
 int b;
}

and we serialize it in some file. After that class Foo was changed:

class Foo
{
 int b;
 int a;
}

Can std.serialization load data from old file to the new class?


Yes. In this case it will use the name of the instance fields when 
searching for values in the archive.


--
/Jacob Carlborg


Re: Download page needs a tidy up

2013-08-22 Thread Ludovit Lucenic

On Thursday, 22 August 2013 at 03:23:57 UTC, 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.


On 22 August 2013 13:07, Manu turkey...@gmail.com 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 am completely with you, Manu.
Same with me with GDC under Windows. Missing libiconv-2.dll...
The same happened to me when looking around for the other two D 
compilers. It took me a couple of days until I found the link on 
the dlang.org's download page.


Any suggestions on where to get a working copy of GDC to run on 
Windows, please?


Thanks,
Ludovit


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

2013-08-22 Thread deadalnix

On Thursday, 22 August 2013 at 13:10:28 UTC, Timon Gehr wrote:

On 08/22/2013 03:07 PM, deadalnix wrote:
On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin 
wrote:
On 2013-08-22 11:55:55 +, Tommi 
tommitiss...@hotmail.com said:



On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:

I think it should be called either a compile-time list ...


And if we go with compile-time list, then we can follow 
the example

of std.regex.ctRegex and name the thing ctList.


Will .tupleof become .ctlistof?


This feature should be dropped and provided as library using 
compile

time reflection.


How to bypass protection attributes?


compile time reflection should be able to do it. Discussion has 
been raised many time.


Re: Why I chose D over Ada and Eiffel

2013-08-22 Thread 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:
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) ?


I would, because my experience with Native Oberon and AOS (Blue 
Bottle),
teached me that those real time capabilities are possible in a 
desktop

OS written in a GC enabled systems programming language.

As example, BlueBottle has a video player, just the decoder has 
some snippets written in Assembly.


http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager?action=downloadupname=AosScreenshot1.jpg


--
Paulo


Re: DQuick a GUI Library (prototype)

2013-08-22 Thread Jacob Carlborg

On 2013-08-22 15:01, Flamaros wrote:


That not always so simple.

With DQuick the D application is like a slave that contains data, and
the GUI is free to display the data in many ways.
Property binding act like a part of the controller if we are talking
about the MVC model.
Notice that if a data in the application side change, depending
properties binding will be updated, so the GUI too.


If I understand you correctly that's how it work on using Xcode on Mac 
OS X as well. But Apple manage without a script language for the GUI 
code. It's XML and a binary format.


--
/Jacob Carlborg


Re: DQuick a GUI Library (prototype)

2013-08-22 Thread Jacob Carlborg

On 2013-08-22 14:39, Andrej Mitrovic wrote:


I meant to say native OSX, It uses GTK on that platform.


Thank you, otherwise you might have made some Mac OS X users angry :)

--
/Jacob Carlborg


Re: DQuick a GUI Library (prototype)

2013-08-22 Thread Andrej Mitrovic
On 8/22/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
 It doesn't seem to support OSX, Unicode, cascading menus:

 http://www.tecgraf.puc-rio.br/iup/en/to_do.html

 But otherwise I agree starting from scratch is really difficult.

Plus it seems to flicker on resize. It's not looking good.


Re: DQuick a GUI Library (prototype)

2013-08-22 Thread Andrej Mitrovic
On 8/22/13, Jacob Carlborg d...@me.com wrote:
 On 2013-08-22 14:39, Andrej Mitrovic wrote:

 I meant to say native OSX, It uses GTK on that platform.

 Thank you, otherwise you might have made some Mac OS X users angry :)

Hey I'm not on the OSX hate-train. :)


Re: Download page needs a tidy up

2013-08-22 Thread Wyatt
On Thursday, 22 August 2013 at 03:38:26 UTC, Tyler Jameson Little 
wrote:


Do we really want D1 compilers that easily accessable?


Considering D1 has an entire site of its own[0], why are they 
even there?  Move them to where they belong with a BIG RED BANNER 
saying they're EOL and an are you sure you want this? 
confirmation to download them.


-Wyatt

[0] http://www.digitalmars.com/d/1.0/


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

2013-08-22 Thread Jakob Ovrum
On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu 
wrote:
There's an inordinate amount of confusion around what we 
currently call type tuple (embodied in std's TypeTuple). I've 
been furious immediately as I got word that Walter called it 
that way, and it hasn't failed to make everybody else feel the 
same over the years.


So: shall we use template pack going forward exclusively 
whenever we refer to that stuff? That way we can unambiguously 
use tuple for value tuples, i.e. like mini-structs that 
group values together.


I'm fine with any name but would like to point out that it's 
probably essential that the new name allows for the distinction 
between what we currently call type tuples and expression/mixed 
tuples. The latter are not so important to distinguish, but type 
tuples have the privilege of being able to declare an expression 
tuple:


TypeTuple!(int, string) myExpressionTuple;
myExpressionTuple[0] = 42;
myExpressionTuple[1] = foo;
// etc

If we don't have an easy way to refer to this distinction with 
the new naming, it may not be adequate enough for everyone to 
discard the old, confusing names, which could potentially 
seriously stall adoption, as it would be tempting to use the old 
terms in certain situations. We also have the naming of 
std.traits' `isTypeTuple` and `isExpressionTuple` to think about.


On a different tangent; changes like this are probably easier to 
push through when they have a strong air of officialness. Thank 
you for starting the process with this thread. An idea would be 
to have Walter and/or yourself (Andrei) pick a short list of 
names you think make the most sense after the discussion has 
unfolded, then put them on a vote. If it ends in a tie, the two 
of you could exercise executive discretion in choosing the 
winner. The result could then be an official announcement that we 
could share in the community to further adoption.



Destroy. I mean criticize.


Oh please, I think destroy reflects a healthy prevalence of 
openness to criticism in this community, let's not stop using it 
just because one or two newbies have announced some mild 
displeasure with it :P


Re: DQuick a GUI Library (prototype)

2013-08-22 Thread Flamaros

On Thursday, 22 August 2013 at 13:20:25 UTC, Jacob Carlborg wrote:

On 2013-08-22 15:01, Flamaros wrote:


That not always so simple.

With DQuick the D application is like a slave that contains 
data, and

the GUI is free to display the data in many ways.
Property binding act like a part of the controller if we are 
talking

about the MVC model.
Notice that if a data in the application side change, depending
properties binding will be updated, so the GUI too.


If I understand you correctly that's how it work on using Xcode 
on Mac OS X as well. But Apple manage without a script language 
for the GUI code. It's XML and a binary format.


A lot of GUI system that respect the MVC system put the 
controller in the native code.


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

2013-08-22 Thread Dicebot

On Thursday, 22 August 2013 at 13:39:25 UTC, Jakob Ovrum wrote:
I'm fine with any name but would like to point out that it's 
probably essential that the new name allows for the distinction 
between what we currently call type tuples and expression/mixed 
tuples. The latter are not so important to distinguish, but 
type tuples have the privilege of being able to declare an 
expression tuple:


TypeTuple!(int, string) myExpressionTuple;
myExpressionTuple[0] = 42;
myExpressionTuple[1] = foo;
// etc



One extra source of confusion is that expression tuple was 
often used for TypeTuple!(42, foo) ones, not for runtime 
instances. Those two are very different in D. That is why I am 
saying one name is not enough and some classification is needed.


Re: Benchmarking a SIMD implementation of dot product

2013-08-22 Thread Wyatt
On Wednesday, 21 August 2013 at 21:11:48 UTC, Andrei Alexandrescu 
wrote:
Loosely related question I've always been curious about: are 
there people who follow this newsgroup but not the announce 
group?


Hi there. I assumed announce was for...well, announcements.  
Like official releases and such.  Looking, I'm even sort of 
correct.


Incidentally, it may be kind of cool to aggregate release 
announcements of various D-related tools into a sidebar of the 
Downloads  Tools page or similar.


-Wyatt


Re: DQuick a GUI Library (prototype)

2013-08-22 Thread Flamaros
On Thursday, 22 August 2013 at 13:29:10 UTC, Andrej Mitrovic 
wrote:

On 8/22/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:

It doesn't seem to support OSX, Unicode, cascading menus:

http://www.tecgraf.puc-rio.br/iup/en/to_do.html

But otherwise I agree starting from scratch is really 
difficult.


Plus it seems to flicker on resize. It's not looking good.


Yep, it's a known issue. I don't know why the resize event of 
window come so late, it seems to be a SDL issue. I began a direct 
win32 implementation, but their is no display for the moment, 
something seems to be wrong with the opengl context.


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

2013-08-22 Thread Jakob Ovrum

On Thursday, 22 August 2013 at 13:43:47 UTC, Dicebot wrote:
One extra source of confusion is that expression tuple was 
often used for TypeTuple!(42, foo) ones, not for runtime 
instances. Those two are very different in D. That is why I am 
saying one name is not enough and some classification is needed.


They are one and the same.


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

2013-08-22 Thread Dicebot

On Thursday, 22 August 2013 at 13:46:12 UTC, Jakob Ovrum wrote:

On Thursday, 22 August 2013 at 13:43:47 UTC, Dicebot wrote:
One extra source of confusion is that expression tuple was 
often used for TypeTuple!(42, foo) ones, not for runtime 
instances. Those two are very different in D. That is why I am 
saying one name is not enough and some classification is 
needed.


They are one and the same.


Almost, but not completely. They share implementation and much of 
observable behavior (and former can be used to initialize latter) 
but one is mutable run-time entity and other - compile-time (and 
thus, of course, constant). As they don't have proper 
representation in the type system, it makes them quite different.


Re: Benchmarking a SIMD implementation of dot product

2013-08-22 Thread Manu
On 22 August 2013 17:24, Jacob Carlborg d...@me.com wrote:

 On 2013-08-22 02:24, Manu wrote:

 Me...


 I guess it's time you start :)


Surely there's nothing interesting there that doesn't end up here anyway? ;)


Re: Download page needs a tidy up

2013-08-22 Thread Manu
On 22 August 2013 17:33, Jacob Carlborg d...@me.com wrote:

 On 2013-08-22 05:33, Manu wrote:

  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.


 The architecture are basically never mentioned for Mac OS X downloads.
 Because everyone assumes universal binaries that will work everywhere.


... what?
Isn't that what I just said?
Did you actually look at Brad's page upgrade?


Re: Download page needs a tidy up

2013-08-22 Thread Manu
On 22 August 2013 17:32, Jacob Carlborg d...@me.com wrote:

 On 2013-08-22 05:07, Manu wrote:

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


 I don't know if they were recently added but they are below the GDC
 binaries.


Can't see any. I can only see binaries for platforms that nobody uses ;)


Re: Thoughts on possible tuple semantics

2013-08-22 Thread Dicebot

On Thursday, 22 August 2013 at 13:01:51 UTC, deadalnix wrote:
It is a sequence of types. It can be used to declare a sequence 
of variables.


That implies defining sequence of X as special entity on 
official spec and update 'alias', 'typeof' and template docs to 
reference it as a special case.


In my proposal, tuple are a library construct. The proposal 
introduce the necessary tooling to implement them nicely.


is(typeof(42, 42) == (int, int));
is(typeof(tuple(42, 42)) == a library defined struct);

It could be defined as follow :

struct Tuple(T...) {
T expand;
alias expand this;
}


It is exactly what we have right now. So you think having two 
different types of expression/value tuples is fine?


Also you don't seem to cover mixed sequences which are 
essential to D templates.


Theses are alias sequences.


As I have already said, it is no less confusing to classify as 
alias sequence something that is not limited to aliases.


Re: Possible solution to template bloat problem?

2013-08-22 Thread eles

On Thursday, 22 August 2013 at 12:11:29 UTC, Ramon wrote:

On Thursday, 22 August 2013 at 09:10:33 UTC, Regan Heath wrote:
On Wed, 21 Aug 2013 02:46:33 +0100, Ramon s...@thanks.no 
wrote:



On Tuesday, 20 August 2013 at 22:58:24 UTC, John Colvin wrote:

On Tuesday, 20 August 2013 at 22:49:40 UTC, Ramon wrote:


Look, is not about alphas, crowds and so on. It is a simple 
misunderstanding that escalated.


Let's end this trouble. There is a lot of work that awaits to be 
done.


std.logger

2013-08-22 Thread Robert Schadek
I'm still missing a logging facility in D and as the last attempt seam
to have stopped I want to throw
in my version. After reading through the std.log thread I made my
conclusions and created my own
logger. People seamed to be unhappy with the naming and the way of
configuration.
Additionally when to throw or not to throw seamed to be an argument.

My attempt is to provide a very small functional interface to logging.
IMO it is impossible to fulfill
all requirements a D developer can have through configuration classes
and such, I designed the
a abstract Logger class that can be easily implemented to one's own needs.

As a quick start feature I created a Stdio- and File-Logger. If no
Logger is provided to the log
function a defaultLogger will be used.

Docu:
http://burner.github.io/phobos/phobos-prerelease/std_logger.html

Pull Request:
https://github.com/D-Programming-Language/phobos/pull/1500


I hope this will lead to some progress in phobos, when it comes to
message logging.


Re: Why I chose D over Ada and Eiffel

2013-08-22 Thread Brian Rogoff

On Thursday, 22 August 2013 at 07:59:56 UTC, qznc wrote:
There are basically two ways to implement generics. Type 
erasure (Java,Haskell) or template instantiation (C++,D). 
Instantiation provides better performance, but sacrifices error 
messages (fixable?), binary code size, and compilation 
modularity (template implementation must be available for 
instantiation). Type safety is not a problem in either approach.


See this brief discussion from Greg Morrisett on the topic, with 
a finer subdivision of approaches


http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt

that confirms your bad news that monomorphization (C++/D 
templates) and separate compilation won't play well together. Nor 
do monomorphization and some advanced type system features work 
together, but that's less of a worry for D.


That said, I like the D approach of putting a lot of power in the 
macro-like template system. I worry more about the reliance on GC 
in a systems programming language, as historically that's been a 
losing proposition.


-- Brian


Re: Range interface for std.serialization

2013-08-22 Thread Tyler Jameson Little

On Thursday, 22 August 2013 at 07:16:11 UTC, Jacob Carlborg wrote:

On 2013-08-22 05:13, Tyler Jameson Little wrote:

I don't like this because it still caches the whole object 
into memory.

In a memory-restricted application, this is unacceptable.


It need to store all serialized reference types, otherwise it 
cannot properly serialize a complete object graph. We don't 
want duplicates. Example:


The following code:

auto bar = new Bar;
bar.a = 3;

auto foo = new Foo;
foo.a = bar;
foo.b = bar;

Is serialized as:

object runtimeType=main.Foo type=main.Foo key=0 id=0
object runtimeType=main.Bar type=main.Bar key=a 
id=1

int key=a id=23/int
/object
reference key=b1/reference
/object

When foo.b is just serializes a reference, not the complete 
object, because that has already been serialized. The 
serializer needs to keep track of that.


Right, but it doesn't need to keep the serialized data in memory.

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...


It seems hard to keep track of nesting. I can't see how pretty 
printing using this technique would work.


Can't you just keep a counter? When you enter anything that would 
increase the indentation level, increment the indentation level. 
When leaving, decrement. At each level, insert whitespace equal 
to indentationLevel * whitespacePerLevel. This seems pretty 
trivial, unless I'm missing something.


Also, I didn't check, but it turns off pretty-printing be 
default, right?



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


How should I set the data used for deserializing?


How about passing it in with a function? Each range passed this 
way would represent a single object, so the current 
deserialize!Foo(InputRange) would work the same way it does now.



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


Again, how does one keep track of nesting in formats like XML, 
JSON and YAML?


YAML will take a little extra care since whitespace is 
significant, but it should work well enough as I've described 
above.


Re: Possible solution to template bloat problem?

2013-08-22 Thread Regan Heath

On Thu, 22 Aug 2013 13:11:28 +0100, Ramon s...@thanks.no wrote:

On Thursday, 22 August 2013 at 09:10:33 UTC, Regan Heath wrote:

On Wed, 21 Aug 2013 02:46:33 +0100, Ramon s...@thanks.no wrote:

Well, where I live to destroy has a pretty clear and very negative  
meaning.
I took that post (of Mr. Alexandrescu) as very rude and condescending  
and I do not intend to change my communication habits so as to  
understand to destroy as a positive statement or even a compliment.


Have you heard the phrase when in Rome...  Seriously, you would  
rather assume a negative meaning/intent even after someone has taken  
the time to explain the intent/usage of the word/phrase in this grand  
forum?


I sense that you may be beyond reasonable advice at this point?
 But, if not..

Always start by assuming good intent, if you're right (and you will be  
90% of the time) no problem.  If you're wrong, well at least you've not  
gotten worked up about it (so they have failed in their goal) and  
chances are it will annoy the abuser even more that you haven't (so  
ultimately, you win).


Communication in written form is fraught with pitfalls, and this thread  
demonstrates how comments can be taken in completely the wrong way.   
Dicebot's I am dangerously close to hating you. was meant in a  
friendly way, /you/ decided not to read it that way.  Likewise Andrei's  
style is abrupt but there are good reasons for this, none of which  
include the goal of offending but /you/ have chosen to read them that  
way.


Sure, more effort could be taken to make it clearer with excess smileys  
etc.  But, that stuff isn't necessary for communicating the content,  
and isn't necessary between established forum members, and isn't  
necessary if everyone just assumes good intent from the outset.


All the best,
Regan



Wow. Now I even get general advice for my life like Always start
by assuming good intent.


.. and have you taken that advice as it was intended?  With good intent?   
Or are you still assuming the worst in people?



How about some honesty?


Who isn't being honest?


It happens to everybody of us. We hadn't any bad intentions but,
alas, someone feels offended, improperly treated, etc.
There is exactly 1 proper reaction for a responsible adult: To
honestly look Did I contribute to that? and if so, to explain
oneself.

It would have cost pretty nothing to Mr. A. to simply say OOps.
Didn't mean any bad. When I say 'destroy' it's actually in
between an invitation to continue hitting with constructive
criticism and a compliment. Weird habit of mine. Not even a
sorry would be needed.


The issue is that you've got this totally backwards.

In some countries people carry bodily fluids around in a small square of  
cloth in their pockets, in others they blow them straight onto the side  
walk.  If one is the norm and you're offended by it does someone owe you  
an apology?


Here, on this forum, destroy has a well known meaning which is the  
norm.  If someone uses it, and you are offended, do they owe you an  
apology?


The answer in both case, IMO, is no.

snip

I can't think of anything constructive to say in response to the rest of  
that, except that you seem to have a very different view of this community  
than I do...


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/


Re: Thoughts on possible tuple semantics

2013-08-22 Thread deadalnix

On Thursday, 22 August 2013 at 14:03:13 UTC, Dicebot wrote:
It is exactly what we have right now. So you think having two 
different types of expression/value tuples is fine?




One is a tuple, the other is a sequence. They are different beast 
and have different behavior.


The fact that it is similar to what we have now is on purpose, so 
we don't need to break a lot of code. Plus, with the proposed 
addition, it allow for nice library tuples.


Also you don't seem to cover mixed sequences which are 
essential to D templates.


Theses are alias sequences.


As I have already said, it is no less confusing to classify as 
alias sequence something that is not limited to aliases.


It is what alias parameter for templates are. Simply keeping the 
terminology here.


Re: Possible solution to template bloat problem?

2013-08-22 Thread Dicebot
Human language rarely has any clear and well-defined meanings. 
Without cultural context it is almost nothing. Actually, in fact 
people almost never understand each other, they always operate 
within some amount of false assumptions.


In that regard, Andrei, who has been using well-established 
communication protocol understood by most part of this community 
was most honest and reasonable in expressing his intentions. 
Failure to understand that is always your failure as proper 
communication is always defined by community and never by beliefs 
of some people.


Scorning from my side is not because of opinions you express or 
technical goals you find important. It is because of sermon 
flavor that overwhelms all your comments. No reasonable man can 
think his beliefs and/or habits are any exceptional. Denying this 
and refusing to properly study domain you oppose is quite 
reliable indicator of ignorance or trolling. Probably both and I 
shouldn't really care about the difference.


I must admit I am quite fast to lose my temper and tend to 
overreact sometimes. However, it makes me sad to see that D 
community falls into completely opposite extreme - wasting time 
and efforts in useless attempts to satisfy people who are simply 
mocking it, whenever form it may take.


Re: Thoughts on possible tuple semantics

2013-08-22 Thread Regan Heath

On Thu, 22 Aug 2013 15:03:12 +0100, Dicebot pub...@dicebot.lv wrote:
Also you don't seem to cover mixed sequences which are essential to D  
templates.


Theses are alias sequences.


As I have already said, it is no less confusing to classify as alias  
sequence something that is not limited to aliases.


I was thinking of it the other way round, as in .. It is not a sequence of  
aliases, but an alias for a sequence of .. expressions(?).  Perhaps  
calling it an aliased sequence makes that clearer?


R

--
Using Opera's revolutionary email client: http://www.opera.com/mail/


Re: windows .lib files (dmc has them, dmd doesn't)

2013-08-22 Thread Adam D. Ruppe

So, what's the plan here?


Re: Thoughts on possible tuple semantics

2013-08-22 Thread Dicebot

On Thursday, 22 August 2013 at 14:22:50 UTC, deadalnix wrote:
One is a tuple, the other is a sequence. They are different 
beast and have different behavior.


The fact that it is similar to what we have now is on purpose, 
so we don't need to break a lot of code. Plus, with the 
proposed addition, it allow for nice library tuples.


I am confused. You proposed tuple implementation is essentially 
the very same current std.typecons.Tuple is. So I can see only 
two differences between value sequence and tuple:


1) latter has address and ABI
2) former auto-expands

Anything else?


Theses are alias sequences.


As I have already said, it is no less confusing to classify as 
alias sequence something that is not limited to aliases.


It is what alias parameter for templates are. Simply keeping 
the terminology here.


Wait, what? Alias parameters for templates have nothing to do 
with template argument lists (other than being one possible type 
of that list element). In other words, T... can contain more 
stuff than alias T... (imaginary syntax).


And, considering the fact that we already have two different 
alias semantics (for template alias parameters and normal 
aliases), it is a dangerous terminology to chose anyway.


Re: Thoughts on possible tuple semantics

2013-08-22 Thread deadalnix

On Thursday, 22 August 2013 at 14:32:27 UTC, Dicebot wrote:
Well, it falls into the same issue named after what you can do 
with it vs named after what it is. The very meaning of word 
alias suggests that calling something alias for X is just 
adding naming indirection on top of X ;)


That is what an alias parameter is, and I do think that regular 
alias and alias parameter should converge.


Re: Thoughts on possible tuple semantics

2013-08-22 Thread deadalnix

On Thursday, 22 August 2013 at 14:29:50 UTC, Dicebot wrote:
Wait, what? Alias parameters for templates have nothing to do 
with template argument lists (other than being one possible 
type of that list element). In other words, T... can contain 
more stuff than alias T... (imaginary syntax).




other than being one possible type of that list element

Indeed it is the only possible meaning and it the right one.

And, considering the fact that we already have two different 
alias semantics (for template alias parameters and normal 
aliases), it is a dangerous terminology to chose anyway.


Yes, the term have 2 meanings. I simply reuse one of theses 
meaning without adding a new one.


Re: Thoughts on possible tuple semantics

2013-08-22 Thread Dicebot

On Thursday, 22 August 2013 at 14:27:01 UTC, Regan Heath wrote:
On Thu, 22 Aug 2013 15:03:12 +0100, Dicebot pub...@dicebot.lv 
wrote:
Also you don't seem to cover mixed sequences which are 
essential to D templates.


Theses are alias sequences.


As I have already said, it is no less confusing to classify as 
alias sequence something that is not limited to aliases.


I was thinking of it the other way round, as in .. It is not a 
sequence of aliases, but an alias for a sequence of .. 
expressions(?).  Perhaps calling it an aliased sequence makes 
that clearer?


R


Well, it falls into the same issue named after what you can do 
with it vs named after what it is. The very meaning of word 
alias suggests that calling something alias for X is just 
adding naming indirection on top of X ;)


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

2013-08-22 Thread Jakob Ovrum

On Thursday, 22 August 2013 at 13:53:45 UTC, Dicebot wrote:
Almost, but not completely. They share implementation and much 
of observable behavior (and former can be used to initialize 
latter) but one is mutable run-time entity and other - 
compile-time (and thus, of course, constant). As they don't 
have proper representation in the type system, it makes them 
quite different.


I don't think it's correct or useful to label one as compile-time 
and the other as runtime. I think the mutability or immutability 
of the expression tuple is an obvious result of its lvalue-ish or 
rvalue-ish nature, respectively. As such - with the current 
semantics - I'm not sure it's important to be able to easily 
distinguish the two. I'd be happy to be convinced otherwise if 
you think it's important.


Re: Why I chose D over Ada and Eiffel

2013-08-22 Thread Dicebot

On Thursday, 22 August 2013 at 14:18:09 UTC, Brian Rogoff wrote:
See this brief discussion from Greg Morrisett on the topic, 
with a finer subdivision of approaches


http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt

that confirms your bad news that monomorphization (C++/D 
templates) and separate compilation won't play well together. 
Nor do monomorphization and some advanced type system features 
work together, but that's less of a worry for D.


Well, in that paper they make a bit too hard statement - such 
model implies certain limitations for separate compilations 
(either explicit instantiation or having access to sources) but 
does not destroy completely. No silver bullet here, every 
approach has its own pros and cons.


As have been discussed recently, ancient object file / linker 
tool stack harms it much more when comes to practice.


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

2013-08-22 Thread deadalnix

On Thursday, 22 August 2013 at 13:43:47 UTC, Dicebot wrote:

On Thursday, 22 August 2013 at 13:39:25 UTC, Jakob Ovrum wrote:
I'm fine with any name but would like to point out that it's 
probably essential that the new name allows for the 
distinction between what we currently call type tuples and 
expression/mixed tuples. The latter are not so important to 
distinguish, but type tuples have the privilege of being able 
to declare an expression tuple:


   TypeTuple!(int, string) myExpressionTuple;
   myExpressionTuple[0] = 42;
   myExpressionTuple[1] = foo;
   // etc



One extra source of confusion is that expression tuple was 
often used for TypeTuple!(42, foo) ones, not for runtime 
instances. Those two are very different in D. That is why I am 
saying one name is not enough and some classification is needed.


That is in the doc : A Tuple whose elements consist entirely of 
types is called a TypeTuple. A Tuple whose elements consist 
entirely of expressions is called an ExpressionTuple. 


http://dlang.org/template.html#TemplateTupleParameter


Re: Range interface for std.serialization

2013-08-22 Thread Dicebot
On Thursday, 22 August 2013 at 03:13:46 UTC, Tyler Jameson Little 
wrote:

On Wednesday, 21 August 2013 at 20:21:49 UTC, Dicebot wrote:
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.


Well, in memory-restricted applications having large object at 
all is unacceptable. Rationale is that you hardly ever want 
half-deserialized object. If environment is very restrictive, 
smaller objects will be used anyway (list of smaller objects).



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


Outputting on its own is not useful to discuss - in pipe model 
output matches input. What is the point in outputting partial 
chunks of serialized object if you still need to provide it as a 
whole to the input?


Re: Benchmarking a SIMD implementation of dot product

2013-08-22 Thread Iain Buclaw
On 22 August 2013 15:59, Manu turkey...@gmail.com wrote:
 On 22 August 2013 17:24, Jacob Carlborg d...@me.com wrote:

 On 2013-08-22 02:24, Manu wrote:

 Me...


 I guess it's time you start :)


 Surely there's nothing interesting there that doesn't end up here anyway? ;)

I never announcement anything in here at least. ;-)

-- 
Iain Buclaw

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


Re: Range interface for std.serialization

2013-08-22 Thread Dicebot

I'll focus on part I find crucial:

On Thursday, 22 August 2013 at 07:08:28 UTC, Jacob Carlborg wrote:
The question is if a range should be treated as multiple 
objects, and not a single object (which it really is). How 
should it be serialized?


* Something like an array, resulting in this XML:

array type=int length=5 key=0 id=0
int key=0 id=11/int
int key=1 id=22/int
int key=2 id=33/int
int key=3 id=44/int
int key=4 id=55/int
/array

* Or like calling serialize multiple times, resulting in this 
XML:


int key=0 id=01/int
int key=1 id=12/int
int key=2 id=23/int
int key=3 id=34/int
int key=4 id=45/int


Is there a reasons arrays needs to be serialized as (1), not (2)? 
I'd expect any input-range compliant data to be serialized as (2) 
and lazy. That allows you to use deserializer as a pipe over some 
sort of network-based string feed to get a potentially infinite 
input range of deserialized objects.


Re: Range interface for std.serialization

2013-08-22 Thread John Colvin

On Thursday, 22 August 2013 at 14:48:57 UTC, Dicebot wrote:
Outputting on its own is not useful to discuss - in pipe model 
output matches input. What is the point in outputting partial 
chunks of serialized object if you still need to provide it as 
a whole to the input?


Partial chunks of serialized objects can be useful for 
applications that aren't immediately deserializing: E.g. sending 
over a network, storing to disk etc.


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

2013-08-22 Thread Dicebot

On Thursday, 22 August 2013 at 14:39:59 UTC, Jakob Ovrum wrote:
I don't think it's correct or useful to label one as 
compile-time and the other as runtime. I think the mutability 
or immutability of the expression tuple is an obvious result of 
its lvalue-ish or rvalue-ish nature, respectively. As such - 
with the current semantics - I'm not sure it's important to be 
able to easily distinguish the two. I'd be happy to be 
convinced otherwise if you think it's important.


I don't know either :) I am just trying to find some order in 
existing scheme. What frustrates me most in expression sequences 
being both runtime and compile-time is that compile-time still 
can act as if they are almost types:


alias a = TypeTuple!(1, 2); // ok
auto  b = TypeTuple!(1, 2); // also ok!

Isn't it the only entity in the whole language that can be used 
in type context (alias) and value context (initializer) at the 
same time?


Re: DQuick a GUI Library (prototype)

2013-08-22 Thread Andrej Mitrovic
On 8/22/13, Flamaros flamaros.xav...@gmail.com wrote:
 Yep, it's a known issue. I don't know why the resize event of
 window come so late, it seems to be a SDL issue. I began a direct
 win32 implementation, but their is no display for the moment,
 something seems to be wrong with the opengl context.

I was referring to the IUP library though, not your library. As for
flicker, this is usually handled by returning 1 for the WM_ERASEBKGND
message.

The IUP flicker I saw was in its hbox example, which had buttons in a
layout (horizontal box), and as the buttons moved when you resize the
window they would flicker. Maybe they should try using a backbuffer if
they don't already do. But anyway, I don't know IUP internals to know
what is going wrong.


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

2013-08-22 Thread Dicebot

On Thursday, 22 August 2013 at 15:01:23 UTC, Meta wrote:
One question, wasn't the fact that template Test(T...) can 
accept literals as well as types originally a bug? Or am I 
thinking of template Test(alias T)?


Well it is necessity that comes from the fact that it denotes 
variadic template argument list. If this is legal (and it is):


template Test(int N, T) { }

than variadic list must accept both too.


  1   2   3   >