Re: My two cents on what D needs to be more successful...
On Sunday, 21 May 2017 at 05:52:11 UTC, Ecstatic Coder wrote: Since a few months, I'm using D for all my command-line tools. For that use case, the language and its standard libraries are really perfect, making it the best scripting language I know, completely exploding JavaScript, Python, Ruby, etc. Glad to see you're happy with the language. Let's break down each of these suggestions. - std.database (connect/use MySQL/MongoDB/etc databases) I while I don't agree that the connection facilities themselves should be included (shipping C libraries has been a huge pain), I agree that some form of either ORM or standardized format of DB API should be in Phobos. Like SQLAlchemy, let's leave the connection to other libraries. - std.ui (draw 2D user interfaces) - std.input (get mouse/touchscreen/etc events) I would like to point out that users of the languages you mentioned almost never use the builtin versions of these types of libraries (and hasn't maintenance of Swing been a huge time burden on the Java devs, I remember reading this somewhere). Python users use either Qt or GTK, not Tk. * a soft-realtime garbage collector (like in Nim), which can progressively recycle the memory of a thread without blocking the whole application. This is possible, just needs a champion. - std.web (serve web data/files/pages) There's a philosophical boundary here. There are many ways to make a web server, and there's no one right answer for every web problem. Standardizing one type of server seems improper. Plus the below problem applies. - std.audio (load/play/process/record sounds/musics) - std.image (load/show/process/record images) - std.video (load/show/process/record videos) - std.graphic (draw 2D/3D graphics) * a dedicated IDE, allowing to effortlessly open/compile/execute/debug a single ".d" file as well as an entire project. The problem with all of these suggestions is that the maintenance burden is so enormous that it would take a medium sized team of paid professionals. Let's take std.graphic as an example. To give a sense of the scale of the job, getting a cross platform graphics API is a task so large that it takes some of the largest corporations in the world (MS, Apple, etc.) to come together to make it happen. It's not so much a code problem as it is an organization problem. The result is OpenGL, an API that no one likes very much and literally no one understands. So we would have to support OpenGL, because this has to work on Linux and OpenBSD. Next, you probably want to support DX 11, because that's what pretty much 99% of video games use, so that's another monolithic API that you have to incorporate into your agnostic API. Now how about DX 12? Because it's supposedly way faster, and if you're going after game devs, they tend to worry about speed. How about Vulkan? How about OpenGL 3 as well as 4 because Apple abjectly refuses to upgrade for no apparent reason. Speaking of Apple, how about Metal? Oh, and we want to support mobile so don't forget about OpenGL ES, plus all its different versions that have to be supported for different phone platforms. I cannot stress enough how difficult a task a cross platform 3D graphics library is. It's the same thing for audio and video too. Just look at all of the different encodings and features ffmpeg supports. No, best to leave graphics/audio/video to C libraries that already exist. Even if it's painful, it's more painful to copy their work. But with some efforts... D is 100% community run and none of us get paid. Bringing something into Phobos doesn't mean that it gets more work (it can actually mean the opposite). It's gotten to the point where each module in Phobos ostensively has one or two owners who's responsible for its condition in order to spread the load. For the web servers, vibe.d is already there. For desktop applications, there is gtkd and dlangui. In order to make the existing libraries standard would require 1. An API freeze. Not something that anyone in the community is willing to concede, not even Vibed. 2. Constant, time consuming review of every change, as is required by any standard library for QA. This is why ndslice is no longer in Phobos. 3. Tons of hours of work fixing the bugs that are present in the existing solutions before even considering merging them into Phobos. I agree that at the moment, all these developments can be possible through several third-party libraries. And that's the way it's going to have to stay TBH.
Re: Off-topic discussions (WAS: OT: Re: My two cents on what D needs to be more successful...)
On Monday, 22 May 2017 at 20:49:22 UTC, Ecstatic Coder wrote: Then, with all due respect, please remove these posts... IMHO, they are so incredibly off-topic that I don't see why they should remain here to pollute the pages of a D language forum. The forum is a web frontend for a newsgroup server, which also has a mailing list interface. I think the NG server does support message deletion, and that may cause it to disappear from the web frontend, but it will still be in NG readers and inboxes.
Re: DMD VS2017 Support
On Monday, 22 May 2017 at 21:08:02 UTC, Jolly James wrote: I mean, if for any circumstance, e.g. like the VS2017 thing (which did not suddenly appear from one day to another anyway), the whole software cannot be used without larger fiddling (in this case: setting up NSIS + plugins), it seems quite strange to not simply update the installer, which would be a work for a few minutes - and after that everybody would be happy. But to be honest, I don't think that this is a problem of D. More or less, this is something that appears everywhere in the world of open-source. Here it annoys and chases away users, in the corporate sector you could not do so, as this would cause the company's ruin. D's implementation (which is a part of the project as a whole) is cross-platform, we support several platforms other than Windows. Additionally, Visual Studio integration is an optional feature of the Windows version, and of course VS2017 is just one supported version of VS. The scope of the problem may seem larger to you because you are affected by it personally, however at any point in time there may be any number of fixes queued for release of similar relative importance. Making an urgent release for every such occurrence would be impractical, if not impossible given the necessary work involved with making each new release. The difference between open-source and proprietary projects here is mainly that open-source projects do their development in the open. Generally, users usually are not made aware of the status of any particular fix or issue for proprietary projects up until the point that they appear in the changelog of a published release. Heck, most proprietary projects don't even have public bug trackers, or even forums for that matter.
Re: DMD VS2017 Support
On Monday, 22 May 2017 at 07:28:23 UTC, Vladimir Panteleev wrote: On Sunday, 21 May 2017 at 22:47:44 UTC, Jolly James wrote: On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote: Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227 I really like this philosophy: "It does not work, a fix is available, but it won't be rolled out (for now). Who cares about those who cannot use the broken software?" Please don't antagonize volunteer contributors who are actually creating and improving things. We have a release process for a reason, we can't ship every single change immediately. If you require a solution urgently, use a workaround or build it from source yourself. My message was neither addressed directly to anybody of the volunteer contributors (I have a huge respect of them and their great work), nor to anyone at the D Foundation directly. I just wanted to critize the whole release cycle stuff itself. I mean, if for any circumstance, e.g. like the VS2017 thing (which did not suddenly appear from one day to another anyway), the whole software cannot be used without larger fiddling (in this case: setting up NSIS + plugins), it seems quite strange to not simply update the installer, which would be a work for a few minutes - and after that everybody would be happy. But to be honest, I don't think that this is a problem of D. More or less, this is something that appears everywhere in the world of open-source. Here it annoys and chases away users, in the corporate sector you could not do so, as this would cause the company's ruin.
Re: Off-topic discussions (WAS: OT: Re: My two cents on what D needs to be more successful...)
On Monday, 22 May 2017 at 14:09:10 UTC, Andrei Alexandrescu wrote: I tried to send the message below via email. Couldn't reach all participants so I'll post it here: Hi there, thanks for your participation in the D forums. As this thread has stepped outside the charter of the forum, could you kindly please take it either to private email or to a place where such discussions are carried. (We do allow the occasional "near" off-topic posts related to general computing technology under the "OT" label.) We've sent a similar message to the other participants. Thanks! -- Andrei Then, with all due respect, please remove these posts... IMHO, they are so incredibly off-topic that I don't see why they should remain here to pollute the pages of a D language forum.
Destructor attribute inheritance, yea or nay?
I'd like to hear what you guys think about this issue:
https://issues.dlang.org/show_bug.cgi?id=15246
Marco argues that because "it currently doesn't work that way"
(i.e. destructors are not inherited), the bug is invalid.
However, what this means in practice is:
- destroy()/rt_finalize() can never be anything but @system
- destructors of derived classes, and even destructors of
aggregates (structs) can violate attributes, and the compiler
does nothing to prevent that
Considering that the core runtime component - the GC - is the one
that usually handles finalization, it follows that *GC collection
can never be @safe*. And since collection only happens during
allocation, it follows that allocation cannot be @safe either.
Nor can they be @trusted, because destructors are effectively not
restricted in any way. IOW, the "doesn't work that way" claim
effectively hammers shut the coffin of memory safety as far as
dynamic allocation is concerned, and that means the whole runtime
and anything that depends on it.
I am of the opinion that the destructors should not be capable of
violating the aggregated destruction attributes. This would allow
the destroy() function to safely infer the correct attribute set
for finalization, and propagate it to the calling code.
I.e. we could implement destroy() for classes as follows:
void destroy(T)(T obj) if (is(T == class))
{
(cast(_finalizeType!T)&rt_finalize)(cast(void*)obj);
}
void destroy(T)(T obj) if (is(T == interface))
{
destroy(cast(Object)obj);
}
extern(C) void rt_finalize(void* p, bool det = true);
extern(C)
template _finalizeType(T)
{
static if (is(T == Object))
{
alias _finalizeType = typeof(&rt_finalize);
}
else
{
alias _finalizeType = typeof((void* p, bool det = true)
{
// generate a body that calls all the destructors in
the chain,
// compiler should infer the intersection of
attributes
// _Seq is an equivalent of std.meta.AliasSeq
// _Bases is an equivalent of
std.traits.BaseClassesTuple
foreach (B; _Seq!(T, _Bases!T)) {
// __dtor, i.e. B.~this
static if (__traits(hasMember, B, "__dtor"))
() { B obj; obj.__dtor; } ();
// __xdtor, i.e. dtors for all RAII members
static if (__traits(hasMember, B, "__xdtor"))
() { B obj; obj.__xdtor; } ();
}
});
}
}
This would keep the inferred attributes for code that actually
calls destroy(). However, currently we cannot do that, because
the language does not enforce attribute propagation in
destructors, and at runtime, destroy() could be called via base
class reference, while derived class violates the attributes:
class Base {
~this() @safe @nogc {}
}
class Derived : Base {
~this() {}
}
Base b = new Derived;
destroy(b); // infer @safe @nogc, while in reality this call is
neither @safe nor @nogc, it is @system
Any thoughts?
[OT] Don't feed the troll
On 22.05.2017 16:31, bachmeier wrote: On Monday, 22 May 2017 at 12:04:39 UTC, rikki cattermole wrote: Once you start banning + deleting non-spam its a real slippery slope. This is an argument I've never understood. First, _this not a significant problem around here_. The forum self-moderates reasonably well. That said: Ignoring trolls is both effective and convenient. Why would anyone be affected by what such a person posts in the first place? Their thoughts have no relevance as they lack maturity. Therefore, all they do is waste a tiny little bit of time now and then. Moderation also wastes time, and it is not actually easy to do well. Seems to be dominant here. It's part of the reason why I'm here. Attacking someone personally for supposedly being hostile is a great way to derail a technical discussion. It's a popular trolling strategy. The way it has worked here so far is that if you are not able to give someone the benefit of the doubt, you simply ignore them. Not banning and deleting is a slippery slope. If you use a newsgroup reader, you can block people's posts at will. Why does there need to be a central authority? It's just overhead. As soon as such an authority is established, people will try to move the line around and argue about definitions of fuzzy terms in order to get the central authority to ban precisely the set of posts they do not like. This is not a productive use of the forums. Also, aggressive moderation does not necessarily solve a problem. People can simply get more sensitive (e.g. they will get offended about trivialities such as exclamation marks and other unreliable cues) and then newcomers, whose first language is not necessarily English, need to learn arbitrary rules in order to be treated respectfully.
Re: Off-topic discussions (WAS: OT: Re: My two cents on what D needs to be more successful...)
On Monday, 22 May 2017 at 14:09:10 UTC, Andrei Alexandrescu wrote: I tried to send the message below via email. Couldn't reach all participants so I'll post it here: Sorry about the post just now, I did not see your message beforehand.
Re: OT: Re: My two cents on what D needs to be more successful...
On Monday, 22 May 2017 at 13:59:16 UTC, handG wrote: On Monday, 22 May 2017 at 12:29:13 UTC, Moritz Maxeiner wrote: On Monday, 22 May 2017 at 11:29:33 UTC, handG wrote: [...] Germany - no no, the muslim (so called refugees) thugs, rapist and murders arrived here now. Bad example!! Thanks america. This is totally off topic, which is why I split off the thread. The percentage of such people with regards to all refugees is not worrisome when compared to the percentage of such people with regards to the people with German citizenship; see IMK Bericht 2016 [1]. Also, considering the excellent solve rate of most (reported) crimes here, even if it were worrisome in the short term, there would be no need to be concerned with regards to long term effects. Additionally, blaming an entire people for the actions of their government is ludicrous, especially since our own government happily assists with the USA government's drone murders (i.e. war crimes). [1] https://www.bka.de/DE/AktuelleInformationen/StatistikenLagebilder/PolizeilicheKriminalstatistik/PKS2016/pks2016_node.html 1.) we have no sovereignty (until 2099) over the us bases and HAVE to pay for them - Those are reasonable consequences for an unconditional surrender and it's not as if we couldn't afford it. Not to mention that these bases have people living in them that often go out and spend their money in the surrounding communities, which in turn generates both income for the (native) people living there, as well as taxes that are used for e.g. keeping the infrastructure in those communities maintained. that makes us a still occupied (by so called friends) country 1.) That is not what occupation means. If you want to call it something, "observation with preemptive capabilities" would be appropriate. 2.) There are no friends in politics, only ever shifting allegiances. 2.) http://www.refcrime.info/de/verbrechen/karte/ -- https://www.unzensuriert.at/einzelfall 1.) Neither of those websites cite reputable sources (online media outlets are not a reputable source for crime reports, since they necessarily have to work on a "publish first, check only if harsh backlash occurs" schedule to remain competitive) for their data and are thus irrelevant as aggregators. 2.) With around 600 crimes (yes, that is 6 million) reported in the year 2016 alone in Germany, the around 27 supposed crimes (and this number is not per year, but overall total) on the first of those two websites are below 0.5 percent: Statistical noise, aka not relevant. 3.) The 2nd of those two websites is specifically about single cases and is such utterly irrelevant for a statistical analysis (which is the only kind that makes any sense on this scale).
Re: Value closures (no GC allocation)
On Monday, 22 May 2017 at 14:06:54 UTC, Vittorio Romeo wrote: On Sunday, 21 May 2017 at 20:25:14 UTC, Adam D. Ruppe wrote: Blah. Well, let's go ahead and formally propose the C++ syntax, our library solutions are all fat. Are you going to create a DIP for this? I would be happy to contribute, but I don't feel confident enough to create a DIP on my own (I just started learning the language) :) The three of us could do it together through the magics of github.
Re: The dlang-tour translations need you
On Monday, 22 May 2017 at 14:52:43 UTC, Seb wrote: Russian --- - Welcome & Basic chapter completely translated - https://tour.dlang.org/tour/ru/welcome/welcome-to-d - Huge thanks to @El-Lin, @dmi7ry, @9il, @Dicebot, @DmitryOlshansky If nobody's working on that already, I'll take the "Gems" chapter. And go by chapter unless someone else also participates.
The dlang-tour translations need you
Hi all, this is just a quick update from the Dlang Tour maintainers (there will be a bigger one next month when we finally get the menu and navigation UX issue addressed). For now, I want to highlight another fact: the Dlang Tour is most likely the first "in-depth" point of contact for newcomers (if you think this isn't true due to missing visibility or why it shouldn't be, please let me know). In any case, this means that Andrei's famous first five minutes will be spent to a great extent on this tour. This means that whenever you have time, you can help the D community just by going through the pages and clicking the "Edit" button on the right and/or opening issues at the regarding repo (https://github.com/dlang-tour/english) For more general ideas (UI, features, ...), you can ping us at the base repo: https://github.com/stonemaster/dlang-tour/issues Translations While in some countries, English is taught for many years in school, in others it's a barrier for people who want to learn D. I think Ali and his Turkish D-Community have proven that having excellent documentation in the native language can make a huge difference. A couple of months ago we modified the DLang Tour, s.t. every language is a submodule which can be separately maintained. They can be found here: http://tour.dlang.org/tour/en/welcome/languages https://github.com/dlang-tour Most of the translation "projects" have unfortunately stopped, so any help to revive them is very welcome. The entire tour is written in Markdown, so it's even possible to edit a language purely with the GH UI and without knowing anything about git or programming. However, if you do want to run it locally, that's rather easy as well, e.g.: dub fetch dlang-tour git clone https://github.com/dlang-tour/english cd english dub run dlang-tour -- --lang-dir . I am just going to highlight the three best translations, but obviously much more people have helped to get the Dlang Tour to the stage where it's now and the virtual thanks goes to all of them. Ukrainian - - Completely translated - https://tour.dlang.org/tour/uk/welcome/welcome-to-d - Huge thanks to @eresid (Eugene) and @ikod Japanese - @kotet is doing a lot of hard work, so even sole reviewing would help - https://github.com/dlang-tour/japanese/pulls - Huge thanks to @kotet, @majiang, @simdnyan, @alphaKAI Russian --- - Welcome & Basic chapter completely translated - https://tour.dlang.org/tour/ru/welcome/welcome-to-d - Huge thanks to @El-Lin, @dmi7ry, @9il, @Dicebot, @DmitryOlshansky
Re: Non-x86 targets for DMD
On Monday, 22 May 2017 at 01:05:04 UTC, solidstate1991 wrote: On Wednesday, 17 May 2017 at 22:16:35 UTC, Kagamin wrote: Can't you run it in qemu? Probably I could, might even work parallel with other stuff, especially stuff that are mainly lexical (register naming, etc). So far I studied the ARM assembly language, and it seems less scary than the x86 one, also the conditional execution might be useful with the ? : operators (if thumb isn't used). Conditional execution is not in the later models of ARM, I believe. Also does not really provide advantages over conditional jumps, except in rare circumstances.
Re: Weak Eco System?
On Monday, 22 May 2017 at 12:04:39 UTC, rikki cattermole wrote: Once you start banning + deleting non-spam its a real slippery slope. This is an argument I've never understood. Seems to be dominant here. Not banning and deleting is a slippery slope.
Re: Idea: Reverse Type Inference
On Monday, 22 May 2017 at 13:20:41 UTC, Stefan Koch wrote: And how long does that code take to compile ? +1 My immediate thought was one of horror - Scala's compilation times are a sufficient reason to avoid the language. I also think it would make D code harder to read. Not a problem in some cases, but in others it would add a lot of complexity.
Re: Idea: Reverse Type Inference
On Monday, 22 May 2017 at 13:20:41 UTC, Stefan Koch wrote: type inference is not magic, it's a search for a pattern over the syntax (sub)tree. Hence it can have quadratic time/memory complexity. Well, the type system of Scala is turing complete, hence it can take arbitrarily long: https://michid.wordpress.com/2010/01/29/scala-type-level-encoding-of-the-ski-calculus/
Off-topic discussions (WAS: OT: Re: My two cents on what D needs to be more successful...)
I tried to send the message below via email. Couldn't reach all participants so I'll post it here: Hi there, thanks for your participation in the D forums. As this thread has stepped outside the charter of the forum, could you kindly please take it either to private email or to a place where such discussions are carried. (We do allow the occasional "near" off-topic posts related to general computing technology under the "OT" label.) We've sent a similar message to the other participants. Thanks! -- Andrei
Re: DIP 1008 Preliminary Review Round 1
On Saturday, 20 May 2017 at 09:35:34 UTC, Stanislav Blinov wrote: On Saturday, 20 May 2017 at 02:25:45 UTC, Walter Bright wrote: void foo(scope string s); string s = callCAPIAndAllocateString(); foo(s ~ "abc"); What will happen? The compiler will generate different code? Won't compile? The former means invisible performance gap. The latter means an unpleasant surprise. Neither are good. Do we really need such special cases? It's no different from when s is GC allocated, s[] has to be copied for the concatenation. I'm not sure how Walter wants to lower this, but maybe it could use a region/stacked allocator. That could mean allocation in constant time when the region is already big enough, and deallocation would be constant time (except if freeing an unused region ahead of the current region).
Re: Value closures (no GC allocation)
On Sunday, 21 May 2017 at 20:25:14 UTC, Adam D. Ruppe wrote: Blah. Well, let's go ahead and formally propose the C++ syntax, our library solutions are all fat. Are you going to create a DIP for this? I would be happy to contribute, but I don't feel confident enough to create a DIP on my own (I just started learning the language) :)
Re: OT: Re: My two cents on what D needs to be more successful...
On Monday, 22 May 2017 at 12:29:13 UTC, Moritz Maxeiner wrote: On Monday, 22 May 2017 at 11:29:33 UTC, handG wrote: [...] Germany - no no, the muslim (so called refugees) thugs, rapist and murders arrived here now. Bad example!! Thanks america. This is totally off topic, which is why I split off the thread. The percentage of such people with regards to all refugees is not worrisome when compared to the percentage of such people with regards to the people with German citizenship; see IMK Bericht 2016 [1]. Also, considering the excellent solve rate of most (reported) crimes here, even if it were worrisome in the short term, there would be no need to be concerned with regards to long term effects. Additionally, blaming an entire people for the actions of their government is ludicrous, especially since our own government happily assists with the USA government's drone murders (i.e. war crimes). [1] https://www.bka.de/DE/AktuelleInformationen/StatistikenLagebilder/PolizeilicheKriminalstatistik/PKS2016/pks2016_node.html 1.) we have no sovereignty (until 2099) over the us bases and HAVE to pay for them - that makes us a still occupied (by so called friends) country 2.) http://www.refcrime.info/de/verbrechen/karte/ -- https://www.unzensuriert.at/einzelfall
Re: Idea: Reverse Type Inference
On 22.05.2017 12:13, Sebastiaan Koppe wrote:
I work with Scala professionally. I often feel its type inference for
generics/templates is better than D's; as long as it can find a type
_anywhere_ it will use that, no matter where it needs to pull it from.
Over the past weeks I have been noticing a specific case where it
happens. I call it reverse type inference, simply because it goes
against the normal evaluation order.
While it is only syntactic sugar,
(It's not.)
I think it would be nice to have in D
and I want to know what you guys think about it.
Some examples:
---
T convert(T)(string s) { ... }
auto dec = "1234".convert!int; // normal
int dec = "1234".convert;// T of convert is inferred due to type
declaration of dec
int square(int t) { ... }
auto a = "1234".convert.square; // since square accepts int, T of
convert is inferred to be int
---
p.s. I am not asking anyone to build it. I just want to have the idea
out there. And if time allows I might take a stab at implementing it.
I'm in favour. Note that this already happens in some circumstances,
e.g. the parameter type of the delegate is inferred here from the
expected type:
int delegate(int) dg = x=>x;
I suspect your enhancement might actually be easy to implement by
reusing the same mechanism in the compiler. (I.e. defer the template
instantiation if forward inference is incomplete, and then deduce the
remaining template arguments in "matchType".)
Another annoying case:
alias Fun(A,B) = B delegate(A);
B apply(A,B)(Fun!(A,B) f, A a){ return f(a); }
void main(){
apply(x=>x,2); // error
}
Re: Idea: Reverse Type Inference
On Monday, 22 May 2017 at 10:13:02 UTC, Sebastiaan Koppe wrote: I work with Scala professionally. I often feel its type inference for generics/templates is better than D's; as long as it can find a type _anywhere_ it will use that, no matter where it needs to pull it from. And how long does that code take to compile ? type inference is not magic, it's a search for a pattern over the syntax (sub)tree. Hence it can have quadratic time/memory complexity. Additionally it's harder to prove sound, i.e. there is more potential for undetected bugs, As well as making it more surprising when the inference fails.
OT: Re: My two cents on what D needs to be more successful...
On Monday, 22 May 2017 at 11:29:33 UTC, handG wrote: And I would have appreciated if Middle East guys stopped fighting and made their region nice and pleasant as Switzerland. Or if folks of Sudan and Uganda made their countries as prosperous and convenient to live in as Singapore and Germany. That would make life simpler and easier, for many newcomers. ;) Germany - no no, the muslim (so called refugees) thugs, rapist and murders arrived here now. Bad example!! Thanks america. This is totally off topic, which is why I split off the thread. The percentage of such people with regards to all refugees is not worrisome when compared to the percentage of such people with regards to the people with German citizenship; see IMK Bericht 2016 [1]. Also, considering the excellent solve rate of most (reported) crimes here, even if it were worrisome in the short term, there would be no need to be concerned with regards to long term effects. Additionally, blaming an entire people for the actions of their government is ludicrous, especially since our own government happily assists with the USA government's drone murders (i.e. war crimes). [1] https://www.bka.de/DE/AktuelleInformationen/StatistikenLagebilder/PolizeilicheKriminalstatistik/PKS2016/pks2016_node.html
Re: My two cents on what D needs to be more successful...
You are exactly the 146-th person to come here and say "std lib should be richer, and more docs and tutorials should be written". Unfortunately there is no automatic tool to convert these requests and suggestions into reality without using a lot of manpower. Don't worry I'm on that too. Simply at the moment, I'm currently writing a D tutorial for total beginners, based on the materials I made to teach programming to my children. As the theory and exercises are currently in French, I'll have translate them, which will take some time. And now I'm also maintaining several open source tools. As for everybody my free time is limited, but I'll do my best to test the future std libs, and help debug them.
Re: Weak Eco System?
I am sorry for your experience here. I am unaware of any contributions from him in the past. He appears to be pretty new here. We generally try not to respond to such posts telling people to quit it until it really is well past this point. It is expected that you ignore them. Once you start banning + deleting non-spam its a real slippery slope. Everybody has bad days and sometimes telling them to quit is not a good thing. Yes you came on a bit strong (this is fine) in the beginning but you raised excellent points of problems in our ecosystem. We recently moved dcd, dscanner and dfmt under a community run organization to help maintain these code bases. I am part of this organization, I will have a chat with HackerPilot (author) to see if there is anything we can do to aid packaging.
Re: DIP 1008 Preliminary Review Round 1
On Saturday, 20 May 2017 at 02:05:21 UTC, Jonathan M Davis wrote:
What we would probably need would be to change msg is a
function which generates a message so that derived classes can
override that rather than passing a message string.
Further to Moritz's reply showing the existing toString overload
taking a delegate. This delegate is not @nogc. Otherwise I was
thinking of doing something like this:
//FIXME: uniqueToString should return @nogc UniquePtr!(const
char[])
import std.conv;
alias uniqueToString = to!(const char[]);
class MessageEx(E, sinkArgs...) : E
{
this(A...)(A args)
{
super(args);
}
//FIXME: delegate not @nogc
/*@nogc*/ override void toString(scope void delegate(in
char[]) sink) const
{
foreach (a; sinkArgs)
sink(uniqueToString(a));
}
}
unittest
{
auto x = 7;
throw new MessageEx!(Exception, "x = ", x)(null);
}
The result of uniqueToString would free any memory allocated
after the call to sink.
Re: Weak Eco System?
On Monday, 22 May 2017 at 09:13:22 UTC, Mike B Johnson wrote: You should ask yourself that question, seriously. You started with your condescending ego based remark about how ! is yelling, when it is not! THIS IS YELLING Which, in fact, it is not because no sound was made. But because of your need to be treated as an authority you pretend to know something and then run around trying to enforce some imaginary law that you have self appointed yourself the judge, jury, and executioner. Then, because you think you are intelligent you try to pretend further to hold some imaginary high ground because you are born from the loins of Jesus himself and the rest of us heathens are too stupid to get it. My suggestion, go back to acting school. Whatever you are doing isn't working. Instead of actually commenting on the topic, you seem to keep focusing on a misunderstanding that everybody got over the a long time ago. All you do is make people feel unwelcome, that seems to be your goal. 1. Statement 2. Misunderstanding 3. Fixed << It ended here 4. << Your troll comment 5. << My response 6. << Several days later your troll comment again 7. This respond to Troll As stated before. Good compiler, weak eco system and some nasty individuals. It seems that you missed my point about "inviting" community. Any normal community will have a moderator that by now removed the clearly trolling attempts. I on the other hand have been using my time productive, trying to figure out where those issue come from as it was impossible to reproduce the same issue ( VSC ) on a system. But, its clear i do not need to wast my time any more feeding the trolls here. All: * Sure, it started because of my mistake and i take full responsibility and it was resolved but i will not deal with this attitude any more. And for the people that wonder why D is not more popular. No offense but when you have people like that lurking around and you do not use moderators to deal with them, its difficult for anybody to ever feel welcome. / Mike: * So, Mike you win, happy now. Probably not because i expect you will post some other nasty responds soon how its all my fault. You got your wish. Uninstalling D / VSC plugin / Jetbrain plugin and will moving to a more open and moderated community. / Peace out to the rest of the community and frankly... Good luck!
Re: My two cents on what D needs to be more successful...
And I would have appreciated if Middle East guys stopped fighting and made their region nice and pleasant as Switzerland. Or if folks of Sudan and Uganda made their countries as prosperous and convenient to live in as Singapore and Germany. That would make life simpler and easier, for many newcomers. ;) Germany - no no, the muslim (so called refugees) thugs, rapist and murders arrived here now. Bad example!! Thanks america.
Re: My two cents on what D needs to be more successful...
On Sunday, 21 May 2017 at 19:33:35 UTC, Ecstatic Coder wrote: I would have to evaluate several libraries from github, after having searches on forums whether some regular expression libraries are better or more successful, or better maintained than other, etc. No need to trawl github, just go to code.dlang.org and you'll quickly find what libs are available and which ones are actively maintained. So for newcomers like me, they make a HUGE difference, as they make my life simpler and easier. I would have appreciated to have a default GUI library, even if it's not perfect, and even if some better alternative could exist on github. And I would have appreciated if Middle East guys stopped fighting and made their region nice and pleasant as Switzerland. Or if folks of Sudan and Uganda made their countries as prosperous and convenient to live in as Singapore and Germany. That would make life simpler and easier, for many newcomers. ;) You are exactly the 146-th person to come here and say "std lib should be richer, and more docs and tutorials should be written". Unfortunately there is no automatic tool to convert these requests and suggestions into reality without using a lot of manpower.
Re: Idea: Reverse Type Inference
On Monday, 22 May 2017 at 10:13:02 UTC, Sebastiaan Koppe wrote:
I work with Scala professionally. I often feel its type
inference for generics/templates is better than D's; as long as
it can find a type _anywhere_ it will use that, no matter where
it needs to pull it from.
Over the past weeks I have been noticing a specific case where
it happens. I call it reverse type inference, simply because it
goes against the normal evaluation order.
While it is only syntactic sugar, I think it would be nice to
have in D and I want to know what you guys think about it.
Some examples:
---
T convert(T)(string s) { ... }
auto dec = "1234".convert!int; // normal
int dec = "1234".convert;// T of convert is inferred
due to type declaration of dec
int square(int t) { ... }
auto a = "1234".convert.square; // since square accepts int, T
of convert is inferred to be int
---
p.s. I am not asking anyone to build it. I just want to have
the idea out there. And if time allows I might take a stab at
implementing it.
AFAICT this should be possible purely with changes to the
compiler frontend (no language changes), yes?
Regardless, this would be nice to have, because imho this (from
your examples):
---
int dec = "1234".convert;
---
is easier to review than this:
---
auto dec = "1234".convert!int;
and I'm all for making code more readable. I must object against
usage of this though:
---
auto a = "1234".convert.square;
---
No way for a reviewer to easily guess the type of a without
inspecting all functions.
Idea: Reverse Type Inference
I work with Scala professionally. I often feel its type inference
for generics/templates is better than D's; as long as it can find
a type _anywhere_ it will use that, no matter where it needs to
pull it from.
Over the past weeks I have been noticing a specific case where it
happens. I call it reverse type inference, simply because it goes
against the normal evaluation order.
While it is only syntactic sugar, I think it would be nice to
have in D and I want to know what you guys think about it.
Some examples:
---
T convert(T)(string s) { ... }
auto dec = "1234".convert!int; // normal
int dec = "1234".convert;// T of convert is inferred due
to type declaration of dec
int square(int t) { ... }
auto a = "1234".convert.square; // since square accepts int, T
of convert is inferred to be int
---
p.s. I am not asking anyone to build it. I just want to have the
idea out there. And if time allows I might take a stab at
implementing it.
Re: Weak Eco System?
On Wednesday, 17 May 2017 at 08:19:43 UTC, Benro wrote: On Tuesday, 16 May 2017 at 23:17:10 UTC, Mike B Johnson wrote: Grow up! ! is not yelling. It makes no sound, has no meaning, and only exists to insert in to tight anuses that have no life. Thank you for your helpful comment. I wonder if the inability for D community to grow is not more related to the fairly noticeable arrogant attitude of its members. You should ask yourself that question, seriously. You started with your condescending ego based remark about how ! is yelling, when it is not! THIS IS YELLING Which, in fact, it is not because no sound was made. But because of your need to be treated as an authority you pretend to know something and then run around trying to enforce some imaginary law that you have self appointed yourself the judge, jury, and executioner. Then, because you think you are intelligent you try to pretend further to hold some imaginary high ground because you are born from the loins of Jesus himself and the rest of us heathens are too stupid to get it. My suggestion, go back to acting school. Whatever you are doing isn't working.
Re: Weak Eco System?
On Thursday, 18 May 2017 at 05:43:48 UTC, Manu wrote: On 17 May 2017 at 00:51, Benro via Digitalmars-d < digitalmars-d@puremagic.com> wrote: [...] 4 Hours work. Discouraged and gave up after this. Visual Studio proper is the only IDE that 'just works' well, VisualD is very good. MonoDevelop also has good 'just works' support last I checked, but debugging is much better in Visual Studio. We could use a more precise statement than "just works". Here is someone who likes IntelliJ IDEA's Rust support [0]. What I can see: * Show documentation in tooltip * Inline renaming of local variable (What about project-wide?) * Completion (with semantics, I assume) * Find all uses (of a local variable? What about project-wide?) * One-click dependency resolution (I guess) * Folding What I do not see (might or might not be available): * Advanced refactoring, like "extract function" or "converted lambda to named function" * Clicking on build errors/warnings and showing them inline * Displaying unit test status * Integrated debugger (which should probably have various sub-items...) * Integrated profiling * GUI builder * Color picker [0] https://twitter.com/kot_2010/status/865861074360426496
Re: DMD VS2017 Support
On Sunday, 21 May 2017 at 22:47:44 UTC, Jolly James wrote: On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote: Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227 I really like this philosophy: "It does not work, a fix is available, but it won't be rolled out (for now). Who cares about those who cannot use the broken software?" Please don't antagonize volunteer contributors who are actually creating and improving things. We have a release process for a reason, we can't ship every single change immediately. If you require a solution urgently, use a workaround or build it from source yourself.
