Re: Implicit conversion from class in parent class fails?
On Sat, Jun 16, 2012 at 11:52 AM, Namespace rswhi...@googlemail.com wrote:
Why work this:
[code]
class Foo { }
class Bar : Foo { }
class Quatz : Bar { }
void foo(Foo f) {
}
void main() {
Foo f = new Foo();
Foo f2;
foo(f);
foo(f2);
Bar b = new Bar();
Bar b2;
foo(b);
foo(b2);
Quatz q = new Quatz();
Quatz q2;
foo(q);
foo(q2);
}
[/code]
but not:
[code]
import std.stdio;
class Foo { }
class Bar : Foo { }
class Quatz : Bar { }
void bar(Foo[] fs) {
}
void main() {
Foo[] fs = [new Foo()];
Foo[] fs2;
bar(fs);
bar(fs2);
Bar[] bs = [new Bar()];
Bar[] bs2;
bar(bs);
bar(bs2);
Quatz[] qs = [new Quatz()];
Quatz[] qs2;
bar(qs);
bar(qs2);
}
[/code]
I think that should work also.
The problem is that this would also work:
[code]
import std.stdio;
class Foo { }
class Bar : Foo { }
class Quatz : Bar { }
void bar(Foo[] fs) {
fs[0] = new Foo(); // -- OH NOES
}
void main() {
Foo[] fs = [new Foo()];
Foo[] fs2;
bar(fs);
bar(fs2);
Bar[] bs = [new Bar()];
Bar[] bs2;
bar(bs);
bar(bs2);
Quatz[] qs = [new Quatz()];
Quatz[] qs2;
bar(qs);
bar(qs2);
}
[/code]
Re: Windows program instant crash: no messages.
On Tue, Jun 12, 2012 at 1:32 AM, Dmitry Olshansky dmitry.o...@gmail.com wrote: On 12.06.2012 11:17, Nekroze wrote: Hello. I am trying to make a wrapper to use the DarkGDK 3d game engine for windows with D and i am doing rather well so far. I have just gotten it to successfully compile however the resulting exe instantly crashes and outputs nothing at all even though the very first command in WinMain is writeln which doesnt show up. It may be the case that you need to call rt_init(); at first line of WinMain. Every time I see WinMain problems it boils down to D runtime not setup properly. I agree. Take a look at http://dlang.org/windows.html Working from that, I was able to get your app to begin to start up. The other trick is that when you structure your main this way, stdout/stderr/stdin don't seem to be set up for you (at least, not with MinGW GDC). I added this: stdout = File(test.txt, w); and now test.txt contains this: %sCreating Swindow %sInitializing DarkGDK It's still crashing, but it's getting significantly farther. I haven't dug enough to figure out what's going on now.
Re: Windows program instant crash: no messages.
On Tue, Jun 12, 2012 at 1:50 AM, Andrew Wiley wiley.andre...@gmail.com wrote: On Tue, Jun 12, 2012 at 1:32 AM, Dmitry Olshansky dmitry.o...@gmail.com wrote: On 12.06.2012 11:17, Nekroze wrote: Hello. I am trying to make a wrapper to use the DarkGDK 3d game engine for windows with D and i am doing rather well so far. I have just gotten it to successfully compile however the resulting exe instantly crashes and outputs nothing at all even though the very first command in WinMain is writeln which doesnt show up. It may be the case that you need to call rt_init(); at first line of WinMain. Every time I see WinMain problems it boils down to D runtime not setup properly. I agree. Take a look at http://dlang.org/windows.html Working from that, I was able to get your app to begin to start up. The other trick is that when you structure your main this way, stdout/stderr/stdin don't seem to be set up for you (at least, not with MinGW GDC). I added this: stdout = File(test.txt, w); and now test.txt contains this: %sCreating Swindow %sInitializing DarkGDK It's still crashing, but it's getting significantly farther. I haven't dug enough to figure out what's going on now. Actually, it's not crashing, it's failing to initialize DarkGDK and bailing nicely. Looks like it's probably because the DarkGDK DLL is 32 bit and I'm building a 64 bit executable. If I switch to a 32 bit executable and add a stdout.flush() after every writeln, I get this: %sCreating Swindow %sInitializing DarkGDK %sStarting the window %sHanind the window to DarkGDK Unfortunately, I can't debug the crash for some reason. I'll have to ping the MinGW GDC folks about it. The code looks like this: http://pastebin.com/i5A3PFTt My GDC build.bat looks like this: http://pastebin.com/PW30V3q4
Re: Segmentation fault hell in D
On Sat, Jun 9, 2012 at 6:09 AM, Dejan Lekic dejan.le...@gmail.com wrote: On Fri, 08 Jun 2012 19:57:47 -0700, Andrew Wiley wrote: On Fri, Jun 8, 2012 at 11:29 AM, Jonathan M Davis jmdavisp...@gmx.comwrote: On Friday, June 08, 2012 19:30:57 Jarl André jarl.an...@gmail.com@puremagic.com wrote: Evry single time I encounter them I yawn. It means using the next frickin hour to comment away code, add more log statements and try to eleminate whats creating the hell of bugz, segmantation fault. Why can't the compiler tell me anything else than the fact that i have referenced data that does not exist? Thanks I knew that. Now, please tell me where the error occured Jeezes. Turn on core dumps and use gdb. It'll give a backtrace and allow you to look at the state of the program when the segfault occured. That's pretty much the standard way to figure out what happened when a segfault occurs. And use GDC because DMD's debug symbols on Linux are broken enough to crash GDB at times. GDC is generally flawless. Ah noes, HTML code again... Sorry, my bad. Better?
Re: floats default to NaN... why?
On Sat, Jun 9, 2012 at 4:53 PM, Andrew Wiley wiley.andre...@gmail.com wrote: On Sat, Jun 9, 2012 at 11:57 AM, Kevin kevincox...@gmail.com wrote: On Sat 09 Jun 2012 14:59:21 EDT, Jerome BENOIT wrote: On 09/06/12 20:48, Kevin wrote: On 09/06/12 14:42, Minas wrote: With ints, the best we can do is 0. With floats, NaN makes it better. With the logic that NaN is the default for floats, 0 is a very bad choice for ints. It the worst we could do. Altough I understand that setting it to something else like -infinity is still not a good choice. Is it just me but do ints not have infinity values? in Mathematics yes, but not in D. I think ints should default to about half of their capacity (probably negative for signed). This would be machine depends, as such it should be avoided. This way you are unlikely to get an off-by-one for an uninitialized values. something as a Not an Integer NaI should be better. I just don't think it is a good idea to add more metadata to ints. I agree. With floats, NaN is implemented in hardware. The compiler doesn't have to check for NaN when emitting assembly, it just emits operations normally and the hardware handles NaN like you'd expect. If we tried to add a NaN-like value for integers, we would have to check for it before performing integer math. Even with value range propagation, I think that would injure integer math performance significantly. Crap, my apologies for responding with HTML.
Re: floats default to NaN... why?
On Thu, Jun 7, 2012 at 6:50 PM, Minas minas_mina1...@hotmail.co.uk wrote: I agree that the default value for floats/doubles should be zero. It feels much more natural. The point is to make sure code is correct. Initializing your variables should be what feels natural. Leaving then uninitialized is bad style, bad practice, and generally a bad idea. If getting stung by a float initializing to NaN is what it takes to make that happen, so be it. I think the problem here is that people are thinking about some stuff too much. D is a rather new language that wants to be practical. Floats defaulting to NaN is NOT practical FOR MOST PEOPLE when at the same time I write: Actually, as far as I know, floats have been initialized to NaN since D first appeared in 2001. This isn't news. int sum; for(...) sum += blah blah blah And it works. In any other systems language, this would be undefined behavior. D is simply trying to make initialization bugs as obvious as possible. With ints, the best we can do is 0. With floats, NaN makes it better.
Re: Segmentation fault hell in D
On Fri, Jun 8, 2012 at 11:29 AM, Jonathan M Davis jmdavisp...@gmx.comwrote: On Friday, June 08, 2012 19:30:57 Jarl André jarl.an...@gmail.com@puremagic.com wrote: Evry single time I encounter them I yawn. It means using the next frickin hour to comment away code, add more log statements and try to eleminate whats creating the hell of bugz, segmantation fault. Why can't the compiler tell me anything else than the fact that i have referenced data that does not exist? Thanks I knew that. Now, please tell me where the error occured Jeezes. Turn on core dumps and use gdb. It'll give a backtrace and allow you to look at the state of the program when the segfault occured. That's pretty much the standard way to figure out what happened when a segfault occurs. And use GDC because DMD's debug symbols on Linux are broken enough to crash GDB at times. GDC is generally flawless.
Re: convert ubyte[k..k + 1] to int
On Wed, May 16, 2012 at 11:03 AM, Regan Heath re...@netmail.co.nz wrote:
On Wed, 16 May 2012 15:24:33 +0100, ref2401 refacto...@gmail.com wrote:
i have an array of ubytes. how can i convert two adjacent ubytes from the
array to an integer?
pseudocode example:
ubyte[5] array = createArray();
int value = array[2..3];
is there any 'memcpy' method or something else to do this?
You don't need to copy the data, just tell the compiler to pretend
it's a short (in this case, for 2 bytes) then copy the value/assign to an
int. e.g.
import std.stdio;
void main()
{
ubyte[5] array = [ 0xFF, 0xFF, 0x01, 0x00, 0xFF ];
int value = *cast(short*)array[2..3].ptr;
writefln(Result = %s, value);
}
The line:
int value = *cast(short*)array[2..3].ptr;
1. slices 2 bytes from the array.
2. obtains the ptr to them
3. casts the ptr to short*
4. copies the value pointed at by the short* ptr to an int
You may need to worry about little/big endian issues, see:
http://en.wikipedia.org/wiki/**Endiannesshttp://en.wikipedia.org/wiki/Endianness
The above code outputs Result = 1 on my little-endian x86 desktop
machine but would output Result = 256 on a big-endian machine.
R
Unfortunately, this is undefined behavior because you're breaking alignment
rules. On x86, this will just cause a slow load from memory. On ARM, this
will either crash your program with a bus error on newer hardware or give
you a gibberish value on ARMv6 and older.
Declaring a short, getting a pointer to it, and casting that pointer to a
ubyte* to copy into it is fine, but casting a ubyte* to a short* will cause
a 2-byte load from a 1-byte aligned address, which leads down the yellow
brick road to pain.
Re: convert ubyte[k..k + 1] to int
On Wed, May 16, 2012 at 11:07 PM, H. S. Teoh hst...@quickfur.ath.cx wrote:
On Wed, May 16, 2012 at 10:25:51PM -0500, Andrew Wiley wrote:
On Wed, May 16, 2012 at 11:03 AM, Regan Heath re...@netmail.co.nz
wrote:
On Wed, 16 May 2012 15:24:33 +0100, ref2401 refacto...@gmail.com
wrote:
i have an array of ubytes. how can i convert two adjacent ubytes from
the
array to an integer?
pseudocode example:
ubyte[5] array = createArray();
int value = array[2..3];
is there any 'memcpy' method or something else to do this?
You don't need to copy the data, just tell the compiler to pretend
it's a short (in this case, for 2 bytes) then copy the value/assign to
an
int. e.g.
import std.stdio;
void main()
{
ubyte[5] array = [ 0xFF, 0xFF, 0x01, 0x00, 0xFF ];
int value = *cast(short*)array[2..3].ptr;
writefln(Result = %s, value);
}
The line:
int value = *cast(short*)array[2..3].ptr;
1. slices 2 bytes from the array.
2. obtains the ptr to them
3. casts the ptr to short*
4. copies the value pointed at by the short* ptr to an int
You may need to worry about little/big endian issues, see:
http://en.wikipedia.org/wiki/**Endianness
http://en.wikipedia.org/wiki/Endianness
The above code outputs Result = 1 on my little-endian x86 desktop
machine but would output Result = 256 on a big-endian machine.
R
Unfortunately, this is undefined behavior because you're breaking
alignment rules. On x86, this will just cause a slow load from memory.
On ARM, this will either crash your program with a bus error on newer
hardware or give you a gibberish value on ARMv6 and older.
Declaring a short, getting a pointer to it, and casting that pointer
to a ubyte* to copy into it is fine, but casting a ubyte* to a short*
will cause a 2-byte load from a 1-byte aligned address, which leads
down the yellow brick road to pain.
Do unions suffer from this problem? Could this prevent alignment
problems:
short bytesToShort(ubyte[] b)
in { assert(b.length==2); }
body {
union U {
short val;
ubyte[2] b;
}
U u;
u.b[] = b[];
return u.val;
}
?
As I understand it, this should be fine because the compiler will guarantee
that the union is aligned to the maximum alignment required by one of its
members, which is the short. This is probably the safest solution.
Re: What is a good strategy for finding undefined symbols...
On Sat, May 12, 2012 at 12:22 PM, WhatMeWorry kc_hea...@yahoo.com wrote: Looks like you are trying to link. Libraries are not linked they are just compiled. Then object files are put together into library file. Link produces *executable* (yeah I recall that was hard to get at first). Wait, isn't that the whole point of libraries, that they are pre-compiled? Linking just resolves their addresses? Yes and no. You have to link *dynamic* libraries to resolve addresses, but you're dealing with a static library. Static library is to some extent a misnomer because you don't link them at all; they're basically a bunch of object files thrown into an archive file. Addresses get resolved when you link an executable and all those object files get included from inside the archive. Anyway, I set the LIB environment variable to point to where my druntime and phobos libraries (with absolute paths even) like so: set LIB=C:\D\dmd2\src\druntime\**lib;C:\D\dmd2\src\phobos but when I redo the link step,I am still seening the undefined symbols like in my original posting. I love programming, but I hate building. Is this what Andrei means by code for being as opposed to code for doing:. One of the downsides of native compilation is that the toolchain is a much more complex system than it is with VM languages (and interpreted languages don't need a toolchain at all). Unfortunately, I use GDC on Windows and Linux, so I can't tell you exactly the command to create a static library with DMD, but I can tell you that you don't need to invoke optlink.
Re: std.socket with GDC
On Sat, Feb 25, 2012 at 4:45 PM, DNewbie r...@myopera.com wrote: On Sat, Feb 25, 2012, at 10:38 PM, Mars wrote: On Saturday, 25 February 2012 at 18:27:29 UTC, Vladimir Panteleev wrote: On Friday, 24 February 2012 at 19:15:26 UTC, Mars wrote: Hello everybody. When trying to compile a program using GDC (Windows), which includes an import std.socket, I get a lot undefined references, like undefined reference to `WSAGetLastError@0' Try linking with libws2_32.a. Still the same. Does that work for you? std.socket works for me, gdc64 (windows) I recall having some issues because Winsock needs to be on the linker commandline *after* phobos. Try running with `gdc -v` to see what the linker commandline looks like.
Re: Singleton question (shared class)
On Wed, Jan 25, 2012 at 9:35 AM, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Wed, 25 Jan 2012 09:50:57 -0500, Mars -@-.- wrote:
Alternative approach, I just found:
http://pastie.org/private/1jlcvfostnbopfp3quflg
If I get that right, this is basically the classic singleton, like it
would be in other languages, right?
So... what's the best way?
This is an ok approach, but you must handle all threading issues manually.
In fact, you need to even with the shared version. I don't know how
threading support works with MySQL, so it may be ok just to ignore threading
issues. I'm not sure.
Another approach is to use thread local storage to have a singleton per
instance. This avoids the whole problem of sharing the instance.
An issue with your singleton allocation, is that you don't do the check for
the instance being null while synchronized. The singleton pattern looks
like this:
static T instance;
T get()
{
if(instance is null)
{
synchronized if(instance is null)
{
instance = new T;
}
}
return instance;
}
The second check is necessary to avoid allocating multiple instances (they
will get thrown away, but no need to create them).
Normally, you'd mark instance as volatile, but D2 doesn't support volatile
any more. I don't know the correct way to make sure the second check isn't
optimized out.
In the language spec, shared is supposed to guarantee this, but it
currently doesn't. There was a conversation where pretty much every
safe variant of the singleton pattern was discussed recently:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Singleton_Pattern_31406.html
Re: Singleton Pattern
On Thu, Jan 5, 2012 at 4:15 PM, asm a...@hotmail.com wrote: how can i implementing the singleton pattern in D? Multithreaded or not?
Re: AA char[] as key
On Tue, Jan 3, 2012 at 1:25 PM, simendsjo simend...@gmail.com wrote: seems T[char[]] is rewritten as T[const(char)[]], and does not accept char[] as key even if mutable data should automatically convert to const (right..?) Shouldn't T[char[]] be disallowed, and have to be written as T[immutable(char)[]] instead of a silent rewrite? alias long[char[]] AA; // key automatically changed to const(char)[] static assert(is(AA == long[const(char)[]])); AA aa; aa[a] = 10; // error - have to use immutable keys aa[b.dup] = 11; By design, the problem is things like this: char[] key = somekey; long[char[]] aa; aa[key] = 5; key[2] = 'b'; If this were allowed, the associative array would reach an invalid state where the hash it stored for the key is no longer correct. It does seem like T[char[]] should be disallowed and the requirement for immutable keys should be literally enforced, and it's possible that was intended but immutable/const weren't as complete when this problem was last visited. I'll see if I can dig up an old discussion about this.
Re: AA char[] as key
On Tue, Jan 3, 2012 at 1:41 PM, Andrew Wiley wiley.andre...@gmail.com wrote: On Tue, Jan 3, 2012 at 1:25 PM, simendsjo simend...@gmail.com wrote: seems T[char[]] is rewritten as T[const(char)[]], and does not accept char[] as key even if mutable data should automatically convert to const (right..?) Shouldn't T[char[]] be disallowed, and have to be written as T[immutable(char)[]] instead of a silent rewrite? alias long[char[]] AA; // key automatically changed to const(char)[] static assert(is(AA == long[const(char)[]])); AA aa; aa[a] = 10; // error - have to use immutable keys aa[b.dup] = 11; By design, the problem is things like this: char[] key = somekey; Sorry, should be: char[] key = somekey.dup;
Re: AA char[] as key
On Tue, Jan 3, 2012 at 1:50 PM, simendsjo simend...@gmail.com wrote: On 03.01.2012 20:41, Andrew Wiley wrote: On Tue, Jan 3, 2012 at 1:25 PM, simendsjosimend...@gmail.com wrote: seems T[char[]] is rewritten as T[const(char)[]], and does not accept char[] as key even if mutable data should automatically convert to const (right...?) Shouldn't T[char[]] be disallowed, and have to be written as T[immutable(char)[]] instead of a silent rewrite? alias long[char[]] AA; // key automatically changed to const(char)[] static assert(is(AA == long[const(char)[]])); AA aa; aa[a] = 10; // error - have to use immutable keys aa[b.dup] = 11; By design, the problem is things like this: char[] key = somekey; long[char[]] aa; aa[key] = 5; key[2] = 'b'; If this were allowed, the associative array would reach an invalid state where the hash it stored for the key is no longer correct. It does seem like T[char[]] should be disallowed and the requirement for immutable keys should be literally enforced, and it's possible that was intended but immutable/const weren't as complete when this problem was last visited. I'll see if I can dig up an old discussion about this. It is disallowed, but it's enforced when setting a key rather than when constructing the type. So `aa[key] = 5` above fails as key is char[] rather than string. Yes, while that's correct, it doesn't make much sense (as you pointed out). Rewriting long[char[]] to long[const(char)[]] isn't particularly useful when you can't use char[] as a key. If the compiler is basically going to disallow using the AA as anything but a long[string], it should really disallow declaring anything with a mutable key type. Disallowing mutable keys at that assignment site but allowing them in the type is confusing.
Re: AA char[] as key
On Tue, Jan 3, 2012 at 4:20 PM, bearophile bearophileh...@lycos.com wrote: Andrew Wiley: If the compiler is basically going to disallow using the AA as anything but a long[string], it should really disallow declaring anything with a mutable key type. Disallowing mutable keys at that assignment site but allowing them in the type is confusing. Two related bug reports: http://d.puremagic.com/issues/show_bug.cgi?id=4475 Improving the compiler 'in' associative array can return just a bool Whether this is a good idea or not is a moot point. Changing this would break too much code (basically all code that uses AAs significantly). http://d.puremagic.com/issues/show_bug.cgi?id=6253 Refuse definition too of impossible associative arrays This is what we're discussing. Some consequences of actually changing this: - This breaks D1 compatibility of AAs across the board because immutable simply didn't exist then - Significant D2 code breakage as well We might see if Walter is willing to add this as a warning and/or deprecation to see whether it's actually feasible to disallow it completely.
Re: GetAndSet function (corresponding to cas function)
On Mon, Dec 26, 2011 at 2:34 PM, Adrian Mercieca amerci...@gmail.com wrote:
Hi folks,
Would anyone answer me on this please?
To clarify, in Java there is are getAndSet methods on Atomic type objects
(along with compareAndSet).
I know that in D there is the cas function (equivalent to Java's
compareAndSet); is there an equivalent D function for Java's getAndSet
please?
Thanks.
From Java:
---
public final boolean getAndSet(boolean newValue) {
for (;;) {
boolean current = get();
if (compareAndSet(current, newValue))
return current;
}
}
---
getAndSet is just a wrapped version of compareAndSet.
Re: GetAndSet function (corresponding to cas function)
On Mon, Dec 26, 2011 at 4:05 PM, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Monday, December 26, 2011 20:34:39 Adrian Mercieca wrote:
Hi folks,
Would anyone answer me on this please?
To clarify, in Java there is are getAndSet methods on Atomic type objects
(along with compareAndSet).
I know that in D there is the cas function (equivalent to Java's
compareAndSet); is there an equivalent D function for Java's getAndSet
please?
If it's not in core.atomic, then probably not. It has atomicLoad and
atomicStore, but I don't see anything that tries to combine the two, assuming
that that's what you want be getAndSet.
getAndSet can easily be implemented as a utility method using cas and
atomicLoad. It's not a primitive atomic operation, it's just a
convenience function.
T getAndSet(T)(shared(T)* location, T newValue) {
while(1) {
auto current = atomicLoad(*location);
if(cas(location, current, newValue))
return current;
}
}
Someone who knows more about the options to atomicLoad could probably
make this faster, but because we're using cas, it's guaranteed to be
correct.
Re: Catching signals with D
On Sat, Dec 24, 2011 at 7:37 AM, Matej Nanut matejna...@gmail.com wrote: @Heywood Floyd: that works, but what exactly am I permitted to use inside the handler, as I assume it's a C function? This might be a useless question as non-atomic operations touching global data aren't supposed to be in signal handlers, but I'm still interested to know. @Alex Rønne Petersen: what exactly is https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/posix/signal.d? I don't see it mentioned anywhere on dlang.org? :/ I'm still new to all this stuff. When programming in C, everything I ever needed was in the default repositories of my Linux distribution, so I neved needed to worry about anything. :) That module is part of druntime, and you can import it with import core.sys.posix.signal; The documentation isn't on dlang.org, probably because dlang.org doesn't contain the documentation for OS-specific modules (it's hard to generate the documentation for those when you're not on the same OS).
Re: Reading about D: few questions
2011/12/24 Mr. Anonymous mailnew4s...@gmail.com: On 24.12.2011 19:01, Denis Shelomovskij wrote: 23.12.2011 22:51, bearophile пишет: ++a[] works, but a[]++ doesn't. Already known compiler bug. Is it a joke? Array expression in D are for performance reasons to generate x2-x100 faster code without any compiler optimisations. Link to one of these epic comments (even x100 more epic because of '%' use instead of 'x###'): https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d#L1127 But `a[]++` should store a copy of `a`, increment elements and return stored copy. It is hidden GC allocation. We already have a silent allocation in closures, but here a _really large_ peace of data can be allocated. Yes, this allocation sometimes can be optimized out but not always. IMHO, D should not have `a[]++` operator. Why should it store a copy? o_O I also don't see any allocations in the code on the URL above. int a_orig = a++; int[] arr_orig = arr[]++; If ++ is going to be applied to an array, it needs to have the same meaning as it does elsewhere. After this operation, arr_orig and arr must refer to different arrays for that to be true.
Re: Reading about D: few questions
On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehr timon.g...@gmx.ch wrote:
On 12/24/2011 06:18 PM, Andrew Wiley wrote:
2011/12/24 Mr. Anonymousmailnew4s...@gmail.com:
On 24.12.2011 19:01, Denis Shelomovskij wrote:
23.12.2011 22:51, bearophile пишет:
++a[] works, but a[]++ doesn't.
Already known compiler bug.
Is it a joke? Array expression in D are for performance reasons to
generate x2-x100 faster code without any compiler optimisations. Link to
one of these epic comments (even x100 more epic because of '%' use
instead of 'x###'):
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d#L1127
But `a[]++` should store a copy of `a`, increment elements and return
stored copy. It is hidden GC allocation. We already have a silent
allocation in closures, but here a _really large_ peace of data can be
allocated. Yes, this allocation sometimes can be optimized out but not
always.
IMHO, D should not have `a[]++` operator.
Why should it store a copy? o_O
I also don't see any allocations in the code on the URL above.
int a_orig = a++;
int[] arr_orig = arr[]++;
If ++ is going to be applied to an array, it needs to have the same
meaning as it does elsewhere. After this operation, arr_orig and arr
must refer to different arrays for that to be true.
Not necessarily.
class D{
int payload;
D opUnary(string op:++)(){payload++; return this;}
}
void main() {
D d = new D;
assert(d.payload == 0);
assert(d++.payload == 1);
}
That doesn't match integer semantics:
int a = 0;
assert(a++ == 0);
assert(a == 1);
Re: Reading about D: few questions
On Sat, Dec 24, 2011 at 1:08 PM, Timon Gehr timon.g...@gmx.ch wrote:
On 12/24/2011 07:00 PM, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehrtimon.g...@gmx.ch wrote:
On 12/24/2011 06:18 PM, Andrew Wiley wrote:
2011/12/24 Mr. Anonymousmailnew4s...@gmail.com:
On 24.12.2011 19:01, Denis Shelomovskij wrote:
23.12.2011 22:51, bearophile пишет:
++a[] works, but a[]++ doesn't.
Already known compiler bug.
Is it a joke? Array expression in D are for performance reasons to
generate x2-x100 faster code without any compiler optimisations. Link
to
one of these epic comments (even x100 more epic because of '%' use
instead of 'x###'):
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d#L1127
But `a[]++` should store a copy of `a`, increment elements and return
stored copy. It is hidden GC allocation. We already have a silent
allocation in closures, but here a _really large_ peace of data can be
allocated. Yes, this allocation sometimes can be optimized out but not
always.
IMHO, D should not have `a[]++` operator.
Why should it store a copy? o_O
I also don't see any allocations in the code on the URL above.
int a_orig = a++;
int[] arr_orig = arr[]++;
If ++ is going to be applied to an array, it needs to have the same
meaning as it does elsewhere. After this operation, arr_orig and arr
must refer to different arrays for that to be true.
Not necessarily.
class D{
int payload;
D opUnary(string op:++)(){payload++; return this;}
}
void main() {
D d = new D;
assert(d.payload == 0);
assert(d++.payload == 1);
}
That doesn't match integer semantics:
int a = 0;
assert(a++ == 0);
assert(a == 1);
Yes, that was my point.
Then I'm not understanding what you're trying to prove.
I'm saying that if we implement a postfix ++ operator for arrays,
keeping the language consistent would require it to make a copy if the
user stores a copy of the original array. I guess it could be argued
that since arrays have hybrid value/reference semantics, no copy
should be made and the original should change.
Actually, looking at it from that angle, a[]++ is fundamentally
ambiguous because it could have value semantics or reference
semantics, so I would argue that we shouldn't have it for that reason.
'++a' and 'a += 1' do not have such ambiguities.
Re: Reading about D: few questions
On Sat, Dec 24, 2011 at 1:45 PM, Timon Gehr timon.g...@gmx.ch wrote:
On 12/24/2011 08:41 PM, Mr. Anonymous wrote:
On 24.12.2011 21:22, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 1:08 PM, Timon Gehrtimon.g...@gmx.ch wrote:
On 12/24/2011 07:00 PM, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehrtimon.g...@gmx.ch wrote:
On 12/24/2011 06:18 PM, Andrew Wiley wrote:
2011/12/24 Mr. Anonymousmailnew4s...@gmail.com:
On 24.12.2011 19:01, Denis Shelomovskij wrote:
23.12.2011 22:51, bearophile пишет:
++a[] works, but a[]++ doesn't.
Already known compiler bug.
Is it a joke? Array expression in D are for performance reasons to
generate x2-x100 faster code without any compiler optimisations.
Link
to
one of these epic comments (even x100 more epic because of '%' use
instead of 'x###'):
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d#L1127
But `a[]++` should store a copy of `a`, increment elements and
return
stored copy. It is hidden GC allocation. We already have a silent
allocation in closures, but here a _really large_ peace of data
can be
allocated. Yes, this allocation sometimes can be optimized out
but not
always.
IMHO, D should not have `a[]++` operator.
Why should it store a copy? o_O
I also don't see any allocations in the code on the URL above.
int a_orig = a++;
int[] arr_orig = arr[]++;
If ++ is going to be applied to an array, it needs to have the same
meaning as it does elsewhere. After this operation, arr_orig and arr
must refer to different arrays for that to be true.
Not necessarily.
class D{
int payload;
D opUnary(string op:++)(){payload++; return this;}
}
void main() {
D d = new D;
assert(d.payload == 0);
assert(d++.payload == 1);
}
That doesn't match integer semantics:
int a = 0;
assert(a++ == 0);
assert(a == 1);
Yes, that was my point.
Then I'm not understanding what you're trying to prove.
I'm saying that if we implement a postfix ++ operator for arrays,
keeping the language consistent would require it to make a copy if the
user stores a copy of the original array. I guess it could be argued
that since arrays have hybrid value/reference semantics, no copy
should be made and the original should change.
Actually, looking at it from that angle, a[]++ is fundamentally
ambiguous because it could have value semantics or reference
semantics, so I would argue that we shouldn't have it for that reason.
'++a' and 'a += 1' do not have such ambiguities.
Maybe you're right, but a[]++; alone, imo, should compile.
+1.
You could special case this, but I'd be happy with an error that told
you to use one of the working alternatives.
Re: Linking problem on Mac OS X
On Sat, Dec 24, 2011 at 6:29 PM, Robert Rouse robert.e.ro...@gmail.com wrote: Running a simple compile and link dmd test.d produces gcc-4.2: Invalid argument What can I provide to track this down? Run with `dmd -v` to get the linker commandline.
Re: test if object is instance of class at compile time
On Thu, Dec 22, 2011 at 8:35 AM, Trass3r u...@known.com wrote: I'd really like to have 'if (instance is ClassType)' syntax in D. It couldn't use that syntax because 'is' means direct bitwise equality everywhere else. Changing it in this one situation would be awkward.
Re: Are D classes always garbage collected?
On Wed, Dec 21, 2011 at 10:20 PM, Froglegs lug...@gmail.com wrote:
Which returned me a nice fat null pointer.. wth? Perhaps that should be a
compile time error if you aren't supposed to use classes..
Strange... I'm not sure what the deal is with that overload. I meant the
last one on the page (that takes a void[]).
Hum I've tried the array version but I believe it contains a rather serious
bug...
T emplace(T, Args...)(void[] chunk, Args args) if (is(T == class))
{
enforce(chunk.length = __traits(classInstanceSize, T),
new ConvException(emplace: chunk size too small));
...
This fails whenever the size is greater or equal to the amount of memory
required :(
Anyway I need the pointer version for what I was hoping to do, unless there
is some way to convert a pointer into an array?
Is there any way to do something like this..
void* pData = some_c_function();
void [] fakeArray = pData, size;
Yes:
void* pData = some_c_function();
void[] fakeArray = pData[0..size];
Although Vladimir's solution is safer.
Re: Restrict access to critical functions
2011/12/12 Christian Köstlin christian.koest...@gmail.com: Hi, I want to restrict the access of a piece of d2-code to just some functions I declare allowed. E.g. I would like to forbid all access to io and prevent the program to format my hd. Or even better I would like to tell D2 which functions of the std-libraries are allowed, all other functions should not be callable. Goal would be to have a possibility to compile and let run code from random people (some of them perhaps evil minded), watch over the processes and kill them, if they take too long or use up too much memory. Thanks in advance Christian Köstlin Honestly, I don't think what you're looking for is possible in *any* statically compiled systems language. The kind of thing you're looking for is pretty much limited to VM languages that can enforce security restrictions at runtime. In particular, having direct access to assembly code and the stub C libraries for syscalls means that even if the compiler denied the user access to a certain library, the user could write the code needed to invoke a syscall to load that library into memory and make calls into it, and they could bypass all safety checks if they were determined enough.
Re: Matching with std.concurrency receive
On Sat, Dec 10, 2011 at 1:38 PM, Jonathan M Davis jmdavisp...@gmx.com wrote: On Saturday, December 10, 2011 17:30:50 Adam wrote: Hrm... that's a bit problematic. If I do use the exact match, it seems to hang / lock up (probably the lack of support for classes?). However, that's pretty much never the case of what I want to do, since what I'm trying to do involves passing / accepting an interface and its implementations. I guess I can manage this with a static table of operation IDs pointing to function delegates. Sadness. Haha It probably _should_ accept interfaces for classes and the like, but I don't think that it works properly for classes at the moment (due to issues with Variant), and in my experience, I've had use the _exact_ type, as annoying as that may be. For instance, if IIRC, I tried to pass a string which happened to be immutable, and when I tried to receive string on the other end, it wouldn't work until I changed it to receive an immutable string. If you have a type A which you think definitely should be receivable as type B on the other side, and it doesn't work, please submit a bug report: d.puremagic.com/issues . It's possible that you're misunderstanding something, but it's also definitely a possibility that receive just doesn't work right in some cases (e.g. far too strict). A bug report increases the chances of it getting fixed. - Jonathan M Davis With classes, Variant currently can't handle immutability. Passing shared objects is fine, and casting works as a workaround. The bug report also has a workaround that's fairly easy to add to std.variant, but it sounds like the current std.variant isn't going to get fixed (just the replacement that's in development). The thing that seems to be confusing about message passing is that we have no dynamic pattern matching (and that's not because of receive, it's because of Variant), so all type matching comes from templates and checking types for equality. If you pass in a reference of type Object, it doesn't matter what type the actual object is, you can only match it as Object when receiving it. This may or may not be unavoidable - if we can implement dynamic type matching, classes will need to special cased in the Variant code (because you can't dynamically typecheck a struct or primitive). This is probably worth asking Rob Jacques about, since he's developing the std.variant replacement.
Re: Is __VERSION__ cross-compiler compatible?
On Mon, Nov 21, 2011 at 8:16 PM, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: GDC does seem to use this, now that I've tested it: D:\dev\code\d_codegdc test.d 1067L D:\dev\code\d_codegdc -v2 test.d 2052L I've found the docs, it states this is a compiler token: http://d-programming-language.org/lex.html (section Special Tokens) But being able to target a *language version* in a compiler-neutral way would be great. I don't know if LDC does the same thing as GDC though. Odds are good that this value is part of the frontend, in which case it would be identically in LDC and GDC.
Re: .di files have implementation??
On Sat, Oct 22, 2011 at 9:49 PM, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: It's because the function is small enough to be inlineable, you can't inline it if you've only got the prototype in the header file. So it's optimizations at play. Interestingly, it looks like GNU ld should be able to inline functions as part of link time optimizations, which would make this unnecessary on platforms where DMD uses ld. Probably not worth looking into right now, but if di files become more used in the future, this sort of thing could probably go away (except on Windows, but the linker situation there is probably one of the most problematic parts of the D toolchain).
Re: D on other platforms than Win,Lin,Mac?
On Wed, Sep 7, 2011 at 2:46 AM, Johannes Pfau s...@example.com wrote: Andrew Wiley wrote: On Tue, Sep 6, 2011 at 2:25 PM, Johannes Pfau s...@example.com wrote: Trass3r wrote: I've heard that our company is considering the T20 from Toradex.com for a new project with remote hardware. The platform runs on Nvidia Tegra and Linux. Since I have been very impressed by the D programming language, for some years now, could it be possible to use D in such projects? You'd have to use gdc or ldc and patch at least druntime. Some people already managed to get stuff running on ARM but it's tricky. At least for gdc only hello-world like code works. Real code hits this issue: https://bitbucket.org/goshawk/gdc/issue/215/alignment-of-struct-members-wrong-on-arm This also applies to all platforms which aren't supported by dmd. I think the GC is problematic, thus you also have to avoid most of phobos. The GC seems to work if druntime is compiled with -fno-section-anchors , but no real testing was done. https://bitbucket.org/goshawk/gdc/issue/120/fsection-anchors-broken-on-arm might also be caused by bug 215. +1 If you're looking at an ARMv7 platform (my Tegra is ARMv7, dunno if they all are), I believe you can set the Linux kernel to handle faults caused by unaligned memory accesses, which *should* make D run with a performance hit until this bug gets fixed. Keep in mind that the library situation is largely untested, although Iain seems to have quietly done a lot of work in Druntime at some point to make it all build. Once I've got my Tegra up and running (need a serial cable - it's in the mail), I'll be able to say more. I only had a cheap ARM5TE till now, but yesterday my PandaBoard arrived (OMAP4 / Dual Core Cortex A9 / ARM7). But the SD Card I ordered is broken, I'm waiting for a replacement now. Anyway: Are you referring to this? http://www.mjmwired.net/kernel/Documentation/arm/mem_alignment Yes. That won't make our OS structs match up, but it should keep alignment problems from crashing the program otherwise. Also, my experience with LDC was that it doesn't have the Druntime patches it needs, but I seem to recall adding enough to get it building, then watching LDC segfault. I think they're already fixing the alignments (though I'm not familiar enough with their source to be certain that's what I was seeing), but there seems to be some other issue.
Re: D on other platforms than Win,Lin,Mac?
On Tue, Sep 6, 2011 at 2:25 PM, Johannes Pfau s...@example.com wrote: Trass3r wrote: I've heard that our company is considering the T20 from Toradex.com for a new project with remote hardware. The platform runs on Nvidia Tegra and Linux. Since I have been very impressed by the D programming language, for some years now, could it be possible to use D in such projects? You'd have to use gdc or ldc and patch at least druntime. Some people already managed to get stuff running on ARM but it's tricky. At least for gdc only hello-world like code works. Real code hits this issue: https://bitbucket.org/goshawk/gdc/issue/215/alignment-of-struct-members-wrong-on-arm This also applies to all platforms which aren't supported by dmd. I think the GC is problematic, thus you also have to avoid most of phobos. The GC seems to work if druntime is compiled with -fno-section-anchors , but no real testing was done. https://bitbucket.org/goshawk/gdc/issue/120/fsection-anchors-broken-on-arm might also be caused by bug 215. +1 If you're looking at an ARMv7 platform (my Tegra is ARMv7, dunno if they all are), I believe you can set the Linux kernel to handle faults caused by unaligned memory accesses, which *should* make D run with a performance hit until this bug gets fixed. Keep in mind that the library situation is largely untested, although Iain seems to have quietly done a lot of work in Druntime at some point to make it all build. Once I've got my Tegra up and running (need a serial cable - it's in the mail), I'll be able to say more.
Re: D on other platforms than Win,Lin,Mac?
On Tue, Sep 6, 2011 at 1:51 PM, Nick Sabalausky a@a.a wrote: Trass3r u...@known.com wrote in message news:op.v1edf3bj3ncmek@enigma... I've heard that our company is considering the T20 from Toradex.com for a new project with remote hardware. The platform runs on Nvidia Tegra and Linux. Since I have been very impressed by the D programming language, for some years now, could it be possible to use D in such projects? You'd have to use gdc or ldc and patch at least druntime. Some people already managed to get stuff running on ARM but it's tricky. I think the GC is problematic, thus you also have to avoid most of phobos. For a language that aims at C/C++'s domain, it's extremely depressing that this is still the case. I *really* think this needs to be one of D's top priorities at this point. I honestly see it as D's #1 biggest glaring hole ATM (Honestly, I've always cared about embedded/non-x86 processors *far* more than the native 64-bit support that got enormous attention awhile back). 'Course I'm kinda just blowing smoke out my ass since I unfortunately have neither the time nor ability to help tackle this goal :( The problem is that the most direct way to do this is to use a compiler backend that isn't Digital Mars, and there's far fewer people working on other backends. This is why I asked whether anything had happened with GCC inclusion a while back. If that could happen, D would get a large leap forward in this area. I agree that a systems language that only works on x86/x86_64 is a depressing concept, and I think it's about to become unacceptable in the next few years.
Re: gdc setup without gcc
On Thu, Sep 1, 2011 at 12:31 AM, %u asm...@hotmail.com wrote: is there a way to install gdc without gcc because I already have gcc install in archlunix? Use the gdc2-hg PKGBUILD in the AUR.
Re: help understanding import libraries
On Fri, Aug 19, 2011 at 9:38 AM, Jesse Phillips jessekphillip...@gmail.comwrote: maarten van damme Wrote: the compiler flags I needed to add was -I for every src directory and -L for the lib file. The problem with that was that those files in the src dir don't declare the functions but also define them. They are the real source code files so I didn't understand why the -L flag was necessary. I never experimented further though :) The process of creating an executable goes from generating machine code from source to linking the machine code for execution, as you know. The -I flag is the compiler import/include directory while -L is flags passed to the linker. That so while you may have complete source code in the import directory the compiler is only looking at the declaration and does not compile the files, it then informs the linker where the symbols can be found from the information you provide after the -L flag. Technically it's not saying anything about where the symbols can be found, it's just putting them into the object file as external symbols that the linker needs to resolve, but yes. The compiler basically ignores lib files and passes them to the linker.
Re: Permission denied under Ubuntu.
On Tue, Aug 9, 2011 at 1:40 AM, Johannes Pfau s...@example.com wrote: Andrew Wiley wrote: Try `chmod +x dmd` (when in the same directory as the dmd executable). That should get fixed in the package though. Shouldn't it be `chmod +x testFile`? If I read his question correctly, compiling with dmd worked, only running the compiled program failed. Yes, it should be. /me needs to learn him an English for great good. However, dmd always correctly flagged files as executable for me. @Charles could you try `chmod +x testFile` and see if it fails? The filesystem testFile is on could be configured to disallow executing programs. If that's the case, we may have found a reason for DMD to emit a warning that Walter will approve!
Re: Permission denied under Ubuntu.
On Mon, Aug 8, 2011 at 4:30 PM, Charles McAnany mcana...@rose-hulman.eduwrote: Hi, all. I installed dmd_2.054-0_amd64.deb on Ubuntu 11.04, and the compiler seems to work fine, but I can't execute its output. Here's what I'm doing: (ls to show directory contents) $ dmd testFile.d $ ./testFile bash: ./testFile: Permission denied testFile.d is the Hello world program exactly as it appears on page 1 of TDPL. Has anyone else had this issue? If it helps, I let the software center thing do the installing, so if I need to manually change the permission of something, I probably haven't done that. Try `chmod +x dmd` (when in the same directory as the dmd executable). That should get fixed in the package though.
Re: Importing D libraries
On Wed, Jul 27, 2011 at 11:46 PM, Jacob Carlborg d...@me.com wrote: On 2011-07-28 03:23, Andrew Wiley wrote: On Wed, Jul 27, 2011 at 2:10 AM, Jacob Carlborg d...@me.com mailto:d...@me.com wrote: Cannot be implemented in GDC. The driver/compiler/assembler/__** linker structure doesn't allow it. Why is that? Well, the short version is that GDC (the executable) is not a compiler. GDC is a driver that runs cc1d to compile your code, runs as (at least I think that's the name offhand) to assemble it, then runs ld to link it. As far as I know, there's no way for cc1d to communicate the contents of pragmas like this back to the driver, which it would have to do if you wanted the driver to include the library in the arguments to the linker. It's possible that I just don't know the infrastructure well enough, but I think this is one of the reasons the GCC guys refused to implement #pragma in C/C++ as well. I don't really get this. GDC is a D front end for the GCC back end. So the the front end should handle all language specific things, like the pragma. Then I assume the front end can pass options to the linker. Is this not the case? In traditional terms, cc1d is a compiler, including both the frontend and the backend. It takes parameters and spits out assembly. That's it. The GDC executable is the driver responsible for running cc1d to compile the source to assembly, as to assemble the object files, and ld to link it all into a binary. cc1d cannot pass options to the linker because it does not invoke the linker.
Re: Importing D libraries
On Tue, Jul 26, 2011 at 11:38 PM, Jacob Carlborg d...@me.com wrote: On 2011-07-26 21:34, Andrej Mitrovic wrote: On 7/26/11, Nick Sabalauskya@a.a wrote: Pellepelle.mansson@gmail.**com pelle.mans...@gmail.com wrote in message news:op.vy74cwejzu79i9@pelle-**d2608-a1... On Tue, 26 Jul 2011 13:06:56 +0200, Dainius (GreatEmerald) past...@gmail.com wrote: I updated the DMD and tried RDMD, but still no luck. Linker errors galore. You can see all of them here: http://pastebin.com/C6cRVGKt You need to link the library as well, try adding -L-llua (I think) to the command. A better way to do it is just include this in your code: pragma(lib, lua); // Assuming the lib file is named lua.lib Benefits: - One less cmd-line param. - Should work the same on both windows and posix (the linker args are completely different between windows and posix). Drawbacks: - Not implemented in GDC yet. Still not implemented in GDC?? Cannot be implemented in GDC. The driver/compiler/assembler/linker structure doesn't allow it.
Re: Importing D libraries
On Wed, Jul 27, 2011 at 2:10 AM, Jacob Carlborg d...@me.com wrote: Cannot be implemented in GDC. The driver/compiler/assembler/**linker structure doesn't allow it. Why is that? Well, the short version is that GDC (the executable) is not a compiler. GDC is a driver that runs cc1d to compile your code, runs as (at least I think that's the name offhand) to assemble it, then runs ld to link it. As far as I know, there's no way for cc1d to communicate the contents of pragmas like this back to the driver, which it would have to do if you wanted the driver to include the library in the arguments to the linker. It's possible that I just don't know the infrastructure well enough, but I think this is one of the reasons the GCC guys refused to implement #pragma in C/C++ as well.
Re: Importing D libraries
On Tue, Jul 26, 2011 at 2:02 AM, Dainius (GreatEmerald)
past...@gmail.comwrote:
I must be missing something incredibly obvious here, but I can't find
out what it is... I'm trying to build a very simple test program for
LuaD, right now it simply imports the library. But it throws a linker
error for some reason. Here's the program I'm trying to compile:
import std.stdio;
import luad.all;
int main()
{
readln();
return 0;
}
This is what I use to compile it:
dmd -ILuaD LuaTest.d
This is the error it gives me:
LuaTest.o:(.data+0x18): undefined reference to
`_D4luad3all12__ModuleInfoZ'
collect2: ld returned 1 exit status
--- errorlevel 1
I got LuaD by simply performing a git clone from here:
https://github.com/JakobOvrum/LuaD
Using Linux, DMD64 v2.053.
DMD will parse files you import, but won't generate output for them unless
you specify them on the command line. If you want it to generate code for
luad.all (which is what the linker says is missing), you need to compile
like this:
dmd -ILuaD LuaTest.d LuaD/luad/all.d
There are probably other files you need in LuaD, so you might try generating
a lib:
dmd -ILuaD -lib -ofLuaD.lib LuaD/luad/*.d [insert other paths as
appropriate]
Which you can then use like this:
dmd -ILuaD LuaTest.d LuaD.lib
Re: DMD Backend: Deciding instructions to use/avoid?
On Thu, Jun 9, 2011 at 5:58 PM, Nick Sabalausky a@a.a wrote: Bernard Helyer b.hel...@gmail.com wrote in message news:isdgdc$m3a$1...@digitalmars.com... 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. I can try that if anyone can help walk me through it or at least point me to a good beginner's tutorial for gdb. I never use commandline debuggers, and I've never even touched gdb, so I don't have the slightest clue how to use it. The short version is to run `gdb yourapp` which will get you into the GDB shell. Then `run` to actually start the app. It will halt and return to the shell when it hits the bad instruction, and you should type `disass` to view the assembly code of the current function. There will be a pointer (-, I think) pointing to the current instruction in the listing. You can find GDB basics at http://www.cs.cmu.edu/~gilpin/tutorial/ although that tutorial doesn't include `disass`. I mostly learned it by firing it up and typing `help` :D
Re: Install DWT2 using DMD and Tango
On Wed, Jun 8, 2011 at 2:57 PM, Jesse Phillips jessekphillip...@gmail.comwrote: Andrew Wiley Wrote: On Wed, Jun 8, 2011 at 11:54 AM, Fabian contact-...@freenet.de wrote: Hi I'm trying to install DWT2 to create GUI applications with D. I have downloaded DWT2 with TortoiseHg already and I've installed Ruby and Rake. But when I try to build the packages I get the following error message: http://imageshack.us/photo/my-images/62/dwt2error.png/ Is there anybody who can help me? I believe it's possible to use DWT2 and Tango - isn't it? It's called DWT2 because it's a port of the existing DWT code to D2. Tango is a replacement standard library for D1, so no, they can't really be used together. I'm not sure about the state of DWT1, but it should be fairly stable, even if it hasn't been worked on recently. No, DWT2 is a strategy change to how DWT is structured. The change was to use the structure of SWT instead of renaming and moving everything. This was to make porting easier. It also combined dwt-linux, dwt-windows dwt-mac under one repository. Ah, apparently I am a font of misinformation. Now that I think about it, I do remember a discussion a while back about issues making D2 code remain compatible with D1 where DWT2 was brought up. Or at least I think I do. Sorry for the noise.
Re: Install DWT2 using DMD and Tango
On Wed, Jun 8, 2011 at 11:54 AM, Fabian contact-...@freenet.de wrote: Hi I'm trying to install DWT2 to create GUI applications with D. I have downloaded DWT2 with TortoiseHg already and I've installed Ruby and Rake. But when I try to build the packages I get the following error message: http://imageshack.us/photo/my-images/62/dwt2error.png/ Is there anybody who can help me? I believe it's possible to use DWT2 and Tango - isn't it? It's called DWT2 because it's a port of the existing DWT code to D2. Tango is a replacement standard library for D1, so no, they can't really be used together. I'm not sure about the state of DWT1, but it should be fairly stable, even if it hasn't been worked on recently. As an overview, D1 originally had Phobos as the standard library, but it wasn't that great, so an independent team built Tango as a replacement. Tango hasn't ever officially shipped with DMD, the reference compiler, but it's pretty much become the standard for D1 (with a few exceptions and attempts to reconcile it with Phobos). Nowadays, we have D2 and Phobos2 (which is generally just called Phobos). There's an ongoing project to port Tango to D2 as well, and Druntime, the runtime library, has been separated from Phobos2 to hopefully make Tango and Phobos2 coexist if/when that D2 port is completed (back in D1, Phobos and Tango both included their own runtimes, so you couldn't use both at the same time). In the meantime, Phobos2 far better than Phobos1, and Andrei has been leading its development. Learn to Tango with D obviously refers to D1/Tango The D Programming Language refers to D2/Phobos2 Hopefully that makes everything a bit clearer.
Re: Receiving data into a type using sockets
On Sun, Jun 5, 2011 at 12:55 PM, David Nadlinger s...@klickverbot.at wrote: On 6/5/11 9:49 PM, Jonathan Sternberg wrote: Cool. It compiles, but it doesn't seem to be doing exactly what I want. Say I send 2 integers from the server to the client. When I do this on the client, it seems to do the wrong thing. int first, second; auto sock = new TcpSocket(); sock.connect(new InternetAddress(localhost, 1)); writeln( sock.receive((first)[0..int.sizeof]) ); writeln( sock.receive((second)[0..int.sizeof] ); This seems to print 8 and then block on the second call to receive. I thought that D was supposed to recognize that the array was only 4 bytes long and read only that much. (note: on a 32-bit machine, so int comes out to 4 bytes) When I do: writeln( (first)[0..int.sizeof].length ); It prints 4 as it's supposed to. first is of type int*, so (first)[0..int.sizeof] returns a slice pointing to int.sizeof (i.e. 4) ints, not a single one as you intend to. Just use »(first)[0..1]« as per my original reply, and you should be fine. Also, note that receive is basically a direct call to C's receive, which means that it has the same behavior with regards to buffer filling. Calling sock.receive((first)[0..1]) returns the number of bytes read, which may be less than 4. I've handled this in the past by writing a template function that takes a primitive type and loops until it has read all the bytes it needs. Oh, and D's int is always 32 bits, on 32 bit or 64 bit platforms. size_t is an alias that switches from uint on 32 bit to ulong on 64 bit, and there's another alias somewhere for signed types (ssize_t, I believe). The primitive types always have the same sizes until you get into things like cent.
Re: how to get the local?
On Thu, Jun 2, 2011 at 12:23 AM, Nick Sabalausky a@a.a wrote: Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message news:mailman.521.1306960464.14074.digitalmars-d-le...@puremagic.com... From my understanding of this page http://msdn.microsoft.com/en-us/library/dd318136%28v=vs.85%29.aspx : Note The application should call this function in preference to GetUserDefaultLCID if designed to run only on Windows Vista and later. It's not in kernel32.lib distributed with DMD. You would have to create an OMF import lib by calling implib /system kernel32.dll (your own kernel32.dll) if you're actually using Vista or a newer OS and then linking with that. But you can say goodbye to supporting Windows older than Vista. OTOH GetUserDefaultLCID /is/ in the kernel32.lib distributed with DMD. So why not use that? Lloyd, if the program you're writing is designed to be sold or distributed to the public then I'd highly recommend against doing anything that requires at least Vista. From what I've heard, the adoption rates of Vista and Win7 haven't been very good and about half of the Windows systems out there are still XP and pretty much holding there. A *lot* of Windows users are deliberately sticking with XP, and you'll be loosing a lot of people. Of course, if your software is only designed to be used internally by some company, or just for you own use, etc., then obviously it doesn't matter... Actually, Windows 7 is growing somewhat exponentially and XP is falling, though that fall isn't accelerating too rapidly. However, XP still sits at around 45%.
Re: How to break module into multiple file.
On Mon, May 23, 2011 at 4:39 AM, Matthew Ong on...@yahoo.com wrote: On 5/23/2011 3:58 PM, Timon Gehr wrote: On 2011-05-23 00:09, Matthew Ong wrote: Thanks everyone that gave some working model to a newbie from Java Space. I found the working file layout model from dwt2 http://hg.dsource.org/projects/dwt2 There is a dwt2\base\src Haha. That is exactly like what I am looking for. Yes. The person made one module to one d file. Super cool. Yes, but DWT is also an almost direct port of a Java project (you'll also find a port of quite a bit of the Java standard library in there), so you really can't use it as an example to support any sort of D style. The authors did what made sense in a library that wasn't designed for D.
Re: Linux: How to statically link against system libs?
On Mon, May 9, 2011 at 11:01 PM, Adam D. Ruppe destructiona...@gmail.comwrote: Nick Sabalausky wrote: Do we know what that switch is for? --no-warn-search-mismatch Normally ld will give a warning if it finds an incompatible library during a library search. This option silences the warning. In the DMD changelog, there was a note about making the linker a little less noisy. I assume that's the reasoning behind the change. Actually I just realized it was Gnome. Gnome sucks too! (I actually run a mostly custom linux gui. Customly hacked up window manager, custom theme, custom taskbar, hacked up terminals, hacked up IM client my own linux install is one of the very few on the planet that doesn't suck ass. It still sucks, mind you, just not ass anymore.) XP seems to work fine for me in VirtualBox Yeah, it's not bad on my comp either, but I always find some annoying lag as menus pop up and things like that. Other benefits of remote desktop though are easier sound and file/clipboard sharing without installing anything in the guest. Whatever floats your boat, but after I tried out the remote desktop strategy I was very pleased. I run Arch/Gnome in Virtualbox and get reasonable performance. There's some menu lag, but it's not significant enough to bother me too much. It may just be that my standards are lower :D Virtualbox's guest additions and accelerated video definitely made a difference for me, although apparently they don't yet support enough OpenGL calls to allow Gnome 3's shell to run in a VM.
Re: Why are unsigned to signed conversions implicit and don't emit a warning?
On Sun, Apr 10, 2011 at 7:57 PM, Jonathan M Davis jmdavisp...@gmx.com wrote: Andrej Mitrovic: I just had a little bug in my code. In the WindowsAPI, there's this alias: alias ubyte BYTE; Unfortunately I didn't check for this, and I erroneously assumed BYTE was a signed value (blame it on my lack of coffee). I and Don have asked (in Bugzilla and elsewhere) to change the built-in names into sbyte and ubyte, to avoid the common confusions between signed and unsigned bytes in D, but Walter was deaf to this. But what really surprises me is that these unsigned to signed conversions happen implicitly. I didn't even get a warning, even though I have all warning switches turned on. Add your vote here (I have voted this), a bug report from 07 2006, but Walter doesn't like this warning, and warnings in general too: http://d.puremagic.com/issues/show_bug.cgi?id=259 Personally, I see _zero_ value in renaming byte, int, etc. to sbyte, sint, etc. It's well-known that they're signed. I don't see how adding an extra s would make that any clearer. Their names are perfectly clear as they are. However, I also would have thought that converting between signed and unsigned values would be just as much of an error as narrowing conversions are - such as assigning an int to a byte. And arguably, assigning either an unsigned value to a signed value or vice versa is _also_ a narrowing conversion. So, I would have thought that it would be an error. Apparently not though. I agree completely. The names are fine, we just need to get the conversions right. Yes, they aren't theoretically correct but integers as we define them aren't even integers in the mathematical sense, so the whole system isn't theoretically correct. D's scheme, while not pure, is very natural to use.
Re: I seem to be able to crash writefln
On Wed, Mar 9, 2011 at 5:19 PM, Joel Christensen joel...@gmail.com wrote:
This is on Windows 7. Using a def file to stop the terminal window coming
up.
win.def
EXETYPE NT
SUBSYSTEM WINDOWS
bug.d
import std.stdio;
import std.string;
void main() {
auto f = File( z.txt, w );
scope( exit )
f.close;
string foo = bar;
foreach( n; 0 .. 10 ) {
writefln( %s, foo );
f.write( format( count duck-u-lar: %s\n, n ) );
}
}
output (from in z.txt):
count duck-u-lar: 0
My understanding is that the 0..10 isn't actually a range notation,
and you need to use iota(0, 10). I may be wrong, but if I'm right,
hopefully someone can explain why this syntax works?
I remember there being a discussion about this recently; I'll see if I
can find it.
Re: Best way in D2 to rotate a ubyte[4] array
On Wed, Mar 9, 2011 at 7:25 PM, U2 fan i...@u2fan.com wrote:
== Quote from bearophile (bearophileh...@lycos.com)'s article
Tom:
What is the most efficient way of implement a rotation of ubyte[4] array?
By rotation I mean: rotateRight([1, 2, 3, 4]) - [4, 1, 2, 3]
Two versions, I have done no benchmarks so far:
import std.c.stdio: printf;
union Four {
ubyte[4] a;
uint u;
}
void showFour(Four f) {
printf(f.u: %u\n, f.u);
printf(f.a: [%d, %d, %d, %d]\n,
cast(int)f.a[0], cast(int)f.a[1],
cast(int)f.a[2], cast(int)f.a[3]);
}
void main() {
Four f;
f.a[] = [1, 2, 3, 4];
showFour(f);
f.u = (f.u 8) | (f.u 24);
showFour(f);
printf(\n);
// alternative
f.a[] = [1, 2, 3, 4];
uint u2 = f.u;
showFour(f);
printf(u2: %u\n, u2);
asm {
rol u2, 8;
}
f.u = u2;
showFour(f);
}
Bye,
bearophile
I am offend!
Once I figured it out, I lol'd quite a bit.
Re: I seem to be able to crash writefln
On Thu, Mar 10, 2011 at 1:31 AM, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Wednesday 09 March 2011 23:15:13 Andrew Wiley wrote:
On Wed, Mar 9, 2011 at 5:19 PM, Joel Christensen joel...@gmail.com wrote:
This is on Windows 7. Using a def file to stop the terminal window coming
up.
win.def
EXETYPE NT
SUBSYSTEM WINDOWS
bug.d
import std.stdio;
import std.string;
void main() {
auto f = File( z.txt, w );
scope( exit )
f.close;
string foo = bar;
foreach( n; 0 .. 10 ) {
writefln( %s, foo );
f.write( format( count duck-u-lar: %s\n, n ) );
}
}
output (from in z.txt):
count duck-u-lar: 0
My understanding is that the 0..10 isn't actually a range notation,
and you need to use iota(0, 10). I may be wrong, but if I'm right,
hopefully someone can explain why this syntax works?
I remember there being a discussion about this recently; I'll see if I
can find it.
0..10 works with foreach. It's specific to foreach. iota also works, because
it
produces a range rather being built in to the language. As such, iota works in
places _other_ than foreach. But 0..10 works just fine in foreach. It
definitely
pre-dates iota.
- Jonathan M Davis
Ah, then I guess I just need to learn me some D. Sorry for the noise.
Re: dmd gdc in archlinux
On Sun, Mar 6, 2011 at 10:55 PM, %u asm...@hotmail.com wrote: == Quote from %u (asm...@hotmail.com)'s article i can't install it and i use this command yaourt -R gdc i mean yaourt -S gdc It looks like in the official repositories, we have dmd, but you're not installing libtango or libphobos. You must install one of them. If you're after D2, you're back in the AUR with gdc2-hg or dmd2/libphobos2.
Re: Sending a socket to another thread
On Tue, Feb 15, 2011 at 12:00 PM, lurker lur...@mailinator.com wrote: I'd like to modify the listener sample to handle requests in separate threads but I'm experiencing weird crashes. What platform and version of DMD? There was a bug in the Socket implementation on Windows recently where the WinSock data was either initialized or deinitialized multiple times. I don't remember the details, but I remember having weird crashes. Once a connection is established can I send() the relevant socket to another thread and receive() from there? Yes, I've done this in the past.
Re: Sending a socket to another thread
On Tue, Feb 15, 2011 at 4:13 PM, lurker lur...@mailinator.com wrote:
What platform and version of DMD? There was a bug in the Socket
implementation on Windows recently where the WinSock data was
either
initialized or deinitialized multiple times. I don't remember the
details, but I remember having weird crashes.
Yes, Windows + dmd 2.51.
I looked it up, and that bug was fixed in 2.50, so that's not the problem.
Yes, I've done this in the past.
Great. At least is posible. Do you have an example available
somewhere? It would really help
Actually, I lied, I was getting sockets and spawning new threads with
them as arguments.
However, the attached source compiles and runs on Linux (although it
doesn't do any sort of cleanup when it exits, so I can get errors on
the bind call that the address is in use).
Disclaimer:
I'm not sure whether casting to and away from shared like I do is
actually safe, so hopefully someone more knowledgeable can chime in on
that. From a type standpoint, as long as ownership of the socket is
passed between threads cleanly and only one thread can access the
socket at a time, nothing odd should happen, but I'm not sure how/if
TLS and the actual details of shared could break this. I'll see what I
can dig out as far as that goes.
module dsocktest;
import std.stdio;
import std.socket;
import std.concurrency;
void main() {
auto sock = new TcpSocket();
sock.bind(new InternetAddress(5122));
spawn(listen, cast(shared)sock, thisTid);
while(true) {
receive((shared(Socket) s) {
auto sock = cast(Socket)s;
writeln(got socket!);
sock.send(You Win!\n);
sock.close();
});
}
}
void listen(TcpSocket s, Tid dest) {
s.listen(5);
while(true) {
auto sock = cast(shared)s.accept;
writeln(got connection!);
send(dest, sock);
}
}
Re: Sending a socket to another thread
On Tue, Feb 15, 2011 at 4:59 PM, Andrew Wiley debio...@gmail.com wrote: On Tue, Feb 15, 2011 at 4:13 PM, lurker lur...@mailinator.com wrote: What platform and version of DMD? There was a bug in the Socket implementation on Windows recently where the WinSock data was either initialized or deinitialized multiple times. I don't remember the details, but I remember having weird crashes. Yes, Windows + dmd 2.51. I looked it up, and that bug was fixed in 2.50, so that's not the problem. Yes, I've done this in the past. Great. At least is posible. Do you have an example available somewhere? It would really help Actually, I lied, I was getting sockets and spawning new threads with them as arguments. However, the attached source compiles and runs on Linux (although it doesn't do any sort of cleanup when it exits, so I can get errors on the bind call that the address is in use). Disclaimer: I'm not sure whether casting to and away from shared like I do is actually safe, so hopefully someone more knowledgeable can chime in on that. From a type standpoint, as long as ownership of the socket is passed between threads cleanly and only one thread can access the socket at a time, nothing odd should happen, but I'm not sure how/if TLS and the actual details of shared could break this. I'll see what I can dig out as far as that goes. TDPL seems to say that casting away shared is alright - just make sure it isn't ever actually shared between threads and you should be fine.
Re: Number of references to a Class Object
On Sat, Feb 12, 2011 at 1:20 AM, d coder dlang.co...@gmail.com wrote: Greetings I am in a situation where I need to know the number of references to a class' object. To explain, I have an array of class objects and I occasionally process this array. But if a particular object in this array is not being garbage collected just because it is part of this array, I would like to loose that object by making it null. I believe what you're referring to is generally called a Weak Reference, which is a reference that the GC doesn't consider when deciding to keep an object alive, but that the GC will update if an object dies. There's a feature request at http://d.puremagic.com/issues/show_bug.cgi?id=4151
Re: Source code annotations alla Java
On Thu, Jan 20, 2011 at 8:02 AM, Steven Schveighoffer schvei...@yahoo.comwrote: On Thu, 20 Jan 2011 08:47:28 -0500, Justin Johansson j...@nospam.com wrote: Not long ago the Java Language people introduced the idea of annotations together with an annotation processing tool (apt). Now perhaps the idea of source code annotations is not actually a Java invention per se, however for someone learning D is there any equivalent idiom [of Java annotations] in the D language? Haven't used Java since they added annotations, but I think they are like C# attributes? In any case, D has an annotation syntax like: @property But I think at the moment, annotations have no custom ability. Only compiler-defined annotations are allowed. This may change in the future, but probably not short-term. FWIW, I think we need a much richer runtime-reflection capability before we can use custom annotations to any great effect. I would find it useful to be able to access annotations as part of compile time reflection, actually, but AFAIK no progress has been made on that front so far.
