date:20130512


On 2013-05-12 18:35, Juan Manuel Cabo wrote:


I'm using a little known IDE for D known as Poseidon:
 http://www.dsource.org/projects/poseidon/wiki/Screenshots
it is very fast, loads very quickly, and the editor is very responsive.
The keyword autocompletion is mostly broken in D2 but I can live without
it. It is a bit sad that it has gone unmantained for more than a year.

These are the things that I cannot live without for my big D2 project:
 - Syntax highlighting.
 - Tree like structure for navigating all the many source files of
my project.
 - Search in multiple files.
 - Debugging (breakpoints, step by step, go to line that crashed).
It suprisingly still works in Poseidon.
 - Can go to file/line when double-clicking on compiler error.
 - Compile/run/debug just by hitting SHIFT-F5, and other keys.
 - No need for a makefile. It feeds all source files (hundreds) and
libraries to dmd.


I can do that with TextMate, except the debugging.

--
/Jacob Carlborg

Re: DConf 2013 keynote


On 2013-05-12 21:31, Nick Sabalausky wrote:


Looks interesting. Now that you mention it, I do seem to recall hearing
about it back then. Personally, I've been a huge fan of Programmer's
Notepad 2 . My #1 complaint about it though
is that it's Windows-only. I want to switch to Linux for my primary
system, but the lack of PN2 is one of the roadblocks (there are other
roadblocks, though).


Take a look at Sublime Text. It's ridicules fast and cross platform. The 
only problem is that it's not free. You can download it for free and 
dismiss a dialog popping up once in a while.


http://www.sublimetext.com/


But these days I prefer RDMD-style approaches ("pass the one main
source file to a cmdline tool and it figures out the rest") because
they're trivially scriptable and don't cause a specific editor (or any
editor at all) to become a build requirement. I find that especially
important for OSS and cross-platform projects.


The problem here is when you need to use a couple of compiler switches. 
You need a file to put that in, usually a shell script. Unfortunately 
that doesn't work on Windows. So you need to duplicate that file for 
Windows.


--
/Jacob Carlborg

Re: rename our github organization?


On 2013-05-12 17:08, Andrei Alexandrescu wrote:

I'm thinking we should rename D-programming-language on github with
dlang. While we're at it, project d-programming-language.org should be
renamed dlang.org.

This may cause disruption. Thoughts?


This will break all the URL's for the repository. It's not just the need 
to change the git configuration for all developers, tools my also depend 
on this. I have a tool, DVM, that depends on this. But since Github 
downloads are deprecated/removed it doesn't matter in my case.


--
/Jacob Carlborg

Re: DConf 2013 Day 1 Talk 2 (Copy and Move Semantics)


On 5/12/2013 11:11 PM, Dmitry Olshansky wrote:

In the long run I'd prefer the second and exact formal rules and if they are too
hard to explain we'd better not do it at all.



I agree that formal rules are better. I'm working on it.

Re: DConf 2013 Day 1 Talk 2 (Copy and Move Semantics)


13-May-2013 02:47, Walter Bright пишет:

On 5/12/2013 1:48 PM, Dmitry Olshansky wrote:

13-May-2013 00:28, Walter Bright пишет:

On 5/12/2013 6:01 AM, Andrei Alexandrescu wrote:

Bartosz, Walter and I reached a similar design a few years ago. We
just thought
it complicates things too much for what it does.


I've been working in the background on a scheme that can infer
uniqueness. The beauty of it is it will not require visible language
changes - it's just that things that didn't compile before now will.


Good things these are, but that adds up to what a programmer should
know or we
are stuck trying out combinations that might work until we hit it.


I think programmers will find it to be intuitive, not magical.



By the end of day we need guarantees not intuition which is the problem.

Compare the statement in the would be standard of D:
"If the compiler can prove that the expression is unique it's implicitly 
convertible to shared/immutable/const."

vs
"The following rules define what kinds of if the expression is unique. 
[...] Unique expression is convertible to shared/immutable/const."


The keyword "the compiler can prove" - it doesn't state anything 
reliable. In the long run I'd prefer the second and exact formal rules 
and if they are too hard to explain we'd better not do it at all.


--
Dmitry Olshansky

Re: Numeric limits tracking

On 13 May 2013 13:46, Walter Bright  wrote:

> On 5/12/2013 6:23 PM, Manu wrote:
>
>> It is done by the optimiser, but I'm suggesting that it doesn't only have
>> value
>> in terms of optimisation. It could improve language usability if
>> performed in
>> the front end.
>>
>
> I understand.
>
>
>  In that context, unless the analysis is very powerful(/mature) and can
>> statically determine 'expr', then x would need to be relaxed to unlimited
>> at
>> that point, since it obviously can't know the limits within (or after)
>> that loop.
>> In this case, the compiler would complain that it can't determine x and
>> you
>> would need an explicit cast as usual.
>>
>> I can see the effective forward reference issue here, which could be
>> addressed
>> in time, but even just reasonably simple limits tracking (ie, within
>> sequential
>> code) would make a massive difference. I think programmers would
>> intuitively
>> understand this situation and wouldn't expect magic from the compiler.
>> The places where it matters the most are places where it's dead obvious
>> what the
>> numeric limits are, and it should be equally obvious to the compiler.
>>
>> It's the sort of thing that could be improved with time, but even a very
>> simple
>> start would be a big help in many cases.
>>
>
> It's true you could do a sequential only, very conservative form of data
> flow analysis.
>
> But be aware there are other problems, such as:
>
>   int *p = ...;
>   ...
>   x &= 0x;
>   ++(*p);  // hmm, is x affected?
>   short s = x;
>

Yes indeed, there are certainly many ways to interfere with it, but I
certainly hope that most lines of code you deal with on a daily basis
aren't like this ;)
Obviously it would grow in maturity over time. In that example, just revert
to unlimited assumptions when it encounters the pointer operation. Limits
may then be refined again in following code.
I can imagine things like proper escaping analysis as planned could
eventually help in cases like this.

Anyway, it's just something to think about. I think it would offer
additional safety/correctness to the language; anywhere you type a blind
cast, you are potentially hiding a future bug. I'd rather never cast when I
don't absolutely need/intend to.

Re: new DIP40: Template parameter deduction for constructors


On Monday, 13 May 2013 at 02:39:22 UTC, timotheecour wrote:

The link:
http://wiki.dlang.org/DIP40
The paper links mentioned in the abstract are given in this DIP.


Not the first time it is mentioned. Definitively a direction we 
want to take.

Re: Numeric limits tracking


On 5/12/2013 6:23 PM, Manu wrote:

It is done by the optimiser, but I'm suggesting that it doesn't only have value
in terms of optimisation. It could improve language usability if performed in
the front end.


I understand.


In that context, unless the analysis is very powerful(/mature) and can
statically determine 'expr', then x would need to be relaxed to unlimited at
that point, since it obviously can't know the limits within (or after) that 
loop.
In this case, the compiler would complain that it can't determine x and you
would need an explicit cast as usual.

I can see the effective forward reference issue here, which could be addressed
in time, but even just reasonably simple limits tracking (ie, within sequential
code) would make a massive difference. I think programmers would intuitively
understand this situation and wouldn't expect magic from the compiler.
The places where it matters the most are places where it's dead obvious what the
numeric limits are, and it should be equally obvious to the compiler.

It's the sort of thing that could be improved with time, but even a very simple
start would be a big help in many cases.


It's true you could do a sequential only, very conservative form of data flow 
analysis.


But be aware there are other problems, such as:

  int *p = ...;
  ...
  x &= 0x;
  ++(*p);  // hmm, is x affected?
  short s = x;

Re: new DIP40: Template parameter deduction for constructors

2013-05-12 Thread timotheecour


The link:
http://wiki.dlang.org/DIP40
The paper links mentioned in the abstract are given in this DIP.

new DIP40: Template parameter deduction for constructors

2013-05-12 Thread Timothee Cour

A proposed feature of C++14 is to introduce template parameter
deduction for constructors, see paper, mentioned here. The idea is to
deduce template parameters when calling a constructor given the
arguments given to the constructor, whenever possible. A compile error
occurs when the deduction is ambiguous. The benefits would be:
* make the code more DRY
* make boilerplate of class instantiators unnecessary in most cases
(they're all over phobos, eg: std.typecons.tuple,
std.typecons.rebindable etc)
* make D more consistent: it deduces template parameters for
functions, so why not for constructors, when this is unambiguous?
* it won't break any code.
Note, just as for deduction of normal functions, it should work with 0
or more template parameters specified (ie the first k>=0 templates may
be provided).

Re: Numeric limits tracking

On 13 May 2013 11:03, Walter Bright  wrote:

> On 5/12/2013 5:00 PM, Manu wrote:
>
>> So, here's an issue that constantly drives me nuts, and an elegant
>> solution
>> seems so do-able.
>>
>
> It's a form of "data flow analysis". This is done by the optimizer,
> although it doesn't track ranges.
>
> It isn't quite as simple as you suggest, there are issues like dealing
> with arbitrary control flow.
>
>
>   x &= 0x;
>   short s = x; // Error! (but we know x is 0 .. 65535)
>
> Ok, but what about:
>
>   x &= 0x;
>   while (expr) {
>   short s = x;
>   x += 1;
>   }
>
> There's a forward reference going on. We cannot semantically evaluate s=x
> until we semantically evaluate the rest of the function in order to know
> that x is or is not reassigned.
>

It is done by the optimiser, but I'm suggesting that it doesn't only have
value in terms of optimisation. It could improve language usability if
performed in the front end.

In that context, unless the analysis is very powerful(/mature) and can
statically determine 'expr', then x would need to be relaxed to unlimited
at that point, since it obviously can't know the limits within (or after)
that loop.
In this case, the compiler would complain that it can't determine x and you
would need an explicit cast as usual.

I can see the effective forward reference issue here, which could be
addressed in time, but even just reasonably simple limits tracking (ie,
within sequential code) would make a massive difference. I think
programmers would intuitively understand this situation and wouldn't expect
magic from the compiler.
The places where it matters the most are places where it's dead obvious
what the numeric limits are, and it should be equally obvious to the
compiler.

It's the sort of thing that could be improved with time, but even a very
simple start would be a big help in many cases.

Re: Numeric limits tracking

2013-05-12 Thread bearophile


Walter Bright:

There's a forward reference going on. We cannot semantically 
evaluate s=x until we semantically evaluate the rest of the 
function in order to know that x is or is not reassigned.


A first step to improve the situation is to propagate the range 
of const/immutable values inside a function:


void main() {
uint x = 1000;
immutable y = x % 256;
ubyte z = y; // currently error.
}

Bye,
bearophile

Re: Numeric limits tracking


On 5/12/2013 5:00 PM, Manu wrote:

So, here's an issue that constantly drives me nuts, and an elegant solution
seems so do-able.


It's a form of "data flow analysis". This is done by the optimizer, although it 
doesn't track ranges.


It isn't quite as simple as you suggest, there are issues like dealing with 
arbitrary control flow.


  x &= 0x;
  short s = x; // Error! (but we know x is 0 .. 65535)

Ok, but what about:

  x &= 0x;
  while (expr) {
  short s = x;
  x += 1;
  }

There's a forward reference going on. We cannot semantically evaluate s=x until 
we semantically evaluate the rest of the function in order to know that x is or 
is not reassigned.

Re: Official D Grammar

2013-05-12 Thread Brian Schott

I wrote a small program to take the grammar and generate input to 
the dot program from Graphviz. You can generate the diagrams with 
some scripts available on Github or view a prebuilt version here:


http://hackerpilot.org/d/dgrammar.zip

Please take a look at this and let me know if you find any 
mistakes.

Re: Numeric limits tracking

It is, but there are limits to what it can do.
D's contracts potentially offer a lot of information that the optimiser
wouldn't naturally have (any function receiving blind arguments can't make
any assumptions without a contract present), but more from a
usability/safety point of view, I really hate casting when the compiler
should know the assignment is safe.

