digitalmars.D - Policy opinion
- Georg Wrede (49/49) Oct 24 2005 Currently, D is a Windows-32 language, and more or less just on the side...
- =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= (18/18) Oct 24 2005 I think the most important thing to do now is to come up with a working
- Walter Bright (4/17) Oct 24 2005 I agree with you, but my expertise on Linux is minimal. If you can provi...
- Ameer Armaly (12/32) Oct 24 2005 Here are a few things I can think of off the top of my head:
- BCS (4/7) Oct 24 2005 What about us schmucks that can't wright to /usr/include/d and
- Ameer Armaly (5/14) Oct 24 2005 Noone's saying you *have* to, just that since many do, it should be
- BCS (3/20) Oct 25 2005 That's more or less what I am doing. But it just seems like sutch a klug...
- =?utf-8?B?RGF3aWQgQ2nEmcW8YXJraWV3aWN6?= (5/8) Oct 26 2005 This is exacly as everything else work in linux. Ever tried run gcc
- =?utf-8?B?RGF3aWQgQ2nEmcW8YXJraWV3aWN6?= (22/40) Oct 26 2005 IMO current DMD integration with linux is quite good. It is packager
Currently, D is a Windows-32 language, and more or less just on the side is available for Linux. We all know this is for "historical" reasons. However, if we were to consider what (or if, any) future directions D should weigh against each other, things might be different. Establishing a non-trivial presence on Windows will be hard. While gaining a marginal foothold is simple (as we've seen with D, Euphoria, and a bunch of other languages), reaching critical mass on Windows may be a hurdle that needs substantial markening savvy and economic backing. On the other hand, those who make decisions on the Linux platform, are in a different situation. They already are on an "alternative" platform, and therefore are not averse to "unconventional" choices. For them, the product itself, rather than its market share or other secondary issues, is what counts. While we don't have now, and will not have in the immediate future any significant chances of expanding outside Linux on 32-bit Intel, I still think that this is the exact segment we should target. That is the exact segment where we only need to make the distro install smoothly and behave like any other language package. At the same time, the effort needed here is next to trivial -- compared to other measures with the same effect. In other words, benefit per cost is superior here. What makes competing on Windows harder is Microsoft's own languages, companies who use Windows are conservative in their choice of tools. By default everyone assumes a longevity for anything originating from Microsoft itself as comparable to that of Windows itself. We here on this mailing list may know better, but the issue is the assumptions of Customers, or end-users of languages and development tools. If a product is better has never before made any difference in Windows. On Linux, the merits of the language itself are what counts. Even the documentation doesn't have to be all that "productized", as long as the compiler package doesn't appear quirky or pequliar. --- The first thing we might do is to separate the Windows and Linux downloads. Then the Linux download should get rid of the /etc conf file. Next the .exe files should vanish. And the executable binaries should be executable on Linux without manual adjustment. Issues with finding libraries, "distribution home directory", the shared object file, should all be fixed. Good examples can be found in the other language compilers for Linux. Oh, and being non-root should cause a single user installation, and being root should cause a system-wide installation. D should not care or restrict choice of install directory. These are all well understood issues with plenty of examples, howtos and other documentation around. Not having fixed these does give the language a home-made feel right from the outset. And to a user, this in itself implies other than longevity and huge potential. Once prevalent and respected on Linux, D might wake up Windows people -- at the end of the day, we'd meet our goal this way with less total effort and expenditure than with the current tack.
Oct 24 2005
=?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> I think the most important thing to do now is to come up with a working language specification. You know, as long as the language is on an alpha development state, all projects need to be partly rewritten due to some nasty language modifications. IMO there are same big problems with D interfaces. It would also be crucial to clearly define all the advanced and generic features of the language. Later on it would be easier to fix the smaller issues from any 3rd party software code. We've seen this with Java. The late support for generics has been a pain in the ass for many projects. If the core language is not ready, the oss zealots _will_ most probably want to fork their own versions of D. If the specification is "ready", there's no further need to fork anything. The same goes with "standard libraries". I think Phobos is not very good. It's weirdly structured, the hierarchies seem to be far from final. The main level of Phobos is strange - I don't think that std.recls belongs to the same abstraction level with std.math or std.file. Phobos is also missing some useful functions like the std.file.islink(char[] name).
Oct 24 2005
"Georg Wrede" <georg.wrede nospam.org> wrote in message news:435D0D24.5020608 nospam.org...The first thing we might do is to separate the Windows and Linux downloads. Then the Linux download should get rid of the /etc conf file. Next the .exe files should vanish. And the executable binaries should be executable on Linux without manual adjustment. Issues with finding libraries, "distribution home directory", the shared object file, should all be fixed. Good examples can be found in the other language compilers for Linux. Oh, and being non-root should cause a single user installation, and being root should cause a system-wide installation. D should not care or restrict choice of install directory. These are all well understood issues with plenty of examples, howtos and other documentation around. Not having fixed these does give the language a home-made feel right from the outset. And to a user, this in itself implies other than longevity and huge potential.I agree with you, but my expertise on Linux is minimal. If you can provide a step-by-step guide for me to implement this stuff, I can get it done.
Oct 24 2005
Here are a few things I can think of off the top of my head: 1. hard-code /usr/include/d and /usr/local/include/d in to DMD's search path; this way we can just copy the relevant stuff there and be done with it. 2. It would be a good idea to just drop the config file, and go with environment variables for configuration. 3. I believe, if nothing else than for unofficial community standards compliance, that we should drop the -op and -of options, have dmd respect paths like everything else, and reimplement -o. What does everyone think? "Walter Bright" <newshound digitalmars.com> wrote in message news:djjeu3$1g0k$1 digitaldaemon.com..."Georg Wrede" <georg.wrede nospam.org> wrote in message news:435D0D24.5020608 nospam.org...The first thing we might do is to separate the Windows and Linux downloads. Then the Linux download should get rid of the /etc conf file. Next the .exe files should vanish. And the executable binaries should be executable on Linux without manual adjustment. Issues with finding libraries, "distribution home directory", the shared object file, should all be fixed. Good examples can be found in the other language compilers for Linux. Oh, and being non-root should cause a single user installation, and being root should cause a system-wide installation. D should not care or restrict choice of install directory. These are all well understood issues with plenty of examples, howtos and other documentation around. Not having fixed these does give the language a home-made feel right from the outset. And to a user, this in itself implies other than longevity and huge potential.I agree with you, but my expertise on Linux is minimal. If you can provide a step-by-step guide for me to implement this stuff, I can get it done.
Oct 24 2005
What about us schmucks that can't wright to /usr/include/d and /usr/local/include/d? I run dmd on a system for which I have only basic user privileges. If you are going to tweak things how about make it easier for us little pawns.1. hard-code /usr/include/d and /usr/local/include/d in to DMD's search path; this way we can just copy the relevant stuff there and be done with it.
Oct 24 2005
Noone's saying you *have* to, just that since many do, it should be automatically planned for; if you can't, then set up your own directory, modify your environment, and you're all set. "BCS" <BCS_member pathlink.com> wrote in message news:djjjes$1jo6$1 digitaldaemon.com...What about us schmucks that can't wright to /usr/include/d and /usr/local/include/d? I run dmd on a system for which I have only basic user privileges. If you are going to tweak things how about make it easier for us little pawns.1. hard-code /usr/include/d and /usr/local/include/d in to DMD's search path; this way we can just copy the relevant stuff there and be done with it.
Oct 24 2005
That's more or less what I am doing. But it just seems like sutch a kluge. I'm hopeing someone can come up with a better solution. In article <djjkjs$1kgf$1 digitaldaemon.com>, Ameer Armaly says...Noone's saying you *have* to, just that since many do, it should be automatically planned for; if you can't, then set up your own directory, modify your environment, and you're all set. "BCS" <BCS_member pathlink.com> wrote in message news:djjjes$1jo6$1 digitaldaemon.com...What about us schmucks that can't wright to /usr/include/d and /usr/local/include/d? I run dmd on a system for which I have only basic user privileges. If you are going to tweak things how about make it easier for us little pawns.1. hard-code /usr/include/d and /usr/local/include/d in to DMD's search path; this way we can just copy the relevant stuff there and be done with it.
Oct 25 2005
On Tue, 25 Oct 2005 19:14:47 +0200, BCS <BCS_member pathlink.com> wrote:That's more or less what I am doing. But it just seems like sutch a kluge. I'm hopeing someone can come up with a better solution.This is exacly as everything else work in linux. Ever tried run gcc instaled under ~/ - it's the same. -- Dawid Ciężarkiewicz
Oct 26 2005
On Mon, 24 Oct 2005 21:41:26 +0200, Walter Bright <newshound digitalmars.com> wrote:"Georg Wrede" <georg.wrede nospam.org> wrote in message news:435D0D24.5020608 nospam.org...The first thing we might do is to separate the Windows and Linux downloads. Then the Linux download should get rid of the /etc conf file. Next the .exe files should vanish. And the executable binaries should be executable on Linux without manual adjustment. Issues with finding libraries, "distribution home directory", the shared object file, should all be fixed. Good examples can be found in the other language compilers for Linux. Oh, and being non-root should cause a single user installation, and being root should cause a system-wide installation. D should not care or restrict choice of install directory.IMO current DMD integration with linux is quite good. It is packager problem to make everything intalled well - so *.exe files are only wasted bandwidth problem (but if this wouldn't be a maintenance problem - should be splited of course). I have prepared myself packaged version of DMD for ArchLinux and I haven't had much problems - still it was different than "native" linux apps. What I miss is some "Makefile" that would make simple user life easier if his distro does not have dmd packaged. Ameer Armaly proposed things that I generaly agree (and are easy to do IMHO), and would make dmd looks more like standard unix compiler. Oh. And recognition of "dmd --help" and "dmd -h" would be trivial to add but unixuserfriendly. If the "/etc/dmd.conf" file removal is problem, then good resolution would be checking for "$HOME/.dmdrc" (or something like this - only leading dot is important) and unless it exists for global "/etc/dmd.conf". Everything of these are little things that make life nicer and most propably may give good impresion on Linux Zealots which are good to have on D (our) side. Regards, -- Dawid CiężarkiewiczThese are all well understood issues with plenty of examples, howtos and other documentation around. Not having fixed these does give the language a home-made feel right from the outset. And to a user, this in itself implies other than longevity and huge potential.I agree with you, but my expertise on Linux is minimal. If you can provide a step-by-step guide for me to implement this stuff, I can get it done.
Oct 26 2005