Profile

Cover photo
Werner Van Belle
124,726 views
AboutPosts

Stream

Werner Van Belle

Shared publicly  - 
 
Still garbage colleciton issues with crap android: java.lang.OutOfMemoryError: Failed to allocate a 7048 byte allocation with 4933392 free bytes; failed due to fragmentation (largest possible contiguous allocation 64800 bytes). Yes you read that right, even though the largest continuous block is 64800 bytes, it apparently can't find it because,you know,  7048 bytes is quite a lot larger than 64800.
1
Litrik De Roy's profile photo
 
Add a comment...

Werner Van Belle

Shared publicly  - 
 
Mixed some Drum 'n Bass. Afterwards I equalized it until I got my satisfaction. Then uploaded. Tomorrow /me very likely regret. https://www.mixcloud.com/5dbb/drum-n-frickn-bass/
Using BpmDj to mix some Drum 'n Bass. Afterwards Eq-ed until I got my satisfaction. Then uploaded. Tomorrow regret.
1
Add a comment...

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...
In their circles
383 people

Werner Van Belle

Shared publicly  - 
 
I feel kinda smart today. The problem: two records that should be merged. E.h: a string and a corresponding latestUpdatedAt timestamp. The first has 'Alfa timestamp:1' the second 'Beta timestamp:2'. If each host decides that the one with highest timestamp wins then both will agree on 'Beta timestamp:2'. Yet what happens when the timestamps are equal is interesting. The client will have its own version of the record: 'Alfa: timestamp 4' and the version of the other side: 'Beta: timestamp: 4'. The server will have exactly the opposite: his side will be 'Beta timestamp: 4' while his other side will be 'Alfa: timestamp: 4' Both will reach a different consensus if we simply compare the timestamps. To solve that I have been trying to force the same consensus on both sides. E.g: 'server always wins'. Yet that does not work if 1 client synchronizes with 2 different servers. Then you get some very interesting oscilations. The next idea is to assign a globally unique id to every instance and use that to decide which timestamp has priority. Yet that is not as straightforward as I might want it. I don't want to write code to ensure that a globally unique id is unique... Luckily in the end I figured out that a much easier way to resolve these conflicts is to look at the data itself and then, when the timestamps are equal, choose the largest label. That 1 line of code solves all before mentioned problems.
1
Add a comment...

Werner Van Belle

Shared publicly  - 
 
 
The Call For Participation for Chaos Communications Camp 2015 is now out! Please consider coming for an incredible time!
August 13-17, near Berlin.
http://events.ccc.de/2015/04/09/call-for-participation-chaos-communication-camp-2015/
Deutsche Version: siehe unten. The Chaos Communication Camp in Mildenberg is an open-air hacker camp and party that takes place every four years, organized by the Chaos Computer Club (CCC). Thousands of hackers, technology freaks, artists and utopians get together in a field for five days in the ...
View original post
2
Add a comment...

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...
People
In their circles
383 people
Links
Story
Tagline
Als uw hond kan schrijven.... dan is het eerder een pen.