It's not only an inconvenience, it's also a safety thing.
Consider:
I have an int that I assign to a byte, I know the value fits in a byte, but
I'm forced to type the manual cast anyway.
Once that cast is written, if the valid range of my int happens to change
in outer code, I will not receive an error informing me that the new range
doesn't fit within a byte anymore, it'll just truncate it anyway, since a
blind cast is already there in the code.
It would be much better for the compiler to start complaining that it can
no longer assure that the int fits into the byte. With the cast present, my
bug has been hidden until I eventually crash.

On 13 May 2013 10:18, John Colvin  wrote:

> On Monday, 13 May 2013 at 00:00:54 UTC, Manu wrote:
>
>> So, here's an issue that constantly drives me nuts, and an elegant
>> solution
>> seems so do-able.
>>
>> void func(int x)
>> {
>>   x &= 0x;
>>   short s = x; // Error! (but we know x is 0 .. 65535)
>>
>>   if(x < 256)
>>   {
>> byte b = x; // Error! (we also know x is 0 .. 255)
>>   }
>> }
>>
>> It would be really nice if the compiler would carry around the known
>> possible range of values, and refer to that information when performing
>> down-casting assignments.
>> It would also be very useful information for the back end, it can choose
>> more efficient types if it knows the range, or produce jump tables rather
>> than branch sequences.
>>
>> I think the compiler would need a min, max, and mask for any integers, and
>> update them as it works.
>>
>> There are many sources of this information.
>> Comparisons effectively limit the range:
>> if(x > 0)
>> {
>>   // x = 0 .. int.max
>> }
>> else
>> {
>>   // x = int.min .. -1
>> }
>>
>> Masks, obviously:
>> x &= 15;
>>
>> Also contracts are a really great source of seeding this information on
>> function entry.
>>
>> Has this been discussed? It seems simple, and it's invisible to the
>> language. It would just reduce some boilerplate (tedious casts), and also
>> offer some great optimisation opportunities.
>>
>
> I've been thinking about this for a while from an optimisation point of
> view. Is this not a common practice for an optimising compiler?
>

Re: Numeric limits tracking

2013-05-12 Thread John Colvin


On Monday, 13 May 2013 at 00:00:54 UTC, Manu wrote:
So, here's an issue that constantly drives me nuts, and an 
elegant solution

seems so do-able.

void func(int x)
{
  x &= 0x;
  short s = x; // Error! (but we know x is 0 .. 65535)

  if(x < 256)
  {
byte b = x; // Error! (we also know x is 0 .. 255)
  }
}

It would be really nice if the compiler would carry around the 
known
possible range of values, and refer to that information when 
performing

down-casting assignments.
It would also be very useful information for the back end, it 
can choose
more efficient types if it knows the range, or produce jump 
tables rather

than branch sequences.

I think the compiler would need a min, max, and mask for any 
integers, and

update them as it works.

There are many sources of this information.
Comparisons effectively limit the range:
if(x > 0)
{
  // x = 0 .. int.max
}
else
{
  // x = int.min .. -1
}

Masks, obviously:
x &= 15;

Also contracts are a really great source of seeding this 
information on

function entry.

Has this been discussed? It seems simple, and it's invisible to 
the
language. It would just reduce some boilerplate (tedious 
casts), and also

offer some great optimisation opportunities.


I've been thinking about this for a while from an optimisation 
point of view. Is this not a common practice for an optimising 
compiler?

Numeric limits tracking

So, here's an issue that constantly drives me nuts, and an elegant solution
seems so do-able.

void func(int x)
{
  x &= 0x;
  short s = x; // Error! (but we know x is 0 .. 65535)

  if(x < 256)
  {
byte b = x; // Error! (we also know x is 0 .. 255)
  }
}

It would be really nice if the compiler would carry around the known
possible range of values, and refer to that information when performing
down-casting assignments.
It would also be very useful information for the back end, it can choose
more efficient types if it knows the range, or produce jump tables rather
than branch sequences.

I think the compiler would need a min, max, and mask for any integers, and
update them as it works.

There are many sources of this information.
Comparisons effectively limit the range:
if(x > 0)
{
  // x = 0 .. int.max
}
else
{
  // x = int.min .. -1
}

Masks, obviously:
x &= 15;

Also contracts are a really great source of seeding this information on
function entry.

Has this been discussed? It seems simple, and it's invisible to the
language. It would just reduce some boilerplate (tedious casts), and also
offer some great optimisation opportunities.

Re: new DIP39: Safe rvalue references: backwards compatible, safe against ref/nonref code evolution, compatible with UFCS and DIP38

2013-05-12 Thread timotheecour

OK, First remark on the way the DIP is presented. You start 
right away with example which make it hard to understand o 
general big picture.


I've clarified differences with the rejected DIP36 in the 
abstract and added more context.


Second, ^ is not unused in D and the DIP introduce an ambiguity 
here.


Indeed, it's used in XOR; I've clarified this point. It should 
still be unambiguous as XOR is binary.


Making the temporary creation explicit is an idea that hasn't 
been explored that much. I have to think more about it.


Could you point out to any potential pitfalls, when used as 
described in section 'Implementation details' ?



I've also incorporated a useful suggestion from Dmitry S, which 
is to allow LV^ to create a temporary from an lvalue reference, 
as oppose to result in compile error in that case, see the 
updated DIP.

Re: DConf 2013 Day 1 Talk 2 (Copy and Move Semantics)


On 5/12/2013 1:48 PM, Dmitry Olshansky wrote:

13-May-2013 00:28, Walter Bright пишет:

On 5/12/2013 6:01 AM, Andrei Alexandrescu wrote:

Bartosz, Walter and I reached a similar design a few years ago. We
just thought
it complicates things too much for what it does.


I've been working in the background on a scheme that can infer
uniqueness. The beauty of it is it will not require visible language
changes - it's just that things that didn't compile before now will.


Good things these are, but that adds up to what a programmer should know or we
are stuck trying out combinations that might work until we hit it.


I think programmers will find it to be intuitive, not magical.

RFC: mysql-native - Supporting both Vibe.d and Phobos sockets

There is need for mysql-native
to support both
Vibe.d's sockets and Phobos sockets.

First, a little background (feel free to skip ahead if you wish):

Steve Teale's original version of mysql-native only supported Phobos's
sockets (there was no Vibe.d at the time). But all activity and
maintenance since then has been on a fork that *replaces* use of
Phobos's sockets with Vibe.d's sockets. Vibe.d uses its own socket
implementation instead of Phobos's because (AIUI) Phobos sockets don't
support the particular Async I/O model that's a cornerstone of Vibe.d.

There are people, including myself, who have need to use mysql-native
together with Vibe.d. But naturally, there's also very valid reasons
why mysql-native should also be usable with nothing more than Phobos,
in projects that choose not to rely on Vibe.d.
(End of background)

