date:20121113


On 11/10/2012 11:15 AM, Jacob Carlborg wrote:

On 2012-11-10 20:04, Walter Bright wrote:


Think of it this way. If I have myString.String, and use the strings in
it as an attribute in one module, and in another use module use
myString.String as an attribute with a totally different meaning, that
will not work if plugins are used.


I'm not entirely sure what you're meaning here but if you have two symbols with
the same name in two different modules their fully qualified names won't be the
same.

If you're referring to using a string literal as an attribute then that would be
a bad thing, like we have tried to explain. It's better to use a type which will
have a unique name.

If I have misunderstood what you're meaning could you provide a code example?



That is what I mean, and it also applies to a library type which different 
modules may press into service as attributes.

Re: User Defined Attributes


On 11/10/2012 12:21 PM, deadalnix wrote:

Thinking of it this way don't make any sense. The whole point of an attribute is
to tell a library about how to understand your code.

If many library uses the same attribute, then it defeat the whole point of
having attribute. This is why the discussion about disallowing any type as UDA
exists in the first place.


I understand that. I just am not convinced of the scope of this issue, and I am 
not convinced that a runtime attribute system is that applicable for this case, 
nor am I convinced that exception handling is that applicable (all for reasons 
already explained).


For another analogy, consider the type int. Different modules impute different 
meanings into it all the time, and it doesn't cause terrible compatibility 
problems between modules.

Re: User Defined Attributes


On 11/13/2012 2:55 PM, bearophile wrote:

Walter Bright:


consider the type int. Different modules impute different meanings into it
all the time, and it doesn't cause terrible compatibility problems between
modules.


The usage of naked basic types as int and double cause troubles.


I know that you can use custom types instead, and have better type checking, 
etc., and can be a pretty good idea for a lot of use cases. But D does not 
require that. It's up to the programmer.

Re: User Defined Attributes


Walter Bright:

(I know this sub-discussion is a bit OT, but not too much, and I 
think it's not wasted time.)



But D does not require that. It's up to the programmer.


Oh, but the use of newtype is not required in Haskell; 
programmers are free to use it, or to use normal basic types as 
Int, Integer, Double, etc. Probably newtype is not that useful in 
little programs. And even in larger programs it's better to not 
use it too much.


And the use of that using in a newtype is not standard Haskell, 
it's a GHC compiler extension to the language, that you have to 
ask with a compilation switch or an annotation inside the code. 
That using attached to a newtype allows you to both use a 
newtype like its base type (like the underlying Int), or to 
choose where the newtype must not do what its base type is able 
to do (this technically means what typeclasses it conforms to or 
not). I think D Typedef should allow something similar, despite D 
has no typeclasses. As an example, currently D Typedef is kind of 
useless if you want to use it to define a new array type.


Bye,
bearophile

Re: User Defined Attributes


On 11/13/2012 5:22 PM, bearophile wrote:

As an
example, currently D Typedef is kind of useless if you want to use it to define
a new array type.


D's typedef is deprecated, as nobody could figure out what it was good for or 
properly define its semantics.

Re: User Defined Attributes

2012-11-13 Thread deadalnix


Le 13/11/2012 23:27, Walter Bright a écrit :

On 11/10/2012 12:21 PM, deadalnix wrote:

Thinking of it this way don't make any sense. The whole point of an
attribute is
to tell a library about how to understand your code.

If many library uses the same attribute, then it defeat the whole
point of
having attribute. This is why the discussion about disallowing any
type as UDA
exists in the first place.


I understand that. I just am not convinced of the scope of this issue,
and I am not convinced that a runtime attribute system is that
applicable for this case, nor am I convinced that exception handling is
that applicable (all for reasons already explained).



I presented you compile time uses cases for such a mecanism already. See 
project lombok for instance.



For another analogy, consider the type int. Different modules impute
different meanings into it all the time, and it doesn't cause terrible
compatibility problems between modules.


int isn't meant to be discovered. The whole point of attribute is to be 
discovered.

Re: User Defined Attributes


Walter Bright:

D's typedef is deprecated, as nobody could figure out what it 
was good for or properly define its semantics.


Look better, in both my last posts Typedef was 
std.typecons.Typedef.


Bye,
bearophile

Re: User Defined Attributes

2012-11-13 Thread Jacob Carlborg


On 2012-11-13 23:24, Walter Bright wrote:


That is what I mean, and it also applies to a library type which
different modules may press into service as attributes.


I think there must be some kind of misunderstanding here. I still don't 
see the problem if fully qualified symbols are used. I mean, it will be 
unique.


--
/Jacob Carlborg

Re: User Defined Attributes


On 11/13/2012 11:16 PM, Jacob Carlborg wrote:

On 2012-11-13 23:24, Walter Bright wrote:


That is what I mean, and it also applies to a library type which
different modules may press into service as attributes.


I think there must be some kind of misunderstanding here. I still don't see the
problem if fully qualified symbols are used. I mean, it will be unique.



We agree that strings can be used globally as attributes with different 
meanings, right?


So why can't test.foo.bar also be used globally as an attribute with different 
meanings? It's just a type name, it has no magic property that says it cannot be 
used for different purposes. Ok, let's call it:


std.mytypes.mystring

? Now have those string contents mean different things to different users of 
std.mytypes.mystring.

Re: Const ref and rvalues again...


On 13.11.2012 2:16, martin wrote:

On Monday, 12 November 2012 at 23:38:43 UTC, luka8088 wrote:

What about making this a default behavior and introducing a new
keyword if the function wants to modify the argument but it is not ref
(pass by value) ? The reason I think that this should be a default
behavior because not many functions actually modify their arguments
and so it leaves a lot of space for optimization.

For example:

void f (int x, val int y, ref int z) {
x = 1; // x is not copied
// compiler throws an error, x is not passed by value
// and therefor could not / should not be changed
y = 2; // ok, y is copied
z = 3; // ok, z is a reference
}


Your proposal isn't really related to this thread's topic, but I


Um, Const ref and rvalues again, I suggest it to be the default 
behavior, how is this not related ?



understand what you mean (although your code comments distract me a bit):

void f(const int x, int y, ref int z); =
void f(int x, val/mutable int y, ref int z);



Yes, you understood correctly:
void f (const ref int x, int y, ref int z); =
void f (int x, val int y, ref int z);

The point here is to make We need a way for a function to declare that 
it doesn't want it's argument to be copied, but it also doesn't care 
whether the argument is an rvalue or an lvalue.  a default behavior.



I use const/in ;) parameters a lot in my code too to prevent accidental
modifications, so my function signatures may be more compact by treating
normal pass-by-value parameters as const if not denoted with a special
keyword. I guess it wouldn't be very important for optimization though
because I'd expect the optimizer to detect unchanged parameters. Anyway,
your proposal would completely break existing code.


