On Mon, 27 Oct 2014 03:34:34 +0000
Tofu Ninja via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

p.s. no, really, we have a VERY powerful scripting language built into DMD itself! why we should resort to plugin libraries or so?

i know that it's a mad idea. well, that's 'cause i'm a madman! ;-)

On Monday, 27 October 2014 at 03:24:47 UTC, Ola Fosheim Grøstad wrote:
> That's ok for a personal user account, but not for a work account IMO.
>
> Then again, I prefer to fetch directly from repos manually and only use dub-like features for languages that run in a VM.

What I am saying is that unless you read every line of all the libraries that you want to use and de-compile every precompiled library and read the asm, you are taking a risk, any of that code could do malicious things. You draw a line.

> Another point is that if you make fetching libraries too easy it means bloat starts creeping in. OK for a scripting language, but for a system level language…? You risk ending up with Tango-bloat, where you cannot include anything without pulling inn all kinds of dependencies.

The whole point of the thing is to get the benefits of a large library without having a bloated standard lib. Obviously none of phobos would depend on anything in dub. But users need things out side of phobos, why would we want to make getting that harder?

On Monday, 27 October 2014 at 03:42:08 UTC, ketmar via Digitalmars-d wrote:
> i'm dreaming about having this as CTFE interface. one, for example,
> could write special module like 'core.import_resolver', DMD will load
> and parse it when it encounters missing import, and then evaluate some
> of it's well-defined API funcions that can prepare command line for the
> necessary tool or even execute that tool and parse it's output.
>
> sure, this is not safe and not secure, so such such things as "allow
> import resolver to execute external programs" must be explicitly
> enabled with some CLI switch.

I have brought up the idea of executing external exe's at compile time and capturing the output a few times before. Specifically for the use you just mentioned. But every time I suggest it, it gets shot down with concerns over security.

On Mon, 27 Oct 2014 03:55:50 +0000
Tofu Ninja via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> I have brought up the idea of executing external exe's at compile time and capturing the output a few times before. Specifically for the use you just mentioned. But every time I suggest it, it gets shot down with concerns over security.
at least i can still summon OOM-killer with CTFE code and hope that it will kill something completely unrelated to the compiler. still fun! ;-)

On Monday, 27 October 2014 at 02:33:18 UTC, Tofu Ninja wrote:
> I don't think this is a new idea but it would be pretty awesome.
>
> So the idea is that the compiler could check dub for libraries that it can't find and automatically download and integrate them. It would essentially make all of dub seem like it was a part of the standard lib and make integrating dub into projects seamless.
>
> Something like "import derelict.opengl3.gl3;" could automatically trigger dub if the import was not found on any local path.
>
> It also might need some special syntax for version specifications.
>
> It would require some work on both sides. Obviously the compiler would need to change but dub would have to as well, I don't think currently there is any way to look up a dub package by an import statement alone.
>
>
>
> Pros:
> Greatly increase ease of dub use.
> Greatly increase libraries that "seem" to be a part of the std lib.
> Would solve the large vs small stdlib dilemma.
>
> Cons:
> Could degrade perceived quality of stdlib if bad dub packages got in.
> Would mean some things could not be compiled without an internet connection.
>
> My answers to those cons would be
>
> 1)
> It might require some policing to make sure quality stays high.
> Maybe even with votes on what dub packages could automatically be picked up by this similar to how packages get into phobos but with a much lower bar.
>
> Also maybe a different import syntax for these imports to clearly differentiate them so that we can draw a line between the standard lib and dub. (personally I don't like that idea, I like the idea of seamless integration)
>
> 2)
> Normal code would still compile like normal, this would only open up the option of automatic library download for basically the 99% of people who always have an internet connection.
>
>
>
>
> So yeah...
> Thoughts?

I'm against it. dub already tracks down libraries for you if need
them, and dub already calls dmd for you. So all this seems like
to me is calling dmd on the command line would just essentially
be calling dub.
I much rather have a clean distinction between the toolkit and
the compiler. Anyways, automating things just for the sake of
automating them isn't a very good idea. I'm mainly offset by the
idea that my compiler is chatting away with some server in hopes
of finding a missing library or file. Downloading whatever I need
and properly calling it is cleaner, safer, and more organized.

The idea sounds like in the end it would primarily just help
hobbyist or someone looking to just quickly prototype something.
So instead of fancying up/complicating dmd a better solution
would be to improve dub in someway, make a new tool, or if we
really have to do something to dmd then the solution that would
make the most people the happiest would be to allow plugins to
dmd or something, so if people want something like this then they
can add it and then grumpy people like me won't be bothered by it
;P

