www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Well, it's been a total failure

reply "Vladimir G. Ivanovic" <vladimir acm.org> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

 I'm running Fedora 13.x86_64 and I've tried various ways of getting a
D compiler to work. None have succeeded.

1. a. I can't install dmd 2.048:

        # rpm -Uvh /downloads/dmd-2.048-0.i386.rpm
        error: Failed dependencies:
           gcc(x86-32) >=3D 4.2.3 is needed by dmd-2.048-0.i386
   I don't know what package will satisfy this dependency.
   b. dmd is a closed compiler. Not good. I'm really not comfortable
running a compiler for which I don't have access to the source. The
risk of undetected malware is too great.
   c. So, I give up on dmd.

2. I can't run ldc because
   a. The ldc RPM requires Tango, even though this is not an RPM
dependency for ldc, i.e. you can install ldc without any errors.
   b. The installation instructions for Fedora on the LDC web site are
incorrect. "yum install ldc" works, but "yum install tango" doesn't.
"yum install tango-devel" is the correct command. (This is the first
time I've heard of <pkg>-devel without a corresponding <pkg>.)
   c. After I've gotten everything installed, it still doesn't work. I ge=
t
        $ ldc hello.d
        hello.d(5): Error: module stdio cannot read file 'std/stdio.d'
   d. OK, so I link /usr/include/d/tango/stdc to
/usr/include/d/tango/std, but it still doesn't work. I get:
        $ ldc hello.d
        hello.d(8): Error: undefined identifier writefln
        hello.d(8): Error: function expected before (), not writefln
of type int
   e. ldc only supports D v1.
   f. All of this is too much for me. I give up on ldc.

3. I can't get gdc to compile.
   a. First I have to get gcc-4.4.4 to compile, but that requires a 4
year old version of automake. I have to downgrade.
   b. After that's fixed, I'm still running into errors that prevent a
build. The errors change from changeset to changeset. So, I'm giving
up on gdc.

Getting a D compiler to run on x86_64 Linux is too hard. I'm giving up
on D.

I'm posting this message not as a plea for help, but to illustrate how
hard it is to get D to run on Fedora.x86_64. The success of D depends
on high quality, open source compilers being available (my belief),
and so far, D doesn't seem to be mature enough to be considered, at
least on Fedora.x86_64.

But, on the plus side, the existence of the book "The D Programming
Language" is a major step in getting D accepted as a serious system
programming language. Maybe installation will improve and D will move
forward.

--- Vladimir

--=20
Vladimir G. Ivanovic                            http://www.leonora.org
+1 650 450 4101                                       vladimir acm.org
Sep 11 2010
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Vladimir G. Ivanovic wrote:
  I'm running Fedora 13.x86_64 and I've tried various ways of getting a
 D compiler to work. None have succeeded.
 
 1. a. I can't install dmd 2.048:
 
         # rpm -Uvh /downloads/dmd-2.048-0.i386.rpm
         error: Failed dependencies:
            gcc(x86-32) >= 4.2.3 is needed by dmd-2.048-0.i386
    I don't know what package will satisfy this dependency.
    b. dmd is a closed compiler. Not good. I'm really not comfortable
 running a compiler for which I don't have access to the source. The
 risk of undetected malware is too great.
    c. So, I give up on dmd.

Complete source code comes with dmd. Try downloading: http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.063.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.048.zip There are several people working on the source. Lots of D users compile their own versions of dmd. The complete dmd source code is also available here: http://www.dsource.org/projects/dmd/browser/trunk/
Sep 11 2010
prev sibling next sibling parent Robert Clipsham <robert octarineparrot.com> writes:
On 11/09/10 23:52, Vladimir G. Ivanovic wrote:
   I'm running Fedora 13.x86_64 and I've tried various ways of getting a
 D compiler to work. None have succeeded.

 1. a. I can't install dmd 2.048:

          # rpm -Uvh /downloads/dmd-2.048-0.i386.rpm
          error: Failed dependencies:
             gcc(x86-32)>= 4.2.3 is needed by dmd-2.048-0.i386
     I don't know what package will satisfy this dependency.

I've never used fedora, so I'll skip anything further about rpms.
     b. dmd is a closed compiler. Not good. I'm really not comfortable
 running a compiler for which I don't have access to the source. The
 risk of undetected malware is too great.

Only the backend is closed, and the source is still available. The front end is dual licensed under the GPL and artistic licenses: http://www.dsource.org/projects/dmd/browser/trunk/src
     c. So, I give up on dmd.

 2. I can't run ldc because
     a. The ldc RPM requires Tango, even though this is not an RPM
 dependency for ldc, i.e. you can install ldc without any errors.

Again, I know nothing of RPMs/Fedora, but I can say ldc doesn't require tango - it's just a lot nicer to use if you have a standard library :)
     b. The installation instructions for Fedora on the LDC web site are
 incorrect. "yum install ldc" works, but "yum install tango" doesn't.
 "yum install tango-devel" is the correct command. (This is the first
 time I've heard of<pkg>-devel without a corresponding<pkg>.)
     c. After I've gotten everything installed, it still doesn't work. I get
          $ ldc hello.d
          hello.d(5): Error: module stdio cannot read file 'std/stdio.d'

std is part of phobos, and phobos does not support ldc. A hello world using tango would look like this: --- import tango.io.Stdout; void main() { Stdout("Hello World!").newline; } ----
     d. OK, so I link /usr/include/d/tango/stdc to
 /usr/include/d/tango/std, but it still doesn't work. I get:
          $ ldc hello.d
          hello.d(8): Error: undefined identifier writefln
          hello.d(8): Error: function expected before (), not writefln
 of type int

Again, phobos doesn't support ldc.
     e. ldc only supports D v1.

Correct.
     f. All of this is too much for me. I give up on ldc.

 3. I can't get gdc to compile.
     a. First I have to get gcc-4.4.4 to compile, but that requires a 4
 year old version of automake. I have to downgrade.
     b. After that's fixed, I'm still running into errors that prevent a
 build. The errors change from changeset to changeset. So, I'm giving
 up on gdc.

I've only used gdc once, and it was a long time ago - I can't help here. Even then I do know that dmd is the only D compiler that supports D2 currently. Gdc is getting there.
 Getting a D compiler to run on x86_64 Linux is too hard. I'm giving up
 on D.

Been there, done that :/
 I'm posting this message not as a plea for help, but to illustrate how
 hard it is to get D to run on Fedora.x86_64. The success of D depends
 on high quality, open source compilers being available (my belief),
 and so far, D doesn't seem to be mature enough to be considered, at
 least on Fedora.x86_64.

This will change most likely when dmd gets 64 bit support - this is progressing rapidly. -- Robert http://octarineparrot.com/
Sep 11 2010
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Vladimir G. Ivanovic wrote:

  I'm running Fedora 13.x86_64 and I've tried various ways of getting a
 D compiler to work. None have succeeded.
 
 1. a. I can't install dmd 2.048:
 
         # rpm -Uvh /downloads/dmd-2.048-0.i386.rpm
         error: Failed dependencies:
            gcc(x86-32) >= 4.2.3 is needed by dmd-2.048-0.i386
    I don't know what package will satisfy this dependency.

You need the i686 versions of some packages, probably start with libgcc (yum install libgcc.i686) and glibc, I don't remember which exactly are required. I have dmd running on 64 bit fedora just fine, it can work. There is also a 64-bit dmd in the making which should solve all those problems.
    b. dmd is a closed compiler. Not good. I'm really not comfortable
 running a compiler for which I don't have access to the source. The
 risk of undetected malware is too great.

dmd is not open source, but not closed source either :) You can compile it from scratch, the source is included with the zip file.
Sep 11 2010
parent reply Jesse Phillips <jessekphillips+D gmail.com> writes:
Lutger Wrote:

 You need the i686 versions of some packages, probably start with libgcc (yum 
 install libgcc.i686) and glibc, I don't remember which exactly are required. I 
 have dmd running on 64 bit fedora just fine, it can work. There is also a
64-bit 
 dmd in the making which should solve all those problems.

Based on a previous post by Walter, it sounds like he is working on just the code generation for 64bit and does not see a need to make the compiler 64 bit itself.
Sep 12 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Jesse Phillips (jessekphillips+D gmail.com)'s article
 Lutger Wrote:
 You need the i686 versions of some packages, probably start with libgcc (yum
 install libgcc.i686) and glibc, I don't remember which exactly are required. I
 have dmd running on 64 bit fedora just fine, it can work. There is also a
64-bit
 dmd in the making which should solve all those problems.


The compiler already has been compilable as a 64-bit binary for months. IMHO, though, Walter should release a 64-bit pre-compiled binary to make life easy for ppl with 64-bit installs.
Sep 12 2010
next sibling parent reply chmod+x <zip should.support.it> writes:
dsimcha Wrote:

 == Quote from Jesse Phillips (jessekphillips+D gmail.com)'s article
 Lutger Wrote:
 You need the i686 versions of some packages, probably start with libgcc (yum
 install libgcc.i686) and glibc, I don't remember which exactly are required. I
 have dmd running on 64 bit fedora just fine, it can work. There is also a
64-bit
 dmd in the making which should solve all those problems.


The compiler already has been compilable as a 64-bit binary for months. IMHO, though, Walter should release a 64-bit pre-compiled binary to make life easy for ppl with 64-bit installs.

