Re: floating-WTF - Compiler-BUG with 64bit
On Sunday, January 29, 2012 08:43:54 sclytrack wrote: Prior to filing the bug I tried to compile dmd from source. I have now succeeded. The only problem I had was a missing symbolic link libstdc++.so and this in Ubuntu 11.10. So I just created it. /usr/lib32/libstdc++.so - /usr/lib/i386-linux-gnu/libstdc++.so.6 Then make -f posix and in the dmd/src directory. The bug is indeed gone. It uses the xmm3 register now to store the intermediate value. Going to clone phobos now. While I'm at it. :-) Don't forget druntime. You need it as well if you want to build Phobos. - Jonathan M Davis
Re: Clutter GObject bindings
On 01/28/12 17:08, Artur Skawina wrote: On 01/28/12 03:02, Sparse Push wrote: What is the best way to generate GObject bindings? I ask this because I would like to use Clutter (http://www.clutter-project.org/) in my D program and I don't think it has D bindings already. From the website, http://www.clutter-project.org/about : [...] Developed in C, with language bindings for Perl, Python, C#, C++, Vala and Ruby. Clutter also generates introspection data during build, for dynamic language binding using the GObject introspection API. Learn more about GObject introspection... so, in theory, it should be possible to use girtod to create the bindings. http://repo.or.cz/w/girtod.git/shortlog/refs/heads/master In practice, it will likely require tweaks for some data types and errors in the introspection files (for GTK, this took me way more time than writing the xml parser and code generator; maybe much of the work is already done so this will be less painful). Also, right now, girtod does not handle certain things (eg gobject interfaces). so if clutter is using them, support will have to be added (it wasn't immediately obvious to me how to expose the parts of the API that i haven't used myself; once i figure that out, adding the support will be easy, as most of the work is already done). Started to look at this myself, but had to handle all the deps first, that took some time. As a side effect the gtk bindings improved. girtod can now generate bindings for Cogl. Not even compile tested yet, but should already give an idea how the thing will look like. If somebody familiar with Cogl would check it out and see if exposing the API this way makes sense, that would be great. http://repo.or.cz/w/girtod.git/blob/refs/heads/gtk2:/gtk2/cogl.d I'll try to get clutter done first, and will fill in the missing cogl/gl pieces then. artur
Re: Clutter GObject bindings
On 01/29/12 17:27, Artur Skawina wrote: On 01/28/12 17:08, Artur Skawina wrote: On 01/28/12 03:02, Sparse Push wrote: What is the best way to generate GObject bindings? I ask this because I would like to use Clutter (http://www.clutter-project.org/) in my D program and I don't think it has D bindings already. From the website, http://www.clutter-project.org/about : [...] Developed in C, with language bindings for Perl, Python, C#, C++, Vala and Ruby. Clutter also generates introspection data during build, for dynamic language binding using the GObject introspection API. Learn more about GObject introspection... so, in theory, it should be possible to use girtod to create the bindings. http://repo.or.cz/w/girtod.git/shortlog/refs/heads/master In practice, it will likely require tweaks for some data types and errors in the introspection files (for GTK, this took me way more time than writing the xml parser and code generator; maybe much of the work is already done so this will be less painful). Also, right now, girtod does not handle certain things (eg gobject interfaces). so if clutter is using them, support will have to be added (it wasn't immediately obvious to me how to expose the parts of the API that i haven't used myself; once i figure that out, adding the support will be easy, as most of the work is already done). Started to look at this myself, but had to handle all the deps first, that took some time. As a side effect the gtk bindings improved. girtod can now generate bindings for Cogl. Not even compile tested yet, but should already give an idea how the thing will look like. If somebody familiar with Cogl would check it out and see if exposing the API this way makes sense, that would be great. http://repo.or.cz/w/girtod.git/blob/refs/heads/gtk2:/gtk2/cogl.d I'll try to get clutter done first, and will fill in the missing cogl/gl pieces then. Done. Does the resulting clutter API look usable? http://repo.or.cz/w/girtod.git/blob/refs/heads/gtk2:/gtk2/clutter.d None of the new modules were tested - i still need code samples to port and time to fix any bugs. artur
A tutorial on D templates: updates
Hello, [cross-posted with D.announce, since it's a topic of interest for people learning D] I posted there a few weeks ago about a tutorial on D templates I put in github: https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/dtemplates.pdf Since then, I received numerous mails, issues, advices and thanks. Thank to you all! Following the ideas found in TDPL, I wrote a D script to extract and test all the samples presented in the document. I'm proud to say that right now, all named (module XXX;) samples compile, which makes for more than 200 modules tested! Indeed, you could see the entire document as a huge package documentation :) I also added explanations, new sections and a new appendix in D templates resources. As before, do not hesitate to read, comment, post and even send pull requests, I'm all ears. Bye, Philippe
Partial classes
Hello everybody. Quick question, is there anything like C#'s partial classes in D? Mars
Re: Partial classes
Mars: Hello everybody. Quick question, is there anything like C#'s partial classes in D? In D there are ways to compose classes, using static methods of interfaces, with alias this, and even low-level ways like mixin(import(filename.d)), and so on. But currently there are no partial classes in D. Maybe partial classes will be added in future if their usefulness becomes evident :-) Bye, bearophile
Re: A tutorial on D templates: updates
I'm learning D. So thanks for the tutorial. I hope D becomes more popular, as it deserves.
Re: Clutter GObject bindings
Done. Does the resulting clutter API look usable? http://repo.or.cz/w/girtod.git/blob/refs/heads/gtk2:/gtk2/clutter.d None of the new modules were tested - i still need code samples to port and time to fix any bugs. artur Now I am going to feel bad if I don't create something awesome with it just as quickly. The API looks fine to me, should be enough to play around with it. btw. You should definitely post this to the clutter website.
Does D supply basic error codes?
Hello all. C has EXIT_FAILURE and EXIT_SUCCESS to be returned from main(). Does D have similar predefined values?
Re: Clutter GObject bindings
On 01/29/12 23:51, Sparse Push wrote: Done. Does the resulting clutter API look usable? http://repo.or.cz/w/girtod.git/blob/refs/heads/gtk2:/gtk2/clutter.d None of the new modules were tested - i still need code samples to port and time to fix any bugs. artur Now I am going to feel bad if I don't create something awesome with it just as quickly. The API looks fine to me, should be enough to play around with it. btw. You should definitely post this to the clutter website. I wouldn't be surprised - in fact i'd expect - that at this point the new modules don't even compile. This is the first time i looked at clutter; i wanted to port some toy app and use that for testing, but the ones i found were either very unspectacular, didn't build at all, or were GPLed, which is a very bad idea for an example. Even the C example from http://wiki.clutter-project.org/wiki/Cogl/CoglBasicsExample does not work here (there's no cube, just the Hello Cogl line), so i'm still looking for something that will let me show off how much nicer the D version is (compared to all the C clutter code i saw so far, this is not exactly hard). Until the bindings are tested and shown to actually work, announcing them would be a bit premature. I'll try make them work in the next couple of days; there's also a mob girtod git branch, that anybody can push to... ;) artur
Re: Does D supply basic error codes?
import core.stdc.stdlib;
int main()
{
return EXIT_FAILURE; // EXIT_SUCCESS works here too.
}
Am 30.01.2012 00:21, schrieb NewName:
Hello all.
C has EXIT_FAILURE and EXIT_SUCCESS to be returned from main().
Does D have similar predefined values?
Re: Does D supply basic error codes?
On Sunday, January 29, 2012 23:21:16 NewName wrote: Hello all. C has EXIT_FAILURE and EXIT_SUCCESS to be returned from main(). Does D have similar predefined values? No, but you can use the C ones if you want, as mta`chrono points out. - Jonathan M Davis
Re: Does D supply basic error codes?
mta`chrono:
import core.stdc.stdlib;
int main()
{
return EXIT_FAILURE; // EXIT_SUCCESS works here too.
}
And in D void main(){} returns a EXIT_SUCCESS.
Bye,
bearophile
Re: Partial classes
On Sunday, January 29, 2012 22:43:26 Mars wrote: Hello everybody. Quick question, is there anything like C#'s partial classes in D? Not really, no. It's one file per module by design. However, you can use template and string mixins to add code from other files. - Jonathan M Davis
Overriding Template Methods
Hi,
I don't know if this is a bug or if I'm doing something wrong, but I'm not
being able to override template methods. This can be seen with this simple code:
class Base
{
void writeValueType( T )( T value )
{
writefln( This is Base.writeValueType: value %s has type %s, value,
typeid( value ) );
}
}
class Derived : Base
{
override void writeValueType( T )( T value )
{
writefln( This is Derived.writeValueType: value %s has type %s,
value, typeid( value ) );
}
}
void main()
{
Base b = new Derived();
b.writeValueType( true );
}
The output should be:
This is Derived.writeValueType: value true has type bool
But, instead, it is:
This is Base.writeValueType: value true has type bool
Am I missing something?
Re: Overriding Template Methods
On 01/29/2012 06:23 PM, Daniel L. Alves wrote:
Hi,
I don't know if this is a bug or if I'm doing something wrong, but
I'm not
being able to override template methods. This can be seen with this
simple code:
class Base
{
void writeValueType( T )( T value )
{
writefln( This is Base.writeValueType: value %s has type
%s, value,
typeid( value ) );
}
}
class Derived : Base
{
override void writeValueType( T )( T value )
{
writefln( This is Derived.writeValueType: value %s has type
%s,
value, typeid( value ) );
}
}
void main()
{
Base b = new Derived();
b.writeValueType( true );
}
The output should be:
This is Derived.writeValueType: value true has type bool
But, instead, it is:
This is Base.writeValueType: value true has type bool
Am I missing something?
Template member functions cannot be virtual.
One quick reason why this is so is that Derived.writeValueType would
have to be instantiated by the compiler, for every possible type in the
program. This would lead to almost infinitely large virtual function
pointer table.
I don't know whether the compiler could refuse the code to compile with
that 'override' keyword, but luckily the code is rejected as soon as you
add the following two lines:
Derived d = new Derived();
d.writeValueType(true);
Only then the compiler sees the problem:
Error: function deneme.Derived.writeValueType!(bool).writeValueType
cannot override a non-virtual function
And that kind of makes sense, because the templates are compiled only if
they are used and only for the types that they are used with.
Ali
Re: Overriding Template Methods
Hey, thank you very much for the explanation! Daniel
Re: Overriding Template Methods
On Sun, Jan 29, 2012 at 06:43:39PM -0800, Ali Çehreli wrote: [...] Template member functions cannot be virtual. One quick reason why this is so is that Derived.writeValueType would have to be instantiated by the compiler, for every possible type in the program. This would lead to almost infinitely large virtual function pointer table. [...] I wonder, though, if there are ways of simulating overridable template members by clever use of opDispatch(). Having said that, if you ever get to the point where you can't get around needing overridable template members, then it may be a sign that you're trying to represent simulated types by language types and simulated objects by language objects, whereas the two are different beasts. The solution is to work at a higher level of abstraction. This kind of thing happens, for example, when you're trying to do, say, a physics simulation where you have various types of particles that interact with each other. It may be possible up to a point to represent each type of particle as a separate class, perhaps with a class hierarchy of some sort. But there comes a point where you need to treat simulated types (i.e., particle types) as distinct from the programming language's types. I.e., you have a Particle class that stores an enum that represents what type the particle is (not to be confused with the programming language's types), and perhaps an array of attributes associated with the particle (as opposed to coding each attribute into a distinct field). Particle interactions then are handled by a single method that takes a string or enum type representing what kind of interaction it is, rather than mapping each interaction to a method. This kind of implementation is necessary if, say, the particles have runtime-variable attribute lists, or runtime-variable types, or even types that emerge at runtime. Or when simulated particles don't really behave like programming language class objects, and therefore don't map very well onto the OO paradigm. T -- Do not reason with the unreasonable; you lose by definition.
Re: Does D supply basic error codes?
On Sunday, 29 January 2012 at 23:58:50 UTC, bearophile wrote:
mta`chrono:
import core.stdc.stdlib;
int main()
{
return EXIT_FAILURE; // EXIT_SUCCESS works here too.
}
And in D void main(){} returns a EXIT_SUCCESS.
Bye,
bearophile
Except when exited due to an exception thrown.
