Re: DUB 0.9.24 release

2015-09-24 Thread Sönke Ludwig via Digitalmars-d-announce

Am 24.09.2015 um 10:40 schrieb Suliman:

Does DUB still can't generate sdl package format after dub init?
It's a little bit not comfortable to have docs that describe SDL, when
dub generate json.


No, it generates a dub.sdl file.


Re: DUB 0.9.24 release

2015-09-24 Thread John Colvin via Digitalmars-d-announce

On Thursday, 24 September 2015 at 08:23:54 UTC, Suliman wrote:

How I can add multiple dependencies? In json I was can wrote:
dependencies": {
"dini": ">=1.0.0",
"colorize": ">=1.0.5",
"ddbc": ">=0.2.11",
}

How it will be in SDL?


http://code.dlang.org/package-format?lang=sdl


Re: DUB 0.9.24 release

2015-09-24 Thread Suliman via Digitalmars-d-announce
On Thursday, 24 September 2015 at 09:48:10 UTC, Sönke Ludwig 
wrote:

Am 24.09.2015 um 10:40 schrieb Suliman:
Does DUB still can't generate sdl package format after dub 
init?
It's a little bit not comfortable to have docs that describe 
SDL, when

dub generate json.


No, it generates a dub.sdl file.


Oh, I see I had conflict with double mention DUB is PATH. Yes now 
I see that it's work.







Re: DUB 0.9.24 release

2015-09-24 Thread Sönke Ludwig via Digitalmars-d-announce

Am 24.09.2015 um 11:22 schrieb John Colvin:

On Thursday, 24 September 2015 at 09:21:06 UTC, John Colvin wrote:

On Thursday, 24 September 2015 at 08:23:54 UTC, Suliman wrote:

How I can add multiple dependencies? In json I was can wrote:
dependencies": {
"dini": ">=1.0.0",
"colorize": ">=1.0.5",
"ddbc": ">=0.2.11",
}

How it will be in SDL?


http://code.dlang.org/package-format?lang=sdl


woops, sorry, I see it's not actually mentioned there


It's only mentioned implicitly by stating that all directives can be 
used multiple times to override/append. I'll mention this more explicitly.


So the above example is:

dependency "dini" version=">=1.0.0"
dependency "colorize" version=">=1.0.5"
dependency "ddbc" version=">=0.2.11"



Re: DUB 0.9.24 release

2015-09-24 Thread Suliman via Digitalmars-d-announce
btw, yaml is still looks for me more readable and easier to 
googling.


Re: DUB 0.9.24 release

2015-09-24 Thread John Colvin via Digitalmars-d-announce

On Thursday, 24 September 2015 at 09:21:06 UTC, John Colvin wrote:

On Thursday, 24 September 2015 at 08:23:54 UTC, Suliman wrote:

How I can add multiple dependencies? In json I was can wrote:
dependencies": {
"dini": ">=1.0.0",
"colorize": ">=1.0.5",
"ddbc": ">=0.2.11",
}

How it will be in SDL?


http://code.dlang.org/package-format?lang=sdl


woops, sorry, I see it's not actually mentioned there


Re: Scriptlike v0.9.4 - Perl-like interpolated strings, full examples and more.

2015-09-24 Thread Jacob Carlborg via Digitalmars-d-announce

On 2015-09-23 15:59, Ben Boeckel via Digitalmars-d-announce wrote:


Be aware that you will have to pay an extra lstat call for such a
function so that *it* can call the right function. It certainly
shouldn't replace the existing functions.


Perhaps not in Phobos, but I don't see why someone using Scriptlike 
would care. As I understand it, the whole point of Scriptlike is 
convenience.


--
/Jacob Carlborg


Re: DUB 0.9.24 release

2015-09-24 Thread Suliman via Digitalmars-d-announce

How I can add multiple dependencies? In json I was can wrote:
dependencies": {
"dini": ">=1.0.0",
"colorize": ">=1.0.5",
"ddbc": ">=0.2.11",
}

How it will be in SDL?


Re: DUB 0.9.24 release

2015-09-24 Thread Suliman via Digitalmars-d-announce

Does DUB still can't generate sdl package format after dub init?
It's a little bit not comfortable to have docs that describe SDL, 
when dub generate json.


Re: OneDrive Client written in D

2015-09-24 Thread Suliman via Digitalmars-d-announce

On Tuesday, 22 September 2015 at 20:43:32 UTC, skilion wrote:
I've been waiting for a good sync client for OneDrive (15 GB 
for free!) on Linux, but Microsoft seems to have other plans...

So I've decided to write my own, using D. Take a look:

  http://skilion.github.io/onedrive/



What this string in config.d do?
 auto r = regex("(?:^\\s*)(\\w+)(?:\\s*=\\s*\")(.*)(?:\"\\s*$)");




Re: DUB 0.9.24 release

2015-09-24 Thread Chris via Digitalmars-d-announce

On Sunday, 20 September 2015 at 19:36:13 UTC, Sönke Ludwig wrote:

http://sdl.ikayzo.org/ does not work atm.

Is there a tool/switch that converts my old dub.json files to 
dub.sdl?