Another source of misery are the contents of the dmd zip file. Every time you need to set +x flag for the executable. This is so ridiculous. Does the Creator accept one bit binary patches to the distributions to make the solution a reality? It's open source: unzip dmdzip.zip chmod +x executables zip -r dmdzip *
Sep 12 2010
next sibling parent chmod+x <zip should.support.it> writes:
chmod+x Wrote:

 dsimcha Wrote:
 
 == Quote from Jesse Phillips (jessekphillips+D gmail.com)'s article
 Lutger Wrote:
 You need the i686 versions of some packages, probably start with libgcc (yum
 install libgcc.i686) and glibc, I don't remember which exactly are required. I
 have dmd running on 64 bit fedora just fine, it can work. There is also a
64-bit
 dmd in the making which should solve all those problems.


The compiler already has been compilable as a 64-bit binary for months. IMHO, though, Walter should release a 64-bit pre-compiled binary to make life easy for ppl with 64-bit installs.

Another source of misery are the contents of the dmd zip file. Every time you need to set +x flag for the executable. This is so ridiculous. Does the Creator accept one bit binary patches to the distributions to make the solution a reality? It's open source: unzip dmdzip.zip chmod +x executables zip -r dmdzip *

Okey, the binary patch is actually 349 bytes. A repackaged dmd is also 523737 bytes smaller (dmd 2.048, repackaged with 7z). That would save 5% in bandwidth cost and download time. Nobody cares.
Sep 12 2010
prev sibling next sibling parent reply BCS <none anon.com> writes:
Hello chmod+x,

 Another source of misery are the contents of the dmd zip file. Every
 time you need to set +x flag for the executable. This is so
 ridiculous. Does the Creator accept one bit binary patches to the
 distributions to make the solution a reality? It's open source:
 
 unzip dmdzip.zip
 chmod +x executables
 zip -r dmdzip *
 

IIRC the .zip is created on a windows box so that doesn't exactly work. :( -- ... <IXOYE><
Sep 12 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/12/2010 10:05 PM, retard wrote:
 Mon, 13 Sep 2010 01:53:06 +0000, BCS wrote:

 Hello chmod+x,

 Another source of misery are the contents of the dmd zip file. Every
 time you need to set +x flag for the executable. This is so ridiculous.
 Does the Creator accept one bit binary patches to the distributions to
 make the solution a reality? It's open source:

 unzip dmdzip.zip
 chmod +x executables
 zip -r dmdzip *

:(

FWIW, http://www.digitalmars.com/webnews/newsgroups.php? art_group=digitalmars.D&article_id=114660 mentions that the build system uses *nix. I'm guessing the internal testing system uses modern *nix tools, but the final release is published on a windows machine.

My understanding is that Walter still uses Windows for the final packaging steps. It's ironic because he essentially uses cmd on Windows in conjunction with a few command-line tools of his use that emulate (badly, nonstandardly, and NIHily) 0.1% of Unix. I hope this to gradually change. Andrei
Sep 13 2010
parent reply Justin Johansson <no spam.com> writes:
On 13/09/2010 11:50 PM, Andrei Alexandrescu wrote:
 My understanding is that Walter still uses Windows for the final
 packaging steps. It's ironic because he essentially uses cmd on Windows
 in conjunction with a few command-line tools of his use that emulate
 (badly, nonstandardly, and NIHily) 0.1% of Unix. I hope this to
 gradually change.

 Andrei

If this is true I can well understand Walter's position. My most prolific and effective coding days were back when 80x25 character mode editing was the norm on a DOS screen using the brilliant Brief (emacs-like) editor. Ever since the invention of GUI and mouse and the depreciation of keyboard skills, I feel that coding productivity has gone backwards. As for Unix command line skills that you allude to, I also understand that one well-versed in the simplicity of oft-scorned-upon DOS skills can work wonders over and above others in the large. Most unix scripts are not works meant for understanding by the common man. OTOH, simple DOS scripts do oft make for the Fanfare for the Command Man. Hey, perhaps Aaron Copland would have preferred to be a DOS programmer. Cheers Justin Johansson
Sep 13 2010
parent reply Justin Johansson <no spam.com> writes:
On 14/09/2010 12:55 AM, Justin Johansson wrote:
 meant for understanding by the common man. OTOH, simple
 DOS scripts do oft make for the Fanfare for the Command Man.
 Hey, perhaps Aaron Copland would have preferred to be a
 DOS programmer.

Seriously, that was just a serendipitous typo. I meant the Common Man, not the "Command" Man as in say a "command-line" man. Maybe that wasn't really a typo but some Freudian slip on my part. :-) -- Justin
Sep 13 2010
parent reply Justin Johansson <no spam.com> writes:
He he.

Of course "SideKick" itself was some very popular TSR
utility wasn't it?  (But you didn't mean that?)
For the young people here, TSR is Terminate and Stay Resident,
an artifact of DOS 640KB days.  No doubt see Wikipedia for more.
Oh dear.  :-)

But Clippy? The only Clippy I know (and hated) it that
stupid yesteryear Word popup.  You meant that thing?

- Justin


On 14/09/2010 1:40 AM, Andrej Mitrovic wrote:
 Command Man, and his sidekick, Clippy.

 On Mon, Sep 13, 2010 at 5:29 PM, Justin Johansson<no spam.com>  wrote:
 On 14/09/2010 12:55 AM, Justin Johansson wrote:
 meant for understanding by the common man. OTOH, simple
 DOS scripts do oft make for the Fanfare for the Command Man.
 Hey, perhaps Aaron Copland would have preferred to be a
 DOS programmer.

Seriously, that was just a serendipitous typo. I meant the Common Man, not the "Command" Man as in say a "command-line" man. Maybe that wasn't really a typo but some Freudian slip on my part. :-) -- Justin


Sep 13 2010
parent Robert Clipsham <robert octarineparrot.com> writes:
On 13/09/10 21:43, Justin Johansson wrote:
 He he.

 Of course "SideKick" itself was some very popular TSR
 utility wasn't it? (But you didn't mean that?)
 For the young people here, TSR is Terminate and Stay Resident,
 an artifact of DOS 640KB days. No doubt see Wikipedia for more.
 Oh dear. :-)

 But Clippy? The only Clippy I know (and hated) it that
 stupid yesteryear Word popup. You meant that thing?

 - Justin

At some point during my childhood I acquired the nickname Clippy, it's followed me ever since. Fortunately very few people I know know the nickname commonly associated with that wretched paper clip, so it never causes too much dismay. -- Robert http://octarineparrot.com/
Sep 13 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Russel Winder wrote:
 To be honest I don't give a fig about how the zipfile is created, the
 scripts and executables for Linux should come with the execute
 permission preset.  It is a ridiculous irritation that after unzipping a
 supposed binary distribution, I then have to go and work out which files
 to make executable.  If Windows cannot hack building a proper zipfile
 then a machine with a proper operating system should be used so that the
 zipfile is fit for its purpose.

Of course you're right, and I know it, I've just been lazy. I spent some time on google and cannot find a zip program for Windows that enables one to set (or even display) the file attributes in zip files. Go figure. So I'll just write one using Phobos' std.zip.
Sep 13 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/13/2010 12:32 PM, Walter Bright wrote:
 Russel Winder wrote:
 To be honest I don't give a fig about how the zipfile is created, the
 scripts and executables for Linux should come with the execute
 permission preset. It is a ridiculous irritation that after unzipping a
 supposed binary distribution, I then have to go and work out which files
 to make executable. If Windows cannot hack building a proper zipfile
 then a machine with a proper operating system should be used so that the
 zipfile is fit for its purpose.

Of course you're right, and I know it, I've just been lazy. I spent some time on google and cannot find a zip program for Windows that enables one to set (or even display) the file attributes in zip files. Go figure. So I'll just write one using Phobos' std.zip.

s/So I\'ll just write one using Phobos\' std.zip/So I\'ll just use zip on Linux and call it a day/ Waste of time doesn't begin to describe this. Andrei
Sep 13 2010
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 On 09/13/2010 12:32 PM, Walter Bright wrote:
 Russel Winder wrote:
 To be honest I don't give a fig about how the zipfile is created, the
 scripts and executables for Linux should come with the execute
 permission preset. It is a ridiculous irritation that after unzipping a
 supposed binary distribution, I then have to go and work out which files
 to make executable. If Windows cannot hack building a proper zipfile
 then a machine with a proper operating system should be used so that the
 zipfile is fit for its purpose.

Of course you're right, and I know it, I've just been lazy. I spent some time on google and cannot find a zip program for Windows that enables one to set (or even display) the file attributes in zip files. Go figure. So I'll just write one using Phobos' std.zip.

on Linux and call it a day/ Waste of time doesn't begin to describe this. Andrei

Well, some people (like me) just plain prefer Windows over Linux. That said, there's always Cygwin. I love the command line environment of Unix-like OS's, but prefer certain things about Windows like having stable ABIs for the basic OS facilities (meaning that I can just download and unpack a binary and it **consistently** just works across all modern Windows machines) and having hardware support that doesn't suck horribly. Cygwin lets me have it both ways. Also, Cygwin's zip is probably compiled from the same source as any Linux distro's, and should probably do what you need.
Sep 13 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/13/2010 04:28 PM, dsimcha wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 On 09/13/2010 12:32 PM, Walter Bright wrote:
 Russel Winder wrote:
 To be honest I don't give a fig about how the zipfile is created, the
 scripts and executables for Linux should come with the execute
 permission preset. It is a ridiculous irritation that after unzipping a
 supposed binary distribution, I then have to go and work out which files
 to make executable. If Windows cannot hack building a proper zipfile
 then a machine with a proper operating system should be used so that the
 zipfile is fit for its purpose.