So, there's a need for mysql-native to support *both* Vibe.d and
Phobos-only, and I've already created a branch which does exactly that:

https://github.com/Abscissa/mysql-native/blob/optional-phobos-sockets/source/mysql/connection.d

You can use that with either type of socket, even switch between them
at runtime (although not within the same connection, obviously). And
you can also use an optional "-verson=" to completely eliminate any
compile-time dependency on Vibe.d (which naturally disables the ability
to use Vibe.d sockets, of course).

I've tested it on both types of sockets with mysql-native's included
test app ('source/app.d'), and it all works for me.

I *could* push that to the main mysql-native master repo right now
. But I'm hesitant
for one reason:

Since Phobos's and Vibe.d's sockets have incompatible APIs, my design
converts most of the types in mysql-native into templates. For example,
'Connection' becomes either 'Connection!mySQLSocketVibeD' or
'Connection!mySQLSocketPhobos'. The type 'Command' becomes either
'Command!mySQLSocketVibeD' or 'Connection!mySQLSocketPhobos'. And the
same goes for most other types, such as Row, ResultSet, etc.

That is the only breaking change, but depending how your code uses
mysql-native, it can be a very significant breaking change.

So before merging that, I wanted to get input from anyone else who has
used or contributed to either mysql-native or HibernateD
which currently uses a
Phobos-only fork of mysql-native for its MySQL capability (which is
actually my main original motivating factor for making these changes).

Couple alternatives I've considered:

- I considered templating the types on an actual socket type instead of
on "enum MySQLSocketType { phobos, vibed }", but I can't imagine a
need for any other socket type being likely to arise. And even if it
did, mysql-native would likely still need special-handling for it
anyway.

- The *ideal* solution would be for Phobos and Vibe.d to agree on a
common interface, defined in Phobos, and inherit their socket classes
from that interface. The reasons I didn't go this route are because
1) I don't know enough about the background/internals/motiovations of
either of the socket types to be the right person to spearhead this.
and 2) Such a change in Phobos would likely require a lot of time and
effort whereas my primary interest is to take mysql-native and just
*make it work* on both Phobos and Vibe.d.

If the appropriate people on both the Phobos and Vibe.d sides wanted to
spearhead an effort to make the respective sockets compatible, and
fast-track it all, then I'd be happy to make mysql-native just use
that. But I realize priorities might be elsewhere right now, and that's
perfectly fine. I figure we can just "make it work" with both types of
sockets right now (as I've already done, albeit in an unofficial
branch), and if/when a merged socket design emerges, then mysql-native
can just keep one option and deprecate the other.

Thoughts? Opinions? Etc?

Re: DConf 2013 Day 1 Talk 2 (Copy and Move Semantics)


13-May-2013 00:28, Walter Bright пишет:

On 5/12/2013 6:01 AM, Andrei Alexandrescu wrote:

Bartosz, Walter and I reached a similar design a few years ago. We
just thought
it complicates things too much for what it does.


I've been working in the background on a scheme that can infer
uniqueness. The beauty of it is it will not require visible language
changes - it's just that things that didn't compile before now will.


Good things these are, but that adds up to what a programmer should know 
or we are stuck trying out combinations that might work until we hit it.



--
Dmitry Olshansky

Re: DConf 2013 Day 1 Talk 2 (Copy and Move Semantics)


On 5/12/2013 6:01 AM, Andrei Alexandrescu wrote:

Bartosz, Walter and I reached a similar design a few years ago. We just thought
it complicates things too much for what it does.


I've been working in the background on a scheme that can infer uniqueness. The 
beauty of it is it will not require visible language changes - it's just that 
things that didn't compile before now will. It won't solve all the problems, but 
I'm hoping it'll solve enough that the rest will not be more than a minor annoyance.


For a trivial example,

shared p = new int;

would work, as 'new int' would be inferred to be unique, and a unique pointer 
can be implicitly cast to immutable or shared. This plays to D's strength with 
function purity, transitive const/immutable/shared, attribute inference, etc.

Re: Formal Review of std.uni


28-Apr-2013 20:56, Jesse Phillips пишет:

This is a replacement module for the current std.uni by Dmitry
Olshansky. The std.uni module provides an implementation of fundamental
Unicode algorithms and data structures.

To use this module, install 2.63 beta, import uni; and not std.uni,
compile two files from the source uni.d unicode_tables.d

Docs:
http://blackwhale.github.io/phobos/uni.html

Source:
https://github.com/blackwhale/gsoc-bench-2012

DMD Beta:
http://forum.dlang.org/post/517c8552.7040...@digitalmars.com

It should be noted that inclusion into Phobos may require addressing
inter-dependencies, see "Reducing the inter-dependencies"
http://forum.dlang.org/post/kl8hn8$bm3$1...@digitalmars.com


We have only one week for review left so I'd like to sort out the last 
issues before we get to the voting.


First to fill in on latest developments.
With a bunch of ugly hacks I've managed to integrate new std.uni in my 
Phobos fork and it passes unittests for me now (on win32 at least).


See it hanging there and waiting to be destroyed by the pull tester:
https://github.com/D-Programming-Language/phobos/pull/1289

Remaining issues that I'm aware of:
- proper toLower/toUpper (current one is simplified codepoint-for-codepoint)
- clean up the debris after crush-landing back into Phobos, revert some 
unrelated changes etc.


Please take time to make that list grow, esp w.r.t interface choices and 
the code itself.


Plus separately I'd need to remove rudimentary versions of the same 
data-structures used in std.regex and rewire it to use the new std.uni.


There are few bugs and issues uncovered during integration that I wish 
to get feedback on.


std.string has a bogus test for toLower:
Of the very few tests being done 2 are very special corner case around 
\u0130 which is I with dot and is expected to be lowercased to i.
But it's *not* supposed to - this conversion is specific to Turk(?) 
locale (=tailoring). What should happen is unfolding it to 2-codepoint 
sequence 'i' and 'dot-above' (this is in works).


I just hope nobody depends on these particular conversions and I am 
wondering who's put them there in the first place.


std.json is another thing - 0x7F somehow is specifically tested as being 
accepted as part of string literal. Yet ECMA script docs clearly state 
that Unicode control characters are to be stripped even before lexing 
(ignored even in literals).


P.S. Someday I need to track down and file about 2 (or 3?) distinct 
compiler bugs (fwd-ref hell, private alias hijacking) that I worked 
around while getting there.

Another one has a fix already (thanks, Kenji):
http://d.puremagic.com/issues/show_bug.cgi?id=10067

--
Dmitry Olshansky

Re: DConf 2013 keynote

2013-05-12 Thread Jeff Nowakowski


On 05/12/2013 02:08 PM, Walter Bright wrote:

On 5/12/2013 9:42 AM, Jeff Nowakowski wrote:

Second, in the Q&A session of your talk, you said, "I'm sorely tempted
to say
that real men don't use IDEs..."


Yes, but I said that as a joke.


It was said jokingly, but I have very little doubt it conveyed your true 
feelings. You have a history of brushing off concerns about IDEs by 
relying on a remark from David B. Held that Java needs an IDE to 
generate boilerplate, which I will say to the contrary is one of the 
lower priority reasons of why I find IDEs so useful for Java.


Do you use an IDE? Have you even tried one in the past 10 years?


No, the sentiment was that an IDE was not the solution to a language's
deficiencies.


That's fine, but when somebody asks you about D support for IDEs, 
"joking" about "real men" not needing one doesn't inspire confidence you 
actually understand the value. Maybe in your next keynote you can talk 
about how D has first-class support for IDEs, much like you did for unit 
tests.


One way to get first-class support is to make the compiler amenable to 
being used as a library, something that's been suggested before. I'd be 
happy to be told I'm out of date, and this support is already in the 
works or at least on the radar.

Re: Migrating D front end to D - post Dconf

2013-05-12 Thread Daniel Murphy

"Walter Bright"  wrote in message 
news:kmnk08$3qr$1...@digitalmars.com...
> On 5/11/2013 10:25 PM, Daniel Murphy wrote:
>> My thought was that you ensure (for the foreseeable future) that all D
>> versions of the compiler compile with the most recent C++ version of the
>> compiler.
>
> That would likely mean the the D compiler sources must be compilable with 
> 2.063.
>

Yes.  And anybody with a C++ compiler can build the latest release.

Re: DConf 2013 keynote

On Sun, 12 May 2013 14:16:18 +0200
Timon Gehr  wrote:

> On 05/12/2013 05:59 AM, Nick Sabalausky wrote:
> > On Fri, 10 May 2013 19:04:31 -0400
> > "Jonathan M Davis"  wrote:
> >
> >> On Friday, May 10, 2013 14:31:00 H. S. Teoh wrote:
> >>> As they say in information theory: it is the stuff that stands
> >>> out, that is different from the rest, that carries the most
> >>> information. The stuff that's pretty much repeated every single
> >>> time conveys very little information.
> >>
> >> This is an excellent way of looking at language design (and program
> >> design for that matter).
> >>
> >
> > Not to mention data compression ;)
> >
> 
> A program is a compressed representation of its possible executions.