Would it ? How many functions actually change their non ref/out 
arguments ? Can you point out any existing public code that would be 
broken ?

Re: Binary compatibility on Linux

2012-11-13 Thread Kagamin

On Sunday, 11 November 2012 at 11:46:07 UTC, Joseph Rushton 
Wakeling wrote:
Which is well and good, but doesn't address the problem that 
software developers face, which is How can I make directly 
available binaries of my programs that will work for any Linux 
user?


http://en.wikipedia.org/wiki/Open_Build_Service ?

Re: Immutable and unique in C#


On 11/12/2012 11:48 PM, Sönke Ludwig wrote:

Am 13.11.2012 00:46, schrieb Walter Bright:

On 11/9/2012 5:53 AM, Sönke Ludwig wrote:

Independent of this article I think D is currently missing out a lot by
omitting a proper unique type (a _proper_ library solution would be a
start, but I'm not sure if that can handle all details). It would make a
lot of the cases work that are currently simply not practical because of
loads of casts that are necessary.


Unique as a type qualifier comes with all kinds of subtle problems. For one 
thing, unique is more of
a property of an expression rather than a property of the type.

But I was thinking - what if it's a storage class? Like ref is? Working through 
the use cases in my
head, I think it can work. Unique being a property of an expression, this can 
be tested upon
assignment to the unique variable. Upon reading that unique variable, the value 
of it is erased.

Function parameters can be qualified with unique as well, meaning their 
corresponding arguments
can only be unique expressions.



Currently I also see no reason why this should not be possible. Since it is 
acting recursively and
locally anyway, a storage class will probably capture almost everything that a 
full type would. I
had thought about the same route to reduce intrusiveness, before looking first 
what's possible with
a pure library solution.

The library solution seems surprisingly practical for some use cases. With the concept of 
string
and weak isolation (*), it can even handle the bridge between isolated and 
shared memory (thanks
to the completely separated nature of shared). By this, it solves a lot of the 
problems that only
Bartosz system was able to solve, for example declaring owned collections (no 
Mutex necessary),
which contain references to shared data, and still everything is safely checked.

A proper language feature can still do a lot more and IMO D should get there at 
some point - but I
think this is a viable short/mid-term alternative. I would like to get some 
discussion going to
eventually include something in phobos.


(*)

strong isolation: allows only strongly isolated and immutable references
  - can be passed to other threads and casts implicitly to immutable

weak isolation: allows weakly isolated, immutable and shared references
  - can only be passed to other threads



I've thought some more about it, and there are some implementation problems with 
doing it as a storage class. Specifically, the issue of enforcing destructive 
reads from unique variables, which is a very intrusive and complex change for 
little gain.


However, this is not an issue if, instead, we created:

   Unique!T v = ...;

where T is a pointer/class type. It's a wrapper around T with some interesting 
properties. Unique!T can be implemented to only allow one, destructive, read. 
All that read does is return a value of type T.


A Unique!T can only be initialized by:

   1. a destructive read of another instance of Unique!T
   2. an expression that can be determined to generated an isolated pointer

#2 is the interesting bit. That requires some compiler support, sort of like:

 __unique(Expression)

which will allow it through if Expression is some combination of new, pure 
functions, and other Unique pointers.


There is also the issue of I know it's a unique pointer, but the compiler 
cannot guarantee that, so how do I set it? for which I propose that in @system 
functions, __unique(Expression) always says it's ok.


Note that dereferencing a Unique!T variable will always entail a destructive 
read of it. Therefore, multiple reads will require storing it into an instance 
of T. Calling a method with a Unique!T this will also require converting it into 
a T. Getting it back into a Unique!T will require some @system programming.



P.S. Yes, I know there's std.typecons.Unique, but it has a lot of holes in it, 
such as:


up.a.b;   // uh-oh, now we have another address
   // into the supposedly isolated graph!

Re: Something needs to happen with shared, and soon.


On Tuesday, 13 November 2012 at 09:11:15 UTC, luka8088 wrote:

On 12.11.2012 3:30, Walter Bright wrote:

On 11/11/2012 10:46 AM, Alex Rønne Petersen wrote:
It's starting to get outright embarrassing to talk to 
newcomers about D's
concurrency support because the most fundamental part of it 
-- the

shared type
qualifier -- does not have well-defined semantics at all.


I think a couple things are clear:

1. Slapping shared on a type is never going to make algorithms 
on that
type work in a concurrent context, regardless of what is done 
with
memory barriers. Memory barriers ensure sequential 
consistency, they do
nothing for race conditions that are sequentially consistent. 
Remember,
single core CPUs are all sequentially consistent, and still 
have major
concurrency problems. This also means that having templates 
accept

shared(T) as arguments and have them magically generate correct
concurrent code is a pipe dream.

2. The idea of shared adding memory barriers for access is not 
going to
ever work. Adding barriers has to be done by someone who knows 
what
they're doing for that particular use case, and the compiler 
inserting

them is not going to substitute.


However, and this is a big however, having shared as 
compiler-enforced
self-documentation is immensely useful. It flags where and 
when data is
being shared. So, your algorithm won't compile when you pass 
it a shared
type? That is because it is NEVER GOING TO WORK with a shared 
type. At
least you get a compile time indication of this, rather than 
random

runtime corruption.

To make a shared type work in an algorithm, you have to:

1. ensure single threaded access by aquiring a mutex
2. cast away shared
3. operate on the data
4. cast back to shared
5. release the mutex

Also, all op= need to be disabled for shared types.



This clarifies a lot, but still a lot of people get confused 
with:

http://dlang.org/faq.html#shared_memory_barriers
is it a faq error ?

and also with http://dlang.org/faq.html#shared_guarantees said, 
I come to think that the fact that the following code compiles 
is either lack of implementation, a compiler bug or a faq error 
?


//

import core.thread;

void main () {
  shared int i;
  (new Thread({ i++; })).start();
}


Um, sorry, the following code:

//

import core.thread;

void main () {
  int i;
  (new Thread({ i++; })).start();
}

Re: Something needs to happen with shared, and soon.


On 12.11.2012 3:30, Walter Bright wrote:

On 11/11/2012 10:46 AM, Alex Rønne Petersen wrote:

It's starting to get outright embarrassing to talk to newcomers about D's
concurrency support because the most fundamental part of it -- the
shared type
qualifier -- does not have well-defined semantics at all.


I think a couple things are clear:

1. Slapping shared on a type is never going to make algorithms on that
type work in a concurrent context, regardless of what is done with
memory barriers. Memory barriers ensure sequential consistency, they do
nothing for race conditions that are sequentially consistent. Remember,
single core CPUs are all sequentially consistent, and still have major
concurrency problems. This also means that having templates accept
shared(T) as arguments and have them magically generate correct
concurrent code is a pipe dream.

2. The idea of shared adding memory barriers for access is not going to
ever work. Adding barriers has to be done by someone who knows what
they're doing for that particular use case, and the compiler inserting
them is not going to substitute.


However, and this is a big however, having shared as compiler-enforced
self-documentation is immensely useful. It flags where and when data is
being shared. So, your algorithm won't compile when you pass it a shared
type? That is because it is NEVER GOING TO WORK with a shared type. At
least you get a compile time indication of this, rather than random
runtime corruption.

To make a shared type work in an algorithm, you have to:

1. ensure single threaded access by aquiring a mutex
2. cast away shared
3. operate on the data
4. cast back to shared
5. release the mutex

Also, all op= need to be disabled for shared types.



This clarifies a lot, but still a lot of people get confused with:
http://dlang.org/faq.html#shared_memory_barriers
is it a faq error ?

and also with http://dlang.org/faq.html#shared_guarantees said, I come 
to think that the fact that the following code compiles is either lack 
of implementation, a compiler bug or a faq error ?


//

import core.thread;

void main () {
  shared int i;
  (new Thread({ i++; })).start();
}

Re: Something needs to happen with shared, and soon.

Am 13.11.2012 10:14, schrieb luka8088:
 On Tuesday, 13 November 2012 at 09:11:15 UTC, luka8088 wrote:
 On 12.11.2012 3:30, Walter Bright wrote:
 On 11/11/2012 10:46 AM, Alex Rønne Petersen wrote:
 It's starting to get outright embarrassing to talk to newcomers about D's
 concurrency support because the most fundamental part of it -- the
 shared type
 qualifier -- does not have well-defined semantics at all.

 I think a couple things are clear:

 1. Slapping shared on a type is never going to make algorithms on that
 type work in a concurrent context, regardless of what is done with
 memory barriers. Memory barriers ensure sequential consistency, they do
 nothing for race conditions that are sequentially consistent. Remember,
 single core CPUs are all sequentially consistent, and still have major
 concurrency problems. This also means that having templates accept
 shared(T) as arguments and have them magically generate correct
 concurrent code is a pipe dream.

 2. The idea of shared adding memory barriers for access is not going to
 ever work. Adding barriers has to be done by someone who knows what
 they're doing for that particular use case, and the compiler inserting
 them is not going to substitute.


 However, and this is a big however, having shared as compiler-enforced
 self-documentation is immensely useful. It flags where and when data is
 being shared. So, your algorithm won't compile when you pass it a shared
 type? That is because it is NEVER GOING TO WORK with a shared type. At
 least you get a compile time indication of this, rather than random
 runtime corruption.

 To make a shared type work in an algorithm, you have to:

 1. ensure single threaded access by aquiring a mutex
 2. cast away shared
 3. operate on the data
 4. cast back to shared
 5. release the mutex

 Also, all op= need to be disabled for shared types.


 This clarifies a lot, but still a lot of people get confused with:
 http://dlang.org/faq.html#shared_memory_barriers
 is it a faq error ?

 and also with http://dlang.org/faq.html#shared_guarantees said, I come to 
 think that the fact that
 the following code compiles is either lack of implementation, a compiler bug 
 or a faq error ?

 //

 import core.thread;

 void main () {
   shared int i;
   (new Thread({ i++; })).start();
 }
 
 Um, sorry, the following code:
 
 //
 
 import core.thread;
 
 void main () {
   int i;
   (new Thread({ i++; })).start();
 }
 

Only std.concurrency (using spawn() and send()) enforces that unshared data 
cannot be pass between
threads. The core.thread module is just a low-level module that just represents 
the OS functionality.

Re: Const ref and rvalues again...

2012-11-13 Thread Era Scarecrow


On Tuesday, 13 November 2012 at 08:34:19 UTC, luka8088 wrote:
Would it ? How many functions actually change their non ref/out 
arguments ? Can you point out any existing public code that 
would be broken ?


 It would be possible that if the language became 
const-preference that a simple regex tool could be made that 
would do the conversions, thereby any code broken in this way 
could be un-broken just as easily; But that assumes you aren't 
using mixins or magic as part of your signatures.


 Somehow this reminds me a little of when I worked at a company 
where we were trying out asp as a web server; The whole VB script 
was by default 'by ref' so you littered all your functions with 
'byVal' in order for your behavior to act as you expected.



 Anyways, my take on this is consistency would be a lot more 
difficult and annoying unless you had different rules for the 
signature vs all other references... I doubt you would say 'this 
is mutable here but immutable here' type of thing. So 
assuming 'mutable' is used, then the following would be 
comparable...


//D as of now
int func(int x, int y, const ref int z) {
  int something; //mutable far more likely
  int something2;
  const int lessOften;
}

//then would become...
//if x  y aren't ever changed then mutable may be unneeded.
mutable int func(mutable int x, mutable int y, ref int z) {
  mutable int something;
  mutable int something2;
  int lessOften;  //const (once set)
}

//or for inconsistancy..
//mutable or const as a return? (Or either?)
//and which would/should you use to reverse it?
int func(mutable int x, mutable int y, ref int z) {
  int something;   //mutable
  int something2;
  const int lessOften; //const
}

 Seems in a function body you are far more likely to have mutable 
items, while in the signature you're more likely to have const 
items; But mixing them or changing how you do it would likely 
break code very easily if it isn't signature only, but it doesn't 
seem like a good idea...


 Now in the above the function may not specify 'x' is const it 
doesn't guarantees it ever changes it (but it's a local copy so 
does it matter?), but specifically specifying it may be more 
clutter than actually useful.


 All in all it seems like it would have far more confusion (and 
break code) than help; although having it prefer const versions 
of functions/methods to non-const ones should probably have a 
higher priority (Although you then couldn't have a non-const one 
unless it was as part of the struct/class constness and not the 
variables, (and ref preferred over non-ref)).

