Re: GtkD help
Any information about using gio.Settings would be really appreciated too.
Re: Call thread_attachThis() from your D shared library
On 11/18/2017 03:45 AM, Guillaume Piolat wrote: > I highly advise to attach incoming threads _and detach them when they > exit the callback_. Indeed when they have exited the callback no need to > scan their stack. > > If you don't do this and the thread dies outside your library, then your > runtime still register it and will try to pause it at the first collection. Ooh! That makes sense. :) Ali
GtkD help
I have this small application for viewing select log data from a certain game that I originally wrote in C++/Qt. For various reasons, I decided to rewrite this app in D using gtk-d. First, I have to say that the documentation for gtk-d is atrocious! However, I managed to cobble together enough information to get 80% of it done. I would like to be able to controll how the cells in a TreeView are rendered (ie the text color used) but I'm not able to find any information about how to do this. Does any one have experience here? If so, can you please give me a clue?
Re: @nogc deduction for templated functions
Huh, I think I did something weird. It compiles now, and I don't know why. Thanks for your answers.
Re: @nogc deduction for templated functions
On Saturday, 18 November 2017 at 17:28:14 UTC, David Zhang wrote:
Hi,
Is there a way for a templated function to deduce or apply the
@safe/@nogc attributes automaticaly? I feel like I remember dmd
doing so at one point, but it doesn't appear to work anymore.
In particular, I need to call a function belonging to a
templated type, but do not know what attributes are applied.
eg.
void func(T)(T t)
{
//Don't know if safe or nogc
t.someFunc();
}
Thanks.
If you instantiate "func" the compiler should correctly infer
the attributes. Do you have any code where it doesn't work?
Re: @nogc deduction for templated functions
On Saturday, November 18, 2017 17:28:14 David Zhang via Digitalmars-d-learn
wrote:
> Hi,
>
> Is there a way for a templated function to deduce or apply the
> @safe/@nogc attributes automaticaly? I feel like I remember dmd
> doing so at one point, but it doesn't appear to work anymore. In
> particular, I need to call a function belonging to a templated
> type, but do not know what attributes are applied.
>
> eg.
>
> void func(T)(T t)
> {
> //Don't know if safe or nogc
> t.someFunc();
> }
>
> Thanks.
pure, nothrow, @safe, and @nogc are infered for templated functions. So,
whether those attributes apply when they're not explicitly marked on a
templated function deponds on the contents of the function. You can test it
with a unit test. e.g.
@nogc unittest
{
...
foo.func();
}
will give a compiler error if func wasn't infered as @nogc.
- Jonathan M Davis
@nogc deduction for templated functions
Hi,
Is there a way for a templated function to deduce or apply the
@safe/@nogc attributes automaticaly? I feel like I remember dmd
doing so at one point, but it doesn't appear to work anymore. In
particular, I need to call a function belonging to a templated
type, but do not know what attributes are applied.
eg.
void func(T)(T t)
{
//Don't know if safe or nogc
t.someFunc();
}
Thanks.
Re: User defined type and foreach
On Fri, Nov 17, 2017 at 02:50:59AM -0700, Jonathan M Davis via Digitalmars-d-learn wrote: [...] > Personally, I'm inclined to think that we should never have had save > and should have required that reference type ranges which are forward > ranges be wrapped in a struct where copying it does the same thing > that save does now, but I seriously doubt that we could make a change > that big now. Andrei also expressed, in retrospect, the same sentiment about input vs. forward ranges. But as you said, that ship has already sailed and we just have to make do with what we have now. T -- If you want to solve a problem, you need to address its root cause, not just its symptoms. Otherwise it's like treating cancer with Tylenol...
Re: DerelictGL3.reload(); crashes in release mode, but not in debug
On Saturday, 18 November 2017 at 14:15:21 UTC, Mike Parker wrote: The proper place to report this sort of issue is at the DerelictGL3 issues page [1]. You'll also want to include some minimal, reproducible sample code. Okay, I've made an issue: https://github.com/DerelictOrg/DerelictGL3/issues/59
Re: Lambda cannot access frame of function
On 11/18/2017 06:22 AM, kerdemdemir wrote:
//DMD64 D Compiler 2.072.2
import std.stdio;
bool foo( bool function( double ) controlFoo )
{
return controlFoo(5.0);
}
void foo2( double val )
{
writeln ( foo( a => a > val ) );
}
void main()
{
foo2(20);
writeln("Hello, World!");
}
Does not compile and gives this errors:
source_file.d(12): Error: function source.foo2.__lambda2 cannot access
frame of function source.foo2
foo should take 'delegate'.
If you want it to work with any callable entity, take the function as an
alias template parameter:
bool foo(alias controlFoo)()
{
return controlFoo(5.0);
}
void foo2( double val )
{
writeln ( foo!( a => a > val )() );
}
Ali
Re: Lambda cannot access frame of function
On Saturday, 18 November 2017 at 14:22:19 UTC, kerdemdemir wrote: bool foo( bool function( double ) controlFoo ) Change that `function` to `delegate` and it should work. Function pointers aren't allowed to access other locals, but delegates are.
Re: Lambda cannot access frame of function
On Saturday, 18 November 2017 at 14:30:29 UTC, Adam D. Ruppe wrote: On Saturday, 18 November 2017 at 14:22:19 UTC, kerdemdemir wrote: bool foo( bool function( double ) controlFoo ) Change that `function` to `delegate` and it should work. Function pointers aren't allowed to access other locals, but delegates are. Yes it worked as you suggested. Thanks.
Re: Json
I am using vibe.d's json(http://vibed.org/api/vibe.data.json/) module without a problem and really happy with it. There are also some examples(https://github.com/vibe-d/vibe.d/tree/master/examples/json). If you are using "dub" package manager it is also very easy to integrate vibe.d.
Lambda cannot access frame of function
//DMD64 D Compiler 2.072.2
import std.stdio;
bool foo( bool function( double ) controlFoo )
{
return controlFoo(5.0);
}
void foo2( double val )
{
writeln ( foo( a => a > val ) );
}
void main()
{
foo2(20);
writeln("Hello, World!");
}
Does not compile and gives this errors:
source_file.d(12): Error: function source.foo2.__lambda2 cannot
access frame of function source.foo2
source_file.d(12): Error: function source.foo (bool
function(double) controlFoo) is not callable using argument types
(void)
Live example:
http://rextester.com/WRKCWR55408
Is there any workaround for that?
Regards
Erdem
Re: DerelictGL3.reload(); crashes in release mode, but not in debug
On Saturday, 18 November 2017 at 14:15:21 UTC, Mike Parker wrote: The proper place to report this sort of issue is at the DerelictGL3 issues page [1]. You'll also want to include some minimal, reproducible sample code. [1] https://github.com/DerelictOrg/DerelictGL3/issues
Re: DerelictGL3.reload(); crashes in release mode, but not in debug
On Saturday, 18 November 2017 at 12:36:36 UTC, Dennis wrote: I'm trying to set up a game window with Derelict glfw and opengl. When I perform a default (debug) build, it correctly shows a window, but when I do this: dub run "--build=release" Then I get this: object.Error@(0): Access Violation 0x00443BCF 0x00425164 0x00418545 0x00418874 0xF96485C7 0x83AC 0x85C70041 0xF960 Program exited with code 1 With some writeln calls I found that it happens in DerelictGL3.reload(): writeln(__LINE__); //printed before error DerelictGL3.reload(); writeln(__LINE__); //not printed But I have no idea how to further debug this. Any suggestions what I can do? The proper place to report this sort of issue is at the DerelictGL3 issues page [1]. You'll also want to include some minimal, reproducible sample code.
DerelictGL3.reload(); crashes in release mode, but not in debug
I'm trying to set up a game window with Derelict glfw and opengl. When I perform a default (debug) build, it correctly shows a window, but when I do this: dub run "--build=release" Then I get this: object.Error@(0): Access Violation 0x00443BCF 0x00425164 0x00418545 0x00418874 0xF96485C7 0x83AC 0x85C70041 0xF960 Program exited with code 1 With some writeln calls I found that it happens in DerelictGL3.reload(): writeln(__LINE__); //printed before error DerelictGL3.reload(); writeln(__LINE__); //not printed But I have no idea how to further debug this. Any suggestions what I can do?
Re: Call thread_attachThis() from your D shared library
On Saturday, 18 November 2017 at 00:23:31 UTC, Ali Çehreli wrote:
We had an issue today calling a D shared library from our Java
code where we were getting segfaults during GC collection
cycles.
Of course we were being careful and calling
Runtime.initialize() inside our initialization function, which
is called from the Java side:
extern (C) auto mylib_init() {
const rtInit = Runtime.initialize();
if (!rtInit) {
logf("Failed to initialize D runtime");
abort();
}
// ...
}
but we were forgetting about the fact that our API functions
might be called from threads other than the one that called
Runtime.initialize().
extern (C) auto mylib_do_good_work() {
// Oops! A GC collection cycle may cause segmentation fault
here
// ...
}
A simple solution is to call thread_attachThis() from each API
function:
extern (C) auto mylib_do_good_work() {
import core.thread : thread_attachThis;
thread_attachThis();
// Now this thread is attached to D runtime and all is good
// ...
}
Although thread_attachThis() can be called multiple times from
the same thread, it may be possible to call it only once per
thread if potential calling threads are known; such threads can
call a per-thread initialization function on the D side. (We
don't think our Java program gives us that option because "our
Java code" is a callback registered with the framework of a
Java program, which has total control of its threads.)
Ali
I highly advise to attach incoming threads _and detach them when
they exit the callback_. Indeed when they have exited the
callback no need to scan their stack.
If you don't do this and the thread dies outside your library,
then your runtime still register it and will try to pause it at
the first collection.
Re: Json
On Friday, 17 November 2017 at 19:12:04 UTC, Jonathan M Davis wrote: On Friday, November 17, 2017 19:02:12 Mafi via Digitalmars-d-learn wrote: [...] I've typically used http://code.dlang.org/packages/std_data_json which comes from vibe.d and was a candidate for replacing std.json - though it didn't complete the review process, and I'm not sure that Sonke is interested in going through the effort of actually getting it into Phobos at this point (if I understand correctly, there were too many disagreements over what the final result should look like than there really being much wrong with std_data_json). But overall, I've found that it works reasonably well - certainly, it's better than using std.json. I don't know if it's quite what you're looking for though. Regardless, just searching on code.dlang.org gives plenty of hits for libraries to try out if std_data_json doesn't suit your fancy. - Jonathan M Davis Sadly it's not really updated and vibe.d's json module seems more stable, as it has had 60+ commits this year, while std_data_json hasn't been updated for over a year. It will probably work fine in general, but I assume it'll have a few gotchas here and there, as it seems like even vibe.d's module has that.
