Re: AA reference semantics

[H. S. Teoh]

On Wed, Mar 14, 2012 at 04:20:32PM +1100, Daniel Murphy wrote:
> "H. S. Teoh"  wrote in message 
> news:mailman.652.1331699976.4860.digitalmar...@puremagic.com...
> > Is this a bug?
> >
> 
> Nope.

OK good. That means I don't have to fix my AA implementation. :-P


> > int[string] aa, bb;
> aa == bb == null

Ahh, I see.


> > bb = aa;
> same
> 
> > aa["abc"] = 123;
> A new AA is created.

OK, makes sense.


> > assert(bb["abc"] == 123); // assertion fails
> >
> 
> B is still null 

Righto.


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you 
wish you hadn't.

Re: AA reference semantics

[Daniel Murphy]

"H. S. Teoh"  wrote in message 
news:mailman.652.1331699976.4860.digitalmar...@puremagic.com...
> Is this a bug?
>

Nope.


> int[string] aa, bb;
aa == bb == null

> bb = aa;
same

> aa["abc"] = 123;
A new AA is created.


> assert(bb["abc"] == 123); // assertion fails
>

B is still null 

Re: Replacing AA's in druntime

[Daniel Murphy]

"H. S. Teoh"  wrote in message 
news:mailman.651.1331696880.4860.digitalmar...@puremagic.com...
> On Wed, Mar 14, 2012 at 12:37:08PM +1100, Daniel Murphy wrote:
>> Welcome to Hell. =D
>
> Ahhhahahaha... sounds like I leapt into the deep end of the pool without
> knowing it. :-P
>
>

Yeah, the AA implementation is the deepest part I've found in dmd.

>> Some of the things you can do with AAs are recognized by the compiler
>> during semantic and turned into druntime calls, sometimes the
>> constructs survive all the way to the glue layer (e2ir) and are turned
>> into druntime calls there and sometimes the type of an expressions is
>> magically rewritten to AssociativeArray and the methods are looked up
>> normally.  (this one caused problems with literals)
>>
>> The type needs to stay as V[K] _not_ AssociativeArray, so that error
>> messages work properly.  Something needs to be done about literals
>> too...  Don't forget template arg deduction!
>>
>> There's a function AAGetSym (or something like that) that can be
>> searched for to find where dmd emits druntime calls, but there might
>> be other places it generates them.
> [...]
>
> Alright. So now I have to dig into dmd internals to do what I want.
> Maybe I should complete the template implementation first before
> tackling this stuff. Sounds nasty. :-P  (But then again, I *did* have to
> deal with over-engineered C++ in the past, which at one point required
> making an IPC call via 6 levels of abstraction, one of which involved
> fork(), fwrite() and fread(). I doubt dmd attains to that level of
> evil.)
>
>
> T

Probably a good idea to finish it first.  It might be possible to just 
recognize AssociativeArray when printing error messages, and let the 
existing struct template code handle everything else.  Ideally syntax and 
error messages/stringof/pragma msg should be the only places where the 
compiler is actually aware AAs exist.  But this might not be that easy... 

AA reference semantics

[H. S. Teoh]

Is this a bug?

int[string] aa, bb;
bb = aa;
aa["abc"] = 123;
assert(bb["abc"] == 123);   // assertion fails

The following works:

int[string] aa, bb;
aa["def"] = 456;
bb = aa;
aa["abc"] = 123;
assert(bb["abc"] == 123);   // OK


T

-- 
Don't drink and derive. Alcohol and algebra don't mix.

Dmitry on Regular expressions

[Walter Bright]

http://www.reddit.com/r/programming/comments/quyy1/walk_through_regexen_in_the_d_programming/

Re: Regarding implementing a stable sort for Phobos

[Xinok]

On Tuesday, 13 March 2012 at 18:32:27 UTC, Xinok wrote:

On Tuesday, 13 March 2012 at 06:32:01 UTC, Xinok wrote:
I've been playing with sorting algorithms a lot in recent 
months, so I want to implement a *working* stable sort for 
Phobos which is broken at the moment. I have a working library 
and I'm still adding to it. It's much more complex than a 
simple merge sort, being over 300 lines of code at the moment.


I've implemented slicing which has improved benchmarks quite a 
bit.


It still uses O(log n log n) space. I modified the code to 
allocate up to 1KiB on the stack, and use the heap for anything 
larger. I simply marked the entry sort function as @trusted. 
The non-slicing code is still in the lib but disabled. I've yet 
to add contracts, documentation, and a unittest.


I won't be adding optimized code for arrays utilizing pointers 
as I expect the performance gain to be as little as 10%.


A second update:
http://www.mediafire.com/?gqejl17ob1ywyat

I removed the code without slicing from the lib, though I still 
retain a copy.
I added 3 unittests: A basic sort test, a stability test, and a 
CTFE test.
I added a few asserts which have helped me discover bugs in the 
past.
I only added basic documentation. I've found it difficult to 
explain to others how an in-place merge sort works, so I didn't 
bother.


I've ran the code through several tests. It works, it's stable, 
and it consistently gives good performance. So for the all 
important question: Does anybody want to implement it in 
std.algorithm for me? I've looked at the code in std.algorithm, 
and all I can tell is that sortImpl is a recursive function. I 
have no idea what it's doing or what I need to change.

Re: Replacing AA's in druntime

[H. S. Teoh]

On Wed, Mar 14, 2012 at 12:37:08PM +1100, Daniel Murphy wrote:
> Welcome to Hell. =D

Ahhhahahaha... sounds like I leapt into the deep end of the pool without
knowing it. :-P


> Some of the things you can do with AAs are recognized by the compiler
> during semantic and turned into druntime calls, sometimes the
> constructs survive all the way to the glue layer (e2ir) and are turned
> into druntime calls there and sometimes the type of an expressions is
> magically rewritten to AssociativeArray and the methods are looked up
> normally.  (this one caused problems with literals)
> 
> The type needs to stay as V[K] _not_ AssociativeArray, so that error
> messages work properly.  Something needs to be done about literals
> too...  Don't forget template arg deduction!
> 
> There's a function AAGetSym (or something like that) that can be
> searched for to find where dmd emits druntime calls, but there might
> be other places it generates them.
[...]

Alright. So now I have to dig into dmd internals to do what I want.
Maybe I should complete the template implementation first before
tackling this stuff. Sounds nasty. :-P  (But then again, I *did* have to
deal with over-engineered C++ in the past, which at one point required
making an IPC call via 6 levels of abstraction, one of which involved
fork(), fwrite() and fread(). I doubt dmd attains to that level of
evil.)


T

-- 
Жил-был король когда-то, при нём блоха жила.

Re: Replacing AA's in druntime

[H. S. Teoh]

On Tue, Mar 13, 2012 at 09:30:45PM -0500, Andrei Alexandrescu wrote:
> On 3/13/12 7:54 PM, H. S. Teoh wrote:
> >Hi all,
> >
> >My AA implementation is slowly inching closer to being ready to
> >replace aaA.d.
> 
> Great! This will need compiler restructuring, and in fact offers the
> perfect opportunity for it. I suggest you to post your implementation
> here for review first, and assume only the minimal lowerings from the
> compiler.

Currently I have it as a struct that implements AA functionality without
needing special support from the compiler (i.e., as a template library).
The only thing that needs compiler support is AA literals and internal
mapping between V[K] and AssociativeArray!(K,V) for nicer syntax and
error messages.

I didn't do anything fancy with the implementation, just used the same
algorithms as the current aaA.d, the idea being that fancy stuff can be
added later once we have successfully extricated AA's from internal
compiler dependencies.

The current code is already nicer in that it no longer needs the void*
casts and typeinfo's now that key/value types are directly accessible.
This will allow us to address some fundamental issues with aaA.d such as
key/value types that require deep traversal of references (the current
implementation of AA.toHash is broken partly because of this). Of
course, performance issues also need to be addressed eventually, such as
possible optimizations when key/value types have no external references,
in which case some operations can use byte-level representations
instead. But IMO this should be postponed till later; the main thing
right now is to fix up the compiler. Once AA's are completely in
object.d, optimizations and other fixes/improvements will be much
easier.


> Here's something that I thinks we should have:
> 
> int[string] aa;
> char[] b;
> ...
> aa[b] = 42;
> 
> The implementation should be clever enough to work, and only duplicate
> the string if it wasn't already present.
[...]

Hmm, this is something nice to have. I guess get() and opIndex*() should
allow any type that is comparable with the key type? Now that the
implementation is in a template, this should be much easier to do. :)

But while we're at it, one thing that I'd like to see is that AA key
types should be *implicitly* immutable. It makes no sense for AA keys to
be mutable, and it's syntactically painful to keep typing stuff like
string[immutable(int)[]]. Especially when mutable key types *never* make
sense anyway. So why not translate string[int[]] into
string[immutable(int)[]] implicitly? Thoughts?


T

-- 
INTEL = Only half of "intelligence".

Re: Tuple unpacking syntax [Was: Re: Multiple return values...]

[Derek Parnell]

On Wed, 14 Mar 2012 13:33:18 +1100, Kevin Cox   
wrote:


Kind of unrelated but I think that it is important to have a way to  
ignore

values also.  Leaving them bank would sufice.

(int i,,float f) = intBoringFloat();


For what its worth, the Euphoria Programming Language uses ? to signify  
ignored values.


eg.

  integer i
  atomf
  {i, ?, f} = intBoringFloat()


We felt that leaving a blank could be a source of human error (can be  
missed when reading code) and also a result of human error (accidentally  
put in a double comma).  Using an unusual glyph to signify omission was  
the compromise we came up with.


--
Derek Parnell

Re: Replacing AA's in druntime

[Jakob Bornecrantz]

On Wednesday, 14 March 2012 at 00:52:32 UTC, H. S. Teoh wrote:

Hi all,

My AA implementation is slowly inching closer to being ready to 
replace aaA.d. So far I've been writing the implementation

outside of object_.d for ease of testing & development; now I'm
ready to start moving stuff into object_.d to start working on
integration with druntime.


Hi,

If I'm understanding this correctly you are moving the entire
implementation of the AA into object.d and as such letting
programs be purview to its inner working? In sort meaning you
are making the entire AA implementation D ABI locked.

This will make it impossible to either change the AA
implementation in any ABI breaking fashion or make it impossible
to pass AA's between libraries compiled against different
versions of druntime.

Is this what we really want?

Cheers, Jakob.

Re: Replacing AA's in druntime

[Andrei Alexandrescu]

On 3/13/12 7:54 PM, H. S. Teoh wrote:

Hi all,

My AA implementation is slowly inching closer to being ready to replace
aaA.d.


Great! This will need compiler restructuring, and in fact offers the 
perfect opportunity for it. I suggest you to post your implementation 
here for review first, and assume only the minimal lowerings from the 
compiler.


Here's something that I thinks we should have:

int[string] aa;
char[] b;
...
aa[b] = 42;

The implementation should be clever enough to work, and only duplicate 
the string if it wasn't already present.



Thanks,

Andrei

Re: Tuple unpacking syntax [Was: Re: Multiple return values...]

[Kevin Cox]

Kind of unrelated but I think that it is important to have a way to ignore
values also.  Leaving them bank would sufice.

(int i,,float f) = intBoringFloat();

Re: Replacing AA's in druntime

[James Miller]

On 14 March 2012 14:37, Daniel Murphy  wrote:
> Welcome to Hell. =D

Sounds fun.

(Seasoned DF player)

--
James Miller

A thread-safe weak reference implementation

[Alex Rønne Petersen]

Hi,

This is something I hacked together today. It seems to work exactly as 
intended, and has no threading issues.


import core.atomic,
   core.memory;

private alias void delegate(Object) DEvent;
private extern (C) void rt_attachDisposeEvent(Object h, DEvent e);
private extern (C) void rt_detachDisposeEvent(Object h, DEvent e);

final class Weak(T : Object)
{
// Note: This class uses a clever trick which works fine for
// a conservative GC that was never intended to do
// compaction/copying in the first place. However, if compaction is
// ever added to D's GC, this class will break horribly. If D ever
// gets such a GC, we should push strongly for built-in weak
// references.

private size_t _object;
private size_t _ptr;
private hash_t _hash;

this(T object)
in
{
assert(object);
}
body
{
auto ptr = cast(size_t)cast(void*)object;

// We use atomics because not all architectures may guarantee
// atomic store and load of these values.
atomicStore(*cast(shared)&_object, ptr);

// Only assigned once, so no atomics.
_ptr = ptr;
_hash = typeid(T).getHash(&object);

rt_attachDisposeEvent(object, &unhook);
GC.setAttr(cast(void*)this, GC.BlkAttr.NO_SCAN);
}

@property T object()
{
auto obj = cast(T)cast(void*)atomicLoad(*cast(shared)&_object);

// We've moved obj into the GC-scanned stack space, so it's now
// safe to ask the GC whether the object is still alive. Note
// that even if the cast and assignment of the obj local
// doesn't put the object on the stack, this call will. So,
// either way, this is safe.
if (GC.addrOf(cast(void*)obj))
return obj;

return null;
}

private void unhook(Object object)
{
rt_detachDisposeEvent(object, &unhook);

// This assignment is important. If we don't null _object when
// it is collected, the check in object could return false
// positives where the GC has reused the memory for a new
// object.
atomicStore(*cast(shared)&_object, cast(size_t)0);
}

override equals_t opEquals(Object o)
{
if (this is o)
return true;

if (auto weak = cast(Weak!T)o)
return _ptr == weak._ptr;

return false;
}

override int opCmp(Object o)
{
if (auto weak = cast(Weak!T)o)
return _ptr > weak._ptr;

return 1;
}

override hash_t toHash()
{
auto obj = object;

return obj ? typeid(T).getHash(&obj) : _hash;
}

override string toString()
{
auto obj = object;

return obj ? obj.toString() : toString();
}
}

Things worth noting:

* I've chosen to make it a class for simplicity. I don't believe that 
the effort to make a struct correctly is worth it, when using weak 
references already implies GC anyway.
* The implementation relies on atomicLoad/atomicStore to use actual 
lock-prefixed instructions on x86 (and the equivalent on other 
architectures) rather than e.g. a spinlock.
* It obviously doesn't work for a compacting GC. Ideally, a compacting 
GC will have full-blown support for weak (and maybe soft) references so 
we don't have to do hacks like this one. But, until then, this is IMHO a 
necessary addition to the standard library.
* The class does not support custom overloads of opEquals() or opCmp() 
on the stored object; it always uses referential equality. It also 
stores its hash at construction time. This is necessary because a 
Weak(T) cannot sensibly be used as e.g. an AA key otherwise, because 
invariants cannot be maintained when you need to call methods on the 
contained object (which may be collected).
* Strictly speaking, the atomics aren't necessary on x86 since 
everything is size_t, and loads/stores of these are guaranteed to be 
atomic. However, I opted to be on the safe side, and also use atomics to 
stay compatible with !x86 architectures.
* I know, I haven't annotated it with any type or method qualifiers at 
all. I'm more focused on the implementation right now.
* Hacks, hacks, hacks. I know it isn't pretty, but there's no good way 
to do it in a thread-safe fashion with a conservative GC other than this.


Comments, suggestions, reviews are all *very* welcome.

--
- Alex

Re: Replacing AA's in druntime

[Daniel Murphy]

Welcome to Hell. =D

Some of the things you can do with AAs are recognized by the compiler during 
semantic and turned into druntime calls, sometimes the constructs survive 
all the way to the glue layer (e2ir) and are turned into druntime calls 
there and sometimes the type of an expressions is magically rewritten to 
AssociativeArray and the methods are looked up normally.  (this one caused 
problems with literals)

The type needs to stay as V[K] _not_ AssociativeArray, so that error 
messages work properly.  Something needs to be done about literals too... 
Don't forget template arg deduction!

There's a function AAGetSym (or something like that) that can be searched 
for to find where dmd emits druntime calls, but there might be other places 
it generates them.

Enjoy. 

Replacing AA's in druntime

[H. S. Teoh]

Hi all,

My AA implementation is slowly inching closer to being ready to replace
aaA.d. So far I've been writing the implementation outside of object_.d
for ease of testing & development; now I'm ready to start moving stuff
into object_.d to start working on integration with druntime. So I'm
wondering how the current stuff works.

Is it correct that when the compiler sees a declaration like:

int[string] aa;

it automatically translates that to struct AssociativeArray(K,V)?

What about the functions in aaA.d? I presume the compiler generates
calls to them whenever it sees an AA construct like "x in y", "x[y]",
etc?

Right now, I've implemented opBinaryRight!"in", opIndexAssign, and
opIndex; will the compiler know to invoke these methods, or will it
still go through aaA.d? I presume the latter? If so, I was thinking that
I can simply forward these calls to struct AssociativeArray, but the
problem is I wouldn't know which instance to forward it to since the
aaA.d functions only get typeinfos and an opaque pointer.

(There are also other issues, such as potential code bloat from
instantiating AssociativeArray(K,V), since everything is in the template
struct member now. But I'm not too worried about that yet; once the AA
implementation is fully dissocciated from aaA.d, it should be relatively
easy to factor out common code and/or replace the implementation with
something better.)


T

-- 
Unix was not designed to stop people from doing stupid things, because that 
would also stop them from doing clever things. -- Doug Gwyn

Re: Wanted: 128 bit integers

[Alex Rønne Petersen]

On 14-03-2012 01:34, Paul D. Anderson wrote:

I'm working on a decimal arithmetic project and I need 128 bit integers
in order to implement the decimal128 type. (The decimal value is stored
in 128 bits; the coefficient field is 114 bits, to hold values with 34
decimal digits.)

I could use BigInt (but that's overkill) or I could code them up myself,
which I'm willing to do if no alternative exists. But surely someone has
already created this type, either as part of a larger project or as some
kind of test problem, etc. Or perhaps someone would like to tackle it as
a project of their own.

I specifically need unsigned 128 bit integers, but both signed and
unsigned versions would probably have more general applications. Better
yet, if it checked for overflow, like Andrei's CheckedInt class in TDPL,
it would be more immediately useful.

This could also be the basis for a general fixed-size integer type,
where the size is specified: CheckedInt!128, CheckedInt!96, etc. I
recall having seen something like this mentioned in this forum.

So has anyone already done this? Does anyone want to take it on?

Thanks,

Paul



The D language specifies 128-bit integers: cent and ucent. They just 
aren't implemented yet...


--
- Alex

Wanted: 128 bit integers

[Paul D. Anderson]

I'm working on a decimal arithmetic project and I need 128 bit 
integers in order to implement the decimal128 type. (The decimal 
value is stored in 128 bits; the coefficient field is 114 bits, 
to hold values with 34 decimal digits.)


I could use BigInt (but that's overkill) or I could code them up 
myself, which I'm willing to do if no alternative exists. But 
surely someone has already created this type, either as part of a 
larger project or as some kind of test problem, etc. Or perhaps 
someone would like to tackle it as a project of their own.


I specifically need unsigned 128 bit integers, but both signed 
and unsigned versions would probably have more general 
applications. Better yet, if it checked for overflow, like 
Andrei's CheckedInt class in TDPL, it would be more immediately 
useful.


This could also be the basis for a general fixed-size integer 
type, where the size is specified: CheckedInt!128, CheckedInt!96, 
etc. I recall having seen something like this mentioned in this 
forum.


So has anyone already done this? Does anyone want to take it on?

Thanks,

Paul

Re: toHash => pure, nothrow, const, @safe

[Walter Bright]

On 3/13/2012 4:50 AM, Martin Nowak wrote:

Yeah, you're right. It would easily create confusing behavior.


In general, for modules a and b, all of these should work:

dmd a b

dmd b a

dmd -c a
dmd -c b

Re: Multiple return values...

[Martin Nowak]

Shall we discuss the shortcomings of his implementation? Can someone
demonstrate the details of his implementation?
 From the little examples up in the thread, it looked like you could
only declare new variables inline, but not assign out to existing ones.
I'd say this needs to be added too, and perhaps that will throw the
whole design into turmoil? ;)



We already have very flexible assignments to existing variables.

import std.typecons, std.typetuple, std.stdio;

Tuple!(int, int) foo()
{
return typeof(return)(1, 2);
}

void main()
{
int a, b;
TypeTuple!(a, b) = foo();
writeln(a, b);

TypeTuple!(a, b) = tuple(0, 1, 2)[0 .. 2];
writeln(a, b);

Tuple!(int, int) t;
t[] = TypeTuple!(a, b);
writeln(t);

TypeTuple!(a, b) = tuple(t[1], t[0]);
writeln(a, b);
}

Re: toHash => pure, nothrow, const, @safe

[Andrei Alexandrescu]

On 3/13/12 5:39 PM, kennytm wrote:

Andrei Alexandrescu  wrote:

Because in the general case functions call one another so there's no way
to figure which to look at first.

Andrei


That's no difference from template functions calling each others right?

 int a()(int x) { return x==0?1:b(x-1); }
 int b()(int x) { return x==0?1:a(x-1); }


There is. Templates are guaranteed to have the body available. Walter 
uses a recursive on-demand approach instead of a worklist approach for 
inferring attributes (worklists have an issue I forgot about).


Andrei

Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw

[H. S. Teoh]

On Tue, Mar 13, 2012 at 11:09:54AM +0100, FeepingCreature wrote:
[...]
> I've seen it argued a lot over the years (even argued it myself) that
> it's impossible to throw from Linux signal handlers. This is basically
> correct, because they constitute an interruption in the stack that
> breaks exceptions' ability to unroll properly.
> 
> However, there is a method to turn a signal handler into a regular
> function call that you can throw from.
> 
> Basically, what we need to do is similar to a stack buffer overflow
> exploit. Under Linux, the extended signal handler that is set with
> sigaction is called with three arguments: the signal, a siginfo_t* and
> a ucontext_t* as the third.
> 
> The third parameter is what we're interested in. Deep inside the
> ucontext_t struct is uc.mcontext.gregs[REG_EIP], the address of the
> instruction that caused the segfault. This is the location that
> execution returns to when the signal handler returns. By overwriting
> this location, we can turn a return into a function call.
> 
> First, gregs[REG_EAX] = gregs[REG_EIP];
> 
> We can safely assume that the function that caused the segfault
> doesn't really need its EAX anymore, so we can reuse it to reconstruct
> a proper stackframe to throw from later.
> 
> Second, gregs[REG_EIP] = cast(void*) &sigsegv_userspace_handler;
> 
> Note that the naked attribute was not used. If used, it can make this
> code slightly easier.
> 
> extern(C) void sigsegv_userspace_handler() {
>   // done implicitly
>   // asm { push ebp; }
>   // asm { mov ebp, esp; }
>   asm { mov ebx, [esp]; } // backup the pushed ebp
>   asm { mov [esp], eax; } // replace it with the correct return address
>   // which was originally left out due to the
>   // irregular way we entered this function (via a 
> ret).
>   asm { push ebx; }   // recreate the pushed ebp
>   asm { mov ebp, esp; }   // complete stackframe.
>   // originally, our stackframe (because we entered this function via a ret)
>   // was [ebp]. Now, it's [return address][ebp], as is proper for cdecl.
>   // at this point, we can safely throw
>   // (or invoke any other non-handler-safe function).
>   throw new SignalException("SIGSEGV");
> }

Nice!! So basically you allow the signal handler to return cleanly so
that we're out of signal-handling context, but overwrite the return
address so that instead of returning to where the signal happened, it
gets diverted to a special handler that reconstructs a stack frame and
then throws. Cool beans!

The only drawback is, this only works on x86 Linux. I think it should be
possible to make it work on non-x86 Linux by writing machine-specific
code along the same principles. But I'm pretty sure it won't work for
other unixen though.  They'll probably need their own system-specific
hacks.


T

-- 
If you compete with slaves, you become a slave. -- Norbert Wiener

Re: toHash => pure, nothrow, const, @safe

[bearophile]

Walter:

> Break a lot of existing code?

Invent a good deprecation strategy for toString?

