Cheap Kitchens Sale UK
Cheap Kitchens Sale UK. Thirty Ex Display Kitchens To Clear. www.exdisplaykitchens1.co.uk £ 595 Each with appliances.Tel 01616-694785 [URL=http://www.uk-affordablekitchens.co.uk]Cheap Kitchens Sale UK[/URL]
Re: Program logic bugs vs input/environmental errors
On 2014-10-15 16:25, Dicebot wrote: How can one continue without recovering? This will result in any kind of environment not being cleaned and false failures of other tests that share it. I will probably use something else than "assert" in my unit tests. Something like assertEq, assertNotEq and so on. It's more flexible, can give better error message and I can have it throw an exception instead of an error. But there's still the problem with asserts in contracts and other parts of the code. -- /Jacob Carlborg
Re: So what exactly is coming with extended C++ support?
On 2014-10-15 19:31, Andrei Alexandrescu wrote: C++11 includes C++03. -- Andrei I kind of only read the C++11 part. -- /Jacob Carlborg
Re: Mathematical rounding
On Thursday, 16 October 2014 at 03:11:57 UTC, Elena wrote: Hi,every one! How can I realize mathematical rounding (not banking) for Never used it, but: http://dlang.org/library/std/math/FloatingPointControl.html phobos/math.d lists the enums: roundToNearest, roundDown, roundUp, roundToZero
Re: So what exactly is coming with extended C++ support?
On Thursday, 16 October 2014 at 03:53:53 UTC, Daniel N wrote: There's no impact, we already support it since the template is instantiated from C++ side. But you don't know the return type of the templated function until you know which combination of templates it instantiated?
Re: Mathematical rounding
On 10/15/14, 8:11 PM, Elena wrote: Hi,every one! How can I realize mathematical rounding (not banking) for Double in D 0.4 -> 0 0.5 -> 1 1.5 -> 2 2.5 -> 3 3.5 -> 4 ? Thank you. Add 0.5 and then cast to integral. -- Andrei
Re: So what exactly is coming with extended C++ support?
On Wednesday, 15 October 2014 at 18:06:18 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 15 October 2014 at 17:38:46 UTC, Paulo Pinto wrote: I imagine you meant C++17. C++14 is already ratified. Yes, sorry, I meant that it is close enough for consideration as a draft. So discussing the effects of it on D's C++ support is now possible? There's no impact, we already support it since the template is instantiated from C++ side.
Mathematical rounding
Hi,every one! How can I realize mathematical rounding (not banking) for Double in D 0.4 -> 0 0.5 -> 1 1.5 -> 2 2.5 -> 3 3.5 -> 4 ? Thank you.
Re: Program logic bugs vs input/environmental errors
On Wednesday, 15 October 2014 at 03:18:31 UTC, Walter Bright wrote: However, the compiler is still going to regard the assert() as nothrow, so the unwinding from an Exception won't happen until up stack a throwing function is encountered. I hate to say it, but I'm inclined to treat nothrow the same as in C++, which is to basically pretend it's not a part of the language. The efficiency is nice, but not if it means that throwing an Error will cause the program to be invalid. Please tell me there's no plan to change the unwinding behavior when Error is thrown in standard (ie not nothrow) code. I touched on all this in my "on errors" thread that seems to have died. I suppose I could write a DIP but I was hoping for discussion.
Re: [OT] Ada gems
On Wednesday, 15 October 2014 at 21:29:23 UTC, Paulo Pinto wrote: Who needs stars when working on an enterprise budget? :) Yeah, these metrics are skewed, but it is interesting to see what kind of projects people get excited about in different languages. I didn't expect Go to do so well on github. I found that surprising. Besides, Ada never was an hobbyist language. Only after GNAT Core decided to release their compiler as GPL, universities decided to pay attention. Ada is "industrial", and comes through as a bit syntax heavy for casual use. Still, the feature set appears to fit well together when reading about it. Go on the other hand comes through as a bit arcane and the defer/panic/recover error handling is kind of weird and the syntax for it does not indicate that it is about errors. Which I think is important to make distinct. So I have trouble liking Go when browsing Go code for the same reason I'd never want to do anything large in C. Then again, it took a while for me to get used to C-style braces after being used to languages like Pascal. So maybe it grows on you… (doubt it). Not that I like regular try/catch exceptions either. A more efficient "transactional" approach to error-handling seems more attractive. A solution where you don't sprinkle error-handling code all over your codebase. It probably requires high-level language support if you want to avoid the extra noise that "plague" current error handling solutions… :-/
Re: [OT] Ada gems
Am 15.10.2014 um 23:13 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ": On Wednesday, 15 October 2014 at 20:48:21 UTC, ketmar via Digitalmars-d wrote: Ada projects have no stars... Who needs stars when working on an enterprise budget? :) Besides, Ada never was an hobbyist language. Only after GNAT Core decided to release their compiler as GPL, universities decided to pay attention. -- Paulo
Re: [OT] Ada gems
On Wednesday, 15 October 2014 at 20:48:21 UTC, ketmar via Digitalmars-d wrote: so, c++ is most complicated language, and D is so easy and nice that people don't even asking questions. Yeah, top stars on github this month for D: libasync: 22 stars vibe.d: 15 phobos: 10 druntime: 8 dash: 9 For Go: pup: 1243 stars inspeqtor: 856 docker: 743 gopherjs: 659 syncthing: 584 For C++: cool-retro-term: 999 stars node-webkit: 690 CppCon2014: 615 cling: 512 ricochet: 498 On github Go appears to be on the same number of stars as C++ and Python… so I guess this could mean it is popular among hobbyists. Ada projects have no stars...
Re: [OT] Ada gems
On Wed, 15 Oct 2014 20:37:19 + via Digitalmars-d wrote: > Just for fun, some D tag stats from Stackoverflow for the last > week: > > C++: 2080 this week > Go: 96 this week > Rust: 58 this week > D: 25 this month > > Or (roughly): > > C++: 357x more questions > Go: 16x > Rust: 10x so, c++ is most complicated language, and D is so easy and nice that people don't even asking questions. signature.asc Description: PGP signature
Re: [OT] Ada gems
Just for fun, some D tag stats from Stackoverflow for the last week: C++: 2080 this week Go: 96 this week Rust: 58 this week D: 25 this month Or (roughly): C++: 357x more questions Go: 16x Rust: 10x
Re: [OT] Ada gems
Am 15.10.2014 um 22:00 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ": On Wednesday, 15 October 2014 at 18:50:21 UTC, Paulo Pinto wrote: This is C++, I am speaking about C. C++ is part of my "there are better alternatives" list. Scott Meyers pointed out that C is the most popular open source language still (which probably is true if you count lines of code), and that the popularity of C is important for the popularity of C++ today. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html Ah ok. Yes, I do have to agree. However that is mostly caused by the animosity in open source world against C++. I can still remember how it was to be on Gtkmm vs Gtk. -- Paulo
Re: [OT] Ada gems
On Wednesday, 15 October 2014 at 18:50:21 UTC, Paulo Pinto wrote: This is C++, I am speaking about C. C++ is part of my "there are better alternatives" list. Scott Meyers pointed out that C is the most popular open source language still (which probably is true if you count lines of code), and that the popularity of C is important for the popularity of C++ today. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Re: [OT] Ada gems
Am 15.10.2014 um 20:29 schrieb eles: On Wednesday, 15 October 2014 at 18:15:10 UTC, Paulo Pinto wrote: Am 15.10.2014 um 19:41 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ": On Wednesday, 15 October 2014 at 17:10:52 UTC, Paulo Pinto wrote: I saw that roadmap. It is also the confirmation that they won't ever add generics. So I guess, a better C it is. It isn't all that great at the C-stuff, Go is no system level language IMO. I look at Go and see Oberon, hence my remark. Even if that isn't the case, the only thing C is good at currently is embedded devices low on RAM, device drivers and being a portable assembler. For everything else, there are better alternatives. Still.. https://www.youtube.com/watch?v=ltCgzYcpFUI Scott Meyers talk This is C++, I am speaking about C. C++ is part of my "there are better alternatives" list. -- Paulo
Re: [OT] Ada gems
On Wednesday, 15 October 2014 at 18:15:10 UTC, Paulo Pinto wrote: Even if that isn't the case, the only thing C is good at currently is embedded devices low on RAM, device drivers and being a portable assembler. For everything else, there are better alternatives. Portable libraries. It is a stable design that most languages can interface with, so you can generally not go wrong by writing libraries in C. It is a pity that some cool libraries are C++ only (like 3D physics), but maybe automatic source-to-source translation can do well sometime in the future.
Re: [OT] Ada gems
On Wednesday, 15 October 2014 at 18:15:10 UTC, Paulo Pinto wrote: Am 15.10.2014 um 19:41 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ": On Wednesday, 15 October 2014 at 17:10:52 UTC, Paulo Pinto wrote: I saw that roadmap. It is also the confirmation that they won't ever add generics. So I guess, a better C it is. It isn't all that great at the C-stuff, Go is no system level language IMO. I look at Go and see Oberon, hence my remark. Even if that isn't the case, the only thing C is good at currently is embedded devices low on RAM, device drivers and being a portable assembler. For everything else, there are better alternatives. Still.. https://www.youtube.com/watch?v=ltCgzYcpFUI Scott Meyers talk
Re: [OT] Ada gems
On Wed, 15 Oct 2014 20:15:11 +0200 Paulo Pinto via Digitalmars-d wrote: > Even if that isn't the case, the only thing C is good at currently is > embedded devices low on RAM, device drivers and being a portable > assembler. and it sux as portable assembler. signature.asc Description: PGP signature
Re: [OT] Ada gems
Am 15.10.2014 um 19:41 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ": On Wednesday, 15 October 2014 at 17:10:52 UTC, Paulo Pinto wrote: I saw that roadmap. It is also the confirmation that they won't ever add generics. So I guess, a better C it is. It isn't all that great at the C-stuff, Go is no system level language IMO. I look at Go and see Oberon, hence my remark. Even if that isn't the case, the only thing C is good at currently is embedded devices low on RAM, device drivers and being a portable assembler. For everything else, there are better alternatives. -- Paulo
Re: So what exactly is coming with extended C++ support?
On Wednesday, 15 October 2014 at 17:38:46 UTC, Paulo Pinto wrote: I imagine you meant C++17. C++14 is already ratified. Yes, sorry, I meant that it is close enough for consideration as a draft. So discussing the effects of it on D's C++ support is now possible?
Re: [OT] Ada gems
On Wednesday, 15 October 2014 at 17:10:52 UTC, Paulo Pinto wrote: I saw that roadmap. It is also the confirmation that they won't ever add generics. So I guess, a better C it is. It isn't all that great at the C-stuff, Go is no system level language IMO. But templates can always be added later. If Google manage to get a solid GC based runtime up, one might write a new front end for it. Just like people write new languages for JVM. (but it is still a big "if") They just got a victory today, as Microsoft is now bringing Docker to Windows, which uses Go quite heavily. Docker is a nice idea. Not sure where Microsoft is going with it, but they probably go for this to make Azure competitive.
Re: So what exactly is coming with extended C++ support?
Am 15.10.2014 um 09:18 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ": On Wednesday, 15 October 2014 at 06:29:40 UTC, Daniel N wrote: "C++03 has this syntax to oblige the compiler to instantiate a template: template class std::vector;" But how does D handle concepts which most likely will be in the C++14 standard? http://concepts.axiomatics.org/~ans/ I imagine you meant C++17. C++14 is already ratified. -- Paulo
Re: So what exactly is coming with extended C++ support?
On 10/14/14, 11:18 PM, Jacob Carlborg wrote: On 2014-10-15 01:01, Andrei Alexandrescu wrote: Correct. Here's the syntax on the C++ side: http://en.wikipedia.org/wiki/C++11#Extern_template -- Andrei "extern template class std::vector; which tells the compiler NOT to instantiate the template in this translation unit." That sounds like the complete opposite of what's needed. C++11 includes C++03. -- Andrei
template constraint diagnostics
http://youtu.be/qwXq5MqY2ZA?t=33m57s I wish we had diagnostics like that in D.
Re: So what exactly is coming with extended C++ support?
On 2014-10-15 08:50, Dan Olson wrote: This would allow a D library to be embedded in an otherwise Objective-C (or maybe Swift?) iOS app. Sure, as long as it's using an Objective-C compatible API. How about bindings for APIs in the iPhone SDK? I think folks can build those as needed with help from Jacob's dstep tool. It would be nice to have a repository for these bindings somewhere though. I will create Dub packages when I need some framework, unless someone else beats me to it. Objective-C interop (DIP 43). Without it, it will be hard to go all out "D" in an iOS app. I have not been following the pull request and don't have any idea when it might bubble into LDC via DMD, but not anytime soon I would guess. It needs some refactoring, which I've already started. Then there are all the tool related things that might hinder D use on iOS. Things such as no source level debugging I think I have used Xcode to debug a D application. lack of D/Xcode integration. Yeah, it will be far from as convenient as using Swift but I think it's possible. Most tools Xcode uses: compiling, build nib files and so on are command line tools. For example, TextMate is using Ninja as a build system, completely without Xcode. It still uses nib files and other OS X specific features. -- /Jacob Carlborg
Re: [OT] Ada gems
Am 15.10.2014 um 16:41 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
":
On Wednesday, 15 October 2014 at 10:32:53 UTC, Paulo Pinto wrote:
Now the going native wave that hit Microsoft, has made them create the
Windows Runtime, having .NET compile to native code in Windows Phone 8
and create the .NET Native, the ahead-of-time native code compiler for
.NET.
Yes, these moves are interesting to watch. Not sure how it will turn out
unless Microsoft truly embrace cross-platform development.
On a related note I found these notes on the Go roadmap interesting:
http://dotgo.sourcegraph.com/post/99652962343/brad-fitzpatrick-on-the-future-of-the-go-programming
Go 1.4:
- precise GC for everything
- start of Android support
Go 1.5:
- concurrent GC with marginal pauses (15ms?)
- start of iOS support
- cache-friendly scheduler ("NUMA")
- tracing in browser (Chrome)
And people are working on Go->PNACL and Go->Javascript compilers…
I saw that roadmap. It is also the confirmation that they won't ever add
generics.
So I guess, a better C it is.
I haven't really looked much at Go in the past two years, but it looks
like D has roughly 18 months to get the GC up to speed or make
programming without GC really comfy.
At some point quality of implementation, programmer productivity, tools
and platform support matters more than semantic details if both language
A and B can do roughly the same things.
IF the Go developers succeed in reaching their goals, which is a gamble.
But neither Google or Microsoft lack resources or the motivation. So it
all hangs on project management and strategic thinking I think. :)
Competition and choice is a good thing. We'll see.
They just got a victory today, as Microsoft is now bringing Docker to
Windows, which uses Go quite heavily.
Although for the time being they are being silent on what languages will
Microsoft be using.
Nick Stinemates from Docker
https://news.ycombinator.com/item?id=8458382
"As a result, it will be a community/maintainer decision what language
it's written in, but obviously we're heavily biased toward Go."
--
Paulo
Re: Will D ever get optional named parameters?
On Wednesday, 15 October 2014 at 11:52:13 UTC, bearophile wrote: ketmar: besides, nested foreach with '_' is not working. but "__" can generate unique temporary variable each time. The point is to introduce a little breaking change in D and use "_" as "don't care", so you can reuse it for nested scoped and for tuple unpacking, and for other similar future purposes. Bye, bearophile I agree that _ would be the ideal syntax, but why make a breaking change when it is unnecessary? __ would serve just as well and it is only one extra character. It is already reserved so it would be reasonable to put it to good use.
Re: Program logic bugs vs input/environmental errors
On Wednesday, 15 October 2014 at 14:47:33 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 15 October 2014 at 14:25:43 UTC, Dicebot wrote: How can one continue without recovering? This will result in any kind of environment not being cleaned and false failures of other tests that share it. fork()? http://check.sourceforge.net/doc/check_html/check_2.html "Writing a framework for C requires solving some special problems that frameworks for Smalltalk, Java or Python don’t have to face. In all of those language, the worst that a unit test can do is fail miserably, throwing an exception of some sort. In C, a unit test is just as likely to trash its address space as it is to fail to meet its test requirements, and if the test framework sits in the same address space, goodbye test framework. To solve this problem, Check uses the fork() system call to create a new address space in which to run each unit test, and then uses message queues to send information on the testing process back to the test framework. That way, your unit test can do all sorts of nasty things with pointers, and throw a segmentation fault, and the test framework will happily note a unit test error, and chug along. "
Re: So what exactly is coming with extended C++ support?
"Wyatt" wrote in message news:vhwivrusiysydgkxr...@forum.dlang.org... I get the sense that http://dlang.org/cpp_interface needs some updates then? At the very least, it mentions "...it is very unlikely that any sort of reasonable method could be found to express C++ templates in a link-compatible way with D." Or am I misunderstanding what you mean with that bullet point? That page is many years out of date.
Re: So what exactly is coming with extended C++ support?
On Tuesday, 14 October 2014 at 22:27:35 UTC, Walter Bright wrote: Currently, D supports C++: * function calling * name mangling * namespaces * templates * member functions * single inheritance * basic types that exist in C++ but not D (like 'long') I get the sense that http://dlang.org/cpp_interface needs some updates then? At the very least, it mentions "...it is very unlikely that any sort of reasonable method could be found to express C++ templates in a link-compatible way with D." Or am I misunderstanding what you mean with that bullet point? -Wyatt
Re: Program logic bugs vs input/environmental errors
On Wednesday, 15 October 2014 at 14:25:43 UTC, Dicebot wrote: How can one continue without recovering? This will result in any kind of environment not being cleaned and false failures of other tests that share it. fork()?
Re: [OT] Ada gems
On Wednesday, 15 October 2014 at 10:32:53 UTC, Paulo Pinto wrote:
Now the going native wave that hit Microsoft, has made them
create the Windows Runtime, having .NET compile to native code
in Windows Phone 8 and create the .NET Native, the
ahead-of-time native code compiler for .NET.
Yes, these moves are interesting to watch. Not sure how it will
turn out unless Microsoft truly embrace cross-platform
development.
On a related note I found these notes on the Go roadmap
interesting:
http://dotgo.sourcegraph.com/post/99652962343/brad-fitzpatrick-on-the-future-of-the-go-programming
Go 1.4:
- precise GC for everything
- start of Android support
Go 1.5:
- concurrent GC with marginal pauses (15ms?)
- start of iOS support
- cache-friendly scheduler ("NUMA")
- tracing in browser (Chrome)
And people are working on Go->PNACL and Go->Javascript compilers…
I haven't really looked much at Go in the past two years, but it
looks like D has roughly 18 months to get the GC up to speed or
make programming without GC really comfy.
At some point quality of implementation, programmer productivity,
tools and platform support matters more than semantic details if
both language A and B can do roughly the same things.
IF the Go developers succeed in reaching their goals, which is a
gamble. But neither Google or Microsoft lack resources or the
motivation. So it all hangs on project management and strategic
thinking I think. :)
Competition and choice is a good thing. We'll see.
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak wrote: Would this affect your code? Probably, but I have no D code of any size to care about. Do you think it makes your code better or worse? Better. Is this just a pointless style change? Nope. Anything else? Only what you said in summary to this thread (I am waay late to this party) Regan -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Sat, 11 Oct 2014 13:47:55 +0100, Martin Nowak wrote: https://github.com/D-Programming-Language/dmd/pull/4043#issuecomment-58748353 There has been a broad support for this on the newsgroup discussion because this regularly confuses beginners. There are also some arguments against it (particularly by Walter) saying that this change will put too much work on D code owners. Let's continue with the following steps. - add RHS/LHS function qualifiers to D's style guide - change all code formatting (like dmd's headergen and ddoc to use RHS qualifiers) - help Brian to get dfix up and running (https://github.com/Hackerpilot/dfix/issues/1) Then we might revisit the topic in 6 month and see whether we have better arguments now. +1 -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Program logic bugs vs input/environmental errors
Walter Bright writes: > On 10/14/2014 11:23 PM, Jacob Carlborg wrote: >> On 2014-10-15 07:57, Walter Bright wrote: >> >>> Why do you need non-fatal unittests? >> >> I don't know if this would cause problems with the current approach. But most >> unit test frameworks don't NOT stop on the first failure, like D does. It >> catches the exception, continues with the next test and in the end prints a >> final report. > > I understand that, but I don't think that is what Dicebot is looking > for. He's looking to recover from unittests, not just continue. That is what I am looking for, just being able to continue from a failed assert in a unittest. On iOS, it is easier to build one app with all unit tests. This is because I don't know of a way to automate the download/run of a bunch of smaller unittests. The test driver catches Throwables, records failure, then goes on to the next test. After catching up on this thread, I feel like unittests should throw an Exceptions.
Re: Program logic bugs vs input/environmental errors
On Wednesday, 15 October 2014 at 07:26:03 UTC, Walter Bright wrote: On 10/14/2014 11:23 PM, Jacob Carlborg wrote: On 2014-10-15 07:57, Walter Bright wrote: Why do you need non-fatal unittests? I don't know if this would cause problems with the current approach. But most unit test frameworks don't NOT stop on the first failure, like D does. It catches the exception, continues with the next test and in the end prints a final report. I understand that, but I don't think that is what Dicebot is looking for. He's looking to recover from unittests, not just continue. How can one continue without recovering? This will result in any kind of environment not being cleaned and false failures of other tests that share it.
Re: Program logic bugs vs input/environmental errors
On 10/15/14, 4:25 AM, Walter Bright wrote: On 10/14/2014 11:23 PM, Jacob Carlborg wrote: On 2014-10-15 07:57, Walter Bright wrote: Why do you need non-fatal unittests? I don't know if this would cause problems with the current approach. But most unit test frameworks don't NOT stop on the first failure, like D does. It catches the exception, continues with the next test and in the end prints a final report. I understand that, but I don't think that is what Dicebot is looking for. He's looking to recover from unittests, not just continue. I think this means you can't get stack traces for exceptions thrown in unit tests, right?
Re: dub configuration for external dependencies
On Wednesday, 15 October 2014 at 12:26:14 UTC, Shammah Chancellor wrote: I'm not sure where the appropriate place to ask about dub is. There doesn't seem to be a newsgroup for it? Anyways, I am wondering what the proper way to deal with external non-D dependencies is. For example, libd-llvm uses a lot of libraries from LLVM whose library path changes from machine to machine, and some of the list of 30 libraries changes as well. They have a nice configuration tool llvm-config which emits ldflags which are very nice to use from makefiles but I don't see any way to obtain this information from within the dub.json. Do I essentially need to make an autotools-esque script to generate the dub.json? That seems to be at odds with the ability to register packages. -S I'm not sure what the answer is but there is an official forum which might yield some useful information. http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/
Re: WAT: opCmp and opEquals woes
Am Wed, 15 Oct 2014 11:25:10 + schrieb "Martin Nowak" : > On Wednesday, 23 July 2014 at 21:14:35 UTC, Brian Schott wrote: > > $ ./dscanner --styleCheck ~/tmp/test.d > > test.d(1:8)[warn]: 'A' has method 'opCmp', but not 'opEquals'. > > Nice Yep! Some say opCmp is something entirely different from opEquals. One creates an order between two objects while the other tests for equality. I always had the idea that opCmp supersedes opEquals. What dscanner does is probably the only sane way out :) -- Marco
dub configuration for external dependencies
I'm not sure where the appropriate place to ask about dub is. There doesn't seem to be a newsgroup for it? Anyways, I am wondering what the proper way to deal with external non-D dependencies is. For example, libd-llvm uses a lot of libraries from LLVM whose library path changes from machine to machine, and some of the list of 30 libraries changes as well. They have a nice configuration tool llvm-config which emits ldflags which are very nice to use from makefiles but I don't see any way to obtain this information from within the dub.json. Do I essentially need to make an autotools-esque script to generate the dub.json? That seems to be at odds with the ability to register packages. -S
Re: Will D ever get optional named parameters?
ketmar: besides, nested foreach with '_' is not working. but "__" can generate unique temporary variable each time. The point is to introduce a little breaking change in D and use "_" as "don't care", so you can reuse it for nested scoped and for tuple unpacking, and for other similar future purposes. Bye, bearophile
Re: Will D ever get optional named parameters?
On Wed, 15 Oct 2014 11:21:43 +
via Digitalmars-d wrote:
> On Tuesday, 14 October 2014 at 21:21:23 UTC, 岩倉 澪 wrote:
> > Something like:
> > void foo(int a = 42, int b = 0){}
> > foo(@default, 7); //rewritten to foo(42, 7);
>
> It is useful to have "_" mean "I don't care" when you have
> tuples. So you would then write:
>
> "foo( _ , 7 )" and " _,y = get_point()"
it better be "__" (two underscores). the rationale is simple: "__" is
clearly reserved for internal use, so it can has any meaning we need
without breaking any code. 'cause single underscore now can be used as
placeholder in `foreach (_; 0..42)`, *AND* still can be accessed as
normal var. besides, nested foreach with '_' is not working. but "__"
can generate unique temporary variable each time.
signature.asc
Description: PGP signature
Re: On Phobos GC hunt
On Tuesday, 14 October 2014 at 13:29:33 UTC, Dmitry Olshansky wrote: On Wednesday, 8 October 2014 at 07:52:37 UTC, Dmitry Olshansky wrote: On Tuesday, 7 October 2014 at 21:59:08 UTC, Peter Alexander Okay, I think I should go a bit futher with the second version of the tool. Things on todo list: - make tool general enough to work for any GitHub based project (and hackable for other hostings) - use Brian's D parser to accurately find artifacts - detect "throw new SomeStuff" pattern and automatically populate potential fix line - list all source links in one coulmn for the same function (this needs proper parser) - use blacklist of : to filter out CTFE - use current data from wiki for "potential fix" column if present The new version is out, it's a bit rough for a proper announcement yet and misses a couple of things from my todo list but the improvement is so radical I decided to share it anyway. With the new pattern-matcher/parser I hacked together in on top of Brain's lexer it's now surgically precise in labeling artifacts. Also I retained as much as possible of original comments (line numbers have changed), and grouped source links per artifact. Updated Wiki: http://wiki.dlang.org/Stuff_in_Phobos_That_Generates_Garbage Tool: https://github.com/DmitryOlshansky/gchunt Also it's "universal" as in any github-hosted D project, for example here is an output for druntime: http://wiki.dlang.org/Stuff_in_Druntime_That_Generates_Garbage Still todo: - blacklisting of modules/artifacts - detect usage of (i)dup - label throw new xyz as `EX` - a few bugs to fix in artifact labeling Thanks a million! That's very very useful.
Re: std.experimental.logger formal review round 3
On Wednesday, 15 October 2014 at 10:12:56 UTC, Jakob Ovrum wrote: On Wednesday, 15 October 2014 at 09:25:07 UTC, Robert burner Schadek wrote: On Wednesday, 15 October 2014 at 02:54:27 UTC, Dicebot wrote: As there was quite some last moment feedback I am giving some more time for me to research issues a bit and Robert to address them :) No need, I fixed the MultiLogger last weekend. "Fixed" by simply removing the attempt at logarithmic time operations, and still not conforming to the Phobos container interface... Yes, because other people already complained that nobody will every need a logarithmic time MulitLogger and I always thought that MultiLogger was to complex anyway. I could make the Logger[] array alias this and it would be comforming to Phobos container, but that doesn't really solve the issue does it.
Re: WAT: opCmp and opEquals woes
On Wednesday, 23 July 2014 at 21:14:35 UTC, Brian Schott wrote: $ ./dscanner --styleCheck ~/tmp/test.d test.d(1:8)[warn]: 'A' has method 'opCmp', but not 'opEquals'. Nice
Re: Will D ever get optional named parameters?
On Tuesday, 14 October 2014 at 21:21:23 UTC, 岩倉 澪 wrote:
Something like:
void foo(int a = 42, int b = 0){}
foo(@default, 7); //rewritten to foo(42, 7);
It is useful to have "_" mean "I don't care" when you have
tuples. So you would then write:
"foo( _ , 7 )" and " _,y = get_point()"
Re: [OT] Ada gems
On Wednesday, 15 October 2014 at 08:40:04 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 15 October 2014 at 07:27:38 UTC, eles wrote: ... For some reason Microsoft did not make that strategic move until much later. I think Bill Gates was the reason, MS pushed Visual Basic too much to be taken seriously… So eventually they had to create their own incompatible "Java" (C#) in order to keep collecting Windows-tax in the business environment. An interesting thing for conspiracy theories is how close the new Window Runtime model is from Ext-VOS. Ext-VOS was the next architecture of COM, based on the idea that all Windows languages would target it, as a common language runtime. Along the way, they decided to create the CLR instead. Now the going native wave that hit Microsoft, has made them create the Windows Runtime, having .NET compile to native code in Windows Phone 8 and create the .NET Native, the ahead-of-time native code compiler for .NET. The main difference with Windows Native Runtime and the old Ext-VOS, is the use .NET metadata instead of COM type libraries. http://blogs.msdn.com/b/dsyme/archive/2012/07/05/more-c-net-generics-history-the-msr-white-paper-from-mid-1999.aspx Java might as well have been, what made them move away from the initial design. -- Paulo
Re: std.experimental.logger formal review round 3
On Wednesday, 15 October 2014 at 09:25:07 UTC, Robert burner Schadek wrote: On Wednesday, 15 October 2014 at 02:54:27 UTC, Dicebot wrote: As there was quite some last moment feedback I am giving some more time for me to research issues a bit and Robert to address them :) No need, I fixed the MultiLogger last weekend. "Fixed" by simply removing the attempt at logarithmic time operations, and still not conforming to the Phobos container interface...
Re: DIP66 - Multiple alias this
On Wednesday, 15 October 2014 at 03:49:41 UTC, Daniel N wrote:
On Wednesday, 15 October 2014 at 02:46:05 UTC, Dicebot wrote:
On Tuesday, 14 October 2014 at 12:33:50 UTC, IgorStepanov
wrote:
This code tell that C is subtype of A and C is subtype of B.
User can use this fact in his code:
void foo(B);
C c = new C;
foo(c); //Ok.
Of course, we shouldn't allow user to cast c to int:
int i = c; //wrong
However, user can explicitly cast c to his subtype, which is
convertable to int:
int i = cast(B)c; //Ok
Summarizing, I disagree with suggestion disallow this code at
type semantic stage.
I agree. It will also make possible to break already working
disambugation of `foo(c)` kind but adding new `alias this` to
one of subtypes independently. That sounds annoying.
I guess the best part of D is, you have the means to fix
anything you disagree with yourself... I can add a static
assert to my class and be happy.
I have another idea, we could define that the shortest
conversion chain wins, analogous to type promotions, that makes
it possible to contain the issue inside C.
class C
{
A a;
B b;
int disambiguate_int()
{
return a;
}
alias a this;
alias b this;
alias disambiguate_int this;
static assert(__traits(compiles, {int _ = C.init;}),
"Ambiguous alias this");
}
i.e. this assert should pass.
In first edition I've implemented rule, when if type defines
alias this directly, this alias hides all indirect aliases with
the same type. However Andrey said that we should implement the
strictest rules as possible and maybe relax them later.
Thus I implemented current rules, but saved the old implemetation
of search. After some time we will able to return to first rule.
It's not hard.
Re: std.experimental.logger formal review round 3
On Wednesday, 15 October 2014 at 02:54:27 UTC, Dicebot wrote: As there was quite some last moment feedback I am giving some more time for me to research issues a bit and Robert to address them :) No need, I fixed the MultiLogger last weekend.
Re: [OT] Ada gems
On Wednesday, 15 October 2014 at 07:27:38 UTC, eles wrote: In defense of C++, beyond its C roots & compatibility, it also have been the language that made the mistakes useful for the other languages. That is, Java and C# capitalized on C++'s mistakes by simply not repeating them. Of course, mistakes are obvious only after they are made and, as such, C++ was in the weakest position, just like any pioneer. I guess you could say that, but the reality is that C++ has been considered a bad language design from the start in academia. C++ wouldn't have had any chance without full C compatibility. C++ is one more proof that installed based and gradual adoption in combination with supporting "The Next Big Thing" (OO) is the easy path to dominance. You could always defend using C++ by saying that you used it as mostly C with some bells and whistles (such as explicit inlining, overloading, vectors, complex numbers etc), so you did not have to learn C++ to start using it if you knew C. (Objective-C requires much more effort from the programmer) Java primarily capitalized on educational institutions having a positive attitude towards SUN as a company. SUN was run by true engineers. In addition Java was marketed as a language for the web (which was hyped in the mid 90s) so educational institutions got what they wanted: 1. A language that students would be motivated by, being able to run programs in web browsers (which didn't turn out to work very well in reality). It was common for universities to use clean languages that nobody in the real world used. 2. A language that was simple, safe and had a garbage collector and provided all the mechanisms needed to teach CS and OO (Java was as close to Simula as you can get). 3. A language for which many educational books were being written (important when you select a curriculum). Once you get educational institutions to force feed students with a language you win. I am not sure if Java would have survived without it. For some reason Microsoft did not make that strategic move until much later. I think Bill Gates was the reason, MS pushed Visual Basic too much to be taken seriously… So eventually they had to create their own incompatible "Java" (C#) in order to keep collecting Windows-tax in the business environment.
Re: Will D ever get optional named parameters?
On Monday, 13 October 2014 at 08:29:42 UTC, 岩倉 澪 wrote: From what I've found, there was some work on this in the past (http://forum.dlang.org/thread/wokfqqbexazcguffw...@forum.dlang.org?page=6#post-thclpgdlfxxhhfklwsoj:40forum.dlang.org), but a pull request was never made/I don't seem to find discussion about adding it as a feature anywhere. I think optional named parameters would be a nice addition, either to the core language, or something like the monadic solution from that old thread in phobos. Are there good reasons not to add something like this to the language, or is it simply a matter of doing the work? Has it been discussed much? That's just taking laziness one step further :)
Re: [OT] Ada gems
On Wednesday, 15 October 2014 at 07:31:45 UTC, eles wrote: On Tuesday, 14 October 2014 at 19:49:08 UTC, Paulo Pinto wrote: Am 14.10.2014 um 17:30 schrieb eles: On Tuesday, 14 October 2014 at 14:56:53 UTC, eles wrote: On Tuesday, 14 October 2014 at 13:52:24 UTC, eles wrote: consistency between 3rd party libraries. Java has spoiled me While I agree with all this, I think the reason for Java's developing smoothness is not portability as such, but the unitarity of it. This is exactly how Bjarne puts it: "Java is not portable over platforms, Java is *a platform*." Which is quite true, might it be not interesting for some applications. In a way is just like one would brag about Windows apps portability on the grounds that all operating systems support Virtualbox... This is common to any language that offers a rich runtime that abstracts away over OS specific issues, while allowing you to jump into the OS when required to do so. C and C++ fail at this, because C's notion of runtime is called UNIX and C++ followed along, to cater to the same crowd. That standard runtime never managed into the language standard and instead became a standard of its own, POSIX. With the caveat that not every OS out there implements POSIX (there are others besides Windows that don't), and those that do, don't have 100% the same version. This is exactly the reason why C++ standardization group is now trying to get the same form of plaftorm abstractions into the standard, that other languages enjoy. -- Paulo
Re: Wouldn't it be nice (case range statements)
On Tuesday, 14 October 2014 at 21:29:59 UTC, John Colvin wrote: if code like this worked: http://dpaste.dzfl.pl/7ea4eb03f02e A few reasons why it doesn't: You have to duplicate the case keyword when declaring case ranges. Why? Case ranges are inclusive at both ends of the range, unlike in foreach. Again, why? Actually, the latter is the reason for the former. If incluseve ranges were defined (let's say with ...), then that becomes possible.
Re: Wouldn't it be nice (case range statements)
On Tuesday, 14 October 2014 at 21:33:36 UTC, Adam D. Ruppe wrote:
On Tuesday, 14 October 2014 at 21:29:59 UTC, John Colvin wrote:
You have to duplicate the case keyword when declaring case
ranges. Why?
Case ranges are inclusive at both ends of the range, unlike in
foreach. Again, why?
It comes from writing:
switch(foo) {
case 1:
case 2:
case 3:
case 4:
// code
}
Then just replacing the case 2 and case 3 with .. collapsing
the repetition to just the beginning and the end. If you write
it as:
switch(foo) {
case 1:
..
case 4:
// code
}
vertically, that is, I think the rationale becomes a lot more
clear. I like this a lot, it works brilliantly for me and makes
good sense.
Ah, yeah, that does make sense.
Allow the second `case` keyword to be removed, which would
then have the same semantics as the range in foreach.
That would be ok too.
Re: So what exactly is coming with extended C++ support?
On Wednesday, 15 October 2014 at 06:50:55 UTC, Dan Olson wrote: "Szymon Gatner" writes: That is good to hear indeed. In your estimate: how much longer until D is usable on iOS? Depends on your definition of "usable" Szymon. This would allow a D library to be embedded in an otherwise Objective-C (or maybe Swift?) iOS app. That is my definition :) I would use static D library in C++ iOS application. How about bindings for APIs in the iPhone SDK? I think folks can build those as needed with help from Jacob's dstep tool. It would be nice to have a repository for these bindings somewhere though. Would be nice but much less important for me. It would be cool if by Feb/Mar 2015 a demo app could be submited to the App Store, just to test acceptance. I would gladly do that Then there are all the tool related things that might hinder D use on iOS. Things such as no source level debugging, lack of D/Xcode integration. Right Oh, and compiling to arm64 for newer devices. Knowing Apple that will be mandatory for new apps soon. Thanks for all your work!
Re: [OT] Ada gems
On Tuesday, 14 October 2014 at 19:49:08 UTC, Paulo Pinto wrote: Am 14.10.2014 um 17:30 schrieb eles: On Tuesday, 14 October 2014 at 14:56:53 UTC, eles wrote: On Tuesday, 14 October 2014 at 13:52:24 UTC, eles wrote: consistency between 3rd party libraries. Java has spoiled me While I agree with all this, I think the reason for Java's developing smoothness is not portability as such, but the unitarity of it. This is exactly how Bjarne puts it: "Java is not portable over platforms, Java is *a platform*." Which is quite true, might it be not interesting for some applications. In a way is just like one would brag about Windows apps portability on the grounds that all operating systems support Virtualbox...
Re: [OT] Ada gems
On Tuesday, 14 October 2014 at 20:47:14 UTC, Paulo Pinto wrote: Am 14.10.2014 um 22:08 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ": On Tuesday, 14 October 2014 at 19:49:08 UTC, Paulo Pinto wrote: Am 14.10.2014 um 17:30 schrieb eles: On Tuesday, 14 October 2014 at 14:56:53 UTC, eles wrote: On Tuesday, 14 October 2014 at 13:52:24 UTC, eles wrote: I can use other languages *today* or wait until 2020 for C++17 to be available across all major compilers. IIRC, the standard team said something that for C++17 will be many technical notes that will implement changes available in experimental, thus people should be able to include them in their code. Of course, having the compilers implement those, is another matter. In defense of C++, beyond its C roots & compatibility, it also have been the language that made the mistakes useful for the other languages. That is, Java and C# capitalized on C++'s mistakes by simply not repeating them. Of course, mistakes are obvious only after they are made and, as such, C++ was in the weakest position, just like any pioneer.
Re: Program logic bugs vs input/environmental errors
On 10/14/2014 11:23 PM, Jacob Carlborg wrote: On 2014-10-15 07:57, Walter Bright wrote: Why do you need non-fatal unittests? I don't know if this would cause problems with the current approach. But most unit test frameworks don't NOT stop on the first failure, like D does. It catches the exception, continues with the next test and in the end prints a final report. I understand that, but I don't think that is what Dicebot is looking for. He's looking to recover from unittests, not just continue.
Re: Official PPA for dmd
On Wednesday, 3 September 2014 at 18:08:17 UTC, Jordi Sayol via Digitalmars-d wrote: Yes, that's correct. I juts wait for next dmd v2.067 to avoid all the 2.066 regressions. Maybe this worths the pain?... http://forum.dlang.org/post/543dd28193525_57e33ffa705592b89...@hookshot-fe3-cp1-prd.iad.github.net.mail 2.067 is quite far ahead... Thanks
Re: So what exactly is coming with extended C++ support?
On Tuesday, 14 October 2014 at 20:41:25 UTC, Nick Sabalausky wrote: On 09/30/2014 04:48 AM, Szymon Gatner wrote: On Monday, 29 September 2014 at 20:15:06 UTC, bachmeier wrote: On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner wrote: Is that all it would take? Do you also need a GC-free standard library, which seems to be the need of all the others saying "do this and I'll switch from C++"? Are the tools good enough? Considered how many games (and I don't mean indie anymore, but for example Blizzard's Heartstone) are now created in Unity which uses not only GC but runs in Mono I am very skeptical of anybody claiming GC is a no-go for games. The whole "Unity3D == Mono" thing is a somewhat inaccurate misconception. Unity3D's engine (ie, the real workhorse of any Unity3D game) is written in plain old native C++. So not *necessarily* GC (though they might still use one internally, I wouldn't know). Only the game-specific scripts (and I *think* the Unity3D Editor) actually run on Mono. And even then, the game scripts *are* able to call into C-linkage stuff, which *is* occasionally done to work around performance issues within game scripts. Also, I imagine Mono's GC is probably quite a bit better than D's currently is. Yeah, but on the other hand there are quite a few small studios living off Air, LibGDX/jMonkeyEngine and XNA/MonoGame. Which is an area where D could also appeal to indies. One needs to start somewhere. -- Paulo
Re: Program logic bugs vs input/environmental errors
On Saturday, 4 October 2014 at 08:08:49 UTC, Walter Bright wrote: On 10/3/2014 4:27 AM, Kagamin wrote: Do you interpret airplane safety right? As I understand, airplanes are safe exactly because they recover from assert failures and continue operation. Nope. That's exactly 180 degrees from how it works. Any airplane system that detects a fault shuts itself down and the backup is engaged. No way in hell is software allowed to continue that asserted. Sure, software is one part of an airplane, like a thread is a part of a process. When the part fails, you discard it and continue operation. In software it works by rolling back a failed transaction. An airplane has some tricks to recover from failures, but still it's a "no fail" design you argue against: it shuts down parts one by one when and only when they fail and continues operation no matter what until nothing works and even then it still doesn't fail, just does nothing. The airplane example works against your arguments. The unreliable design you talk about would be committing a failed transaction, but no, nobody suggests that.
Re: So what exactly is coming with extended C++ support?
On Wednesday, 15 October 2014 at 06:29:40 UTC, Daniel N wrote: "C++03 has this syntax to oblige the compiler to instantiate a template: template class std::vector;" But how does D handle concepts which most likely will be in the C++14 standard? http://concepts.axiomatics.org/~ans/