Re: I'm back

2012-11-13 Thread deadalnix


Le 13/11/2012 03:59, Andrei Alexandrescu a écrit :

On 11/12/12 6:29 PM, deadalnix wrote:

Le 13/11/2012 03:01, Andrei Alexandrescu a écrit :

On 11/12/12 5:40 PM, deadalnix wrote:

I never used moveFront and alike.


They're used by algorithms that you might be using.

Andrei


I'm not saying they are useless, or that I never used them under the
hood.


Then what is it that you are saying? Honest question.

Andrei


That mastering every range feature isn't required to work effectively 
with ranges.

Re: Const ref and rvalues again...


On 13.11.2012 11:00, Era Scarecrow wrote:

On Tuesday, 13 November 2012 at 08:34:19 UTC, luka8088 wrote:

Would it ? How many functions actually change their non ref/out
arguments ? Can you point out any existing public code that would be
broken ?


It would be possible that if the language became const-preference that a
simple regex tool could be made that would do the conversions, thereby
any code broken in this way could be un-broken just as easily; But that
assumes you aren't using mixins or magic as part of your signatures.

Somehow this reminds me a little of when I worked at a company where we
were trying out asp as a web server; The whole VB script was by default
'by ref' so you littered all your functions with 'byVal' in order for
your behavior to act as you expected.