The idea of modifying toString isn't new, we have discussed it more than on 
time, and I agree with the general strategy Don appreciates. As far as I know 
you didn't do much on it mostly because there were other more important things 
to do, like fixing important bugs, not because people thought the situation was 
good enough. Maybe now it's a good moment to slow down bug fixing and look for 
things more important than bugs (where "important" means "can't be done much 
later").

Bye,
bearophile

Re: Reference counted containers prototype

[Tove]

Is work ongoing on this container prototype? Sounds quite 
interesting...

Re: toHash => pure, nothrow, const, @safe

[Timon Gehr]

On 03/13/2012 11:39 PM, kennytm wrote:

Andrei Alexandrescu  wrote:

On 3/13/12 6:02 AM, Peter Alexander wrote:

On Monday, 12 March 2012 at 09:40:15 UTC, Walter Bright wrote:

On 3/12/2012 1:08 AM, Martin Nowak wrote:

What's wrong with auto-inference. Inferred attributes are only
strengthening
guarantees.


Auto-inference is currently done for lambdas and template functions -
why? - because the function's implementation is guaranteed to be
visible to the compiler. For other functions, not so, and so the
attributes must be part of the function signature.


Dumb question:

Why not auto-infer when the function body is available, and put the
inferred attributes into the automatically generated .di file?

Apologies if I've missed something completely obvious.


Because in the general case functions call one another so there's no way
to figure which to look at first.

Andrei


That's no difference from template functions calling each others right?

 int a()(int x) { return x==0?1:b(x-1); }
 int b()(int x) { return x==0?1:a(x-1); }


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

The non-trivial issue is what to do with compile-time reflection in the 
function body. I think during reflection, the function should appear 
non-annotated to itself and all functions with inferred attributes it 
calls transitively through other functions with inferred attributes 
regardless of whether or not they are later inferred. (currently 
inference fails spectacularly for anything inside a typeof expression 
anyway, therefore it is not yet that much of an issue.)


pragma(msg, typeof({writeln("hello world");})); // "void function() pure 
@safe"

Re: toHash => pure, nothrow, const, @safe

[Walter Bright]

On 3/13/2012 4:15 AM, Don Clugston wrote:

On 13/03/12 03:05, Walter Bright wrote:

On 3/12/2012 6:15 PM, Stewart Gordon wrote:

And what about toString?


Good question. What do you suggest?


Why can't we just kill that abomination?


Break a lot of existing code?

Re: Tuple unpacking syntax [Was: Re: Multiple return values...]

[foobar]

On Tuesday, 13 March 2012 at 22:26:14 UTC, bearophile wrote:

Andrei Alexandrescu:

Let me put it another way: I don't see one syntax over another 
a deal maker or deal breaker. At all.


I am usually able to follow threads, but this time I am a bit 
lost (this discussion has mixed very different topics like 
ABIs, implementation efficiency of tuples and typetuples, a 
hypothetical not-really-a-tuple third-kind of tuple, built-in 
syntax, library implementation code, etc). Is someone able and 
willing to summarize the current situation of this discussion?



[snip]
So I think we should put this thread back on the rails. Library 
implementations are not enough here. I suggest to start 
discussing about what's wrong in the proposed D syntax patch, 
solve the problems Walter has with it.


Bye,
bearophile


Yeap, I'm confused as well. D's tuple support seems to be 
completely messed up.
This reminds me - what was the semantic problem with the auto 
unpacking in a function's parameter list?
Personally, I think D ought to learn from the experts on this. 
Take a look at how FP languages implement this. E.g take a look 
at ML or Haskell for pointers.

Re: Fortran DLL and D

[Michael]

Thanks, but i still get the same.

Re: Fortran DLL and D

[Michael]

On Tuesday, 13 March 2012 at 22:42:38 UTC, Andrej Mitrovic wrote:

I don't think this can work:
alias void function(int) MyHandler;

maybe:
alias extern(C) void function(int) MyHandler;

And there's no need to call it like this: '(*mh)(1)', call it 
mh(1).


I know, it's short version.

Anyway,

object.Error: Access Violation

409960
4097D7
402BA8
402BE7
4027F7
413635

Re: Fortran DLL and D

[Tobias Brandt]

On 13 March 2012 23:53, Michael  wrote:
> On Tuesday, 13 March 2012 at 22:30:02 UTC, Tobias Brandt wrote:
>>
>> Fortran uses pass-by-ref by default. You could try
>>
>>    integer, value :: i
>>
>> in the Fortran function declaration, OR
>>
>>    *int
>>
>> in the MyHandler declaration.
>
> in case integer, value :: i or integer, intent(in) :: i
>
> same results
>
>
> in case int*
>
> int * i;
> *i=5;
> (*mh)(i);
>
> object.Error: Access Violation
> 
> 409960
> 4097D7
> 402BA8
> 402BE7
> 4027F7
> 413635
> 
>
>


You could use the C binding syntax:

SUBROUTINE fsu (i) bind(C, name = "FSU")
   real :: x
   integer, value :: i
   x = 0.025
   print *, 'The answer is x = ', x , i
END SUBROUTINE fsu

and then use extern(C) in D. That should work, but you
need a newish Fortran compiler.

Re: Fortran DLL and D

[Michael]

On Tuesday, 13 March 2012 at 22:30:02 UTC, Tobias Brandt wrote:

Fortran uses pass-by-ref by default. You could try

integer, value :: i

in the Fortran function declaration, OR

*int

in the MyHandler declaration.

in case integer, value :: i or integer, intent(in) :: i

same results


in case int*

int * i;
*i=5;
(*mh)(i);

object.Error: Access Violation

409960
4097D7
402BA8
402BE7
4027F7
413635

Re: Fortran DLL and D

[Andrej Mitrovic]

I don't think this can work:
alias void function(int) MyHandler;

maybe:
alias extern(C) void function(int) MyHandler;

And there's no need to call it like this: '(*mh)(1)', call it mh(1).

Re: Tuple unpacking syntax [Was: Re: Multiple return values...]

[Michael]

Maybe

[x, y] = func();

?

Re: toHash => pure, nothrow, const, @safe

[kennytm]

Andrei Alexandrescu  wrote:
> On 3/13/12 6:02 AM, Peter Alexander wrote:
>> On Monday, 12 March 2012 at 09:40:15 UTC, Walter Bright wrote:
>>> On 3/12/2012 1:08 AM, Martin Nowak wrote:
 What's wrong with auto-inference. Inferred attributes are only
 strengthening
 guarantees.
>>> 
>>> Auto-inference is currently done for lambdas and template functions -
>>> why? - because the function's implementation is guaranteed to be
>>> visible to the compiler. For other functions, not so, and so the
>>> attributes must be part of the function signature.
>> 
>> Dumb question:
>> 
>> Why not auto-infer when the function body is available, and put the
>> inferred attributes into the automatically generated .di file?
>> 
>> Apologies if I've missed something completely obvious.
> 
> Because in the general case functions call one another so there's no way
> to figure which to look at first.
> 
> Andrei

That's no difference from template functions calling each others right?

int a()(int x) { return x==0?1:b(x-1); }
int b()(int x) { return x==0?1:a(x-1); }

Re: Fortran DLL and D

[Tobias Brandt]

Fortran uses pass-by-ref by default. You could try

integer, value :: i

in the Fortran function declaration, OR

*int

in the MyHandler declaration.

Re: [video] A better way to program

[F i L]

On Tuesday, 13 March 2012 at 15:34:17 UTC, proxy wrote:
Very interesting talk about the merits of direct feedback in 
any creative process(first half) and being a developer 
activist(second half).


"It eventually gets going and it isn't only about game 
programming at about 18 mins in you will find the same ideas 
applied to more abstract coding and even to other engineering 
disciplines."


http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html


Great presentation. Loved the technical demonstrations, 
definitely a window into the future of software design. Even the 
philosophical portion was pretty concrete and well presented.

Re: Turning a SIGSEGV into a regular function call under Linux, allowing throw

[Vladimir Panteleev]

On Tuesday, 13 March 2012 at 10:09:55 UTC, FeepingCreature wrote:
However, there is a method to turn a signal handler into a 
regular function call that you can throw from.


Very nice!

The only similarity with a buffer overflow exploit is that we're 
overriding the continuation address. There is no execution of 
data, so it's closer to a "return-to-libc" attack. This is a very 
clean (and Neat) solution.


Here's a D implementation without inline assembler. It's 
DMD-specific due to a weirdness of its codegen.

http://dump.thecybershadow.net/20f792fa05c020e561137cfaf3d65d7a/sigthrow_32.d

The 64-bit version is a hack, in that it clobbers the last word 
on the stack. If the exception was thrown right after a stack 
frame was created, things might go ugly. The same trick as in my 
32-bit implementation (creating a new stack frame with an 
extern(C) helper) won't work here, and I don't know enough about 
x64 exception handling to know how to fix it.

http://dump.thecybershadow.net/121efc460a01fb4597926ec76352a674/sigthrow_64.d

I think something like this needs to end up in Druntime, at least 
for Linux x86 and x64.

Tuple unpacking syntax [Was: Re: Multiple return values...]

[bearophile]

Andrei Alexandrescu:

> Let me put it another way: I don't see one syntax over another a deal 
> maker or deal breaker. At all.

I am usually able to follow threads, but this time I am a bit lost (this 
discussion has mixed very different topics like ABIs, implementation efficiency 
of tuples and typetuples, a hypothetical not-really-a-tuple third-kind of 
tuple, built-in syntax, library implementation code, etc). Is someone able and 
willing to summarize the current situation of this discussion?

>From the last weeks (more like months) of intensive usage of functional-style 
>D code I really think D will really enjoy an unpacking syntax for 
>std.typecons.Tuples. Recently I have written a long post about this:

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=159627

The proposed syntax is quite simple, it's mostly implemented in a patch. The 
person that has written the patch says he's willing to add the missing part, 
for foreach looping (see below).

Walter is waiting for something, to find problems. One raw solution for this 
impasse is to apply the patch as an experiment and then look for problems. 
Practical usages helps thinking, sometimes.

In this thread I have seen something regarding problems of the patch on code 
like this, that has one already defined variable:

Tuple!(int,int) foo() { return tuple(1, 2); }
int x;
(x, int y) = foo();


If such code is a problem for the patch, then I am sure the patch author will 
improve it.

Now I am seeing a scatter()/gather library implementation. In that post of mine 
there examples like:

alias Tuple!(CTable, string, int, int) Four;
GrowableCircularQueue!Four open;
// ...
while (open.length) {
immutable item = open.pop();
immutable CTable cur = item[0];
immutable string cSol = item[1];
immutable int x = item[2];
immutable int y = item[3];


With a tuple unpacking syntax becomes:

while (open.length) {
immutable (cur, cSol, x, y) = open.pop();


Are those scatter/gather designed to solve this very very simple problem? How 
do you unpack into immutables? I don't understand.

The missing part in the DMD patch is for something like this (but the exact 
syntax for this is not yet decided):

foreach (auto (x, y); [tuple(1,2), tuple(3,4)]) {...}

How do you do this with library code?

So I think we should put this thread back on the rails. Library implementations 
are not enough here. I suggest to start discussing about what's wrong in the 
proposed D syntax patch, solve the problems Walter has with it.

Bye,
bearophile

Fortran DLL and D

[Michael]

Hi everyone)

dmd 2.058
os: win 7 64 bit
fortran compilers: gfortran, ftn95

I have a fortran code that compiled into dll:

SUBROUTINE fsu (i)
real :: x
integer :: i
x = 0.025
print *, 'The answer is x = ', x , i
END SUBROUTINE fsu

and simple D code

import std.stdio;
import core.runtime;
import std.c.windows.windows;
import core.memory;

alias void function(int) MyHandler;

void main()
{
GC.disable;
FARPROC fp;
HMODULE lib = cast(HMODULE)Runtime.loadLibrary("testf.dll");
MyHandler mh;

if (lib is null)
{
writeln("Lib!");
return;
}

fp = GetProcAddress(lib, "FSU");

if (fp is null)
{
writeln("Proc!");
writeln(GetLastError());
return;
}
mh = cast(MyHandler) fp;
(*mh)(1);
Runtime.unloadLibrary(lib);
}

and its output

The answer is x = 2.50E-02  1407551829

It's should be an 1 value instead 1407551829.

I think, trouble in param passing.
How it can be fixed? Or where to look?

Thanks)

Re: Multiple return values...

[Andrei Alexandrescu]

On 3/13/12 2:57 PM, Manu wrote:

And you think that's more readable and intuitive than: (v1, v2, v3) =
fun(); ?


Yes (e.g. when I see the commas my mind starts running in all directions 
because that's valid code nowadays that ignores v1 and v2 and keeps v3 
as an lvalue).


Let me put it another way: I don't see one syntax over another a deal 
maker or deal breaker. At all.



Andrei

Re: [draft] New std.regex walkthrough

[Dmitry Olshansky]

On 14.03.2012 0:54, H. S. Teoh wrote:

On Tue, Mar 13, 2012 at 11:27:57PM +0400, Dmitry Olshansky wrote:

For a couple of releases we have a new revamped std.regex, that as
far as I'm concerned works nicely, thanks to my GSOC commitment last
summer. Yet there was certain dark trend around std.regex/std.regexp
as both had severe bugs, missing documentation and what not, enough
to consider them unusable or dismiss prematurely.

It's about time to break this gloomy aura, and show that std.regex
is actually easy to use, that it does the thing and has some nice
extras.

Link: http://blackwhale.github.com/regular-expression.html

Comments are welcome from experts and newbies alike, in fact it
should encourage people to try out a few tricks ;)

[...]

Yay! Updated docs is always a good thing. I'd like to do some
copy-editing to make it nicer to read. (Hope you don't mind my extensive
revisions, I'm trying to make the docs as professional as possible.)
My revisions are in straight text under the quoted sections, and inline
comments are enclosed in [].



Thanks, I'm concerned with "make it nicer to read" part ;)

[... a bunch of good stuff to work through  later on ...]

--
Dmitry Olshansky

Re: [draft] New std.regex walkthrough

[Dmitry Olshansky]

On 14.03.2012 0:32, Brad Anderson wrote:

On Tue, Mar 13, 2012 at 1:27 PM, Dmitry Olshansky mailto:dmitry.o...@gmail.com>> wrote:

For a couple of releases we have a new revamped std.regex, that as
far as I'm concerned works nicely, thanks to my GSOC commitment last
summer. Yet there was certain dark trend around std.regex/std.regexp
as both had severe bugs, missing documentation and what not, enough
to consider them unusable or dismiss prematurely.

It's about time to break this gloomy aura, and show that std.regex
is actually easy to use, that it does the thing and has some nice
extras.

Link: http://blackwhale.github.com/__regular-expression.html


Comments are welcome from experts and newbies alike, in fact it
should encourage people to try out a few tricks ;)

This is intended as replacement for an article on dlang.org

about outdated (and soon to disappear) std.regexp:
http://dlang.org/regular-__expression.html


[Spoiler] one example relies on a parser bug being fixed (blush):
https://github.com/D-__Programming-Language/phobos/__pull/481

Well, it was a specific lookahead inside lookaround so that's not
severe bug ;)

P.S. I've been following through a bunch of new bug reports
recently, thanks to everyone involved :)


--
Dmitry Olshansky


Second paragraph:
- "..,expressions, though one though one should..." has too many "though
one"s

Third paragraph:
- "...keeping it's implementation..." should be "its"
- "We'll see how close to built-ins one can get this way." was kind of
confusing.  I'd consider just doing away with the distinction between
built in and non-built in regex since it's an implementation detail most
programmers who use it don't even need to know about.  Maybe say that it
is not built in and explain why that is a neat thing to have (meaning,
the language itself is powerful enough to express it in user code).

Fourth paragraph:
- "...article you'd have..." should probably be "you'll" or, preferably,
"you will".
- "...utilize it's API..." should be "its"
- "yet it's not required to get an understanding of the API." I'd
probably change this to "...yet it's not required to understand the API"

Lost track of which paragraph:
- "... that allows writing a regex pattern in it's natural notation"
another "its"
- "trying to match special characters like" I'd write "trying to match
special regex characters like" for clarity
- "over input like e.g. search or simillar" I'd remove the e.g., write
search as "search()" to show it's a function in other languages and fix
the spelling of similar :P
- "An element type is Captures for the string type being used, it is a
random access range." I just found this confusing.  Not sure what it's
trying to say.
- "I won't go into full detail of the range conception, suffice to say,"
I'd change "conception" to "concept" and remove "suffice to say". (It's
a shame we don't a range article we can link to).
- "At that time ancors like" misspelled "anchors"
- "Needless to say, one need not" I'd remove the "Needless to say,"
because I think it's actually important to say :P
- "replace(text, regex(r"([0-9]{1,2})/([0-9]{1,2})/([0-9]{4})","g"),
"--");" Is this code example correct?  It references $1, $2, etc. in the
explanatory paragraph below but they are no where to be found.
- When you are explaining named captures it sounds like you are about to
show them in the subsequent code example but you are actually showing
what it'd look like without them which was a bit confusing.
- Maybe some more words on what lookaround/lookahead do as I was lost.
- "Amdittedly, barrage of ? and ! makes regex rather obscure, more then
it's actually is. However" should be "Admittedly, the barrage of ? and !
makes the regex rather obscure, more than it actually is.".  Maybe
change "obscure" to a different adjective. Perhaps "complex looking" or
"complicated". (note I've removed the "However" as the upcoming sentence
isn't contradicting what you just said.
- "Needless to say it's", again, I think it's rather important to say :P
- "Run-time version took around 10-20us on my machine, admittedly no
statistics." here, borrow this "µ" :P.  Also, I'd get rid of "admittedly
no statistics".
- "meaningful tasks, it's features" another "its"
- "together it's major" and another :P
- "...flexible tools: match, replace, spliter" should be spelled "splitter"



Wow, thanks a lot, that sure was a through read. I'll going to carefully 
work through this list tomorrow.




Great article.  I didn't even know about the replacement delegate
feature which is something I've often wished I could use in other regex
systems.  D and Phobos need more articles like this.  We should have a
link to it from the std.regex documentation once this is a

Re: [draft] New std.regex walkthrough

[H. S. Teoh]

On Tue, Mar 13, 2012 at 11:27:57PM +0400, Dmitry Olshansky wrote:
> For a couple of releases we have a new revamped std.regex, that as
> far as I'm concerned works nicely, thanks to my GSOC commitment last
> summer. Yet there was certain dark trend around std.regex/std.regexp
> as both had severe bugs, missing documentation and what not, enough
> to consider them unusable or dismiss prematurely.
> 
> It's about time to break this gloomy aura, and show that std.regex
> is actually easy to use, that it does the thing and has some nice
> extras.
> 
> Link: http://blackwhale.github.com/regular-expression.html
> 
> Comments are welcome from experts and newbies alike, in fact it
> should encourage people to try out a few tricks ;)
[...]

