HMAC and toHexString
... string key = "blahblahblah"; auto mac = hmac!SHA256(key.representation); string s = ...,t=...u=...,v=...; foreach(w;AliasSeq!(s,t,u,v)) mac.put(w.representation); ubyte[32] s = mac.finish; string sig = toHexString!(LetterCase.lower)(s); writeln(sig); // From what I understand Should print something like 41771e2d0d6c1cf7f442aa8547783ea5b126bfc15a4b354e94d0eaea2ab0fa1a // Actually prints something like x"31 36 39 33 39 32 38 31 62 38 31 62 36 36 62 63 63 34 63 36 36 61 62 32 34 37 64 32 64 34 61 00 78 2A 55 5B FF 7F 00 00 78 2A 55 5B FF 7F 00 00 E0 2A 55 5B FF 7F 00 00 08 2C 55 5B FF 7F 00 00"c Note the nuls and things like FF What am I doing wrong here?
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: LDC 1.11.0 beta2
On Wednesday, 18 July 2018 at 01:35:11 UTC, Ali wrote: On Sunday, 15 July 2018 at 19:46:24 UTC, kinke wrote: Glad to announce the second beta for LDC 1.11. * Prebuilt packages now using LLVM 6.0.1 and including additional cross-compilation targets (MIPS, MSP430, RISC-V and WebAssembly). * Rudimentary support for compiling & linking directly to WebAssembly. See the dedicated Wiki page [1] for how to get started. [1] https://wiki.dlang.org/Generating_WebAssembly_with_LDC The WebAssembly part discussed on hackernews https://news.ycombinator.com/item?id=17546063 Second link on the front page now.
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 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: Symmetry Autumn of Code
On 18/07/2018 5:36 AM, Ecstatic Coder wrote: On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ I'd suggest adding the following to SAOC 2018 project proposals : 1/ adding a Go-like http module to the standard library 2/ adding Go-like async IO management to the standard library, i.e. fibers communicating through blocking channels Until we get an event loop in druntime, both of these options are off the table.
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: 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: LDC 1.11.0 beta2
On Sunday, 15 July 2018 at 19:46:24 UTC, kinke wrote: Glad to announce the second beta for LDC 1.11. * Prebuilt packages now using LLVM 6.0.1 and including additional cross-compilation targets (MIPS, MSP430, RISC-V and WebAssembly). * Rudimentary support for compiling & linking directly to WebAssembly. See the dedicated Wiki page [1] for how to get started. [1] https://wiki.dlang.org/Generating_WebAssembly_with_LDC The WebAssembly part discussed on hackernews https://news.ycombinator.com/item?id=17546063
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=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=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: LDC 1.11.0 beta2
On Sunday, 15 July 2018 at 19:46:24 UTC, kinke wrote: * Rudimentary support for compiling & linking directly to WebAssembly. See the dedicated Wiki page [1] for how to get started. This is really awesome! I tried the examples, is there any other documentation about it currently? I tried passing strings instead of numbers to the callback, but it passes the length as a number only. I doesn't work with char pointers either, I presume that's still WIP. Still, really exciting.
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: Symmetry Autumn of Code
On Tuesday, 17 July 2018 at 17:36:12 UTC, Ecstatic Coder wrote: I'd suggest adding the following to SAOC 2018 project proposals : [snip] Things on my wishlist: Improved REPL support (esp Windows) Jupyter kernel for D (someone might be working on this) Very smooth integration between mir-ndslice and the most common data science languages: Julia, Numpy, R, Matlab/Octave (might need way to call Matlab/Octave?). Some already exists, but clear/good documentation or tutorials would be good contribution in those cases. mir project for pandas-like dataframes mir project for regression, built on mir-lapack/lubeck
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Tuesday, 17 July 2018 at 16:39:48 UTC, bachmeier wrote: On Tuesday, 17 July 2018 at 15:55:03 UTC, bachmeier wrote: On Tuesday, 17 July 2018 at 06:57:37 UTC, drug wrote: [...] I'm going to create an issue on Github. This is the output I get: [...] I solved that problem but now I have others. dpp is a good thing on paper but maybe not yet in practice. Echoing what Andrei and Walter say all the time, it's not going to get fixed without bug reports...
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: 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: 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 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: 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 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
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: Hunt framework 1.2.0 released
On Tuesday, 17 July 2018 at 11:10:07 UTC, Suliman wrote: On Tuesday, 17 July 2018 at 09:27:26 UTC, Brian wrote: Hello, hunt framework fix bugs version release. Major updates: 1. Add simplify functions 2. You can use createUrl() to create link url from module.controller.action 3. support date() / url() function for template engine 4. fix multi-domain use other port 5. use portgresql / mysql / sqlite on default config 6. upgrade dependencies package version to latest 7. release stabled skeleton project hunt-framework source code: https://github.com/huntlabs/hunt hunt-skeleton source code: https://github.com/huntlabs/hunt-skeleton Could you explain what your vision about benefits Hunt over Vibed? Vibe.d is very cool and fast network and data management library. but, we need a web framework like spring boot, django, laravel, rails. It's so easy to use, so simple to configuration and quickly for development. My team develop the Entity(Like java's JPA & PHP's doctrine2), cache(Like ehcache), Collie(Like netty), entity-repository(Like spring-data) to development people are more familiar with the hunt-framework.
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: 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.
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
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
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
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 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
[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: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ I'd suggest adding the following to SAOC 2018 project proposals : 1/ adding a Go-like http module to the standard library 2/ adding Go-like async IO management to the standard library, i.e. fibers communicating through blocking channels 3/ possibility to use automatic reference counting (with weak references) instead of garbage collection for automatic unused memory deallocation 4/ adding automatic cycle detection and collection to the automatic reference counting system (https://wiki.dlang.org/SAOC_2018_ideas) Thanks :)
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.
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=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=allintext%3A+%22this%28ref%22+site%3Agithub.com+filetype%3Ad
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: Is it feasible to slowly rewrite a C++ codebase in D?
On Tuesday, 17 July 2018 at 15:55:03 UTC, bachmeier wrote: On Tuesday, 17 July 2018 at 06:57:37 UTC, drug wrote: [...] I'm going to create an issue on Github. This is the output I get: [...] I solved that problem but now I have others. dpp is a good thing on paper but maybe not yet in practice.
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Tuesday, 17 July 2018 at 06:57:37 UTC, drug wrote: I just build it using dub then do something like that(from memory): `d++ some_c_header.h --include-path path/to/other/c/header/files --keep-d-files` and it generates d file for the corresponding c header. Although dpp is intended to be used directly I use it for generating intermediate files. First of all because when I tried to import nuklear.h dpp generated nuklear.d with simple error - due to bug it included diagnostic message of libclang into d file and it was simpler and faster to edit intermediate file manually than wait for bug fixing. I'm going to create an issue on Github. This is the output I get: $ dub build dpp Building package dpp in /home/office/.dub/packages/dpp-0.0.1/dpp/ WARNING: A deprecated branch based version specification is used for the dependency libclang. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead. Performing "debug" build using /usr/bin/dmd for x86_64. libclang ~master: target for configuration "library" is up to date. dpp 0.0.1: building configuration "executable"... .dub/packages/dpp-0.0.1/dpp/source/dpp/runtime/app.d(106,16): Warning: C preprocessor directive #define is not supported .dub/packages/dpp-0.0.1/dpp/source/dpp/cursor/typedef_.d(89,9): Error: @nogc function dpp.cursor.typedef_.isSomeFunction cannot call non-@nogc function clang.Type.pointee .dub/packages/dpp-0.0.1/dpp/source/dpp/type/package.d(176,8): Error: incompatible types for (type.pointee()) is (null): Type and typeof(null) .dub/packages/dpp-0.0.1/dpp/source/dpp/type/package.d(177,12): Error: incompatible types for (type.pointee()) !is (null): Type and typeof(null) .dub/packages/dpp-0.0.1/dpp/source/dpp/type/package.d(184,40): Error: can only * a pointer, not a Type .dub/packages/dpp-0.0.1/dpp/source/dpp/type/package.d(192,21): Error: can only * a pointer, not a Type .dub/packages/dpp-0.0.1/dpp/source/dpp/type/package.d(202,22): Error: cannot implicitly convert expression (*ptr).pointee() of type Type to const(Type)* .dub/packages/dpp-0.0.1/dpp/source/dpp/type/package.d(246,31): Error: can only * a pointer, not a Type /usr/bin/dmd failed with exit code 1.
Re: names not demangled in nm --demangle=dlang
On Tuesday, 17 July 2018 at 15:39:39 UTC, Zheng (Vic) Luo wrote: Hi, I built a simple program with dmd a.d and tried to observe symbols with nm --demangle=dlang ./a. However, I can observe that only part of the symbols (e.g., std.stdio.File.size()) are demangled, while others remain in their original name (e.g., _D3std5stdio4File8opAssignMFNfSQBdQBcQzZv). Is this a bug of nm? It probably doesn't support the new back-referencing yet. https://dlang.org/changelog/2.077.0.html#mangleBackref https://dlang.org/blog/2017/12/20/ds-newfangled-name-mangling/ Moreover, what is the suggested way to demangle symbol names in dlang? ddemangle (it should be part of your distribution or release archive)
names not demangled in nm --demangle=dlang
Hi, I built a simple program with dmd a.d and tried to observe symbols with nm --demangle=dlang ./a. However, I can observe that only part of the symbols (e.g., std.stdio.File.size()) are demangled, while others remain in their original name (e.g., _D3std5stdio4File8opAssignMFNfSQBdQBcQzZv). Is this a bug of nm? Moreover, what is the suggested way to demangle symbol names in dlang? Thanks
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: 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!
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 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 :-)
[Issue 19082] Cannot inline "...Slides.numberOfFullFrames", "...Slides.gap"
https://issues.dlang.org/show_bug.cgi?id=19082 Seb changed: What|Removed |Added Severity|enhancement |major --
[Issue 19082] Cannot inline "...Slides.numberOfFullFrames", "...Slides.gap"
https://issues.dlang.org/show_bug.cgi?id=19082 --- Comment #6 from Seb --- Oh I see. This should fix it: https://github.com/dlang/phobos/pull/6636 --
Re: Check whether a range is empty
On Tuesday, 17 July 2018 at 13:59:45 UTC, Gary Willoughby wrote:
I thought every range at the lowest level has an `empty`
property. So, in this case, it would be:
if (PFResutl.toRange.empty)
{
writeln("Empty");
}
Yeah, but it seems, that PFResutl is a range of ranges, and the
OP has the case, where both of the contained ranges are empty.
However, this does not correspond to empty of the governing range.
So
[[], []].empty is false
whereas
[[], []].joiner.empty is true.
Re: CJK problem when using console outputs
On Monday, 16 July 2018 at 18:16:45 UTC, ag0aep6g wrote:
On 07/16/2018 11:30 AM, zhani wrote:
[...]
Try this:
import std.stdio: writeln;
import std.exception: enforce;
import core.sys.windows.windows: CP_UTF8, SetConsoleOutputCP;
void main()
{
SetConsoleOutputCP(CP_UTF8).enforce;
writeln("Allo");
writeln("こんにちは");
writeln("你好");
writeln("안녕하세요");
}
thank you for reply. :-)
i removed a code that my cheated and solved it.
i still, don't know why dmd didn't support CJK by default when
write a console.
Dlang must be a world-wise for everyone.
anyway, thank you so much.
Re: Check whether a range is empty
On Friday, 13 July 2018 at 18:37:35 UTC, vino.B wrote:
Hi All,
How do i check whether a range is empty. eg.
(!PFResutl.toRange).empty. I tired the below, but it is no
printing Empty if the range is empty it just prints blank line.
if (!(!PFResutl.toRange).empty) { writeln("Empty"); }
From,
Vino.B
I thought every range at the lowest level has an `empty`
property. So, in this case, it would be:
if (PFResutl.toRange.empty)
{
writeln("Empty");
}
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: 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
[Issue 19055] [404 Not Found] std.digest.digest
https://issues.dlang.org/show_bug.cgi?id=19055 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/841ca3433340b4129dda9bb879720f3c810e93f1 Issue 19055 - [404 Not Found] std.digest.digest https://github.com/dlang/phobos/commit/ec776b77345fd69e2ff0bbff2a86219f02e25aab Merge pull request #6635 from wilzbach/fix-19055 Issue 19055 - [404 Not Found] std.digest.digest --
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: 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
[Issue 19091] __traits(compiles) and error in templated structs leads to missing symbol
https://issues.dlang.org/show_bug.cgi?id=19091 --- Comment #1 from FeepingCreature --- Note that __traits(compiles) evaluates to true?! --
[Issue 19091] New: __traits(compiles) and error in templated structs leads to missing symbol
https://issues.dlang.org/show_bug.cgi?id=19091
Issue ID: 19091
Summary: __traits(compiles) and error in templated structs
leads to missing symbol
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: default_357-l...@yahoo.de
Minimized repro:
enum compiles = __traits(compiles, Outer!());
struct Inner()
{
// Note syntax error: missing return statement. This is important?
int foo() { }
void bar() { }
}
struct Outer()
{
Inner!() field;
}
void main()
{
Outer!()().field.bar;
}
Expected:
Compiler error: missing return statement in foo
Got:
Linker error: undefined reference to test.Inner.bar()
--
[Issue 15206] [REG2.077] ICE on optimized build, tym = x1d Internal error: backend\cgxmm.c 547
https://issues.dlang.org/show_bug.cgi?id=15206 Stingertough changed: What|Removed |Added CC||wolfsp...@gmail.com --
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 7/17/18 12:04 AM, Manu wrote: But that's the point, and the key advantage of the name ;) [:nod:]
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
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/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.
[Issue 19055] [404 Not Found] std.digest.digest
https://issues.dlang.org/show_bug.cgi?id=19055 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19055] [404 Not Found] std.digest.digest
https://issues.dlang.org/show_bug.cgi?id=19055 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dlang.org https://github.com/dlang/dlang.org/commit/0f867b7e39175a5a6a3d8cdb50ed3ad9f46c9227 Fix Issue 19055 - [404 Not Found] std.digest.digest https://github.com/dlang/dlang.org/commit/e8b6f6760e3cd58e912345d5e11fea3834c44ed0 Merge pull request #2421 from wilzbach/fix-19055 Fix Issue 19055 - [404 Not Found] std.digest.digest merged-on-behalf-of: Jacob Carlborg --
[Issue 19082] Cannot inline "...Slides.numberOfFullFrames", "...Slides.gap"
https://issues.dlang.org/show_bug.cgi?id=19082 --- Comment #5 from Mitu --- (In reply to Seb from comment #4) > I'm sorry, but I can't reproduce this: > > https://run.dlang.io/is/W8BEnJ > https://run.dlang.io/is/mHxy3W > > Have you tried DustMite? You seem to have forgotten that dub release build insterts -inline. Try this: https://run.dlang.io/is/acZVMa --
Re: Check whether a range is empty
On 7/15/18 8:56 AM, vino.B wrote: On Sunday, 15 July 2018 at 12:18:27 UTC, Steven Schveighoffer wrote: On 7/15/18 7:45 AM, vino.B wrote: [...] I still don't know why you are using chain here as it equates to the identity function in this instance: https://github.com/dlang/phobos/blob/3d41721141f31059ca6e77dec2da390fad737955/std/range/package.d#L900 Hi Steve, Initially i thought the using "chain" it will merge several ranges for arrays into single range of array, but it doesn't merge into single range of array so i have removed the same from my code. Ahh, I think you want joiner: https://dlang.org/phobos/std_algorithm_iteration.html#joiner -Steve
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
[Issue 19081] Can't declare enum with UDA at statement level
https://issues.dlang.org/show_bug.cgi?id=19081 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19081] Can't declare enum with UDA at statement level
https://issues.dlang.org/show_bug.cgi?id=19081
--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd
https://github.com/dlang/dmd/commit/89639f2876a72015ef4ade085293deb55c2f459f
Fix issue 19081 - defining enum with UDA at statements level
Don't treat 'enum' as storage class if it's followed by ':', '{' or an
identifier and '{'.
https://github.com/dlang/dmd/commit/4a2805d4986ee85899abeb7903f523526603291c
Merge pull request #8492 from yshui/uda-enum
Fix issue 19081 - defining enum with UDA at statements level
--
[Issue 18991] Invalid code in std.iteration.each
https://issues.dlang.org/show_bug.cgi?id=18991 Seb changed: What|Removed |Added CC||greeen...@gmail.com --- Comment #1 from Seb --- DMD PR: https://github.com/dlang/dmd/pull/8437 --
[Issue 18720] Segfault in src/gc/impl/conservative/gc.d:1990
https://issues.dlang.org/show_bug.cgi?id=18720 Seb changed: What|Removed |Added Status|NEW |RESOLVED CC||greeen...@gmail.com Resolution|--- |FIXED --- Comment #2 from Seb --- Not reproducible anymore. --
[Issue 19055] [404 Not Found] std.digest.digest
https://issues.dlang.org/show_bug.cgi?id=19055 --- Comment #3 from Seb --- I see. Sorry I was looking at the Ddox version. This is then required: https://github.com/dlang/phobos/pull/6635 https://github.com/dlang/dlang.org/pull/2421 --
[Issue 19055] [404 Not Found] std.digest.digest
https://issues.dlang.org/show_bug.cgi?id=19055 --- Comment #2 from Nicholas Wilson --- As in on https://dlang.org/phobos/index.html The "Library overview" panel thing on the left hand side expand "std" go to digest digest. Alternately look for the link that points to https://dlang.org/phobos/std_digest_digest.html --
[Issue 18791] No VERSION file in DMD .zip distribution
https://issues.dlang.org/show_bug.cgi?id=18791 Seb changed: What|Removed |Added CC||greeen...@gmail.com --
[Issue 15119] LDC version of installer
https://issues.dlang.org/show_bug.cgi?id=15119 Seb changed: What|Removed |Added CC||greeen...@gmail.com --- Comment #3 from Seb --- The DMD installer source is here: https://github.com/dlang/installer/tree/master/windows --
[Issue 17268] Build dub with dmd version that included in the release
https://issues.dlang.org/show_bug.cgi?id=17268 Seb changed: What|Removed |Added CC||greeen...@gmail.com --- Comment #2 from Seb --- Ideally dub should be built with a stable LDC though... --
[Issue 19055] [404 Not Found] std.digest.digest
https://issues.dlang.org/show_bug.cgi?id=19055 Seb changed: What|Removed |Added CC||greeen...@gmail.com --- Comment #1 from Seb --- std.digest.digest has been deprecated for a while and isn't exposed via the menu anymore. I can't see it. Are you using the docarchives or a local copy? --
Hunt framework 1.2.0 released
Hello, hunt framework fix bugs version release. Major updates: 1. Add simplify functions 2. You can use createUrl() to create link url from module.controller.action 3. support date() / url() function for template engine 4. fix multi-domain use other port 5. use portgresql / mysql / sqlite on default config 6. upgrade dependencies package version to latest 7. release stabled skeleton project hunt-framework source code: https://github.com/huntlabs/hunt hunt-skeleton source code: https://github.com/huntlabs/hunt-skeleton
Re: Funding code-d
On Friday, 13 July 2018 at 15:05:05 UTC, Michael wrote: On Friday, 13 July 2018 at 14:20:19 UTC, Mike Parker wrote: As promised in my tweet of June 30 (and to the handful of people who emailed me), the cloud of mystery surrounding the use of the money raised for code-d and its supporting tools has now been (partially) lifted! In this post, I lay out the details of how the first $1000 will be paid out to project maintainer Jan Jurzitza, a.k.a Webfreak001, and explain what we hope to achieve with this ecosystem fundraising initiative going forward. This time around, it all came together in the background of prepping for DConf with little forethought beyond activating an Open Collective goal and then working with Jan to determine the details. Lessons were learned. Later this year, you'll see the result when we announce the next of what we hope to be an ongoing series of funding targets. In the meantime: The blog https://dlang.org/blog/2018/07/13/funding-code-d/ Reddit https://www.reddit.com/r/d_language/comments/8yka7b/funding_coded_the_d_blog/ I think this is a worthy cause for the money. I'm glad to see the D foundation looking more towards investing in these kinds of community projects, as they make up the D ecosystem that many opponents of D describe as lacking. Yeah, indeed all of my friends who tried D and were not convinced that's it's a good alternative to Go/C++/etc were pushed away by a bad support in Visual Studio Code. Even those who didn't use Visual Studio Code (most of them actually). Like being able to automatically make a foreach loop become parallel for instance. Invaluable... Keep up the good work and let's invest still more money in extending further this fantastic plugin. PS: Joking... ;)
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: Funding code-d
On Saturday, 14 July 2018 at 16:19:29 UTC, Joakim wrote: On Friday, 13 July 2018 at 14:20:19 UTC, Mike Parker wrote: As promised in my tweet of June 30 (and to the handful of people who emailed me), the cloud of mystery surrounding the use of the money raised for code-d and its supporting tools has now been (partially) lifted! In this post, I lay out the details of how the first $1000 will be paid out to project maintainer Jan Jurzitza, a.k.a Webfreak001, and explain what we hope to achieve with this ecosystem fundraising initiative going forward. This time around, it all came together in the background of prepping for DConf with little forethought beyond activating an Open Collective goal and then working with Jan to determine the details. Lessons were learned. Later this year, you'll see the result when we announce the next of what we hope to be an ongoing series of funding targets. In the meantime: The blog https://dlang.org/blog/2018/07/13/funding-code-d/ Reddit https://www.reddit.com/r/d_language/comments/8yka7b/funding_coded_the_d_blog/ Nice explication of the plan, really needed. Why github never rolled out such a bounty program for OSS and other public projects has to be one of the head-scratching moves of all time, no wonder they were about to run out of money before they sold. A good way to decide on future projects would be to let prospective donors stake money on various proposals, to see how much backing they might receive, sort of like how kickstarter and other crowdfunding sites work. +1 May I suggest the two following improvements for the next proposals : 1/ integrating a Go-like web server code inside the default library (http module, fiber and channel async IO) 2/ possibility to use automatic reference counting (with weak references and optional cycle detection) instead of garbage collection for automatic unused memory deallocation The first one to help D compete on the same grounds as Go and Crystal, and the second to make it usable in the same GC-unwanted use cases where people currently use C or C++. Probably just a silly idea, please feel free to completely ignore it... PS: Geany is also a VERY nice multi-platform IDE to develop in C++ and D on Linux, Windows and Mac, for those who still don't know it...
[Issue 19089] Compiler crash for using struct
https://issues.dlang.org/show_bug.cgi?id=19089 ag0aep6g changed: What|Removed |Added Keywords||ice CC||ag0ae...@gmail.com --
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: Is it feasible to slowly rewrite a C++ codebase in D?
16.07.2018 17:32, bachmeier пишет: On Friday, 13 July 2018 at 19:53:45 UTC, Laeeth Isharc wrote: On Wednesday, 20 June 2018 at 18:47:10 UTC, Jordi Gutiérrez Hermoso wrote: What are your ideas? If you would like to expose C function and type declarations to D, you could take a look at DPP, which allows you to just #include a C header. If you encounter a bug, please file an issue and in time we will fix it. Does not yet work for C++ except in some cases. https://github.com/atilaneves/dpp I would like to give this a try, but I don't see any instructions for installation on the Github page. I tried dub build dpp, but I got a bunch of error messages. I just build it using dub then do something like that(from memory): `d++ some_c_header.h --include-path path/to/other/c/header/files --keep-d-files` and it generates d file for the corresponding c header. Although dpp is intended to be used directly I use it for generating intermediate files. First of all because when I tried to import nuklear.h dpp generated nuklear.d with simple error - due to bug it included diagnostic message of libclang into d file and it was simpler and faster to edit intermediate file manually than wait for bug fixing.
Re: Implicit conversion of struct with methods to immutable in pure function fails
On Monday, 16 July 2018 at 13:13:53 UTC, Timoses wrote: On Monday, 16 July 2018 at 12:00:57 UTC, Simen Kjærås wrote: On Monday, 16 July 2018 at 11:43:03 UTC, Timoses wrote: Why does this fail? It doesn't. Not using DMD 2.081.1 under Windows, at least. I tried adding a bitfield since you mentioned it, but it compiles nicely for me. Which version of DMD are you using, and are you having the issues with the exact code you posted here? -- Simen https://run.dlang.io/is/Pgs527 I'm on 2.080.1. But above is on latest 2.081.1 I believe. Note that the bottom code snippet in the original post does work, while the first one does not. That makes sense. The problem is F has a context pointer to the main() block, since it's a non-static struct with methods inside a block. It doesn't actually use the context pointer for anything, so it possibly shouldn't have one, but it does, so we have to work around it. The fix is to mark F as static, or move it outside the main() block. -- Simen
[Issue 13926] Find all references
https://issues.dlang.org/show_bug.cgi?id=13926 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #1 from Rainer Schuetze --- Should be fixed in recent AppVeyor builds to the extend that was also available to Mono-D. --
