June 08, 2013
Hi,

I know it has been discussed previously to deprecate the builtin sort. I don't know the status of this, but I observed the following problem.

With dmd, druntime and phobos all on 2.063, this program runs successfully on a mac:

#!/usr/bin/env rdmd

import std.stdio;

void main() {

  int[] a = [5, 4, 3, 2, 1];

  a.sort;
  writeln(a);

}

But it fails on linux, with the line:


/nfs/users/nfs_s/ss27/Software/dlang/phobos/generated/linux/release/64/libphobos2.a(qsort_4c4_2cc.o): In function `_adSort':
src/rt/qsort.d:(.text._adSort+0x47): undefined reference to `qsort_r'
collect2: ld returned 1 exit status
--- errorlevel 1


When I change "a.sort" -> "a.sort()" and add import std.algorithm everything works fine.
Does this mean that the builtin sort on Linux is broken with 2.063?

Stephan
June 08, 2013
On Saturday, June 08, 2013 10:30:52 Stephan Schiffels wrote:
> Hi,
> 
> I know it has been discussed previously to deprecate the builtin sort. I don't know the status of this, but I observed the following problem.
> 
> With dmd, druntime and phobos all on 2.063, this program runs successfully on a mac:
> 
> #!/usr/bin/env rdmd
> 
> import std.stdio;
> 
> void main() {
> 
>    int[] a = [5, 4, 3, 2, 1];
> 
>    a.sort;
>    writeln(a);
> 
> }
> 
> But it fails on linux, with the line:
> 
> 
> /nfs/users/nfs_s/ss27/Software/dlang/phobos/generated/linux/release/64/libph
> obos2.a(qsort_4c4_2cc.o): In function `_adSort':
> src/rt/qsort.d:(.text._adSort+0x47): undefined reference to
> `qsort_r'
> collect2: ld returned 1 exit status
> --- errorlevel 1
> 
> 
> When I change "a.sort" -> "a.sort()" and add import std.algorithm
> everything works fine.
> Does this mean that the builtin sort on Linux is broken with
> 2.063?

Hmm, it works just fine on my system (64-bit Linux), so I don't know why you're seeing the problem that you're seeing.

However, we really, really need to deprecate the built-in sort - especially when a pair of parens can make the difference between whether you call the built-in sort or std.algorithm's sort - and it's particularly broken with regards to Unicode.

- Jonathan M Davis
June 08, 2013
On Saturday, 8 June 2013 at 08:52:22 UTC, Jonathan M Davis wrote:
> However, we really, really need to deprecate the built-in sort - especially
> when a pair of parens can make the difference between whether you call the
> built-in sort or std.algorithm's sort - and it's particularly broken with
> regards to Unicode.
>
> - Jonathan M Davis

Or anything that uses non-POD comparison (opCmp) for that matter:

//----
import std.stdio;
import std.algorithm;
struct S
{
    int i;
    int opCmp(S o)
    {
       return (i < o.i) - (i > o.i); //inverse order
    }
}

void main()
{
    auto a = [S(1), S(2), S(3)];
    writeln(a); //[S(1), S(2), S(3)]
    a.sort;
    writeln(a); //[S(1), S(2), S(3)]
    a.sort();
    writeln(a); //[S(3), S(2), S(1)]
}
//----

I had pretty much forgotten ".sort" even existed (it really never even crossed my mind that it could be built-in), and given the push for optional parenthesis in general (especially in UFCS call chains), I can say I am surprised by this behavior.
June 08, 2013
On Saturday, 8 June 2013 at 08:52:22 UTC, Jonathan M Davis wrote:

> Hmm, it works just fine on my system (64-bit Linux), so I don't know why you're
> seeing the problem that you're seeing.

Hmm, that's bizarre, but I guess there's no need to understand this further since things work fine with std.algorithm.sort.

>
> However, we really, really need to deprecate the built-in sort - especially
> when a pair of parens can make the difference between whether you call the
> built-in sort or std.algorithm's sort - and it's particularly broken with
> regards to Unicode.
>

Yes, I completely agree!

Stephan

