Re: dmd 1.048 and 2.033 releases
On Tue, Oct 6, 2009 at 3:08 PM, Walter Bright newshou...@digitalmars.com wrote: Lutger wrote: Walter Bright wrote: Don wrote: It's pretty standard, though. For example, there are some bugs which Visual C++ detects only when the optimiser is on. From memory, they are all flow-related. The MS docs recommend compiling a release build occasionally to catch them. The flow analysis could be run on every compile by default, but it would make for pretty slow turnaround. Is it possible / reasonably to run flow analysis but still have a build that can be properly debugged? If yes, wouldn't it be nice to have it as a separate compiler option? Some people with build slaves, fast cpu's or smallish projects won't care that much for the performance. Just compile with: -debug -O You don't seem to be grasping the issue here. It's not using -O with -debug that's the problem, it's using it with -g. You can't reasonably expect someone to put an optimized executable through a debugger.
Re: Crash handler with stack trace
On Wed, Sep 23, 2009 at 11:58 AM, bearophile bearophileh...@lycos.com wrote: Leandro Lucarella: Blaze is an engine AFAIK, not a program. And an engine to build games AFAIK, and game aren't usually a good candidate for benchmarking since they can't be automated. Blaze is a program that simulates 2D physics written in D. http://www.dsource.org/projects/blaze It's an engine, but it comes with an extensive demo that is and can be used as benchmark. So I think it can be used for your purposes (but I don't know how many memory allocations it performs). It performs *way too fucking many*. ;) Which, I suppose, would make it a good GC benchmark.
Re: reddit.com: first Chapter of TDPL available for free
On Sat, Aug 8, 2009 at 8:44 PM, Jos van Udenj...@nospam.nl wrote:
Andrei Alexandrescu wrote:
http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/
(Don't tell anyone, but I plan to rewrite it.)
Andrei
Is this supposed to compile? I keep getting error messages.
import std.stdio, std.string;
void main() {
uint[string] dic;
foreach (line; stdin.byLine) {
// Break sentence into words
string[] words = split(strip(line));
// Add each word in the sentence to the vocabulary
foreach (word; words) {
if (word in dic) continue; // nothing to do
uint newID = dic.length;
dic[word] = newID;
writeln(newID, '\t', word);
}
}
}
test.d(7): Error: function std.string.split (immutable(char)[] s) does not
match parameter types (char[])
test.d(7): Error: cannot implicitly convert expression (strip(line)) of type
char[] to immutable(char)[]
test.d(7): Error: expected 2 function arguments, not 1
I've changed the code to:
import std.stdio;
import std.string;
void main() {
uint[string] dic;
foreach (line; stdin.byLine) {
string[] words = split(strip!(string)(line));
foreach (word; words) {
if (word in dic) {
continue;
}
uint newID = dic.length;
dic[word] = newID;
writeln(newID, '\t', word);
}
}
}
but I still get an error...
test.d(12): Error: cannot implicitly convert expression (line) of type
char[] to immutable(char)[]
It's not documented, but the .byLine method returns char[], not
immutable(char)[] (string). This is because the 'line' variable is
reused on each new line of the input, to improve speed. I think to
solved this, you should use:
auto words = split(strip(line.idup));
The .idup creates a new duplicate of the line that is immutable.
Now, why split() doesn't take a const(char)[] is beyond me..
Re: reddit.com: first Chapter of TDPL available for free
On Mon, Aug 3, 2009 at 7:34 PM, Nick Sabalauskya...@a.a wrote: Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:h57mno$26g...@digitalmars.com... http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/ (Don't tell anyone, but I plan to rewrite it.) Andrei I just read the first section and already I'm impressed with it. Great job :) One little niggle though: At the end of the paragraph that explains the hello world's import statement, it says Repeated imports of the same file are of no import. Sounds like a typo snuck in there. That's no typo; that's a pun!
Re: reddit.com: first Chapter of TDPL available for free
On Mon, Aug 3, 2009 at 7:40 PM, Robert Fraserfraseroftheni...@gmail.com wrote: Nick Sabalausky wrote: One little niggle though: At the end of the paragraph that explains the hello world's import statement, it says Repeated imports of the same file are of no import. Sounds like a typo snuck in there. Or a pun ;-P. The mailing list lag is killing me.
Re: C++0x Concepts - Dead?
On Thu, Jul 16, 2009 at 5:03 PM, Walter Brightnewshou...@digitalmars.com wrote: Jarrett Billingsley wrote: Let's try to *simplify* metaprogramming and make things *orthogonal* instead of tacking on features with no regard to the existing ones. Type matching cannot do what expression matching can do. You'd need a totally new syntax anyway to bring expression matching into the template type parameter list. Wow, can you say taken out of context? I proposed the *exact* opposite. Note: template X(T: A, U: B) would basically be syntactic sugar for template X(T) if(is(T: A) is(U: B))
Re: dmd 1.046 and 2.031 releases
On Thu, Jul 16, 2009 at 6:43 PM, Jason Housejason.james.ho...@gmail.com wrote:
bearophile Wrote:
I'm playing with the new D2 a bit, this comes from some real D1 code:
void main(string[] args) {
int n = args.length;
ubyte m = (n = 0 ? 0 : (n = 255 ? 255 : n));
}
At compile-time the compiler says:
temp.d(3): Error: cannot implicitly convert expression (n = 0 ? 0 : n =
255 ? 255 : n) of type int to ubyte
You have to add a silly cast:
void main(string[] args) {
int n = args.length;
ubyte m = (n = 0 ? 0 : (n = 255 ? 255 : cast(ubyte)n));
}
In theory if the compiler gets a smarter such cast can be unnecessary.
Bye,
bearophile
add it to bugzilla.
Bearophile has never reported anything in Bugzilla. It's
inexplicable. He constantly complains about D and does nothing to
help it.
Re: C++0x Concepts - Dead?
On Mon, Jul 13, 2009 at 5:33 PM, Walter Brightnewshou...@digitalmars.com wrote: There are unconfirmed reports that this morning, the C++0x standards group in Frankfurt voted to kill Concepts. Oh, wow.
Re: C++0x Concepts - Dead?
On Mon, Jul 13, 2009 at 5:46 PM, Jarrett Billingsleyjarrett.billings...@gmail.com wrote: On Mon, Jul 13, 2009 at 5:33 PM, Walter Brightnewshou...@digitalmars.com wrote: There are unconfirmed reports that this morning, the C++0x standards group in Frankfurt voted to kill Concepts. Oh, wow. I mean, really, I'm kind of speechless. I thought they were supposed to be one of the killer features.
Re: C++0x Concepts - Dead?
On Mon, Jul 13, 2009 at 5:59 PM, Andrei Alexandrescuseewebsiteforem...@erdani.org wrote: Jarrett Billingsley wrote: On Mon, Jul 13, 2009 at 5:46 PM, Jarrett Billingsleyjarrett.billings...@gmail.com wrote: On Mon, Jul 13, 2009 at 5:33 PM, Walter Brightnewshou...@digitalmars.com wrote: There are unconfirmed reports that this morning, the C++0x standards group in Frankfurt voted to kill Concepts. Oh, wow. I mean, really, I'm kind of speechless. I thought they were supposed to be one of the killer features. You were at the wrong tense: -ing, not -er. :o) Ahaha, good one :) Yeah, what's the solution to a complex, incomprehensible language? More complexity!
Re: dmd 1.046 and 2.031 releases
On Tue, Jul 7, 2009 at 11:33 AM, Andrei Alexandrescuseewebsiteforem...@erdani.org wrote: Well 32-bit architectures may be a historical relic but I don't think 32-bit integers are. And I think it would be too disruptive a change to promote results of arithmetic operation between integers to long. ... This is a different beast. We simply couldn't devise a satisfactory scheme within the constraints we have. No simple solution we could think of has worked, nor have a number of sophisticated solutions. Ideas would be welcome, though I need to warn you that the devil is in the details so the ideas must be fully baked; too many good sounding high-level ideas fail when analyzed in detail. Hm. Just throwing this out there, as a possible solution for both problems. Suppose you kept the current set of integer types, but made all of them open (i.e. byte+byte=short, int+int=long etc.). Furthermore, you made it impossible to implicitly convert between the signed and unsigned types of the same size (the intuint hole disappears). But then you introduce two new native-size integer types. Well, we already have them - ptrdiff_t and size_t - but give them nicer names, like word and uword. Unlike the other integer types, these would be implicitly convertible to one another. They'd more or less take the place of 'int' and 'uint' in most code, since most of the time, the size of the integer isn't that important.
Re: MiniD 2 - Might as well be done
On Tue, Jun 16, 2009 at 3:58 AM, Nick Sabalauskya...@a.a wrote: Jarrett Billingsley jarrett.billings...@gmail.com wrote in message news:mailman.264.1245108702.13405.digitalmars-d-annou...@puremagic.com... I recommend you read the spec and the language tutorial if you're wondering what the language is all about. Where is the language tutorial? On the front page, in the section marked language tutorial. ;) http://www.dsource.org/projects/minid#LanguageTutorial Some of the later pages aren't yet complete, but I've got nothing but time. = You're drunk, aren't you? = A little. lol. Watch out for the localized glitches in gravity :) Hehe :)
Re: MiniD 2 - Might as well be done
On Tue, Jun 16, 2009 at 10:31 AM, Robert Clipshamrob...@octarineparrot.com wrote: Jarrett Billingsley wrote: Any questions, just ask, please! Congrats on finally making a release! The only question I have really, is do you plan on making some release binaries/libraries? You mentioned about the tool chain being difficult to use, it might be nice if there were some premade binaries/libraries people could use to play with mdcl/minid. That's a very good idea. :) http://svn.dsource.org/projects/minid/trunk/mdcl.zip It contains binaries for both Windows and Linux (32-bit).
Re: MiniD 2 - Might as well be done
On Tue, Jun 16, 2009 at 10:54 PM, Jesse Phillipsjessekphill...@gmail.com wrote: On Wed, 17 Jun 2009 00:39:01 +0200, BLS wrote: Why not writing a book about D, Jarrett ? The MiniD documents are excellent. In fact you, respective what you write, reminds me to Jesse Liberty + Humor. (well,... maybe C++ in 21 days was already a joke) but nevertheless Jesse's book was a kind of eye opener to me simply because it shows that is IS possible to explain difficult stuff in a smart way. So why not JB on D...? In case of doubt : I am willing to send you a bottle of fine Cognac to give the book a very first go. (not kidding) However, guess like anybody else, I just can say: Thanks for this interesting new language. Björn I agree in regards to both Jarrett having good documentation on MiniD and Jesse Liberty being a good author leading to the conclusion that Jarrett should write a book on D. While I have yet to use MiniD, the language looks very impressive and complete. Good work Jarrett. Thanks.
Re: MiniD 2 - Might as well be done
On Wed, Jun 17, 2009 at 1:06 AM, BLSwindev...@hotmail.de wrote: Jarrett Billingsley wrote: On Tue, Jun 16, 2009 at 6:39 PM, BLSwindev...@hotmail.de wrote: Why not writing a book about D, Jarrett ? The MiniD documents are excellent. In fact you, respective what you write, reminds me to Jesse Liberty + Humor. (well,... maybe C++ in 21 days was already a joke) but nevertheless Jesse's book was a kind of eye opener to me simply because it shows that is IS possible to explain difficult stuff in a smart way. It's funny you mention Jesse Liberty's C++ in 21 days. Guess what was the first programming book I ever read? ;) Maybe it influenced me? I would bet on it. NO You are kidding me. Ha! No, I'm serious. :) So why not JB on D...? In case of doubt : I am willing to send you a bottle of fine Cognac to give the book a very first go. (not kidding) It'd certainly be an interesting proposition. I also don't know if writing a book on D _now_ is the best idea. If it were based on D1, it might just be obsolete in two or three years. If it were based on D2, well, Andrei has a much better idea of where it's going than I do, and I also doubt Phobos2 has seen the last major changes. But maybe in a bit, when things settle down. I can see a D2-Phobos2 based book next year-ish being much more solid. Well the Cognac can wait and becomes better, not that sure about you... :) However, a promise is a promise. Just marked one with Jarret. (Hint for me ' don't touch) :D However, guess like anybody else, I just can say: Thanks for this interesting new language. Sure! No seriously.
MiniD 2 - Might as well be done
I'm bad at meeting deadlines. Partly because I mismanage my time, but a large part of it is also because being a perfectionist, I never know when to _stop working on something_. After nearly two years in development, I think I'm ready to call MiniD 2 gold. http://www.dsource.org/projects/minid I write lots of docs. Please read them. = Oh wow, an interpreted version of D! = NO! That was the aim _three years ago_ but by now it's a completely different language. Please read the docs before you form your opinions on what it is :) = What's changed since MiniD 1? = Lots. It's enough to say that it's practically a different language. To be honest, I don't even consider MiniD 1 - either the language or the implementation thereof - anything more than a crude, unfinished work. MiniD 2 is what I consider to be the first _actual_ language/implementation. The MiniD 2 reference implementation is far more mature, complete, and efficient than its predecessor. It has been reimplemented pretty much from scratch and now features its own heap and GC separate from D's. While this does incur a bit of a hit on the terseness of the native API, it also manifests itself in a frankly _incredible_ increase in performance, as well as features that would have been difficult or impossible to implement using the native GC (like weak references and class finalizers). What kind of performance, you ask? Well, almost every test I've run kicks the crap out of Python, and is more in the ballpark of Lua. The only tests that don't quite measure up are those which are GC-heavy. The current implementation uses a simple mark-and-sweep GC, but that is one of my main development priorities after this release. If I can reach Lua's performance - awesome! The API is much more like Lua's now, though with some nice perks due to overloading that aren't possible in a C API. Writing code for what is essentially a stack language is kind of nice, in some ways. Being such a departure from what most people are used to, though, it can take some getting used to. The API is also much more there is one way to do it. The old MiniD 1 - and early MiniD 2 - APIs sometimes had several, inconsistent methods of acquiring information. This has been entirely done away with. That being said, D's current protection mechanisms (and DMD's forward reference issues) are woefully inadequate for dividing up the API the way I want to, forcing almost all of the public API functions into a single module. Sorry for that. = I'm bearophile, and I don't think it performs as well as X, and isn't similar enough to Python. = OK. Give me some benchmarks, and I'll see what's taking so long. As for the language style? Tough luck ;) I admit the standard library probably doesn't have as many lazy-evaluation functions and datatypes as it could, but that can certainly change. I am open to suggestions! = Why do I need it? = I don't know! Maybe you're just interested in learning new languages. Maybe you've got a legitimate need for a scripting language in one of the D apps you're writing. Whatever. I can't tell you why you need it. Only you know that. For a high-level, pseudo-philosophical introduction to the language, see http://www.dsource.org/projects/minid/wiki/Introduction2 I recommend you read the spec and the language tutorial if you're wondering what the language is all about. _Then_ can you tell me what you do and don't like. = What prerequisites do I need, and how do I install it? = D1 with Tango 0.99.8, currently. That's about it, as far as the core language and its standard libraries are concerned. Installation instructions are available here: http://www.dsource.org/projects/minid/wiki/Installation I plan on putting some more detailed docs up especially w.r.t. feti's sandbox script, since I haven't been able to get some configurations to work. If you're having trouble installing a D compiler or build tool or Tango, I'm sorry, but I just don't have the time or patience to help you install the prerequisites. I have spent far too much time helping others install those and it's just.. well, it's not my fault that the D toolchain is currently so fractured and hard-to-use, and I've kind of lost the will to help anyone else. Sorry :\ MiniD works fine with DMD and LDC. GDC is too old to compile it. Bug David Friedman or Arthur about that. :| = How do I x? = Please ask me. Here on the newsgroups is OK, but for more long-term conversations, *please* sign up for a dsource account and post your questions to the MiniD dsource forum (http://www.dsource.org/forums/viewforum.php?f=94). If you don't have a dsource account already, why not? ;) If you're one of those people who refuses to post on one of those dirty, slow, inefficient web forums, well, I guess you're not getting any help! Or you could just email me, but by doing that, you'll be depriving anyone else from seeing your question and the resulting answer. Your choice. I love writing
Re: TDPL available for preorder on amazon.com
On Thu, Jun 11, 2009 at 1:05 AM, Saaaem...@needmail.com wrote: Hope you like the cover - my sister's art. http://tinyurl.com/lyrsyk Andrei The first programming book I'll buy :) 500 pages.. is that normal for programming books? What he's not telling you is that the pages are only 10cm square ;)
Re: TDPL available for preorder on amazon.com
On Wed, Jun 10, 2009 at 1:27 AM, Andrei Alexandrescuseewebsiteforem...@erdani.org wrote: Hope you like the cover - my sister's art. http://tinyurl.com/lyrsyk Andrei Wow, I'm pretty excited. I think I might preorder this.
Re: TDPL available for preorder on amazon.com
On Wed, Jun 10, 2009 at 6:41 PM, Tim Matthewstim.matthe...@gmail.com wrote: bearophile wrote: I'll probably write a review in my language when possible. What language would that be? Or do you mean your blog? He means Italian, I think.
Re: ldc 0.9.1 released
On Wed, May 27, 2009 at 2:19 PM, Christian Kamm kamm-incasoftw...@removethis.de wrote: The release 0.9.1 of LDC, the LLVM based compiler for the D programming language, contains the following major improvements: * lots of bug fixes (http://www.dsource.org/projects/ldc/report/15) * x86-64 support is mature * inline asm improved (we now define D_Inline_Asm) * cross-compilation support * uses boehm-gc during compilation (x86-32 only) * D specific optimizations: * turn GC allocations to allocas if possible * simplify or remove certain calls to D runtime functions The command line interface of LDC now has added options in line with other LLVM based tools. Please use the ldmd wrapper if you want a drop-in replacement for DMD. Linux x86-32 download: http://www.incasoftware.de/~kamm/ldc/ldc-0.9.1-x86_32.tar.bz2 Linux x86-64 download: http://www.incasoftware.de/~kamm/ldc/ldc-0.9.1-x86_64.tar.bz2 Rock on!
Re: OT: Flash and Javascript (Was: Taunting)
On Sun, May 24, 2009 at 4:39 PM, Nick Sabalausky a...@a.a wrote: Jarrett Billingsley jarrett.billings...@gmail.com wrote in message news:mailman.165.1243195228.13405.digitalmars-d-annou...@puremagic.com... I'm starting to get the impression that you just have a _really slow Javascript interpreter_ in your browser. I have no idea what you're talking about with text input lag. I have never experienced that. And the Tango API opens in about 2 seconds with JS enabled for me. What browser are you *using*? Oh I do have a notably slow JS interpreter (FF). But that's completely beside the point. A web page should be designed to work properly (and that includes responsiveness) on *any* major browser. Anything less is just plain irresponsible. Also, what kind of computer do you have? Some sort of multi-core 64-bit? I don't care if that's all that the stores are currently trying to sell, there's no excuse for responsive *web browsing* to require that kind of hardware. I use Firefox too. My computer isn't even a fire-breathing monster by today's standards: Athlon X2 64 4600+, but it's running in 32-bit mode. And if you don't want to keep your hardware new enough to match the demands of modern software, no matter how badly-engineered you deem it, well, you'll always be bitching about how slow everything is. If you have usability issues, it's on your end. I don't. My computer, and everything I access on the internet, are perfectly responsive. Are you going to continue blaming everyone else, or are you just going to get a new machine? They're like $12 now.
Re: OT: Flash and Javascript (Was: Taunting)
On Sun, May 24, 2009 at 5:12 PM, grauzone n...@example.net wrote: to get a new machine? They're like $12 now. Where can I buy 12$ computers? lern2hyperbole.
Re: Taunting
On Sat, May 23, 2009 at 4:27 PM, Nick Sabalausky a...@a.a wrote: BCS n...@anon.com wrote in message news:a6268ff63c58cba9bbc96d8...@news.digitalmars.com... Hello Nick, what they can do is additionally provide a non-youtube/flash version. Which should be really [censored] easy since they had to have already had one in order to upload it to craptube in the first place. Ha ha, you censored the f^*^*? :) If they can, yes, but they might not have access to general file hosting or if they do, the bandwidth to steam video. 1. Sure, some people may not, but considering how cheap and easy good hosting packages are these days, I find it hard to believe that, out of a group of programmers, any more than a small minority wouldn't have reasonable hosting. I mean look at me, I can't afford basic airfare to go to a conference (or any of the repairs that my car currently needs), but I still have a gig or so of hosted space and about 100x as much bandwidth as I'm actually using. Or, you know, maybe we could stop reading so much into Ary's _completely understandable decision_ to host a short video on _the largest video hosting site in the world_. Give me a break. You guys act like it's a fucking affront to your religion to have to use Flash or Youtube.
Re: Split digitalmars.D newsgroup into .D and .D2 newsgroups?
On Mon, May 11, 2009 at 8:26 PM, Walter Bright newshou...@digitalmars.com wrote: Is this a good idea? My gut reaction is 'yes'. But what would be left on .D without the hundred-post threads about ranges? There really _isn't_ that much conversation about D1, and most of it probably belongs on .D.learn anyway. Somewhat offtopic: I get the impression, from using the D IRC channels, that a lot of newcomers are far more influenced into reading about and using D2 by the Digital Mars site than by how the newsgroups are divided. The site guides you right into the D2 spec and compiler without ever really explaining that D2 is in beta, or that there are practically no libraries for it, or that virtually everyone who is using D for production code is using D1. You get to the D site; what do you do? Click overview, naturally. You read through that, and every one of the links is into the D2 spec. The D 1.0 link at the top left has also disappeared. And of course, since bigger numbers *must* be better, D1 is probably old and unsupported, right! Maybe there should be a foyer page which explains the purpose, status, and future plans for both D1 and D2 (like I think it was Derek who said, nowhere on the DM site is it mentioned that D1 is still supported!). Then and only then should visitors have the opportunity to see the rest of the appropriate spec.
Re: Planet D is back
On Fri, May 8, 2009 at 5:55 PM, Christian Kamm kamm-incasoftw...@removethis.de wrote: The Planet D aggregator at http://planet.dsource.org is being updated again! Thanks go to Anders Bergh, who made it and provided me with the necessary files. I noticed 29 new items in my reader today! :D
Re: dmd 2.029 release [OT]
On Thu, Apr 23, 2009 at 2:32 PM, Georg Wrede georg.wr...@iki.fi wrote: (OT: an excellent example of this It's Done Because We Noticed We Could stuff is in Firefox. When a picture is a link to another page, and you want to drag that to the tab area, the entire picture is dragged with the mouse. Now, how the hell am I supposed to hit the small tab area when the large picture covers half of my Firefox?? Sure it looks good, and the computer owner can brag to the guy in the next cubicle, etc. But there should be some obvious or useful *purpose* for dragging entire pictures where a mouse pointer would be clearer, cleaner, easier for the user, and use less computer cycles. I mean, who's such a nutcase that he forgets halfway in the dragging, what it is he's dragging? Middle-click.
Re: dmd 2.029 release
On Thu, Apr 23, 2009 at 6:01 PM, Christopher Wright dhase...@gmail.com wrote:
Andrei Alexandrescu wrote:
Yes. The way it should be is not with sink, but with the standard output
iterator method put().
void streamOut(T, R)(T object, R range)
{
foreach(x; a) range.put(x);
range.put(b);
range.put(c);
}
// object.d
class Object
{
void streamOut(R)(R range);
}
No?
No. Templated methods are not virtual.
Re: ACCU conference
On Wed, Apr 22, 2009 at 8:29 PM, Christopher Wright dhase...@gmail.com wrote: Georg Wrede wrote: Walter Bright wrote: I'm off to speak at it! http://accu.org/index.php/conferences/accu_conference_2009/accu2009_speakers Next time you come over to the Old World, why not fly back a day later. Then a few of us might get together. A mini D-meeting wouldn't hurt. It could be interesting and fun! Nor would a MiniD meeting. It would hurt me. On the inside. Because I wouldn't be there.
Re: I'm curious: when will D2 be declared stable?
On Wed, Mar 25, 2009 at 5:50 PM, bearophile bearophileh...@lycos.com wrote: Jarrett Billingsley: What makes you have any expectation that Walter has anything to do with LLVM? Isn't LLVM open source? So anyone can help, especially if such person finds someone willing to pay for such work. Suuure, but do you honestly think Walter's going to drop everything he's doing and work on a project that he is currently not involved in in any way, to support a compiler that he didn't make? It just seems very unlikely, is all.
Re: Descent 0.5.4 released
On Sat, Mar 21, 2009 at 7:23 PM, Saaa em...@needmail.com wrote: Poseidon has 7 (custom) groups of keywords which have different colours. eg. import=orange, static=green, void=blue, this=purple To me it makes source much easier to navigate. Honestly I don't know how people can cope with that.. if you use 30 colors, don't they stop having meaning? :|
Re: Descent 0.5.4 released
On Mon, Mar 23, 2009 at 9:00 PM, Ary Borenszweig a...@esperanto.org.ar wrote:
Jarrett Billingsley escribió:
On Sat, Mar 21, 2009 at 7:23 PM, Saaa em...@needmail.com wrote:
Poseidon has 7 (custom) groups of keywords which have different colours.
eg. import=orange, static=green, void=blue, this=purple
To me it makes source much easier to navigate.
Honestly I don't know how people can cope with that.. if you use 30
colors, don't they stop having meaning? :|
Yes, I think the code will look like a mess. But maybe he's talking about
primitive types with one color, attributes with other, etc. But something
like:
public static void ... {
}
with three different colors would just call my attention too much and I
won't be able to focus on the real code. :-P
The worst offender, by far, is the D highlighter for Kate. It has 24
separate styles for various syntactico-semantic elements, all of which
have different colors by default. It looks like a rainbow vomited.
It's just so distracting :P
Re: Blaze 2.0
On Tue, Mar 17, 2009 at 6:54 PM, Mason Green mason.gr...@gmail.com wrote: Brian wrote: I don't know how different Blaze 2.0 is from the version i had, but I'll take a look when I get a chance and see if I can be of any help. I'm using Box2D for the time being because there were still GC issues, but I'm very excited about smoothed partial hydrodynamics and non-convex models/partitioning. Blaze 2.0 is 90% Box2D, using all the same algorithms for the CPU intensive tasks. All I did was add smoothed particle dynamics, and force generators from the Motor2 engine. The new version is much, much different from Blaze 1.0. Motor2 has a few other features that I may eventually incorporate, but as I mentioned, for all practical purposes Blaze 2.0 is pretty much a straight port of Box2D. Performance should be on par with the Java and Action Script variants of Box2D, aside from their more efficient garbage collectors. If there are D specific tricks I can use to speed up the engine, I would definitely appreciate the help and/or contribution. Using value types where possible would probably help. Porting the SOA from the C++ version of Box2D would probably also give a tremendous speedup (and fewer GC pauses), though I don't know what effects that would have on the API. The way it is now is really noticeably GC-bound. On some of the more complex testbed scenes (like the compound bodies test), there's a noticeable pause every two seconds or so.
Re: Blaze 2.0
On Mon, Mar 16, 2009 at 9:24 PM, Bill Baxter wbax...@gmail.com wrote: The video card you have, and which drivers you are using for it, might be more relevant factors than the speed of your CPU. GeForce 8600 512MB, version 181.22 of the official drivers.
Re: Blaze 2.0
On Mon, Mar 16, 2009 at 7:38 PM, Jarrett Billingsley jarrett.billings...@gmail.com wrote: On Mon, Mar 16, 2009 at 3:44 PM, Mason Green mason.gr...@gmail.com wrote: Blaze 2.0, a 2D game physics engine based on Box2D, is finally here. The testBed examples have been completely overhauled with Hybrid and Dog! Project page: http://www.dsource.org/projects/blaze/wiki/WikiStart Testbed examples (win32 binary): http://svn.dsource.org/projects/blaze/downloads/blazeDemos.zip I've taken a stab at writing a `getting started` section on the wiki, with clear (hopefully) instructions on how to compile. Comments, suggestions, contributions, and bug reports are appreciated in the dsource forum. I get really strange performance. It runs.. choppy. Not slow framerate, just really choppy, in a nondeterministic manner. The Hybrid controls are also incredibly sensitive - one button press sets them to absurdly large/small values, usually freezing/crashing the app. My computer should be able to more than handle this. It's a dual-core Athlon X2 4600+. I've tried messing with all my driver's 3D settings to no effect. The framerate is like.. like it's running at 60fps, and then it'll just skip a bunch of frames. Like it suddenly processed way faster than the screen was able to update. It does this constantly - just switching between normal speed and super-fast a few times a second at seemingly random intervals.
Re: Blaze 2.0
On Mon, Mar 16, 2009 at 9:56 PM, Bill Baxter wbax...@gmail.com wrote: On Tue, Mar 17, 2009 at 10:33 AM, Jarrett Billingsley jarrett.billings...@gmail.com wrote: On Mon, Mar 16, 2009 at 9:24 PM, Bill Baxter wbax...@gmail.com wrote: The video card you have, and which drivers you are using for it, might be more relevant factors than the speed of your CPU. GeForce 8600 512MB, version 181.22 of the official drivers. Sounds like that should be capable. If you're motivated enough you could try installing the 182.08 drivers to see if that fixes it. Ah, that fixed it! Good idea, I didn't consider it since I only just updated my drivers a couple weeks ago. Figures.
Re: Open source dmd on Reddit!
On Thu, Mar 12, 2009 at 12:46 PM, Leandro Lucarella llu...@gmail.com wrote: Free Software is a very ambiguous term too (many people think of free as in no charge). Unfortunately English is a very crappy language ;) I think with the absurd preponderance of FLOSS proponents saying free as in freedom! the term free software really cannot be interpreted as anything *but* FLOSS anymore. Frankly I'm sick of hearing free as in freedom! and libre! all the goddamn time, I know what is meant :P
Re: Open source dmd on Reddit!
On Thu, Mar 12, 2009 at 7:49 PM, Ary Borenszweig a...@esperanto.org.ar wrote: In the company I work we just finished building a website, chose a name for it, and we still don't know how it is pronounced in English. We only have suppositions. :-P NAY-un or NAY-oon would be by guess.
Re: dmd 1.041 and 2.026 releases
2009/3/5 Walter Bright newshou...@digitalmars.com: http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.041.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.026.zip From the backend license: The Software was not designed to operate after December 31, 1999. Well that explains EVERYTHING! ;)
Re: Boost.ScopeExit based on D's scope(exit)
On Wed, Mar 4, 2009 at 6:11 PM, Walter Bright newshou...@digitalmars.com wrote: Linux has actually gotten a lot better. As late as 2000, even gnu make couldn't read makefiles with CR's in them. OT - it's weird to think that that was almost a decade ago. Ten years! 2000 used to sound so futuristic, and now it sounds quaint :P
Re: QtD 0.1 is out!
On Sun, Mar 1, 2009 at 10:16 AM, Don nos...@nospam.com wrote: The D system has a major limitation, though -- you can't split the source for a module across multiple files. Which pushes you towards enormous source files. It's more restricted than both C# and C++ in this respect. Yeah. Imagine if DMDFE were written in D; how big would those modules have to be?
Re: Poppler
On Sat, Feb 28, 2009 at 5:40 AM, áîáåô bo...@abv-nospam.bg wrote: Hi guys, if someone is interested in wrapper classes for Poppler (pdf library) - give me a note at afrikanski at gmail dot com. Regards, bobef Why don't you release them publicly?
Re: QtD 0.1 is out!
On Sat, Feb 28, 2009 at 3:05 PM, Walter Bright newshou...@digitalmars.com wrote: Christopher Wright wrote: Additionally, the compiler has sufficient information to complain about the problem at compile time, but it doesn't. That is a bug. No, it does not. The compiler doesn't know about private imports of separately compiled modules. See it's funny, since in the other post, you said that using an autogenerated header file is semantically indistinguishable from compiling it to a metadata file. And here you're pointing out an obvious shortcoming!
Re: Just one more thing...
On Sat, Feb 28, 2009 at 10:52 PM, Daniel Keep
daniel.keep.li...@gmail.com wrote:
extern(C) void __identifier(blah$UNIX2003)(int);
A beneficial side-effect is that I can finally get rid of all those
mixins that are just doing this:
mixin(`void `~name_of_fn~`(int a)
{
// ... rest of function ...
}`);
Yes, please, Jesus I'd love that.
Re: QtD 0.1 is out!
On Fri, Feb 27, 2009 at 12:36 PM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: We faced a bug that module static constructors don't work with cyclic imports. Currently it's fixed with a dirty hack which is not really acceptable. Is there any chance for this to be fixed? I'll save Walter the trouble: come up with a reproduceable testcase if you haven't already. It won't get fixed it he can't tell what the problem is.
Re: QtD 0.1 is out!
On Fri, Feb 27, 2009 at 5:07 PM, Walter Bright newshou...@digitalmars.com wrote: Eldar Insafutdinov wrote: in our case resources we are initializing are unrelated to the modules we are importing. and semantically the code is placed in modules as it should be. True, often there isn't an actual dependency on the order, but the compiler can't tell that. I was going to say can't it? but then remembered separate compilation. Sigh. I think the separate compilation paradigm, at least as designed for C and C++, has to go the way of the dodo for lots of cool things to be made possible. The thread on .D about not being able to non-virtualize methods in the face of separate compilation is another example.
Re: Just one more thing...
On Thu, Feb 26, 2009 at 8:39 PM, Walter Bright newshou...@digitalmars.com wrote: Can you upgrade to 10.5 ? That costs money.
Re: QtD 0.1 is out!
On Sun, Feb 15, 2009 at 9:27 PM, Eldar Insafutdinov e.insafutdi...@gmail.com wrote: The reason why is this file is big is in this bug http://d.puremagic.com/issues/show_bug.cgi?id=282 And I don't thing that placing enums outside the class is a good idea, because enums will be exposed to global namespace unlike original Qt version. I have just checked, if enum A belongs to qt.core.Qt module you can't access it like Qt.A - which means that we have to keep that file big until this bug is fixed. Anyway, I tried to place enums outside the classes, and I got: qt/core/QFile.d(24): Error: enum FileError is forward referenced qt/core/QFile.d(24): Error: enum FileError is forward referenced qt/core/QFile.d(24): Error: enum FileError is forward referenced qt/core/QFile.d(24): Error: enum FileError is forward referenced qt/core/QFile.d(24): Error: enum FileError is forward referenced qt/core/QFile.d(24): Error: enum FileError is forward referenced qt/core/QFile.d(24): Error: enum FileError is forward referenced qt/core/QFile.d(24): Error: enum FileError is forward referenced Circular import is present. You would do well to remove all circular imports. They make the compiler do stupid things.
Re: Descent 0.5.4 released
On Tue, Jan 27, 2009 at 12:05 PM, Jarrett Billingsley jarrett.billings...@gmail.com wrote: On Tue, Jan 27, 2009 at 10:46 AM, Ary Borenszweig a...@esperanto.org.ar wrote: Here's the video! http://www.youtube.com/watch?v=oAhrFQVnsrY I kind of just exploded a little watching that. Some of my brain is coming out. In a good way, of course.
Re: DMD 1.039 and 2.023 releases
On Wed, Jan 7, 2009 at 12:31 AM, Walter Bright newshou...@digitalmars.com wrote: Regarding the pure optimizations done by D2, how can the LDC compiler do the same? Are them done by the front-end? I changed nothing with the compiler. I just rewrote the runtime long division function. Can you say non sequitur? He asked about pure optimization, not long division.
Re: DMD 1.039 and 2.023 releases
On Tue, Jan 6, 2009 at 11:03 PM, Bill Baxter wbax...@gmail.com wrote: 2009/1/7 Walter Bright newshou...@digitalmars.com: Faster long divides! No progress on faster long compiles though? --bb The D2 changelog says that he undid the fix to 2500, which might be the cause. But no word on whether it was the cause, or if D1 got the revert as well.
Re: DMD 1.039 and 2.023 releases
On Tue, Jan 6, 2009 at 11:51 PM, Walter Bright newshou...@digitalmars.com wrote: Jarrett Billingsley wrote: The D2 changelog says that he undid the fix to 2500, which might be the cause. But no word on whether it was the cause, or if D1 got the revert as well. D1 got the same reversion. Wee!
Re: New DigitalMars D newsgroups/forum
On Tue, Dec 16, 2008 at 8:58 PM, Denis Koroskin 2kor...@gmail.com wrote: I have been working on new newsgroups archive last few days. This is an newsgroup posts archive structured in a way so that it feels more like a forum (that's what you demanded, right?). Currently it is readonly, updated infrequently and have some known bugs. Testing needed! User registration, post submition (of course!), post editing/removal, search (per forum/per thread etc) - not supported atm (but will be soon!) Forum theme is copyrighted and needs to be changed by something free. Feedback, bugs detected, suggestions etc are *very* much appreciated! Check it out: http://dnews.naxx.ru Wow, this looks fantastic. I can't wait to use it :) One thing I notice, though - maybe it's not noticeable on larger screens - but on my laptop, the content is not centered. The left side of the content starts about 1/4-1/3 of the way across the screen so that all the content is smushed against the right side.
Re: New DigitalMars D newsgroups/forum
On Tue, Dec 16, 2008 at 9:37 PM, BCS a...@pathlink.com wrote: Reply to Denis, I have been working on new newsgroups archive last few days. This is an newsgroup posts archive structured in a way so that it feels more like a forum (that's what you demanded, right?). COOL I hit this page: http://dnews.naxx.ru/topic.php?id=117556 and it started trying to download and save files. Is that a bug? (FF2) Same here, with FF3. It seems to want to download the raw messages rather than putting their text into the page. I just figured it's very early in development now.
Re: MiniD 2 - Tentative Release Candidate 1
On Wed, Dec 10, 2008 at 11:45 PM, Jarrett Billingsley jarrett.billings...@gmail.com wrote: I think if MiniD is able to do the syntax I proposed, I wouldn't have those bunch questions about foreach on a coroutine function. And People won't expect do foreach on a coroutine in most cases if that syntax comes true. Because for most people, a coroutine opApply is more intuitive than a coroutine with an opApply method available. I've considered making coroutines a basic iterable type, in which case their opApply would disappear. (it would also make the dummy first index disappear.) And they are now :)
Re: MiniD 2 - Tentative Release Candidate 1
On Sat, Dec 13, 2008 at 11:53 PM, davidl dav...@126.com wrote: Cool, I've learned Scala a bit that I miss several things in scala. 1.Case class I'm not familiar with what a case class is, could you demonstrate? 2.threading I'm sorry but I don't think SMP will ever make it into the language. It is open-source, so you're free to modify it and add it if you want.
Re: MiniD 2 - Tentative Release Candidate 1
On Sun, Dec 14, 2008 at 12:09 AM, Jarrett Billingsley jarrett.billings...@gmail.com wrote: 2.threading I'm sorry but I don't think SMP will ever make it into the language. It is open-source, so you're free to modify it and add it if you want. Erm, not necessarily SMP, just preemptive multithreading. Probably not going to be added, ever.
Re: Anyone use twitter for D?
On Sun, Dec 14, 2008 at 12:17 AM, John Reimer terminal.n...@gmail.com wrote: Hello Nick, Walter Bright newshou...@digitalmars.com wrote in message news:ghs5kf$9d...@digitalmars.com... I started one to see how that works out for D. http://twitter.com/WalterBright Call me a curmudgeon, but does anyone ever read twitters? They seem to be enormously popular to write, though I've never understood why. (Maybe I'm just not a web 2.0 kind of guy - I've never cared for social networking sites, either.) I find it odd too and fail to see why the fad attracts people. I'm guessing that the popularity of it is due the attraction the idea has for certain personality types: something like an opportunity for the less expressive to express themselves free of the obligations rigour (no more thought to choosing words carefully, I suppose). In the manner of blogs, maybe people just like talking about themselves... only twitter seems to take it once step further, where the reader is entertained with decidedly less thought provoking material. I just don't get it. Maybe I should /not/ be looking at twitter as an information resource. But if it's just a way people can connect with one another to let each other know they are there, then all they really need is a flashy red or green light. Add to that a beeping noise for extra effect. The other alternative is that it's just yet another marketing scheme that has succeeded in making people think that it's the thing to do. I'm sure facebook fans would eat this one up. :) The last option is that I'm just a boring killjoy that doesn't get it. I dunno ;). But I'm sure this isn't the last clever idea to make it's rounds on the internet. I found this article pretty interesting, at least as far as an insight into what some people see in Twitter and similar services. http://tinyurl.com/6ng7tg
Re: MiniD 2 - Tentative Release Candidate 1
On Thu, Dec 11, 2008 at 2:06 AM, davidl [EMAIL PROTECTED] wrote: Another thing is I really didn't pay attention to parallel in MiniD. So , the thread is not tradition thread in D? It's actually just a coroutine? Right; it's more like a Fiber from Tango (and is implemented using Fibers depending on the compilation options). I just thought that coroutine was implemented as several different MiniD interpret context for each coroutine, and resume a coroutine just simply resuming that interpret context which could be very costless. You're actually right, in a way; each thread object is its own _interpreter_, which has a call stack and locals. But each thread is _not_ its own VM; that is, all threads share the same globals and data can be freely passed between them. In MiniD, coroutine == thread. coroutine creates a thread object. And the thread I though could be some native threads with several MiniD interpreters working. MiniD was not designed with symmetric multithreading as a goal. However, it would still be possible to make a library which you could use to create and use other VMs from within MiniD. It's been done with Lua.
Re: MiniD 2 - Tentative Release Candidate 1
On Wed, Dec 10, 2008 at 3:15 AM, davidl [EMAIL PROTECTED] wrote:
在 Wed, 10 Dec 2008 13:52:18 +0800，Jarrett Billingsley [EMAIL PROTECTED] 写道:
It's cool it could be used in that syntax. But I find nowhere of docs
describing this feature?
Do I miss something?
Yeah, you do. I gave you a link in my last post. See at the end? Go
there and read all about it.
Actually I tried something like:
module test
global v=coroutine function()
{
local opApply=coroutine function opApply(m)
{
local i=0
if (i3) {
i++
yield(i)
}
return null
}
yield()
}
v()
foreach(m;v)writefln(m)
No wonder it didn't work, it's completely the wrong way to do it. ;)
In the case I wrote, the coroutine foreach just conflicts with the coroutine
foreach way you illustrate
in your example. As I didn't have that information, I tried to perform my
coroutine foreach in a standardized
opApply way. That's somewhat confusing for people not having the knowledge of
coroutine foreach.
Intuitively, the foreach is presumably working in the way of calling
instance's opApply func and passing the arg
of reverse or not to it. While the truth is I'm wrong.
The thing is, it _does_ work by calling the coroutine's opApply. It's
just that you don't define opApply yourself. Think about it - you
don't put an opApply in an array to foreach over it. How can you
opApply over it? Because array.opApply is defined by the standard
library. The same thing for coroutines.
http://www.dsource.org/projects/minid/wiki/StdLib2/ThreadLib#Threadmetamethods
That shows where opApply is defined for thread (coroutine) objects.
Which again links to the page I gave you in my last post.
The inconsistency seems to be a tradeoff. Yes, without opApply it looks
clean. While it's inconsistent. That means
developers who use minid need to learn more.
Again, it's not inconsistent, as coroutines _do_ have an opApply.
The following case illustrates a easily misread code for me at least. In
minid, I thought the parentheses
were compulsive, cause the coroutinefunc.state won't work, but
coroutinefunc.state(). So in such case, I guess the
count refers to the function object, while the result shows it just endless
loop and results stack overflow.
Even that count actually a function call without the arg, the calling is
performed. that's somehow misleading.
function count(x)
{
function opApply(m) = coroutine function opApply(m)
{
for(i: 1 .. x + 1)
yield(i) // yield values after that
return null
}
foreach(v;count)
writeln(v) // prints 1 through 4
}
count(4)
object.Exception: Stack Overflow
No, it's just that you don't understand MiniD's iteration protocol.
I'm not going to explain it here because I've already explained it -
two or three times - in the documentation. Long story short, 'count'
refers to the global function 'count' which you already defined.
Functions are first-class values, so count refers to the function
object itself, like doing count in D. Foreach loops are based on
an iterator function, and so when you do foreach(v; count) it thinks
count is your iterator function. It calls it, which makes a
recursive call, which calls itself, and so on.
For information on the iteration protocol, read this:
http://www.dsource.org/projects/minid/wiki/LanguageSpec2/Statements#ForeachStatements
MDCL stack overflowed out, maybe mdcl should do something to protect itself
from stack overflowing.
Maybe it should ;)
I'm trying to use coroutine foreach in a class.
class count
{
x =3
function opApply(m) = coroutine function opApply(m)
{
yield()
for(i: 1 .. m.x + 1)
yield(i)
}
}
global c= count()
foreach(v;c.opApply(c))
writeln(v) // prints 1 through 4
it causes of runtime error: Error: opApply(7): Attempting to access field 'x'
from a value of type 'null'
Well yeah. Where is your coroutine getting the value 'm'? It's not.
So it gets 'null'.
The problem here is I misuseing the function definition.
function opApply(m) = coroutine function opApply() works OK.
Yes, because of upvalues. When you take the parameter off the
coroutine, 'm' then refers to the local variable in the outer
function.
But that's inconsistent from a strong type user's view. Because the left part
is function with 1 arg, right part
is a coroutine function without any arg. That's pretty error-prone for
newbies.
And coroutines and iterators are pretty advanced. So I'm not so sure
I much mind what the newbies think ;)
Actually you're again doing it wrong. You don't have to manually pass
the object to be iterated to opApply, it's already passed as 'this'.
The following:
class count
{
x = 3
function opApply()
{
local m = this
return (coroutine function()
{
yield()
for(i: 1 .. m.x + 1
Re: MiniD 2 - Tentative Release Candidate 1
On Wed, Dec 10, 2008 at 10:21 PM, davidl [EMAIL PROTECTED] wrote:
That's not true. All about compiler is easeing developers. Why not issue a
compiler
error/warning when it reaches some code like:
function opApply(m) = coroutine function opApply(m)
1. the local var m shadows the arg m _in 1 declaration_
2. this could be a general mistake which could possibly be made by people with
a strong type programming background
Probing this kind of code seems troublesome, I will be glad to see MiniD can
give an error
on this kind of code someday.
I'm not sure that's a good idea. The compiler does already issue an
error if you declare a local multiple times in the same function:
local x
{
local x // error, shadows previous declaration
}
But if that is generalized to disallowing local variable declarations
that shadow locals in any enclosing functions as well, .. ech. It
seems a bit much. I might implement it, I might not.
That's pretty tricky. But the syntax of following is cleaner if possible:
class count
{
x = 3
coroutine function opApply() //mark it as a coroutine function.
{
yield()
for(i: 1 .. :x + 1)
yield(i)
}
}
global c = count()
foreach(v; c)
writeln(v) // prints 1 through 4
It's pretty sad coroutine function in a whole doesn't work.
I think you're confused about what coroutine is, grammatically.
coroutine is an expression. Much like - in front of 5 gives the
number -5, coroutine in front of an expression that evaluates to a
function gives a thread object.
Allowing something like coroutine function as a declaration is
inflexible. Most of the time, the parameters to the coroutine are not
going to be the same as the parameters to the function which creates
it. It seems like syntactic noise for little benefit.
But still opApply() = coroutine function() still not work
You do it: function f()=coroutine function()
..you don't have a body on that function. Of course it's not going to work.
I think if MiniD is able to do the syntax I proposed, I wouldn't have those
bunch
questions about foreach on a coroutine function.
And People won't expect do foreach on a coroutine in most cases if that
syntax comes
true. Because for most people, a coroutine opApply is more intuitive than a
coroutine
with an opApply method available.
I've considered making coroutines a basic iterable type, in which case
their opApply would disappear. (it would also make the dummy first
index disappear.)
And I think it's practicle for MiniD compiler decide what to do, because
MiniD can
probe that if the opApply method is coroutine or not. If it's coroutine
function, than
implicitly a coroutine context created. Also the first yield is quite weird
for me.
The first yield is there so that any extra parameters to the coroutine
object are passed before iteration starts, as well as to associate the
context ('this') parameter with it.
class count
{
x = 3
function opApply() = coroutine function() //mark it as a coroutine
function.
Again I think you're getting a bit confused as to what coroutine is
doing. opApply is not a coroutine function. opApply is a function
which returns a thread object. That is,
function opApply() = coroutine function() {}
is equivalent to:
function opApply()
{
local function blah() {}
return coroutine blah
}
{
yield() // I hope that we could get rid of the first yield, is
that for something special or else?
for(i: 1 .. :x + 1)
yield(i)
}
}
global c = count()
foreach(v; c)
writeln(v) // current it prints nothing. I don't know what it's
actually going here.
I'll agree that that's a bit surprising. What actually happens is
that on the first iteration, it notices that 'c' is not a function, so
it calls c.opApply(). It then happily assumes that opApply returned a
function, and calls it. That is, it doesn't notice opApply returned a
coroutine, and so doesn't call opApply on the coroutine itself. It
calls the coroutine, thinking it's a function, and the coroutine
yields nothing, which the foreach loop interprets as end of
iteration. Agh.
I'm liking the idea of making 'thread' a basic iterable type more and more ;)
Re: MiniD 2 - Tentative Release Candidate 1
On Wed, Dec 10, 2008 at 12:12 AM, davidl [EMAIL PROTECTED] wrote:
I got an impression that a scripting lang coroutine is less expensive than a
function call? I guess coroutine in a scripting interpreted lang won't
require any thread involved, and the suspension of the execution maybe even
more costless compared to a return statement and reexecution of that function
in the case of opApply.
The cost of a coroutine object in MiniD, as well as the cost of
calling it, depends on the compilation options
(http://www.dsource.org/projects/minid/wiki/API2/CompilationOptions).
If you don't specify any version flags when compiling MiniD, it will
use tango Fibers for coroutines created from native functions, and
will use its own system of pausing and resuming for coroutines created
from MiniD functions.
The cost of a coroutine resume/yield is more than a normal function
call, but it's still not a lot. For example, using MiniD coroutines,
I can perform around 1.6 million resume/yield pairs per second on my
Pentium M. Fibers aren't much slower; I still get about 1.25 million.
That's not going to be a bottleneck considering the speed of most
other operations.
Rather, the biggest cost with a coroutine is memory. A coroutine
object is relatively large compared to a function closure, and
depending on the compilation options, can also allocate D heap memory.
So for simple iteration tasks, it might be in the interest of
performance to try to write it in the form of a function iterator, and
if it gets to be too complex to be worth it, you can write it as a
coroutine.
And I'm still not able to get opApply to work with coroutines, any example
available?
I always get the error message of Iterated coroutine must be in the initial
state, I've no clue about what it's going on.
When you use foreach on a coroutine, it has to be in the initial
state. The only times a coroutine can be in an initial state is (1)
immediately after they are created, before they are called even once,
and (2) after they have died and then had their .reset() method
called. A simple example:
function count(x) =
coroutine function()
{
yield() // first empty yield is important for foreach-able coroutines
for(i: 1 .. x + 1)
yield(i) // yield values after that
// when this coroutine returns here, iteration stops
}
foreach(v; count(4))
writeln(v) // prints 1 through 4
Notice that count is returning a new coroutine object each time you
call it, so the coroutine is always in the initial state.
There's more info on coroutines, including showing some iterators and
explaining their various states, at the following link:
http://www.dsource.org/projects/minid/wiki/LanguageSpec2/Functions#Coroutines
Re: MiniD 2 - Tentative Release Candidate 1
On Mon, Dec 8, 2008 at 3:44 AM, mpt [EMAIL PROTECTED] wrote:
Great stuff, but I have some trouble with the binding lib.
Good! Because I wasn't ;)
1. If I don't wrap a constructor, I get an error:
minid/bind.d(1101): static assert Cannot call default constructor for class
Foo; please wrap a constructor explicitly
Fixed.
2. If I wrap a constructor with no parameters (i.e. WrapCtors!(void
function())), I get an error:
minid/bind.d(1066): constructor
minid.bind.WrappedClass!(Foo,Foo,,WrapCtors!(void
function()),WrapMethod!(Call)).WrappedClass.ClassCtorShims!(void
function()).this (MDVM*,()) does not match parameter types ()
minid/bind.d(1066): Error: expected 1 arguments, not 0
Fixed.
3. I can't find an obvious way to initialize global variables, so I try
superPush, which gives a runtime error:
You're actually doing it right, unless you wanted to instantiate the
wrapped MiniD class, in which case it'd be more like:
pushGlobal(t, Foo); // get the global class Foo
pushNull(t); // make room for 'this'
rawCall(t, -2, 1); // call the class to instantiate it (1 return
for the instance)
newGlobal(t, myfoo); // save it in the global myfoo
minid.types.MDException: no location available: newInstance - expected
'class' for base, not 'null'
Fixed.
Test code below:
import minid.bind;
import minid.api;
class Foo {
this() {}
this(int i) {}
void Call() {}
}
void main() {
MDVM vm;
auto t = openVM(vm);
loadStdlibs(t);
WrapGlobals!(
WrapType!(
Foo, Foo,
WrapCtors!(void function(int)),
WrapMethod!(Foo.Call)
)
)(t);
superPush(t, new Foo());
newGlobal(t, myfoo);
}
This code now works, just svn up your MiniD installation :)
Re: DMD 1.037 and 2.020 releases
On Wed, Nov 26, 2008 at 9:20 AM, Jarrett Billingsley
[EMAIL PROTECTED] wrote:
On Wed, Nov 26, 2008 at 9:06 AM, Kagamin [EMAIL PROTECTED] wrote:
- Added range support to foreach statement. What is this?
Good question, because what is called foreach range statement was
implemented long ago.
It's the ability to use foreach on the new ranges (see std.range).
I'm affraid, this breaks my resource parser
struct ResourceTable
{
ushort Shift; //alignment shift count
ResourceType* FirstType()
{
return cast(ResourceType*)(this+1);
}
}
return cast(ResourceType)(this + 1);
Erm, that's cast(ResourceType*), of course ;)
Re: DMD 1.037 and 2.020 releases
2008/11/25 Walter Bright [EMAIL PROTECTED]: http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.037.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.021.zip I want to say thank you for taking the community's requests into account when fixing the bugs for this release. I can't tell you how happy it makes me to see some of these fixed. I hope this keeps up ;)
Re: DMD 1.037 and 2.020 releases
On Wed, Nov 26, 2008 at 9:06 AM, Kagamin [EMAIL PROTECTED] wrote:
- Added range support to foreach statement. What is this?
Good question, because what is called foreach range statement was implemented
long ago.
It's the ability to use foreach on the new ranges (see std.range).
I'm affraid, this breaks my resource parser
struct ResourceTable
{
ushort Shift; //alignment shift count
ResourceType* FirstType()
{
return cast(ResourceType*)(this+1);
}
}
return cast(ResourceType)(this + 1);
Re: Scope storage class
On Wed, Nov 26, 2008 at 11:07 AM, bearophile [EMAIL PROTECTED] wrote:
Can you try declaring b as a nested function instead of as a delegate
literal and see if that helps?
I think that may lead to nonworking code.
Uh, why? You are declaring the delegate as 'scope', yes? Meaning you
don't expect the delegate to be allocated on the heap? Why don't you
try it and see what happens instead of arguing?
(why are you declaring it the way you are, anyway?
Here you can find explanations:
http://en.wikipedia.org/wiki/Man_or_boy_test
Here you can find other two versions that work, but I think the version I
have shown is the more robust one (that is: able to computer up to higher N
values with D1 compiler):
http://www.rosettacode.org/wiki/Man_or_boy_test#D
I don't really care about what test it is. I'm just confused why you're doing:
scope int delegate() b;
b = { .. };
instead of:
scope int b() { .. }
The reason I wonder is because I would expect that the compiler is
still allocating the delegate on the heap if you use the first syntax.
(the second is also shorter and clearer.)
Re: Scope storage class
On Wed, Nov 26, 2008 at 4:13 PM, Walter Bright
[EMAIL PROTECTED] wrote:
Jarrett Billingsley wrote:
The reason I wonder is because I would expect that the compiler is
still allocating the delegate on the heap if you use the first syntax.
(the second is also shorter and clearer.)
There's no reason to suspect. Just obj2asm the output and see.
That'd be great if I had it. I don't want to get into that, though.
Furthermore,
better results will come from:
int b() {
k -= 1;
return a(k, b(), x1, x2, x3, x4);
};
instead of using the delegate.
So my suspicion is correct, then? That is:
scope int delegate() b;
b = { ... };
Will allocate on the heap?
Re: Tango conference 2008 - Tomasz Stachowiak DDL talk
On Tue, Nov 18, 2008 at 11:32 PM, Saaa [EMAIL PROTECTED] wrote: One last simple thing: In the Molly Rocket talk about immediate-mode guis a comment is made about some games not holding true to the convention that releasing the mouse away from the clicked button will not result in button click. ... 3. faulty clicks are not that damaging Oops, I just used my one-time super awesome buff trinket that I was saving for Kil'jaeden _when I was fighting a trash mob_. It might not be damaging to your computer or data, but it can sure be frustrating in the game ;)
