Re: WeakRefs for a CPP-D wrapper
Hi yes I think noticed in another thread that you were wrapping Qt with dynamic loading of the qt libs, interesting idea - does your code allow subclassing of the Qt classes and overriding the virtual methods? I'm taking a much more traditional approach, but there is method in my madness :-) I found a way to bypass the restriction associated with virtual methods. In a virtual method C + + code I put a call D code. More examples with wrapping Qt: https://github.com/MGWL/QtE-Qt_for_Dlang_and_Forth
Re: When using Win32/x86 in a version block is that the compiler or OS?
On 2014-01-12 19:47, Gary Willoughby wrote:
When using Win32/x86 in a version block, does that relate to the
compiler or OS?
for example:
version(Win32)
{
// 32bit Windows or 32bit Compiler?
}
Microsoft 32-bit Windows systems
version(X86)
{
// 32bit OS or 32bit Compiler?
}
Intel and AMD 32-bit processors
If these don't relate to the compiler is there any indication that the
program is being compiled with a 32bit compiler?
You might want to use: D_LP64 - Pointers are 64 bits (command line
switch -m64). (Do not confuse this with C's LP64 model)
I don't think what you're asking for is useful. The 32bit compiler can
compile both 32bit and 64bit code, at least DMD.
I'm primarily asking because i need to use this to constrain dub to
build different things depending on what compiler is used and on what
architecture.
DigitalMars - DMD
GNU - GDC
LDC - LDC
SDC - SDC
A complete list of predefined versions can be found here:
http://dlang.org/version.html#PredefinedVersions
--
/Jacob Carlborg
Re: What's the D way of application version numbers?
On Sun, 2014-01-12 at 19:11 +, Adam D. Ruppe wrote: […] enum version = import(VERSION); // use it now like any other string in D Calling a string an enum seemed discordant, and version is sort of a reserved word (at least as far as Emacs D-Mode colorizing is concerned) so in the end I went with: immutable auto versionNumber = strip(import(VERSION)); which seems to do the job very nicely. Thanks for your response to my original question, most helpful. :-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Value or Reference Semantics Trait
On Sunday, 12 January 2014 at 20:16:15 UTC, Nordlöw wrote: Is there a trait to check whether a type has value or reference semantics? I need this in a template struct that adaptively (using static if) represent histogram bins as either a dense static array or a sparse associative array. No, afaik. However, the question goes deeper than you might have though. You probably want to distuingish between structs+scalars vs classes. However, what about ref-arguments? Mutable arrays are struct values, but have reference semantics. Immutable-value arrays (e.g. string) have value semantics. You could use one version as default and define special cases via some stuff you find in std.traits.
Re: Value or Reference Semantics Trait
On Sunday, 12 January 2014 at 20:16:15 UTC, Nordlöw wrote: Is there a trait to check whether a type has value or reference semantics? I need this in a template struct that adaptively (using static if) represent histogram bins as either a dense static array or a sparse associative array. That's a complicated question in D. Only simple cases fit one or the other exactly. E.g. A class always has reference semantics, but may contain any combination of reference and value semantic fields. A struct has value semantics, but may contain any combination of reference and value semantic fields. A slice has value semantics w.r.t. its length and start point, but reference semantics for its data. A static array has value semantics. For your problem you should look at the set of IsSomething traits in the table at the top of http://dlang.org/phobos-prerelease/std_traits.html as they will hopefully be sufficient.
Re: What's the D way of application version numbers?
On Monday, 13 January 2014 at 11:39:02 UTC, Russel Winder wrote: Calling a string an enum seemed discordant Slightly off-topic but I should mention that in D enums are not just enumerations but any compile-time constants and used idiomatically that way.
Re: What's the D way of application version numbers?
On Monday, 13 January 2014 at 11:39:02 UTC, Russel Winder wrote: immutable auto versionNumber = strip(import(VERSION)); The auto doesn't do anything in this case, as immutable is a storage class and hence implies auto. It might be better to write: static immutable versionNumber = ...
Re: Value or Reference Semantics Trait
On Sunday, 12 January 2014 at 20:16:15 UTC, Nordlöw wrote: Is there a trait to check whether a type has value or reference semantics? I need this in a template struct that adaptively (using static if) represent histogram bins as either a dense static array or a sparse associative array. Adding to the other answers: std.traits.hasIndirections
pure is as pure does with LLVM compiler
Hi There,
I am playing around CTFE, and I get different compile time
behavior with the reference compiler (both 64-bit Linux):
DMD64 D Compiler v2.064
and the LLVM compiler:
LDC - the LLVM D compiler (37ee99): based on DMD v2.063.2
and
LLVM 3.3
The code snippet at the bottom of the post compiles fine with the
reference compiler, but with LDC I get the following error:
ldc2 example.d
example.d(4): Error: pure function 'append_index' cannot call
impure function 'to'
'to' is not pure, however it seems the reference compiler is able
to determine that to is effectively pure. If I remove the 'pure'
keyword from the definition of 'append_index', the problem is
resolved.
Is it reasonable that ldc gives this error?
What is the best practice in this situation (I require the result
of such function calls for constructing more complicated strings
at compile time).
--
import std.conv;
string append_index(uint i) pure {
return v_ ~ to!string(i);
}
void main() {
static assert(A.append_index(3)==v_3);
}
Re: Value or Reference Semantics Trait
If you just want to check if specifically it's a structure, you could always check `__traits(compiles, T()) if(typeof(T()) == T)` beware however that this will evaluate to true if T is a class with a static opCall who's return type is T. On 1/13/14, Tobias Pankrath tob...@pankrath.net wrote: On Sunday, 12 January 2014 at 20:16:15 UTC, Nordlöw wrote: Is there a trait to check whether a type has value or reference semantics? I need this in a template struct that adaptively (using static if) represent histogram bins as either a dense static array or a sparse associative array. Adding to the other answers: std.traits.hasIndirections
Re: Value or Reference Semantics Trait
On Monday, 13 January 2014 at 13:41:30 UTC, Orvid King wrote: If you just want to check if specifically it's a structure, you could always check `__traits(compiles, T()) if(typeof(T()) == T)` beware however that this will evaluate to true if T is a class with a static opCall who's return type is T. is(T == struct)
Re: pure is as pure does with LLVM compiler
On Monday, 13 January 2014 at 13:37:05 UTC, Ben Cumming wrote: Hi There, I am playing around CTFE, and I get different compile time behavior with the reference compiler (both 64-bit Linux): DMD64 D Compiler v2.064 and the LLVM compiler: LDC - the LLVM D compiler (37ee99): based on DMD v2.063.2 and LLVM 3.3 This is the answer. Current LDC is still based on 2.063.2 version of frontend. There have been several tweaks in `std.conv` to make `to` more pure-friendly between those two releases.
Re: Value or Reference Semantics Trait
On Monday, 13 January 2014 at 13:41:30 UTC, Orvid King wrote: If you just want to check if specifically it's a structure, you could always check `__traits(compiles, T()) if(typeof(T()) == T)` beware however that this will evaluate to true if T is a class with a static opCall who's return type is T. is(T == struct)
Re: pure is as pure does with LLVM compiler
On Monday, 13 January 2014 at 13:46:26 UTC, Dicebot wrote: This is the answer. Current LDC is still based on 2.063.2 version of frontend. There have been several tweaks in `std.conv` to make `to` more pure-friendly between those two releases. Thanks! I will recompile the latest version of LDC then...
Re: pure is as pure does with LLVM compiler
On Monday, 13 January 2014 at 14:18:49 UTC, Ben Cumming wrote: On Monday, 13 January 2014 at 13:46:26 UTC, Dicebot wrote: This is the answer. Current LDC is still based on 2.063.2 version of frontend. There have been several tweaks in `std.conv` to make `to` more pure-friendly between those two releases. Thanks! I will recompile the latest version of LDC then... I don't think 2.064 LDC has been released yet
Re: Value or Reference Semantics Trait
On 1/13/14, anonymous anonym...@example.com wrote: On Monday, 13 January 2014 at 13:41:30 UTC, Orvid King wrote: If you just want to check if specifically it's a structure, you could always check `__traits(compiles, T()) if(typeof(T()) == T)` beware however that this will evaluate to true if T is a class with a static opCall who's return type is T. is(T == struct) Or that, yeah XD (For some reason I was thinking about ensuring that it was constructible, which, after reading the question again, isn't actually needed, woops :D) With that in mind, value type semantics would be `enum hasValueSemantics(T) = is(T == struct) || is(T == enum) || is(T == union) || isArray!T;` Be aware however that this assumes you want arrays to be considered to have value semantics due to their length and base element being by-value.
Re: What's the D way of application version numbers?
On Sunday, 12 January 2014 at 18:36:19 UTC, Russel Winder wrote: With C++ and Python, it is idiomatic to put the application version number in a separate file that can then be processed by the build system. For C++ a config file is constructed defining a macro that is then used in the rest of the course. For Python the file is read at runtime to define a variable. The build system itself uses the version number for creating deb, RPM, egg, wheel, etc. packages. D has no macro processing so C++ idioms are not useful. D does create a standalone executable and so the Python approach of reading the file at initialization time seems inappropriate. Is there a known D idiom for this? Thanks. I simply define version in my main module (module which contains the main() function). I am planning to submit a DIP about something that is related to this. - I think we really need a way to specify version of package, and maybe even version of a module (similar to how the new Java module system works - see project Jigsaw). D does not offer this. I humbly believe it should be part of the language as it could be used also for building versions of dynamic libraries. Anyway, back to the topic. Say my main() function is in the org.dlang.myapp module. If I want to have information about version of the artifact, my myapp.d starts with the following two lines of D code: module org.dlang.myapp; version = 1_3_21_4; // major_minor_micro_qualifier Naturally, build tool looks for the version line when I need it.
Re: Question on static declaration
Maxim Fomin: as well as more sophisticated nonsense. Issue is filed is bugzilla, so it will be fixed sooner or latter, current policy is to ignore it. See also: https://d.puremagic.com/issues/show_bug.cgi?id=3934 Bye, bearophile
Re: pure is as pure does with LLVM compiler
On Monday, 13 January 2014 at 14:32:03 UTC, Dicebot wrote: I don't think 2.064 LDC has been released yet So I see, thanks.
Re: pure is as pure does with LLVM compiler
On Monday, 13 January 2014 at 15:12:21 UTC, Ben Cumming wrote: On Monday, 13 January 2014 at 14:32:03 UTC, Dicebot wrote: I don't think 2.064 LDC has been released yet So I see, thanks. The merge-2.064 branch in Git is stable enough already for most purposes, so if you don't mind building from Git, you can have an LDC version based on 2.064.2 already. We really need to work out a plan to get a release done… ;) David
Re: Is continuously seeding a random number generator performance intensive?
On Thursday, 2 January 2014 at 20:38:10 UTC, Jeroen Bollen wrote: Is it good to re-seed a generator for every coordinate, will this be performance intensive? Is there maybe way to easily implement Generator.at(uint x) in D? http://www.valion-game.com/337/noise-functions-to-generate-landscapes/ I successfully implemented a D version of the above for my toy voxel engine project. I will be happy to share it ( it's currently not uploaded anywhere ).
Re: std.xml
Thanks Jacob and Dejan! I guess I can just build a generic DOM using one of those and replace the nodes I am interested with subclasses after the tree building process. I was thinking more of a library that allows me to say that a specific element (like svg) should use a specific subclass, but mapping after building is ok too I suppose.
Re: What's the D way of application version numbers?
On Mon, 2014-01-13 at 15:05 +, Dejan Lekic wrote: […] I simply define version in my main module (module which contains the main() function). I am planning to submit a DIP about something that is related to this. - I think we really need a way to specify version of package, and maybe even version of a module (similar to how the new Java module system works - see project Jigsaw). D does not offer this. I humbly believe it should be part of the language as it could be used also for building versions of dynamic libraries. For the version number to be available to SCons it cannot be embedded in the D source code. (Unless I am missing some really useful trick. :-) Anyway, back to the topic. Say my main() function is in the org.dlang.myapp module. If I want to have information about version of the artifact, my myapp.d starts with the following two lines of D code: module org.dlang.myapp; version = 1_3_21_4; // major_minor_micro_qualifier Python uses a tuple: (major, minor, bugfix, annotation) which seems to work very well: it needs very little reprocessing to be used in most contexts. Naturally, build tool looks for the version line when I need it. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
Le 12/01/2014 18:01, Benjamin Thaut a écrit :
Am 12.01.2014 17:18, schrieb Xavier Bigand:
Le 12/01/2014 11:16, Benjamin Thaut a écrit :
Am 12.01.2014 00:47, schrieb Xavier Bigand:
I didn't know this menu settings, but activate Access Violation don't
change anything.
It seems that your crash happens inside the OpenGL part of the graphics
driver. It is caused by
DQuick\src\dquick\renderer3D\openGL\mesh.d line 125
I assume that you setup a few OpenGL parameters invalid and thus the
driver reads from a null pointer.
I found it by single stepping. I started the application, then set the
breakpoint like shown below and single steppt into the draw() method.
debug
{
if (mRebuildDebugMeshes)
updateDebugMesh(); // put breakpoint here
mDebugMesh.draw();
if ((implicitWidth != float.nan implicitHeight != float.nan)
(implicitWidth != mSize.x implicitHeight != mSize.y))
mDebugImplicitMesh.draw();
}
Have fun debugging ;-)
Kind Regards
Benjamin Thaut
Thank for your support and your time
I already tried to debug opengl with gdebugger is used to find those
kind of issues. But it doesn't seems working fine with D binaries.
I higly recommend using either glIntercept
(http://code.google.com/p/glintercept/) or glslDevil
(http://www.vis.uni-stuttgart.de/glsldevil/) to debug OpenGL applications.
If you have a nvidia card you could also use nvidia nsight to debug your
application:
https://developer.nvidia.com/nvidia-nsight-visual-studio-edition
My guess would be that either your vertex buffer or index buffer is no
longer valid, thus gets not bound, and as a result the graphics driver
reads from client memory at address null.
Kind Regards
Benjamin Thaut
I took a look to buffers manually just before the glDrawElements call,
and all values seems good. I also check if any glDeleteBuffers and
glDeleteShader,... was called before the glDrawElements.
I need find some more time to test with glIntercept or nvidia nsight
Re: std.xml
On 2014-01-13 18:47, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: Thanks Jacob and Dejan! I guess I can just build a generic DOM using one of those and replace the nodes I am interested with subclasses after the tree building process. I was thinking more of a library that allows me to say that a specific element (like svg) should use a specific subclass, but mapping after building is ok too I suppose. I'm not sure what you're trying to do but the implementation in Tango uses structs for the nodes so you cannot subclass that. -- /Jacob Carlborg
Re: What's the D way of application version numbers?
On Monday, 13 January 2014 at 19:18:17 UTC, Russel Winder wrote:
On Mon, 2014-01-13 at 15:05 +, Dejan Lekic wrote:
[…]
I simply define version in my main module (module which
contains the main() function). I am planning to submit a DIP
about something that is related to this. - I think we really
need a way to specify version of package, and maybe even
version of a module (similar to how the new Java module system
works - see project Jigsaw). D does not offer this. I humbly
believe it should be part of the language as it could be used
also for building versions of dynamic libraries.
For the version number to be available to SCons it cannot be
embedded in
the D source code. (Unless I am missing some really useful
trick. :-)
Anyway, back to the topic.
Say my main() function is in the org.dlang.myapp module.
If I want to have information about version of the artifact,
my myapp.d starts with the following two lines of D code:
module org.dlang.myapp;
version = 1_3_21_4; // major_minor_micro_qualifier
Python uses a tuple:
(major, minor, bugfix, annotation)
which seems to work very well: it needs very little
reprocessing to be
used in most contexts.
Naturally, build tool looks for the version line when I need
it.
template DeclareVersion(T...)
{
static if (T.length == 4)
{
alias Version = T;
}
else
{
static assert(false, Version declaration must be of the
form Version!(major, minor, bugfix, annotation));
}
}
enum Version
{
major = 0,
minor = 1,
bugfix = 2,
annotation = 3,
}
//main.d
alias AppVersion = DeclareVersion!(1, 3, 21, 4);
import std.stdio;
void main()
{
writeln(AppVersion[Version.major]);
}
Kind of neat, it's even accessible at compile time and gets
compiled into the source.
Adding object files to dub build?
I have a pre-built sqlite3 object file which I'd like to include as part of the linking for the final executable. I have been unable to find a way to do this with dub. I have attempted adding: sourceFiles: [csqlite3.obj], This doesn't work since it is added to the compile stage, and there is nothing to be done. It appears it will not be included in the temp.obj created at this stage. I also tried: lflags: [csqlite3.obj], I'm surprised that this doesn't work, it is added to dmd's command line as -Lcsqlite3.obj which I would think the linker should pick up. I was able to build the executable without missing symbols by taking the temp.obj and combining it with the csqlite3.obj dmd .\temp.obj .\csqlite3.obj -- The follow up to this request is that I can't add flags to the link step, so that I could get verbose output of the link step.
Tyepof regex
what is the type returned by regex function?
I want to store a regex member because I need to reuse it
multiple times.
Can this be done?
class A {
protected SomeTypeName regexPattern;
void load() {
string str;
// obtain a regex pattern and store it as str.
regexPattern = regex( str );
}
bool matches() {
// use regexPattern
}
}
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
Le 13/01/2014 20:42, Xavier Bigand a écrit :
Le 12/01/2014 18:01, Benjamin Thaut a écrit :
Am 12.01.2014 17:18, schrieb Xavier Bigand:
Le 12/01/2014 11:16, Benjamin Thaut a écrit :
Am 12.01.2014 00:47, schrieb Xavier Bigand:
I didn't know this menu settings, but activate Access Violation don't
change anything.
It seems that your crash happens inside the OpenGL part of the graphics
driver. It is caused by
DQuick\src\dquick\renderer3D\openGL\mesh.d line 125
I assume that you setup a few OpenGL parameters invalid and thus the
driver reads from a null pointer.
I found it by single stepping. I started the application, then set the
breakpoint like shown below and single steppt into the draw() method.
debug
{
if (mRebuildDebugMeshes)
updateDebugMesh(); // put breakpoint here
mDebugMesh.draw();
if ((implicitWidth != float.nan implicitHeight != float.nan)
(implicitWidth != mSize.x implicitHeight != mSize.y))
mDebugImplicitMesh.draw();
}
Have fun debugging ;-)
Kind Regards
Benjamin Thaut
Thank for your support and your time
I already tried to debug opengl with gdebugger is used to find those
kind of issues. But it doesn't seems working fine with D binaries.
I higly recommend using either glIntercept
(http://code.google.com/p/glintercept/) or glslDevil
(http://www.vis.uni-stuttgart.de/glsldevil/) to debug OpenGL
applications.
If you have a nvidia card you could also use nvidia nsight to debug your
application:
https://developer.nvidia.com/nvidia-nsight-visual-studio-edition
My guess would be that either your vertex buffer or index buffer is no
longer valid, thus gets not bound, and as a result the graphics driver
reads from client memory at address null.
Kind Regards
Benjamin Thaut
I took a look to buffers manually just before the glDrawElements call,
and all values seems good. I also check if any glDeleteBuffers and
glDeleteShader,... was called before the glDrawElements.
I need find some more time to test with glIntercept or nvidia nsight
I finally tried glIntercept, but I am not sure how I need interpret the
output :
glViewport(0,0,801,600)
glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT)
glBindBuffer(GL_ARRAY_BUFFER,10)
glBufferData(GL_ARRAY_BUFFER,48,0604C000,GL_DYNAMIC_DRAW)
glBindBuffer(GL_ARRAY_BUFFER,0)
glBindBuffer(GL_ARRAY_BUFFER,11)
glBufferData(GL_ARRAY_BUFFER,64,0604E600,GL_DYNAMIC_DRAW)
glBindBuffer(GL_ARRAY_BUFFER,0)
glBindBuffer(GL_ARRAY_BUFFER,13)
glBufferData(GL_ARRAY_BUFFER,48,0604FFC0,GL_DYNAMIC_DRAW)
glBindBuffer(GL_ARRAY_BUFFER,0)
glBindBuffer(GL_ARRAY_BUFFER,14)
glBufferData(GL_ARRAY_BUFFER,64,0604E580,GL_DYNAMIC_DRAW)
glBindBuffer(GL_ARRAY_BUFFER,0)
glUseProgram(4)
glUniformMatrix4fv(0,1,false,[0.002497,0.00,0.00,0.00,0.00,-0.00,0.00,0.00,0.00,0.00,-0.01,0.00,-1.00,1.00,0.00,1.00])
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9)
glBindBuffer(GL_ARRAY_BUFFER,10)
glEnableVertexAttribArray(0)
glVertexAttribPointer(0,3,GL_FLOAT,false,12,)
glBindBuffer(GL_ARRAY_BUFFER,11)
glEnableVertexAttribArray(1)
glVertexAttribPointer(1,4,GL_FLOAT,false,16,)
glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,) GLSL=4
-glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT)
--glUseProgram(4)
--glUniformMatrix4fv(0,1,false,[0.002497,0.00,0.00,0.00,0.00,-0.00,0.00,0.00,0.00,0.00,-0.01,0.00,-1.00,1.00,0.00,1.00])
-glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9)
--glBindBuffer(GL_ARRAY_BUFFER,10)
--glEnableVertexAttribArray(0)
--glVertexAttribPointer(0,3,GL_FLOAT,false,12,)
--glBindBuffer(GL_ARRAY_BUFFER,11)
--glEnableVertexAttribArray(1)
--glVertexAttribPointer(1,4,GL_FLOAT,false,16,)
--glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,) GLSL=4
This extract seems to correspond of latest gl command called just before
the crash after the window resize. It doesn't seems to have any error here.
Re: Tyepof regex
On Monday, 13 January 2014 at 20:53:55 UTC, Tiberiu Gal wrote:
what is the type returned by regex function?
I want to store a regex member because I need to reuse it
multiple times.
Can this be done?
class A {
protected SomeTypeName regexPattern;
void load() {
string str;
// obtain a regex pattern and store it as str.
regexPattern = regex( str );
}
bool matches() {
// use regexPattern
}
}
The type is a template called Regex that is templated on the
character width.
struct A
{
Regex!char re;
this(string str)
{
re = regex(str);
}
}
There is also std.traits.ReturnType you can use for more complex
types or voldemort types.
Re: Tyepof regex
On Monday, 13 January 2014 at 20:53:55 UTC, Tiberiu Gal wrote:
what is the type returned by regex function?
I want to store a regex member because I need to reuse it
multiple times.
Can this be done?
class A {
protected SomeTypeName regexPattern;
void load() {
string str;
// obtain a regex pattern and store it as str.
regexPattern = regex( str );
}
bool matches() {
// use regexPattern
}
}
It's Regex!char
class A {
protected Regex!char regexPattern;
...
Re: Tyepof regex
On Monday, 13 January 2014 at 20:59:28 UTC, Brad Anderson wrote:
On Monday, 13 January 2014 at 20:53:55 UTC, Tiberiu Gal wrote:
what is the type returned by regex function?
I want to store a regex member because I need to reuse it
multiple times.
Can this be done?
class A {
protected SomeTypeName regexPattern;
void load() {
string str;
// obtain a regex pattern and store it as str.
regexPattern = regex( str );
}
bool matches() {
// use regexPattern
}
}
The type is a template called Regex that is templated on the
character width.
struct A
{
Regex!char re;
this(string str)
{
re = regex(str);
}
}
There is also std.traits.ReturnType you can use for more
complex types or voldemort types.
thank you
Re: Tyepof regex
On Monday, 13 January 2014 at 20:59:28 UTC, Brad Anderson wrote: There is also std.traits.ReturnType you can use for more complex types or voldemort types. Or: typeof(regex()) BTW, how does ReturnType handle overloads? -- Nicolas
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
Am 13.01.2014 21:52, schrieb Xavier Bigand: glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) glBindBuffer(GL_ARRAY_BUFFER,10) glEnableVertexAttribArray(0) glVertexAttribPointer(0,3,GL_FLOAT,false,12,) glBindBuffer(GL_ARRAY_BUFFER,11) glEnableVertexAttribArray(1) glVertexAttribPointer(1,4,GL_FLOAT,false,16,) glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,) GLSL=4 -glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT) --glUseProgram(4) --glUniformMatrix4fv(0,1,false,[0.002497,0.00,0.00,0.00,0.00,-0.00,0.00,0.00,0.00,0.00,-0.01,0.00,-1.00,1.00,0.00,1.00]) -glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) --glBindBuffer(GL_ARRAY_BUFFER,10) --glEnableVertexAttribArray(0) --glVertexAttribPointer(0,3,GL_FLOAT,false,12,) --glBindBuffer(GL_ARRAY_BUFFER,11) --glEnableVertexAttribArray(1) --glVertexAttribPointer(1,4,GL_FLOAT,false,16,) --glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,) GLSL=4 This extract seems to correspond of latest gl command called just before the crash after the window resize. It doesn't seems to have any error here. Yes this indeed looks correct. Maybe its even a bug in the driver. Because it happens right after the window resize graphic resource might got invalid and the driver would need to re-create them. The problem ist most likely that you use two array buffers, one for each attribute, instead of using one array buffer and interleaving the attribute (this is the usual way). I could bet, that if you switch over to the interleaved variant, the problem goes away. You could also try to make the three buffers slightly larger and specifiy different pointers to see which one actually causes the invalid read. So that the calls become: -glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) --glBindBuffer(GL_ARRAY_BUFFER,10) --glEnableVertexAttribArray(0) --glVertexAttribPointer(0,3,GL_FLOAT,false,12,) --glBindBuffer(GL_ARRAY_BUFFER,11) --glEnableVertexAttribArray(1) --glVertexAttribPointer(1,4,GL_FLOAT,false,16,0016) --glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,0004) GLSL=4 You could then see from the access violation which of the three buffers the read attempt fails. You could also try to move the glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) right before the glDrawElements call. Kind Regards Benjamin Thaut
In-Place Ordering of Elements
Does Phobos have some variadic algorithm to order l-value reference arguments in place? Something like int a=3; int b=2; int c=1; orderInPlace(a,b,c); // a is now 1 // b is now 2 // c is now 3 Also a functional variant, say `order(a, b, c)`, that returns a tuple would also be nice. See also https://stackoverflow.com/questions/21102646/in-place-ordering-of-elements.
Why is string.front dchar?
I'm curious, why is the .front property of narrow strings of type dchar? And not the underlying character type for the string.
Re: In-Place Ordering of Elements
On Monday, 13 January 2014 at 22:28:23 UTC, Nordlöw wrote:
Does Phobos have some variadic algorithm to order l-value
reference arguments in place? Something like
int a=3;
int b=2;
int c=1;
orderInPlace(a,b,c);
// a is now 1
// b is now 2
// c is now 3
import std.algorithm: map, sort;
import std.range: only;
int a=3;
int b=2;
int c=1;
static ref int deref(int* p) {return *p;}
sort(only(a, b, c).map!deref);
assert(a == 1);
assert(b == 2);
assert(c == 3);
Re: Why is string.front dchar?
TheFlyingFiddle: I'm curious, why is the .front property of narrow strings of type dchar? And not the underlying character type for the string. There was a long discussion on this. It was chosen this way to allow most range-based algorithms to work correctly on UTF8 and UTF16 strings. In some cases you can use the std.string.representation function to avoid to pay the UTF decoding, or/and to use some algorithms as sort(). But for backwards compatibility reasons in this code: foreach (c; somestring) c is a char, not a dchar. You have to type it explicitly to handle the UTF safely: foreach (dchar c; somestring) Bye, bearophile
Re: In-Place Ordering of Elements
anonymous:
static ref int deref(int* p) {return *p;}
sort(only(a, b, c).map!deref);
Despite some holes, std.algorithm and std.range are quite
powerful. Sometimes using them feels like playing a puzzle game
:-)
Bye,
bearophile
Re: Regarding std.range.indexed
Jesse Phillips: I thought it was to provide an index number during a foreach iteration. That's the enumerate() range, that is still missing in Phobos. If you have an randomAccess range with assignable elements, why use indexed? But source is immutable, so its elements aren't assignable. Bye, bearophile
Re: Why is string.front dchar?
On Monday, January 13, 2014 23:10:03 TheFlyingFiddle wrote: I'm curious, why is the .front property of narrow strings of type dchar? And not the underlying character type for the string. It's to promote the correct handling of Unicode. A couple of related questions and answers: http://stackoverflow.com/questions/12288465/std-algorithm-joinerstring-string-why-result-elements-are-dchar-and-not-ch http://stackoverflow.com/questions/16590650/how-to-read-a-string-character-by-character-as-a-range-in-d - Jonathan M Davis
Re: Why is string.front dchar?
On Tuesday, 14 January 2014 at 03:01:53 UTC, Jonathan M Davis wrote: On Monday, January 13, 2014 23:10:03 TheFlyingFiddle wrote: I'm curious, why is the .front property of narrow strings of type dchar? And not the underlying character type for the string. It's to promote the correct handling of Unicode. A couple of related questions and answers: http://stackoverflow.com/questions/12288465/std-algorithm-joinerstring-string-why-result-elements-are-dchar-and-not-ch http://stackoverflow.com/questions/16590650/how-to-read-a-string-character-by-character-as-a-range-in-d - Jonathan M Davis Also somewhat related: http://stackoverflow.com/questions/13368728/why-isnt-dchar-the-standard-character-type-in-d
Shared library string safety?
Alright, so I FINALLY got shared libraries somewhat working through my program, however I have some issues transferring data between the shared library and the main program, the problem is between https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/settings.d and https://github.com/MinekoRox/Breaker-Engine/blob/master/res/scripts/core/settings.d The settings script is loaded by https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/core.d And, this is the error I get: +start(string[]) Starting up the program 800600 B Shutting off the program Writing logs to disk ERROR: Error(s) occured, check the error log -start(string[]) +stop() Segmentation fault (core dumped) The 800600 is width and height, the problem is the binary output of what's supposed to be a string.
Re: Shared library string safety?
On Tuesday, 14 January 2014 at 05:50:37 UTC, Mineko wrote: Alright, so I FINALLY got shared libraries somewhat working through my program, however I have some issues transferring data between the shared library and the main program, the problem is between https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/settings.d and https://github.com/MinekoRox/Breaker-Engine/blob/master/res/scripts/core/settings.d The settings script is loaded by https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/core.d And, this is the error I get: +start(string[]) Starting up the program 800600 B Shutting off the program Writing logs to disk ERROR: Error(s) occured, check the error log -start(string[]) +stop() Segmentation fault (core dumped) The 800600 is width and height, the problem is the binary output of what's supposed to be a string. are you set your gc proxies for shared libs, right? if not, i think it would be safer to do string.dup(as with other arrays) when moving them between shared lib boundaries. but still keep in mind that current GC may not handle properly multiple intances. p.s. i don't do shared libs for non-Windows platform for a long time now, so it may be outdated info for now...
Re: Shared library string safety?
Sorry for the double post, I should be more specific. .dup worked, I don't know how to have the GC proxy for shared libs though.
Re: Shared library string safety?
On Tuesday, 14 January 2014 at 06:40:52 UTC, evilrat wrote: On Tuesday, 14 January 2014 at 05:50:37 UTC, Mineko wrote: Alright, so I FINALLY got shared libraries somewhat working through my program, however I have some issues transferring data between the shared library and the main program, the problem is between https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/settings.d and https://github.com/MinekoRox/Breaker-Engine/blob/master/res/scripts/core/settings.d The settings script is loaded by https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/core.d And, this is the error I get: +start(string[]) Starting up the program 800600 B Shutting off the program Writing logs to disk ERROR: Error(s) occured, check the error log -start(string[]) +stop() Segmentation fault (core dumped) The 800600 is width and height, the problem is the binary output of what's supposed to be a string. are you set your gc proxies for shared libs, right? if not, i think it would be safer to do string.dup(as with other arrays) when moving them between shared lib boundaries. but still keep in mind that current GC may not handle properly multiple intances. p.s. i don't do shared libs for non-Windows platform for a long time now, so it may be outdated info for now... Wow, um, that actually worked, thank you.
Re: Shared library string safety?
On Tuesday, 14 January 2014 at 06:48:48 UTC, Mineko wrote:
Sorry for the double post, I should be more specific.
.dup worked, I don't know how to have the GC proxy for shared
libs though.
the reason string.dup worked is due to GC on app side, right
after the moment your lib receive the original string it is may
be marked by GC for collection, so you need to save a copy on lib
side. but using the proxies it should work without copying.
for windows here is the topic about this http://dlang.org/dll.html
for *nix platforms it should be the same.
in short(pseudocode):
==
app.d
extern(C) void* gc_getProxy();
void main()
{
loadlib();
initLib( gc_getProxy() );
... do something ...
libFinalize();
}
--
lib.d
extern (C)
{
void gc_setProxy(void* p);
void gc_clrProxy();
}
export void initLib(void* gc)
{
gc_setProxy(gc);
}
export void libFinalize()
{
gc_clrProxy();
}
==
as i said i don't know about current status of shared libs, but
there was some progress on linux and Windows, and unfortunatelly
not OS X...
Re: Shared library string safety?
On Tuesday, 14 January 2014 at 07:23:52 UTC, evilrat wrote:
the reason string.dup worked is due to GC on app side, right
after the moment your lib receive the original string it is may
be marked by GC for collection, so you need to save a copy on
lib side. but using the proxies it should work without copying.
for windows here is the topic about this
http://dlang.org/dll.html
for *nix platforms it should be the same.
in short(pseudocode):
==
app.d
extern(C) void* gc_getProxy();
void main()
{
loadlib();
initLib( gc_getProxy() );
... do something ...
libFinalize();
}
--
lib.d
extern (C)
{
void gc_setProxy(void* p);
void gc_clrProxy();
}
export void initLib(void* gc)
{
gc_setProxy(gc);
}
export void libFinalize()
{
gc_clrProxy();
}
==
as i said i don't know about current status of shared libs, but
there was some progress on linux and Windows, and
unfortunatelly not OS X...
I see, I'll have to look more into that, on a slightly unrelated
note, any idea what's going on with glfwCreateWindow, it keeps
wanting to be null while it's supposed to be an adddress.
this.get = glfwCreateWindow(settings.width, settings.height,
toStringz(settings.title), this.monitor, this.share);
writeln(this.get);
That writeln will give me null, is it related to all this stuff?
