www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DUB RC 0.9.24-rc.1 ready for testing

reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
If everything goes as planned, the 0.9.24 release will be the last one 
before 1.0.0. The two major additions over 0.9.23 are the support for 
SDLang based package descriptions [1] [2] and an extended support for 
"dub describe" and build command environment variable support. See the 
change log for more details.

There are a few issues open that may still get into the final release if 
they get confirmed:
https://github.com/D-Programming-Language/dub/milestones/0.9.24

My first practical impressions of the new SDL based package descriptions 
(vibe.d and some private projects) are very positive. It's a bit like 
converting a C++ code base to D - all the lines get a lot shorter, with 
less visual noise. And comments are of course a great win. My only 
nitpick is that attributes can only be placed at the end of a line, 
which not optimal in case of the "platform" attribute.

Download:
http://code.dlang.org/download

Change log:
https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

[1]: http://sdl.ikayzo.org/display/SDL/Home
[2]: http://code.dlang.org/package-format?lang=sdl
Jul 13 2015
next sibling parent reply "Suliman" <evermind live.ru> writes:
Why this version is still after dub init are generate json 
instead of sdl file?
Jul 14 2015
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 14.07.2015 um 13:36 schrieb Suliman:

 Why this version is still after dub init are generate json instead of
 sdl file?


It should generate a dub.sdl file by default. Maybe you still have an 
older version in your $PATH? You can run "dub --version" to verify this.
Jul 14 2015
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/13/15 7:09 PM, Sönke Ludwig wrote:

 If everything goes as planned, the 0.9.24 release will be the last one
 before 1.0.0.


Great! I wish we'd synchronize release and distribution schedules for 
dmd, dub, and vibe soon. -- Andrei
Jul 14 2015
parent reply "Suliman" <evermind live.ru> writes:
On Tuesday, 14 July 2015 at 13:58:36 UTC, Andrei Alexandrescu 
wrote:

 On 7/13/15 7:09 PM, Sönke Ludwig wrote:

 If everything goes as planned, the 0.9.24 release will be the 
 last one
 before 1.0.0.


 Great! I wish we'd synchronize release and distribution 
 schedules for dmd, dub, and vibe soon. -- Andrei


In what version of DMD do you plan to include dub and vibe?
Jul 16 2015
parent reply "Martin Nowak" <code dawg.eu> writes:
On Thursday, 16 July 2015 at 08:28:08 UTC, Suliman wrote:

 In what version of DMD do you plan to include dub and vibe?


It doesn't make sense to include vibe.d. We plan to include dub, 
when it reaches 1.0.0, should happen soon.
Jul 20 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/20/15 5:30 PM, Martin Nowak wrote:

 On Thursday, 16 July 2015 at 08:28:08 UTC, Suliman wrote:

 In what version of DMD do you plan to include dub and vibe?


 It doesn't make sense to include vibe.d.


I think it does - this has been discussed before. -- Andrei
Jul 20 2015
next sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Monday, 20 July 2015 at 23:18:34 UTC, Andrei Alexandrescu 
wrote:

 On 7/20/15 5:30 PM, Martin Nowak wrote:

 On Thursday, 16 July 2015 at 08:28:08 UTC, Suliman wrote:

 In what version of DMD do you plan to include dub and vibe?


 It doesn't make sense to include vibe.d.


 I think it does - this has been discussed before. -- Andrei


It has, in length 
http://forum.dlang.org/post/mdnrus$188e$1 digitalmars.com, but 
you remain one of the very few to think it is a good idea to 
distribute vibe.d with dmd.

It doesn't make sense because dub is the enabling tool for the 
whole package ecosystem, with which vibe.d is fully integrated 
(dub was formerly called vpm - vibe package manager).
Copying a vibe.d version into the distribution creates a lot of 
problems without solving anything.

- what about vibe.d's dependencies
- how would dub know about the distributed vibe.d package
- how to use multiple vibe.d versions in parallel

If your long-term goal is to integrate vibe into phobos, fine,
though I'm not a fan of this strategy b/c an independent package 
ecosystem can grow faster.
Simply copying a dub package into the distribution doesn't help 
anyone.
Jul 21 2015
next sibling parent reply "extrawurst" <stephan extrawurst.org> writes:
On Tuesday, 21 July 2015 at 07:00:57 UTC, Martin Nowak wrote:

 On Monday, 20 July 2015 at 23:18:34 UTC, Andrei Alexandrescu 
 wrote:

 On 7/20/15 5:30 PM, Martin Nowak wrote:

 On Thursday, 16 July 2015 at 08:28:08 UTC, Suliman wrote:

 [...]


 It doesn't make sense to include vibe.d.


 I think it does - this has been discussed before. -- Andrei


 It has, in length 
 http://forum.dlang.org/post/mdnrus$188e$1 digitalmars.com, but 
 you remain one of the very few to think it is a good idea to 
 distribute vibe.d with dmd.

 It doesn't make sense because dub is the enabling tool for the 
 whole package ecosystem, with which vibe.d is fully integrated 
 (dub was formerly called vpm - vibe package manager).
 Copying a vibe.d version into the distribution creates a lot of 
 problems without solving anything.

 - what about vibe.d's dependencies
 - how would dub know about the distributed vibe.d package
 - how to use multiple vibe.d versions in parallel

 If your long-term goal is to integrate vibe into phobos, fine,
 though I'm not a fan of this strategy b/c an independent 
 package ecosystem can grow faster.
 Simply copying a dub package into the distribution doesn't help 
 anyone.


I agree, i am a fan of vibe.d too but including it in phobos just 
tastes wrong. if you absolutely want to distribute such a lib 
then consider libasync (https://github.com/etcimon/libasync) 
which is at least completely written in D.
Jul 21 2015
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 21/07/2015 8:07 p.m., extrawurst wrote:

 On Tuesday, 21 July 2015 at 07:00:57 UTC, Martin Nowak wrote:

 On Monday, 20 July 2015 at 23:18:34 UTC, Andrei Alexandrescu wrote:

 On 7/20/15 5:30 PM, Martin Nowak wrote:

 On Thursday, 16 July 2015 at 08:28:08 UTC, Suliman wrote:

 [...]


 It doesn't make sense to include vibe.d.


 I think it does - this has been discussed before. -- Andrei


 It has, in length
 http://forum.dlang.org/post/mdnrus$188e$1 digitalmars.com, but you
 remain one of the very few to think it is a good idea to distribute
 vibe.d with dmd.

 It doesn't make sense because dub is the enabling tool for the whole
 package ecosystem, with which vibe.d is fully integrated (dub was
 formerly called vpm - vibe package manager).
 Copying a vibe.d version into the distribution creates a lot of
 problems without solving anything.

 - what about vibe.d's dependencies
 - how would dub know about the distributed vibe.d package
 - how to use multiple vibe.d versions in parallel

 If your long-term goal is to integrate vibe into phobos, fine,
 though I'm not a fan of this strategy b/c an independent package
 ecosystem can grow faster.
 Simply copying a dub package into the distribution doesn't help anyone.


 I agree, i am a fan of vibe.d too but including it in phobos just tastes
 wrong. if you absolutely want to distribute such a lib then consider
 libasync (https://github.com/etcimon/libasync) which is at least
 completely written in D.


+1
Jul 21 2015
prev sibling next sibling parent reply "Suliman" <evermind live.ru> writes:
So maybe would be good to pot in phobos vibe's json lib and some 
other good stuff, to prevent overlapping phobos and vibe's lib 
that are doing similar things?
Jul 21 2015
next sibling parent "extrawurst" <stephan extrawurst.org> writes:
On Tuesday, 21 July 2015 at 08:36:12 UTC, Suliman wrote:

 So maybe would be good to pot in phobos vibe's json lib and 
 some other good stuff, to prevent overlapping phobos and vibe's 
 lib that are doing similar things?


I think sönke did already start to work on the json lib at least
Jul 21 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/21/15 4:36 AM, Suliman wrote:

 So maybe would be good to pot in phobos vibe's json lib and some other
 good stuff, to prevent overlapping phobos and vibe's lib that are doing
 similar things?


Yes. -- Andrei
Jul 21 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/21/15 4:07 AM, extrawurst wrote:

 I agree, i am a fan of vibe.d too but including it in phobos just tastes
 wrong.


I was thinking of distributing vibe.d as an integrated but distinct 
package, not part of phobos.


 if you absolutely want to distribute such a lib then consider
 libasync (https://github.com/etcimon/libasync) which is at least
 completely written in D.


Yah, phobos needs features to better support vibe.d and libasync is one 
of them.


Andrei
Jul 21 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/21/15 3:00 AM, Martin Nowak wrote:

 On Monday, 20 July 2015 at 23:18:34 UTC, Andrei Alexandrescu wrote:

 On 7/20/15 5:30 PM, Martin Nowak wrote:

 On Thursday, 16 July 2015 at 08:28:08 UTC, Suliman wrote:

 In what version of DMD do you plan to include dub and vibe?


 It doesn't make sense to include vibe.d.


 I think it does - this has been discussed before. -- Andrei


 It has, in length
 http://forum.dlang.org/post/mdnrus$188e$1 digitalmars.com, but you
 remain one of the very few to think it is a good idea to distribute
 vibe.d with dmd.


Probably I need to better explain why I think we should try that.

It all starts with a high level thought. We want to accelerate D 
adoption rate way beyond what it is now. Radically, like 10x. We've done 
a number of things, many of which helped. But there's this thought - if 
we keep on doing what we've been doing, we'll keep on getting the 
results we've been getting. (There could be changes of phase, synergy, 
cumulative effects etc. but just waiting for those to happen doesn't 
sound like the best tactics.)

So I keep an eye on radical new things we could try - things we have not 
done before, and that have worked for others. Some might just not work, 
but we don't know if we don't just try.

At the first D meetup in the Silicon Valley, Vic (an accomplished 
entrepreneur who has been following up D'd path) discussed some ideas 
for improving D's adoption. He mentioned some other languages have 
improved adoption by means of a strong application (e.g. Rails for Ruby) 
and suggested we make vibe.d, which is one of D's most compelling 
publicly available applications, more prominent among D's toolchain. He 
mentioned that many folks start with the high-level need ("I need a web 
framework") and accept the language as an artifact.

I think that's a good idea to try, for several reasons. First, it will 
enhance vibe.d's visibility (there are quite a few D users who haven't 
heard of vibe). Second, it consolidates things and makes it easy for 
folks who want to get vibe.d - no more version incompatibilities, 
multiple downloads, things that don't mesh etc. Third, it provides even 
non-vibe users with a good example of a large framework written in D 
that they may use for inspiration and good language use.


 It doesn't make sense because dub is the enabling tool for the whole
 package ecosystem, with which vibe.d is fully integrated (dub was
 formerly called vpm - vibe package manager).
 Copying a vibe.d version into the distribution creates a lot of problems
 without solving anything.


I agree it does not "solve" anything the same way Rails does not "solve" 
anything for Ruby.


 - what about vibe.d's dependencies
 - how would dub know about the distributed vibe.d package
 - how to use multiple vibe.d versions in parallel


These may be framed two ways. One is, these are arguments to not 
integrate vibe.d with D. The other is, we buy into the vision that we 
should try bundling vibe with D, and as a matter of course we need to 
solve some practical matters. Clearly these all are solvable.


 If your long-term goal is to integrate vibe into phobos, fine,
 though I'm not a fan of this strategy b/c an independent package
 ecosystem can grow faster.
 Simply copying a dub package into the distribution doesn't help anyone.


I think it could help. This is like one of those business ideas 
discussions - there are lots of reasons for which any isn't going to 
work. The point is finding ways to make it work.


Andrei
Jul 21 2015
next sibling parent "extrawurst" <stephan extrawurst.org> writes:
On Tuesday, 21 July 2015 at 13:17:36 UTC, Andrei Alexandrescu 
wrote:

 On 7/21/15 3:00 AM, Martin Nowak wrote:

 [...]


 Probably I need to better explain why I think we should try 
 that.

 [...]


I can agree with the idea behind it, I am just apposed adding the 
package to the actual download bundle because of it would 
decouple it from an ecosystem that we want to encourage D users 
to use: dub

Bundling dub with dmd IMO will be a major thing helping people 
benefit from all the awesome work that went into all the great 
libs and applications in there.

Maybe we can go by an installer option that automatically creates 
a vibe.d example project and lunching it (while using dub for 
that all the way).


 [...]
Jul 21 2015
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/21/15 9:17 AM, Andrei Alexandrescu wrote:


 At the first D meetup in the Silicon Valley, Vic (an accomplished
 entrepreneur who has been following up D'd path) discussed some ideas
 for improving D's adoption. He mentioned some other languages have
 improved adoption by means of a strong application (e.g. Rails for Ruby)
 and suggested we make vibe.d, which is one of D's most compelling
 publicly available applications, more prominent among D's toolchain. He
 mentioned that many folks start with the high-level need ("I need a web
 framework") and accept the language as an artifact.


Rails is not shipped with ruby. You have to install it separately. In 
fact, vibe.d follows almost the same model as rails (I may be sketchy on 
the details, still learning ruby/rails), with gem substituting for dub.

I think what we need is dub to be shipped with d (If it's not already).

-Steve
Jul 21 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/21/15 9:34 AM, Steven Schveighoffer wrote:

 On 7/21/15 9:17 AM, Andrei Alexandrescu wrote:


 At the first D meetup in the Silicon Valley, Vic (an accomplished
 entrepreneur who has been following up D'd path) discussed some ideas
 for improving D's adoption. He mentioned some other languages have
 improved adoption by means of a strong application (e.g. Rails for Ruby)
 and suggested we make vibe.d, which is one of D's most compelling
 publicly available applications, more prominent among D's toolchain. He
 mentioned that many folks start with the high-level need ("I need a web
 framework") and accept the language as an artifact.


 Rails is not shipped with ruby.


That doesn't dilute my point. -- Andrei
Jul 21 2015
parent "krzaq" <dlangmailinglist krzaq.cc> writes:
On Tuesday, 21 July 2015 at 14:07:22 UTC, Andrei Alexandrescu 
wrote:

 On 7/21/15 9:34 AM, Steven Schveighoffer wrote:

 On 7/21/15 9:17 AM, Andrei Alexandrescu wrote:


 At the first D meetup in the Silicon Valley, Vic (an 
 accomplished
 entrepreneur who has been following up D'd path) discussed 
 some ideas
 for improving D's adoption. He mentioned some other languages 
 have
 improved adoption by means of a strong application (e.g. 
 Rails for Ruby)
 and suggested we make vibe.d, which is one of D's most 
 compelling
 publicly available applications, more prominent among D's 
 toolchain. He
 mentioned that many folks start with the high-level need ("I 
 need a web
 framework") and accept the language as an artifact.


 Rails is not shipped with ruby.


 That doesn't dilute my point. -- Andrei


If vibe.d is to be distributed with D, it would be preferable to 
have MySQL support out of the box.
Jul 21 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-07-21 15:34, Steven Schveighoffer wrote:


 Rails is not shipped with ruby. You have to install it separately. In
 fact, vibe.d follows almost the same model as rails (I may be sketchy on
 the details, still learning ruby/rails), with gem substituting for dub.

 I think what we need is dub to be shipped with d (If it's not already).


Yeah, RubyGems is bundled these days with Ruby. We need to do that same 
with Dub.

-- 
/Jacob Carlborg
Jul 21 2015
prev sibling next sibling parent Mathias Lang via Digitalmars-d <digitalmars-d puremagic.com> writes:
2015-07-21 15:17 GMT+02:00 Andrei Alexandrescu via Digitalmars-d <
digitalmars-d puremagic.com>:


 Probably I need to better explain why I think we should try that.

 It all starts with a high level thought. We want to accelerate D adoption
 rate way beyond what it is now. Radically, like 10x. We've done a number of
 things, many of which helped. But there's this thought - if we keep on
 doing what we've been doing, we'll keep on getting the results we've been
 getting. (There could be changes of phase, synergy, cumulative effects etc.
 but just waiting for those to happen doesn't sound like the best tactics.)

 So I keep an eye on radical new things we could try - things we have not
 done before, and that have worked for others. Some might just not work, but
 we don't know if we don't just try.

 At the first D meetup in the Silicon Valley, Vic (an accomplished
 entrepreneur who has been following up D'd path) discussed some ideas for
 improving D's adoption. He mentioned some other languages have improved
 adoption by means of a strong application (e.g. Rails for Ruby) and
 suggested we make vibe.d, which is one of D's most compelling publicly
 available applications, more prominent among D's toolchain. He mentioned
 that many folks start with the high-level need ("I need a web framework")
 and accept the language as an artifact.

 I think that's a good idea to try, for several reasons. First, it will
 enhance vibe.d's visibility (there are quite a few D users who haven't
 heard of vibe). Second, it consolidates things and makes it easy for folks
 who want to get vibe.d - no more version incompatibilities, multiple
 downloads, things that don't mesh etc. Third, it provides even non-vibe
 users with a good example of a large framework written in D that they may
 use for inspiration and good language use.


It is a good idea, but there are other ways to achieve it.
Vibe.d is ATM going in the other direction: Plan is to split it up in more
smaller chunks, and encourage people to write plugins to it: markdown /
reST processors being the leading examples . See the following comment:
https://github.com/rejectedsoftware/vibe.d/issues/1134#issuecomment-111365416
Enhancing visibility won't happen by just bundling it. We can write a
"getting started with Vibe" or "Web development using D" on the website.
Someone would want to take a shot at it / contribute to that ?
We could also, at a later stage, integrate Vibe.d's docs within the website.

Regarding version incompatibilities: read my previous post.


 - what about vibe.d's dependencies

 - how would dub know about the distributed vibe.d package
 - how to use multiple vibe.d versions in parallel


 These may be framed two ways. One is, these are arguments to not integrate
 vibe.d with D. The other is, we buy into the vision that we should try
 bundling vibe with D, and as a matter of course we need to solve some
 practical matters. Clearly these all are solvable.


Once again, bundling it would be against where Vibe is currently going at :
more features by creating smaller packages that integrates together.
Jul 21 2015
prev sibling next sibling parent reply "notna" <notna.remove.this ist-einmalig.de> writes:
If we want to accelerate D2 adoption, we need too:

- have more and better WORKING examples. More or less, a workable 
"copy-paste" approach for (almost) every module and function...
- make D2 easy2use for "not C++/Java/whatever gurus" again
   -> all this different "types", which are either required as an 
input for functions or are returned from those and need to be 
casted/converted all the time... frustrating for real "new comers"
   -> it all starts with "string" and "char[]" stuff, but is 
really a nightmare with all the ranges and things which need to 
be converted all the time, i.e. like with ".array"... I couldn't 
convince colleagues to use D2 because it's just to complicate 
already for the low level things like those!

In short, I would:
- NOT include VIBE.D and such things into the core lang, but make 
it a breeze to integrate such modules with DUB
- make every D2 function accept and return "string"s and 
"[dw]char[]" (THAT would be a radical new thing for D2, maybe!)


On Tuesday, 21 July 2015 at 13:17:36 UTC, Andrei Alexandrescu 
wrote:

 It all starts with a high level thought. We want to accelerate 
 D adoption rate way beyond what it is now. Radically, like 10x. 
 We've done a number of things, many of which helped. But 
 there's this thought - if we keep on doing what we've been 
 doing, we'll keep on getting the results we've been getting. 
 (There could be changes of phase, synergy, cumulative effects 
 etc. but just waiting for those to happen doesn't sound like 
 the best tactics.)

 So I keep an eye on radical new things we could try - things we 
 have not done before, and that have worked for others. Some 
 might just not work, but we don't know if we don't just try.


  ~~~ snip ~~~

 Andrei
Jul 21 2015
parent reply "wobbles" <grogan.colin gmail.com> writes:
On Tuesday, 21 July 2015 at 14:59:21 UTC, notna wrote:
[...snip...]

 - make D2 easy2use for "not C++/Java/whatever gurus" again
   -> all this different "types", which are either required as 
 an input for functions or are returned from those and need to 
 be casted/converted all the time... frustrating for real "new 
 comers"


[...snip...]

Huh? Whats frustrating about it?
It's a statically typed language, there's always going to be 
"types".
We have the 'auto' keyword for type inference though, which 
really makes it feel like a scripting language.
Honestly, the biggest advice I can give to real new-comers is to 
use auto for a while till you get a feel for it.
Jul 21 2015
parent "notna" <notna.remove.this ist-einmalig.de> writes:
On Tuesday, 21 July 2015 at 15:36:56 UTC, wobbles wrote:

 On Tuesday, 21 July 2015 at 14:59:21 UTC, notna wrote:
 [...snip...]

 - make D2 easy2use for "not C++/Java/whatever gurus" again
   -> all this different "types", which are either required as 
 an input for functions or are returned from those and need to 
 be casted/converted all the time... frustrating for real "new 
 comers"


 [...snip...]

 Huh? Whats frustrating about it?
 It's a statically typed language, there's always going to be 
 "types".
 We have the 'auto' keyword for type inference though, which 
 really makes it feel like a scripting language.
 Honestly, the biggest advice I can give to real new-comers is 
 to use auto for a while till you get a feel for it.


I think you miss the point... maybe my confusing wording...

"auto" is fantastic, no doubt, but already not always 
usable/working. I think there are plenty ppl out there, who want 
to be sure what will be returned and prefer to specify the return 
type they want/expect. And yes, again, I also like and use 
"auto", as it can make life easy... or not... but only if I know 
what will be returned or I just don't care (like for "write" and 
friends) ;) And "auto" is a good example that auto-conversions 
enhance the user experience, exactly what i want and try to 
suggest/explain here...

What I say is, we should try to make the usage of "string" and 
friends a comfortable no-brainer for all functions and by this 
minimize the "cast|convert hell" by either having always all 
functions accepting and returning basic types like [dw]char, 
[dw]char[], string... or at least forcing the different range 
types to do so. Just remember, most of the data out there is 
still lines, strings, words and/or just a bunch of chars ;)

What i mean with the "cast|convert hell".. Just go to the Phobos 
modules and check out how many casts|conversions are there... or 
search the forum.dlang.org for threads which include the 
suggestion to use the UFCS".array" hack ;) and so on...

example:
    $ egrep -w 
"to\!char|to\!\(char|to\!string|to\!\(string|cast\(char|cast\(string" -c
datetime.d
43

or more general:

    $ egrep -w 'to!|cast' -c *.d
    array.d:52
    ascii.d:9
    base64.d:47
    bigint.d:14
    bitmanip.d:66
    compiler.d:0
    complex.d:1
    concurrency.d:15
    conv.d:176
    cstream.d:8
    csv.d:6
    datetime.d:250
    demangle.d:4
    encoding.d:105
    exception.d:29
    file.d:21
    format.d:125
    functional.d:13
    getopt.d:7
    json.d:2
    math.d:142
    mathspecial.d:0
    metastrings.d:0
    mmfile.d:31
    numeric.d:40
    outbuffer.d:22
    parallelism.d:34
    path.d:19
    process.d:24
    random.d:31
    signals.d:3
    socket.d:85
    socketstream.d:4
    stdint.d:0
    stdio.d:79
    stdiobase.d:0
    stream.d:72
    string.d:98
    syserror.d:1
    system.d:0
    traits.d:3
    typecons.d:65
    typelist.d:0
    typetuple.d:1
    uni.d:79
    uri.d:27
    utf.d:146
    uuid.d:35
    variant.d:57
    xml.d:42
    zip.d:44
    zlib.d:28

I hope it's clearer now what I was trying to say before :O
Jul 21 2015
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 07/21/2015 09:17 AM, Andrei Alexandrescu wrote:

 At the first D meetup in the Silicon Valley, Vic (an accomplished
 entrepreneur who has been following up D'd path) discussed some ideas
 for improving D's adoption. He mentioned some other languages have
 improved adoption by means of a strong application (e.g. Rails for Ruby)
 and suggested we make vibe.d, which is one of D's most compelling
 publicly available applications, more prominent among D's toolchain. He
 mentioned that many folks start with the high-level need ("I need a web
 framework") and accept the language as an artifact.


Maybe this suggests that perhaps Vibe.d should (optionally) come with a 
copy of DMD, rather than the other way around?
Jul 21 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-07-21 15:17, Andrei Alexandrescu wrote:


 So I keep an eye on radical new things we could try - things we have not
 done before, and that have worked for others. Some might just not work,
 but we don't know if we don't just try.


It sounds like you want to give it a try and see what happens. I would 
be a bit careful with that, in regard to the very strong policy of no 
breaking changes. If it turns out that it doesn't work so well it might 
be hard to remove.

How about we start with bundling Dub and see what happens? Then at a 
later point we can discuss what to do about vibe.d.

-- 
/Jacob Carlborg
Jul 21 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/21/15 12:22 PM, Jacob Carlborg wrote:

 How about we start with bundling Dub and see what happens? Then at a
 later point we can discuss what to do about vibe.d.


Yah, nice. -- Andrei
Jul 21 2015
parent "suliman" <Evermind live.ru> writes:
On Tuesday, 21 July 2015 at 16:27:24 UTC, Andrei Alexandrescu 
wrote:

 On 7/21/15 12:22 PM, Jacob Carlborg wrote:

 How about we start with bundling Dub and see what happens? 
 Then at a
 later point we can discuss what to do about vibe.d.


 Yah, nice. -- Andrei


So why we can't simply add vibed in manner of VS addon?
What about make some of api common for D and vibed?
And yes, vibe should have by default mysql driver. I am not a fun 
of mysql, but it will help people to start develop much faster.
Jul 21 2015
prev sibling parent reply "yawniek" <dlang srtnwz.com> writes:
On Tuesday, 21 July 2015 at 13:17:36 UTC, Andrei Alexandrescu 
wrote:


 At the first D meetup in the Silicon Valley, Vic (an 
 accomplished entrepreneur who has been following up D'd path) 
 discussed some ideas for improving D's adoption. He mentioned 
 some other languages have improved adoption by means of a 
 strong application (e.g. Rails for Ruby) and suggested we make 
 vibe.d, which is one of D's most compelling publicly available 
 applications, more prominent among D's toolchain. He mentioned 
 that many folks start with the high-level need ("I need a web 
 framework") and accept the language as an artifact.


great point, i was one of these people.
my requirements where simple:
- needs to be ultrafast
- needs to produce binary
- bonus: nice language, many libraries.
in the end it was GO (many libs, shitty lang) vs. D (not so many 
libs, great lang,faster)

but i don't think bundling vibe will help.
bundling dub will be enough. you just do dub init -t vibe.d and 
you're set.
plus you will hopefully have the latest stable version 
automatically.

imho the following stuff is missing/could be done to lower the 
barrier of entry
(some have been mentioned already):

general language:
- join the forums. create a place to discuss vibe that has some 
traffic already.
- ability to add code snippets/comments to the documentation 
(this was php's way to success back in the days). A risky 
strategy because of the trash,but maybe worth thinking about

vibe:
- a cool example project (e.g. a clone of hackernews similar to 
lobste.rs. )
- include/document (postgres)sql database access (ddb?)

nice to haves:
- plugin system with generators e.g. for Users, Authorization etc.
- some live compile/reload loop for development (via shared libs?)
- same for release. how do i deploy a new version without loosing 
requests (as for me, i currently just use nginx)
Aug 06 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 6/08/2015 10:28 p.m., yawniek wrote:

 On Tuesday, 21 July 2015 at 13:17:36 UTC, Andrei Alexandrescu wrote:


 At the first D meetup in the Silicon Valley, Vic (an accomplished
 entrepreneur who has been following up D'd path) discussed some ideas
 for improving D's adoption. He mentioned some other languages have
 improved adoption by means of a strong application (e.g. Rails for
 Ruby) and suggested we make vibe.d, which is one of D's most
 compelling publicly available applications, more prominent among D's
 toolchain. He mentioned that many folks start with the high-level need
 ("I need a web framework") and accept the language as an artifact.


 great point, i was one of these people.
 my requirements where simple:
 - needs to be ultrafast
 - needs to produce binary
 - bonus: nice language, many libraries.
 in the end it was GO (many libs, shitty lang) vs. D (not so many libs,
 great lang,faster)

 but i don't think bundling vibe will help.
 bundling dub will be enough. you just do dub init -t vibe.d and you're set.
 plus you will hopefully have the latest stable version automatically.

 imho the following stuff is missing/could be done to lower the barrier
 of entry
 (some have been mentioned already):

 general language:
 - join the forums. create a place to discuss vibe that has some traffic
 already.
 - ability to add code snippets/comments to the documentation (this was
 php's way to success back in the days). A risky strategy because of the
 trash,but maybe worth thinking about

 vibe:
 - a cool example project (e.g. a clone of hackernews similar to
 lobste.rs. )
 - include/document (postgres)sql database access (ddb?)

 nice to haves:
 - plugin system with generators e.g. for Users, Authorization etc.
 - some live compile/reload loop for development (via shared libs?)


Definitely possible[0]. But Vibe.d is the wrong place to go looking at 
it. We need a web application server ala Java/JSP style.

And yes, I'm working on it :)
There are dependencies missing still unfortunately to do it effectively. 
E.g. VFS (yes a requirement). Again, working on it.

[0] https://github.com/rikkimax/livereload
Aug 06 2015
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 20 July 2015 at 23:18:34 UTC, Andrei Alexandrescu 
wrote:

 On 7/20/15 5:30 PM, Martin Nowak wrote:

 On Thursday, 16 July 2015 at 08:28:08 UTC, Suliman wrote:

 In what version of DMD do you plan to include dub and vibe?


 It doesn't make sense to include vibe.d.


 I think it does - this has been discussed before. -- Andrei


Have you used dub and vibe.d extensively yourself? I'm seeing 
quite a lot of pushback on this idea from people who do.
Jul 21 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/21/15 4:46 AM, John Colvin wrote:

 On Monday, 20 July 2015 at 23:18:34 UTC, Andrei Alexandrescu wrote:

 On 7/20/15 5:30 PM, Martin Nowak wrote:

 On Thursday, 16 July 2015 at 08:28:08 UTC, Suliman wrote:

 In what version of DMD do you plan to include dub and vibe?


 It doesn't make sense to include vibe.d.


 I think it does - this has been discussed before. -- Andrei


 Have you used dub and vibe.d extensively yourself?


No.


 I'm seeing quite a
 lot of pushback on this idea from people who do.


Well we'll need to address it.


Andrei
Jul 21 2015
prev sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Tuesday, 21 July 2015 at 08:46:49 UTC, John Colvin wrote:

 On Monday, 20 July 2015 at 23:18:34 UTC, Andrei Alexandrescu 
 wrote:

 On 7/20/15 5:30 PM, Martin Nowak wrote:

 On Thursday, 16 July 2015 at 08:28:08 UTC, Suliman wrote:

 In what version of DMD do you plan to include dub and vibe?


 It doesn't make sense to include vibe.d.


 I think it does - this has been discussed before. -- Andrei


 Have you used dub and vibe.d extensively yourself? I'm seeing 
 quite a lot of pushback on this idea from people who do.


Granted, I'm on a forked DUB master but I think it absolutely 
belongs to the standard language distribution. The downside of 
not having people discover it is just too huge.
Jul 21 2015
prev sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 14/07/2015 00:09, Sönke Ludwig wrote:

 If everything goes as planned, the 0.9.24 release will be the last one
 before 1.0.0. The two major additions over 0.9.23 are the support for
 SDLang based package descriptions [1] [2] and an extended support for
 "dub describe" and build command environment variable support. See the
 change log for more details.


I've now given this a try with the goal to integrated with DDT. I was 
still using 0.9.21 as the baseline.

DUB 0.9.24 might be required for the next DDT version though, because of 
the build target information added to DUB describe: I'm working on build 
target support in DDT. Originally I was thinking of parsing the JSON 
myself for that bit of info (this is already done to a limited extent 
for source folders if DUB is not present). However if people are going 
to start using SDL package format, not gonna work... -_-

`dub describe` it is. The only problem is that this is still giving me 
some grievances:
https://github.com/D-Programming-Language/dub/issues/580
It was mostly on DDT tests, so it's not a deal-breaker. On the IDE 
itself there is the minor issue that to get build configurations 
information, `dub describe` has to run successfully, thus performing 
full DUB dependency information even though it's not necessary.

BTW --bare is indeed welcome as I have to do some juggling to run 
several tests with code that integrates with DUB. But --bare is still 
very limited: you cant run `dub describe` on a directory of a DUB 
package. You have to run on the parent directory, which means you need 
to figure out the actual name of the DUB package (merely specifying the 
directory doesn't work). A bit of an annoyance.
Why not simply have an option to specify the directory of the DUB local 
registry (the one with the local-packages.json file)? Such an option 
might have other uses as well, even beyond `dub describe`. This registry 
singleton shouldn't be hardcoded to just a default location.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Aug 04 2015
next sibling parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 04/08/2015 16:52, Bruno Medeiros wrote:

 DUB 0.9.24 might be required for the next DDT version though, because of
 the build target information added to DUB describe: I'm working on build
 target support in DDT. Originally I was thinking of parsing the JSON
 myself for that bit of info (this is already done to a limited extent
 for source folders if DUB is not present). However if people are going
 to start using SDL package format, not gonna work... -_-


I spoke too soon. Seems like the new "targets" info in describe only 
lists the targets for current config, for each dependency. :(

So, is there a way to list all build configurations of a DUB package?

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Aug 04 2015
prev sibling parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 04/08/2015 16:52, Bruno Medeiros wrote:

 BTW --bare is indeed welcome as I have to do some juggling to run
 several tests with code that integrates with DUB. But --bare is still
 very limited: you cant run `dub describe` on a directory of a DUB
 package. You have to run on the parent directory, which means you need
 to figure out the actual name of the DUB package (merely specifying the
 directory doesn't work). A bit of an annoyance.
 Why not simply have an option to specify the directory of the DUB local
 registry (the one with the local-packages.json file)? Such an option
 might have other uses as well, even beyond `dub describe`. This registry
 singleton shouldn't be hardcoded to just a default location.


Opened https://github.com/D-Programming-Language/dub/issues/641

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Aug 05 2015