Anyways, my take on this is consistency would be a lot more difficult
and annoying unless you had different rules for the signature vs all
other references... I doubt you would say 'this is mutable here but
immutable here' type of thing. So assuming 'mutable' is used, then
the following would be comparable...

//D as of now
int func(int x, int y, const ref int z) {
int something; //mutable far more likely
int something2;
const int lessOften;
}

//then would become...
//if x  y aren't ever changed then mutable may be unneeded.
mutable int func(mutable int x, mutable int y, ref int z) {
mutable int something;
mutable int something2;
int lessOften; //const (once set)
}

//or for inconsistancy..
//mutable or const as a return? (Or either?)
//and which would/should you use to reverse it?
int func(mutable int x, mutable int y, ref int z) {
int something; //mutable
int something2;
const int lessOften; //const
}

Seems in a function body you are far more likely to have mutable items,
while in the signature you're more likely to have const items; But
mixing them or changing how you do it would likely break code very
easily if it isn't signature only, but it doesn't seem like a good idea...

Now in the above the function may not specify 'x' is const it doesn't
guarantees it ever changes it (but it's a local copy so does it
matter?), but specifically specifying it may be more clutter than
actually useful.

All in all it seems like it would have far more confusion (and break
code) than help; although having it prefer const versions of
functions/methods to non-const ones should probably have a higher
priority (Although you then couldn't have a non-const one unless it was
as part of the struct/class constness and not the variables, (and ref
preferred over non-ref)).


Can you point out any existing public code that would be broken ?

Re: Something needs to happen with shared, and soon.


On 13.11.2012 10:20, Sönke Ludwig wrote:

Am 13.11.2012 10:14, schrieb luka8088:

On Tuesday, 13 November 2012 at 09:11:15 UTC, luka8088 wrote:

On 12.11.2012 3:30, Walter Bright wrote:

On 11/11/2012 10:46 AM, Alex Rønne Petersen wrote:

It's starting to get outright embarrassing to talk to newcomers about D's
concurrency support because the most fundamental part of it -- the
shared type
qualifier -- does not have well-defined semantics at all.


I think a couple things are clear:

1. Slapping shared on a type is never going to make algorithms on that
type work in a concurrent context, regardless of what is done with
memory barriers. Memory barriers ensure sequential consistency, they do
nothing for race conditions that are sequentially consistent. Remember,
single core CPUs are all sequentially consistent, and still have major
concurrency problems. This also means that having templates accept
shared(T) as arguments and have them magically generate correct
concurrent code is a pipe dream.