Indeed. And generally with an absolutely enormous compression ratio -
often even infinite (when there's infinite possible executions). Or
at least "effectively infinite" even if not truly infinite in a strict
mathematical sense, simply due to finite memory.

Re: DConf 2013 keynote

On Sun, 12 May 2013 18:35:25 +0200
"Juan Manuel Cabo"  wrote:

> On Sunday, 12 May 2013 at 03:58:04 UTC, Nick Sabalausky wrote:
> > The nicest thing of all, IMO, about not strictly needing all 
> > that
> > support software is that basic things like
> > editing/navigating/opening/closing code is always and forever 
> > 100%
> > unobstructed by things like startup delays and keyboard input 
> > lag which
> > have no business existing on the rocket-engined supercomputers 
> > we now
> > call "a PC".
> 
> I'm using a little known IDE for D known as Poseidon:
>  http://www.dsource.org/projects/poseidon/wiki/Screenshots
> it is very fast, loads very quickly, and the editor is very 
> responsive. The keyword autocompletion is mostly broken in D2 but 
> I can live without it. It is a bit sad that it has gone 
> unmantained for more than a year.
> 

Looks interesting. Now that you mention it, I do seem to recall hearing
about it back then. Personally, I've been a huge fan of Programmer's
Notepad 2 . My #1 complaint about it though
is that it's Windows-only. I want to switch to Linux for my primary
system, but the lack of PN2 is one of the roadblocks (there are other
roadblocks, though).

> These are the things that I cannot live without for my big D2 
> project:
>  - Syntax highlighting.
>  - Search in multiple files.
>  - Can go to file/line when double-clicking on compiler error.
>  - Compile/run/debug just by hitting SHIFT-F5, and other keys.

Yea, PN2 has all of that. Essential stuff IMO too.

>  - Tree like structure for navigating all the many source 
> files of my project.

PN2 has that for files, although it looks like Poseidon goes another
step further and puts funcs/classes/etc into the tree, too. I heavily
use PN2's FF-like QuickFind for that sort of thing. Obviously not as
good, but it gets me where I'm going ;)

>  - Debugging (breakpoints, step by step, go to line that 
> crashed). It suprisingly still works in Poseidon.

Yea, that's something PN2 doesn't have. (Un)Luckily for me, I've spent
a lot of time in the past on things where I didn't have a debugger
available (one time my only debugging aid was a single LED! Royal
PITA!), so I've gotten so accustomed to printf debugging that I find I
usually prefer it.

Debuggers are great, I'd never deny that, but one thing I love about
printf-style is you can trivially go back-and-forth in time just by
scrolling. Debuggers only give you one time-slice at a time, and can
usually only progress forwards.

Of course, printf-style debugging really needs a language that compiles
fast. Fine for D, but it's no so fun with C/C++.

>  - No need for a makefile. It feeds all source files 
> (hundreds) and libraries to dmd.
> 

I used to swear by Visual Studio (until it got bloated, somewhere
around one of the earlier .NET versions) and I loved the whole
approach of "no makefiles, just feed all the project files to the
compiler".

But these days I prefer RDMD-style approaches ("pass the one main
source file to a cmdline tool and it figures out the rest") because
they're trivially scriptable and don't cause a specific editor (or any
editor at all) to become a build requirement. I find that especially
important for OSS and cross-platform projects.

Ever dealt with automated building of a multi-part project that
included building a Visual Studio project or (worse) a Flash project as
just one part of the overall process? Blech. It's awful.

> For smaller D projects I use Vim/makefiles though.
> 
> Again, I'm a bit sad that it has gone unmantained for so long, 
> but it's totally usable still. This is the faster IDE that I've 
> found.
> 
> --jm
>

Re: Formal Review of std.uni


30-Apr-2013 23:17, Jonathan M Davis пишет:

On Tuesday, April 30, 2013 15:13:14 Dmitry Olshansky wrote:

Unicode --> can't be done on character by character basis


Sure it can. It operates on dchar.


Getting back to this.

Sure it can't - I'd hate to break the illusion but the keyword is e.g. 
Unicode Case Folding. Another one is Combining Character sequence.



So, with how it's been, std.uni would only be operating on dchars, and putting
a function in there which operated on strings wouldn't make any sense. Maybe
that doesn't work if you've done a bunch of grapheme stuff, and things will
have to be adjusted, but it would be a definite shift to put anything in
std.uni which operated on strings, and I think that it would need some definite
justification (and there's a good chance that I'd be inclined to argue that it
should still go in std.string, possibly using some internal modules if
necessary).


Justification is that we'd rather have exactly one module dealing with a 
bunch of Unicode data arranged into intricate tables.


Strictly speaking I'd abolish any Unicode related algorithm in 
std.string since it's almost definitely doing it wrong anyway (I've 
checked only 2 - both broken).


There is not a single sign of unicode standards used, just the 
fallacious logic: byte --> dchar and use the same algorithm as with 
ASCII. It won't work.




But clearly I need to take the time to take a look at what you've actually
done (I keep meaning to but haven't gotten around to it yet). It had been my
impression that what you were doing was primarily a matter of improving the
implementation, but it sounds like you're doing something beyond that.


Take a peek at icmp and sicmp in new std.uni.
Current fork of Phobos is here:
https://github.com/blackwhale/phobos/tree/new-std-uni

Eventually we'd have to do a bit more in the same direction e.g. title 
casing, split by word boundary etc. (all of these need fixing in 
std.string).


Also all of the core tools are now in the open: CodepointSet, and 
generating Tries from sets and AA-s.



--
Dmitry Olshansky

Ali's book "Programming in D" on Hacker News


https://news.ycombinator.com/item?id=5693345

Re: DConf 2013 keynote

2013-05-12 Thread Diggory


On Sunday, 12 May 2013 at 18:42:22 UTC, deadalnix wrote:

On Sunday, 12 May 2013 at 18:09:59 UTC, Walter Bright wrote:
I think that is irrelevant to my point. A language doesn't 
have to be text based.


Textual format have proven theur usefullness again and again. 
Programming languages, json, xml, even dark stuff like LLVM IR 
have a textual representation. This is easier to debug.


In that regard, if you consider IntelliJ, java has become a 
textual representation. It is important as the compiler would 
be much harder to create otherwize.


Languages have been stored textually yes, and that is clearly 
beneficial, but editing code even in fairly basic editors is far 
beyond simple text editing.


Automatic indentation, symbol selection, symbol renaming, symbol 
navigation, code folding, auto-completion, quick info, 
intellisense, syntax highlighting, etc. mean that editing code is 
far closer to editing a complex tree-like data structure than 
editing text, even displaying it is not the same, and that's how 
it should be for maximum productivity. Conceptually we think 
about code in a way much closer to an AST than a bunch of lines 
of text.


Joke or not, I would amend "real programmers use notepad" to 
"real programmers *should be able* to use notepad".

Re: rename our github organization?


On 5/12/2013 11:15 AM, Brad Anderson wrote:

On Sunday, 12 May 2013 at 18:11:28 UTC, Walter Bright wrote:

It'll also cause disruption in that google won't find it when searching for "d
programming".


There should really be a README in the root of the repo so that GitHub displays
some information about the project.  That would solve the "d programming" issue
and make it more discoverable in general.


Not really. Having "d programming" in the URL gives it a much higher ranking.

Re: DConf 2013 keynote


On Sunday, 12 May 2013 at 18:09:59 UTC, Walter Bright wrote:
I think that is irrelevant to my point. A language doesn't have 
to be text based.


Textual format have proven theur usefullness again and again. 
Programming languages, json, xml, even dark stuff like LLVM IR 
have a textual representation. This is easier to debug.


In that regard, if you consider IntelliJ, java has become a 
textual representation. It is important as the compiler would be 
much harder to create otherwize.

Re: rename our github organization?

2013-05-12 Thread Brad Anderson


On Sunday, 12 May 2013 at 15:08:22 UTC, Andrei Alexandrescu wrote:
I'm thinking we should rename D-programming-language on github 
with dlang. While we're at it, project 
d-programming-language.org should be renamed dlang.org.


This may cause disruption. Thoughts?

Andrei


They are painfully long so I'm for it (and in the case of 
d-programming-language.org, inaccurate since dlang.org is the 
official url now).  The major contributors should weigh in though 
since it will affect them the most.


For those wondering how you resolve this after the change you 
just open .git/config for each repo and change 
"D-Programming-Language" remotes to say "dlang". Pretty easy.


A couple spots on the website that link to the repo would have to 
be updated but nothing you couldn't find and fix in less than a 
minute using a git grep.

Re: rename our github organization?

2013-05-12 Thread Brad Anderson


On Sunday, 12 May 2013 at 18:11:28 UTC, Walter Bright wrote:

On 5/12/2013 8:08 AM, Andrei Alexandrescu wrote:
I'm thinking we should rename D-programming-language on github 
with dlang. While
we're at it, project d-programming-language.org should be 
renamed dlang.org.


This may cause disruption. Thoughts?


It'll also cause disruption in that google won't find it when 
searching for "d programming".


There should really be a README in the root of the repo so that 
GitHub displays some information about the project.  That would 
solve the "d programming" issue and make it more discoverable in 
general.

Re: rename our github organization?


On 5/12/2013 8:08 AM, Andrei Alexandrescu wrote:

I'm thinking we should rename D-programming-language on github with dlang. While
we're at it, project d-programming-language.org should be renamed dlang.org.

This may cause disruption. Thoughts?


It'll also cause disruption in that google won't find it when searching for "d 
programming".

Re: DConf 2013 keynote


On 5/12/2013 2:32 AM, deadalnix wrote:

On Sunday, 12 May 2013 at 08:53:59 UTC, Walter Bright wrote:

On 5/12/2013 1:42 AM, deadalnix wrote:

On Sunday, 12 May 2013 at 08:40:11 UTC, Walter Bright wrote:

On 5/11/2013 10:57 PM, deadalnix wrote:

Stupid inexpressive language are easier to write tools for, this is the very
reason why java have such a great tooling.


You run the risk of having a write-only language if the expressivity is in the
tools rather than the language.


Tools don't have to show you what is in the text file. That is the beauty of it.
IntelliJ for instance, don't show java source code as it is in the source.


I.e. you've invented another language that has Java as its output so the user
never sees Java because Java is not presentable to users.


What is presented to the user isn't a text format anymore.


I think that is irrelevant to my point. A language doesn't have to be text 
based.

Re: DConf 2013 keynote


On 5/12/2013 9:42 AM, Jeff Nowakowski wrote:

Second, in the Q&A session of your talk, you said, "I'm sorely tempted to say
that real men don't use IDEs..."


Yes, but I said that as a joke.



The fixation on boilerplate as to why people
"need" IDEs is just a symptom of the more general sentiment.


No, the sentiment was that an IDE was not the solution to a language's 
deficiencies.

Re: rename our github organization?

On Sun, 12 May 2013 12:56:45 -0400
Matt Soucy  wrote:

> On 05/12/2013 11:14 AM, Peter Alexander wrote:
> > On Sunday, 12 May 2013 at 15:08:22 UTC, Andrei Alexandrescu wrote:
> >> I'm thinking we should rename D-programming-language on github with
> >> dlang. While we're at it, project d-programming-language.org
> >> should be renamed dlang.org.
> >>
> >> This may cause disruption. Thoughts?
> >>

Sounds worthwhile to me. I'm up for it.

> it needs to be
> announced well in advance to give people time to prepare.
> 

I agree.

Re: rename our github organization?

2013-05-12 Thread Calin Grosan


On Sunday, 12 May 2013 at 15:08:22 UTC, Andrei Alexandrescu wrote:
I'm thinking we should rename D-programming-language on github 
with dlang. While we're at it, project 
d-programming-language.org should be renamed dlang.org.


This may cause disruption. Thoughts?

Andrei


I would go even further and try to encourage/enforce "dland" 
instead of "D" everywhere. It's often complicated to google stuff 
related to D because is just

one character long.

Re: rename our github organization?

2013-05-12 Thread Matt Soucy

On 05/12/2013 11:14 AM, Peter Alexander wrote:
> On Sunday, 12 May 2013 at 15:08:22 UTC, Andrei Alexandrescu wrote:
>> I'm thinking we should rename D-programming-language on github with
>> dlang. While we're at it, project d-programming-language.org should be
>> renamed dlang.org.
>>
>> This may cause disruption. Thoughts?
>>
>> Andrei
> 
> I always thought D-programming-language was a bit wordy.
> 
> What kind of disruption are we talking about here though? Is this just
> an aesthetic change, or does it affect the git repro URLs? Having
> everyone update their remote URLs may be quite drastic (especially as
> many people may not follow the forums, and we have no way to announce
> this).

It would affect the repo urls as well. Which means that yes, all
references would need to be updated. Everywhere. So, as much as I think
it's a good idea, I feel that if it happens, it needs to be announced
well in advance to give people time to prepare.

Though, the point is a bit moot as someone already has the dlang name...
--
Matt Soucy



signature.asc
Description: OpenPGP digital signature

Re: DConf 2013 keynote

2013-05-12 Thread Jeff Nowakowski


On 05/11/2013 05:06 PM, Walter Bright wrote:


I didn't say an IDE was bad for D, I only said that if you need an IDE
to generate boilerplate for you, then there's something wrong with the
language.

IDE's have lots of other valuable uses.


Two points. One, the person I responded to (and quoted in my reply) 
said, "Yes, which is why I love D so much. All I need is a text editor 
and the compiler, and I can do everything."


Second, in the Q&A session of your talk, you said, "I'm sorely tempted 
to say that real men don't use IDEs..." The fixation on boilerplate as 
to why people "need" IDEs is just a symptom of the more general sentiment.

Re: DConf 2013 keynote

2013-05-12 Thread Juan Manuel Cabo


On Sunday, 12 May 2013 at 03:58:04 UTC, Nick Sabalausky wrote:
The nicest thing of all, IMO, about not strictly needing all 
that

support software is that basic things like
editing/navigating/opening/closing code is always and forever 
100%
unobstructed by things like startup delays and keyboard input 
lag which
have no business existing on the rocket-engined supercomputers 
we now

call "a PC".


I'm using a little known IDE for D known as Poseidon:
http://www.dsource.org/projects/poseidon/wiki/Screenshots
it is very fast, loads very quickly, and the editor is very 
responsive. The keyword autocompletion is mostly broken in D2 but 
I can live without it. It is a bit sad that it has gone 
unmantained for more than a year.


These are the things that I cannot live without for my big D2 
project:

- Syntax highlighting.
- Tree like structure for navigating all the many source 
files of my project.

- Search in multiple files.
- Debugging (breakpoints, step by step, go to line that 
crashed). It suprisingly still works in Poseidon.

- Can go to file/line when double-clicking on compiler error.
- Compile/run/debug just by hitting SHIFT-F5, and other keys.
- No need for a makefile. It feeds all source files 
(hundreds) and libraries to dmd.


For smaller D projects I use Vim/makefiles though.

Again, I'm a bit sad that it has gone unmantained for so long, 
but it's totally usable still. This is the faster IDE that I've 
found.


--jm

Re: DConf 2013 keynote

On 12 May 2013 14:14, deadalnix  wrote:

> On Sunday, 12 May 2013 at 13:04:31 UTC, Andrei Alexandrescu wrote:
>
>> Looks like text to me. http://www.jetbrains.com/idea/**. Did I look at
>> the wrong product?
>>
>>
> Yes, it is text based, but you can do many manipulation you can't do with
> a regular text presentation.
>
> This is text++
>

Looks like *shivers* ASP

-- 
Iain Buclaw

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

Re: rename our github organization?

2013-05-12 Thread Kenji Hara

I always agree that short good name is better than long ones.
At least to me, changing git remote setting is not so much laborious.

Kenji Hara


2013/5/13 Andrei Alexandrescu 

> I'm thinking we should rename D-programming-language on github with dlang.
> While we're at it, project d-programming-language.org should be renamed
> dlang.org.
>
> This may cause disruption. Thoughts?
>
> Andrei
>

Re: rename our github organization?

2013-05-12 Thread Peter Alexander


On Sunday, 12 May 2013 at 15:08:22 UTC, Andrei Alexandrescu wrote:
I'm thinking we should rename D-programming-language on github 
with dlang. While we're at it, project 
d-programming-language.org should be renamed dlang.org.


This may cause disruption. Thoughts?

Andrei


I always thought D-programming-language was a bit wordy.

What kind of disruption are we talking about here though? Is this 
just an aesthetic change, or does it affect the git repro URLs? 
Having everyone update their remote URLs may be quite drastic 
(especially as many people may not follow the forums, and we have 
no way to announce this).

rename our github organization?

I'm thinking we should rename D-programming-language on github with 
dlang. While we're at it, project d-programming-language.org should be 
renamed dlang.org.


This may cause disruption. Thoughts?

Andrei

Re: github dashboard

2013-05-12 Thread David Nadlinger


On Sunday, 12 May 2013 at 15:06:22 UTC, Andrei Alexandrescu wrote:

On 5/12/13 10:32 AM, Dicebot wrote:
On Sunday, 12 May 2013 at 14:30:44 UTC, Andrei Alexandrescu 
wrote:

Found it from memory but there's no link to it!

https://github.com/organizations/D-Programming-Language/dashboard/pulls


Andrei


It is actually a private dashboard equivalent to
https://github.com/dashboard/pulls , at least for me.


Ah, thanks. So only a few get to see that? This seems an 
unnecessary limitation (after all the pull requests can be seen 
by all, just not aggregated in the same place).


Yep, only organization members get to see it, which is rather 
unfortunate.


David

Re: github dashboard


On 5/12/13 10:42 AM, David Nadlinger wrote:

On Sunday, 12 May 2013 at 14:29:15 UTC, Andrei Alexandrescu wrote:

At some point I found a nice dashboard for D-programming-language on
github showing all pull requests for all projects together (dmd,
phobos, tools...). Now I can't find it to save my life. Does anyone
know how to get that?


Go to github.com and select the D-Programming-Language organization from
the dropdown at the top left.


Ah, that's right. Thanks!

Andrei

Re: github dashboard


On 5/12/13 10:32 AM, Dicebot wrote:

On Sunday, 12 May 2013 at 14:30:44 UTC, Andrei Alexandrescu wrote:

Found it from memory but there's no link to it!

https://github.com/organizations/D-Programming-Language/dashboard/pulls


Andrei


It is actually a private dashboard equivalent to
https://github.com/dashboard/pulls , at least for me.


Ah, thanks. So only a few get to see that? This seems an unnecessary 
limitation (after all the pull requests can be seen by all, just not 
aggregated in the same place).


Andrei

Re: github dashboard

2013-05-12 Thread David Nadlinger


On Sunday, 12 May 2013 at 14:29:15 UTC, Andrei Alexandrescu wrote:
At some point I found a nice dashboard for 
D-programming-language on github showing all pull requests for 
all projects together (dmd, phobos, tools...). Now I can't find 
it to save my life. Does anyone know how to get that?


Go to github.com and select the D-Programming-Language 
organization from the dropdown at the top left.


David

Re: github dashboard

2013-05-12 Thread Dicebot


On Sunday, 12 May 2013 at 14:30:44 UTC, Andrei Alexandrescu wrote:

Found it from memory but there's no link to it!

https://github.com/organizations/D-Programming-Language/dashboard/pulls


Andrei


It is actually a private dashboard equivalent to 
ttps://github.com/dashboard/pulls , at least for me.

Re: github dashboard


On 5/12/13 10:29 AM, Andrei Alexandrescu wrote:

Hello,

At some point I found a nice dashboard for D-programming-language on
github showing all pull requests for all projects together (dmd, phobos,
tools...). Now I can't find it to save my life. Does anyone know how to
get that?

Thanks,

Andrei


Found it from memory but there's no link to it!

https://github.com/organizations/D-Programming-Language/dashboard/pulls


Andrei

github dashboard


Hello,

At some point I found a nice dashboard for D-programming-language on 
github showing all pull requests for all projects together (dmd, phobos, 
tools...). Now I can't find it to save my life. Does anyone know how to 
get that?


Thanks,

Andrei

Re: What is a "pull request"?

2013-05-12 Thread SomeDude


On Sunday, 12 May 2013 at 08:48:28 UTC, w0rp wrote:

This thread is hilarious.

This is like asking a car mechanic what an alternator is. Then 
when he gives you a handbook explaining what one is, you throw 
it back and spit fury in his face. Other people don't breathe 
to cater to your every whim, especially when you reject more 
than adequate explanations for questions.


No, you are not clever. Aside from not being able to understand 
the simplest of things, you are not clever enough to speak to 
others with tact and respect. For this reason alone you should 
either re-evaluate the way you behave around others, or take a 
position which does not require teamwork. If you can't respond 
well to help, you cannot be expected to react accordingly when 
faced with the criticism you will surely face when making a 
pull request.


Spare your saliva, it's the typical random troll. Probably the 
same drunk/lunatic guy coming over and over again in this 
newsgroup.


I wonder if there are sociological studies of guys like that. 
I've yet to understand what their motivation is, if there is one.

Re: DConf 2013 Day 1 Talk 2 (Copy and Move Semantics)


On Sunday, 12 May 2013 at 13:07:15 UTC, Andrei Alexandrescu wrote:

On 5/12/13 5:50 AM, deadalnix wrote:

On Sunday, 12 May 2013 at 09:10:56 UTC, Simen Kjaeraas wrote:

On 2013-05-12, 08:12, deadalnix wrote:

On Saturday, 11 May 2013 at 22:24:38 UTC, Simen Kjaeraas 
wrote:
I'm not convinced. unique, like const or immutable, is 
transitive.

If foo
is unique, then so is foo.bar.



That isn't true. Please read microsoft's paper.


Done. *Mostly* transitive, then. Anything reachable through a 
unique

reference is either unique or immutable.


No.

Think about it : when you reach something via a uniq pointer, 
it is by
definition not unique as you have 2 copies of it, because you 
just

accessed it.


I don't think so. Lent and destructive read can be used.



Destructive read would be super confusing and due to the Correct 
point below, don't ensure anything.


Plus the unique pointer refers to a unique mutable graph of 
object. A
object into that graph can have several object into the graph 
refereing

to it.


Correct.

Re: DConf 2013 keynote


On Sunday, 12 May 2013 at 13:04:31 UTC, Andrei Alexandrescu wrote:
Looks like text to me. http://www.jetbrains.com/idea/. Did I 
look at the wrong product?




Yes, it is text based, but you can do many manipulation you can't 
do with a regular text presentation.


This is text++

Re: DConf 2013 Day 1 Talk 2 (Copy and Move Semantics)


On 5/12/13 5:50 AM, deadalnix wrote:

On Sunday, 12 May 2013 at 09:10:56 UTC, Simen Kjaeraas wrote:

On 2013-05-12, 08:12, deadalnix wrote:


On Saturday, 11 May 2013 at 22:24:38 UTC, Simen Kjaeraas wrote:

I'm not convinced. unique, like const or immutable, is transitive.
If foo
is unique, then so is foo.bar.



That isn't true. Please read microsoft's paper.


Done. *Mostly* transitive, then. Anything reachable through a unique
reference is either unique or immutable.


No.

Think about it : when you reach something via a uniq pointer, it is by
definition not unique as you have 2 copies of it, because you just
accessed it.


I don't think so. Lent and destructive read can be used.


Plus the unique pointer refers to a unique mutable graph of object. A
object into that graph can have several object into the graph refereing
to it.


Correct.


Andrei

Re: DConf 2013 keynote


On 5/12/13 5:32 AM, deadalnix wrote:

On Sunday, 12 May 2013 at 08:53:59 UTC, Walter Bright wrote:

On 5/12/2013 1:42 AM, deadalnix wrote:

On Sunday, 12 May 2013 at 08:40:11 UTC, Walter Bright wrote:

On 5/11/2013 10:57 PM, deadalnix wrote:

Stupid inexpressive language are easier to write tools for, this is
the very
reason why java have such a great tooling.


You run the risk of having a write-only language if the expressivity
is in the
tools rather than the language.


Tools don't have to show you what is in the text file. That is the
beauty of it.
IntelliJ for instance, don't show java source code as it is in the
source.


I.e. you've invented another language that has Java as its output so
the user never sees Java because Java is not presentable to users.


What is presented to the user isn't a text format anymore.


Looks like text to me. http://www.jetbrains.com/idea/. Did I look at the 
wrong product?


Andrei

Re: DConf 2013 Day 1 Talk 2 (Copy and Move Semantics)


On 5/12/13 5:10 AM, Simen Kjaeraas wrote:

On 2013-05-12, 08:12, deadalnix wrote:


On Saturday, 11 May 2013 at 22:24:38 UTC, Simen Kjaeraas wrote:

I'm not convinced. unique, like const or immutable, is transitive. If
foo
is unique, then so is foo.bar.



That isn't true. Please read microsoft's paper.


Done. *Mostly* transitive, then. Anything reachable through a unique
reference is either unique or immutable.


Bartosz, Walter and I reached a similar design a few years ago. We just 
thought it complicates things too much for what it does.


Andrei

Re: DConf 2013 Day 1 Talk 2 (Copy and Move Semantics)

2013-05-12 Thread Thiez

You may wish to take a look at Rust for inspiration. Rust has 
unique (~) pointers and has made some interesting choices there. 
Their ~pointers imply ownership. I'm not sure this could be 
(efficiently) duplicated in a library for D (Rust has significant 
compiler support for its pointer types) but it may be worth 
taking a look regardless.

Re: DConf 2013 keynote

2013-05-12 Thread Timon Gehr


On 05/12/2013 05:59 AM, Nick Sabalausky wrote:

On Fri, 10 May 2013 19:04:31 -0400
"Jonathan M Davis"  wrote:


On Friday, May 10, 2013 14:31:00 H. S. Teoh wrote:

As they say in information theory: it is the stuff that stands out,
that is different from the rest, that carries the most information.
The stuff that's pretty much repeated every single time conveys
very little information.


This is an excellent way of looking at language design (and program
design for that matter).



Not to mention data compression ;)