Re: Release D 2.068.2

2015-09-24 Thread Robert burner Schadek via Digitalmars-d-announce
On Thursday, 24 September 2015 at 00:10:34 UTC, Martin Nowak 
wrote:

Glad to announce D 2.068.2.


Congratulations


Re: reggae v0.5.0: new features in the D meta-build system

2015-09-24 Thread Atila Neves via Digitalmars-d-announce
On Wednesday, 23 September 2015 at 06:16:08 UTC, Jacob Carlborg 
wrote:

On 2015-09-22 14:39, Per Nordlöw wrote:


SCons has a very hidden feature called interactive mode via
`--interactive` that supports instantaenous incremental builds 
via a

very primitive CLI that basically supports to commands:


Incremental builds in D are currently not reliable. Something 
about templates not being outputted to all object files it need 
to.


That's not been my experience at all using reggae. I only do 
incremental builds now and have never run into a problem. Can you 
give an example?


Atila


Re: reggae v0.5.0: new features in the D meta-build system

2015-09-24 Thread Atila Neves via Digitalmars-d-announce

On Tuesday, 22 September 2015 at 12:39:48 UTC, Per Nordlöw wrote:
On Wednesday, 16 September 2015 at 14:07:17 UTC, Atila Neves 
wrote:

http://code.dlang.org/my_packages/reggae

What's new:
Atila


If you want to build a really revolutionary *new* build system 
you should turn reggae into a client-server-architecture that 
listens to file moves/copies/notifications via inotify on 
Linux. I'm not sure how the develop/builder interface would 
look like then, however. A web-client would be one way.


That idea is in the TODO.txt of the project. There's a 99.9% 
chance I won't bother.


I just benchmarked a toy auto-generated project of 30'000 D 
files, because I wanted to profile and optimise the binary 
backend against ninja and tup. I'm doing this by measuring the 
overhead of checking all of these files for modification 
timestamps, since actually compiling and linking take much 
longer. The overhead for ninja is 0.18s. Tup does it even faster. 
My current binary backend spends all of 0.3s, and that's what I 
was trying to optimize. Make, however... 22s I think.


It would seem obvious that using something like inotify would be 
incredibly fast, but in practice it's irrelevant. Well, it's 
irrelevant for pretty much every project out there. I'm 
incredibly sensible to how long my feedback loops are, but if a 
30k file project takes under a second to check, I really don't 
care.


Now, you may say that my toy project doesn't accurately represent 
real life. But I've used ninja on a real C codebase of 40M lines 
spread over ~14k files. This is much larger than most people will 
ever deal with. A no-op build took 1s.


Make is slow. Just don't use make. The ninja, tup and binary 
backends of reggae are fast enough. Incidentally, this is why 
ninja didn't try to get faster. It doesn't need to.


I might consider a system where you don't even have to tell the 
computer to build anything. I'm not even sure that's that useful. 
Maybe it's just the way I work, I don't know.


This however does not rebuild the dependency tree between 
invokations which is a serious limitation. I believe reggae 
could be even smarter here.


It already is ;)

I've spent the last two years designing and implementing a 
SCons-based build system at work. Involving, among others, 
adding support for Ada and auto-detection of include-paths as 
you have done in reggae.


Feel free to issue a PR for Ada auto-detection for reggae. :)

I you want any advice on this matter please contact me. I'd be 
glad to be of service.


Send me an email, I'm more than happy to waffle away about build 
systems.





Re: DUB 0.9.24 release

2015-09-24 Thread Nick Sabalausky via Digitalmars-d-announce

On 09/24/2015 07:23 AM, Suliman wrote:

btw, yaml is still looks for me more readable and easier to googling.


Yaml is a very complicated format.


Re: DUB 0.9.24 release

2015-09-24 Thread Chris via Digitalmars-d-announce
On Thursday, 24 September 2015 at 15:06:04 UTC, Nick Sabalausky 
wrote:

On 09/24/2015 09:45 AM, Chris wrote:
On Sunday, 20 September 2015 at 19:36:13 UTC, Sönke Ludwig 
wrote:


http://sdl.ikayzo.org/ does not work atm.



Permanent mirror here:

http://semitwist.com/sdl-mirror/Home.html

> Is there a tool/switch that converts my old dub.json files to
dub.sdl?

Not at the moment. But the SDLang-D project *does* need to add 
some conversion tools. I don't know that I can get to it right 
away though.


Cool. Thanks.


Re: DUB 0.9.24 release

2015-09-24 Thread Nick Sabalausky via Digitalmars-d-announce

On 09/24/2015 09:45 AM, Chris wrote:

On Sunday, 20 September 2015 at 19:36:13 UTC, Sönke Ludwig wrote:

http://sdl.ikayzo.org/ does not work atm.



Permanent mirror here:

http://semitwist.com/sdl-mirror/Home.html

> Is there a tool/switch that converts my old dub.json files to dub.sdl?

Not at the moment. But the SDLang-D project *does* need to add some 
conversion tools. I don't know that I can get to it right away though.




Re: Scriptlike v0.9.4 - Perl-like interpolated strings, full examples and more.

