Re: Copy Constructor DIP
On Tuesday, 17 July 2018 at 00:04:12 UTC, Andrei Alexandrescu wrote: Then "negative" :o). In brief @implicit follows the same implementation as @safe and @nogc/ Why? This is a breaking change. Why not go with an approach that does not cause any breaking changes, which is just as easy to do? It also doesn't required any special casing in the parser. This is how @selector is implemented. -- /Jacob Carlborg
Re: Anyone can contact Dmitry Olshansky?
On Monday, 16 July 2018 at 16:20:24 UTC, Mr.Bingo wrote: On Tuesday, 3 July 2018 at 07:31:46 UTC, Nick Sabalausky (Abscissa) wrote: On 07/01/2018 05:34 AM, ag0aep6g wrote: On 07/01/2018 08:00 AM, Ali Çehreli wrote: Apparent from uncharacteristic messages from Dmitry's account to multiple destinations recently, I suspect his gmail account has been compromised. Could also be a psychotic episode or some such. The incoherent rambling doesn't seem to be just bad English. You've got stuff like "I can save the world" in there, which sounds more like mental illness than an imposter to me. If someone's going around as an imposter on a web forum, I'd say it's pretty clear that in and of itself indicates SOME form of mental illness, even if the illness is something as basic and simple as "idiot" and "jackass". We already know we've had a problem with a puppet whackjob here lately. Occam's Razor suggests it's likely just more of the same nut. Over-analysing unlikely scenarios is only going to encourage more. It's also known that mental illness readily stems from paranoia and believing others are mentally ill and out to get them in some way shape or fashion. Its known by who? By armchair psychologists? Paranoia is a symptom of mental illness not a cause in itself. And paranoid delusions vary from person to person, they dont generally think other people are mentally ill. Probably comes from primitive circuitry that hasn't yet been eliminated evolution wise(after all, modern societies have only existed for a few hundred years... lot's have changed but the brain has yet to evolve to handle those changes). There are many causes, genetic, environmental, gut bacteria, autoimmune disease. There's cases of people who have had their gut bacteria replaced to deal with other health issues who have suddenly been cured of their OCD for example. A lot of gut bacteria consume or produce neurotransmitters for example. Brain inflammation is another cause, a big area of research at the moment. The point is most of these causes are not down to prehistoric brain circuits, it's genuinely other causes. Or a mix of all these things together. You are vastly over simplifying a very complex issue. Also there's no way we can know how much of a modern problem it is because we've only seen mental illness as an illness for a couple of hundred years. So we have no idea whether it is more prevalent now that it was a thousand years ago. After all, I'd say that a society that has developed weapons that can only be used to destroy itself requires a massive amount of mental illness... of course, they disagree, so maybe mental illness is actually relative. It's known quite well that most people who work in the mental illness sector are also mentally ill themselves(I guess it's hard not to go crazy when everyone else is). The idea that "crazy" is catching is idiotic, sorry.
Re: std.experimental.allocator and const etc.
On 7/15/18 9:06 AM, John Colvin wrote:
Currently the API's don't support const(void)[], e.g.
import std.experimental.allocator : makeArray, theAllocator, dispose;
import std.experimental.allocator.mallocator : Mallocator;
void main()
{
const a = theAllocator.makeArray!ubyte(100);
theAllocator.dispose(a);
// can't call RCIAllocator.deallocate(void[] b) with const(ubyte)[]
const(void)[] b = Mallocator.instance.allocate(100);
Mallocator.instance.deallocate(b);
// can't call Mallocator.deallocate(void[] b) with const(void)[]
}
Is this deliberate? It's pretty annoying.
I don't think it's something that was considered. I would expect at
least dispose to support it by casting away const.
-Steve
Re: Copy Constructor DIP
On 7/16/18 8:57 PM, docandrew wrote: I think in this case, a more obscure name like @copyctor is more descriptive. On the contrary, it is redundant and uninformative. It applies to exactly a constructor that copies, so it adds no information. "@implicit" describes precisely what the attribute does.
Shopping on Amazon on Prime Day (and beyond)? Support the D language!
Amazon has a nonprofit arm: https://smile.amazon.com Go there and choose The D Language Foundation as your charity of choice, then shop normally through smile.amazon.com. A fraction of your expenditure will go to the Foundation. Thanks, Andrei
Re: Copy Constructor DIP
On 7/17/18 12:04 AM, Manu wrote: But that's the point, and the key advantage of the name ;) [:nod:]
Re: Anyone can contact Dmitry Olshansky?
Thanks, Dave, for the good points. All: please refrain from commenting on the mental disposition of community members publicly. Thanks, Andrei
Re: Copy Constructor DIP
On Tuesday, 17 July 2018 at 07:27:32 UTC, Jacob Carlborg wrote: On Tuesday, 17 July 2018 at 00:04:12 UTC, Andrei Alexandrescu wrote: Then "negative" :o). In brief @implicit follows the same implementation as @safe and @nogc/ Why? This is a breaking change. Why not go with an approach that does not cause any breaking changes, which is just as easy to do? It also doesn't required any special casing in the parser. This is how @selector is implemented. -- /Jacob Carlborg Can you explain a bit more here? How does having implicit as a compiler recognized UDA avoid breaking changes as opposed to it being implemented like @nogc/@safe (how are those implemented differently anyway?) Cheers, - Ali
Re: Copy Constructor DIP
On Tuesday, 17 July 2018 at 04:04:33 UTC, Manu wrote: On Mon., 16 Jul. 2018, 6:00 pm docandrew via Digitalmars-d, < digitalmars-d@puremagic.com> wrote: On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu wrote: > On 7/14/18 5:03 AM, Luís Marques wrote: >> If there is "no other meaning of @implicit" (other than the >> intersection of those two properties) why don't you just >> call it something like @copyctor? > > I'm totally cool with giving the attribute a more obscure > name such as @copyctor or anything people want really. > > (What follows is a personal opinion. > > I think it's better to choose a more general attribute name > with reduced initial applicability. Then application of said > attribute can be extended to other functions with ease. In > contrast, an obscure attribute name is sure to be followed > by more obscure attribute names. And don't get me started > about inventing new syntax. > > Regarding the hand-wringing over generality: we have an > exceedingly poor record of paralysis of analysis, whereby > we'd worry that every design decision potentially locks us > out from all other as-of-yet-unchosen design decisions. If > history is any indication, this sudden worry about > vaguely-promising green pastures of the future is a sign of > malady. We want copy construction. Conflating this with a > very general schemata for implicit conversion would not be a > wise decision in my opinion. I now deeply regret ever > telling Razvan to mention future possible directions. This > DIP must do implicit copy constructors and do it well, > nothing less and nothing more.) > > > Andrei I think in this case, a more obscure name like @copyctor is more descriptive. I fear that at some point, a more general attribute like "@implicit" will turn into the next "static". To me, @implicit smells like one of those keywords that will grow to carry many different meanings in different contexts and just end up overly-broad. But that's the point, and the key advantage of the name ;) Aye! And in this case it really is implicit copy construction. With this attribute in the compiler I can also see a future DIP that deprecates implicit construction and requires an explicit @implicit be added to constructors! Which also sounds like a win :D It's not ideal that the implicit attribute does not have a larger discussion around it. But it is nice to something in D where the default is the conservative approach and the more liberal has to be explicitly asked for. And at the same time, at this point it really is an attribute that is only applicable to copy constructors. So how much expansion on that would be enough I wonder? Cheers, - Ali
Re: DIP 1014--Hooking D's struct move semantics--Final Review
On Thursday, 12 July 2018 at 10:24:40 UTC, Shachar Shemesh wrote: On 29/06/18 15:35, aliak wrote: On Wednesday, 27 June 2018 at 07:24:05 UTC, Mike Parker wrote: On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote: Thanks in advance for your participation. For those of you using the NNTP or mailing list interfaces, this is the thread to respond in. Thanks! Alo! This is great! Just a clarification about the last paragraph phrasing The last line: "We can further reduce this problem by calling the function opPostMove." seemed to imply that an alternate name to opPostMove would be mentioned, but am I correct in understanding that it is just saying that "naming this second function as op* will keep code breakage to a minimum" ? This is a left over from a previous draft, where the operator was called "opMove". It should be removed. Also, what should happen if someone defines an opPostMove for a class. Compile error or? Should something about that be mentioned? I think nothing should happen. The function would be ignored, just like it is today. I am open to hear other ideas, however. I'm not sure whether it should be explicitly mentioned or not. Shachar A postblit on a class issues a compiler error. And an identity opAssign on a class also issues a compiler error. So I'm not sure how this would be different. And the page In https://dlang.org/spec/operatoroverloading.html also explicitly mentions differences between ops on classes or structs. Cheers, - Ali
Re: Copy Constructor DIP
On Saturday, 14 July 2018 at 00:57:14 UTC, Andrei Alexandrescu
wrote:
[...]
chucklesomely profligate and ridiculously baroque.
Andrei
Hahaha this sentence... amazing! :D
I was going to propose auto this(ref A other) {} but nevermind :p
Cheers,
- Ali
Re: Copy Constructor DIP
On Saturday, 14 July 2018 at 10:53:17 UTC, Andrei Alexandrescu wrote: I think it's better to choose a more general attribute name with reduced initial applicability. Then application of said attribute can be extended to other functions with ease. In contrast, an obscure attribute name is sure to be followed by more obscure attribute names. And don't get me started about inventing new syntax. Regarding the hand-wringing over generality: we have an exceedingly poor record of paralysis of analysis, whereby we'd worry that every design decision potentially locks us out from all other as-of-yet-unchosen design decisions. If history is any indication, this sudden worry about vaguely-promising green pastures of the future is a sign of malady. We want copy construction. Conflating this with a very general schemata for implicit conversion would not be a wise decision in my opinion. I now deeply regret ever telling Razvan to mention future possible directions. This DIP must do implicit copy constructors and do it well, nothing less and nothing more.) I also think a more general attribute is better. I think there's a middle ground between total analysis paralysis and no discussion of concept generality. I had hoped some thought would be given to the implications of implicit but overall I'm still happy, and I trust your judgement. BTW, I would still have brought it up even if the DIP didn't mention future directions :-)
Re: Copy Constructor DIP
On 07/17/2018 03:03 PM, aliak00 wrote:
Can you explain a bit more here? How does having implicit as a compiler
recognized UDA avoid breaking changes as opposed to it being implemented
like @nogc/@safe (how are those implemented differently anyway?)
In a UDA `@implicit`, `implicit` is just a normal symbol. So the normal
lookup rules apply. In particular, you can shadow an imported `implicit`
with a local one:
--- object.d
enum implicit = 1; /* Actual implementation would be different. */
--- bar.d
/* invisible default `import object` here */
@implicit void f() {}
static assert(__traits(getAttributes, f)[0] == 1);
/* Passes. `object.implicit` is used. */
--- baz.d
/* invisible default `import object` here */
enum implicit = 2;
@implicit void f() {}
static assert(__traits(getAttributes, f)[0] == 2);
/* Passes. The local `implicit` is used. */
You can't do that with `@safe`, because `@safe` is not a UDA, and `safe`
is not a symbol there. `@safe` is special syntax, recognized as a whole
by the parser. No symbol lookup is happening.
You can see the difference if you change all occurrences of "implicit"
to "safe" in that code. Won't work.
As for breakage, baz.d is working code today. With `@implicit` as a UDA,
it keeps working in the same way. With `@implicit` as a new non-UDA
attribute, it will change its meaning, and the assert will fail.
Re: Copy Constructor DIP
On Tuesday, 17 July 2018 at 14:41:06 UTC, ag0aep6g wrote: On 07/17/2018 03:03 PM, aliak00 wrote: [...] In a UDA `@implicit`, `implicit` is just a normal symbol. So the normal lookup rules apply. In particular, you can shadow an imported `implicit` with a local one: [...] Ah, gotcha! Thank you!
std.experimental.collections.rcstring and its integration in Phobos
So we managed to revive the rcstring project and it's already a
PR for Phobos:
https://github.com/dlang/phobos/pull/6631 (still WIP though)
The current approach in short:
- uses the new @nogc, @safe and nothrow Array from the
collections library (check Eduardo's DConf18 talk)
- uses reference counting
- _no_ range by default (it needs an explicit `.by!{d,w,}char`)
(as in no auto-decoding by default)
Still to be done:
- integration in Phobos (the current idea is to generate
additional overloads for rcstring)
- performance
- use of static immutable rcstring in fully @nogc
- extensive testing
Especially the "seamless" integration in Phobos will be
challenging.
I made a rough listing of all symbols that one would expect to be
usable with an rcstring type
(https://gist.github.com/wilzbach/d74712269f889827cff6b2c7a08d07f8). It's more than 200.
As rcstring isn't a range by default, but one excepts
`"foo".rcstring.equal("foo")` to work, overloads for all these
symbols would need to be added.
What do you think about this approach? Do you have a better idea?
Re: std.experimental.collections.rcstring and its integration in Phobos
On Tuesday, July 17, 2018 15:21:30 Seb via Digitalmars-d wrote:
> So we managed to revive the rcstring project and it's already a
> PR for Phobos:
>
> https://github.com/dlang/phobos/pull/6631 (still WIP though)
>
> The current approach in short:
>
> - uses the new @nogc, @safe and nothrow Array from the
> collections library (check Eduardo's DConf18 talk)
> - uses reference counting
> - _no_ range by default (it needs an explicit `.by!{d,w,}char`)
> (as in no auto-decoding by default)
>
> Still to be done:
>
> - integration in Phobos (the current idea is to generate
> additional overloads for rcstring)
> - performance
> - use of static immutable rcstring in fully @nogc
> - extensive testing
>
> Especially the "seamless" integration in Phobos will be
> challenging.
> I made a rough listing of all symbols that one would expect to be
> usable with an rcstring type
> (https://gist.github.com/wilzbach/d74712269f889827cff6b2c7a08d07f8). It's
> more than 200. As rcstring isn't a range by default, but one excepts
> `"foo".rcstring.equal("foo")` to work, overloads for all these
> symbols would need to be added.
>
> What do you think about this approach? Do you have a better idea?
If it's not a range by default, why would you expect _anything_ which
operates on ranges to work with rcstring directly? IMHO, if it's not a
range, then range-based functions shouldn't work with it, and I don't see
how they even _can_ work with it unless you assume code units, or code
points, or graphemes as the default. If it's designed to not be a range,
then it should be up to the programmer to call the appropriate function on
it to get the appropriate range type for a particular use case, in which
case, you really shouldn't need to add much of any overloads for it.
- Jonathan M Davis
Re: Copy Constructor DIP
On Friday, 13 July 2018 at 12:31:41 UTC, Atila Neves wrote: On Friday, 13 July 2018 at 03:01:25 UTC, Manu wrote: On Thu, 12 Jul 2018 at 19:15, Andrei Alexandrescu via Digitalmars-d wrote: On 7/12/18 6:34 PM, Manu wrote: > On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via > Digitalmars-d wrote: >> [..] doesn't perform copy construction? 1. the function is highly unlikely to exist because postblit; it's a meaningless function to write. are there any known instances of that signature in the wild? https://github.com/search?q=%22this%5C%28ref%22+language%3AD&type=Code The answer seems to be: not many. Most of the results above are false positives because github won't let me escape the left parenthesis. Atila https://www.google.no/search?q=allintext%3A+%22this%28ref%22+site%3Agithub.com+filetype%3Ad&oq=allintext%3A+%22this%28ref%22+site%3Agithub.com+filetype%3Ad
Re: std.experimental.collections.rcstring and its integration in Phobos
On Tuesday, 17 July 2018 at 16:58:37 UTC, Jonathan M Davis wrote: On Tuesday, July 17, 2018 15:21:30 Seb via Digitalmars-d wrote: [...] If it's not a range by default, why would you expect _anything_ which operates on ranges to work with rcstring directly? IMHO, if it's not a range, then range-based functions shouldn't work with it, and I don't see how they even _can_ work with it unless you assume code units, or code points, or graphemes as the default. If it's designed to not be a range, then it should be up to the programmer to call the appropriate function on it to get the appropriate range type for a particular use case, in which case, you really shouldn't need to add much of any overloads for it. - Jonathan M Davis Well, there are few cases where the range type doesn't matter and one can simply compare bytes, e.g. equal (e.g. "ä" == "ä" <=> [195, 164] == [195, 164]) commonPrefix find ... Of course this assumes that there's no normalization necessary, but the current auto-decoding assumes this too.
[Fwd: [accu-general] Code Critique 112]
Hi,
Hopefully, people are preparing their submissions for this CVu Code
Critique. I am writing one as we speak, but as I know absolutely SFA
about Vibe.d I am sure it will be as crap as the code below. ACCU
members would I suspect like to have some constructive material on
using D for Web backends. Many of them know and use Go and Python.
Forwarded Message
> Code Critique 112
>
> Hello all,
> Below is the code for Code Critique number 112
>
> As usual, please don't reply to the list with your entry but email
> s...@accu.org for collation.
>
> Regards,
> Steve.
> ---
> -
> (Submissions to s...@accu.org by August 1st)
>
> Further to articles introducing D, I am attempting to use the
> event-driven Vibe.d server library, which I understand to be like a
> native version of Python's Tornado and potentially a “killer app” of
> D
> as I haven't seen any other mature event-driven server library in a
> compiled language.
>
> I would like to build a back-end server that performs some processing
> on
> the body of the HTTP request it receives. To begin with, I would
> like
> it to simply echo the request body back to the client.
>
> My code works but there are three problems: (1) when I issue a POST
> request with lynx, 3 spaces are added to the start of the response
> text,
> (2) I cannot test with nc because it just says 404 and doesn't log
> anything, and (3) I'm worried that reading and writing just one byte
> at
> a time is inefficient, but I can't see how else to do it: I raised a
> "more documentation needed" bug at
> https://github.com/vibe-d/vibe.d/issues/2139 but at the time of
> writing
> nobody has replied (should I have used a different forum?)
>
> --- code ---
> import vibe.d;
> void main() {
> auto settings = new HTTPServerSettings;
> settings.port = 8080;
> listenHTTP(settings, (req, res) {
> ubyte[1] s;
> while(!req.bodyReader.empty()) {
> req.bodyReader.read(s);
> res.bodyWriter.write(s);
> }
> });
> runApplication();
> }
>
> ___
> accu-general mailing list
> accu-gene...@accu.org
> https://lists.accu.org/mailman/listinfo/accu-general
--
Russel.
===
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
signature.asc
Description: This is a digitally signed message part
Re: std.experimental.collections.rcstring and its integration in Phobos
On 2018-07-17 17:21, Seb wrote:
- _no_ range by default (it needs an explicit `.by!{d,w,}char`) (as in
no auto-decoding by default)
What do you think about this approach? Do you have a better idea?
I vote for .by!char to be the default.
--
/Jacob Carlborg
Re: Anyone can contact Dmitry Olshansky?
On Tuesday, 17 July 2018 at 09:08:03 UTC, Dave Jones wrote: On Monday, 16 July 2018 at 16:20:24 UTC, Mr.Bingo wrote: On Tuesday, 3 July 2018 at 07:31:46 UTC, Nick Sabalausky (Abscissa) wrote: On 07/01/2018 05:34 AM, ag0aep6g wrote: On 07/01/2018 08:00 AM, Ali Çehreli wrote: Apparent from uncharacteristic messages from Dmitry's account to multiple destinations recently, I suspect his gmail account has been compromised. Could also be a psychotic episode or some such. The incoherent rambling doesn't seem to be just bad English. You've got stuff like "I can save the world" in there, which sounds more like mental illness than an imposter to me. If someone's going around as an imposter on a web forum, I'd say it's pretty clear that in and of itself indicates SOME form of mental illness, even if the illness is something as basic and simple as "idiot" and "jackass". We already know we've had a problem with a puppet whackjob here lately. Occam's Razor suggests it's likely just more of the same nut. Over-analysing unlikely scenarios is only going to encourage more. It's also known that mental illness readily stems from paranoia and believing others are mentally ill and out to get them in some way shape or fashion. Its known by who? By armchair psychologists? Paranoia is a symptom of mental illness not a cause in itself. And paranoid delusions vary from person to person, they dont generally think other people are mentally ill. Probably comes from primitive circuitry that hasn't yet been eliminated evolution wise(after all, modern societies have only existed for a few hundred years... lot's have changed but the brain has yet to evolve to handle those changes). There are many causes, genetic, environmental, gut bacteria, autoimmune disease. There's cases of people who have had their gut bacteria replaced to deal with other health issues who have suddenly been cured of their OCD for example. A lot of gut bacteria consume or produce neurotransmitters for example. Brain inflammation is another cause, a big area of research at the moment. The point is most of these causes are not down to prehistoric brain circuits, it's genuinely other causes. Or a mix of all these things together. You are vastly over simplifying a very complex issue. Also there's no way we can know how much of a modern problem it is because we've only seen mental illness as an illness for a couple of hundred years. So we have no idea whether it is more prevalent now that it was a thousand years ago. After all, I'd say that a society that has developed weapons that can only be used to destroy itself requires a massive amount of mental illness... of course, they disagree, so maybe mental illness is actually relative. It's known quite well that most people who work in the mental illness sector are also mentally ill themselves(I guess it's hard not to go crazy when everyone else is). The idea that "crazy" is catching is idiotic, sorry. I see we have the resident genius on hand. Yes, anything that doesn't fit within your narrow understanding of science is idiotic. I would get in to it with you but I really do have better things to do then try to educate you on what real science is and what we really know about all the problems that we think we know so much about. Just keep in mind, second hand knowledge of science may be useful but it does not mean you understand science, it's purpose, or how it relates in the big picture. BTW, using your logic cults must be created by the cultists all having the same food diet. Yes, I know you will say that is not what you said because there are other factors like vitamin deficiencies(certain combinations, like some chemical ratios, of vitamin deficiencies creates cults). In fact, if you think a cult member is crazy then you also have to scientifically find some correlation between all them and diet. You should have no problem with your gifted scientific abilities to prove that! Just go collect the data, genius! (again, you will say it is not about vitamins because vitamins are basically related to food so that was already addressed in the first case and it is really some other thing...) But, I see you have lived with a bunch of crazy people your entire life... Too bad you haven't learned about relativity... or psychology.
Re: std.experimental.collections.rcstring and its integration in Phobos
On Tuesday, July 17, 2018 17:28:19 Seb via Digitalmars-d wrote: > On Tuesday, 17 July 2018 at 16:58:37 UTC, Jonathan M Davis wrote: > > On Tuesday, July 17, 2018 15:21:30 Seb via Digitalmars-d wrote: > >> [...] > > > > If it's not a range by default, why would you expect _anything_ > > which operates on ranges to work with rcstring directly? IMHO, > > if it's not a range, then range-based functions shouldn't work > > with it, and I don't see how they even _can_ work with it > > unless you assume code units, or code points, or graphemes as > > the default. If it's designed to not be a range, then it should > > be up to the programmer to call the appropriate function on it > > to get the appropriate range type for a particular use case, in > > which case, you really shouldn't need to add much of any > > overloads for it. > > > > - Jonathan M Davis > > Well, there are few cases where the range type doesn't matter and > one can simply compare bytes, e.g. > > equal (e.g. "ä" == "ä" <=> [195, 164] == [195, 164]) > commonPrefix > find > ... That effectively means treating rcstring as a range of char by default rather than not treating it as a range by default. And if we then do that only with functions that overload on rcstring rather than making rcstring actually a range of char, then why aren't we just treating it as a range of char in general? IMHO, the fact that so many alogorithms currently special-case on arrays of characters is one reason that auto-decoding has been a disaster, and adding a bunch of overloads for rcstring is just compounding the problem. Algorithms should properly support arbitrary ranges of characters, and then rcstring can be passed to them by calling one of the functions on it to get a range of code units, code points, or graphemes to get an actual range - either that, or rcstring should default to being a range of char. going halfway and making it work with some functions via overloads really doesn't make sense. Now, if we're talking about functions that really operate on strings and not ranges of characters (and thus do stuff like append), then that becomes a different question, but we've mostly been trying to move away from functions like that in Phobos. > Of course this assumes that there's no normalization necessary, > but the current auto-decoding assumes this too. You can still normalize with auto-decoding (the code units - and thus code points - are in a specific order even when encoded, and that order can be normalized), and really, anyone who wants fully correct string comparisons needs to be normalizing their strings. With that in mind, rcstring probably should support normalization of its internal representation. - Jonathan M Davis
opCmp / opEquals do not actually support partial orders
As we know, when opCmp is defined for a user type, then opEquals must also be defined in order for == to work, even though in theory the compiler could translate x==y into x.opCmp(y)==0. In the past, it was argued that this was so that partial orders could be made to work, i.e., it could be the case that x and y are incomparable, then x.opCmp(y) would return 0, and x.opEquals(y) would be false. Supposedly, this would allow us to, say, model the subset relation (which is a partial order) using the comparison operators. However, this supposition is in fact false. The reason is that `<=` and `>=` *only* check the return value of opCmp(); they do not check opEquals at all. So suppose we define a Set type, and we'd like to use the comparison operators to model the subset relation. How would we define opCmp and opEquals? opEquals is obvious, of course. It's true if x and y have the same elements, false otherwise. But opCmp turns out to be a tarpit. Here's why: - If x is a (strict) subset of y, then obviously we should return -1. - If x is a (strict) superset of y, then obviously we return 1. - If x and y have the same elements, then obviously we should return 0, since we'd like x <= y and x >= y to be true when x == y is true. - If x and y are not subsets of each other, then what should we return? According to the original claim, it should also return 0, for "incomparable". However, this leads to problems: - Since `x <= y` in D means `x.opCmp(y) <= 0`, this will return TRUE when x and y are incomparable. - Similarly, `x >= y` in D means `x.opCmp(y) >= 0`, so it will also return TRUE when x and y are incomparable. - Therefore, `x <= y` cannot distinguish between x being a non-strict subset of y vs. x and y being incomparable. Similarly for `x >= y`. So we have the counterintuitive semantics that <= and >= will return true for non-comparable sets. There is no return value of opCmp for which both <= and >= will be false, as we need it to be if we are to map <= to ⊆ and >= to ⊇. Furthermore, this situation cannot be remedied by redefining < and > to be ⊆ and ⊇ (as we might try to do in order to work around <= and >= not checking the return value of opEquals), because when x == y, then there is no return value that opCmp could return that would make `x < y` and `x > y` both true simultaneously. IOW, with the current semantics of opEquals and opCmp, it is impossible to map the semantics of ⊆ and ⊇ to the comparison operators, in spite of the fact that we allow opCmp() to return 0 when opEquals returns false. Conclusion: the claim that opCmp/opEquals could be made to support partial orders is patently false. In fact, it cannot even be made to model NaN's in floating-point arithmetic, which is a mostly-linear ordering, because there is no way to make <= and >= both false using opCmp() when NaN's are involved (e.g., in a user-defined floating-point wrapper type). The best you can get is that `x <= NAN` and `x >= NAN` is always true. Corollary: allowing opCmp()==0 to be inconsistent with opEquals()==true is useless, since we cannot actually use it to support any meaningful ordering that isn't a linear ordering. Thus, it only serves as a source of confusion, and should be made illegal in the language. T -- EMACS = Extremely Massive And Cumbersome System
DMD, Vibe.d, and Dub
Hi, I set up the CVu Code Critique 112 code in a cannical D project with a minimal dub.sdl file. name "server" description "A sample server using vibe.d for CVu Code Critique 112" dependency "vibe-d" version="*" I am on Debian Sid with Dub and DMD from d-apt (so Dub 1.1.0.0 and DMD 2.081.0) and then: |> dub build Fetching eventcore 0.8.35 (getting selected version)... Fetching libevent 2.0.2+2.0.16 (getting selected version)... Fetching diet-ng 1.5.0 (getting selected version)... Fetching taggedalgebraic 0.10.11 (getting selected version)... Fetching openssl 1.1.6+1.0.1g (getting selected version)... Fetching botan 1.12.10 (getting selected version)... Fetching stdx-allocator 2.77.2 (getting selected version)... Fetching vibe-d 0.8.4 (getting selected version)... Fetching mir-linux-kernel 1.0.0 (getting selected version)... Fetching memutils 0.4.11 (getting selected version)... Fetching vibe-core 1.4.1 (getting selected version)... Fetching libasync 0.8.3 (getting selected version)... Fetching botan-math 1.0.3 (getting selected version)... Performing "debug" build using /usr/bin/dmd for x86_64. taggedalgebraic 0.10.11: building configuration "library"... eventcore 0.8.35: building configuration "epoll"... stdx-allocator 2.77.2: building configuration "library"... vibe-core 1.4.1: building configuration "epoll"... vibe-d:utils 0.8.4: building configuration "library"... vibe-d:data 0.8.4: building configuration "library"... mir-linux-kernel 1.0.0: building configuration "library"... vibe-d:crypto 0.8.4: building configuration "library"... diet-ng 1.5.0: building configuration "library"... vibe-d:stream 0.8.4: building configuration "library"... ../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/stream/vibe/stream/wrapper.d(179,22): Error: no property connected for type const(InterfaceProxy!(ConnectionStream)) ../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/stream/vibe/stream/wrapper.d(187,19): Error: no property connected for type InterfaceProxy!(ConnectionStream) ../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/stream/vibe/stream/wrapper.d(188,15): Error: no property close for type InterfaceProxy!(ConnectionStream) ../../../../../.dub/packages/vibe-d-0.8.4/vibe-d/stream/vibe/stream/wrapper.d(198,22): Error: no property waitForData for type InterfaceProxy!(ConnectionStream) /usr/bin/dmd failed with exit code 1. This would seem to imply that you can't use Vibe.d 0.8.4 with DMD 2.081.0. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: std.experimental.collections.rcstring and its integration in Phobos
On Tuesday, 17 July 2018 at 15:21:30 UTC, Seb wrote: So we managed to revive the rcstring project and it's already a PR for Phobos: [snip] I'm glad this is getting worked on. It feels like something that D has been working towards for a while. Unfortunately, I haven't (yet) watched the collections video at Dconf and don't see a presentation on the website. Because of that, I don't really understand some of the design decisions. For instance, I also don't really understand how RCIAllocator is different from the old IAllocator (the documentation could use some work, IMO). It looks like RCIAllocator is part of what drives the reference counting semantics, but it also looks like Array has some support for reference counting, like addRef, that invoke RCIAllocator somehow. But Array also has some support for gc_allocator as the default, so my cursory examination suggests that Array is not really intended to be an RCArray... So at that point I started wondering why not just have String as an alias of Array, akin to how D does it for dynamic arrays to strings currently. If there is stuff in rcstring now that isn't in Array, then that could be included in Array as a compile-time specialization for the relevant types (at the cost of bloating Array). And then leave it up to the user how to allocate. I think part of the above design decision connects in with why rcstring stores the data as ubytes, even for wchar and dchar. Recent comments suggest that it is related to auto-decoding. My sense is that an rcstring that does not have auto-decoding, even if it requires more work to get working with phobos is a better solution over the long-run.
Re: DMD, Vibe.d, and Dub
On Tuesday, 17 July 2018 at 18:31:18 UTC, Russel Winder wrote: This would seem to imply that you can't use Vibe.d 0.8.4 with DMD 2.081.0. I think that regression was the main reason for early 2.081.1.
Re: DMD, Vibe.d, and Dub
I then tried with ldc2, which on Debian Sid in 1.8.0 :-( |> dub build --compiler=ldc2 Performing "debug" build using ldc2 for x86_64. taggedalgebraic 0.10.11: building configuration "library"... eventcore 0.8.35: building configuration "epoll"... stdx-allocator 2.77.2: building configuration "library"... vibe-core 1.4.1: building configuration "epoll"... vibe-d:utils 0.8.4: building configuration "library"... vibe-d:data 0.8.4: building configuration "library"... mir-linux-kernel 1.0.0: building configuration "library"... vibe-d:crypto 0.8.4: building configuration "library"... diet-ng 1.5.0: building configuration "library"... vibe-d:stream 0.8.4: building configuration "library"... vibe-d:textfilter 0.8.4: building configuration "library"... vibe-d:inet 0.8.4: building configuration "library"... vibe-d:tls 0.8.4: building configuration "openssl"... vibe-d:http 0.8.4: building configuration "library"... vibe-d:mail 0.8.4: building configuration "library"... vibe-d:mongodb 0.8.4: building configuration "library"... vibe-d:redis 0.8.4: building configuration "library"... vibe-d:web 0.8.4: building configuration "library"... vibe-d 0.8.4: building configuration "vibe-core"... server ~master: building configuration "application"... /usr/bin/ld: cannot find -lssl /usr/bin/ld: cannot find -lcrypto collect2: error: ld returned 1 exit status Error: /usr/bin/gcc failed with status: 1 ldc2 failed with exit code 1. which came as a surprise. Is this a my project problem (I believe it shouldn't be) or a vibe.d/ldc2 problem? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: DMD, Vibe.d, and Dub
On Tue, 2018-07-17 at 18:49 +, kinke via Digitalmars-d wrote: > On Tuesday, 17 July 2018 at 18:31:18 UTC, Russel Winder wrote: > > This would seem to imply that you can't use Vibe.d 0.8.4 with > > DMD 2.081.0. > > I think that regression was the main reason for early 2.081.1. Ah, OK. I'll have to wait for a d-apt update then. Thanks for the "heads up". -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: DMD, Vibe.d, and Dub
On Tue, 2018-07-17 at 20:23 +0100, Russel Winder wrote: > On Tue, 2018-07-17 at 18:49 +, kinke via Digitalmars-d wrote: > > On Tuesday, 17 July 2018 at 18:31:18 UTC, Russel Winder wrote: > > > This would seem to imply that you can't use Vibe.d 0.8.4 with > > > DMD 2.081.0. > > > > I think that regression was the main reason for early 2.081.1. > > Ah, OK. I'll have to wait for a d-apt update then. Thanks for the > "heads up". It seems that the LDC 1.11 branch in the GitHub repository has the DMD 2.081.0 problem. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: DMD, Vibe.d, and Dub
On Tuesday, 17 July 2018 at 19:39:32 UTC, Russel Winder wrote: It seems that the LDC 1.11 branch in the GitHub repository has the DMD 2.081.0 problem. If you're referring to branch merge-2.081, that one doesn't exist anymore. master/beta2 are based on 2.081.1+ and should thus be fixed.
Re: opCmp / opEquals do not actually support partial orders
On Tuesday, 17 July 2018 at 18:21:26 UTC, H. S. Teoh wrote: As we know, when opCmp is defined for a user type, then opEquals must also be defined in order for == to work, even though in theory the compiler could translate x==y into x.opCmp(y)==0. In the past, it was argued that this was so that partial orders could be made to work, i.e., it could be the case that x and y are incomparable, then x.opCmp(y) would return 0, and x.opEquals(y) would be false. Supposedly, this would allow us to, say, model the subset relation (which is a partial order) using the comparison operators. However, this supposition is in fact false. The reason is that `<=` and `>=` *only* check the return value of opCmp(); they do not check opEquals at all. So suppose we define a Set type, and we'd like to use the comparison operators to model the subset relation. How would we define opCmp and opEquals? opEquals is obvious, of course. It's true if x and y have the same elements, false otherwise. But opCmp turns out to be a tarpit. Here's why: - If x is a (strict) subset of y, then obviously we should return -1. - If x is a (strict) superset of y, then obviously we return 1. - If x and y have the same elements, then obviously we should return 0, since we'd like x <= y and x >= y to be true when x == y is true. - If x and y are not subsets of each other, then what should we return? According to the original claim, it should also return 0, for "incomparable". However, this leads to problems: - Since `x <= y` in D means `x.opCmp(y) <= 0`, this will return TRUE when x and y are incomparable. - Similarly, `x >= y` in D means `x.opCmp(y) >= 0`, so it will also return TRUE when x and y are incomparable. - Therefore, `x <= y` cannot distinguish between x being a non-strict subset of y vs. x and y being incomparable. Similarly for `x >= y`. So we have the counterintuitive semantics that <= and >= will return true for non-comparable sets. There is no return value of opCmp for which both <= and >= will be false, as we need it to be if we are to map <= to ⊆ and >= to ⊇. Just do what std.typecons.Proxy does and return float.nan for the incomparable case.
Re: DMD, Vibe.d, and Dub
On Tuesday, 17 July 2018 at 18:55:07 UTC, Russel Winder wrote: [...] Missing openssl libs? Try installing openssl-dev package.
Re: Error: only one main allowed. Previously found main at *
I have also faced this same issue. But I couldn't recover from it. One of my friends suggests me to contact https://applesupportnumber.net/apple-customer-support/ for help. AS he said I contact them and they solved my issue. You should also try them.
Re: Anyone can contact Dmitry Olshansky?
On Tuesday, 17 July 2018 at 17:47:57 UTC, Mr.Bingo wrote: On Tuesday, 17 July 2018 at 09:08:03 UTC, Dave Jones wrote: On Monday, 16 July 2018 at 16:20:24 UTC, Mr.Bingo wrote: On Tuesday, 3 July 2018 at 07:31:46 UTC, Nick Sabalausky I see we have the resident genius on hand. Yes, anything that doesn't fit within your narrow understanding of science is idiotic. I would get in to it with you but I really do have better things to do then try to educate you on what real science is and what we really know about all the problems that we think we know so much about. Just keep in mind, second hand knowledge of science may be useful but it does not mean you understand science, it's purpose, or how it relates in the big picture. I critiqued what you actually said, you make vague jumbled assertions about my understanding of science. If you cant attack the argument attack the man. *shrug* BTW, using your logic cults must be created by the cultists all having the same food diet. Yes, I know you will say that is not what you said because there are other factors like vitamin deficiencies(certain combinations, like some chemical ratios, of vitamin deficiencies creates cults). I said gut bacteria is one of many causes. I did not say it was the cause of all mental illness. Do try and keep up. In fact, if you think a cult member is crazy then you also have to scientifically find some correlation between all them and diet. You should have no problem with your gifted scientific abilities to prove that! Just go collect the data, genius! (again, you will say it is not about vitamins because vitamins are basically related to food so that was already addressed in the first case and it is really some other thing...) Strawman. Logical fallacy. And just plain stupid. But, I see you have lived with a bunch of crazy people your entire life... Too bad you haven't learned about relativity... or psychology. LMAO that has got to be the most retarded thing anyone has ever said to me in my entire life. How old are you? (BTW it's a trick question)
Re: Copy Constructor DIP
On Tue, 17 Jul 2018 at 10:20, aliak via Digitalmars-d wrote: > > On Friday, 13 July 2018 at 12:31:41 UTC, Atila Neves wrote: > > On Friday, 13 July 2018 at 03:01:25 UTC, Manu wrote: > >> On Thu, 12 Jul 2018 at 19:15, Andrei Alexandrescu via > >> Digitalmars-d wrote: > >>> > >>> On 7/12/18 6:34 PM, Manu wrote: > >>> > On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via > >>> > Digitalmars-d wrote: > >>> >> > >> [..] > >> doesn't perform copy construction? > >> 1. the function is highly unlikely to exist because > >> postblit; it's a > >> meaningless function to write. are there any known instances > >> of that > >> signature in the wild? > > > > https://github.com/search?q=%22this%5C%28ref%22+language%3AD&type=Code > > > > The answer seems to be: not many. Most of the results above are > > false positives because github won't let me escape the left > > parenthesis. > > > > Atila > > https://www.google.no/search?q=allintext%3A+%22this%28ref%22+site%3Agithub.com+filetype%3Ad&oq=allintext%3A+%22this%28ref%22+site%3Agithub.com+filetype%3Ad I clicked through quite a few. Every function that's a valid copy constructor by the definition here does indeed perform a valid copy construction with no side-effects, as predicted. Existing functions interpreted as copy constructors under this DIP would continue to work as intended. There's a ridiculously low probability that any such wild function that would be broken by a no-attribute version of this DIP exists.
Re: DIP 1014--Hooking D's struct move semantics--Final Review
On 17/07/18 16:29, aliak00 wrote: A postblit on a class issues a compiler error. And an identity opAssign on a class also issues a compiler error. So I'm not sure how this would be different. And the page In https://dlang.org/spec/operatoroverloading.html also explicitly mentions differences between ops on classes or structs. That's actually a good argument. It should definitely be handled the same way the corresponding opAssign is handled. Thanks, Shachar
Re: std.experimental.collections.rcstring and its integration in Phobos
On 7/17/18 12:58 PM, Jonathan M Davis wrote: If it's not a range by default, why would you expect_anything_ which operates on ranges to work with rcstring directly? Many functions do not care about the range aspect, but do care about the string aspect. Consider e.g. chdir.
Re: std.experimental.collections.rcstring and its integration in Phobos
On 18/07/2018 5:41 AM, Jacob Carlborg wrote:
On 2018-07-17 17:21, Seb wrote:
- _no_ range by default (it needs an explicit `.by!{d,w,}char`) (as in
no auto-decoding by default)
What do you think about this approach? Do you have a better idea?
I vote for .by!char to be the default.
I'm thinking .as!T
So we can cover, ubyte/char/wchar/dchar, string/wstring/dstring all in one.
I think whatever we expose as the default for string/wstring/dstring
however should be settable. e.g.
```
struct RCString(DefaultStringType=string) {
alias .as!DefaultStringType this;
}
```
Which is a perfect example of what my named parameter DIP is for ;)
Re: std.experimental.collections.rcstring and its integration in Phobos
On Tuesday, 17 July 2018 at 15:21:30 UTC, Seb wrote:
So we managed to revive the rcstring project and it's already a
PR for Phobos:
https://github.com/dlang/phobos/pull/6631 (still WIP though)
The current approach in short:
- uses the new @nogc, @safe and nothrow Array from the
collections library (check Eduardo's DConf18 talk)
- uses reference counting
- _no_ range by default (it needs an explicit `.by!{d,w,}char`)
(as in no auto-decoding by default)
[snip]
What do you think about this approach? Do you have a better
idea?
I don't know the goals/role rcstring is expected to play,
especially wrt existing string/character facilities. Perhaps you
could describe more?
Strings are central to many applications, so I'm wondering about
things like whether rcstring is intended as a replacement for
string that would be used by most new programs, and whether
applications would use arrays and ranges of char together with
rcstring, or rcstring would be used for everything.
Perhaps its too early for these questions, and the current goal
is simpler. For example, adding a meaningful collection class
that is @nogc, @safe and ref-counted that be used as a proving
ground for the newer memory management facilities being developed.
Such simpler goals would be quite reasonable. What's got me
wondering about the larger questions are the comments about
ranges and autodecoding. If rcstring is intended as a vehicle for
general @nogc handling of character data and/or for reducing the
impact of autodecoding, then it makes sense to consider from
those perspectives.
--Jon
Re: std.experimental.collections.rcstring and its integration in Phobos
On Tuesday, July 17, 2018 22:45:33 Andrei Alexandrescu via Digitalmars-d wrote: > On 7/17/18 12:58 PM, Jonathan M Davis wrote: > > If it's not a range by default, why would you expect_anything_ which > > operates on ranges to work with rcstring directly? > > Many functions do not care about the range aspect, but do care about the > string aspect. Consider e.g. chdir. It doesn't care about strings either. It operates on a range of characters. If a function is just taking a value as input and isn't storing it or mutating its elements, then a range of characters works perfectly fine and is more flexible than any particular type - and IMHO shouldn't then be having overloads for particular ranges of characters or string types if we can avoid it. If we're talking about a functions that's really operating on a string as a string and doing things like appending as opposed to doing range-based operations, then maybe overloading for other string types makes sense rather than requiring an array of characters. But if it's just taking a string and reading it? That has no need to operate on strings specifically and should be operating on a range of characters - something that we've been moving towards with Phobos. As such, I don't think that it generally makes sense for functions in Phobos to be explicitly accepting rcstring unless it's actually a range. If it's not actually a range, then such functions should already work with it by calling the appropriate function to get a range over it without needing to special-case anything. - Jonathan M Davis
Re: Sutter's ISO C++ Trip Report - The best compliment is when someone else steals your ideas....
On Friday, 13 July 2018 at 13:15:39 UTC, Steven Schveighoffer wrote: But it doesn't scale if you use OS processes, it's too heavyweight. Of course, it depends on the application. If you only need 100 concurrent connections, processes might be OK. I think you may have fallen for Microsoft FUD. In the Early Days of Windows Microsoft was appalling Bad at multiple processes Rather than fix their OS, they cranked up their Marketing machine and Hyped threads as "Light Weight Processes". Unixy land has had "COW" (Copy on Write) page handling for years and years and process creation and processes are light weight. There are very very few Good reasons for threads, but threads being "light weight processes" is definitely not one of them