A program is a compressed representation of its possible executions.

Re: issue 9122

2013-05-12 Thread Zhenya


On Sunday, 12 May 2013 at 10:49:40 UTC, Tofu Ninja wrote:

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

Is anyone working on this or know of a work around, it is 
breaking my project and I can't move on until its fixed.


see 
http://forum.dlang.org/thread/puqbpycvisbjrahao...@forum.dlang.org

Re: Migrating D front end to D - post Dconf

On 12 May 2013 11:39, John Colvin  wrote:

> On Sunday, 12 May 2013 at 09:48:58 UTC, Iain Buclaw wrote:
>
>> On 12 May 2013 10:39, Jacob Carlborg  wrote:
>>
>>  On 2013-05-12 05:50, Jonathan M Davis wrote:
>>>
>>>  That helps considerably, though if the compiler is old enough, that
>>> won't
>>>
 work
 for Linux due to glibc changes and whatnot.


>>> My experience is the other way around. Binaries built on newer version of
>>> Linux doesn't work on older. But binaries built on older versions usually
>>> works on newer versions.
>>>
>>> --
>>> /Jacob Carlborg
>>>
>>>
>> Depends... statically linked binaries will probably always work on the
>> latest version, dynamic link and then you've got yourself a 'this
>> libstdc++v5 doesn't exist anymore' problem.
>>
>
> So surely we can just offer a full history of statically linked binaries,
> problem solved?
>

