D related reddit link
http://www.reddit.com/r/linux/comments/akkj2/dread_moon_linux_andromeda_release/ Support if you wish. - Clay
Re: D+Ubuntu+SDL_image said undefined reference
alisue wrote: Trass3r Wrote: Michael P. schrieb: How come you are not using something like rebuild or DSSS? don't forget xfBuild ;) Well... Because I haven't heard about them. I knew 'rebuild' and 'DSSS' but I thought it might be too old (For Mac OS X 10.4 I use Mac OS X 10.6 and Most of time when I try to use package for Mac OS X 10.4 they doesn't take a effort) So I just decide to use Ant(for now using Makefile but in future) and build all of .d file in src directory and manually link to lib. I knew it stupid but could't find the way. What is the best way to do it. Is DSSS not too old? or xfBuild P.S. Well... Where can I find some tutorial things? I found some but too old and can't compile. P.S. Derelict... seem good I'll try. The easier D build system I've found is CDC, its simple and probably the most portable as well. http://www.dsource.org/projects/cdc dsource.org/projects/derelict There is also Dreadmoon.com, which provides a full linux distro suited for D ;)
D piggyback style - is popularity really what D wants? If so...
Disclaimer: Within a finite amount of time, I wrote this quickly, fully explaining the finer details would take a lonnng time ;) Concise Summary: D language popularity can increase dramatically if: * C++ support is improved * D is ported to .Net * D is ported to JVM * Driver-run grassroots marketing campaign (kind of like intelligent spam or context-sensative ads, where the driver is the central machine that tells where to advertise and when and how, etc, and people would post on different sites. The driver machine could be a community member who organizes this campaign on a wiki, and D citizens could carry out the deed.) Long post: Maybe this is just stating the obvious, but if popularity is really what D wants then features are not the choke point or problem with D adoption, I see the choke points as * How well does this language interact with others? * How stable is this language ? I think the D language can make great strides by riding piggy back on * .NET MSIL (Doesn't exist?) * JVM (Doesn't exist?) * C++ (D 2.0 implementing this somewhat) * C (already done) The fact is that no one wants to re-invent the wheel, I would never have used D if not for the fact that it can ride on C's progress. Similarly, it is very feasible to have D run on top of C++, MSIL, and JVM. Great progress have been made in both the .NET and Java libraries, and I suspect D or a similar language would do well there. D wouldn't do as well on .NET as Java perhaps because C# is already halfway decent, but it would increase D adoption anyways. D on JVM on the other hand, if it's possible then I think it can be a big hit. You can say there are fundamental philosophical differences between JVM and D, but I see it as a way to increase D adoption. Then suggest move to mainline D when speed is a greater concern. Now, I'm not the one to do this work anytime soon, but perhaps it is a good idea to remind others. I think language adoption comes from 1. How well the language interacts with existing technologies (Only can interact with C and C++ with a lot of effort, no MSIL or Java interaction) 2. How useful the language itself it (D is already incredibly useful) 3. Language stability (Rapid growth is a good start, however without stability its like trying to build a building on a fault-line ) 4. Massive marketing machine (D's actually doing decent in this) Looking at these points it becomes obvious why languages are successful. Interpreted languages have gotten away with not requiring too much compatibility because of their nature, and C# and Java are decent products with a good amount of hype behind them. C had AT&T and was actually useful, and C++ became popular on the sole fact that it extended C. Now we have D, which talks to C and therefore the next "C". D can also be the next "C++", "Java", and "C#" if D can have direct access to these languages libraries. - Clay
Re: static foreach is deferred
Andrei Alexandrescu wrote: Bill Baxter wrote: On Wed, Nov 18, 2009 at 5:15 PM, Andrei Alexandrescu wrote: Walter and I agreed that static foreach, although present in TDPL, poses enough new problems to warrant its deferral to post-D2. Andrei Is it trouble with scopes and hygenic variable naming? Yah. I know we all think it's an interesting path to pursue, but we'd rather do a good design instead of hastily planting something we'll be sorry about later. Andrei If this is the reason, thanks for prioritizing good design over feature creep. : )
Re: Developing a browser (Firefox) extension with D
Nick Sabalausky wrote: "Justin Johansson" wrote in message news:hdvrmr$215...@digitalmars.com... I'm just wondering for a moment if D might be a good vehicle for developing a browser extension for Firefox, or any other browser for that matter. Has anyone either considered doing, or has actually done, any browser extension development with D and have some thoughts or experience to share? Thanks for all feedback, Justin Johansson I thought FF extensions were JS-only, is that not the case? https://developer.mozilla.org/En/Creating_Custom_Firefox_Extensions_with_the_Mozilla_Build_System C/C++ works, I imagine D could with some effort.
Re: How about Go's... error on unused imports?
Bill Baxter wrote: On Fri, Nov 13, 2009 at 11:15 AM, Clay Smith wrote: bearophile wrote: Clay Smith: I would like my all.d files to not give errors :o< "all.d" files are a hack used to patch one of the minor holes of the current D module system. The right way to do that is with a syntax like (that must not import the 'foo' name too in the current namespace, only the names inside "std.foo"): import std.foo: *; Every part of a language needs to be designed with care. Approximate designs with several holes aren't enough. Bye, bearophile That would be a nice feature. It would be a convenient feature, but in both Java and Python where they have this feature, its use is frowned upon. --bb I don't understand why its frowned upon, if you really want to see what you are importing then look at the folder where the import is coming from.
Re: How about Go's... error on unused imports?
bearophile wrote: Clay Smith: I would like my all.d files to not give errors :o< "all.d" files are a hack used to patch one of the minor holes of the current D module system. The right way to do that is with a syntax like (that must not import the 'foo' name too in the current namespace, only the names inside "std.foo"): import std.foo: *; Every part of a language needs to be designed with care. Approximate designs with several holes aren't enough. Bye, bearophile That would be a nice feature.
Re: How about Go's... error on unused imports?
Bill Baxter wrote: On Fri, Nov 13, 2009 at 10:23 AM, Clay Smith wrote: Clay Smith wrote: Bill Baxter wrote: On Fri, Nov 13, 2009 at 9:51 AM, Clay Smith wrote: Leandro Lucarella wrote: I'm sorry to bring up another "How about Go's ..." topic, but I think this feature is very in sync with D and it should be really easy to implement. Go issues an error if you have an import that's never used, to avoid unnecessary dependencies. Do you see any reasons not to do that? I think it happens very often to stop using some import and never notice it. No, this is a job to be left to the IDE, not compiler. Well, just a small argument for the contrary, but you may be importing some module precisely for the purpose of getting its module constructors to run. For instance the module constructor may have a call like RegisterComponent(thisModule) in it. Think of a set of image format loaders that register themselves with the main ImageLoader module. Then you call ImageLoader.load(filename). Nowhere in your code do you care if it is a PNG or not. You only need to use the ImageLoader's API. Also there's public imports. And all.d type modules with nothing but pubilic imports. There's no way an IDE can know about those intents. So that argues that there should be a way in the language to indicate "i know it doesn't look like I'm using this, but I am". And if that's in the language then the compiler might as well do the checking, too. Ok, not a super strong argument... unless D changed to compile things the way Go does, rolling in all deps. How about that one from Go? Including all deps in an obj. Could D use the same trick to speed up compilation further? --bb I'm not really understanding what you are saying, It's not that complicated. Maybe try reading it again. And forget about the example of why you might want to import something without using it, just trust that there are legit cases where you might want to. ok but I see no need for the compiler to error on unused import. If anything, the compiler can just ignore it, or have a flag to find unused imports. I would like my all.d files to not give errors :o Actually, I agree that the compiler should not error unused *public* imports. That really would not make any sense. True Plus copy/paste imports from other modules, without compile error :o Why do you want to paste in a bunch of unused imports? Wouldn't you like to know which ones you use and which you don't, and trim the fat? --bb If I want to save time, and I'm developing a module similar to an existing one, copying/pasting imports is 90% accurate and saves me time, which is invaluable.
Re: How about Go's... error on unused imports?
Bill Baxter wrote: On Fri, Nov 13, 2009 at 9:51 AM, Clay Smith wrote: Leandro Lucarella wrote: I'm sorry to bring up another "How about Go's ..." topic, but I think this feature is very in sync with D and it should be really easy to implement. Go issues an error if you have an import that's never used, to avoid unnecessary dependencies. Do you see any reasons not to do that? I think it happens very often to stop using some import and never notice it. No, this is a job to be left to the IDE, not compiler. Well, just a small argument for the contrary, but you may be importing some module precisely for the purpose of getting its module constructors to run. For instance the module constructor may have a call like RegisterComponent(thisModule) in it. Think of a set of image format loaders that register themselves with the main ImageLoader module. Then you call ImageLoader.load(filename). Nowhere in your code do you care if it is a PNG or not. You only need to use the ImageLoader's API. Also there's public imports. And all.d type modules with nothing but pubilic imports. There's no way an IDE can know about those intents. So that argues that there should be a way in the language to indicate "i know it doesn't look like I'm using this, but I am". And if that's in the language then the compiler might as well do the checking, too. Ok, not a super strong argument... unless D changed to compile things the way Go does, rolling in all deps. How about that one from Go? Including all deps in an obj. Could D use the same trick to speed up compilation further? --bb I'm not really understanding what you are saying, but I see no need for the compiler to error on unused import. If anything, the compiler can just ignore it, or have a flag to find unused imports. I would like my all.d files to not give errors :o
Re: How about Go's... error on unused imports?
Clay Smith wrote: Bill Baxter wrote: On Fri, Nov 13, 2009 at 9:51 AM, Clay Smith wrote: Leandro Lucarella wrote: I'm sorry to bring up another "How about Go's ..." topic, but I think this feature is very in sync with D and it should be really easy to implement. Go issues an error if you have an import that's never used, to avoid unnecessary dependencies. Do you see any reasons not to do that? I think it happens very often to stop using some import and never notice it. No, this is a job to be left to the IDE, not compiler. Well, just a small argument for the contrary, but you may be importing some module precisely for the purpose of getting its module constructors to run. For instance the module constructor may have a call like RegisterComponent(thisModule) in it. Think of a set of image format loaders that register themselves with the main ImageLoader module. Then you call ImageLoader.load(filename). Nowhere in your code do you care if it is a PNG or not. You only need to use the ImageLoader's API. Also there's public imports. And all.d type modules with nothing but pubilic imports. There's no way an IDE can know about those intents. So that argues that there should be a way in the language to indicate "i know it doesn't look like I'm using this, but I am". And if that's in the language then the compiler might as well do the checking, too. Ok, not a super strong argument... unless D changed to compile things the way Go does, rolling in all deps. How about that one from Go? Including all deps in an obj. Could D use the same trick to speed up compilation further? --bb I'm not really understanding what you are saying, but I see no need for the compiler to error on unused import. If anything, the compiler can just ignore it, or have a flag to find unused imports. I would like my all.d files to not give errors :o Plus copy/paste imports from other modules, without compile error :o
Re: How about Go's... error on unused imports?
Leandro Lucarella wrote: I'm sorry to bring up another "How about Go's ..." topic, but I think this feature is very in sync with D and it should be really easy to implement. Go issues an error if you have an import that's never used, to avoid unnecessary dependencies. Do you see any reasons not to do that? I think it happens very often to stop using some import and never notice it. No, this is a job to be left to the IDE, not compiler.
Re: CPAN for D
Bill Baxter wrote: On Tue, Nov 10, 2009 at 3:08 PM, Walter Bright wrote: http://www.reddit.com/r/programming/comments/a2nfz/guido_people_want_cpan/ http://search.cpan.org/ Over and over, I hear that CPAN is one of the great reasons people use Java. Such for D would be a tremendous boost to the D community. CPAN is so bad that people run away from Perl in horror over to comfortable but boring old Java? :-P DSSS was supposed to be a sort of CPAN for D. I think it's still the easiest way to get the Derelict library installed. Unfortunately it's really only a very humble start. It lacks any sort of versioning, and has no web face. And now it's unmaintained. --bb It would be great if there could be a new DSSS maintainer, or someone to fix DSSS. Then I'd imagine a site like dsource.org could easily add CPAN like functionality, however it would need to make sure to only search for completed / near completed projects.
Re: Introducing Myself
Travis Boucher wrote: I guess I should introduce myself. Hi, I'm Travis, and I am a code-a-holic and general purpose unix geek. I heard about D a long time ago, but never took a good look at it. A few weeks ago a friend of mine suggested I look at D when I was brushing up on some more advanced uses of C++ (I was mostly brushing up on STL and template usage in general). I love studying different programming languages, semantics, syntax and implementation. I also love some of the different paradigms, and seeing how they work. Now I am not some coding expert, I wouldn't even call myself a good programmer. I can get stuff done when I need, but its usually messy, ugly, "works for me", "code is meant to be run, not read (ie. PERL)" sort of crap. The one thing that frustrates me about the direction of programming in general is how high level and bloated it is getting, and how alot of programmers I have come across are fine with that. Abstraction upon abstraction upon abstraction, turning something as simple as 1 + 1 into an operation that goes through layers upon layers of code until the machine finally says "2", then back up the abstraction chain until you get a value that may or may not be 2. Turning a 1 tick operation of 2-4 bytes into a 100+ tick operation of 100+ bytes. (ok, I may be exaggerating a bit on the numbers but you get the point). Don't get me wrong, I love a language that allows me to make 1 + 1 = 3 if I want it to, but I don't think it should require massive amounts of memory or CPU time to do it. In comes D. D lets me code like I am coding in a scripting language, but executes like I am coding in C/C++. It has taken the best parts of all languages and put them into one pretty package. Ok, the implementations are still less mature then I'd like, but they are getting better. The language lets me ignore issues I don't care about (like memory management), and moves out of the way on issues I do care about (like memory management). I could go on forever on what I love about D, conditional compiling, delegates, templates (especially the syntax), but most people on this newsgroup probably feel the same. Anyway, since I don't have that many geek friends capable of understanding the merits of D, or sharing my excitement of new features I learn to use, I turn to this newsgroup. A little about me (thats what an introduction is for anyway, isn't it?) I have mostly worked on systems administration tasks. Programming is more of a hobby that has applied uses in systems administration. The past few years I've focused mostly on large scale web clustering, both high transaction and high throughput. Recently I started teaching myself a bit about the 3d world world (no, that double world is not a typo). Learned Blender (and Python by association). Been poking around 3D engines for a few years including Ogre and Irrlicht. Have done a bit with embedded stuff, including micro controllers (just AMR, and mostly in emulators as my hands as not steady enough anymore to do much electronics, too much caffine) and nintendo DS (devkitpro). I use open source software almost exclusively. I have a couple windows boxes around just to keep myself up to date on the new stuff microsoft is doing. I don't do OSX, but I'd love to. I use Linux (mostly ubuntu these days, but started with Slackware back in the 2.0 kernel days), and BSDs (mostly FreeBSD, but OpenBSD and NetBSD a bit as well). I like different architectures, and trying to get a unix of some sort running on them (I have MIPS, ARM, Alpha, Sparc, x86, and x86_64 machines in one form or another). I love learning new things, and D is the most exciting thing I have gotten into the past 5 years. I hope to become part of the community in some way or another. Hello Travis, Welcome aboard the D train. Let's see... dsource.org planet.dsource.org dsource.org/projects/descent dsource.org/projects/dsss http://wiki.team0xf.com/index.php?n=Tools.XfBuild http://dsource.org/projects/ldc http://dsource.org/projects/tango Hope these links can make you more productive with D. Good luck, other D friends are sure to give you advice as well.
Re: At a crossroad
Sjoerd van Leent wrote: Lately, I've been tuning in to the development of D again. But what I see is rather disturbing. There is a new continuation of the old D, in the newer D2. Personally, I think this is good, as long as there will be a defined end to D2. What disturbs me more, is that there appears to be no coherent development. There are all nice ideas, but it appears that one project dies after the other. I see a number of problems, which keep D from growing up. There appears to be a lack of understanding about whom are going to use the language. D is targeted at the niche of C and C++. Next to D, there are .NET and Java. These are all competitors. Other popular languages, such as Python and Ruby, though being non-system languages, have their share as well. As I look at it, I come to some essential conclusions: All of these environments have a stable language, and on top of that, ONE single main library. With C++ this is STL/IOStream, with .NET and Java it's their respective libraries. Similar for Python and Ruby. With D however, there are at least 2 main libraries (Phobos and Tango), whereof Tango doesn't support D2. It is unacceptable for the target audience to find this situation. Tools can't interoperate, libraries can't interoperate, etc. There are a lot of ideas for nice tools. But the essential base is missing. For large projects there is the need for a decent IDE and the need for dynamic linking. Although attempts are made, it all appears to stall. There is barely any usable main-purpose library. As D2 will be finished hopefully not to long from now, especially the specification, I would really request to start thinking about how to continue. D is a nice language, with great opportunity. But without management, even when it is nice, it will fail. I would like to ask everyone interested in getting D up and running for main-stream purposes, to sit together and think about solutions. Anyway, I hope I'm not putting too much poison into the newsgroup, but I really needed to say this. I think the major issue with D is the total lack of funding, and by this I mean - Not enough people out there are making money using the D language - No funding from any large open source groups Until more people learn how to get income programming in D and there are job posts asking for D experience, D is destined to be a hobby language only. - Clay
Re: Metaprogramming in D
Walter Bright wrote: This is a talk I gave last January for the NWCPP: http://www.vimeo.com/4333802 http://www.reddit.com/r/programming/comments/8fymt/walter_bright_explains_metaprogramming_in_the_d/ Cool video : )
Re: Anyone want to maintain Planet D?
Anders Bergh wrote: Hi, I need someone to take over Planet D because I don't have time for maintaining it. I use Planet Planet to generate static HTML which is uploaded to dsource, so there's no web hosting involved. All it needs to work is Python, cron and ncftp. Adding new feeds is very simple, it's just a regular INI file. What's the work required to maintain it? Do you have to run a job about every day or so to update the feeds? Is this why the feeds have stopped updating?
Re: htod not support stlport stuff good enough
davidl wrote:
err, I tried a little bit with htod seems it always bug me with error
messages. any idea?
void operator delete(void* ptr, const std::nothrow_t&) throw();
^
d:\digitalmars\dm\include\../include/new.h(77) : Error: must be void
operator delete(void * [,size_t]);
void operator delete[](void* ptr, const std::nothrow_t&) throw();
^
d:\digitalmars\dm\include\../include/new.h(83) : Error: must be void
operator delete[](void * [,size_t]);
class nothrow_t {};
after tweaking it a bit for a while, i find the trick to bypass this error:
htod myfile.h -Iblah -D__NEW_H
htod also need the -I stuff, it actually should get the sc.ini value
^
# Declarations with C++ linkage cannot be converted. A C interface must
be made for any C++ code.
http://www.digitalmars.com/d/2.0/htod.html Limitations
Re: D, so it happend...
Baas wrote:
In the past 10 motnhs, I completly rewrote the D Compiler in C#!
Motivations:
- LOVE THE D LANGUAGE!!
- To be fully able to develop in a VS.NET like environment using D, with no
limmitations.
Cons:
- Requires Windows platforms (XP and above).
- Requires P4+ CPU.
- 2-4 times slower compiler (still need to be optimized).
- No "_Identifier" allowed! (I hate that _ s##t!)
- Removed "auto" types.
- Removed some data types.
- No documentation available :(
Pros:
- Faster overall application execution speed.
- Tested against existing benchmarks.
- Implemented full debug functionality.
- No more creapy asm stuff.
- View/Modify ALL datatypes without any limitations or hassles.
- Complete 128 bit ints/reals
- Added Custom 256 bit ints/reals. (...who's gonna use it anyway?)
- Dynamic keywords:
- For example:
- Can rename "else if" to ElseIf etc.
- Can rename "{}" code block indicators to Begin/End etc.
- Remain compatible with any older/newer "keyword set".
- Can basically change keywords to adopt your style.
- Includes "event handler" functionality
- Includes dynamic binary modules (.ddbm)
- Can automaticaly optimize itself on a target environment.
- Can restructure its own code pattern (32/64/Multi-CPU)
- Can physically relocate itself.
- Can defrag itself in memory/disk.
- Magnitudes faster then normal DLLs.
- Can bind/execute across networks.
- Can be initiated from a remote machine.
- Includes full security features.
- Includes pre-set configuration templates:
- Custom Mode
- Console Mode (exe)
- Windows Mode (exe)
- GL Mode (exe)
- Library Mode (dll)
- Dynamic Binary Module Mode (ddbm)
- Windows Service Mode (exe)
- Device Driver Mode (drv/sys)
- Includes Code Convertion Utility (from C# to D).
Tech info:
- Parse the code into XML using Regular Expressions.
- More code optimization is now possible.
- Replaced the backend with HLA.
- Code > HLA > OBJ > EXE/DLL
- Removed GC, ...don't need it.
- Variables allocate/deallocate themselfs.
- Manual allocation/deallocation still possible.
- Package/Module now require code block indicators
- package somepackage.somewhere
{
module somemodule
{
module deep.beneath
{
}
}
module another.module
{
}
}
- More than one module per file is now possible.
- Added inline HLA
- Can now use asm{} or hla{}
- Changed property syntax (similar to C#)
- int something
{
get { return somevariable; }
set { somevariable = value; }
}
- Renamed "mixin" to "macro"
- Removed "imaginary" and "complex" types.
- Changed/Added Types
* ubyte > byte
* byte > sbyte
* char > compiler options determine which type to use (1/2/4 bytes)
* short > short/int16
* ushort > ushort/uint16
* int > int/int32
* uint > uint/uint32
* long > long/int63
* ulong > ulong/uint64
* float > float/single/real32
* double > double/real64
+ int128/decimal
+ uint128/udecimal
+ int256
+ uint256
+ real128
+ real256
+ string > compiler options determine which type to use (1/2 bytes)
+ date/time/datetime
In Progress:
- "native" .NET framework.
Plan for the Future:
- "VS.NET-like" IDE.
- "true" Generic functionality.
Sorry...
NO CODE OR BINARIES INCLUDED WITH THIS MESSAGE! (yet)
Baas
Technically cool, but I'm not sure it can be considered 'D' if you won't
be able to compile D 1.0 code with it. Sounds like a language fork.
Re: State of Play
Ary Borenszweig wrote: Daniel Keep wrote: ValeriM wrote: Ary Borenszweig Wrote: Mike James escribi�: What is the state of play with D1.0 vs. D2.0? Is D1.0 a dead-end and D2.0 should be used for future projects? Is D2.0 stable enough for use at the present? Is Tango for D2.0 at a level of D1.0 and can be used now? Is DWT ready for D2.0 now? Regards, mike. I don't know why a lot of people see D1.0 as a dead-end. It's a stable language. It won't get new features. It won't change. It'll probably receive bug fixes. It works. It gets the job done. You can use it and be sure than in a time all of what you did will still be compatible with "newer" versions of D1. No. It's not stable. Try to build last Tango and DWT releases with D1.041 and you will get the problems. "It's a stable language." Note the use of the word "language." What you're referring to are bugs in the compiler. It happens. -- Daniel But ValieriM has a point. If I code, say, a library in D 1.041 only to find out that in a couple of months it won't compile anymore in D 1.045, that's not good at all. That's when someone sends a message to the newsgroups saying "I just downloaded library Foo, but it won't compile with D 1.045... is it abandoned? Why isn't it maintained? D1 is broken". The point is, you shouldn't need to maintain libraries for D1 anymore. Maybe the test suite for D1 should be bigger to cover more cases... You should be using the compiler that comes bundled with Tango, perhaps.
Re: State of Play
Mike James wrote: What is the state of play with D1.0 vs. D2.0? Is D1.0 a dead-end and D2.0 should be used for future projects? Is D2.0 stable enough for use at the present? Is Tango for D2.0 at a level of D1.0 and can be used now? Is DWT ready for D2.0 now? Regards, mike. Use DMD 1.0 if you want a stable language that works. Use DMD 2.0 if you don't potentially changing your code with every compiler release, and don't need to use that many libraries.
Re: Can't get Tango to work on WinXP, with DMD
Jaba Adams wrote: Is Tango known to work with DMD 1.041, on WinXP? I can't seem to get it working with either "dsss net build tango", or by downloading a binary package, and following the instructions here: http://www.dsource.org/projects/tango/wiki/WindowsInstall If I build from source, with dsss net build tango, it eventually kacks with missing files (Exception.d). With the binary approach, when I go to build my app, I get link errors, like: Error 42: Symbol Undefined _D5tango4core9Exception11IOException5_ctorMFAaZC5tango4core9Exception11IOException I'm interested in putting together a "D Box" for PC + OS X, similar to Peter Seibel's LispBox concept (http://www.gigamonkeys.com/book/lispbox/) D itself works fine (both dmd, and gdc). The problem is that my "minimum interesting configuration" is DMD+tango+derelict or GDC+tango+derelict. It would be a great benefit if new, curious users could get up and running with these modules in one click, in less than an hour. My advice would be to grab the stable Tango version... 1) Grab http://downloads.dsource.org/projects/tango/0.99.7/tango-0.99.7-bin-win32-dmd.1.033.zip 2) Extract to desktop 3) Open folder, copy paste bin/ example/ etc/ folders into your C:\dmd path (or whichever path you choose) Do you really need to use version 1.041 compiler? ~ Clay
Re: Is DSSS still being developed?
BCS wrote: Hello Trass3r, Bill Baxter schrieb: Gregor said he got busy with grad school, so basically nothing is happening with it. Maybe when summer break time rolls around? But I'm not holding my breath. Why does every good D project get more or less abandoned? :( Because D is a young man thing. "Young" as in about to dive into school/job/having wife & kids/whatever. We start a project and then real life kicks in. Fully agree, 100%. This will be true until D becomes more viable in the commercial scene.
Re: People speaketh
Andrei Alexandrescu wrote: first/last - 13: Jarrett, Bill, dsimcha, Sandeep, Chad, Tiago, Robert, Simen, Brian, Bill, Yigal, Gide, Ary. head/toe - 9: Bill, dsimcha, Robert, Simen, Max, Don, Michel, Denis, Brian, front/back - 15: dsimcha, Chad, Steve, Robert, Nick, BCS, Bill, BLS, Yigal, Daniel, Max, Don, Gide, Brian, Andrei. head/last - 7: John, Chad, Sean, Nick, Yigal, Kazuhiro, Max. There were other choices that were not as popular as the ones above, please don't be angry I didn't mention them all. This vote was rather informal so I allowed myself to do a tally without having specified a deadline etc. So I'm not sure how much this all counts... should we just settle for front and back? Andrei I think head/toe is pretty neat, otherwise first/last. ~ Clay
Re: dsource considered harmful
Martin Carney wrote: Visiting dsource I'm disappointed by the large number of half-finished and not-started projects on the projects page. I pick on interesting project and look at the source tree - no files or years out of date. I think the unfinished, out-of-date and not-started projects should be moved to their own page - lets see the wood for the trees... mc I think there needs to be a feature so the project mods can mark their project as active or inactive. Those mods who aren't around, should be labeled as Potentially Inactive. Then they can be sorted by status, and no projects would appear inactive unless the project author specified. ~ Clay
