Re: Where is TypeInfo stored?
On Tuesday, 27 March 2018 at 19:06:38 UTC, Adam D. Ruppe wrote: On Tuesday, 27 March 2018 at 18:56:58 UTC, Jeremy DeHaan wrote: Are these put into the text or data segments? Yeah, they are in the data segment as static data (just like if you declared your own static array). Awesome, thanks. That is what I was hoping for.
Where is TypeInfo stored?
I was doing some experiments with the runtime and I didn't notice the TypeInfo instances being allocated by the GC. Are these put into the text or data segments? Is there anyway to find out more about this process?
How to change the file extension of generated doc files
I can't find anywhere describing how to change the extension of the generated doc files. I've tried `-of.php`, but it still generates .html. I'm probably missing something here that's going to make me feel silly.
Re: returning D string from C++?
On Saturday, 5 August 2017 at 20:17:23 UTC, bitwise wrote: I have a Windows native window class in C++, and I need a function to return the window title. [...] As long as you have a reachable reference to the GC memory SOMEWHERE, the GC won't reclaim it. It doesn't have to be on the stack as long as it is reachable through the stack.
Re: Size of D bool vs size of C++ bool
On Friday, 4 August 2017 at 20:38:16 UTC, Steven Schveighoffer wrote: On 8/4/17 4:16 PM, Jeremy DeHaan wrote: I'm trying to do some binding code, and I know that C++ bool isn't defined to be a specific size like D's bool. That said, can I assume that the two are the same size on the most platforms? I shudder to think that D may work with a platform that doesn't consider it to be 1 byte :) The only platforms I'm really interested in are Windows, Linux, OSX, iOS, FreeBSD, Android. The only thing that might throw me off is if there are some things that Linux or FreeBSD target where this is not the case, but these machines are probably out of the scope of my project. I would say any platform that D currently supports, C++ bool is defined to be 1 byte. The ldc/gdc guys would know better. -Steve Thanks, Steve. I was hoping this was the case and it will significantly simplify a lot of my binding code. I'm curious to see what systems don't have a bool size of 1 byte, but perhaps I'll put a check in my CMake file and prevent the project from building if it isn't.
Size of D bool vs size of C++ bool
I'm trying to do some binding code, and I know that C++ bool isn't defined to be a specific size like D's bool. That said, can I assume that the two are the same size on the most platforms? The only platforms I'm really interested in are Windows, Linux, OSX, iOS, FreeBSD, Android. The only thing that might throw me off is if there are some things that Linux or FreeBSD target where this is not the case, but these machines are probably out of the scope of my project.
Re: Adding deprecated to an enum member
On Tuesday, 1 August 2017 at 02:06:27 UTC, dark777 wrote: I did as follows using deprecated may help you to elucidate in relation to this https://pastebin.com/NEHtWiGx Deprecating an entire module isn't really a solution though. I only want parts of an existing enum to be deprecated when they are used.
Adding deprecated to an enum member
I got an error today because I added deprecated to an enum member.
Is there a way to achieve this, or am I out of luck? If it isn't
doable, should it be?
Here's what I want:
enum PrimitiveType
{
Points,
Lines,
LineStrip,
Triangles,
TriangleStrip,
TriangleFan,
Quads,
deprecated("Use LineStrip instead.")
LinesStrip = LineStrip,
deprecated("Use TriangleStrip instead.")
TrianglesStrip = TriangleStrip,
deprecated("Use TriangleFan instead.")
TrianglesFan = TriangleFan
}
PrimitiveType ptype = LinesStrip; //error, Use LineStrip instead.
Issue in _d_dso_registry on Linux when unloading DSO's
I'm running into this issue when I compile DRuntime in debug. In
sections_elf_shared.d, there's an assert on line 454
(assert(pdso._tlsSize == _tlsRanges.back.length);). Because of
this line, I get an assertion thrown, where the actual issue is
that _tlsRanges is empty and thus has no "back". The GC has been
finalized at this point in the program and can't actually
allocate the assertion, so I end up with a segfault.
The whole bit of code looks like this:
assert(pdso._tlsSize == _tlsRanges.back.length);
_tlsRanges.popBack();
assert(pdso == _loadedDSOs.back);
_loadedDSOs.popBack();
Right now my "fix" looks like this:
if(!_tlsRanges.empty)
{
assert(pdso._tlsSize == _tlsRanges.back.length);
_tlsRanges.popBack();
}
assert(pdso == _loadedDSOs.back);
_loadedDSOs.popBack();
I have no idea if this is safe to do since I am not familiar with
this code, but at least I don't have a segfault anymore. Can
anyone help me figure out what is going on?
MSVC path on windows
I'm trying to automate a build process for a project of mine, and I want to get the path to the MSVC toolchain DMD is using. I don't want to hard code any paths that may not work on some people's set-ups. I know there are some environmental variables such as VS140COMNTOOLS, VS120COMNTOOLS, etc. Are these reliable to get the location for some MSVC toolchain? I've also thought of parsing the PATH to figure out where dmd is installed and extract the info from the sc.ini file. Am I being ridiculous?
Re: Adding linker paths with spaces using dmd and msvc toolchain
On Friday, 30 December 2016 at 21:51:32 UTC, Rainer Schuetze wrote: On 30.12.2016 19:24, Jeremy DeHaan wrote: On Friday, 30 December 2016 at 04:56:59 UTC, Jerry wrote: On Friday, 30 December 2016 at 03:51:13 UTC, Jeremy DeHaan wrote: How does one correctly add a linker path that has spaces? The quotes get consumed by the command line. The way DMD spawns the linker by creating a new string with all the flags. Does this happen on other platforms too? There has to be a GOOD way to pass a linker path that has spaces. Should this be considered as a bug? Not sure if it qualifies as "GOOD", but this works: dmd -m64 "-L/LIBPATH:\"path with spaces\"" main.d Well, it's probably as good as it's going to get without dmd looking for this specifically or having something added. Thanks.
Re: Adding linker paths with spaces using dmd and msvc toolchain
On Friday, 30 December 2016 at 04:56:59 UTC, Jerry wrote: On Friday, 30 December 2016 at 03:51:13 UTC, Jeremy DeHaan wrote: How does one correctly add a linker path that has spaces? The quotes get consumed by the command line. The way DMD spawns the linker by creating a new string with all the flags. Does this happen on other platforms too? There has to be a GOOD way to pass a linker path that has spaces. Should this be considered as a bug?
Re: Adding linker paths with spaces using dmd and msvc toolchain
On Friday, 30 December 2016 at 04:56:59 UTC, Jerry wrote: On Friday, 30 December 2016 at 03:51:13 UTC, Jeremy DeHaan wrote: How does one correctly add a linker path that has spaces? The quotes get consumed by the command line. The way DMD spawns the linker by creating a new string with all the flags. So it smashes everything into a new string, ignoring how the string was passed into DMD. I think you can use triple quotes, """string with space""", and it should make the string passed to DMD include the string. Might be different for powershell. You mean I could do -L/LIBPATH:"""path"""?
Adding linker paths with spaces using dmd and msvc toolchain
I have a path to where some .libs are, and this path has some spaces in it. Using dmd and the msvc toolchain, I only seem to be able to correctly link .lib files if I pass them to the compiler with their full paths, or if I give the linker a relative path. When I add -L/LIBPATH:"path" to the command line, it ends up looking like this: -L/LIBPATH:"C:\Users\Jeremy DeHaan\Desktop\CODE\dsfml\lib". The linker will complain that it cannot open input file 'DeHaan\Desktop\CODE\dsfml\lib.obj'. How does one correctly add a linker path that has spaces?
What is the correct way to run the auto-tester tests on FreeBSD?
I'm trying to figure out how to run the auto-tester tests locally on FreeBSD and I'm running into an issue. I managed to get the tests to run on a 32 bit after a fashion, but I can't seem to get the tests to run successfully on the 64 bit version. Here's what I've done so far. git cloned dmd, druntime, and phobos. ran 'gmake -f posix.mak auto-tester-build' in the dmd directory ran 'gmake -f posix.mak' in both druntime and phobos directories ran 'gmake -f posix.mak auto-tester-test' in the dmd directory The tests start, however after the first test (issue8671.d) I get a strange error message: Error: module is in file '.d' which cannot be read Do I need to set up the system in a specific way to get these tests to properly run or is something else going on here? Note: this is using the master version of each repo, I'm not trying out my own branches yet.
Re: What is up with building DMD (et al.) on Windows?
On Wednesday, 11 May 2016 at 14:30:44 UTC, Vladimir Panteleev wrote: On Tuesday, 10 May 2016 at 04:48:23 UTC, Jeremy DeHaan wrote: Building DMD, Phobos, and druntime on Linux is so easy and straight forward. It all works as expected. What's up with building DMD on Windows? For historical reasons, the Windows makefiles take a different approach in many aspects. One important point is that they are limited to the feature set of the Digital Mars make implementation, which is extremely basic. There is one thing that I don't understand about the Windows makefiles though. The Posix makefiles for druntime and phobos use the dmd executable found in dmd/src/ and that makes sense. It is the one you should be using. That is not the case for the Windows makefiles though. It uses the one found on PATH even though it would be easy to do the same as the Posix version. Why is that?
Re: What is up with building DMD (et al.) on Windows?
On Wednesday, 11 May 2016 at 14:30:44 UTC, Vladimir Panteleev wrote: On Tuesday, 10 May 2016 at 04:48:23 UTC, Jeremy DeHaan wrote: After DMD is built, other things keep getting built by DMC. I get more than a few errors due to having an eof character on the first line of some .h files, or something like that. I've never seen such an error. Do you have the details? Late reply, but I was building DMD on a different computer today and it reminded me of this. After dmd.exe is built, I see the command `dmd -run checkwhitespace` with a bunch of files following it. The errors I see are from this. Error - file 'aggregate.h' contains windows line endings at line 1 Error - file 'aliasthis.h' contains windows line endings at line 1 Error - file 'arraytypes.h' contains windows line endings at line 1 And so on.
What is up with building DMD (et al.) on Windows?
I went to build DMD on Windows for the first time tonight and I have to say that it was a terrible experience when compared with Linux. First issue I ran into was having HOST_DC not being set. I'm not sure if the DMD installer is supposed to do this or if I needed to take care of it, but it wasn't mentioned anywhere I could find. I finally just set it myself. Then it builds DMD, but gets placed in dmd/src/ instead of its own directory. After DMD is built, other things keep getting built by DMC. I get more than a few errors due to having an eof character on the first line of some .h files, or something like that. I also built druntime, but instead of trying to use a freshly built dmd.exe in the neighboring DMD source directory, it went for the one in PATH. I haven't bothered to build Phobos on Windows yet. Building DMD, Phobos, and druntime on Linux is so easy and straight forward. It all works as expected. What's up with building DMD on Windows?
Re: How the heck is onInvalidMemoryOperationError() nothrow?
On Friday, 6 May 2016 at 03:24:23 UTC, tsbockman wrote: On Friday, 6 May 2016 at 02:57:59 UTC, Jeremy DeHaan wrote: [...] From the spec (https://dlang.org/spec/function.html#nothrow-functions): "Nothrow functions can only throw exceptions derived from class Error." Throwing an Error is, for many purposes, considered fundamentally different than throwing an Exception because Error objects aren't meant to be caught by user code. Throwing an Error is supposed to just be a way of crashing the program with a nice message and stack trace. A key benefit of this distinction, is that it enables the use of `assert()` statements in `nothrow` code. Oh, interesting. That makes sense, thanks.
How the heck is onInvalidMemoryOperationError() nothrow?
In core.exception, we have a lovely function called onInvalidMemoryOperationError(). This function is marked as nothrow (plus other annotations). This function literally does nothing except throwing an error. How can it be marked as nothrow?
Re: Destructor order
On Friday, 18 March 2016 at 15:07:53 UTC, Andrea Fontana wrote: On Friday, 18 March 2016 at 15:03:14 UTC, Steven Schveighoffer wrote: On 3/18/16 10:58 AM, Andrea Fontana wrote: On Friday, 18 March 2016 at 14:53:20 UTC, Steven Schveighoffer wrote: On 3/18/16 7:44 AM, Nicholas Wilson wrote: [...] I think technically not true. If you call __dtor directly, it does not recurse. But this is an implementation detail. Why doesn't this print ~B ~A? http://dpaste.dzfl.pl/0bef0a4316b7 It raises a bug on my code because dtor are called in "wrong" order. b holds a ref to a, why a is desctructed before b? Structs are contained completely within the class instance memory block (e.g. the OP's code). Classes are references. They are not destroyed when you destroy the holder, that is left up to the GC, which can destroy in any order. And in fact, it's a programming error to destroy any GC-allocated memory inside your dtor, because it may already be gone! -Steve Not the case. I'm writing a binding for a library. Class A and B wrap c-struct and on d-tor I have to free underlying c object calling c-library destroyer. I'm not destroying any d/GC-allocated object. But of course i have to destroy c object in the correct order... How to? You can't rely on classes to have their destructors call in any particular order. My guess is that the GC is going through and deallocating them in the order they appear on the heap. If you need destructors called in a reliable manner, use structs instead of classes or call destroy on your objects manually.
Re: Why does partial ordering of overloaded functions not take return type into account?
On Saturday, 20 February 2016 at 12:29:21 UTC, Jonathan M Davis wrote: On Saturday, February 20, 2016 03:24:45 Jeremy DeHaan via Digitalmars-d-learn wrote: snip I'm unaware of any language that takes the return type into account when overloading. The type the expression test.thing() has to be determined before the assignment is evaluated, and it would be very confusing if the return type were used for overload evaluation in a context like this, because there are other contexts where it would be impossible to do that even theoretically - the simplest being auto thingOne = test.thing(); So, suddenly, which function gets called would depend on where the expression was used, which would just be confusing and error-prone. - Jonathan M Davis With the case of auto of course there is ambiguity, you don't know which one to pick. In my example there should have been no ambiguity at all as only one of the overloads would actually compile. That is what confuses me and why I think return type should be taken into account. If there are multiple overloads that have the same number of parameters, a very simple addition to the rules of function overloading would be "does it compile?" If only one overload compiles, use it. If more than one compile, there is ambiguity and its an error.
Why does partial ordering of overloaded functions not take return type into account?
module main;
struct ThingOne
{
int thing = 1;
}
struct ThingTwo
{
float thing = 2;
}
struct Test
{
ThingOne thing()
{
return ThingOne();
}
ThingTwo thing()
{
return ThingTwo();
}
}
void main()
{
Test test;
ThingOne thingOne = test.thing();
}
test.d(35): Error: main.Test.thing called with argument types ()
matches both:
test.d(17): main.Test.thing()
and:
test.d(22): main.Test.thing()
Why isn't the return type checked when resolving this? Only one
of the choices would actually compile so there should be no
ambiguity.
Re: Struct destructors not always called?
On Sunday, 27 December 2015 at 18:47:52 UTC, Adam D. Ruppe wrote: On Sunday, 27 December 2015 at 18:40:55 UTC, Jeremy DeHaan wrote: I was playing around with some code today and I noticed that in some cases struct destructors are not called. struct destructors are called when the struct ceases to exist in the program. A global variable never ceases to exist as long as the program lives. So are these left dangling or do they actually get cleaned up at the program exit?
Struct destructors not always called?
I was playing around with some code today and I noticed that in
some cases struct destructors are not called.
for example:
impost std.stdio;
SomeStruct global;
void main()
{
SomeStruct inMain;
writeln(global.thing);
writeln(inMain.thing);
writeln(getSomeInt());
}
int getSomeInt()
{
static SomeStruct inner;
return inner.thing;
}
struct SomeStruct
{
int thing = 100;
~this()
{
writeln("destructor");
}
output is
100
100
100
destructor
Only inMain's destructor is ever called, or at least it is the
only one that ever prints "destructor" to the console. Are there
special rules for structs that I'm unaware of?
Re: Using a struct as a wrapper for an extern(C) opaque type, no default constructor, what do?
On Thursday, 17 December 2015 at 03:43:58 UTC, Jakob Ovrum wrote: On Thursday, 17 December 2015 at 03:31:37 UTC, Jeremy DeHaan wrote: Hi all. I'm interfacing to some C code which include an opaque type and some C functions that create and work with a pointer to that type. I want to wrap up everything in a struct, and the only thing that seems to bug me is initialization. Since it is C code, I obviously can't read the function that creates the opaque type. Not only that, I can't define a default constructor. What are my options here? This is for an API that is intended to be used by people other than myself, so I'd like to use something that doesn't look ugly or isn't a hack. I really don't like the idea of using a factory method or overriding opCall. Am I basically out of luck and need to resort to one of these methods? Using a factory function alongside @disable this(); is the canonical way to do this. Although, if your struct is a reference type, you can simply allow default construction and have it mean a null reference. Using static opCall here is just a factory function with special syntax, but I think it does more harm than good. Thanks. I guess what bugs me is that I always try to hide the fact that the API is a wrapper around C stuff, ie, I want to make people feel as though they're using idiomatic D. Doing something like this makes it feel like less idiomatic D and more like a wrapper. I think I have a solution that I like in my own case though. Right now I'm considering something like this: http://dpaste.com/3FH3W13
Re: Using a struct as a wrapper for an extern(C) opaque type, no default constructor, what do?
On Thursday, 17 December 2015 at 04:59:20 UTC, Jakob Ovrum wrote:
On Thursday, 17 December 2015 at 04:05:30 UTC, Jeremy DeHaan
wrote:
http://dpaste.com/3FH3W13
Also, I would be wary of lazy initialization. We have bad
experiences with it for AAs and standard containers. A typical
example would be:
void foo(Wrapper w)
{
...
w.doTheThing();
...
}
void main()
{
Wrapper w;
foo();
w.inspect(); // `w` is still a null reference here
}
Thanks for the heads up. I'll think more on this, but you made a
good point here.
And I guess what I was talking about before is that using a
factory method feels klunky to me. If the things I am wrapping
had been written in D they could use default initialization, so
it feels wrong to do otherwise. I also just don't really like
factory methods. They feel like a workaround that the end user
has to deal with. But that's just me.
Using a struct as a wrapper for an extern(C) opaque type, no default constructor, what do?
Hi all. I'm interfacing to some C code which include an opaque type and some C functions that create and work with a pointer to that type. I want to wrap up everything in a struct, and the only thing that seems to bug me is initialization. Since it is C code, I obviously can't read the function that creates the opaque type. Not only that, I can't define a default constructor. What are my options here? This is for an API that is intended to be used by people other than myself, so I'd like to use something that doesn't look ugly or isn't a hack. I really don't like the idea of using a factory method or overriding opCall. Am I basically out of luck and need to resort to one of these methods?
Re: scope keyword
On Thursday, 19 November 2015 at 23:16:04 UTC, Spacen Jasset wrote: I thought scope was deprecated, but I see that this is still here: http://dlang.org/attribute.html#scope Is it just the uses on classes and local variables that are discouraged, but the use in a function signature will continue? in == const scope? Using scope to allocate on the stack is what you are thinking of, but it was only marked for deprecation. http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack
Re: OSX Foundation framework D binding
On Thursday, 12 November 2015 at 05:50:09 UTC, Vadim Lopatin wrote: On Wednesday, 11 November 2015 at 16:04:44 UTC, Jacob Carlborg wrote: On 2015-11-11 17:02, Jacob Carlborg wrote: I would recommend creating new bindings which use the new Objective-C interoperability feature that was added in the latest release (2.069.0). You could use DStep [1] to generate the bindings. It will generate bindings which are not completely compatible with what the compiler can handle. But it can be used as a base. [1] https://github.com/jacob-carlborg/dstep Aren't there any ready set of translated and post-processed files for main OSX foundations in some repository? Could you point at it? That's doubtful. OS X interoperability is pretty new. If anyone has done any bindings like what you want I don't think they've announced it.
Re: How to generate D binding with SWIG?
Do you even need to use swig? It looks like gdal has a C interface. I think that htod would be what you're looking for http://dlang.org/htod.html
gdc and ldc command line examples?
Hey all, I am finally working on moving out of dmd territory and playing with gdc and ldc. I was hoping that I could get some links to some example command lines. I'm mainly interested command lines regarding linking to libraries and building static libraries. My guess is that gdc will function essentially the same as gcc for these things, or at least close enough to where I can figure it out, but I have had no experience with ldc and I am having trouble tracking down documentation for it. Thanks!
Re: How to make Application bundle from Executable? (Mac)
On Friday, 20 February 2015 at 03:26:47 UTC, Gan wrote: I managed to copy an application bundle and change stuff inside it to run my executable, but it was very manual and kinda hackish. Also I can't get my application to load images that I place in the Resources folder(or any folder in the bundle for that matter). Is there an official way to turn a D executable into a Mac Application Bundle? I don't have an answer, but I too am interested in hearing what others have to say about this.
Re: windows wininet library
On Sunday, 1 February 2015 at 07:32:05 UTC, ketmar wrote: how can i use wininet.dll from D? i got bindings from https://github.com/ CS-svnmirror/dsource-bindings-win32.git, and then i tried to create wininet.lib with implib.exe from DMC package. no matter how i tried, the resulting wininet.lib seems to not work, as linker keep complaining about missing symbols like _InternetReadFile@16 and so on. i'm building for win32. ah, and yep, i compiled wininet.lib to lib dir, and added option to dmd.exe: -L+wininet.lib. i assume that i have to create corrent .def file to remap all the names, am i right? oh, delightful... What does your implib command look like?
Deducing a template retrun parameter type based on an assignment?
I have a template fuction that looks like this: immutable(T)[] getString(T)() const if (is(T == dchar)||is(T == wchar)||is(T == char)) Basically, I was hoping that the type would be deduced based on the prameter that was being assigned to like so. string ret = thing.getString(); Apparently that does not work, though. I get informed that the type of the template is not able to be deduced. I'm curious as to why it was not able to deduce it on its own. Additionally, and I haven't run my code to try this yet, but giving T a default type compiled to my surprise. immutable(T)[] getString(T=char)() const if (is(T == dchar)||is(T == wchar)||is(T == char)) Is something like this supposed even to work?
Re: Deducing a template retrun parameter type based on an assignment?
On Friday, 30 January 2015 at 06:58:58 UTC, Vlad Levenfeld wrote: On Friday, 30 January 2015 at 06:35:31 UTC, Jeremy DeHaan wrote: A bunch of stuff for template type deduction to work, you have to supply an argument. Your type signature would need to look like this: immutable(T)[] getString(T)(T arg) const and then T would be deduced from arg. That seems strange. I figured that it would be smart enough to deduce the parameter type based on the type that it was trying to be assigned to. But string ret = thing.getString(); won't compile because it is rewritten to getString(thing), but your getString function takes no runtime parameters. It looks like the signature I wrote earlier is what you actually want. Whoops. I should have mentioned that this is a member function in a class and not a free fiction. Not that it changes much about the deduction. As to your second example, it'll work fine. Basically your signature says only accept dchar, wchar or char, but if nothing's been specified, default to char. But if you rewrite getString to take one parameter, then the default template arg is redundant. That is good to hear. It seemed like that was the way it would work, but I've never had to specify a default template parameter type. I'm hoping to avoid having to specify a template parameter, but it seems like it can't be helped if users want to get their string type as a wstring or dstring though.
Re: xcb error for core.thread's Thread.join
On Monday, 29 December 2014 at 07:23:32 UTC, Rikki Cattermole wrote: On 29/12/2014 7:39 p.m., Jeremy DeHaan wrote: On Monday, 29 December 2014 at 06:34:02 UTC, Jeremy DeHaan wrote: On Monday, 29 December 2014 at 06:26:04 UTC, Jeremy DeHaan wrote: Hey all, I've never gotten any xcb errors with just regular D code before, but maybe I just haven't done anything that would have caused them. I can't say I actually know much about how these things work, but does D not use xcb when it does threading on Linux? I'm not really doing anything that I could call complicated. I am creating a secondary thread and just outputting some text to the console from both threads. The error itself seems to happen on a call to Thread.join, though I can't say why. Looks like it isn't the call to Thread.join, that was just a coincidence for my writeln debugging. If I have the second thread going it just happens. Not sure if this makes any difference, but I don't get any errors when I let the main thread sleep, but the main thread and secondary thread do not run simultaneously. XCB and xlib in general is not thread safe. They should only ever be called on one thread. Although I'm guessing you're not directly interfacing with it in which case that little tidbit isn't much use to you. But I thought that XCB was thread safe.
Re: xcb error for core.thread's Thread.join
On Monday, 29 December 2014 at 06:26:04 UTC, Jeremy DeHaan wrote: Hey all, I've never gotten any xcb errors with just regular D code before, but maybe I just haven't done anything that would have caused them. I can't say I actually know much about how these things work, but does D not use xcb when it does threading on Linux? I'm not really doing anything that I could call complicated. I am creating a secondary thread and just outputting some text to the console from both threads. The error itself seems to happen on a call to Thread.join, though I can't say why. Looks like it isn't the call to Thread.join, that was just a coincidence for my writeln debugging. If I have the second thread going it just happens.
Re: xcb error for core.thread's Thread.join
On Monday, 29 December 2014 at 06:34:02 UTC, Jeremy DeHaan wrote: On Monday, 29 December 2014 at 06:26:04 UTC, Jeremy DeHaan wrote: Hey all, I've never gotten any xcb errors with just regular D code before, but maybe I just haven't done anything that would have caused them. I can't say I actually know much about how these things work, but does D not use xcb when it does threading on Linux? I'm not really doing anything that I could call complicated. I am creating a secondary thread and just outputting some text to the console from both threads. The error itself seems to happen on a call to Thread.join, though I can't say why. Looks like it isn't the call to Thread.join, that was just a coincidence for my writeln debugging. If I have the second thread going it just happens. Not sure if this makes any difference, but I don't get any errors when I let the main thread sleep, but the main thread and secondary thread do not run simultaneously.
Segmentation fault after having a certain number of elements in an array?
I'll be trying to narrow it down even more tomorrow, but I was
hoping somone here might have some insight into this weird issue
I am having.
I have a dynamic array of shorts that I had been trying to append
to (capturing sound data). I kept getting a segfault when doing
the append, and have narrowed it down to getting a segfault when
the length of the array is equal to or greater than 1024.
It looks wonky because of my many tests, but this is the code
that was causing the segfault:
override bool onProcessSamples(const(short)[] samples)
{
import std.stdio;
for(int i = 0; isamples.length; ++i)
{
writeln(m_samples.length);
m_samples.length +=1;
}
return true;
}
It will print all the numbers, endikng with 1023, and then it
shows Segmentation fault and if I comment out the writeln line
it just shows the Segmentation fault line. Similar code that
would cause the length to be at 1024 or higher will also cause a
segfault.
The class that this method belongs to is wraped up in a C++
interface and it gets called C++ side.
Also, if I set the length to 1024 or higher in the class
constructor or if I create a different array elsewhere and set
its length to 1024 or higher, I don't get the segfault anymore.
As far as I can tell, this only happens because it is called in
C++ code. It doesn't appear to happen on my system at all if I do
anything like this outside of my C++ interoperating. So far my
fix is to set the length of the array to 1024, and then right
away set it back to 0 in the class' constructor, but I'd like to
get this to work without any strange hacks.
Re: Segmentation fault after having a certain number of elements in an array?
I should also mention that this is on Linux. I haven't tried on OSX or Windows yet.
Re: Segmentation fault after having a certain number of elements in an array?
On Saturday, 13 December 2014 at 09:24:51 UTC, Paul wrote: On Saturday, 13 December 2014 at 08:59:19 UTC, Jeremy DeHaan wrote: for(int i = 0; isamples.length; ++i) m_samples.length +=1; You are testing i against an ever-increasing limit aren't you, so it's an infinite loop. Not really. When the function is called, the length of samples (Incoming sound data) is usually around 4000. m_samples (the total samples recorded) doesn't make it past 1024 in length without segfaulting. It probably doesn't matter, but the array passed to this function is actually a slice created from a pointer and length generated in the C++ side.
Re: Segmentation fault after having a certain number of elements in an array?
On Saturday, 13 December 2014 at 09:47:40 UTC, Artem Tarasov wrote: On Saturday, 13 December 2014 at 08:59:19 UTC, Jeremy DeHaan wrote: I'll be trying to narrow it down even more tomorrow, but I was hoping somone here might have some insight into this weird issue I am having. Could you upload the code to somewhere? With only a small snippet, it's hard to get any clue. Yes, but it might take some time. I'll have to make a reduced c++ and D portion. I'll see what I can manage.
The package feature is ignored when the file name is package.di
Is this on purpose? Granted, I almost never use interface files, but I had a whim to use them for what I was working on today. Everything worked fine when I renamed the file to package.d, but apparently package.di is not acceptible.
Re: Audio file read/write?
On Friday, 7 November 2014 at 11:55:16 UTC, ponce wrote: Pretty sure libsndfile can read .wav, .au, .ogg but not mp3 No commercial usage unless you pay a licence. https://github.com/p0nce/DerelictSndFile.git Not sure about the others, but you can use sndfile in a commercial project for free as long as you follow the correct steps for linking/including the licenses. http://www.mega-nerd.com/libsndfile/FAQ.html#Q021
Re: DDoc module description?
Thanks for the reply. I just went through it and I didn't see anything that was missed. I'll post this here so that maybe someone can see something I am missing. DDOC = html head META http-equiv=content-type content=text/html; charset=utf-8 link rel=stylesheet type=text/css media=screen href=stylesheets/stylesheet.css title$(TITLE)/title /head body !-- HEADER -- div id=header_wrap class=outer header class=inner a id=forkme_banner href=https://github.com/Jebbs/DSFML;View on GitHub/a h1 id=project_titleDSFML/h1 section id=downloads a class=zip_download_link href=https://github.com/Jebbs/DSFML/zipball/master;Download this project as a .zip file/a a class=tar_download_link href=https://github.com/Jebbs/DSFML/tarball/master;Download this project as a tar.gz file/a /section /header /div !-- MAIN BODY -- div id=main_content_wrap class=outer section id=main_content class=inner h1$(TITLE)/h1 $(BODY) /section /div !-- FOOTER -- div id=footer_wrap class=outer footer class=inner /footer /div /body /html The problem seems to be when I do something like this. *blah.d* ///A module that contains blahblahblah. module something.blah; //Stuff goes here What will end up happening is the generated html file turns out like this: html !-- All the generated stuff here -- /html A module that contains blahblahblah. As you can see, the module description is put outside the html tag. If I don't redefine the DDOC macro, it will place the module description inside the body tag just after h1$(TITLE)/h1. Is this a DDoc bug?
Re: DDoc module description?
On Sunday, 19 October 2014 at 16:59:10 UTC, Gary Willoughby wrote: On Sunday, 19 October 2014 at 16:44:25 UTC, Jeremy DeHaan wrote: The problem seems to be when I do something like this. *blah.d* ///A module that contains blahblahblah. module something.blah; //Stuff goes here What will end up happening is the generated html file turns out like this: html !-- All the generated stuff here -- /html A module that contains blahblahblah. Try it using a normal comment style like this: /** * A module that contains blahblahblah. */ module something.blah; See if that compiles differently, it may be a bug with triple slash comments. No change. It still places the comment outside the html tag.
Re: DDoc module description?
That's ok though. I can live with out it. I'll look through the bugzilla site and see if I can find a bug report for this or open up a new one. On a side note, is there any way that I can redefine the DDOC macro (or any other macro) once and have it be used for every file? That was the only thing I couldn't seem to find in the documentation for it.
Re: DDoc module description?
On Sunday, 19 October 2014 at 18:19:26 UTC, Gary Willoughby wrote: On Sunday, 19 October 2014 at 17:43:51 UTC, Jeremy DeHaan wrote: That's ok though. I can live with out it. I'll look through the bugzilla site and see if I can find a bug report for this or open up a new one. On a side note, is there any way that I can redefine the DDOC macro (or any other macro) once and have it be used for every file? That was the only thing I couldn't seem to find in the documentation for it. Just add the following line to your dmd.conf file (on GNU/Linux) or sc.ini file (on Windows): DDOCFILE=file http://dlang.org/dmd-windows.html#sc-ini http://dlang.org/dmd-linux.html#dmd-conf Is there no way to specify one at compile time? Also, if I were to set the DDoc file like you suggest, does it look for one locally to dmd.conf/sc.ini or to the source code? Additionally, I found out what was going on. When I redefined DDOC, I did so right before the module description so it ended up combining the two documentation blocks together putting the description after the html block. I just swapped them so that the module description appeared before I redefined the DDOC macro and it worked as expected again.
DDoc module description?
Although perhaps unnecessary, I added DDoc documentation to my module for a short description of the body. This showed up in the place I wanted it to be in when I built the html documentation, so I was pretty happy. (below the module name and before any module members) I then went to override the DDOC macro to set it up with the correct formatting with the rest of the site I'll be putting the documentation on. The single line documentation I had written for the module apparently does not reside in BODY, and with the new formatting, it just casts it to the bottom of the page. It now resides below the footer. Is there anything I can do to correct this? If not then I'll just say screw it and not bother, but I thought it looked pretty nice. Especially for modules that have more than one class in them.
Initializing D in C to use?
I'm starting a new project, and I plan on creating a C interface in case other languages want to use it. I remember reading something(but my googlefu is weak today) about having to initialize the runtime if you are using D inside another language. Can anyone confirm this is the case? I just wanted to make sure I make that explicit for users if they don't want to use the library with D. Thanks all! Jeremy
Re: Recommended GUI library?
I highly recommend gtkD. It works on Windows, OSX, and Linux and provides a very nice OO interface to Gtk+. http://gtkd.org/
Why was scope for allocating classes on the stack marked for deprecation?
I'm curious as to why using scope to allocate classes on the stack was marked for future deprecation. I mean, sure it could be potentially unsafe, but the new library solution (using std.typecons.scoped) does the exact same thing and is just as unsafe for the same reasons, is it not? I would rather continue to use the keyword scope instead of having to import another module in order to use this feature.
Re: Initializing D in C to use?
On Friday, 17 October 2014 at 17:21:11 UTC, Adam D. Ruppe wrote: On Friday, 17 October 2014 at 17:14:30 UTC, K.K. wrote: Sorry if this isn't the most helpful answer but.. Do you have Adam Ruppe's book? buy my book too, and write amazon reviews :P A lot of the topics in there were chosen because there are questions that come up somewhat often on this forum or the D chat room. I answer a lot of questions here too, but the book is cool too! I actually do own it! I just haven't had as much time as I would like to go through it. Thanks for the answers everyone!
Error with constraints on a templated fuction
I've done things like this before with traits and I figured that
this way should work as well, but it gives me errors instead.
Perhaps someone can point out my flaws.
immutable(T)[] toString(T)(const(T)* str)
if(typeof(T) is dchar)//this is where the error is
{
return str[0..strlen(str)].idup; //I have strlen defined for
each *string
}
I was going to add some || sections for the other string types,
but this one won't even compile.
src/dsfml/system/string.d(34): Error: found ')' when expecting
'.' following dchar
src/dsfml/system/string.d(35): Error: found '{' when expecting
identifier following 'dchar.'
src/dsfml/system/string.d(36): Error: found 'return' when
expecting ')'
src/dsfml/system/string.d(36): Error: semicolon expected
following function declaration
src/dsfml/system/string.d(36): Error: no identifier for
declarator str[0 .. strlen(str)]
src/dsfml/system/string.d(36): Error: no identifier for
declarator .idup
src/dsfml/system/string.d(37): Error: unrecognized declaration
It compiles if I remove the 'if(typeof(T) is dchar)' section. Any
thoughts?
Re: Error with constraints on a templated fuction
On Monday, 25 August 2014 at 15:59:38 UTC, ketmar via Digitalmars-d-learn wrote: On Mon, 25 Aug 2014 15:48:10 + Jeremy DeHaan via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: It compiles if I remove the 'if(typeof(T) is dchar)' section. Any thoughts? is should be used as function. here. i.e.: `if (is(T == dchar))` Is its ability to be used as a function like this documented anywhere? I looked and could not find it.
Re: Error with constraints on a templated fuction
On Monday, 25 August 2014 at 15:52:20 UTC, bearophile wrote: Jeremy DeHaan: It compiles if I remove the 'if(typeof(T) is dchar)' section. Any thoughts? Try: if (is(T == dchar)) Bye, bearophile That one compiles, and I'm assuming it works. I didn't know you could use is this way. I've only seen it as an 'obj1 is obj2' sort of way. Thanks much!
Re: Error with constraints on a templated fuction
On Monday, 25 August 2014 at 16:20:24 UTC, ketmar via Digitalmars-d-learn wrote: On Mon, 25 Aug 2014 16:11:27 + Jeremy DeHaan via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Is its ability to be used as a function like this documented anywhere? I looked and could not find it. http://dlang.org/concepts.html template constraints is a special case. is not a real function here, it's more like special predicate syntax. Awesome! Thanks so much.
Re: Very vague compiler error message
I didn't have access to my compute for longer than I thought, but
I finally got around to this.
After some messing around, I not only managed to track down the
cause, but I got it fixed and the Audio module for DSFML is back
to where it was.
In one of my D classes, SoundStream, I defined a struct called
Chunk, which held a chunk of sound data. It looks like this:
struct Chunk
{
const(short)* samples;
size_t sampleCount;
}
All of the streaming is actually happening in an extern(C++)
interface instance, and with the help of Dustmite, the method
that caused the initial error was this:
extern(C++) bool onGetData(SoundStream.Chunk* chunk);
I think because it has a D Class member as the parameter type in
an extern(C++) class method the D compiler broke?
What I did to fix it was I changed Chunk from being a member of
SoundStream and declared it as a extern(C++) struct instead.
That changed onGetData to extern(C++) bool onGetData(Chunk*
chunk); and the compiler was ok with that.
I might do some more testing to see if I can reproduce the error,
but changing the parameter type fixed it for me.
Re: Very vague compiler error message
On Thursday, 14 August 2014 at 13:47:58 UTC, Théo Bueno wrote: On Thursday, 14 August 2014 at 13:28:03 UTC, bearophile wrote: Théo Bueno: Same issue here with dsfml-audio, this is really annoying :/ Have you filed the issue? Bye, bearophile Jebbs filed an issue on his bugtracker : https://github.com/Jebbs/DSFML/issues/125 ... and he seems to have a fix, or at least a clue. Personally, I was not able to figure out where is the bug. Yeah, sorry. I did get it to compile, but I didn't have access to my computer last night unexpectedly and I haven't checked it to confirm that the audio module still works. If everything does still work, then I'll upload the fix in the next couple of hours.
Re: Identifying 32 vs 64 bit OS?
On Monday, 11 August 2014 at 06:17:22 UTC, ketmar via Digitalmars-d-learn wrote: On Mon, 11 Aug 2014 05:18:59 + Jeremy DeHaan via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: why do you need that info? D types has well-defined sizes (i.e uint is always 32 bits, and so on). I came up with a better solution for what I actually needed, but I was toying with some things in a rdmd build script for different kinds of compilation.
Very vague compiler error message
I recently got this error messege when building my library: dmd: cppmangle.c:154: void CppMangleVisitor::cpp_mangle_name(Dsymbol*): Assertion `0' failed. I have no idea what it means and haven't found much information about it. I think I have narrowed it down to the file that is giving this error, but does anyone know what the heck causes something like this? Talk about a nondescript error.
Re: Very vague compiler error message
Awesome, thanks everyone. I'll take the suggestion to use Dustmite as an excuse to familiarize myself with it, but if normally extern(C++) types cause it I know just where to look.
Identifying 32 vs 64 bit OS?
I am looking at these versions as described here: http://dlang.org/version.html There are X86 and X86_64 version identifiers, but these specifically mention that they are versions for the processor type. Can they also be used to determine if the OS is running in 32 vs 64 bits?
Re: Passing Command Line Arguments to a new Thread
On Thursday, 7 August 2014 at 18:23:26 UTC, Nordlöw wrote:
What is the best way to forward a string[] as argument to a
function called through std.concurrency.spawn().
I need this in the following example where I start the vibe.d
event loop in the main thread (the only way I've managed to get
runEventLoop() to work) and run my other program logic in
another which requires command line arguments to passed to the
new thread.
void otherMain(string[] args)
{
// use args
}
void main(string[] args)
{
import std.concurrency: spawn;
auto otherMainTid = spawn(otherMain, args); // this line
fails
runEventLoop();
}
The line calling spawn() fails as
/home/per/opt/x86_64-unknown-linux-gnu/dmd/linux/bin64/src/phobos/std/concurrency.d(442):
Error: static assert Aliases to mutable thread-local data not
allowed.
If you don't care how you get the args to otherMain, you can also
use Runtime.args. That way you wouldn't even need to pass it to
the function in the first place.
http://dlang.org/phobos/core_runtime.html#.Runtime.args
Re: Building 32bit program with MSVC?
On Friday, 30 May 2014 at 20:48:44 UTC, Kagamin wrote: You can try ldc, which uses mingw toolchain, it's probably compatible with msvc. I don't necessarily need to do this, I was just wondering if it was possible. Mostly because MSVC provides a lot of import and static libraries that DMC doesn't, and MSVC is supported in a lot of major tools(such as CMake) where DMC isn't.
Building 32bit program with MSVC?
I know that we can use MSVC to build a 64 bit program, but is it also possible to use it to build a 32 bit program as well?
Re: Problem with code coverage. No .lst files?
On Friday, 25 April 2014 at 08:20:37 UTC, Jeremy DeHaan wrote:
On Friday, 25 April 2014 at 04:23:45 UTC, Ali Çehreli wrote:
On 04/24/2014 08:32 PM, Jeremy DeHaan wrote:
added the -cov switch to my unit test build
Then you must execute the program. :)
Ali
I did, but still nothing. I even tried using the switch in a
debug build and the same thing happened(or didn't happen I
guess). I'm using Mono-D to build if that makes any difference,
and I've tried running it both through Mono-D and via the
application itself. I'm not sure what to do. :(
Well, I think I found out what was happening. If you compile with
-cov AND use -of where the output file is in a different
directory than where the build is taking place(eg, buld happens
in C:/DProject/, and the command line has
-ofC:/DProject/Unittest/Unittest.exe), no .lst files are
produced. I guess the compiler isn't sure where to put them? In
any case, I removed the -of switch and when I ran that
application .lst files were now created in the same directory as
the application. Is this a bug that needs to be reported?
Here's a simple test that reproduces the issues.
test.d
===
module test;
class Test
{
int thing;
this(int newThing)
{
thing = newThing;
}
void showThing()
{
import std.stdio;
writeln(thing);
}
}
unittest
{
auto tester = new Test(100);
tester.showThing();
}
command line that will produce .lst file: dmd test.d -cov
-unittest -main -ofWill.exe
command line that won't produce .lst file: dmd test.d -cov
-unittest -main -oftest\Wont.exe
Re: Problem with code coverage. No .lst files?
On Sunday, 27 April 2014 at 00:37:39 UTC, Ali Çehreli wrote: So, under Linux, if I start the program as test/wont then the .lst gets generated in the current directory. Ali Just tried that in Windows, and the same thing happened. Weird! I'll be sure to file a bug report. Thanks for the confirmation, Ali!
Re: Problem with code coverage. No .lst files?
On Friday, 25 April 2014 at 04:23:45 UTC, Ali Çehreli wrote: On 04/24/2014 08:32 PM, Jeremy DeHaan wrote: added the -cov switch to my unit test build Then you must execute the program. :) Ali I did, but still nothing. I even tried using the switch in a debug build and the same thing happened(or didn't happen I guess). I'm using Mono-D to build if that makes any difference, and I've tried running it both through Mono-D and via the application itself. I'm not sure what to do. :(
Problem with code coverage. No .lst files?
Hey all, I tried to use code coverage analysis for the first time tonight. I added the -cov switch to my unit test build, but no matter what I do, I can't seem to locate the produced .lst files. Is there something I should know that isn't in the docs that I might be doing wrong? I'm not sure what's going on here. Thanks, Jeremy
