On Sunday, 1 July 2018 at 20:15:02 UTC, crimaniak wrote:
On Sunday, 1 July 2018 at 13:44:23 UTC, Anton Fediushin wrote:
I reduced the test case to _one_ line:
```
1.seconds.setTimer(() =>
"http://google.com".requestHTTP((scope req) {}, (scope res)
{res.disconnect;}), true);
```
What
On Sunday, 1 July 2018 at 13:44:23 UTC, Anton Fediushin wrote:
I reduced the test case to _one_ line:
```
1.seconds.setTimer(() => "http://google.com".requestHTTP((scope
req) {}, (scope res) {res.disconnect;}), true);
```
What happens is `res.disconnect` doesn't free all of the
internal
On Sunday, 1 July 2018 at 12:32:25 UTC, Jacob Shtokolov wrote:
On Sunday, 1 July 2018 at 05:20:17 UTC, Anton Fediushin wrote:
Now I tried it and indeed, it's vibe.d's fault. I'm not quite
sure what causes it and if this problem is known, I'll look
into that later and open an issue if it
On Sunday, 1 July 2018 at 05:20:17 UTC, Anton Fediushin wrote:
Now I tried it and indeed, it's vibe.d's fault. I'm not quite
sure what causes it and if this problem is known, I'll look
into that later and open an issue if it doesn't exist already.
Yes, please do this when you have time. That
On Saturday, 30 June 2018 at 22:06:50 UTC, Jacob Shtokolov wrote:
On Friday, 29 June 2018 at 17:40:07 UTC, Anton Fediushin wrote:
So, long story short:
- Usage of Mallocator instead of theAllocator made it a little
bit better
- VibeManualMemoryManagement had no (or little) effect
- Manually
On Friday, 29 June 2018 at 17:40:07 UTC, Anton Fediushin wrote:
So, long story short:
- Usage of Mallocator instead of theAllocator made it a little
bit better
- VibeManualMemoryManagement had no (or little) effect
- Manually calling GC.collect had no (or little) effect
You could try to call
On 30/06/2018 7:42 PM, Anton Fediushin wrote:
On Saturday, 30 June 2018 at 05:00:35 UTC, rikki cattermole wrote:
On 30/06/2018 4:49 AM, Bauss wrote:
I wouldn't really blame the GC. There is a higher chance you're just
not using it how it's meant to be, especially since it looks like
you're
On Saturday, 30 June 2018 at 05:00:35 UTC, rikki cattermole wrote:
On 30/06/2018 4:49 AM, Bauss wrote:
I wouldn't really blame the GC. There is a higher chance
you're just not using it how it's meant to be, especially
since it looks like you're mixing manual memory management
with GC memory.
On 30/06/2018 4:49 AM, Bauss wrote:
I wouldn't really blame the GC. There is a higher chance you're just not
using it how it's meant to be, especially since it looks like you're
mixing manual memory management with GC memory.
Let's be honest, I don't think it was meant to live in a container
On Friday, 29 June 2018 at 16:49:41 UTC, Bauss wrote:
On Friday, 29 June 2018 at 16:07:00 UTC, Anton Fediushin wrote:
On Friday, 29 June 2018 at 11:11:57 UTC, rikki cattermole
wrote:
On 29/06/2018 11:09 PM, Anton Fediushin wrote:
It is GC's fault for sure, I built my program with
profile-gc
On Friday, 29 June 2018 at 16:19:39 UTC, 12345swordy wrote:
On Friday, 29 June 2018 at 16:07:00 UTC, Anton Fediushin wrote:
Now I finally understand why GC is not a great thing. I was
writing apps utilizing GC for a long time and never had
problems with it, but when it came down to this simple
On Friday, 29 June 2018 at 16:07:00 UTC, Anton Fediushin wrote:
On Friday, 29 June 2018 at 11:11:57 UTC, rikki cattermole wrote:
On 29/06/2018 11:09 PM, Anton Fediushin wrote:
It is GC's fault for sure, I built my program with profile-gc
and it allocated a lot there. Question is, why doesn't
On Friday, 29 June 2018 at 16:07:00 UTC, Anton Fediushin wrote:
On Friday, 29 June 2018 at 11:11:57 UTC, rikki cattermole wrote:
On 29/06/2018 11:09 PM, Anton Fediushin wrote:
It is GC's fault for sure, I built my program with profile-gc
and it allocated a lot there. Question is, why doesn't
On Friday, 29 June 2018 at 11:11:57 UTC, rikki cattermole wrote:
On 29/06/2018 11:09 PM, Anton Fediushin wrote:
It is GC's fault for sure, I built my program with profile-gc
and it allocated a lot there. Question is, why doesn't it free
this memory?
Probably doesn't know that it should
On Friday, 29 June 2018 at 14:10:26 UTC, Daniel Kozak wrote:
Have you try use VibeManualMemoryManagement
https://github.com/TechEmpower/FrameworkBenchmarks/blob/3b24d0a21463edc536b30e2cea647fd425915401/frameworks/D/vibed/dub.json#L22
I'll try, not quite sure it'll help much.
Have you try use VibeManualMemoryManagement
https://github.com/TechEmpower/FrameworkBenchmarks/blob/3b24d0a21463edc536b30e2cea647fd425915401/frameworks/D/vibed/dub.json#L22
On Fri, Jun 29, 2018 at 3:20 PM Anton Fediushin via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> On
On Friday, 29 June 2018 at 11:42:18 UTC, bauss wrote:
On Friday, 29 June 2018 at 11:24:14 UTC, Anton Fediushin wrote:
On Friday, 29 June 2018 at 11:01:41 UTC, Anton Fediushin wrote:
On Friday, 29 June 2018 at 10:21:24 UTC, Radu wrote:
On Friday, 29 June 2018 at 09:44:27 UTC, Anton Fediushin
On Friday, 29 June 2018 at 11:24:14 UTC, Anton Fediushin wrote:
On Friday, 29 June 2018 at 11:01:41 UTC, Anton Fediushin wrote:
On Friday, 29 June 2018 at 10:21:24 UTC, Radu wrote:
On Friday, 29 June 2018 at 09:44:27 UTC, Anton Fediushin
wrote:
Almost forgot, there are two timers which call
On Friday, 29 June 2018 at 11:01:41 UTC, Anton Fediushin wrote:
On Friday, 29 June 2018 at 10:21:24 UTC, Radu wrote:
On Friday, 29 June 2018 at 09:44:27 UTC, Anton Fediushin wrote:
Almost forgot, there are two timers which call this function
for two different streams.
Value of `metaint` is
On 29/06/2018 11:09 PM, Anton Fediushin wrote:
It is GC's fault for sure, I built my program with profile-gc and it
allocated a lot there. Question is, why doesn't it free this memory?
Probably doesn't know that it should deallocate so eagerly.
A GC.collect(); call may help.
On Friday, 29 June 2018 at 10:31:14 UTC, bauss wrote:
On Friday, 29 June 2018 at 10:21:24 UTC, Radu wrote:
On Friday, 29 June 2018 at 09:44:27 UTC, Anton Fediushin wrote:
Almost forgot, there are two timers which call this function
for two different streams.
Value of `metaint` is 16000,
On Friday, 29 June 2018 at 10:21:24 UTC, Radu wrote:
On Friday, 29 June 2018 at 09:44:27 UTC, Anton Fediushin wrote:
Almost forgot, there are two timers which call this function
for two different streams.
Value of `metaint` is 16000, which means that only 16KB of
memory are allocated for the
On Friday, 29 June 2018 at 10:21:24 UTC, Radu wrote:
On Friday, 29 June 2018 at 09:44:27 UTC, Anton Fediushin wrote:
Almost forgot, there are two timers which call this function
for two different streams.
Value of `metaint` is 16000, which means that only 16KB of
memory are allocated for the
On Friday, 29 June 2018 at 09:44:27 UTC, Anton Fediushin wrote:
Almost forgot, there are two timers which call this function
for two different streams.
Value of `metaint` is 16000, which means that only 16KB of
memory are allocated for the `buffer`, then it reads another
byte which contains
Almost forgot, there are two timers which call this function for
two different streams.
Value of `metaint` is 16000, which means that only 16KB of memory
are allocated for the `buffer`, then it reads another byte which
contains length of the metadata / 16 and then it reads the
metadata which
Hello, I'm looking for an advice on what I am doing wrong.
I have a vibe.d-based program, which connects to an audio stream
and gets name of the song currently playing. For that, I wrote
the following code:
```
@safe string nowPlaying(string url) {
import vibe.core.stream;
26 matches
Mail list logo
