Re: "is not an lvalue" when passing template function to spawn function
On Thursday, 9 November 2023 at 10:14:46 UTC, Bienlein wrote: On Thursday, 9 November 2023 at 09:40:47 UTC, Bienlein wrote: On Wednesday, 8 November 2023 at 16:47:02 UTC, Paul Backus wrote: On Wednesday, 8 November 2023 at 16:30:49 UTC, Bienlein wrote: ... The actual problem here is that you can't take the address of a template without instantiating it first. To make your example work, replace `` with `!int`, like this: spawn(!int, biz); All right. It seems I cannot pass on an object. So I store the object in a global and access it from the callback function passed to spawn.
Re: "is not an lvalue" when passing template function to spawn function
On Thursday, 9 November 2023 at 09:40:47 UTC, Bienlein wrote:
On Wednesday, 8 November 2023 at 16:47:02 UTC, Paul Backus
wrote:
On Wednesday, 8 November 2023 at 16:30:49 UTC, Bienlein wrote:
...
The actual problem here is that you can't take the address of
a template without instantiating it first. To make your
example work, replace `` with `!int`, like
this:
spawn(!int, biz);
Thanks, Paul. This helped a step further. When applying your
change it looks like this:
Biz!int biz = new Biz!int(123);
spawn(!int, biz);
Then I get this error: 'Error: static assert: "Aliases to
mutable thread-local data not allowed."'
For this error I found this in the Internet:
https://stackoverflow.com/questions/14395018/aliases-to-mutable-thread-local-data-not-allowed
But this change, did not help:
spawn(!int, cast(shared) biz);
Then I moved "Biz!int biz = new Biz!int(123);" out of the main
function. Compiler complains about static this. Okay, then the
code outside the main function now looks this way:
class Biz(T) {
private T value;
this(T value) {
this.value = value;
}
}
static void addToBiz(T)(Biz!T biz)
{
// ...
}
Biz!int biz;
static this() {
biz = new Biz!int(123);
}
int main()
{
// ...
}
However, this results in no gain as the compiler now shows the
initial error again: 'Error: static assert: "Aliases to
mutable thread-local data not allowed."'
Everything I tried on my own was also to no avail. If someone
could gould give me a hint again ... ;-)
Thank you.
If I supply a callback function with the parameter not being an
instance from a parameterized class I get the same error. The
problem seems to be that the parameter of the callback function
takes on object as a parameter and not a built-in type like int
or String.
The samples on how to use the spawn function on dlang.org does
not contain a sample on how to get things to work with a objecgt
being supllied as parameter to the callback function
Re: "is not an lvalue" when passing template function to spawn function
On Wednesday, 8 November 2023 at 16:47:02 UTC, Paul Backus wrote:
On Wednesday, 8 November 2023 at 16:30:49 UTC, Bienlein wrote:
...
The actual problem here is that you can't take the address of a
template without instantiating it first. To make your example
work, replace `` with `!int`, like this:
spawn(!int, biz);
Thanks, Paul. This helped a step further. When applying your
change it looks like this:
Biz!int biz = new Biz!int(123);
spawn(!int, biz);
Then I get this error: 'Error: static assert: "Aliases to
mutable thread-local data not allowed."'
For this error I found this in the Internet:
https://stackoverflow.com/questions/14395018/aliases-to-mutable-thread-local-data-not-allowed
But this change, did not help:
spawn(!int, cast(shared) biz);
Then I moved "Biz!int biz = new Biz!int(123);" out of the main
function. Compiler complains about static this. Okay, then the
code outside the main function now looks this way:
class Biz(T) {
private T value;
this(T value) {
this.value = value;
}
}
static void addToBiz(T)(Biz!T biz)
{
// ...
}
Biz!int biz;
static this() {
biz = new Biz!int(123);
}
int main()
{
// ...
}
However, this results in no gain as the compiler now shows the
initial error again: 'Error: static assert: "Aliases to mutable
thread-local data not allowed."'
Everything I tried on my own was also to no avail. If someone
could gould give me a hint again ... ;-)
Thank you.
"is not an lvalue" when passing template function to spawn function
Hello,
I get the error "`addToBiz(T)(Biz!T biz)` is not an lvalue and
cannot be modified" when compiling the code below. Can't find a
way how to do it right. Am a D newbie and would appreciate some
help.
Thank you, Bienlein
class Biz(T) {
private T value;
this(T value) {
this.value = value;
}
}
static void addToBiz(T)(Biz!T biz)
{
// ...
}
int main()
{
auto biz = new Biz!int(123);
spawn(, biz);
}
Re: Way to pass params to a function passed to a fiber?
On Monday, 3 October 2022 at 10:13:09 UTC, Rene Zwanenburg wrote:
On Monday, 3 October 2022 at 08:10:43 UTC, Bienlein wrote:
My question is whether someone has an idea for a better
solution.
You can pass a lambda to the fiber constructor. For example:
```
void fiberFunc(int i)
{
writeln(i);
}
void main()
{
auto fiber = new Fiber(() => fiberFunc(5));
fiber.call();
}
```
Oh, that simple... Thanks a lot :-).
Way to pass params to a function passed to a fiber?
Hello,
I'm looking for a way to pass parameters to a function called by
a fiber. Starting a fiber works like this:
int main()
{
auto fiber = new Fiber();
fiber.call();
fiber.call();
return 0;
}
void myFunc() {
writeln("Fiber called");
Fiber.yield();
writeln("Fiber recalled after yielding");
}
In the code above there is no way to add parameters to myFunc.
The construcor of class Fiber does not allow for a function to be
passed that has parameters (unlike for the spawn function when
starting a thread).
I ended up with something like this:
class Foo {
public int i;
}
Foo foo;
static this()
{
foo = new Foo;
}
int main()
{
auto fiber = new Fiber();
fiber.call();
fiber.call();
return 0;
}
void myFunc() {
import std.stdio;
writeln("foo: ", foo.i);
foo.i++;
Fiber.yield();
writeln("foo: ", foo.i);
}
But this solution is a bit clumsy. It's kind of programming with
global variables.
My question is whether someone has an idea for a better solution.
Thank you, Bienlein
Re: null == "" is true?
why? Because an empty string is, by default, represented by an empty slice of the null pointer. I don't program in D. I just read from time to time posts in the D forum because of the good quality of what people write. So, I'm not proficient in D, but in general internals should not boil up to the surface. In my experience null and empty in DTOs usually play the same logical role. Oh, oh ... IIRC someone wrote a master thesis about the different roles for null values in databases >and came up with many different null situations (was it five?). Oh, oh, oh ... I once worked on a system where some little robot running on a track picked up material in carriers from some machine and then brought it to the next machine. If the destination of a carrier was set to null, it implied that the destination was currently undefined. Then the robot brought the carrier to some rack where it was put aside for a while till the planning system had created a new production plan. The number of null pointer exceptions we had to fix because auf this was countless. Never make null imply some meaning ...
Re: Time to setup D's wallet
On Tuesday, 9 November 2021 at 17:29:37 UTC, Rumbu wrote: Nim received a nice donation :) https://nim-lang.org/blog/2021/10/25/nim-receives-100k-usd-bitcoin.html You never know when it happens. I hope the put the money into making a better debugger ;-)
Re: How to call destructor before free without dropping @nogc?
This works, vit. Thanks! I thought it wouldn't, because your code
still makes use of embrace. But it somehow worked, although I
don't understand why ... ;-).
I also added a constructor using the same approach as your
destructor and this also worked:
this(int otherNum) @nogc {
this.num = otherNum;
debug writeln("this: ", this.num);
}
@evilrat: Will try what you suggested after work today. Too busy
now.
Re: How to call destructor before free without dropping @nogc?
On Thursday, 19 August 2021 at 07:30:38 UTC, Bienlein wrote:
Hello,
I allocate some instance of class C manually and then free the
memory again:
class C {
int num;
~this() {
writeln("~this");
}
}
void foo() // @nogc
{
auto mem = cast(C)malloc(__traits(classInstanceSize,
C));
auto c = emplace!(C)(mem);
c.num = 789;
destroy(c);
free(cast(void*) c);
c = null;
}
int main()
{
foo();
}
The code above works well as the destructor of c in class C is
called by destroy. Problem is that destroy cannot be used once
function foo is annotated with @nogc. There seems to be no way
round it.
What I want is to keep the function foo annotated with @nogc,
but still have the destructor of C be called before free is
called. Is there a way to call the destructor through meta
programming or some kind of reflection so that I can create
some generic function that calls the destructor and then free
for any kind of class?
Thanks, Bienlein
Oops, I just realized that you can also not call emplace when
@nogc is present. Well that is at least consistent with not
either being able to call destroy ;-).
So, I guess this means that you can forget about manually
allocating and freeing some instance of a class and using @nogc
as well. That's a pitty, @nogc was a good idea.
How to call destructor before free without dropping @nogc?
Hello,
I allocate some instance of class C manually and then free the
memory again:
class C {
int num;
~this() {
writeln("~this");
}
}
void foo() // @nogc
{
auto mem = cast(C)malloc(__traits(classInstanceSize, C));
auto c = emplace!(C)(mem);
c.num = 789;
destroy(c);
free(cast(void*) c);
c = null;
}
int main()
{
foo();
}
The code above works well as the destructor of c in class C is
called by destroy. Problem is that destroy cannot be used once
function foo is annotated with @nogc. There seems to be no way
round it.
What I want is to keep the function foo annotated with @nogc, but
still have the destructor of C be called before free is called.
Is there a way to call the destructor through meta programming or
some kind of reflection so that I can create some generic
function that calls the destructor and then free for any kind of
class?
Thanks, Bienlein
Re: What's the best way to find out which exceptions may be thrown ?
On Wednesday, 27 May 2020 at 11:40:00 UTC, Mike Parker wrote: On Wednesday, 27 May 2020 at 10:30:36 UTC, wjoe wrote: On Wednesday, 27 May 2020 at 10:01:33 UTC, Mike Parker wrote: Could you please elaborate why checked exceptions are more annoying? For me, it's because they require all functions that touch them to either try/catch or include an exception specification in its declaration. In my Java days, I ended up just doing what so many others do and adding `throws Exception` or `catch(Exception)` to avoid having to handle multiple exception types. Most of the time, I didn't care what specific sort of exception was thrown. Because of the problems with checked exceptions they were deliberately left out in C#. Here is an interview with Anders Hejlsberg, the creator of C# at MS, where he explains the reasons for this decision: https://www.artima.com/intv/handcuffs.html
Re: Alternative to friend functions?
On Tuesday, 18 February 2020 at 12:43:22 UTC, Adnan wrote:
What is the alternative to C++'s friend functions in D?
module stable_matching;
alias FemaleID = int;
alias MaleID = int;
class Person {
string name;
int id;
}
class Male : Person {
this(string name = "Unnamed Male") {
static int nextID = 0;
this.id = nextID++;
this.name = name;
}
}
class Female : Person {
this(string name = "Unnamed Female") {
static int nextID = 0;
this.id = nextID++;
this.name = name;
}
}
class Husband(uint N) : Male {
FemaleID engagedTo = -1;
const FemaleID[N] preferences;
this(FemaleID[N] preferences) {
this.preferences = preferences;
}
}
class Wife(uint N) : Female {
FemaleID engagedTo = -1;
const MaleID[N] preferences;
this(MaleID[N] preferences) {
this.preferences = preferences;
}
}
void engage(N)(ref Wife!N, wife, ref Husband!N husband) {
// Here, I want to access both husband and wife's engaged_to
}
class MatchPool(uint N) {
Husband!N[N] husbands;
Wife!N[N] wives;
}
I would make Husband and Wife subclasses of a common abstract
superclass Spouse that declares the engagedTo var. The Spouse
superclass would also be the place where to put the engage
method. What is different for males and females you can redefine
in the respective subclass.
Re: Functional Programming in D
On Thursday, 10 October 2019 at 16:05:13 UTC, bachmeier wrote: On Thursday, 10 October 2019 at 08:59:49 UTC, Russel Winder wrote: My impressions is that the complaints about Scala are similar to C++: too many features that clash with one another and make the language complicated, plus extremely slow compilation times. I haven't seen a lot of complaints about mixing imperative and functional. Scala compile times are slow, because Scala has more compilation phases than C++. I guess that is because of feature bloat in the language as such, IMHO not necessarily because FP and OOP are mixed into the same language. Scala is just packed with too many language constructs that are also in many cases quite extensive. Then there is a problem with implicit conversions in Scala not being scalable in compilation times, see https://dzone.com/articles/implicits-scala-conversion In Scala3 (due to be released in spring 2020) implicits were replaced by what they call delegates (and extension methods were introduced). Whether that reduces compilation times I don't know. But the compiler in Scala3 is based on a complete new approach to further reduce compilation times. However, Scala3 is a new language. Whether people will make the move from Scala to Scala3 remains to be seen.
Re: Functional Programming in D
On Thursday, 10 October 2019 at 10:08:14 UTC, H. S. Teoh wrote: On Thu, Oct 10, 2019 at 09:59:49AM +0100, Russel Winder via Digitalmars-d-learn wrote: On Wed, 2019-10-09 at 11:12 -0700, H. S. Teoh via Digitalmars-d-learn wrote: […] > Actually, std.functional is somewhat of a misnomer. It > mostly deals with higher-order functions, i.e., functions > that return functions, currying, that sort of thing. These > are part of functional programming, but there's more to > functional programming than that. I'd say std.range and > std.algorithm are another major part of functional-style > programming support in D, along with the purity system. […] I feel that it is best to leave functional programming to functional programming language, e.g. Haskell, Scheme, etc. rather than try to do functional programming in imperative languages, e.g. Java, C++, Rust, D. [...] Note this is why I wrote "functional-style programming" w.r.t. D, rather than "functional programming". Clearly, what D has isn't "real" functional programming in the strict sense, but it does share similar characteristics when written in that style. I did programming in Smalltalk for about 10 years. Smalltalk has all those things that are now called "functional-style programming" or even IMHO incorrectly "functional programming" that are about applying operations on collections. In Smalltalk these functions (like collect, map, reject, detect, inject, etc.) are simply called "collection iterators". They already exist in Smalltalk-80, which is called that way, because it was published in 1980. To verify this you can download the Smalltalk-80 "blue book" from here and do a text search on these function names: http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf In those 10 years where I did Smalltalk development I met no one who called making use of those collection iterators functional programming. There are several books about Smalltalk who have some importance in CS, because Smalltalk was the first truly useable OO language afer Simula. I don't think the term functional programming is ever used there. Calling collection iterators functional programming opened Pandoras box of mixing up things. I fear it is too late to explain to people that functional progeramming is what is done in Haskel and Lisp and related languages and nothing else. Collection iterators carry some aspects of functional programming such as non-destructive programming as the result of applying a function on a call returns a new collection leaving the original collection unchanged, but that alone is not enogh for things to be called functional programming. It is merely simply making use of closures.
Re: Top Five World’s Most Underrated Programming Languages
On Wednesday, 23 January 2019 at 12:26:02 UTC, rikki cattermole wrote: On 24/01/2019 1:20 AM, JN wrote: Well, the truth is, people don't come to a language because of a killer feature. Sometimes it's even the opposite. Java and Dart are familiar to some extent because of lack of killer features. Actually that isn't quite true. Java's killer feature is consistent simplicity. That is how it was originally sold to great success. The ecosystem and tooling came later. Java is going to get CSP-style concurency as in Go probably in JDK13. It's called Project Loom. Here is a presentation by Mark Reinhold (Java project lead at Oracle) where he is presenting a preview of JDK13 and Project Loom: https://www.youtube.com/watch?time_continue=4125=nKJbDYRsO0s (starting at 1:08:47) This will create some competition for Go what the multi-threading model is concerned. Java is better than Go otherwise in every aspect except memory consumption.
Re: Top Five World’s Most Underrated Programming Languages
On Wednesday, 23 January 2019 at 15:04:00 UTC, jmh530 wrote: I would think that dynamic class loading is something that could be bolted on to C++ (and presumably D as well), albeit awkwardly. Dynamic class loading means there is no more link step.
Re: Top Five World’s Most Underrated Programming Languages
On Wednesday, 23 January 2019 at 14:14:06 UTC, bachmeier wrote:
I've made this comparison many times before, but I'll do it
again...
Look at what Rust offers as documentation for Cargo:
https://doc.rust-lang.org/cargo/index.html
This is what you get with Dub:
https://dub.pm/getting_started
One is professional documentation, the other was something
hacked together by a sixth grader over the weekend. The Dub
documentation is good through the part demonstrating `dub
init`, then it falls apart. It talks about two configuration
file formats - not one, but two ("use whichever you prefer")
and I have no idea there is even a discussion of configuration
file formats at that point. Then there's a link to this word
dump https://dub.pm/package-format-json.html.
Noticeably absent: how I'm supposed to *use* Dub. Where do I
put my source files? How do I add dependencies? Have you ever
heard of an example?
Then a little below that is a link to this page:
https://dub.pm/publish.html. I wonder what that is for. Can't
make heads or tails out of that.
This is *introduction to the language*. If someone sees that
and doesn't run away, there's something wrong. I most
definitely would have gone with Rust if it had been usable when
I started using D. The Dub documentation makes it really hard
to bring in users - and makes Rust look like a sane language in
comparison.
This is all true, but you need to keep in mind that Go had no
real package manager for a long time. There was the "go get"
command which loaded the code from some github repo in the state
it was at the time when being loaded. There was no version
control. Nobody really cared (the vendor stuff in Go was added
with Go 1.10 or 1.11). Goroutines were the killer feature of the
language that paved the way, because this was badly needed for
writing server-side software.
I don't think D will have some killer app in the mid-term future.
So what is left is to put a killer feature into the language like
CSP or safe manual memory management or something.
Re: Top Five World’s Most Underrated Programming Languages
On Wednesday, 23 January 2019 at 12:26:02 UTC, rikki cattermole wrote: Java's killer feature is consistent simplicity. That is how it was originally sold to great success. The ecosystem and tooling came later. Also, the Internet was Java's killer application. No other language had the libraries for accessing the Internet easily. Then there is dynamic class loading. This made things a little bit more unsafe at runtime but in general developer productivity rose sharply, comparable to Smalltalk and by order of magnitude compared to C++. At that time the competition for Java was only Smalltalk and C++. Performance was nevertheless good, because of runtime code optimization (HotSpot), which was a new thing (albeit taken from Strongtalk, some Smalltalk high performance variant)
Re: Top Five World’s Most Underrated Programming Languages
On Friday, 18 January 2019 at 08:55:23 UTC, Paulo Pinto wrote: D really needs its killer use case if it is to move away from that list. D is a lot like Scala on the JVM: Both language have myriads of language features and bells and whistles, but there is no killer feature in the language itself. Rust and Go have that: Rust has safe manual memory management and Go has an excellent threading model with communicating sequential processes (aka goroutines). Scala didn't make it anywhere until Akka came along beind developed in Scala. Then came Play, Spark and Kafka - all developed in Scala. Either the language has a killer feature or there must be a killer application written in it. For D the latter applies as it does not have a killer feature in the language. Build CSP into D or manual memory management as in Rust. CSP without a GC is difficult (that's one reason why Go has a GC) and Go has a very good GC. I don't think marketing is a requirement. Rust and Go also received no big marketing. Their respective killer feature paved the way as those things were needed. Then people just take it and use it.
Re: DConf 2019: Shepherd's Pie Edition
On Saturday, 22 December 2018 at 13:33:29 UTC, Russel Winder wrote: Brilliant, DConf comes to the UK, I can get to it… except… it's on at the exact same time as DevoxxUK 2019 which is at the Business Design Centre. :-( Programming languages are unimportant anyway.
Re: Writing Postgresql extension in D
On Friday, 16 November 2018 at 02:18:11 UTC, Ranjan wrote: On Thursday, 15 November 2018 at 17:03:55 UTC, Andrea Fontana wrote: On Thursday, 15 November 2018 at 13:05:59 UTC, Ranjan wrote: This is my first time on the Dlang forum. I like the language but my usecase is a bit different. I want to write Postgresql extension in D. Currently extension can be written in C or C linked languages. Has anyone done this or can point me to some code. Thanks Did you read this: https://dlang.org/spec/interfaceToC.html ? Andrea Yes, but it's not useful, in Postgesql extension C code needs to call D, without GarbageCollection. I am able to do this in RustLang but I am not sure how to in D, as it has a GC. Looking for examples from the community. Thanks I'm not an exert with C nor D. So I might misuderstand the issue... You can write a skeleton plugin for postgres in C that at init time starts the D runtime. From then on your C skelton plugin can call some function in D.
Re: Inherit from class based on bool value
On Tuesday, 13 November 2018 at 07:10:26 UTC, Jamie wrote:
I would like my class to inherit from one of two classes based
on a boolean value known at compile time. Something like this:
void main()
{
Top!(OPTION.FALSE) top = new Top!(OPTION.FALSE);
}
enum OPTION
{
FALSE = 0.,
TRUE = 1.
}
class One
{}
class Two
{}
class Top(OPTION option) : option ? One : Two
{}
Is this possible? I can't get it to work in the way I'm showing
above.
Cheers
My piece of advice would be not to do this but to model all data
explicitly. And I had some exposure to OOP with over 10 years
developing in Smalltalk, which is a pure OO language. Actually, I
don't know whether it is good that this can be done in D ...
Re: Aalborg D meetup
On Friday, 15 June 2018 at 07:34:07 UTC, biocyberman wrote: On Friday, 15 June 2018 at 07:20:04 UTC, Bienlein wrote: On Wednesday, 13 June 2018 at 12:37:26 UTC, bauss wrote: On Wednesday, 13 June 2018 at 12:12:11 UTC, bauss wrote: I'll be there since I live there and would be nice to see monthly meetups! :) I forgot to ask. Is it free entry? :) Yeah, and the Aalborg Akvavit is also free ? ;-) Depending on the volume you can take and how you transport to and from the meetup :) But I am taking some beer, soft drinks (saft vand?), fruit and chips. It's good for discussing socializing parts It is called soda vand, I think. Unhappily I'm about 1000 km away from Aalborg :-(
Re: Aalborg D meetup
On Wednesday, 13 June 2018 at 12:37:26 UTC, bauss wrote: On Wednesday, 13 June 2018 at 12:12:11 UTC, bauss wrote: I'll be there since I live there and would be nice to see monthly meetups! :) I forgot to ask. Is it free entry? :) Yeah, and the Aalborg Akvavit is also free ? ;-)
Re: PR duty
On Wednesday, 4 April 2018 at 05:31:10 UTC, Andrei Alexandrescu wrote: Hi folks, I was thinking of the following. To keep the PR queue trim and in good shape, we'd need at least one full-time engineer minding it. I've done that occasionally, and the queue size got shorter, but I couldn't do much else during that time. I was thinking, we can't afford a full-time engineer, and even if we did, we'd probably have other important matters for that engineer as well. However, what we can afford - and indeed already benefit from - is a quantum of time from each of many volunteers. By organizing that time better we may be able to get more output. Here's what I'm thinking. Let's define a "PR duty" role that is one week long for each of a pool of volunteers. During that week, the person on PR duty focuses on minding github queues - merge trivial PRs, ping authors of old PRs, email decision makers for specific items in PRs, etc. Then the week ends and the role is handed off to the next person in the pool. (...) Thanks, Andrei Maybe one idea would be to get university people interested in D. A lot of work on the Scala compiler and eco system is done by students at the technical university of Lausanne where Martin Odersky (the creator of Scala) is teaching. They do work on it in their master or PhD thesis or just help on the development of tools and libraries. The EPFL is well endowed with money and pays as long as the work being done is in some way research oriented (and as long as Scala is a big thing in the IT world). So the idea would be to get some university professors interested in D. Then you have people working on D and its eco system that are paid by the university or do the work for their thesis. I would say that D is ideal for teaching programming being a high-level language with both manual memory management and a GC. It's really a win-win situation for D and teaching institutions. So I would propose to have a look at universities/academia as a new target to promote D. Students one day finish their studies and then take the language with them from which they learned a lot and know very well ... ;-).
Re: D mentioned in Infoworld
On Thursday, 29 March 2018 at 16:10:55 UTC, Johannes Loher wrote: I have to say, my experience was totally different. I recently had quite many job interviews for jobs in which I would mainly be using Java/C#. Because I like D very much, obviously the topic came up in every single interview. Most of the time, I was encouraged to solve the simple programming tasks they gave me in D. I think they were actually quite impressed, both by D itself and the fact that I am interested in such a "niche" language. I believe showing that you are enthusiatic about such things can help you with getting jobs much more than some experience in a language which is "closer" to the language they mainly use. Yes, I beliebe that enthusiasm and passion is something people are sometimes looking for at job interviews. In my last job interview I showed some passion about concurrent programming and I think they like that, that is the passion. Whether it is about concurrent programming or D might not be that important. I landed a previous job using .NET about two years ago, because of some D code I >had written, so for me the experience is different too. This is interesting. Maybe I write a little framwork or something in Kotlin and file it on github. Then I have something to show in any case. And from then on I can just play with D ;-)
Re: D mentioned in Infoworld
On Monday, 26 March 2018 at 17:49:18 UTC, bauss wrote: On Monday, 26 March 2018 at 16:13:17 UTC, Joakim wrote: On Monday, 26 March 2018 at 15:52:11 UTC, Jean-Louis Leroy wrote: ...as a "programming languages you should learn now" - albeit somewhat dismissively ;-) https://www.infoworld.com/article/3263395/application-development/the-programming-languages-you-should-learn-now.html Eh, never bad to be mentioned in articles like that, could encourage some to try D. D should have been under the "if you know Java" and "if you know C#" too though. I agree that this should be the case. But I can see the point of the author saying D is something for C++ people to look into. For C++ developers having some exposure to D might be a plus in some job interview. For Java/C# developers this is not the case. Almost certainly in any job interview the people have never heard of a language named D. Being a Java developer some knowledge of Scala or Kotlin are a plus. Eventually they will listen to you for about half a minute why you like D. But in the end they will prefer someone with some working experience with Kotlin or Scala. IMHO, the core D people are into system programming and from their background come from a C or C++ world. Also, it is hard to comine Java/C# with D. In C# it is easy to call functions from a dll or so file. In Java this will also be the case in some upcoming JDK. Whatever, to call functions from dll or so file can also be done using Rust or plain C or C++. In my geographical surroundings here people will just stick to C or C++. Neither Rust nor D would be considered. So I don't want to spread negative attitude. But how to make D useful for Java/C# is a difficult problem.
Re: Can this be done? Defining type as in this Scala sample code
On Monday, 26 February 2018 at 19:36:33 UTC, Simen Kjærås wrote:
On Monday, 26 February 2018 at 15:43:54 UTC, Bienlein wrote:
object Scratch extends App {
// compiles:
val list = List(1, 2.4, 5)
val sum = list.sum
println(sum)
// does not compile:
val list2 = List(1, 2.4, 5, "123")
val sum2 = list2.sum
println(sum2)
}
There's nothing in the language or standard library that
supports this. However, it's perfectly possible to make
something with those semantics:
import std.variant;
import std.stdio;
struct List(T) {
T[] values;
alias values this;
}
auto list(T...)(T args)
{
import std.traits : CommonType;
static if (is(CommonType!T == void))
List!Variant result;
else
List!(CommonType!T) result;
result.length = T.length;
foreach (i, e; args) {
result[i] = e;
}
return result;
}
auto sum(T)(List!T lst)
if (is(typeof(lst[0] + lst[0])) && !is(T == Variant))
{
T result = 0;
foreach (e; lst) {
result += e;
}
return result;
}
unittest {
auto list1 = list(1, 2.4, 5);
auto sum1 = list1.sum;
writeln(sum1);
auto list2 = list(1, 2.4, 5, "123");
auto sum2 = list2.sum;
writeln(sum2);
}
Since std.variant.Variant does operator overloads, we have to
explicitly check if T == Variant in the sum function. For
Variant, that's probably the correct choice. We could use
Algebraic instead, but it also does operator overloads, even
when no type in its arguments support them. Again, we could
create our own - Algebraic and Variant are library types, after
all.
--
Simen
Didn't have time so far to look into this. But thanks anyway.
Re: Can this be done? Defining type as in this Scala sample code
On Monday, 26 February 2018 at 16:53:39 UTC, drug wrote:
you can do something like this (https://run.dlang.io/is/RYR5Dm):
```
import std.algorithm : sum;
import std.range : only;
import std.stdio : writeln;
import std.typecons : tuple;
void main()
{
{
auto list = tuple(1, 2.4, 5);
auto sum = list.expand.only.sum;
writeln(sum);
}
{
// do not compile
/*
auto list = tuple(1, 2.4, 5, "123");
auto sum = list.expand.only.sum;
writeln(sum);
*/
}
}
```
This looks good. It's not completely transparent, because of this
"expand.only" thing. But I guess it can be done to hide it.
Thanks for this one.
Can this be done? Defining type as in this Scala sample code
Hello,
just curious whether this is a Scala speciality or whether it
could also be done in D. Here is some Scala code:
object Scratch extends App {
// compiles:
val list = List(1, 2.4, 5)
val sum = list.sum
println(sum)
// does not compile:
val list2 = List(1, 2.4, 5, "123")
val sum2 = list2.sum
println(sum2)
}
In the code above list.sum compiles, because list only contains
values that are of type Numeric. The sum method looks like this:
def sum[B >: A](implicit num: Numeric[B]): B =
foldLeft(num.zero)(num.plus)
So sum compiles if all values can be converted to Numeric which
the compiler checks at compile time.
For list2 this is not the case as "123" is a string and therefore
not of type Numeric. Calling functions on list2 ist fine as long
as no function is called that requires a conversion to Numeric
for each element in the list such as in the case of sum.
My question is now whether that kind of logic can also be defined
in D. My knowledge of D is too limited to find out in reasonable
time myself. Reason for my curiosity is that the Scala solution
relies on implicit conversion at compile time which has its
drawbacks (compilation times, colliding implicit conversions the
compiler cannot detect, etc.). So I just wanted to see whether D
does this in a clean way and I know that D allows for some type
parameter constraints to be set.
Thansk for any answers,
Bienlein
Re: Don't expect class destructors to be called at all by the GC
On Thursday, 21 December 2017 at 18:45:27 UTC, Adam D. Ruppe wrote: On Thursday, 21 December 2017 at 18:20:19 UTC, H. S. Teoh wrote: When the scoped destruction of structs isn't an option, RefCounted!T seems to be a less evil alternative than an unreliable class dtor. :-/ Alas, RefCounted doesn't work well with inheritance... Though, what you could do is make the refcounted owners and borrow the actual reference later. Is there some summary of the things you have to be aware of when using the GC in D and not using the GC? I feel this would be very useful especially for people that are new to D or are not used to that kind of issues (because coming from a GCed language).
Re: Is there any threadsafe queue?
On Wednesday, 13 September 2017 at 07:51:19 UTC, John Burton
wrote:
Is there any threadsafe queue in the standard library?
I've not been able to find anything but thought I'd check
before making my own.
I want to be able to assemble messages (Which are just streams
of bytes) in one thread into a struct and push them to the
queue, and then have a another thread be able to read and
process the messages. Single producer and consumer.
You can take some existing container and overwrite the add and
remove methods to be synchronized, e.g.
public void add(T t) {
synchronized {
super.add(t);
}
}
However, this could cause some lock contention depending on your
use case. This is why class Vector in Java is basically
discontinued. In that class every method is synchronized which
has led to bad timing behavior. For the new concurrent
collections in Java since Java 5 some work has been done to
replace synchronized with some CAS approach. For example, class
ConcurrentLinkedQueue in Java does some tricks with CAS
algorithms to get around this.
Re: M:N thread multiplexing
On Sunday, 30 July 2017 at 13:35:18 UTC, Poyeyo wrote: Reading this article: http://www.evanmiller.org/why-im-learning-perl-6.html makes me curious about the state of Dlang's M:N thread multiplexing. Quoting the article: "if you want M:N thread multiplexing your options today are precisely Erlang, Go, .NET, and Perl 6." Is it possible to add D to this list of languages mentioned in that article? Whenever I asked about CSP in D I got the answer to consider vibe.d. D has fibers. In addition to have something like green threads, it would need a mechanism that a fiber that is going to be blocked when taking from an empty channel is detached from that channel and assigned to one that is not empty. Not sure I agree that .NET has m:n threads in sense of CSP/green threads. About Perl 6 I don't know. Java has it as well through Quasar (http://docs.paralleluniverse.co/quasar/) and the JVM in general through Coroutines in Kotlin (https://kotlinlang.org/docs/reference/coroutines.html)
Re: D easily overlooked?
When looking at other language ranking sites, D always scores better then Rust. Yet, Rust gets included in the ranking but D is ... nowhere to be seen. Well, on the Tiobe index D is currently on place 23 way ahead of Lua, Scala, Rust, Kotlin, Groovy. So there is obviously asomething wrong with the Tiobe index here as all those other languagse are quite a bit in use. Hope this compensates a bit for your pain ;-). Not to be a downer but D really in my eyes is missing that "unique" feature that people care about, that allows people to blog about the language... D is the most feature rich language I know of. Maybe only Scala comes close, but Scala can be at times an unreadable mess as the designers of the language valued mixing functional and OO higher than readability. D, on the contrary, has a very clean design througout. But you are right. D is missing some unique selling point like ease of concurrency using Communicating Sequential Processes in Go or memory safety in Rust without a GC. This is because D does not have a business model, but seems to be seen as a playground for building the greatest language ever. I fear this will not change. Topics of people arguing that D needs a business case pop up regularly here and are every time mostly or also completely ignored. It does not look like this will change, because the main drivers of the language never drop a comment in those discussions.
Re: Go 1.9
On Friday, 23 June 2017 at 14:07:09 UTC, Ola Fosheim Grøstad wrote: On Friday, 23 June 2017 at 11:15:40 UTC, Bienlein wrote: I have not done any manual memory management at work for the last 25 years. But are you doing any programming for the low end of the hardware spectrum? It has been the low end hardware limitations that have the standard for memory consumption… I'm assuming that D is for general purpose programming as well.
Re: Go 1.9
On Friday, 23 June 2017 at 08:57:04 UTC, Ola Fosheim Grøstad wrote: On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote: Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :) The memory footprint doesn't matter. Those times are OVER :-). People said that 30 years ago too... It is still an issue, though. Not as much as it was, but still relevant. Programmers seem to be able to suck up whatever RAM is available on the low-end by adding frameworks, bloated libraries and runtimes, or just bugs… I have not done any manual memory management at work for the last 25 years. Did some C++ programming at college and a bit at home where I had to take care of memory myself. That was it. Till I retire in 20 years I will also not have been doing any manual memory management. That kind of stuff only survives in very special areas where 0.1% of all software developers work. That being said let me repeat that D needs a decent GC for being able to create any traction, because those 99.9% of the share are the far bigger market.
Re: Go 1.9
On Friday, 23 June 2017 at 06:41:26 UTC, Bienlein wrote: Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :) The memory footprint doesn't matter. Those times are OVER :-). Here are some references: http://benchmarksgame.alioth.debian.org/u64q/go.html http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go=gcc There you can see how little memory Go uses compared to C and Java. Java will also get better as it will also get value types in some upcoming JDK.
Re: Go 1.9
Java, Kotlin, C# are still Jit compiled languages, with the memory footprint to prove it :) The memory footprint doesn't matter. Those times are OVER :-).
Re: Go 1.9
I suspect though that like Go took Python more than C folk, Kotlin Native will take more Java that C++, Go and Rust folks. But speculation rarely turn out quite as speculated. In Java development there is almost no C or C++ and no Rust or D at all. Memory is no problem. Some server needs 256 GB RAM or maybe 512 GB? That's not an issue anywhere. As long as you get the performance through parallelisation there is no need for C or C++. You won't meet any Java EE archtitecture that will do anything else than fight against calling C, C++ routines from Java. That is only done in some very exceptional cases. The days of languages for systems programming are over. There are only very few people that need such a language. That is why D really needs a decent GC, otherwise it won't find any users that would do production systems with it.
Re: Go 1.9
On Monday, 19 June 2017 at 13:24:00 UTC, Russel Winder wrote: Go gets parallel compilation, at last, and better garbage collection. The former is not a problem for D, but the latter… Right, D2 has a problem with the GC. It cannot be put to reasonable speed, because of initial design decisions with D memory management. If there is a reason for D3, then it is to make the required changes so that the GC can be made faster. The GC is in my opinion very important for the success of D. Go is the best example that a programming language for "system-like" programming can have a huge success out there in the real world. If using the GC were problem free in D, a lot of projects that chose Go might have gone with D. And there are tons of applications out there that are the flag ship product of some startup company that are written in Go. So the best thing that can happen to D, IMHO, is that the GC issue is resolved even if that required a move from D2 to D3.
Re: What are we going to do about mobile?
Let's not forget Kotlin and Swift, things we'd really be competing against - that is the other NEW stuff. Kotlin/Native is now in the making and there is already a preview: https://blog.jetbrains.com/kotlin/2017/04/kotlinnative-tech-preview-kotlin-without-a-vm/
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On Friday, 21 April 2017 at 17:20:14 UTC, Vasudev Ram wrote: Hi list, I hope the question is self-evident from the message subject. If not, it means: what are D developers generally called (to indicate that they develop in D)? The question occurred to me somehow while browsing some D posts on the forums just now. DLanger? DLangist? D'er? Doer? :) I tend to favor DLanger, FWIW. Interested to know, just for fun ... Here is one for the fun : Dentists
Re: Tuple enhancement
On Sunday, 16 October 2016 at 13:58:51 UTC, Andrei Alexandrescu
wrote:
I was thinking it would be handy if tuples had a way to access
a field by name at runtime. E.g.:
Tuple!(int, "a", double, "b") t;
string x = condition ? "a" : "b";
In Scala you can do this:
def getUserInfo = ("Al", 42, 200.0)
val(name, age, weight) = getUserInfo
See http://alvinalexander.com/scala/scala-tuple-examples-syntax.
You can also do the same thing in Kotlin and in Groovy (in Groovy
it only works if static type checking is not turned on, though).
I fear if D in contrast has a solution for tuples like this:
Tuple!(int, "a", double, "b") t;
string x = condition ? "a" : "b";
double v = t.get!string(x, 3.14);
where variable names are mapped as strings it could harm the
reputation of the language. People have something they could
easily use as a sample to attack the language. These are harsh
words, I know. Sorry for that. I only write this because I feel
people should be advised not to do this. Real tuples or none.
IMHO much better.
Re: Image of D code on Norwegian IT news site
On Thursday, 1 September 2016 at 18:45:14 UTC, deadalnix wrote: On Wednesday, 31 August 2016 at 18:50:58 UTC, simendsjo wrote: An article about how outsourcing reduces the need for Norwegian developers. No links to D other than the image on top though. I wonder what they searched for to find this image. http://www.digi.no/artikler/rader-norske-it-folk-til-a-droppe-programmering/279380 I assume Norwegian jobs are taken away by these annoying Romanians :) I met many of them and they were all nice. But lots of Java development work is going there and to other countries in Eastern Europe. These guys are just as smart and it doesn't take a PhD in rocket science for application development anyway...
Re: Why D is not popular enough?
On Tuesday, 30 August 2016 at 18:36:19 UTC, CRAIG DILLABAUGH wrote: I am going to vote with Adam here. If memory serves me correctly what initially drew me in to the D language was a statement on the main page that "D is not a religion". I think at the time I had been doing some work with Java, where everything had to be an object. Man, I hate Java for that. Many of the inconsitencies and problems in Java come from basic types not being objects. Everything being objects is a great way to keep things easy to understand, consistent and clean. It has some impact on performance, but a lot can be done here which is more than sufficient for application programming. Hot Spot runtime code optimization in Java is very effective. Also, I think saying if you don't like functional programming you will miss 'most' of what D has to offer is really selling the language short. After all you can write C or C++ style code in D if you want, which may be very attractive to some folks. D has a lot to offer with regard to functional programming. It has pure functions and true immutable classes (true = also sub objects become immutable), which Scala all doesn't have (because of restrictions of the JVM). Does D have tail call recursion optimization? I don't know, actually. If D had that and pattern matching, it would beat Scala with all it's hype by a big leap.
Re: Image of D code on Norwegian IT news site
On Wednesday, 31 August 2016 at 18:50:58 UTC, simendsjo wrote: An article about how outsourcing reduces the need for Norwegian developers. No links to D other than the image on top though. I wonder what they searched for to find this image. http://www.digi.no/artikler/rader-norske-it-folk-til-a-droppe-programmering/279380 Well, it seems that outsourcing to India is over. Now it's outsourcing to Eastern Europe. 2/3 of the developers in my company reside in a country in Eastern Europe. In my previous country that ratio was even higher. The CTO wasted a lot of money (because not talking to his people who would have told him) and then had to look for ways to compensate for the losses. I once followed a phone conversation between a C++ developer in India and C++ developers in Germany. The developer in India thought those in Germany were stupid and not getting it while the developers in Germany tried to explain to him that they were not stupid, but that he was missing some detail. Seems to me that outsourcing development in a very difficult language such as C++ does not work. But as what "simpler" languages are concerned such as Java or C# it is currently happening at full high. The dream about systems programming is starting to fade away. There are only very few jobs for it. And the dream about application development is fading away, too. But illusions are here to stay ;-).
Re: I have a problem with D
You can make use of the visitor pattern. The user that created some subclass then only needs to fill the visitor method with some stuff and that's it. The visitor was already initialized when created which happened before it was handed in to the visitor method of the subclass as a method parameter and things are fine. -- Bienlein
Workaround for RefCounted with classes would work?
Hello, RefCounted so far works well with structs, but not with classes (see http://wiki.dlang.org/DIP74). I have now set up a little kludge where a struct takes a class as a template parameter. The struct with the containing object, which is of the type of the struct's template type, is handed over to the RefCounted instance. When RefCounted calls the destructor of the contained struct, the destructor of the object contained by the struct is also called. I have tried this out and it works fine. It seems to be good enough for my purposes. Question is whether there is some hidden problem with this approach. Anything I need to be aware of? I'm not proficient with D. So I thought it's better to ask ;-). Regards, Bienlein
Re: Andrei's list of barriers to D adoption
RefCounted does not work for classes, only for structs. Reason against adoption at least for me ;-).
Re: Some questions on latest work
On Tuesday, 3 May 2016 at 19:54:06 UTC, tsbockman wrote: On Friday, 29 April 2016 at 10:06:06 UTC, Bienlein wrote: All right, thanks for the hint. Is there a timeline till when this DIP will be implemented? No; that particular solution might never be implemented at all. Getting safe reference counting working well in D (*somehow*) is a high priority, though. Andrei Alexandrescu is giving the opening keynote for DConf 2016 tomorrow: http://dconf.org/2016/schedule/ From the abstract, it sounds like he will be discussing the reference counting problem again. Also it would be nice if the GC, that does not leak with 32-bit D, would be plugged into 32-bit D from the beginning. Jeremy DeHaan just started a Google Summer of Code project to make D's GC precise - or at least much *more* precise than it is now: http://forum.dlang.org/post/dgvhslayxialmebvj...@forum.dlang.org If he is able to meet his proposed schedule, I expect there will be a D release with a much less leaky GC in 6 months to a year. All right, that was constructive. Thanks.
Re: Some questions on latest work
On Tuesday, 26 April 2016 at 12:34:49 UTC, cym13 wrote: On Tuesday, 26 April 2016 at 12:19:40 UTC, Bienlein wrote: Hi deadalnix, thanks for taking the time to answer my questions. The issue with RefCounted and classes appears to be fixed. I found this: http://wiki.dlang.org/DIP74. I also found evidence on the Internet that the GC leaking memory is only an issue with 32 bit machines. Looks like I could have just googled those things. Didn't expect things to be that easy. Anyway, thanks for answering. Beware that what you found is but an Improvement Proposal, it hasn't been accepted in its current state yet and it hasn't been implemented either. All right, thanks for the hint. Is there a timeline till when this DIP will be implemented? Also it would be nice if the GC, that does not leak with 32-bit D, would be plugged into 32-bit D from the beginning. Regards, Bienlein
Re: Some questions on latest work
Hi deadalnix, thanks for taking the time to answer my questions. The issue with RefCounted and classes appears to be fixed. I found this: http://wiki.dlang.org/DIP74. I also found evidence on the Internet that the GC leaking memory is only an issue with 32 bit machines. Looks like I could have just googled those things. Didn't expect things to be that easy. Anyway, thanks for answering. With regard to Rust I think it is a very well thought out language also with an ecosystem that is well thought out (e.g. crates, module system, and other things). But it is for pure systems programming. I will not enter this area any more in this life, but do my stuff in Java and have some performance critical parts in C++. For that purpose modelling power still matters and I find Rust falls short in this area (which is probably fine for a pure systems language) whereas C++ and D are very well equipped for this. Cheers, Bienlein
Some questions on latest work
Hello, I've been busy with other things for about a year and would like to ask some questions to catch up with latest language/library additions in D. Looking through the change logs simply appeared to be a bit tedious. My questions might look a bit like asking pain point questions on purpose, but it's really only about catching up with the status on some issues: * There was a problem with the GC leaking memory in some situations. Is this still the case? * There was some talk about changing the standard library in a way that it can be used with the GC and without. My question is what the current status is concerning this topic. * RefCounted only used to work with structs. It would be useful if it worked with classes as well. Is it being considered to work on this? Thanks for any answers. Regards, Bienlein
Re: Rant after trying Rust a bit
I think the ability to express an interface without buying into inheritance is the right move. The alternative in D is specifying the behavior as a template and verifying the contract in a unittest for the type. Rust only has structs. I'm not as familiar with them so it's not as clear how they overlap with D's structs and classes. It seems like you can put Rust structs on the stack or heap. What some people call interface inheritance in Rust is not inheritance in the sense of OOP whewre an inherited method can be overwritten. Rust is here the same as Go. Some people sometimes get confused and don't see that without the possibility of overwriting an inherited method delegation applies and not inheritance. This is also explained in this blog: http://objectscape.blogspot.de/search/label/Go See the section titled Inheritance. -- Bienlein
Re: D casually mentioned and dismissed + a suggestion
You are making a cool project and we'd like to contribute to it, but we don't know and neither feel like studying this silly D. This is indeed a problem for many newly created languages. Scala has somewhat managed to create its own eco system with Akka, Spark, Spray in a specialized area like concurrent programming and big data. Also because Scala has found some liking in academical circles (e.g. Spark, Scala STM). I don't know how things will look like for Kotlin. Maybe there will be a niche for Android development. For Groovy there is basically only Grails as a killer application. For company internal development those languages might find some aficionados, but for open-source development exactly that but we don't know and neither feel like studying argument pops up. The rise of Scala started with Akka. Go has CSP-style concurrency as a killer feature (10k problem solved out of the box, much simpler concurrency). Rust fixes the problem with manual memory management being error prone. So you need some killer argument/feature/application. Otherwise you always face this counter argument.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Java programmers are having to come to terms with this. Python programmers sort of have, except that BDFL has failed to accept the correct end point and still likes loops. Scala has done it all wrong. (Further opinions available on request :-) Could you provide some sample Scala code to demonstrate what you mean? Just because it is not clear to me what this is about. Thanks.
Re: A reason to choose D over Go
I was recently told by a commercial D user, that using D helps them to more easily identify good programmers. It would be nice, if not just D users had this attitude :-) It's also a bit like that for Scala when companies look for Java people. Alas, Scala is a bit overloaded ...
Re: A reason to choose D over Go
I recently made a pull request for a go tool and spent about half an hour trying to find some function to test whether an array contains a particular element. There are libraries for this like gen: http://clipperhouse.github.io/gen. But it also suffers from the absence of generics. trust me, from an undecided but experienced developer's perspective there are so many reasons to choose D over Go. on the otherhand same person has a lot more reasons to choose Go over D. I earn my pay with Java development. In my spare time I learn some Scala hoping there might be some work for me with Scala in the future. Then I need to become familiar with all kinds of new frameworks, tools, libraries and systems that continue to pop up every year in the JVM eco system. In the end there is not much time left for playing with a systems language. As Go is very effortless it could be a good compromise here. I have thrown it away and refetched it due to lack of alternatives several times. I would like to play with D, but it has as step a learning curve as Scala. If you don't have a background in C or C++ the learning curve is even steeper. So it depends a lot from where you are coming. i'm writing a very long blog post about this. if anyone's interested, i can happily share the draft with them. Please drop a comment in this thread or somewhere when it is published. Cheers, Bienlein
Re: A few notes on choosing between Go and D for a quick project
What about using a JVM with green threads support or Quasar, wouldn't it be more comparable? -- Paulo Long text, contents of common interest in the last section :-) Thanks for the hints, Paulo. Quasar looks interesting. The current number one actor implementation for the JVM is Akka (akka.io). It was earlier built on Hawtdispatch (https://github.com/fusesource/hawtdispatch), which is similar to Quasar but much simpler. Now they have plugged in their own scheduler. Those libraries follow the same approach that a small number of threads (small to make the overhead of context switches small) serve a large number of consumers (e.g., channels, actors, or whatever consumer abstraction). This works well as long as all tasks are short-runners. It becomes a problem once you have many long-runners. Me talking about large fibonacci numbers in my previous post was to indicate that it is all about the problem with long-runners. In Vert.x they have a separate scheduler for long-runners that can serve a certain number of tasks and rejects tasks once the max is exceeded. I will check out have they have implemented channel select in Quasar. In Go they can do this efficiently, because it is done by the built-in scheduler and not in the library. As what D is concerned it has vibe.d, which follows on principle the same approach as described above from what I understand about it. There is an old discussion about integrating vibe.d in the D distribution. This way multi-threading in D comes with batteries included as in Go. I still think this is a good idea :-).
Re: OFFTOPIC: GPars performance vs Go [was Re: A few notes on choosing between Go and D for a quick project]
A priori I do not believe the claim made here: a GPars task is
submitted
to a thread pool, which is exactly what the goroutines are.
Thus the
number of Java threads is not a bound on the number of GPars
tasks. Any
bounds will be provided by the Fork/Join pool.
Here is a GPars sample from
http://www.gpars.org/1.0.0/guide/guide/GroovyCSP.html
final class Copy implements Callable {
private final DataflowChannel inChannel
private final DataflowChannel outChannel1
private final DataflowChannel outChannel2
public def call() {
final PGroup group = Dataflow.retrieveCurrentDFPGroup()
while (true) {
def i = inChannel.val
group.task {
outChannel1 i
outChannel2 i
}.join()
}
}
If inChannel.val blocks, the thread serving the Copy instance is
blocked and lost for serving other channels. If this happens
several times the JVM has run out of threads and the application
is in limbo.
This is not the case in Go. When a goroutine is blocked by a
blocking take on an empty channel, the Go scheduler withdraws the
thread serving this goroutine and assigns it to some other
goroutine.
Re: A few notes on choosing between Go and D for a quick project
Go is only a CSP-like, it isn't CSP. cf Python-CSP and PyCSP, not to mention JCSP and GPars. I'm not really sure whether this can be put exactly that way. On a machine with 4 GB RAM you can spawn about 80.000 goroutines (aka green threads). Let's say each threads calculates a large fibonacci number. If the fibonacci calculation yields the processor frequently all 80.000 run seamingly in parallel and return their result almost at the same time. With GPars this would not work. You can only start some 2.000 Java threads on a machine with the same amount of memory. If also the fibonacci calculation in Groovy/GPars yields the processor, using GPars the first 2.000 fibonacci calculations will nevertheless crowd out the following 2.000 threads of all those 80.000 fibonacci calculations and so on. I once tried this out with both Go and Groovy/GPars. -- Bienlein
Re: What is the D plan's to become a used language?
On Monday, 22 December 2014 at 21:46:48 UTC, ketmar via Digitalmars-d wrote: i can assure you that concurency in the language is not the only thing one needs to know before start writing a server. you keep telling that everything else in Go is so cheap to learn, so only CSP matters. oh, really? Go can magically do all header parsing, database management and other things for me? or we talking about echo servers? Go does have good libraries for networking and support for REST, WS, messaging systems, bindings to other messaging systems, and all that stuff. I remember that even Walter or Andrei acknowledged that themselves somewhere in a post in this forum. To me Go is too simplistic. Everytime I try to like it I can't resist to say No, I can't continue with this. It's just too minimalistic.. But they have a true selling point which is developing server side software and they have the batteries included for that. What I'm saying is that being good at everything is good, but only a true selling point would receive people's attention. That's the way it is. Making D fit for server side development is a suggestion of mine. It seems to me something that has traction and will continue to have so unless the Internet dies a sudden death. There might be other even better ideas what could be selling points, but continuing with being good at everything and hoping that one day a big spender will come along might in the end not work out and result in a great loss of time. I don't want to appear harsh. It only seems to me that I wasn't able to bring my point across. Cheers, Bienlein
Re: What is the D plan's to become a used language?
People have already suggested you to actually try vibe.d at least once before repeating CSP is necessary for easy async mantra. I was trying to point out in some previous thread that the value of CSP is that concurrent things from the code looks like sync calls (not async, but sync). The statement above again says async and not sync (in CSP is necessary for easy async mantra.). So, I'm not sure the point was understood. Asynchronous programming is very difficult to get right and also inherently difficult. Programming with channels where things look like synchronous calls make concurrent programming immensely easier than with asynchronous programming. If you have done asynchronous programming for some years and then only spend 1/2 h looking at concurrency in Go you will grasp immediately that this is a lot lot simpler. All cores are being made used of very evenly out of the box and are constantly under high load. You have to work very hard for long time to achieve the same in Java/C/C++/C#/whatever, because the threading model is conventional. With CSP-style concurrency in Go it is a lot easier to write concurrent server side applications and whatever you do can hold 40'000 network connections out of the box. Yes, you can do that with vibe.d as well. But for Go you only need to learn a drop simple language and you can start writing your server application, because all you need for concurrency is in the language. One idea would be to add a drop dead simple abstraction layer for vibe.d to provide the same and sell D as a language for server side development like Go. There is a need for a unique selling point. Let's say the guys at Docker had chosen D, because it had that already. Then they would realize that they also can use D for general purpose programming and be happy. But first there has to be a unique selling point. The selling point of a better C++ has not worked out. You have to accept that and move on. Not accepting that time moves on is not an option. Sorry, but wrong and wrong. Go has a model of concurrency and parallelism that works very well and no other language has, so Go has technical merit. The technical merit is in the concurrency model as already said in the statement above. And currently is the time of server side software development. When C++ was started it was time for some better C. That time is over. Things change constantly and there is nothing you can do about that. You can accept that things have moved on and make use of the new chance of server side programming as a new selling point or continue living in the past. Go might be simplistic. So add CSP-style channels to D and you can overtake Go in all respects very easily. Besides, Haskell also has channel-based inter-process communication. If that is not academical/scientiic backing then I don't know.
Re: What is the D plan's to become a used language?
I would say that D needs a usecase that puts it aside from other languages. For Java this was the Internet. For Go it was channel-based concurrency in conjunction with some style of green threads (aka CSP). It is now the time of server side concurrent programming. I would suggest to jump onto this wagon and add channels and green threads to D. When people successfully develop many server side systems this way as with Go the news will spread by itself. No killer app for D needed. Also Go does not have one. -- Bienlein
Re: What is the D plan's to become a used language?
On Saturday, 20 December 2014 at 12:24:29 UTC, Paulo Pinto wrote: On Saturday, 20 December 2014 at 12:19:34 UTC, Bienlein wrote: I would say that D needs a usecase that puts it aside from other languages. For Java this was the Internet. For Go it was channel-based concurrency in conjunction with some style of green threads (aka CSP). It is now the time of server side concurrent programming. I would suggest to jump onto this wagon and add channels and green threads to D. When people successfully develop many server side systems this way as with Go the news will spread by itself. No killer app for D needed. Also Go does not have one. -- Bienlein Go has Google's sponsorship, Docker and CoreOS. Message passing for concurrent server programming means asynchronous programming. Asynchronous programming is inherently difficult and error prone. I have done it for years and everyone else who has can confirm this. The big thing with CSP-style channels is that while things are going on concurrently the code can be read like synchronous code. This way a lot of people out there have built server side systems with Go in record time. All the startups using Go are proof for this. There is really a lot of technical data and scientic papers about this. The success of Go tells its own story. Also Rust will have a module for CSP-style concurrent programming. That comes for a reason. This is the original paper titled Communicating Sequential Processes by C. A. R. Hoare: http://www.usingcsp.com/cspbook.pdf. CSP is not missing technical data. It has a solid basis and Go shows that it works well. It has drawbacks like lack of pre-emptiveness, but things like the C10K problem solved out of the box is more important to many server side systems to be built. Apparently, for D some commercial big spender has never popped up. Killer apps to be developed need some good piece of fortune to turn out successfull. But adding a more adequate multi-threading/concurrency model to D and make it a success. And that takes little resources compared to other alternatives to make D more widely used. Docker is not developed by Google. It is made by a company of its own who was looking for a language suitable for server-side concurrent programming. It could have been D if D better support for this.
Re: What is the D plan's to become a used language?
On Saturday, 20 December 2014 at 12:21:49 UTC, Dicebot wrote: CSP is not superior to message passing for concurrent server programming and D already beats Go in this domain, it is purely marketing crap. Stop repeating same statement over and over again with no technical data to back it up. Or just go and implement CSP if you want it so much - I doubt anyone would object merging it if it is already implemented. A different approach would be to use D's existing multi-threading model and develop a first class actor system for it like Akka for Scala/Java. But that would be a big effort and competing with Akka would be difficult anyway. So, again, an idea to think of might be to add CSP to D.
Re: What is the D plan's to become a used language?
On Saturday, 20 December 2014 at 12:50:02 UTC, Dicebot wrote: People have already suggested you to actually try vibe.d at least once before repeating CSP is necessary for easy async mantra. How about actually doing so? vibe.d + std.concurrency gives you pretty much standard actor model - it lacks more complicated schedulers and network message passing but fundamentals are all there. CSP-style programming in D needs to be drop-dead simple as in Go to take off. You need to know about channels and the go command to spawn a thread and that's it. That's why Go was that successful. Vibe.d might be a well written system, but nobody will learn D and thereafter vibe.d. It is either laughable simple as in Go or it will not be noticed. The simplicity of channels and goroutines as in Go created the excitement. The same simplöicity is needed for any other language. The whole thing can be implemented with vibe.d, but at the surface there must only by goroutines and channels and nothing more.
Re: What is the D plan's to become a used language?
On Saturday, 20 December 2014 at 14:06:51 UTC, Paulo Pinto wrote: That is why I seldom buy into hype driven development. Okay, so Docker is hype? Have you seen the impact of it? Every Java magazine has articles about Docker. And that is not because Java people had an interest in it, because it is written in Go. It is because of its business value. Have a look at all the job offers for Go developers here: http://www.golangprojects.com. All those jobs are the result of some hype.
Experimental JavaScript compiler written in D
Experimental JavaScript compiler [written in D] shakes up ideas about speed, simplicity: http://www.javaworld.com/article/2686955/html-css-js/experimental-javascript-compiler-shakes-up-ideas-about-speed-simplicity.html Unless I missed something so far no post has been made in this forum to point people to this interesting article. So I thought I have to do it. Regards, Bienlein
Re: Getting RefCounted to work with classes
On Tuesday, 26 August 2014 at 06:01:25 UTC, uri wrote: RefCounted does not work with classes. Classes are reference types already. Yep, that's the problem. I also got some suspicion, then surfed the Internet and found the information about it. Thanks for explaining the error message to me. Now it even seems obvious to me what it wants to say ;-). But you can define a var inside a struct that holds a class and this way I got it working with my class as well thanks to generics in D. Woohoo!
Non-GC based List/Set/Map implementation?
Hello, does anyone know of a List/Set/Map implementation that does not rely on the GC? The would be the last thing I need for D to be really happy with it ;-) Thanks, Bienlein
Re: Non-GC based List/Set/Map implementation?
Thanks for the replies. This looks good. I meanwhile found http://dsource.org/projects/dcollections But it seems to be GC-based just like Tango ... ;-(.
Getting RefCounted to work with classes
Hello,
the code below compiles and runs fine. However, when I change
Payload from struct to class I get compiler errors:
Error 1 Error: template instance
std.typecons.RefCounted!(Payload,
cast(RefCountedAutoInitialize)1) does not match template
declaration RefCounted(T, RefCountedAutoInitialize autoInit =
RefCountedAutoInitialize.yes) if (!is(T ==
class)) C:\Users\Nutzer\Windows Ordner\Documents\Visual Studio
2013\Projects\RefCountedScratch\RefCountedScratch\main.d 26
I tried many things, but nothing did it. Any help appreciated :-).
Thanks, Bienlein
import std.stdio;
import std.typecons;
struct Payload
{
private int num = 0;
this(int i)
{
num = i;
writefln(Payload's constructor called);
}
~this()
{
writefln(Payload's destructor called);
}
}
int main(string[] argv)
{
alias RefCounted!(Payload, RefCountedAutoInitialize.yes) Data;
int bar = 12;
Data data = Data(bar);
return 0;
}
How to get nogc to work with manual memory allocation
Hello,
I was having a look at the new nogc annotation and therefore
wrote some code that creates an instance on the heap bypassing
the GC (code adapted from http://dpaste.dzfl.pl/2377217c7870).
Problem is that calls to call the class' constructor, destructor
and others can't be called anymore once nogc is used. So the
question is how to get manual allocation and deallocation done
with using nogc. Here is the experimental code:
@nogc
T nogcNew(T, Args...) (Args args)
{
import std.conv : emplace;
import core.stdc.stdlib : malloc;
// get class size of class object in bytes
auto size = __traits(classInstanceSize, T);
// allocate memory for the object
auto memory = malloc(size)[0..size];
if(!memory)
{
import core.exception : onOutOfMemoryError;
onOutOfMemoryError();
}
// call T's constructor and emplace instance on
// newly allocated memory
return emplace!(T, Args)(memory, args);
}
@nogc
void nogcDel(T)(T obj)
{
import core.stdc.stdlib : free;
// calls obj's destructor
destroy(obj);
// free memory occupied by object
free(cast(void*)obj);
}
@nogc
void main()
{
TestClass test = nogcNew!TestClass();
test.x = 123;
nogcDel(test);
test.x = 456; // no protection violation ?!
// remove @nogc to run this
TestClass t = new TestClass();
t.x = 789;
delete t;
t.x = 678; // protection violation as expected
}
I have omitted the code for the TestClass class to save space.
Problem is that the compiler outputs this:
Error: @nogc function 'main.nogcNew!(TestClass, ).nogcNew' cannot
call non-@nogc function 'core.exception.onOutOfMemoryError'
Error: @nogc function 'main.nogcNew!(TestClass, ).nogcNew' cannot
call non-@nogc function 'std.conv.emplace!(TestClass, ).emplace'
Error: @nogc function 'main.nogcDel!(TestClass).nogcDel' cannot
call non-@nogc function 'object.destroy!(TestClass).destroy'
Is there a way to get around this? Then the test.x = 456; did not
cause a protection violation although the instance was
deallocated before calling nogcDel. Something with the
deallocation in nogcDel seems not to work. Some hint appreciated
on this. When calling delete t the protection violation happens
on the next line as expected.
Thanks a lot, Bienlein
Re: How to get nogc to work with manual memory allocation
On Sunday, 24 August 2014 at 08:48:03 UTC, bearophile wrote:
Perhaps there are ways, but note that @nogc is meant mostly for
stack-allocation.
Ah, I missed that. Thanks for telling me. I changed nogcDel now
to null out the deallocated object:
void nogcDel(T)(ref T obj)
{
import core.stdc.stdlib : free;
// calls obj's destructor
destroy(obj);
// free memory occupied by object
free(cast(void*)obj);
obj = null;
}
And now I also get the dearly missed protection violation ;-).
Re: Opportunities for D
I think Walter is exactly right with the first 7 points he is listing in his starting post of this thread. Nullable types are nice, but don't get too much distracted by them. The first 7 points are far more important. Go takes absolutely no effort to get rid of nil and they are very successful in despite of this nil thing. IMHO goroutines and channels is really the key. D might be a better C++. But languages need a use case to make people change. I don't see why D can't do for cloud computing and concurrent server-side software what Go is doing. Go's GC is also not that advanced, but it is precise so 24/7 is not a problem. Making the D GC precise is more important than making it faster. Actually, you get the strange situation now that to make D a language for the cloud a quick approach would be to make everything GC and let people have pointers as well as in Go. Of course, no good approach for the long run prospects of D. But let all memory management be handled by the GC should remain easy in D. Otherwise, D will be for the systems people only as with Rust. Much of the froth about Go is dismissed by serious developers, but they nailed the goroutine thing. It's Go's killer feature. I think so, too. Along with channels and channel selects to coordinate all those goroutines and exchange data between them. Without them goroutines would be pointless except for doing things in parallel. I'm not sure you can do selects in the library with little lock contention, but I'm not an expert on this. Think of it from the perspective of attracting Erlang programmers, or Java/Scala programmers who use Akka. Not wanting to be rude, but you don't stand a chance with that. Java has Hadoop, MongoDB, Hazelcast, Akka, Scala, Cassandra and MUCH more. No way you can beat all that. Hordes of average Java developers that will be against you, because they know Java and nothing else and don't want to loose their status. But Go also does not have these things. It's success is huge, though, and it seems mostly to be attributed to goroutines and channels. This made Go the language for the cloud (at least other people say so), which is what there is a need for now. Other than that Go is drop dead simple. You can start coding now and start your cloud software start-up now. There is nothing complicated you need to learn. D cannot compete with that (thank goodness it is also no minimalistic language like Go). Akka similarly uses its own lightweight threads, not heavyweight JVM threads. Akka uses some approach like Apple's Grand Central Dispatch. As I understand it so does vibe.d (using libevent). A small number of threads is serving queues to which tasks are added. This works fine as long as those tasks are short runners. You can have 50.000 long runners in Go. As long as they aren't all active the system is well responsive. You can't have 50.000 long-runners in Akka, because they would block all kernel threads that serve the task queues. The 50.000 and first long running task will have to wait a long time till it will be served. This is why they have special worker threads in Vert.x for Java: threads that are reserved for long-runners (and you can't have many of them).
Re: Programming in D book is 100% translated
Very nice piece of work. Thank you! The PDF version seems not to have a table of contents. Would be really helpful if it had :-).
Re: Java compilation [was GCs in the news]
The JVM JIT was originally targeted to SELF, not Java. Yes, that's right. The guys that developed Self (David Ungar et al.) then set out to develop a high-performance typed Smalltalk using the optimization techniques they developed for Self. The Smalltalk system never hit the market as the development team was acquired by Sun before that could happen. The Smalltalk system they were working on was released to the public: http://www.strongtalk.org/ I think you'll find HotSpot evolved from a Smalltalk JIT originally. The reason I replied to this is that the original technology developed for Self was not a JIT. It was a runtime byte code optimizer that was put into Java named HotSpot. Since HotSpot operates at runtime it can optimize things an optimizing compiler could not find at compile time. This is why Java sometimes catches up very good performance and in isolated cases can compete with C.
Re: spawn and wait
There is also a Semaphore and Barrier class: http://dlang.org/phobos/core_sync_barrier.html http://dlang.org/phobos/core_sync_semaphore.html
Re: Passing around a list of differently typed functions
On Monday, 23 June 2014 at 01:16:49 UTC, Evan Davis wrote: As the subject says, I would like to pass around an array of functions. The trick is, that the functions have different type signatures. Is there a way to put the two functions int foo(int a, int b); bool bar(bool a, bool b); into one array, that I can pass around and cast as necessary? Thanks, Evan Have functions in the array without parpameters that call the function with the applicable parameters, e.g. int foo(int a, int b) or bool bar(bool a, bool b). That doesn't address the problem of the different return types (int and bool). So change the return type to void and return the value as an inout parameter.
Re: Some kind of RPC exists for D?
On Saturday, 21 June 2014 at 18:22:54 UTC, Paul wrote: I wrote some (JSONRPC and TXTRPC) and used them with vibe. I can send you via email Hi Paul, alternatively you could upload your code to GitHub or some similar place and place the link here. Then you also have a means to proof that the code is your work along with the date of publication. -- Bienlein
Re: Adding the ?. null verification
On Wednesday, 18 June 2014 at 15:57:40 UTC, Etienne wrote:
On 2014-06-18 11:55 AM, bearophile wrote:
Etienne:
writeln(obj.member?.nested?.val);
What about an approach like Scala instead?
Bye,
bearophile
You mean like this?
http://stackoverflow.com/questions/1163393/best-scala-imitation-of-groovys-safe-dereference-operator
def ?[A](block: = A) =
try { block } catch {
case e: NullPointerException if
e.getStackTrace()(2).getMethodName == $qmark = null
case e = throw e
}
val a = ?(b.c.d.e)
I think he means to use the Option class instead of returning
null. Also Rust does it that way.
Re: Some kind of RPC exists for D?
What data load profile do you expect? Vibe is tuned to handle thousands simultaneous incoming light requests (milliseconds), while distributed computing works better with exclusive heavy requests, at least minutes of work worth, BOINC uses hours worth work items. Communication will be bi-directional as some thread sends computation along with the data to be computed to some remote thread and somewhen waits for the answer. The amount of data will be relatively small, that is only consisting of numbers to be processed creating some result, because Julia is geared towards scientific computing. In that way there is little data compared to enterprise computing. How often remote computations are initiated depends to a large extend on the user. So that is hard to say. But from the typical use case scenario it will be anything but few large messages to go across the wire. I might have to do a bit more research looking at Julia to get a better understanding. But it's all about performance, e.g. crunching as many numbers as quickly as possible. So I will have to stick to a high-performance solution anyway. For that reason it looks more like Swift or ZeroMQ. Depends a lot which one can do marshalling and unmarshalling of the function invocation and the data more transparently than the other.
Re: Some kind of RPC exists for D?
What I want to do is some little framework that allows Julia-style (julialang.org) distributed computation: send some function invocation to some other machine along with the numbers to be crunched and get the result back. vibe.web.rest server/client combo is effectively RPC over HTTP/json This looks good. For what am I'm thinking of doing performance is important. In that way rest makes me think a bit or is this only a prejudice from the Java world? I wrote an implementation of Thrift for D a while back This also looks interesting. Because my C/C++/D skills are limited being a Smalltalk/Java developer (only played with C++ when studying) I have to stick to what is easier to use. It would be a fun leisure learning project anyway... Regards, Bienlein
Some kind of RPC exists for D?
Hello, I'm looking for a way to do some kind of RPC in D. Some way of being able to say aFoo.bar(int i, ...) with receiver object and method being marshalled at the sender's site and being unmarshalled and invoked at the receiver's site. Any hints appreciated. Thanks, Bienlein
Re: [OT] Go officially won't get generics
On Wednesday, 7 May 2014 at 15:54:42 UTC, Paulo Pinto wrote: So the videos of the Gophercon 2014 are being made available. Rob Pike did the keynote. At the expected question about generics, his answer was There are no plans for generics. I said we're going to leave the language; we're done.. Discussion ongoing on HN, https://news.ycombinator.com/item?id=7708904 -- Paulo When Rob Pike was asked at the end of his keynote speech whether Go will support generics one day the majority of the audience was immediately laughing. If I were into Go this would make me think. I don't think parameterized types are necessary for a typed language to be good. But in Go it would be helpful to allow workarounds for modelling problems. As I like the way concurrency is done in Go I tried several times to find programming solutions that can manage without violating visibility rules or having duplicate variables or some other compromise. But there was simply no way.
Re: [OT] Go officially won't get generics
Well, he had previously stated that there would be no breaking changes, and that if there were changes it would have to be called go version 2 or something. So when generics were brought up he stated that there were no plans for generics and I said we are going to leave the language, we are done (with version 1 semantics). Ola.. Robert Pike says in this thread (https://groups.google.com/forum/?hl=de#!topic/golang-nuts/3fOIZ1VLn1o): Go has type switches, and therefore no need for the Visitor Pattern.. He has exactly the same mindset as Niklaus Wirth and Oberon never got templates. Future will tell... Would be a nice thing to bet a dime on whether Go will have generics or not. I bet not ;-).
Re: [OT] Go officially won't get generics
On Wednesday, 7 May 2014 at 15:54:42 UTC, Paulo Pinto wrote: So the videos of the Gophercon 2014 are being made available. Rob Pike did the keynote. At the expected question about generics, his answer was There are no plans for generics. I said we're going to leave the language; we're done.. Discussion ongoing on HN, https://news.ycombinator.com/item?id=7708904 -- Paulo I agree with Paulo. At 54:40 he says what Paulo has already quoted. And we are done means that's it, folks. It even sounds to me like the language is finished and it will be left like that. -- Bienlein
Re: Spawn as many thousand threads as you like and D
I still don't understand what you mean by distributed.
Spawning 50.000 tasks:
import vibe.core.core;
import std.stdio;
void main()
{
foreach (i; 0 .. 50_000)
runTask({
writefln(Hello, World!);
});
}
Alternatively, runWorkerTask will also distribute the tasks
among a set of worker threads, which would be more in line with
Go AFAIK.
Hello Sönke,
would it be possible in vibe.d to spawn a task the usual
actor-style way as it is done with kernel threads in D? What I
mean is this:
void spawnedFunc(Tid tid)
{
receive(
(int i) { writeln(Received the number , i);}
);
}
auto tid = spawn(spawnedFunc, thisTid);
Thanks, Bienlein
Re: Spawn as many thousand threads as you like and D
On Wednesday, 7 May 2014 at 17:13:07 UTC, Sönke Ludwig wrote:
The Tid handling is currently a little different, but apart
from that it
should work like this:
import vibe.core.core;
import vibe.core.concurrency;
void spawnedFunc(Tid tid)
{
receive(
(int i) { writeln(Received the number , i); }
);
}
// run it as a fiber in the same thread
// note: runTask only takes a delegate to make runTask({
... })
// work without an ambiguity error
auto tid = runTask(toDelegate(spawnedFunc),
Task.getThis());
// or run it in the thread pool instead
runWorkerTask(spawnedFunc, Task.getThis());
Having said that, I'll just add a thisTid property to
vibe.core.concurrency to make that part API compatible. I'd
also add a
spawn alias, but the question is if that should point to
runTask or
rather to runWorkerTask.
BTW, a runnable example can be found here:
https://github.com/rejectedsoftware/vibe.d/blob/master/examples/message/source/app.d
Thanks for the quick answer. I'll give it a try ;-).
Re: D Breaks on to the TIOBE Top 20 List.
On Friday, 25 April 2014 at 19:51:22 UTC, Adam Wilson wrote: I know we don't place much value in TIOBE and it's brethren. However, I thought that this was a milestone worthy of a note anyways. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html I don't want to take your joy, but tiobe has its mood swings: Groovy was within the top 20 last year, see http://glaforge.appspot.com/article/groovy-enters-top-20-of-the-tiobe-language-index Now it is somewhere below the top 40. I think it was below the top 50 at the beginning of the year. Nevertheless, it is certainly good news :-).
Re: On Concurrency
One key difference is that coroutines won't make your programs run faster. It is a modelling mechanism that can simplify your programs where you otherwise would have to implement a state machine. This is also my impression when I look at this code (see http://www.99-bottles-of-beer.net/language-d-2547.html) that implements 99 bottles of beer in D with fibers. What seems to be happening is some alternating handover of the CPU. But when I run the code all 4 cores of my machine are under load and it looks like the runtime were able to make things run in parallel somehow. Now I'm really confused ...
Spawn as many thousand threads as you like and D
When looking at the success of Go it seems to me that it is caused to a large extend by the kind of multi-threading Go offers which is something like spawn as many thousand threads as you like. Being able to spawn as many thousand threads as needed without caring about it seems to be an important aspect for being an interesting offering for developing server-side software. It would be nice if D could also play in that niche. This could be some killer domain for D beyond being a better C++. While Go uses channels and goroutines D takes some actor-style approach when spawning threads. This is also fine, but the problems remains that you cannot create as many D kernel threads just as you like. Maybe this could be something to improve in D and promote in order to give D a further boost. I don't mean to be pushy, it's just about exchanging ideas ;-). The FiberScheduler by Sean Kelly could achieve something in that direction. What do you think? Regards, Bienlein
Re: Spawn as many thousand threads as you like and D
On Wednesday, 16 April 2014 at 14:06:13 UTC, Sönke Ludwig wrote: I agree, but I also wonder why you still keep ignoring vibe.d. It achieves exactly that - right now! Integration with std.concurrency would be great, but at least for now it has an API compatible replacement that can be merged later when Sean's pull request is done. The point is that vibe.d is a distributed solution. Nothing wrong about that. But in a single instance of some Go program you can locally spawn as many threads as you like with the number of threads easily being 50.000 and more. It seems that in the Go community people often do that without going distributed. Looks like this makes things a lot simpler when writing server-side applications.
Re: Spawn as many thousand threads as you like and D
On Wednesday, 16 April 2014 at 14:21:03 UTC, Sönke Ludwig wrote:
I still don't understand what you mean by distributed.
Spawning 50.000 tasks:
import vibe.core.core;
import std.stdio;
void main()
{
foreach (i; 0 .. 50_000)
runTask({
writefln(Hello, World!);
});
}
Alternatively, runWorkerTask will also distribute the tasks
among a set of worker threads, which would be more in line with
Go AFAIK.
All right, I see. I spent some time looking at the vibe.d
homepage and I never saw any other code than something like this:
shared static this()
{
auto settings = new HTTPServerSettings;
settings.port = 8080;
listenHTTP(settings, handleRequest);
}
void handleRequest(HTTPServerRequest req,
HTTPServerResponse res)
{
res.writeBody(Hello, World!, text/plain);
}
Not wanting just to be right, but things like that should still
be in some base library of the language and not in some 3rd party
library. The vibe.d homepage says As soon as a running fiber
calls a special yield() function, it returns control to the
function that started the fiber.. Yielding in the FiberScheduler
by Sean Kelly is transparent. That's an important point to be
easy to use, I think. Also the use of libevent is mentioned. I
don't understand what the implications of that exactly is.
What I mean is that some nice transparent solution in a base
library for the some ten thousand threads thing would be nice.