The historical quirk of binary compatibility on Linux is OT to the problem
I questioned, so no.


-- 
Iain Buclaw

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

Re: DConf 2013 Day 1 Talk 2 (Copy and Move Semantics)


On 2013-05-12, 11:50, deadalnix wrote:


On Sunday, 12 May 2013 at 09:10:56 UTC, Simen Kjaeraas wrote:

On 2013-05-12, 08:12, deadalnix wrote:


On Saturday, 11 May 2013 at 22:24:38 UTC, Simen Kjaeraas wrote:
I'm not convinced. unique, like const or immutable, is transitive. If  
foo

is unique, then so is foo.bar.



That isn't true. Please read microsoft's paper.


Done. *Mostly* transitive, then. Anything reachable through a unique
reference is either unique or immutable.


No.

Think about it : when you reach something via a uniq pointer, it is by  
definition not unique as you have 2 copies of it, because you just  
accessed it.


Plus the unique pointer refers to a unique mutable graph of object. A  
object into that graph can have several object into the graph refereing  
to it.


You are wrong in 2 different ways.


I'd argue it's only one way, if only to reduce the impact to my ego. :p

Yes, you're absolutely right. Anything reachable through a unique
reference needs to be *lent* or immutable. That way, it's either safe
to create new references to it, or the type system forbids it.

