On 06/18/2012 08:19 AM, Mehrdad wrote:
> On Monday, 18 June 2012 at 06:14:22 UTC, Matthias Walter wrote:
>> Its not, that a const method cannot modify an object, it just
>> ensures that the const method cannot modify the object *by using
>> the this-pointer*.
>
>
>
> I see...
>
>
> So that mea
On Monday, 18 June 2012 at 06:14:22 UTC, Matthias Walter wrote:
Its not, that a const method cannot modify an object, it just
ensures that the const method cannot modify the object *by
using the this-pointer*.
I see...
So that means you /can't/ tell something just by looking at a
part of
On 06/18/2012 08:04 AM, Mehrdad wrote:
> On Monday, 18 June 2012 at 06:00:11 UTC, Matthias Walter wrote:
>> On 06/18/2012 07:36 AM, Mehrdad wrote:
>>> Is it just me, or did I subvert the type system here?
>>>
>>>
>>> import std.stdio;
>>>
>>> struct Const
>>> {
>>> this(void delegate() incremen
On Monday, 18 June 2012 at 06:00:11 UTC, Matthias Walter wrote:
On 06/18/2012 07:36 AM, Mehrdad wrote:
Is it just me, or did I subvert the type system here?
import std.stdio;
struct Const
{
this(void delegate() increment)
{ this.increment = increment; }
int a;
void delegate()
On Monday, 18 June 2012 at 06:00:11 UTC, Matthias Walter wrote:
On 06/18/2012 07:36 AM, Mehrdad wrote:
Is it just me, or did I subvert the type system here?
import std.stdio;
struct Const
{
this(void delegate() increment)
{ this.increment = increment; }
int a;
void delegate()
On Monday, June 18, 2012 07:36:26 Mehrdad wrote:
> Is it just me, or did I subvert the type system here?
>
>
> import std.stdio;
>
> struct Const
> {
> this(void delegate() increment)
> { this.increment = increment; }
> int a;
> void delegate() increment;
> void oop
On 06/18/2012 07:36 AM, Mehrdad wrote:
> Is it just me, or did I subvert the type system here?
>
>
> import std.stdio;
>
> struct Const
> {
> this(void delegate() increment)
> { this.increment = increment; }
> int a;
> void delegate() increment;
> void oops() const { this.inc
Is it just me, or did I subvert the type system here?
import std.stdio;
struct Const
{
this(void delegate() increment)
{ this.increment = increment; }
int a;
void delegate() increment;
void oops() const { this.increment(); }
}
void main()
{
Const
On Sunday, 17 June 2012 at 22:39:00 UTC, Stephen Jones wrote:
I recently switched from Eclipse to monoD and found that all my
code to images etc was invalid because getcwd returns the
directory that contains the main entry code in Eclipse, but
returns the directory that contains the executable
On 6/17/12 4:47 PM, Guillaume Chatelet wrote:
On 06/17/12 18:38, Andrei Alexandrescu wrote:
However, I don't think we need to abide strictly to the nomenclature
(e.g. some of the stuff in EoP was already defined with a different
name) although some EoP names are more mathematicky (such as "Codom
On Monday, June 18, 2012 00:38:59 Stephen Jones wrote:
> I recently switched from Eclipse to monoD and found that all my
> code to images etc was invalid because getcwd returns the
> directory that contains the main entry code in Eclipse, but
> returns the directory that contains the executable in
On Jun 17, 2012 6:42 PM, "Stephen Jones" wrote:
>
> I recently switched from Eclipse to monoD and found that all my code to
images etc was invalid because getcwd returns the directory that contains
the main entry code in Eclipse, but returns the directory that contains the
executable in MonoDevelo
I recently switched from Eclipse to monoD and found that all my
code to images etc was invalid because getcwd returns the
directory that contains the main entry code in Eclipse, but
returns the directory that contains the executable in
MonoDevelop. Is there a universally consistent way of acces
On 06/17/12 18:38, Andrei Alexandrescu wrote:
> However, I don't think we need to abide strictly to the nomenclature
> (e.g. some of the stuff in EoP was already defined with a different
> name) although some EoP names are more mathematicky (such as "Codomain"
> vs. "ReturnType"). One issue is when
On Sun, Jun 17, 2012 at 6:39 PM, Timon Gehr wrote:
>> // alias Constrained!(int, (x) { return x> 0;}) Positive; // ka-boom!
>> // alias Constrained!(int, x => x> 0) Positive; // no such luck
>>
>
> I have reported this bug a few days ago:
> http://d.puremagic.com/issues/show_bug.cgi?id=8242
>
>
On 17/06/12 19:50, Artur Skawina wrote:
I took your random.d and ran with that:
[6612, 6650, 6704, 0, 6629, 6834, 6634, 6756, 6590, 6591]
[6589, 6587, 6636, 0, 6673, 6704, 6647, 6704, 6643, 6817]
[6744, 6552, 6602, 0, 6641, 6722, 6598, 6676, 6749, 6716]
[6641, 6583, 6710, 0, 6618
On 06/17/12 18:51, Joseph Rushton Wakeling wrote:
> I'm feeling a bit braindead today so I may have misunderstood your code, but
> I'm not sure your fix actually does fix the problem identified. You could
> check out Jerro's pull request for an alternative:
> https://github.com/D-Programming-Lan
On 2012-06-17 18:46, Timon Gehr wrote:
This should go straight to the bug tracker. User code is not supposed to
see the AssociativeArray rewrite.
Done: http://d.puremagic.com/issues/show_bug.cgi?id=8259
--
/Jacob Carlborg
On 06/17/2012 11:38 AM, Damian wrote:
I've noticed a few languages are adopting this, for example
Haskell: http://tryhaskell.org
Go: http://play.golang.org
those sure look a lot more polished than ideone.com
On 06/17/12 18:38, Andrei Alexandrescu wrote:
>
> This is a good idea because the traits are useful within and outside the
> algorithms discussed in EoP.
>
> However, I don't think we need to abide strictly to the nomenclature
> (e.g. some of the stuff in EoP was already defined with a different
On 06/17/12 18:41, Andrei Alexandrescu wrote:
> I'm surprised by such claims. I found EoP very easy to read.
>
> Andrei
Ok let me restate this. First, those words are originally from Stepanov
himself "This is not an easy book" is explicitly written in the inner
cover :)
Then it's not a *difficult
On 17/06/12 18:31, Joseph Rushton Wakeling wrote:
I can't work out why the compiled result would be different from the output of
rdmd
... and one restart later, the correct output is coming out. Probably should
have run rehash. :-\
On 17/06/12 17:51, Joseph Rushton Wakeling wrote:
On 17/06/12 17:08, Artur Skawina wrote:
Now the result is:
[0, 7568, 7476, 0, 7494, 7500, 7461, 7504, 7527, 7470]
ie still not quite what you'd expect...
If you've got time, you might like to pull from my master branch:
https://github.com/Web
On 6/16/12, Jacob Carlborg wrote:
> That's cheating :)
You're right, I didn't think of a non-intrusive way to do this. :)
On 17/06/12 17:08, Artur Skawina wrote:
The bug description and cause makes sense, thanks for the explanation.
But the problem is that this kind of bug inside a module which is supposed
to generate pseudo-random data makes it very hard to trust _any_ result
given back by the code...
Sure. Whe
On 6/17/12 11:38 AM, Damian wrote:
I've noticed a few languages are adopting this, for example
Haskell: http://tryhaskell.org
Go: http://play.golang.org
Will D get something like this? I find it to be of great use
with Go specifically and I'm sure it would benefit D just as much.
It's already
On 06/17/2012 06:14 PM, Jacob Carlborg wrote:
The following code shows that depending on how a function is called,
UFCS or regular syntax, the type of T is inferred differently. If I
remove the alias parameter the code behaves as expected.
string foo (alias p, T) (T t)
{
return typeof(t).st
On 6/17/12 7:23 AM, Philippe Sigaud wrote:
An obvious generalization is to template the struct on a predicate:
struct Constrained(T, alias pred) {
Nice idea, but it should be said that making the predicate opaque
prevents the implementer from taking advantage of its properties.
Andrei
On 06/17/2012 03:53 PM, Philippe Sigaud wrote:
On Sun, Jun 17, 2012 at 3:11 PM, Guillaume Chatelet
wrote:
On 06/17/12 14:23, Philippe Sigaud wrote:
void main(){
auto a = constrained!(x => x> 0)(1);
auto b = a;
auto c = b+1;
auto d = c+a;
a = b-d; // Boom!
}
Very nice
On 6/16/12 11:29 AM, Guillaume Chatelet wrote:
On 06/16/12 17:58, bearophile wrote:
Guillaume Chatelet:
A minimalistic website maintains the concepts defined so far and the
C++ code
http://www.elementsofprogramming.com/
That page looks quite interesting. I'll take a better look later (I have
On 6/16/12 10:26 AM, Guillaume Chatelet wrote:
'Elements of Programming' is an amazing book by Alexander Stepanov and
Paul McJones ( M. Stepanov is the primary designer of the C++ STL ).
[snip]
So without further ado, here is my humble first attempt
https://github.com/gchatelet/phobos/blob/trai
The following code shows that depending on how a function is called,
UFCS or regular syntax, the type of T is inferred differently. If I
remove the alias parameter the code behaves as expected.
string foo (alias p, T) (T t)
{
return typeof(t).stringof;
}
void main ()
{
string[string] a
On 06/17/12 16:37, Joseph Rushton Wakeling wrote:
> On 15/06/12 06:58, Artur Skawina wrote:
>> Considering the output of this program:
>>
>> import std.stdio;
>> import std.random;
>>
>> void main() {
>>foreach (i; 0..20)
>> writeln(randomSample([0,1,2,4,5,6,7,8,9], 3,
On Jun 17, 2012, at 3:49 AM, Gor Gyolchanyan
wrote:
> On Sun, Jun 17, 2012 at 2:34 PM, Jacob Carlborg wrote:
>> On 2012-06-17 07:15, Gor Gyolchanyan wrote:
>>>
>>> Is it possible to use the VC2010 linker with DMD? That would allow
>>> easily linking with COFF libraries and building 64 bit bina
Andrei Alexandrescu:
Would joiner help?
I don't know. I think the point of those segmented ranges is to
not hide their segmented nature (as joiner does).
- - - - - - - - - - - - - -
This paper shows a variant of the stream fusion, applied on
chunked arrays that represent strings:
"Rewri
On 06/17/12 15:53, Philippe Sigaud wrote:
> x => ... still has some problem as it's a template, but using a
> standard module-level function gives functionalities akin to X10:
>
> bool pos(int x) { return x > 0;}
> alias Constrained!(int, pos) Positive; // works
>
> // alias Constrained!(int, (in
On 15/06/12 12:48, jerro wrote:
Joseph's pull request already contains a fix for this bug but
I'm guessing it won't be merged until other issues with
randomSample are resolved.
FWIW, I think my updates can be merged first without problem -- yes, they don't
address the bigger design issues, but
On 15/06/12 06:58, Artur Skawina wrote:
Considering the output of this program:
import std.stdio;
import std.random;
void main() {
foreach (i; 0..20)
writeln(randomSample([0,1,2,4,5,6,7,8,9], 3,
Random(unpredictableSeed)));
}
I'd say the use of std.random shou
On Sun, Jun 17, 2012 at 3:11 PM, Guillaume Chatelet
wrote:
> On 06/17/12 14:23, Philippe Sigaud wrote:
>> void main(){
>> auto a = constrained!(x => x > 0)(1);
>> auto b = a;
>> auto c = b+1;
>> auto d = c+a;
>> a = b-d; // Boom!
>> }
>
> Very nice :)
The new syntax for lambdas is
On 6/17/12 1:38 AM, Philippe Sigaud wrote:
On Sat, Jun 16, 2012 at 9:22 PM, bearophile wrote:
I see. is that semantically different from this (beside being shorter)?
struct NoZero {
int value;
this(int x) { value = x; }
alias value this;
invariant() { assert(value != 0); }
}
v
On 06/17/12 14:23, Philippe Sigaud wrote:
> An obvious generalization is to template the struct on a predicate:
>
> struct Constrained(T, alias pred) {
>private T _value;
>
>invariant() { assert(pred(_value)); }
>
>this(T x) { _value = x; }
>this(Constrained c) { _value = c._valu
On Sun, Jun 17, 2012 at 10:20 AM, Guillaume Chatelet
wrote:
Nice.
You can also add:
this(NoZero nz) { _value = nz._value; }
and
ref NoZero opAssign(NoZero rhs) {
value = rhs._value;
return this;
}
this allows code like this:
a = a-a; // asserts
a = a*0; // asserts
An
On 17.06.2012 9:15, Gor Gyolchanyan wrote:
Is it possible to use the VC2010 linker with DMD? That would allow
easily linking with COFF libraries and building 64 bit binaries.
You can do it with UniLink, as it's able to link OMF & COFF together.
The problem is that there is no 64 bit object fi
On Sun, Jun 17, 2012 at 2:34 PM, Jacob Carlborg wrote:
> On 2012-06-17 07:15, Gor Gyolchanyan wrote:
>>
>> Is it possible to use the VC2010 linker with DMD? That would allow
>> easily linking with COFF libraries and building 64 bit binaries.
>
>
> No.
>
> 1. DMD can only output OMF binaries
> 2. D
On 2012-06-17 07:15, Gor Gyolchanyan wrote:
Is it possible to use the VC2010 linker with DMD? That would allow
easily linking with COFF libraries and building 64 bit binaries.
No.
1. DMD can only output OMF binaries
2. DMD cannot output 64bit code for Windows
3. DMD is not compatible with the
On 2012-06-17 08:39, Tommi wrote:
As I see it, the goal of uniform function call syntax, as described here
http://www.drdobbs.com/blogs/cpp/232700394, is to allow non-intrusively
extending the functionality of a type. I think the current
implementation comes short in accomplishing this goal on tw
On 17.06.2012 12:36, Alex Rønne Petersen wrote:
On 17-06-2012 10:22, Johannes Pfau wrote:
Am Sun, 17 Jun 2012 12:15:00 +0400
schrieb Dmitry Olshansky:
On 17.06.2012 12:04, Johannes Pfau wrote:
Am Sat, 16 Jun 2012 21:11:51 +0400
schrieb Dmitry Olshansky:
Ah and another way to go about it is:
Am Sun, 17 Jun 2012 01:10:16 -0700
schrieb Jonathan M Davis :
> I seriously question that it will _ever_ be anything worse then
> Mt19997, but if you're that worried about it, maybe you should add a
> static assert that Random is Mt19997? If you want to leave it as-is,
> then you should probably a
On 17-06-2012 10:22, Johannes Pfau wrote:
Am Sun, 17 Jun 2012 12:15:00 +0400
schrieb Dmitry Olshansky:
On 17.06.2012 12:04, Johannes Pfau wrote:
Am Sat, 16 Jun 2012 21:11:51 +0400
schrieb Dmitry Olshansky:
Ah and another way to go about it is:
union {
ubyte[16] uuid;
size_t[1
That's a *lot* more code but I think we could do something like
struct NoZero {
private int _value;
invariant() { assert(_value != 0); }
this(int x) { _value = x; }
NoZero opBinary(string op)(const ref NoZero rhs) {
return NoZero(mixin("this._value"~op~"rhs._value"));
Am Sun, 17 Jun 2012 12:15:00 +0400
schrieb Dmitry Olshansky :
> On 17.06.2012 12:04, Johannes Pfau wrote:
> > Am Sat, 16 Jun 2012 21:11:51 +0400
> > schrieb Dmitry Olshansky:
> >>
> >> Ah and another way to go about it is:
> >> union {
> >>ubyte[16] uuid;
> >>size_t[16/size_t.sizeof] by_wo
On 17.06.2012 12:04, Johannes Pfau wrote:
Am Sat, 16 Jun 2012 21:11:51 +0400
schrieb Dmitry Olshansky:
Ah and another way to go about it is:
union {
ubyte[16] uuid;
size_t[16/size_t.sizeof] by_word;
}
Isn't that an optimization which should really be done by the compiler?
It
On Sunday, June 17, 2012 09:42:40 Johannes Pfau wrote:
> Am Sat, 16 Jun 2012 16:57:25 -0700
>
> schrieb Jonathan M Davis :
> > Umm. My point was that as far as I can tell, what you're doing is
> > _identical_ to what rndGen is doing.
>
> Yes right now it's exactly the same. But there's no guarant
Am Sat, 16 Jun 2012 21:11:51 +0400
schrieb Dmitry Olshansky :
> On 16.06.2012 21:06, Dmitry Olshansky wrote:
> > On 16.06.2012 15:30, Johannes Pfau wrote:
> >> Am Tue, 12 Jun 2012 13:46:17 +0200
> >> schrieb Johannes Pfau:
> >>
> >>> Am Mon, 11 Jun 2012 13:12:49 +0200
> >>> schrieb Johannes Pfau:
Am Sat, 16 Jun 2012 16:57:25 -0700
schrieb Jonathan M Davis :
> Umm. My point was that as far as I can tell, what you're doing is
> _identical_ to what rndGen is doing.
>
Yes right now it's exactly the same. But there's no guarantee that the
'Random' alias (and therefore rndGen) will always use
On Sunday, June 17, 2012 09:04:16 Philippe Sigaud wrote:
> On Sun, Jun 17, 2012 at 8:42 AM, Jonathan M Davis
wrote:
> > It wouldn't be. No public function was called. All you did was access the
> > public member variable. Having public members and invariants at the same
> > time doesn't work very
On Sun, Jun 17, 2012 at 8:42 AM, Jonathan M Davis wrote:
> It wouldn't be. No public function was called. All you did was access the
> public member variable. Having public members and invariants at the same time
> doesn't work very well.
If I change
int value;
to
private int value;
it can s
57 matches
Mail list logo
