A screencast overview of the Go package model (writing, publishing,
downloading, and installing third-party code):
http://www.youtube.com/watch?v=jDWBJOXs_iI
Simple and well conceived! I would like this for D please (and am willing
to help :)).
DSSS covers similar ground, but appears to be mo
Graham Fawcett wrote:
Simple and well conceived! I would like this for D please (and am willing
to help :)).
Any help in this direction will be most appreciated.
Hello Graham,
Simple and well conceived! I would like this for D please (and am
willing to help :)).
I haven't watched the video (not enough bandwidth) but I'd like a well done
package tool as well. Thinking in the direction of a spec, what do you like
about the Go system?
Some things I'd
On 5/7/10 00:59, Graham Fawcett wrote:
A screencast overview of the Go package model (writing, publishing,
downloading, and installing third-party code):
http://www.youtube.com/watch?v=jDWBJOXs_iI
Simple and well conceived! I would like this for D please (and am willing
to help :)).
DSSS cover
Hi BCS,
On Fri, 07 May 2010 01:54:17 +, BCS wrote:
n>
> I haven't watched the video (not enough bandwidth) but I'd like a well
> done package tool as well. Thinking in the direction of a spec, what do
> you like about the Go system?
I'll summarize the video (which, by the way, contains every
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?
> (by the way, I'm o
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
>> install
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 t
Graham Fawcett, el 7 de mayo a las 11:55 me escribiste:
> Hi BCS,
Let me add:
* It integrates well with existing packaging systems (dpkg, rpm, etc.).
I hate installing stuff outside my distro's packaging system. A simple:
d-pkg builddeb
should leave you a nice Debian package to install usi
Graham Fawcett wrote:
I'll summarize the video
Thank you for doing this. It's a real time saver for us!
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
2. backups are automatic
3.
Leandro Lucarella wrote:
> Graham Fawcett, el 7 de mayo a las 11:55 me escribiste:
>> Hi BCS,
>
> Let me add:
>
> * It integrates well with existing packaging systems (dpkg, rpm, etc.).
> I hate installing stuff outside my distro's packaging system. A simple:
> d-pkg builddeb
> should lea
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 pack
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 installi
Walter Bright wrote:
> 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 beca
On 5/7/2010 11:55, Walter Bright wrote:
> Source code could look something like:
>
> import http.d_repository.foo.version1_23;
>
> and the compiler could interpret "http" as meaning the rest is an
> internet url, foo is the package name, and version1_23 is the particular
> version of it.
I l
On 2010-05-07 13:55:34 -0400, Walter Bright said:
Source code could look something like:
import http.d_repository.foo.version1_23;
and the compiler could interpret "http" as meaning the rest is an
internet url, foo is the package name, and version1_23 is the
particular version of it.
Johan Granberg wrote:
Walter Bright wrote:
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
Rainer Deyke wrote:
I like this. The only question is, how do you handle computers without
an internet connection?
It can also be a LAN connection if the sys admin sets up a local repository.
But essentially, what we are talking about is distribution over the internet and
a central internet
Michel Fortin wrote:
On 2010-05-07 13:55:34 -0400, Walter Bright
said:
Source code could look something like:
import http.d_repository.foo.version1_23;
and the compiler could interpret "http" as meaning the rest is an
internet url, foo is the package name, and version1_23 is the
part
On 08/05/10 11:25, Walter Bright wrote:
Rainer Deyke wrote:
I like this. The only question is, how do you handle computers without
an internet connection?
It can also be a LAN connection if the sys admin sets up a local
repository.
But essentially, what we are talking about is distribution ov
Bernard Helyer wrote:
On 08/05/10 11:25, Walter Bright wrote:
If you want to work off line, then you can do the extra steps necessary
to install it locally.
I guess the trouble is if you use a special syntax like `import http.`,
then one has to modify the source of the application to install
Bernard Helyer wrote:
I guess the trouble is if you use a special syntax like `import http.`,
then one has to modify the source of the application to install it
locally, no?
I'd like to emphasize that this idea is specifically about not having to install
anything. You just type the correct p
On 2010-05-07 19:27:52 -0400, Walter Bright said:
Michel Fortin wrote:
On 2010-05-07 13:55:34 -0400, Walter Bright said:
Source code could look something like:
import http.d_repository.foo.version1_23;
and the compiler could interpret "http" as meaning the rest is an
internet url, f
Michel Fortin wrote:
On 2010-05-07 13:55:34 -0400, Walter Bright
said:
Source code could look something like:
import http.d_repository.foo.version1_23;
and the compiler could interpret "http" as meaning the rest is an
internet url, foo is the package name, and version1_23 is the
part
Walter Bright wrote:
Bernard Helyer wrote:
I guess the trouble is if you use a special syntax like `import
http.`, then one has to modify the source of the application to
install it locally, no?
I'd like to emphasize that this idea is specifically about not having to
install anything. You j
Hello Walter,
I kind of like the idea that it shouldn't install D packages, but
rather cache them from the web repository.
One absolute must in my book is that it be trivial to get a build working
without any external dependencies. Tweaking lots of import paths is not trivial.
Some users wo
:Hello Walter,
Rainer Deyke wrote:
I like this. The only question is, how do you handle computers
without an internet connection?
It can also be a LAN connection if the sys admin sets up a local
repository.
But essentially, what we are talking about is distribution over the
internet and a
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 repos
Hello Walter,
You just type the correct package name in the
import declaration, and the compiler system takes care of the rest.
How about a package->source mapping?
dmd -I my.corp=http://mycorp.com/sourcerepo
import my.corp.foo; // looked for at http://mycorp.com/sourcerepo.foo.d
that way w
"Leandro Lucarella" wrote in message
news:20100508011012.ga32...@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
Bernard Helyer wrote:
On 08/05/10 11:25, Walter Bright wrote:
Rainer Deyke wrote:
I like this. The only question is, how do you handle computers without
an internet connection?
It can also be a LAN connection if the sys admin sets up a local
repository.
But essentially, what we are talking
BCS wrote:
> Hello Walter,
>
>> You just type the correct package name in the
>> import declaration, and the compiler system takes care of the rest.
>
> How about a package->source mapping?
>
> dmd -I my.corp=http://mycorp.com/sourcerepo
>
> import my.corp.foo; // looked for at http://mycorp.c
On Sat, 08 May 2010 02:07:29 +, BCS wrote:
> Hello Walter,
>
>> You just type the correct package name in the import declaration, and
>> the compiler system takes care of the rest.
>
> How about a package->source mapping?
>
> dmd -I my.corp=http://mycorp.com/sourcerepo
>
> import my.corp.f
Nick Sabalausky, el 7 de mayo a las 22:36 me escribiste:
> >> 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 py
On 07/05/10 18:55, 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 t
"Leandro Lucarella" wrote in message
news:20100508173421.ga8...@llucax.com.ar...
> Nick Sabalausky, el 7 de mayo a las 22:36 me escribiste:
>> >> The caching should handle that transparently.
>> >
>> > Already done:
>> > http://0install.net/
>> >
>> > Too bad (or good?) nobody uses or know it.
>
"Robert Clipsham" wrote in message
news:hs4f66$1a1...@digitalmars.com...
> On 07/05/10 18:55, 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 w
Robert Clipsham 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;
--
Simen
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 08/05/10 21:26, Nick Sabalausky wrote:
I don't see what benefit having the "@remote" there provides. Why not just:
import foo.bar.baz.ver1_23;
dmd -R:foo.bar.baz=http://repo.example.com/tag/%VERSION%/%PACKAGE%/
Good point! Doing this means it can be done now too, no language changes
neede
On Fri, 07 May 2010 22:36:22 -0400, Nick Sabalausky wrote:
> "Leandro Lucarella" wrote in message
> news:20100508011012.ga32...@llucax.com.ar...
>> Walter Bright, el 7 de mayo a las 13:18 me escribiste:
>>> Johan Granberg wrote:
>>> >Walter Bright wrote:
>>> >
>>> >>Jacob Carlborg wrote:
>>> >>>
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 gi
Hello Simen,
Robert Clipsham 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?
--
... <
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
--
... <
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...
-
"BCS" wrote in message
news:a6268ff137a98ccbd7270f72...@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.
Hello Nick,
"BCS" wrote in message
news:a6268ff137a98ccbd7270f72...@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 versi
"BCS" wrote in message
news:a6268ff137cd8ccbd85902a1...@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 s
Hello Nick,
"BCS" wrote in message
news:a6268ff137cd8ccbd85902a1...@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 versi
BCS wrote:
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?
Compilation error.
Hello Walter,
BCS wrote:
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?
Compilation error.
Exactly. If there were a way for A to ask for X or Y and B to ask for Y or
Z than the solution is easy: Y.
Hello BCS,
Hello Walter,
BCS wrote:
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?
Compilation error.
Exactly. If there were a way for A to ask for X or Y and B to ask for
Y or Z than the solution is
BCS wrote:
And to finish the thought; a system that only allows a program to ask
for a single version is worse than one that doesn't allow any or allows
many.
We've been around this block already several times :-(
BCS wrote:
> Hello BCS,
>
> > Hello Walter,
> > >> BCS wrote:
> >> >>> 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?
> >>> >> Compilation error.
> >> > Exactly. If there were a way for
"Sean Kelly" wrote in message
news:1012172047295742031.093272sean-invisibleduck@news.digitalmars.com...
> BCS wrote:
>> Hello BCS,
>>
>> > Hello Walter,
>> > >> BCS wrote:
>> >> >>> My program imports lib A and B. Lib A imports lib C and asks
>> > > > > > for
>> >>> version "X". Lib B import
On 5/17/10 20:35, Nick Sabalausky wrote:
"Sean Kelly" wrote in message
news:1012172047295742031.093272sean-invisibleduck@news.digitalmars.com...
BCS wrote:
Hello BCS,
Hello Walter,
BCS wrote:
My program imports lib A and B. Lib A imports lib C and asks
for
version "X". Lib B imports
On Thu, 06 May 2010 16:01:49 -0700, Walter Bright wrote:
> Graham Fawcett wrote:
>> Simple and well conceived! I would like this for D please (and am
>> willing to help :)).
>
> Any help in this direction will be most appreciated.
I'm slowly working on a proposal, trying to incorporate the feedb
Hello Graham,
If so, what's the minimum harnessing we can impose upon a subproject
writer, to make their library compilable by an automated tool?
For many cases, there is a zero config solution that will work much of the
time: Compile all files and pack them into a .lib/.a
Until that doesn'
Hi BCS,
On Thu, 13 May 2010 01:53:34 +, BCS wrote:
> Hello Graham,
>
>> If so, what's the minimum harnessing we can impose upon a subproject
>> writer, to make their library compilable by an automated tool?
>
> For many cases, there is a zero config solution that will work much of
> the time
Hello Graham,
(b) derives the list of files by including all *.d files, except those
in directories named 'test' and except those which contain a
main() function.
I'm thinking of how to make this work for the simple publication model of
"Put it all out via HTTP/SVN/CVS/GIT/etc.". Anything tha
Hi BCS,
On Thu, 13 May 2010 17:31:34 +, BCS wrote:
>> (b) derives the list of files by including all *.d files, except those
>> in directories named 'test' and except those which contain a main()
>> function.
>
> I'm thinking of how to make this work for the simple publication model
> of "Pu
Hello Graham,
I was concerned
others might think the lack of a pre-compiled library was too hackish
(though I quite like it!). I think I'll proceed, and come back with
some sample code.
[...]
Thanks to your suggestion, I just discovered 'pragma("lib", ...)'
which does exactly what I wanted, a
Hey again,
On Thu, 13 May 2010 18:26:07 +, Graham Fawcett wrote:
> Hi BCS,
>
> On Thu, 13 May 2010 17:31:34 +, BCS wrote:
>
>>> (b) derives the list of files by including all *.d files, except those
>>> in directories named 'test' and except those which contain a main()
>>> function.
>>
On 5/14/10 22:27, Graham Fawcett wrote:
Hey again,
On Thu, 13 May 2010 18:26:07 +, Graham Fawcett wrote:
Hi BCS,
On Thu, 13 May 2010 17:31:34 +, BCS wrote:
(b) derives the list of files by including all *.d files, except those
in directories named 'test' and except those which conta
Hi Jacob,
On Sat, 15 May 2010 15:28:23 +0200, Jacob Carlborg wrote:
>
> If you already have it written the script in python why do you use a
> shell script as the dependency file?
The dependency file isn't strictly a shell script, though the syntax
looks the same. As you see, each line represen
On Sat, May 15, 2010 at 18:27, Graham Fawcett wrote:
>
> On a side note, I've found that dranges, dstats and dcrypt (all from
> dsource.org) all work with a little bit of shoehorning (though I had
> to patch dcrypt to get it to compile under the latest D2: see
> http://github.com/gmfawcett/d-buil
Hi Philippe,
On Sat, 15 May 2010 23:03:54 +0200, Philippe Sigaud wrote:
> On Sat, May 15, 2010 at 18:27, Graham Fawcett
> wrote:
>
>> On a side note, I've found that dranges, dstats and dcrypt (all from
>> dsource.org) all work with a little bit of shoehorning (though I had to
>> patch dcrypt t
On Sun, May 16, 2010 at 06:13, Graham Fawcett wrote:
>
> 'trunk/dranges' would be fine -- keeping 'trunk' makes good sense for
> a Subversion project. For my purposes, any depth is okay, e.g.
> 'trunk/src/lang/d2/dranges' would also work. The key is that modules
> which belong to the 'dranges' pa
69 matches
Mail list logo