2. The idea of shared adding memory barriers for access is not going to
ever work. Adding barriers has to be done by someone who knows what
they're doing for that particular use case, and the compiler inserting
them is not going to substitute.


However, and this is a big however, having shared as compiler-enforced
self-documentation is immensely useful. It flags where and when data is
being shared. So, your algorithm won't compile when you pass it a shared
type? That is because it is NEVER GOING TO WORK with a shared type. At
least you get a compile time indication of this, rather than random
runtime corruption.

To make a shared type work in an algorithm, you have to:

1. ensure single threaded access by aquiring a mutex
2. cast away shared
3. operate on the data
4. cast back to shared
5. release the mutex

Also, all op= need to be disabled for shared types.



This clarifies a lot, but still a lot of people get confused with:
http://dlang.org/faq.html#shared_memory_barriers
is it a faq error ?

and also with http://dlang.org/faq.html#shared_guarantees said, I come to think 
that the fact that
the following code compiles is either lack of implementation, a compiler bug or 
a faq error ?

//

import core.thread;

void main () {
   shared int i;
   (new Thread({ i++; })).start();
}


Um, sorry, the following code:

//

import core.thread;

void main () {
   int i;
   (new Thread({ i++; })).start();
}



Only std.concurrency (using spawn() and send()) enforces that unshared data 
cannot be pass between
threads. The core.thread module is just a low-level module that just represents 
the OS functionality.


In that case http://dlang.org/faq.html#shared_guarantees is wrong, it is 
not a correct guarantee. Or at least that should be noted there. If 
nothing else it is confusing...

Re: I'm back

Andrei Alexandrescu wrote:
 Hi all,


 I'm back from a few long trips during which I got behind reading this
 group. I decided to mark everything as read and restart anew. If there
 are any topics that you believe have extinguished but need my
 attention, I'd be indebted if you mentioned them to me via private
 email or by replying to this.


 Thanks,

 Andrei

Hello you fucking creep... I was feeling kinda lonely for not having anyone 
to punch iin the face. Are you done with that other thing now? Are you ready 
to rumble?  Andrei...you fantasize about being in the ring and winning. Yet 
I alone am a boxer, and would put your lights out. I know  you Andrei, and I 
know you don't want to fight me  (because you know you will lose).

So  to your question, the answer is NO.

I  mean, it is not my JOB to make you a man is it? (Someone get Andrei a 
wife!)

That said, all you fucking turks wanna spar with me, bring it. ( I can't hit 
in the head a stupid lil fuck like Amdrei that SIMPLY wants to be a man).. 
Nope, you go back to key largo and siip umberella drinks you ... well 
whoever you

Re: I'm back

Andrei Alexandrescu wrote:

 I'm leaning toward doing nothing about this.



Translated: I am looking forwad to retirrment. Or, I am so burnt ot but 
you stupid sheeple actually believe what I say, I am not tired, I am a 
liar.

Re: I'm back

Andrei Alexandrescu wrote:
 Hi all,


 I'm back from a few long trips during which I got behind reading this
 group. I decided to mark everything as read and restart anew. If there
 are any topics that you believe have extinguished but need my
 attention, I'd be indebted if you mentioned them to me via private
 email or by replying to this.


 Thanks,

 Andrei

That said, I want to punch you in the face. I want to hit you in your head 
until they throw me out  of the bar.

That said, I want to punch you in the face.  Ya know? Ya thnk? Wait lets 
think about this (apparently I have !).. you are a stupid lil man and I can 
train to beat  your bitch ass into a pulp... I diress... about these taxes 
imposed  by your dick upon me can we talk?? yes property taxes.

I am thinking, let's strike a deal, I fuck you up, and you shut the fuck 
up, and I won't let your daughter suck my cock. OK, I ddn't mean that. I 
meant I WOULD let her, be free of your impo... free of you. Deal, Andrei, 
you craxy fuk?

:)

Re: Compiler bug? (alias sth this; and std.signals)

2012-11-13 Thread Joe

No one? Is this a bug, or am I overlooking something? (entirely 
possible since I didn't use D since trying it once in D1 times)


On Monday, 12 November 2012 at 11:59:50 UTC, Joe wrote:
Ok, i was trying out D and wanted to see if i could create 
something that behaves like a property but adds a change 
notification signal. Doing this, I encountered a hangup which 
might be a bug. So far I have the following:


---

import std.signals;
import std.stdio;

struct Property
{
alias get this;

int set(int v) { emit(); return data_ = v; }
int get() { return data_; }

int opAssign(int v) { return set(v); }

mixin Signal!();

private:
int data_ = 0;
}

struct Foo
{
Property prop;
}

class Observer
{
void watch()
{
writeln(Value change observed!);
}
}

---

This works:
void main()
{
Foo f;
Observer o = new Observer;
f.prop.connect(o.watch);
f.prop = 7;
}

This also works:
void main()
{
Foo f;
Observer o = new Observer;
f.prop = 7;
writeln(f.prop);
}

This never terminates:
void main()
{
Foo f;
Observer o = new Observer;
f.prop.connect(o.watch);
f.prop = 7;
writeln(f.prop);
}

Re: Immutable and unique in C#

Am 13.11.2012 09:40, schrieb Walter Bright:
 
 #2 is the interesting bit. That requires some compiler support, sort of like:
 
  __unique(Expression)
 
 which will allow it through if Expression is some combination of new, pure 
 functions, and other
 Unique pointers.
 

I just realized that using __unique(expression) vs. verifying the type must be 
unique is not really
mutually exclusive. Unique!T (or Isolated!T) could simply support both. It 
could still expose plain,
immutable or Isolated!T data fields and could still allow pure methods that 
only have these kinds of
parameters to be called. So performing one-time reads is, even in that case, 
only necessary for
certain operations.

Re: Immutable and unique in C#

On 11/13/2012 1:38 AM, Sönke Ludwig wrote:

Wouldn't it be better to handle this as a special means of construction in the
Unique struct, along
the lines of assumeUnique()? Assuming that still most functions are still
@system, this would
severely limit the verification value of the Unique type otherwise.

The trouble is that templates don't work on expression ASTs, they work on types.
Being able to determine if an expression is unique requires access to the
expression tree, currently only the compiler can do that.

Did you see my effort on this?
(http://forum.dlang.org/thread/k7orpj$1tt5$1...@digitalmars.com?page=4#post-k7rhoj:24m8h:241:40digitalmars.com)

This version, instead of requiring the initialization expression to be unique,
enforces that the
type cannot contain non-unique references.

By operating on the expression, a lot more cases can be handled.

That is, except for shared data. Allowing shared data
greatly improves its flexibility for passing data between threads.

But because it guarantees that the type cannot contain non-unique data, it can
allow multiple
dereferences and still guarantee that no references are shared. Only immutable
(or shared)
references can be extracted. Everything else can only be copied or moved,
keeping everything isolated.

Allowing shared access into the middle of something means that unique pointers
cannot be implicitly cast to immutable.

The other trouble is doing assignments into the isolated data. What if you're
assigning to a pointer, and the pointer value is pointing outside of the
isolated graph?

The result is, I think, more usable because a) shared data is allowed and b)
step-by-step
construction of unique data is possible naturally without constantly moving a
unique pointer around.
What makes the C# system usable are mostly the automatic uniqueness-recovery
rules, and I think
those can only be implemented by the compiler (setting apart AST macros ;) ).