Yay! Updated docs is always a good thing. I'd like to do some
copy-editing to make it nicer to read. (Hope you don't mind my extensive
revisions, I'm trying to make the docs as professional as possible.)
My revisions are in straight text under the quoted sections, and inline
comments are enclosed in [].


> Introduction
> 
> String processing is a kind of daily routine that most applications do
> in a one way or another.  It should come as no wonder that many
> programming languages have standard libraries stoked with specialized
> functions for common needs.

String processing is a common task performed by many applications. Many
programming languages come with standard libraries that are equipped
with a variety of functions for common string processing needs.


> The D programming language standard library among others offers a nice
> assortment in std.string and generic ones from std.algorithm.

The D programming language standard library also offers a nice
assortment of such functions in std.string, as well as generic functions
in std.algorithm that can also work with strings.


> Still no amount of fixed functionality could cover all needs, as
> naturally flexible text data needs flexible solutions. 

Still no amount of predefined string functions could cover all needs.
Text data is very flexible by nature, and so needs flexible solutions.


> Here is where regular expressions come in handy, often succinctly
> called as regexes.

This is where regular expressions, or regexes for short, come in.


> Simple yet powerful language for defining patterns of strings, put
> together with a substitution mechanism, forms a Swiss Army knife of
> text processing.

Regexes are a simple yet powerful language for defining patterns of
strings, and when integrated with a substitution mechanism, forms a
Swiss Army knife of text processing.


> It's considered so useful that a number of languages provides built-in
> support for regular expressions, though one though one should not jump
> to conclusion that built-in implies faster processing or more
> features. It's all about getting more convenient and friendly syntax
> for typical operations and usage patterns. 

It's considered so useful that a number of languages provides built-in
support for regular expressions. (This doesn't necessarily mean,
however, that built-in implies faster processing or more features.  It's
more a matter of providing a more convenient and friendly syntax for
typical operations and usage patterns.) 

[I think it's better to put the second part in parentheses, since it's
not really the main point of this doc.]


> The D programming language provides a standard library module
> std.regex.

[OK]


> Being a highly expressive systems language, it opens a possibility to
> get a good look and feel via core features, while keeping it's
> implementation within the language.

Being a highly expressive systems language, D allows regexes to be
implemented within the language itself, yet still have the same level of
readability and usability that a built-in implementation would provide.


> We'll see how close to built-ins one can get this way. 

We will see below how close to built-in regexes we can achieve.


> By the end of article you'd have a good understanding of regular
> expression capabilities in this library, and how to utilize it's API
> in a most straightforward way.

By the end of this article, you will have a good understanding of the
regular expression capabilities offered by this library, and how to
utilize its API in the most straightforward way.



> Examples in this article assume the reader has fairly good
> understanding of regex elements, yet it's not required to get an
> understanding of the API.

Examples in this article assume that the reader has fairly good
understanding of regex elements, but this is not required to get an
understanding of the API.

[I'll do this much for now. More to come later.]


T

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it. -- Brian W. Kernighan

Re: How about colors and terminal graphics in std.format?

[Christian Manning]

On Tuesday, 13 March 2012 at 16:05:31 UTC, Jacob Carlborg wrote:

On 2012-03-13 13:31, Christian Manning wrote:
On Tuesday, 13 March 2012 at 07:45:19 UTC, Jacob Carlborg 
wrote:

On 2012-03-13 02:36, Christian Manning wrote:

It would be great if an std.terminal contained general stuff 
for
manipulating/querying a terminal portably, as well as colour 
output, eg.
get terminal size, move cursor around, erase line... just 
things to help

with building UIs, progress bars, etc. that are easy to use.


I actually have a library for this written in C++, somewhere.


Any chance of a release? :)

I'd like to have a stab at porting it to D, when I have time, 
if you

aren't already planning to.


I have been thinking about porting it to D from time to time. I 
can see what I can do :)


Looking forward to it!

Re: [draft] New std.regex walkthrough

[Brad Anderson]

On Tue, Mar 13, 2012 at 1:27 PM, Dmitry Olshansky wrote:

> For a couple of releases we have a new revamped std.regex, that as far as
> I'm concerned works nicely, thanks to my GSOC commitment last summer. Yet
> there was certain dark trend around std.regex/std.regexp as both had severe
> bugs, missing documentation and what not, enough to consider them unusable
> or dismiss prematurely.
>
> It's about time to break this gloomy aura, and show that std.regex is
> actually easy to use, that it does the thing and has some nice extras.
>
> Link: 
> http://blackwhale.github.com/**regular-expression.html
>
> Comments are welcome from experts and newbies alike, in fact it should
> encourage people to try out a few tricks ;)
>
> This is intended as replacement for an article on dlang.org
> about outdated (and soon to disappear) std.regexp:
> http://dlang.org/regular-**expression.html
>
> [Spoiler] one example relies on a parser bug being fixed (blush):
> https://github.com/D-**Programming-Language/phobos/**pull/481
> Well, it was a specific lookahead inside lookaround so that's not severe
> bug ;)
>
> P.S. I've been following through a bunch of new bug reports recently,
> thanks to everyone involved :)
>
>
> --
> Dmitry Olshansky
>

Second paragraph:
- "..,expressions, though one though one should..." has too many "though
one"s

Third paragraph:
- "...keeping it's implementation..." should be "its"
- "We'll see how close to built-ins one can get this way." was kind of
confusing.  I'd consider just doing away with the distinction between built
in and non-built in regex since it's an implementation detail most
programmers who use it don't even need to know about.  Maybe say that it is
not built in and explain why that is a neat thing to have (meaning, the
language itself is powerful enough to express it in user code).

Fourth paragraph:
- "...article you'd have..." should probably be "you'll" or, preferably,
"you will".
- "...utilize it's API..." should be "its"
- "yet it's not required to get an understanding of the API." I'd probably
change this to "...yet it's not required to understand the API"

Lost track of which paragraph:
- "... that allows writing a regex pattern in it's natural notation"
another "its"
- "trying to match special characters like" I'd write "trying to match
special regex characters like" for clarity
- "over input like e.g. search or simillar" I'd remove the e.g., write
search as "search()" to show it's a function in other languages and fix the
spelling of similar :P
- "An element type is Captures for the string type being used, it is a
random access range." I just found this confusing.  Not sure what it's
trying to say.
- "I won't go into full detail of the range conception, suffice to say,"
I'd change "conception" to "concept" and remove "suffice to say". (It's a
shame we don't a range article we can link to).
- "At that time ancors like" misspelled "anchors"
- "Needless to say, one need not" I'd remove the "Needless to say," because
I think it's actually important to say :P
- "replace(text, regex(r"([0-9]{1,2})/([0-9]{1,2})/([0-9]{4})","g"),
"--");" Is this code example correct?  It references $1, $2, etc. in the
explanatory paragraph below but they are no where to be found.
- When you are explaining named captures it sounds like you are about to
show them in the subsequent code example but you are actually showing what
it'd look like without them which was a bit confusing.
- Maybe some more words on what lookaround/lookahead do as I was lost.
- "Amdittedly, barrage of ? and ! makes regex rather obscure, more then
it's actually is. However" should be "Admittedly, the barrage of ? and !
makes the regex rather obscure, more than it actually is.".  Maybe change
"obscure" to a different adjective. Perhaps "complex looking" or
"complicated". (note I've removed the "However" as the upcoming sentence
isn't contradicting what you just said.
- "Needless to say it's", again, I think it's rather important to say :P
- "Run-time version took around 10-20us on my machine, admittedly no
statistics." here, borrow this "µ" :P.  Also, I'd get rid of "admittedly no
statistics".
- "meaningful tasks, it's features" another "its"
- "together it's major" and another :P
- "...flexible tools: match, replace, spliter" should be spelled "splitter"


Great article.  I didn't even know about the replacement delegate feature
which is something I've often wished I could use in other regex systems.  D
and Phobos need more articles like this.  We should have a link to it from
the std.regex documentation once this is added to the website.

Regards,
Brad Anderson

Re: [draft] New std.regex walkthrough

[Dmitry Olshansky]

On 14.03.2012 0:05, bearophile wrote:

Dmitry Olshansky:


It's about time to break this gloomy aura, and show that std.regex is
actually easy to use, that it does the thing and has some nice extras.


This seems a good moment to ask people regarding this small problem, that we 
have already discussed a little in Bugizilla (there is a significant need to 
show here some Bugzilla discussions):

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



Yeah, it's prime  thing that I regret when thinking of current API.


The problem is easy to show:

import std.stdio: write, writeln;
import std.regex: regex, match;

void main() {
 string text = "abc312de";

 foreach (c; text.match("1|2|3|4"))
 write(c, " ");
 writeln();

 foreach (c; text.match(regex("1|2|3|4", "g")))
 write(c, " ");
 writeln();
}


It outputs:

["3"]
["3"] ["1"] ["2"]

In my code I have seen that usually the "g" option (that means "repeat over the
whole input") is what I want. So what do you think about making "g" the default?


I like the general idea of foreach on match to work intuitively.
Yet I'm not convinced to use extra flag as "non-global".

I'd propose to yank "g" flag entirely assuming all regex are global, but 
that breaks code in a lot of subtle ways. Problems of using global flag 
by default:


1. Generic stuff:
assert(equal(match(...), someOtherRange)); //normal regex silently 
becomes global, quite unexpectedly


2. replace that then have to be 2 funcs - replaceFirst, replaceAll or we 
are back to the problem of extra flag.


I'm thinking there is a path through opApply to allow foreach iteration 
of non-global regex as if it had global flag, yet not getting full range 
interface. It's hackish but so far it's as best as it gets.



This request is not as arbitrary as it looks, if you compare to the older API. 
See Bug 7260 for more info.





--
Dmitry Olshansky

Re: [draft] New std.regex walkthrough

[Jesse Phillips]

On Tuesday, 13 March 2012 at 19:27:59 UTC, Dmitry Olshansky wrote:
For a couple of releases we have a new revamped std.regex, that 
as far as I'm concerned works nicely, thanks to my GSOC 
commitment last summer. Yet there was certain dark trend around 
std.regex/std.regexp as both had severe bugs, missing 
documentation and what not, enough to consider them unusable or 
dismiss prematurely.


Thank you for the work Dmitry, I look forward to reading this and 
ultimately have been happy with the changes.


D has been getting a great number of face lifts on its many faces.

Re: [draft] New std.regex walkthrough

[bearophile]

Dmitry Olshansky:

> It's about time to break this gloomy aura, and show that std.regex is 
> actually easy to use, that it does the thing and has some nice extras.

This seems a good moment to ask people regarding this small problem, that we 
have already discussed a little in Bugizilla (there is a significant need to 
show here some Bugzilla discussions):

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

The problem is easy to show:

import std.stdio: write, writeln;
import std.regex: regex, match;

void main() {
string text = "abc312de";

foreach (c; text.match("1|2|3|4"))
write(c, " ");
writeln();

foreach (c; text.match(regex("1|2|3|4", "g")))
write(c, " ");
writeln();
}


It outputs:

["3"] 
["3"] ["1"] ["2"]

In my code I have seen that usually the "g" option (that means "repeat over the
whole input") is what I want. So what do you think about making "g" the default?

This request is not as arbitrary as it looks, if you compare to the older API. 
See Bug 7260 for more info.

Bye,
bearophile

Re: [draft] New std.regex walkthrough

[Dmitry Olshansky]

On 13.03.2012 23:42, Nick Sabalausky wrote:

"Dmitry Olshansky"  wrote in message
news:jjo73v$4gv$1...@digitalmars.com...

For a couple of releases we have a new revamped std.regex, that as far as
I'm concerned works nicely, thanks to my GSOC commitment last summer. Yet
there was certain dark trend around std.regex/std.regexp as both had
severe bugs, missing documentation and what not, enough to consider them
unusable or dismiss prematurely.

It's about time to break this gloomy aura, and show that std.regex is
actually easy to use, that it does the thing and has some nice extras.

Link: http://blackwhale.github.com/regular-expression.html

Comments are welcome from experts and newbies alike, in fact it should
encourage people to try out a few tricks ;)

This is intended as replacement for an article on dlang.org
about outdated (and soon to disappear) std.regexp:
http://dlang.org/regular-expression.html

[Spoiler] one example relies on a parser bug being fixed (blush):
https://github.com/D-Programming-Language/phobos/pull/481
Well, it was a specific lookahead inside lookaround so that's not severe
bug ;)

P.S. I've been following through a bunch of new bug reports recently,
thanks to everyone involved :)



Looks nice at an initial glance through. Few things I'll point out though:

- The bullet-list immediately after the text "Now, come to think of it, this
tiny sample showed a lot of useful things already:" looks like it's
outdented instead of indented. Just kinda looks a little odd.

- Speaking of the same line, I'd omit the "Now, come to think of it" part.
It sounds too "stream-of-conciousness" and not very "professional article".


Thanks, these are kind of things I intend to fix/improve/etc.
Hence the [draft] prefix.



- I'm very much in favor of using backticked strings for regexes instead of
r"", because with the latter, you can't include double-quotes, which I'd
think would be a much more common need in a regex than a backtick. Although
I understand that backticks aren't easy to make on some keyboards. (In the
US layout I have, it's just an unshifted tilde, ie, the key just to the left
of "1". I guess some people don't have a backtick key though?)



Same here, but I recall there is a movement (was it?) against backticked 
strings, including some of DPL's highly ranked members ;)
So I thought that maybe it's best to not impose my (perverted?) style on 
readers.


--
Dmitry Olshansky

Re: Multiple return values...

[Manu]

On 13 March 2012 21:40, Andrei Alexandrescu
wrote:

> On 3/13/12 1:20 PM, Manu wrote:
>
>> What value does it add over Kenji's change? Is this because Kenji's
>> change is unable to perform direct to existing variables?
>>
>
> Yes.
>
>
>  My understanding from early in the thread was that Kenji's change hides
>> the returned tuple, and performs a convenient unpack. How can you
>> perform a scatter if the tuple instance is no longer visible?
>>
>
> If I understand you correctly, you just say fun().scatter(v1, v2, v3).


Ah okay, I see.
And you think that's more readable and intuitive than: (v1, v2, v3) =
fun(); ?

Re: [video] A better way to program

[Nick Sabalausky]

"proxy"  wrote in message 
news:heezhlrlpjogvinob...@forum.dlang.org...
> On Tuesday, 13 March 2012 at 16:57:48 UTC, Vladimir Panteleev wrote:
>> On Tuesday, 13 March 2012 at 15:34:17 UTC, proxy wrote:
>>> Very interesting talk about the merits of direct feedback in any 
>>> creative process(first half) and being a developer activist(second 
>>> half).
>>>
>>> "It eventually gets going and it isn't only about game programming at 
>>> about 18 mins in you will find the same ideas applied to more abstract 
>>> coding and even to other engineering disciplines."
>>>
>>> http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html
>>
>> Could someone summarize the video?
>
> http://developers.slashdot.org/comments.pl?sid=2719385&cid=39320247

Thanks for the link.

Reading it, I'm reminded of the cvars system id was using *ages* ago. Not 
exactly the same thing, but doesn't have the downsides of the suggested 
approach.

Re: Arbitrary abbreviations in phobos considered ridiculous

[H. S. Teoh]

On Tue, Mar 13, 2012 at 12:42:47PM -0700, David Gileadi wrote:
> On 3/13/12 12:28 PM, Nick Sabalausky wrote:
> >Another thing is Flash. Almost *everyone* uses JS to embed flash. But
> >*it's not needed*! I embed Flash with pure HTML and it works
> >perfectly fine. Don't even need any server-side code!
> 
> I thought that using JS to load Flash was to avoid Eolas lawsuits.
> http://en.wikipedia.org/wiki/Eolas, Workarounds section.

Ugh. Yet another reason to hate Flash.

How I long for the day when Flash will die a long overdue horrible
death. I would s celebrate!!


T

-- 
The diminished 7th chord is the most flexible and fear-instilling chord.
Use it often, use it unsparingly, to subdue your listeners into
submission!

Re: [video] A better way to program

[sclytrack]

On 03/13/2012 05:57 PM, Vladimir Panteleev wrote:

On Tuesday, 13 March 2012 at 15:34:17 UTC, proxy wrote:

Very interesting talk about the merits of direct feedback in any
creative process(first half) and being a developer activist(second half).

"It eventually gets going and it isn't only about game programming at
about 18 mins in you will find the same ideas applied to more abstract
coding and even to other engineering disciplines."

http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html



Could someone summarize the video?




You when you use RAD, you edit the properties on the property tab. Then 
you see the immediate result in the form. Because you edit the properties.


Well here it is not the editing in the property tab but directly in the 
code itself. I know it's weird. Like the colour you get a drop down list
in the code. Or a slider that pops up in the code to modify the value. 
Totally weird.

Re: Arbitrary abbreviations in phobos considered ridiculous

[Nick Sabalausky]

"David Gileadi"  wrote in message 
news:jjo7vn$648$1...@digitalmars.com...
> On 3/13/12 12:28 PM, Nick Sabalausky wrote:
>> Another thing is Flash. Almost *everyone* uses JS to embed flash. But 
>> *it's
>> not needed*! I embed Flash with pure HTML and it works perfectly fine. 
>> Don't
>> even need any server-side code!
>
> I thought that using JS to load Flash was to avoid Eolas lawsuits. 
> http://en.wikipedia.org/wiki/Eolas, Workarounds section.

Ugh, working for the USPTO should be a capital offense. So should submitting 
an application for a software patent.

Re: Arbitrary abbreviations in phobos considered ridiculous

[David Gileadi]

On 3/13/12 12:28 PM, Nick Sabalausky wrote:

Another thing is Flash. Almost *everyone* uses JS to embed flash. But *it's
not needed*! I embed Flash with pure HTML and it works perfectly fine. Don't
even need any server-side code!


I thought that using JS to load Flash was to avoid Eolas lawsuits. 
http://en.wikipedia.org/wiki/Eolas, Workarounds section.

Re: [draft] New std.regex walkthrough

[Nick Sabalausky]

"Dmitry Olshansky"  wrote in message 
news:jjo73v$4gv$1...@digitalmars.com...
> For a couple of releases we have a new revamped std.regex, that as far as 
> I'm concerned works nicely, thanks to my GSOC commitment last summer. Yet 
> there was certain dark trend around std.regex/std.regexp as both had 
> severe bugs, missing documentation and what not, enough to consider them 
> unusable or dismiss prematurely.
>
> It's about time to break this gloomy aura, and show that std.regex is 
> actually easy to use, that it does the thing and has some nice extras.
>
> Link: http://blackwhale.github.com/regular-expression.html
>
> Comments are welcome from experts and newbies alike, in fact it should 
> encourage people to try out a few tricks ;)
>
> This is intended as replacement for an article on dlang.org
> about outdated (and soon to disappear) std.regexp:
> http://dlang.org/regular-expression.html
>
> [Spoiler] one example relies on a parser bug being fixed (blush):
> https://github.com/D-Programming-Language/phobos/pull/481
> Well, it was a specific lookahead inside lookaround so that's not severe 
> bug ;)
>
> P.S. I've been following through a bunch of new bug reports recently, 
> thanks to everyone involved :)
>

Looks nice at an initial glance through. Few things I'll point out though:

- The bullet-list immediately after the text "Now, come to think of it, this 
tiny sample showed a lot of useful things already:" looks like it's 
outdented instead of indented. Just kinda looks a little odd.

- Speaking of the same line, I'd omit the "Now, come to think of it" part. 
It sounds too "stream-of-conciousness" and not very "professional article".

- I'm very much in favor of using backticked strings for regexes instead of 
r"", because with the latter, you can't include double-quotes, which I'd 
think would be a much more common need in a regex than a backtick. Although 
I understand that backticks aren't easy to make on some keyboards. (In the 
US layout I have, it's just an unshifted tilde, ie, the key just to the left 
of "1". I guess some people don't have a backtick key though?)

Re: Multiple return values...

[Andrei Alexandrescu]

On 3/13/12 1:20 PM, Manu wrote:

What value does it add over Kenji's change? Is this because Kenji's
change is unable to perform direct to existing variables?


Yes.


My understanding from early in the thread was that Kenji's change hides
the returned tuple, and performs a convenient unpack. How can you
perform a scatter if the tuple instance is no longer visible?


If I understand you correctly, you just say fun().scatter(v1, v2, v3).


Andrei

Re: [draft] New std.regex walkthrough

[Andrei Alexandrescu]

On 3/13/12 2:27 PM, Dmitry Olshansky wrote:

For a couple of releases we have a new revamped std.regex, that as far
as I'm concerned works nicely, thanks to my GSOC commitment last summer.
Yet there was certain dark trend around std.regex/std.regexp as both had
severe bugs, missing documentation and what not, enough to consider them
unusable or dismiss prematurely.

It's about time to break this gloomy aura, and show that std.regex is
actually easy to use, that it does the thing and has some nice extras.

Link: http://blackwhale.github.com/regular-expression.html


Reddited: 
http://www.reddit.com/r/programming/comments/quyy1/walk_through_regexen_in_the_d_programming/



Andrei

Re: Multiple return values...

[Andrei Alexandrescu]

On 3/13/12 2:07 PM, Jose Armando Garcia wrote:

On Tue, Mar 13, 2012 at 9:07 AM, Andrei Alexandrescu
  wrote:

On 3/13/12 10:48 AM, Manu wrote:


float t;
...
(myStruct.pos, t, _, int err) = intersectThings();




This can be checked at compile time. The D compiler can check that the
number of arguments and the types match.


scatter() can also be compile-time checked. I left that to a runtime 
assert for more flexibility, but probably more checking is better 
particularly because skip allows skipping some values.



I actually find the scatter syntax better than this. Anyway, I hope you'll
agree there's not much difference pragmatically.



Correct if I am wrong but the scatter and gather functions cannot
check that the number of arguments and their type match at compile
time.


Just replace the two assert()s with static assert or a template constraint.


Andrei

Re: Arbitrary abbreviations in phobos considered ridiculous

[Nick Sabalausky]

"Nick Sabalausky"  wrote in message 
news:jjmmh3$9jb$1...@digitalmars.com...
> "Adam D. Ruppe"  wrote in message 
> news:oxkxtvkuybdommyer...@forum.dlang.org...
>> On Tuesday, 13 March 2012 at 04:24:45 UTC, Nick Sabalausky wrote:
>>> 2. On the web, animation means JS.
>>
>> css3 does animations that are pretty easy to use,
>> degrade well, and tend to be fast. Moreover css
>> is where it belongs anyway - it is pure presentation.
>>
>
> Interesting, I had no idea! Thanks for the tip :)
>
>> Far, far superior to the JS crap.
>>
>
> Yea, there's a lot of things that are much better done in CSS that a lot 
> of people don't even know about. For example, most rollovers are easily 
> doable in pure CSS. But there's a lot stuff out there (paricularly things 
> created in Adobe's "software") that use JS for rollovers, which doesn't 
> even work as well (even with JS on).
>

Another thing is Flash. Almost *everyone* uses JS to embed flash. But *it's 
not needed*! I embed Flash with pure HTML and it works perfectly fine. Don't 
even need any server-side code! (You probably need JS to tell the user when 
they don't have Flash or, in some cases, when they don't have a new enough 
version, and suggest a download link. But including those features with JS 
still does *nothing* to prevent you from making the applet run without JS. 
And...It's not even a fallback! It's just embedding with method A instead of 
method B. And method A is, frankly, dead-simple.)

[draft] New std.regex walkthrough

[Dmitry Olshansky]

For a couple of releases we have a new revamped std.regex, that as far 
as I'm concerned works nicely, thanks to my GSOC commitment last summer. 
Yet there was certain dark trend around std.regex/std.regexp as both had 
severe bugs, missing documentation and what not, enough to consider them 
unusable or dismiss prematurely.


It's about time to break this gloomy aura, and show that std.regex is 
actually easy to use, that it does the thing and has some nice extras.


Link: http://blackwhale.github.com/regular-expression.html

Comments are welcome from experts and newbies alike, in fact it should 
encourage people to try out a few tricks ;)


This is intended as replacement for an article on dlang.org
about outdated (and soon to disappear) std.regexp:
http://dlang.org/regular-expression.html

[Spoiler] one example relies on a parser bug being fixed (blush):
https://github.com/D-Programming-Language/phobos/pull/481
Well, it was a specific lookahead inside lookaround so that's not severe 
bug ;)


P.S. I've been following through a bunch of new bug reports recently, 
thanks to everyone involved :)



--
Dmitry Olshansky

Re: Arbitrary abbreviations in phobos considered ridiculous

[Nick Sabalausky]

"Nick Sabalausky"  wrote in message 
news:jjo65v$305$1...@digitalmars.com...
> "Ary Manzana"  wrote in message 
> news:jjne58$1ouf$1...@digitalmars.com...
>> On 03/13/2012 02:14 AM, H. S. Teoh wrote:
>>> On Mon, Mar 12, 2012 at 10:35:54PM -0400, Nick Sabalausky wrote:
 "Jonathan M Davis"  wrote in message
 news:mailman.572.1331601463.4860.digitalmar...@puremagic.com...
>>> [...]
> All I'm saying is that if it makes sense for the web developer to
> use javascript given what they're trying to do, it's completely
> reasonable to expect that their users will have javascript enabled
> (since virtually everyone does). If there's a better tool for the
> job which is reasonably supported, then all the better. And if it's
> easy to provide a workaround for the lack of JS at minimal effort,
> then great. But given the fact that only a very small percentage of
> your user base is going to have JS disabled, it's not unreasonable
> to require it and not worry about the people who disable it if
> that's what you want to do.
>

 Personally, I disagree with the notion that non-JS versions are a
 "workaround".
>>> [...]
>>>
>>> Me too. To me, non-JS versions are the *baseline*, and JS versions are
>>> enchancements. To treat JS versions as baseline and non-JS versions as
>>> "workaround" is just so completely backwards.
>>
>> While I don't agree that non-JS is the baseline (because most if not all 
>> browsers come with JS enabled by default, so why would you want to 
>> disable javascript for?), I'm starting to understand that providing both 
>> non-JS and JS versions is useful.
>>
>> At least so that:
>>  - Some users don't go mad when they can't use it, and then realise it's 
>> because JS is disabled
>>  - And for the above reason, not to loose reputation to those people :-P
>>
>> But if people didn't have an option to disable JS, we wouldn't have this 
>> discussion.[...]
>>
>
> Bullcrap. If people didn't have an option to disable JS, there'd be a lot 
> more people using *very* *VERY* old browsers, and that would piss of 
> *cough*modern*cough* webdevs even more.
>
> The problem isn't that JS *can* be disabled. Some people *just don't want 
> it*:
>
> When they disable JS, yea, ok, on *some* sites they get a *slighty worse* 
> user experience with, say, posting a comment. But it *also* gives them a 
> *far BETTER* user experience on all those sites that misuse and overuse 
> JS. It also increases security.

Oh, and with JS disabled, it's impossible for sites *cough*GitHub*cough* to 
break the back button.

>The idea that JS-enabled pages are "just simply better" is patently false: 
>Yes, *some* are *slightly* better, but many are *much* worse (no matter how 
>good their respective developers believe themselves to be. *Everyone* 
>believes "Oh, well, when *I* use it, it works very well." I'm sure the 
>Reddit developers have fooled themselves into thinking their site is 
>reasonably fast).
>
> 

Re: Arbitrary abbreviations in phobos considered ridiculous

[Nick Sabalausky]

"Ary Manzana"  wrote in message 
news:jjne58$1ouf$1...@digitalmars.com...
>
> But if people didn't have an option to disable JS, we wouldn't have this 
> discussion. I think it as having an option to disable CSS.
>

