Re: Open Methods: From C++ to D

2017-08-31 Thread jmh530 via Digitalmars-d-announce 
On Thursday, 31 August 2017 at 16:55:17 UTC, Jean-Louis Leroy 
wrote:


Indeed I misunderstood.

Well, I am very pleased that my stuff interacts well with the 
rest of the language - I strive for that. However, I found that 
it is difficult to get people to open their mind to the idea of 
open methods, initially. Unless they come from Lisp, 
polymorphism and membership are almost indissociable for them. 
I often have to jump three hurdles.




I can see that it's a uphill battle, but there's a lot to like 
about it as well for those who listen.


Maybe it would be a good idea to allow the @method to take an 
argument, like @method(Animal), then you could mixin

string kick(virtual!Animal);
without having to define kick.

I think the ideal would be if you could just write something like 
below:

@string(Animal)
string kick(virtual!Dog dog) { return "bark"; }
but I don't really know how to get that to work.

Re: GitBook about D on embedded ARM Linux

2017-08-31 Thread solidstate1991 via Digitalmars-d-announce 

On Thursday, 31 August 2017 at 14:43:22 UTC, thinwybk wrote:
There is no single point of entry to find information about how 
to use D on ARM Linux. I created a small project on GitHub 
https://github.com/fkromer/d-on-embedded-linux-arm which shall 
enable absolute beginners (of embedded Linux and D) to get 
started as fast as possible. The project is in sync with a 
GitBook page 
https://fkromer.gitbooks.io/d-on-embedded-linux-arm/content/. 
The BeagleBone Black https://beagleboard.org/black is used as 
exemplary development board (a lot of information and tutorials 
available e.g. here http://exploringbeaglebone.com/, board 
hardware is extensible easily and in a modular manner with 
"capes" https://beagleboard.org/cape 
http://elinux.org/Beagleboard:BeagleBone_Capes).


I'm interested in it as I'm planning to making my graphics engine 
usable on as many platforms as possible.

Re: Open Methods: From C++ to D

2017-08-31 Thread EntangledQuanta via Digitalmars-d-announce 
On Thursday, 31 August 2017 at 23:21:03 UTC, Jean-Louis Leroy 
wrote:
On Thursday, 31 August 2017 at 21:42:50 UTC, EntangledQuanta 
wrote:

It's fixed now, in master and in release v1.0.0-rc.2.


I'll check it out. I don't think the last errors I was getting 
were due to the sizing issues though, so is that all you fixed 
or was there some other stuff related to windows?


Only size issues. Two lines in fact, see 
https://github.com/jll63/openmethods.d/commit/b63a88132e639bb23bb7cb305f4457450f865c6a but errors can cascade. I ran a few examples using the current dmd on Windows. Worked OK.


It would be nice to have the Windows equivalent of 
dev/run-everything, maybe someone can PR me that?




I'll try again at some point. I haven't got around to messing 
with it again. I was testing it out on something and ran in to 
those errors, fixed them, then ran in to some more and just went 
a different direction. I will try to start using them more at 
some point as I think the concept, at least, can be useful. I 
haven't used it yet though to know just how useful. I like how it 
extends object functionality without having to mess directly with 
the objects. I think the more complex the project the more useful 
they become. What is good though is that one can mingle oop and 
openmethods and finding a proper balance should result in a 
simpler design.


Yeah, but one should always be allowed to shoot themselves in 
the foot.


I agree, wholeheartedly. In C++, yomm11 has macros that you can 
use to make a specific override or an entire method friend of a 
class. But alas no friendship in D.


Yeah, D does some weird things. For all it's power it just screws 
the pooch in certain cases that really casts a shadow on what 
might be a great design. Usually there are work-arounds, but they 
always fill like a kludge and require an excessive amount of code 
to do something that could be done very simple, all in the name 
of XXX(whatever XXX is: backwards compatibility, "safety"(no guns 
on the beach! PERIOD! Even if the beach is full of alligators! We 
don't want anyone shooting anyone else! Better that they be eaten 
by alligators!), or some other "excuse").

Re: Open Methods: From C++ to D

2017-08-31 Thread Jean-Louis Leroy via Digitalmars-d-announce 
On Thursday, 31 August 2017 at 21:42:50 UTC, EntangledQuanta 
wrote:

It's fixed now, in master and in release v1.0.0-rc.2.


I'll check it out. I don't think the last errors I was getting 
were due to the sizing issues though, so is that all you fixed 
or was there some other stuff related to windows?


Only size issues. Two lines in fact, see 
https://github.com/jll63/openmethods.d/commit/b63a88132e639bb23bb7cb305f4457450f865c6a but errors can cascade. I ran a few examples using the current dmd on Windows. Worked OK.


It would be nice to have the Windows equivalent of 
dev/run-everything, maybe someone can PR me that?


Yeah, but one should always be allowed to shoot themselves in 
the foot.


I agree, wholeheartedly. In C++, yomm11 has macros that you can 
use to make a specific override or an entire method friend of a 
class. But alas no friendship in D.

Re: Open Methods: From C++ to D

2017-08-31 Thread EntangledQuanta via Digitalmars-d-announce 
On Thursday, 31 August 2017 at 21:02:26 UTC, Jean-Louis Leroy 
wrote:
On Thursday, 31 August 2017 at 20:42:36 UTC, EntangledQuanta 
wrote:

On Wednesday, 30 August 2017 at 18:16:47 UTC, jmh530 wrote:

[...]


I was getting similar errors and simply added a 
cast(size_t)[used in the indexing, as he used ulongs for 
indexes rather than size_t] to all those you mention. After 
that I got more errors that I can't recall now but was much 
more cryptic. I did updateMethods and added the mixin but 
things wern't working so I gave up. Seems like a nice idea, 
although, the downside that I see is one doesn't get 
encapsulation.


It's fixed now, in master and in release v1.0.0-rc.2.


I'll check it out. I don't think the last errors I was getting 
were due to the sizing issues though, so is that all you fixed or 
was there some other stuff related to windows?


Actually not getting encapsulation is good. With vfuncs, if you 
want polymorphism you get access to private parts, need it or 
not. And most of the time you neither need nor want it.


If you need polymorphism and privileged access, you should use 
a vfunc but it's usually a sign of bad design, because a vfunc 
is meant to be overridden. And the override won't have access 
to the private parts so you may end up changing access from 
private to protected and usually trouble follows.


I can imagine legitimate cases though. Fox example, the 
DiagonalMatrix addition example. In that case you can write a 
public final member function that performs addition using 
privileged access and call that from the 2-method 'plus'.




Yeah, but one should always be allowed to shoot themselves in the 
foot. You never know when you might do it. Maybe an alligator has 
attached itself to your foot and is about to drag you under water?




ANother approach is to write the fvunc - or the 1-method - in 
terms of the public interface. Usually it's feasible and yields 
a better design.

Re: Open Methods: From C++ to D

2017-08-31 Thread Jean-Louis Leroy via Digitalmars-d-announce 
On Thursday, 31 August 2017 at 20:42:36 UTC, EntangledQuanta 
wrote:

On Wednesday, 30 August 2017 at 18:16:47 UTC, jmh530 wrote:
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.


I was getting similar errors and simply added a 
cast(size_t)[used in the indexing, as he used ulongs for 
indexes rather than size_t] to all those you mention. After 
that I got more errors that I can't recall now but was much 
more cryptic. I did updateMethods and added the mixin but 
things wern't working so I gave up. Seems like a nice idea, 
although, the downside that I see is one doesn't get 
encapsulation.


It's fixed now, in master and in release v1.0.0-rc.2.

Actually not getting encapsulation is good. With vfuncs, if you 
want polymorphism you get access to private parts, need it or 
not. And most of the time you neither need nor want it.


If you need polymorphism and privileged access, you should use a 
vfunc but it's usually a sign of bad design, because a vfunc is 
meant to be overridden. And the override won't have access to the 
private parts so you may end up changing access from private to 
protected and usually trouble follows.


I can imagine legitimate cases though. Fox example, the 
DiagonalMatrix addition example. In that case you can write a 
public final member function that performs addition using 
privileged access and call that from the 2-method 'plus'.




ANother approach is to write the fvunc - or the 1-method - in 
terms of the public interface. Usually it's feasible and yields a 
better design.

Re: Open Methods: From C++ to D

2017-08-31 Thread EntangledQuanta via Digitalmars-d-announce 

On Wednesday, 30 August 2017 at 18:16:47 UTC, jmh530 wrote:
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.


I was getting similar errors and simply added a cast(size_t)[used 
in the indexing, as he used ulongs for indexes rather than 
size_t] to all those you mention. After that I got more errors 
that I can't recall now but was much more cryptic. I did 
updateMethods and added the mixin but things wern't working so I 
gave up. Seems like a nice idea, although, the downside that I 
see is one doesn't get encapsulation.

Re: Released vibe.d 0.8.1

2017-08-31 Thread Daniel Kozak via Digitalmars-d-announce 
Same here.  We are moving from mongo to postgresql. And we are going to
rewrite our geolocation services from C# and mongo to D(vibe.d) and
PostgreSQL

Dne 31. 8. 2017 7:15 odpoledne napsal uživatel "Matthias Klumpp via
Digitalmars-d-announce" :

On Thursday, 31 August 2017 at 11:56:53 UTC, aberba wrote:

> On Wednesday, 30 August 2017 at 16:53:40 UTC, Matthias Klumpp wrote:
>
>> 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
>>
>
> Even with mysql (using mysql-native), the absent of something like
>
> struct User {
> @optional int userName; //its ok if row doesn't have this column
> @as("phone_number") string phoneNumber;
> 
> }
>
> User[] users;
> 
> foreach(row; ...)
> {
> users ~= row.toStruct!User;
> }
> 
>

I would love that :-)