I think we can do this with __unique(Expression), which is not a pervasive
change to the compiler, it's fairly isoloated (!). That construct would perform
the recovery. I implemented a little bit of this in NewExp::implicitConvTo().

Re: Immutable and unique in C#

I think the only way values can be extracted from Unique!T containers is by 
copying them, and those values cannot contain any non-immutable references.


A Unique!T can be implicitly cast to mutable/shared/immutable, which then grants 
direct mutable/shared/immutable access, but it won't be unique anymore.

Re: Immutable and unique in C#

Am 13.11.2012 12:00, schrieb Walter Bright:
 
 By operating on the expression, a lot more cases can be handled.

Yes, but _only_ doing that, the unique property is lost as soon as the 
expression crosses the
statement border - then the type system somehow needs to take over. But 
extending its capabilities
using this is certainly a win.

 
 That is, except for shared data. Allowing shared data
 greatly improves its flexibility for passing data between threads.

 But because it guarantees that the type cannot contain non-unique data, it 
 can allow multiple
 dereferences and still guarantee that no references are shared. Only 
 immutable (or shared)
 references can be extracted. Everything else can only be copied or moved, 
 keeping everything
 isolated.
 
 Allowing shared access into the middle of something means that unique 
 pointers cannot be implicitly
 cast to immutable.

Not to immutable, but it may still be moved to another thread without 
copying/locking etc. Since
this can be easily checked at compile time, in my current implementation, the 
freeze() method of
Isolated!T is only available if T is strongly isolated (i.e. does not contain 
shared references).

 
 The other trouble is doing assignments into the isolated data. What if you're 
 assigning to a
 pointer, and the pointer value is pointing outside of the isolated graph?
 

The trick is that an Isolated!T value only has references to immutable or other 
Isolated!U data. So
assigning to any field will never violate the isolation. Assigning to an 
Isolated!U field requires a
move().

 
 The result is, I think, more usable because a) shared data is allowed and b) 
 step-by-step
 construction of unique data is possible naturally without constantly moving 
 a unique pointer around.
 What makes the C# system usable are mostly the automatic uniqueness-recovery 
 rules, and I think
 those can only be implemented by the compiler (setting apart AST macros ;) ).
 
 I think we can do this with __unique(Expression), which is not a pervasive 
 change to the compiler,
 it's fairly isoloated (!). That construct would perform the recovery. I 
 implemented a little bit
 of this in NewExp::implicitConvTo().
 

But how can it do recovery across a statement boundary?

Anyways, it was partly a moot point on my part, as the Isolated struct can 
simply make sure to
expose only fields that are safe (i.e. POD, immutable or Isolated fields). 
Those can be freely
changed without violating isolation and thus no explicit recovery is even 
necessary. But other
fields with references to mutable or shared data are still difficult to handle.

D wiki

2012-11-13 Thread Thomas Koch

Buna Andrei,

I initiated a discussion[1] about the state of the D wiki[2].

[1] http://forum.dlang.org/thread/k6jak1$quh$1...@digitalmars.com
[2] http://www.prowiki.org/wiki4d

There were three people agreeing that the current wiki engine might be a 
cause for the bad state of the content. Nobody wants to use this engine.

Tobias Pankrath proposed the github wiki engine (free software[3]) and I 
agreed that it would be best to just enable the wiki in a new project at the 
D github account[4].

[3] https://github.com/github/gollum
[4] https://github.com/D-Programming-Language

Now we need a decision on this issue and probably somebody to turn on the 
github wiki.

Multumesc, Thomas Koch

Re: Immutable and unique in C#

Am 13.11.2012 12:08, schrieb Walter Bright:
 I think the only way values can be extracted from Unique!T containers is by 
 copying them, and those
 values cannot contain any non-immutable references.
 
 A Unique!T can be implicitly cast to mutable/shared/immutable, which then 
 grants direct
 mutable/shared/immutable access, but it won't be unique anymore.
 

Ditto

Andrei

You know I don't want to kick the shit out  of you in a  boxing ring, yes? 
I was  just saying, that sissy men like you  are the pieces of shit you 
are. So don't worry your ugly head, I got you covered. I mean, if I feel 
like punching the man   in the face, you got some ball-gowing to do Ms. 
Andrei. :P

