Re: Linker errors after updating to DMD 2.060
Make sure you completely wipe out your old installation. Several modules were _removed_ that may be still hanging around. On top of that, ensure that you're not linking any object files from 2.059 with new object files from 2.060 (i.e. do a complete rebuild).
Re: float.nan is not itself ?
On Tuesday, 14 February 2012 at 15:39:37 UTC, Joshua Reusch wrote: Hello, why does this assertion fail: > assert(float.nan == float.nan); there is the std.math.isNaN function which works correctly, but why can I not just use the comparison ? Thanks, Joshua Use `float.nan is float.nan`; all other expressions with NaNs in them will be false (or result in NaN).
Re: xml Bible for conversion for D
On Wed, 19 Oct 2011 21:45:29 +1300, Joel Christensen wrote: > I don't care to learn xml at this stage. What do you mean by "learn xml"? I'm saying std.xml is a terrible library, and furthermore will be deprecated sooner or later. Use another library. There is already a suggestion in this thread, and I can give one too if you want. Friends don't let friends use std.xml.
Re: xml Bible for conversion for D
On Wed, 19 Oct 2011 07:04:53 +, Bernard Helyer wrote: > meen Just not my day, is it?
Re: xml Bible for conversion for D
On Wed, 19 Oct 2011 07:03:05 +, Bernard Helyer wrote: > and the power of Satan* Err, I can see how that could be construed as in poor taste, considering the subject matter of the XML document. I meen no offense. >_<
Re: xml Bible for conversion for D
On Wed, 19 Oct 2011 18:21:22 +1300, Joel Christensen wrote: > I think I want to stick with the current std xml library for now. No, you don't. It's a terrible library, held together by lashings of hate and the power of Satan* *only half kidding
Re: clear bug?
clear() nulls out the vtable.
Re: DMD Backend: Deciding instructions to use/avoid?
If you run the program in GDB, can you disassemble when the error is given? That may give you the instruction the kernel is assasinating your process for.
Re: Anyone know why system change directory calls don't work?
On Sun, 29 May 2011 00:54:10 -0400, Andrej Mitrovic wrote: > E.g.: > > import std.process; > system(r"cd C:\newfolder"); // no effect > > It just stays in the same folder as the exe. I can use > SetCurrentDirectoryA as an alternative, but why doesn't it work via the > system call? Because system starts a shell process -- the cd only affects that process, not the parent process (that's you!).
Re: implib
implib is for working with Windows libraries. Why on earth do you need it on OS X?
Re: Else clauses for loops
You could wrap the loop in an if clause:
if (condition) while (true) {
// ...
} else {
// ...
}
Re: Input handling? (newbie alert!)
On Thu, 09 Sep 2010 18:07:43 -0700, Jonathan M Davis wrote: > Yes std.stdio.readln() would be a much better way to go. However, I'd > suggest using std.conv.parse() rather than std.conv.to(). It's less > picky about whitespace, and it allows you to deal with the case where > you have multiple values on the same line. For string manipulation > functions, check out the functions in std.string. > > - Jonathan M Davis D'oh. I completely forgot that std.conv.parse existed! >_<;
Re: Input handling? (newbie alert!)
I've not time for a more full answer now (I'll try later), but please,
for the love of God, don't use scanf! As a general hint, use
std.stdio.readln to get input as a string, then use the `to` function
found in std.conv to convert it into what you want:
auto input = readln();
auto asInteger = to!int(input);
To handle errors, you'll probably want to catch whatever it is that to
throws on failure:
int i;
auto input = readln();
try {
i = to!int(input);
} catch (TheThingThatToThrows) {
i = 0;
}
I don't know how to!int handles entry of floating point numbers, if it
doesn't, what you may want to do:
int i;
auto input = readln();
try {
i = cast(int) to!double(input);
} catch (TheThingThatToThrows) {
i = 0;
}
---
Sorry I couldn't be more thorough. I hope that helps!
Re: Cannot initialize associative array.
On Wed, 23 Jun 2010 00:41:45 -0700, Ali Çehreli wrote:
> Ali Çehreli wrote:
>> dcoder wrote:
>>
>> > So, I moved the initialization to inside the main function, and now
>> it works.
>> > Great. I think we need to put this question in the FAQ.
>>
>> For future reference, if it really needs to be global:
>>
>> uint[string] mywords;
>>
>> static this()
>> {
>> mywords = [ "Hello" : 1, "World" : 1, "Cat" : 1, "Dog" : 1 ];
>> }
>
> Could someone please verify whether the above is really necessary? Is it
> actually a dmd bug that we need to use 'static this()' to initialize an
> associative array?
>
> Ali
I can't remember where exactly I read it, but there's a line in the docs
specifically forbidding the use of AAs in constant expressions, so it's
by design AFAIK.
Re: Cannot initialize associative array.
On Tue, 22 Jun 2010 21:32:48 +, dcoder wrote: > Sorry, I forgot to put some compiler output: > > For the declaration: uint[string] mywords = [ "Hello" : 1, "World" : 1, > "Cat" : 1, "Dog" : 1 ]; > > > I get: > > $ dmd test_01.d > test_01.d(3): Error: non-constant expression > ["Hello":1u,"World":1u,"Cat":1u,"Dog":1u] AAs can't be assigned to at compile time (:[). You'll have to use a static constructor or an initiliasation function to assign to one at global scope.
Re: segfaults
On 04/05/10 09:49, Steven Schveighoffer wrote: On Mon, 03 May 2010 17:25:30 -0400, Bernard Helyer wrote: I believe his problem is that the return code of the caller indicates success. Could it be perhaps that it can't possibly get at that status? Remember, system runs /bin/sh -c, so all you can get as status is the return code of /bin/sh (which didn't segfault). -Steve sh -c returns failure if the specified executable segfaults.
Re: segfaults
On 04/05/10 08:57, Lars T. Kyllingstad wrote:
On Mon, 03 May 2010 15:54:28 -0500, Ellery Newcomer wrote:
Hello.
I'm trying to invoke a command inside d, and it returns a success code
when the command in question segfaults.
any ideas?
// the caller
import std.process;
int main(){
auto r = system("./test");
return(r);
}
//test.d
import std.stdio;
void main()
{
Object o;
writeln(o.toString());
}
It's a null dereference. What you're doing is essentially
Object o = null;
writeln(o.toString());
-Lars
I believe his problem is that the return code of the caller indicates
success.
Re: Passing dynamic arrays into C.
Guilty on all charges. Confused the behaviour of static and dynamic arrays with sizeof. On 25/04/10 21:54, bearophile wrote: Bernard Helyer: glBufferData(GL_ARRAY_BUFFER, vertices.sizeof, vertices.ptr, GL_STATIC_DRAW); glVertexPointer(2, GL_FLOAT, GLfloat.sizeof * 2, cast(void*)0); Are you sure that vertices.sizeof is right? It can be wrong. Maybe you want something like: (vertices[0]).sizeof * vertices.length That: cast(void*)0 is better written: null The sizeof of a dynamic array is 2 CPU words. Bye, bearophile
Re: Passing dynamic arrays into C.
Ah, thank you!
The problem was I read the way T[].sizeof behaves on static arrays,
thinking I was reading the section on dynamic array properties.
On 25/04/10 21:52, Daniel Murphy wrote:
It should work if you treat the dynamic array like a pointer and a length.
eg:
glBufferData(GL_ARRAY_BUFFER, (vertices[0]).sizeof * vertices.length,
vertices.ptr, GL_STATIC_DRAW);
It's probably because (type).sizeof gives the number of bytes to hold the
type.
For dynamic arrays, this is the size of the (length, pointer) pair and not
the array itself.
float.sizeof // gives 4
int.sizeof // gives 4
int[].sizeof // gives 8
int[3].sizeof // gives 12
class C { int[100] d; };
C.sizeof // gives the size of the reference, not the instance.
I haven't checked the sizes, but it generally follows something like that.
"Bernard Helyer" wrote in message
news:hr0veq$226...@digitalmars.com...
I was having a problem interfacing with OpenGL from D, as demonstrated by
this program, written once in D, and again in C:
http://gist.github.com/378273
Now the 'gist' of it is, doing things like this (D):
glBufferData(GL_ARRAY_BUFFER, vertices.sizeof,
vertices.ptr, GL_STATIC_DRAW);
glVertexPointer(2, GL_FLOAT, GLfloat.sizeof * 2, cast(void*)0);
With this data (D):
const GLfloat[] vertices = [-1.0f, -1.0f, 1.0f, -
1.0f, -1.0f, 1.0f, 1.0f, 1.0f];
and the same data in C:
const GLfloat vertices[] = {-1.0f, -1.0f, 1.0f,
-1.0f, -1.0f, 1.0f, 1.0f, 1.0f};
I was getting nothing but a blank screen. I'm sure you smart folks know
what comes next.
GLfloat[] vertices = {1.0f, 1.0f}; // vertices is a dynamic array.
GLfloat[2] vertices = {1.0f, 1.0f}; // vertices is a static array.
The second version enables the program to work as the C one does.
My question is, why doesn't passing the `GLfloat[] vertex ...` declaration
work? I've looked through the docs, and can't see anything too obvious.
Thanks.
Passing dynamic arrays into C.
I was having a problem interfacing with OpenGL from D, as demonstrated
by this program, written once in D, and again in C:
http://gist.github.com/378273
Now the 'gist' of it is, doing things like this (D):
glBufferData(GL_ARRAY_BUFFER, vertices.sizeof,
vertices.ptr, GL_STATIC_DRAW);
glVertexPointer(2, GL_FLOAT, GLfloat.sizeof * 2, cast(void*)0);
With this data (D):
const GLfloat[] vertices = [-1.0f, -1.0f, 1.0f, -
1.0f, -1.0f, 1.0f, 1.0f, 1.0f];
and the same data in C:
const GLfloat vertices[] = {-1.0f, -1.0f, 1.0f,
-1.0f, -1.0f, 1.0f, 1.0f, 1.0f};
I was getting nothing but a blank screen. I'm sure you smart folks know
what comes next.
GLfloat[] vertices = {1.0f, 1.0f}; // vertices is a dynamic array.
GLfloat[2] vertices = {1.0f, 1.0f}; // vertices is a static array.
The second version enables the program to work as the C one does.
My question is, why doesn't passing the `GLfloat[] vertex ...`
declaration work? I've looked through the docs, and can't see anything
too obvious.
Thanks.
Re: segfaults
On 24/02/10 12:53, Ellery Newcomer wrote:
Hey! You're right!
import tango.io.Stdout;
void main(){
Object obj = null;
int[] a;
a ~= 1;
Stdout(obj.toString()).newline;
}
gives me
Die: DW_TAG_type_unit (abbrev 7, offset 0x6f)
parent at offset: 0xb
has children: FALSE
attributes:
DW_AT_byte_size (DW_FORM_data1) constant: 8
DW_AT_type (DW_FORM_ref4) constant ref: 0x68 (adjusted)
Dwarf Error: Missing children for type unit [in module
/home/ellery/test/test]
Do you think this should be a separate issue from 1079?
Well, I've noted it down on 1079. I think it's related. Seeing as *that*
bug doesn't seem to be getting much attention, I don't know how much
good it'd to. You are, of course, welcome to open a new issue.
Re: segfaults
On 24/02/10 03:45, Ellery Newcomer wrote: I'm thinking it's an issue with DMD. I can get backtraces with simple programs. If you use a dynamic array in there somewhere, the chances of it not working go up, I'm afraid. This doesn't leave many programs that *work*.
Re: segfaults
On 23/02/10 15:14, Ellery Newcomer wrote: Is there any decent way to figure out where segfaults are coming from? e.g. 200k lines of bad code converted from java I tried gdb, and it didn't seem to work too well. Die: DW_TAG_type_unit (abbrev 3, offset 0x6d) parent at offset: 0xb has children: FALSE attributes: DW_AT_byte_size (DW_FORM_data1) constant: 8 Dwarf Error: Missing children for type unit [in module /home/ellery/dxl.exe] Missing separate debuginfos, use: debuginfo-install glibc-2.11.1-1.i686 And I'm not proficient with gdb. dmd 1.056 / tango .9 or whatever fedora linux It's a bit hit and miss with DMD, GDB, and debugging I'm afraid (I have no real experience with D1.X and Tango, but I assume it is the same deal). The debugging information put out by DMD seems to be in error, coupled with a possible bug in GDB). Sometimes a different debug switch (-g vs -gc) can help, as can (as in my current project) omitting it altogether. So once you compile your file into an executable run gdb exename then run then, once you hit a SIGSEGV, bt And see what luck you have with the switches and their combinations. Good luck! -Bernard.
Re: TLS definition in curses.o section .tbss mismatches non-TLS reference in /usr/lib/libncurses.a(lib_initscr.o)
On 11/12/09 10:48, Gareth Charnock wrote: Is there any way to tell dmd to just share them between threads? __gshared type whatever;
