Re: Release D 2.070.0
El 28/01/16 a les 23:36, Minas Mina via Digitalmars-d-announce ha escrit: > On Wednesday, 27 January 2016 at 21:08:54 UTC, Martin Nowak wrote: >> Glad to announce D 2.070.0 >> >> http://dlang.org/download.html >> >> This release comes with the new std.experimental.ndslice, heavily expanded >> Windows bindings, and native exception handling on 64-bit linux. See the >> changelog for more details. >> >> http://dlang.org/changelog/2.070.0.html >> >> -Martin > > When trying to install on Ubuntu 15.10 x64, I get this: > http://imgur.com/L4ozgC1 > > I didn't proceed with the installation as I don't want any possible broken > things. > Same problem on Ubuntu 15.10 x32. $ lintian -c dmd_2.070.0-0_i386.deb Can't close(GLOB(0x9a83b5c)) filehandle: '' at /usr/share/lintian/helpers/coll/objdump-info-helper line 192 command failed with error code 123 at /usr/share/lintian/collection/objdump-info line 79. warning: collect info objdump-info about package dmd failed warning: skipping check of binary package dmd the command exit status is 2 on lintina manpages: EXIT STATUS 0 No policy violations or major errors detected. (There may have been warnings, though.) 1 Policy violations or major errors detected. 2 Lintian run-time error. An error message is sent to stderr. So this is not a dmd deb package issue but Ubuntu 15.10 lintian issue. Please report it as a bug. You can safely install dmd deb package on your Ubuntu system. Regards, Jordi
Re: Vision for the first semester of 2016
On Friday, 29 January 2016 at 23:41:47 UTC, Ola Fosheim Grøstad wrote: Yep, a curated list like those awesome-lists found on github would be a start. I've got one before there were many awesome-lists: https://github.com/zhaopuming/awesome-d
Re: Vision for the first semester of 2016
On Friday, 29 January 2016 at 16:07:48 UTC, Adam D. Ruppe wrote: In my perfect world, quality third party apps - as determined just by usage stats or something - would be automatically downloadable and their documentation searchable as if it was standard. I've noticed that curated lists of libraries are popping up on github for various languages: https://github.com/search?utf8=%E2%9C%93&q=awesome If D gets more users maybe there would be a market for a commercial IDE with a reviewed repository with globally searchable reference documentation and cookbook recipes. For popular languages stack overflow is pretty ok, but over time it is getting more chaotic. Imagine an intelligent IDE that looks at the probability of a match between a cookbook recipe and what you type. A.I. templating of sorts. Then the line between "standard library" and other library basically disappears. I usually prefer to download from github for commercial code and put it in my project archive. I want to check out if the library programmers are maintaining it and have enough people as well. Then I lock that version until I find a reason to upgrade. For me automatic downloading (dub etc) fits more with hobby projects and experiments. While that isn't likely to happen, we could at least start promoting third party stuff more equally. Yep, a curated list like those awesome-lists found on github would be a start. Then write tutorials that only use libraries from that list. This is a reason why I tend to only write libs that I actually use myself - at least then I know every function has one happy user. Yeah, I find myself constantly wanting to improve on even the simplest libraries for better interaction with the kind of code the functions/objects seem to be most used with. More of a discovery process of usability than "mathematical deduction".
Re: Vision for the first semester of 2016
On Friday, 29 January 2016 at 20:30:35 UTC, Iain Buclaw wrote: How much of it actually depends on the compiler though? I'd be a little surprised if we couldn't backport at least 80% of phobos to 2.067/2.068 with zero changes. I have no idea, I think you are probably right. But having a compiler and phobos out of sync sounds even worse than the way it is now. A better solution for me would be to just stick with a version and wait for gdc to catch up but honestly it seems like as soon as a new version comes out I hit some bug that is only fixed in the latest version, forcing me to upgrade. For example this literally happened days ago, I am currently at 2.069 and the other day I needed to call some winapi stuff, only to realize the winapi bindings are way outdated, well guess what they are updated in 2.070. Its amazing how often I hit a problem and then find out its fixed in the next version.
Re: Vision for the first semester of 2016
On 29 January 2016 at 21:14, Tofu Ninja via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Friday, 29 January 2016 at 18:13:21 UTC, Iain Buclaw wrote: > >> On 29 Jan 2016 6:55 pm, "Tofu Ninja via Digitalmars-d-announce" < >> digitalmars-d-announce@puremagic.com> wrote: >> >>> >>> On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote: >>> Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei >>> >>> >>> Just out of curiosity, is getting the different compilers in sync still a >>> >> priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc at 2.066. >> >> If anyone wants to help out... >> >> I have to also juggle working on GCC and GDB. :-) >> >> When gdc reaches 2.068 (GCC 7.1 is the target release next year) - expect >> it to stay there for a while... >> > > It would be nice if keeping them in sync was a priority, I would love to > use GDC so I could use GDB, but not having the latest fixes is simply not > worth it. Even simple things dont work when you go back just a few > versions, like in 2.066 isForwardRange is not correct and does not work > properly, something as simple as that does not work. Not to mention using > the new stuff like allocators. > How much of it actually depends on the compiler though? I'd be a little surprised if we couldn't backport at least 80% of phobos to 2.067/2.068 with zero changes.
Re: Vision for the first semester of 2016
On Friday, 29 January 2016 at 18:13:21 UTC, Iain Buclaw wrote: On 29 Jan 2016 6:55 pm, "Tofu Ninja via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote: Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei Just out of curiosity, is getting the different compilers in sync still a priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc at 2.066. If anyone wants to help out... I have to also juggle working on GCC and GDB. :-) When gdc reaches 2.068 (GCC 7.1 is the target release next year) - expect it to stay there for a while... It would be nice if keeping them in sync was a priority, I would love to use GDC so I could use GDB, but not having the latest fixes is simply not worth it. Even simple things dont work when you go back just a few versions, like in 2.066 isForwardRange is not correct and does not work properly, something as simple as that does not work. Not to mention using the new stuff like allocators.
Re: Vision for the first semester of 2016
On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote: Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei A couple comments: a) No mention of targeting increased organizational participation (academic, corporate, etc). Not trying to suggest it should or shouldn't be a goal. Just that if it is goal meaningful effort will be directed toward in H1 then it'd be worth including in the writeup. b) More specificity in the roadmap and priorities, to the extent they are known - As a potential D adopter, it'd be useful to have better insight into where the language might be a year or two out. For example, what forms of C++ integration might be available, or if the major components of the standard library are likely to be available nogc. However, it's hard to discern this from the writeup. Perhaps in many cases it would be premature to establish such goals, but to the extent there has been concrete thought it'd be useful to write it up. This comment is similar to a number of others suggesting a preference for more concrete goals. --Jon
Re: Release D 2.070.0
On 01/29/2016 12:53 PM, Adam D. Ruppe wrote: On Friday, 29 January 2016 at 17:49:58 UTC, Nick Sabalausky wrote: I don't recall: Does that parse the source for comments on its own or does it still use dmd's json (or html) output? Does it on its own. (Well, except the search results page, it still uses the json, but I'm fixing that soon and the main body pages already do their own thing.) Brian Schott's libdparse does the bulk of the work, independently of dmd. A big reason for this is that doing changes on dmd is a pain in the butt, and another one is that dmd is optimized toward compiling code (as it should be!) which isn't always ideal for doc generation (like version(Windows) docs being left out if you happen to be on a Linux box.) So doing it myself frees me from dmd's design constraints as well as dmd's development process. Ah, cool. I've filed this: https://github.com/Hackerpilot/Dscanner/issues/304
Re: Vision for the first semester of 2016
On 29 Jan 2016 6:55 pm, "Tofu Ninja via Digitalmars-d-announce" < digitalmars-d-announce@puremagic.com> wrote: > > On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote: >> >> Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei > > > Just out of curiosity, is getting the different compilers in sync still a priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc at 2.066. If anyone wants to help out... I have to also juggle working on GCC and GDB. :-) When gdc reaches 2.068 (GCC 7.1 is the target release next year) - expect it to stay there for a while...
Re: Sublime Text 3 Gets Better D Support
On Wednesday, 27 January 2016 at 17:34:35 UTC, Jack Stouffer wrote: In order to use this, you can either wait until a version of sublime is released with these changes, or you can download the dev version here https://www.sublimetext.com/3dev, and then install the new packages as described here https://github.com/sublimehq/Packages#installation. Build 3098 (3099 is the latest) now contains these changes. So all you have to do is download the dev build of Sublime.
Re: Release D 2.070.0
On 01/29/2016 11:09 AM, Adam D. Ruppe wrote: On Thursday, 28 January 2016 at 19:46:48 UTC, Nick Sabalausky wrote: Use dpldocs.info. We have good docs. That's orthogonal to this. It is just another example of why I feel it is necessary to take a different direction than dmd. I see. Good point. You've probably answered this elsewhere, but I don't recall: Does that parse the source for comments on its own or does it still use dmd's json (or html) output? Unless it does the parsing 100% on its own, then it would still suffer from the issue that PR addresses.
Re: Release D 2.070.0
On Friday, 29 January 2016 at 17:49:58 UTC, Nick Sabalausky wrote: I don't recall: Does that parse the source for comments on its own or does it still use dmd's json (or html) output? Does it on its own. (Well, except the search results page, it still uses the json, but I'm fixing that soon and the main body pages already do their own thing.) Brian Schott's libdparse does the bulk of the work, independently of dmd. A big reason for this is that doing changes on dmd is a pain in the butt, and another one is that dmd is optimized toward compiling code (as it should be!) which isn't always ideal for doc generation (like version(Windows) docs being left out if you happen to be on a Linux box.) So doing it myself frees me from dmd's design constraints as well as dmd's development process.
Re: Vision for the first semester of 2016
On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote: Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei Just out of curiosity, is getting the different compilers in sync still a priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc at 2.066.
RC vibe.d 0.7.27-rc.2
Am 22.01.2016 um 12:14 schrieb Sönke Ludwig: I've finally managed to tag a first beta for vibe.d. It contains numerous optimizations in the network and HTTP code, so it's especially important to thoroughly test this before release. 0.7.26 (except for the win32 driver) still compiles fine on DMD 2.070.0, so a fully synchronized release is fortunately not essential this time. http://code.dlang.org/packages/vibe-d/0.7.27-beta.1 Changelog: https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md A release candidate is now up for testing. If now further issues come up, this will be tagged as 0.7.27 next week. http://code.dlang.org/packages/vibe-d/0.7.27-rc.2
Re: Vision for the first semester of 2016
On Thursday, 28 January 2016 at 12:40:56 UTC, Ola Fosheim Grøstad wrote: I think that Sonke received too much "negative motivation" for his contributions recently, if I had been in his shoes I'd probably found working on vibe.d more fun. IRRC Ruppe also have voiced that he want to work on libraries which he has more freedom with. Yeah, I think getting in Phobos is a waste of time and likely a net negative on the library due to how much harder it is to change phobos vs changing your own file. In my perfect world, quality third party apps - as determined just by usage stats or something - would be automatically downloadable and their documentation searchable as if it was standard. When you do `import std.string;` you expect it to just work, and you find std.string's docs easily from dmd. I'd love it if you could do `import thirdparty.independent;` and it magically works too - without even need for a configuration file or an install command. And the docs are right there and tutorials are written however the author feels like writing them. Then the line between "standard library" and other library basically disappears. While that isn't likely to happen, we could at least start promoting third party stuff more equally. An frankly, as APIs have to be vetted on large applications in maintenance mode a lot of the effort put into arguing the design "perfect Phobos libraries" most likely will be in vain. This is a reason why I tend to only write libs that I actually use myself - at least then I know every function has one happy user.
Re: Release D 2.070.0
On Thursday, 28 January 2016 at 19:46:48 UTC, Nick Sabalausky wrote: Use dpldocs.info. We have good docs. That's orthogonal to this. It is just another example of why I feel it is necessary to take a different direction than dmd.
Re: Silicon Valley D Meetup January 28, 2016
On Friday, 29 January 2016 at 08:01:54 UTC, Ali Çehreli wrote:
Why didn't you say hi? :)
There was no chat box!
I'm pretty uncomfortable with the whole video and audio thing. I
think I sound terrible and look just as bad. I prefer reading and
writing.
I think we were seeing just two connections: Luís and us.
Yeah, I only saw the two boxes and myself, and I turned my camera
+ mic off.
Is there a reason why only auto functions have attribute
inference? Why not infer all attributes unless they are
overridden by explicit attributes?
The big reason is that for non-template functions, the body isn't
necessarily there and it affects mangling.
So if you tried to do the whole .di thing and wrote:
void foo() { ... } // implicitly @safe implementation
and accessed it via
void foo(); // not marked, but no body so cannot be inferred...
You'd get linker errors because the bodyless one now has a
different mangled name from being unable to infer.
This can also be relevant with inheritance:
class Base {
void foo() { a+b; } // implicitly @safe
}
class Derived : Base {
void foo() { *(cast(void*) 0) = 0; } // totally @system
}
What happens then? Is Derived.foo an error because it cannot
override the implicitly @safe interface of Base.foo?
I think: yes, that's exactly what should happen.
But, what if you import an interface file again:
class Base {
void foo();
}
Can we still make it an error? Eh, not reliably. And then the
danger is: here, Base.foo *appears* to be @system, so the
compiler will let you override it.
But in the file that uses it, with the full definition, the
compiler inferred it to be @safe.
@safe useMyClass(Base base) {
base.foo(); // allowed, it thinks foo is @safe
}
then the other module, compiled separately via bodyless
interface, does:
useMyClass(new Derived());
...and it compiles because Derived *it believes* implements the
Base interface correctly but now the @safe guarantee was just
blown wide open.
With templates, the body must be present at *all* uses, even if
compiled separately, so it doesn't fall victim to this, but other
functions do bring a few worries.
(though, on the other hand, using a .di file, you could always
just lie about the attributes anyway and the compiler trusts
you... so maybe we aren't in that great of a position to begin
with and this shouldn't be a blocker)
Re: Silicon Valley D Meetup January 28, 2016
On 01/22/2016 03:54 PM, Ali Çehreli wrote: "A defense of so-called anemic domain models" by Luís Marques http://www.meetup.com/D-Lang-Silicon-Valley/events/228027468/ Luís gave an excellent presentation on anemic domain models (ADM) (Thank you Luís!): http://files.meetup.com/18234529/luis_marques_anemic_domain_models.pdf This presentation made me realize why I've been struggling with clean OOP designs even for very simple programs (e.g. simple games like shut the box, master mind, etc.). I will read more on ADM starting with this one: https://blog.inf.ed.ac.uk/sapm/2014/02/04/the-anaemic-domain-model-is-no-anti-pattern-its-a-solid-design/ Ali
Re: Silicon Valley D Meetup January 28, 2016
On 01/28/2016 08:37 PM, Adam D. Ruppe wrote: > I've been listening in on this Why didn't you say hi? :) This has been the first time that we didn't have the attendance list open, so we didn't even know whether others were connected. Come to think of it, I think we were seeing just two connections: Luís and us. Perhaps it was showing just the attendees who had video enabled? Anyway... > and the talk about @nogc on constructors highlights the need to me > of having more attribute inference. Is there a reason why only auto functions have attribute inference? Why not infer all attributes unless they are overridden by explicit attributes? > Yes, it works on templates, but not all methods are templates. Agreed. Ali
