Re: Button: A fast, correct, and elegantly simple build system.
On Wednesday, 15 June 2016 at 12:02:56 UTC, Andrei Alexandrescu wrote: In all likelihood. One issue with build systems is there's no clear heir to make. There are so many, including a couple (!) by our community, each with its pros and cons. Which one should we choose? You should choose mine, obviously. ;) In all seriousness, Make will probably live as long as C. There are a *ton* of Makefiles out there that no one wants translate to a new build system. Part of the reason for that is probably because they are so friggin' incomprehensible and its not exactly glamorous work. This is why I'm working on that tool to allow Button to build existing Makefiles [1]. It may not work 100% of the time, but it should help a lot with migrating away from Make. [1] https://github.com/jasonwhite/button-make
Re: Button: A fast, correct, and elegantly simple build system.
On Wednesday, 15 June 2016 at 12:00:52 UTC, Andrei Alexandrescu wrote: I'd say the gating factor is -j. If an build system doesn't implement the equivalent of make -j, that's a showstopper. Don't worry, there is a --threads option and it defaults to the number of logical cores. I just did some tests and the reason it is slower than Make is because of the automatic dependency detection on every single command. I disabled the automatic dependency detection and compared it with Make again. Button was then roughly the same speed as Make -- sometimes it was faster, sometimes slower. Although, I think getting accurate dependencies at the cost of slightly slower builds is very much a worthwhile trade-off.
Re: Work in Amsterdam
On 06/15/2016 04:44 PM, Jack Stouffer wrote: On Wednesday, 15 June 2016 at 19:48:07 UTC, Dejan Lekic wrote: LinkedIn has the D Developer Network (DDN) group with 1900 members (at the moment of writing this post): https://www.linkedin.com/groups/3923820 I didn't know about this either. You should make a separate announce post about this. Should be accessible from the website and wiki. -- Andrei
Re: Work in Amsterdam
On Wednesday, 15 June 2016 at 19:48:07 UTC, Dejan Lekic wrote: LinkedIn has the D Developer Network (DDN) group with 1900 members (at the moment of writing this post): https://www.linkedin.com/groups/3923820 I didn't know about this either. You should make a separate announce post about this.
Re: Work in Amsterdam
On 06/15/2016 12:48 PM, Dejan Lekic wrote: On Monday, 13 June 2016 at 22:45:15 UTC, Márcio Martins wrote: Forgive me if this is not the best place for this sort of posts, but we are looking for experienced developers willing to learn D to join our development team in Amsterdam. We are a fast-growing travel e-commerce startup focused on themed vacation packages. You'll be part of our small and agile development team, working with D/vibe.d on a daily basis, with the occasional javascript for the client-side of things. Learn more on https://www.linkedin.com/jobs2/view/140710158 LinkedIn has the D Developer Network (DDN) group with 1900 members (at the moment of writing this post): https://www.linkedin.com/groups/3923820 I've posted a link to this job on the DDN's group job list few minutes ago. I've just sent a request to join but I wasn't aware of it until I've read your message. How does one know about the existence of such groups? Ali
Re: Work in Amsterdam
On Monday, 13 June 2016 at 22:45:15 UTC, Márcio Martins wrote: Forgive me if this is not the best place for this sort of posts, but we are looking for experienced developers willing to learn D to join our development team in Amsterdam. We are a fast-growing travel e-commerce startup focused on themed vacation packages. You'll be part of our small and agile development team, working with D/vibe.d on a daily basis, with the occasional javascript for the client-side of things. Learn more on https://www.linkedin.com/jobs2/view/140710158 LinkedIn has the D Developer Network (DDN) group with 1900 members (at the moment of writing this post): https://www.linkedin.com/groups/3923820 I've posted a link to this job on the DDN's group job list few minutes ago.
Re: Button: A fast, correct, and elegantly simple build system.
On Wednesday, 15 June 2016 at 15:39:47 UTC, Andrei Alexandrescu
wrote:
On 06/15/2016 08:05 AM, John Colvin wrote:
On Wednesday, 15 June 2016 at 11:47:00 UTC, Walter Bright
wrote:
On 6/15/2016 4:07 AM, Edwin van Leeuwen wrote:
How about using reggae?
https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d
I haven't studied either.
If you do study that reggae file, remember that it's a
deliberate
transliteration of the makefile and therefore is a lot more
verbose than
it *could* be if done from a clean slate or as a proper
translation.
IIRC it was done to show that reggae could do literally
everything the
makefile does, in the same way.
Does it do -j? -- Andrei
Short answer: yes.
Long answer: it has multiple backends. I assume the one that'd be
used for dmd/druntime/phobos would be the binary (compiled D
code) one since that one doesn't have dependencies on anything
else. It does what ninja does, which is to use the number of
cores on the system. There are also the ninja, make and tup
backends and those do what they do.
I've been meaning to update my reggae branch for a while but
haven't been able to gather enough motivation. The part that just
builds the library is easy (I haven't tried compiling the code
below):
alias cObjs = objectFiles!(Sources!("etc/c/zlib"),
Flags("-m64 -fPIC -O3"));
alias dObjs = objectFiles!(Sources!(["std", "etc"]),
Flags("-conf= -m64 -w -dip25 -O
-release"),
ImportPaths("../druntime/import"));
auto static_phobos =
link("$project/generated/linux/release/64/libphobos",
cObjs ~ dObjs,
"-lib");
The problem is all the other targets, and I can't break any of
them, and they're all annoying in their own special way. The
auto-tester only covers a fraction and I have no idea if all of
them are still being used by anyone. Does anyone do MinGW builds
with posix.mak for instance? I'm half convinced it's broken.
Atila
Release candidate 1.0.0-rc.1 is out
Am 07.06.2016 um 11:54 schrieb Sönke Ludwig:
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:
#!/usr/bin/env dub
/+ dub.sdl:
name "colortest"
dependency "color" version="~>0.0.3"
+/
void main()
{
import std.stdio : writefln;
import std.experimental.color.conv;
import std.experimental.color.hsx;
import std.experimental.color.rgb;
auto yellow = RGB!("rgb", float)(1.0, 1.0, 0.0);
writefln("Yellow in HSV: %s", yellow.convertColor!(HSV!()));
}
With "chmod +x" it can then simply be run as ./colortest.d.
Apart from that, the release contains some bug fixes, most notably it
doesn't query the registry for each build any more.
Full change log:
https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md
Download (Latest Preview):
http://code.dlang.org/download
The first release candidate is out now! If nothing else comes up, the
release is scheduled for next Monday.
For this release, I've restricted the recipe comments to the /+ +/ style
and to be the first thing in the file apart from the optional shebang
line. This leaves all options open to relax the rules later without
losing backwards compatibility and allows #872 [1] to be finished with
less time pressure.
[1]: https://github.com/dlang/dub/pull/872
Re: Button: A fast, correct, and elegantly simple build system.
On Wednesday, 15 June 2016 at 15:39:47 UTC, Andrei Alexandrescu wrote: On 06/15/2016 08:05 AM, John Colvin wrote: On Wednesday, 15 June 2016 at 11:47:00 UTC, Walter Bright wrote: On 6/15/2016 4:07 AM, Edwin van Leeuwen wrote: How about using reggae? https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d I haven't studied either. If you do study that reggae file, remember that it's a deliberate transliteration of the makefile and therefore is a lot more verbose than it *could* be if done from a clean slate or as a proper translation. IIRC it was done to show that reggae could do literally everything the makefile does, in the same way. Does it do -j? -- Andrei It can work with multiple backends (make/tup/ninja), which all support -j. There is also a binary backend (creates an executable), not sure if that supports -j natively.
Re: Button: A fast, correct, and elegantly simple build system.
On 06/15/2016 08:05 AM, John Colvin wrote: On Wednesday, 15 June 2016 at 11:47:00 UTC, Walter Bright wrote: On 6/15/2016 4:07 AM, Edwin van Leeuwen wrote: How about using reggae? https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d I haven't studied either. If you do study that reggae file, remember that it's a deliberate transliteration of the makefile and therefore is a lot more verbose than it *could* be if done from a clean slate or as a proper translation. IIRC it was done to show that reggae could do literally everything the makefile does, in the same way. Does it do -j? -- Andrei
Re: Beta release DUB 1.0.0-beta.1
On 06/13/2016 07:31 AM, Kagamin wrote: On Friday, 10 June 2016 at 17:45:54 UTC, Nick Sabalausky wrote: On 06/08/2016 11:04 AM, Kagamin wrote: BTW do people find nested comments particularly useful? God yes. It's the *only* block comment I ever use. Non-nesting comment blocks are a worthless PITA with no real benefit: You can't comment out a block if the block already contains a block comment. Block comments are low-level: the commented code changes its lexical structure completely, but you probably don't expect it and want it to behave and be properly commented at a higher level, which is provided by version statement. No, I WANT commenting-out to be low-level, but just not have a stupid, useless, badly-chosen rule for when the block ends. Version(none) is too high-level. I can't use it *within* a statement, which means I'd have to use one method to "comment-out" blocks of code and a different method when I comment out ex., params, args, or parts of an expression (all of which I occasionally do). But why would I want to do that when there's one construct (nesting block comments) that works perfectly for both AND actually gets highlighted as "disabled" in every editor and HTML highlighter out there so I can actually see at a glance what's disabled?
Re: Button: A fast, correct, and elegantly simple build system.
On Wednesday, 15 June 2016 at 11:47:00 UTC, Walter Bright wrote: On 6/15/2016 4:07 AM, Edwin van Leeuwen wrote: How about using reggae? https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d I haven't studied either. If you do study that reggae file, remember that it's a deliberate transliteration of the makefile and therefore is a lot more verbose than it *could* be if done from a clean slate or as a proper translation. IIRC it was done to show that reggae could do literally everything the makefile does, in the same way.
Re: Button: A fast, correct, and elegantly simple build system.
On 6/15/16 1:42 AM, Jason White wrote: On Monday, 13 June 2016 at 20:12:27 UTC, Walter Bright wrote: On 6/12/2016 4:27 PM, Jason White wrote: I don't understand this dependency-phobia. It's the "first 5 minutes" thing. Every hiccup there costs us maybe half the people who just want to try it out. I suppose you're right. It is just frustrating that people are unwilling to adopt clearly superior tools simply because it would introduce a new dependency. I'm sure D itself has the same exact problem. In all likelihood. One issue with build systems is there's no clear heir to make. There are so many, including a couple (!) by our community, each with its pros and cons. Which one should we choose? -- Andrei
Re: Button: A fast, correct, and elegantly simple build system.
On 6/15/16 1:29 AM, Jason White wrote: On Tuesday, 14 June 2016 at 14:57:52 UTC, Andrei Alexandrescu wrote: On 6/12/16 8:27 PM, Walter Bright wrote: On 5/30/2016 12:16 PM, Jason White wrote: Here is an example build description for DMD: https://github.com/jasonwhite/dmd/blob/button/src/BUILD.lua I'd say that's a lot easier to read than this crusty thing: https://github.com/dlang/dmd/blob/master/src/posix.mak Yes, the syntax looks nice. Cool. Difference in size is also large. Do they do the same things? -- Andrei Not quite. It doesn't download a previous version of dmd for bootstrapping and it doesn't handle configuration (e.g., x86 vs x64). About all it does is the bare minimum work necessary to create the dmd executable. I basically ran `make all -n` and converted the output because it's easier to read than the Makefile itself. OK. I guess at least some of that stuff should be arguably scripted. Building from scratch takes about 7 seconds on my machine (using 8 cores and building in /tmp). Make takes about 5 seconds. Guess I need to do some optimizing. :-) I'd say the gating factor is -j. If an build system doesn't implement the equivalent of make -j, that's a showstopper. Andrei
Re: Button: A fast, correct, and elegantly simple build system.
On Wednesday, 15 June 2016 at 05:42:21 UTC, Jason White wrote: On Monday, 13 June 2016 at 20:12:27 UTC, Walter Bright wrote: On 6/12/2016 4:27 PM, Jason White wrote: I don't understand this dependency-phobia. It's the "first 5 minutes" thing. Every hiccup there costs us maybe half the people who just want to try it out. I suppose you're right. It is just frustrating that people are unwilling to adopt clearly superior tools simply because it would introduce a new dependency. I'm sure D itself has the same exact problem. I am confident can build a lua to D transcompiler that works at CTFE.
Re: Button: A fast, correct, and elegantly simple build system.
On 6/15/2016 4:07 AM, Edwin van Leeuwen wrote: How about using reggae? https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d I haven't studied either.
Re: LDC 1.0.0 has been released!
On 2016-06-07 14:59, FreeSlave wrote: Yes. Look at https://issues.dlang.org/show_bug.cgi?id=16096 I don't have such problem with ldc 1.0.0. Fixed, unless you already have noticed. -- /Jacob Carlborg
Re: Button: A fast, correct, and elegantly simple build system.
On Monday, 13 June 2016 at 00:27:47 UTC, Walter Bright wrote: On 5/30/2016 12:16 PM, Jason White wrote: Here is an example build description for DMD: https://github.com/jasonwhite/dmd/blob/button/src/BUILD.lua I'd say that's a lot easier to read than this crusty thing: https://github.com/dlang/dmd/blob/master/src/posix.mak Yes, the syntax looks nice. How about using reggae? https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d
Re: Button: A fast, correct, and elegantly simple build system.
On Wednesday, 15 June 2016 at 05:04:28 UTC, Jason White wrote: If you want to depend on the compiler version, then you can add a dependency on the compiler executable. It might be a good idea to have Button do this automatically for every command. That is, finding the path to the command's executable and making it a dependency. I think you are fine if adding a dependency works. If it's done automatically someone will ask for a way to disable this feature. However, I can think of another scenario where it would just as well be incorrect behavior: Linking an executable and then running tests on it. The executable could then be seen by the build system as the "secondary" or "intermediate" output. If it gets deleted, I think we'd want it rebuilt. I'm not sure how Make or Shake implement this without doing it incorrectly in certain scenarios. There would need to be a way to differentiate between necessary and unnecessary outputs. I'll have to think about this more. Shake has 'order only' dependencies that cover the 'intermediate' case. GNU make supports special targets '.INTERMEDIATE' and '.SECONDARY' [1]. [1] http://www.gnu.org/software/make/manual/make.html#Chained-Rules
Re: LDC+Dub+Vibe.d work on SmartOS 64bit now
On Thursday, 9 June 2016 at 19:37:29 UTC, Alexandr Basko wrote: 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. I have made tests, but some tests failed. We are analyzing errors, and will done all for tests passed.
