Re: Release DUB 1.0.0
On Monday, 20 June 2016 at 15:52:46 UTC, Sönke Ludwig wrote: [...] This release also adds support for single-file packages, which can be used for conveniently writing small scripts and applications. It supports a shebang line, so that directly executing the script on Posix systems also works (using "chmod +x"): #!/usr/bin/env dub /+ dub.sdl: name "colortest" dependency "color" version="~>0.0.3" +/ You should add a system to support example files, without dependency. For example in a static library, something that would indicate that the package in which the file resides is itself a dependency but don't have to be downloaded: package examples ex1.d ex2.d source package src1.d ex1.d /+ dub.sdl: name "package" dependency "this" (or dependency "../..") +/ from ex1 you should be able to locate the package by using .dirName until a dub.json is found. Maybe that if the dep value is a relative path that leads to a description this works too.
Re: LDC+Dub+Vibe.d work on SmartOS 64bit now
On Wednesday, 8 June 2016 at 15:35:32 UTC, Johan Engelen 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. 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 What are the system requirements for a SmartOS buildbot?
Re: Release DUB 1.0.0
On Monday, 20 June 2016 at 15:52:46 UTC, Sönke Ludwig wrote: I'm pleased to announce the release of the first stable version of the DUB package manager. Congratulations and thank you from all of us! DUB is amazing!!!
Re: Release DUB 1.0.0
Am 20.06.2016 um 21:11 schrieb Jacob Carlborg: On 2016-06-20 17:52, Sönke Ludwig wrote: I'm pleased to announce the release of the first stable version of the DUB package manager. Stable in this case means that the API, the command line interface and the package recipe format will only receive fully backwards compatible changes and additions for a while. Great work :) The main (high-level) priority for the upcoming versions will be adding C family language build support (starting with C/C++ and ObjC). There is a draft for how such support might look like, for anyone interested in discussing this in prior: https://github.com/dlang/dub/wiki/DEP5 The DEP explicitly mentions Objective-C as not part of the DEP. But above you're mentioning Objective-C? It should be just as easy to support Objective-C and Objective-C++ as well from the perspective of the tool. For Objective-C it's basically the C compiler but with .m files and for Objective-C++ it's the C++ compiler but with .mm files. I mostly just wanted to keep the DEP small and focused, but adding Objective-C/C++ is indeed trivial once C/C++ is there (modulo some small additional features).
Re: Release DUB 1.0.0
On 2016-06-20 17:52, Sönke Ludwig wrote: I'm pleased to announce the release of the first stable version of the DUB package manager. Stable in this case means that the API, the command line interface and the package recipe format will only receive fully backwards compatible changes and additions for a while. Great work :) The main (high-level) priority for the upcoming versions will be adding C family language build support (starting with C/C++ and ObjC). There is a draft for how such support might look like, for anyone interested in discussing this in prior: https://github.com/dlang/dub/wiki/DEP5 The DEP explicitly mentions Objective-C as not part of the DEP. But above you're mentioning Objective-C? It should be just as easy to support Objective-C and Objective-C++ as well from the perspective of the tool. For Objective-C it's basically the C compiler but with .m files and for Objective-C++ it's the C++ compiler but with .mm files. -- /Jacob Carlborg
Re: QtE5 - is a wrapping of Qt-5 for D
Very nice! -- Marco
Re: QtE5 - is a wrapping of Qt-5 for D
On 06/20/2016 12:52 PM, MGW wrote: This my library has about 400 functions from Qt and is quite efficient for small applications. Ooh, awesome, this is something D really needs! Definitely going to have to give this a try.
Re: Release DUB 1.0.0
On Monday, 20 June 2016 at 15:52:46 UTC, Sönke Ludwig wrote: I'm pleased to announce the release of the first stable version of the DUB package manager. Congrats! Can't wait to see DUB bundled with DMD.
Re: Release DUB 1.0.0
On Monday, 20 June 2016 at 15:52:46 UTC, Sönke Ludwig wrote: I'm pleased to announce the release of the first stable version of the DUB package manager. Stable in this case means that the API, the command line interface and the package recipe format will only receive fully backwards compatible changes and additions for a while. [...] Congratulations on the 1.0.0 release, and thanks for providing this tool to the community.
QtE5 - is a wrapping of Qt-5 for D
This my library has about 400 functions from Qt and is quite efficient for small applications. https://github.com/MGWL/QtE5 Small video about QtE5 and id5 written on its basis - an example of use. QtE5 on Mac OSX https://www.youtube.com/watch?v=JBA4vkT5uKE
Release DUB 1.0.0
I'm pleased to announce the release of the first stable version of the
DUB package manager. Stable in this case means that the API, the command
line interface and the package recipe format will only receive fully
backwards compatible changes and additions for a while.
This release also adds support for single-file packages, which can be
used for conveniently writing small scripts and applications. It
supports a shebang line, so that directly executing the script on Posix
systems also works (using "chmod +x"):
#!/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!()));
}
Instead of a separate file, the contents of the package recipe file go
into a specially formatted comment within the source code itself. The
comment must be the first token in the D file (apart from the optional
shebang line) and must be of the form /+ dub.(json/sdl): ... +/ where
"..." is a place holder for the actual recipe contents.
The main (high-level) priority for the upcoming versions will be adding
C family language build support (starting with C/C++ and ObjC). There is
a draft for how such support might look like, for anyone interested in
discussing this in prior: https://github.com/dlang/dub/wiki/DEP5
BTW, we now have almost 800 public packages in the registry, covering
more and more application areas. The growth is not exponential, but very
steady.
Full change log:
https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md
Download:
http://code.dlang.org/download
Making Of: LDC 1.0
Kai Nacke has put together a guest post for the D Blog [1] on how he decided the time was right for a 1.0 release of LDC. The reddit thread is at [2]. [1] http://dlang.org/blog/2016/06/20/making-of-ldc-1-0/ [2] https://www.reddit.com/r/programming/comments/4oz8h9/making_of_ldc_10_a_post_by_the_maintainer_of_the/
Re: D-Man culture
On Sunday, 19 June 2016 at 15:01:33 UTC, Seb wrote: Hi, I am not sure how much you have heard about the D-Man, but in Japan there is an entire culture based on the D-Man! As I learned about this by accident (and even Walter didn't know about it), I thought I share this great movement with the DLang community! [...] Funny stuff! I found this link useful: http://dlangcomicstrips.tumblr.com/
Re: dlang-requests 0.1.7 released
On Friday, 17 June 2016 at 17:31:55 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
Python-requests,
with primary goal of easy to use and performance.
...
Thanks! Does the project have a dub presence? How does it
compare feature-wise and speed-wise with curl? -- Andrei
Hello,
Finally, I made some improvements and run minimal performance
tests against command-line curl. I wrote simple code for file
download using dlang-requests, run it and curl for the same
urls(httpbin server on my notebook) and compare "total",
"system", and "user" time for different cases. You can find
numbers and code below.
So my conclusion is - performances are comparable for these
cases, but there is some field for improvement in
dlang-requests.
Case 1 - 50Mb of random data, no any encoding
Case 2 - 50Mb of random data, transfer chunked
Case 3 - 50Mb of random data, transfer chunked, content gzip
measured times, sec
-
| user| system | total
Case|---|---|---
| d-r | curl| d-r| curl| d-r | curl
-|-|-|-|-|-|-
1 | 0.17| 0.14| 0.20| 0.32| 51.7| 52.2
2 | 0.19| 0.11| 0.15| 0.21| 51.8| 51.9
3 | 0.21| 0.15| 0.11| 0.15| 51.5| 52.1
Finally after all unnecessary memory movements were cleaned up,
results for dlang-requests and curl almost equals.
measured times, sec
-
| user| system | total
Case|---|---|---
| d-r | curl| d-r| curl| d-r | curl
-|-|-|-|-|-|-
1 | 0.14| 0.14| 0.15| 0.32| 53.3| 52.2
2 | 0.13| 0.11| 0.11| 0.21| 51.1| 51.9
3 | 0.18| 0.15| 0.08| 0.15| 51.2| 52.1
import std.stdio;
import requests;
pragma(lib, "ssl");
pragma(lib, "crypto");
void main()
{
auto sink = File("/dev/null", "wb");
auto rq = Request();
rq.useStreaming = true;
auto rs =
rq.get("http://127.0.0.1:8080/stream-bytes/5120;);
auto stream = rs.receiveAsRange();
while(!stream.empty) {
sink.rawWrite(stream.front);
stream.popFront;
}
}
Re: Button: A fast, correct, and elegantly simple build system.
On Mon, Jun 20, 2016 at 10:21 AM, Dicebot via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Monday, 20 June 2016 at 02:46:13 UTC, Jason White wrote: > >> This actually sounds nice. Main problem that comes to my mind is that >>> there is no cross-platform shell script. Even if it is list of plain >>> unconditional commands there are always differences like normalized path >>> form. Of course, one can always generate `build.d` as a shell script, but >>> that would only work for D projects and Button is supposed to be a generic >>> solution. >>> >> >> I'd make it so it could either produce a Bash or Batch script. Possibly >> also a PowerShell script because error handling in Batch is awful. That >> should cover any platform it might be needed on. Normalizing paths >> shouldn't be a problem either. >> >> This should actually be pretty easy to implement. >> > > Will plain sh script script also work for MacOS / BSD flavors? Committing > just two scripts is fine but I wonder how it scales. > Bash script should work with all. I also read that Microsoft is making bash for windows[1]. [1] http://www.theverge.com/2016/3/30/11331014/microsoft-windows-linux-ubuntu-bash
Re: Button: A fast, correct, and elegantly simple build system.
On Monday, 20 June 2016 at 02:46:13 UTC, Jason White wrote: This actually sounds nice. Main problem that comes to my mind is that there is no cross-platform shell script. Even if it is list of plain unconditional commands there are always differences like normalized path form. Of course, one can always generate `build.d` as a shell script, but that would only work for D projects and Button is supposed to be a generic solution. I'd make it so it could either produce a Bash or Batch script. Possibly also a PowerShell script because error handling in Batch is awful. That should cover any platform it might be needed on. Normalizing paths shouldn't be a problem either. This should actually be pretty easy to implement. Will plain sh script script also work for MacOS / BSD flavors? Committing just two scripts is fine but I wonder how it scales.
