gt; 1 or 2 files), but for posterity's sake:
>>>
>>> http://personal.utulsa.edu/~ellery-newcomer/dmdz/dmdz.zip
>>
>> How about adding a README? To a casual reader like me, it's not clear
>> what dmdz is supposed to do...
>>
>> Graham
>>
> We
On 06/02/2010 09:08 AM, Graham Fawcett wrote:
On Tue, 01 Jun 2010 18:59:23 -0500, Ellery Newcomer wrote:
it doesn't really need itself to compile itself anymore (there's only 1
or 2 files), but for posterity's sake:
http://personal.utulsa.edu/~ellery-newcomer/dmdz/dmdz.zip
H
On Tue, 01 Jun 2010 18:59:23 -0500, Ellery Newcomer wrote:
> it doesn't really need itself to compile itself anymore (there's only 1
> or 2 files), but for posterity's sake:
>
> http://personal.utulsa.edu/~ellery-newcomer/dmdz/dmdz.zip
How about adding a README? To a
it doesn't really need itself to compile itself anymore (there's only 1
or 2 files), but for posterity's sake:
http://personal.utulsa.edu/~ellery-newcomer/dmdz/dmdz.zip
Rewrote split or whatever it was to be a bidirectional range.
Also wrote a nifty join implementation (of
nt on the
host system if you need them.
and I'm out..
I'm using Windows and don't have any of those (well, I have MS's
FIND.EXE but that has nothing in common with posix')
You're right.
Anyway, Ellery is right: general stuff that dmdz needs could probably be
m
ed them.
and I'm out..
I'm using Windows and don't have any of those (well, I have MS's
FIND.EXE but that has nothing in common with posix')
Anyway, Ellery is right: general stuff that dmdz needs could probably be
moved into Phobos at some point. As for "module&q
Andrei Alexandrescu wrote:
On 03/18/2010 06:00 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
On 03/18/2010 05:11 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
The basic interface is:
Another thing needed for the interface is an associative array that
maps
a string to a member
On 03/18/2010 06:00 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
On 03/18/2010 05:11 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
The basic interface is:
Another thing needed for the interface is an associative array that maps
a string to a member of the archive. Object code li
Andrei Alexandrescu wrote:
On 03/18/2010 05:11 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
The basic interface is:
Another thing needed for the interface is an associative array that maps
a string to a member of the archive. Object code libraries do this (the
string is the unresolved
On 03/18/2010 05:32 PM, Michel Fortin wrote:
On 2010-03-18 18:17:26 -0400, Andrei Alexandrescu
said:
On 03/18/2010 05:11 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
The basic interface is:
Another thing needed for the interface is an associative array that maps
a string to a member
On 2010-03-18 18:17:26 -0400, Andrei Alexandrescu
said:
On 03/18/2010 05:11 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
The basic interface is:
Another thing needed for the interface is an associative array that maps
a string to a member of the archive. Object code libraries do thi
On 03/18/2010 05:11 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
The basic interface is:
Another thing needed for the interface is an associative array that maps
a string to a member of the archive. Object code libraries do this (the
string is the unresolved symbol's name, the member is
Andrei Alexandrescu wrote:
The basic interface is:
Another thing needed for the interface is an associative array that maps a
string to a member of the archive. Object code libraries do this (the string is
the unresolved symbol's name, the member is of course the corresponding object
file).
Andrei Alexandrescu wrote:
On 03/18/2010 04:22 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
Is it really necessary to support streaming archives?
It is not necessary, only vital.
I understand your point.
But I still would like a way to build and read archives entirely in
memory. One
On 03/18/2010 04:22 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
Is it really necessary to support streaming archives?
It is not necessary, only vital.
I understand your point.
But I still would like a way to build and read archives entirely in
memory. One reason is that's how dmd is
Lutger wrote:
Just like dsss did...(and still does for D1 I guess)
I like dmdz and rdmd, but it's a pity dsss isn't revived yet. I still really
miss it, always thought it would become the ruby gems / CPAN of D.
Anyone can revive it if they're motivated too!
ere you aren't editing the parts in the zip file.
>
> It might even be practical to have dmdz compile from a zip file specified
> by a URL! That would be cool.
Just like dsss did...(and still does for D1 I guess)
I like dmdz and rdmd, but it's a pity dsss isn't revived yet.
Andrei Alexandrescu wrote:
Is it really necessary to support streaming archives?
It is not necessary, only vital.
I understand your point.
But I still would like a way to build and read archives entirely in memory. One
reason is that's how dmd is able to generate libraries so quickly.
Andrei Alexandrescu wrote:
To be frank, I even think you shouldn't worry at all about "module".
Just extract the blessed thing with caching and call it a day. I was
also thinking of simplifying options etc. by requiring a file
"dmdflags.txt" in the archive and then do this when you run dmd:
d
;t editing the parts in the zip file.
It might even be practical to have dmdz compile from a zip file
specified by a URL! That would be cool.
In that case I do think caching would be helpful :o).
Andrei
On 03/18/2010 04:14 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
FWIW, for rdmd caching makes a big, big difference.
Caching the executable, sure, but I'm not sure that translates into a
case for caching the intermediate files (i.e. the extracted source).
I see. It should be fine to c
might even be practical to have dmdz compile from a zip file specified by a
URL! That would be cool.
Andrei Alexandrescu wrote:
FWIW, for rdmd caching makes a big, big difference.
Caching the executable, sure, but I'm not sure that translates into a case for
caching the intermediate files (i.e. the extracted source).
On 03/18/2010 03:11 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
Reading the file header (e.g. first 512 bytes) and then matching
against archive signatures is, I think, a very nice touch. (I was only
thinking of matching by file name.) There is a mild complication - you
can't close and r
Hello Walter,
BCS wrote:
Hello Andrei,
The idea is to not extract the files every time you build. If they
are in place already, the tool should recognize that.
The difference in speed between disk IO and CPU /might/ be high
enough that (unless the uncompressed file is cached or you round t
Andrei Alexandrescu wrote:
Reading the file header (e.g. first 512 bytes) and then matching against
archive signatures is, I think, a very nice touch. (I was only thinking
of matching by file name.) There is a mild complication - you can't
close and reopen the archive, so you need to pass those
On 03/18/2010 02:49 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
Heh, incidentally I just needed a tar reader a few days ago, so I
wrote an embryo of a base class etc. I'll add it soon.
The basic interface is:
(a) open the archive
(b) get an input range for it. The range iterates over
On 03/18/2010 02:36 PM, Walter Bright wrote:
BCS wrote:
Hello Andrei,
The idea is to not extract the files every time you build. If they are
in place already, the tool should recognize that.
The difference in speed between disk IO and CPU /might/ be high enough
that (unless the uncompressed
Andrei Alexandrescu wrote:
Heh, incidentally I just needed a tar reader a few days ago, so I wrote
an embryo of a base class etc. I'll add it soon.
The basic interface is:
(a) open the archive
(b) get an input range for it. The range iterates over archive entries.
(c) You can look at archive
BCS wrote:
Hello Andrei,
The idea is to not extract the files every time you build. If they are
in place already, the tool should recognize that.
The difference in speed between disk IO and CPU /might/ be high enough
that (unless the uncompressed file is cached or you round trip it back
to
On 18/03/10 16:39, Ellery Newcomer wrote:
Wait, what's tar.xz?
http://en.wikipedia.org/wiki/Xz - A lot of linux distro's seem to be
moving to it for packaging from .tar.gz, I'm on Arch Linux, and the
updates are a fraction of the size they used to be :)
On 03/18/2010 12:28 PM, Clemens wrote:
Andrei Alexandrescu Wrote:
To be frank, I even think you shouldn't worry at all about
"module". Just extract the blessed thing with caching and call it a
day. I was also thinking of simplifying options etc. by requiring a
file "dmdflags.txt" in the archive
On 03/18/2010 11:48 AM, Ellery Newcomer wrote:
On 03/18/2010 11:36 AM, Robert Clipsham wrote:
On 18/03/10 16:28, Ellery Newcomer wrote:
I still don't see why (other than lexd.g adds ~ 10k loc just to get the
line 'module foo.bar;' out of a source file)
That seems like a tad too much for it...
Andrei Alexandrescu Wrote:
> To be frank, I even think you shouldn't worry at all about "module".
> Just extract the blessed thing with caching and call it a day. I was
> also thinking of simplifying options etc. by requiring a file
> "dmdflags.txt" in the archive and then do this when you run
On 03/18/2010 11:39 AM, Ellery Newcomer wrote:
On 03/18/2010 11:32 AM, Robert Clipsham wrote:
On 18/03/10 01:17, Ellery Newcomer wrote:
I was kind of hoping others would try it and give their opinions, but
apparently nobody else cares. Or they're on vacation, like I should be.
Or they're giving
hat does matter with regard to distributing
it with dmd.
I still don't see why (other than lexd.g adds ~ 10k loc just to get the
line 'module foo.bar;' out of a source file)
If a casual user downloads the dmd distro and says, hey, let me see how
this rdmd tool is implemented, I
On 03/18/2010 11:36 AM, Robert Clipsham wrote:
On 18/03/10 16:28, Ellery Newcomer wrote:
I still don't see why (other than lexd.g adds ~ 10k loc just to get the
line 'module foo.bar;' out of a source file)
That seems like a tad too much for it... Surely it would only take a few
(here meaning f
On 03/18/2010 11:32 AM, Robert Clipsham wrote:
On 18/03/10 01:17, Ellery Newcomer wrote:
I was kind of hoping others would try it and give their opinions, but
apparently nobody else cares. Or they're on vacation, like I should be.
Or they're giving the infamous 'silent approval'. Who knows.
I'
On 18/03/10 16:28, Ellery Newcomer wrote:
I still don't see why (other than lexd.g adds ~ 10k loc just to get the
line 'module foo.bar;' out of a source file)
That seems like a tad too much for it... Surely it would only take a few
(here meaning far less than 10k) lines to parse away comments/
On 18/03/10 01:17, Ellery Newcomer wrote:
I was kind of hoping others would try it and give their opinions, but
apparently nobody else cares. Or they're on vacation, like I should be.
Or they're giving the infamous 'silent approval'. Who knows.
I'm usually one of those, but seen as you asked...
he tool should recognize that.
It does that, but on a per-file basis.
Nice, but I don't know why you need to understand dmd's flags instead of
simply forwarding them to dmd. You could define dmdz-specific flags
which you parse and understand, and then dump everything else to dmd,
wh
On 03/17/2010 10:30 PM, BCS wrote:
Hello Andrei,
The idea is to not extract the files every time you build. If they are
in place already, the tool should recognize that.
The difference in speed between disk IO and CPU /might/ be high enough
that (unless the uncompressed file is cached or you
Hello Andrei,
The idea is to not extract the files every time you build. If they are
in place already, the tool should recognize that.
The difference in speed between disk IO and CPU /might/ be high enough that
(unless the uncompressed file is cached or you round trip it back to the
disk) re
come from, distributing dmdz with
dmd is also a message to users on how things are getting done in D.
dang right you are. If you're going to count the antlr runtime, then
maybe you should also be counting druntime and the sections of phobos
that I used?
I meant the antlr grammar for the task. I gave
On 03/17/2010 03:53 PM, Andrei Alexandrescu wrote:
Thanks for replying to this. I'd been afraid that I was coming off too
critical. (I counted the ANTLR files as modules, and I think that's
fair.) To give you an idea on where I come from, distributing dmdz with
dmd is also a message t
xisted and took less time.
Thanks for replying to this. I'd been afraid that I was coming off too
critical. (I counted the ANTLR files as modules, and I think that's
fair.) To give you an idea on where I come from, distributing dmdz with
dmd is also a message to users on how things a
appened to std.getopt? You don't need to recognize dmd's
options any more than rdmd does. rdmd dedicates only a few lines to
argument parsing, dmdz makes it a science.
It started when I said, "huh. when is this thing building an executable,
and when is it building a library?&qu
On 03/16/2010 05:55 PM, Ellery Newcomer wrote:
Anyone want to play with dmdz, here it is:
http://personal.utulsa.edu/~ellery-newcomer/dmdz.zip
Haven't tested it much, especially on windows. Don't know what it will
do with multiple zip files. piecemeal flag doesn't know how t
On 16/03/10 22:55, Ellery Newcomer wrote:
Anyone want to play with dmdz, here it is:
http://personal.utulsa.edu/~ellery-newcomer/dmdz.zip
Haven't tested it much, especially on windows. Don't know what it will
do with multiple zip files. piecemeal flag doesn't know how to stop w
Ellery Newcomer wrote:
> Anyone want to play with dmdz, here it is:
>
> http://personal.utulsa.edu/~ellery-newcomer/dmdz.zip
>
>
> Haven't tested it much, especially on windows. Don't know what it will
> do with multiple zip files. piecemeal flag doesn't kn
Anyone want to play with dmdz, here it is:
http://personal.utulsa.edu/~ellery-newcomer/dmdz.zip
Haven't tested it much, especially on windows. Don't know what it will
do with multiple zip files. piecemeal flag doesn't know how to stop when
you tell it to. dmd's ru
On 03/15/2010 10:04 PM, Nick Sabalausky wrote:
"Ellery Newcomer" wrote in message
news:hnmbkl$2rs...@digitalmars.com...
Hello.
I've run into a problem.
dmd foo/bar/bizz.d
bizz.d:
module bar.bizz;
...
dmd thinks it's looking at module foo.bar.bizz and generally gets confused
unless suppl
"Ellery Newcomer" wrote in message
news:hnmbkl$2rs...@digitalmars.com...
> Hello.
>
> I've run into a problem.
>
> dmd foo/bar/bizz.d
>
> bizz.d:
> module bar.bizz;
> ...
>
> dmd thinks it's looking at module foo.bar.bizz and generally gets confused
> unless supplied with -Ifoo. As a user, I'm
Hello.
I've run into a problem.
dmd foo/bar/bizz.d
bizz.d:
module bar.bizz;
...
dmd thinks it's looking at module foo.bar.bizz and generally gets
confused unless supplied with -Ifoo. As a user, I'm not manually
specifying that -Ifoo. So I need some bare-bones lexing capabilities.
I have
o there is some consistency with rdmd?
-Lars
I have no idea why it's called dmdz and not zdmd. My guess is so you can
have rdmdz.
On Thu, Mar 11, 2010 at 9:09 PM, Nick Sabalausky wrote:
> What I really want is an archive program that automatically makes a
> subfolder by default *but* detects if the top level inside the archive
> contains nothing more than a single folder and intelligently *not* create a
> new folder in that
Ellery Newcomer wrote:
So I'm toying with a prototype, which is proving nice enough, but there
be a few things that I'm not quite sure which way to go with.
Cool! Looking forward to using it. :)
But can we please call it zdmd, so there is some consistency with rdmd?
-Lars
"Ellery Newcomer" wrote in message
news:hnc4o3$2lm...@digitalmars.com...
>
> I suppose the name isn't so important, but I really hate zip files whose
> contents aren't contained inside a single directory.
This is a bit of a "vim vs emacs" or "static vs dynamic" sort of issue.
Most of the archi
Ellery Newcomer wrote:
So I'm toying with a prototype, which is proving nice enough, but there
be a few things that I'm not quite sure which way to go with.
How about:
dmdz ...stuff... foo.zip ...morestuff...
being semantically identical to:
dmdz ...stuff... (expanded c
Ellery Newcomer wrote:
I've hoped to rewrite std.zip forever, but found no time to do so.
Well, heck. Maybe I'll see what I can do with it. Do you want it to
conform to any interface in particular?
What I'd like to see is the creation of a library file interface, say:
std.archive
and th
On 03/11/2010 12:29 PM, Andrei Alexandrescu wrote:
For the more specific case
dmdz [global flags] foo.zip [local flags]
it expects all the relevant content in foo.zip to be located inside
directory foo, and doesn't extract anything else unless you explicitly
tell it to.
I don't
he general pattern
dmdz [global flags] foo1.zip [foo1 local flags] foo2.zip [foo2 local
flags] ...
although when given multiple zips it just compiles them independently.
My thought was when fooi.zip compiles a lib file, the result should be
made available to all subsequent zip files, so you could do
So I'm toying with a prototype, which is proving nice enough, but there
be a few things that I'm not quite sure which way to go with.
Currently I have the general pattern
dmdz [global flags] foo1.zip [foo1 local flags] foo2.zip [foo2 local
flags] ...
although when given multip
63 matches
Mail list logo