Of course you're right, and I know it, I've just been lazy. I spent some time on google and cannot find a zip program for Windows that enables one to set (or even display) the file attributes in zip files. Go figure. So I'll just write one using Phobos' std.zip.

on Linux and call it a day/ Waste of time doesn't begin to describe this. Andrei

Well, some people (like me) just plain prefer Windows over Linux. That said, there's always Cygwin. I love the command line environment of Unix-like OS's, but prefer certain things about Windows like having stable ABIs for the basic OS facilities (meaning that I can just download and unpack a binary and it **consistently** just works across all modern Windows machines) and having hardware support that doesn't suck horribly. Cygwin lets me have it both ways. Also, Cygwin's zip is probably compiled from the same source as any Linux distro's, and should probably do what you need.

There's nothing wrong about preferring Windows over Linux. I'm just saying (much like you) that badly reinventing Unix tools under Windows is not quite productive. Andrei
Sep 13 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 There's nothing wrong about preferring Windows over Linux. I'm just 
 saying (much like you) that badly reinventing Unix tools under Windows 
 is not quite productive.

The unix version of zip has no option to set the file attributes either.
Sep 13 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/13/2010 05:56 PM, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 There's nothing wrong about preferring Windows over Linux. I'm just
 saying (much like you) that badly reinventing Unix tools under Windows
 is not quite productive.

The unix version of zip has no option to set the file attributes either.

It does preserve them. Zip a binary and then unzip it - it'll run. Andrei
Sep 13 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 On 09/13/2010 05:56 PM, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 There's nothing wrong about preferring Windows over Linux. I'm just
 saying (much like you) that badly reinventing Unix tools under Windows
 is not quite productive.

The unix version of zip has no option to set the file attributes either.

It does preserve them. Zip a binary and then unzip it - it'll run.

zip on unix has no way to set the Windows attributes, and zip on Windows has no way to set the unix attributes. Both have attributes that have no analogs on the other. Both have no way to set the non-native attributes.
Sep 13 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/13/2010 07:47 PM, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 On 09/13/2010 05:56 PM, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 There's nothing wrong about preferring Windows over Linux. I'm just
 saying (much like you) that badly reinventing Unix tools under Windows
 is not quite productive.

The unix version of zip has no option to set the file attributes either.

It does preserve them. Zip a binary and then unzip it - it'll run.

zip on unix has no way to set the Windows attributes, and zip on Windows has no way to set the unix attributes. Both have attributes that have no analogs on the other. Both have no way to set the non-native attributes.

I didn't know there is an executable attribute on Windows. Anyhow, I guess that underlines the necessity to do what everybody does - assemble the installer on the distribution platform, and have it only contain the files for that platform. An increasingly large audience is looking at us, and we should avoid being provincial. I'm not even sure why we're having this discussion - there should be no debate here: we do what people do. This reminds me of the discussion of yesteryear - people were complaining about C++ files in dmd having the .c extension, and the right answer would have been to change the blessed thing to be like everybody else has it, instead of finding arguments on why it worked the way it was. Andrei
Sep 13 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 On 09/13/2010 07:47 PM, Walter Bright wrote:
 zip on unix has no way to set the Windows attributes, and zip on Windows
 has no way to set the unix attributes. Both have attributes that have no
 analogs on the other. Both have no way to set the non-native attributes.

I didn't know there is an executable attribute on Windows.

There isn't. But there are system, hidden, and archive attribute bits that have no analog on unix. Not that we use any of those bits, I'm just arguing the point that unix utilities are not always better - in this case, they have the same deficiency. Googling this particular issue brings up pages where people are told to use python scripts to set the attributes in a zip file. It's also nice to eat our own dogfood, and do something useful with std.zip.
 Anyhow, I guess that underlines the necessity to do what everybody does 
 - assemble the installer on the distribution platform, and have it only 
 contain the files for that platform. An increasingly large audience is 
 looking at us, and we should avoid being provincial. I'm not even sure 
 why we're having this discussion - there should be no debate here: we do 
 what people do. This reminds me of the discussion of yesteryear - people 
 were complaining about C++ files in dmd having the .c extension, and the 
 right answer would have been to change the blessed thing to be like 
 everybody else has it, instead of finding arguments on why it worked the 
 way it was.

Hard to argue with that.
Sep 13 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/14/2010 05:38 AM, Steven Schveighoffer wrote:
 Not that anyone here is in charge of your time, I think Andrei's "waste
 of time" point is that there are better, more productive things you can
 do for the good of D. If someone else wants to write this utility,
 great. But in the meantime, can we just put in the easy fix?

Yes. Please, let's not waste our time rewriting shell two-liners as specialized programs. Andrei
Sep 14 2010
parent reply Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 Yes. Please, let's not waste our time rewriting shell two-liners as 
 specialized programs.

It's not always a waste of time. For example, I stopped using lib and ar to generate libraries and instead built it into dmd. The result is quite pleasing, it's very very fast to build libraries and does not litter one's directories with object files.
Sep 14 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/14/10 16:06 CDT, Walter Bright wrote:
 Andrei Alexandrescu wrote:
 Yes. Please, let's not waste our time rewriting shell two-liners as
 specialized programs.

It's not always a waste of time. For example, I stopped using lib and ar to generate libraries and instead built it into dmd. The result is quite pleasing, it's very very fast to build libraries and does not litter one's directories with object files.

There is no comparison. You have spent time replacing a simple but inefficient tool with one that improves efficiency sensibly. That is in keeping with your own recent article on optimization. Your zip utility (better call it "inutility") goes straight against your own advice and also against common sense. It is not right to hijack the positive reinforcement you got from replacing lib and ar, and use it to justify the monumental waste of time that zip is. Andrei
Sep 14 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/14/2010 05:41 AM, retard wrote:
 Mon, 13 Sep 2010 18:44:35 -0700, Walter Bright wrote:
 It's also nice to eat our own dogfood, and do something useful with
 std.zip.

And D is a pragmatic language? Listen man, you the Superman of the D world and instead of fighting crimes, you're always knitting socks.

Well ideally we'd eat our dogfood by bootstrapping dmd. I think that'll happen at some point in the future due to the nice ddmd ongoing effort. Walter is itching to use D's power in day-to-day work. There is a fuzzy limit regarding what should be a script vs. a program. For example, rdmd did start as a script. Probably it still could be, but it's involved and specialized enough to justify writing it in D. My guess is that the script would have more lines and would be much more difficult to maintain than the D program. But writing a zipper in D that essentially emulates a zip command line... I mean come on. Andrei P.S. Never been fond of std.zip's interface...
Sep 14 2010
parent "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:i6o3c3$tep$1 digitalmars.com...
 On 09/14/2010 05:41 AM, retard wrote:
 Mon, 13 Sep 2010 18:44:35 -0700, Walter Bright wrote:
 It's also nice to eat our own dogfood, and do something useful with
 std.zip.

And D is a pragmatic language? Listen man, you the Superman of the D world and instead of fighting crimes, you're always knitting socks.

Well ideally we'd eat our dogfood by bootstrapping dmd. I think that'll happen at some point in the future due to the nice ddmd ongoing effort. Walter is itching to use D's power in day-to-day work. There is a fuzzy limit regarding what should be a script vs. a program. For example, rdmd did start as a script. Probably it still could be, but it's involved and specialized enough to justify writing it in D. My guess is that the script would have more lines and would be much more difficult to maintain than the D program.

It also wouldn't work for us Windows users without having to deal with a PITA like MSYS or Cygwin. (I'm not saying we do or don't need a D-based zip tool. I'm just saying I'm glad rdmd isn't a shell script.)
Sep 14 2010
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Steven Schveighoffer wrote:
 Not that anyone here is in charge of your time, I think Andrei's "waste 
 of time" point is that there are better, more productive things you can 
 do for the good of D.  If someone else wants to write this utility, 
 great.  But in the meantime, can we just put in the easy fix?

It's arguable whether the "easy" fix is to write a trivial utility, or to rejigger all my build and install scripts. In any case, it's done. Here it is, it's mostly a cut&paste from another zip utility I wrote long ago. ========================================== import std.c.stdio; import std.c.stdlib; import std.stdio; import std.file; import std.date; import std.zip; import std.zlib; int main(string[] args) { if (args.length == 1) { writeln("Usage: zip zipfile attr members..."); exit(0); } if (args.length == 2) { auto zipname = args[1]; auto buffer = cast(byte[])std.file.read(zipname); auto zr = new std.zip.ZipArchive(cast(void[])buffer); writefln("comment = '%s'", zr.comment); foreach (ArchiveMember de; zr.directory) { zr.expand(de); writefln("name = %s", de.name); writefln("\tcomment = %s", de.comment); writefln("\tmadeVersion = x%04x", de.madeVersion); writefln("\textractVersion = x%04x", de.extractVersion); writefln("\tflags = x%04x", de.flags); writefln("\tcompressionMethod = %d", de.compressionMethod); writefln("\tcrc32 = x%08x", de.crc32); writefln("\texpandedSize = %s", de.expandedSize); writefln("\tcompressedSize = %s", de.compressedSize); writefln("\teattr = %03o, %03o", de.externalAttributes >> 16, de.externalAttributes & 0xFFFF); writefln("\tiattr = %03o", de.internalAttributes); writefln("\tdate = %s", std.date.toString(std.date.toDtime(de.time))); } return 0; } auto zipname = args[1]; auto attr = args[2]; auto members = args[3 .. $]; uint newattr = 0; foreach (c; attr) { if (c < '0' || c > '7' || attr.length > 4) throw new ZipException("attr must be 1..4 octal digits, not " ~ attr); newattr = (newattr << 3) | (c - '0'); } auto buffer = cast(byte[])std.file.read(zipname); auto zr = new std.zip.ZipArchive(cast(void[])buffer); foreach (member; members) { foreach (ArchiveMember de; zr.directory) { if (de.name == member) goto L1; } throw new ZipException(member ~ " not in zipfile " ~ zipname); L1: ; } bool changes; foreach (ArchiveMember de; zr.directory) { zr.expand(de); foreach (member; members) { if (de.name == member && ((de.externalAttributes >> 16) & 07777) != newattr) { changes = true; de.madeVersion = 0x317; // necessary or linux unzip will ignore attributes de.externalAttributes = (de.externalAttributes & ~(07777 << 16)) | (newattr << 16); break; } } } if (changes) { void[] data2 = zr.build(); std.file.write(zipname, cast(byte[])data2); } return 0; }
Sep 14 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Steven Schveighoffer wrote:
 I'm not sure what this does, I really *really* hope it doesn't set the 
 attrs of all files to a+x.