MongoDB has facilities for these stuff automatically thats why using it
> seem convenient and speeds up stuff.
>

Yeah, it speeds up development, but that doesn't help much if Mongo
swallows your data or messes up replication, or if your data by its nature
simply does not fit a document store well.
I've found Postgres to be very reliable and also very fast in the past, and
- in large part thanks to Vibe.d - I am using Mongo now in a test
deployment instead of it. I don't feel comfortable at all in continuing to
use it though, which is unfortunate, since the development speed with it is
quite high.

Re: D on Tiobe Index

2017-08-31 Thread Daniel Kozak via Digitalmars-d-announce 
They have changed way how is index compute. They do this many times in
history,  so there is almost zero value in this graph

Dne 31. 8. 2017 6:42 odpoledne napsal uživatel "SrMordred via
Digitalmars-d-announce" :

On Thursday, 31 August 2017 at 14:57:28 UTC, bitwise wrote:

> https://www.tiobe.com/tiobe-index/d/
>

What happened in 2009?

Re: D on Tiobe Index

2017-08-31 Thread bitwise via Digitalmars-d-announce 

On Thursday, 31 August 2017 at 16:37:35 UTC, SrMordred wrote:

On Thursday, 31 August 2017 at 14:57:28 UTC, bitwise wrote:

https://www.tiobe.com/tiobe-index/d/


What happened in 2009?


My first thought was that it was related to the D1 -> D2 
transition, but that wasn't it. Considering that I had to ask for 
the graph to be generated though, I figured that it may have been 
omitted on purpose due to low sample size, i.e. noisy results. I 
wouldn't worry too much about it.

Re: D on Tiobe Index

2017-08-31 Thread Max Haughton via Digitalmars-d-announce 

On Thursday, 31 August 2017 at 16:37:35 UTC, SrMordred wrote:

What happened in 2009?


Probably other languages improving rather than D usage declining. 
2009 is (approximately) the year that javascript began it's rise 
up the index (Node.js was released in 2009).

Re: Released vibe.d 0.8.1

2017-08-31 Thread Matthias Klumpp via Digitalmars-d-announce 

On Thursday, 31 August 2017 at 11:56:53 UTC, aberba wrote:
On Wednesday, 30 August 2017 at 16:53:40 UTC, Matthias Klumpp 
wrote:
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


Even with mysql (using mysql-native), the absent of something 
like


struct User {
@optional int userName; //its ok if row doesn't have this 
column

@as("phone_number") string phoneNumber;

}

User[] users;

foreach(row; ...)
{
users ~= row.toStruct!User;
}



I would love that :-)

