On 08/05/10 21:35, Simen kjaeraas wrote:
> Why invent a new keyword? Surely this is a match for extern:
>
> extern import foo.bar.baz.vert1_23;

It's not a keyword, hence the @ :) This said, extern could be a match, if a keyword is needed (see Nick's response).

On Fri, 07 May 2010 22:36:22 -0400, Nick Sabalausky wrote:

> "Leandro Lucarella" <llucax@gmail.com> wrote in message news:20100508011012.GA32072@llucax.com.ar...
>> Walter Bright, el  7 de mayo a las 13:18 me escribiste:
>>> Johan Granberg wrote:
>>> >Walter Bright wrote:
>>> >
>>> >>Jacob Carlborg wrote:
>>> >>>Should it also contain something similar to rdmd?
>>> >>I kind of like the idea that it shouldn't install D packages, but
>>> >>rather
>>> >>cache them from the web repository. It would be convenient because:
>>> >>
>>> >>1. who actually cares about installing the packages
>>> >
>>> >If I was administering a server or multiuser system or linux
>>> >distribution I
>>> >would care, being able to install packages and libraries globaly for
>>> >all users easily can be important.
>>>
>>> The caching should handle that transparently.
>>
>> Already done:
>> http://0install.net/
>>
>> Too bad (or good?) nobody uses or know it.
>>
>>
> That looks absolutely awesome! My only little concern is that it's written in python, I had to use bazaar to do something one time and it was insanely slow.

The speed will depend on your computer, of course, but the overhead on my laptop of using it is around 0.07s (70 ms) to select the versions to use and check they're cached. If they're not cached, the network is the limiting factor, naturally. Using 0compile (which also sets up build directories and generates XML metadata about the build), it seems to add about 0.5s per build:

  http://0install.net/0compile.html

A more likely problem is portability, since Windows users might not want to have to install Python (although someone is writing a .NET version).

It should work well for D, as the Delight fork uses it (e.g. see the installation instructions at http://delight.sourceforge.net/install.html). If anyone wants to discuss it, you're welcome on the mailing list:

  http://0install.net/support.html

Cheers,


-- 
Dr Thomas Leonard
(author of Zero Install and the Delight experimental fork of D)

On 05/07/2010 04:50 PM, Leandro Lucarella wrote:
> Graham Fawcett, el  7 de mayo a las 12:30 me escribiste:
>> On Fri, 07 May 2010 08:26:02 -0400, bearophile wrote:
>>
>>> Graham Fawcett:
>>>
>>>> Finally, he returns to his original application, and replaces the Go
>>>> equivalent of "import mytools;" with "import github.com/nf/mytools;"
>>>> and the application now refers to the version of mytools that was
>>>> installed from Github.
>>>
>>> Is this any safe to do?
>>
>> For certain definitions of safety: yes, or no. :) What did you have in
>> mind?
>>
>>>> (by the way, I'm overloading the term "package" here, at times to mean
>>>> a package in the D sense, but usually to mean a downloadable and
>>>> installable unit.)
>>>
>>> Python for this has Eggs, Ruby has Gems, D needs Satellites ;-)
>>
>> Satellites works for me. While they download, we could call them
>> meteorites. :)
>
> I think it's better to have a short name. What about rocks? ;)
>
Lua has rocks.

Hello Simen,

> Robert Clipsham <robert@octarineparrot.com> wrote:
> 
>> How about:
>> 
>> @remote import foo.bar.baz.ver1_23;
>> 
> Why invent a new keyword? Surely this is a match for extern:
> 
> extern import foo.bar.baz.vert1_23;
> 

For that matter, why even hard code that info the the code at all?

-- 
... <IXOYE><

Hello Robert,

> no language
> changes needed (except maybe to remove the .ver1_23... how would the
> compiler know when to do this though?).

how about a pragama:

pragma(ver, "1.23", "$") import foo.bar.baz; // imports foo.bar.baz, require a version at or later than 1.23 

-- 
... <IXOYE><

Pelle, el  9 de mayo a las 15:39 me escribiste:
> >>Satellites works for me. While they download, we could call them meteorites. :)
> >
> >I think it's better to have a short name. What about rocks? ;)
> >
> Lua has rocks.

D'oh! I've used lua a couple of times but never heard about rocks...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Y ya no tengo colores, sólo gris y negro
Aquí donde el amor es de hierro
Los días pasan y moriremos contando el tiempo

