Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On Wednesday, 11 April 2018 at 20:45:15 UTC, Dmitry Olshansky wrote: * Templates kind of muddy the waters being conpiled with the flags of caller (another reason why they are a mess). Meaning they will work with contracts if caller choses to have debug build. Template can call user code, but it wasn't tested for it, so the contract should be checked.
Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On Wed, Apr 11, 2018 at 08:45:15PM +, Dmitry Olshansky via Digitalmars-d-announce wrote: [...] > What would have made contract trully powerful for me is them being > emitted at caller side. This way if I use a release build of library > but debugging my app I still get my stupidity guarded by contracts of > the API. * [...] I say this should be the next step. We should write up a DIP for this. T -- Creativity is not an excuse for sloppiness.
PixelPerfectEngine v0.9.4-alpha.2
https://github.com/ZILtoid1991/pixelperfectengine/releases/tag/v0.9.4-alpha.2 The editor is almost usable (still needs a way to import tiles from its own proprietary format), and now has a working, although still a bit slow and unstable transformable tile layer with mode7-esque capabilities.
Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On Friday, 6 April 2018 at 12:26:36 UTC, Mike Parker wrote: Congratulations to Zach Tollen and everyone who worked on DIP 1009. It took a painful amount of time to get it through the process, but it had finally come out of the other side with an approval. The proposal itself was approved early on, but it needed quite a bit of revision to get to an acceptable final draft. The DIP in its final form: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1009.md What would have made contract trully powerful for me is them being emitted at caller side. This way if I use a release build of library but debugging my app I still get my stupidity guarded by contracts of the API. * Now *that* would be marvelous. Otherwise having a debug build for each of libraries just to check my precondition is too much of drag I’d say. After all libraries are typically stable code that are (presumably) debugged and you want them to be fast. * Templates kind of muddy the waters being conpiled with the flags of caller (another reason why they are a mess). Meaning they will work with contracts if caller choses to have debug build.
Re: #include C headers in D code
On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis wrote: It's one thing for someone who is familiar with D to weigh the options and decide that being tied to ldc is okay. It's quite another to tell someone who isn't familiar with D that in order to use D, they have to use a feature which only works with a specific compiler that is not the reference compiler and which will likely never work with the reference compiler. I'd say, you can focus on negative aspects if the auditory will analyze them, but it's a bad strategy if you only want to overcome prejudice.
Re: #include C headers in D code
On Wednesday, 11 April 2018 at 12:22:56 UTC, bachmeier wrote: It also wouldn't work with GDC. Given that GDC has been added to GCC, it would be a bad idea to tell people they need to use LDC to work with C code. Currently porting a project to linux, stuff is so severely outdated, pretty much no dependency was satisfied by the distro, in wich case for D it would be better to install ldc just to not touch gdc :) Granted, it's only a problem for active projects, but what projects are inactive?
Re: Release: nanovega.d rendering lib like html5 canvas
11.04.2018 21:13, Adam D. Ruppe пишет: On Wednesday, 11 April 2018 at 17:26:19 UTC, drug wrote: That's it - https://github.com/drug007/nanogui/tree/interacting_with_checkbox So MouseEvent is sent on mouse motion too, and redrawing on each motion might back up the queue. Otherwise, nothing obvious jumps out at me so I might have to take a closer look later. Yes, the reason was spamming events like a crazy, fixed.
Re: #include C headers in D code
On 4/11/2018 3:25 AM, Atila Neves wrote: I did the best I could having seen some macros. It's likely there are cases I've missed, or that maybe the translation in the link above doesn't work even for what it's supposed to be doing (I have no confidence about catching all the C casts for instance). If there are other cases, I'll fix them as they're encountered. It's possible some of them can't be fixed and the user will have to work around them. Right now I have a feeling it will probably be ok. Time will tell (assuming I have users!). That's right. There is no general solution. One can only look for common patterns and do those. For example, #define X 15 is a common pattern and can be reliably rewritten as: enum X = 15;
Re: Release: nanovega.d rendering lib like html5 canvas
On Wednesday, 11 April 2018 at 17:26:19 UTC, drug wrote: That's it - https://github.com/drug007/nanogui/tree/interacting_with_checkbox So MouseEvent is sent on mouse motion too, and redrawing on each motion might back up the queue. Otherwise, nothing obvious jumps out at me so I might have to take a closer look later.
Re: Release: nanovega.d rendering lib like html5 canvas
11.04.2018 16:59, Adam D. Ruppe пишет: On Saturday, 7 April 2018 at 09:13:06 UTC, drug wrote: https://github.com/drug007/nanogui I would be glad if you take a look Do you have a complete example I can just compile and run to get started? That's it - https://github.com/drug007/nanogui/tree/interacting_with_checkbox Window, Label and Checkbox example + dragging (you can move Window) But it lags, so definitely I use arsd.simpledisplay in a wrong way.
Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On Wednesday, 11 April 2018 at 16:16:33 UTC, Jonathan M Davis
wrote:
If we actually end up with a language improvement that makes it
so that contracts are compiled in based on the caller instead
of the callee, then I'll start using contracts. Until then, I'm
not generally going to bother.
My first proposal suggested allowing the contracts at the top of
the function body. If you mixed that idea with what H.S. Teoh
later proposed, the result would have looked like:
int fun(int a) {
in(a >= 0);
out(r; r > 0);
...
}
It's not much different from if you did:
int fun(int a) {
assert(a >= 0);
typeof(return) result;
scope(success) assert(result > 0);
...use `result`...
}
For anyone who wants even more convenience in how to write
contracts this idea would still possible to add, although it's
probably not that important.
But that idea received criticism on principle, that contracts are
part of the signature and not the body. I didn't much care about
the criticism myself, because I just wanted the contracts to be
as ergonomic as possible so that people would use them. They
seemed like a feature of D whose syntax was not up to the same
standards as the rest of D, whose syntax otherwise is a major
selling point.
However, eventually I was convinced that the accepted proposal is
better precisely because of the possibility of a future
implementation where the caller checks rather than the callee. In
this case the contracts *must* be in the signature, because the
body could be missing altogether. So basically, I agree with H.S.
Teoh. A future DIP which allows caller-side checking will be all
about the implementation, rather than about the syntax, and may
or may not face opposition precisely for that reason, I don't
know. From the user's point of view it amounts to nothing more
than being able to use contracts in more places, i.e. in
precompiled code, and with better error messages that fault the
caller instead of the callee. I don't feel technically qualified
to write that DIP, but I'm glad that the current DIP is designed
with that one in mind.
Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On Wednesday, April 11, 2018 07:47:14 H. S. Teoh via Digitalmars-d-announce wrote: > On Tue, Apr 10, 2018 at 11:43:00PM -0600, Jonathan M Davis via > Digitalmars-d-announce wrote: [...] > > > IMHO, for contracts to be worth much outside of the inheritance case, > > we'd need to do something like make it so that contracts are compiled > > in based on whether the caller used -release or not rather than > > whether the callee did. > > This is what should have been done in the first place, and I'd argue > that this is the direction we should be going in. The current > implementation of contracts greatly diminish their value, though > personally I'd still use them because they convey intent better than > just sticking a bunch of asserts at the top of the function body. > > > If that were done, then there would be real value in using contracts, > > and I'd be a lot more excited about the new syntax. As it is, it seems > > like a nice improvement that's ultimately pointless. > > [...] > > I consider this as a first step in improving DbC support in D. The next > step is to make it so that in-contracts are enforced on the caller's > side rather than the callee's side. IIRC, the original version of this > DIP included something to this effect, but it was eventually taken off > in order to stay more focused in scope so that the chances of acceptance > would be higher. But I hope that eventually a future DIP would address > this more fundamental and important issue. If we actually end up with a language improvement that makes it so that contracts are compiled in based on the caller instead of the callee, then I'll start using contracts. Until then, I'm not generally going to bother. And that reminds me, I was considering putting together a DIP to fix the situation with invariants and void initialization. Thanks to the fact that opAssign checks the state of the object prior to assigning it, you basically can't use invariants with anything that you would void initialize, which means that I basically never use invariants, and unlike in and out contracts, invariants are actually a huge boon when they're appropriate, since they insert checks with _every_ public function call, which would be a royal pain to do by hand. Because of this issue, I'd previously argued that opAssign should not check the state of the object before assigning it, but Walter rejected that, and in rare cases, you actually do care about the state of the object before assigning it, so that makes some sense, but it's a huge problem when void initialization gets involved. So, I was thinking that maybe we should have a way to indicate at the call site that an assignment should not call the invariant prior to calling opAssign in that specific case. But I haven't gotten much past that in figuring it out, since it's not all that high on my priority list. It's really annoying if you use invariants, but my solution has been to just not use them, so it's a problem but not one that actively gets in my way at the moment. It's just that I then lose out on invariants. :| - Jonathan M Davis
Re: #include C headers in D code
On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote: Here's my blog post about my project that allows directly #including C headers in D* https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/ Cannot manage to build it on Windows: D:\git\dpp>dub build 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 dmd for x86. libclang ~master: target for configuration "library" is up to date. dpp 0.0.1+commit.41.g60f98e4: building configuration "executable"... Linking... OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html OPTLINK : Warning 183: Extension not .RES : clang.lib C:\Users\[]\AppData\Roaming\dub\packages\libclang-master\libclang\.dub\build\library-debug-windows-x86-dmd_2079-78261F5A299D700FEEC2C0E7B51191C1\libclang.lib(1) : Error 52: .DEF Syntax Error D:\git\dpp>dub build --arch=x86_64 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 dmd for x86_64. libclang ~master: target for configuration "library" is up to date. dpp 0.0.1+commit.41.g60f98e4: building configuration "executable"... Linking... LINK : fatal error LNK1104: cannot open file 'clang.lib' Error: linker exited with status 1104 dmd failed with exit code 1.
Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On Wed, Apr 11, 2018 at 05:23:58AM +, really? via Digitalmars-d-announce
wrote:
> On Friday, 6 April 2018 at 17:36:20 UTC, H. S. Teoh wrote:
> >
> > Yeah, I think having expression syntax will make contracts more
> > readable. We'll just have to see.
> >
>
> Sorry, but I fail to see how (1) is more readable than (2)
>
> (1)
> in(s.length > 0, "s must not be empty")
>
> (2)
> in { assert(s.length > 0, "s must not be empty"); }
>
>
> In (1) The assert .. is removed.
> In (1) The scope indicators {} .. are removed.
> In (1) The semicolon..is removed.
>
> Removing all these things equates to being more readable??
>
> Sure, it makes it more concise, but more readable??
Yes, because it removes unnecessary syntactical noise from the line. All
of that verbose baggage -- braces, "assert", semicolons, is just
needless syntactic boilerplate that's repeated verbatim every single
time you write a contract, and all for what? Just to express a contract
consisting of a single, simple expression.
Besides, the `keyword(expression)` syntax has precedence in signature
constraints:
auto myFunc(Args)(Args...)
if (Args.length == 2) // <---
...
So now to add a contract:
auto myFunc(Args)(Args...)
if (Args.length == 2)
in (Args[0] < 100) // consistent with sig constraint syntax
...
> I assert that it does not. But now..do I use the assert keyword.. or
> not? Do I end with semicolon..or not??
>
> This just removes things that are still needed elsewhere in your code,
> but now... you have to remember that sometimes you need those things,
> and sometimes you don't.
[...]
It's no different from needing to "remember" that the condition of an
if-statement does not require {} and semicolons. According to your
logic, for consistency's sake we should start writing if-statements like
this instead:
if {
assert(myCondition == true);
assert(myOtherCondition == false);
} then {
...
}
I wouldn't say it's less readable, but again, needless boilerplate. If
you love so much boilerplate, perhaps Java may be a better language for
you.
T
--
Lottery: tax on the stupid. -- Slashdotter
Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On Tue, Apr 10, 2018 at 11:43:00PM -0600, Jonathan M Davis via Digitalmars-d-announce wrote: [...] > IMHO, for contracts to be worth much outside of the inheritance case, > we'd need to do something like make it so that contracts are compiled > in based on whether the caller used -release or not rather than > whether the callee did. This is what should have been done in the first place, and I'd argue that this is the direction we should be going in. The current implementation of contracts greatly diminish their value, though personally I'd still use them because they convey intent better than just sticking a bunch of asserts at the top of the function body. > If that were done, then there would be real value in using contracts, > and I'd be a lot more excited about the new syntax. As it is, it seems > like a nice improvement that's ultimately pointless. [...] I consider this as a first step in improving DbC support in D. The next step is to make it so that in-contracts are enforced on the caller's side rather than the callee's side. IIRC, the original version of this DIP included something to this effect, but it was eventually taken off in order to stay more focused in scope so that the chances of acceptance would be higher. But I hope that eventually a future DIP would address this more fundamental and important issue. T -- Shin: (n.) A device for finding furniture in the dark.
Re: #include C headers in D code
On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote: Here's my blog post about my project that allows directly #including C headers in D* I don't know the exact details of your project but can't you just: 1. Copy the includes 2. Paste them into a C file 3. Run DStep on the C file 4. Replace the includes in the first file with the result from DStep This would require changing DStep to always return `false` here [1]. Or perhaps run the preprocessor to expand the includes and then run DStep. [1] https://github.com/jacob-carlborg/dstep/blob/master/dstep/translator/Translator.d#L326 -- /Jacob Carlborg
Re: #include C headers in D code
On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote: Here's my blog post about my project that allows directly #including C headers in D* BTW, you can steal the config script [1] from DStep to help detect locations of LLVM/libclang. It also supports static linking. Supports manually specifying the path to LLVM if needed. [1] https://github.com/jacob-carlborg/dstep/blob/master/configure.d -- /Jacob Carlborg
Re: Release: nanovega.d rendering lib like html5 canvas
11.04.2018 16:59, Adam D. Ruppe пишет: Do you have a complete example I can just compile and run to get started? Yes, but it needs to be pushed. I've ported Window, Widget, Label and Checkbox (may be something else) and interacting by means of mouse (clicking, motion and dragging). But it has lags and I need your advice. I'll push it in 4-5 hours.
Re: [OT] gdc status
AFAIK, GDC does not make it, so hopefully it will be merge with gcc 9 On Wed, Apr 11, 2018 at 3:44 PM, drug via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > 11.04.2018 16:26, Uknown пишет: > > On Wednesday, 11 April 2018 at 13:17:23 UTC, drug wrote: >> >>> 11.04.2018 15:22, bachmeier пишет: >>> On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis wrote: ... Given that GDC has been added to GCC... >>> Is it true? I don't see anything like that here >>> https://gcc.gnu.org/gcc-8/changes.html >>> >> >> Here's relevant news from Phoronix: >> >> https://www.phoronix.com/scan.php?page=news_item&px=D-Frontend-For-GCC >> >> Here's the relevant announcement: >> https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html >> > I've read it. Unfortunately it doesn't answer my question. I've heard > there were some problems. >
Re: Release: nanovega.d rendering lib like html5 canvas
11.04.2018 16:30, bauss пишет: The documentation should probably be updated to match ddoc. Sure, of course, but it has low priority now. It is just proof of concept. First of all I'm interested in estimation of changes I've made. For example I'm trying to keep const qualifier as most as possible and either I use passing by value (most of all) or change api to allow using const qualifier on D side too (in fact one time). Is it worth effort, has it some caveats?
Re: Release: nanovega.d rendering lib like html5 canvas
On Saturday, 7 April 2018 at 09:13:06 UTC, drug wrote: https://github.com/drug007/nanogui I would be glad if you take a look Do you have a complete example I can just compile and run to get started?
Re: [OT] gdc status
11.04.2018 16:26, Uknown пишет: On Wednesday, 11 April 2018 at 13:17:23 UTC, drug wrote: 11.04.2018 15:22, bachmeier пишет: On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis wrote: ... Given that GDC has been added to GCC... Is it true? I don't see anything like that here https://gcc.gnu.org/gcc-8/changes.html Here's relevant news from Phoronix: https://www.phoronix.com/scan.php?page=news_item&px=D-Frontend-For-GCC Here's the relevant announcement: https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html I've read it. Unfortunately it doesn't answer my question. I've heard there were some problems.
Re: Release: nanovega.d rendering lib like html5 canvas
On Saturday, 7 April 2018 at 09:13:06 UTC, drug wrote: https://github.com/drug007/nanogui I would be glad if you take a look The documentation should probably be updated to match ddoc.
Re: [OT] gdc status
On Wednesday, 11 April 2018 at 13:17:23 UTC, drug wrote: 11.04.2018 15:22, bachmeier пишет: On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis wrote: ... Given that GDC has been added to GCC... Is it true? I don't see anything like that here https://gcc.gnu.org/gcc-8/changes.html Here's relevant news from Phoronix: https://www.phoronix.com/scan.php?page=news_item&px=D-Frontend-For-GCC Here's the relevant announcement: https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html
[OT] gdc status
11.04.2018 15:22, bachmeier пишет: On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis wrote: ... Given that GDC has been added to GCC... Is it true? I don't see anything like that here https://gcc.gnu.org/gcc-8/changes.html
Re: #include C headers in D code
On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis wrote: It's one thing for someone who is familiar with D to weigh the options and decide that being tied to ldc is okay. It's quite another to tell someone who isn't familiar with D that in order to use D, they have to use a feature which only works with a specific compiler that is not the reference compiler and which will likely never work with the reference compiler. It also wouldn't work with GDC. Given that GDC has been added to GCC, it would be a bad idea to tell people they need to use LDC to work with C code.
Re: code-d 0.17.0 + serve-d 0.1.2
On Tuesday, 10 April 2018 at 14:00:49 UTC, WebFreak001 wrote: What about workspaces? Multi workspaces in vscode aren't implemented yet though. By multi workspaces, do you mean a multi-root workspace ? If so, multi-roots arrived with LSP 3.6.0 / vscode-languageclient 3.4.0 (if you meant something else then nevermind this comment)
Re: #include C headers in D code
On Wednesday, 11 April 2018 at 06:24:38 UTC, Jacob Carlborg wrote: On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote: Here's my blog post about my project that allows directly #including C headers in D* https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/ How do you deal with macros containing invalid D code, i.e. `#define foo(T) sizeof(T)`? https://github.com/atilaneves/dpp/issues/22 https://github.com/atilaneves/dpp/blob/60f98e4fee2fac0117ac430216ef9c5c25c511fe/tests/issues.d#L229 https://github.com/atilaneves/dpp/blob/60f98e4fee2fac0117ac430216ef9c5c25c511fe/source/dpp/cursor/macro_.d#L55 I did the best I could having seen some macros. It's likely there are cases I've missed, or that maybe the translation in the link above doesn't work even for what it's supposed to be doing (I have no confidence about catching all the C casts for instance). If there are other cases, I'll fix them as they're encountered. It's possible some of them can't be fixed and the user will have to work around them. Right now I have a feeling it will probably be ok. Time will tell (assuming I have users!).
Re: #include C headers in D code
On Wednesday, 11 April 2018 at 06:21:47 UTC, Jacob Carlborg wrote: On Tuesday, 10 April 2018 at 23:44:46 UTC, Atila Neves wrote: The beauty of using libclang is that name mangling issues don't exist. :) How is that not going to be an issue? Are you adding `pragma(mangle)` everywhere? Yes. I don't know how to deal with class templates yet though, since none of their member functions have mangled symbols until they're instantiated. Which obviously doesn't happen at the declaration.
Re: #include C headers in D code
On Wednesday, 11 April 2018 at 06:12:49 UTC, rikki cattermole
wrote:
On 09/04/2018 11:03 PM, Atila Neves wrote:
Here's my blog post about my project that allows directly
#including C headers in D*
https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/
The summary is that, modulo bugs, things like this work:
#include
void main() { printf("Hello world\n".ptr); }
So far it's successfully compiled whilst #including pthread,
libcurl, openssl and others. The blog and the github README
have more information, and feel free to reply to this with
questions.
dub: http://code.dlang.org/packages/dpp
reddit:
https://www.reddit.com/r/programming/comments/8axj53/include_c_headers_in_d_code/
hacker news: It's in there somewhere, search around.
Atila
* Technically, "D + #include directives + C macros"
Any chance objectice-c as well?
I don't know Objective-C. The only way I can think of to even get
close to getting it to work is by copying the relevant tests from
dstep. I also don't think the language is nearly as important as
C and C++ in terms of fostering D adoption.
So probably no unless someone sends PRs my way.
Re: #include C headers in D code
On Wednesday, April 11, 2018 09:23:29 Kagamin via Digitalmars-d-announce wrote: > On Monday, 9 April 2018 at 19:36:23 UTC, Atila Neves wrote: > > If you add to all that "No, really, it's ok, there's this > > project that forked one of the compilers. No, it's not the > > reference compiler. There's just this bit of non-standard > > syntax to learn that's neither C nor D", then the chances of > > convincing any "normal" engineer are 0. > > It is the reference compiler though (which is the frontend), the > backend is different, but they don't want the dmc backend do > they? Also recently it started to use pragma and import syntax, > which are both D. Yes, the frontend is shared, but you don't just use the frontend. You use the whole compiler. dmd is the reference compiler and what your average programmer coming to D is going to expect to be using (at least initially). And telling folks that they have to use a language feature that is not supported by the reference compiler is not going to go over well with a lot of people. It would be one thing to tell them that they should use ldc, because it generates faster code. That doesn't involve forking the language. Your code would then still work just fine with dmd. It would just be slower. It's quite another thing to tell them to use a feature that dmd doesn't support. That _would_ be forking the language, and it would mean writing programs that would not work with the reference compiler. Many folks are not going to be happy with the idea of using a fork rather than the real deal. Some folks will probably be fine with it, but in general, it just plain looks bad. It's one thing for someone who is familiar with D to weigh the options and decide that being tied to ldc is okay. It's quite another to tell someone who isn't familiar with D that in order to use D, they have to use a feature which only works with a specific compiler that is not the reference compiler and which will likely never work with the reference compiler. - Jonathan M Davis
Re: #include C headers in D code
On Monday, 9 April 2018 at 19:36:23 UTC, Atila Neves wrote: If you add to all that "No, really, it's ok, there's this project that forked one of the compilers. No, it's not the reference compiler. There's just this bit of non-standard syntax to learn that's neither C nor D", then the chances of convincing any "normal" engineer are 0. It is the reference compiler though (which is the frontend), the backend is different, but they don't want the dmc backend do they? Also recently it started to use pragma and import syntax, which are both D.