MongoDB has facilities for these stuff automatically thats why 
using it seem convenient and speeds up stuff.


Yeah, it speeds up development, but that doesn't help much if 
Mongo swallows your data or messes up replication, or if your 
data by its nature simply does not fit a document store well.
I've found Postgres to be very reliable and also very fast in the 
past, and - in large part thanks to Vibe.d - I am using Mongo now 
in a test deployment instead of it. I don't feel comfortable at 
all in continuing to use it though, which is unfortunate, since 
the development speed with it is quite high.

Re: Open Methods: From C++ to D

2017-08-31 Thread Jean-Louis Leroy via Digitalmars-d-announce 

On Thursday, 31 August 2017 at 14:52:43 UTC, jmh530 wrote:
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 had a chance to try out what I had suggested above and it 
behaves exactly as I would have expected (i.e. it prints the 
line "lassie.kick(): ctbark").


You seemed to emphasize UFCS in your response, but that really 
wasn't what I was intending to focus on. I just as easily could 
have re-written Dog as below and compiled the program and it 
would have printed the same thing. Similarly, any Dog or 
Pitbull type that call kick would return "ctbark", just Animals 
would return the original results.


class Dog : Animal
{
final string kick()
{
return "ctbark";
}
}

My point is one can easily mix your openmethods's dynamic 
dispatch and D's static dispatch. That seems like a great thing 
that you could emphasize. Simply stated: if you use 
openmethods, you're not forced to only use openmethods. If you 
know the type at compile-time, then you can use it. It's only 
if you want to dynamically dispatch it that you would need 
openmethods.


Indeed I misunderstood.

Well, I am very pleased that my stuff interacts well with the 
rest of the language - I strive for that. However, I found that 
it is difficult to get people to open their mind to the idea of 
open methods, initially. Unless they come from Lisp, polymorphism 
and membership are almost indissociable for them. I often have to 
jump three hurdles.


1/ They're multi-methods, and I never actually had a use for 
that. That is why I insist so much on openness in the article, 
and throw multiple dispatch in as a bonus only half way through. 
That's also why I call them "open methods" and not 
"multi-methods" or "open multi-methods".


2/ It's just function overloading. Hmmm, polymorphism? But once I 
get past that, it's actually a good thing. People know (more or 
less) how overload resolution (or partial template specialization 
for the more expert) works. So I don't need to explain the rules 
governing dispatch and ambiguities in an abstract way. Usually I 
just say "you already know which override will be picked - it's 
the same as with compile-time overload resolution".


3/ This one is specific to D - UFCS gives me the same thing. 
Hmmm, polymorphism again? But you see why I am very careful with 
anything that may obscure or confuse the message.


I find the interaction of open methods and UFCS particularly cool 
when implementing the "call chain" idiom (e.g. 
a.plus(b).times(c).invert()).

Re: D on Tiobe Index

2017-08-31 Thread SrMordred via Digitalmars-d-announce 

