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

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

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

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

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)

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