Profile

Cover photo
Werner Van Belle
124,521 views
AboutPosts

Stream

Werner Van Belle

Shared publicly  - 
 
I mentioned before that my app cryosleep seems to have a sticker 'nutcases only' all over it. The following, I got in my inbox today:
YOU need a shrink
That's how you treat custumers the that wasted 210 $ on a app that
you
can do at home
Get real
You need a shrink
Good custumer service (You need a shrink)
Total rip off (you need a shrink)
Inappropriate answer for people "that work in custumer service"
Does the qualities of messages are filtered cause I save this for
future
qualitie control
Do not reply to this message
It will be redirected by filters approuved by googleplay store
Thank you for your cooperation
Ho and reply's that do not have relation nor has a useful th thing to
say
about that particular app except of course of the negative reply that
your
try to hide with older version that replied on a another app
If you do that kind of thing, well...
YOU NEED A SHRINK
AND IM FLAGING YOUR APP FOR THIS SIMPLE UNRESPECTFULL ANSWER THAT YOU
HAD
1
Add a comment...

Werner Van Belle

Shared publicly  - 
 
Gragl. Program gragl ing ery interesting. Lots of code removal. Harg
1
Add a comment...

Werner Van Belle

Shared publicly  - 
 
And that is when I shot him your honor. A blocktree that decorates a piece of data that was in the 'save-later' queue, would save over a competing tree that was loaded because the referee had to be loaded again. Huzah !
1
Add a comment...

Werner Van Belle

Shared publicly  - 
 
So, a random commit thrown in during the merging leads to lost data. WHY ? <- this is why I am an atheist. You have to deal with the shit you make yourself. If I could just pray to god to get this bloody thing fixed and if it would be effective I'm sure the church would be making software.
1
Add a comment...

Werner Van Belle

Shared publicly  - 
 
Finally my inbox is empty after aggregating a backlog since august last year. Yippie !
1
Add a comment...

Werner Van Belle

Shared publicly  - 
 
6.6Mb to store the tags and associated indices for 61190 songs. That is 113.1 bytes per song. This is not much if you consider the merging off tag elements through timestamps and the fast indexing of tags defined by different peers. It is however a lot if you think about the following: want to tag 400'000 songs, you will need 43 megabyte of data on each peer. Given that these can be phones...
1
Add a comment...

Werner Van Belle

Shared publicly  - 
 
Can I say that working together with the Flemish people is just a hopeless situation ? Until now I did not meet a single retard who actually does what he promises without having to 'argue' later that payment is maybe not for her or him. I get that the economy is not what it used to be. However that does not give you the right to take and not pay. If you can't pay, then don't 'buy'.

So in big letters: want to do business with Belgians ? Don't. You won't get paid. Instead, hire a Dutchman. They might argue but in the end they will pay what they agreed.
1
Christophe VG's profile photoWerner Van Belle's profile photo
2 comments
 
The irony didn't escape me. Yes, this advice is still free :)
Add a comment...
In their circles
383 people

Werner Van Belle

Shared publicly  - 
 
The story of the lost backreferences... Is reaching its end. An anti-climatic reorganisation of a weakhashmap and btree indices.
1
Add a comment...

Werner Van Belle

Shared publicly  - 
 
 
If the Moon Were Only 1 Pixel - A tediously accurate map of the solar system
3 comments on original post
1
Add a comment...

Werner Van Belle

Shared publicly  - 
 
Tagging along... Tags are synchronized when two BpmDj instances meet. The initial sync (download of the entire database) is somewhat slow, but all other increments are so fast that it really has been worth all the trouble. The UI is coming along as well.
1
Add a comment...

Werner Van Belle

Shared publicly  - 
 
May the bandwidth be with CERN. I wonder on who the joke is
1
Add a comment...

Werner Van Belle

Shared publicly  - 
 
After my last post I started to integrate the shit out of all these modules and a bug popped up. Had to do with the signed interpretation of bitpatterns in java. If I consider a sequence of 4 bytes and compare them lexically I get:  0x80000000 > 0x7fffffff. Yet, when I compare them as number, we get 0x80000000 < 0x7fffffff because the msb is a sign bit. Not difficult to understand, yet a shrewd bug to solve because the indices in the table are numerically sorted while the radices in the tree rely on a partial bitpattern from the numbers. In the end I ended up implementing an unsigned comparisons in java. And there happened to be a nice solution to that: http://www.drmaciver.com/2008/08/unsigned-comparison-in-javascala/
Java (and consequently Scala) lack unsigned integer types. Most of the time this isn't an issue – the majority of the operations you're likely to care about (addition, subtraction, bitwise operations) work the same regardless of whether you treat the integer as unsigned.
1
Add a comment...
People
In their circles
383 people
Links
Story
Tagline
Als uw hond kan schrijven.... dan is het eerder een pen.