On Thursday, 31 August 2017 at 14:57:28 UTC, bitwise wrote:

https://www.tiobe.com/tiobe-index/d/


What happened in 2009?

Phobos function and type highlighter for vim

2017-08-31 Thread Uknown via Digitalmars-d-announce 
I wrote a Phobos function and type highlighter, based on 
vim-cpp-enhanced-highlight by octol for C++[1].


It simply matches and highlights functions and types from `std` 
and `core`. Currently everything as of D version 2.0.75 is 
supported, excluding `std.experimental`.



The script and install instructions are available here[2].


[1]https://github.com/octol/vim-cpp-enhanced-highlight
[2]https://github.com/Sirsireesh/vim-dlang-phobos-highlighter

D on Tiobe Index

2017-08-31 Thread bitwise via Digitalmars-d-announce 

https://www.tiobe.com/tiobe-index/d/

Usually, only graphs for the top 20 languages are generated on 
the Tiobe Index, but they were able to generate this for me (not 
sure if it expires at some point).


In any case, I was happy to see that D has been on the rise for 
the last few years.


I'm not sure exactly what has contributed to the rise, but what 
I've noticed the most is a huge improvement in compiler stability 
and usability. The website and documentation are also looking 
very good, where they were once hard read and to navigate.


What I would most like to see in the future would be a more 
complete and simplified set of tools for D.


I believe there should be at least one full-featured tool for 
each operating system, which includes syntax highlighting, 
auto-complete, symbol-information on hover, go to declaration, 
and runtime debugging for D. It should also include at least 
basic syntax highlighting for C++, and the ability to build and 
link that C++ code with the D program. I believe this tool should 
be self contained, and installable with a single click. An end 
user of the D programming language should never have to know 
anything about what dependencies are needed or installed for a 
given addon/extension.


I believe such a set of tools is well within reach. Some existing 
tools are already very close to what I've described above.


Anyways, congratulations to everyone that's contributed to the 
trend!

Re: Open Methods: From C++ to D

2017-08-31 Thread jmh530 via Digitalmars-d-announce 
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 had a chance to try out what I had suggested above and it 
behaves exactly as I would have expected (i.e. it prints the line 
"lassie.kick(): ctbark").


You seemed to emphasize UFCS in your response, but that really 
wasn't what I was intending to focus on. I just as easily could 
have re-written Dog as below and compiled the program and it 
would have printed the same thing. Similarly, any Dog or Pitbull 
type that call kick would return "ctbark", just Animals would 
return the original results.


class Dog : Animal
{
final string kick()
{
return "ctbark";
}
}

My point is one can easily mix your openmethods's dynamic 
dispatch and D's static dispatch. That seems like a great thing 
that you could emphasize. Simply stated: if you use openmethods, 
you're not forced to only use openmethods. If you know the type 
at compile-time, then you can use it. It's only if you want to 
dynamically dispatch it that you would need openmethods.

GitBook about D on embedded ARM Linux