You can download the new beta and see how it worked!
Sep 14 2010
parent reply chmod+x <zip should.support.it> writes:
Walter Bright Wrote:

 Steven Schveighoffer wrote:
 I'm not sure what this does, I really *really* hope it doesn't set the 
 attrs of all files to a+x.

You can download the new beta and see how it worked!

Now it works. However, you're wasting bandwidth because the zipper is a lot worse than 7zip at making .zips!
Sep 14 2010
parent Stephan <spam extrawurst.org> writes:
On 15.09.2010 00:10, chmod+x wrote:
 Walter Bright Wrote:

 Steven Schveighoffer wrote:
 I'm not sure what this does, I really *really* hope it doesn't set the
 attrs of all files to a+x.

You can download the new beta and see how it worked!

Now it works. However, you're wasting bandwidth because the zipper is a lot worse than 7zip at making .zips!

Btw. the LZMA SDK is public domain and could be integrated into phobos just as convenient as std.zip, right ?
Sep 15 2010
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/14/10 16:04 CDT, Walter Bright wrote:
 Steven Schveighoffer wrote:
 Not that anyone here is in charge of your time, I think Andrei's
 "waste of time" point is that there are better, more productive things
 you can do for the good of D. If someone else wants to write this
 utility, great. But in the meantime, can we just put in the easy fix?

It's arguable whether the "easy" fix is to write a trivial utility, or to rejigger all my build and install scripts. In any case, it's done. Here it is, it's mostly a cut&paste from another zip utility I wrote long ago.

I might be missing something, but as I mentioned, I fail to see how this program serves the packaging process better than the zip utility available on Linux. Andrei
Sep 14 2010
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Andrei Alexandrescu wrote:
 I might be missing something, but as I mentioned, I fail to see how this 
 program serves the packaging process better than the zip utility 
 available on Linux.

All the build, install, and test scripts run on windows (using plink to build things on the other platforms). Writing a script to transfer all the files to linux, reset the permissions, run zip, copy the results back, etc., will take longer than just writing that trivial utility. That's what programming languages are for.
Sep 14 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/14/10 18:24 CDT, Denis Koroskin wrote:
 On Wed, 15 Sep 2010 02:58:45 +0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 9/14/10 16:04 CDT, Walter Bright wrote:
 Steven Schveighoffer wrote:
 Not that anyone here is in charge of your time, I think Andrei's
 "waste of time" point is that there are better, more productive things
 you can do for the good of D. If someone else wants to write this
 utility, great. But in the meantime, can we just put in the easy fix?

It's arguable whether the "easy" fix is to write a trivial utility, or to rejigger all my build and install scripts. In any case, it's done. Here it is, it's mostly a cut&paste from another zip utility I wrote long ago.

I might be missing something, but as I mentioned, I fail to see how this program serves the packaging process better than the zip utility available on Linux. Andrei

I think we've spent far more time on this discussion that Walter on the zipper :) I'm actually on his side tbh. Sometimes it's plain faster to reinvent the wheel than learn third-party solution. You are also forgetting about the fun-factor: sometimes you are getting hooked on something even if it's actually useless or silly, there is still an experience gain.

The problem is twofold. One, writing one custom program for a typical scripting task does not foster learning stuff that you'll be using for the next unrelated scripting task. It's squarely the wrong kind of reinforcement. Second, doing this systematically takes us to Creativity's ugly cousins: Provincialism and Isolation.
 Walter delivers the way he can. It might not be an optimal solution from
 other peoples' perspective, but I do think it's viable. And if it is a
 replaceable part of a building process, why not? Make it work first,
 then make it right.

 BTW, in spite of hearing that unix zip is capable of doing the job many
 times today I didn't see the solution posted.

