On Monday, June 18, 2012 15:22:15 maarten van damme wrote:
> and something I forgot to ask, is it a conscious decision to not print
> out fired asserts in treads? Normally when an assert fails my whole
> program crashes and I can see what went wrong. With treads however, it
> quietly dies.
It coul
On Monday, 18 June 2012 at 13:22:24 UTC, maarten van damme wrote:
and something I forgot to ask, is it a conscious decision to
not print out fired asserts in treads? Normally when an assert
fails my whole program crashes and I can see what went wrong.
With treads however, it quietly dies.
Be
and something I forgot to ask, is it a conscious decision to not print
out fired asserts in treads? Normally when an assert fails my whole
program crashes and I can see what went wrong. With treads however, it
quietly dies.
Everything turned out to be problems with \r \n.
The treading system worked perfectly (although I still don't
understand how one can use immutable and receiveonly).
another problem, when I do use shared.
My code is
int amountTreads = 20;
if(upperLimit-lowerLimit
Ok, everything worked (nearly perfect). Sometimes the webpage gets
completely messed up ("<" changes to d134 or something like that) but
the tests handle it rather well.
That's why I decided to improve it a bit and use treads. I've always
been afraid of d treads because I never really got the gras
On Sunday, June 17, 2012 13:07:24 maarten van damme wrote:
> well, the page I parse is automatically generated and thus allways
> contains .
That may be true, but if your code assumes that is there and it ever
isn't for any reason, then you're going to get a RangeError thrown in non-
release and
well, the page I parse is automatically generated and thus allways
contains . (if the page completely downloaded which it didn't).
The second error I found (my mistake) is that newlines get scrambled
up severely when downloading the page causing the markers I try to
find to sometimes break down on
On Sunday, June 17, 2012 01:35:56 maarten van damme wrote:
> It should allways contain so it has more then 2 elements and
> there is a note section that starts with " parsing and break out of the loop so those two should've been
> statisfied. The problem was (I think) the downloader. Now I get waa
It should allways contain so it has more then 2 elements and
there is a note section that starts with "
On 06/16/2012 03:28 PM, maarten van damme wrote:
> And the output I get is
It is possible that some part of the code is reusing a string buffer.
For example, File.byLine does that.
> tradeDocument=tradeDocument[1..$];
For that to work, you must ensure that tradeDocument has at least 2
eleme
Ah, wait a second. After playing a bit with the try catches and
actually writing some proper debug output I found out the problem was
with https://github.com/Bystroushaak/DHTTPClient/blob/master/dhttpclient.d.
It doesn't allways download the complete webpage.
I should've written better tests I gue
On Sunday, June 17, 2012 00:28:07 maarten van damme wrote:
> 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
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
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
Nothing unsafe. I use https://github.com/Bystroushaak/DHTTPClient to
download a webpage and other then that I only use slicing...
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:
randomname
I want to extract randomname but an xml parser would be overkill so I
extract it using
curLine=curLine[curLine.
Ok, It turns out that an array out of bound exception isn't an
exception but an error?
Try catch (Error e) worked fine.
For some crazy reason my program now crashes on seemingly random
locations when parsing content of the form:
randomname
I want to extract randomname but an xml parser would be overkill so I
extract it using
curLine=curLine[curLine.countUntil(">")
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.
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 questio
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
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
23 matches
Mail list logo
