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 support for single-file packages, which can be used to write shebang-style scripts on Posix systems: [...] I've barely started using D, but dub works like a charm and makes development so easy! Thank you for creating such a great tool! :D
Re: Beta release DUB 1.0.0-beta.1
On 6/9/16 4:37 PM, Sönke Ludwig wrote:
Am 09.06.2016 um 15:06 schrieb Steven Schveighoffer:
On 6/8/16 2:45 PM, Sönke Ludwig wrote:
(...)
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.
"It's still possible to put something else in front of it"
I didn't get this. How is /+ different from /*? I thought the only issue
was the nesting.
I mean together with the restriction that it has to be the first /+ +/
comment, it is possible to put // and /* style comments in front of it
without interference.
Oh, didn't see that aspect. I'll answer this with your last point.
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
Thanks. Perhaps more debate is fruitless until someone steps up with an
implementation :)
Rory has started an implementation: https://github.com/dlang/dub/pull/872
But this has brought up another issue. The idea was to allow the recipe
comment to be anywhere in the file and be of any comment style. However,
that basically almost requires a full D lexer (at least string literals
need to be parsed in addition to the comment styles).
I'm reluctant to include this in the current state, because the results
for a program such as the following will be very confusing:
bool foo(string str)
{
return str.startsWith("/*");
}
/* dub.sdl: ... */
void main()
{
}
The string literal will be recognized as the start of a comment and thus
the real comment below will not be recognized. So I think we should
either have a generic and correct version, or one that is restricted
similar to the current one to sidestep such issues.
I think the idea to include it anywhere in the file is not worth the
trouble. I also wouldn't want to scroll through an entire file for such
a thing.
But it also brings up the point, what if the first /+ comes after:
return str.startsWith("/+");
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!).
How would this be a breaking change? It seems an additive feature, and
I'm not sure it's required to be there before the first 1.0 release.
There could be a /* */ comment before the /+ dub.*: +/ one, which is now
not considered as a recipe comment candidate. Depending on its contents,
the behavior could change once /* */ is also recognized. However, that
case would be easily detectable and a warning could be emitted instead,
while falling back to the old behavior. So it's not really an issue
after all.
Yeah, comments are not hard to parse, if they are the first thing you
are expecting.
I would say it doesn't have to be the first comment, but it has to be
one of the first things in the file. You can simply throw away other
comments.
You may want to just tell the user: look, this isn't perfect, it's not a
D parser. Expect reasonable results for reasonable situations :) If you
have a line of code that looks like it could match the sdl file, then
put the true sdl file above it.
-Steve
Re: Beta release DUB 1.0.0-beta.1
Am 09.06.2016 um 15:06 schrieb Steven Schveighoffer:
On 6/8/16 2:45 PM, Sönke Ludwig wrote:
> (...)
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.
"It's still possible to put something else in front of it"
I didn't get this. How is /+ different from /*? I thought the only issue
was the nesting.
I mean together with the restriction that it has to be the first /+ +/
comment, it is possible to put // and /* style comments in front of it
without interference.
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
Thanks. Perhaps more debate is fruitless until someone steps up with an
implementation :)
Rory has started an implementation: https://github.com/dlang/dub/pull/872
But this has brought up another issue. The idea was to allow the recipe
comment to be anywhere in the file and be of any comment style. However,
that basically almost requires a full D lexer (at least string literals
need to be parsed in addition to the comment styles).
I'm reluctant to include this in the current state, because the results
for a program such as the following will be very confusing:
bool foo(string str)
{
return str.startsWith("/*");
}
/* dub.sdl: ... */
void main()
{
}
The string literal will be recognized as the start of a comment and thus
the real comment below will not be recognized. So I think we should
either have a generic and correct version, or one that is restricted
similar to the current one to sidestep such issues.
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!).
How would this be a breaking change? It seems an additive feature, and
I'm not sure it's required to be there before the first 1.0 release.
There could be a /* */ comment before the /+ dub.*: +/ one, which is now
not considered as a recipe comment candidate. Depending on its contents,
the behavior could change once /* */ is also recognized. However, that
case would be easily detectable and a warning could be emitted instead,
while falling back to the old behavior. So it's not really an issue
after all.
Re: LDC+Dub+Vibe.d work on SmartOS 64bit now
On Thursday, 9 June 2016 at 14:25:07 UTC, Joakim wrote: On Thursday, 9 June 2016 at 12:48:24 UTC, Alexandr Basko wrote: On Wednesday, 8 June 2016 at 13:30:26 UTC, Alexandr Basko wrote: [...] Some tests failed. More than that, they walked to the core.sync.semaphore test and frozen on it (no more resources are eating by OS from last evening: [...] Until you figure it out, you can skip a module's tests with ctest -E, ie "ctest -E core.sync.semaphore". Other results are: [...] You may need to add some library flags for curl, as I did last summer: http://forum.dlang.org/post/eipycgdrrjtuuyglp...@forum.dlang.org I will do these tests (according your recommendations) again on Monday and post results here after getting them.
Re: Recursive SymbolNames solved.
On 09.06.2016 11:02, Johan Engelen wrote: On Thursday, 9 June 2016 at 04:58:45 UTC, Stefan Koch wrote: 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. You mean this? https://github.com/weka-io/ldc/commit/ffd6b55a4b83b3007d9690cbd9a25d07b243a00e This doesn't handle the manglers created locally for templates and parameter tuples. Here's a more complete version: https://github.com/dlang/dmd/pull/5855
Re: LDC+Dub+Vibe.d work on SmartOS 64bit now
On Thursday, 9 June 2016 at 12:48:24 UTC, Alexandr Basko wrote: On Wednesday, 8 June 2016 at 13:30:26 UTC, Alexandr Basko wrote: [...] Some tests failed. More than that, they walked to the core.sync.semaphore test and frozen on it (no more resources are eating by OS from last evening: [...] Until you figure it out, you can skip a module's tests with ctest -E, ie "ctest -E core.sync.semaphore". Other results are: [...] You may need to add some library flags for curl, as I did last summer: http://forum.dlang.org/post/eipycgdrrjtuuyglp...@forum.dlang.org
Re: Beta release DUB 1.0.0-beta.1
On 6/8/16 2:45 PM, Sönke Ludwig wrote: 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. So this is definitely something concerning for allowing all comment styles. If one wants to put comments in their sdl file, then one must use an alternate style of commenting inside their sdl file. This makes /+ much more attractive than the other styles. But I think this is really just a documentation issue. The biggest problem I would see is if someone used /* style comments in their sdl file definition, but wanted to use /* style comments to include it, the parser would prematurely close the whole comment block. 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. Not "harm", but confusion. I can see someone never looking this up, because it may seem "obvious" the /+ is dub special. It's very minimal impact, but something I just thought of. 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. "It's still possible to put something else in front of it" I didn't get this. How is /+ different from /*? I thought the only issue was the nesting. 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 Thanks. Perhaps more debate is fruitless until someone steps up with an implementation :) 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!). How would this be a breaking change? It seems an additive feature, and I'm not sure it's required to be there before the first 1.0 release. -Steve
Re: LDC+Dub+Vibe.d work on SmartOS 64bit now
On Wednesday, 8 June 2016 at 13:30:26 UTC, Alexandr Basko wrote: 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 Some tests failed. More than that, they walked to the core.sync.semaphore test and frozen on it (no more resources are eating by OS from last evening: PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 74206 root 7376K 3564K sleep 560 0:00:00 0.0% druntime-test-r And I don't know why? :-( Other results are: [root@936da159-6e0d-ed52-cbc6-a9456004e081 ~/work/test_ldc]# gmake test Running tests... Test project /root/work/test_ldc Start 1: build-druntime-ldc-unittest 1/673 Test #1: build-druntime-ldc-unittest . Passed 611.86 sec Start 2: build-druntime-test-runner 2/673 Test #2: build-druntime-test-runner .. Passed1.43 sec Start 3: build-phobos2-ldc-unittest 3/673 Test #3: build-phobos2-ldc-unittest ..***Failed 525.34 sec Start 4: build-phobos2-test-runner 4/673 Test #4: build-phobos2-test-runner ...***Failed0.43 sec Start 5: build-druntime-ldc-unittest-debug 5/673 Test #5: build-druntime-ldc-unittest-debug ... Passed 70.82 sec Start 6: build-druntime-test-runner-debug 6/673 Test #6: build-druntime-test-runner-debug Passed1.41 sec Start 7: build-phobos2-ldc-unittest-debug 7/673 Test #7: build-phobos2-ldc-unittest-debug ***Failed 125.51 sec Start 8: build-phobos2-test-runner-debug 8/673 Test #8: build-phobos2-test-runner-debug .***Failed0.30 sec Start 9: core.simd 9/673 Test #9: core.simd ... Passed0.01 sec Start 10: core.exception 10/673 Test #10: core.exception .. Passed0.01 sec Start 11: core.atomic 11/673 Test #11: core.atomic . Passed0.01 sec Start 12: core.memory 12/673 Test #12: core.memory . Passed0.01 sec Start 13: core.bitop 13/673 Test #13: core.bitop .. Passed0.02 sec Start 14: core.cpuid 14/673 Test #14: core.cpuid .. Passed0.01 sec Start 15: core.time 15/673 Test #15: core.time ...***Failed0.01 sec Start 16: core.demangle 16/673 Test #16: core.demangle ... Passed0.01 sec Start 17: core.checkedint 17/673 Test #17: core.checkedint . Passed0.01 sec Start 18: core.thread 18/673 Test #18: core.thread . Passed0.12 sec Start 19: core.runtime 19/673 Test #19: core.runtime Passed0.01 sec Start 20: core.math 20/673 Test #20: core.math ... Passed0.01 sec Start 21: core.vararg 21/673 Test #21: core.vararg . Passed0.01 sec Start 22: core.internal.hash 22/673 Test #22: core.internal.hash .. Passed0.01 sec Start 23: core.internal.traits 23/673 Test #23: core.internal.traits Passed0.01 sec Start 24: core.internal.convert 24/673 Test #24: core.internal.convert ... Passed0.01 sec Start 25: core.sync.rwmutex 25/673 Test #25: core.sync.rwmutex ... Passed0.01 sec Start 26: core.sync.config 26/673 Test #26: core.sync.config Passed0.01 sec Start 27: core.sync.mutex 27/673 Test #27: core.sync.mutex . Passed0.01 sec Start 28: core.sync.condition 28/673 Test #28: core.sync.condition . Passed0.02 sec Start 29:
Re: LDC+Dub+Vibe.d work on SmartOS 64bit now
On Wednesday, 8 June 2016 at 14:13:48 UTC, flamencofantasy wrote: 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! I wrote and post howto on https://wiki.dlang.org/LDC%2BDub%2BVibe.d_on_SmartOS_64bit. It need to format, but it fully functional.
Re: Beta release DUB 1.0.0-beta.1
On Thursday, 9 June 2016 at 12:15:24 UTC, Sönke Ludwig wrote: You need to use the --single switch: dub build --single=app.d --build=release For the commandline that you have used, the arguments "build --build=release" will be passed to the compiled app.d executable instead. I'll deploy proper documentation together with the release. Thanks :)
Re: Beta release DUB 1.0.0-beta.1
Am 09.06.2016 um 12:23 schrieb Andre Pany: 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 support for single-file packages, which can be used to write shebang-style scripts on Posix systems: Full change log: https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md Download (Latest Preview): http://code.dlang.org/download Hi, Following command does not work: dub app.d build --build=release I want to compile the application without starting it. Error: Expected one or zero arguments. Is this by intention? Kind regards André You need to use the --single switch: dub build --single=app.d --build=release For the commandline that you have used, the arguments "build --build=release" will be passed to the compiled app.d executable instead. I'll deploy proper documentation together with the release.
Re: Beta release DUB 1.0.0-beta.1
On Thursday, 9 June 2016 at 10:43:31 UTC, drug wrote: 09.06.2016 13:23, Andre Pany пишет: Untested, but try ``` dub build app.d --build=release ``` Unfortunately it is not working: dub answers: Failed to find a package named 'app.d'. Kind regards André
Re: Beta release DUB 1.0.0-beta.1
09.06.2016 13:23, Andre Pany пишет: 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 support for single-file packages, which can be used to write shebang-style scripts on Posix systems: Full change log: https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md Download (Latest Preview): http://code.dlang.org/download Hi, Following command does not work: dub app.d build --build=release I want to compile the application without starting it. Error: Expected one or zero arguments. Is this by intention? Kind regards André Untested, but try ``` dub build app.d --build=release ```
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 support for single-file packages, which can be used to write shebang-style scripts on Posix systems: Full change log: https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md Download (Latest Preview): http://code.dlang.org/download Hi, Following command does not work: dub app.d build --build=release I want to compile the application without starting it. Error: Expected one or zero arguments. Is this by intention? Kind regards André
Re: The Official D Blog is Live
On 2016-06-03 21:33, Mike Parker wrote: The D Blog was born at DConf this year. With help from Jack Stouffer, it is now live at: http://dlang.org/blog/ I would prefer if the text did not hyphenate the words. I think it's easier to read whole words. If possible, it would be great if the blog worked with the Safari reader mode. -- /Jacob Carlborg
Re: Recursive SymbolNames solved.
On Thursday, 9 June 2016 at 04:58:45 UTC, Stefan Koch wrote: 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. You mean this? https://github.com/weka-io/ldc/commit/ffd6b55a4b83b3007d9690cbd9a25d07b243a00e It did not result in a large reduction of symbol sizes. http://forum.dlang.org/post/szodxrizfmufqdkpd...@forum.dlang.org
Re: Beta release DUB 1.0.0-beta.1
On Thursday, 9 June 2016 at 08:02:21 UTC, Mike Parker wrote: On Thursday, 9 June 2016 at 07:35:35 UTC, Andre Pany wrote: while calling dub within the directory containing app.d I dub app.d Without passing a file name, dub will look for a project configuration. Thanks for the info. In my use case this behavior is cumbersome. I created a build script for cloud foundry. Command "dub" is called for the source files uploaded to cloud foundry. This command is buried in the build script. While seeing this new feature I thought I can develop a file app.d instead of dub.json/source folder/app.d I would vote for a fallback of command dub. If there is no dub.json/dub.sdl & source folder but a app.d (convention) then as fallback dub is called with this file. Any chance for this feature request? :) As workaround I can adapt the build script to check for the files mentioned and call dub one way or the other way. Kind regards André
Re: Beta release DUB 1.0.0-beta.1
On Thursday, 9 June 2016 at 07:35:35 UTC, Andre Pany wrote: while calling dub within the directory containing app.d I dub app.d Without passing a file name, dub will look for a project configuration.
Re: LDC+Dub+Vibe.d work on SmartOS 64bit now
On Wednesday, 8 June 2016 at 15:35:32 UTC, Johan Engelen wrote: Are you interested in running a buildbot for LDC on your platform to detect issues early? Yes, interested. But our servers can't to use for this purpose. They use for data acquisition from electrical substation's automation system and do not have access from Internet for sequrity reasons.