2017-08-31 Thread thinwybk via Digitalmars-d-announce 
There is no single point of entry to find information about how 
to use D on ARM Linux. I created a small project on GitHub 
https://github.com/fkromer/d-on-embedded-linux-arm which shall 
enable absolute beginners (of embedded Linux and D) to get 
started as fast as possible. The project is in sync with a 
GitBook page 
https://fkromer.gitbooks.io/d-on-embedded-linux-arm/content/. The 
BeagleBone Black https://beagleboard.org/black is used as 
exemplary development board (a lot of information and tutorials 
available e.g. here http://exploringbeaglebone.com/, board 
hardware is extensible easily and in a modular manner with 
"capes" https://beagleboard.org/cape 
http://elinux.org/Beagleboard:BeagleBone_Capes).

Re: Article: Writing Julia style multiple dispatch code in D

2017-08-31 Thread Jean-Louis Leroy via Digitalmars-d-announce 
On Thursday, 31 August 2017 at 06:58:53 UTC, Petar Kirov 
[ZombineDev] wrote:
The workaround is to cast to Object before getting the typeid. 
The cause for this behavior is that if you have an interface 
reference to an object it points to the interface vtbl and not 
to the Object base class vtbl.


Yeah I know. And in my openmethods lib I simply follow the 
pointers, without relying on typeid. It does look to me like a 
bug though. D has all the info it needs to implement the process 
you describe.

Re: Open Methods: From C++ to D

2017-08-31 Thread jmh530 via Digitalmars-d-announce 

On Thursday, 31 August 2017 at 13:30:27 UTC, Atila Neves wrote:


import otherpackage: funkyMethod = openmethod;
import openmethod: openmethod = method;

Or use the fully qualified name. Either way, nothing that can't 
be dealt with by D's modules as they are now.



Atila


There are no limits to his criticism. If there are conflicts with 
@method, then what happens when someone writes another project 
with @openmethod as a UDA.


I don't think it needs to get changed.

Re: Open Methods: From C++ to D

2017-08-31 Thread Atila Neves via Digitalmars-d-announce 

On Thursday, 31 August 2017 at 11:39:30 UTC, aberba wrote:

On Thursday, 31 August 2017 at 10:30:38 UTC, Atila Neves wrote:
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`?


alias openmethod = method;

Atila


What happens when there is UDA name collision? if its 
catastrophic, then @openmethods makes it unique.


import otherpackage: funkyMethod = openmethod;
import openmethod: openmethod = method;

Or use the fully qualified name. Either way, nothing that can't 
be dealt with by D's modules as they are now.



Atila

Re: Open Methods: From C++ to D

2017-08-31 Thread Jean-Louis Leroy via Digitalmars-d-announce 

On Thursday, 31 August 2017 at 11:39:30 UTC, aberba wrote:
Thanks for this library. Just a suggestion. Would it possible 
to use `@openmethod` instead of `@method`?


alias openmethod = method;

Atila


What happens when there is UDA name collision? if its 
catastrophic, then @openmethods makes it unique.


After tightening a few screws, the library now supports static 
and selective imports.

Re: D as a Better C

2017-08-31 Thread Claude via Digitalmars-d-announce 
I think "betterC" can be a good tool to use D on embedded 
systems, keep as few dependencies as possible, a low ROM 
footprint and a good C interoperability.


I'll try to find some time to play with it.

Re: DlangUI v0.7.60 released

2017-08-31 Thread HyperParrow via Digitalmars-d-announce 

On Thursday, 31 August 2017 at 11:59:16 UTC, Vadim Lopatin wrote:
After opening of project, it takes 10-20 seconds for DCD to 
parse and cache phobos/druntime modules so first invocation may 
be delayed.


That should not take more than 3 secs, there might be an error in 
the way you init DCD.

Re: DlangUI v0.7.60 released

2017-08-31 Thread Suliman via Digitalmars-d-announce 

On Thursday, 31 August 2017 at 11:59:16 UTC, Vadim Lopatin wrote:

On Thursday, 31 August 2017 at 10:06:27 UTC, Suliman wrote:
On Thursday, 31 August 2017 at 08:51:12 UTC, Vadim Lopatin 
wrote:

On Wednesday, 30 August 2017 at 19:47:17 UTC, Dukc wrote:
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.


I'm trying not to spam too often.


How to turn on autocomplete? I am starting typing but do not 
see any autocomplete suggestions.


Ctrl+Space

After opening of project, it takes 10-20 seconds for DCD to 
parse and cache phobos/druntime modules so first invocation may 
be delayed.


Can it work without Ctrl+Space ? Just show variants when typing?

Re: Released vibe.d 0.8.1

2017-08-31 Thread aberba via Digitalmars-d-announce 
On Wednesday, 30 August 2017 at 16:53:40 UTC, Matthias Klumpp 
wrote:
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


Even with mysql (using mysql-native), the absent of something like

struct User {
@optional int userName; //its ok if row doesn't have this 
column

@as("phone_number") string phoneNumber;

}

User[] users;

foreach(row; ...)
{
users ~= row.toStruct!User;
}



MongoDB has facilities for these stuff automatically thats why 
using it seem convenient and speeds up stuff. Mysql-lited does 
this thing but the package does allow much control nor give much 
query info like mysql-native.



I've heard good news about postgresql however, its driver could 
still benefit from this kind of abstraction using CTFE and UDAs.

Re: DlangUI v0.7.60 released

2017-08-31 Thread Vadim Lopatin via Digitalmars-d-announce 

On Thursday, 31 August 2017 at 10:06:27 UTC, Suliman wrote:
On Thursday, 31 August 2017 at 08:51:12 UTC, Vadim Lopatin 
wrote:

On Wednesday, 30 August 2017 at 19:47:17 UTC, Dukc wrote:
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.


I'm trying not to spam too often.


How to turn on autocomplete? I am starting typing but do not 
see any autocomplete suggestions.


Ctrl+Space

After opening of project, it takes 10-20 seconds for DCD to parse 
and cache phobos/druntime modules so first invocation may be 
delayed.

Re: DlangUI v0.7.60 released

2017-08-31 Thread aberba via Digitalmars-d-announce 

On Thursday, 31 August 2017 at 02:41:08 UTC, Domain wrote:
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


Ive been planning to create a new theme but stuff got in my way. 
Its still among my bazillion  plans though.

Re: Open Methods: From C++ to D

2017-08-31 Thread aberba via Digitalmars-d-announce 

On Thursday, 31 August 2017 at 10:30:38 UTC, Atila Neves wrote:
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`?


alias openmethod = method;

Atila


What happens when there is UDA name collision? if its 
catastrophic, then @openmethods makes it unique.

Re: Open Methods: From C++ to D

2017-08-31 Thread Atila Neves via Digitalmars-d-announce 
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`?


alias openmethod = method;

Atila

Re: DlangUI v0.7.60 released

2017-08-31 Thread Suliman via Digitalmars-d-announce 

On Thursday, 31 August 2017 at 08:51:12 UTC, Vadim Lopatin wrote:

On Wednesday, 30 August 2017 at 19:47:17 UTC, Dukc wrote:
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.


I'm trying not to spam too often.


How to turn on autocomplete? I am starting typing but do not see 
any autocomplete suggestions.

Re: DlangUI v0.7.60 released

2017-08-31 Thread Vadim Lopatin via Digitalmars-d-announce 

On Wednesday, 30 August 2017 at 19:47:17 UTC, Dukc wrote:
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.


I'm trying not to spam too often.

Re: DlangUI v0.7.60 released

2017-08-31 Thread Vadim Lopatin via Digitalmars-d-announce 

On Thursday, 31 August 2017 at 02:41:08 UTC, Domain wrote:
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


There are no other themes available.
Although, it's easy to create your own theme.
Instructions can be found here:

https://github.com/buggins/dlangui/wiki/Adding-New-Theme

Built in themes are created based on Eclipse look & feel on 
Windows platform.


But Dark theme is ugly in Eclipse as well :(

BTW, topic should be DlangIDE released, not DlangUI released.

Re: Article: Writing Julia style multiple dispatch code in D

2017-08-31 Thread via Digitalmars-d-announce 
On Wednesday, 30 August 2017 at 23:34:10 UTC, 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.


The workaround is to cast to Object before getting the typeid. 
The cause for this behavior is that if you have an interface 
reference to an object it points to the interface vtbl and not to 
the Object base class vtbl.


https://run.dlang.io/is/3IMrin

Re: Article: Writing Julia style multiple dispatch code in D

2017-08-31 Thread Rainer Schuetze via Digitalmars-d-announce 



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.