Re: DLangUI Drag and Drop support?
On Tuesday, 6 February 2018 at 08:48:47 UTC, aberba wrote: On Saturday, 3 February 2018 at 18:06:30 UTC, Andres Clari wrote: Hi, is there support for drag and drop in dlangui?? I haven't found anything on the docs, issues or forums. I'm building a project that requires support for dropping URLs from the browser into a ListWidget. Is this possible with dlangui at all? Can you please file an issue in the github repo. Its very active so it's possible support will be implemented sooner. I created an issue for it with a basic outline of a possible implementation: https://github.com/buggins/dlangui/issues/553
Re: DLangUI Drag and Drop support?
On Monday, 5 February 2018 at 12:17:22 UTC, Jacob Carlborg wrote: On 2018-02-03 19:06, Andres Clari wrote: Hi, is there support for drag and drop in dlangui?? I haven't found anything on the docs, issues or forums. I'm building a project that requires support for dropping URLs from the browser into a ListWidget. Is this possible with dlangui at all? DWT [1] supports drag-and-drop. [1] https://github.com/d-widget-toolkit/dwt But DWT doesn't support macOS right? That would be my main target...
DLangUI Drag and Drop support?
Hi, is there support for drag and drop in dlangui?? I haven't found anything on the docs, issues or forums. I'm building a project that requires support for dropping URLs from the browser into a ListWidget. Is this possible with dlangui at all?
Re: Get largest heap object at runtime? ...tracking the leak
On Monday, 22 January 2018 at 15:56:53 UTC, thedeemon wrote: On Monday, 22 January 2018 at 06:48:00 UTC, Andres Clari wrote: Not sure why "spawn" would leak like that tho. I would assume that once the thread exits, it would get destroyed and it's resources reclaimed, specially when I have calls to "GC.collect and GC.minimize". All threads withing a process share the same heap, so whatever one thread allocated in that heap is not freed or reclaimed automatically when thread dies, it stays in the heap. Well the destructor of some Json objects and strings should be called when the thread exits tho. Why wouldn’t the GC take care of this?
Re: Get largest heap object at runtime? ...tracking the leak
On Monday, 22 January 2018 at 06:15:24 UTC, Dmitry Olshansky wrote: On Sunday, 21 January 2018 at 17:28:13 UTC, Andres Clari wrote: Hi, is there any way to get from the GC all allocated objects, so I can see their size and find where I'm leaking memory? Or perhaps a good tool to help with this issue... I tried building my program with "profile-gc" but I got an invalid MemoryOperationError with no stack trace... so no luck using that. And the leak is only obvious when running in production, where after 6 hours I've seen 1.5Gb of memory usage. Are you by chance using vibe.d? In versions 0.8.x I observe a huge memory leak. Might be your problem. Right now, I'm able to extend the life of my program by injecting calls to: GC.collect GCminimize Within an event that happens every 5 seconds, which I estimate will give me about a week before the program's memory is again at +1.5Gb. Yeah. Although after doing some manual tracking and isolation of the suspect routines, I found that using "std.concurrency.spawn" to run a http post request with the "requests" library was the leaking suspect. I'm triggering some 15 requests every 5 seconds in production, so it's obvious there, but querying "GC.usedSize" I was able to observe the same on my dev environment. After removing the "spawn" call, and wrapping up the post code inside a "runTask", it seems to work properly now, and so far I have a consistently small memory size in production. Not sure why "spawn" would leak like that tho. I would assume that once the thread exits, it would get destroyed and it's resources reclaimed, specially when I have calls to "GC.collect and GC.minimize".
Get largest heap object at runtime? ...tracking the leak
Hi, is there any way to get from the GC all allocated objects, so I can see their size and find where I'm leaking memory? Or perhaps a good tool to help with this issue... I tried building my program with "profile-gc" but I got an invalid MemoryOperationError with no stack trace... so no luck using that. And the leak is only obvious when running in production, where after 6 hours I've seen 1.5Gb of memory usage. Right now, I'm able to extend the life of my program by injecting calls to: GC.collect GCminimize Within an event that happens every 5 seconds, which I estimate will give me about a week before the program's memory is again at +1.5Gb.
Re: Vibe-d issue with timer in separate thread on debug builds
On Thursday, 18 January 2018 at 10:03:57 UTC, drug wrote: 18.01.2018 08:45, Andres Clari пишет: I see, then although it works (or it may work) on release shouldn't that assert happen for release builds by default too? Or is the thought that you got the error running the debug build you should do it a different way on your own and skip the check all together? asserts are disabled in release mode, so you have no it. Better would be say it seems to be working in release mode. Ahh, that explains it. Indeed. Well I won't complain for now as it seems to be allowing me to do what I meant to do. :)
Re: Vibe-d issue with timer in separate thread on debug builds
On Tuesday, 16 January 2018 at 09:04:18 UTC, Sönke Ludwig wrote:
Am 10.01.2018 um 15:40 schrieb Andres Clari:
Hi, I have an app that uses vibe tasks, fibers and timers
extensively, and I found an issue only for debug builds, when
canceling a timer. However the code in question works just
fine in the release build.
But having this here makes testing certain things in my
program a pain, since it'll crash on the assert in question:
vibe-d-0.8.2/vibe-d/core/vibe/core/drivers/libevent2.d:474
debug assert(m_ownerThread is () @trusted { return
Thread.getThis(); } ());
Also, not sure I understand that assert properly... Is it
checking the stop timer call is fired from the main thread the
event loop is running? That would be bad, since basically that
timer run from a child thread.
The basic requirement for almost all vibe.d primitives is that
they may only be used within the same thread in which they were
created. Anything else requires message passing (e.g. using
std.concurrency) to issue the operation in the owner thread.
There incidentally is a recent thread on the vibe.d forum on
this topic:
https://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/thread/48663/
I see, then although it works (or it may work) on release
shouldn't that assert happen for release builds by default too?
Or is the thought that you got the error running the debug build
you should do it a different way on your own and skip the check
all together?
Vibe-d issue with timer in separate thread on debug builds
Hi, I have an app that uses vibe tasks, fibers and timers
extensively, and I found an issue only for debug builds, when
canceling a timer. However the code in question works just fine
in the release build.
But having this here makes testing certain things in my program a
pain, since it'll crash on the assert in question:
vibe-d-0.8.2/vibe-d/core/vibe/core/drivers/libevent2.d:474
debug assert(m_ownerThread is () @trusted { return
Thread.getThis(); } ());
Also, not sure I understand that assert properly... Is it
checking the stop timer call is fired from the main thread the
event loop is running? That would be bad, since basically that
timer run from a child thread.
Re: C++ Interop
On Saturday, 6 January 2018 at 13:51:54 UTC, qznc wrote: It would be great to have std::vector and std::string out of the box in D, but putting it into druntime? Druntime is supposed to be shared among all frontends, isn't it? GCC and Clang probably do not have equivalent vector/string classes that the same D code can be used. +1 Supporting std::vector and std::string would be a major help
GtkD custom theme on Windows
I've made a linux program with GtkD, and so far, it's been pretty awesome, however I'm thinking about porting it to Windows also, but the Adwaita theme is too fugly, and cringy, so I'd want to use a compatible theme, which is supposed to be doable. What would be the way to go to make a GtkD app use a custom GTK theme in Windows? I tried this in the past, but never succeeded following documentation found online.
