Re: Incubated modules for Phobos
Piotr Szturmaj Wrote: Hi all, Normal Phobos submission procedure is usually like that: 1. write entire module from scratch by oneself 2. submit for voting 3. rewrite wrong parts, if there are none then add it to Phobos 4. otherwise goto 2 It is hard for one person to write entire module in such way it satisfies everyone, especially for very new or complex additions, such as database handling or cryptography. Here, I propose that we add experimental exp hierarchy to Phobos for such projects. I know etc hierarchy may me used for that but IMHO separate exp would be more appropriate. In this namespace beta modules will slowly evolve into official std modules. Some (obvious) advantages are: * developers may receive feedback very early in the process, saving them from mass rewrites when in the opinion of community they made some wrong coding decission. * developers may receive coding help, i.e. many of them may collaborate on one big module. * users may test experimental modules early. This is important, because usability issues may be catched earlier, not after submission when API usually becomes frozen and it is too late. Exp code may be shipped with each release just like etc code. Users using experimental code should be aware of breaking changes that may be introduced with each release or even with each commit. Thoughts? I like it. More people will keep an eye on new versions for new modules that are coming in. And if one wants to write new module for his needs, it can easily check exp to see is he reinventing wheel. (exmple. my suggestion here few days back to upgrade std.process only to find there is upgraded module - if I didn't ask on this NG I would never know there is that module). So exp sounds good.
Re: 64-bit DMD for windows?
Trass3r Wrote: DOS software can be more productive, since it's often keyboard-only. How is that different from a Windows console app? No Solitare, Facebook... much more productive!
Re: Program size, linking matter, and static this()
Andrei Alexandrescu Wrote: On 12/16/11 3:38 PM, Trass3r wrote: A related issue is phobos being an intermodule dependency monster. A simple hello world pulls in almost 30 modules! And std.stdio is supposed to be just a simple wrapper around C FILE. In fact it doesn't (after yesterday's commit). The std code in hello, world is a minuscule 3KB. The rest of 218KB is druntime. Once we solve the static constructor issue, function-level linking should take care of pulling only the minimum needed. One interesting fact is that a lot of issues that I tended to take non-critically (templates cause bloat, intermodule dependencies cause bloat, static linking creates large programs) looked a whole lot differently when I looked closer at causes and effects. Andrei http://wiki.freepascal.org/Size_Matters Otherwise a great language that never did manage to remove bloated factor from its name. Many people stopped using it because of that, including me. I guess people do not like bloat when programming systems stuff.
Re: D1 to be discontinued on December 31, 2012
Forum/Registered Users, Unless you are regularly cleaning out inactives this number means nothing about a current userbase. Purpose is not evaluating size of community but to be able to keep in touch with it. pool/email pool? Are people emailing that I havent heard of. I am on a quite a few mailing lists I cant remove myself from due to lost passwords, or just a lack of caring. Any decent forum has unsubscribe link in each email it sends. Password is not required. Alot of times I just feed them to my spam filter and they stop showing up anymore. I am still a registered user though. This number means nothing. Interesting. Answering on email pool would be too much effort. Writing comment on newsgroup isn't. Anyways, D community can't really speak its mind here. Here it is 5-10 regular users that are persistent enough to dig trough loads of mixed information, some important, most of it not, on this NG. Most users have no time to check this place every other day so they can say 'please, don't discontinue D1, I am using it' or anything like that when important matter arises. Sending question to users is more correct way to obtain opinions than to wait people to stumble on this thread here. It won't happen for most D users. Ever.
Re: D1 to be discontinued on December 31, 2012
Jesse Phillips Wrote: On Wed, 14 Dec 2011 10:46:18 +0100 Gour g...@atmarama.net wrote: Can you give me a list of some successful open-source projects written in D1 and/or some proprietary ones? http://store.steampowered.com/app/18600/?snr=1_200_200_254_13 http://en.wikipedia.org/wiki/ABA_Games http://blissradius.com/
Re: D1 to be discontinued on December 31, 2012
Walter Bright Wrote: On 12/12/2011 10:26 PM, Jesse Phillips wrote: On Sun, 11 Dec 2011 22:57:02 +, Jesse Phillips wrote: I haven't used D1 for a long time so I can't claim a bad choice here. Actually I think I can state an opinion here. The two things that stand out in my mind are. * There has been a statement of supporting D1 while it is in use (or at least has a decent number of users). Maybe there aren't any, I don't see replies claiming such. There don't seem to be many anymore. I'm decent, and I'm user of D1, still got some legacy code to maintain. Discontinuing it is not a problem for me as it is bundled with 2 year old D1 version that checked out for bugs that could matter. Moving all efforts to polishing D2 is the right way.
Re: D1 to be discontinued on December 31, 2012
Walter Bright Wrote: On 12/13/2011 12:52 PM, Jacob Carlborg wrote: On 2011-12-13 19:55, Walter Bright wrote: On 12/13/2011 9:47 AM, Jacob Carlborg wrote: If I recall correctly Walter has said he will continue to support D1 as long as there are users. Yes, I did say that. For some time now, I've been releasing D1 betas and have not received any response to them. I haven't noticed new bug reports for D1. I haven't seen posts here about D1. I announced the D1 1.072 release a few days ago, and there wasn't a single comment on it. Yeah, I noticed that. I'm still using D1. I usually don't have time to try all beta versions or releases for that matter. Your making solid improvements in every release and I'm grateful for that. I apologize if I haven't shown any gratitude. It's not really about gratitude, but just letting me know that there's a point to doing those releases. broken_record suggestion Forum, registered users, pool/email pool = feedback :) /suggestion /broken_record
D kicks ass.
Sorry, but it's true. Compared to C++, it has much friendlier syntax, important built in types and all the goodies. And let us not forget - big standard library ready to go. But it is still rough on the edges, needs polishing and fixing little bugs. Now it needs tender care to grow big (and lose some weight from executables :).
Re: D kicks ass.
Trass3r Wrote: Am 12.12.2011, 19:21 Uhr, schrieb Bane branimir.milosavlje...@gmail.com: Sorry, but it's true. Compared to C++, it has much friendlier syntax, important built in types and all the goodies. And let us not forget - big standard library ready to go. But it is still rough on the edges, needs polishing and fixing little bugs. Now it needs tender care to grow big (and lose some weight from executables :). We know :) Well, it is a nice to reinspect ones own decision after some time and confirm it was and is totally correct.
Suggestion for std.process upgrade
I have been playing with std.process (D2) lately, and have 2 suggestions and more or less tested code if somebody other than my self have use for it. One is shell() function (not mentioned in the docs, curious), I see it can be made more efficient on Windows. It executes shell command and returns standard output as string. Current implementation do it by piping stdout to temporary file on disk and reading that file back. Using CreateProccess Windows API it can do same job 3 times faster and remove need for temporary files and disk writes. I think that is beneficial gain for some applications. Other is fork-exec implementation eg. starting a program using command line and detaching it from parent, so it continues to run after parent is dead. On Posix it is implemented using fork() and exec() calls, on Windows using CreateProcess. One question. Is std.c.windows.windows lacking for most API definitions or am I looking on wrong place?
Re: D kicks ass.
Trass3r Wrote: Well, it is a nice to reinspect ones own decision after some time and confirm it was and is totally correct. To do that just try going back to C++ ;) Just did. Things lacking: - library - easy to use maps and arrays Things that should lack: - bloody header files and forward declarations - preprocessor perversions - cryptic signs like :: - Things that are easier or more fun: - good compiler support - easy linking with C code - RAII tinkering smaller memory footprint (GC just kills all the fun :(
Re: Suggestion for std.process upgrade
There is a completely revamped version of std.process. It is being held up right now because DMD on windows depends on DMC for it's C runtime, and DMC has issues supporting pipes. I have recently opened a pull request for Walter to merge, I'm going to ping him about it right after 2.057 is released. For more info, see the docs Lars posted here: http://kyllingen.net/code/ltk/doc/process.html Once the DMC issue is fixed, you should see this improvement getting much more attention. It's very low hanging fruit. -Steve Nice piece of work. I am looking forward for it becoming part of Phobos. I find multi-process work interesting alternative to multi-threaded, sometimes more stable and robust solution.
Re: If I had my way
Paulo Pinto Wrote: Actually this could be good idea, it is after all where Objective-C (with ARC) and C++ on Windows (C++/CX) are moving to. But there can be some performance issues nonetheless. I am no GC expert, but I think in most cases the overhead imposed by increment/decrement operations looses against most advanced GC in use today. There is only one way to really settle pro/anti GC discussions, and that is optional compilation with or without gc, refcounting etc. That is only way to get the facts how much does GC slows program down (or not :) I am pro GC definitely for simple reason it increases productivity significantly. But in systems world there will always be significant number of people with doubt in any GC implementation, or just with a desire to do their own memory management. I think that group of people is important and we should do what we can to attract them to D.
Re: If I had my way
so Wrote: On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto pj...@progtools.org wrote: Really? Tell that to all game studios developing games in Java/C#/Flash. Do you know that many games in iPhone are done in Unity, which makes use of C#/Boo/Javascript compiled to native code? I don't understand sorry, are you arguing against the argument i made on GCs failure on some specific areas? Come on kidz, GC does good on some tasks that are not performance critical, it fails on other tasks that are. That is why D has assembler option - for parts you need to be done ultra fast. Same should apply for optional GC. And everyone gets candy :)
Re: If I had my way
Paulo Pinto Wrote: Am 11.12.2011 17:12, schrieb Bane: Paulo Pinto Wrote: But in systems world there will always be significant number of people with doubt in any GC implementation, or just with a desire to do their own memory management. I think that group of people is important and we should do what we can to attract them to D. Those people will eventually become irrelevant. As I mentioned in a previous email, if I want to use a language without GC for systems programming I already have C, C++, Delphi, you name it. Why pick D then? Because people are lazy and hate to learn new language, they will try to do that in one they already know or already like. If D offers them tools to do MMM then they have no need to resort to C,C++ for anything anymore thus it really replaces them
What can be done to reduce executable size?
Short term and long term suggestions ? Anything we can do ? I heard it
is some problem with linking dead code?
import std.stdio;
int main(){
writefln(Hello Bloat!);
return 0;
}
dmd -release -O hello.d
On Windows:
v1.071 = 339 Kb
v2.056 = 1017 Kb
It looks very ugly and might distract some people.
Re: What can be done to reduce executable size?
Mirko Pilger Wrote: On Windows: v1.071 = 339 Kb v2.056 = 1017 Kb v2.057b= 840 kb (upx --best = 151 kb) That is improvement. 2.07 is not released yet ? And I don't think UPX is solution. It makes things look even worse, like too much makeup on ugly chick.
Re: What can be done to reduce executable size?
I am dealing with scenario of large numbers of programs written in D placed on same host/1 installer, when it all sums up size does matters. Is it possible to move phobos or runtime to shared lib ? It would reduces code significantly.
Re: What can be done to reduce executable size?
Is it possible to move phobos or runtime to shared lib ? It would reduces code significantly.
Re: What can be done to reduce executable size?
Trass3r Wrote: Short term and long term suggestions ? Anything we can do ? I heard it is some problem with linking dead code? Well most space is covered by the runtime, TypeInfo and stuff like struct .init data. Use http://thecybershadow.net/d/mapview to get a graphical view of your app. E.g. on Linux it sometimes shows Afterpadding way too large. Yes, I use it, great piece of work.
Re: What can be done to reduce executable size?
Andrej Mitrovic Wrote: Try using the unilink linker: ftp://ftp.styx.cabel.net/pub/UniLink/ Get ulnb0329.zip You have to configure ulink.cfg to this: -zsnn.lib -LC:\dmd\windows\lib -LC:\dm\lib -Go -zkernel32;advapi32;user32;wsock32;shell32;snn.lib -LC:\dmd2\windows\lib -Go Then linking is just: ulink file1.obj file2.obj lib.obj etc.. It is nice tool. Too bad it is still beta proprietary, or am I mistaken ?
Re: A real Forum for D
There might be one more benefit of using forum. Registered users could vote on different topics. I find voting process here on newsgroup very inefficient. Is it possible to make (or find existing implementation), using forum, some kind of automated mail spam to all users, and see the results? It would really show what community wants, how much people are active, what they think ...
Re: A real Forum for D
so Wrote: I think you believe something i would say quite naive, as everyone have the best intentions, as they just fight for what they believe right. Maybe it was the case where we were in caves, it is not now. Everything boils down to one thing IMO, we live in a structure made of with the worst of the intentions. We accumulate power to a single place and every now and then give it to a mad puppet. (never been a decent man had that power, why would a decent man want that kind of power?) They are doing what they were told, destroying everything in their way, and we have to live with its consequences because we are that stupid. They are smart people, far smarter than the mess. They are not racist but they profit from racism. It is not the clash of opinions, it never was, it is just the clash of profit. Actually, I believe this too. It almost always rich wanting to get richer, so they use their political or religious influence (which they have because of their money) to make up some reason people would go to war so they can make more money out of it. They are real psychopaths pulling the strings on human civilization. Its all about money. It was the clash of opinions for dummies like us who just go and die for them.
Re: A real Forum for D
It's not really a matter of either/or imo... I think that everyone will admit that having an 'official' forum would probably boost popularity. A good place to post questions and search the archives EASILY would definitely be a boon. True. Most people have some experiance with forums, much less of them with newsgroups. It would be user friendly and more in (as oposed of old geeks using old software) :) And with registred usernames there would be less/no trolls ?
Re: A real Forum for D
so Wrote: On Sun, 27 Nov 2011 21:08:46 +0200, Bane branimir.milosavlje...@gmail.com wrote: And with registred usernames there would be less/no trolls ? Quite the contrary. After you introduce read/write web interfaces based on popular frameworks, you open doors to new kind of trolls and worse... spams. Since this is a programmer related area, it might be worse. But funny captchas can fix it! And it will be fun :) Mind you, we have zero moderation yet we have almost no spam, no troll. I don't know specifics. Maybe it is the risk worth taking if benefits are that more people will read this.
Re: A real Forum for D
Walter Bright Wrote: On 11/27/2011 11:08 AM, Bane wrote: And with registred usernames there would be less/no trolls ? Required registration is a barrier for people who want to be onetime posters. (And onetime posters often become regular posters!) Yeah, I hate that too. Then anonymous access and FunnyCaptchas(tm) might work?
Re: A real Forum for D
Walter Bright Wrote: On 11/27/2011 2:14 PM, Timon Gehr wrote: How do you create a captcha that reliably discriminates between trolls and non-trolls? You can't. But a nice feature would be the addition of a button that only moderators can see use, that would simply delete the corresponding posting. Moderators can be identified using the same scheme as ssh uses. Yeah, that's the idea, just to make deleting garbage more efficient.
Re: Website message overhaul
Andrei Alexandrescu Wrote: On 11/18/11 1:15 PM, Bane wrote: rant As a language claiming for itself it was created out of practical needs of programmers I must say D fails on that test (both compilers and D website). It is not user friendly. It is user hostile, for simplest and most common tasks. Especially for newbie programmers. It was like that 4 years ago when I first saw it, and it is much like that now. Is that the language, compiler, environment, or website? I got a bit confused. Website problems I think should be sorted out: - D1 vs D2, which to choose, what are differences between them etc. Too unclear and discouraging for a newcomer. - Too much old and unnecessary info. Too much redundant text. I suggest going again from scratch or just start using delete key without restrictions. Just one example: a lot is written about benefits of exception handling vs. C like return values etc. It is practically proven that approach is useful, nobody questions that. There is no need to clutter documentation with articles like that. Things like that should be shelved on some old docs place, not on prime pages. - Generally feeling lets stuff as much info as possible here, and don't delete anything - it may be useful for somebody that just overwhelms first time reader and distracts him. You people should really hire some non-programmers with documenting skill and knack for KISS principle to make D website and documentation. It is obvious that Walter, Andrei and the rest of core people are highly skilled in their field of work, but not interested, available or competent to present D complexity in simple, right-to-the point way. Right now D is pushed forward by volunteer work. Indeed it would be great if more articles and tutorials were available. I paused with D last year after (yet another) unsuccessful attempt to port my code from D1 to D2. reason: shared stuff. More specific reason - is it a bug with my code or docs ain't exact or that feature isn't working yet (even docs claim it works?)? So, I guess problem is correctness of manual for D2. Digging trough this newsletter to find is some feature working and how is terrible way for learning. I guess it is so much more fun to add new features and optimize code than to organize and present all the documentation the way it can be useful. Fun doesn't have a lot to do with it. Well... we wouldn't be here if we don't find programming fun (too). And come on, BUD like feature is first useful thing compilers are lacking. Talking about practical need. /rant Agreed. To add to that, I am a bit worried that the most worked-on build management tool uses D1 and Ruby. It strikes me very bad seeing there are/were more than one project published (bud, dss etc. i might be mistaking) and god knows how many people made their solutions for internal work just to simplify task of compiling multiple files and yet - compilers still lack that feature. A lot of work invested in D tools just rot away because it is not incorporated into core, or ad least mentioned in proper docs Hey guys, compiler don;t has feature Y yet, but here is official tool for that here, use it - just don't reinvent the wheel again. And there goes same with lot of small things. People who want D to succeed should start collecting those fruits and putting them where they can be seen. Thanks, Andrei
Re: Website message overhaul
Peter Alexander Wrote: On 19/11/11 2:02 PM, Bane wrote: I paused with D last year after (yet another) unsuccessful attempt to port my code from D1 to D2. reason: shared stuff. More specific reason - is it a bug with my code or docs ain't exact or that feature isn't working yet (even docs claim it works?)? So, I guess problem is correctness of manual for D2. Digging trough this newsletter to find is some feature working and how is terrible way for learning. I agree with this 100%. It is true that a lot of advertised features in D simply do not work at all, and the fact that they don't work isn't documented anywhere except in the newsgroups. In addition to making it incredibly difficult to learn the language, it also dissuades people from writing tutorials. A couple of times I have started to write tutorials and stopped simply because the stuff I wrote didn't actually work (e.g. I'd write about selective imports, but then figure out that they don't work as advertised). I don't want to write tutorials that are filled with D is awesome, you can do this... except you can't. Things that don't work simply shouldn't be mentioned in the docs. Put them on a Work in progress page or something so that people know what should be working, but don't advertise them as working features until at least one compiler supports them. Yup. Learning D is just too difficult comparing to most other popular languages. My general feeling is that it is sloppy and too great investment for one to get to know its powers mixed with pain-in-the-ass quirks. Delete docs, start from scratch, this time documenting only what is and not what it might become one day. Unfortunately, this can be done only by core people who really know how D ticks, and they are probably occupied with other stuff.
Re: Website message overhaul
Walter Bright Wrote: On 11/19/2011 11:33 AM, Bane wrote: Yup. Learning D is just too difficult comparing to most other popular languages. My general feeling is that it is sloppy and too great investment for one to get to know its powers mixed with pain-in-the-ass quirks. It would be nice to be more specific about what pain points you experienced. Main thing was with threading and shared vars. It was painful experience for me last year, I couldn't manage to migrate code to D2. Lost about a month experimenting and digging trough all documentation. At the end, I didn't had final answer what was wrong - me or docs or some obscure bug i couldn't find in bug tracker. Not finding answer was that pain in the ass. Things might be changed now, but I am not ready to experiment again. So I'm sticking with proven D.1.030 for time being.
Re: Website message overhaul
There is 'D' the language and 'DMD' the implementation. You confuse the two. The quirks you are talking about are DMD's, but the specification is that of D. DMD needs to be fixed, and that is what the 'core people' are working on. I am using dmd compilers just because I believe they are first to implement new features and define standard for language. I might be wrong. BTW, I have never felt much PITA when working with DMD even though I have hit a few bugs. What are the specific quirks you are referring to? D1 is joy for me. It is simple and fairly nicely documented. With it I have no problems. D2 is whole different ball game. Delete docs, start from scratch, this time documenting only what is and not what it might become one day. Unfortunately, this can be done only by core people who really know how D ticks, and they are probably occupied with other stuff. I agree that the specification should be reworked and made thorough and unambiguous. I completely disagree that DMD bugs should be incorporated into the D language specification. I didn't say bugs should be incorporated. I say features not working on certain implementations should be clearly documented. Preferably in D language manual, as I believe that should be primary source for learning.
Re: Website message overhaul
rant As a language claiming for itself it was created out of practical needs of programmers I must say D fails on that test (both compilers and D website). It is not user friendly. It is user hostile, for simplest and most common tasks. Especially for newbie programmers. It was like that 4 years ago when I first saw it, and it is much like that now. You people should really hire some non-programmers with documenting skill and knack for KISS principle to make D website and documentation. It is obvious that Walter, Andrei and the rest of core people are highly skilled in their field of work, but not interested, available or competent to present D complexity in simple, right-to-the point way. I guess it is so much more fun to add new features and optimize code than to organize and present all the documentation the way it can be useful. And come on, BUD like feature is first useful thing compilers are lacking. Talking about practical need. /rant
Re: D on GDC announced on reddit
Simen Kjaeraas Wrote: On Fri, 07 Oct 2011 17:11:45 +0200, Nick Sabalausky a@a.a wrote: Trass3r u...@known.com wrote in message news:op.v2ze74ma3ncmek@enigma... Now D is also quite cool, I would just like for the language compilers to be a bit more stable. They have been vastly improving, really. Currently I do have more sucess proposing C++11 based solutions as Go or D based ones, on the type of corporate environment I work in. That's not D's or Go's fault. Most guys especially in bigger corporations are plain ignorant and wear blinders. Strangely that even applies to universities. Not real surprising. Universities can be *enormously* ignorant and conceited. (Community colleges too...my god, some of the flaming egos and politics around there are mind-boggling, especially considering it's *just* a CC...) Hell, they didn't even know about clang even though they were progressive enough to use C++0x. I once had a university professor who openly admitted C was the only language he knew - and yet he didn't even understand how C's null-terminated strings work. So he didn't really even know that one language. I helped a friend with some assignments from a professor who wrote absolutely unreadable code, and who taught students to use int[101] to allocate 100 ints, because he couldn't grasp indexing from 0 to 99. I also really liked the assignment where we were told of a mythical processor that would multiply 2 NxN matrices in O(N^4) time. -- Simen Those who know, work with it. Those who don't know, teach it.
Re: SQLite Bindings
That is great idea. I already hove something similar i n library I use for work, bunch of headers converted for D, from opeanAL to libpq (postgres), sqlite etc. That can be placed in both D1 and D2 without any problem.
Re: D's greatest mistakes
Lot of small things, details, that are not showstoppers but leave impression of unfinished business. First thing that come to my mind is lack of bud (build) building support where you point only to main.d file, and all other modules are imported. I think that is the ting required to bee in compiler itself, not in one of the numerous third party building scripts (how many are them there?) The post C#'s greatest mistakes prompts/begs this post. Have at it, pick up the ball and run with it, don't be shy. I expect Walter and Andrei to answer (if Walter and Andrei so dare!) after others' posts have stopped or stagnated into that cesspool of threaded discussion that is the subthread or tangential thread (which surely needs a rock anthem).
Re: why a part of D community do not want go to D2 ?
ponce Wrote: D1+Tango is working well enough for my project (Yage), but I like the direction of D2. I figure the longer I wait, the more stable it will become and the easier my job will be. Pretty much the same here, except I use D1 + Phobos. To me there is little doubt that D2 is better. Same thing here. It has all I need so far. Tried to switch to D2 couple months ago as a test, but it was painfull and unsucessfull attempt, mostly because of bugs.
Re: blog: Overlooked Essentials for Optimizing Code
Sean Kelly Wrote: == Quote from Bane (branimir.milosavlje...@gmail.com)'s article DMD built in profiler don't work yet with multithreaded apps. Is there a plan to change that or.. ? Yes. It's on my to do list, but other things have had priority. Thanks for reply. Can I help with something? I don't have mush experience with that, though.
Re: blog: Overlooked Essentials for Optimizing Code
Sean Kelly Wrote: Bane Wrote: Sean Kelly Wrote: == Quote from Bane (branimir.milosavlje...@gmail.com)'s article DMD built in profiler don't work yet with multithreaded apps. Is there a plan to change that or.. ? Yes. It's on my to do list, but other things have had priority. Thanks for reply. Can I help with something? I don't have mush experience with that, though. I tried a quick adaption a while back and failed... the code uses globals directly within functions sometimes and not others, etc. It's really going to take a substantial rewrite to get things right. The basic idea is that each thread will keep its own data and merge it into a collective dataset on termination. I'll dig the dmd code to see whats going on, but my love for c is bit rusty... Thanx.
Re: One more update on d-programming-language.org
Dedicated Website! Coool! Me like it!
Re: Thread + socket = (shared) problem? (2.048)
Thank you for your reply. I have been migrating some socket/thread code from D1
to D2 lately. One of changes is that Thread.this() must have super(run) in it.
It seems when one of the thread doesn't have that line, strange things happen.
Can anyone confirm this code to reproduce error:
import std.stdio;
import std.socket;
import core.thread;
class SaboteurThread : Thread {
this(){
// super(run); // comment this line for exception to be thrown when socket
is created in other thread
}
void run(){
writeln(Saboteur running);
while(true){}
}
}
class SockThread : Thread {
this(){
super( run );
}
void run(){
try {
auto s = new TcpSocket; // will throw wsock error WSANOTINITIALISED
(10093) on windows if SaboteurThread.this() has no super(run) in it
writeln(socket created);
} catch (Exception e){
writeln(e);
}
while(true){}
}
}
void main(){
auto x = new SaboteurThread;
x.start;
auto s = new SockThread;
s.start;
while(true){}
}
Thread + socket = (shared) problem? (2.048)
This will throw exception on trying to create socket in derived thread. Socket
created in main thread is ok. Is it some shared issue or... ? I have been
trying to find something info in docs and mailing list but no result.
import std.stdio;
import core.thread;
import std.socket;
class MyThread : Thread {
Socket sock;
this(){
super(run);
}
void run(){
writeln(thread start);
sock = new TcpSocket; // this will throw exception on 2.047, 2.048
writeln(thread end);
}
}
void main(){
writeln(main start);
auto s = new TcpSocket;
writeln(socket in main thread created);
auto t = new MyThread;
t.start;
writeln(main end);
}
Re: Thread + socket = (shared) problem? (2.048)
This is what I get: std.socket.SocketException: Unable to create socket
Re: Thread + socket = (shared) problem? (2.048)
I triple checked it. 2.0.48 has problems with this, 2.040, 2.045 2.047 don't.
This will throw exception on trying to create socket in derived thread.
Socket created in main thread is ok. Is it some shared issue or... ? I have
been trying to find something info in docs and mailing list but no result.
import std.stdio;
import core.thread;
import std.socket;
class MyThread : Thread {
Socket sock;
this(){
super(run);
}
void run(){
writeln(thread start);
sock = new TcpSocket; // this will throw exception on 2.047, 2.048
writeln(thread end);
}
}
void main(){
writeln(main start);
auto s = new TcpSocket;
writeln(socket in main thread created);
auto t = new MyThread;
t.start;
writeln(main end);
}
Re: Thread + socket = (shared) problem? (2.048)
Errr... sorry guys. Joke is on me. Main threads exits before socket is created in new thread. Simple call to sleep() fix this.
Re: TDPL, shared data, and Phobos
It probably wasn't very clear from my simplified example, but I'm looking to create a shared-reader-one-writer scenario. If I declare MyValue synchronized, only one thread can be inside the get() method at a time, which defeats the shared-reader requirement. Imagine this is a much larger more complex data structure, where get() requires walking through multiple levels of a tree and a binary search at the last level. Yup, I get it. But there is one point in it: write is not atomic operation in sense that get() might return half written data, right?
Re: State of and plans for the garbage collector
If I had to chose one topic with most bitchin' on this newsgroup I have impression it would be the one about GC. They usually goes from 'GC managed programs are slow, D ain't good enough', to 'language X has better GC than D', to ' GC that D has is bad at Z'. Why not make D summer of code - write your own GC optimized for special case of XYZ, send it, bundle all up in D with compiler switch '--useGC=XYZ'. That is only way to really compare what is best for special case. Okay. I really don't know much about garbage collectors, how they work, or what makes one particularly good or bad (other than the fact that it needs to be efficient execution-wise and manage memory wisely so that you don't use too much of it or do anything else that would be an overall negative for performance). However, from the comments here - both recent and in the past - it's pretty clear that D's garbage collector is fairly outdated. I would assume that that would be negative for performance - certainly it would mean that significant improvements could be made. So, my question is this: what are the plans for the garbage collector? Is the intention to continue to improve it bit by bit, to give it a major overhaul at some point, to outright replace it at a later date, or something else entirely? If D is going to compete with C and C++, it needs to be highly efficient, and if the garbage collector isn't up to snuff, that's going to be a big problem. I'm not looking to complain about the current garbage collector - I really don't know how good or bad it is - but if it is rather poor (as I've gotten the impresison that it is - at least in some respects - from various discussions on it here), then I'd assume that it needs a major overhaul or replacement at some point. So, are there any specific plans with regards to that, or is that just something that may be considered in the future? - Jonathan M Davis
Re: State of and plans for the garbage collector
Anyway, I'm here bitching myself :) Just want to say that idea to have more than one GC type to chose when compiling would be very interesting thing, if single implementation can't be good for all cases. If I had to chose one topic with most bitchin' on this newsgroup I have impression it would be the one about GC. They usually goes from 'GC managed programs are slow, D ain't good enough', to 'language X has better GC than D', to ' GC that D has is bad at Z'. Why not make D summer of code - write your own GC optimized for special case of XYZ, send it, bundle all up in D with compiler switch '--useGC=XYZ'. That is only way to really compare what is best for special case.
Re: TDPL, shared data, and Phobos
I am few days old in playin with D2 and whole shared stuff, so I am probably
wrong in something.
You should probably declare your example class MyValue synchronized instead of
shared. It implies that class is shared too, and this way all methods are
synchronized. In D1 you could mix synchronized and non syncrhonized methods in
class, in D2 its whole or nothing. This way you don't need _lock var in your
example.
So this would work (i guess)
synchronized class MyValue {
int inc() {
return _value++;
}
int get() {
return _value;
}
private int _value;
}
shared MyValue sharedVal;
void main(){
sharedVal = new shared(MyValue );
}
I noticed that in D1 synchronized methods of same class share same lock, while
in this D2 example (when the whole class is declared synchronized), each method
has its own lock.
Also, is there any documentation on the actual semantics of shared?
http://www.digitalmars.com/d/2.0/attribute.html is a blank on the subject,
and the migrating to shared article only talks about simple global state.
What are the actual semantics of shared classes, and how do they interact
with other code? For instance, after much banging of my head against the
desk, I finally wrote a working implementation of a simple shared
multi-reader var. Obviously there are better ways to do a simple shared
incrementing counter, this is just a first experiment working toward a shared
mutable 512MB trie data structure that we have in our app's current C++
implementation:
shared class MyValue {
this() {
_lock = cast(shared)new ReadWriteMutex;
}
int inc() {
synchronized((cast(ReadWriteMutex)_lock).writer) {
return _value++;
}
}
int get() {
synchronized((cast(ReadWriteMutex)_lock).reader) {
return _value;
}
}
private ReadWriteMutex _lock;
private int _value;
}
shared MyValue sharedVal;
... seems to behave correctly with multiple threads reading and writing ...
So I can maybe understand the cast(shared) in the ctor. But I have to admit I
have absolutely no idea why I had to cast away the shared attribute in the
inc/get methods. Is there any documentation on what's really going on in the
compiler here? It's a shared method, accessing a shared instance var, why the
cast? Is the compiler upset about something in the definition of
ReadWriteMutex itself?
Also, how would one implement this as a struct? My postblit op generates
compiler errors about casting between shared/unshared MyValue:
shared struct MyValue {
this(this) { _lock = cast(shared) new ReadWriteMutex; } // ERROR
... same as above ...
}
I recognize the possible race conditions here, but there has to be *some* way
to implement a postblit op on a shared struct?
I hope this doesn't come across as empty complaining, I'm happy to help
improve the documentation if I can.
Re: Concurrency in the D Programming Language: free chapter
Great stuff. Should be on D website under language reference.
Interesting to see (for geeks)
http://www.youtube.com/watch?v=fzza-ZbEY70
Re: Interesting to see (for geeks)
Sean Kelly Wrote: Sean Kelly Wrote: Walter Bright Wrote: Bane wrote: http://www.youtube.com/watch?v=fzza-ZbEY70 I generally do not watch anonymous youtube videos because I don't want to spend several minutes just to see if it is something I'd want to see. So, for the sake of people like me, can you add a summary of what this is about? It's a mock movie trailer about .NET and Java. To elaborate, imagine the theme from Perfect Beauty, the family are Microsoft diehards, and their young son discovers Java. Parallels are made to the tribulations of a child telling his parents he's gay, and Java is made out to be a guilty yet perfect pleasure. The trailer promises to be passably entertaining and then goes on for too long as the creators try to throw in too many snipes formatted as reviewer commentary. Yes, this pretty much kills all the fun watching it. Now you know why I didn't write anything describing it.
Re: Is it time for D1 to die of natural causes?
SiegeLord Wrote: Justin Johansson Wrote: Now that Andrei's much anticipated publication of TDPL is out, is it time that D1 should now perish? My personal feeling is that by cremating D1, time and effort can then be better expended and focused on solidifying D2. Cheers Justin Johansson To whose benefit? You are advocating nerfing a good, stable, usable language that has an excellent (de facto) standard library, excellent compilers (on Linux, at least), 64 bit support, tons of libraries already written for it etc, and replacing it with a buggy language, buggy standard library, buggy linker, no 64 bit support and only a handful of libraries to support developing in it. How do users benefit from your suggestion? I have scientific computing that must be done *right now* as well as games I want to develop *right now* and I don't want suffer the performance losses that come from DMD's substandard optimizer (at least, relative to LLVM), as well as Phobos 2's abstractions (although a better compiler might solve those issues) and not using 64 bits. I just tried installing dmd2 on my 64 bit Linux box, and while it installed, I couldn't compile Hello World, since I have no 32 bit versions of 32 bit pthread libraries installed. I am not going to install 32 bit versions of every library I use in my C++ development to use them in D2, that is simply unreasonable: I will use D1 instead. And I'm not worried about investing into D1 and then have my work be obsolete: I am fully planning on porting my things to D2 *when* it becomes better than or even as good as D1 for my purposes. It's easy to do... just don't use too many deprecated features. D2 will only become the dominant version if it is actively better than D1, not by making D1 disappear. Users are not going to encounter those issues and start spending their time and effort improving the standard library and compiler tools, it isn't worth their time: they will go use a different language instead. For D2's future's sake, that different language should be D1. Excellent points. I do believe, at the moment, D1 is used for real work, not D2. So idea of shooting D1 so half finished D2 could 'gain momentum' is idiotic one.
Re: beforeGarbageCollection
Andrei Alexandrescu Wrote: I'm thinking of a feature that would improve the memory footprint of D programs. Say druntime provided a function: void beforeGarbageCollection(void delegate() callMe); The runtime would guarantee that callMe gets called before any collection. That would allow modules to clean up caches (e.g. free lists) to improve their memory profile. Any thoughts, please share. Andrei void beforeGarbageCollection(bool delegate() callMe); Maybe return value indicating should collect cycle be executed or skipped only that once? There might be some cases that it can be useful. Just my 2c
Re: Go Programming talk [OT] - C is simple enough!???
BCS Wrote: Hello Andrej, And when D3 comes out, you'll be waiting for D4? I don't understand your posts mentioning D3. I mean, D2 isn't even finalized yet (right?), and you're already treating the language like it came out 50 years ago and needs to be abandoned. I get the impression that some of the people here are more interested in the development *of* D than development *in* D. In some ways, that's a good thing, as long as we don't just produce a toy for language developers. I'mstuck with 1.030 making nice shiny things, so I guess I tip the scale to other end.
Re: MingW compatibility
Robert M. Münch Wrote: On 2010-06-11 13:18:34 +0200, Alex Makhotin said: Yes, libraries produced with mingw32 GCC link well with binaries produced with DMD and I didn't notice runtime issues. Perfect! I start to like D more and more... -- Robert M. Münch http://www.robertmuench.de I don't remember having problems with using any dll on windows, implib does good job. As far for linking static lib, I believe compiling it with dmc is required.
Re: How do you use C based libs with D?
Robert M. Münch Wrote: Hi, this is a bit related to my post regarding MingW compatibility. As D uses Optilink (AFAIU) this implies that all C based code needs to be compiled with DMC? Not that I don't like DMC (I like it a lot) but I always had problems (or it requires a bunch of work) to get open-source projects compileable with it. How do you deal with this? I deal the way you say: some compiles nice, some requires (lot) of work, and some are just impossible to compile, so I use dll. Is there particular reason you avoid using dll's? -- Robert M. Münch http://www.robertmuench.de
Re: Go Programming talk [OT]
Andrei Alexandrescu Wrote: On 06/09/2010 06:28 AM, Pelle wrote: On 06/09/2010 01:04 AM, Leandro Lucarella wrote: Bane, el 8 de junio a las 14:42 me escribiste: Is a trade-off. When you don't handle the errors, exceptions might be a win, but when you do handle them, I'm not so sure. And again, I'm not saying I particularly like one more than the other, I don't have a strong opinion =) Of course, the problem is that you rarely see the former code. Most of the time, people just write the second one with or without exceptions and don't bother about error checking if there are no exceptions. You are a lot more likely to get them to handle errors properly with exceptions than without (particularly with D's scope statements). Being lazy as I am, exceptions are faster and easier to use than manual error checking. There will always be some unchecked return value, with exceptions it can't happen. In a way same as GC vs manual memory handling. Each thread of program I make I always enclose in try catch, so everything is cought. Yes, I agree that safety is the best argument in favour of exceptions (as explicitness is the best argument in favour of no-exceptions). The Python Zen put it this way: Errors should never pass silently. Unless explicitly silenced. That's what I like the most about exceptions. I think try/catch is really ugly though. There has to be something better. Careful use of scope(exit) and simply avoiding catching exceptions works well for me. Except when you have to catch, of course. :) Same here. I think a good application only has few try/catch statements, so the fact that try is a relatively heavy statement is not very important. Andrei In my experience exceptions have one great advantage that they are far easier to add/remove to existing codebase without changing lot of things. They require much less coding and do not obfuscate code flow. So for what they offer and for what price - they are extremely worth it.
Re: To throw or not to throw [was: Go Programming talk [OT]]
[Bugs (ie, cases where the program deviates from its specification)] should be corrected before the program is delivered, not handled while it is being run. HA HA HA HA HA!!! (/Wipes tear/) AHH HA HA HA HA HA Translation: He seems to be living in lala-bizarro-land where the waterfall model produces good, reliable results and one can simply choose to find all bugs before shipping. Also, everybody is always happy, there is no disease, and everyone spends all day frolicking in the daisies, climbing rainbows and playing Kumbayah on their guitars. Sounds to me that guy never ever have written program that was used for anything other than lecturing.
Re: Marketing of D - article topic ideas?
superdan Wrote: == Quote from retard (r...@tard.com.invalid)'s article Thu, 03 Jun 2010 16:58:03 -0700, Walter Bright wrote: D is an extremely powerful language, but when I read complaints and sighs about other languages, few seem to know that these problems are solved with D. Essentially, we have a marketing problem. One great way to address it is by writing articles about various aspects of D and how they solve problems, like http://www.reddit.com/r/programming/comments/cb14j/ compiletime_function_execution_in_d/ which was well received on reddit. Anyone have good ideas on topics for D articles? And anyone want to stand up and write an article? They don't have to be comprehensive articles (though of course those are better), even blog entries will do. Well, I for one, like to know when the D2 will be officially published. I thought there was a bugfix week and the TDPL was written because D2 is almost ready and there was supposed to be a big kaboom. The version number is already at 2.046 but there are maybe 100 bugs waiting in the bugzilla with patches and the compiler spec are seriously broken. When will it be usable? What will be the version number of the first usable D2 dmd? There was a huge D1 release party, but I'm not sure when it's a good time to move to D2. It's not enough that the examples from the book work, D needs to be ready for commercial quality applications. What's the library status? Where are the official milestones? Future plans? What's happening here? http://www.youtube.com/watch?v=8r1CZTLk-Gk thanx fer yer self entitlement asshole. yup. too many people take D for granted and only bitch about things it lacks and never see lot of great features it already has. it is usable and it is fucking better than c and c++!
Re: Marketing of D - article topic ideas?
Might be unimportant and off topic, but I think cool website might be nice first impression. As I see, almost all effort is in direction of converting existing programmers to D. We are maybe forgetting about inexperienced people that are just looking for first (compiled) language. They usually chose easiest to use right away, with most understandable docs and easiest installation.
OT: Re: One document about Go
BCS Wrote: Hello Walter, bearophile wrote: Walter Bright: C got it right and it doesn't need fixing. I have never programmed in Go, but keep in mind that Go designers are expert language designers and programmers. They aren't stupid people. Even experts make mistakes. Even Forest Gump knows 'stupid is who stupid does'. For that matter, how many expert language designers are there in the world? To make that have an answer, I've heard it said that to be an expert you need to have done something consistently (like as a part time job or more) for about 10 years. So Walter's and expert compiler writer and might be an expert language designers sometime next year (assuming IIRC he started designing D in '01). Does this makes me expert for beer consumption ? It was a full time job for me, often during weekend days? Does 10 years of banging your fingers with hammer makes you expert carpenter ? I don't think here on Walther, but on that hilarious definition of 'expert'.
Re: If you have to learn just one programming language
This reminds me of elementary school and those discussions which car/plane/tank is best. Pretty futile subject to begin with, as you cant compare fruits and vegetables. And no matter what somebody say there will always be some kid claiming opposite just for the sake of disagreeing. I guess troll got hungry.
Re: If you have to learn just one programming language
IMHO the original blog post was more trolling than my false opinions. I liked your critical way of thinking so much that I publicly admit that my post was a bit provocative. Thank you for a compliment. When you see this kind of articles, you should really ponder whether it makes sense for anyone to prove that a new favorite language beats everything ever built. Seriously, the argumentation was really sloppy. Languages should not be like religions. I find it so funny when people are desperately protecting their precious poor little D from the faceless evil trolls. I think that is consumer society problem. They (evil marketing dudes) brainwash people that new products are better than old, so they would buy new stuff. Its influence is in lot of areas of life, why not programming to. Or just Darwinist evolution approach believing that new things are better and smarter than old. Yea, right. As for trolls, they have their role in questioning things and annoying people that take things too seriously. Keep up the good work!
Re: Memory Mapped File Access
Ok, I need to be fair. We are quite good at these things. Anyone remembering Adimens from the Atari (later for Windows as well)? It was/is a ACID compliant SQL database with row-level locking etc. And, it was written by my friend and sold more than 500.000 times. Yes, we are crazy... but chances are high we will get something done. I need to get some practice with D but shouldn't be that hard. Then this is a whole new ball game. I did that scare-to-double-think-it so you wouldn't start too ambitiously, but it seems you have enough experience to know exactly what you are getting into. I think D is perfect for the job. Much less lines of code than C family, same or more power. I hope your project will make you famous, along with D :)
Re: Memory Mapped File Access
Robert Wrote: Hi, has anyone played around with D and memory mapped files on Windows / Linux? A friend of mine and I want to use D to develop a D native database-system. Yes, sounds crazy and it will take long and we haven't done a lot yet. So don't expect anything to look at soon :-) Thanks Robert. MMapped files work just fine, I played/am playing with them. I greet your idea to learn how to build database, its great way to spend time for people programming that stuff. And you are right - trying to make operational database like this is crazy, crazy idea. It will require from you HUGE investment in time learning to make it remotely reliable and usable. Here I talk about ACID compliance. If you are trying to build something that works *mostly* of the time and saves key - value pairs in file then it is much simpler. SQLite is a great project you could learn a lot from. It has tons of useful docs about making DB, its open source, its been around for 10 years and its probably better job then you could ever do.
Re: 64-bit support (Was: Poll: Primary D version)
bearophile Wrote: Walter Bright: I should amend that by saying that post D2 emphasis will be on addressing problems with the toolchain, of which 64 bit support is a big one. Language changes will be a very low priority. Other toolchain problems are things like shared libraries, installation, bugzilla bugs, etc. Things are not as simple as you say: among the Bugzilla bugs there is more than just pure implementation bugs, there are design bugs too, and they are essentially language changes. I can list you many of them. Bye, bearophile I just hope D won't try to become Jack of All Trades, ad least not to early :D
Re: Poll: Primary D version
Nick Sabalausky Wrote: Nick Sabalausky a...@a.a wrote in message news:ht3uj4$30f...@digitalmars.com... div0 d...@users.sourceforge.net wrote in message news:ht3tfa$2sm...@digitalmars.com... I'm surprised so many people who don't use D bother to read this news group and voted on the poll. Surely they must have better things to do. I have a few guesses for that phonomenon: ... - Troll and/or trolls. I turned on enable IP logging, but I didn't turn on prevent multiple votes from same IP, since shared IPs are fairly common. Maybe GirlProgrammer's been messing with it. Or maybe the Reddit D-Downvoters found it. Maybe I made a mistake by not preventing multiple votes from same IP. Maybe if it turn that on it'll apply retro-actively...or maybe not? I dunno, I really should get around to making my own poll software. ... I've looked into this a little. I was able to download a chart of the IPs, and the number of votes per IP. Unfortunately, there doesn't seem to be any way to tell anything about the actual votes from a particular IP, which I suppose is good for privacy, but it prevents me from looking at an IP with multiple votes and determining if all of the votes were suspiciously strongly favoring the one option. There are 105 IPs. The vast majority of the IPs only had one vote. There were five IPs that had two votes each, and one IP that had three votes. I'm willing to assume those are just multiple people from the same ISP, and even if not they're not particularly significant compared to the rest. But then there was one IP with 72 votes. So, yea, that does seem suspicious. In case anyone thinks they might have more insight, the IP in question is 115.131.192.250, and appears to be from Austrailia. Thats great. It proves my point - even D trolls are loyal to the project. 72 votes? That is some dedication.
Re: Poll: Primary D version
What is more interesting is that the majority of D users already use D2, which has a huge list of bugs. It just tells that most D users don't use D in serious / mission critical / money bringing projects, but instead as a hobby. I'm in serious business with it. I think D1 is up to it pretty well.
Re: Poll: Primary D version
Bane Wrote: What is more interesting is that the majority of D users already use D2, which has a huge list of bugs. It just tells that most D users don't use D in serious / mission critical / money bringing projects, but instead as a hobby. I'm in serious business with it. I think D1 is up to it pretty well. D1 I mean. Shit. I lack clarity.
Re: Poll: Primary D version
OBG! I'm minority! (still stuck on 1.030) Nick Sabalausky Wrote: I'm interested in trying to gauge the current state of D version usage, so I've set up a poll: http://micropoll.com/t/KEFfsZBH5F I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I personally hate MicroPoll but everything else I've seen is even worse and I don't have time to make a custom one.
Re: Poll: Primary D version
OMG! I can't even spell OMG right! OBG! I'm minority! (still stuck on 1.030) Nick Sabalausky Wrote: I'm interested in trying to gauge the current state of D version usage, so I've set up a poll: http://micropoll.com/t/KEFfsZBH5F I apologize for using MicroPoll (and all its manditory-JavaScript-ness). I personally hate MicroPoll but everything else I've seen is even worse and I don't have time to make a custom one.
Re: Please, don't feed the troll (was Does D Suck?)
superdan Wrote: == Quote from Bernard Helyer (b.hel...@gmail.com)'s article On 17/05/10 17:17, GirlProgrammer wrote: If D doesn't suck, and is better than C++ why am I not using it? Indeed, why isn't hardly anyone using it? I imagine you get some dull pleasure from posting essentially the same message to the NG every few months or so (this is almost certainly the person behind the 'is d a cult' thread a few months ago, and ios the same person behind 'what is d' from a few weeks) so until GirlProgrammer/Jane Doe/Janis D/angelinastyle contributes a question beyond the same simple troll, 'she' is not worth responding to, so I'd just like to take this opportunity to remind the NG of the content 'she' has previously posted, and reconsider in replying to 'her' accordingly. Just a friendly PSA. n_n PS: It's nice to see that you've updated your XP install since your last message! yeah dun feed da troll. ass to mouth da troll. too bad that ain't gonna be pleasant. cocksucka as girlprogrammer is it ain't no broad. its a punk-ass motherfucker posing as chick 2 give a twist to his lame life. shit. A troll visit once in a while is a nice way to break routine on any ng/forum. Especially female programmer with love towards word suck. That is bound to be fun. I see this troll is loyal, and will be here for years to come. Looking forward to it.
Re: pure generators
2 words (not relating to true meaning of this post): Crap engine. My first association seeing 'pure generators' subject. Is there better way to counter balance them, and make a useful machine, running on type of fuel that is in abundance here where we live? Better than perpetuum mobile.
Re: Tango Phobos
Nick Sabalausky Wrote: Nick Sabalausky a...@a.a wrote in message news:hrgbo5$fv...@digitalmars.com... Walter Bright newshou...@digitalmars.com wrote in message news:hrgag4$cp...@digitalmars.com... Jason House wrote: It is my understanding that several Tango developers no longer follow digitalmars.D. I recommend posting to the Tango forums. If anyone would like to repost my message initiating this thread in the Tango forums, feel free. Done: http://www.dsource.org/projects/tango/forums/topic/878 It seems to have been silently deleted...(???) Yup, that's what Stalin would do :) Joke aside, hot tempered discussion can't bring any good, so its better that way.
Re: Tango Phobos
Gurney Halleck Wrote: == Quote from Bane (branimir.milosavlje...@gmail.com)'s article Nick Sabalausky Wrote: Nick Sabalausky a...@a.a wrote in message news:hrgbo5$fv...@digitalmars.com... Walter Bright newshou...@digitalmars.com wrote in message news:hrgag4$cp...@digitalmars.com... Jason House wrote: It is my understanding that several Tango developers no longer follow digitalmars.D. I recommend posting to the Tango forums. If anyone would like to repost my message initiating this thread in the Tango forums, feel free. Done: http://www.dsource.org/projects/tango/forums/topic/878 It seems to have been silently deleted...(???) Yup, that's what Stalin would do :) Joke aside, hot tempered discussion can't bring any good, so its better that way. Srsly?!? Its better to censor Walters informative post because the Tango Komintern has no good retort? The dimwits tried to rewrite history once. They edited the title of Dons bug report. They failed to explain that too. This time the truth is out there. Tango leadership deserves no respect. I meant on topic removal from DM newsgroup. I guess Walther did it, as he is the one administering it, right? I support his decision for a reason I wrote above. As far of Tango leadership and respecting them, time will tell soon. If Walther, Andrei and the rest of people that are making tremendously hard work on D can put their ego aside (quest for fame), then what is to say about people that (face it) do less with Tango and act like their work is more important? Bottom line is that D should not suffer because of ego of individuals.
Re: Tango Phobos
Walter Bright Wrote: Bane wrote: I meant on topic removal from DM newsgroup. I guess Walther did it, as he is the one administering it, right? I support his decision for a reason I wrote above. Yes, I did it, it was my idea to do so. I did it for the reason you suggest (not the Stalin one!) but the one about letting our hot tempers cool a bit so hopefully we can find the best solution for D, not an ego-driven one. As I said, this Stalin thing is joke on efficiency and speed of action was taken. Comparing Walther to Staling was not my intention.
Re: Tango Phobos
I've read all the discussion, I think it's very clear (especially from Lars's mesage here: http://thread.gmane.org/gmane.comp.lang.d.phobos/359 ) thst there's been absolutely no ego involved, by anyone, at all. The whole thing was all about Walter being told that it may be possible that one of tango.time's writers could *IN THEORY* have a potentially legal complaint about SHOO's lib. I assume that Lars was the one who informed Walter of this (though I'm not certain), and if so, then *NOBODY* has actually made any complaint about *THEIR OWN* code being infringed!! Additionally, it's been made very clear that the whole binary attribution thing is staying in Tango *purely* because of difficulties in switching away from BSD (While I may disagree that sticking with BSD is the best thing for Tango to do, the important thing here is that ego doesn't have a damn thing to do with it). So can we finally knock it off with all the someone has an ego bullcrap? I fully expect Halleck to keep it up, but that's only because every post he's made here has been trolling, and trolls certainly aren't going to care about any reasonable argument that gets presented to them. But for everyone else: It's done, it's over, QED, there's no flaming egos, give it a rest. I was under impression that stopping factor is that Tango can't switch to boost so it and Phobos can share the same license. Or maybe that Tango has problems with itself switching to single license from current dual licensing thing that has problems. I read all links involving this discussion, and frankly, its a mess (too much details). Also, I'm not tracking who is troll here, so I take seriously everything I read that sounds remotely non-trolling.
Re: The BSD license problem and a trivial solution
1) Add a handler for --printLicenses in extern(C) int main. This ensures
the text can always be printed.
1.1) Make sure to call checkLicenses beforehand!
2) Public import addLicense and registerFile in object.d
3, optional) Extend the module statement so that `module foo under GPLv2; `
is interpreted as `module foo; static this() { registerFile(__FILE__,
GPLv2); }`
4, optional) Extend the above system to track what licenses can import what
others.
The horror! The horror!
Re: Tango Phobos
For those Tango programmers not willing to change their license: They are fucking programmer prima donnas. Tango should prune their work and continue on without them. Too much good work is at hold because of legal bombs they planted. Their contribution is clearly useless, even more, harmful. As for those that can't be reached: hey, either adopt it as anonymous work or prune it too. That's what Stalin would do.
Re: Fatal flaw in D design which is holding back widespread adoption
I wonder do Python folks have same problems.
Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Would something like tidyMyHorribleDcode be a solution? Put a conf file in source somewhere which states how many tabs/spaces/whatever. Before you comit code back to shared repository you run tidy to convert code to D spe format. When you checkout code from repo you run tidy with your custom settings. A great simple solution for trivial problem not worth talking about it.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Jesse Phillips Wrote: Bane wrote: Would something like tidyMyHorribleDcode be a solution? Put a conf file in source somewhere which states how many tabs/spaces/whatever. Before you comit code back to shared repository you run tidy to convert code to D spe format. When you checkout code from repo you run tidy with your custom settings. A great simple solution for trivial problem not worth talking about it. So, something like indent or bcpp for Linux? http://indent.isidore-it.eu/beautify.html http://www.faqs.org/docs/Linux-HOWTO/C-C++Beautifier-HOWTO.html Nah, they are unworthy. Not written in D.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
It would be a start. Used by itself it would be a bit of a hassle, but having it hooked up to auto-run upon checkout/commit or upon save/load in the editor (this would ideally be better since you can double-check the reults before committing) would be pretty much what I already had in mind as a solution. My thinking the same. Alhough it wouldn't necessarily even need to be a full-fledged source formatter. Just something to sanitize the whitespace between start-of-line and anything non-whitespace would be a huge improvement *and* be cross-language. Only thing to be taken into special consideration are multi line strings. Sanitizing them would produce errors. Some kind of lexer or advanced regexpr match might be required.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
And here's an even crazier idea: Some sort of well-thought-out UCF format (Unicode Code Format) that is like plain-text, but includes a standard metadata header (typically hidden while editing) that can help sort all this stuff out, and maybe other things as well. Obviously it would require special support from compilers and editors, but if it was well-designed (including discouragement of proprietary extensions - don't want a repeat of HTML) then I think it would be worth trying to push. Sounds complicated and error prone. I still have problems with notepad and his habit of killing utf-8 files and inserting bunch of where all the nice chars were. Makes me want to kill somebody.
Re: Solution for Fatal flaw in D design which is holding back widespread adoption(tm)
Nick Sabalausky Wrote: Walter Bright newshou...@digitalmars.com wrote in message news:hp087r$19l...@digitalmars.com... Nick Sabalausky wrote: Alhough it wouldn't necessarily even need to be a full-fledged source formatter. Just something to sanitize the whitespace between start-of-line and anything non-whitespace would be a huge improvement *and* be cross-language. I think that's a great idea. Yesterday, I wrote the following program and added it to the dmd makefile so that all checkins and installs run the source code through it first. I welcome improvements. The current version replaces tabs with spaces, and removes trailing whitespace. Sounds great. If someone is ambitious, a full fletched D source code pretty printer would be valuable that anyone could use, and which all Phobos source code could be run through in order to enforce a common style. For bonus points, they could expose it as a library so editors and other tools can make use of it without shuffling everything through command-line params, stdout and the filesystem. Will it work with multiline strings? char[] s = r I am very wide string;
Re: Solution for Fatal flaw in D design which is holding back widespread
I have tried that Universal Indent GUI with Uncrustify. It seems nice but it has so many options that finding the correct ones is lot of work, even if you use that GUI: http://uncrustify.sourceforge.net/config.txt It seems unable to recognize foreach and foreach_reverse. Bye, bearophile In my case it breaks class indentation. I guess template syntax is a bit tricky for it too.
LIB flag on Windows DMD (nagging)
(Disclaimer: I don't know is this solved on dmd later than 1.030, I'm stuck with it past...) Problem: PITA when using DMD on windows with custom library paths Example: there is pragma(lib, mylib.lib); somewhere in the code. mylib.lib is not on the known path for the compiler (lets say c:\xxx). How to tell dmd where to look for it? 1. dmd ... -Ic:\xxx won't work 2. dmd ... -Lsome_flag_to_optlink won't work (I haven't found in optlink docs that you can pass argument for lib path) 3. set LIB=c:\xxx dmd ... won't work (sc.ini in dmd binary folder rewrites LIB env. var with the one in it) 4. bud ... -LIBPATH=c:\xxx ... wont work (same as 3) 4. edit sc.ini in dmd folder and add c:\xxx not smart (not all projects need that lib path, even worse if different projects use 2 distinct mylib.lib) 5. create sc.ini in project folder and add c:\xxx to LIB env var pain in the royal behind (lot of duplication, as original LIB, DFLAGS and LINKCMD are not changed, also, full path to dmd folder must be supplied as %...@p% points to project folder now) Is there a way to remedy it? Or just to edit line in original sc.ini in dmd folder from LIB=%...@p%\..\lib;\dm\lib to LIB=%...@p%\..\lib;\dm\lib;%LIB% it seems that adding %LIB% at the end apends existing LIB env var, so paths are preserved.
Re: LIB flag on Windows DMD (nagging)
Robert Jacques Wrote: I don't know about the general case, but I use pragma(lib,...) with a library in my working directory and it works. That works by default. Problem is when different projects share same libs from some other folder.
Re: [OT] Who lives in the by area?
BCS Wrote: I just graduated from collage (Yeah!) and got a job (Ye-ha!) in the San Francisco bay area where I've spent just over 24hr ever (urk...). Anyone from the area have any advice? Places to avoid, things to look into or watch out for? That sort of thing. (Offline responses also welcome at: benjamin at precisionsoftware us ) -- ... IXOYE Avoid Blue Oyster bar, if you are not one of those. Other than that, you'll be just fine.
Re: D is dead, so now where it the money going?
JamesKan Wrote: Andrei wants some (he just wants money, huh). Walter? Shut it down. Count the people engaged in this whatever it is, and if a few select capitalize on its failure, then, who are you? There is no money in D. None. Nada. Religions are not for profit. It's OK to worship, whoever stupid people want to. If TDPL goes to press, there is something VERY wrong (and there is). Bitching about your own life disappointments? Whenever you go everything appears the same? Here's an idea: go some place else!
Re: D is dead, so now where it the money going?
Do you mean this one? What problems has D solved? (Other than providing compiler writers with masturbatory material). Light bulb (!!!): D is a circle jerk! (Not that there's anything wrong with that). It has a similar tone. Why would someone be so bitter and write so badly? Even if it were the case that D was not really any more than a discussion group for ideas about compiler design, it would still be a worthwhile exercise. Walter has been contributing to the industry for years, and anyone who has done that in the way he has will have experienced ups and downs. He's the last person I know who I would describe as money-grabbing. If Andrei wants to risk all the work it takes to get a book published, and he's bet on a particular horse, then whichever way it goes, that's his own choice. Since when was there an unwritten rule that you can't do speculative technical work with a view to making some money in the future. If people hadn't done that many times we would barely have computers and computer languages at all! I'd put it more bluntly than some (not to you Pelle) - piss off you anonymous prat, or be clear about your identity then we can all judge your motives. Steve I agree with Steve.
Re: Network in phobos
Adam Ruppe Wrote: Something that I think would be nice is being able to treat a network connection the same way we can work with files and stdin. I think I saw exactly that in Tango lib, maybe you can save time by looking it up. I don't know for sure, newer used it.
Re: Summary on unit testing situation
Pelle Månsson Wrote: I'm not sure I understand, could you explain? I am not experienced with unittest frameworks, and would like to understand what the D system lacks. Thank you. Me too.
Re: Append char to char-array in function
Nrgyzer Wrote:
Hello everyone,
how can I add a char to a char-array by using a other class?
For example:
class A {
private char[] text;
this() {
...
text ~= a;
new B(text);
writefln(text);
...
}
}
class B {
this(char[] text) {
...
text ~= b;
...
}
}
This should write ab in the command line, but only a is shown.
... Thanks for help :).
No, it shouldn't. What goes in B, stays in B. But if you add magic 'ref' or
'inout' keyword it might work:
class B {
this(inout char[] text) {
...
text ~= b;
...
}
}
Re: Append char to char-array in function
bearophile Wrote: Bane: No, it shouldn't. What goes in B, stays in B. But if you add magic 'ref' or 'inout' keyword it might work: Use 'ref' only. If the OP also wants to know why that's the solution, the d.learn newsgroup is the right place to ask. Bye, bearophile Darn. I like inout more. Why do good keywords die first?
Re: Improve D1/D2 home page
I have been thinking about the same thing the other day. My first contact with D was 5 years ago. I had solid background using PHP and Python, and occasionally used Delphi and C/C++, so I knew basics on non-scripting languages as well. I have been searching for compiled language with less frustrating usage than C, and somehow ended up on D website. I had trouble understanding what's going on. Raw input was there, but some simple basic guide was missing. I believe even now website is optimized for more experienced programmers that know C++ that can read stuff and say Hey, this looks very familiar to what I use... AND that are willing to dig website enough to find what they are looking for. But for beginners or users of non-similar language it is hard, hard and confusing experience. That's why I quit D on first contact after few days of frustration. 2 years and more C/C++ experience later, I came back to website, said something like hey, this looks familiar and started switching to D. Taken the fact that D has simple and powerful syntax as many popular languages today (easy string array manipulation, powerful built in types, no cryptic syntax, compiler that reports errors pretty good, no hidden quirks or PITAs, builtin library with pretty much enough for any start), I really don't see why should D be considered 'good as second language'. Shit, it is good as first language for beginners to! All it needs is more dope friendly website, with tutorials and info that already exists organized to more logical places, more useful menu with real hierarchy, news section, FAQ, beginers section with some programming basics (nothing fancy), and most importantly 'quick start' tutorial with flashing orange link that shows visitor how to download and compile 'Hello world in 2 min and piss his pants of excitement, willing to find out more about this cool language. The only reason I dont bitch more about it because I cant do it (been told more than once I don't distinguish green from red color when I tried to play with webdesign), and its lame from me to say to other people what should they do.
Re: Improve D1/D2 home page
All it needs is more dope friendly website, with tutorials and info that already exists organized to more logical places, more useful menu with real hierarchy, news section, FAQ, beginers section with some programming basics (nothing fancy), and most importantly 'quick start' tutorial with flashing orange link that shows visitor how to download and compile 'Hello world in 2 min and piss his pants of excitement, willing to find out more about this cool language. I would say one more thing, risking to anger people who think othervise: word count or Fibonacci number functions are not cool tutorials for most of programmers :) 'Hello world', 'I rule!' infinite loop or some openGL demo are.
Re: Improve D1/D2 home page
I'm not color blind (yes, I was tested!), but I might as well be because everyone says I have no taste in colors (or web design, for that matter). I believe design and programming skills don't go hand in hand. There's no store set on the current scheme of the pages. So if you or anyone has specific suggestions, feel free. Easy :D use some existing design. Examples of some websites: Minimalistic design I like very much: http://www.sqlite.org/docs.html D is more complex project, so I guess it wont cut it. Maybe some sort of wiki/tracking system for software development would be usefull? It would solve horrible design + enable more people to change/add contents? Here again design I like: http://trac.edgewall.org/ There are many similar projects, they include repository, wiki, bug tracking and all things D need. Using some of it has many benefits: more people are familiar with it so they would know how to use it and contribute + there are templates for pretty design so no more bitching about horrible colors + it offers some predefined ways to organize tons of data D is all about for easier use. I mean D website has lots of data and lack of administrators, it is in danger to evolve in this horrible mess: http://www.firebirdsql.org/ So many bright colors, so much data, so much noise (to be fair, it looks better now than a year ago).
Re: Improve D1/D2 home page
Jesse Phillips Wrote: I also suggest at least some of the changes found on this zilla http://d.puremagic.com/issues/show_bug.cgi?id=3497 True. Lot of D project related stuff is hosted on many sites, which is confusing. http://www.digitalmars.com/d/dlinks.html. I guess there will come a moment in future when something languageD.org will happen so all wikis and sites can be merged to that one.
Re: Obfuscating function names and the like inside exe file
bobef Wrote: Hello all, I was wondering if someone know of way to obfuscate all the strings and function names and class names inside DMD Windows generated exe file. Opening the file with notepad shows all kinds of strings and names in clear text and since my application handles some sensitive data it gives me an extra feeling of insecurity. Any suggestions? Thanks Compress/encode sensitive data and give meaningless names to function/classes ? :)
