Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Thursday, 9 August 2018 at 15:56:31 UTC, w0rp wrote: On Thursday, 9 August 2018 at 10:37:36 UTC, Andrea Fontana wrote: On Thursday, 9 August 2018 at 04:10:47 UTC, Nicholas Wilson wrote: The DIP makes the claim that: * "[@noreturn] has the awkward result of a function specifying it has a return type T, but never returns that type". When it is deliberate (such as annotating a fatal error function) the is almost exclusively `void` (I know of no examples to the contrary). Let's say we need to implement an interface with a int func(); member. We can mark it with @noreturn but we can't use TBottom return type: we're going to break interface implementation. Andrea It will work, and why it will work requires some understanding of bottom types. You can define the function as `TBottom func()` and it should work, because `TBottom` is a subtype of `int`. In the same way you can implement `ParentClass func()` as `SubClass func()`, because `SubClass` is a subtype of `ParentClass`. Similarly, you can assign values of `TBottom` to `int`, because `TBottom` is a subtype of all types, but you cannot assign `int` to `TBottom`, because `int` is not a subtype of `TBottom`. is(T == int) will work with T==tbottom too? is(T:int) ? I feel that all this things are going to complicate implementation and add corner cases, but maybe I'm wrong... Andrea
Re: Give DLS a try
On Thursday, 9 August 2018 at 22:56:02 UTC, tide wrote: Yah that's what I was getting. You should possibly find another way other than symbolic links. I don't think you'll get access to admin rights unless you restart VS Code with them. No, I certainly don't need VSCode to be launched with admin rights. That would be madness... That's why I was talking about powershell, I'm launching `powershell.exe Start-Process [...] -Verb runas` to start the symlink command with admin rights. `-Verb runas` will make Windows graphically ask you to grant admin rights when launching the command, but the rest of the program will always run without privileges.
Re: Give DLS a try
On Thursday, 9 August 2018 at 13:02:47 UTC, Laurent Tréguier
wrote:
On Thursday, 9 August 2018 at 12:42:45 UTC, Domain wrote:
I just give it a try in visual studio code, but I got errors:
[Error - 20:39:54] Starting client failed
Error: Unsupported server configuration {
"command": ""
}
at _getServerWorkingDir.then.serverWorkingDir
(C:\Users\Domain-Work\.vscode\extensions\laurenttreguier.vscode-dls-1.6.3\node_modules\vscode-languageclient\lib\main.js:356:35)
at
Now that looks exactly like the bug I thought I had gotten rid
of...
The bug was that on Windows, the bootstrap program could exit
before the symbolic link to dls.exe was created, so the
extension was left without anything to launch.
Does it continue like this after reloading VSCode's window ?
Creating symlinks requires admin rights on Windows. In order to
do that I'm launching a powershell command to bring up the User
Account Control popup.
I'm no Windows expert, so on some machines it could fail due to
some strict policy about powershell execution, or simply not
having the possibility to gain admin rights.
I was thinking about working around that problem in the next
version; requiring admin rights for something like this is
obviously not really optimal.
Yah that's what I was getting. You should possibly find another
way other than symbolic links. I don't think you'll get access to
admin rights unless you restart VS Code with them.
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On 09.08.2018 05:02, Mike Parker wrote: This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type": https://github.com/dlang/DIPs/blob/8274b0f600075e4553b41c31f4b77be2d917bb40/DIPs/DIP1017.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on August 24, or when I make a post declaring it complete. At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the Final Review and Formal Assessment by the language maintainers. Please familiarize yourself with the documentation for the Community Review before participating. https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review Thanks in advance to all who participate. Copy-paste of my comment on the DIP pull request: "`Tbottom* → Tbottom` and `Tbottom[] → Tbottom` seem a bit unprincipled. I'd have rather expected to see `Tbottom* == typeof(null)` and `Tbottom[] == typeof([])`. In general, I'd advise against having special rules with regards to type construction, as special behavior like this can harm generic code." I think if we in fact want to have some sort of "bottom propagation" nonetheless, it should be expression-based, not type-based.
Re: More fun with autodecoding
On Wednesday, 8 August 2018 at 21:01:18 UTC, Steven Schveighoffer wrote: Not trying to give too much away about the library I'm writing, but the problem I'm trying to solve is parsing out tokens from a buffer. I want to delineate the whole, as well as the parts, but it's difficult to get back to the original buffer once you split and slice up the buffer using phobos functions. I wonder if there are some parallels in the tsv utilities I wrote. The tsv parser is extremely simple, byLine and splitter on a char buffer. Most of the tools just iterate the split result in order, but a couple do things like operate on a subset of fields, potentially reordered. For these a separate structure is created that maps back the to original buffer to avoid copying. Likely quite simple compared to what you are doing. The csv2tsv tool may be more interesting. Parsing is relatively simple, mostly identifying field values in the context of CSV escape syntax. It's modeled as reading an infinite stream of utf-8 characters, byte-by-byte. Occasionally the bytes forming the value need to be modified due to the escape syntax, but most of the time the characters in the original buffer remain untouched and parsing is identifying the start and end positions. The infinite stream is constructed by reading fixed size blocks from the input stream and concatenating them with joiner. This eliminates the need to worry about utf-8 characters spanning block boundaries, but it comes at a cost: either write byte-at-a-time, or make an extra copy (also byte-at-a-time). Making an extra copy is faster, that what the code does. But, as a practical matter, most of the time large blocks could often be written directly from the original input buffer. If I wanted it make it faster than current I'd do this. But I don't see an easy way to do this with phobos ranges. At minimum I'd have to be able to run code when the joiner operation hits block boundaries. And it'd also be necessary to create a mapping back to the original input buffer. Autodecoding comes into play of course. Basically, splitter on char arrays is fine, but in a number of cases it's necessary to work using ubtye to avoid the performance penalty. --Jon
Re: Give DLS a try
On Thursday, 9 August 2018 at 12:42:45 UTC, Domain wrote:
I just give it a try in visual studio code, but I got errors:
[Error - 20:39:54] Starting client failed
Error: Unsupported server configuration {
"command": ""
}
at _getServerWorkingDir.then.serverWorkingDir
(C:\Users\Domain-Work\.vscode\extensions\laurenttreguier.vscode-dls-1.6.3\node_modules\vscode-languageclient\lib\main.js:356:35)
at
Do you have ldc.exe in your PATH by any chance ? I've just
realized this can screw up everything; a patched version is on
the way.
I really don't think we can call it "stable"...
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Thursday, 9 August 2018 at 10:37:36 UTC, Andrea Fontana wrote: On Thursday, 9 August 2018 at 04:10:47 UTC, Nicholas Wilson wrote: The DIP makes the claim that: * "[@noreturn] has the awkward result of a function specifying it has a return type T, but never returns that type". When it is deliberate (such as annotating a fatal error function) the is almost exclusively `void` (I know of no examples to the contrary). Let's say we need to implement an interface with a int func(); member. We can mark it with @noreturn but we can't use TBottom return type: we're going to break interface implementation. Andrea It will work, and why it will work requires some understanding of bottom types. You can define the function as `TBottom func()` and it should work, because `TBottom` is a subtype of `int`. In the same way you can implement `ParentClass func()` as `SubClass func()`, because `SubClass` is a subtype of `ParentClass`. Similarly, you can assign values of `TBottom` to `int`, because `TBottom` is a subtype of all types, but you cannot assign `int` to `TBottom`, because `int` is not a subtype of `TBottom`.
Re: DIP 1017--Add Bottom Type--Community Review Round 1
A better name for this type is `never`, which is the name of the TypeScript type with similar semantics. https://www.typescriptlang.org/docs/handbook/basic-types.html#never `nothing` is also a decent name, used in some other languages, but `never` makes it more obvious that a function never returns, and isn't as easy to confuse with `void`, which is a different kind of nothing.
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Thursday, 9 August 2018 at 13:45:54 UTC, Stefan Koch wrote: I hope there is a better name than Tbottom. A name like that is not consistent with the rest of the language. Why not Bottom? according to the DIP, the name can be chosen arbitrarily as the type is retrieved via matching the type expression `typeof(assert(0))` Okay. That's a lot worse. A type for a function that returns nothing and has an arbitrary name.
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Thursday, 9 August 2018 at 13:56:05 UTC, Gary Willoughby wrote: perhaps this should actually be an attribute `@bottom`, or more a documenting: `@noreturn`? Yes, it should.
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Thursday, 9 August 2018 at 10:47:37 UTC, Stefan Koch wrote: There is no explanation of when the additional optimizations would be actually relevant, Usually functions that don't return abort the program anyway. Maybe total code size. OT: as for microoptimizations, what bugged me is a pattern when a method returns its first argument to enable chaining, if it returned void (or something like that) and the chained call reused the first argument of the preceding call how much that can save? But indeed introspection can be painful.
Re: Alignment of symbol is not kept during linking
On Thursday, 9 August 2018 at 13:50:00 UTC, Kagamin wrote: On Thursday, 9 August 2018 at 13:30:38 UTC, Yuxuan Shui wrote: I searched around, and there seems to be no way to specify alignment on symbol, so I don't think the linker is in the wrong here. The alignment should be specified for section. The alignment is specified for the section, and it apparently kept. problem is individual symbols in the section don't have a alignment.
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Thursday, 9 August 2018 at 13:42:57 UTC, bachmeier wrote: On Thursday, 9 August 2018 at 03:02:55 UTC, Mike Parker wrote: This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type": I hope there is a better name than Tbottom. A name like that is not consistent with the rest of the language. Why not Bottom? `bottom_t` or `never_t` are much better but perhaps this should actually be an attribute `@bottom`, or more a documenting: `@noreturn`?
Re: Alignment of symbol is not kept during linking
On Thursday, 9 August 2018 at 13:30:38 UTC, Yuxuan Shui wrote: I searched around, and there seems to be no way to specify alignment on symbol, so I don't think the linker is in the wrong here. The alignment should be specified for section.
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Thursday, 9 August 2018 at 13:42:57 UTC, bachmeier wrote: On Thursday, 9 August 2018 at 03:02:55 UTC, Mike Parker wrote: This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type": I hope there is a better name than Tbottom. A name like that is not consistent with the rest of the language. Why not Bottom? according to the DIP, the name can be chosen arbitrarily as the type is retrieved via matching the type expression `typeof(assert(0))`
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Thursday, 9 August 2018 at 03:02:55 UTC, Mike Parker wrote: This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type": I hope there is a better name than Tbottom. A name like that is not consistent with the rest of the language. Why not Bottom?
Re: Alignment of symbol is not kept during linking
Clarifications: On Thursday, 9 August 2018 at 13:30:38 UTC, Yuxuan Shui wrote: I'm trying to build LDC with dmd and Musl, but the result ldc will always crash. I track that down to an unalignment SIMD access to a global variable. Apparently C++ compiler thinks the variable should be aligned to 16 bytes, but it's only aligned to 8 bytes. SIMD is generated by the C++ compiler, the unaligned read happens in C++ code. The accessed variable is a __gshared global variable.
Alignment of symbol is not kept during linking
I'm trying to build LDC with dmd and Musl, but the result ldc will always crash. I track that down to an unalignment SIMD access to a global variable. Apparently C++ compiler thinks the variable should be aligned to 16 bytes, but it's only aligned to 8 bytes. After some more digging, I find out dmd does try to do the right thing here. In the .o file, the offending symbol is indeed aligned to 16 bytes. But, after linking, that symbol got bumped 8 bytes for some reason. I searched around, and there seems to be no way to specify alignment on symbol, so I don't think the linker is in the wrong here. C compilers would not put variables like that in .data, instead they use SHN_COMMON, and specify alignment there. LDC will just put every symbol into their own section, which also supports alignment. dmd should probably do the same.
Re: Give DLS a try
On Thursday, 9 August 2018 at 12:42:45 UTC, Domain wrote:
I just give it a try in visual studio code, but I got errors:
[Error - 20:39:54] Starting client failed
Error: Unsupported server configuration {
"command": ""
}
at _getServerWorkingDir.then.serverWorkingDir
(C:\Users\Domain-Work\.vscode\extensions\laurenttreguier.vscode-dls-1.6.3\node_modules\vscode-languageclient\lib\main.js:356:35)
at
Now that looks exactly like the bug I thought I had gotten rid
of...
The bug was that on Windows, the bootstrap program could exit
before the symbolic link to dls.exe was created, so the extension
was left without anything to launch.
Does it continue like this after reloading VSCode's window ?
Creating symlinks requires admin rights on Windows. In order to
do that I'm launching a powershell command to bring up the User
Account Control popup.
I'm no Windows expert, so on some machines it could fail due to
some strict policy about powershell execution, or simply not
having the possibility to gain admin rights.
I was thinking about working around that problem in the next
version; requiring admin rights for something like this is
obviously not really optimal.
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Thursday, 9 August 2018 at 03:02:55 UTC, Mike Parker wrote: This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type": [...] How does this DIP interact with constructors and deconstructors as they are glorified void functions? -Alexander
Re: Give DLS a try
On Thursday, 9 August 2018 at 11:48:55 UTC, Laurent Tréguier
wrote:
On Thursday, 9 August 2018 at 10:37:32 UTC, IM wrote:
I've always had issues with Code-d! I filed several issues on
its GitHub repo, but my experience with the Code-d author was
that those issues are likely to remain open and unaddressed.
Since he is a student (or at least he was some time ago, I
don't know if it's still the case), he might simply have had
little time to work on it, depending on the period of the year.
I switched to DLS and I'm much happier now. I'm glad we have
options. So thanks for the hard work and keep it up!
I'll try to keep it up :)
I just give it a try in visual studio code, but I got errors:
[Error - 20:39:54] Starting client failed
Error: Unsupported server configuration {
"command": ""
}
at _getServerWorkingDir.then.serverWorkingDir
(C:\Users\Domain-Work\.vscode\extensions\laurenttreguier.vscode-dls-1.6.3\node_modules\vscode-languageclient\lib\main.js:356:35)
at
Re: Give DLS a try
On Thursday, 9 August 2018 at 10:37:32 UTC, IM wrote: I've always had issues with Code-d! I filed several issues on its GitHub repo, but my experience with the Code-d author was that those issues are likely to remain open and unaddressed. Since he is a student (or at least he was some time ago, I don't know if it's still the case), he might simply have had little time to work on it, depending on the period of the year. I switched to DLS and I'm much happier now. I'm glad we have options. So thanks for the hard work and keep it up! I'll try to keep it up :)
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Thursday, 9 August 2018 at 10:47:37 UTC, Stefan Koch wrote: Regarding the rationale: It should be pointed out that this is a further complication of the type-system (which is already more complex than what c++ has). That does impact generic code. My own experience with generic code has show that it is very hard (practically impossible) to write correct code, (correct meaning here working as intended, when instantiation succeeds) even when using template constraints. Indeed. There is no explanation of when the additional optimizations would be actually relevant, Usually functions that don't return abort the program anyway. I presume Walter is talking about considering all branches that don't return to be cold and "outlining" them as much as possible so as to not pollute icache, which he already implemented. So I assume he's talking about propagating that information? There not even an example piece of code where the newly enabled optimizations would make an impact. The point about other system languages having this feature is actually the most substantiated one :) It was about that is was required to be competitive which I find to be a bizarre claim. But we already have this in LDC, GDC probably has something similar (whatever corresponds to __attribute__(noreturn)),and if you care about perf you are not using DMD.
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Thursday, 9 August 2018 at 03:02:55 UTC, Mike Parker wrote: This is the feedback thread for the first round of Community Review for DIP 1017, "Add Bottom Type": [ ... ] Regarding the rationale: It should be pointed out that this is a further complication of the type-system (which is already more complex than what c++ has). That does impact generic code. My own experience with generic code has show that it is very hard (practically impossible) to write correct code, (correct meaning here working as intended, when instantiation succeeds) even when using template constraints. There is no explanation of when the additional optimizations would be actually relevant, Usually functions that don't return abort the program anyway. There not even an example piece of code where the newly enabled optimizations would make an impact. The point about other system languages having this feature is actually the most substantiated one :) I could accept a rationale which is about being able to simplify and extend the applicability of CFA (control flow analysis). Though even than CFA, not really that effective when is comes to making faster code. It is however quite good at subtly breaking code :( TLDR; I would kindly recommend further expansion on the interactions with the rest of the language and implications thereof.. Regards, Stefan
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Thursday, 9 August 2018 at 04:16:45 UTC, Uknown wrote: I would like to point out that C++ does this with attributes instead[0]. If this was an attribute instead (like `@noreturn`), it would simplify interfacing with C++. It would also avoid the breaking change. [0]: eel.is/c++draft/DCL.attral.noreturn The DIP mentions that, (e.g. I also don't like the syntax "@noreturn int fun()"), but I don't understand what "other uses" of a type tBottom there are, which the DIP states are not possible in C++. Especially I want a section that explains how tBottom is different from void in such situations. For functions that don't return it's clear, but else?
Re: DIP 1017--Add Bottom Type--Community Review Round 1
On Thursday, 9 August 2018 at 04:10:47 UTC, Nicholas Wilson wrote: The DIP makes the claim that: * "[@noreturn] has the awkward result of a function specifying it has a return type T, but never returns that type". When it is deliberate (such as annotating a fatal error function) the is almost exclusively `void` (I know of no examples to the contrary). Let's say we need to implement an interface with a int func(); member. We can mark it with @noreturn but we can't use TBottom return type: we're going to break interface implementation. Andrea
Re: Give DLS a try
On Wednesday, 8 August 2018 at 20:56:51 UTC, tide wrote: On Wednesday, 8 August 2018 at 07:57:49 UTC, Laurent Tréguier wrote: [...] Code-d overcomplicates things I find though. I can't even build it, there's so many dependencies attached to it that it isn't worth looking through to even find which one is causing the build issue. Let alone there's a restriction that it can only build 32-bit. Also can't be built with LDC2 cause of the dependencies is trying to build a 64-bit binary even though the arch is set to 32-bit. It's a mess. DLS took no time at all to build, nice and simple. Just one thing is installing the extension didn't create that symbolic link for me. And the plugin just silently passes an empty path if it can't find DLS. https://github.com/LaurentTreguier/vscode-dls/blob/master/src/extension.ts#L20 I've always had issues with Code-d! I filed several issues on its GitHub repo, but my experience with the Code-d author was that those issues are likely to remain open and unaddressed. I switched to DLS and I'm much happier now. I'm glad we have options. So thanks for the hard work and keep it up!
Re: Give DLS a try
On Wednesday, 8 August 2018 at 07:25:57 UTC, Tab wrote: I find DLS [1] to be very stable, updated more often [2], and it just works without issues (vs. Code-d) ~~ at least for me. I think we should give it a chance. I agree. I created a long list of features [3] I'd like to see in D IDE. Hopefully some of them is being worked on. A list of features posted on wrong project page :) Right link: https://github.com/LaurentTreguier/dls/ Andrea
Re: Give DLS a try
On Wednesday, 8 August 2018 at 20:56:51 UTC, tide wrote: DLS took no time at all to build, nice and simple. The only thing built is a small bootstrap program that downloads a prebuilt binary release, that's why it's fast. Before v0.5.0, DLS was always compiled, and that took some time, as well as 3 GB of your RAM... Just one thing is installing the extension didn't create that symbolic link for me. And the plugin just silently passes an empty path if it can't find DLS. https://github.com/LaurentTreguier/vscode-dls/blob/master/src/extension.ts#L20 That's weird. What OS are you using ? There was a bug at some point with symlink creation on Windows, but it should be fixed now. For some reason it takes a crazy amount of time instead now, 30 seconds for a simple symlink... If you have more info about this, you can always post an issue: https://github.com/LaurentTreguier/dls/issues
