Re: Beta release DUB 1.0.0-beta.1
On 2016-06-07 20:42, Sönke Ludwig wrote: No, it has to be the "+" variant (the first /+ +/ comment is evaluated). That's unfortunate. -- /Jacob Carlborg
LDC+Dub+Vibe.d work on SmartOS 64bit now
At first, we have build ldc-lts-master on OmniOS(32bit arch). We did some corrections in AddLLVM.cmake file for build llvm_3.8. And soon we have received working "Hello world" on Dlang. But when we try to build vibe.d it fall down. We should had do some corrections in vide.d source. After this vibe.d began working on OmniOS and SmartOS 32bit. But in SmartOS 64 bit not only vibe.d not compiling, even "Hello world" not working. Many hours of analyzing and correcting errors during build bring success. Vibe.d works fine with libevent configuration in OmniOS, SmartOS 32bit and SmartOS 64bit. All corrections are commited to druntime, phobos and vibe.d by Nykytenko Oleg. PS. If anybody need more details, we will be happy to help and write completely "HOWTO"
Re: LDC 1.0.0 has been released!
Was there anything changed regarding -od / -op / -oq behaviour? I am getting DCD build errors with new LDC because object files are emitted to a different place it expects.
Re: LDC+Dub+Vibe.d work on SmartOS 64bit now
On Wednesday, 8 June 2016 at 08:00:03 UTC, Alexandr Basko wrote: At first, we have build ldc-lts-master on OmniOS(32bit arch). We did some corrections in AddLLVM.cmake file for build llvm_3.8. And soon we have received working "Hello world" on Dlang. But when we try to build vibe.d it fall down. We should had do some corrections in vide.d source. After this vibe.d began working on OmniOS and SmartOS 32bit. But in SmartOS 64 bit not only vibe.d not compiling, even "Hello world" not working. Many hours of analyzing and correcting errors during build bring success. Vibe.d works fine with libevent configuration in OmniOS, SmartOS 32bit and SmartOS 64bit. All corrections are commited to druntime, phobos and vibe.d by Nykytenko Oleg. PS. If anybody need more details, we will be happy to help and write completely "HOWTO" Have you run the standard library's tests? There was a thread last summer about this: http://forum.dlang.org/thread/zhcduibirwprgbzqk...@forum.dlang.org
Re: Beta release DUB 1.0.0-beta.1
Am 08.06.2016 um 08:59 schrieb Jacob Carlborg: On 2016-06-07 20:42, Sönke Ludwig wrote: No, it has to be the "+" variant (the first /+ +/ comment is evaluated). That's unfortunate. I generally really do appreciate your critique, but without backing reasons it doesn't really have a constructive effect. Two good properties about restricting to /+ +/ is that it's still possible to put something else in front of it, and that it stands out from the usual /* */ comments. Sure arguments can be made for supporting all comment types, but it shouldn't be forgotten that in the end this is a question of absolutely minimal impact. Just to be clear: If anyone has a good argument for supporting more/all comment types and there are no equally good arguments against it, please go ahead and implement it and it will be included. Let's just make this a quick decision, because changing it later on will mean breakage no matter how it's done.
Re: foo => "bar" key/value literals in D!
On Friday, 27 May 2016 at 18:10:59 UTC, Vladimir Panteleev wrote: This is by far the most appealing way to implement named arguments that I've seen so far: https://github.com/CyberShadow/ae/blob/master/utils/meta/args.d Another cool thing this enables: object initializers. T init(T, Args...)() { import std.traits : FunctionTypeOf; static struct DummyType {} static if (is(T == class)) T r = new T; else T r; foreach (arg; Args) { alias fun = arg!DummyType; static if (is(FunctionTypeOf!fun PT == __parameters)) { enum name = __traits(identifier, PT); foreach (m; __traits(allMembers, T)) { static if (name == m) __traits(getMember, r, m) = fun(DummyType.init); } } } return r; } struct Point { int x, y; } void main() { auto pt = init!(Point, x => 123, y => 456); assert(pt.x == 123 && pt.y == 456); }
Re: LDC+Dub+Vibe.d work on SmartOS 64bit now
On Wednesday, 8 June 2016 at 08:43:59 UTC, Joakim wrote: Have you run the standard library's tests? There was a thread last summer about this: http://forum.dlang.org/thread/zhcduibirwprgbzqk...@forum.dlang.org We haven't run library's tests. What right way to run this tests? But: We ported our sufficiently big server application from Linux to SmartOS x64. All application tests is OK. Application working now on testing server in production like regime under full load. And it's working fine. We're planning to use it in production in future. Vibe.d simple http/https/web test applications work fine too.
Re: Beta release vibe.d 0.7.29-beta.2
On Thursday, 2 June 2016 at 08:27:03 UTC, Sönke Ludwig wrote: The release candidate is planned for the 6th, so please take a moment to test this release. There are two problems after the upgrade. 1. subConfiguration "vibe-d" "win32" not applied to "vibe-d:core" https://github.com/rejectedsoftware/vibe.d/issues/1513 2. vibe-d/examples/http_server asserts when using win32 subconfiguration. https://github.com/rejectedsoftware/vibe.d/pull/1514 The previous build used "vibe-d": "0.7.26".
Re: LDC+Dub+Vibe.d work on SmartOS 64bit now
On Wednesday, 8 June 2016 at 10:06:00 UTC, Oleg Nykytenko wrote: On Wednesday, 8 June 2016 at 08:43:59 UTC, Joakim wrote: Have you run the standard library's tests? There was a thread last summer about this: http://forum.dlang.org/thread/zhcduibirwprgbzqk...@forum.dlang.org We haven't run library's tests. What right way to run this tests? But: We ported our sufficiently big server application from Linux to SmartOS x64. All application tests is OK. Application working now on testing server in production like regime under full load. And it's working fine. We're planning to use it in production in future. Vibe.d simple http/https/web test applications work fine too. That's great to hear. :) If I were you though, I'd at least double-check by running the ldc tests, as I don't think others are using that platform. With ldc, I believe it's just "make test".
Re: Beta release vibe.d 0.7.29-beta.2
On Wednesday, 8 June 2016 at 11:30:07 UTC, akaDemik wrote: On Thursday, 2 June 2016 at 08:27:03 UTC, Sönke Ludwig wrote: The release candidate is planned for the 6th, so please take a moment to test this release. There are two problems after the upgrade. 1. subConfiguration "vibe-d" "win32" not applied to "vibe-d:core" https://github.com/rejectedsoftware/vibe.d/issues/1513 2. vibe-d/examples/http_server asserts when using win32 subconfiguration. https://github.com/rejectedsoftware/vibe.d/pull/1514 The previous build used "vibe-d": "0.7.26". Oh sorry. #1513 only for "vibe-d": "0.7.28". It works fine in version 0.7.29-beta.2`. #1514 -- still open.
Re: LDC+Dub+Vibe.d work on SmartOS 64bit now
On Wednesday, 8 June 2016 at 08:00:03 UTC, Alexandr Basko wrote: At first, we have build ldc-lts-master on OmniOS(32bit arch). We did some corrections in AddLLVM.cmake file for build llvm_3.8. And soon we have received working "Hello world" on Dlang. But when we try to build vibe.d it fall down. We should had do some corrections in vide.d source. After this vibe.d began working on OmniOS and SmartOS 32bit. But in SmartOS 64 bit not only vibe.d not compiling, even "Hello world" not working. Many hours of analyzing and correcting errors during build bring success. Vibe.d works fine with libevent configuration in OmniOS, SmartOS 32bit and SmartOS 64bit. All corrections are commited to druntime, phobos and vibe.d by Nykytenko Oleg. PS. If anybody need more details, we will be happy to help and write completely "HOWTO" Excellent! Please post a howto. I would very much like to move my server from an LX branded zone to SmartOS.
Re: Beta release DUB 1.0.0-beta.1
On 2016-06-08 11:15, Sönke Ludwig wrote: I generally really do appreciate your critique, but without backing reasons it doesn't really have a constructive effect. Two good properties about restricting to /+ +/ is that it's still possible to put something else in front of it, and that it stands out from the usual /* */ comments. Sure arguments can be made for supporting all comment types, but it shouldn't be forgotten that in the end this is a question of absolutely minimal impact. Just to be clear: If anyone has a good argument for supporting more/all comment types and there are no equally good arguments against it, please go ahead and implement it and it will be included. Let's just make this a quick decision, because changing it later on will mean breakage no matter how it's done. It's just that since the language support other styles of comments one could think that all comments are supported and it will cause confusion if only one style is supported. Otherwise it might be better to use a UDA, if possible. If one reads the documentation and copy pastes and example the user will most likely get it right. But if you have a conversation saying something like "it's possible to put the content of dub.json inline in the source code, just put it in a comment" then someone will for sure try using a comment style that is not supported. The documentation needs to be very clear that only one type comments are supported, if that's the conclusion. -- /Jacob Carlborg
Re: Beta release DUB 1.0.0-beta.1
On Wednesday, 8 June 2016 at 12:21:57 UTC, Jacob Carlborg wrote: It's just that since the language support other styles of comments one could think that all comments are supported and it will cause confusion if only one style is supported. That reason alone is enough. Restricting DUB special comments to only /++/ will put users off, because now they know that there's a cool feature in DUB, but it only works with certain types of comments, that nobody wants to remember (why should they?), so they will decide that this feature is either broken or unfinished and will hardly use it at all. We could make users' lives easier, if we allowed them to just specify the dependencies in Gradle style on a single line: #!/usr/bin/env dub // dependencies: "color:~>0.0.3", "vibe.d:~>0.7.28"
Recursive SymbolNames solved.
Hi, I solved the issue. PR is coming shortly.
Re: LDC+Dub+Vibe.d work on SmartOS 64bit now
On Wednesday, 8 June 2016 at 11:30:50 UTC, Joakim wrote: On Wednesday, 8 June 2016 at 10:06:00 UTC, Oleg Nykytenko wrote: On Wednesday, 8 June 2016 at 08:43:59 UTC, Joakim wrote: [...] We haven't run library's tests. What right way to run this tests? But: We ported our sufficiently big server application from Linux to SmartOS x64. All application tests is OK. Application working now on testing server in production like regime under full load. And it's working fine. We're planning to use it in production in future. Vibe.d simple http/https/web test applications work fine too. That's great to hear. :) If I were you though, I'd at least double-check by running the ldc tests, as I don't think others are using that platform. With ldc, I believe it's just "make test". Ok. I try to run these tests on server. Tomorrow i will post results, then i came back to working place
Re: LDC+Dub+Vibe.d work on SmartOS 64bit now
On Wednesday, 8 June 2016 at 12:19:08 UTC, flamencofantasy wrote: On Wednesday, 8 June 2016 at 08:00:03 UTC, Alexandr Basko wrote: [...] Excellent! Please post a howto. I would very much like to move my server from an LX branded zone to SmartOS. Can I post howto in this thread? If yes, than i`m post it tomorrow also
Re: Beta release vibe.d 0.7.29-beta.2
Am 08.06.2016 um 13:53 schrieb akaDemik: On Wednesday, 8 June 2016 at 11:30:07 UTC, akaDemik wrote: On Thursday, 2 June 2016 at 08:27:03 UTC, Sönke Ludwig wrote: The release candidate is planned for the 6th, so please take a moment to test this release. There are two problems after the upgrade. 1. subConfiguration "vibe-d" "win32" not applied to "vibe-d:core" https://github.com/rejectedsoftware/vibe.d/issues/1513 2. vibe-d/examples/http_server asserts when using win32 subconfiguration. https://github.com/rejectedsoftware/vibe.d/pull/1514 The previous build used "vibe-d": "0.7.26". Oh sorry. #1513 only for "vibe-d": "0.7.28". It works fine in version 0.7.29-beta.2`. #1514 -- still open. Pulled #1514 into the 0.7.29 branch, will be in 0.7.29-rc.1. Thanks for doing the PR!
Re: Beta release DUB 1.0.0-beta.1
Am 08.06.2016 um 15:27 schrieb burjui: On Wednesday, 8 June 2016 at 12:21:57 UTC, Jacob Carlborg wrote: It's just that since the language support other styles of comments one could think that all comments are supported and it will cause confusion if only one style is supported. That reason alone is enough. Restricting DUB special comments to only /++/ will put users off, because now they know that there's a cool feature in DUB, but it only works with certain types of comments, that nobody wants to remember (why should they?), so they will decide that this feature is either broken or unfinished and will hardly use it at all. We could make users' lives easier, if we allowed them to just specify the dependencies in Gradle style on a single line: #!/usr/bin/env dub // dependencies: "color:~>0.0.3", "vibe.d:~>0.7.28" But the user *will* remember the filename + colon requirement? Or will remember yet another format to specify dependencies? What if something else, such as compiler flags or link libraries need to be specified? I'll stay out of this discussion until there is a conclusion now.
Re: LDC+Dub+Vibe.d work on SmartOS 64bit now
On Wednesday, 8 June 2016 at 13:41:59 UTC, Alexandr Basko wrote: On Wednesday, 8 June 2016 at 12:19:08 UTC, flamencofantasy wrote: On Wednesday, 8 June 2016 at 08:00:03 UTC, Alexandr Basko wrote: [...] Excellent! Please post a howto. I would very much like to move my server from an LX branded zone to SmartOS. Can I post howto in this thread? If yes, than i`m post it tomorrow also Yes, please. Or if that's too much trouble just send to my email. Thanks!
Re: The Official D Blog is Live
On Tuesday, 7 June 2016 at 22:18:57 UTC, Ali Çehreli wrote: On 06/07/2016 12:19 PM, Mike Parker wrote: On Tuesday, 7 June 2016 at 18:50:47 UTC, Jesse Phillips wrote: I think each post should have an author displayed. While this likely will be the same person, I think it is good to have it called out repeatedly so one doesn't have to find the first post to see who is posting. It will also make it very clear when there is a guest poster. The author name is displayed at the bottom of each post then single post page (i.e. when you click the post title on the main page). I didn't notice it wasn't showing on the main page. I'll see about adding it. Both the author and the date of a blog post is important. I would like to see botthat information right under the title. Ok, now the author and the date is at the top of every post, front page and single post page. Looks better. Thanks, guys!
Re: Beta release DUB 1.0.0-beta.1
On Wednesday, 8 June 2016 at 13:27:31 UTC, burjui wrote: That reason alone is enough. Restricting DUB special comments to only /++/ will put users off, because now they know that there's a cool feature in DUB, but it only works with certain types of comments, that nobody wants to remember (why should they?), so they will decide that this feature is either broken or unfinished and will hardly use it at all. We could make users' lives easier, if we allowed them to just specify the dependencies in Gradle style on a single line: #!/usr/bin/env dub // dependencies: "color:~>0.0.3", "vibe.d:~>0.7.28" I don't understand this argument. There are two options: /++/ and /**/. If a user can't remember which one it is, it's a matter of a few seconds to find out. With all the things we need to remember about a language when programming, I hardly think something of this nature is going to put anyone off. And if they *are* put off by it, they've got bigger issues than trying to remember which comment style to use.
Re: The Official D Blog is Live
Is it possible to announce the new This Week In D from the blog when it comes out?
Re: Beta release DUB 1.0.0-beta.1
On 6/8/16 8:21 AM, Jacob Carlborg wrote: On 2016-06-08 11:15, Sönke Ludwig wrote: I generally really do appreciate your critique, but without backing reasons it doesn't really have a constructive effect. Two good properties about restricting to /+ +/ is that it's still possible to put something else in front of it, and that it stands out from the usual /* */ comments. Sure arguments can be made for supporting all comment types, but it shouldn't be forgotten that in the end this is a question of absolutely minimal impact. Just to be clear: If anyone has a good argument for supporting more/all comment types and there are no equally good arguments against it, please go ahead and implement it and it will be included. Let's just make this a quick decision, because changing it later on will mean breakage no matter how it's done. It's just that since the language support other styles of comments one could think that all comments are supported and it will cause confusion if only one style is supported. Otherwise it might be better to use a UDA, if possible. If one reads the documentation and copy pastes and example the user will most likely get it right. But if you have a conversation saying something like "it's possible to put the content of dub.json inline in the source code, just put it in a comment" then someone will for sure try using a comment style that is not supported. The documentation needs to be very clear that only one type comments are supported, if that's the conclusion. I agree with Jacob. A comment is a comment. There is no reason one needs to use specifically /+. In fact the only reason for the existence of /+ is to allow nesting of comments -- which doesn't apply here. I'd say you should support // comments as well. There's another aspect here, in that most people (even core D developers) use the /* comment style */. So someone seeing the /+ comment might think this is a specialized dub thing. I will finally say this: if such an implementation update existed, what would be the reason NOT to pull it? That is, I think literally the only reason not to support /* for this purpose is that nobody has done the work. If you can give no better reason, it should take away any barriers for anyone wishing to create this improvement. -Steve
Re: Beta release DUB 1.0.0-beta.1
On Wednesday, 8 June 2016 at 09:15:09 UTC, Sönke Ludwig wrote: Two good properties about restricting to /+ +/ is that it's still possible to put something else in front of it, and that it stands out from the usual /* */ comments. It stands out because we don't have a recognizable convention for such... processing instructions, every tool uses its own. BTW do people find nested comments particularly useful?
Nested comments
On Wednesday, 8 June 2016 at 15:04:28 UTC, Kagamin wrote: BTW do people find nested comments particularly useful? Yes for: A) commenting out a block of code without having to care about syntactic correctness (otherwise version(none)) or whether it contains comments (otherwise /* */) B) code examples inside comments
Re: LDC+Dub+Vibe.d work on SmartOS 64bit now
On Wednesday, 8 June 2016 at 13:41:59 UTC, Alexandr Basko wrote: On Wednesday, 8 June 2016 at 12:19:08 UTC, flamencofantasy wrote: On Wednesday, 8 June 2016 at 08:00:03 UTC, Alexandr Basko wrote: [...] Excellent! Please post a howto. I would very much like to move my server from an LX branded zone to SmartOS. Can I post howto in this thread? If yes, than i`m post it tomorrow also You could make a new page on the wiki so the Howto will be easier to locate.
Re: Nested comments
On Wednesday, 8 June 2016 at 15:21:08 UTC, John Colvin wrote: On Wednesday, 8 June 2016 at 15:04:28 UTC, Kagamin wrote: BTW do people find nested comments particularly useful? Yes for: A) commenting out a block of code without having to care about syntactic correctness (otherwise version(none)) or whether it contains comments (otherwise /* */) B) code examples inside comments same two points for me too.
Re: LDC+Dub+Vibe.d work on SmartOS 64bit now
On Wednesday, 8 June 2016 at 10:06:00 UTC, Oleg Nykytenko wrote: On Wednesday, 8 June 2016 at 08:43:59 UTC, Joakim wrote: Have you run the standard library's tests? There was a thread last summer about this: http://forum.dlang.org/thread/zhcduibirwprgbzqk...@forum.dlang.org We haven't run library's tests. What right way to run this tests? But: We ported our sufficiently big server application from Linux to SmartOS x64. All application tests is OK. Application working now on testing server in production like regime under full load. And it's working fine. We're planning to use it in production in future. Are you interested in running a buildbot for LDC on your platform to detect issues early? See: http://forum.dlang.org/thread/hikcbbqqnpvvyirxg...@forum.dlang.org Thanks, Johan
Re: Web page listing all D compilers (and DMDFE version!) on travis-ci
On 06/07/2016 12:05 PM, FreeSlave wrote: On Tuesday, 26 April 2016 at 06:42:11 UTC, Nick Sabalausky wrote: https://semitwist.com/travis-d-compilers That's an auto-generated listing of all versions of DMD, GDC and LDC available on travis-ci. [...] Looks like semitwist.com is down. Oops. It's back up now. How about duplicating this list to github pages? Not a bad idea. https://github.com/Abscissa/travis-dc-detect-master/issues/4
Berlin D Meetup June 2016
Hi All, The June Berlin D Meetup will be happening at 20:00 (note new time) on Friday the 17th of June at Berlin Co-Op (http://co-up.de/) on the fifth floor. Danny Arends will be giving a more detailed version of his lightning talk he gave at the D conference on his web server, "DaNode". Both alcoholic and non-alcoholic drinks will be available. More details and an abstract of the talk are available on the meetup page here: http://www.meetup.com/Berlin-D-Programmers/events/231746496/ Thanks, Ben.
Re: Beta release DUB 1.0.0-beta.1
On 2016-06-08 16:58, Steven Schveighoffer wrote: I agree with Jacob. A comment is a comment. There is no reason one needs to use specifically /+. In fact the only reason for the existence of /+ is to allow nesting of comments -- which doesn't apply here. And basically the only reason why /+ exists and /* doesn't allow nesting is to be compatible with C. -- /Jacob Carlborg
Re: The Official D Blog is Live
On Wednesday, 8 June 2016 at 14:45:07 UTC, bachmeier wrote: Is it possible to announce the new This Week In D from the blog when it comes out? That sort of post doesn't really fit within the goals of the blog. I mean, TWID is put out every Sunday. That would mean I'd make a two or three line blurb of the nature, "There's a new TWID out" every Sunday. That's what the Announce forum is for, and even Adam doesn't announce the new TWID every week. I do intend to contact Adam about a TWID-related post, though (I've already got some others lined up for some interesting content). That's much more valuable, IMO, and fits better with the goals of the blog. And, of course, any time I can fit it in to the context of a given post, I'll certainly remind people to check TWID out. Every post should have value on its own other than being a simple announcement with a link. And now that you've brought this up, I've just realized there are no links to TWID in the dlang.org menus. I'll have to add one to the side bar of the blog.
Re: The Official D Blog is Live
On Wednesday, 8 June 2016 at 16:44:35 UTC, Mike Parker wrote: On Wednesday, 8 June 2016 at 14:45:07 UTC, bachmeier wrote: Is it possible to announce the new This Week In D from the blog when it comes out? That sort of post doesn't really fit within the goals of the blog. I mean, TWID is put out every Sunday. That would mean I'd make a two or three line blurb of the nature, "There's a new TWID out" every Sunday. That's what the Announce forum is for, and even Adam doesn't announce the new TWID every week. +1 I do intend to contact Adam about a TWID-related post, though (I've already got some others lined up for some interesting content). That's much more valuable, IMO, and fits better with the goals of the blog. And, of course, any time I can fit it in to the context of a given post, I'll certainly remind people to check TWID out. Every post should have value on its own other than being a simple announcement with a link. And now that you've brought this up, I've just realized there are no links to TWID in the dlang.org menus. I'll have to add one to the side bar of the blog. It has even a better spot - the "News" section of the front page. Speaking of which: now that we have have an official D Blog, maybe we can put the latest headline of the official blog to the news section?
Re: Recursive SymbolNames solved.
On Wednesday, 8 June 2016 at 13:28:19 UTC, Stefan Koch wrote: Hi, I solved the issue. PR is coming shortly. How was they getting recursive?
Re: Beta release DUB 1.0.0-beta.1
Am 08.06.2016 um 16:58 schrieb Steven Schveighoffer: I agree with Jacob. A comment is a comment. Well, there are normal comments, doc comments and now DUB recipe comments. But at least if doc comments serve as an analogy, those are possible with all three comment styles, so that could be taken as a consistency argument. > There is no reason one needs to use specifically /+. In fact the only reason for the existence of /+ is to allow nesting of comments -- which doesn't apply here. I'd say you should support // comments as well. SDLang supports C and C++ style comments as well, so could in fact apply here. But probably you'd usually use // style comments in that case. There's another aspect here, in that most people (even core D developers) use the /* comment style */. So someone seeing the /+ comment might think this is a specialized dub thing. Would there be any harm? Looking it up in either DUB's or DMD's documentation would clarify that. I will finally say this: if such an implementation update existed, what would be the reason NOT to pull it? That is, I think literally the only reason not to support /* for this purpose is that nobody has done the work. If you can give no better reason, it should take away any barriers for anyone wishing to create this improvement. Apart from what I've already mentioned in my first reply to Jacob, I think there is nothing else that couldn't be solved in either case. Okay, so at least 3 people favor supporting other comment styles, while I'm not convinced that supporting all comment styles is necessarily better, I wouldn't mind pulling an update. The relevant code section is here: https://github.com/dlang/dub/blob/b02c18991b0cb4627eb0c943efd6ca3e69192751/source/dub/dub.d#L288 It would probably make sense to unify the comment matcher with the one here, which currently doesn't support /+ +/ comments: https://github.com/dlang/dub/blob/b02c18991b0cb4627eb0c943efd6ca3e69192751/source/dub/internal/utils.d#L430 1.0.0-rc.1 is scheduled for Monday morning, so it should ready by then to avoid stretching the release schedule (it's technically a breaking change!).
Re: Beta release DUB 1.0.0-beta.1
On Wed, Jun 8, 2016 at 11:15 AM, Sönke Ludwig wrote: > Am 08.06.2016 um 08:59 schrieb Jacob Carlborg: >> >> On 2016-06-07 20:42, Sönke Ludwig wrote: >> >>> No, it has to be the "+" variant (the first /+ +/ comment is evaluated). >> >> >> That's unfortunate. > > > I generally really do appreciate your critique, but without backing reasons > it doesn't really have a constructive effect. > > Two good properties about restricting to /+ +/ is that it's still possible > to put something else in front of it, and that it stands out from the usual > /* */ comments. Sure arguments can be made for supporting all comment types, > but it shouldn't be forgotten that in the end this is a question of > absolutely minimal impact. > > Just to be clear: If anyone has a good argument for supporting more/all > comment types and there are no equally good arguments against it, please go > ahead and implement it and it will be included. Let's just make this a quick > decision, because changing it later on will mean breakage no matter how it's > done. The only thing I can think to change would be that it doesn't have to be the _first_ '/+...' but rather the first regex: \n\/\+\s*dub\.(sdl|json):?\n(.*)\n\+\/\n See [0] for regex in action on the code below. Sometimes we might want to put the dub config just above the main function, and a lot of people like that to be at the bottom of the file (who knows what comments might be above that and we wouldn't want to break the way /+ ... +/ can be used anywhere to comment out code / comments. concrete example: #!/usr/bin/env dub /** * Copyright (C) blah blah blah * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice * Some long copyright notice */ /+ // Example and/or documentation on changing this program Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code /* * Note that when doing the below !not threadsafe!... * see next example for threadsafe version. */ Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code /* * This is the threadsafe version of above both are provided. * threadsafe version is not quite as fast */ Some codeSome codeSome codeSome code Some codeSome codeSome codeSome code // this line has to be here Some codeSome codeSome codeSome code +/ /+ dub.sdl: name "colortest" dependency "color" version="~>0.0.3" +/ // implementation of support functions void main(string[] args) { ... } [0] https://regex101.com/r/dR7xY1/1
Re: Beta release DUB 1.0.0-beta.1
On Wed, Jun 8, 2016 at 8:45 PM, Sönke Ludwig wrote: ... > 1.0.0-rc.1 is scheduled for Monday morning, so it should ready by then to > avoid stretching the release schedule (it's technically a breaking change!). I just tried this inside a directory that happened to be a dub project, it seemed like dub tried to build both the test file and the dub project as one. I see that it puts the compiled binary in the same directory as the .d file. This makes it not possible to deploy to e.g. /usr/local/bin/. What is the expected isolation of a single file dub project?
Re: Beta release DUB 1.0.0-beta.1
regex version pull request: https://github.com/dlang/dub/pull/869 On Wed, Jun 8, 2016 at 8:50 PM, Rory McGuire wrote: > On Wed, Jun 8, 2016 at 11:15 AM, Sönke Ludwig > wrote: >> Am 08.06.2016 um 08:59 schrieb Jacob Carlborg: >>> >>> On 2016-06-07 20:42, Sönke Ludwig wrote: >>> No, it has to be the "+" variant (the first /+ +/ comment is evaluated). >>> >>> >>> That's unfortunate. >> >> >> I generally really do appreciate your critique, but without backing reasons >> it doesn't really have a constructive effect. >> >> Two good properties about restricting to /+ +/ is that it's still possible >> to put something else in front of it, and that it stands out from the usual >> /* */ comments. Sure arguments can be made for supporting all comment types, >> but it shouldn't be forgotten that in the end this is a question of >> absolutely minimal impact. >> >> Just to be clear: If anyone has a good argument for supporting more/all >> comment types and there are no equally good arguments against it, please go >> ahead and implement it and it will be included. Let's just make this a quick >> decision, because changing it later on will mean breakage no matter how it's >> done. > > The only thing I can think to change would be that it doesn't have to > be the _first_ '/+...' but rather the first regex: > \n\/\+\s*dub\.(sdl|json):?\n(.*)\n\+\/\n > > See [0] for regex in action on the code below. > > Sometimes we might want to put the dub config just above the main > function, and a lot of people like that to be at the bottom of the > file (who knows what comments might be above that and we wouldn't want > to break the way /+ ... +/ can be used anywhere to comment out code / > comments. > > concrete example: > #!/usr/bin/env dub > /** > * Copyright (C) blah blah blah > * Some long copyright notice > * Some long copyright notice > * Some long copyright notice > * Some long copyright notice > * Some long copyright notice > * Some long copyright notice > * Some long copyright notice > * Some long copyright notice > */ > /+ > // Example and/or documentation on changing this program > Some codeSome codeSome codeSome code > Some codeSome codeSome codeSome code > /* > * Note that when doing the below !not threadsafe!... > * see next example for threadsafe version. > */ > Some codeSome codeSome codeSome code > Some codeSome codeSome codeSome code > Some codeSome codeSome codeSome code > Some codeSome codeSome codeSome code > /* > * This is the threadsafe version of above both are provided. > * threadsafe version is not quite as fast > */ > Some codeSome codeSome codeSome code > Some codeSome codeSome codeSome code // this line has to be here > Some codeSome codeSome codeSome code > > +/ > > /+ dub.sdl: > name "colortest" > dependency "color" version="~>0.0.3" > +/ > > // implementation of support functions > > void main(string[] args) { > ... > } > > > [0] https://regex101.com/r/dR7xY1/1
Re: Recursive SymbolNames solved.
On Wednesday, 8 June 2016 at 13:28:19 UTC, Stefan Koch wrote: Hi, I solved the issue. PR is coming shortly. Dude come on, that isn't an announce. There is No PR, there is no description of the solution, there is nothing. Hey guys, I cured cancer and solved world hunger. PR coming soon.
Re: Beta release DUB 1.0.0-beta.1
Am 08.06.2016 um 21:20 schrieb Rory McGuire via Digitalmars-d-announce: On Wed, Jun 8, 2016 at 8:45 PM, Sönke Ludwig wrote: ... 1.0.0-rc.1 is scheduled for Monday morning, so it should ready by then to avoid stretching the release schedule (it's technically a breaking change!). I just tried this inside a directory that happened to be a dub project, it seemed like dub tried to build both the test file and the dub project as one. I see that it puts the compiled binary in the same directory as the .d file. This makes it not possible to deploy to e.g. /usr/local/bin/. What is the expected isolation of a single file dub project? Everything regarding the single-file package is supposed to stay in the temp directory and only the file itself is supposed to be considered as a source file. Fix: https://github.com/dlang/dub/pull/870
Re: Recursive SymbolNames solved.
On Wednesday, 8 June 2016 at 18:02:41 UTC, Jerry wrote: On Wednesday, 8 June 2016 at 13:28:19 UTC, Stefan Koch wrote: Hi, I solved the issue. PR is coming shortly. How was they getting recursive? Think to the fibo templatized example, it generates a very long mangle with basically always the same symbol.
Re: Recursive SymbolNames solved.
On Wednesday, 8 June 2016 at 19:41:49 UTC, deadalnix wrote: On Wednesday, 8 June 2016 at 13:28:19 UTC, Stefan Koch wrote: Hi, I solved the issue. PR is coming shortly. Dude come on, that isn't an announce. There is No PR, there is no description of the solution, there is nothing. Hey guys, I cured cancer and solved world hunger. PR coming soon. Lol ! My turn: I'm a genious but I haven't done anything genial yet...
Re: Beta release DUB 1.0.0-beta.1
I made a little parser, it doesn't handle nested + comments (just needs a depth check). https://github.com/dlang/dub/pull/871 On Wed, Jun 8, 2016 at 9:44 PM, Rory McGuire wrote: > regex version pull request: > https://github.com/dlang/dub/pull/869 > > On Wed, Jun 8, 2016 at 8:50 PM, Rory McGuire wrote: >> On Wed, Jun 8, 2016 at 11:15 AM, Sönke Ludwig >> wrote: >>> Am 08.06.2016 um 08:59 schrieb Jacob Carlborg: On 2016-06-07 20:42, Sönke Ludwig wrote: > No, it has to be the "+" variant (the first /+ +/ comment is evaluated). That's unfortunate. >>> >>> >>> I generally really do appreciate your critique, but without backing reasons >>> it doesn't really have a constructive effect. >>> >>> Two good properties about restricting to /+ +/ is that it's still possible >>> to put something else in front of it, and that it stands out from the usual >>> /* */ comments. Sure arguments can be made for supporting all comment types, >>> but it shouldn't be forgotten that in the end this is a question of >>> absolutely minimal impact. >>> >>> Just to be clear: If anyone has a good argument for supporting more/all >>> comment types and there are no equally good arguments against it, please go >>> ahead and implement it and it will be included. Let's just make this a quick >>> decision, because changing it later on will mean breakage no matter how it's >>> done. >> >> The only thing I can think to change would be that it doesn't have to >> be the _first_ '/+...' but rather the first regex: >> \n\/\+\s*dub\.(sdl|json):?\n(.*)\n\+\/\n >> >> See [0] for regex in action on the code below. >> >> Sometimes we might want to put the dub config just above the main >> function, and a lot of people like that to be at the bottom of the >> file (who knows what comments might be above that and we wouldn't want >> to break the way /+ ... +/ can be used anywhere to comment out code / >> comments. >> >> concrete example: >> #!/usr/bin/env dub >> /** >> * Copyright (C) blah blah blah >> * Some long copyright notice >> * Some long copyright notice >> * Some long copyright notice >> * Some long copyright notice >> * Some long copyright notice >> * Some long copyright notice >> * Some long copyright notice >> * Some long copyright notice >> */ >> /+ >> // Example and/or documentation on changing this program >> Some codeSome codeSome codeSome code >> Some codeSome codeSome codeSome code >> /* >> * Note that when doing the below !not threadsafe!... >> * see next example for threadsafe version. >> */ >> Some codeSome codeSome codeSome code >> Some codeSome codeSome codeSome code >> Some codeSome codeSome codeSome code >> Some codeSome codeSome codeSome code >> /* >> * This is the threadsafe version of above both are provided. >> * threadsafe version is not quite as fast >> */ >> Some codeSome codeSome codeSome code >> Some codeSome codeSome codeSome code // this line has to be here >> Some codeSome codeSome codeSome code >> >> +/ >> >> /+ dub.sdl: >> name "colortest" >> dependency "color" version="~>0.0.3" >> +/ >> >> // implementation of support functions >> >> void main(string[] args) { >> ... >> } >> >> >> [0] https://regex101.com/r/dR7xY1/1
Re: Beta D 2.071.1-b2
On Sunday, 29 May 2016 at 21:53:23 UTC, Martin Nowak wrote: Second beta for the 2.071.1 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.071.1.html Please report any bugs at https://issues.dlang.org -Martin 2.072 is getting rather long in the tooth: https://github.com/dlang/phobos/blob/master/changelog.dd. I think that's the largest change log for Phobos I have seen. When are you planning on branching master?
Re: Beta release DUB 1.0.0-beta.1
On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote: DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is... Great work! I've spread the news to all my hackish friends.
Re: LDC 1.0.0 has been released!
On Monday, 6 June 2016 at 10:45:39 UTC, Guillaume Piolat wrote: On Monday, 6 June 2016 at 07:25:49 UTC, tester wrote: On Monday, 6 June 2016 at 07:00:56 UTC, Kai Nacke wrote: Hi everyone, It is a great pleasure to announce that version 1.0.0 of LDC, the LLVM-based D compiler, is now available for download! The release is based on the 2.070.2 frontend and standard library and supports LLVM 3.5-3.8. We provide binaries for Linux, OX X, Win32 & Win64, Linux/ARM (armv7hf). :-) As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/lwsnqbravjqbnnryv...@forum.dlang.org Regards, Kai very nice! how about a howto for windows/VS users? Hi, Here is what I've learned: - use VS 2015 preferably, - since a while the stock LDC package work as is, nothing to configure, - use PATH and --compiler=ldc2 or --compiler=path/to/compiler.exe to tell dub where LDC is (separate packages for 32-bit and 64-bit), - to avoid a dependency on the VS 2015 runtime, add the following linker flags: "lflags-windows-ldc": [ "libcmt.lib", "/nodefaultlib:msvcrt.lib", "/nodefaultlib:vcruntime.lib" ], - executables made with LDC are not supported on XP and Vista, but seem to work regardless :) Thanks! See https://github.com/ldc-developers/ldc-scripts/pull/1 Regards, Kai
Re: Recursive SymbolNames solved.
On Wednesday, 8 June 2016 at 13:28:19 UTC, Stefan Koch wrote: Hi, I solved the issue. PR is coming shortly. Solution is as follows: Keep a list of already visited symbols in the mangler. And information where we store the mangle. meaning the position in the mangle string. If a symbol is encountered for the second time store a backrefernce rather then the symbol name again.