Re: D for Android beta
On Saturday, 26 August 2017 at 09:59:33 UTC, Joakim wrote: On Thursday, 1 June 2017 at 19:45:17 UTC, Ali Çehreli wrote: Very exciting! :) On 06/01/2017 12:31 PM, Joakim wrote: > I will write up instructions on how to write an Android app in D _on_ > your Android device I hope it will be detailed enough for people who are very new to programming on the Android. Ali I've finally written up full instructions on building D apps for Android by using the linux cross-compiler or native Android compiler I provide: https://wiki.dlang.org/Build_D_for_Android The upcoming ldc 1.4 beta will be the first to include Android cross-compilation support for all supported host platforms, ie Windows, Mac, and linux, as all my Android patches have now been merged. I'll stop putting out my own cross-compiler builds, though I'll maintain the native ldc package in the Termux package repo, once that's accepted. If you want to build full OpenGLES GUI Android apps on your Android device, this wiki page shows you how to do that too. You too can be one of the elite few building mobile apps on your mobile device, and in D! And there is now an ldc package in the Termux Android app, updated the wiki page to show how simple it is to install ldc on your Android device now: https://wiki.dlang.org/Build_D_for_Android#Native_compilation_2 Make sure to tell everyone you know how easy it is to write D on your Android smartphone or tablet now, just like the Go people have been enjoying: https://mobile.twitter.com/mattbostock/status/896923877711814657 The Termux twitter highlights those now happy about using Node, Clojure, or Scala on their Android phone, hopefully D is next: https://mobile.twitter.com/termux Next up, getting D working on 64-bit ARM devices, which I recently got access to. David has been working on it already, hope we can get that done by ldc 1.5: https://github.com/ldc-developers/ldc/issues/2153
DlangUI v0.7.60 released
There are a lot of improvements in DlangIDE since last announcement. DlangIDE is a cross-platform IDE for D programming language. Project link: https://github.com/buggins/dlangide Release: https://github.com/buggins/dlangide/releases Windows binaries are available (requires only DMD or LDC to work). * DUB package as project format * DUB is used to build and debug projects * DCD is integrated as a library - provides code completion, go to definition and symbol documentation lookup. * GDB (mago-mi on windows) debugger support Recent changes: * Stability fixes * DCD support fixes * Better UI look and feel * UI font setting added * List of opened files is saved on exit * Setting to reopen recent workspace on startup * Opens project or workspace passed as commandline parameter * UI translations improved * DUB Subpackages support Thanks to DlangIDE and DlangUI contributors for PRs and issue reports. Main TODO: better debugging support - variable display. Currently it's impossible to see content referenced by pointers, struct or class members. It's main stopper from using DlangIDE for everyday development.
Released vibe.d 0.8.1
Apart from removing the old vibe-d:diet package in favor of diet-ng, this release most notably contains a number of performance improvements in the HTTP server, as well as improvements and fixes in the WebSocket code. Furthermore, initial OpenSSL 1.1.x support has been added and a few @safe related issues introduced in 0.8.0 have been fixed. Change log: https://vibed.org/blog/posts/vibe-release-0.8.1 DUB package: https://code.dlang.org/packages/vibe-d/0.8.1
DCompute: Driver APIs are here
Hi all, I am happy to announce that the driver APIs for both OpenCL and CUDA are now here[1]! They are not yet feature complete and still have a lot more polishing and testing to be done, but the ground work is there. That should give contributors a scope to work on and help break up the work that needs to be done into more manageable pieces. I'll put up a release of LLVM and LDC for both OSX and Windows (now that I finally got it to link) soon for anyone who wants to try it out or start contributing, the more hand helping and testing the better. Also I'm looking for someone who would be interested in co-presenting at the international workshop on OpenCL in Edinburgh (mid May) on an application of DCompute. I will be continuing to work on this and do testing in my spare time until I start work (Laeeth: how's the office moving and infrastructure migration going ;) ), but now the foundation is there hopefully development will start to pick up. Nic [1]: https://github.com/libmir/dcompute
Re: DCompute: Driver APIs are here
On Wednesday, 30 August 2017 at 07:49:29 UTC, Nicholas Wilson wrote: Hi all, I am happy to announce that the driver APIs for both OpenCL and CUDA are now here[1]! They are not yet feature complete and still have a lot more polishing and testing to be done, but the ground work is there. That should give contributors a scope to work on and help break up the work that needs to be done into more manageable pieces. [...] Great! Thank you, Nicholas
Re: D as a Better C
On Wednesday, 30 August 2017 at 00:29:19 UTC, Parke wrote: But my original question was about what you (Kagamin) called "intermediate D". I was trying to understand what "intermediate D" is, and whether or not I could use "intermediate D" (whatever it is) to produce small(er) executables. I rely on llvm tooling to remove unused stuff, build process is a bit lengthy, I didn't write a step by step guide for it. Also linux might need different approach depending what code compiler generates.
Re: D as a Better C
On Wednesday, 30 August 2017 at 02:19:21 UTC, Michael V. Franklin wrote: As you can see it is not a polished experience and gets much worse when you start employing more features of D. This could be improved, and in fact, with GDC you need even less useless boilerplate in object.d and may end up with an even smaller executable. (Maybe I'll follow up later with GDC illustration. Right now I don't have a computer with the latest GDC installed). If you try this experiment with LDC, you may end up with a multi-gigabyte file and crash your PC due to https://github.com/ldc-developers/ldc/issues/781 I use stock object.d, just don't link it.
5 seconds agoDIP 1009--Improve Contract Usability--Formal Review Begins
The feedback period of the formal review for DIP 1009, "Improve Contract Syntax", is now underway. http://forum.dlang.org/post/otsfobizkagfawvqh...@forum.dlang.org
Re: Open Methods: From C++ to D
On Wednesday, 30 August 2017 at 04:48:11 UTC, Arun Chandrasekaran
wrote:
On Tuesday, 29 August 2017 at 12:45:50 UTC, Jean-Louis Leroy
wrote:
On Tuesday, 29 August 2017 at 12:09:01 UTC, Mark wrote:
Nice. This does seem superior to the visitor pattern.
Here is another example - AST traversal:
https://github.com/jll63/openmethods.d/blob/master/examples/acceptnovisitors/source/app.d
Thanks for this library. Just a suggestion. Would it possible
to use `@openmethod` instead of `@method`?
Ah, I think it's a little late for that. A while ago I asked if
anyone had suggestions regarding that sort of things...But now
that the article has been published I think it would be a very
bad idea to break all the exmaples in it.
What was your rationale for `openmethod` instead of just `method`?
I will push a commit tonight that will make this work:
import openmethods : virtual, openmethod = method, next,
registerMethods, updateMethods;
// ...
@openmethod // implement 'kick' for dogs
string _kick(Dog x) // note the underscore
{
return "bark";
}
Re: Open Methods: From C++ to D
On Wednesday, 30 August 2017 at 13:35:22 UTC, Jean-Louis Leroy wrote: On Wednesday, 30 August 2017 at 04:48:11 UTC, Arun What was your rationale for `openmethod` instead of just `method`? Just that `openmethod` precisely expresses it's intent and `method` is too generic.
Re: Open Methods: From C++ to D
On Wednesday, 30 August 2017 at 14:37:14 UTC, Arun Chandrasekaran wrote: On Wednesday, 30 August 2017 at 13:35:22 UTC, Jean-Louis Leroy wrote: On Wednesday, 30 August 2017 at 04:48:11 UTC, Arun What was your rationale for `openmethod` instead of just `method`? Just that `openmethod` precisely expresses it's intent and `method` is too generic. I sort of agree, and somewhat regret not picking 'openmethod'. I considered both. Also @specialize. If anyone had pushed for @openmethod before the article, I would almost certainly have given in. My reasoning was, I hope to promote the term 'method' as the standard name for polymorphism from outside, as opposed to vfunc. We usually say "virtual functions", rarely "virtual member functions". Membership is implicit.
Re: Open Methods: From C++ to D
On 30/08/2017 4:10 PM, Jean-Louis Leroy wrote: On Wednesday, 30 August 2017 at 14:37:14 UTC, Arun Chandrasekaran wrote: On Wednesday, 30 August 2017 at 13:35:22 UTC, Jean-Louis Leroy wrote: On Wednesday, 30 August 2017 at 04:48:11 UTC, Arun What was your rationale for `openmethod` instead of just `method`? Just that `openmethod` precisely expresses it's intent and `method` is too generic. I sort of agree, and somewhat regret not picking 'openmethod'. I considered both. Also @specialize. If anyone had pushed for @openmethod before the article, I would almost certainly have given in. My reasoning was, I hope to promote the term 'method' as the standard name for polymorphism from outside, as opposed to vfunc. We usually say "virtual functions", rarely "virtual member functions". Membership is implicit. Rename, alias to old and have it deprecated. Keep around for a couple of releases, done!
Re: Open Methods: From C++ to D
On Wednesday, 30 August 2017 at 15:14:04 UTC, rikki cattermole wrote: On 30/08/2017 4:10 PM, Jean-Louis Leroy wrote: On Wednesday, 30 August 2017 at 14:37:14 UTC, Arun Chandrasekaran wrote: [...] I sort of agree, and somewhat regret not picking 'openmethod'. I considered both. Also @specialize. If anyone had pushed for @openmethod before the article, I would almost certainly have given in. My reasoning was, I hope to promote the term 'method' as the standard name for polymorphism from outside, as opposed to vfunc. We usually say "virtual functions", rarely "virtual member functions". Membership is implicit. Rename, alias to old and have it deprecated. Keep around for a couple of releases, done! Deprecated, already? :-D Hmmm maybe...Let's see if anyone speaks in favor of just @method.
Re: Open Methods: From C++ to D
On Wednesday, 30 August 2017 at 15:10:03 UTC, Jean-Louis Leroy
wrote:
I sort of agree, and somewhat regret not picking 'openmethod'.
I considered both. Also @specialize. If anyone had pushed for
@openmethod before the article, I would almost certainly have
given in.
My reasoning was, I hope to promote the term 'method' as the
standard name for polymorphism from outside, as opposed to
vfunc. We usually say "virtual functions", rarely "virtual
member functions". Membership is implicit.
We had some discussion about what to name it in the original
announce thread, but I didn't want to get too focused on
bikeshedding the names and you had made good points. @method is
probably better than @specialize. Not sure what additional
information you get from @openmethod, given that you're already
importing from openmethods, but I don't really care that much.
One thing you didn't really cover is how seamlessly interacts
with normal polymorphism. For instance, what if to your first
example, I add the following function (note: without @method) and
adjust main as below. I see no reason why this shouldn't work.
But you wouldn't be able to create a string kick(Animal animal)
function since that is created by the mixin.
string kick(Dog dog) { return "ct bark"; }
void main()
{
updateMethods();
import std.stdio : writeln;
Animal snoopy = new Dog, hector = new Pitbull;
writeln("snoopy.kick(): ", snoopy.kick()); // bark
writeln("hector.kick(): ", hector.kick()); // bark an dbite
Dog lassie = new Dog;
writeln("lassie.kick(): ", lassie.kick()); // ct bark
}
Re: Open Methods: From C++ to D
On Wednesday, 30 August 2017 at 15:42:09 UTC, jmh530 wrote:
One thing you didn't really cover is how seamlessly interacts
with normal polymorphism. For instance, what if to your first
example, I add the following function (note: without @method)
and adjust main as below. I see no reason why this shouldn't
work. But you wouldn't be able to create a string kick(Animal
animal) function since that is created by the mixin.
string kick(Dog dog) { return "ct bark"; }
void main()
{
updateMethods();
import std.stdio : writeln;
Animal snoopy = new Dog, hector = new Pitbull;
writeln("snoopy.kick(): ", snoopy.kick()); // bark
writeln("hector.kick(): ", hector.kick()); // bark an dbite
Dog lassie = new Dog;
writeln("lassie.kick(): ", lassie.kick()); // ct bark
}
What happens here is that kick(Animal) is shadowed by kick(Dog).
kick(Animal) is a method but it appears to the user and the
compiler as an ordinary function - which is generally good. As
such it is eligible for UFCS. I would not recommend this sort of
coding, but it's everyone's choice, methods or not.
Likewise, methods can be overloaded (like here
https://github.com/jll63/openmethods.d/blob/1.0.0-rc.1/examples/matrix/source/matrix.d#L12).
A current limitation is that default arguments are not supported
(yet), although I think it's just a matter of putting the effort
in.
UFCS interacts nicely with methods because you can say a.plus(b)
even if 'plus' is an open method.
Re: Open Methods: From C++ to D
In the article it says:
Finally, main calls updateMethods. This should be done before
calling any method (typically first thing in main) and each
time a library containing methods is dynamically loaded or
unloaded.
If the something has to be done at the beginning, we have a tool
for that: static this (on module level). The
mixin(registerMethods); at the top should therefore mix in.
static this() { updateMethods(); }
It's never wrong: Calling it in main, too, will at most be
redundant. You can still call it manually, but for the part of
main, you cannot inadvertently forget it. You can still have
static this in that module as you may have multiple static this.
Re: Article: Writing Julia style multiple dispatch code in D
On Monday, 28 August 2017 at 13:19:19 UTC, Jean-Louis Leroy wrote:
On Thursday, 24 August 2017 at 23:50:21 UTC, data pulverizer
wrote:
I find OOP-polymorphic types ultimately unsatisfying, but I
don't know of anyway to write, compile and load a D script
with new types and methods on the fly into the same session.
That is why binding membership and polymorphism together is a
historical wrong turn. CLOS had it right but the world followed
the Simula/Smalltalk path because of a nice metaphor (objects
sending messages to each other).
My openmethods library allows you to add methods "from outside"
and also supports dynamic loading: you can add new methods to
existing classes and new classes to hierarchies that have
methods. See the blog post that just came up.
Thanks, just read it. Looks like a useful package. As you said it
is about being able to dispatch with polymorphism ... where
implicit promotions occur or explicit polymorphism is required.
One thing that confused me was examples like this ...
@method
Matrix _plus(DiagonalMatrix a, DiagonalMatrix b)
{
// just add the elements on diagonals
// return a DiagonalMatrix
}
Which is marked as returning a DiagonalMatrix rather than a
Matrix by polymorphism however the function is marked Matrix
return type.
You mentioned Julia in your article, however for clarity I would
point out that Julia doesn't have OOP-type polymorphism. There is
no notion of being able to do something like:
Animal snoopy = new Dog();
It's dispatch method is more like compile-time over as discussed
here https://github.com/dataPulverizer/dispatch-it-like-julia -
but you can recompile 'online' which I guess is what they mean by
"dynamic dispatch" - but there's no polymorphism. Type
hierarchies are basically for dispatching methods with varying
amounts of specificity which can be accomplished using templates
and only explicitly defined type conversions from one concrete
type to another are allowed.
Re: Released vibe.d 0.8.1
On Wednesday, 30 August 2017 at 07:47:53 UTC, Sönke Ludwig wrote: Apart from removing the old vibe-d:diet package in favor of diet-ng, this release most notably contains a number of performance improvements in the HTTP server, as well as improvements and fixes in the WebSocket code. Furthermore, initial OpenSSL 1.1.x support has been added and a few @safe related issues introduced in 0.8.0 have been fixed. Change log: https://vibed.org/blog/posts/vibe-release-0.8.1 DUB package: https://code.dlang.org/packages/vibe-d/0.8.1 Debian packages are on their way too :-) (pending approval from our archive masters). Granted, this is most useful for Vibe.d-using software that wants to be in Debian. Now, the only thing I am missing in Vibe is a good interface to PostgreSQL, because in some circumstances MongoDB is just a very bad choice. (Postgres even outperforms it in my testcase, and PG supports JSON/BSON as well now). DPQ2[1] looks very promising though :-) Thank you for making Vibe.d! [1]: https://github.com/denizzzka/dpq2
Re: Article: Writing Julia style multiple dispatch code in D
On Wednesday, 30 August 2017 at 16:45:19 UTC, data pulverizer
wrote:
You mentioned Julia in your article, however for clarity I
would point out that Julia doesn't have OOP-type polymorphism.
There is no notion of being able to do something like:
Animal snoopy = new Dog();
p.s. my bad, I was wrong about that! Turns out you can do
something like this in Julia (apologies for the Julia code in a D
forum):
abstract type Animal end
struct Dog <: Animal end
struct Cat <: Animal end
x = Array{Animal}(3)
x[1] = Cat(); x[2] = Dog(); x[3] = Cat();
x # returns
3-element Array{Animal,1}:
Cat()
Dog()
Cat()
Which is polymorphism
Re: Article: Writing Julia style multiple dispatch code in D
On Wednesday, 30 August 2017 at 17:14:37 UTC, data pulverizer
wrote:
On Wednesday, 30 August 2017 at 16:45:19 UTC, data pulverizer
wrote:
You mentioned Julia in your article, however for clarity I
would point out that Julia doesn't have OOP-type polymorphism.
There is no notion of being able to do something like:
Animal snoopy = new Dog();
p.s. my bad, I was wrong about that! Turns out you can do
something like this in Julia (apologies for the Julia code in a
D forum):
abstract type Animal end
struct Dog <: Animal end
struct Cat <: Animal end
x = Array{Animal}(3)
x[1] = Cat(); x[2] = Dog(); x[3] = Cat();
x # returns
3-element Array{Animal,1}:
Cat()
Dog()
Cat()
p.p.s
typeof(x[1]) # returns Cat
so it isn't really polymorphism - the object is never converted
to the "parent" type! Lol ... sorry for the confusion!
Which is polymorphism
Re: Open Methods: From C++ to D
On Wednesday, 30 August 2017 at 16:37:20 UTC, Q. Schroll wrote:
In the article it says:
Finally, main calls updateMethods. This should be done before
calling any method (typically first thing in main) and each
time a library containing methods is dynamically loaded or
unloaded.
If the something has to be done at the beginning, we have a
tool for that: static this (on module level). The
mixin(registerMethods); at the top should therefore mix in.
static this() { updateMethods(); }
It's never wrong: Calling it in main, too, will at most be
redundant. You can still call it manually, but for the part of
main, you cannot inadvertently forget it. You can still have
static this in that module as you may have multiple static this.
We had a discussion about automating the call to updateMethods
but I don't think that anybody thought of putting it in
registerMethods. It might work. I'll look into it. Thanks for the
suggestion...
Re: Article: Writing Julia style multiple dispatch code in D
On Wednesday, 30 August 2017 at 16:45:19 UTC, data pulverizer
wrote:
One thing that confused me was examples like this ...
@method
Matrix _plus(DiagonalMatrix a, DiagonalMatrix b)
{
// just add the elements on diagonals
// return a DiagonalMatrix
}
Which is marked as returning a DiagonalMatrix rather than a
Matrix by polymorphism however the function is marked Matrix
return type.
Indeed returning a DiagonalMatrix would work, and is marginally
more useful (in case you want to call the specialization
directly). I'll update the example. Thanks.
Re: Article: Writing Julia style multiple dispatch code in D
On Wednesday, 30 August 2017 at 17:16:59 UTC, data pulverizer wrote: p.p.s typeof(x[1]) # returns Cat so it isn't really polymorphism - the object is never converted to the "parent" type! Lol ... sorry for the confusion! Which is polymorphism Haha what I know of Julia is what wikipedia says. Confusing indeed...
Re: Article: Writing Julia style multiple dispatch code in D
On Wednesday, 30 August 2017 at 17:29:42 UTC, Jean-Louis Leroy wrote: On Wednesday, 30 August 2017 at 17:16:59 UTC, data pulverizer wrote: p.p.s typeof(x[1]) # returns Cat so it isn't really polymorphism - the object is never converted to the "parent" type! Lol ... sorry for the confusion! Haha what I know of Julia is what wikipedia says. Confusing indeed... To be fair they say it is parametric polymorphism - dispatching basically template style, rather than subtyping polymorphism (OOP type), (more wikipedia https://en.wikipedia.org/wiki/Polymorphism_(computer_science)). The reason I have never really been comfortable with sub-typing is that the polymorphic types are a black-box, my preference is certainly for parametric type polymorphism. The main disadvantage with parametric polymorphism in compiled languages is that array containers only operate under subtyping polymorphism. In the above Julia example the array container is essentially acting exactly like a compile-time dispatch (overloaded) function - the array is dispatching on a specific set of types defined by the abstract parent type. That kind of construct would be very desirable to me in D. The closest such thing you can have to that in D are tuples.
Re: Open Methods: From C++ to D
On Wednesday, 30 August 2017 at 17:24:55 UTC, Jean-Louis Leroy wrote: We had a discussion about automating the call to updateMethods but I don't think that anybody thought of putting it in registerMethods. It might work. I'll look into it. Thanks for the suggestion... Ali had suggested something similar[1]. I think your concern was that it would get called multiple times, but shared static module constructors runs once a program (static module constructor runs once per thread). [1] http://forum.dlang.org/post/okljj1$ktb$1...@digitalmars.com
Re: Open Methods: From C++ to D
On Wednesday, 30 August 2017 at 15:59:32 UTC, Jean-Louis Leroy
wrote:
What happens here is that kick(Animal) is shadowed by
kick(Dog). kick(Animal) is a method but it appears to the user
and the compiler as an ordinary function - which is generally
good. As such it is eligible for UFCS. I would not recommend
this sort of coding, but it's everyone's choice, methods or not.
Likewise, methods can be overloaded (like here
https://github.com/jll63/openmethods.d/blob/1.0.0-rc.1/examples/matrix/source/matrix.d#L12).
A current limitation is that default arguments are not
supported (yet), although I think it's just a matter of putting
the effort in.
UFCS interacts nicely with methods because you can say
a.plus(b) even if 'plus' is an open method.
I can submit this as an issue on the github page, but I figured
I'd mention it here in case there was some easy fix.
I tried installing the latest release from github. Compiling
(Windows 7 on DMD with default options) the simple program below
import openmethods;
mixin(registerMethods);
void main()
{
}
gives me the errors:
..\..\dubFolder\openmethods.d-1.0.0-rc.1\source\openmethods.d(970,21): Error: ca
nnot implicitly convert expression h of type ulong to uint
..\..\dubFolder\openmethods.d-1.0.0-rc.1\source\openmethods.d(1076,34): Error: c
annot implicitly convert expression dim of type ulong to uint
..\..\dubFolder\openmethods.d-1.0.0-rc.1\source\openmethods.d(1177,23): Error: c
annot implicitly convert expression h of type ulong to uint
dmd failed with exit code 1.
The error at line 1076 can be fixed by changing the type of dim
in the function to size_t. I couldn't fix the other errors. I
tried having the hash function return size_t also, but that just
causes other problems.
Re: Open Methods: From C++ to D
On Wednesday, 30 August 2017 at 18:05:38 UTC, jmh530 wrote: On Wednesday, 30 August 2017 at 17:24:55 UTC, Jean-Louis Leroy wrote: We had a discussion about automating the call to updateMethods but I don't think that anybody thought of putting it in registerMethods. It might work. I'll look into it. Thanks for the suggestion... Ali had suggested something similar[1]. I think your concern was that it would get called multiple times, but shared static module constructors runs once a program (static module constructor runs once per thread). [1] http://forum.dlang.org/post/okljj1$ktb$1...@digitalmars.com Ah yes...So the problem is that registerMethods emits static ctors that fill data structures representing the methods and the specializations. They have to run - all of them - before updateMethods. Thus, sadly Q's suggestion won't work.
Re: Open Methods: From C++ to D
On Wednesday, 30 August 2017 at 18:20:46 UTC, Jean-Louis Leroy wrote: On Wednesday, 30 August 2017 at 18:05:38 UTC, jmh530 wrote: On Wednesday, 30 August 2017 at 17:24:55 UTC, Jean-Louis Leroy wrote: We had a discussion about automating the call to updateMethods but I don't think that anybody thought of putting it in registerMethods. It might work. I'll look into it. Thanks for the suggestion... Ali had suggested something similar[1]. I think your concern was that it would get called multiple times, but shared static module constructors runs once a program (static module constructor runs once per thread). [1] http://forum.dlang.org/post/okljj1$ktb$1...@digitalmars.com Ah yes...So the problem is that registerMethods emits static ctors that fill data structures representing the methods and the specializations. They have to run - all of them - before updateMethods. Thus, sadly Q's suggestion won't work. Yes I remember now...even if we arrange to put the call to updateMethods in its own static ctor, coming after all the other static ctors, we don't know if there will be more modules with more methods afterwards. So we would have to do the updateMethods work each time, lest this module is the last. And updateMethods is costly: not only does it figure out all the dispatch tables, it also calculates a perfect hash (if @mptr is used) using a random algorithm.
Re: Article: Writing Julia style multiple dispatch code in D
On Wednesday, 30 August 2017 at 17:57:49 UTC, data pulverizer wrote: The reason I have never really been comfortable with sub-typing is that the polymorphic types are a black-box, my preference is certainly for parametric type polymorphism. The main disadvantage with parametric polymorphism in compiled languages is that array containers only operate under subtyping polymorphism. In the above Julia example the array container is essentially acting exactly like a compile-time dispatch (overloaded) function - the array is dispatching on a specific set of types defined by the abstract parent type. That kind of construct would be very desirable to me in D. The closest such thing you can have to that in D are tuples. I suspect the reason you can't have parametric typed array containers in statically typed compiled languages is that underneath, they are doubly/linked lists, and there is no way of resolving the types at the end of the array, and allowing appending at the same time ... someone correct me if I am wrong.
Re: Open Methods: From C++ to D
On Wednesday, 30 August 2017 at 18:16:47 UTC, jmh530 wrote:
I tried installing the latest release from github. Compiling
(Windows 7 on DMD with default options) the simple program below
import openmethods;
mixin(registerMethods);
void main()
{
}
gives me the errors:
Gosh Windows I completely forgot about that...I'll take a look
tonight.
Re: DlangUI v0.7.60 released
On Wednesday, 30 August 2017 at 07:44:54 UTC, Vadim Lopatin wrote: [snip] From what I've followed, you sure update the project often! Perhaps more often than what Phobos is upgraded, by all developers combined. Great work.
Re: Article: Writing Julia style multiple dispatch code in D
On Wednesday, 30 August 2017 at 18:48:58 UTC, data pulverizer wrote: I suspect the reason you can't have parametric typed array containers in statically typed compiled languages is that underneath, they are doubly/linked lists, and there is no way of resolving the types at the end of the array, and allowing appending at the same time ... someone correct me if I am wrong. The only other way would be to create a wrapper interface and classes for each type you want to include in the array, which takes you back to sub-type (OOP) polymorphism.
Re: Article: Writing Julia style multiple dispatch code in D
On Wednesday, 30 August 2017 at 17:16:59 UTC, data pulverizer
wrote:
On Wednesday, 30 August 2017 at 17:14:37 UTC, data pulverizer
wrote:
On Wednesday, 30 August 2017 at 16:45:19 UTC, data pulverizer
wrote:
You mentioned Julia in your article, however for clarity I
would point out that Julia doesn't have OOP-type
polymorphism. There is no notion of being able to do
something like:
Animal snoopy = new Dog();
p.s. my bad, I was wrong about that! Turns out you can do
something like this in Julia (apologies for the Julia code in
a D forum):
abstract type Animal end
struct Dog <: Animal end
struct Cat <: Animal end
x = Array{Animal}(3)
x[1] = Cat(); x[2] = Dog(); x[3] = Cat();
x # returns
3-element Array{Animal,1}:
Cat()
Dog()
Cat()
p.p.s
typeof(x[1]) # returns Cat
so it isn't really polymorphism - the object is never converted
to the "parent" type! Lol ... sorry for the confusion!
Which is polymorphism
After mulling over this example, I don't see how this proves that
Julia does *not* support run time polymorphism. On the contrary.
If you translate this to D you get the same result by the way:
import std.stdio;
class Animal {}
class Cat : Animal {}
void main()
{
Animal[] array;
array ~= new Cat();
writeln(typeid(array[0])); // typeid.Cat
}
Re: Article: Writing Julia style multiple dispatch code in D
On Wednesday, 30 August 2017 at 20:40:38 UTC, Jean-Louis Leroy
wrote:
After mulling over this example, I don't see how this proves
that Julia does *not* support run time polymorphism. On the
contrary. If you translate this to D you get the same result by
the way:
import std.stdio;
class Animal {}
class Cat : Animal {}
void main()
{
Animal[] array;
array ~= new Cat();
writeln(typeid(array[0])); // typeid.Cat
}
writeln(typeof(array[0]).stringof); // this is an Animal
The return type of any item in the array would be of type Animal.
You would have to do a type cast to really get type Cat.
In Julia there is no real notion that any item in Array{Animal,
1} is an Animal. Their types are never masked by Animal, which
only really serves as a way of dispatching types to the array,
unlike in D where the actual type is Animal. However if your
multi-methods is dispatching methods using typeid (which I am
guessing is the case) this distinction no longer matters.
It may be better to say that typeof() in Julia is a run-time type
and there is no notion of typeof() as in D.
In the light of this I think your package just became more
interesting to me.
Re: Article: Writing Julia style multiple dispatch code in D
On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer wrote: On Wednesday, 30 August 2017 at 20:40:38 UTC, Jean-Louis Leroy wrote: After mulling over this example, I don't see how this proves that Julia does *not* support run time polymorphism. On the contrary. In that case you are right! Julia is doing run-time polymorphism and dynamic multiple dispatch ... because there is no sense in which compile time types exist. Functions are pre-compiled but types are always run time. Phew, I think got there in the end
Re: Article: Writing Julia style multiple dispatch code in D
On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer wrote: In the light of this I think your package just became more interesting to me. I think that your work and mine are complementary :-)
Re: D as a Better C
How should command-line arguments be used in better C ? Looping
through argv seems to print environment variables :
import core.stdc.stdio;
extern(C) int main(int argc, char*[] argv, char*[] env)
{
foreach(i; 0 .. argc)
printf("arg %d: %s\n", i, argv[i]);
return 0;
}
Compiling with v2.076.0-b2-dirty on Lubuntu 14.04 and running
with one argument outputs the following :
arg 0: XDG_VTNR=7
arg 1: LC_PAPER=fr_FR.UTF-8
Re: D as a Better C
On Wednesday, 30 August 2017 at 22:22:23 UTC, Azi Hassan wrote:
How should command-line arguments be used in better C ? Looping
through argv seems to print environment variables :
import core.stdc.stdio;
extern(C) int main(int argc, char*[] argv, char*[] env)
{
foreach(i; 0 .. argc)
printf("arg %d: %s\n", i, argv[i]);
return 0;
}
Compiling with v2.076.0-b2-dirty on Lubuntu 14.04 and running
with one argument outputs the following :
arg 0: XDG_VTNR=7
arg 1: LC_PAPER=fr_FR.UTF-8
Forgot to mention, char*[] env was only for testing purposes. The
code still produces the same output with char*[] env omitted.
Re: Article: Writing Julia style multiple dispatch code in D
On Wednesday, 30 August 2017 at 22:10:38 UTC, Jean-Louis Leroy
wrote:
On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer
wrote:
In the light of this I think your package just became more
interesting to me.
I think that your work and mine are complementary :-)
Yes, one of the problems I have been trying to solve is the best
way of writing a table structure similar to a data frame in R.
Till now polymorphism never really appealed to me but with your
package writing methods for such structures become much nicer, a
simple prototype could be this:
```
import std.stdio: writeln;
class GenericVector{}
class Vector(T): GenericVector{
T[] data;
this(T[] data)
{
this.data = data;
}
}
void main()
{
GenericVector[] myTable = [new Vector!double([1., 2., 3.]), new
Vector!string(["a", "b", "c"])];
writeln(typeid(myTable[0]));
writeln(typeid(myTable[1]));
}
```
Then your openmethods package can dispatch on these types of
objects. Very cool!
Re: Article: Writing Julia style multiple dispatch code in D
On Wednesday, 30 August 2017 at 22:10:38 UTC, Jean-Louis Leroy
wrote:
On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer
wrote:
In the light of this I think your package just became more
interesting to me.
I think that your work and mine are complementary :-)
Here is one strange difference between inheriting from an
interface and a class:
```
interface Animal{}
class Dog: Animal{}
class Cat: Animal{}
void main()
{
Animal[] x;
x ~= new Cat();
x ~= new Dog();
x ~= new Cat();
writeln(typeid(x[0])); // Gives Animal
}
```
But if Animal is set to a class the typeid gives Cat, why does
this happen? Does this mean that inheriting from an interface is
not really polymorphism?
Re: D as a Better C
On Wednesday, 30 August 2017 at 22:22:23 UTC, Azi Hassan wrote: extern(C) int main(int argc, char*[] argv, char*[] env) That's a D array of pointers. A D array is larger than a C "array" argument, thus you're skipping past it. The correct declaration is (int argc, char** argv, char** env). (I'd argue that is the correct way to write it in C too, that's how I always do and it works there. But I just loathe C's arrays anyway.)
Re: Article: Writing Julia style multiple dispatch code in D
On Wednesday, 30 August 2017 at 22:30:12 UTC, data pulverizer
wrote:
On Wednesday, 30 August 2017 at 22:10:38 UTC, Jean-Louis Leroy
wrote:
On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer
wrote:
In the light of this I think your package just became more
interesting to me.
I think that your work and mine are complementary :-)
Here is one strange difference between inheriting from an
interface and a class:
```
interface Animal{}
class Dog: Animal{}
class Cat: Animal{}
void main()
{
Animal[] x;
x ~= new Cat();
x ~= new Dog();
x ~= new Cat();
writeln(typeid(x[0])); // Gives Animal
}
```
But if Animal is set to a class the typeid gives Cat, why does
this happen? Does this mean that inheriting from an interface
is not really polymorphism?
Is there a reason you're not using
writeln(typeid(typeof(x[0])));
I pretty much always write it that way.
Re: Article: Writing Julia style multiple dispatch code in D
On Wednesday, 30 August 2017 at 22:30:12 UTC, data pulverizer
wrote:
On Wednesday, 30 August 2017 at 22:10:38 UTC, Jean-Louis Leroy
wrote:
On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer
wrote:
In the light of this I think your package just became more
interesting to me.
I think that your work and mine are complementary :-)
Here is one strange difference between inheriting from an
interface and a class:
```
interface Animal{}
class Dog: Animal{}
class Cat: Animal{}
void main()
{
Animal[] x;
x ~= new Cat();
x ~= new Dog();
x ~= new Cat();
writeln(typeid(x[0])); // Gives Animal
}
```
But if Animal is set to a class the typeid gives Cat, why does
this happen? Does this mean that inheriting from an interface
is not really polymorphism?
I noticed that too. Still scratching my head.
Re: Open Methods: From C++ to D
On Wednesday, 30 August 2017 at 18:16:47 UTC, jmh530 wrote: ..\..\dubFolder\openmethods.d-1.0.0-rc.1\source\openmethods.d(970,21): Error: ca nnot implicitly convert expression h of type ulong to uint ..\..\dubFolder\openmethods.d-1.0.0-rc.1\source\openmethods.d(1076,34): Error: c annot implicitly convert expression dim of type ulong to uint ..\..\dubFolder\openmethods.d-1.0.0-rc.1\source\openmethods.d(1177,23): Error: c annot implicitly convert expression h of type ulong to uint dmd failed with exit code 1. The error at line 1076 can be fixed by changing the type of dim in the function to size_t. I couldn't fix the other errors. I tried having the hash function return size_t also, but that just causes other problems. Fixed. Committed to master and it should show up in dub soon. Gosh, all that mind bending meta polymorphic mixin reflection multi-dimensional fu and then fall prey to ints and uints and size_ts. Sobering...
Re: Article: Writing Julia style multiple dispatch code in D
On Wednesday, 30 August 2017 at 22:49:54 UTC, jmh530 wrote:
On Wednesday, 30 August 2017 at 22:30:12 UTC, data pulverizer
wrote:
On Wednesday, 30 August 2017 at 22:10:38 UTC, Jean-Louis Leroy
wrote:
On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer
wrote:
In the light of this I think your package just became more
interesting to me.
I think that your work and mine are complementary :-)
Here is one strange difference between inheriting from an
interface and a class:
```
interface Animal{}
class Dog: Animal{}
class Cat: Animal{}
void main()
{
Animal[] x;
x ~= new Cat();
x ~= new Dog();
x ~= new Cat();
writeln(typeid(x[0])); // Gives Animal
}
```
But if Animal is set to a class the typeid gives Cat, why does
this happen? Does this mean that inheriting from an interface
is not really polymorphism?
Is there a reason you're not using
writeln(typeid(typeof(x[0])));
I pretty much always write it that way.
typeid() will give you the run-time type while typeof() gives the
declared (compile time) type, typeid(typeof()) will not give you
the run-time type - which in our case is what we want if we are
using sub-typing polymorphism.
Re: DlangUI v0.7.60 released
On Wednesday, 30 August 2017 at 07:44:54 UTC, Vadim Lopatin wrote: There are a lot of improvements in DlangIDE since last announcement. [...] Is there any themes to download? It's a bit ugly in windows
Re: Open Methods: From C++ to D
On Wednesday, 30 August 2017 at 23:40:59 UTC, Jean-Louis Leroy wrote: Fixed. Committed to master and it should show up in dub soon. Gosh, all that mind bending meta polymorphic mixin reflection multi-dimensional fu and then fall prey to ints and uints and size_ts. Sobering... Ha. Cheers.
Re: Article: Writing Julia style multiple dispatch code in D
On Wednesday, 30 August 2017 at 23:45:13 UTC, data pulverizer wrote: typeid() will give you the run-time type while typeof() gives the declared (compile time) type, typeid(typeof()) will not give you the run-time type - which in our case is what we want if we are using sub-typing polymorphism. Ah, news to me. Also, I have pushed my branch of the distributions work I've done to my fork of dstats. I haven't submitted a PR yet because I had submitted some other small fixes and want to see how they go (and maybe adjust some of the work I've done in response). https://github.com/jmh530/dstats/tree/jmh530-addDistributions
Re: Article: Writing Julia style multiple dispatch code in D
On 31.08.2017 01:34, Jean-Louis Leroy wrote:
On Wednesday, 30 August 2017 at 22:30:12 UTC, data pulverizer wrote:
On Wednesday, 30 August 2017 at 22:10:38 UTC, Jean-Louis Leroy wrote:
On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer wrote:
In the light of this I think your package just became more
interesting to me.
I think that your work and mine are complementary :-)
Here is one strange difference between inheriting from an interface
and a class:
```
interface Animal{}
class Dog: Animal{}
class Cat: Animal{}
void main()
{
Animal[] x;
x ~= new Cat();
x ~= new Dog();
x ~= new Cat();
writeln(typeid(x[0])); // Gives Animal
}
```
But if Animal is set to a class the typeid gives Cat, why does this
happen? Does this mean that inheriting from an interface is not really
polymorphism?
I noticed that too. Still scratching my head.
typeid(Interface) has been subject to a number of bugzilla reports, e.g.
https://issues.dlang.org/show_bug.cgi?id=13833 and
https://issues.dlang.org/show_bug.cgi?id=14612.