June 08, 2013
On Saturday, 8 June 2013 at 09:16:23 UTC, monarch_dodra wrote:
> On Saturday, 8 June 2013 at 08:52:22 UTC, Jonathan M Davis wrote:
>> However, we really, really need to deprecate the built-in sort - especially
>> when a pair of parens can make the difference between whether you call the
>> built-in sort or std.algorithm's sort - and it's particularly broken with
>> regards to Unicode.
>>
>> - Jonathan M Davis
>
> Or anything that uses non-POD comparison (opCmp) for that matter:
>
> //----
> import std.stdio;
> import std.algorithm;
> struct S
> {
>     int i;
>     int opCmp(S o)
>     {
>        return (i < o.i) - (i > o.i); //inverse order
>     }
> }
>
> void main()
> {
>     auto a = [S(1), S(2), S(3)];
>     writeln(a); //[S(1), S(2), S(3)]
>     a.sort;
>     writeln(a); //[S(1), S(2), S(3)]
>     a.sort();
>     writeln(a); //[S(3), S(2), S(1)]
> }
> //----
>
> I had pretty much forgotten ".sort" even existed (it really never even crossed my mind that it could be built-in), and given the push for optional parenthesis in general (especially in UFCS call chains), I can say I am surprised by this behavior.

Wow, that's much worse than in my example... indeed very unexpected behaviour.

June 08, 2013
On 08/06/13 18:51, Jonathan M Davis wrote:
> On Saturday, June 08, 2013 10:30:52 Stephan Schiffels wrote:
>> Hi,
>>
>> I know it has been discussed previously to deprecate the builtin
>> sort. I don't know the status of this, but I observed the
>> following problem.
>>
>> With dmd, druntime and phobos all on 2.063, this program runs
>> successfully on a mac:
>>
>> #!/usr/bin/env rdmd
>>
>> import std.stdio;
>>
>> void main() {
>>
>>     int[] a = [5, 4, 3, 2, 1];
>>
>>     a.sort;
>>     writeln(a);
>>
>> }
>>
>> But it fails on linux, with the line:
>>
>>
>> /nfs/users/nfs_s/ss27/Software/dlang/phobos/generated/linux/release/64/libph
>> obos2.a(qsort_4c4_2cc.o): In function `_adSort':
>> src/rt/qsort.d:(.text._adSort+0x47): undefined reference to
>> `qsort_r'
>> collect2: ld returned 1 exit status
>> --- errorlevel 1
>>
>>
>> When I change "a.sort" -> "a.sort()" and add import std.algorithm
>> everything works fine.
>> Does this mean that the builtin sort on Linux is broken with
>> 2.063?
>
> Hmm, it works just fine on my system (64-bit Linux), so I don't know why you're
> seeing the problem that you're seeing.
>
> However, we really, really need to deprecate the built-in sort - especially
> when a pair of parens can make the difference between whether you call the
> built-in sort or std.algorithm's sort - and it's particularly broken with
> regards to Unicode.
>
> - Jonathan M Davis
>

Rather than deprecate it why not fix it?  Shouldn't have to import std.algorithm just to sort an array.

Peter

June 08, 2013
Peter Williams:

> Rather than deprecate it why not fix it?  Shouldn't have to import std.algorithm just to sort an array.

Generally you want to keep the compiler (all its layers) as simpler as possible, to make it simpler to compile, debug and develop. A sort is implementable very well in library code. Other things, like tuples with a good syntax maybe can't be implemented well in library code, so they should be in the compiler :)

I suggest to kill the built-in sort ASAP.

Bye,
bearophile
June 08, 2013
On Saturday, 8 June 2013 at 22:25:14 UTC, Peter Williams wrote:
> Shouldn't have to import std.algorithm just to sort an array.

Why not?

David
June 09, 2013
On 09/06/13 08:54, David Nadlinger wrote:
> On Saturday, 8 June 2013 at 22:25:14 UTC, Peter Williams wrote:
>> Shouldn't have to import std.algorithm just to sort an array.
>
> Why not?

Because it's large with a lot of stuff unrelated to sorting.

Peter
PS A few weeks ago I would have said "large and ugly" but now I have a better feel for component programming it's not so ugly :-) but it's still large.

June 09, 2013
On Sunday, 9 June 2013 at 00:03:04 UTC, Peter Williams wrote:
> On 09/06/13 08:54, David Nadlinger wrote:
>> On Saturday, 8 June 2013 at 22:25:14 UTC, Peter Williams wrote:
>>> Shouldn't have to import std.algorithm just to sort an array.
>>
>> Why not?
>
> Because it's large with a lot of stuff unrelated to sorting.

import std.algorithm : sort;

David
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home