That's not even an accurate comparison anyway. Disabling CSS never does much 
to improve things, and usually it'll just make things *far* worse. People 
don't fuck up CSS nearly to the extent that they fuck up JS. Hell, CSS 
*can't* be fucked up as badly as JS can be. The "no JS == no CSS" comparison 
is like saying "Disabling JS is like disabling vowels". No, no it isn't like 
that. Not remotely.

Negative integer modulo/division

[bearophile]

When I translate Python code to D I sometimes need in D the different integer 
division and the different modulo operation of Python3. They give different 
results with the operands are negative:

Python2 code:

for x in xrange(-10, 1):
print x, "", x % 3, "", x // 3


Python output:

-10  2  -4
-9  0  -3
-8  1  -3
-7  2  -3
-6  0  -2
-5  1  -2
-4  2  -2
-3  0  -1
-2  1  -1
-1  2  -1
0  0  0



D code:

import std.stdio;
void main() {
foreach (x; -10 .. 1)
writeln(x, "  ", x % 3, "  ", x / 3);
}


D output:

-10  -1  -3
-9  0  -3
-8  -2  -2
-7  -1  -2
-6  0  -2
-5  -2  -1
-4  -1  -1
-3  0  -1
-2  -2  0
-1  -1  0
0  0  0



For the modulus I sometimes use:
((x % y) + y) % y

So I suggest to add both simple functions to Phobos, possibly as efficient 
compiler intrinsics (this means inlined asm).


It seems Ada and CommonLisp have functions for both needs:
http://en.wikipedia.org/wiki/Modulo_operation

I have also seen this Wikipedia page doesn't tell (it has a "?") about what % 
does on floating point values.

Bye,
bearophile

Re: Arbitrary abbreviations in phobos considered ridiculous

[Nick Sabalausky]

"Ary Manzana"  wrote in message 
news:jjne58$1ouf$1...@digitalmars.com...
> On 03/13/2012 02:14 AM, H. S. Teoh wrote:
>> On Mon, Mar 12, 2012 at 10:35:54PM -0400, Nick Sabalausky wrote:
>>> "Jonathan M Davis"  wrote in message
>>> news:mailman.572.1331601463.4860.digitalmar...@puremagic.com...
>> [...]
 All I'm saying is that if it makes sense for the web developer to
 use javascript given what they're trying to do, it's completely
 reasonable to expect that their users will have javascript enabled
 (since virtually everyone does). If there's a better tool for the
 job which is reasonably supported, then all the better. And if it's
 easy to provide a workaround for the lack of JS at minimal effort,
 then great. But given the fact that only a very small percentage of
 your user base is going to have JS disabled, it's not unreasonable
 to require it and not worry about the people who disable it if
 that's what you want to do.

>>>
>>> Personally, I disagree with the notion that non-JS versions are a
>>> "workaround".
>> [...]
>>
>> Me too. To me, non-JS versions are the *baseline*, and JS versions are
>> enchancements. To treat JS versions as baseline and non-JS versions as
>> "workaround" is just so completely backwards.
>
> While I don't agree that non-JS is the baseline (because most if not all 
> browsers come with JS enabled by default, so why would you want to disable 
> javascript for?), I'm starting to understand that providing both non-JS 
> and JS versions is useful.
>
> At least so that:
>  - Some users don't go mad when they can't use it, and then realise it's 
> because JS is disabled
>  - And for the above reason, not to loose reputation to those people :-P
>
> But if people didn't have an option to disable JS, we wouldn't have this 
> discussion.[...]
>

Bullcrap. If people didn't have an option to disable JS, there'd be a lot 
more people using *very* *VERY* old browsers, and that would piss of 
*cough*modern*cough* webdevs even more.

The problem isn't that JS *can* be disabled. Some people *just don't want 
it*:

When they disable JS, yea, ok, on *some* sites they get a *slighty worse* 
user experience with, say, posting a comment. But it *also* gives them a 
*far BETTER* user experience on all those sites that misuse and overuse JS. 
It also increases security. The idea that JS-enabled pages are "just simply 
better" is patently false: Yes, *some* are *slightly* better, but many are 
*much* worse (no matter how good their respective developers believe 
themselves to be. *Everyone* believes "Oh, well, when *I* use it, it works 
very well." I'm sure the Reddit developers have fooled themselves into 
thinking their site is reasonably fast).

Re: Multiple return values...

[Jose Armando Garcia]

On Tue, Mar 13, 2012 at 9:07 AM, Andrei Alexandrescu
 wrote:
> On 3/13/12 10:48 AM, Manu wrote:
>>
>> float t;
>> ...
>> (myStruct.pos, t, _, int err) = intersectThings();
>

This can be checked at compile time. The D compiler can check that the
number of arguments and the types match.

>
> I actually find the scatter syntax better than this. Anyway, I hope you'll
> agree there's not much difference pragmatically.
>

Correct if I am wrong but the scatter and gather functions cannot
check that the number of arguments and their type match at compile
time.

> Andrei
>
>

Re: [video] A better way to program

[Brad Anderson]

On Tue, Mar 13, 2012 at 12:34 PM, Brad Anderson  wrote:

> On Tue, Mar 13, 2012 at 10:57 AM, Vladimir Panteleev <
> vladi...@thecybershadow.net> wrote:
>
>> On Tuesday, 13 March 2012 at 15:34:17 UTC, proxy wrote:
>>
>>> Very interesting talk about the merits of direct feedback in any
>>> creative process(first half) and being a developer activist(second half).
>>>
>>> "It eventually gets going and it isn't only about game programming at
>>> about 18 mins in you will find the same ideas applied to more abstract
>>> coding and even to other engineering disciplines."
>>>
>>> http://www.i-programmer.info/**news/112-theory/3900-a-better-**
>>> way-to-program.html
>>>
>>
>> Could someone summarize the video?
>>
>
> It's basically a very slick argument for interactive coding.  His demos
> are all pretty neat but you have to watch it to get the full effect.
>
> Regards,
> Brad Anderson
>

A word of warning though.  He goes on, and on, and on about the philosophy
of design in a rather self important way that I don't think our profession
of software developers deserves (over other makers of tools).  Can you
imagine the manufacturer of a hammer spending hours talking about the
philosophy of tool design and the unique connection between the the hammer
and the hammerer that some change to the tool fosters? Instead they just
list concrete improvements; more durable, better striking head, lighter
weight, etc.

Apple has really done a number on the minds and egos of young designers
(for better or worse).

Regards,
Brad Anderson

Re: Regarding implementing a stable sort for Phobos

[Jesse Phillips]

On Tuesday, 13 March 2012 at 14:31:59 UTC, Andrei Alexandrescu 
wrote:

On 3/13/12 1:31 AM, Xinok wrote:
- I wrote it to sort random-access ranges *without* slicing, 
but I think
the exclusion of slicing makes it slower. I'm writing a 
separate
implementation which uses slicing and I'll keep it if it's 
much faster.


Having random access implies having slicing.


Currently it can not be assumed that isRandomAccessRange has 
slicing:


http://dlang.org/phobos/std_range.html#isRandomAccessRange

Maybe it should be a requirement?

It seems to me that Bidirectional ranges can't be infinite, and 
by extension Random Access ranges too. But slicing could be 
supported on an infinite range. So hasSlicing is still useful, 
but I think could be a good requirement on RA ranges.

Re: Regarding implementing a stable sort for Phobos

[Xinok]

On Tuesday, 13 March 2012 at 06:32:01 UTC, Xinok wrote:
I've been playing with sorting algorithms a lot in recent 
months, so I want to implement a *working* stable sort for 
Phobos which is broken at the moment. I have a working library 
and I'm still adding to it. It's much more complex than a 
simple merge sort, being over 300 lines of code at the moment.


I've implemented slicing which has improved benchmarks quite a 
bit.


Sorting a random array of 1 million uints:
Phobos Unstable Sort - 132ms
Phobos   Stable Sort - 2037ms
Proposed Stable Sort - 187ms

Sorting a random array of 1 million strings:
Phobos Unstable Sort - 1228ms
Phobos   Stable Sort - 3516ms
Proposed Stable Sort - 1178ms

It still uses O(log n log n) space. I modified the code to 
allocate up to 1KiB on the stack, and use the heap for anything 
larger. I simply marked the entry sort function as @trusted. The 
non-slicing code is still in the lib but disabled. I've yet to 
add contracts, documentation, and a unittest.


I won't be adding optimized code for arrays utilizing pointers as 
I expect the performance gain to be as little as 10%.


You can download the preliminary lib here:
http://www.mediafire.com/?ux49x30dj483dqg

Re: [video] A better way to program

[Brad Anderson]

On Tue, Mar 13, 2012 at 10:57 AM, Vladimir Panteleev <
vladi...@thecybershadow.net> wrote:

> On Tuesday, 13 March 2012 at 15:34:17 UTC, proxy wrote:
>
>> Very interesting talk about the merits of direct feedback in any creative
>> process(first half) and being a developer activist(second half).
>>
>> "It eventually gets going and it isn't only about game programming at
>> about 18 mins in you will find the same ideas applied to more abstract
>> coding and even to other engineering disciplines."
>>
>> http://www.i-programmer.info/**news/112-theory/3900-a-better-**
>> way-to-program.html
>>
>
> Could someone summarize the video?
>

It's basically a very slick argument for interactive coding.  His demos are
all pretty neat but you have to watch it to get the full effect.

Regards,
Brad Anderson

Re: Multiple return values...

[Manu]

On 13 March 2012 19:25, Andrei Alexandrescu
wrote:

> On 3/13/12 12:02 PM, Manu wrote:
>
>> There's a few finicky differences. I'm still of the understanding (and I
>> may be wrong, still mystified by some of D's more complicated template
>> syntax) that once you give the returned tuple a name, it is structurally
>> bound to the stack. At that point, passing any member by-ref to any
>> function must conservatively commit the entire tuple to the stack. This
>> behaviour won't be intuitive to most users, and can be easily avoided;
>> by obscuring the Tuple from user visibility, they can only access the
>> returned values through their independant output assignments, which
>> guarantees the independence of each returned item.
>>
>
> Here we go moving the goalposts again.


I don't see how? I'm just saying that I don't think they are pragmatically
identical.

Syntactically, scatter can't declare new variables inline (?), it also
>> uses additional lines of code (1 + as many variables as you need to
>> declare), which is very disruptive to flow.
>>
>
> This is in addition to Kenji's change.
>

What value does it add over Kenji's change? Is this because Kenji's change
is unable to perform direct to existing variables?
My understanding from early in the thread was that Kenji's change hides the
returned tuple, and performs a convenient unpack. How can you perform a
scatter if the tuple instance is no longer visible?

What people want from MRV is to capture the returned
>> values independently. If I /wanted/ to capture the returned Tuple (the
>>
>> extremely rare case), I'd rather do that explicitly, something like this:
>> auto t = tuple(mrvFunc());
>>
>
> No. Tuple stays together by default and is expanded explicitly. This is
> not negotiable.
>

Then I think you commit to polluting the common case with wordy redundant
noise. Why is it so important?
If it were expanded by default, all you need to do it put a tuple
constructor around it to wrap it up again.
It creates semantic multi-assignment problems I suspect? This is what I
reckon needs to be addressed to make the implementation really nice.

scatter/gather is nice and simple, I'll take it in the mean time, but I
>> think it would be a shame for it to stop there longer term...
>> That said though, it's all still nothing to me without at least a
>> promise on the ABI :) .. And I feel that should ideally come in the form
>> of a language policy/promise that this feature will be 'efficient' (or
>> at very least, not /inefficient/ as it is now), and leave it to compiler
>>
>> implementations to concur with that promise, ie, failing to be
>> 'standards' compliant if they fail to do so.
>>
>
> This is not for me to promise.


Sure, but it'd be good to get a weigh in on that issue from Walter, and
others, Iain?

Re: [video] A better way to program

[proxy]

On Tuesday, 13 March 2012 at 16:57:48 UTC, Vladimir Panteleev 
wrote:

On Tuesday, 13 March 2012 at 15:34:17 UTC, proxy wrote:
Very interesting talk about the merits of direct feedback in 
any creative process(first half) and being a developer 
activist(second half).


"It eventually gets going and it isn't only about game 
programming at about 18 mins in you will find the same ideas 
applied to more abstract coding and even to other engineering 
disciplines."


http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html


Could someone summarize the video?


http://developers.slashdot.org/comments.pl?sid=2719385&cid=39320247

Re: Breaking backwards compatiblity

[Simen Kjærås]

On Tue, 13 Mar 2012 06:45:12 +0100, H. S. Teoh   
wrote:



On Tue, Mar 13, 2012 at 04:10:20AM +0100, Simen Kjærås wrote:

On Tue, 13 Mar 2012 03:50:49 +0100, Nick Sabalausky  wrote:

[...]

>D is great for physics programming. Now you can have much, much more
>than 26 variables :)

True, though mostly, you'd just change to using Greek letters, right?


And Russian. And extended Latin. And Chinese (try exhausting that one!).
And a whole bunch of other stuff that you may not have known even
existed.


I know Unicode covers a lot more than just Greek. I didn't know the usage
of Chinese was very common among physicists, though. :p



Finally we can use θ for angles, alias ulong ℕ...


+1.

Come to think of it, I wonder if it's possible to write a large D
program using only 1-letter identifiers. After all, Unicode has enough
alphabetic characters that you could go for a long, long time before you
exhausted them all. (The CJK block will be especially resilient to
exhaustion.) :-)


63,207[1] designated characters thus far[2]. Add in module names and other
'namespaces', and I'd say that should be no problem at all. As long as
your head doesn't explode, that is.

[1] http://unicode.org/alloc/CurrentAllocation.html

[2] Yeah, not all of those are valid identifiers.

Re: Regarding implementing a stable sort for Phobos

[bearophile]

Andrei Alexandrescu:

> it's about elements for which 
> comparisons do a lot of work because they have common prefixes. Consider:
> 
> auto arr = [ "aaa", "aab", "aac", "aad" ];
> sort!((a, b) => a > b)(arr);
> 
> There will be a lot of redundant prefix comparisons because the sorting 
> method doesn't have information about the common prefixes.