--
Simen

issue 9122

2013-05-12 Thread Tofu Ninja


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

Is anyone working on this or know of a work around, it is 
breaking my project and I can't move on until its fixed.

Re: Migrating D front end to D - post Dconf

2013-05-12 Thread John Colvin


On Sunday, 12 May 2013 at 09:48:58 UTC, Iain Buclaw wrote:

On 12 May 2013 10:39, Jacob Carlborg  wrote:


On 2013-05-12 05:50, Jonathan M Davis wrote:

 That helps considerably, though if the compiler is old 
enough, that won't

work
for Linux due to glibc changes and whatnot.



My experience is the other way around. Binaries built on newer 
version of
Linux doesn't work on older. But binaries built on older 
versions usually

works on newer versions.

--
/Jacob Carlborg



Depends... statically linked binaries will probably always work 
on the
latest version, dynamic link and then you've got yourself a 
'this

libstdc++v5 doesn't exist anymore' problem.


So surely we can just offer a full history of statically linked 
binaries, problem solved?

Re: Migrating D front end to D - post Dconf

On 12 May 2013 11:08, w0rp  wrote:

> On Sunday, 12 May 2013 at 09:48:58 UTC, Iain Buclaw wrote:
>
>> Depends... statically linked binaries will probably always work on the
>> latest version, dynamic link and then you've got yourself a 'this
>> libstdc++v5 doesn't exist anymore' problem.
>>
>
> I am picturing a Linux workstation with the Post-It note ”DO NOT UPDATE"
> stuck to it.
>

:D

The only reason you'd have for that post-it note is if you were running
some application that you; built yourself, obtained from a third party
vendor, general other or not part of the distributions repository.

For instance, I've had some linux ports of games break on me once after an
upgrade.  And I've even got a company gcc that does not work on
Debian/Ubuntu.  There's nothing wrong with binary compatibility, just that
they implemented a multi-arch directory structure, so everything is in a
different place to what the vanilla gcc expects.  ;)

-- 
Iain Buclaw

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

Re: Migrating D front end to D - post Dconf

2013-05-12 Thread w0rp


On Sunday, 12 May 2013 at 09:48:58 UTC, Iain Buclaw wrote:
Depends... statically linked binaries will probably always work 
on the
latest version, dynamic link and then you've got yourself a 
'this

libstdc++v5 doesn't exist anymore' problem.


I am picturing a Linux workstation with the Post-It note ”DO NOT 
UPDATE" stuck to it.

Re: DConf 2013 keynote


RAFFI CHOWDURY


Islam Freedom division of Holy Makkah
34 Green Street
London
E7 8BZ
Main Tel: 0203 432 9692  /  0207 112 8819
Tech Tel: 0208 472 5593
Main Fax: 0208 552 1600
Main Email: sa...@islamfreedom.com
Online: Send us a request


Islam Freedom division of Holy Makkah
548 Coventry Road
Small Heath
Birmingham
B10 0UN
Main Tel: 0121 285 0044
Main Fax: 0121 773 7717
Main Email: sa...@islamfreedom.com
Online: Send us a request

Re: DConf 2013 keynote


RAFFI CHOWDHURY
British Airways Direct Umrah flights Non-stop
Depart: BA 133 10MAY LHRJED-2150 0715
Return: BA 132 18MAY JEDLHR-0855 1300

Cheap Flights to Jeddah
British Airways Direct Umrah flights Non-stop
Depart: BA 133 10MAY LHRJED-2150 0715
Return: BA 132 25MAY JEDLHR-0855 1300

Cheap Flights to Jeddah
British Airways Direct Umrah flights Non-stop
Depart: BA 133 17MAY LHRJED-2150 0715
Return: BA 132 25MAY JEDLHR-0855 1300

Cheap Flights to Jeddah
British Airways Direct Umrah flights Non-stop
Depart: BA 133 17MAY LHRJED-2150 0715
Return: BA 132 31MAY JEDLHR-0855 130
Cheap Flights to Jeddah
British Airways Direct Umrah flights Non-stop
Depart: BA 133 24MAY LHRJED-2150 0715
Return: BA 132 01JUN JEDLHR-0855 1300

Cheap Flights to Jeddah
British Airways Direct Umrah flights Non-stop
Depart: BA 133 25MAY LHRJED-2150 0715
Return: BA 132 03JUN JEDLHR-0855 1300

Cheap Flights to Jeddah
British Airways Direct Umrah flights Non-stop
Depart: BA 133 26MAY LHRJED-2150 0715
Return: BA 132 05JUN JEDLHR-0855 1300

Cheap Flights to Jeddah
British Airways Direct Umrah flights Non-stop
Depart: BA 133 31MAY LHRJED-2150 0715
Return: BA 132 15JUN JEDLHR-0855 1300

Cheap Flights to Jeddah
British Airways Direct Umrah flights Non-stop
Depart: BA 133 07JUN LHRJED-2150 0715
Return: BA 132 15JUN JEDLHR-0855 1300

Re: DConf 2013 keynote



Cheap Flights to Jeddah fr £150 + tax
Find direct flights to Jeddah at rock-bottom prices try Islam 
Freedom today!
Many of our consolidated Umrah airfares are substantially less 
than the lowest published fare purchased directly from airlines. 
Most of our airfares are block airlines tickets, bought in bulk 
at wholesale prices then resold to you at huge discounts. Fly in 
style and comfort with British Airways, the most reliable and 
flights are on time - Halal meals served on all Hajj and Umrah 
flights. Generous baggage allowance of 46kg (2 pieces) and cabin 
size hand luggage plus 10 litres Zamzam water on return flight. 
Terminal 5’s efficiency has made the airline more punctual and 
more reliable, also prayer room provided in terminal 5 to change 
Ihram. Heathrow connecting flights are available from Aberdeen, 
Edinburgh, Glasgow, Manchester and Newcastle to Jeddah.

Cheap Flights to Jeddah
British Airways Direct Umrah flights Non-stop
Depart: BA 133 19APR LHRJED-2150 0715
Return: BA 132 27APR JEDLHR-0855 1300

Cheap Flights to Jeddah
British Airways Direct Umrah flights Non-stop
Depart: BA 133 19APR LHRJED-2150 0715
Return: BA 132 04MAY JEDLHR-0855 1300

Cheap Flights to Jeddah
British Airways Direct Umrah flights Non-stop
Depart: BA 133 26APR LHRJED-2150 0715
Return: BA 132 04MAY JEDLHR-0855 1300

Cheap Flights to Jeddah
British Airways Direct Umrah flights Non-stop
Depart: BA 133 26APR LHRJED-2150 0715
Return: BA 132 11MAY JEDLHR-0855 1300

Cheap Flights to Jeddah
British Airways Direct Umrah flights Non-stop
Depart: BA 133 03MAY LHRJED-2150 0715
Return: BA 132 11MAY JEDLHR-0855 1300

Cheap Flights to Jeddah
British Airways Direct Umrah flights Non-stop
Depart: BA 133 03MAY LHRJED-2150 0715
Return: BA 132 18MAY JEDLHR-0855 1300

Cheap Flights to Jeddah
British Airways Direct Umrah flights Non-stop
Depart: BA 133 10MAY LHRJED-2150 0715
Return: BA 132 18MAY JEDLHR-0855 1300

Cheap Flights to Jeddah
British Airways Direct Umrah flights Non-stop
Depart: BA 133 10MAY LHRJED-2150 0715
Return: BA 132 25MAY JEDLHR-0855 1300

Cheap Flights to Jeddah
British Airways Direct Umrah flights Non-stop
Depart: BA 133 17MAY LHRJED-2150 0715

Re: DConf 2013 keynote


On Friday, 10 May 2013 at 12:35:07 UTC, Dmitry Olshansky wrote:

10-May-2013 01:32, Nick Sabalausky пишет:

On Thu, 09 May 2013 10:26:46 -0400
Andrei Alexandrescu  wrote:


On 5/9/13 10:26 AM, Andrei Alexandrescu wrote:
With all this focus on technicalities, we forgot to discuss 
the

gist of it: what did you guys think of the talk?



That should better go in the digitalmars.D group though...



Very good talk! And good production quality, too. This would 
be a

great thing to point people towards to introduce them to D.



Indeed and I can actually hear questions :)
BTW these were quite interesting in their own right like "if 
there is a way to cleanly manipulate carry bit within the 
language".



And Walter does a good job on stage. *Never* comes across as
pretentious, or cocky or full-of-...various things...like 
*cough*a
certain former Apple leader*cough* always did. (Minor nit: 
Forgot to

mention Mono-D on the last question, though.)



I loved the warm informal atmosphere here, too bad I've been 
stuck with visa approval at the last moment. The idea to 
smuggle myself in some crate of rice doesn't seem half-bad now 
;)

Re: DConf 2013 Day 1 Talk 2 (Copy and Move Semantics)


On Sunday, 12 May 2013 at 09:10:56 UTC, Simen Kjaeraas wrote:

On 2013-05-12, 08:12, deadalnix wrote:


On Saturday, 11 May 2013 at 22:24:38 UTC, Simen Kjaeraas wrote:
I'm not convinced. unique, like const or immutable, is 
transitive. If foo

is unique, then so is foo.bar.



That isn't true. Please read microsoft's paper.


Done. *Mostly* transitive, then. Anything reachable through a 
unique

reference is either unique or immutable.


No.

Think about it : when you reach something via a uniq pointer, it 
is by definition not unique as you have 2 copies of it, because 
you just accessed it.


Plus the unique pointer refers to a unique mutable graph of 
object. A object into that graph can have several object into the 
graph refereing to it.


You are wrong in 2 different ways.

Re: Migrating D front end to D - post Dconf

On 12 May 2013 10:39, Jacob Carlborg  wrote:

> On 2013-05-12 05:50, Jonathan M Davis wrote:
>
>  That helps considerably, though if the compiler is old enough, that won't
>> work
>> for Linux due to glibc changes and whatnot.
>>
>
> My experience is the other way around. Binaries built on newer version of
> Linux doesn't work on older. But binaries built on older versions usually
> works on newer versions.
>
> --
> /Jacob Carlborg
>

Depends... statically linked binaries will probably always work on the
latest version, dynamic link and then you've got yourself a 'this
libstdc++v5 doesn't exist anymore' problem.

-- 
Iain Buclaw

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

Re: Migrating D front end to D - post Dconf


On 2013-05-12 05:50, Jonathan M Davis wrote:


That helps considerably, though if the compiler is old enough, that won't work
for Linux due to glibc changes and whatnot.


My experience is the other way around. Binaries built on newer version 
of Linux doesn't work on older. But binaries built on older versions 
usually works on newer versions.


--
/Jacob Carlborg

Re: DConf 2013 keynote


On Sunday, 12 May 2013 at 08:53:59 UTC, Walter Bright wrote:

On 5/12/2013 1:42 AM, deadalnix wrote:

On Sunday, 12 May 2013 at 08:40:11 UTC, Walter Bright wrote:

On 5/11/2013 10:57 PM, deadalnix wrote:
Stupid inexpressive language are easier to write tools for, 
this is the very

reason why java have such a great tooling.


You run the risk of having a write-only language if the 
expressivity is in the

tools rather than the language.


Tools don't have to show you what is in the text file. That is 
the beauty of it.
IntelliJ for instance, don't show java source code as it is in 
the source.


I.e. you've invented another language that has Java as its 
output so the user never sees Java because Java is not 
presentable to users.


What is presented to the user isn't a text format anymore.

Re: DConf 2013 Day 1 Talk 2 (Copy and Move Semantics)


On 2013-05-12, 05:16, Diggory wrote:


On Sunday, 12 May 2013 at 01:16:43 UTC, Simen Kjaeraas wrote:
I believe you're overthinking this. First, what is global unique  
variable?
A unique value will per definition have to be thread-local (if not,  
other
threads have a reference to it, and it's not unique). Thus, when passed  
to

a function, the value is inaccessible outside of that function until it
returns. (I guess fibers might be an exception here?)


While in the function, that function can access a value both through the  
global variable which is supposed to be "unique" and through the lent  
parameter. This could cause problems because "unique" no longer means  
"unique", although it's difficult to see how serious that might be.


Ah, like that. That's the same problem as passing the same unique value
twice as a parameter to a function, I believe. Let's try:

class A {}

unique A globalA;
A globalNonUnique;

void foo() {
bar( globalA );
}

void bar(lent A localA) {
globalNonUnique = globalA;
// Where the good stuff happens.
}

At the point of the comment, globalA is null, because of unique's rules.
localA is still what it was, because it's lent, which gives no uniqueness
guarantees, only that no new, escaping references be created.

If the parameter had been marked unique instead of lent, globalA would
have been cleared upon its value being passed to the function.


I believe the elephant in the room is lent return values:

lent A baz(lent A a) {
return a; // Obviously illegal - a new alias is created.
}

lent A qux(ref lent A a) {
return a; // Sets a to null and returns its old value?
}

--
Simen

Re: DConf 2013 Day 1 Talk 2 (Copy and Move Semantics)


On 2013-05-12, 11:10, Simen Kjaeraas wrote:


On 2013-05-12, 08:12, deadalnix wrote:


On Saturday, 11 May 2013 at 22:24:38 UTC, Simen Kjaeraas wrote:
I'm not convinced. unique, like const or immutable, is transitive. If  
foo

is unique, then so is foo.bar.



That isn't true. Please read microsoft's paper.


Done. *Mostly* transitive, then. Anything reachable through a unique
reference is either unique or immutable.


btw, we're free to define unique to be completely transitive, or even
not transitive at all. We need not end up with a carbon copy of
Microsoft's system.

--
Simen

Re: What is a "pull request"?

2013-05-12 Thread Dicebot


On Sunday, 12 May 2013 at 09:10:35 UTC, Maxim Fomin wrote:

Author of the thread is not interested in getting right answer.

I do not know why, but in usenet groups there is this kind of 
trolling (asking naive questions to troll those who answer). I 
met it for the first time in comp.lang.c where it was used to 
assault frequent contributors. Luckily digitalmars-d is not 
that littered by trolls, spam and porn as comp.lang.c


Interesting issue here is whether there would be some kind of 
ex post moderation.


It is not unique to usenet, even contrary, kind of example of 
contemporary internet "culture". D newsgroup did not have this 
issue that much only because it is not wide-known, any popular 
internet community that does not have any form of moderation get 
overrun by trolls damn fast. (Though I remember few similar cases 
before, it took crazy amount of time until posts were actually 
deleted and author banned)


What surprises me is that someone replies to this posts and even 
tries to answer the "questions". It is like some of you guys have 
never met a troll before. X_x

Re: What is a "pull request"?

2013-05-12 Thread Maxim Fomin


On Sunday, 12 May 2013 at 07:30:12 UTC, eles wrote:

On Saturday, 11 May 2013 at 06:07:39 UTC, skeptical wrote:



What is a "pull request"? Thank you.


A pull request is like a patch that is sent for review before 
being applied to the source code tree.


It is specific to git. "git pull" is a command that retrieves 
and applies that patch, so is like a "request to apply a patch".


Author of the thread is not interested in getting right answer.

I do not know why, but in usenet groups there is this kind of 
trolling (asking naive questions to troll those who answer). I 
met it for the first time in comp.lang.c where it was used to 
assault frequent contributors. Luckily digitalmars-d is not that 
littered by trolls, spam and porn as comp.lang.c


Interesting issue here is whether there would be some kind of ex 
post moderation.

Re: DConf 2013 Day 1 Talk 2 (Copy and Move Semantics)


On 2013-05-12, 08:12, deadalnix wrote:


On Saturday, 11 May 2013 at 22:24:38 UTC, Simen Kjaeraas wrote:
I'm not convinced. unique, like const or immutable, is transitive. If  
foo

is unique, then so is foo.bar.



That isn't true. Please read microsoft's paper.


Done. *Mostly* transitive, then. Anything reachable through a unique
reference is either unique or immutable.

--
Simen

Re: DConf 2013 keynote

2013-05-12 Thread Dicebot


On Saturday, 11 May 2013 at 22:11:25 UTC, Diggory wrote:

...


That provokes another argument about attribute inference, 
off-topic one :) Must resist!

Re: DConf 2013 keynote


On 5/12/2013 1:42 AM, deadalnix wrote:

On Sunday, 12 May 2013 at 08:40:11 UTC, Walter Bright wrote:

On 5/11/2013 10:57 PM, deadalnix wrote:

Stupid inexpressive language are easier to write tools for, this is the very
reason why java have such a great tooling.


You run the risk of having a write-only language if the expressivity is in the
tools rather than the language.


Tools don't have to show you what is in the text file. That is the beauty of it.
IntelliJ for instance, don't show java source code as it is in the source.


I.e. you've invented another language that has Java as its output so the user 
never sees Java because Java is not presentable to users.

Re: What is a "pull request"?

2013-05-12 Thread w0rp


This thread is hilarious.

This is like asking a car mechanic what an alternator is. Then 
when he gives you a handbook explaining what one is, you throw it 
back and spit fury in his face. Other people don't breathe to 
cater to your every whim, especially when you reject more than 
adequate explanations for questions.


No, you are not clever. Aside from not being able to understand 
the simplest of things, you are not clever enough to speak to 
others with tact and respect. For this reason alone you should 
either re-evaluate the way you behave around others, or take a 
position which does not require teamwork. If you can't respond 
well to help, you cannot be expected to react accordingly when 
faced with the criticism you will surely face when making a pull 
request.

Re: DConf 2013 keynote


On Sunday, 12 May 2013 at 08:40:11 UTC, Walter Bright wrote:

On 5/11/2013 10:57 PM, deadalnix wrote:
Stupid inexpressive language are easier to write tools for, 
this is the very

reason why java have such a great tooling.


You run the risk of having a write-only language if the 
expressivity is in the tools rather than the language.


Tools don't have to show you what is in the text file. That is 
the beauty of it. IntelliJ for instance, don't show java source 
code as it is in the source.

Re: DConf 2013 keynote


On 5/11/2013 10:57 PM, deadalnix wrote:

Stupid inexpressive language are easier to write tools for, this is the very
reason why java have such a great tooling.


You run the risk of having a write-only language if the expressivity is in the 
tools rather than the language.

Re: Migrating D front end to D - post Dconf