Re: GTKD resources
On 2017-08-11 13:00, Mr. Pib wrote:
How can one include external files such as glade, icons, images that are
static in nature in to the binary but not require extraction on program
run to be used?
gtk's builder doesn't seem to take an in memory representation of glade
files and building a pixbuf seems quite over the top to do such simple
things?
including the glade UI/XML defs to the executable is simple, compile
with -J. switch and:
immutable string UIdefs = import("myuidefs.glade");
...
main(){
...
builder.addFromString( UIdefs );
...
Re: core.stdc.stdlib.malloc & alignment
On 2016-06-29 14:39, Hiemlick Hiemlicker wrote: Yes, the C standard requires malloc to be aligned to the platform size(4 for 32bit, 8 for 64-bit). just what i was hopping for. thanks!
core.stdc.stdlib.malloc & alignment
is there an alignment guarantee for core.stdc.stdlib.malloc? more specifically, using DMD and compiling for 32bit on windows, can i assume proper alignment for int or uint variables? background: i like to re-use a (ubyte) buffer, sometimes it will store only bytes, sometimes it shall store uints. thanks
Re: Using .lib and .dll in D applications
On 2016-06-20 06:33, moe wrote: I see where I went wrong. I thought that it's possible to only use the .lib file without the source code of dbar. Having access to the source makes what I am trying somewhat pointless. Is it otherwise possible to provide some functionality without having to give away your source? I would like to put together a library that I can reuse, without having to rely on the source each time. Maybe a dll instead? for this purpose there are .di interface files that can be generated automatically: https://dlang.org/dmd-windows.html#interface-files
Re: GTKD - overrideBackgroundColor of Button doesn't work
string cssPath = "test.css";
CssProvider provider = new CssProvider();
provider.loadFromPath(cssPath);
unfortunately i don't know anything about yr specific problem.
but i just wanted to mention (in case you are not aware of it) that the
CSS can be embedded into the D source. this is what i did to fix GTKs
terrible design mistake for the background of Notebook:
```
enum myCSS = q{
GtkNotebook {
background-color: #e9e9e9;
}
GtkNotebook tab {
background-color: #d6d6d6;
}
};
...
int main(string[] args){
...
import gtk.CssProvider;
auto styleProvider = new CssProvider;
styleProvider.loadFromData(myCSS);
import gdk.Screen;
import gtk.StyleContext;
StyleContext.addProviderForScreen( Screen.getDefault(),
styleProvider, 800);
```
Re: How to share an appender!string?
On 2016-05-20 07:49, Era Scarecrow wrote: Experimented and quickly got what looks like good clean results. Took your code, ripped out what I didn't want and added in what I did. Simple! https://dpaste.dzfl.pl/6952fdf463b66 i am most curious about your solution. why does printAll() has a synchronized block? in case you would call it before thread_joinAll() i.e. before all threads are terminated? then again, why is there a synchronized block necessary in printAll() at all? it is only reading out data, not writing. (i am still learning the subtleties of multithreading.) /det
Re: Anonymous structure
On 2016-04-18 14:12, Tofu Ninja wrote:
Also is there a way to have a named substructure, not a nested structure
but something to just add an additional name, maybe something like
struct a{
struct{
int x;
int y;
int z;
} b;
}
not sure what you mean by "named substructure, not a nested structure"
but this works:
struct Outer{
struct Inner{
int x;
int y;
int z;
}
Inner inner;
int a;
}
Outer outer;
outer.a = 7;
outer.inner.y = 42;
// outer.x = 13; //fails
writeln(outer);
Re: static void arrays under garbage control?
On 2015-02-26 10:07, Steven Schveighoffer wrote:
Static data I believe is always scanned conservatively because no
type information is stored for it ever, even on allocation (i.e.
program startup).
ouh, the confusion goes on... are you saying that
{
// will be all scanned by GC for
// potential pointers into GC managed memory:
void[16] buffer0 = void;
ubyte[16] buffer1;
uint[4] buffer3;
// will not be scanned by GC for pointers:
void[] buffer4 = cast(void[])(new ubyte[16]);
uint[] buffer5 = cast(uint[])(new ubyte[16]);
}
Re: static void arrays under garbage control?
On 2015-02-26 12:07, Steven Schveighoffer wrote:
On 2/26/15 11:57 AM, captaindet wrote:
On 2015-02-26 10:07, Steven Schveighoffer wrote:
Static data I believe is always scanned conservatively because no
type information is stored for it ever, even on allocation (i.e.
program startup).
ouh, the confusion goes on... are you saying that
{
// will be all scanned by GC for
// potential pointers into GC managed memory:
void[16] buffer0 = void;
ubyte[16] buffer1;
uint[4] buffer3;
Yes, all 3 are stack based. This is not static data, which would be like
uint[4] at module level. Those are also treated as scannable, as the entire
stack of every thread is scanned.
// will not be scanned by GC for pointers:
void[] buffer4 = cast(void[])(new ubyte[16]);
uint[] buffer5 = cast(uint[])(new ubyte[16]);
Correct, since they are allocated as ubyte[]. uint[] also would not be scanned.
-Steve
got it, finally! thanks to everyone for their help.
/det
Re: static void arrays under garbage control?
On 2015-02-25 20:45, H. S. Teoh via Digitalmars-d-learn wrote:
On Wed, Feb 25, 2015 at 08:20:37PM -0600, captaindet via Digitalmars-d-learn
wrote:
[...]
struct Stuff2Do{
static ubyte[1024*1024] buffer4speed = void; // even if untyped at this
point
// more
}
[...]
Tangential note: be careful with putting a large static array inside a
struct. Structs are passed by value, which means that if you didn't
allocate that struct on the heap and you pass it around to various
functions, you will overflow your stack very quickly -- every function
call that passes the struct will consume 1MB of stack space. Many OSes
do not allocate that much space for the runtime stack.
T
this is why i tried to get away with a 'static' static array, which only exists once for all Stuff2Do structs. but as it seems, i'll rather need on the order of 512MB buffer, so i will probably go with c.stdlib.malloc
/det
Re: static void arrays under garbage control?
On 2015-02-25 19:24, Adam D. Ruppe wrote:
does this warning only apply to dynamic void[] arrays but not to static
void[CTconstant] arrays?
Both of those will be scanned for pointers.
thanks, adam,
so i should always use
struct Stuff2Do{
static ubyte[1024*1024] buffer4speed = void; // even if untyped at this
point
// more
}
to avoid that the GC is scanning my buffer for pointers?
static void arrays under garbage control?
if i understand correctly, static arrays are exempt from GC scanning for memory pointers http://dlang.org/garbage.html : Pointers in D can be broadly divided into two categories: Those that point to garbage collected memory, and those that do not. Examples of the latter are pointers created by calls to C's malloc(), pointers received from C library routines, pointers to static data. but there is also a warning for void arrays http://dlang.org/arrays.html : The garbage collector will scan void[] arrays for pointers, since such an array may have been implicitly converted from an array of pointers or an array of elements that contain pointers. does this warning only apply to dynamic void[] arrays but not to static void[CTconstant] arrays? (because sometimes the docs also mean static arrays even if just type[] is written.) thanks! ps: this is for 32bit apps
one of the weirdest bugs ever - request for testing
hi,
i just run into a (wrong code gen?) bug that manifests itself only under
certain conditions.
before i file it, i'd like to know if it is still around in the latest DMD
version and/or if other platforms and 64bit code is affected as well.
bug description:
std.algorithm.countUntil fails to find the needle
my system:
DMD 2.0642 compiling into 32bit code on Win7 64bit
required conditions:
compile with -release -inline -noboundscheck
(an additional -O will also cause the bug)
AND the module imports std.file
/det
import std.stdio;
import std.algorithm;
import std.file;// not needed, but if imported, causing trouble, see below
void main()
{
auto names = [one,FOO,two,three];
// wrong code gen(*) with -release -O -inline -noboundscheck or
// with -release -inline -noboundscheck but only if std.file is imported:
auto x = countUntil( names, FOO );
write(x);
if( 0 = x ) writeln( found a FOO); // (*) not found!
}
Re: one of the weirdest bugs ever - request for testing
On 2014-06-12 14:20, captaindet wrote: before i file it, i'd like to know if it is still around in the latest DMD version and/or if other platforms and 64bit code is affected as well. thanks andrew, philippe, i had the suspicion that it is a windows only problem anyway because the only thing that an unused std.file would do is pulling a lot of windows specific stuff (on my system). if now someone could test this with the current DMD on windows, 64 and 32 bit executables... /det
Re: one of the weirdest bugs ever - request for testing
On 2014-06-12 17:27, Rene Zwanenburg wrote: On Thursday, 12 June 2014 at 22:14:23 UTC, captaindet wrote: On 2014-06-12 14:20, captaindet wrote: before i file it, i'd like to know if it is still around in the latest DMD version and/or if other platforms and 64bit code is affected as well. thanks andrew, philippe, i had the suspicion that it is a windows only problem anyway because the only thing that an unused std.file would do is pulling a lot of windows specific stuff (on my system). if now someone could test this with the current DMD on windows, 64 and 32 bit executables... /det No problems with 2.065 on win, both 32 and 64 bit. great, thanks, so no need to file a bug report. some other bugfix seemed to have taken care of the issue alongside. (in the meantime i had the bug confirmed on another win7/64 machine, however, using DMD2.0642 again.) hopefully it is still fixed in 2.066 which will be my next upgrade step once it is out. /det
delegate issue
hi,
i stumbled upon something weird - it looks like a bug to me but maybe it is a
feature that is unclear to me.
so i know i can declare function and delegate pointers at module level.
for function pointers, i can initialize with a lambda.
BUT for delegates i get an error - see below
i found out that using module static this(){...} provides a workaround, but why
is this necessary?
also, if there is a good reason after all then the error message should make
more sense.
/det
ps: i know there is a shorthand syntax for this.
module demo;
int function(int) fn = function int(int){ return 42; };
// ok
int delegate(int) dg = delegate int(int){ return 666; };
// demo.d(6): Error: non-constant nested delegate literal expression
__dgliteral6
void main(){}
Re: delegate issue
On 2014-06-02 08:08, Marc Schütz schue...@gmx.net wrote:
On Monday, 2 June 2014 at 06:56:54 UTC, captaindet wrote:
hi,
i stumbled upon something weird - it looks like a bug to me but
maybe it is a feature that is unclear to me.
so i know i can declare function and delegate pointers at module level.
for function pointers, i can initialize with a lambda.
BUT for delegates i get an error - see below
i found out that using module static this(){...} provides a
workaround, but why is this necessary?
also, if there is a good reason after all then the error message should make
more sense.
/det
ps: i know there is a shorthand syntax for this.
module demo;
int function(int) fn = function int(int){ return 42; };
// ok
int delegate(int) dg = delegate int(int){ return 666; };
// demo.d(6): Error: non-constant nested delegate literal expression
__dgliteral6
void main(){}
This doesn't work, because a delegate needs a context it can capture,
which is available only inside of a function.
so the real explanation is that a module as such has no context. much of the
module design has the look and feel as if it were some sort of object, so this
is a bit of a surprise to me. well, i learned something.
thanks,
det
Re: delegate issue
On 2014-06-02 08:03, MrSmith wrote:
On Monday, 2 June 2014 at 06:56:54 UTC, captaindet wrote:
hi,
i stumbled upon something weird - it looks like a bug to me but maybe it is a
feature that is unclear to me.
so i know i can declare function and delegate pointers at module level.
for function pointers, i can initialize with a lambda.
BUT for delegates i get an error - see below
i found out that using module static this(){...} provides a workaround, but why
is this necessary?
also, if there is a good reason after all then the error message should make
more sense.
/det
ps: i know there is a shorthand syntax for this.
module demo;
int function(int) fn = function int(int){ return 42; };
// ok
int delegate(int) dg = delegate int(int){ return 666; };
// demo.d(6): Error: non-constant nested delegate literal expression
__dgliteral6
void main(){}
You can't assign a delegate at compile time now.
But you can do this in static constructor like this:
int delegate(int) dg;
static this()
{
dg = delegate int(int){ return 666; };
}
i knew about the static constructor, mentioned it in my OP ;)
tried it in my project proper and got run-time cycle detected between modules
ctors/dtors :(
something new to figure out now.
thanks, det
Re: delegate issue
On 2014-06-02 08:08, Marc Schütz schue...@gmx.net wrote:
On Monday, 2 June 2014 at 06:56:54 UTC, captaindet wrote:
hi,
i stumbled upon something weird - it looks like a bug to me but maybe it is a
feature that is unclear to me.
so i know i can declare function and delegate pointers at module level.
for function pointers, i can initialize with a lambda.
BUT for delegates i get an error - see below
i found out that using module static this(){...} provides a workaround, but why
is this necessary?
also, if there is a good reason after all then the error message should make
more sense.
/det
ps: i know there is a shorthand syntax for this.
module demo;
int function(int) fn = function int(int){ return 42; };
// ok
int delegate(int) dg = delegate int(int){ return 666; };
// demo.d(6): Error: non-constant nested delegate literal expression
__dgliteral6
void main(){}
This doesn't work, because a delegate needs a context it can capture, which is
available only inside of a function.
The workaround is either, as Mr Smith suggests, to use a static
constructor, or you can use std.functional.toDelegate() (probably,
didn't test).
i knew about the static constructor workaround (mentioned it in my OP). works
in a simple case, but when i tried it in my project proper i hit a run-time
error: cycle detected between modules ctors/dtors :( could be an unrelated, so
far undetected bug, will look into it tonight. will try
std.functional.toDelegate() as well, maybe it will do the trick.
thanks, det
Re: delegate issue
On 2014-06-02 08:08, Marc Schütz schue...@gmx.net wrote:
On Monday, 2 June 2014 at 06:56:54 UTC, captaindet wrote:
hi,
i stumbled upon something weird - it looks like a bug to me but
maybe it is a feature that is unclear to me.
so i know i can declare function and delegate pointers at module level.
for function pointers, i can initialize with a lambda.
BUT for delegates i get an error - see below
i found out that using module static this(){...} provides a workaround, but why
is this necessary?
also, if there is a good reason after all then the error message should make
more sense.
/det
ps: i know there is a shorthand syntax for this.
module demo;
int function(int) fn = function int(int){ return 42; };
// ok
int delegate(int) dg = delegate int(int){ return 666; };
// demo.d(6): Error: non-constant nested delegate literal expression
__dgliteral6
void main(){}
This doesn't work, because a delegate needs a context it can capture,
which is available only inside of a function.
The workaround is either, as Mr Smith suggests, to use a static
constructor, or you can use std.functional.toDelegate() (probably,
didn't test).
FWIW, tried toDelegate() and it does not work either:
module demo2;
import std.functional : toDelegate;
int function(int) fn = function int(int){ return 42; };
// ok
int dg_def(int){ return 666; }
int delegate(int) dg = toDelegate(dg_def);
// c:\D\DMD2\windows\bin\..\..\src\phobos\std\functional.d(758): Error: Cannot
convert int delegate(int a0) @system to void* at compile time
// demo2.d(8):called from here: toDelegate( dg_def)
void main(){}
Re: delegate issue
On 2014-06-02 09:57, Steven Schveighoffer wrote:
On Mon, 02 Jun 2014 10:37:07 -0400, captaindet 2k...@gmx.net wrote:
On 2014-06-02 08:03, MrSmith wrote:
On Monday, 2 June 2014 at 06:56:54 UTC, captaindet wrote:
hi,
i stumbled upon something weird - it looks like a bug to me but
maybe it is a feature that is unclear to me.
so i know i can declare function and delegate pointers at module level.
for function pointers, i can initialize with a lambda.
BUT for delegates i get an error - see below
i found out that using module static this(){...} provides a workaround, but why
is this necessary?
also, if there is a good reason after all then the error message should make
more sense.
/det
ps: i know there is a shorthand syntax for this.
module demo;
int function(int) fn = function int(int){ return 42; };
// ok
int delegate(int) dg = delegate int(int){ return 666; };
// demo.d(6): Error: non-constant nested delegate literal expression
__dgliteral6
void main(){}
You can't assign a delegate at compile time now.
But you can do this in static constructor like this:
int delegate(int) dg;
static this()
{
dg = delegate int(int){ return 666; };
}
i knew about the static constructor, mentioned it in my OP ;)
tried it in my project proper and got run-time cycle detected between modules
ctors/dtors :(
something new to figure out now.
FYI, the module ctor/dtor cycles thing is an interesting problem.
When D decides to call module ctors or dtors, it wants to initialize
them in an order where two initializations don't depend on one
another. For instance:
module a;
import b;
int x;
static this() { x = b.x;}
module b;
import a;
int x;
static this() { x = a.x;}
But of course, D does not know what exactly is done in module a, and
module b. It could be:
module a;
import b;
int x;
static this() { x = b.x; }
module b;
import a;
int x;
static this() { x = 15;}
Which could be perfectly legal, as long as module b is initialized
before module a.
But D doesn't have the information to sort this out. So at the
moment, it has to assume the first situation, and reject the code.
And it can only detect this at runtime, since we have no way to tell
the linker to refuse to link this code.
The typical solution is to put your static ctors into another module,
which nothing will import (and therefore cannot be part of a cycle).
A module with no static ctors/dtors will not be flagged as causing a
problem.
-Steve
thanks a lot, steve! turned out - not surprisingly - that i would run into the
ctor/dtor cycle issue whenever the user code module had a static constructor
(even if not due to the delegate workaround mixin). i was able to refactor my
package and after 'outsourcing' of the static constructor there, i can now use
the mixed in static constructors in the user module to initialize the delegate
with a default. not pretty, but it works!
/det