Re: Undefined identifier WIN32_FILE_ATTRIBUTE_DATA

2012-11-13 Thread Regan Heath

On Mon, 12 Nov 2012 21:22:16 -, Martin Drašar dra...@ics.muni.cz  
wrote:



Dne 11.11.2012 21:41, Regan Heath napsal(a):
On Sun, 11 Nov 2012 08:03:40 -, creatio creatio.x...@gmail.com  
wrote:




I'm not sure if this is the correct forum. But It looks like I'm one
of the few people that ran into this. I've recently upgraded to 2.60
and been getting this error when compiling:

Error: undefined identifier WIN32_FILE_ATTRIBUTE_DATA
D:\__dev\D\dmd2\src\phobos\std\file.d530

Now I have found the thread of Walter at
http://www.digitalmars.com/d/archives/digitalmars/D/announce/D_version_of_MicroEmacs_24416.html
, but it didn't help me much to solving my problem. Does anyone have
an idea how I can fix this :-S


Try to reduce your code down to a sample which fails and post it here.

R


Hi Regan,

rdmd --eval=import std.file; --main

Environment: DMD32 D Compiler v2.060, Windows 7 Pro 32bit


I get no errors, in fact I get no output at all from that command line.

Environment: DMD32 D Compiler v2.060, Windows 7 Pro 64bit

R

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

Re: Const ref and rvalues again...

2012-11-13 Thread Era Scarecrow


On Tuesday, 13 November 2012 at 10:09:27 UTC, luka8088 wrote:

Can you point out any existing public code that would be broken?


 Off hand, no.. I'm not that familiar with a lot of the code or 
the in depth details of phoboes; However suddenly reversing what 
is mutable and what is const is bound to break a lot of things 
even unintentionally.


 Hmmm.. Does remind me of a bit of my code sometimes... Something 
went like...


 class S {
   void func(S s) {
 if (!s)
   s = new S(); //create one if not passed in.

 //process using S and s (be it new or passed in)
   }
 }

 That would certainly cause a problem.. In my own code example it 
