Re: .di files have implementation??
On Sat, Oct 22, 2011 at 9:49 PM, Andrej Mitrovic 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: Is __VERSION__ cross-compiler compatible?
On Mon, Nov 21, 2011 at 8:16 PM, Andrej Mitrovic wrote: > GDC does seem to use this, now that I've tested it: > > D:\dev\code\d_code>gdc test.d > 1067L > > D:\dev\code\d_code>gdc -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: Matching with std.concurrency receive
On Sat, Dec 10, 2011 at 1:38 PM, Jonathan M Davis 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: Restrict access to "critical" functions
2011/12/12 Christian Köstlin : > 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: Are D classes always garbage collected?
On Wed, Dec 21, 2011 at 10:20 PM, Froglegs 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: writing iterators without code duplication. inout?
On Thu, Dec 22, 2011 at 12:04 AM, pompei2 wrote:
>> int delegate(int delegate(ref int)) doIter() const
>> {
>> 74 return (int delegate(ref int) dg)
>> {
>> cast(typeof(this))(this).doIter()
>> 77 (
>> 78 (ref int i)
>>
>> {
>> int copy = i; dg(copy);
>> }
>> );
>> }
>> }
>
>
> I see what you are doing there. Unfortunately, the innermost delegate (the
> one doing the copy trick) somehow got @system attribute, which leads to the
> following compile errors (I added line numbers and reordered your code in
> the citation above):
>
> constiter.d(78): Error: cannot implicitly convert expression (__dgliteral2)
> of type void delegate(ref int i) @system to int delegate(ref int)
> constiter.d(77): Error: cast has no effect in expression
> (cast(const(Container))this.doIter()((__error)))
> constiter.d(74): Error: cannot implicitly convert expression (__dgliteral1)
> of type void delegate(int delegate(ref int) dg) @system to int delegate(int
> delegate(ref int))
>
> Where does this @system come from? How do I get rid of it?
Actually, it looks like your issue is here:
constiter.d(78): Error: cannot implicitly convert expression
(__dgliteral2) of type *void* delegate(ref int i) @system to int
delegate(ref int)
void delegate(ref int) != int delegate(ref int)
Re: test if object is instance of class at compile time
On Thu, Dec 22, 2011 at 8:35 AM, Trass3r 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: Catching signals with D
On Sat, Dec 24, 2011 at 7:37 AM, Matej Nanut 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 : > 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 wrote:
> On 12/24/2011 06:18 PM, Andrew Wiley wrote:
>>
>> 2011/12/24 Mr. Anonymous:
>>
>>> 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 wrote:
> On 12/24/2011 07:00 PM, Andrew Wiley wrote:
>>
>> On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehr wrote:
>>>
>>> On 12/24/2011 06:18 PM, Andrew Wiley wrote:
>>>
>>>>
>>>> 2011/12/24 Mr. Anonymous:
>>>>
>>>>> 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 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 Gehr wrote:
>>>>
>>>> On 12/24/2011 07:00 PM, Andrew Wiley wrote:
>>>>>
>>>>>
>>>>> On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehr wrote:
>>>>>>
>>>>>>
>>>>>> On 12/24/2011 06:18 PM, Andrew Wiley wrote:
>>>>>>
>>>>>>>
>>>>>>> 2011/12/24 Mr. Anonymous:
>>>>>>>
>>>>>>>> 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 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: GetAndSet function (corresponding to cas function)
On Mon, Dec 26, 2011 at 2:34 PM, 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?
>
>
> 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 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: AA char[] as key
On Tue, Jan 3, 2012 at 1:25 PM, simendsjo 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 wrote: > On Tue, Jan 3, 2012 at 1:25 PM, simendsjo 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 wrote: > On 03.01.2012 20:41, Andrew Wiley wrote: >> >> On Tue, Jan 3, 2012 at 1:25 PM, simendsjo 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 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: Singleton Pattern
On Thu, Jan 5, 2012 at 4:15 PM, asm wrote: > how can i implementing the singleton pattern in D? Multithreaded or not?
Re: Singleton question (shared class)
On Wed, Jan 25, 2012 at 9:35 AM, Steven Schveighoffer
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: std.socket with GDC
On Sat, Feb 25, 2012 at 4:45 PM, DNewbie 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 >> >> reference"s, 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: What is a good strategy for finding undefined symbols...
On Sat, May 12, 2012 at 12:22 PM, WhatMeWorry 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: convert ubyte[k..k + 1] to int
On Wed, May 16, 2012 at 11:03 AM, Regan Heath wrote:
> On Wed, 16 May 2012 15:24:33 +0100, ref2401 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
>
> 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 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
> wrote:
> >
> > > On Wed, 16 May 2012 15:24:33 +0100, ref2401
> 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: floats default to NaN... why?
On Thu, Jun 7, 2012 at 6:50 PM, Minas 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 wrote: > On Friday, June 08, 2012 19:30:57 Jarl André" > @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: Segmentation fault hell in D
On Sat, Jun 9, 2012 at 6:09 AM, Dejan Lekic 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 >> wrote: >> >>> On Friday, June 08, 2012 19:30:57 Jarl André" >>> @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 11:57 AM, Kevin 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.
Re: floats default to NaN... why?
On Sat, Jun 9, 2012 at 4:53 PM, Andrew Wiley wrote: > > On Sat, Jun 9, 2012 at 11:57 AM, Kevin 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: Windows program instant crash: no messages.
On Tue, Jun 12, 2012 at 1:32 AM, Dmitry Olshansky 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 wrote:
> On Tue, Jun 12, 2012 at 1:32 AM, Dmitry Olshansky
> 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: Implicit conversion from class in parent class fails?
On Sat, Jun 16, 2012 at 11:52 AM, Namespace 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: Source code annotations alla Java
On Thu, Jan 20, 2011 at 8:02 AM, Steven Schveighoffer wrote: > On Thu, 20 Jan 2011 08:47:28 -0500, Justin Johansson > 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.
Re: Number of references to a Class Object
On Sat, Feb 12, 2011 at 1:20 AM, d coder 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: Sending a socket to another thread
On Tue, Feb 15, 2011 at 12:00 PM, lurker 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 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 wrote: > On Tue, Feb 15, 2011 at 4:13 PM, lurker 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: dmd & gdc in archlinux
On Sun, Mar 6, 2011 at 10:55 PM, %u 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: I seem to be able to crash writefln
On Wed, Mar 9, 2011 at 5:19 PM, Joel Christensen 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 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 wrote:
> On Wednesday 09 March 2011 23:15:13 Andrew Wiley wrote:
>> On Wed, Mar 9, 2011 at 5:19 PM, Joel Christensen 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: 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 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: Linux: How to statically link against system libs?
On Mon, May 9, 2011 at 11:01 PM, Adam D. Ruppe wrote: > 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: How to break module into multiple file.
On Mon, May 23, 2011 at 4:39 AM, Matthew Ong 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: how to get the local?
On Thu, Jun 2, 2011 at 12:23 AM, Nick Sabalausky wrote: > "Andrej Mitrovic" 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: Receiving data into a type using sockets
On Sun, Jun 5, 2011 at 12:55 PM, David Nadlinger 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: Install DWT2 using DMD and Tango
On Wed, Jun 8, 2011 at 11:54 AM, Fabian 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: Install DWT2 using DMD and Tango
On Wed, Jun 8, 2011 at 2:57 PM, Jesse Phillips wrote: > Andrew Wiley Wrote: > > > On Wed, Jun 8, 2011 at 11:54 AM, Fabian 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: DMD Backend: Deciding instructions to use/avoid?
On Thu, Jun 9, 2011 at 5:58 PM, Nick Sabalausky wrote: > "Bernard Helyer" 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: Importing D libraries
On Tue, Jul 26, 2011 at 2:02 AM, Dainius (GreatEmerald)
wrote:
> 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: Importing D libraries
On Tue, Jul 26, 2011 at 11:38 PM, Jacob Carlborg wrote: > On 2011-07-26 21:34, Andrej Mitrovic wrote: > >> On 7/26/11, Nick Sabalausky wrote: >> >>> "Pelle"> wrote in >>> message >>> >>> news:op.vy74cwejzu79i9@pelle-**d2608-a1... >>> On Tue, 26 Jul 2011 13:06:56 +0200, Dainius (GreatEmerald) 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 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 Wed, Jul 27, 2011 at 11:46 PM, Jacob Carlborg wrote: > On 2011-07-28 03:23, Andrew Wiley wrote: > >> On Wed, Jul 27, 2011 at 2:10 AM, Jacob Carlborg > <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: Permission denied under Ubuntu.
On Mon, Aug 8, 2011 at 4:30 PM, Charles McAnany wrote: > 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: Permission denied under Ubuntu.
On Tue, Aug 9, 2011 at 1:40 AM, Johannes Pfau 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: help understanding import libraries
On Fri, Aug 19, 2011 at 9:38 AM, Jesse Phillips wrote: > 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: gdc setup without gcc
On Thu, Sep 1, 2011 at 12:31 AM, %u 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: D on other platforms than Win,Lin,Mac?
On Tue, Sep 6, 2011 at 2:25 PM, Johannes Pfau 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 wrote: > "Trass3r" 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: D on other platforms than Win,Lin,Mac?
On Wed, Sep 7, 2011 at 2:46 AM, Johannes Pfau wrote: > Andrew Wiley wrote: > >On Tue, Sep 6, 2011 at 2:25 PM, Johannes Pfau 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.
