q66 wrote:
> On Sunday, 1 April 2012 at 20:32:00 UTC, Walter Bright wrote:
> >On 4/1/2012 1:12 PM, q66 wrote:
> >>Cool. I'll try to get some other lib bindings up in the future
> >>as well. :)
> >
> >That would be most appreciated.
>
> I'm preparing my game engine for possible migration to D. Mean
I read some posts on the internet about irrlicht (
http://irrlicht.sf.net ) port for D, named Dirrlicht. There's no
(working) link to project, is it dead?
What about other 3d engines ports like ogre3d?
What about other 3d engines ports like ogre3d?
there are bindings for http://www.horde3d.org/ available.
http://d.puremagic.com/test-results/
On 01.04.2012 22:27, Adam D. Ruppe wrote:
I've prepared a dmd pull request to add a new __trait:
getProtection.
It is meant to be used along with getMember() to add to
the reflection capabilities, letting us use the existing
protection qualifiers as strings.
From the test:
==
class Test {
publ
Hi,
I have a design question, or maybe it is a bug ? In D, == and != have
the same precedence than comparisons operators. This isn't the case in
C/C++ . Is it a design decision, made on purpose ? Is it a bug ?
DMD implementation and http://dlang.org/expression.html both agree on that.
I pers
Probably a good way to force parentesys usage and avoid subtle
bugs...
On Monday, 2 April 2012 at 10:01:20 UTC, deadalnix wrote:
Hi,
I have a design question, or maybe it is a bug ? In D, == and
!= have the same precedence than comparisons operators. This
isn't the case in C/C++ . Is it a de
On Mon, 02 Apr 2012 12:03:14 +0200, deadalnix wrote:
Hi,
I have a design question, or maybe it is a bug ? In D, == and != have
the same precedence than comparisons operators. This isn't the case in
C/C++ . Is it a design decision, made on purpose ? Is it a bug ?
DMD implementation and ht
On 02/04/2012 11:32, Simen Kjaeraas wrote:
On Mon, 02 Apr 2012 12:03:14 +0200, deadalnix wrote:
I have a design question, or maybe it is a bug ? In D, == and != have the same
precedence than comparisons operators. This isn't the case in C/C++ . Is it a
design
decision, made on purpose ? Is it
Le 02/04/2012 13:10, Stewart Gordon a écrit :
On 02/04/2012 11:32, Simen Kjaeraas wrote:
On Mon, 02 Apr 2012 12:03:14 +0200, deadalnix
wrote:
I have a design question, or maybe it is a bug ? In D, == and != have
the same
precedence than comparisons operators. This isn't the case in C/C++ .
Is
On Monday, 2 April 2012 at 09:26:07 UTC, Dmitry Olshansky wrote:
It's all nice and well, but I believe part of the reason of say
private protection is that user is never ever able to see(!)
it. Thus it user can't depend on private members being there,
which is a good thing.
That's not the way
On 2012-04-02 09:00, Jens Mueller wrote:
Do you want to load libraries at run time?
Can you check http://jkm.github.com/ddl/ddl.html? Technically any Deimos
module should work.
Cool, but the name kind of conflicts with this old project:
http://www.dsource.org/projects/ddl
Don't know if anyon
Parentesys are needed only where there's ambiguity with
precedence.
a > b > c is ambiguous (we need parentesys)
a == b > c is amibiguous (we need parentesys because == and >
have the same precedence)
a == b && c is not ambiguous ( && and == haven't the same
precedence so we don't need paren
On 02.04.2012 16:04, Adam D. Ruppe wrote:
On Monday, 2 April 2012 at 09:26:07 UTC, Dmitry Olshansky wrote:
It's all nice and well, but I believe part of the reason of say
private protection is that user is never ever able to see(!) it. Thus
it user can't depend on private members being there, wh
On Fri, 30 Mar 2012 17:45:36 -0400, Michel Fortin
wrote:
On 2012-03-30 14:46:19 +, Andrei Alexandrescu
said:
Destroy!
Since you're asking…
One thing the current system avoids is unresolvable symbols. If two
symbol name clashes, you just qualify them fully and it'll always be
una
On Sat, 31 Mar 2012 00:23:32 -0400, Chris NS wrote:
I'm pretty impressed with the idea, and look forward to its
implementation, but I do have one question. How does this affect (if at
all) the implicit "friend" relationship of declarations? Since package
"foo.bar" is treated as a single
On 4/2/2012 5:04 AM, deadalnix wrote:
So basically, the precedence doesn't matter because any situation where it
matter is illegal anyway ?
That's correct and neatly sums up the situation.
Le 02/04/2012 15:49, Walter Bright a écrit :
On 4/2/2012 5:04 AM, deadalnix wrote:
So basically, the precedence doesn't matter because any situation
where it
matter is illegal anyway ?
That's correct and neatly sums up the situation.
Merci :D
On Monday, April 02, 2012 13:26:05 Dmitry Olshansky wrote:
> It's all nice and well, but I believe part of the reason of say private
> protection is that user is never ever able to see(!) it. Thus it user
> can't depend on private members being there, which is a good thing.
> If I read it right, th
Le 02/04/2012 19:10, Jonathan M Davis a écrit :
On Monday, April 02, 2012 13:26:05 Dmitry Olshansky wrote:
It's all nice and well, but I believe part of the reason of say private
protection is that user is never ever able to see(!) it. Thus it user
can't depend on private members being there, wh
On Monday, April 02, 2012 20:02:20 deadalnix wrote:
> Le 02/04/2012 19:10, Jonathan M Davis a écrit :
> > On Monday, April 02, 2012 13:26:05 Dmitry Olshansky wrote:
> >> It's all nice and well, but I believe part of the reason of say private
> >> protection is that user is never ever able to see(!)
On 1 April 2012 21:27, Adam D. Ruppe wrote:
> I've prepared a dmd pull request to add a new __trait:
> getProtection.
>
> It is meant to be used along with getMember() to add to
> the reflection capabilities, letting us use the existing
> protection qualifiers as strings.
>
> From the test:
> ==
On Mon, 02 Apr 2012 20:02:20 +0200, deadalnix wrote:
Now, there are a number of people very unhappy about this state of
affairs and
want private to hide symbols as well (personally, I think that the fact
that
it makes private aliases effectively useless is reason enough to
seriously
recons
On 04/02/2012 10:59 PM, Simen Kjærås wrote:
On Mon, 02 Apr 2012 20:02:20 +0200, deadalnix wrote:
Now, there are a number of people very unhappy about this state of
affairs and
want private to hide symbols as well (personally, I think that the
fact that
it makes private aliases effectively usel
Hi everyone,
A couple of days ago I handed in my application/proposal for GSoC.
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/adhoc__/1
Is there a reason there seems to be no response or have I missed
something?
Just wanted to make sure that I'm not doing so :)
--Alex
Code:
// S.d
struct S {
int x;
this(int _x) { x = _x; }
}
// test.d
class T {
S s;
this(S _s) { s = _s; }
}
void main() {
auto t = new T(S(1)); // this is line 1
H. S. Teoh:
Is there any reason whatsoever that the compiler should resolve
"S" to
the module rather than the struct defined by the eponymous
module?
For DMD choosing one or the other is arbitrary. It's a defect of
the way the D module system is designed. This problem is _absent_
in the Pyt
On 4/3/12, H. S. Teoh wrote:
> However, this name conflict makes this scheme rather painful to use. :-(
For now you can stutter a little bit and use this:
import S : S;
On Tuesday, April 03, 2012 00:31:32 Andrej Mitrovic wrote:
> On 4/3/12, H. S. Teoh wrote:
> > However, this name conflict makes this scheme rather painful to use. :-(
>
> For now you can stutter a little bit and use this:
> import S : S;
The simplest is just to rename the module so that it's all
On Mon, Apr 02, 2012 at 06:46:07PM -0400, Jonathan M Davis wrote:
> On Tuesday, April 03, 2012 00:31:32 Andrej Mitrovic wrote:
> > On 4/3/12, H. S. Teoh wrote:
> > > However, this name conflict makes this scheme rather painful to use. :-(
> >
> > For now you can stutter a little bit and use this:
Yet another follow-up, sorry. I changed the proposal quite a bit
trying to do a better job at separating the very specific technical
content from the rest of the proposal which should make is easier to
read for people who didn't work on the library - this, I imagine, was
a hurdle for people who mig
On Monday, April 02, 2012 16:01:38 H. S. Teoh wrote:
> On Mon, Apr 02, 2012 at 06:46:07PM -0400, Jonathan M Davis wrote:
> > On Tuesday, April 03, 2012 00:31:32 Andrej Mitrovic wrote:
> > > On 4/3/12, H. S. Teoh wrote:
> > > > However, this name conflict makes this scheme rather painful to use.
>
On Monday, April 02, 2012 15:08:42 H. S. Teoh wrote:
> Code:
> // S.d
> struct S {
> int x;
> this(int _x) { x = _x; }
> }
>
> // test.d
> class T {
> S s;
> this(S _s) { s = _s; }
> }
>
> void main() {
> auto t = new T(S(1)); // this is line 10
> }
>
> Compiler error:
>
> test.d(10): Error: fu
On Mon, Apr 02, 2012 at 07:21:53PM -0400, Jonathan M Davis wrote:
> On Monday, April 02, 2012 16:01:38 H. S. Teoh wrote:
> > On Mon, Apr 02, 2012 at 06:46:07PM -0400, Jonathan M Davis wrote:
[...]
> > > The simplest is just to rename the module so that it's all
> > > lowercase. I believe that most
I also haven't received any feedback yet, don't worry - I don't think
there's any specific reason for this.
---
Cristi Cobzarenco
BSc in Artificial Intelligence and Computer Science
University of Edinburgh
Profile: http://www.google.com/profiles/cristi.cobzarenco
On 2 April 2012 23:00, alex w
On Sunday, 1 April 2012 at 10:12:45 UTC, Davita wrote:
Or maybe to work with MS and integrate D in VS and WinRT api.
Or an MS employee can try it on their own:
http://www.reddit.com/tb/ow7qc
On 2012-04-02 13:04:31 +, "Steven Schveighoffer"
said:
On Fri, 30 Mar 2012 17:45:36 -0400, Michel Fortin
The problem is that if .std.algorithm.package
contains a sort function and there is also a module called
std.algorithm.sort, the fully-qualified name of that 'sort' module wil l
becom
I've read **Proposed Changes and Additions**, and I would like to
comment and ask a few questions if that's okay. BTW, I've used Eigen
a lot and I see some similarities here, but a direct rewrite may not
be the best thing because D > C++.
2. Change the matrix & vector types, adding fixed-sized m
Regarding this:
http://d.puremagic.com/issues/show_bug.cgi?id=790
I submit that nested functions should be exempt from the usual sequential
visibility rules. (Therefore, mutually recursive nested functions would
become possible.)
Or at the very *least*, this horrific C-like workaround should b
"Jesse Phillips" wrote in message
news:wazenwszxxaipyabw...@forum.dlang.org...
> On Sunday, 1 April 2012 at 10:12:45 UTC, Davita wrote:
>
>> Or maybe to work with MS and integrate D in VS and WinRT api.
>
> Or an MS employee can try it on their own:
>
> http://www.reddit.com/tb/ow7qc
Whoa, that
> Sorry, I didn't mean this to go into "D.announce". Reposting in the proper
> place... Can this one be deleted?
Off Topic: In Gmail, it applied both labels to the one email, which is cool :D.
Otherwise I think that the C-like workaround should be ok, the issue
is with closures, what values shoul
Le 02/04/2012 22:59, Simen Kjærås a écrit :
On Mon, 02 Apr 2012 20:02:20 +0200, deadalnix wrote:
Now, there are a number of people very unhappy about this state of
affairs and
want private to hide symbols as well (personally, I think that the
fact that
it makes private aliases effectively usel
Le 03/04/2012 00:00, Timon Gehr a écrit :
Making private symbols invisible to other modules or at least excluding
them from symbol clashes is necessary. The current behaviour is not
useful or desirable in any way.
This smells like religious coding to me.
NVI is perfectly possible with prote
43 matches
Mail list logo