2015-09-24 Thread Andrei Alexandrescu via Digitalmars-d-announce

On 09/23/2015 01:44 AM, Sönke Ludwig wrote:

Am 22.09.2015 um 22:18 schrieb Nick Sabalausky:

=
String Interpolation:
=
https://github.com/Abscissa/scriptlike#string-interpolation

AFAICT, a string mixin is necessary to accomplish this in D, but
otherwise it works much like other languages:


// Output: The number 21 doubled is 42!
int num = 21;
writeln(
 mixin(interp!"The number ${num} doubled is ${num * 2}!")
);


The interpolated sections are handled via std.conv.text(), so they
accept any type.

Bikeshedding requested! I'm not 100% sold on the name "interp" for this
long-term. Suggestions welcome.



An alternative idea would be to mix in a local "writeln" function, which
can then be used multiple times without syntax overhead:

mixin template interp()
{
 void iwriteln(string str)()
 {
 // pretend that we actually parse the string ;)
 write("This is ");
 write(somevar);
 writeln(".");
 }
}

void main()
{
 int somevar = 42;
 mixin interp;
 iwriteln!("This is ${somevar}.");
}


Yah, I think we need something like that in the stdlib. Also, we need 
writefln with compile-time format string (someone was working on it but 
I haven't heard about it in a while). -- Andrei




Re: Scriptlike v0.9.4 - Perl-like interpolated strings, full examples and more.

2015-09-24 Thread H. S. Teoh via Digitalmars-d-announce
On Thu, Sep 24, 2015 at 08:00:53PM -0400, Andrei Alexandrescu via 
Digitalmars-d-announce wrote:
[...]
> Yah, I think we need something like that in the stdlib. Also, we need
> writefln with compile-time format string (someone was working on it
> but I haven't heard about it in a while). -- Andrei

https://issues.dlang.org/show_bug.cgi?id=13568

I wanted to work on it, but haven't actually gotten to it yet.
Basically, the idea is relatively simple:

// compile-time variant
void writefln(string format="", A...)(A args)
if (format.length > 0)
{
... // implementation here
}

// runtime variant
void writefln(string format="", A...)(A args)
if (format.length == 0 && args.length > 0 &&
is(typeof(args[0]) == string))
{
... // current implementation
}

This will allow backward compatibility with the current writefln API,
while allowing existing code to simply transition from:

writefln("...", ...);

to:

writefln!"..."(...);

The tricky part is how to extricate the various parts of the current
implementation in order to take full advantage of compile-time format
strings, e.g., (1) don't import anything except what's necessary to
format the current format string (the current format() has to import,
e.g., std.bigint even if you never use BigInt, because it can't assume
that a runtime format string might not ask to format BigInts; this
causes the infamous format() template bloat) -- this includes allowing
format() to be pure, @nogc, etc. if your format strings never ask for
anything that requires that; (2) compile-time argument mismatch checking
(e.g., writefln!"%d"("abc") should give a compile-time error rather than
a runtime exception).

A lot of the current implementation will probably have to be overhauled
/ rewritten in order to make this work. That part unfortunately requires
a lot of time, which I don't have right now.


T

-- 
Creativity is not an excuse for sloppiness.


Coedit 2 alpha 1 - now with dub

2015-09-24 Thread BBasile via Digitalmars-d-announce

A first alpha of the Coedit 2, the small D IDE, is available.

Summary:


This alpha is focused on the integration of the official build 
tool DUB.

In fact it's almost fully supported since it's possible to
- create a new DUB project from scratch.
- open an existing project to modify it.
- compile, run, choose the configuration and the build type.
but only the JSON format is handled.

Additionally some other features have been added, notably:
- the symbol list has an option to expand smartly on the 
declaration matching to what's being edited.

- demangle the messages redirected from DUB or DMD.
- a runnable module can use the first script line to define some 
additional DMD options.
- a native project format configuration can be defined as 'base' 
or 'overridden'.

- and more...read the changelog for more details.

Links:
-

- changelog: 
https://github.com/BBasile/Coedit/releases/tag/2_alpha_1
- win32 zip: 
https://github.com/BBasile/Coedit/releases/download/2_alpha_1/coedit.2alpha1.win32.zip
- win32 setup: 
https://github.com/BBasile/Coedit/releases/download/2_alpha_1/coedit.2alpha1.win32.setup.zip
- linux32 zip: 
https://github.com/BBasile/Coedit/releases/download/2_alpha_1/coedit.2alpha1.linux32.zip
- linux32 setup: 
https://github.com/BBasile/Coedit/releases/download/2_alpha_1/coedit.2alpha1.linux32.setup.zip
- linux64 zip: 
https://github.com/BBasile/Coedit/releases/download/2_alpha_1/coedit.2alpha1.linux64.zip
- linux64 setup: 
https://github.com/BBasile/Coedit/releases/download/2_alpha_1/coedit.2alpha1.linux64.setup.zip


Note:
-

- Test by feeding Coedit with your DUB projects.
- Despite of not being a final version, this alpha can be setup 
safely (base features have not changed).
- If you find a problem, report it at 
https://github.com/BBasile/Coedit/issues.