Re: template library like Jinja
On Wednesday, 21 November 2012 at 20:56:04 UTC, Masahiro Nakagawa wrote: On Tuesday, 20 November 2012 at 11:38:46 UTC, Tobias Pankrath wrote: Is there any template library like Jinja? (jinja.pocoo.org). I'm pretty sure we can do even better by leveraging CTFE and a precompiler, but speed is no concern for me. I'm not familiar with Jinja. So I may not meet your expectation, but I have the D version of Mustache template engine. https://github.com/repeatedly/mustache4d http://mustache.github.com/ Masahiro jinja2 or twig better to use!
Re: @property
On Thursday, 8 December 2016 at 22:46:32 UTC, Jonathan M Davis wrote: On Thursday, December 08, 2016 22:11:22 ArturG via Digitalmars-d-learn wrote: On Thursday, 8 December 2016 at 16:54:57 UTC, Adam D. Ruppe wrote: > On Thursday, 8 December 2016 at 16:53:13 UTC, Satoshi wrote: >> is there any advantage of marking function as @property?? > > Not really. I think it just changes the meaning of > typeof(thatfunc) but otherwise it does nothing. > > However, if you use it in a base class, you must also use it > when overriding the function. it does when you add it to for example a struct with alias opCall this. reported it as a bug https://issues.dlang.org/show_bug.cgi?id=16951 but seems to be addressed by https://wiki.dlang.org/DIP23 ... - Jonathan M Davis i actually didnt want to use @property at all, as i asumed that by using alias opCall this it would always call opCall not only sometimes. the issue was about the commented line // a; // Error: var has no effect in expression (a) the rest can be solved by @property or a custom toString.
Re: Range of uncopyable elements
On Thursday, December 08, 2016 22:32:47 Jerry via Digitalmars-d-learn wrote:
> On Thursday, 8 December 2016 at 21:46:26 UTC, Jonathan M Davis
>
> wrote:
> > However, at least as of C++98, non-copyable elements in a
> > container were not allowed IIRC, so it would have been pretty
> > rare to have a C++ iterator that returned a non-copyable value
> > when you dereferenced it.
>
> Even if it was uncommon, i doubt anyone actually made a copy of
> the dereferenced iterator.
I've seen that in C++ code all the time, especially if you're dealing with
smart pointers, because otherwise you have to do stuff like (*iter)->foo()
instead of just var->foo().
> There were also no restrictions in place that every algorithm
> needed it to be copyable, only the ones that actually needed it.
> In the case of C++, dereferencing an iterator was basically free.
> As an iterator was essentially a pointer and there were no
> special iterators.
Except that C++ _does_ have special iterators. They're just not as common.
> As an example you can write the following in C++:
>
> int foo0() { return 10; }
> int& foo1() { static int i; return i; }
>
> const int& a = foo0(); // a copy is made on the stack, this
> ref points to it
> const int& b = foo1(); // this ref points to the global
> variable in foo1()
> > Yes, not allowing copyable elements for ranges is a problem.
> > But allowing them would also be a big problem.
>
> Not if one of the biggest and most reoccurring complaints with D
> was fixed.
With the upcoming improvements to @safe and return ref, it _might_ happen
that there will be a way for a function to accept rvalues by ref. Andrei has
indicated that a really good proposal might be accepted. But that's a
separate issue from having ref on local variables, which is what would be
required for what you're suggesting, and both Walter and Andrei have been
adamant that that is not worth it - even without getting rvalue references
into the mix. I don't know that it would be impossible to convince them
otherwise, but I would be _very_ surprised if anyone managed to talk them
into it.
And for the most part, with ranges, this is pretty much a non-issue. It does
become an issue when you start worrying about ranges with a non-copyable
front, but this is literally only the second or third thread that I have
ever seen where anyone complained about it. Much as it is annoying when
someone runs int ito, it's not a big complaint that folks have. And given
how much of a pain it would be to deal with in general, I seriously question
that it's worth it - especially when simply using pointers fixes the
problem.
- Jonathan M Davis
Re: @property
On Thursday, December 08, 2016 22:11:22 ArturG via Digitalmars-d-learn wrote: > On Thursday, 8 December 2016 at 16:54:57 UTC, Adam D. Ruppe wrote: > > On Thursday, 8 December 2016 at 16:53:13 UTC, Satoshi wrote: > >> is there any advantage of marking function as @property?? > > > > Not really. I think it just changes the meaning of > > typeof(thatfunc) but otherwise it does nothing. > > > > However, if you use it in a base class, you must also use it > > when overriding the function. > > it does when you add it to for example a struct with alias opCall > this. > reported it as a bug > https://issues.dlang.org/show_bug.cgi?id=16951 > > but seems to be addressed by https://wiki.dlang.org/DIP23 Except that it's not really a bug. It's a design flaw in the original solution for properties which gave us optional parens. And since @property has never really been implemented to properly _do_ much of anything, it doesn't actually fix the problem. While it's a nice idea in concept, @property was half-baked from the beginning, and it's never actually done anything useful except act as documentation. So, as it stands, @property doesn't matter for anything like this. It's just that we would need to actually implement something with it to solve that particular problem (DIP23 being one proposal to do so). And as it stands, property functions for callables simply don't work like a variable would, defeating the purpose of making them properties. It would be very nice if we got a DIP that was approved which solved this, but @property is not a topic that much of anyone wants to discuss at this point. There's never really been agreement on how properties should be handled in D, and everyone is sick of discussing it. And we've lived with this flaw with callables and properties for years now. So, I think that it would be pretty hard to get a DIP past Walter and Andrei, much as we really should clean this @property mess up. - Jonathan M Davis
Re: Range of uncopyable elements
On Thursday, 8 December 2016 at 21:46:26 UTC, Jonathan M Davis
wrote:
However, at least as of C++98, non-copyable elements in a
container were not allowed IIRC, so it would have been pretty
rare to have a C++ iterator that returned a non-copyable value
when you dereferenced it.
Even if it was uncommon, i doubt anyone actually made a copy of
the dereferenced iterator.
There were also no restrictions in place that every algorithm
needed it to be copyable, only the ones that actually needed it.
In the case of C++, dereferencing an iterator was basically free.
As an iterator was essentially a pointer and there were no
special iterators.
Also, it pretty much _is_ assumed that
auto h = r.front;
is cheap, and there are plenty of cases where calling front
multiple times for the same range would incur additional
overhead, because front is calculated rather than simply
returning a value (e.g. this is what happens with map).
So, it could be a definite performance hit in general to start
insisting that r.front be called without the value being
assigned somewhere.
No one suggested calling front multiple times as a fix. Part of
the problem with D is an old one and one that comes up often.
There are no rvalue references. This means it's a pain in the ass
to write generic code. There's no easy way to write code that
will work for both references and values.
As an example you can write the following in C++:
int foo0() { return 10; }
int& foo1() { static int i; return i; }
const int& a = foo0(); // a copy is made on the stack, this
ref points to it
const int& b = foo1(); // this ref points to the global
variable in foo1()
in D:
int foo0() { ... }
ref int foo1() { ... }
auto a = foo0(); // a copy is made
auto b = foo1(); // a copy is made
auto c = (); // need to write different code to get the
result we want
void callback(ref int);
callback(a); // ok
callback(b); // ok
callback(c); // nope
The problem lies with D's inability to write generic code that
works in boths instances. This means writing the same code twice
in some instances, or just not supporting one of the methods.
Yes, not allowing copyable elements for ranges is a problem.
But allowing them would also be a big problem.
Not if one of the biggest and most reoccurring complaints with D
was fixed.
What we should ultimately do about it, I don't know, but I
think that it's pretty clear that the majority of code would be
better off if non-copyable elements for ranges were not
allowed. And it _is_ possible to work around the problem by
doing as H.S. Teoh suggested and using ranges of pointers.
I don't think so. There's a lot of functions that work with
non-copyable
elements. Without modifying any code, the only blockage is caused
by isInputRange.
Oh well, custom build of phobos it is.
Re: @property
On Thursday, 8 December 2016 at 16:54:57 UTC, Adam D. Ruppe wrote: On Thursday, 8 December 2016 at 16:53:13 UTC, Satoshi wrote: is there any advantage of marking function as @property?? Not really. I think it just changes the meaning of typeof(thatfunc) but otherwise it does nothing. However, if you use it in a base class, you must also use it when overriding the function. it does when you add it to for example a struct with alias opCall this. reported it as a bug https://issues.dlang.org/show_bug.cgi?id=16951 but seems to be addressed by https://wiki.dlang.org/DIP23
Re: @property
On Thursday, December 08, 2016 16:54:57 Adam D. Ruppe via Digitalmars-d- learn wrote: > On Thursday, 8 December 2016 at 16:53:13 UTC, Satoshi wrote: > > is there any advantage of marking function as @property?? > > Not really. I think it just changes the meaning of > typeof(thatfunc) but otherwise it does nothing. > > However, if you use it in a base class, you must also use it when > overriding the function. Yeah, it's pretty common for folks to slap @property on functions to make it clear that it's intended to be used as a property and thus is a getter or setter. So, it serves a purpose from the standpoint of documentation. But at this point, it doesn't make much differently on the technical level. The differences with typeof and stuff like std.traits.FunctionAttributes are what would be different. You can use the property syntax whether @property was used or not. The history of @property is a bit of a mess. It was an attempt to move away from the ad-hoc situation with anything being treated as a property if it had a signature that worked with one (e.g. something like writeln = 7; is legal), but for various reasons, it never worked out, and we got a partial transition with @property ultimately being mostly for documentation purposes. One place where this is truly a technical problem rather than a stylistic one is property functions that return callables, since if you try and call them with parens, you end up just calling the property function (whether it's marked with @property or not), and you need a second set of parens to actually call the callable, meaning that it doesn't actually work as a property. So, @property _might_ be changed at some point in the future to fix that problem, but given how long it's been the way that it is, there's a good chance that we're just stuck with how it is, and it's going to do pretty much nothing on a technical level except cause some corner case weirdness with typeof and be detectable by introspection. It does serve as documentation though, which I think is a lot of why many folks who know full well what the whole situation with properties is continue to use it. - Jonathan M Davis
Re: Range of uncopyable elements
On Thursday, December 08, 2016 20:21:41 Jerry via Digitalmars-d-learn wrote: > Assuming that is wrong though, as you aren't copying an iterator > or range you are copying the actual value. What you are confusing > "auto h = r.front;" for is this: "auto rcopy = r;". The D code > "auto h = r.front" is not a cheap operation and the equivalent in > C++ is actually this: "auto h = *iterator;" and one should not > assume it is cheap, cause it isn't. Anyways your comparison with > C++ is off. His comparison with C++ is off, because front isn't analogous to an iterator. It's analagous to dereferencing an iterator. However, at least as of C++98, non-copyable elements in a container were not allowed IIRC, so it would have been pretty rare to have a C++ iterator that returned a non-copyable value when you dereferenced it. Also, it pretty much _is_ assumed that auto h = r.front; is cheap, and there are plenty of cases where calling front multiple times for the same range would incur additional overhead, because front is calculated rather than simply returning a value (e.g. this is what happens with map). So, it could be a definite performance hit in general to start insisting that r.front be called without the value being assigned somewhere. Part of the problem here is that in some cases, it's more efficient to call front multiple times, whereas in others it's more efficient to call it once. But since most ranges do not have their front or back return by ref (and many cannot), it's going to be more efficient to call front only once for most ranges. Also, consider that the way that foreach works, it _has_ to be able to copy front unless it's used with ref - and since most ranges do not have a front that returns by ref, most ranges will not compile with a ref foreach variable, and generic code would fall completly flat on its face if it tried to use foreach with a range and made the foreach variable ref, whereas that's exactly what would be required for a range of non-copyable elements. Even if it were allowed, a range of non-copyable elements would not play nicely with the same code that a normal range would work with, resulting in a lot more conditional compilation from stuff like function overloading and static ifs in order to make the code work for both. So, allowing ranges of non-copyable types would tend to complicate code considerably - either that or a lot of template constraints would just do something like hasCopyableFront!R, making it so that ranges of non-copyable elements still really didn't work. Yes, not allowing copyable elements for ranges is a problem. But allowing them would also be a big problem. What we should ultimately do about it, I don't know, but I think that it's pretty clear that the majority of code would be better off if non-copyable elements for ranges were not allowed. And it _is_ possible to work around the problem by doing as H.S. Teoh suggested and using ranges of pointers. - Jonathan M Davis
Re: Hosting vibe.d on OpenShift
On Thursday, 8 December 2016 at 14:03:35 UTC, aberba wrote: I would like to try vibe.d with mongoDB on OpenShit. I managed to do that on Heroku. Do I need a buildpack like vibe.d? Any help will be really appreciated. I've tried to create a vibe cartridge but cannot because of memory limitations. The easiest way: You should build locally and deploy the executable
Re: Range of uncopyable elements
On Thursday, 8 December 2016 at 17:29:42 UTC, H. S. Teoh wrote: The problem is that most range algorithms won't work if `auto h = r.front;` doesn't compile. Random chunks of std.algorithm won't work for such a range. One may argue, of course, that std.algorithm ought to be fixed... but the root of the problem really is a conceptual one. The definition of a range was made as an extension of a C++ iterator, which is basically a wrapped pointer. So `auto h = r.front;` is assumed to be a cheap copy of a *reference* to the underlying data, rather than copying the data itself. This is why most of std.algorithm is written the way it is, and why isInputRange is defined the way it is. A range of non-copyable elements in this sense is a poor fit for the range concept; a better fit would be a range of references to an underlying container of non-copyable elements. Hence my suggestion of using pointers. (In any case, conflating a range with a container is usually a red flag that there's a conceptual mismatch somewhere. Unfortunately built-in arrays aren't helping by hiding the fact that the container is actually GC-managed memory, which isn't directly visible to the user, thus perpetuating the misconception that range == container.) T Well it's exactly like that for C++ as well. std::copy(Iter, ...) won't compile if the values aren't copyable. There's no constraints in C++ either so you get some cryptic error message. The entire std library is like that. Assuming that is wrong though, as you aren't copying an iterator or range you are copying the actual value. What you are confusing "auto h = r.front;" for is this: "auto rcopy = r;". The D code "auto h = r.front" is not a cheap operation and the equivalent in C++ is actually this: "auto h = *iterator;" and one should not assume it is cheap, cause it isn't. Anyways your comparison with C++ is off.
Re: Templating Function Names
On 12/08/2016 10:21 AM, Bryce Kellogg wrote: > It should look like Foo always had a property named after their custom Component. opDispatch? https://dlang.org/spec/operatoroverloading.html#dispatch Ali
Templating Function Names
Say I've got a bunch of classes that inherit from a common
interface (in this case Component) and a class Foo that can
handle any subclass of Component. Like so:
interface Component { ... }
class A : Component { ... }
class B : Component { ... }
class C : Component { ... }
class Foo {
alias a = this.of!A;
alias b = this.of!B;
alias c = this.of!C;
void of(T : Component)(T t) { ... }
}
It's pretty trivial to access a specific component using regular
templates:
f.of!A = new A();
f.of!B = new B();
f.of!C = new C();
And I can alias the instantiations of these templates as seen
above for a cleaner interface:
f.a = new A();
f.b = new B();
f.c = new C();
However, suppose I have the following situation:
void main() {
Foo f = new Foo();
class D : Component { ... }
f.of!D = new D(); // works fine
f.d = new D();// fails to compile (for obvious reason)
}
Is there a way I can get a function of Foo named after D (like
f.d() or f.D()) without knowing before hand every single subclass
of Component and adding aliases manually?
For example, is there a way to template the name of the function
or an alias like:
void T(T : Component)(T t) { ... }
or
alias T = this.of!T;
Both of these just gave me functions named T.
The important thing is that it's transparent to the person
creating a new subclass of Component. It should look like Foo
always had a property named after their custom Component.
Is this possible?
Thanks!
Bryce
Re: Range of uncopyable elements
On Thu, Dec 08, 2016 at 05:22:25PM +, Jerry via Digitalmars-d-learn wrote: > On Thursday, 8 December 2016 at 16:48:07 UTC, H. S. Teoh wrote: > > On Thu, Dec 08, 2016 at 04:35:02PM +, Jerry via Digitalmars-d-learn > > wrote: > > > The problem is with how isInputRange is defined, requires that > > > front be copyable. > > > > > > auto h = r.front; // can get the front of the range > > > > > > https://github.com/dlang/phobos/blob/v2.072.1/std/range/primitives.d#L168 > > > > > > It doesn't take into consideration that front exists and that it's > > > a reference to a struct that can't be copied. There was a > > > discussion a while back to change it but it seems nothing came of > > > it. > > > > A possible workaround, which is somewhat ugly but should work, is to > > have the range return pointers to the elements instead of the > > elements themselves. For the most part, this should be mostly > > transparent because the . operator automatically dereferences. > > > > > > T > > It's not something that you should have to workaround, isInputRange is not > defined properly and should be fixed. You end up complicating your code for > no reason other than isInputRange is poorly defined. The problem is that most range algorithms won't work if `auto h = r.front;` doesn't compile. Random chunks of std.algorithm won't work for such a range. One may argue, of course, that std.algorithm ought to be fixed... but the root of the problem really is a conceptual one. The definition of a range was made as an extension of a C++ iterator, which is basically a wrapped pointer. So `auto h = r.front;` is assumed to be a cheap copy of a *reference* to the underlying data, rather than copying the data itself. This is why most of std.algorithm is written the way it is, and why isInputRange is defined the way it is. A range of non-copyable elements in this sense is a poor fit for the range concept; a better fit would be a range of references to an underlying container of non-copyable elements. Hence my suggestion of using pointers. (In any case, conflating a range with a container is usually a red flag that there's a conceptual mismatch somewhere. Unfortunately built-in arrays aren't helping by hiding the fact that the container is actually GC-managed memory, which isn't directly visible to the user, thus perpetuating the misconception that range == container.) T -- What did the alien say to Schubert? "Take me to your lieder."
Re: Range of uncopyable elements
On Thursday, 8 December 2016 at 16:48:07 UTC, H. S. Teoh wrote: On Thu, Dec 08, 2016 at 04:35:02PM +, Jerry via Digitalmars-d-learn wrote: The problem is with how isInputRange is defined, requires that front be copyable. auto h = r.front; // can get the front of the range https://github.com/dlang/phobos/blob/v2.072.1/std/range/primitives.d#L168 It doesn't take into consideration that front exists and that it's a reference to a struct that can't be copied. There was a discussion a while back to change it but it seems nothing came of it. A possible workaround, which is somewhat ugly but should work, is to have the range return pointers to the elements instead of the elements themselves. For the most part, this should be mostly transparent because the . operator automatically dereferences. T It's not something that you should have to workaround, isInputRange is not defined properly and should be fixed. You end up complicating your code for no reason other than isInputRange is poorly defined.
Re: @property
On Thursday, 8 December 2016 at 16:53:13 UTC, Satoshi wrote: is there any advantage of marking function as @property?? Not really. I think it just changes the meaning of typeof(thatfunc) but otherwise it does nothing. However, if you use it in a base class, you must also use it when overriding the function.
Re: Range of uncopyable elements
On Thu, Dec 08, 2016 at 04:35:02PM +, Jerry via Digitalmars-d-learn wrote: > The problem is with how isInputRange is defined, requires that front > be copyable. > > auto h = r.front; // can get the front of the range > > https://github.com/dlang/phobos/blob/v2.072.1/std/range/primitives.d#L168 > > It doesn't take into consideration that front exists and that it's a > reference to a struct that can't be copied. There was a discussion a > while back to change it but it seems nothing came of it. A possible workaround, which is somewhat ugly but should work, is to have the range return pointers to the elements instead of the elements themselves. For the most part, this should be mostly transparent because the . operator automatically dereferences. T -- Designer clothes: how to cover less by paying more.
@property
Hello,
is there any advantage of marking function as @property??
class Foo {
void objectValue(Object value) { }
Object objectValue() { }
}
auto foo = new Foo;
// This works fine without @property attribute
foo.objectValue = null;
auto bar = foo.objectValue;
Re: Range of uncopyable elements
The problem is with how isInputRange is defined, requires that front be copyable. auto h = r.front; // can get the front of the range https://github.com/dlang/phobos/blob/v2.072.1/std/range/primitives.d#L168 It doesn't take into consideration that front exists and that it's a reference to a struct that can't be copied. There was a discussion a while back to change it but it seems nothing came of it.
Range of uncopyable elements
Hi,
I am trying to create a range with uncopyable elements. My
thought process was the following:
1.I have created a struct :
struct S
{
int a;
@disable this(this);
}
2. I declared an array :
S[] arr = [S(1), S(2), S(3)];
expecting that arr will be a range like, for example, an int[].
I was surprised to see that isInputRange!arr is false.
So, is there any possibility to create a range with uncopyable
elements?
Re: [Semi-OT] I don't want to leave this language!
On Thursday, 8 December 2016 at 09:57:21 UTC, Guillaume Piolat wrote: On Wednesday, 7 December 2016 at 12:12:56 UTC, Ilya Yaroshenko wrote: R, Matlab, Python, Mathematica, Gauss, and Julia use C libs. --Ilya As a C lib, you have the possibility of not initializing the runtime, which leaves usable a part of phobos+druntime and it's only a matter of avoiding TLS/globals and global ctor/dtor. No need to rewrite druntime this way. https://www.auburnsounds.com/blog/2016-11-10_Running-D-without-its-runtime.html -betterC is cleaner (link errors) but give more work. Link requirement is problem too. A numeric library for the language list above will never be accepted if this library depends on huge non portable runtime like D has. --Ilya
Re: [Semi-OT] I don't want to leave this language!
On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote: what can be done, tho, is article (or series of articles) describing what exactly druntime is, how it is compared to libc and libc++, why it doesn't hurt at all, how to do "bare metal" with custom runtime, why GC is handy (and how to limit GC impact if that is necessary), and so on. that is something D Foundation should do, i believe. give the man a cigar!
Re: [Semi-OT] I don't want to leave this language!
On Thursday, 8 December 2016 at 12:10:55 UTC, Andrey wrote: On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote: what can be done, tho, is article (or series of articles) describing what exactly druntime is, how it is compared to libc and libc++, why it doesn't hurt at all, how to do "bare metal" with custom runtime, why GC is handy (and how to limit GC impact if that is necessary), and so on. that is something D Foundation should do, i believe. +1 +1
Re: drepl fails because of missing lib linenoise
On Thursday, 8 December 2016 at 13:03:10 UTC, Edwin van Leeuwen wrote: On Thursday, 8 December 2016 at 12:31:01 UTC, Nordlöw wrote: drepl fails to build as https://github.com/drepl/drepl/issues/58 Any ideas why? Looks like you don't have liblinenoise installed. ... and for the record I just recompiled it with the lastest, greatest DMD and it still worked :) Btw if you also feel that DUB should have a smoother integration with C code -> https://github.com/dlang/dub/issues/852 Some basic notes on how to install on linux/macosx can be found here: https://github.com/BlackEdder/todod#linenoise For ArchLinux there's also a convenient packages: https://aur.archlinux.org/packages/linenoise
Hosting vibe.d on OpenShift
I would like to try vibe.d with mongoDB on OpenShit. I managed to do that on Heroku. Do I need a buildpack like vibe.d? Any help will be really appreciated.
Re: drepl fails because of missing lib linenoise
On Thursday, 8 December 2016 at 12:31:01 UTC, Nordlöw wrote: drepl fails to build as https://github.com/drepl/drepl/issues/58 Any ideas why? Looks like you don't have liblinenoise installed. Some basic notes on how to install on linux/macosx can be found here: https://github.com/BlackEdder/todod#linenoise
drepl fails because of missing lib linenoise
drepl fails to build as https://github.com/drepl/drepl/issues/58 Any ideas why?
Re: [Semi-OT] I don't want to leave this language!
On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote: what can be done, tho, is article (or series of articles) describing what exactly druntime is, how it is compared to libc and libc++, why it doesn't hurt at all, how to do "bare metal" with custom runtime, why GC is handy (and how to limit GC impact if that is necessary), and so on. that is something D Foundation should do, i believe. +1
Re: [Semi-OT] I don't want to leave this language!
On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote: [...] what can be done, tho, is article (or series of articles) describing what exactly druntime is, how it is compared to libc and libc++, why it doesn't hurt at all, how to do "bare metal" with custom runtime, why GC is handy (and how to limit GC impact if that is necessary), and so on. that is something D Foundation should do, i believe. Amen. Features should never become a religion (else you'll get Java :).
Re: [Semi-OT] I don't want to leave this language!
On Thursday, 8 December 2016 at 11:32:56 UTC, Paolo Invernizzi wrote: On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote: what can be done, tho, is article (or series of articles) describing what exactly druntime is, how it is compared to libc and libc++, why it doesn't hurt at all, how to do "bare metal" with custom runtime, why GC is handy (and how to limit GC impact if that is necessary), and so on. that is something D Foundation should do, i believe. +1 /Paolo +1 This is what technical domination is about :) not apologize for everything
Re: [Semi-OT] I don't want to leave this language!
On Thursday, 8 December 2016 at 11:09:12 UTC, ketmar wrote: what can be done, tho, is article (or series of articles) describing what exactly druntime is, how it is compared to libc and libc++, why it doesn't hurt at all, how to do "bare metal" with custom runtime, why GC is handy (and how to limit GC impact if that is necessary), and so on. that is something D Foundation should do, i believe. +1 /Paolo
Re: [Semi-OT] I don't want to leave this language!
On Thursday, 8 December 2016 at 10:49:40 UTC, Chris wrote: The "hard way" (no runtime/Phobos/GC) should not be the default and I hope that nobody is seriously suggesting this. It should be available in case anyone needs it. I dare doubt, however, that C/C++ programmers will take to D like ducks take to water because of it. especially considering that nobody in c++ land really talking about "we should drop c++ runtime". yes, in case somebody doesn't know, c++ also has runtime. and c too, by the way. some people in c++ land avoiding using c++ features that require runtime (stl, rtti, etc.), but majority of programmers are ok with runtime. the very same is true for D. saying that "D will be more attractive to C++ programmers if we will remove runtime" is... i can't even find a word to describe it. what can be done, tho, is article (or series of articles) describing what exactly druntime is, how it is compared to libc and libc++, why it doesn't hurt at all, how to do "bare metal" with custom runtime, why GC is handy (and how to limit GC impact if that is necessary), and so on. that is something D Foundation should do, i believe.
Re: [Semi-OT] I don't want to leave this language!
On Wednesday, 7 December 2016 at 16:43:54 UTC, bachmeier wrote:
On Wednesday, 7 December 2016 at 16:15:32 UTC, Chris wrote:
I don't understand this discussion at all. Why not have both?
I don't need bare metal stuff at the moment but I might one
day, and I perfectly understand that people may need it. At
the same time, there are people who are happy with
runtime/Phobos/GC. In my opinion it's not a question of
"either or" but of "both and".
I can only speak for myself, but the concern is that we'll move
in the direction of Rust, where you're supposed to read a
dissertation on memory management before writing "Hello,
World". The current state of affairs should be the default.
Those with more advanced uses in mind should be able to do what
they need, but it should be done without pushing away non-hard
core developers.
The "hard way" (no runtime/Phobos/GC) should not be the default
and I hope that nobody is seriously suggesting this. It should be
available in case anyone needs it. I dare doubt, however, that
C/C++ programmers will take to D like ducks take to water because
of it. It's been said time and time again that D's mission is no
longer to convert C/C++ programmers ("a better C++") but to
provide a good tool for programming. I think D still suffers from
the slogan that it's "a better C++". Bad marketing, because
you'll always be compared to C++. Imagine you date a woman and
tell her "I'm a better your ex-boyfriend/ex-husband".
Re: [Semi-OT] I don't want to leave this language!
On Wednesday, 7 December 2016 at 12:12:56 UTC, Ilya Yaroshenko wrote: R, Matlab, Python, Mathematica, Gauss, and Julia use C libs. --Ilya As a C lib, you have the possibility of not initializing the runtime, which leaves usable a part of phobos+druntime and it's only a matter of avoiding TLS/globals and global ctor/dtor. No need to rewrite druntime this way. https://www.auburnsounds.com/blog/2016-11-10_Running-D-without-its-runtime.html -betterC is cleaner (link errors) but give more work.
Re: Multiple producer - multiple consumer with std.concurrency?
Hi Ali, Thanks for the input, will read about this. About the slowness. I think it also depends on the situation. Sure, every message from all producers/consumers has to go through one MessageBox, but, that is a small critical section, if the work for producing and consuming takes long enough, the contention is not so important (for small desktop sized problems). I would still be able to stress all my cores :) About a single dispatcher: Why not. But the dispatcher would have to keep track (manually) of tasks to do and unoccupied workers. While this is for sure possible, simply sharing the MessageBox would be a great solutions I think. Looking into std.concurrency, it seems that it should be possible to provide another spawn function, that takes an additional MessageBox parameter that is then used for creating the Tid (given that get and put on MessageBox are threadsafe). What do you think? Christian On 08/12/2016 00:06, Ali Çehreli wrote: > The simplest idea is to have a single dispatcher thread that distributes > to consumers. However, both that and other shared mailbox designs are > inherently slow due to contention on this single mailbox. > > Sean Parent's "Better Code: Concurrency" presentation does talk about > that topic and tells how "task stealing" is a solution. > > There are other concurrency models out there like the Disruptor: > > https://lmax-exchange.github.io/disruptor/ > > It's a very interesting read but I don't know how it can be done with > Phobos. It would be awesome if D had that solution. > > Ali >
