Re: std.concurrency and module constructors
On Fri, 11 May 2012 07:34:46 -0400, japplegame jappleg...@gmail.com
wrote:
OS: Windows 7 64bit
Compiler: DMD32 D Compiler v2.059
Using spawn in module constructor causes very strange behavior.
import std.concurrency;
import std.stdio;
void main() {
}
void worker() {
receiveOnly!OwnerTerminated;
}
static this() {
writeln(module constructor);
spawn(worker);
}
static ~this() {
writeln(module destructor);
}
prints in console:
module constructor
module destructor
module constructor
module destructor
module constructor
module constructor
module constructor
module constructor
module constructor
...
This list is for bugzilla to post to, it is not for general bug reports or
help requests. I really wish it was disabled to post to from everyone but
bugzilla.
Please repost your issue to D.learn.
Thanks
-Steve
Re: GLUT glutCreateWindow error
On Wed, 18 Apr 2012 03:27:45 -0400, DAS_888 vangelisfore...@yandex.ru wrote: When I'm trying to create GLUT Window via DMD 2.059 compilation of my code, I'm getting an error: freeglut ERROR: Internal error FBConfig with necessary capabilities not found in function fgOpenWindow X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 4 (X_DestroyWindow) Resource id in failed request: 0x0 Serial number of failed request: 57 Current serial number in output stream: 60 But if my glut code was compiled by GDC the GLUT Window creates fine. Thanks. This request is quite incomplete. In any case, this list is not for general questions, it's simply a mailing list that shows changes to bugzilla. Use digitalmars.d.learn to post questions (and try to include some more context, this post will not get you any help). Brad, can we once and for all close this list to general posts? -Steve
Re: overloading template functions it not always allowed
On Fri, 31 Dec 2010 09:09:23 -0500, szali bszalk...@gmail.com wrote: BTW, this list is generally not used for questions (it's auto-generated from bugzilla reports), d.learn is a better place, but no worries, here are your answers: In one of my classes, I created two overloads to opIndexAssign (the second one was made for better performance, because in most cases only one index is used): public final T opIndexAssign(T value, int[] args ...) public final T opIndexAssign(T value, int i) These are allowed by the compiler. But these are not: public T opIndexOpAssign(string op)(T value, int i) public T opIndexOpAssign(string op)(T value, int[] args ...) It's a limitation of the way templates are specified. To the compiler, both are the same template. The way around this is to change the template parameters: public T opIndexOpAssign(string op)(T value, int i) public T opIndexOpAssign(string op, bool variadic=true)(T value, int[] args ...) It's a crappy requirement, I think this is a well-known bug. BTW, you gain very very very little by having both these functions, the variadic one is all you need. Also, you may have an issue with using a variadic, as I think you can call with zero indexes (not sure how that would look). You may want to replace both with this one function: public T opIndexOpAssign(string op)(T value, int idx0, int[] idxN...) And when I want to make these final, like this: public final T opIndexOpAssign(string op)(T value, int i) the compiler complains because it thinks i want to apply the final keyword to string op (why would I? the keyword is at a completely different position). That is kind of strange. All template functions are final. They cannot be virtual, so even though I feel this is a bug (it should be silently ignored), you can fix it by just removing final. -Steve
Re: overloading template functions it not always allowed
On Fri, 31 Dec 2010 10:11:02 -0500, bearophile bearophileh...@lycos.com wrote: Steven Schveighoffer: so even though I feel this is a bug (it should be silently ignored), Generally silently ignoring attributes is exactly the opposite you want from a modern compiler. See bug 3934. In this case though, you are asking for a function which is already final to be final. The compiler can safely ignore the request because the request is already satisfied. If you asked for a virtual function to be final, and the compiler ignored the request, I'd say it was bad. -Steve
Re: D2 Associative Arrays keys has a bug
On Thu, 02 Sep 2010 06:28:14 -0400, soarowl soar...@yeah.net wrote:
private import
std.stdio;
static ubyte[] data = [1, 3, 5, 7, 9, 7, 5];
void main()
{
int[ubyte] set;
foreach(e; data) set[e]++;
//foreach(k, v; set) std.stdio.writef(%d: %d , k, v);
foreach(e; set.keys.sort) std.stdio.writef(%d , e);
//foreach(e; set.values) std.stdio.writef(%d , e);
}
I expect result: 1 3 5 7 9
But result will be: 0 0 0 1 5 or something else, which not equals
expaect result.
http://d.puremagic.com/issues/show_bug.cgi?id=4201
-Steve
Re: DMD1 function template broken or did I f.u.?
On Tue, 24 Aug 2010 11:18:35 -0400, 0ffh
fr...@youknow.what.todo.internetz wrote:
Hi, all!
Try this:
--- snip ---
void remove(T)(out T[] array,T element) {
int r=0,w=0;
while (rarray.length) {
if (array[r]!=element)
array[w++]=array[r];
++r;
}
array.length=w;
}
void test() {
int[] array;
int element=2;
//
array=[1,3,2,2,1,3,1,1,2];
writef(direct\n);
writef( before : ,array,\n);
int r=0,w=0;
while (rarray.length) {
if (array[r]!=element)
array[w++]=array[r];
++r;
}
array.length=w;
writef( after : ,array,\n);
//
array=[1,3,2,2,1,3,1,1,2];
writef(template\n);
writef( before : ,array,\n);
remove!(int)(array,element);
writef( after : ,array,\n);
}
--- snap ---
I get the following output:
direct
before : [1,3,2,2,1,3,1,1,2]
after : [1,3,1,3,1,1]
template
before : [1,3,2,2,1,3,1,1,2]
after : []
So, my question is: Huh?
s/out/ref
out means return this argument by reference, but initialize it to its
initial value first which for arrays means, a null array.
ref means pass the argument by reference.
Also, btw, you should not need to specifically call the !int version, you
can just do remove(array, element).
-Steve
doc errors in std.range
Just getting more familiar with ranges in D2, I saw the following errors in the docs: isInfinite: Specifies that the range must have a static member that equals false, but it really should say that the range must have a static member *named empty* that equals false. advance: mislabel, The pass of r into *drop* is by reference, should be advance, not drop. retreatN: similar issue as advance, example also has mislabel. SListRange: popFront,front: last sentence either reference a hidden member input or is a copy-paste error. = Couple comments I thought of, could have made another post, but... 1. advance is O(n) if slicing is not offered. However, an infinite range doesn't, and shouldn't, offer slicing. But it might be able to advance n elements in constant time if each element is well defined without a recurrence. You may want to implement some sort of skip function, which advance uses if slicing isn't available, and it can be supported. For example, an infinite range of 1 to infinity could be easily skipped n elements. However, you don't want to offer a slice function, because the result might or might not be an infinite range (depending on if the second argument to the slice is $). A stream may need a similar function. For example, skipping n bytes could be a quick operation. skip should only be defined if it can be done faster than repeatedly calling popFront. 2. Transversal, I would think, should continue to iterate over the elements that are left (if so desired). That is, given two ranges such as: [1,2,3] [4,5,6] I would think a useful range over this would result in: [1,4,2,5,3,6] -Steve
Re: [Issue 2934] .dup does not return empty string
On Mon, 04 May 2009 16:56:49 -0400, Derek Parnell de...@psych.ward wrote: On Mon, 4 May 2009 17:44:56 + (UTC), d-bugm...@puremagic.com wrote: http://d.puremagic.com/issues/show_bug.cgi?id=2934 schvei...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from schvei...@yahoo.com 2009-05-04 12:45 --- From posts in the newsgroup, I've determined that this bug is invalid: 1. Duplicating an empty array should always return a null array. Otherwise, you'd have to allocate space to store 0 data bytes in order for the result to be non-null. 2. String literals have a null character implicitly appended to them by the compiler. This is done to ease calling c functions. So a string literal's pointer cannot be null, since it has to point to a static zero byte. The spec identifies specifically item 2 here: http://www.digitalmars.com/d/1.0/arrays.html#strings see the section describing C's printf and Strings I could not find a reference for item 1, but I remember reading something about it. Regardless of it is identified specifically in the spec or not, it is not a bug, as the alternative would be to allocate blocks for 0-sized arrays. Huh??? Duplicating something should give one a duplicate. I do not think that this is an invalid bug. Ok, so duplicating an empty array causes memory to be allocated - so what! I asked for a duplicate so give me a duplicate, please. To me, the no surprise path is simple. Duplicating an empty array should return an empty array. Duplicating a null array should return a null array. Is that not intuitive? what's not intuitive is comparing an array (which is a struct) to null. char[] arr1 = ; char[] arr2 = null; assert(arr1 == arr2); // OK assert(arr1 == null); // FAIL I'd say that comparing an array to null should always succeed if the array is empty, but I guess some people may use the fact that the pointer is not null in an empty array. I definitely don't want the runtime to allocate blocks of data when requested to allocate 0 bytes. In any case, this bug is not valid, because the compiler acts as specified by the spec. I never compare arrays to null if I can remember, I always check the length instead, which is consistent for both null and empty arrays. -Steve
Re: dmd.conf problems on dmd.2.019 (object.d not readable)
Charles Hixson wrote Message: object.d: module object cannot read file 'object.d' The fix was to alter dmd.conf, thus: [Environment] DFLAGS=-I/usr/local/dmd/src/phobos -L-L/usr/local/dmd/lib [EMAIL PROTECTED]/../src/phobos [EMAIL PROTECTED]/../lib I'm running on Ubuntu Hardy Heron. dmd is installed in /usr/local/dmd, but the execution is via symbolic links in /usr/local/bin. My guess is that it's reading the compilation path via the links rather than the installation location. Sorry I didn't file this via Bugzilla, but I'm on the wrong computer, and I don't have my account memorized. The benefit of links is that the application does not know that it is a link (and shouldn't try to find out). This is the expected behavior in my opinion. -Steve
