Jump to page: 1 2 3
Thread overview
sorting associative array's keys by values
Jun 16, 2012
maarten van damme
Jun 16, 2012
Timon Gehr
Jun 16, 2012
Timon Gehr
Jun 16, 2012
maarten van damme
Jun 16, 2012
maarten van damme
Jun 16, 2012
Timon Gehr
Jun 16, 2012
maarten van damme
Jun 16, 2012
maarten van damme
Jun 16, 2012
Jonathan M Davis
Jun 16, 2012
maarten van damme
Jun 16, 2012
Ali Çehreli
Jun 16, 2012
maarten van damme
Jun 17, 2012
Jonathan M Davis
Jun 17, 2012
maarten van damme
Jun 16, 2012
Jonathan M Davis
Jun 16, 2012
maarten van damme
Jun 17, 2012
Jonathan M Davis
Jun 17, 2012
maarten van damme
Jun 17, 2012
maarten van damme
Jun 18, 2012
maarten van damme
Jun 18, 2012
maarten van damme
Jun 18, 2012
Era Scarecrow
Jun 21, 2012
Jonathan M Davis
June 16, 2012
Right now I have an associative array "int[string] aa" and stored the
keys in "string[] keys".
Now I want to sort keys[] so that "aa[keys[0]]>aa[keys[1]]"
I remember someone gave the answer to that question on stackoverflow
but after some googling I couldn't find the right answer.

maarten
June 16, 2012
On 06/16/2012 06:34 PM, maarten van damme wrote:
> Right now I have an associative array "int[string] aa" and stored the
> keys in "string[] keys".
> Now I want to sort keys[] so that "aa[keys[0]]>aa[keys[1]]"
> I remember someone gave the answer to that question on stackoverflow
> but after some googling I couldn't find the right answer.
>
> maarten

schwartzSort!(k=>aa[k])(keys);
June 16, 2012
On 06/16/2012 06:41 PM, Timon Gehr wrote:
> On 06/16/2012 06:34 PM, maarten van damme wrote:
>> Right now I have an associative array "int[string] aa" and stored the
>> keys in "string[] keys".
>> Now I want to sort keys[] so that "aa[keys[0]]>aa[keys[1]]"
>> I remember someone gave the answer to that question on stackoverflow
>> but after some googling I couldn't find the right answer.
>>
>> maarten
>
> schwartzSort!(k=>aa[k])(keys);

oops.

Seems like you actually want

schwartzSort!(k=>aa[k],"a > b")(keys);
June 16, 2012
thank you, works perfectly.
I'm really having some troubles understanding the whole std.algorithm
documentation although it is a module I've had to use in nearly every
single program I wrote and it's always extremely powerful.
June 16, 2012
For some crazy reason my program now crashes on seemingly random
locations when parsing content of the form:
	                <div class="details">
	                    <h1 class="unique">randomname</h1>
I want to extract randomname but an xml parser would be overkill so I
extract it using
curLine=curLine[curLine.countUntil(">")+1..$];
curLine=curLine[0..curLine.countUntil("</")];

with curLine containing the contents of the second line.
When it crashes, it does so on the second instruction. I tried
wrapping try{}catch around it but to no avail.
I have no problem with it crashing, could be a logic mistake, but I
really need to be able to rely on try{}catch...

It's really strange because every string involved in the process is completely cleared and it fails sometimes on cases where it has no problems the other times.
June 16, 2012
Ok, It turns out that an array out of bound exception isn't an
exception but an error?
Try catch (Error e) worked fine.
June 16, 2012
On 06/16/2012 07:51 PM, maarten van damme wrote:
> For some crazy reason my program now crashes on seemingly random
> locations when parsing content of the form:
> 	<div class="details">
> 	<h1 class="unique">randomname</h1>
> I want to extract randomname but an xml parser would be overkill so I
> extract it using
> curLine=curLine[curLine.countUntil(">")+1..$];
> curLine=curLine[0..curLine.countUntil("</")];
>
> with curLine containing the contents of the second line.
> When it crashes, it does so on the second instruction. I tried
> wrapping try{}catch around it but to no avail.
> I have no problem with it crashing, could be a logic mistake, but I
> really need to be able to rely on try{}catch...
>
> It's really strange because every string involved in the process is
> completely cleared and it fails sometimes on cases where it has no
> problems the other times.

Possibly memory corruption. Do you use any unsafe constructs?
June 16, 2012
Nothing unsafe. I use https://github.com/Bystroushaak/DHTTPClient to download a webpage and other then that I only use slicing...
June 16, 2012
On Saturday, June 16, 2012 21:48:52 maarten van damme wrote:
> Ok, It turns out that an array out of bound exception isn't an
> exception but an error?
> Try catch (Error e) worked fine.

Yes, it's a RangeError. It's considered a programming bug if you access an array out of bounds - just like any assertion failure is an AssertError and considered a bug in your program in if it fails. And so they kill the program when they fail. Catching either of them is generally a very bad idea.

- Jonathan M Davis
June 16, 2012
I wanted to catch it because I could not for the life of me understand how downloading the exact same page twice could alter it's contents in such a way that it causes the program to crash.

There's something really strange going on (or maybe I'm just too tired
to see the obvious)
My code literally reads

				if(debugtemp){
					writeln(tradeDocument[0..100]);
					writeln(tradeDocument.countUntil("<div class=\""));
					stdout.flush();
				}

And the output I get is

P-BODY SHRUG</h1>
                            <span class="level">Level 1</span><br />(Uncraftable
)

150
<div class="item unique" id="7088388" data="620,20,6" search="level:1;craftable:
false;">

0

Now either I'm going crazy or std.algorithm sees ghosts apearing.

That isn't the worst part, that is

tradeDocument=tradeDocument[1..$];

tradeDocument=tradeDocument[tradeDocument.countUntil("<div
class=\"")..$];//go to the next element

crashing immediatly after the previous piece of code. So in reality std.algorithm sees an ellement that isn't there, says it's at index 0 and a second later my program crashes on the statement x=x[0..$] What on earth is going on?

I use methods from
import std.algorithm;
import std.array;
import std.stdio;
import std.string;
and no pointers, aren't they supposed to be a subset of safeD so we
can rule out memory corruption?
(I've confirmed this behaviour on two different machines)
« First   ‹ Prev
1 2 3