As a benchmark for this new sorting algorithm I suggest to use a poor's man BWT 
(http://en.wikipedia.org/wiki/Burrows%E2%80%93Wheeler_transform ). The purpose 
here is not to create the most efficient BWT.

Bye,
bearophile

Re: toHash => pure, nothrow, const, @safe

[Martin Nowak]

On Tue, 13 Mar 2012 04:40:01 +0100, Andrei Alexandrescu  
 wrote:


I think the three others have a special regime because pointers to them  
must be saved for the sake of associative arrays. toString is used only  
generically,

 Andrei


Adding a special case for AAs is not a good idea but
these operators are indeed special and should have
a defined behavior.
Requiring pureness for comparison for example is good
for all kind of generic algorithms.

Re: Multiple return values...

[Andrei Alexandrescu]

On 3/13/12 12:02 PM, Manu wrote:

There's a few finicky differences. I'm still of the understanding (and I
may be wrong, still mystified by some of D's more complicated template
syntax) that once you give the returned tuple a name, it is structurally
bound to the stack. At that point, passing any member by-ref to any
function must conservatively commit the entire tuple to the stack. This
behaviour won't be intuitive to most users, and can be easily avoided;
by obscuring the Tuple from user visibility, they can only access the
returned values through their independant output assignments, which
guarantees the independence of each returned item.


Here we go moving the goalposts again.


Syntactically, scatter can't declare new variables inline (?), it also
uses additional lines of code (1 + as many variables as you need to
declare), which is very disruptive to flow.


This is in addition to Kenji's change.


What people want from MRV is to capture the returned
values independently. If I /wanted/ to capture the returned Tuple (the
extremely rare case), I'd rather do that explicitly, something like this:
auto t = tuple(mrvFunc());


No. Tuple stays together by default and is expanded explicitly. This is 
not negotiable.



scatter/gather is nice and simple, I'll take it in the mean time, but I
think it would be a shame for it to stop there longer term...
That said though, it's all still nothing to me without at least a
promise on the ABI :) .. And I feel that should ideally come in the form
of a language policy/promise that this feature will be 'efficient' (or
at very least, not /inefficient/ as it is now), and leave it to compiler
implementations to concur with that promise, ie, failing to be
'standards' compliant if they fail to do so.


This is not for me to promise.


Andrei

Re: Regarding implementing a stable sort for Phobos

[deadalnix]

Le 13/03/2012 17:38, Xinok a écrit :

On Tuesday, 13 March 2012 at 16:04:55 UTC, deadalnix wrote:

Le 13/03/2012 16:08, Xinok a écrit :

On Tuesday, 13 March 2012 at 09:32:49 UTC, deadalnix wrote:

Le 13/03/2012 10:19, Xinok a écrit :

Would you mind sharing your smoothsort? I haven't implemented one
myself
and I'd love to test it out.


It is on github :
https://github.com/deadalnix/Dsort/blob/master/sort/smooth.d


Thanks. I found a couple cases where it performs better, but overall,
the overhead of the algorithm seems to be too much and most other
algorithms performed better.


smooth sort is intended to be used on semi sorted data (like
transparent polygons on a 3D scene). Ideal to keep some data sorted.

It also have a guarantee to run in O(n*log(n)). But qsort variation
(like we have in phobos) is faster in the general case.


It only performs well if there aren't many elements to move around. For
example, I took a sorted list with 1 million elements, and appended 64
random elements. Smoothsort was the second slowest, only marginally
beating heap sort. My natural merge sort was 27x faster.


Yes, that being said, my implementation use multiple swap where move 
would have been more appropriate, and don't implement some improvements.


Merge sort is also known to be very fast (it is default is some 
langauges) but trigger memory allocation, something that some cannot afford.


Definitively, this is something we should have in phobos.

Re: Multiple return values...

[Manu]

On 13 March 2012 18:07, Andrei Alexandrescu
wrote:

> On 3/13/12 10:48 AM, Manu wrote:
>
>> float t;
>> ...
>> (myStruct.pos, t, _, int err) = intersectThings();
>>
>
> I actually find the scatter syntax better than this. Anyway, I hope you'll
> agree there's not much difference pragmatically.


There's a few finicky differences. I'm still of the understanding (and I
may be wrong, still mystified by some of D's more complicated template
syntax) that once you give the returned tuple a name, it is structurally
bound to the stack. At that point, passing any member by-ref to any
function must conservatively commit the entire tuple to the stack. This
behaviour won't be intuitive to most users, and can be easily avoided; by
obscuring the Tuple from user visibility, they can only access the returned
values through their independant output assignments, which guarantees the
independence of each returned item.

Syntactically, scatter can't declare new variables inline (?), it also uses
additional lines of code (1 + as many variables as you need to declare),
which is very disruptive to flow. Maths-y code should be un-cluttered and
read sequentially. Having to put extra lines in to munge un-related things
really ruins the code IMO ('t' is of no consequence to the user, pollutes
their namespace, gets in the way with extra lines, etc).
What people want from MRV is to capture the returned values independently.
If I *wanted* to capture the returned Tuple (the extremely rare case), I'd
rather do that explicitly, something like this:
auto t = tuple(mrvFunc());

scatter/gather is nice and simple, I'll take it in the mean time, but I
think it would be a shame for it to stop there longer term...
That said though, it's all still nothing to me without at least a promise
on the ABI :) .. And I feel that should ideally come in the form of a
language policy/promise that this feature will be 'efficient' (or at very
least, not *inefficient* as it is now), and leave it to compiler
implementations to concur with that promise, ie, failing to be 'standards'
compliant if they fail to do so.

Re: [video] A better way to program

[Vladimir Panteleev]

On Tuesday, 13 March 2012 at 15:34:17 UTC, proxy wrote:
Very interesting talk about the merits of direct feedback in 
any creative process(first half) and being a developer 
activist(second half).


"It eventually gets going and it isn't only about game 
programming at about 18 mins in you will find the same ideas 
applied to more abstract coding and even to other engineering 
disciplines."


http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html


Could someone summarize the video?

Re: toHash => pure, nothrow, const, @safe

[H. S. Teoh]

On Tue, Mar 13, 2012 at 11:06:00AM -0500, Andrei Alexandrescu wrote:
> On 3/13/12 10:47 AM, deadalnix wrote:
> >This problem is pretty close to garbage collection. Let's use pure as
> >example, but it work with other qualifier too.
> >
> >function are marked pure, impure, or pure given all function called
> >are pure (possibly pure). Then you go throw all possibly pure
> >function and if it call an impure function, they mark it impure. When
> >you don't mark any function as impure on a loop, you can mark all
> >remaining possibly pure functions as pure.
> 
> Certain analyses can be done using the so-called worklist approach.
> The analysis can be pessimistic (initially marking all functions as
> not carrying the property analyzed and gradually proving some do carry
> it) or optimistic (the other way around). The algorithm ends when the
> worklist is empty. This approach is well-studied and probably ought
> more coverage in compiler books. I learned about it in a graduate
> compiler class.
[...]

I have an idea.

Instead of making potentially risky changes to the compiler, or changes
with unknown long-term consequences, what about an external tool (or a
new compiler option) that performs this analysis and saves it into a
file, say in json format or something?

So we run the analysis on druntime, and it tells us exactly which
functions can be marked pure, const, whatever, then we can (1) look
through the list to see if functions that *should* be pure aren't, then
investigate why and (possibly) fix the problem; (2) annotate all
functions in druntime just by going through the list, without needing to
manually fix one function, find out it breaks 5 other functions, fix
those functions, find another 25 broken, etc..

We can also run this on phobos, cleanup whatever functions aren't marked
pure, and then go through the list and annotate everything in one shot.

Now that I think of it, it seems quite silly that we should be agonizing
over the amount of manual work needed to annotate druntime and phobos,
when the compiler already has all the necessary information to automate
most of the tedious work.


T

-- 
It is not the employer who pays the wages. Employers only handle the
money. It is the customer who pays the wages. -- Henry Ford

Re: Regarding implementing a stable sort for Phobos

[Xinok]

On Tuesday, 13 March 2012 at 16:11:05 UTC, Andrei Alexandrescu 
wrote:

On 3/13/12 10:54 AM, Sean Kelly wrote:
How does the built-in sort do?  I ask because the sort routine 
I
wrote works the same way, which is optimized for ranges with a 
lot of

common elements.


It's not about common (equal) elements, it's about elements for 
which comparisons do a lot of work because they have common 
prefixes. Consider:


auto arr = [ "aaa", "aab", "aac", "aad" ];
sort!((a, b) => a > b)(arr);

There will be a lot of redundant prefix comparisons because the 
sorting method doesn't have information about the common 
prefixes.


Trie-based sorting is a more efficient method for ranges of 
ranges, see e.g. http://en.wikipedia.org/wiki/Burstsort.



Andrei


Rather than a sort function, I think we'd benefit more from Trie 
in std.container. If implemented correctly, it could be self 
sorting like RedBlackTree.

Re: Regarding implementing a stable sort for Phobos

[Xinok]

On Tuesday, 13 March 2012 at 16:04:55 UTC, deadalnix wrote:

Le 13/03/2012 16:08, Xinok a écrit :

On Tuesday, 13 March 2012 at 09:32:49 UTC, deadalnix wrote:

Le 13/03/2012 10:19, Xinok a écrit :
Would you mind sharing your smoothsort? I haven't 
implemented one myself

and I'd love to test it out.


It is on github :
https://github.com/deadalnix/Dsort/blob/master/sort/smooth.d


Thanks. I found a couple cases where it performs better, but 
overall,
the overhead of the algorithm seems to be too much and most 
other

algorithms performed better.


smooth sort is intended to be used on semi sorted data (like 
transparent polygons on a 3D scene). Ideal to keep some data 
sorted.


It also have a guarantee to run in O(n*log(n)). But qsort 
variation (like we have in phobos) is faster in the general 
case.


It only performs well if there aren't many elements to move 
around. For example, I took a sorted list with 1 million 
elements, and appended 64 random elements. Smoothsort was the 
second slowest, only marginally beating heap sort. My natural 
merge sort was 27x faster.

Re: toHash => pure, nothrow, const, @safe

[deadalnix]

Le 13/03/2012 17:06, Andrei Alexandrescu a écrit :

On 3/13/12 10:47 AM, deadalnix wrote:

This problem is pretty close to garbage collection. Let's use pure as
example, but it work with other qualifier too.

function are marked pure, impure, or pure given all function called are
pure (possibly pure). Then you go throw all possibly pure function and
if it call an impure function, they mark it impure. When you don't mark
any function as impure on a loop, you can mark all remaining possibly
pure functions as pure.


Certain analyses can be done using the so-called worklist approach. The
analysis can be pessimistic (initially marking all functions as not
carrying the property analyzed and gradually proving some do carry it)
or optimistic (the other way around). The algorithm ends when the
worklist is empty. This approach is well-studied and probably ought more
coverage in compiler books. I learned about it in a graduate compiler
class.

However, the discussion was about availability of the body. A
worklist-based approach would need all functions that call one another
regardless of module. That makes the analysis interprocedural, i.e.
difficult on large codebases.


Andrei


I expect the function we are talking about here not to call almost all 
the codebase. It would be scary.

Re: Regarding implementing a stable sort for Phobos

[Andrei Alexandrescu]

On 3/13/12 10:54 AM, Sean Kelly wrote:

How does the built-in sort do?  I ask because the sort routine I
wrote works the same way, which is optimized for ranges with a lot of
common elements.


It's not about common (equal) elements, it's about elements for which 
comparisons do a lot of work because they have common prefixes. Consider:


auto arr = [ "aaa", "aab", "aac", "aad" ];
sort!((a, b) => a > b)(arr);

There will be a lot of redundant prefix comparisons because the sorting 
method doesn't have information about the common prefixes.


Trie-based sorting is a more efficient method for ranges of ranges, see 
e.g. http://en.wikipedia.org/wiki/Burstsort.



Andrei

Re: toHash => pure, nothrow, const, @safe

[Andrei Alexandrescu]

On 3/13/12 10:47 AM, deadalnix wrote:

This problem is pretty close to garbage collection. Let's use pure as
example, but it work with other qualifier too.

function are marked pure, impure, or pure given all function called are
pure (possibly pure). Then you go throw all possibly pure function and
if it call an impure function, they mark it impure. When you don't mark
any function as impure on a loop, you can mark all remaining possibly
pure functions as pure.


Certain analyses can be done using the so-called worklist approach. The 
analysis can be pessimistic (initially marking all functions as not 
carrying the property analyzed and gradually proving some do carry it) 
or optimistic (the other way around). The algorithm ends when the 
worklist is empty. This approach is well-studied and probably ought more 
coverage in compiler books. I learned about it in a graduate compiler class.


However, the discussion was about availability of the body. A 
worklist-based approach would need all functions that call one another 
regardless of module. That makes the analysis interprocedural, i.e. 
difficult on large codebases.



Andrei

Re: Multiple return values...

[Andrei Alexandrescu]

On 3/13/12 10:48 AM, Manu wrote:

float t;
...
(myStruct.pos, t, _, int err) = intersectThings();


I actually find the scatter syntax better than this. Anyway, I hope 
you'll agree there's not much difference pragmatically.


Andrei

Re: How about colors and terminal graphics in std.format?

[Jacob Carlborg]

On 2012-03-13 13:31, Christian Manning wrote:

On Tuesday, 13 March 2012 at 07:45:19 UTC, Jacob Carlborg wrote:

On 2012-03-13 02:36, Christian Manning wrote:


It would be great if an std.terminal contained general stuff for
manipulating/querying a terminal portably, as well as colour output, eg.
get terminal size, move cursor around, erase line... just things to help
with building UIs, progress bars, etc. that are easy to use.


I actually have a library for this written in C++, somewhere.


Any chance of a release? :)

I'd like to have a stab at porting it to D, when I have time, if you
aren't already planning to.


I have been thinking about porting it to D from time to time. I can see 
what I can do :)


--
/Jacob Carlborg

Re: Regarding implementing a stable sort for Phobos

[deadalnix]

Le 13/03/2012 16:08, Xinok a écrit :