zip gorramfile.zip gorramfiles/* Andrei
Sep 14 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 The difference is, on *nix the disabled executable flag prevents *all 
 users* from launching the application. The attributes have a standard 
 meaning.

No, the meanings are not standard between Windows and Linux. There's no way to make them standard, either. The file systems are *different*.
 *nix also has the 'hidden flag' in form of files with names 
 starting with a dot.

A filename convention is not a file attribute bit, and there's no way to pretend they are the same in a portable archiver.
 The S, H, and A attributes don't have any use when shipping 3rd party 
 userspace applications.

That's up to the distributor. I don't like 'em and don't use 'em, but I'd support them properly if I was writing a file packager/unpackager. The right solution is supported by the zip file format - there are separate attribute fields for unix and Windows. The unzipper follows them, it's just that the zipper offers no way to set them for systems other than the one the zipper is run on.
Sep 14 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
retard wrote:
 Tue, 14 Sep 2010 14:14:42 -0700, Walter Bright wrote:
 
 retard wrote:
 The difference is, on *nix the disabled executable flag prevents *all
 users* from launching the application. The attributes have a standard
 meaning.

way to make them standard, either. The file systems are *different*.

Across *nixen. I couldn't care less about Windows.

Dmd supports Windows, therefore it must care about it.
 A power user version of the zipper would support both sets of attributes 
 and would also provide an interface for modifyin them.

Except that I could not find such a utility - for Windows or Unix.
Sep 14 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/14/10 17:05 CDT, Walter Bright wrote:
 retard wrote:
 Tue, 14 Sep 2010 14:14:42 -0700, Walter Bright wrote:

 retard wrote:
 The difference is, on *nix the disabled executable flag prevents *all
 users* from launching the application. The attributes have a standard
 meaning.

way to make them standard, either. The file systems are *different*.

Across *nixen. I couldn't care less about Windows.

Dmd supports Windows, therefore it must care about it.
 A power user version of the zipper would support both sets of
 attributes and would also provide an interface for modifyin them.

Except that I could not find such a utility - for Windows or Unix.

So please let's restart - what _exactly_ is the utility we need? Far as I can tell what we're looking for looking for a zip utility that knows how to preserve the executable bit on Unix, and produce otherwise readable archives for Windows. That's it. From what I can tell, the zip already available on Linux does all that. Andrei
Sep 14 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, September 14, 2010 15:50:22 Andrei Alexandrescu wrote:
 On 9/14/10 17:05 CDT, Walter Bright wrote:
 retard wrote:
 Tue, 14 Sep 2010 14:14:42 -0700, Walter Bright wrote:
 retard wrote:
 The difference is, on *nix the disabled executable flag prevents *all
 users* from launching the application. The attributes have a standard
 meaning.

No, the meanings are not standard between Windows and Linux. There's no way to make them standard, either. The file systems are *different*.

Across *nixen. I couldn't care less about Windows.

Dmd supports Windows, therefore it must care about it.
 A power user version of the zipper would support both sets of
 attributes and would also provide an interface for modifyin them.

Except that I could not find such a utility - for Windows or Unix.

So please let's restart - what _exactly_ is the utility we need? Far as I can tell what we're looking for looking for a zip utility that knows how to preserve the executable bit on Unix, and produce otherwise readable archives for Windows. That's it. From what I can tell, the zip already available on Linux does all that. Andrei

I understood that the files in question are being zipped on a windows box, and since the windows file system is not going to retain any of the unix permissions, the zipped files won't either. I take it that Walter's utility is meant to appropriately set the unix permissions when it zips the files. Of course, I could have completely misunderstood, but that's what it seemed to me was going on. Personally, I would think that it would make more sense to do the linux build on a linux machine and package it with tar and bzip2 (or gzip if you're old school and want a larger download), while the windows build is done a windows machine and zipped there, creating two separate downloads - one for linux and one for windows (and presumably, you'd do the same for the other architectures). All file permissions are thus properly maintained. Since I assume that you have to do the build on the appropriate machine _anyway_, I don't see why we should be going to the trouble of creating a single zip file with both. Normally, people only want one of the two anyway. - Jonathan M Davis
Sep 14 2010
prev sibling parent BCS <none anon.com> writes:
Hello Walter,

 retard wrote:
 
 Tue, 14 Sep 2010 14:14:42 -0700, Walter Bright wrote:
 
 retard wrote:
 
 The difference is, on *nix the disabled executable flag prevents
 *all users* from launching the application. The attributes have a
 standard meaning.
 

no way to make them standard, either. The file systems are *different*.



Do any of the attribute bits for the files in the DMD zips matter on windows? If not, just zip it up on linux and be done with it. -- ... <IXOYE><
Sep 14 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/14/10 16:14 CDT, Walter Bright wrote:
 retard wrote:
 The difference is, on *nix the disabled executable flag prevents *all
 users* from launching the application. The attributes have a standard
 meaning.

No, the meanings are not standard between Windows and Linux. There's no way to make them standard, either. The file systems are *different*.
 *nix also has the 'hidden flag' in form of files with names starting
 with a dot.

A filename convention is not a file attribute bit, and there's no way to pretend they are the same in a portable archiver.
 The S, H, and A attributes don't have any use when shipping 3rd party
 userspace applications.

That's up to the distributor. I don't like 'em and don't use 'em, but I'd support them properly if I was writing a file packager/unpackager. The right solution is supported by the zip file format - there are separate attribute fields for unix and Windows. The unzipper follows them, it's just that the zipper offers no way to set them for systems other than the one the zipper is run on.

What flags do you need to set specifically for Windows? Andrei
Sep 14 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/13/2010 11:51 PM, Russel Winder wrote:
 On Mon, 2010-09-13 at 19:57 -0500, Andrei Alexandrescu wrote:
 [ . . . ]
 Anyhow, I guess that underlines the necessity to do what everybody does
 - assemble the installer on the distribution platform, and have it only
 contain the files for that platform. An increasingly large audience is

So create a Linux distribution on a Linux box (*) containing only the Linux materials with tar not zip using bzip2 or gzip compression. Solaris, FreeBSD, etc. all go the same. Doing this for the source distribution will assist getting things into the Debian packaging system. On Windows I guess zip created on a Windows box (*) is the only option. I am sure Windows people will be happy not to have all the Linux and Mac OS stuff (which to them is crud). For Mac OS X the question is whether to make a Mac OS X installer, or ship a zipfile or tarball -- difficult for me to call I am not really a Mac OS X person, but . . . it would be really good to have a port in MacPorts to save the hassle of doing any manual installation. (**) Can I suggest that as part of the revolution that is going to be caused by having a 64-bit as well as 32-bit version of D v2, that there is a campaign to have D in Debian, Fedora and MacPorts.

My thoughts exactly. Andrei
Sep 14 2010
prev sibling next sibling parent Brad Roberts <braddr slice-2.puremagic.com> writes:
On Mon, 13 Sep 2010, Andrei Alexandrescu wrote:

 On 09/13/2010 12:32 PM, Walter Bright wrote:
 Of course you're right, and I know it, I've just been lazy. I spent some
 time on google and cannot find a zip program for Windows that enables
 one to set (or even display) the file attributes in zip files. Go
 figure. So I'll just write one using Phobos' std.zip.

s/So I\'ll just write one using Phobos\' std.zip/So I\'ll just use zip on Linux and call it a day/ Waste of time doesn't begin to describe this.

Well, it does begin the description, but it's no where near the full, sad, story.
Sep 13 2010
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/13/2010 04:44 PM, Andrej Mitrovic wrote:
 Can't you use your archiver to do that for you? F2, rename, extract.
 Done deal. I like to keep the latest version in the DMD2 folder, all
 the better for compatibility with existing build scripts. I really
 wouldn't want to have to keep renaming paths in makefiles for every
 release of DMD2. Although I'll never have that problem since I can
 rename the folder inside the zip.

What they often do is install the product with the full version in the directory name, and then write a link to the latest. So you'd have dmd2.048/ and then dmd2 a link to it. Andrei
Sep 13 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Mon, 13 Sep 2010 01:53:06 +0000, BCS wrote:

 Hello chmod+x,
 
 Another source of misery are the contents of the dmd zip file. Every
 time you need to set +x flag for the executable. This is so ridiculous.
 Does the Creator accept one bit binary patches to the distributions to
 make the solution a reality? It's open source:
 
 unzip dmdzip.zip
 chmod +x executables
 zip -r dmdzip *
 
 

:(

FWIW, http://www.digitalmars.com/webnews/newsgroups.php? art_group=digitalmars.D&article_id=114660 mentions that the build system uses *nix. I'm guessing the internal testing system uses modern *nix tools, but the final release is published on a windows machine.
Sep 12 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisprog gmail.com> writes:
On Sunday 12 September 2010 18:53:06 BCS wrote:
 Hello chmod+x,
 
 Another source of misery are the contents of the dmd zip file. Every
 time you need to set +x flag for the executable. This is so
 ridiculous. Does the Creator accept one bit binary patches to the
 distributions to make the solution a reality? It's open source:
 
 unzip dmdzip.zip
 chmod +x executables
 zip -r dmdzip *

IIRC the .zip is created on a windows box so that doesn't exactly work. :(

That would explain why the permissions are always messed up on dmd and phobos' files. There are some things that Windows does better than Linux. However, file permissions is _not_ one of them. - Jonathan M Davis
Sep 12 2010
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2010-09-13 at 01:53 +0000, BCS wrote:
 Hello chmod+x,
=20
 Another source of misery are the contents of the dmd zip file. Every
 time you need to set +x flag for the executable. This is so
 ridiculous. Does the Creator accept one bit binary patches to the
 distributions to make the solution a reality? It's open source:
=20
 unzip dmdzip.zip
 chmod +x executables
 zip -r dmdzip *
=20

IIRC the .zip is created on a windows box so that doesn't exactly work. :=

To be honest I don't give a fig about how the zipfile is created, the scripts and executables for Linux should come with the execute permission preset. It is a ridiculous irritation that after unzipping a supposed binary distribution, I then have to go and work out which files to make executable. If Windows cannot hack building a proper zipfile then a machine with a proper operating system should be used so that the zipfile is fit for its purpose. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Sep 13 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 12 Sep 2010 21:53:06 -0400, BCS <none anon.com> wrote:

 Hello chmod+x,

 Another source of misery are the contents of the dmd zip file. Every
 time you need to set +x flag for the executable. This is so
 ridiculous. Does the Creator accept one bit binary patches to the
 distributions to make the solution a reality? It's open source:
  unzip dmdzip.zip
 chmod +x executables
 zip -r dmdzip *

IIRC the .zip is created on a windows box so that doesn't exactly work. :(

I have written this script to aid in my installation of different dmd versions, and it's made it much less unpleasant. Because in addition to the chmod+x, it always unpacks into dmd2, which may not be where you want to put it. It installs dmd version X into the directory ~/dmd-X and automatically chmods the exes. It assumes your files all download into the ~/Download directory. It also will list all dmd versions you have downloaded if you don't specify a version. #!/bin/sh if [ -z "$1" ] then echo Error, must supply dmd version to unpack. error=1 else filename=~/Download/dmd.$1.zip if [ ! -f "$filename" ] then echo DMD version $1 does not exist. error=1 fi fi if [ "$error" = "1" ] then echo here are the valid versions: for fname in ~/Download/dmd.*.zip do basename $fname .zip | sed 's/dmd\.//g' done exit 1 fi tmpdir=`mktemp -d /tmp/dmd.XXXXXXXX` cd $tmpdir unzip -q $filename chmod 755 dmd2/linux/bin/* mv dmd2 ~/dmd-$1 cd ~ rmdir $tmpdir exit 0 -Steve
Sep 13 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Command Man, and his sidekick, Clippy.

On Mon, Sep 13, 2010 at 5:29 PM, Justin Johansson <no spam.com> wrote:
 On 14/09/2010 12:55 AM, Justin Johansson wrote:
 meant for understanding by the common man. OTOH, simple
 DOS scripts do oft make for the Fanfare for the Command Man.
 Hey, perhaps Aaron Copland would have preferred to be a
 DOS programmer.

Seriously, that was just a serendipitous typo. I meant the Common Man, not the "Command" Man as in say a "command-line" man. =A0Maybe that wasn't really a typo but some Freudian slip on my part. :-) -- Justin

Sep 13 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Lost in translation.

Yes I was only kidding. :)

On Mon, Sep 13, 2010 at 10:43 PM, Justin Johansson <no spam.com> wrote:
 He he.

 Of course "SideKick" itself was some very popular TSR
 utility wasn't it? =A0(But you didn't mean that?)
 For the young people here, TSR is Terminate and Stay Resident,
 an artifact of DOS 640KB days. =A0No doubt see Wikipedia for more.
 Oh dear. =A0:-)

 But Clippy? The only Clippy I know (and hated) it that
 stupid yesteryear Word popup. =A0You meant that thing?

 - Justin


 On 14/09/2010 1:40 AM, Andrej Mitrovic wrote:
 Command Man, and his sidekick, Clippy.

 On Mon, Sep 13, 2010 at 5:29 PM, Justin Johansson<no spam.com> =A0wrote:
 On 14/09/2010 12:55 AM, Justin Johansson wrote:
 meant for understanding by the common man. OTOH, simple
 DOS scripts do oft make for the Fanfare for the Command Man.
 Hey, perhaps Aaron Copland would have preferred to be a
 DOS programmer.

Seriously, that was just a serendipitous typo. I meant the Common Man, not the "Command" Man as in say a "command-line" man. =A0Maybe that wasn't really a typo but some Freudian slip on my part. :-) -- Justin



Sep 13 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 13 Sep 2010 17:11:30 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 09/13/2010 12:32 PM, Walter Bright wrote:
 Russel Winder wrote:
 To be honest I don't give a fig about how the zipfile is created, the
 scripts and executables for Linux should come with the execute
 permission preset. It is a ridiculous irritation that after unzipping a
 supposed binary distribution, I then have to go and work out which  
 files
 to make executable. If Windows cannot hack building a proper zipfile
 then a machine with a proper operating system should be used so that  
 the
 zipfile is fit for its purpose.

Of course you're right, and I know it, I've just been lazy. I spent some time on google and cannot find a zip program for Windows that enables one to set (or even display) the file attributes in zip files. Go figure. So I'll just write one using Phobos' std.zip.

s/So I\'ll just write one using Phobos\' std.zip/So I\'ll just use zip on Linux and call it a day/

Better yet, have downloads for the different OSes. Downloading all executables/compiled libs for all platforms when I'm interested in one makes no sense. The current zipfile is at 10MB, if I trim out all but my OS, it is down to 5MB. I assume you are not building all the compiled binaries and libs on a cross-compiler, so at this point, you have to go to each OS *anyways*. Then make the OSX and Linux ones tarballs. Finally, the files that are extracted should be under a directory named for the compiler version. For example, if I extract dmd.2.048.zip, it should extract into a dmd2.048 directory, not dmd2. -Steve
Sep 13 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Can't you use your archiver to do that for you? F2, rename, extract.
Done deal. I like to keep the latest version in the DMD2 folder, all
the better for compatibility with existing build scripts. I really
wouldn't want to have to keep renaming paths in makefiles for every
release of DMD2. Although I'll never have that problem since I can
rename the folder inside the zip.

On Mon, Sep 13, 2010 at 11:25 PM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:
 Finally, the files that are extracted should be under a directory named f=

 the compiler version. =A0For example, if I extract dmd.2.048.zip, it shou=

 extract into a dmd2.048 directory, not dmd2.

 -Steve

Sep 13 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 13 Sep 2010 17:44:57 -0400, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:

 Can't you use your archiver to do that for you? F2, rename, extract.
 Done deal. I like to keep the latest version in the DMD2 folder, all
 the better for compatibility with existing build scripts. I really
 wouldn't want to have to keep renaming paths in makefiles for every
 release of DMD2. Although I'll never have that problem since I can
 rename the folder inside the zip.

I don't use an "archiver", I just unzip. Then I have to rename. I typically keep all versions I've extracted intact so I can test older versions against code. I can see why that's not advantageous to simple users. However, it's pretty standard to have source archives extract to a version-specific directory, and there's a lot of source code in the archive. For one thing, you don't want to extract over the old one, since files that may be deleted in the new archive would not be removed by extracting. The best way to handle installation for your purposes is to use an installer. That will remove older files and install newer ones. BTW, this is a non-issue on non-windows systems, because you have the universally accepted symlink method of pointing at a different version. -Steve
Sep 13 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
http://sourceforge.net/projects/getgnuwin32/files/ (it extracts some
files and download & install scripts).

The download takes a while though. There's some 400 packages in there,
or about ~1000 executables in my GNUWin32/bin folder. Crazy. :p

On Tue, Sep 14, 2010 at 12:15 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:
 On 09/13/2010 04:28 PM, dsimcha wrote:
 =3D=3D Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s
 article
 On 09/13/2010 12:32 PM, Walter Bright wrote:
 Russel Winder wrote:
 To be honest I don't give a fig about how the zipfile is created, the
 scripts and executables for Linux should come with the execute
 permission preset. It is a ridiculous irritation that after unzipping=





 supposed binary distribution, I then have to go and work out which
 files
 to make executable. If Windows cannot hack building a proper zipfile
 then a machine with a proper operating system should be used so that
 the
 zipfile is fit for its purpose.

Of course you're right, and I know it, I've just been lazy. I spent so=




 time on google and cannot find a zip program for Windows that enables
 one to set (or even display) the file attributes in zip files. Go
 figure. So I'll just write one using Phobos' std.zip.

s/So I\'ll just write one using Phobos\' std.zip/So I\'ll just use zip on Linux and call it a day/ Waste of time doesn't begin to describe this. Andrei

Well, some people (like me) just plain prefer Windows over Linux. =A0Tha=


 said,
 there's always Cygwin. =A0I love the command line environment of Unix-li=


 OS's, but
 prefer certain things about Windows like having stable ABIs for the basi=


 OS
 facilities (meaning that I can just download and unpack a binary and it
 **consistently** just works across all modern Windows machines) and havi=


 hardware support that doesn't suck horribly. =A0Cygwin lets me have it b=


 ways.
 Also, Cygwin's zip is probably compiled from the same source as any Linu=


 distro's, and should probably do what you need.

There's nothing wrong about preferring Windows over Linux. I'm just sayin=

 (much like you) that badly reinventing Unix tools under Windows is not qu=

 productive.

 Andrei

Sep 13 2010
prev sibling next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
On Tue, Sep 14, 2010 at 12:56 AM, Walter Bright
<newshound2 digitalmars.com> wrote:
 Andrei Alexandrescu wrote:
 There's nothing wrong about preferring Windows over Linux. I'm just saying
 (much like you) that badly reinventing Unix tools under Windows is not quite
 productive.

The unix version of zip has no option to set the file attributes either.

It has the (default) option of preserving the attributes and the option (-X) to explicitly not save the attributes. What is the reason for delivering executables for 4 different operating systems in the same archive anyway? Having a different archive for each OS would reduce the download-size and you could use archive formats that are better suited for each platform, e.g. tar for unixoid systems. Tar *does* allow to set the owner/group/mode attributes when adding files to a tarball. At least gnu tar does, but probably there are ports for windows are able to do the same thing. Cheers, - Daniel
Sep 13 2010
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2010-09-13 at 23:44 +0200, Andrej Mitrovic wrote:
 Can't you use your archiver to do that for you? F2, rename, extract.
 Done deal. I like to keep the latest version in the DMD2 folder, all
 the better for compatibility with existing build scripts. I really
 wouldn't want to have to keep renaming paths in makefiles for every
 release of DMD2. Although I'll never have that problem since I can
 rename the folder inside the zip.

That is what symbolic links are for. The binary distribution should unpack into a version specific directory. This then allows multiple versions to be installed at the same time and for selection to be by trivially changing a symbolic link. |> ll -d ~/lib*/*[dD][mM][dD]* lrwxrwxrwx 1 russel russel 9 2010-08-13 16:50 /home/users/russel/lib/DM= D1 -> dmd-1.063/ drwx------ 10 russel russel 4096 2010-08-13 16:49 /home/users/russel/lib/dm= d-1.063/ lrwxrwxrwx 1 russel russel 9 2010-08-13 18:33 /home/users/russel/lib/DM= D2 -> dmd-2.048/ drwx------ 9 russel russel 4096 2010-08-13 16:50 /home/users/russel/lib/dm= d-2.048/ lrwxrwxrwx 1 russel russel 17 2010-08-13 16:52 /home/users/russel/lib.Li= nux.ix86/DMD1 -> ../lib/DMD1/linux/ lrwxrwxrwx 1 russel russel 17 2010-08-13 16:52 /home/users/russel/lib.Li= nux.ix86/DMD2 -> ../lib/DMD2/linux/ lrwxrwxrwx 1 russel russel 17 2010-08-13 16:55 /home/users/russel/lib.Li= nux.x86_64/DMD1 -> ../lib/DMD1/linux/ lrwxrwxrwx 1 russel russel 17 2010-08-13 16:55 /home/users/russel/lib.Li= nux.x86_64/DMD2 -> ../lib/DMD2/linux/ |> Better still, get the whole thing packaged by Debian and thence in the Debian and Ubuntu distributions by default. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Sep 13 2010
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2010-09-13 at 19:57 -0500, Andrei Alexandrescu wrote:
[ . . . ]
 Anyhow, I guess that underlines the necessity to do what everybody does=20
 - assemble the installer on the distribution platform, and have it only=20
 contain the files for that platform. An increasingly large audience is=20