may empty the pointer/reference if certain requirements were met, 
and then use if the class reference was set or null for later 
logic (even if the object referenced to wasn't changed...). 
Course being passed something like a string... (seems the most 
likely place you'd find it), in which case using .dup on the 
input string right back into the variable would be completely 
understandable. ie:


string someStringTransformationWithCOW(string x) {
  //if COW'd then
  x = x.dup;

  //...
  return x;
}

 Course having the input as char[] rather than string makes more 
sense for on the fly changes before returning it...

Re: I'm back


On 11/12/2012 11:09 PM, bearophile wrote:

In this thread
http://forum.dlang.org/thread/50a0eea4.7010...@webdrake.net

Joseph Rushton Wakeling suggests code like this to compile:

struct Foo(_T) {
 alias _T T;
}
void bar(FooT)(FooT foo, FooT.T x) {
}
void main() {
 Foo!int foo;
 bar(foo, 1); // line 8
}


I'm not actually suggesting that the particular syntax above necessarily ought 
to work, but I'd like an easy way to ensure that one template parameter can be 
determined from another.

I apologize

I am not  even sure if she was  Andrei's sister. Yah, I fucked her. Let's be 
real: she fucked me. Else I'd be happy and have a little house on the 
prairie. Wait, I am  bad? Because Andre's sister fucked me, nowI am bad? 
How does that go?

I didn't fuck her and it is not a product of my sperm. I feel rejected 
though. And I never hit her when we  were datung, but I'd send her to the 
moon now, huh. I cannot believe she would do me this way. WTF is the big 
fucking hurry to make someone  elsse???

I hate her.. I hate her.WTF?!

All my life, I have been alone. And now yet another stupid shit politic I 
don't know?!!!

The girl I was dating is now fullfilled with being bred? What the living 
fuck?! Are you all crazy?

I come here trying so hard NOT to hate you  wait, there  is only one 
girl  and   I am vying  for her? Is that it?

I gotta go   to bed.  Y'all suck.   I don't think   I willlbe 
able to sleep unless I say I hate you. So I hate y'all with a passion. I 
mean, I really really mean it: I hate   you. Because  y'all suck. You do 
and you know it.  Y'all suck. And I hate you. So now  I can go to  bed. 
Because now you  now that you suck and that I hate you.

OK?  You  keep  sucking, and I'll keep hatin. Deal? OK then.  I wish I 
could stay uplonger to tell you what I really think.

(Aside: I don't know if she  was  really Andrei's sister... I'm not sure I 
fucked her.. I was  so drunk!!! I dropped her   on the way out  from the 
party I was   then bad... we made it though.. to the  car.. she  kept 
saying fuck me.. I keep  remembering  I should have? Those  days, I was 
drunk all the time. Stop making me remember.

I gotta go (to  bed).

Re: Undefined identifier WIN32_FILE_ATTRIBUTE_DATA

2012-11-13 Thread Martin Drasar

On 13.11.2012 12:41, Regan Heath wrote:
 Hi Regan,

 rdmd --eval=import std.file; --main

 Environment: DMD32 D Compiler v2.060, Windows 7 Pro 32bit
 
 I get no errors, in fact I get no output at all from that command line.
 
 Environment: DMD32 D Compiler v2.060, Windows 7 Pro 64bit
 
 R

Hmm,

that is might strange. I have just downloaded D installer from the
website, installed it on Windows 7 Pro 64bit and ran the command and
this is what I got:

 std.cpuid has been deprecated. It will be removed in January 2013. Please use 
 co
 re.cpuid instead.
 C:\Program Files\D\dmd2\windows\bin\..\..\src\phobos\std\file.d(530): Error: 
 und
 efined identifier WIN32_FILE_ATTRIBUTE_DATA

Which is exactly the same error I have on 32bit machine.

Martin

Re: [OT] Ubuntu 12.10 guest in VirtualBox completely broken

2012-11-13 Thread Alix Pexton


On 12/11/2012 20:27, Alix Pexton wrote:

./update-gcc.sh

which I have tried to run, but I only got the help message or an error
depending on if I add --setup or not 

should setup-gcc be present? if not, what is the correct way to call
update-gcc?



OK, ibuclaw helped me over that hurdle over irc, it is now building (I 
think) ^^


My next stupid question, is once its compiled on the qemu chroot, how do 
I get it onto the RasPi?


A...

iota with custom boundary conditions

A small proposal -- would it be possible, without introducing lots of 
complications, to permit iota to take a template parameter for boundary 
conditions similar to that used for std.random.uniform?


So, iota![)() would give the current iota behaviour of including the start 
point but not the end; iota![] would include beginning and end; iota!(] 
would include the end but not the beginning; and iota!() would exclude both 
beginning and end.


It certainly has application in my own code where e.g. I'd like to be able to 
use,

 foreach(x; iota![](0, 1, 0.05)) {  }

i.e. to foreach across the closed interval [0, 1] with 0.05 step increments.  I 
can see similar use-cases for the open interval elsewhere, e.g. when I'm dealing 
with a function that will display asymptotic behaviour at the limit values.


Any thoughts?

Re: Undefined identifier WIN32_FILE_ATTRIBUTE_DATA

2012-11-13 Thread Regan Heath

On Tue, 13 Nov 2012 12:21:06 -, Martin Drasar dra...@ics.muni.cz  
wrote:



On 13.11.2012 12:41, Regan Heath wrote:

Hi Regan,

rdmd --eval=import std.file; --main

Environment: DMD32 D Compiler v2.060, Windows 7 Pro 32bit


I get no errors, in fact I get no output at all from that command line.

Environment: DMD32 D Compiler v2.060, Windows 7 Pro 64bit

R


Hmm,

that is might strange. I have just downloaded D installer from the
website, installed it on Windows 7 Pro 64bit and ran the command and
this is what I got:

std.cpuid has been deprecated. It will be removed in January 2013.  
Please use co

re.cpuid instead.
C:\Program Files\D\dmd2\windows\bin\..\..\src\phobos\std\file.d(530):  
Error: und

efined identifier WIN32_FILE_ATTRIBUTE_DATA


Which is exactly the same error I have on 32bit machine.


Curiouser and curiouser.  In my case I had (re)built phobos/druntime so,  
suspecting it might be causing issues I download a fresh copy of the  
installer, moved my old installation folder and replaced it with the new  
one.


I still don't get any output/errors.

If I add --force to the command line given, I get the std.cpuid  
deprecation warning, but no other output.


I stripped my PATH right back to just about nothing and that made no  
difference.


Can you get the same errors running dmd directly?  I can't seem to get it  
to output the deprecation message..


R

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

Re: I'm back


Joseph Rushton Wakeling:

I'm not actually suggesting that the particular syntax above 
necessarily ought to work, but I'd like an easy way to ensure 
that one template parameter can be determined from another.


Right. But I think that syntax is the most natural one for that.

And Hara now thinks it's an idea worth considering:
http://d.puremagic.com/issues/show_bug.cgi?id=9004#c3

Bye,
bearophile

Re: Const ref and rvalues again...

2012-11-13 Thread martin


On Tuesday, 13 November 2012 at 08:34:19 UTC, luka8088 wrote:

Your proposal isn't really related to this thread's topic


Um, Const ref and rvalues again, I suggest it to be the 
default behavior, how is this not related ?


The topic here is binding rvalues to (const) ref parameters. You, 
on the other hand, are suggesting to flip the constness of 
by-value parameters (int = val/mutable int, const int = int), 
which affects both rvalues and lvalues (no difference between 
them) and only by-value parameters.



Yes, you understood correctly:
void f (const ref int x, int y, ref int z); =
void f (int x, val int y, ref int z);

The point here is to make We need a way for a function to 
declare that it doesn't want it's argument to be copied, but it 
also doesn't care whether the argument is an rvalue or an 
lvalue.  a default behavior.


So now tell me why argument x wouldn't be copied. It's passed by 
value, so of course it is copied (lvalues)/moved (rvalues) just 
as it is now. The only difference is that the parameter won't be 
modified by f().


I guess what you furthermore implicate is that you'd expect the 
compiler to automatically pass appropriate arguments to such 
parameters by reference to avoid copying (for large structs or 
structs with non-trivial copy constructors). Such a (handy!) 
optimization is sadly not possible due to aliasing issues, e.g.:


int foo(ref int dst, const int src)
{
dst = 2*src;
return src;
}
// optimized foo():
int bar(ref int dst, const ref int src)
{
dst = 2*src;
return src;
}

int i = 1;
assert(foo(i, i) == 1  i == 2); // okay
i = 1;
assert(bar(i, i) == 2  i == 2); // wtf?!
// the const src parameter is actually modified since the
// original argument i is also used as mutable dst parameter!

Would it ? How many functions actually change their non ref/out 
arguments ? Can you point out any existing public code that 
would be broken ?


I don't want to look for examples in Phobos etc. as it should be 
trivial to imagine cases such as:


void bla(float x)
{
// restrict x to safe range [0,1]
x = max(0, min(1, x));
}

Re: iota with custom boundary conditions


Joseph Rushton Wakeling:


Any thoughts?


In general is it a good idea to use iota with floating point 
arguments?


Bye,
bearophile

Re: I'm back


On 11/13/2012 03:01 PM, bearophile wrote:

Right. But I think that syntax is the most natural one for that.


Agree. :-)


And Hara now thinks it's an idea worth considering:
http://d.puremagic.com/issues/show_bug.cgi?id=9004#c3


Excellent!  Thank you so much for bringing it to notice like this.

Re: iota with custom boundary conditions