"BCS" <none@anon.com> wrote in message news:a6268ff137a98ccbd7270f72004@news.digitalmars.com...
> Hello Robert,
>
>> no language
>> changes needed (except maybe to remove the .ver1_23... how would the
>> compiler know when to do this though?).
>
> how about a pragama:
>
> pragma(ver, "1.23", "$") import foo.bar.baz; // imports foo.bar.baz, require a version at or later than 1.23

I have a mixed opinion on that. On one hand, being able to specify either a specific version or an arbitrary range matches real-world cases much better than "any version" vs "this exact version". However, different programs and libs use different versioning conventions. For example: Are "v1.1" and "v1.100" the same or is the latter much newer? Or, which is first, "v1.100" vs "v1.99"? Also, I can imagne certain programs may be able to work with more complex ranges. For instace, maybe FooApp can use BarLib's "v1.x" branch as long as it's at least "v1.7", and it can also use any version of the "v2.x" branch from "v2.1" through "v2.5", but "v2.4.3" through "v2.4.8" are known to have problems.

So maybe trying to allow ranges (even one as simple as "at least vX.X") is just too complicated, and should be left to static if(), and the "helping the compiler automatically download/install a dependency" should be limited to an option between one specific known-working version or the latest version. So something roughly like:

enum suggestedBarLib = "http://www.barlib.com/packages/barlib-v2.6.dstone";
pragma(ifMissingGetFrom, suggestedBarLib) import barlib;
static if(!IsAcceptableBarLibVersion!(BarLibVersion))
{
    pragma(importFrom, suggestedBarLib);
}

And then maybe some sort of sugar could be added later (maybe it could all be wrapped up in a mixin).

Hello Nick,

> "BCS" <none@anon.com> wrote in message
> news:a6268ff137a98ccbd7270f72004@news.digitalmars.com...
> 
>> pragma(ver, "1.23", "$") import foo.bar.baz; // imports foo.bar.baz,
>> require a version at or later than 1.23
>> 
> I have a mixed opinion on that. On one hand, being able to specify
> either a specific version or an arbitrary range matches real-world
> cases much better than "any version" vs "this exact version". However,
> different programs and libs use different versioning conventions. For
> example: Are "v1.1" and "v1.100" the same or is the latter much newer?
> Or, which is first, "v1.100" vs "v1.99"? Also, I can imagne certain
> programs may be able to work with more complex ranges. For instace,
> maybe FooApp can use BarLib's "v1.x" branch as long as it's at least
> "v1.7", and it can also use any version of the "v2.x" branch from
> "v2.1" through "v2.5", but "v2.4.3" through "v2.4.8" are known to have
> problems.

Good, point. Dealing with that client side might be an issue. So how about do it server side? Define a way to map the given string (or strings) to something that can be handed off to the server and let the server do whatever it wants with it. The simplest one would be Nick's suggestion of allowing %VERSION% or the like in the mappings specifications.

OTOH how do you deal with sever libraries asking for different versions? The simplest option would be to allow the pragma to take a ordered list of preferences and have DMD try to find a common version.

-- 
... <IXOYE><

"BCS" <none@anon.com> wrote in message news:a6268ff137cd8ccbd85902a1798@news.digitalmars.com...
>
> Good, point. Dealing with that client side might be an issue. So how about do it server side? Define a way to map the given string (or strings) to something that can be handed off to the server and let the server do whatever it wants with it. The simplest one would be Nick's suggestion of allowing %VERSION% or the like in the mappings specifications.
>

Actually, that was Robert's (very good) idea.

> OTOH how do you deal with sever libraries asking for different versions?

Can you clarify? I'm not sure what you mean by that.

> The simplest option would be to allow the pragma to take a ordered list of preferences and have DMD try to find a common version.
>

Hello Nick,

> "BCS" <none@anon.com> wrote in message
> news:a6268ff137cd8ccbd85902a1798@news.digitalmars.com...
> 
>> OTOH how do you deal with sever libraries asking for different
>> versions?
>> 
> Can you clarify? I'm not sure what you mean by that.
> 

My program imports lib A and B. Lib A imports lib C and asks for version "X". Lib B imports lib C and asks for version "!X". Who wins?

>> The simplest option would be to allow the pragma to take a ordered
>> list of preferences and have DMD try to find a common version.
>> 
-- 
... <IXOYE><