On Monday, 27 October 2014 at 04:34:41 UTC, Kyoji Klyden wrote:
> I'm against it. dub already tracks down libraries for you if need
> them, and dub already calls dmd for you. So all this seems like
> to me is calling dmd on the command line would just essentially
> be calling dub.
> I much rather have a clean distinction between the toolkit and
> the compiler.

It isn't a big leap from what we have now, but personally I think it would help greatly with generating a larger user base by just making things easier.

> Anyways, automating things just for the sake of
> automating them isn't a very good idea.

We are programmers, isn't that what we do? :P

> I'm mainly offset by the
> idea that my compiler is chatting away with some server in hopes
> of finding a missing library or file. Downloading whatever I need
> and properly calling it is cleaner, safer, and more organized.

I can definitely understand how some people don't like the idea of a compiler that connects to the internet but I don't feel that at all. I have had internet all my life so I am very used to all of my things being connected to the internet 100% of the time.

Also I think it could definitely be argued that an automated(well more automated) solution would be cleaner and more organized.

> The idea sounds like in the end it would primarily just help
> hobbyist or someone looking to just quickly prototype something.

That is true. It would get people to play with D more, which is a good thing. Bring more people to D.

> So instead of fancying up/complicating dmd a better solution
> would be to improve dub in someway, make a new tool, or if we
> really have to do something to dmd then the solution that would
> make the most people the happiest would be to allow plugins to
> dmd or something, so if people want something like this then they
> can add it and then grumpy people like me won't be bothered by it
> ;P

I am not sure how dub it self could be changed to do what I proposed, but a new tool like what ketmar suggested or a plugin system could definitely be an option.

On 2014-10-27 03:33, Tofu Ninja wrote:
> I don't think this is a new idea but it would be pretty awesome.
>
> So the idea is that the compiler could check dub for libraries that it
> can't find and automatically download and integrate them. It would
> essentially make all of dub seem like it was a part of the standard lib
> and make integrating dub into projects seamless.

I don't really like the idea. I don't see the point of it, for a couple of reasons:

* There are still other parts of the configuration that needs to live somewhere. Which compiler switches should be used and so on

* I don't know exactly how Dub works but in theory it could ask the registry of the complete set of dependencies for a particular build and start to download all of them. With your suggestion the compiler might need to ask the registry many times to get all dependencies. First it sees "import foo" which it can't resolve and asks the registry about that. Then it needs to compile "foo" to find out if it has any dependencies as well. This applies recursively to all imports

-- 
/Jacob Carlborg

On 10/27/2014 3:40 PM, Tofu Ninja wrote:

>
> It isn't a big leap from what we have now, but personally I think it
> would help greatly with generating a larger user base by just making
> things easier.
>

I can't count the number of times over the years I have heard this as a reason to add feature X to software Y. In reality, it rarely works out that way. For my two cents, I don't see any benefit to integrating dub with dmd when invoking dub does what you want already. dub will eventually ship with dmd releases, so at that point it will be even easier to get going with than it is now without tying it directly to the compiler.

On Monday, 27 October 2014 at 06:40:52 UTC, Tofu Ninja wrote:
>...

I definitely get your perspective on this whole thing and can see
the appeal to it all, but I feel like it really is just
complicating things in ways it doesn't need to be complicated. It
definitely would make things easier for new users, but for
long-term/hardcore D user, it would just be a complete liability.
Especially large teams or companies, wouldn't gain anything from
this.
So I guess what I'm trying to get to is this feature would
benefit lone, new programmers/users, especially as a draw in, but
nobody else has much at all to gain. I dont intend this to sound
harsh, but if a new programmer can't handle a good old compiler,
then they'd probably be better off using an interpreted language,
such as python. (At least until they're ready for compilers).

Also as Mike Parker just mentioned, dub will be shipping with dmd
in the future, so if you really need to, just use dub in newbie
tutorials or something like that while people get the hang of D.

The only other way I could see this happening aside from a plugin
system, and this suggestion is probably better than my last, is
do a custom dmd build with whatever features you want in it.

I'm happy that your proposed the idea and I love hearing
propositions like this, but I'm gonna pass on this one.

On Mon, 2014-10-27 at 02:33 +0000, Tofu Ninja via Digitalmars-d wrote: […]
> Something like "import derelict.opengl3.gl3;" could automatically trigger dub if the import was not found on any local path.
[…]

Groovy has "grapes" for automated download of dependencies.

        @Grab("org.spockframework:spock-core:0.7-groovy2.0")
        import spock.core.Specification

The artefact is cached locally after first download, but you have to remember to run the script while connected to the Internet. Not that useful for projects where the Gradle script would manage the dependencies, but great for scripts.

Go also allows for import of packages from elsewhere, and I rather like the way that is done, but I think that whole Go mechanism has been slagged off on this list a number of times already. Pity.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder