Re: Button: A fast, correct, and elegantly simple build system.
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.
Re: Button: A fast, correct, and elegantly simple build system.
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. 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. :-)
Re: Button: A fast, correct, and elegantly simple build system.
On Wed, Jun 15, 2016 at 05:04:28AM +, Jason White via Digitalmars-d-announce wrote: > On Tuesday, 14 June 2016 at 10:47:58 UTC, Fool wrote: [...] > > A possible use case is creating object files first and packing them > > into a library as a second step. Then single object files are of not > > much interest anymore. Imagine, you want to distribute a build to > > several development machines such that their local build > > environments are convinced that the build is up to date. If object > > files can be treated as secondary or intermediate targets you can > > save lots of unnecessary network traffic and storage. > > You're right, that is a valid use case. In my day job, we have builds > that produce 60+ GB of object files. It would be wasteful to > distribute all that to development machines. > > 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. I don't think Make handles this at all. You'd just write rules in the Makefile to delete the intermediate files if you really care to. Most of the time people just ignore it, and add a 'clean' rule with some wildcards to cleanup the intermediate files. (This is actually one of the sources of major annoyance with Makefiles: because of the unknown state of intermediate files, builds are rarely reproducible, and `make clean; make` is a ritual that has come to be accepted as a fact of life. Arguably, though, a *proper* build system ought to be such that incremental builds are always correct and reproducible, and does not depend on environmental factors.) T -- Not all rumours are as misleading as this one.
Re: Button: A fast, correct, and elegantly simple build system.
On Tuesday, 14 June 2016 at 10:47:58 UTC, Fool wrote: Switching the compiler version seems to be a valid use case. You might have other means to detect this, though. 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. A possible use case is creating object files first and packing them into a library as a second step. Then single object files are of not much interest anymore. Imagine, you want to distribute a build to several development machines such that their local build environments are convinced that the build is up to date. If object files can be treated as secondary or intermediate targets you can save lots of unnecessary network traffic and storage. You're right, that is a valid use case. In my day job, we have builds that produce 60+ GB of object files. It would be wasteful to distribute all that to development machines. 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.
Re: dlang-requests 0.1.7 released
On Tuesday, 14 June 2016 at 22:46:00 UTC, ikod wrote: On Tuesday, 14 June 2016 at 14:59:37 UTC, Andrei Alexandrescu wrote: On 6/11/16 7:03 PM, ikod wrote: Hello, Dlang-requests is library created under influence of ... Code and docs available at https://github.com/ikod/dlang-requests or as dub package. Thanks Dlang authors and community for excellent language. Thanks! Does the project have a dub presence? How does it compare feature-wise and speed-wise with curl? -- Andrei Yes, it is in the dub repository under name "requests" As for speed comparison, I'll post numbers in a day or two, when I'll finish some performance improvements. Feature matrix for libcurl(per https://curl.haxx.se/docs/features.html) and dlang-requests: https://github.com/ikod/dlang-requests/blob/master/docs/matrix.txt Please note, that dlang-requests supports only http,https and ftp. No worries - `std.net.curl` doesn't expose all the exotic protocols that libcurl supports either ;-) Same goes for the features, it's more interestingly to see what std.net.curl exposes to the user: http://dlang.org/phobos/std_net_curl.html
Re: dlang-requests 0.1.7 released
On Tuesday, 14 June 2016 at 14:59:37 UTC, Andrei Alexandrescu wrote: On 6/11/16 7:03 PM, ikod wrote: Hello, Dlang-requests is library created under influence of ... Code and docs available at https://github.com/ikod/dlang-requests or as dub package. Thanks Dlang authors and community for excellent language. Thanks! Does the project have a dub presence? How does it compare feature-wise and speed-wise with curl? -- Andrei Yes, it is in the dub repository under name "requests" As for speed comparison, I'll post numbers in a day or two, when I'll finish some performance improvements. Feature matrix for libcurl(per https://curl.haxx.se/docs/features.html) and dlang-requests: https://github.com/ikod/dlang-requests/blob/master/docs/matrix.txt Please note, that dlang-requests supports only http,https and ftp.
Re: Button: A fast, correct, and elegantly simple build system.
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. ... The makefiles, especially posix.mak, have grown into horrific snarls of who-knows-what-is-happening. I had a minor rant about this at DConf. The makefiles are the major reason I haven't contributed to the core D projects. They'd be a hell of a lot simpler if everything that isn't building an executable (and isn't idempotent) got ripped out. No downloading compilers, no cloning/updating repos, etc, etc. Having a pushbutton process for installing/bootstrapping is cool, but that stuff is better off in scripts.
Re: July D Boston Meetup gathering
On 06/14/2016 12:00 PM, Steven Schveighoffer wrote: Just announced. If you are in the area, come join us! http://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/231887464/ -Steve Can't wait! -- Andrei
July D Boston Meetup gathering
Just announced. If you are in the area, come join us! http://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/231887464/ -Steve
Re: dlang-requests 0.1.7 released
On 6/11/16 7:03 PM, ikod wrote: Hello, Dlang-requests is library created under influence of Python-requests, with primary goal of easy to use and performance. It provide interfaces for HTTP(S) and FTP requests. You can tune request details, but for most cases you will need single and simple API call. Latest release added streaming content from server and some performance improvements (avoiding some of unnecessary buffer copying). Code and docs available at https://github.com/ikod/dlang-requests or as dub package. Thanks Dlang authors and community for excellent language. Thanks! Does the project have a dub presence? How does it compare feature-wise and speed-wise with curl? -- Andrei
Re: Button: A fast, correct, and elegantly simple build system.
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
Re: Button: A fast, correct, and elegantly simple build system.
On 2016-06-14 14:04, drug wrote: I don't agree if you don't mind. I have two almost identical implementation of the same thing in D and C++. And if I rebuild them totally - yes, dmd is faster than gcc: dmd5 secs ldmd2 6 secs make 40 secs make -j10 11 secs But if I changed several lines only then dmd time doesn't change and gcc takes much less time. In fact digits are small for D, but I feel the difference really. Not big, not bad, but it exists. For me, IIRC, it takes longer time to recompile a single C++ file from the DMD source code than it takes to build Phobos from scratch. What's slowing down the compilation of Phobos is the C code. -- /Jacob Carlborg
Re: LDC+Dub+Vibe.d work on SmartOS 64bit now
On Monday, 13 June 2016 at 06:10:22 UTC, Alexandr Basko wrote: On Friday, 10 June 2016 at 21:40:22 UTC, flamencofantasy wrote: On Thursday, 9 June 2016 at 12:30:30 UTC, Alexandr Basko wrote: [...] Thank you very much! I followed the instructions and I was able to build ldc, dub but not vibe.d's examples. [...] You only need to install additional package libevent. # pkgin in libevent Nothing else need to change, your project will be builded with vibe.d version > 0.7.30-alpha1 Yes, it all works now. The only thing I noticed is build time of my project has increased to a few minutes up from a few seconds when using DMD. But overall I am very happy. Thanks!
Re: Button: A fast, correct, and elegantly simple build system.
14.06.2016 13:04, ketmar пишет: On Tuesday, 14 June 2016 at 07:45:10 UTC, Jacob Carlborg wrote: I couldn't agree more. With the D compiler being so fast it's reasonable to just recompile everything at once instead of trying to track what's changed. i'm agree with that. i'm so used to do just "rdmd main.d" in my projects (ranged from "hello, world" to complex game engines). I don't agree if you don't mind. I have two almost identical implementation of the same thing in D and C++. And if I rebuild them totally - yes, dmd is faster than gcc: dmd5 secs ldmd2 6 secs make 40 secs make -j10 11 secs But if I changed several lines only then dmd time doesn't change and gcc takes much less time. In fact digits are small for D, but I feel the difference really. Not big, not bad, but it exists.
Re: Button: A fast, correct, and elegantly simple build system.
On Sunday, 12 June 2016 at 22:59:15 UTC, Jason White wrote: - "system1: Dependency on system information" (Because tasks with no dependencies are only run once. This could be changed easily enough, but I don't see the point.) Switching the compiler version seems to be a valid use case. You might have other means to detect this, though. - "secondary: Secondary target" (I think this is incorrect behavior and not a feature.) - "intermediate: Intermediate target" (Same reason as "secondary". If this is really needed, it should be encapsulated inside a single task.) A possible use case is creating object files first and packing them into a library as a second step. Then single object files are of not much interest anymore. Imagine, you want to distribute a build to several development machines such that their local build environments are convinced that the build is up to date. If object files can be treated as secondary or intermediate targets you can save lots of unnecessary network traffic and storage. I should probably make a pull request to add it to the shootout. It might help advertising. :-)
std.experimental.checkedint is ready for comments!
http://forum.dlang.org/post/jxaisipbdqfifpncn...@forum.dlang.org
Re: Button: A fast, correct, and elegantly simple build system.
On Tuesday, 14 June 2016 at 07:45:10 UTC, Jacob Carlborg wrote: I couldn't agree more. With the D compiler being so fast it's reasonable to just recompile everything at once instead of trying to track what's changed. i'm agree with that. i'm so used to do just "rdmd main.d" in my projects (ranged from "hello, world" to complex game engines).
Re: Button: A fast, correct, and elegantly simple build system.
On 2016-06-13 22:12, Walter Bright wrote: It's the "first 5 minutes" thing. Every hiccup there costs us maybe half the people who just want to try it out. Even the makefiles have hiccups. I've had builds fail with the dmd system because I had the wrong version of make installed. And it doesn't fail with "you have the wrong make program installed" messages, it fails with some weird error message pointing into the middle of the makefile. The makefiles, especially posix.mak, have grown into horrific snarls of who-knows-what-is-happening. I hate makefiles that call other makefiles. Sometimes I feel like chucking them all and replacing them with a batch file that is nothing more than an explicit list of commands: dmd -c file1.d dmd -c file2.d etc. :-) I couldn't agree more. With the D compiler being so fast it's reasonable to just recompile everything at once instead of trying to track what's changed. -- /Jacob Carlborg
D Programmers in Colombia
Anybody from Colombia here? Looking to find Programmers who enjoy D and live in Bogota. anybody?