On Tuesday, 13 March 2012 at 09:32:49 UTC, deadalnix wrote:

Le 13/03/2012 10:19, Xinok a écrit :

Would you mind sharing your smoothsort? I haven't implemented one myself
and I'd love to test it out.


It is on github :
https://github.com/deadalnix/Dsort/blob/master/sort/smooth.d


Thanks. I found a couple cases where it performs better, but overall,
the overhead of the algorithm seems to be too much and most other
algorithms performed better.

While some need to be rewritten, I have a slew of algorithms if you want
them for your project.


smooth sort is intended to be used on semi sorted data (like transparent 
polygons on a 3D scene). Ideal to keep some data sorted.


It also have a guarantee to run in O(n*log(n)). But qsort variation 
(like we have in phobos) is faster in the general case.

Re: toHash => pure, nothrow, const, @safe

[Alex Rønne Petersen]

On 13-03-2012 16:56, deadalnix wrote:

Le 13/03/2012 01:50, Walter Bright a écrit :

On 3/12/2012 4:11 AM, deadalnix wrote:

For struct, we have inference,


? No we don't.



Ok my mistake. So why not dig in that direction ?


so most of the time attributes will correct.
const pure nothrow @safe are something we want, but is it something we
want to
enforce ?


Yes, because they are referred to by TypeInfo, and that's fairly useless
if it isn't const etc.


I always though that TypeInfo is a poor substitute for metaprograming
and compile time reflexion.


Yes, and in some cases, it doesn't even work right; i.e. you can declare 
certain opCmp and opEquals signatures that work fine for ==, >, <, etc 
but don't get emitted to the TypeInfo metadata, and vice versa. It's a mess.


--
- Alex

Re: Regarding implementing a stable sort for Phobos

[Sean Kelly]

I forgot to mention that my routine uses the same basic algorithm as the 
built-in sort. 

On Mar 13, 2012, at 8:54 AM, Sean Kelly  wrote:

> How does the built-in sort do?  I ask because the sort routine I wrote works 
> the same way, which is optimized for ranges with a lot of common elements. 
> 
> On Mar 13, 2012, at 7:33 AM, Andrei Alexandrescu 
>  wrote:
> 
>> On 3/13/12 4:02 AM, Xinok wrote:
>>> On Tuesday, 13 March 2012 at 06:53:30 UTC, Chad J wrote:
 Hey, I'd love to see more sorting algorithms in phobos. Being stuck
 with one seems kind of... wrong.
>>> 
>>> Things like this are better left to 3rd party libs. Phobos already has
>>> two, a stable and unstable sort, which fulfill 99% of cases.
>> 
>> I think we need a good sort for ranges of ranges (e.g. array of string). 
>> Right now sort() does pretty badly on arrays of strings with large common 
>> prefixes.
>> 
>> Andrei
>> 

Re: Regarding implementing a stable sort for Phobos

[Sean Kelly]

How does the built-in sort do?  I ask because the sort routine I wrote works 
the same way, which is optimized for ranges with a lot of common elements. 

On Mar 13, 2012, at 7:33 AM, Andrei Alexandrescu 
 wrote:

> On 3/13/12 4:02 AM, Xinok wrote:
>> On Tuesday, 13 March 2012 at 06:53:30 UTC, Chad J wrote:
>>> Hey, I'd love to see more sorting algorithms in phobos. Being stuck
>>> with one seems kind of... wrong.
>> 
>> Things like this are better left to 3rd party libs. Phobos already has
>> two, a stable and unstable sort, which fulfill 99% of cases.
> 
> I think we need a good sort for ranges of ranges (e.g. array of string). 
> Right now sort() does pretty badly on arrays of strings with large common 
> prefixes.
> 
> Andrei
> 

Re: toHash => pure, nothrow, const, @safe

[deadalnix]

Le 13/03/2012 01:50, Walter Bright a écrit :

On 3/12/2012 4:11 AM, deadalnix wrote:

For struct, we have inference,


? No we don't.



Ok my mistake. So why not dig in that direction ?


so most of the time attributes will correct.
const pure nothrow @safe are something we want, but is it something we
want to
enforce ?


Yes, because they are referred to by TypeInfo, and that's fairly useless
if it isn't const etc.


I always though that TypeInfo is a poor substitute for metaprograming 
and compile time reflexion.

Re: Regarding implementing a stable sort for Phobos

[Xinok]

On Tuesday, 13 March 2012 at 14:31:59 UTC, Andrei Alexandrescu 
wrote:

On 3/13/12 1:31 AM, Xinok wrote:
- It's a natural merge sort, which is faster on partially 
sorted lists,

and adds little overhead for mostly random lists.
- It uses O(log n log n) additional space for merging.


That's 1024 when n is 4 billion. I think you can safely 
approximate it with alloca or a fixed-size stack-allocated 
array.


How about stack allocated for small lists, and heap allocated for 
larger lists? e.g. Limit the stack to 1KiB and use the heap for 
anything larger.


- I wrote it to sort random-access ranges *without* slicing, 
but I think
the exclusion of slicing makes it slower. I'm writing a 
separate
implementation which uses slicing and I'll keep it if it's 
much faster.


Having random access implies having slicing.

- To avoid multiple allocations, the user can allocate their 
own

temporary memory and pass it to the sort function.


If you need different allocation strategies, I suggest you make 
it a policy (like stability is).


- I decided against using pointers. While I could use them to 
write
highly optimized code for arrays, pointers can't be used in 
safe code

and don't work very well in CTFE at the moment.


Perhaps it's best to have two distinct implementations guarded 
by if (__ctfe). The runtime implementation can be @trusted.


If the performance gain is great enough, I'll consider doing that.

Is it worth keeping the implementation *without* slicing? Many 
functions
in Phobos do require slicing, including the unstable sort, and 
I think

most random-access ranges do or could support slicing.


No need.


I'll leave it out of Phobos.

What would you prefer in terms of memory usage vs performance? 
O(n/2)

space is optimal for performance, O(1) (in-place) requires zero
allocations but is slower, and O(log n log n) provides a good 
balance.


The latter rounded up to a constant sounds best.

Should I implement concurrency? Merge sort is very easy to 
parallelize,

and being in-place or natural doesn't change this fact.


Let's save that for std.parallel_algorithm.


I'll leave it out of Phobos for now.

Re: toHash => pure, nothrow, const, @safe

[deadalnix]

Le 13/03/2012 15:46, Andrei Alexandrescu a écrit :

On 3/13/12 6:02 AM, Peter Alexander wrote:

On Monday, 12 March 2012 at 09:40:15 UTC, Walter Bright wrote:

On 3/12/2012 1:08 AM, Martin Nowak wrote:

What's wrong with auto-inference. Inferred attributes are only
strengthening
guarantees.


Auto-inference is currently done for lambdas and template functions -
why? - because the function's implementation is guaranteed to be
visible to the compiler. For other functions, not so, and so the
attributes must be part of the function signature.


Dumb question:

Why not auto-infer when the function body is available, and put the
inferred attributes into the automatically generated .di file?

Apologies if I've missed something completely obvious.


Because in the general case functions call one another so there's no way
to figure which to look at first.

Andrei


This problem is pretty close to garbage collection. Let's use pure as 
example, but it work with other qualifier too.


function are marked pure, impure, or pure given all function called are 
pure (possibly pure). Then you go throw all possibly pure function and 
if it call an impure function, they mark it impure. When you don't mark 
any function as impure on a loop, you can mark all remaining possibly 
pure functions as pure.

Re: Multiple return values...

[Manu]

On 13 March 2012 16:44, Andrei Alexandrescu
wrote:

> I thought more about it and we should be fine with two functions
> (untested):
>
> enum Skip {};
> @property ref Skip skip() {
>static __gshared Skip result;
>return result;
> }
>
> void scatter(T, U...)(auto ref T source, ref U targets) {
>assert(source.length == targets.length);
>foreach (i, ref target; targets) {
>static if (is(typeof(target) != Skip)) {
>target = source[i];
>}
>}
> }
>
> void gather(T, U...)(ref T target, auto ref U sources) {
>assert(target.length == sources.length);
>foreach (i, source; sources) {
>static if (is(typeof(source) != Skip)) {
>target[i] = source;
>}
>}
> }
>
> Usage:
>
> auto t = tuple(1, "hi", 2.3);
> int a;
> string b;
> double c;
> t.scatter(a, b, skip); // assigns a and b from tuple
> b = "!";
> ++c;
> t.gather(skip, b, c); // assigns tuple from variables b and c


Well, that 'works' :) .. Is that a proposal for a 'final' syntax, or
something to work with in the mean time?
I said I've come to accept the Tuple *implementation*, but I'm absolutely
not ready to accept the syntax baggage ;)
I'd really rather see something that actually looks like a language feature
in its final manifestation. Is natural and convenient to read and type.

float t;
...
(myStruct.pos, t, _, int err) = intersectThings();

Or something to this effect. That's about as clear and concise as it gets
for my money.

[video] A better way to program

[proxy]

Very interesting talk about the merits of direct feedback in any 
creative process(first half) and being a developer 
activist(second half).


"It eventually gets going and it isn't only about game 
programming at about 18 mins in you will find the same ideas 
applied to more abstract coding and even to other engineering 
disciplines."


http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html

Re: Regarding implementing a stable sort for Phobos

[Xinok]

On Tuesday, 13 March 2012 at 09:32:49 UTC, deadalnix wrote:

Le 13/03/2012 10:19, Xinok a écrit :
Would you mind sharing your smoothsort? I haven't implemented 
one myself

and I'd love to test it out.


It is on github : 
https://github.com/deadalnix/Dsort/blob/master/sort/smooth.d


Thanks. I found a couple cases where it performs better, but 
overall, the overhead of the algorithm seems to be too much and 
most other algorithms performed better.


While some need to be rewritten, I have a slew of algorithms if 
you want them for your project.

Re: toHash => pure, nothrow, const, @safe

[Andrei Alexandrescu]

On 3/13/12 6:02 AM, Peter Alexander wrote:

On Monday, 12 March 2012 at 09:40:15 UTC, Walter Bright wrote:

On 3/12/2012 1:08 AM, Martin Nowak wrote:

What's wrong with auto-inference. Inferred attributes are only
strengthening
guarantees.


Auto-inference is currently done for lambdas and template functions -
why? - because the function's implementation is guaranteed to be
visible to the compiler. For other functions, not so, and so the
attributes must be part of the function signature.


Dumb question:

Why not auto-infer when the function body is available, and put the
inferred attributes into the automatically generated .di file?

Apologies if I've missed something completely obvious.


Because in the general case functions call one another so there's no way 
to figure which to look at first.


Andrei

Re: Multiple return values...

[Andrei Alexandrescu]

On 3/13/12 4:12 AM, Manu wrote:

I think I feel a sense of urgency towards the ABI aspect because it is a
breaking change, and I suspect the longer anything like that is left,
the less likely/more risky it becomes.
If it gets delayed for 6-12 months, are you honestly more or less likely
to say it's a good idea to fiddle with the ABI?


I think Walter could answer that.


I am sold on the Tuple approach now, so that's a big discussion that can
be dismissed.


Great!


Shall we discuss the shortcomings of his implementation? Can someone
demonstrate the details of his implementation?
 From the little examples up in the thread, it looked like you could
only declare new variables inline, but not assign out to existing ones.
I'd say this needs to be added too, and perhaps that will throw the
whole design into turmoil? ;)


I thought more about it and we should be fine with two functions (untested):

enum Skip {};
@property ref Skip skip() {
static __gshared Skip result;
return result;
}

void scatter(T, U...)(auto ref T source, ref U targets) {
assert(source.length == targets.length);
foreach (i, ref target; targets) {
static if (is(typeof(target) != Skip)) {
target = source[i];
}
}
}

void gather(T, U...)(ref T target, auto ref U sources) {
assert(target.length == sources.length);
foreach (i, source; sources) {
static if (is(typeof(source) != Skip)) {
target[i] = source;
}
}
}

Usage:

auto t = tuple(1, "hi", 2.3);
int a;
string b;
double c;
t.scatter(a, b, skip); // assigns a and b from tuple
b = "!";
++c;
t.gather(skip, b, c); // assigns tuple from variables b and c


Andrei

Re: Arbitrary abbreviations in phobos considered ridiculous

[Adam D. Ruppe]

On Tuesday, 13 March 2012 at 05:38:44 UTC, Nick Sabalausky wrote:
OTOH, I don't like CSS drop-down menus. Maybe it's different in 
CSS3, but in CSS2 the only way to make CSS menus work is for 
them

to open  upon rollover, not click.


Yeah, the way I do it is with a hybrid approach:

menu.onclick = function() { toggleClass(this, "opened"); };

.with-js menu > ul {
   display: none;
   /* or if you want it to roll, use the transition */
}

.with-js menu.open > ul {
   display: block;
}


and there you go. If you ask me, most your javascripts
should be changing classes, not actually doing the
work itself. That way, you keep the clean separation -
the class just represents the current state.

(indeed, with-js is another toggled class; put a little
script in the head that adds it to the html element.)



One downside of the css3 animations though is that
doing it without fixed height kinda sucks.

I wanted a quick foldout of something for the work
site. The simple height: 0px then open means
height: auto didn't work - you can't animate
to height: auto. Which sucks and they should
fix that, but apparently Apple's developers are
too incompetent to implement it in Safari, so
it gets left out of the standard. Or something
like that. I hate the standard, the process is
biased bullshit.


Anyway, to make it work, I ended up doing this:

/* overflow: hidden rox btw, use it a lot, you'll
thank me later */
max-height: 0px; overflow: hidden; transition: max-height 0.2s;

.open { max-height: 20em; }



Which gives the effect.. but the animation is from the
numbers given, not the actual height.

So, if you say max-height: 200em for instance, and
your content is only 20em tall, the visible animation
will complete in 0.02 seconds instead of 0.2!


Thus, I decided to pick an approximately right,
and call the animation time good enough.

The problem is now though: what if you add an item
to the drop down? If you don't remember to adjust
max-height too the new thing is just hidden.


Gah, the css is now dependent on the specific
content!



But, you don't always have to do this stuff
(BTW if anyone knows a better technique, let
me know!), and even so, it beats the crap
out of javascript animations.