So create a Linux distribution on a Linux box (*) containing only the Linux materials with tar not zip using bzip2 or gzip compression. Solaris, FreeBSD, etc. all go the same. Doing this for the source distribution will assist getting things into the Debian packaging system. On Windows I guess zip created on a Windows box (*) is the only option. I am sure Windows people will be happy not to have all the Linux and Mac OS stuff (which to them is crud). For Mac OS X the question is whether to make a Mac OS X installer, or ship a zipfile or tarball -- difficult for me to call I am not really a Mac OS X person, but . . . it would be really good to have a port in MacPorts to save the hassle of doing any manual installation. (**) Can I suggest that as part of the revolution that is going to be caused by having a 64-bit as well as 32-bit version of D v2, that there is a campaign to have D in Debian, Fedora and MacPorts. (*) No need for separate Linux and Windows hardware, though that is best, you can just use virtual machines. (**) Mac OS X sort of does require A$$le hardware. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Sep 13 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 13 Sep 2010 21:44:35 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Andrei Alexandrescu wrote:
 On 09/13/2010 07:47 PM, Walter Bright wrote:
 zip on unix has no way to set the Windows attributes, and zip on  
 Windows
 has no way to set the unix attributes. Both have attributes that have  
 no
 analogs on the other. Both have no way to set the non-native  
 attributes.


There isn't. But there are system, hidden, and archive attribute bits that have no analog on unix. Not that we use any of those bits...

Um... ok, so logic says that in this particular case, the most universally useful archive is formed on Linux. I don't see where your point is...
 I'm just arguing the point that unix utilities are not always better -  
 in this case, they have the same deficiency. Googling this particular  
 issue brings up pages where people are told to use python scripts to set  
 the attributes in a zip file.

This isn't a unix vs. windows war. We aren't counting up the points that the utilities score to see who is better. We just want an archive that does the right thing on all OSes. This can be achieved by building it on Linux. So do it already :) BTW, the fact that zip is not all-encompassing on Linux is not surprising -- the main method of archive distribution on Linux is tar.gz/bz2.
 It's also nice to eat our own dogfood, and do something useful with  
 std.zip.

