Re: D Article Contest - win an iPad2
I don't see why is it inappropriate of you to comment on them. Shouldn't the winner be picked by the most votes? In that case, you have a vote like everyone else, and should also be allowed to comment.
Re: D Article Contest - win an iPad2
On 4/8/2011 12:05 AM, simendsjo wrote: I don't see why is it inappropriate of you to comment on them. Shouldn't the winner be picked by the most votes? In that case, you have a vote like everyone else, and should also be allowed to comment. While technically you are correct, I still think it is unseemly for me to appear to try and influence the vote.
Re: D Article Contest - win an iPad2
On 30/03/2011 06:40, Walter Bright wrote: D Article Contest! Voting Rules 1. You must have used your handle to post to the digitalmars.D newsgroup prior to this announcement 2. One vote per handle 3. Voting will be done on the digitalmars.D newsgroup Question: Are votes per-article or per-author? If it's per-article it could lead to a situation where an author has the most votes but someone else's article has the most votes, per-author this isn't a problem. Of course if it's per author, it could lead to an author monopolizing the contest... -- Robert http://octarineparrot.com/
Re: D Article Contest - win an iPad2
On 4/8/11 10:35 AM, Robert Clipsham wrote: On 30/03/2011 06:40, Walter Bright wrote: D Article Contest! Voting Rules 1. You must have used your handle to post to the digitalmars.D newsgroup prior to this announcement 2. One vote per handle 3. Voting will be done on the digitalmars.D newsgroup Question: Are votes per-article or per-author? If it's per-article it could lead to a situation where an author has the most votes but someone else's article has the most votes, per-author this isn't a problem. Of course if it's per author, it could lead to an author monopolizing the contest... -- Robert http://octarineparrot.com/ If you're an author prolific enough to produce two or more quality articles within the time frame, I'd say you deserve to accumulate the votes. This is not a supermarket sale with one per family please. The more articles, the better for everybody. Of course Walter decides. Andrei
Re: D Article Contest - win an iPad2
On 4/8/2011 8:41 AM, Andrei Alexandrescu wrote: On 4/8/11 10:35 AM, Robert Clipsham wrote: On 30/03/2011 06:40, Walter Bright wrote: D Article Contest! Voting Rules 1. You must have used your handle to post to the digitalmars.D newsgroup prior to this announcement 2. One vote per handle 3. Voting will be done on the digitalmars.D newsgroup Question: Are votes per-article or per-author? If it's per-article it could lead to a situation where an author has the most votes but someone else's article has the most votes, per-author this isn't a problem. Of course if it's per author, it could lead to an author monopolizing the contest... -- Robert http://octarineparrot.com/ If you're an author prolific enough to produce two or more quality articles within the time frame, I'd say you deserve to accumulate the votes. This is not a supermarket sale with one per family please. The more articles, the better for everybody. Of course Walter decides. As it's an article contest, the votes would be for articles. While Andrei's thoughts are sensible, I don't want to try and change things midstream.
Re: GUI library for D
On 2011-04-07 21:38, Bruno Medeiros wrote: On 05/04/2011 14:06, Jacob Carlborg wrote: On 2011-04-05 13:08, Matthias Pleh wrote: So I think for short or middle term such solution like gtkD, QtD, DWT are good, but for the long term the D community needs a D GUI library completly written in D. Just my thoughts °Matthias You do know that DWT is completely written in D? Really? What about the parts of SWT that written in C? Or are those very small compared to the whole codebase? In SWT it's just the bindings which are written in C using JNI (these are generate automatically with a tool). Since D can link to C there's no need for any C code. Just bindings to the native libraries. -- /Jacob Carlborg
Re: Should all enums be immutable?
Trass3r wrote:
Am 07.04.2011, 18:03 Uhr, schrieb Simen kjaeraas simen.kja...@gmail.com:
On Wed, 06 Apr 2011 21:42:35 +0200, Trass3r u...@known.com wrote:
Am 06.04.2011, 20:40 Uhr, schrieb Simen kjaeraas
simen.kja...@gmail.com:
Yup. In theory, any immutable Foo declared at module scope (and likely
also those at static class/struct scope) could be elided by the linker
if it not used anywhere, but Optlink does not do that.
Ok, I guess the hack works by replacing every occurrence of the
constant identifier in the AST with the initializer part of enum foo
= initializer;?
So there would be no reason to keep enum manifest constants if this
Optlink bug was fixed?
Correct on both counts.
I'm still confused about this.
Don't we need enum to have things like PI not consume memory?
No, the only thing it does it make it not take up space in the
executable if it isn't used. And this is a linker issue.
Which directly brings me to the following:
http://www.digitalmars.com/d/2.0/enum.html states that enum ident = val;
is just shorthand for enum {ident = val}.
Yet it suggests these are different things by calling only these special
cases manifest constants and stating that SUCH declarations are not
lvalues. Even though normal enums aren't lvalues either:
enum {a = 5, b}
pragma(msg, b);
Error: constant 6 is not an lvalue
And also dmd handles them specially by treating enum as a storage class
(STC_manifest) in this case.
The terminology stuff is just because they're not enums. There is
nothing about them which would justify them being called an enumerated
type. But that's true of anonymous enums, enum { ident = val } as well.
Re: D grammar overhaul
Trass3r wrote:
I hope, we agree on !in and !is, as the current lexing introduces the
shown parsing problems. But !is needs to be added to the IsExpression
rules then.
Hmm what if you have something like Templ!is(T:int)
This is not allowed, template arguments without parenthesis are limited
to a specific list of single tokens.
Is http://d.puremagic.com/issues/show_bug.cgi?id=5785 fixable with
grammar changes other that !is being one token?
if (s.x !in a) {}
if (b !in a) {} // but this compiles!?
The second line works because it is special cased for PrimaryExpression
in the dmd parser by checking whether '!' is followed by 'in' or 'is',
while PostfixExpression only checks 'is'. I've added a patch to the
bugreport.
I haven't had a look yet how UFCS is expressed and how it could affect
this.
Re: Jonas Drewsen has been accepted as a GSoC 2011 mentor for Digital Mars
Congratulations! On 4/8/11, Walter Bright newshou...@digitalmars.com wrote: On 4/7/2011 5:54 PM, Andrei Alexandrescu wrote: Thanks David for rising to the challenge! You have been accepted. Congratulations! Congrats from me, too!
Re: GUI library for D
On 2011-04-08 00:27, Andrej Mitrovic wrote: DWT is 3x the codebase size of SWT? 0o Don't know what code base he used for SWT but the DWT repository contains: * 16 libraries from Eclipse * 1 library from IBM * 2 code bases for snippets * 2 SWT platforms (I counted those as 1 in the above number) So the DWT repository contains in total 20 different libraries/code bases. -- /Jacob Carlborg
Re: Jonas Drewsen has been accepted as a GSoC 2011 mentor for Digital Mars
On 2011-04-08 02:33, Andrei Alexandrescu wrote: Jonas Drewsen has been accepted as a mentor for the Google Summer of Code 2011 program for Digital Mars. He is particularly interested in topics related to networking. Please join me in congratulating and wishing the best to Jonas. We have 18 student applications and only 6 mentors. Probably we won't be able to accept all student applications, but we could definitely use more mentors. Please apply: http://d-programming-language.org/gsoc2011.html Andrei Do we need a 1:1 mapping between students and mentors? I though several students were interested in the same topics and perhaps could share a mentor. -- /Jacob Carlborg
image processing in D
i was thinking,would it be possible to read RAW image formats using std.outbuffer from phobos ?? regards, -- aman bansal namaban...@gmail.com
string and char[]
It is OK if I write int[char[]] asr; asr[hello] = 10; but the following does not compile: char[] car = hello; What is the explanation for this behaviour?
Re: string and char[]
On Fri, 08 Apr 2011 12:46:08 +0200, Morlan h...@valentimex.com wrote: It is OK if I write int[char[]] asr; asr[hello] = 10; but the following does not compile: char[] car = hello; What is the explanation for this behaviour? The first should not be allowed. It is a mistake to use non-immutable keys for an associative array. -- Simen
Re: string and char[]
It is a mistake to use non-immutable keys for an associative array. But a string literal isn't mutable..?
Re: Is the world coming to an end?
On 04/08/2011 07:25 AM, Nick Sabalausky wrote: I want base PI literals :) Yum. I want base 1 literals Denis -- _ vita es estrany spir.wikidot.com
Re: string and char[]
On Fri, 08 Apr 2011 13:01:41 +0200, simendsjo simen.end...@pandavre.com wrote: It is a mistake to use non-immutable keys for an associative array. But a string literal isn't mutable..? This is correct. I'm referring to line 1, int[char[]] asr;. This declaration is wrong, and should be rejected by the compiler. Also note that I'm saying non-immutable. const is not good enough, as it may come from a mutable source. -- Simen
Re: Is the world coming to an end?
On Fri, 08 Apr 2011 13:03:23 +0200, spir denis.s...@gmail.com wrote: On 04/08/2011 07:25 AM, Nick Sabalausky wrote: I want base PI literals :) Yum. I want base 1 literals Denis I like the numeric systems described in Hacker's Delight[1], among them complex numbers with integer parts, written as bit strings in base 1-i. [1]: http://www.amazon.com/a/dp/0201914654 -- Simen
Re: string and char[]
int[char[]] is consistently used D's Language reference to illustrate associative arrays. For me it looks like something that should not compile. Of course int[string] works without problem so I wonder why int[char[]] was used as an example. Was it carried over from D1 reference perhaps?
Re: string and char[]
On Fri, 08 Apr 2011 13:37:10 +0200, Morlan h...@valentimex.com wrote: int[char[]] is consistently used D's Language reference to illustrate associative arrays. For me it looks like something that should not compile. Of course int[string] works without problem so I wonder why int[char[]] was used as an example. Was it carried over from D1 reference perhaps? Probably it was. Could you please file a bug report on that? http://d.puremagic.com/issues/enter_bug.cgi -- Simen
Re: string and char[]
Of course, by saying it should not compile I mean things like asr[hello] should not compile.
Re: Jonas Drewsen has been accepted as a GSoC 2011 mentor for Digital Mars
On 4/8/2011 4:37 AM, Jacob Carlborg wrote: On 2011-04-08 02:33, Andrei Alexandrescu wrote: Jonas Drewsen has been accepted as a mentor for the Google Summer of Code 2011 program for Digital Mars. He is particularly interested in topics related to networking. Please join me in congratulating and wishing the best to Jonas. We have 18 student applications and only 6 mentors. Probably we won't be able to accept all student applications, but we could definitely use more mentors. Please apply: http://d-programming-language.org/gsoc2011.html Andrei Do we need a 1:1 mapping between students and mentors? I though several students were interested in the same topics and perhaps could share a mentor. Possibly better question: Would we even accept multiple students for the same project?
Re: string and char[]
On Fri, 08 Apr 2011 06:44:42 -0400, Simen kjaeraas simen.kja...@gmail.com wrote: On Fri, 08 Apr 2011 12:46:08 +0200, Morlan h...@valentimex.com wrote: It is OK if I write int[char[]] asr; asr[hello] = 10; but the following does not compile: char[] car = hello; What is the explanation for this behaviour? The first should not be allowed. It is a mistake to use non-immutable keys for an associative array. int[char[]] asr; pragma(msg, typeof(asr).stringof); outputs: AssociativeArray!(const(char)[],int) So the compiler adds const to the keys, which is why it works. Do I think this is the correct behavior? Absolutely not. First, it prevents nothing as far as modifying keys (const accepts mutable keys as well as const and mutable ones). Second, I believe you should be able to use whatever key constancy you want. We should just say if you do the wrong thing, it's undefined. Maybe @safe code can only use immutable keys. Third, if it must be illegal to have an AA with mutable keys, it should be an error, not silently change to const. -Steve
Re: GCC 4.6
On Thu, 07 Apr 2011 18:46:06 -0400, Matthias Pleh j...@konrad.net wrote: Am 01.04.2011 02:50, schrieb bearophile: inventing new language features for D3 Why do you always mention D3. I always hated the M$ strategy to release every 2 years a new C#/.Net version. I'm satisfied with D2, and let's improve it in quality not in quantity of features. D2 is essentially feature-frozen. Very little can change in terms of the language. D3 is the logical place to put radical new feature ideas. It has nothing to do with a schedule, it has to do with what version of the language has the ability to accept bearophile's pythonesque ideas ;) -Steve
[OT] Re: GUI library for D
On 07/04/2011 21:21, Nick Sabalausky wrote: Heh :) Damn Borg kids... I think I'm basically turning into Cranky Kong (if you've ever played Donkey Kong Country): They can't keep this level of graphics up for much longer! We used to be lucky if we only got three shades of grey, let alone any real colors! Look!...look at this!...as I rock, my beard swings! Waste of frames in my opinion! Are those actual quotes from the game? If so, hehe, pretty funny. :) -- Bruno Medeiros - Software Engineer
Re: DWT2
On 05/04/2011 04:54, Andrej Mitrovic wrote: You have to be kidding me. Who writes code like this? http://i.imgur.com/BBQde.png What's wrong with it? Do you mean the anonymous classes with all the fields and contructors for passing the variables in the enclosing scope? -- Bruno Medeiros - Software Engineer
Re: DWT2
On 05/04/2011 13:16, Paulo Pinto wrote: Most Java developers do. I code mostly in Java and really hate when I see code like this, but somehow the pattern of using anonymous classes in-place for event handlers has got into the mind of many developers. You will find thousands of such examples when searching for Java GUI examples, either in SWT or Swing. What's wrong with such pattern in Java? There aren't much alternatives in Java, what would you use instead? A nested class? Or use the outer class itself as the handler, by having it implement the handler interface? I find that using the anonymous class in-place is the cleanest in most situations. -- Bruno Medeiros - Software Engineer
Re: Is the world coming to an end?
On 08/04/2011 12:03, spir wrote: On 04/08/2011 07:25 AM, Nick Sabalausky wrote: I want base PI literals :) Yum. I want base 1 literals Denis hehe :D -- Bruno Medeiros - Software Engineer
GSoC Proposals: Level of Detail
I've been looking over some of the GSoC proposals and I've noticed that most aren't very detailed. It seems most of the students have only a very rough idea of what they want to do and plan on filling in the details at the beginning of the project. I don't have experience with GSoC and I'm trying to understand whether this is a problem or is what's expected. How detailed are the proposals supposed to be?
Re: string and char[]
On Fri, 08 Apr 2011 17:13:19 +0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Fri, 08 Apr 2011 06:44:42 -0400, Simen kjaeraas
simen.kja...@gmail.com wrote:
On Fri, 08 Apr 2011 12:46:08 +0200, Morlan h...@valentimex.com wrote:
It is OK if I write
int[char[]] asr;
asr[hello] = 10;
but the following does not compile:
char[] car = hello;
What is the explanation for this behaviour?
The first should not be allowed. It is a mistake to use non-immutable
keys for an associative array.
int[char[]] asr;
pragma(msg, typeof(asr).stringof);
outputs:
AssociativeArray!(const(char)[],int)
So the compiler adds const to the keys, which is why it works.
Do I think this is the correct behavior? Absolutely not. First, it
prevents nothing as far as modifying keys (const accepts mutable keys as
well as const and mutable ones). Second, I believe you should be able
to use whatever key constancy you want. We should just say if you do
the wrong thing, it's undefined. Maybe @safe code can only use
immutable keys. Third, if it must be illegal to have an AA with mutable
keys, it should be an error, not silently change to const.
-Steve
What about storing objects as keys? There is nothing wrong to modify those
objects as long as their order stays the same.
Immutable works, but that's an overkill, tail const would suffice in most
cases (where an indirection isn't used). E.g.:
int[void*] example;
All that is required is that int compare(T)(T lhs, T rhs) is pure (i.e.
returns same result for same inputs).
In future, compiler could statically enforce that
int compare(void* lhs, void* rhs) pure
{
if (lhs rhs) return 1;
if (lhs rhs) return -1;
return 0;
}
is correct and
int compare(char[] lhs, char[] rhs) pure
{
if (lhs rhs) return 1;
if (lhs rhs) return -1;
return 0;
}
is not.
For some reason (bug?), both compile with 2.052.
Re: GCC 4.6
On Thu, 07 Apr 2011 23:45:54 +0300, Bruno Medeiros brunodomedeiros+spam@com.gmail wrote: On 01/04/2011 01:50, bearophile wrote: On the other hand it's all voluntary service, most people don't get paid to help D development, so they_can't_ be managed as employed people, especially in a public forum designed for generic discussions about a language. Some people are more interested in coding a lot, other people are more interested in talking and ideas, and so on. If such desires aren't respected, some people may just decrease their interest in the community, if not leave. And given the small size of this group, this is bad. Frankly, (and regardless of how small our group may be) if the people leaving the community would be of those more interested in talking and ideas than coding a lot, I don't think it would be bad at all. You could have as well signed it - Flat Earth Society
Re: image processing in D
On 7 April 2011 17:55, Eric Poggel (JoeCoder) dnewsgro...@yage3d.netwrote: On 4/3/2011 6:35 PM, Emil Madsen wrote: This about image processing, got me thinking, hows the shader support for D currently? - Interfaceable though C? Because for image processing, thats def. the way to go, at least in my opinion, that is if you want acceptable processing speeds. And a more specific question; say one wants to blur a picture with Gaussian blur, how would D ranges deal with the 2d array? GL Shaders are perfectly usable via Derelict. I use them in Yage ( yage3d.net). Thats nice :) - I have to spend some time with it then :D -- // Yours sincerely // Emil 'Skeen' Madsen
Re: Jonas Drewsen has been accepted as a GSoC 2011 mentor for Digital Mars
On 08/04/2011 01:47, dsimcha wrote: On 4/7/2011 8:33 PM, Andrei Alexandrescu wrote: Jonas Drewsen has been accepted as a mentor for the Google Summer of Code 2011 program for Digital Mars. He is particularly interested in topics related to networking. Please join me in congratulating and wishing the best to Jonas. We have 18 student applications and only 6 mentors. Probably we won't be able to accept all student applications, but we could definitely use more mentors. Please apply: http://d-programming-language.org/gsoc2011.html Andrei I've finally decided at the last minute to apply as a mentor. I'm primarily but not exclusively interested in garbage collection. I'd also like working on parallelism and concurrency stuff if any students seemed interested in it. Good to hear that, welcome David and Jonas! -- Bruno Medeiros - Software Engineer
Re: GSoC Proposals: Level of Detail
On 8-apr-11, at 15:40, dsimcha wrote: I've been looking over some of the GSoC proposals and I've noticed that most aren't very detailed. It seems most of the students have only a very rough idea of what they want to do and plan on filling in the details at the beginning of the project. I don't have experience with GSoC and I'm trying to understand whether this is a problem or is what's expected. How detailed are the proposals supposed to be? I don't have experience with GSoC either, but I fear that the very simple I would like to work on X proposal will have to be discarded. As andrei said the students have to convince us that they can do the project, and this means: - good project - knowledge of the field - knowledge of the tools (D) - skills - motivation Obviously projects don't have to be perfect, this is *before* doing it, but just saying I would like to work on X is not going to cut it. Fawzi
Re: string and char[]
On Fri, 08 Apr 2011 09:40:32 -0400, Denis Koroskin 2kor...@gmail.com wrote: On Fri, 08 Apr 2011 17:13:19 +0400, Steven Schveighoffer schvei...@yahoo.com wrote: On Fri, 08 Apr 2011 06:44:42 -0400, Simen kjaeraas simen.kja...@gmail.com wrote: On Fri, 08 Apr 2011 12:46:08 +0200, Morlan h...@valentimex.com wrote: It is OK if I write int[char[]] asr; asr[hello] = 10; but the following does not compile: char[] car = hello; What is the explanation for this behaviour? The first should not be allowed. It is a mistake to use non-immutable keys for an associative array. int[char[]] asr; pragma(msg, typeof(asr).stringof); outputs: AssociativeArray!(const(char)[],int) So the compiler adds const to the keys, which is why it works. Do I think this is the correct behavior? Absolutely not. First, it prevents nothing as far as modifying keys (const accepts mutable keys as well as const and mutable ones). Second, I believe you should be able to use whatever key constancy you want. We should just say if you do the wrong thing, it's undefined. Maybe @safe code can only use immutable keys. Third, if it must be illegal to have an AA with mutable keys, it should be an error, not silently change to const. -Steve What about storing objects as keys? There is nothing wrong to modify those objects as long as their order stays the same. I agree with you. See my second point. But even if that isn't what the committee decides, the current behavior guarantees absolutely nothing. -Steve
Re: Is the world coming to an end?
On 2011-04-08 07:03:23 -0400, spir denis.s...@gmail.com said: On 04/08/2011 07:25 AM, Nick Sabalausky wrote: I want base PI literals :) Yum. I want base 1 literals Denis Like this? assert(0i == 0) assert(0i0 == 1) assert(0i00 == 2) assert(0i000 == 3) assert(0i00_00_00_00 == 32) -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Jonas Drewsen has been accepted as a GSoC 2011 mentor for Digital Mars
On 8-apr-11, at 15:01, dsimcha wrote: On 4/8/2011 4:37 AM, Jacob Carlborg wrote: On 2011-04-08 02:33, Andrei Alexandrescu wrote: Jonas Drewsen has been accepted as a mentor for the Google Summer of Code 2011 program for Digital Mars. He is particularly interested in topics related to networking. Please join me in congratulating and wishing the best to Jonas. We have 18 student applications and only 6 mentors. Probably we won't be able to accept all student applications, but we could definitely use more mentors. Please apply: http://d-programming-language.org/gsoc2011.html Andrei Do we need a 1:1 mapping between students and mentors? I though several students were interested in the same topics and perhaps could share a mentor. Possibly better question: Would we even accept multiple students for the same project? That is a good question, and I guess, excluding cases where effort has been done to reduce the overlap (containers), the answer will probably be no. Personally I will not have time to follow more than one student (I might help out or something, but I can commit to only one student. Fawzi
Re: GSoC Proposals: Level of Detail
I don't have experience with GSoC either, but I fear that the very simple I would like to work on X proposal will have to be discarded. As andrei said the students have to convince us that they can do the project, and this means: - good project - knowledge of the field - knowledge of the tools (D) - skills - motivation I was wondering, can a project report be too lengthy? O.o
Re: string and char[]
On Fri, 08 Apr 2011 17:40:32 +0400, Denis Koroskin wrote:
int compare(char[] lhs, char[] rhs) pure {
if (lhs rhs) return 1;
if (lhs rhs) return -1;
return 0;
}
is not.
For some reason (bug?), both compile with 2.052.
Purity has nothing to do with the type. Hello and a char[] storing
Hello will always produce the same results when passed to this
function. The fact that it can be changed to Byelo does not effect the
results for when Hello is passed in.
I agree that Objects make for great mutable keys, but how can you
guarantee the hash won't change when the contents change, toHash is
overridable after all.
Re: D Tools Special Interest Group (SIG)
On 01/04/2011 21:39, Jonas Drewsen wrote: On 01/04/11 20.53, Bruno Medeiros wrote: On 22/03/2011 23:41, Jonas Drewsen wrote: Hi, It seems that every now and then a discussion about build tools or D package management pops up in this group. Many people on this list have a huge amount of experience and knowledge in this area. Some has even created their own tools for D. Unfortunately this has not yet resulted in a standard set of tools somehow. This post is an attempt to collect all the know-how and put it in a central place. One goal is to use that for forming state-of-the-art tools for D possible. Another goal is for several people to join forces since many people means a higher chance of keeping the resulting tools maintained and improved regularly. This does not necessarily suggest that an entirely new tool must be developed from scratch. Maybe some of the existing ones are best used as the base. This will probably be the first thing to determine. I've create a wikipage that I welcome anyone interested in this area to add,modify and correct as they see fit. http://prowiki.org/wiki4d/wiki.cgi?ToolSIG Let's see if we can keep the ball rolling on this one :) /Jonas This is relevant to my inter... err.., I mean, I am interested in this issue. ^^ Ok, for starters, you should have called the wiki page (and this thread) D Build Tools, or D Package Management Tools, or something like that. Just D Tools is not accurately specific, there many other *kinds* of D tools. Yes, I am the eternal nitpicker. One of the better tools (DSSS) though not maintained actually falls into several of these catergories. Thats why it is just called D tools. But maybe it would be better splitting it into several pages. Please change the wiki page as you see fit :) Personally I think DSSS may be a good starting point. It would need to be revived and moved to D2. As for the issue itself, I mentioned some thoughts on this on the previous thread that Andrei mentioned: http://www.digitalmars.com/d/archives/digitalmars/D/More_on_the_necessity_and_difficulty_of_a_package_management_system_127873.html#N128815 Nice points. Please fell free to add it to the wiki page - just to have a central place to refer to. /Jonas DSSS may fall in both categories (Build, and Package Management), but not any other. I would add those comments to the wiki, but only if we rename the title, am I free to do that?... :P But in any case, I don't think it matters much, to try to proceed with this discussion, unless someone is actually planning to work on this. ~_~ AFAIK no one is planning to work on such build tools. -- Bruno Medeiros - Software Engineer
Re: DWT2
On 4/8/11, Bruno Medeiros brunodomedeiros+spam@com.gmail wrote: On 05/04/2011 04:54, Andrej Mitrovic wrote: You have to be kidding me. Who writes code like this? http://i.imgur.com/BBQde.png What's wrong with it? Do you mean the anonymous classes with all the fields and contructors for passing the variables in the enclosing scope? -- Bruno Medeiros - Software Engineer I don't understand the need to create huge anonymous classes. If you're going to create or override so many methods, you might as well create a new class instead of embedding one in the call. Maybe that's a standard way of doing it in Java, but I'd never code like this. Maybe it's because I don't depend on an IDE, and like to keep my code clean. I'm not a fan of deeply nested code.
Re: DWT2
On Fri, 08 Apr 2011 10:36:39 -0400, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 4/8/11, Bruno Medeiros brunodomedeiros+spam@com.gmail wrote: On 05/04/2011 04:54, Andrej Mitrovic wrote: You have to be kidding me. Who writes code like this? http://i.imgur.com/BBQde.png What's wrong with it? Do you mean the anonymous classes with all the fields and contructors for passing the variables in the enclosing scope? -- Bruno Medeiros - Software Engineer I don't understand the need to create huge anonymous classes. If you're going to create or override so many methods, you might as well create a new class instead of embedding one in the call. Maybe that's a standard way of doing it in Java, but I'd never code like this. Maybe it's because I don't depend on an IDE, and like to keep my code clean. I'm not a fan of deeply nested code. I think the reason it looks like this is because Java does not have delegates. Anonymous delegates are much easier to read, and also do not take up heap space. If anything, I'd say a very worthwhile project would be to change all the callback interfaces and anonymous classes to delegates. -Steve
dmd2-2.052 is only for i386, while you are running amd64 (or dmd2 on FreeBSD)
Hello, I'm running Free/PC-BSD desktop now, and here is dmd-2 experience: [gour@atmarama] /home/gour# cd /usr/ports/lang/dmd2/ [gour@atmarama] /usr/ports/lang/dmd2# make install clean === dmd2-2.052 is only for i386, while you are running amd64. *** Error code 1 Stop in /usr/ports/lang/dmd2. Can we expect that something will change in regard to 64bit support on FreeBSD soon or it's safer to look for alternatives (gdc, ldc)? Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Core.atomic: Fencing?
Are all atomic functions in core.atomic going to be guaranteed to act as full memory barriers when it's ported to non-x86 architectures? std.parallelism assumes that atomic instructions act as full barriers. This is correct on x86/x86, since loads and stores cannot be reordered with locked instructions, and everything in the x86/x64 implementation of core.atomic uses the lock prefix. Are similar guarantees going to be made on other architectures?
Re: A few thoughts on the existing GSoC student proposals
On 04/04/2011 19:57, Andrei Alexandrescu wrote: On 4/4/11 1:19 PM, Bruno Medeiros wrote: On 04/04/2011 19:04, Andrei Alexandrescu wrote: On 4/4/11 12:53 PM, Bruno Medeiros wrote: BTW Andrei, do you any idea or estimation of how many proposal slots Digital Mars might get from GSoC? We have eight student applications so far. Andrei I know that, I can see it in my Google-Melange dashboard... :p I meant the number of student slots that Google will allocate to each organization (and yes, the exact number is not know in advance, even for Google). I don't know. Andrei I've now come across this link: http://socghop.appspot.com/document/show/site/site/studentallocations which explains the process in a bit more detail. Let's see how it goes then, and hopefully we'll get enough allocation for all the quality proposals we have received. -- Bruno Medeiros - Software Engineer
Re: Jonas Drewsen has been accepted as a GSoC 2011 mentor for Digital Mars
On 4/8/11 3:37 AM, Jacob Carlborg wrote: On 2011-04-08 02:33, Andrei Alexandrescu wrote: Jonas Drewsen has been accepted as a mentor for the Google Summer of Code 2011 program for Digital Mars. He is particularly interested in topics related to networking. Please join me in congratulating and wishing the best to Jonas. We have 18 student applications and only 6 mentors. Probably we won't be able to accept all student applications, but we could definitely use more mentors. Please apply: http://d-programming-language.org/gsoc2011.html Andrei Do we need a 1:1 mapping between students and mentors? I though several students were interested in the same topics and perhaps could share a mentor. I just asked for clarification. Andrei
Re: GSoC Proposals: Level of Detail
On 4/8/11 8:40 AM, dsimcha wrote: I've been looking over some of the GSoC proposals and I've noticed that most aren't very detailed. It seems most of the students have only a very rough idea of what they want to do and plan on filling in the details at the beginning of the project. I don't have experience with GSoC and I'm trying to understand whether this is a problem or is what's expected. How detailed are the proposals supposed to be? I emailed all student proposing a project the following. After the email we got a lot of updates. Andrei Hello, Apologies for the semi-automated email. You should know that the deadline is only a few hours away - on the 8th April at 19:00 UTC. Be careful! That may mean a different time at your location. Refer to this link: http://www.timeanddate.com/worldclock/fixedtime.html?month=4day=8year=2011hour=19min=0sec=0p1=0 You should expect an interview during the application review period. There is no need for special preparation. The interview consists of a few simple questions and a couple of coding exercises. You should have an Internet connection handy; the interview uses www.collabedit.com for writing code. Phone is fine, Skype is preferable. Below are a few tips regarding last-minute polishing of your application. * Make sure you send our way a detailed overview of the project you are embarking on. A good overview should clarify that you have a good understanding of the problem domain and that you are capable of carrying the task through. * Please mention your fluency in the D programming language. * Specify a plan for your project, with deadlines and deliverables. Make sure it is something that you can realistically commit to. * Mention how much time you realistically expect to spend on the project. If you plan to take a vacation or otherwise be unavailable for some time, please specify. * Needless to say, it is in your best interest to be honest. * Mention in brief, if you can, alternative topics/projects you might be working on. We have had quite a few overlapping applications - there are five proposals for containers, for example. We wouldn't want to let you compete and then choose the best implementation, so we will allow only 1-2 applications on containers. In case you are interested in containers, how comfortable are you with advanced containers - Bloom filters, tries, generalized suffix trees, skip lists...? * At the same time, don't spread yourself too thin. A too broad application loses focus and enthusiasm for any one specific topic. * Include anything that you believe is relevant to the project(s) of your choice: courses completed, grades, references, experience on similar projects. Feel free to paste your resume. Don't forget we start with knowing nothing about you. * Above all, be honest about everything. This program is at Google's considerable expense, not to mention the time your mentors will invest. Above everything, the best outcome of this for you is establishing an excellent reputation with everybody involved. Good luck! Andrei
Re: UCFS, Reflection/Metadata, Overload Resolution, Templates, and other issues
I've added reflection capabilities to an update to std.variant I'm working on. Overloads work. General functions work. (Although a few bugs with opCall and opDispatch prevents the ideal syntax: var.x(5) vs var.x = 5 and var.call(5) vs var(5), but I assume those will be eventually fixed). I've also added an internal type database, so you can auto-magically build a Variant(TypeInfo, void*) or Variant(Object) and then call methods on the real, underlying type. Whoa nice. I'm eagerly waiting to see it. :) Templates, I think, will out of the range of dynamic D capabilities for some time to come. Yeah, 'cause I just realized they basically need you to implement the entire compiler.
Re: Jonas Drewsen has been accepted as a GSoC 2011 mentor for Digital Mars
On 08/04/2011 09:37, Jacob Carlborg wrote: On 2011-04-08 02:33, Andrei Alexandrescu wrote: Jonas Drewsen has been accepted as a mentor for the Google Summer of Code 2011 program for Digital Mars. He is particularly interested in topics related to networking. Please join me in congratulating and wishing the best to Jonas. We have 18 student applications and only 6 mentors. Probably we won't be able to accept all student applications, but we could definitely use more mentors. Please apply: http://d-programming-language.org/gsoc2011.html Andrei Do we need a 1:1 mapping between students and mentors? I though several students were interested in the same topics and perhaps could share a mentor. Technically it is allowed, but the GSoC info says that it is not recommended, because of the time expenditure involved. They say that even for one student mentors often underestimate the amount of time necessary to provide good support. So I guess it would be up to the mentor, if he really feels up to it. -- Bruno Medeiros - Software Engineer
Re: Jonas Drewsen has been accepted as a GSoC 2011 mentor for Digital Mars
On 4/8/11 10:33 AM, Bruno Medeiros wrote: On 08/04/2011 09:37, Jacob Carlborg wrote: On 2011-04-08 02:33, Andrei Alexandrescu wrote: Jonas Drewsen has been accepted as a mentor for the Google Summer of Code 2011 program for Digital Mars. He is particularly interested in topics related to networking. Please join me in congratulating and wishing the best to Jonas. We have 18 student applications and only 6 mentors. Probably we won't be able to accept all student applications, but we could definitely use more mentors. Please apply: http://d-programming-language.org/gsoc2011.html Andrei Do we need a 1:1 mapping between students and mentors? I though several students were interested in the same topics and perhaps could share a mentor. Technically it is allowed, but the GSoC info says that it is not recommended, because of the time expenditure involved. They say that even for one student mentors often underestimate the amount of time necessary to provide good support. So I guess it would be up to the mentor, if he really feels up to it. Yah. That means that the number of approved projects is limited by min(students, mentors). We have 7 mentors for over student 20 applications. Experienced members of the community - please consider applying for mentorship. This is the time to act, and the best answer to the FAQ What can I do for D? On the other hand, please don't take this lightly as mentoring is a solid commitment that takes real work. Thanks, Andrei
Re: GSoC Proposals: Level of Detail
On 8-apr-11, at 17:15, Andrei Alexandrescu wrote: On 4/8/11 8:40 AM, dsimcha wrote: I've been looking over some of the GSoC proposals and I've noticed that most aren't very detailed. It seems most of the students have only a very rough idea of what they want to do and plan on filling in the details at the beginning of the project. I don't have experience with GSoC and I'm trying to understand whether this is a problem or is what's expected. How detailed are the proposals supposed to be? I emailed all student proposing a project the following. After the email we got a lot of updates. Andrei Hello, Apologies for the semi-automated email. You should know that the deadline is only a few hours away - on the 8th April at 19:00 UTC. Be careful! That may mean a different time at your location. Refer to this link: http://www.timeanddate.com/worldclock/fixedtime.html?month=4day=8year=2011hour=19min=0sec=0p1=0 You should expect an interview during the application review period. There is no need for special preparation. The interview consists of a few simple questions and a couple of coding exercises. You should have an Internet connection handy; the interview uses www.collabedit.com for writing code. Phone is fine, Skype is preferable. Below are a few tips regarding last-minute polishing of your application. * Make sure you send our way a detailed overview of the project you are embarking on. A good overview should clarify that you have a good understanding of the problem domain and that you are capable of carrying the task through. * Please mention your fluency in the D programming language. * Specify a plan for your project, with deadlines and deliverables. Make sure it is something that you can realistically commit to. * Mention how much time you realistically expect to spend on the project. If you plan to take a vacation or otherwise be unavailable for some time, please specify. * Needless to say, it is in your best interest to be honest. * Mention in brief, if you can, alternative topics/projects you might be working on. We have had quite a few overlapping applications - there are five proposals for containers, for example. We wouldn't want to let you compete and then choose the best implementation, so we will allow only 1-2 applications on containers. In case you are interested in containers, how comfortable are you with advanced containers - Bloom filters, tries, generalized suffix trees, skip lists...? * At the same time, don't spread yourself too thin. A too broad application loses focus and enthusiasm for any one specific topic. * Include anything that you believe is relevant to the project(s) of your choice: courses completed, grades, references, experience on similar projects. Feel free to paste your resume. Don't forget we start with knowing nothing about you. * Above all, be honest about everything. This program is at Google's considerable expense, not to mention the time your mentors will invest. Above everything, the best outcome of this for you is establishing an excellent reputation with everybody involved. Good luck! Andrei Excellent, I was thinking that an interview would be the best thing to evaluate the candidates. Fawzi
Re: GSoC Proposals: Level of Detail
Who is going to interview the students? Will the mentor interested in the student be the interviewer or a selected group of the community? Luca On 4/8/11, Fawzi Mohamed fa...@gmx.ch wrote: On 8-apr-11, at 17:15, Andrei Alexandrescu wrote: On 4/8/11 8:40 AM, dsimcha wrote: I've been looking over some of the GSoC proposals and I've noticed that most aren't very detailed. It seems most of the students have only a very rough idea of what they want to do and plan on filling in the details at the beginning of the project. I don't have experience with GSoC and I'm trying to understand whether this is a problem or is what's expected. How detailed are the proposals supposed to be? I emailed all student proposing a project the following. After the email we got a lot of updates. Andrei Hello, Apologies for the semi-automated email. You should know that the deadline is only a few hours away - on the 8th April at 19:00 UTC. Be careful! That may mean a different time at your location. Refer to this link: http://www.timeanddate.com/worldclock/fixedtime.html?month=4day=8year=2011hour=19min=0sec=0p1=0 You should expect an interview during the application review period. There is no need for special preparation. The interview consists of a few simple questions and a couple of coding exercises. You should have an Internet connection handy; the interview uses www.collabedit.com for writing code. Phone is fine, Skype is preferable. Below are a few tips regarding last-minute polishing of your application. * Make sure you send our way a detailed overview of the project you are embarking on. A good overview should clarify that you have a good understanding of the problem domain and that you are capable of carrying the task through. * Please mention your fluency in the D programming language. * Specify a plan for your project, with deadlines and deliverables. Make sure it is something that you can realistically commit to. * Mention how much time you realistically expect to spend on the project. If you plan to take a vacation or otherwise be unavailable for some time, please specify. * Needless to say, it is in your best interest to be honest. * Mention in brief, if you can, alternative topics/projects you might be working on. We have had quite a few overlapping applications - there are five proposals for containers, for example. We wouldn't want to let you compete and then choose the best implementation, so we will allow only 1-2 applications on containers. In case you are interested in containers, how comfortable are you with advanced containers - Bloom filters, tries, generalized suffix trees, skip lists...? * At the same time, don't spread yourself too thin. A too broad application loses focus and enthusiasm for any one specific topic. * Include anything that you believe is relevant to the project(s) of your choice: courses completed, grades, references, experience on similar projects. Feel free to paste your resume. Don't forget we start with knowing nothing about you. * Above all, be honest about everything. This program is at Google's considerable expense, not to mention the time your mentors will invest. Above everything, the best outcome of this for you is establishing an excellent reputation with everybody involved. Good luck! Andrei Excellent, I was thinking that an interview would be the best thing to evaluate the candidates. Fawzi
Re: Core.atomic: Fencing?
On Apr 8, 2011, at 8:07 AM, dsimcha wrote: Are all atomic functions in core.atomic going to be guaranteed to act as full memory barriers when it's ported to non-x86 architectures? std.parallelism assumes that atomic instructions act as full barriers. This is correct on x86/x86, since loads and stores cannot be reordered with locked instructions, and everything in the x86/x64 implementation of core.atomic uses the lock prefix. Are similar guarantees going to be made on other architectures? Yes. The default behavior of core.atomic will be to produce no unexpected results. I may expose some routines that allow the user to explicitly request weaker guarantees if available, but this shouldn't impact anyone calling core.atomic routines without the additional parameter.
Linux RPM out of date
I've been waiting patiently for the Linux RPM to be updated (it's currently 2.051). Do I need to continue to wait, or should I volunteer some time to help maintain the RPM packaging? I would be happy to help develop and maintain a DEB package as well. -Kai Meyer
Re: GSoC Proposals: Level of Detail
On 4/8/11 11:35 AM, Luca Boasso wrote: Who is going to interview the students? Will the mentor interested in the student be the interviewer or a selected group of the community? I plan to interview qualified candidates personally. An interested mentor could choose to hold the interview in addition or instead of me. Andrei
Re: GSoC Proposals: Level of Detail
Thank you for the information Luca On 4/8/11, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 4/8/11 11:35 AM, Luca Boasso wrote: Who is going to interview the students? Will the mentor interested in the student be the interviewer or a selected group of the community? I plan to interview qualified candidates personally. An interested mentor could choose to hold the interview in addition or instead of me. Andrei
Re: Is the world coming to an end?
On 04/08/2011 03:55 PM, Michel Fortin wrote: On 2011-04-08 07:03:23 -0400, spir denis.s...@gmail.com said: On 04/08/2011 07:25 AM, Nick Sabalausky wrote: I want base PI literals :) Yum. I want base 1 literals Denis Like this? assert(0i == 0) assert(0i0 == 1) assert(0i00 == 2) assert(0i000 == 3) assert(0i00_00_00_00 == 32) Yop! You just reinvented the definition of natural numbers via set theory ;-) Denis -- _ vita es estrany spir.wikidot.com
Re: string and char[]
On 04/08/2011 03:13 PM, Steven Schveighoffer wrote: On Fri, 08 Apr 2011 06:44:42 -0400, Simen kjaeraas simen.kja...@gmail.com wrote: On Fri, 08 Apr 2011 12:46:08 +0200, Morlan h...@valentimex.com wrote: It is OK if I write int[char[]] asr; asr[hello] = 10; but the following does not compile: char[] car = hello; What is the explanation for this behaviour? The first should not be allowed. It is a mistake to use non-immutable keys for an associative array. int[char[]] asr; pragma(msg, typeof(asr).stringof); outputs: AssociativeArray!(const(char)[],int) So the compiler adds const to the keys, which is why it works. Do I think this is the correct behavior? Absolutely not. First, it prevents nothing as far as modifying keys (const accepts mutable keys as well as const and mutable ones). Second, I believe you should be able to use whatever key constancy you want. We should just say if you do the wrong thing, it's undefined. Maybe @safe code can only use immutable keys. Third, if it must be illegal to have an AA with mutable keys, it should be an error, not silently change to const. I agree on points 1 3. Second looks dangerous to me. Denis -- _ vita es estrany spir.wikidot.com
Re: string and char[]
On 04/08/2011 03:40 PM, Denis Koroskin wrote: What about storing objects as keys? There is nothing wrong to modify those objects as long as their order stays the same. I think if referenced objects are to be used as keys, they should be compared by pointer/identity (hash would return their address?). Then, it's up to the programmer to be coherent. After all, that is the sense of reference isn't it? Denis -- _ vita es estrany spir.wikidot.com
Re: Core.atomic: Fencing?
== Quote from Sean Kelly (s...@invisibleduck.org)'s article On Apr 8, 2011, at 8:07 AM, dsimcha wrote: Are all atomic functions in core.atomic going to be guaranteed to act as full memory barriers when it's ported to non-x86 architectures? std.parallelism assumes that atomic instructions act as full barriers. This is correct on x86/x86, since loads and stores cannot be reordered with locked instructions, and everything in the x86/x64 implementation of core.atomic uses the lock prefix. Are similar guarantees going to be made on other architectures? Yes. The default behavior of core.atomic will be to produce no unexpected results. I may expose some routines that allow the user to explicitly request weaker guarantees if available, but this shouldn't impact anyone calling core.atomic routines without the additional parameter. On top of that, GCC targets will (*WIP*) be using builtin atomic load/cas routines for architectures that support. And I'm pretty certain LDC does the same (I believe it's implemented in Tango). Regards
Re: Core.atomic: Fencing?
== Quote from Iain Buclaw (ibuc...@ubuntu.com)'s article On top of that, GCC targets will (*WIP*) be using builtin atomic load/cas routines for architectures that support. And I'm pretty certain LDC does the same (I believe it's implemented in Tango). Regards I assume the implication is that the GCC builtin atomics act as full barriers on all architectures?
Re: string and char[]
On Fri, 08 Apr 2011 14:57:52 -0400, spir denis.s...@gmail.com wrote: On 04/08/2011 03:13 PM, Steven Schveighoffer wrote: On Fri, 08 Apr 2011 06:44:42 -0400, Simen kjaeraas simen.kja...@gmail.com wrote: On Fri, 08 Apr 2011 12:46:08 +0200, Morlan h...@valentimex.com wrote: It is OK if I write int[char[]] asr; asr[hello] = 10; but the following does not compile: char[] car = hello; What is the explanation for this behaviour? The first should not be allowed. It is a mistake to use non-immutable keys for an associative array. int[char[]] asr; pragma(msg, typeof(asr).stringof); outputs: AssociativeArray!(const(char)[],int) So the compiler adds const to the keys, which is why it works. Do I think this is the correct behavior? Absolutely not. First, it prevents nothing as far as modifying keys (const accepts mutable keys as well as const and mutable ones). Second, I believe you should be able to use whatever key constancy you want. We should just say if you do the wrong thing, it's undefined. Maybe @safe code can only use immutable keys. Third, if it must be illegal to have an AA with mutable keys, it should be an error, not silently change to const. I agree on points 1 3. Second looks dangerous to me. Dangerous, yes. But immutable objects are typically not easy to deal with. For one, you can't have tail-immutable objects (currently), so implementation of such a container is going to be a pain. In fact, dcollections simply doesn't work if you have fully immutable types as keys. In reality, most times you are not using something as a key and somewhere else simultaneously. So while theoretically dangerous, it's easy to write code that isn't dangerous. -Steve
Re: [OT] Re: GUI library for D
Bruno Medeiros brunodomedeiros+spam@com.gmail wrote in message news:inn2rl$2hp$2...@digitalmars.com... On 07/04/2011 21:21, Nick Sabalausky wrote: Heh :) Damn Borg kids... I think I'm basically turning into Cranky Kong (if you've ever played Donkey Kong Country): They can't keep this level of graphics up for much longer! We used to be lucky if we only got three shades of grey, let alone any real colors! Look!...look at this!...as I rock, my beard swings! Waste of frames in my opinion! Are those actual quotes from the game? If so, hehe, pretty funny. :) According to a Wiki I found, yea. I don't entirely remember though, it's been awhile. But he definitely says some things along those general lines. All while rocking in his chair and swinging his cane at you.
Re: Is the world coming to an end?
Michel Fortin michel.for...@michelf.com wrote in message news:inn4bp$57s$1...@digitalmars.com... On 2011-04-08 07:03:23 -0400, spir denis.s...@gmail.com said: On 04/08/2011 07:25 AM, Nick Sabalausky wrote: I want base PI literals :) Yum. I want base 1 literals Denis Like this? assert(0i == 0) assert(0i0 == 1) assert(0i00 == 2) assert(0i000 == 3) assert(0i00_00_00_00 == 32) Pardon my geekdom, but it would probably have to be: assert(0i == 0) assert(0i1 == 1) assert(0i11 == 2) assert(0i111 == 3) assert(0i11_11_11_11 == 32) In general, number bases work like this: Assuming i=0 is the right-most digit: (digits.length (SIGMA) i=0) digit[i] * (base^^i) Or in less mathy notation: uint[] digits = [...blah...]; // digits[0] is the right-most digit auto finalValue = 0; foreach(i; 0..digits.length) finalValue += digits[i] * (base^^i); So using 0 as the only digit in base 1 would result in all numbers being equal to 0. But using 1 as the only digit would work.
Re: string and char[]
On 04/08/2011 09:20 PM, Steven Schveighoffer wrote:
On Fri, 08 Apr 2011 14:57:52 -0400, spir denis.s...@gmail.com wrote:
On 04/08/2011 03:13 PM, Steven Schveighoffer wrote:
On Fri, 08 Apr 2011 06:44:42 -0400, Simen kjaeraas simen.kja...@gmail.com
wrote:
On Fri, 08 Apr 2011 12:46:08 +0200, Morlan h...@valentimex.com wrote:
It is OK if I write
int[char[]] asr;
asr[hello] = 10;
but the following does not compile:
char[] car = hello;
What is the explanation for this behaviour?
The first should not be allowed. It is a mistake to use non-immutable
keys for an associative array.
int[char[]] asr;
pragma(msg, typeof(asr).stringof);
outputs:
AssociativeArray!(const(char)[],int)
So the compiler adds const to the keys, which is why it works.
Do I think this is the correct behavior? Absolutely not. First, it prevents
nothing as far as modifying keys (const accepts mutable keys as well as const
and mutable ones). Second, I believe you should be able to use whatever key
constancy you want. We should just say if you do the wrong thing, it's
undefined. Maybe @safe code can only use immutable keys. Third, if it must be
illegal to have an AA with mutable keys, it should be an error, not silently
change to const.
I agree on points 1 3. Second looks dangerous to me.
Dangerous, yes. But immutable objects are typically not easy to deal with. For
one, you can't have tail-immutable objects (currently), so implementation of
such a container is going to be a pain. In fact, dcollections simply doesn't
work if you have fully immutable types as keys.
In reality, most times you are not using something as a key and somewhere else
simultaneously. So while theoretically dangerous, it's easy to write code that
isn't dangerous.
What about ref'ed objects used as keys be compared (at least as keys) by ref --
and only by ref.
This is how Lua tables work (and the reason why they're so fast):
a = {1,1} ; b = {2,2}
t = {[a]=1 , [b]=2}
print (t[a], t[{1,1}]) -- 1 nil
a and the second {1,1} key are distinct objects. This is not often what we
mean, in the general case. Composite objects actually often are, conceptually,
*values*, like a position or color; thus, should be compared by value.
But they sometimes represent unique entities, like a game character, which
should be compared (as keys and everywhere else) by unicity -- and only that
way. Comparing their state simply makes no sense.
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Is the world coming to an end?
On 04/08/2011 10:01 PM, Nick Sabalausky wrote: Michel Fortinmichel.for...@michelf.com wrote in message news:inn4bp$57s$1...@digitalmars.com... On 2011-04-08 07:03:23 -0400, spirdenis.s...@gmail.com said: On 04/08/2011 07:25 AM, Nick Sabalausky wrote: I want base PI literals :) Yum. I want base 1 literals Denis Like this? assert(0i == 0) assert(0i0 == 1) assert(0i00 == 2) assert(0i000 == 3) assert(0i00_00_00_00 == 32) Pardon my geekdom, but it would probably have to be: assert(0i == 0) assert(0i1 == 1) assert(0i11 == 2) assert(0i111 == 3) assert(0i11_11_11_11 == 32) In general, number bases work like this: Assuming i=0 is the right-most digit: (digits.length (SIGMA) i=0) digit[i] * (base^^i) Or in less mathy notation: uint[] digits = [...blah...]; // digits[0] is the right-most digit auto finalValue = 0; foreach(i; 0..digits.length) finalValue += digits[i] * (base^^i); So using 0 as the only digit in base 1 would result in all numbers being equal to 0. But using 1 as the only digit would work. True, for using the same algorithm to compute the numeric value. But you're missing the point in base 1 there cannot be '1' digits, as per definition ;-) If I correctly understand Michel's meaning, he just provided a notation mapping natural numbers to sets (actually sequences): Number n maps to n whatever-symbol. Could have been: assert(0i$$$ == 3); but since '0's are available in base 1... Denis -- _ vita es estrany spir.wikidot.com
simple display (from: GUI library for D)
We discussed this first in the GUI library thread, but since it
meandered so much, I decided to split off into a new subject. Much
of what I say here will be old to anyone who saw the previous thread.
There's some new stuff nearer to the bottom though.
I, with input from others, have started writing a little module
for simple uses of a display. You can write to a bitmap, display it
to a window, and handle events all in an easy way. The basics are
cross platform, but you can use native function calls too.
http://arsdnet.net/dcode/simpledisplay.d
It's still very much in progress, but I think it's now at the point
where the direction I'm taking it is clear.
First, the simplest usage:
import simpledisplay;
void main() {
auto image = new Image(255, 255);
foreach(a; 0..255)
foreach(b; 0..255)
image.putPixel(a, b, Color(a, b, ((a + b) % 16) * 16));
image.display();
}
===
Compile: dmd test.d simpledisplay.d
When run, it will pop up a window with a gradient thing with little
bars through it. Press any key and the window closes, exiting the
program.
On Windows, it uses GDI functions. On other systems, it tries to
use X Windows. Linux is the only one I've personally tested, but it
should work on OSX and FreeBSD too (without changing the code).
If you are making some data, then just want to display it, this
works. But, what if you want some interactivity?
Here's a simple HSL color picker:
http://arsdnet.net/dcode/simpledisplay_test2.d
Use these keys to pick your color: q/a change hue. s/w changes S.
e/d changes L. Press ESC to exit. Your color in rgb is printed to
stdout.
Here's the relevant parts of the code:
void main() {
auto image = new Image(255, 255);
auto win = new SimpleWindow(image);
win.eventLoop(0,
(dchar c) {
writeln(Got a char event: , c);
if(c == 'q')
h += 15;
// ...snip...
foreach(a; 0..255)
foreach(b; 0..255)
image.putPixel(a, b, fromHsl(h, s, l));
win.image = image;
},
(int key) {
writeln(Got a keydown event: , key);
if(key == KEY_ESCAPE) {
auto color = fromHsl(h, s, l);
writefln(%02x%02x%02x, color.r, color.g,
color.b);
win.close();
}
});
}
First, we create an image. Then, a window based on that image. At
line two, your window will show up on the screen, just like
image.display() did above. But, here, instead of blocking, it
moves on to a user specified event loop.
SimpleWindow.eventLoop was inspired by std.concurrency.receive.
The first parameter is a pulse timer amount (not yet implemented).
If you set one, you'll get one of your delegates called at the
requested interval. The idea there is to make animations or games
easy to get started.
After that comes a list of delegates. They are matched to different
events by their signature. (dchar c) {} means a key was pressed,
and it passes you the character corresponding to that key.
(int c) {} is almost certain to change, but right now it matches
to key press events, and passes the platform-specific keycode. I'm
planning to put symbolic constants in with the same name across
platform to make that easier to use, but the values themselves are
likely to be platform-specific.
When we get a key event here, the image is redrawn with a new
color. win.image = image tells it you want the image redrawn with
the new image. It's a blunt instrument, but a simple and fairly
effective one.
The advantage of this approach is you can just have fun with
those pixels and handle keys, all right there inside main() - no
need to do subclasses just for a simple program. At the same time,
you can move those event handlers around easily enough, or even
change them at runtime, simply by using named delegates and assignment.
I plan to add more event possibilities so you can actually
make this do some good work for you. Ultimately, they'll also
be an (XEvent) {} and (HWND, LPARAM, WPARAM) event for when what
I provide isn't good enough, so you can always build more off it.
It's meant to be simple, but not horribly limiting.
==
Since last time I posted, I've reorganized the code inside
simpledisplay.d quite a bit. Instead of version Windows vs version
linux, it's now Windows and X11, reflecting the fact that X is
available on many operating systems. (Including Windows, actually,
but meh).
The Color struct is now rgba, but it doesn't use a. I like the
suggestion to template on different color spaces, but haven't gotten
around to that yet.
Next, Image and SimpleWindow are done pretty differently than before.
Now, the platform specific
Re: string and char[]
On Fri, 08 Apr 2011 16:12:27 -0400, spir denis.s...@gmail.com wrote:
On 04/08/2011 09:20 PM, Steven Schveighoffer wrote:
In reality, most times you are not using something as a key and
somewhere else
simultaneously. So while theoretically dangerous, it's easy to write
code that
isn't dangerous.
What about ref'ed objects used as keys be compared (at least as keys) by
ref -- and only by ref.
This is how Lua tables work (and the reason why they're so fast):
a = {1,1} ; b = {2,2}
t = {[a]=1 , [b]=2}
print (t[a], t[{1,1}]) -- 1 nil
a and the second {1,1} key are distinct objects. This is not often what
we mean, in the general case. Composite objects actually often are,
conceptually, *values*, like a position or color; thus, should be
compared by value.
But they sometimes represent unique entities, like a game character,
which should be compared (as keys and everywhere else) by unicity --
and only that way. Comparing their state simply makes no sense.
I believe objects are compared that way by default. But you may want to
compare them based on their values.
For example, a container may want to compare equal to another container if
it has all of the same elements, regardless of whether they are the same
exact instance.
In any case, allowing non-immutable keys in the case where it's just the
references being compared is a good use case.
-Steve
Re: Core.atomic: Fencing?
== Quote from dsimcha (dsim...@yahoo.com)'s article == Quote from Iain Buclaw (ibuc...@ubuntu.com)'s article On top of that, GCC targets will (*WIP*) be using builtin atomic load/cas routines for architectures that support. And I'm pretty certain LDC does the same (I believe it's implemented in Tango). Regards I assume the implication is that the GCC builtin atomics act as full barriers on all architectures? All sync builtins are described as full barriers. Non-traditional locks are acquire or release barriers.
Re: simple display (from: GUI library for D)
Adam D. Ruppe:
I, with input from others, have started writing a little module
for simple uses of a display. You can write to a bitmap, display it
to a window, and handle events all in an easy way. The basics are
cross platform, but you can use native function calls too.
I'd like something like this in Phobos, or if this is not possible, a
cabal-install-like command away. I sometimes use Python PyGame or Processing.
import simpledisplay;
void main() {
auto image = new Image(255, 255);
foreach(a; 0..255)
foreach(b; 0..255)
image.putPixel(a, b, Color(a, b, ((a + b) % 16) * 16));
image.display();
}
Instead of:
image.putPixel(a, b, Color(a, b, ((a + b) % 16) * 16));
I suggest something simpler like:
image[a, b] = std.typecons.tuple(a, b, ((a + b) % 16) * 16);
Instead of:
image.display();
I suggest something like this, to swap the two image buffers:
image.flip();
Plus maybe some image.event(); reader with callbacks...
Bye,
bearophile
Re: simple display (from: GUI library for D)
simpledisplay.d - line 267: int lol, wtf; lol, wtf? :p Btw, an exception will be thrown on unhandled key events, e.g. just hit CTRL: object.Exception@.\simpledisplay.d(299): GetMessage failed Not a good thing if you use shortcut keys to move windows around.
Re: simple display (from: GUI library for D)
== Quote from Adam D. Ruppe (destructiona...@gmail.com)'s article We discussed this first in the GUI library thread, but since it meandered so much, I decided to split off into a new subject. Much of what I say here will be old to anyone who saw the previous thread. There's some new stuff nearer to the bottom though. I, with input from others, have started writing a little module for simple uses of a display. You can write to a bitmap, display it to a window, and handle events all in an easy way. The basics are cross platform, but you can use native function calls too. http://arsdnet.net/dcode/simpledisplay.d It's still very much in progress, but I think it's now at the point where the direction I'm taking it is clear. Can it render text? If so, I'll probably port Plot2kill to it if it becomes part of Phobos at some point. It would be kind of cool to have minimal Plot2kill functionality with zero third-party dependencies. If it's so basic that it can't even do text rendering, then I have my doubts about whether there are very many use cases for something so simple.
Re: Linux RPM out of date
please do
Re: GSoC XML library proposal
Andrei Alexandrescu napisał: We have an XML library proposal. I know Tomek Sowinski was working on such. What is the status? The writer is close to being ready to be discussed, I've been working on the documentation lately. As for the parser, I got a pretty much good idea how to go about it but the code is pretty much in the woods. At work I've changed teams which entails lots of reading to get myself up to pace in the new area, travelling to an office abroad, and working till late with code I don't know yet. Now, that's not an excuse, just an honest answer to what's taking so long. I'm still willing to pull this module through. The work frenzy is clearing out and most probably I'll have the time to do some solid work this month and on. Does Tomek or someone else want to apply as a mentor for this project? Perhaps let's do it this way: I'll finish the writer, get it through community scrutiny myself, out of GSoC. The GSoC contribution to std.xml will be limited in scope to parsing. I will serve as a light bulb with all I read up so far on the topic, the lessons learned from my tries, and several years of experience with D. This way the density of reviews as well as the odds of bringing the module home will be higher. If that sounds good, let me know how to apply as a mentor. -- Tomek
Re: Linux RPM out of date
Kai Meyer Wrote: I've been waiting patiently for the Linux RPM to be updated (it's currently 2.051). Do I need to continue to wait, or should I volunteer some time to help maintain the RPM packaging? I would be happy to help develop and maintain a DEB package as well. -Kai Meyer Well on the DEB side of things: http://www.dsource.org/projects/ddebber/ will make a package. Walter also has a bash script.
Re: GSoC Proposals: Level of Detail
On 4/8/2011 2:43 PM, Andrei Alexandrescu wrote: On 4/8/11 11:35 AM, Luca Boasso wrote: Who is going to interview the students? Will the mentor interested in the student be the interviewer or a selected group of the community? I plan to interview qualified candidates personally. An interested mentor could choose to hold the interview in addition or instead of me. Andrei Looks like we got a ton of proposals at the last minute, so we'll probably need to be selective. A few questions: 1. Are you still seriously going to interview every candidate personally? 2. What, if anything, is Google's role in deciding what proposals get accepted? 3. Is there any point in the mentors reviewing the proposals before we know what makes the interview cut? 4. Is each mentor supposed to review all of the proposals, or just the ones in his/her domain that he/she feels qualified to evaluate? For example, I feel very comfortable reviewing a proposal about garbage collection or containers, but I would have little clue what I was doing if I reviewed an XML proposal. I'd be able to tell a mediocre XML proposal from a terrible one, but not a great one from a mediocre one.
Re: simple display (from: GUI library for D)
bearophile wrote: I'd like something like this in Phobos Me too. It's still pretty far from good enough right now, but that's where I want ultimately want it. My only concern is I don't want Phobos to depend on Xlib unless the module is actually imported. I don't think it will be a problem, but if it means a hello world won't run on a text only machine, that won't be ok. I suggest something simpler like: Yeah, moving to opIndex is something I plan to do. But, I don't really like using a tuple for this - a regular struct makes it a little clearer what's going on, and can be made more efficient. (In the other thread, Nick suggested making it a simple uint internally, using property functions to emulate other outside faces. I like that.) A struct might also have accessors with different color types too. I suggest something like this, to swap the two image buffers That's not really what you're doing there - display actually pops up a new window and waits for the user to close it. Plus maybe some image.event(); reader with callbacks... What would it do?
Re: simple display (from: GUI library for D)
dsimcha wrote: Can it render text? Not yet, but it's on the list. Anything that's reasonably easy in both Windows API and Xlib should be supported here. At the least, text, lines, rectangles - all the basics.
Re: simple display (from: GUI library for D)
Andrej Mitrovic: lol, wtf? :p My brilliant variable names! It reflects my feelings toward parts of the bmp format I forgot about when first writing it. I didn't account for the padding at first, then said wtf and added it... then lol'ed at myself for not doing it right the first time. You should have saw the original C version though: if(hbmp == NULL) goto fuck; :) Btw, an exception will be thrown on unhandled key events, e.g. just hit CTRL: That's weird, I've never seen GetMessage fail... ever. I'll have to try it in real Windows later (I'm on linux / Wine right now).
Re: simple display (from: GUI library for D)
Adam D. Ruppe: My only concern is I don't want Phobos to depend on Xlib unless the module is actually imported. I don't think it will be a problem, but if it means a hello world won't run on a text only machine, that won't be ok. I agree. But, I don't really like using a tuple for this - a regular struct makes it a little clearer what's going on, and can be made more efficient. OK. (But for this module I think usage simplicity is more important than raw speed. Users that need more performance or more features are going to use something else and better. The idea here is to keep simple the things that are simple). (In the other thread, Nick suggested making it a simple uint internally, using property functions to emulate other outside faces. I like that.) OK. I suggest something like this, to swap the two image buffers That's not really what you're doing there - display actually pops up a new window and waits for the user to close it. Indeed, I was suggesting to open the window at the top of the program, and at the bottom of the program to swap the two buffers and show the drawn one. Plus maybe some image.event(); reader with callbacks... What would it do? Read the events, like window closing, key pressed, mouse movements, etc. Take a look at Processing API, for ideas. There are many situations where a simple built-in graphics is useful. Beside the example of Processing (that has anti-aliasing), there are many programs/small games that need just some 2D graphics: http://rosettacode.org/wiki/Animate_a_pendulum Bye, bearophile
Re: simple display (from: GUI library for D)
bearophile wrote: OK. (But for this module I think usage simplicity is more important than raw speed. The struct is at least equal in simplicity: image[x, y] = Color(r, g, b); vs image[x, y] = tuple(r, g, b); Indeed, I was suggesting to open the window at the top of the program, and at the bottom of the program to swap the two buffers and show the drawn one. Sure, that's what happens in my second example. Right now it uses window.image = newImage; to flip it but I think I want to change that. Read the events, like window closing, key pressed, mouse movements, etc. Take a look at Processing API, for ideas. Yes, my window object does this too. See the example here: http://arsdnet.net/dcode/simpledisplay_test2.d win.eventLoop() does it. http://rosettacode.org/wiki/Animate_a_pendulum Heh, I think D will be winning that by Monday!
Integer ops tests in Clang
Through Reddit I've just found something nice, Finding Integer Undefined Behaviors in C/C++: http://embed.cs.utah.edu/ubc/ We modified Clang to dynamically detect most of C/C++'s integer undefined behaviors. Using it, we have found undefined behaviors in nearly every piece of open source software that we have checked. Slowdown due to checking is highly variable, but is in the 0%-30% range for most codes. A few math-intensive codes (codecs, crypto) slow down by more than 100%. It seems likely that by tuning LLVM and our patch a bit, these overheads could be substantially reduced. In real programs in Delphi I used to see about 10-15% slowdown caused by such runtime tests. This is not that different from the slowdown caused by array bound tests. And you are able to disable them globally or in a part of the code. Bye, bearophile
Re: Integer ops tests in Clang
On 4/8/2011 5:39 PM, bearophile wrote: Through Reddit I've just found something nice, Finding Integer Undefined Behaviors in C/C++: http://embed.cs.utah.edu/ubc/ We modified Clang to dynamically detect most of C/C++'s integer undefined behaviors. Using it, we have found undefined behaviors in nearly every piece of open source software that we have checked. Thanks for the link. This is a nice idea.
Re: simple display (from: GUI library for D)
Adam D. Ruppe:
The struct is at least equal in simplicity:
image[x, y] = Color(r, g, b);
vs
image[x, y] = tuple(r, g, b);
A tuple is simpler, there is no new name to remember and use, new type to
define, and 3-tuples come out of other generic computations, like zip:
foreach (col; zip(reds, greens, blues))
image[x, y] = col;
Generally D programmers probably need to learn to use tuples a bit more
seriously and often :-)
Yes, my window object does this too. See the example here:
http://arsdnet.net/dcode/simpledisplay_test2.d
win.eventLoop() does it.
I see. But those lambdas are a bit too much large put there. I suggest true
named function moved elsewhere.
Some other notes to your code:
- generic imports like stdio are probably better before the most specific ones
(this is done in well written Python code);
- Inside the (dchar c) {} a switch seems better.
- In Wrapped struct why are you using a checkLimits() instead of an invariant()?
http://rosettacode.org/wiki/Animate_a_pendulum
Heh, I think D will be winning that by Monday!
Good, but Rosettacode site isn't a competition :-)
Bye,
bearophile
Re: simple display (from: GUI library for D)
foreach (col; zip(reds, greens, blues)) image[x, y] = col; With Color is becomes something like: foreach (col; zip(reds, greens, blues)) image[x, y] = Color(col.tupleof); Bye, bearophile
Re: dmd2-2.052 is only for i386, while you are running amd64 (or dmd2 on FreeBSD)
On Fri, 08 Apr 2011 16:57:07 +0200, Gour-Gadadhara Dasa wrote: Hello, I'm running Free/PC-BSD desktop now, and here is dmd-2 experience: [gour@atmarama] /home/gour# cd /usr/ports/lang/dmd2/ [gour@atmarama] /usr/ports/lang/dmd2# make install clean === dmd2-2.052 is only for i386, while you are running amd64. *** Error code 1 Stop in /usr/ports/lang/dmd2. Can we expect that something will change in regard to 64bit support on FreeBSD soon or it's safer to look for alternatives (gdc, ldc)? Sincerely, Gour There is not plan to have dmd a 64bit executable. There have been reports that you can get it to build but support for it does not exist. However if you are interested in writing 64bit programs the 32bit version can still produce 64bit code with the -m64 flag. This may work for BSD, though it was develop on Linux, I think someone reported it worked?
Re: simple display (from: GUI library for D)
bearophile wrote:
With Color is becomes something like:
foreach (col; zip(reds, greens, blues))
image[x, y] = Color(col.tupleof);
That looks perfectly acceptable to me.
I might add an overload so opIndex can take a tuple too though,
so the zip example is a little easier, but I really prefer the
Color struct.
I see. But those lambdas are a bit too much large put there. I
suggest true named function moved elsewhere.
- Inside the (dchar c) {} a switch seems better.
Yeah, that's what happens when an example grows bigger then
intended without refactoring :P
- In Wrapped struct why are you using a checkLimits() instead of
an invariant()?
It's not a check (poorly chosen name I guess!) - it actually
changes the value (wrapping around) when it hits the limit, so
user input never leads to crazy values.
Besides, invariants are generally to check the program for bugs,
rather than external input from the user like used here.
Re: simple display (from: GUI library for D)
On 2011-04-08 20:11:10 -0400, Adam D. Ruppe destructiona...@gmail.com said: My only concern is I don't want Phobos to depend on Xlib unless the module is actually imported. I don't think it will be a problem, but if it means a hello world won't run on a text only machine, that won't be ok. I'm concerned by this too. I think you need two modules. One for images images with absolutely no dependencies, and another for everything dealing with windows. Only if you import the window module you need to link with the relevant libraries. That means you'll need to change the image.display() shortcut to something else not a member of image. I don't think it's particularly good that images has such a member anyway, it'd be better as a standalone function in my opinion. (Actually, perhaps we need a third to deal with drawing which might also be dependent on system libraries, especially if needs to draw text.) -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: simple display (from: GUI library for D)
On 2011-04-08 20:18:03 -0400, Adam D. Ruppe destructiona...@gmail.com said: dsimcha wrote: Can it render text? Not yet, but it's on the list. Anything that's reasonably easy in both Windows API and Xlib should be supported here. At the least, text, lines, rectangles - all the basics. One issue is that different operating system will draw things with slightly different algorithms, which will result in slightly different images, which might introduce glitches from platform to platform. I wonder if it might not be better to implement our own drawing algorithms for geometric shapes, which in addition won't be dependent on any system library. I guess text drawing would need to be left system-dependent however... -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: simple display (from: GUI library for D)
Text drawing is as simple as TextDraw or TextOut on Windows. Dunno about the nixes.
Re: simple display (from: GUI library for D)
Andrej Mitrovic wrote: Text drawing is as simple as TextDraw or TextOut on Windows. Dunno about the nixes. It's XDrawString() - almost the same. Text output is now implemented on my local copy of the module for both systems.
Re: simple display (from: GUI library for D)
Michel Fortin wrote: One issue is that different operating system will draw things with slightly different algorithms, which will result in slightly different images, which might introduce glitches from platform to platform. I actually hit an even bigger problem... Xlib can't actually draw to XImages, and you don't have direct pixel access to XPixmaps (it's the difference between being on the X Server and the client). So, the lowest common denominator, using only system libraries, is actually to allow *only* pixel access to Image, and move other drawing over to the Window. (Specifically, a Painter struct that ties to the window, so it can manage graphics contexts... yeah, it's starting to get complicated again.) What this means is if we want to draw to images, we've got to spin our own algorithms. Which makes the different OS algorithms moot - the direct screen drawing will be different, but the images will all be the same. The downside is their functions will lag a bit since I can't just wrap some C calls.
Re: simple display (from: GUI library for D)
It looks like SDL (1.3) will be under zlib license soon[1] so maybe using it or parts of it or whatever may be feasible, even in Phobos - the zlib license should be free enough, it says If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. so there's no binary attribution clause. Cheers, - Daniel [1] http://slouken.blogspot.com/2011/04/exploring-galaxy.html?showComment=1302234229839#c4323023909103671526
Re: simple display (from: GUI library for D)
On 2011-04-08 21:45:20 -0400, Adam D. Ruppe destructiona...@gmail.com said: Michel Fortin wrote: One issue is that different operating system will draw things with slightly different algorithms, which will result in slightly different images, which might introduce glitches from platform to platform. I actually hit an even bigger problem... Xlib can't actually draw to XImages, and you don't have direct pixel access to XPixmaps (it's the difference between being on the X Server and the client). So, the lowest common denominator, using only system libraries, is actually to allow *only* pixel access to Image, and move other drawing over to the Window. (Specifically, a Painter struct that ties to the window, so it can manage graphics contexts... yeah, it's starting to get complicated again.) What this means is if we want to draw to images, we've got to spin our own algorithms. Which makes the different OS algorithms moot - the direct screen drawing will be different, but the images will all be the same. The downside is their functions will lag a bit since I can't just wrap some C calls. Personally, I wouldn't even bother with direct screen drawing in that case. Direct screen drawing will need a different implementation for each OS, which means a lot of duplicated effort that could be put in implementing dependency-less cross-platform drawing primitives instead. As for text, which library does the X server uses to draw text? Freetype? You could link directly to it when you need to draw text... and on other OS use similar OS services. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: New look feel for std.algorithm
There seems to be some weird spacing on the articles page, link section Migrating to shared: http://i.imgur.com/dqdub.png
Re: New look feel for std.algorithm
Also, on some pages there's still a Digg button. Other than the fact that Digg is practically dead (everybody who knows about Digg seems to admit this from what I can tell), I don't see a reason why it's there on some pages while not on the others, e.g.: http://d-programming-language.org/hijack.html - digg button http://d-programming-language.org/migrate-to-shared.html - no digg button I say we just kill it.
Re: simple display (from: GUI library for D)
On Fri, Apr 08, 2011 at 06:40:47PM -0700, Cliff Hudson wrote: Have you considered patterning your API off an existing (preferably popular) one? That's essentially what I'm doing - it's a very thin wrapper around the operating system libraries, meant to just make it easy.
Re: simple display (from: GUI library for D)
Michel Fortin wrote: Direct screen drawing will need a different implementation for each OS, which means a lot of duplicated effort that could be put in implementing dependency-less cross-platform drawing primitives instead. I'd agree if not for one thing: it isn't really much duplicated effort - most the functions are just a few lines long; it wraps C. There's a good chance I'll be able to finish them in the next hour for Win32 and X11. As for text, which library does the X server uses to draw text? I think it's freetype for ttf and for bitmap fonts it's built into it. Linking directly to it is a good idea.
Re: simple display (from: GUI library for D)
Daniel Gibson wrote: It looks like SDL (1.3) will be under zlib license soon Now, that's pretty cool!
Re: simple display (from: GUI library for D)
Am 09.04.2011 03:55, schrieb Michel Fortin: On 2011-04-08 21:45:20 -0400, Adam D. Ruppe destructiona...@gmail.com said: Michel Fortin wrote: One issue is that different operating system will draw things with slightly different algorithms, which will result in slightly different images, which might introduce glitches from platform to platform. I actually hit an even bigger problem... Xlib can't actually draw to XImages, and you don't have direct pixel access to XPixmaps (it's the difference between being on the X Server and the client). So, the lowest common denominator, using only system libraries, is actually to allow *only* pixel access to Image, and move other drawing over to the Window. (Specifically, a Painter struct that ties to the window, so it can manage graphics contexts... yeah, it's starting to get complicated again.) What this means is if we want to draw to images, we've got to spin our own algorithms. Which makes the different OS algorithms moot - the direct screen drawing will be different, but the images will all be the same. The downside is their functions will lag a bit since I can't just wrap some C calls. Personally, I wouldn't even bother with direct screen drawing in that case. Direct screen drawing will need a different implementation for each OS, which means a lot of duplicated effort that could be put in implementing dependency-less cross-platform drawing primitives instead. As for text, which library does the X server uses to draw text? Freetype? You could link directly to it when you need to draw text... and on other OS use similar OS services. For the drawingt part. I'm currently working on a rednerer with scanline algorithm. This will be completly OS-independent. It's in a single file with 2kLOC, and rather low level drawing. I just render on a simple ubyte-array, but it already support polygon-rendering, antialiasing and different color-structs. This is how it looks like for now: http://img683.imageshack.us/i/testawa.jpg/ this takes currently 62ms to render, don't know if this is fast enough, but can definitley improved. °Matthias