Not that anyone here is in charge of your time, I think Andrei's "waste of time" point is that there are better, more productive things you can do for the good of D. If someone else wants to write this utility, great. But in the meantime, can we just put in the easy fix? -Steve
Sep 14 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Mon, 13 Sep 2010 18:44:35 -0700, Walter Bright wrote:

 Andrei Alexandrescu wrote:
 On 09/13/2010 07:47 PM, Walter Bright wrote:
 zip on unix has no way to set the Windows attributes, and zip on
 Windows has no way to set the unix attributes. Both have attributes
 that have no analogs on the other. Both have no way to set the
 non-native attributes.

I didn't know there is an executable attribute on Windows.

There isn't. But there are system, hidden, and archive attribute bits that have no analog on unix. Not that we use any of those bits, I'm just arguing the point that unix utilities are not always better - in this case, they have the same deficiency.

The difference is, on *nix the disabled executable flag prevents *all users* from launching the application. The attributes have a standard meaning. *nix also has the 'hidden flag' in form of files with names starting with a dot. The S, H, and A attributes don't have any use when shipping 3rd party userspace applications. The A attribute would matter if various archivers actually preserved it and there was a standard on when to set it on.
 
 It's also nice to eat our own dogfood, and do something useful with
 std.zip.

And D is a pragmatic language? Listen man, you the Superman of the D world and instead of fighting crimes, you're always knitting socks.
Sep 14 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 14 Sep 2010 17:04:21 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Steven Schveighoffer wrote:
 Not that anyone here is in charge of your time, I think Andrei's "waste  
 of time" point is that there are better, more productive things you can  
 do for the good of D.  If someone else wants to write this utility,  
 great.  But in the meantime, can we just put in the easy fix?

It's arguable whether the "easy" fix is to write a trivial utility, or to rejigger all my build and install scripts.

Not knowing what your build scripts look like, I don't know the answer. I'm assuming you have some manual work to do because you are building on several different machines, and I was assuming that due to that fact, the packaging step was not part of the build steps. In that case, it would be a trivial, change package command from running on a windows box to running on a linux box. It might be a simple assumption, but I very much doubt you would have to rejigger *all* your build scripts.
 In any case, it's done. Here it is, it's mostly a cut&paste from another  
 zip utility I wrote long ago.

I'm not sure what this does, I really *really* hope it doesn't set the attrs of all files to a+x. In any case, if it works, it's done, let's move on (I still prefer separate packages per OS though). -Steve
Sep 14 2010
prev sibling next sibling parent retard <re tard.com.invalid> writes:
Tue, 14 Sep 2010 14:14:42 -0700, Walter Bright wrote:

 retard wrote:
 The difference is, on *nix the disabled executable flag prevents *all
 users* from launching the application. The attributes have a standard
 meaning.

No, the meanings are not standard between Windows and Linux. There's no way to make them standard, either. The file systems are *different*.

Across *nixen. I couldn't care less about Windows.
 
 
 *nix also has the 'hidden flag' in form of files with names starting
 with a dot.

A filename convention is not a file attribute bit, and there's no way to pretend they are the same in a portable archiver.

I meant it's semantically a similar convention.
 
 
 The S, H, and A attributes don't have any use when shipping 3rd party
 userspace applications.

That's up to the distributor. I don't like 'em and don't use 'em, but I'd support them properly if I was writing a file packager/unpackager. The right solution is supported by the zip file format - there are separate attribute fields for unix and Windows. The unzipper follows them, it's just that the zipper offers no way to set them for systems other than the one the zipper is run on.

A power user version of the zipper would support both sets of attributes and would also provide an interface for modifyin them.
Sep 14 2010
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Wed, 15 Sep 2010 02:58:45 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 9/14/10 16:04 CDT, Walter Bright wrote:
 Steven Schveighoffer wrote:
 Not that anyone here is in charge of your time, I think Andrei's
 "waste of time" point is that there are better, more productive things
 you can do for the good of D. If someone else wants to write this
 utility, great. But in the meantime, can we just put in the easy fix?

It's arguable whether the "easy" fix is to write a trivial utility, or to rejigger all my build and install scripts. In any case, it's done. Here it is, it's mostly a cut&paste from another zip utility I wrote long ago.

I might be missing something, but as I mentioned, I fail to see how this program serves the packaging process better than the zip utility available on Linux. Andrei

I think we've spent far more time on this discussion that Walter on the zipper :) I'm actually on his side tbh. Sometimes it's plain faster to reinvent the wheel than learn third-party solution. You are also forgetting about the fun-factor: sometimes you are getting hooked on something even if it's actually useless or silly, there is still an experience gain. Walter delivers the way he can. It might not be an optimal solution from other peoples' perspective, but I do think it's viable. And if it is a replaceable part of a building process, why not? Make it work first, then make it right. BTW, in spite of hearing that unix zip is capable of doing the job many times today I didn't see the solution posted.
Sep 14 2010
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 14 Sep 2010 17:57:17 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 Steven Schveighoffer wrote:
 I'm not sure what this does, I really *really* hope it doesn't set the  
 attrs of all files to a+x.

You can download the new beta and see how it worked!

I did, seems to work good, thanks! -Steve
Sep 15 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2010-09-13 02:10, dsimcha wrote:
 == Quote from Jesse Phillips (jessekphillips+D gmail.com)'s article
 Lutger Wrote:
 You need the i686 versions of some packages, probably start with libgcc (yum
 install libgcc.i686) and glibc, I don't remember which exactly are required. I
 have dmd running on 64 bit fedora just fine, it can work. There is also a
64-bit
 dmd in the making which should solve all those problems.


The compiler already has been compilable as a 64-bit binary for months. IMHO, though, Walter should release a 64-bit pre-compiled binary to make life easy for ppl with 64-bit installs.

Yes, I've been compiling dmd as a 64bit binary since I switched to a 64bit system, Snow Leopard. -- /Jacob Carlborg
Sep 13 2010
prev sibling next sibling parent Spacen Jasset <spacenjasset yahoo.co.uk> writes:
On 11/09/2010 23:52, Vladimir G. Ivanovic wrote:
   I'm running Fedora 13.x86_64 and I've tried various ways of getting a
 D compiler to work. None have succeeded.

 1. a. I can't install dmd 2.048:

          # rpm -Uvh /downloads/dmd-2.048-0.i386.rpm
          error: Failed dependencies:
             gcc(x86-32)>= 4.2.3 is needed by dmd-2.048-0.i386
     I don't know what package will satisfy this dependency.
     b. dmd is a closed compiler. Not good. I'm really not comfortable
 running a compiler for which I don't have access to the source. The
 risk of undetected malware is too great.
     c. So, I give up on dmd.

 2. I can't run ldc because
     a. The ldc RPM requires Tango, even though this is not an RPM
 dependency for ldc, i.e. you can install ldc without any errors.
     b. The installation instructions for Fedora on the LDC web site are
 incorrect. "yum install ldc" works, but "yum install tango" doesn't.
 "yum install tango-devel" is the correct command. (This is the first
 time I've heard of<pkg>-devel without a corresponding<pkg>.)
     c. After I've gotten everything installed, it still doesn't work. I get
          $ ldc hello.d
          hello.d(5): Error: module stdio cannot read file 'std/stdio.d'
     d. OK, so I link /usr/include/d/tango/stdc to
 /usr/include/d/tango/std, but it still doesn't work. I get:
          $ ldc hello.d
          hello.d(8): Error: undefined identifier writefln
          hello.d(8): Error: function expected before (), not writefln
 of type int
     e. ldc only supports D v1.
     f. All of this is too much for me. I give up on ldc.

 3. I can't get gdc to compile.
     a. First I have to get gcc-4.4.4 to compile, but that requires a 4
 year old version of automake. I have to downgrade.
     b. After that's fixed, I'm still running into errors that prevent a
 build. The errors change from changeset to changeset. So, I'm giving
 up on gdc.

 Getting a D compiler to run on x86_64 Linux is too hard. I'm giving up
 on D.

 I'm posting this message not as a plea for help, but to illustrate how
 hard it is to get D to run on Fedora.x86_64. The success of D depends
 on high quality, open source compilers being available (my belief),
 and so far, D doesn't seem to be mature enough to be considered, at
 least on Fedora.x86_64.

 But, on the plus side, the existence of the book "The D Programming
 Language" is a major step in getting D accepted as a serious system
 programming language. Maybe installation will improve and D will move
 forward.

 --- Vladimir

when installing an rpm package it's usually best to try yum localinstall /downloads/dmd-2.048-0.i386.rpm first and yum will then go off and fetch the dependencies if (a) they are available and (b) they have been specified properly in the rpm package
Sep 12 2010
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/11/2010 05:52 PM, Vladimir G. Ivanovic wrote:
   I'm running Fedora 13.x86_64 and I've tried various ways of getting a
 D compiler to work. None have succeeded.

 1. a. I can't install dmd 2.048:

          # rpm -Uvh /downloads/dmd-2.048-0.i386.rpm
          error: Failed dependencies:
             gcc(x86-32)>= 4.2.3 is needed by dmd-2.048-0.i386
     I don't know what package will satisfy this dependency.
     b. dmd is a closed compiler. Not good. I'm really not comfortable
 running a compiler for which I don't have access to the source. The
 risk of undetected malware is too great.
     c. So, I give up on dmd.

Apologies for the poor experience. It's because you don't have the 32-bit portability libraries on your 64-bit system. A 64-bit edition is in the works and would certainly make everything smoother. In the meantime you'd need to run: sudo apt-get install gcc-multilib libc6-i386 lib6-dev-i386 sudo apt-get install gcc-multilib sudo apt-get install g++-multilib We need to add these instructions to the download page. Andrei
Sep 12 2010
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Andrei Alexandrescu schrieb:
 On 09/11/2010 05:52 PM, Vladimir G. Ivanovic wrote:
   I'm running Fedora 13.x86_64 and I've tried various ways of getting a
 D compiler to work. None have succeeded.

 1. a. I can't install dmd 2.048:

          # rpm -Uvh /downloads/dmd-2.048-0.i386.rpm
          error: Failed dependencies:
             gcc(x86-32)>= 4.2.3 is needed by dmd-2.048-0.i386
     I don't know what package will satisfy this dependency.
     b. dmd is a closed compiler. Not good. I'm really not comfortable
 running a compiler for which I don't have access to the source. The
 risk of undetected malware is too great.
     c. So, I give up on dmd.

Apologies for the poor experience. It's because you don't have the 32-bit portability libraries on your 64-bit system. A 64-bit edition is in the works and would certainly make everything smoother. In the meantime you'd need to run: sudo apt-get install gcc-multilib libc6-i386 lib6-dev-i386 sudo apt-get install gcc-multilib sudo apt-get install g++-multilib We need to add these instructions to the download page. Andrei

The information is there: http://www.digitalmars.com/d/2.0/dmd-linux.html#installation However apt-get is Debian/Ubuntu specific, so these commands are not *directly* applicable for fedora. However equivalent packages should be available on fedora and instead of apt-get install it's something like yum install gcc-multilib etc (or whatever the packages are called there). Cheers, - Daniel
Sep 12 2010
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Russel Winder wrote:
 Of course this only gives a 32-bit D, which isn't really what is needed
 these days on a 64-bit platform.  So the sooner the 64-bit version of D
 comes out, the better -- preferably last year ;-)

Don't I know it!
Sep 12 2010
prev sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 09/12/2010 12:12 PM, Andrei Alexandrescu wrote:
 Apologies for the poor experience. It's because you don't have the
 32-bit portability libraries on your 64-bit system. A 64-bit edition is
 in the works and would certainly make everything smoother.

 In the meantime you'd need to run:

 sudo apt-get install gcc-multilib libc6-i386 lib6-dev-i386
 sudo apt-get install gcc-multilib
 sudo apt-get install g++-multilib

 We need to add these instructions to the download page.


 Andrei

Andrei, the only reason he's running into problems is because in the rpm script there is the line Requires: gcc(x86-32) which requires gcc to be 32 bit. I've been running dmd with 64 bit gcc on fedora for years without problems. Change the line to Requires: gcc and it will work fine.
Sep 15 2010
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/15/10 22:58 CDT, Ellery Newcomer wrote:
 On 09/12/2010 12:12 PM, Andrei Alexandrescu wrote:
 Apologies for the poor experience. It's because you don't have the
 32-bit portability libraries on your 64-bit system. A 64-bit edition is
 in the works and would certainly make everything smoother.

 In the meantime you'd need to run:

 sudo apt-get install gcc-multilib libc6-i386 lib6-dev-i386
 sudo apt-get install gcc-multilib
 sudo apt-get install g++-multilib

 We need to add these instructions to the download page.


 Andrei

Andrei, the only reason he's running into problems is because in the rpm script there is the line Requires: gcc(x86-32) which requires gcc to be 32 bit. I've been running dmd with 64 bit gcc on fedora for years without problems. Change the line to Requires: gcc and it will work fine.

Ha, good tip. Thanks! Andrei
Sep 15 2010
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 2010-09-12 at 12:12 -0500, Andrei Alexandrescu wrote:
 On 09/11/2010 05:52 PM, Vladimir G. Ivanovic wrote:
   I'm running Fedora 13.x86_64 and I've tried various ways of getting a
 D compiler to work. None have succeeded.

 1. a. I can't install dmd 2.048:

          # rpm -Uvh /downloads/dmd-2.048-0.i386.rpm
          error: Failed dependencies:
             gcc(x86-32)>=3D 4.2.3 is needed by dmd-2.048-0.i386
     I don't know what package will satisfy this dependency.
     b. dmd is a closed compiler. Not good. I'm really not comfortable
 running a compiler for which I don't have access to the source. The
 risk of undetected malware is too great.
     c. So, I give up on dmd.

Apologies for the poor experience. It's because you don't have the=20 32-bit portability libraries on your 64-bit system. A 64-bit edition is=20 in the works and would certainly make everything smoother. =20 In the meantime you'd need to run: =20 sudo apt-get install gcc-multilib libc6-i386 lib6-dev-i386 sudo apt-get install gcc-multilib sudo apt-get install g++-multilib =20 We need to add these instructions to the download page.

I wonder if part of the problem for OP was using rpm rather than yum? I found using aptitude on Ubuntu and Debian on x86_64 it was relatively easy to get the downloaded D distribution working, all that was needed was to install the 32-bit libraries and the multilib GCC. Not a big deal to be honest. Of course this only gives a 32-bit D, which isn't really what is needed these days on a 64-bit platform. So the sooner the 64-bit version of D comes out, the better -- preferably last year ;-) --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Sep 12 2010
prev sibling next sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Vladimir G. Ivanovic wrote:
  I'm running Fedora 13.x86_64 and I've tried various ways of getting a
 D compiler to work. None have succeeded.

 1. a. I can't install dmd 2.048:
 
         # rpm -Uvh /downloads/dmd-2.048-0.i386.rpm
         error: Failed dependencies:
            gcc(x86-32) >= 4.2.3 is needed by dmd-2.048-0.i386
    I don't know what package will satisfy this dependency.
    b. dmd is a closed compiler. Not good. I'm really not comfortable
 running a compiler for which I don't have access to the source. The
 risk of undetected malware is too great.
    c. So, I give up on dmd.

Because DMD is a 32-bit compiler and you have a 64-bit OS install ? yum whatprovides "gcc(x86-32)" tells (or rpm --aid -Uvh before it). Currently gcc-4.4.4-10.fc13.i686.rpm provides the dependency, to use --aid you need rpmdb-fedora and a RPM version that supports it.
 2. I can't run ldc because
    a. The ldc RPM requires Tango, even though this is not an RPM
 dependency for ldc, i.e. you can install ldc without any errors.
    b. The installation instructions for Fedora on the LDC web site are
 incorrect. "yum install ldc" works, but "yum install tango" doesn't.
 "yum install tango-devel" is the correct command. (This is the first
 time I've heard of <pkg>-devel without a corresponding <pkg>.)

This is because Tango (or Phobos) only provides static libraries, if there had been a shared library it would have been "tango"... In the previous packaging one of the "runtime" library providers were required, since the compiler is not very useful without one.
    c. After I've gotten everything installed, it still doesn't work. I get
         $ ldc hello.d
         hello.d(5): Error: module stdio cannot read file 'std/stdio.d'
    d. OK, so I link /usr/include/d/tango/stdc to
 /usr/include/d/tango/std, but it still doesn't work. I get:
         $ ldc hello.d
         hello.d(8): Error: undefined identifier writefln
         hello.d(8): Error: function expected before (), not writefln
 of type int
    e. ldc only supports D v1.
    f. All of this is too much for me. I give up on ldc.

But LDC is the D compiler that Fedora has chosen for inclusion in 14... See https://fedoraproject.org/wiki/Features/D_Programming for details.
 3. I can't get gdc to compile.
    a. First I have to get gcc-4.4.4 to compile, but that requires a 4
 year old version of automake. I have to downgrade.
    b. After that's fixed, I'm still running into errors that prevent a
 build. The errors change from changeset to changeset. So, I'm giving
 up on gdc.

If you use an older GCC, it is much easier. (GCC 4.1.2 was supported) There's some GDC packages available at http://gdcgnu.sourceforge.net/
 Getting a D compiler to run on x86_64 Linux is too hard. I'm giving up
 on D.

Seems like you ran into these, all at once: - 32-bit compiler - static runtime - wrong stdlib - older version Some of these will be fixed, when/if updated. --anders
Sep 12 2010
parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
 yum whatprovides "gcc(x86-32)" tells (or rpm --aid -Uvh before it).

Make that "yum provides", I was thinking of "rpm --what-provides"... --anders
Sep 12 2010
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Nobody would care if the download was fast. :) I always get around
~100-150KB/sec with downloads from digitalmars.com, even though I can
easily reach 0.5Mb/sec on other websites.

On Mon, Sep 13, 2010 at 3:52 AM, chmod+x <zip should.support.it> wrote:
 chmod+x Wrote:

 dsimcha Wrote:

 =3D=3D Quote from Jesse Phillips (jessekphillips+D gmail.com)'s articl=



 Lutger Wrote:
 You need the i686 versions of some packages, probably start with l=





 install libgcc.i686) and glibc, I don't remember which exactly are=





 have dmd running on 64 bit fedora just fine, it can work. There is=





 dmd in the making which should solve all those problems.





 code generation for 64bit and does not see a need to make the compiler=



 The compiler already has been compilable as a 64-bit binary for months=



 though, Walter should release a 64-bit pre-compiled binary to make lif=



 ppl with 64-bit installs.

Another source of misery are the contents of the dmd zip file. Every tim=


he Creator accept one bit binary patches to the distributions to make the s= olution a reality? It's open source:
 unzip dmdzip.zip
 chmod +x executables
 zip -r dmdzip *

Okey, the binary patch is actually 349 bytes. A repackaged dmd is also 52=

andwidth cost and download time. Nobody cares.

Sep 12 2010