Re: New home page
On 05.10.2010 04:28, Nick Sabalausky wrote: Walter Brightnewshou...@digitalmars.com wrote in message news:i8d77c$1bf...@digitalmars.com... Stewart Gordon wrote: The layout breaks in anything but the default text zoom. The annoying thing about this is everyone says don't use tables for layout, use CSS. Except that using CSS for layout DOESN'T WORK RELIABLY. With tables, I can get 3 columns that are actually 3 columns, not 3 columns that are a side effect of bugs in CSS. YES!! This is a pet peeve of mine (but then, what isn't? ;) ). I've even been meaning to write up a little article about it. For styling, CSS is, umm, acceptable. But it's crap for layout. And every argument I've seen against using tables for layout has been either extremely minor, questionable/uncited, or just plain bullcrap. Speaking of, if anyone has links to well-regarded why you shouldn't use tables for layout information, please post them. Whenever I get around to doing that little write-up I'd like to try to refute as much as I can. Or be proven wrong before making a bigger ass of myself. Either way :) The point in not using the table _element_ for layout is that HTML should be used to define the _content_ of your page not its appearance. It's all about what kind of data you have at hand: a heading, a list, tabular data, a figure with an image, etc. It says nothing about how the page is supposed to look, it's just the pure content. After defining the content the appearance is setup with CSS. And there table layouts are used pretty often (if not always). If you don't care about older IE versions you can use display: table and companions. Basically these display properties just make elements behave like the corresponding HTML elements (e.g. table-cell maps to the td element). Prior to that CSS only had mechanisms for defining float layouts (the float property) but these can be used for table layout, too. It's not that difficult but it's less flexible. All you need is a container with overflow: hidden. To create columns inside it just set some child elements to fload: left. This will look like this: -- overflow: hidden -- || | -- float: left -- -- float: left -- | | | | | | | | | | | | | | | | | | | | | | - | | | | | | - | || -- This method works quite well, only IE 6 makes some trouble because the floats trigger some bugs (but if you add a few pixels of reserve space it will be all right for IE 6). The main drawback of this method is that the floated boxes are independent of each other, each gets its own height and with. If you want them to have a consistent layout you have to assign fixed widths and highs. There are some workarounds for this (e.g. using a repeating background image on the container) but I suppose I already talked to much about CSS. Basically it's all about separation of content and presentation. It's not always easy (nor always necessary) but if done right you don't have to touch the HTML code for your next redesign (and the search engines are very happy about proper HTML code, too). ps.: I'm usually only reading this newsgroup because I'm somewhat new to D. But I couldn't resist answering about CSS. ;) Happy programming Stephan Soller
Re: New home page
Stephan Soller stephan.sol...@helionweb.de wrote in message news:i8epjv$1d3...@digitalmars.com... On 05.10.2010 04:28, Nick Sabalausky wrote: Walter Brightnewshou...@digitalmars.com wrote in message news:i8d77c$1bf...@digitalmars.com... Stewart Gordon wrote: The layout breaks in anything but the default text zoom. The annoying thing about this is everyone says don't use tables for layout, use CSS. Except that using CSS for layout DOESN'T WORK RELIABLY. With tables, I can get 3 columns that are actually 3 columns, not 3 columns that are a side effect of bugs in CSS. YES!! This is a pet peeve of mine (but then, what isn't? ;) ). I've even been meaning to write up a little article about it. For styling, CSS is, umm, acceptable. But it's crap for layout. And every argument I've seen against using tables for layout has been either extremely minor, questionable/uncited, or just plain bullcrap. Speaking of, if anyone has links to well-regarded why you shouldn't use tables for layout information, please post them. Whenever I get around to doing that little write-up I'd like to try to refute as much as I can. Or be proven wrong before making a bigger ass of myself. Either way :) The point in not using the table _element_ for layout is that HTML should be used to define the _content_ of your page not its appearance. ... Basically it's all about separation of content and presentation. It's not always easy (nor always necessary) but if done right you don't have to touch the HTML code for your next redesign (and the search engines are very happy about proper HTML code, too). Yea, I do agree in principle. But in my experience, certain realities of CSS complicate the issue. Basically, I've spent enormus amounts of time and energy getting certain layouts to work properly and reliably in CSS. There's been plenty of times I've come across that and eventualy just threw my hands up and said Ok, the heck with purity and ideals, I just need to get it done: So hello tables!. And every single time I've done that everything went smooth from that point on. If CSS could handle layouts as well as tables can, then I would be all for abandoning tables-for-layouts. But CSS just isn't there yet. And I don't see it progressing much. Plus I often find redesigning HTML a lot more straightforward than tweaking typical production-scale CSS (CSS can get real hairy real quick). Not only that, I've recently started doing my sites in a very MVC/rails/django-ish way whenever possible, so for me, the HTML usually *is* just as much part of the view as the CSS anyway. And all I have to do to redesign it is just tweak an html template file. As a bonus, that allows for much more flexibility in my redesigns (and much more easily) than CSS could ever hope to achieve without CSS itself getting a fundamental overhaul. ps.: I'm usually only reading this newsgroup because I'm somewhat new to D. But I couldn't resist answering about CSS. ;) Welcome :)
Re: New home page
On 05.10.2010 12:24, Nick Sabalausky wrote: Stephan Sollerstephan.sol...@helionweb.de wrote in message news:i8epjv$1d3...@digitalmars.com... (and the search engines are very happy about proper HTML code, too). I've actually come across this point before, that search engines will rank a page that doesn't use tables for layout better than one that does. I can't really argue against that point, but I am really curious. Does anyone have links to any authoritative information on this? I would also like to see solid information on that topic but I'm afraid this statement is very hard to catch. The Google SEO Guide mainly focuses on the title and description of websites as well as headings an links. I suppose more detailed structures and elements (lists, tables, em, code, etc.) are not that important for search engines but for other tools that need to work with the document structure (js scripts, screen readers, semantic analysis, data mining, etc.). Happy programming Stephan
Re: New home page
On 05.10.2010 12:13, Nick Sabalausky wrote: Stephan Sollerstephan.sol...@helionweb.de wrote in message news:i8epjv$1d3...@digitalmars.com... On 05.10.2010 04:28, Nick Sabalausky wrote: Walter Brightnewshou...@digitalmars.com wrote in message news:i8d77c$1bf...@digitalmars.com... Stewart Gordon wrote: The layout breaks in anything but the default text zoom. The annoying thing about this is everyone says don't use tables for layout, use CSS. Except that using CSS for layout DOESN'T WORK RELIABLY. With tables, I can get 3 columns that are actually 3 columns, not 3 columns that are a side effect of bugs in CSS. YES!! This is a pet peeve of mine (but then, what isn't? ;) ). I've even been meaning to write up a little article about it. For styling, CSS is, umm, acceptable. But it's crap for layout. And every argument I've seen against using tables for layout has been either extremely minor, questionable/uncited, or just plain bullcrap. Speaking of, if anyone has links to well-regarded why you shouldn't use tables for layout information, please post them. Whenever I get around to doing that little write-up I'd like to try to refute as much as I can. Or be proven wrong before making a bigger ass of myself. Either way :) The point in not using the table _element_ for layout is that HTML should be used to define the _content_ of your page not its appearance. ... Basically it's all about separation of content and presentation. It's not always easy (nor always necessary) but if done right you don't have to touch the HTML code for your next redesign (and the search engines are very happy about proper HTML code, too). Yea, I do agree in principle. But in my experience, certain realities of CSS complicate the issue. Basically, I've spent enormus amounts of time and energy getting certain layouts to work properly and reliably in CSS. There's been plenty of times I've come across that and eventualy just threw my hands up and said Ok, the heck with purity and ideals, I just need to get it done: So hello tables!. And every single time I've done that everything went smooth from that point on. If CSS could handle layouts as well as tables can, then I would be all for abandoning tables-for-layouts. But CSS just isn't there yet. And I don't see it progressing much. Plus I often find redesigning HTML a lot more straightforward than tweaking typical production-scale CSS (CSS can get real hairy real quick). Not only that, I've recently started doing my sites in a very MVC/rails/django-ish way whenever possible, so for me, the HTML usually *is* just as much part of the view as the CSS anyway. And all I have to do to redesign it is just tweak an html template file. As a bonus, that allows for much more flexibility in my redesigns (and much more easily) than CSS could ever hope to achieve without CSS itself getting a fundamental overhaul. ps.: I'm usually only reading this newsgroup because I'm somewhat new to D. But I couldn't resist answering about CSS. ;) Welcome :) Thanks. :) I have to agree that CSS layout techniques have a somewhat steep learning curve. It's straight forward to use floating boxes for column layouts and bugs in IE still hurt. However it's the same in every language/field (e.g. it was totally new to me to use () ? x : y to get the common type of two expressions). Once you get to know some of the techniques it's way more easy to do stuff in CSS, often just because you have less text to type and everything in one place (a few lines in a CSS file). If CSS could handle layouts as well as tables can, then I would be all for abandoning tables-for-layouts. But CSS just isn't there yet. And I don't see it progressing much. CSS is absolutely ready, IE 6 and 7 are not. As soon as you can assume IE 8 or any decent browser you can use CSS tables. Sitepoints Book [Everything You Know About CSS Is Wrong][1] is a very practical guide to these handy properties. There are also some more experimental column or grid based properties but I haven't seen any of them out in the wild. CSS 3 defines quite some interesting stuff but it's very hard to tell if or when someone can use it. [1]: http://www.sitepoint.com/books/csswrong1/ Plus I often find redesigning HTML a lot more straightforward than tweaking typical production-scale CSS (CSS can get real hairy real quick). Production-scale CSS can get really ugly really fast without a fitting coding style (e.g. I'm almost always defining margin and padding on any layout elements, just to have the actual values available at the same code line). Not only that, I've recently started doing my sites in a very MVC/rails/django-ish way whenever possible, so for me, the HTML usually *is* just as much part of the view as the CSS anyway. And all I have to do to redesign it is just tweak an html template file. As a bonus, that allows for much more flexibility in my redesigns (and much more easily) than CSS could ever hope to achieve
Re: New home page
Stephan Soller wrote: This is especially handy when doing a presentation about a programming language since you can use JavaScript to write a small syntax highlighter (the grammar in the D documentation was really handy for that). :) A javascript D syntax highlighter? Please post!
d.vim 0.22
This is actually a better implementation of a fix in 0.21 Highlighting of known versions is correct now. For one thing it would only highlight if the version statement was at the beginning of the line. http://www.vim.org/scripts/script.php?script_id=379
Re: New home page
On 05/10/2010 06:51, Jacob Carlborg wrote: snip I think this site has good CSS tutorials: http://css.maxdesign.com.au/ Here is a tutorial for a liquid three column layout with a header and a footer: http://css.maxdesign.com.au/floatutorial/tutorial0916.htm That's geared towards creating a layout with two fixed-width navigational columns and a central 'main' column. What's wanted here is three equal columns, which is a quite different thing. Stewart.
Re: New home page
That's because HTML/CSS is a pretty terrible language for anything beyond simple layouts. It shares more with Word/PDF/PostScript in terms of its purpose and history than it does with real gui layout engines (GTK, QT, etc). Hardcore HTML/CSS people tout the virtues of separating the content from the presentation. The problem is that HTML has implicit presentation that you often can't override with CSS. There are limits to what you can do with positioning. If I want to rearrange elements in my page I have to change the HTML, I can't do it all on the CSS side. That's not separation of content from presentation! Real separation of the presentation has to happen right at the data layer. But that's server side in most applications. So you run your data through one view abstraction (template language such as Freemarker, PHP, JSP etc), then to HTML, and then polish it with CSS. Oh, and that application runs on an app server that runs in a Java virtual machine that runs in an VMware OS that runs on a real OS that actually accesses real hardware. That's an absurd number of layers... Anyway, to get back to HTML. They'll say use divs not tables because a table represents a distinct concept not a layout element and it has accessibility implications. And yet I you can't layout things with divs in the same way that I can with a table. And even if there are obscure CSS properties that let me, half the user's browsers don't support them. Sometimes I feel like I'm the only one that sees the naked Emperor. People are so excited about the Internet but they don't realize that browsers are just implementing one view language that's 15 years old and really isn't all that great. The beauty of the Internet is the emergent properties that arose from the concept of linking sites. But that's not something that has to be unique to the HTML language itself. And sure there's some cool stuff in HTML5 but a pig's still a pig even when you velcro a TV to its head and a database on its back. -Arlo On 10/04/2010 02:23 PM, Walter Bright wrote: That's what bugs me. Something as straightforward as a 3 column layout shouldn't require tricks for it. Googling it found 3 pages dedicated to explaining this trick (each of them wildly different, of course).
Re: We need to kill C syntax for declaring function types
Jesse Phillips wrote: bearophile Wrote: Jesse Phillips: Is any tested done against deprecated features? Keep in mind that so far the main purpose of the -d in DMD2 was (I think) to enable Phobos code marked with deprecated. Bye, bearophile Yes, and I think that if the code still exists and can be compiled then it should still be tested. I would agree that adding tests, or fixing bugs, isn't really a good idea, but it would be a good idea to keep existing tests and test with the -d option (that is new functionality isn't broken with -d enabled either). Don't worry, that happens.
Re: Module-level accessibility
On 2010-10-05 00:11, Steven Schveighoffer wrote:
On Mon, 04 Oct 2010 17:54:54 -0400, Jonathan M Davis
jmdavisp...@gmx.com wrote:
On Monday, October 04, 2010 13:41:38 Steven Schveighoffer wrote:
To me, making it private doesn't do anything over protected. A derived
class can still call the function in question, because it has the
implementation. I don't see what the point is...
A derived class from the derivative doesn't have access, but it can
always
override it in order to be able to call it (not a good workaround to
require).
Except that part of the point is that because the private method is
private in
the base class, it _can't_ be called by derived classes. It can only be
overridden.
Sure you can. Altered version of code from one of your articles:
#include set
class Set {
std::setint s_;
public:
void add (int i) {
s_.insert (i);
add_impl (i); // Note virtual call.
}
void addAll (int * begin, int * end) {
s_.insert (begin, end); // - (1)
addAll_impl (begin, end); // Note virtual call.
}
private:
virtual void add_impl (int i) = 0;
virtual void addAll_impl (int * begin, int * end) = 0;
};
class CountingSet : public Set {
private:
int count_;
virtual void add_impl (int i) {
addAll_impl(i, (i) + 1); // hey look, we can call a private method!
}
virtual void addAll_impl (int * begin, int * end) {
count_ += std::distance(begin,end);
}
};
compiles with g++. So the private restriction does nothing significant IMO.
Not responding to the rest of your points, since my argument is
predicated on you understanding this first ;)
In this example, BTW, I think the significance of private is the fact
that the s_ member is private. That *does* prevent derived classes from
altering the set except through the common interface.
Also, note that I'm not saying NVI isn't a valid or useful pattern (I've
used it in the past with success). I just think protected is a better
choice for the virtual methods.
-Steve
Who says we need to implement it as g++ does? DMD could implement it to
not allow that.
--
/Jacob Carlborg
Re: Module-level accessibility
On 2010-10-04 21:37, bearophile wrote: Andrei: I agree. Class A can access private methods of class B as long as both defined in the same module. If it has access to private methods, why can't it override them? Makes little sense, if you ask me, especially given that user may prevent overriding methods using final keyword. And the package also implying final is just ridiculous! This is a very good argument that in my mind settles the case. I am not expert about this, but ignoring private attributes among classes/structs in the same module may be useful, but it's a dirty thing. If you split in two parts a module that contains two classes that access each other private members, the code stops working. Overriding private methods makes the situation even dirtier. I don't think C#/Java programmers will appreciate this :-) Bye, bearophile If you have two classes in one file in Java you can access private methods from the other class. -- /Jacob Carlborg
Is D right for me?
Hello! I'd like some help to resolve the subject's question... Let me start with my background...Finished Computer Engineering studies and during that period was introduced to several programming languages (including some assembly stuff) starting with Fortran C, a little Prolog and did my thesis by programming simulator for coloured Petri nets using Zortech C++ - that was in 1990 :-) I also playing with Smalltalk a bit...I'm saying as small emphasis that D would not be my 1st programming language. Later, my life went away from programming into totally different area and today programming is not my occupation, but should serve my hobby projects. After my 'programming come-back', I explored Ruby a bit, checked Ocaml shortly (did not like syntax) and wanting something 'new', I ended up tinkering with Haskell. For my web purposes I wanted to use Django, but realized that not being web developer, there is no sense to write so many code, when I can achieve the same by learning some PHP (which I do these days) in order to tweak and/or write some missing module for my preferred CMS (Made Simple). Similarly, to create invoices for our startup 'company', I abandoned GNUCash which requires tinkering with Scheme (Guile) and decided to use SimpleInvoices (PHP MySQL web app). The keyword here is 'pragmatism', iow. understanding that one needs to make some compromises in order to get job done. Now, we're back at D...Saw a Reddit thread yesterday which inspired me to think (once again) about Haskell vs D... So, we want a general programming language to work on our open-source (we plan GPL) hobby project which is desktop GUI application and besides the need to develop several libs for it, it needs to use C-lib (Swiss Ephemeris). Are there other alternatives? Well, I do not like Java, VMs (Scala included)., want something 'modern' to avoid manual memory management, pointers etc., higher-level...which eliminates C(++). Scripting languages (Perl, Python) are too slow and I'm aware of some projects from the same domain which switched from Python to C++. I'm not interested in LISP-family ala Clojure, neither inspired by C#,Go... We want to develop on Linux (running x86_64 I7 cpu) and have app working on Mac and possibly Windoze. For a long time I was thinking about gtk2hs bindings, but since Mac platform became important for us (supervisor of the project recently switched to it), I abandoned GTK. I was even advised by one dev working on GTK Mac port that wx(haskell) is better solution if we target Mac. However, we would like to write kind of 'desktop-lite' app here idea to use Qt Meego was born, since there is no wxQT port. I was sorry to discover yesterday that QtD project is suspended. :-( So, let's recap in regards to Haskell vs D. a) I like Haskell syntax, its type-system, purity and the concept of separating pure code from non-pure (e.g. IO), HOF. Community is very friendly and growing (1st time when i visited #haskell it was 100 users, today probably 600), there are lot of packages available on Hackage, GHC is keeping strong, Cabal build system is nice, QuickCheck... Otoh, many libs/packages are not adequately documented, there is joke that one needs PhD to use the language, lot of papers but with strong influence from academia and one has to encounter lot of terminology from category theory etc. although maybe wanting to 'just get the job done' - iow, Haskell could become more pragmatic. Moreover, to get better performance, laziness with its non-determinism might be a problem and/or profiling to discover leaks is not straightforward and/or code becomes more ugly. :-) D, from the other side, is younger language, community is not so big, language is, afaict, evolving very rapidly and it's not easy to tell which compiler to use, which libs etc. Moreover, I'm a bit worried on the state of GUI libs available for D, especially about QtD. Moreover, 64-bit is not ready (yet), although I'm told it should come soon. What about ARM if we want to target MeeGo in the future? I also did not research what is the state of database support...Now we're thinking to use sqlite3 as back-end. Our project will be developed in free time and we want language which is easy to maintain because the project (with all desired features) might evolve into a big one during the period of several years. I also have experience that some potential developers did not join our team since Haskell was to hard to grok for them (coming from C++), so D might be an easier path with less steep learning curve, but I also wonder about myself whether I could pick D quickly enough (I'll buy book, of course) after long exposure to Haskell and FP. I read The Case for D article and saw Andrei's Google talk - it was funny to see Google people being like little children when questioned by him :-) So, can you offer some advice, what could be better choice between Haskell D for our planned project with the following features: a) maintainable
Re: The Many Faces of D - slides
On 10/05/2010 02:42 AM, Walter Bright wrote: Max Samukha wrote: He said movable using memcpy(). He didn't say anything about adjusting pointers. A moving GC should and will adjust pointers, but I don't see how the memcpy() is relevant here. The moving GC would adjust the pointers, but the memcpy() means that other things would not need to be done, such as incrementing counters, all the things that non-trivial copy constructors do. Now I see what you meant. Thanks for the explanation.
Re: We need to kill C syntax for declaring function types
On Mon, 04 Oct 2010 11:07:07 +0200, Don wrote: [...] The C syntax is unspeakably ridiculous, useless, and downright dangerous. It shouldn't compile. [...] Patch included in Bug 4987. http://dsource.org/projects/dmd/changeset/703 :) -Lars
phobos is failure
1, Little practical content 2, templat + range subversion use habit, Lost the popularization base sorry!
Re: phobos is failure
On Tue, 05 Oct 2010 04:11:18 -0500, dolive doliv...@sina.com wrote: 2, templat + range subversion use habit, Lost the popularization base sorry! I don't understand this last point. sorry! -- Yao G.
First Experiences in D
by Gavin Norman http://www.reddit.com/r/d_language/comments/dmzbv/first_experiences_in_d/
Re: We need to kill C syntax for declaring function types
Lars T. Kyllingstad wrote: http://dsource.org/projects/dmd/changeset/703 :) Don, as usual, made a compelling case.
Re: phobos is failure
Yao G. дµ½: On Tue, 05 Oct 2010 04:11:18 -0500, dolive doliv...@sina.com wrote: 2, templat + range subversion use habit, Lost the popularization base sorry! I don't understand this last point. sorry! -- Yao G. Don't read understand for templat + range for most people (Including me), Lost the popular base .
Re: phobos is failure
Yao G. дµ½: On Tue, 05 Oct 2010 04:11:18 -0500, dolive doliv...@sina.com wrote: 2, templat + range subversion use habit, Lost the popularization base sorry! I don't understand this last point. sorry! -- Yao G. Don't read understand for templat + range for most people (Including me), Lost the popular base .
Re: Is D right for me?
Gour D. g...@atmarama.net wrote: D, from the other side, is younger language, community is not so big, language is, afaict, evolving very rapidly and it's not easy to tell which compiler to use, which libs etc. This is a big problem for D at this point. The language is no longer evolving (much), and we're at a point in time where libraries and toolchain parts need to be written. Moreover, I'm a bit worried on the state of GUI libs available for D, especially about QtD. Moreover, 64-bit is not ready (yet), although I'm told it should come soon. It will. Latest news (2 days ago) say it's now getting as far as main(), which is good. What about ARM if we want to target MeeGo in the future? I believe GDC supports ARM. I also did not research what is the state of database support...Now we're thinking to use sqlite3 as back-end. There's a list here: http://www.wikiservice.at/d/wiki.cgi?DatabaseBindings However, most of those are for D1, and a large percentage seem to be abandoned. SQLite seems to be well supported, with 7 projects claiming support. I also have experience that some potential developers did not join our team since Haskell was to hard to grok for them (coming from C++), so D might be an easier path with less steep learning curve, but I also wonder about myself whether I could pick D quickly enough (I'll buy book, of course) after long exposure to Haskell and FP. I'm sure you can. D also supports programming styles closer to those of FP, making such a transition easier (I hope :p) So, can you offer some advice, what could be better choice between Haskell D for our planned project with the following features: a) maintainable code This is likely a bit subjective, and much more dependent upon the programmers themselves than the language used. That said, D supports a variety of features that boost maintainability: - Contract programming in the form of pre and post contracts for functions[1]. - Class invariants[2]. - Built in unit testing[3]. - Documentation comments[4]. Of course, other features of D may increase maintainability, but those are the ones most directly associated with it. b) decent performance D is generally as fast as C, though some abstractions of course cost more than others. c) higher-level programming and suitable for general programming tasks My impression (not having used Haskell), D wins hands down on the latter, and is a bit weaker on the former. d) good library support (database stuff, data structures, Qt GUI...) Likely Haskell is better here (as noted above, D has some problems in this regard). e) vibrant community and active development so that there is some guarantee that the language won't fall in oblivion if some devs leave the project, iow. 'bus-factor 2' ? The bus-factor of D is sadly close to 1. If Walter should choose to leave, we have a problem. On the other hand, I don't think a mere bus would keep him from continuing the project. (It would be nice if someone familiar with both languages can share...) Here I can't help. I don't know Haskell. In closing, [1]: http://digitalmars.com/d/2.0/dbc.html [2]: http://digitalmars.com/d/2.0/class.html#invariants [3]: http://digitalmars.com/d/2.0/unittest.html [4]: http://digitalmars.com/d/2.0/ddoc.html -- Simen
Re: tolf and detab (language succinctness)
On 01/10/2010 12:54, bearophile wrote: Bruno Medeiros: From my understanding, Scala is a scalable language in the sense that it easy to add new language features, or something similar to that. I see. You may be right. But I'm missing your point here, what does Ada have to do with this? Ada has essentially died for several reasons, but in my opinion one of them is the amount of code you have to write to do even small things. If you design a language that is not handy to write small programs, you have a higher risk of seeing your language die. There are a lot of things in a language that, if they make it harder to write small programs, they will also make it harder for larger programs. (sometimes even much harder) I'm no expert in ADA, and there are many things that will affect the success of the language, so I can't comment in detail. But from a cursory look at the language, it looks terribly terse. That begin end name of block syntax is awful. I already think just begin end syntax is bad, but also having to repeat the name of block/function/procedure/loop at the end, that's awful. Is it trying to compete with XML ? :p but I simply didn't see much language changes that could have made my D more succint, Making a language more succint is easy, you may take a look at J or K languages. The hard thing is to design a succint language that is also readable and not bug-prone. Indeed, I agree. And that was the spirit of that original comment: First of all, I meant succinct not only in character and line count but also syntactical and semantic constructs. And succinct without changes that would impact a lot the readability or safety of the code. (as mentioned in barring crazy stuff like dynamic scoping) barring crazy stuff like dynamic scoping) I don't know what dynamic scoping is, do you mean that crazy nice thing named dynamic typing? :-) Like Pete explained, it's indeed exactly dynamic scoping that I meant. -- Bruno Medeiros - Software Engineer
Re: Module-level accessibility
On Tue, 05 Oct 2010 03:25:03 -0400, Jacob Carlborg d...@me.com wrote:
Who says we need to implement it as g++ does? DMD could implement it to
not allow that.
The derived class controls everything. You cannot take control away from
the derived class, it just can't be done:
class A
{
private void cantCallMe();
}
class B : A
{
override private void cantCallMe() { butICanCallYou(); }
private void butICanCallYou() { /* do impl */ }
}
so far, private virtual functions == annoyance. I haven't seen anything
to prove otherwise yet.
-Steve
Re: First Experiences in D
On 5/10/2010 8:46 PM, Walter Bright wrote: by Gavin Norman http://www.reddit.com/r/d_language/comments/dmzbv/first_experiences_in_d/ That's a good write-up and certainly marketing material that D needs. I look forward to hearing of the writer's second experiences with D when it comes to his trying to use const, immutable and shared in angst. Please take the cynicism seriously as this supposed hallmark of D2 still alludes prime-time as aspirational goals. Regards Justin Johansson
Re: First Experiences in D
Justin Johansson schrieb: On 5/10/2010 8:46 PM, Walter Bright wrote: by Gavin Norman http://www.reddit.com/r/d_language/comments/dmzbv/first_experiences_in_d/ That's a good write-up and certainly marketing material that D needs. I look forward to hearing of the writer's second experiences with D when it comes to his trying to use const, immutable and shared in angst. Please take the cynicism seriously as this supposed hallmark of D2 still alludes prime-time as aspirational goals. Regards Justin Johansson I guess he was not using D2 without const/immutable and shared but plain old D1. However I agree that his opinion about D2 when he tries it might be interesting. Cheers, - Daniel
Type wrapping blockers
One of the good goals of D I think is to be able to automatically encapsulate a type, and all its attributes/functions, in order to slightly alter the functionality. I think this is probably a pattern, but I don't know what it is (Interceptor?). One of the best methods to wrap a type is to use opDispatch. But there are some problems that block this. It might be good to get a bug report that gathers these together. I have one that I just ran into -- IFTI and literals. Basically, if you have a function: void foo(short x); you can call foo(1) no problem. But if you *wrap* the type that contains foo, you cannot use opDispatch to implement foo(1), because IFTI treats 1 as an int. So what you get is an instantiation of opDispatch like this: opDispatch!(foo, int)(1) Which then cannot call foo, because you cannot cast int to short. Does anyone have any other blockers that prevent type wrapping? Does anyone have any ideas on how to fix the above issue? -Steve
Re: Is D right for me?
On Tue, 05 Oct 2010 12:52:22 +0200 Simen == Simen kjaeraas simen.kja...@gmail.com wrote: Simen This is a big problem for D at this point. The language is no Simen longer evolving (much), and we're at a point in time where Simen libraries and toolchain parts need to be written. That's nice to hear and it's solvable. Simen It will. Latest news (2 days ago) say it's now getting as far as Simen main(), which is good. Great! Simen I believe GDC supports ARM. Hmm, baes on http://dgcc.sourceforge.net/ it looks it is not overly active? Simen There's a list here: Simen http://www.wikiservice.at/d/wiki.cgi?DatabaseBindings Simen Simen However, most of those are for D1, and a large percentage seem Simen to be abandoned. :-( Simen SQLite seems to be well supported, with 7 projects claiming Simen support. Why so many? Similar to Haskell where one can find bunch of libs doing practically the same thing, but most of them half-baked. Simen I'm sure you can. D also supports programming styles closer to Simen those of FP, making such a transition easier (I hope :p) This is certainly bonus. Simen a) maintainable code Simen Simen This is likely a bit subjective, and much more dependent upon the Simen programmers themselves than the language used. I agree. Otoh, afaict, D use modules/packages, so code can be nicely organized, as well as in Haskell. Simen - Contract programming in the form of pre and post contracts for Simenfunctions[1]. Simen - Class invariants[2]. Simen - Built in unit testing[3]. Simen - Documentation comments[4]. Simen Simen Of course, other features of D may increase maintainability, but Simen those are the ones most directly associated with it. Not bad.;) Simen b) decent performance Simen Simen D is generally as fast as C, though some abstractions of course Simen cost more than others. This is, probably, more than we'd need, but definitely no fear as with e.g. Python co. Simen c) higher-level programming and suitable for general Simen programming tasks Simen Simen My impression (not having used Haskell), D wins hands down on the Simen latter, and is a bit weaker on the former. Still, I believe, D provides much more comfortable higher-order experience than C++. Simen d) good library support (database stuff, data structures, Qt Simen GUI...) Simen Simen Likely Haskell is better here (as noted above, D has some Simen problems in this regard). Lack of GUI libs for D2 is serious concern atm. Simen The bus-factor of D is sadly close to 1. If Walter should choose Simen to leave, we have a problem. On the other hand, I don't think a Simen mere bus would keep him from continuing the project. Uhh...this is almost like a showstopper or, at least, very strong anti-adoption pattern. :-( It is even worse than Haskell where GHC has bus-factor =2 and there are other compilers like uhc, lhc, jhc...there is even Haskell committee working on Haskell' (prime) standard. Simen Here I can't help. I don't know Haskell. Thanks a lot. It is helpful, although with a little discouraging end. :-( Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: phobos is failure
On 5/10/2010 8:11 PM, dolive wrote: 1, Little practical content 2, templat + range subversion use habit, Lost the popularization base sorry! Exackaly. Tango rulez. May the meta-force be beside you. :-) Darth
Re: Is D right for me?
Gour D. schrieb: On Tue, 05 Oct 2010 12:52:22 +0200 Simen == Simen kjaeraas simen.kja...@gmail.com wrote: Simen I believe GDC supports ARM. Hmm, baes on http://dgcc.sourceforge.net/ it looks it is not overly active? try http://bitbucket.org/goshawk/gdc/wiki/Home :-) Simen The bus-factor of D is sadly close to 1. If Walter should choose Simen to leave, we have a problem. On the other hand, I don't think a Simen mere bus would keep him from continuing the project. Uhh...this is almost like a showstopper or, at least, very strong anti-adoption pattern. :-( I don't think it's as serious, because afaik Walter is not the only one developing the dmd compiler (and thus familiar with it) and, more importantly, there are alternative D compilers (gdc and ldc, with at least gdc being actively developed). So even if Walter, for whatever reason, stops developing D, there is - IMHO - a good chance that others will continue his efforts and keep D alive. Cheers, - Daniel
Is there anybody working on a linear algebra library for D2?
I remember that one of D's goal is easy scientific computation. However I haven't seen any linear algebra package for D2. My work heavily relays on all kinds of matrix stuff (matrix multiplication, factorization, linear system etc). I like D and am willing to work with D. However without these facilities I can hardly start. I'd like to have a matrix library of which the API is kind of like Matlab. Is there anybody working on this or planning to work on this? Regards, Michael
Re: Is D right for me?
Daniel Gibson Wrote: Gour D. schrieb: On Tue, 05 Oct 2010 12:52:22 +0200 Simen == Simen kjaeraas simen.kja...@gmail.com wrote: Simen I believe GDC supports ARM. Hmm, baes on http://dgcc.sourceforge.net/ it looks it is not overly active? try http://bitbucket.org/goshawk/gdc/wiki/Home :-) Simen The bus-factor of D is sadly close to 1. If Walter should choose Simen to leave, we have a problem. On the other hand, I don't think a Simen mere bus would keep him from continuing the project. Uhh...this is almost like a showstopper or, at least, very strong anti-adoption pattern. :-( I don't think it's as serious, because afaik Walter is not the only one developing the dmd compiler (and thus familiar with it) and, more importantly, there are alternative D compilers (gdc and ldc, with at least gdc being actively developed). So even if Walter, for whatever reason, stops developing D, there is - IMHO - a good chance that others will continue his efforts and keep D alive. Cheers, - Daniel I've also heard there is an unannounced compiler in the works.
Re: Is D right for me?
On Tue, 05 Oct 2010 15:39:30 +0200 Daniel == Daniel Gibson metalcae...@gmail.com wrote: Daniel try http://bitbucket.org/goshawk/gdc/wiki/Home :-) Ahh, this looks much better. Thanks. ;) Daniel I don't think it's as serious, because afaik Walter is not the Daniel only one developing the dmd compiler (and thus familiar with Daniel it) and, more importantly, there are alternative D compilers Daniel (gdc and ldc, with at least gdc being actively developed). So, both gdc ldc are open-source? What about standard libs? Daniel So even if Walter, for whatever reason, stops developing D, Daniel there is - IMHO - a good chance that others will continue his Daniel efforts and keep D alive. This is not so disheartening. :-) btw, I've asked similar/same question on SO http://stackoverflow.com/questions/3863111/haskell-or-d-for-gui-desktop-application if you want to contribute (I'm not much advised for D, so far). ;) Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
LDC is free compiler last revision use dmdfe 1.063 and soon the ladt dmdfe ldc support 32, 64 and arm and works on linux, mac OS X and windows LDC is wrote in c++ using LLVM, all people who whant help this project are welcome. They are a D2 experimental branch (you can too come for help this part )
Re: Is D right for me?
Daniel Gibson wrote: Gour D. schrieb: On Tue, 05 Oct 2010 12:52:22 +0200 Simen == Simen kjaeraas simen.kja...@gmail.com wrote: Simen I believe GDC supports ARM. Hmm, baes on http://dgcc.sourceforge.net/ it looks it is not overly active? try http://bitbucket.org/goshawk/gdc/wiki/Home :-) Simen The bus-factor of D is sadly close to 1. If Walter should choose Simen to leave, we have a problem. On the other hand, I don't think a Simen mere bus would keep him from continuing the project. Uhh...this is almost like a showstopper or, at least, very strong anti-adoption pattern. :-( I don't think it's as serious, because afaik Walter is not the only one developing the dmd compiler (and thus familiar with it) and, more importantly, there are alternative D compilers (gdc and ldc, with at least gdc being actively developed). So even if Walter, for whatever reason, stops developing D, there is - IMHO - a good chance that others will continue his efforts and keep D alive. Look at the changelog for the last three releases. During that time, Walter has worked almost exclusively on the backend for the 64-bit compiler. If there were no community involvement, there would have been almost no progress on the 32-bit compiler. Yet the rate of compiler bug fixing has not fallen. I would estimate the truck factor as between 2.0 and 2.5. Two years ago, the truck factor was 1.0, but not any more.
Re: Is D right for me?
Gour D. schrieb: On Tue, 05 Oct 2010 15:39:30 +0200 Daniel == Daniel Gibson metalcae...@gmail.com wrote: Daniel try http://bitbucket.org/goshawk/gdc/wiki/Home :-) Ahh, this looks much better. Thanks. ;) Daniel I don't think it's as serious, because afaik Walter is not the Daniel only one developing the dmd compiler (and thus familiar with Daniel it) and, more importantly, there are alternative D compilers Daniel (gdc and ldc, with at least gdc being actively developed). So, both gdc ldc are open-source? Yes. What about standard libs? They're open source, too (boost license for phobos, is said to be even more liberal than BSD license, there is an alternative standard lib for D1 - tango[1] - that uses a BSD license and the Academic Free License v3.0[2]). Also, there are already several people maintaining/developing Phobos (not just Walter and Andrei Alexandrescu). Cheers, - Daniel [1] http://www.dsource.org/projects/tango/ [2] http://www.dsource.org/projects/tango/wiki/LibraryLicense
Re: Type wrapping blockers
Am 05.10.2010 14:50, schrieb Steven Schveighoffer: One of the good goals of D I think is to be able to automatically encapsulate a type, and all its attributes/functions, in order to slightly alter the functionality. I think this is probably a pattern, but I don't know what it is (Interceptor?). One of the best methods to wrap a type is to use opDispatch. But there are some problems that block this. It might be good to get a bug report that gathers these together. I have one that I just ran into -- IFTI and literals. Basically, if you have a function: void foo(short x); you can call foo(1) no problem. But if you *wrap* the type that contains foo, you cannot use opDispatch to implement foo(1), because IFTI treats 1 as an int. So what you get is an instantiation of opDispatch like this: opDispatch!(foo, int)(1) Which then cannot call foo, because you cannot cast int to short. Does anyone have any other blockers that prevent type wrapping? Does anyone have any ideas on how to fix the above issue? -Steve Iff you are only wrapping one other thing (ie struct, class...), you should be able to use alias this. It should in my opinion correctly resolve to foo(short). If dmd doesn't find foo in your wrapper it should look for foo in the alias before saying that 1 has to be int. But I didn't test. Mafi
Re: Type wrapping blockers
On Tue, 05 Oct 2010 10:06:58 -0400, Mafi m...@example.org wrote: Am 05.10.2010 14:50, schrieb Steven Schveighoffer: One of the good goals of D I think is to be able to automatically encapsulate a type, and all its attributes/functions, in order to slightly alter the functionality. I think this is probably a pattern, but I don't know what it is (Interceptor?). One of the best methods to wrap a type is to use opDispatch. But there are some problems that block this. It might be good to get a bug report that gathers these together. I have one that I just ran into -- IFTI and literals. Basically, if you have a function: void foo(short x); you can call foo(1) no problem. But if you *wrap* the type that contains foo, you cannot use opDispatch to implement foo(1), because IFTI treats 1 as an int. So what you get is an instantiation of opDispatch like this: opDispatch!(foo, int)(1) Which then cannot call foo, because you cannot cast int to short. Does anyone have any other blockers that prevent type wrapping? Does anyone have any ideas on how to fix the above issue? -Steve Iff you are only wrapping one other thing (ie struct, class...), you should be able to use alias this. It should in my opinion correctly resolve to foo(short). If dmd doesn't find foo in your wrapper it should look for foo in the alias before saying that 1 has to be int. But I didn't test. Alias this does not allow interception of calls. I want to do something inside opDispatch besides just calling foo(1). -Steve
Re: Type wrapping blockers
Steven Schveighoffer wrote: One of the good goals of D I think is to be able to automatically encapsulate a type, and all its attributes/functions, in order to slightly alter the functionality. I think this is probably a pattern, but I don't know what it is (Interceptor?). One of the best methods to wrap a type is to use opDispatch. But there are some problems that block this. It might be good to get a bug report that gathers these together. I have one that I just ran into -- IFTI and literals. Basically, if you have a function: void foo(short x); you can call foo(1) no problem. But if you *wrap* the type that contains foo, you cannot use opDispatch to implement foo(1), because IFTI treats 1 as an int. So what you get is an instantiation of opDispatch like this: opDispatch!(foo, int)(1) Which then cannot call foo, because you cannot cast int to short. That is bug 4953.
Re: Is there anybody working on a linear algebra library for D2?
== Quote from Michael Chen (sth4...@gmail.com)'s article I remember that one of D's goal is easy scientific computation. However I haven't seen any linear algebra package for D2. My work heavily relays on all kinds of matrix stuff (matrix multiplication, factorization, linear system etc). I like D and am willing to work with D. However without these facilities I can hardly start. I'd like to have a matrix library of which the API is kind of like Matlab. Is there anybody working on this or planning to work on this? Regards, Michael You might be able to find something useful for you in this list on this page: http://www.prowiki.org/wiki4d/wiki.cgi?ScientificLibraries (You might not be able to find a D 2.x project for what you need, but it might not be much effort to make a minimal port from a D 1.x project.) Good luck. jcc7
Re: Type wrapping blockers
On Tue, 05 Oct 2010 10:25:31 -0400, Don nos...@nospam.com wrote:
Steven Schveighoffer wrote:
One of the good goals of D I think is to be able to automatically
encapsulate a type, and all its attributes/functions, in order to
slightly alter the functionality. I think this is probably a pattern,
but I don't know what it is (Interceptor?).
One of the best methods to wrap a type is to use opDispatch. But
there are some problems that block this. It might be good to get a bug
report that gathers these together. I have one that I just ran into --
IFTI and literals. Basically, if you have a function:
void foo(short x);
you can call foo(1) no problem.
But if you *wrap* the type that contains foo, you cannot use
opDispatch to implement foo(1), because IFTI treats 1 as an int. So
what you get is an instantiation of opDispatch like this:
opDispatch!(foo, int)(1) Which then cannot call foo, because you
cannot cast int to short.
That is bug 4953.
I don't think so, because I'm using IFTI to imply the argument types. A
generic opDispatch to wrap a function:
auto opDispatch(string op, Args...)(Args args)
{
/* perform interception work here */
return mixin!(wrappedVal. ~ op ~ (args));
}
If you don't know what the arguments are *supposed* to be, I'm unsure how
to derive them based on what the type being wrapped supports.
The specific situation that's failing, in dcollections, I have a function:
add(V[] elems...)
where V is the type being collected. When V == short, then calling add
directly like this:
add(1,2,3,4,5);
works fine. But calling the wrapper with add(1,2,3,4,5) fails, because
Args... is interpreted as int, int, int, int, int.
What I really need is to say hey IFTI, determine the argument types by
looking up as if it were called on this type, because that's what I'm
going to call rather than use the arguments themselves.
Bug 4953 is when IFTI should play no part in determing the argument
types. Or am I missing something?
-Steve
Re: Is D right for me?
On Tue, 05 Oct 2010 16:00:48 +0200 Daniel == Daniel Gibson metalcae...@gmail.com wrote: Daniel So, both gdc ldc are open-source? Daniel Daniel Yes. Nice. It means that, in the future, we could target ARM as well (for MeeGo). Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
On Tue, 05 Oct 2010 16:01:41 +0200 Don == Don nos...@nospam.com wrote: Don I would estimate the truck factor as between 2.0 and 2.5. Two Don years ago, the truck factor was 1.0, but not any more. Nice, nice...Still SO people say: Neither Haskell nor D is popular enough for it to be at all likely that you will ever attract a single other developer to your project... :-) If just QtD hadn't been suspended... Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is there anybody working on a linear algebra library for D2?
On 05/10/10 14:41, Michael Chen wrote: I remember that one of D's goal is easy scientific computation. However I haven't seen any linear algebra package for D2. My work heavily relays on all kinds of matrix stuff (matrix multiplication, factorization, linear system etc). I like D and am willing to work with D. However without these facilities I can hardly start. I'd like to have a matrix library of which the API is kind of like Matlab. Is there anybody working on this or planning to work on this? Regards, Michael I've attempted this in the past, however, each time I manage to work up renewed enthusiasm I keep running into compiler bugs that put me off. My current feeling is I should sit back at wait for the language to mature a little. However, once D does mature there are some neat tricks that would be possible in a matrix library. For a start you could easily build something like ATLAS with all the tuning parameters being passed as template parameters. Another neat trick might be verifying that a matrix is othoginal/unitary/whatever with invariants. Again a static if and a template parameter makes this feature really trivial to add. As for things that aren't vaporware, http://www.dsource.org/projects/mathextra/browser/trunk/blade might be a good place to start.
Re: On C/C++ undefined behaviours (there is no Eclipse)
On 02/10/2010 15:13, retard wrote: Fri, 01 Oct 2010 14:53:04 +0100, Bruno Medeiros wrote: On 20/08/2010 22:37, Nick Sabalausky wrote: retardr...@tard.com.invalid wrote in message news:i4mrss$ca...@digitalmars.com... Fri, 20 Aug 2010 19:04:41 +0200, Andrej Mitrovic wrote: What are these Java programs for the desktop that run fast? I haven't encountered any, but maybe that's just because I didn't try them all out. Eclipse takes at least 20 seconds to load on startup on my quad core, that's not very fast. On the other hand, CodeBlocks which is coded in C++ and has a few dozen plugins installed runs in an instant. Now that's a fair comparison! Crysis runs so slowly but a hello world written in Go is SO fast. This must prove that Go is much faster than C+ +! I think CodeBlocks is one of the most lightweight IDEs out there. Does it even have full semantic autocompletion? Eclipse, on the other hand, comes with almost everything you can imagine. If you turn off the syntax check, Eclipse works just as fast as any native application on a modern desktop. I've tried eclipse with the fancy stuff off, and it's still slower than C::B or PN2 for me. All these comments about Eclipse takes this time to load, or Eclipse is slow when used, etc., are really meaningless unless you tell us something about what actual plugins and features are installed and used. Unlike CodeBlocks which is a free C++ IDE, Eclipse proper is the Eclipse Platform, which is a platform (duh) and doesn't do anything useful by itself. Particularly since there is not even a standard/single Eclipse download: http://www.eclipse.org/downloads/ , unlike Codeblocks. The days were JDT would be the main thing 95% of Eclipse users would use are long gone. So are you using JDT, CDT, Descent, something else? If JDT, do you have extra tools, like the J2EE Web Tools? (these add massive bloat) What about source control plugins, or plugins not provided by the Eclipse Foundation, etc? All of these are a wildcard that can affect performance. For example, I definitely note that sometimes my workspace chokes when I do certain SVN or file related operations (with Subclipse btw, not Subversive). I also noted, when Eclipse 3.6 came out, some sluggishness when working with JDT, even when just typing code (in this case it was very subtle, almost imperceptible, but I still felt it and it was quite annoying). I suspected not JDT, but Mylyn, so I uninstalled it, and now things are back to normal. (there might be a fix or workaround for that issue in Mylyn, but since I don't use it, I didn't bother) I would definitely be quite annoying if Eclipse was not responsive for the vast majority of coding tasks. As for startup time, I hardly care anything about that : http://www.digitalmars.com/d/archives/digitalmars/D/ Re_Eclipse_startup_time_Was_questions_on_PhanTango_merger_was_Merging_Tangobos_into_Tango_60160.html#N60346 (except when I'm doing PDE development, but that's a different thing) Back then the unhappy user was using a 1 GHz Pentium M notebook. I tried this again. Guess what, the latest Eclipse Helios (3.6.1) took 3.5 (!!!) seconds to start up the whole Java workspace, open few projects and fully initialize the editors etc for the most active project. Has the original complainer ever used Photoshop, CorelDraw, AutoCad, Maya/3DSMax, Maple/ MathCad/Mathematica, or some other Real World Programs (tm)? These are all fucking slow. That's how it is: If you need to get the job done, you must use slow programs. I'm sure that the people who downright refuse to use Eclipse because it loads too slow use some other program for media development. Maybe its MS Paint (or a Linux equivalent) because it loads so fast! Or maybe its a vi/emacs plugin for image manipulation or 3D modelling. ;) -- Bruno Medeiros - Software Engineer
Re: On C/C++ undefined behaviours (there is no Eclipse)
On 02/10/2010 17:21, Don wrote: retard wrote: Fri, 01 Oct 2010 14:53:04 +0100, Bruno Medeiros wrote: On 20/08/2010 22:37, Nick Sabalausky wrote: retardr...@tard.com.invalid wrote in message news:i4mrss$ca...@digitalmars.com... Fri, 20 Aug 2010 19:04:41 +0200, Andrej Mitrovic wrote: What are these Java programs for the desktop that run fast? I haven't encountered any, but maybe that's just because I didn't try them all out. Eclipse takes at least 20 seconds to load on startup on my quad core, that's not very fast. On the other hand, CodeBlocks which is coded in C++ and has a few dozen plugins installed runs in an instant. Now that's a fair comparison! Crysis runs so slowly but a hello world written in Go is SO fast. This must prove that Go is much faster than C+ +! I think CodeBlocks is one of the most lightweight IDEs out there. Does it even have full semantic autocompletion? Eclipse, on the other hand, comes with almost everything you can imagine. If you turn off the syntax check, Eclipse works just as fast as any native application on a modern desktop. I've tried eclipse with the fancy stuff off, and it's still slower than C::B or PN2 for me. All these comments about Eclipse takes this time to load, or Eclipse is slow when used, etc., are really meaningless unless you tell us something about what actual plugins and features are installed and used. Unlike CodeBlocks which is a free C++ IDE, Eclipse proper is the Eclipse Platform, which is a platform (duh) and doesn't do anything useful by itself. Particularly since there is not even a standard/single Eclipse download: http://www.eclipse.org/downloads/ , unlike Codeblocks. The days were JDT would be the main thing 95% of Eclipse users would use are long gone. So are you using JDT, CDT, Descent, something else? If JDT, do you have extra tools, like the J2EE Web Tools? (these add massive bloat) What about source control plugins, or plugins not provided by the Eclipse Foundation, etc? All of these are a wildcard that can affect performance. For example, I definitely note that sometimes my workspace chokes when I do certain SVN or file related operations (with Subclipse btw, not Subversive). I also noted, when Eclipse 3.6 came out, some sluggishness when working with JDT, even when just typing code (in this case it was very subtle, almost imperceptible, but I still felt it and it was quite annoying). I suspected not JDT, but Mylyn, so I uninstalled it, and now things are back to normal. (there might be a fix or workaround for that issue in Mylyn, but since I don't use it, I didn't bother) I would definitely be quite annoying if Eclipse was not responsive for the vast majority of coding tasks. As for startup time, I hardly care anything about that : http://www.digitalmars.com/d/archives/digitalmars/D/ Re_Eclipse_startup_time_Was_questions_on_PhanTango_merger_was_Merging_Tangobos_into_Tango_60160.html#N60346 (except when I'm doing PDE development, but that's a different thing) Back then the unhappy user was using a 1 GHz Pentium M notebook. I tried this again. Guess what, the latest Eclipse Helios (3.6.1) took 3.5 (!!!) seconds to start up the whole Java workspace, open few projects and fully initialize the editors etc for the most active project. That's good news. Sounds as though they've fixed the startup performance bug. Not necessarily. Again, you need to consider what is installed and loading in Eclipse. In retard's scenario he was loading a Java workspace (JDT) whereas your original post was a C++ one (with CDT, I'm guessing). Even disregarding the PC specs, it's comparing apples to oranges. Eclipse is not like Firefox where the main platform is 90% of the code/functionality, and the plugins are only like 5-10%. Has the original complainer ever used Photoshop, CorelDraw, AutoCad, Maya/3DSMax, Maple/ MathCad/Mathematica, or some other Real World Programs (tm)? These are all fucking slow. That's how it is: If you need to get the job done, you must use slow programs. That original poster was me. Yes, I've used all of those programs (though not a recent version of CorelDraw). The startup time was 80 seconds, on the most most minimal standard Eclipse setup I could find. MSVC was 3 seconds on the same system. I had expected the times to be roughly comparable. There was just something sloppy in Eclipse's startup code. Any Eclipse IDE configuration/distribution is likely never going to start fast, at least as fast as comparable native IDEs like MS Visual Studio. Still, I do think that 80 seconds sounds excessive, even for those computer specs. But it's likely a CDT issue, not an Eclipse one. Again, this distinction has to be considered, you can't just say There was just something sloppy in Eclipse's startup code or Eclipse developers don't care about performance issues _at all_. The projects that come bundled in offical Eclipse distributions are not only separate projects (JDT, CDT, WTP, PDT, Mylyn, etc.), like
Re: Is there anybody working on a linear algebra library for D2?
== Quote from jcc7 (jccalvar...@gmail.com)'s article == Quote from Michael Chen (sth4...@gmail.com)'s article I remember that one of D's goal is easy scientific computation. However I haven't seen any linear algebra package for D2. My work heavily relays on all kinds of matrix stuff (matrix multiplication, factorization, linear system etc). I like D and am willing to work with D. However without these facilities I can hardly start. I'd like to have a matrix library of which the API is kind of like Matlab. Is there anybody working on this or planning to work on this? Regards, Michael You might be able to find something useful for you in this list on this page: http://www.prowiki.org/wiki4d/wiki.cgi?ScientificLibraries (You might not be able to find a D 2.x project for what you need, but it might not be much effort to make a minimal port from a D 1.x project.) Good luck. jcc7 Lars Kyllingstad's SciD library (http://dsource.org/projects/scid) is a good work in progress. Unfortunately it depends heavily on Blas and Lapack. I haven't figured out how to set these up on Windows yet. However, it's definitely off the ground and looks pretty usable for those wizards sufficiently skilled in the art of fiddling with linker settings to get crufty old C and Fortran libraries to link with D code. IMHO there should eventually be pure D versions of this functionality. I tried to get started writing it, but got sidetracked by about a million other things.
Re: About Andrei's interview, part 3
On 26/08/2010 02:25, bearophile wrote: Jonathan M Davis If D2's user base really increases like we'd like it to (and TDPL should help a lot with that), it's going to cost users a lot more when backwards compatability is broken. This is why I don't like a lot the current work done for the 64 bit implementation. D2 has some design problems (I don't call them 'enhancement requests') that if you want to fix may require to break backward compatibility (they are things that can't just be added to the D2 language), few months ago I have listed about ten of them here (and I think Walter did just ignore them), and probably few more are present (and one or two of them in the meantime have officially become 'things to fix', like the syntax for array ops that I think now officially requires obligatory [], this was one of the things in my list of little breaking changes). I'd like those problems to be fixed (or specs to take them in account, even if the compiler implementation isn't yet up to date to them) before people start using D2 and breaking backwards compatibility becomes a pain. Otherwise they risk never being fixed. Implementation matters come after design matters if you impose the constraint of keeping backwards compatibility. Bye, bearophile I don't see how fixing design problems that [..] break backward compatibility is that much of an issue for the 64 bit implementation. Unless it's a really big design change (which then I would doubt would be accepted), what kind of D design changes would really invalidate a significant amount of work done on a 64bit compiler backend implementation? -- Bruno Medeiros - Software Engineer
Re: About Andrei's interview, part 3 (on bearophile)
On 27/08/2010 03:01, Gareth Charnock wrote: On 26/08/10 07:57, Don wrote: Walter Bright wrote: bearophile wrote: This is why I don't like a lot the current work done for the 64 bit implementation. A lot of groups cannot consider D unless it supports 64 bit compilation. D2 has some design problems (I don't call them 'enhancement requests') that if you want to fix may require to break backward compatibility (they are things that can't just be added to the D2 language), few months ago I have listed about ten of them here (and I think Walter did just ignore them), 71 bugzilla issues were resolved just in the last update. I don't think it's quite fair to characterize the ongoing development as ignoring the community. You list several things *per day*. I doubt any organization could keep up with the sheer volume of your output g. I'm not suggesting that you stop doing it, quite the contrary. I just hope you can be realistic about how much can be done about them in the short term. Since February, 30% of bugzilla entries are from bearophile! It's really impressive. I kind of started thinking of Bearophile as the conscience of the newsgroup a while back ;-) Always sitting on your shoulder pointing out how things should be better or could be fixed. He really is a tireless user advocate! As for the current directly, I think the most critical matter is bugfixes, bugfixes, bugfixes, which is why I was pleased to see that last changelog. It's disheartening to run headlong into a language bug every time I code something in D2. I don't know about the rest of people here in the NG, but actually I would hope bearophile would post much less often, especially when its him creating a new thread. And that's simply because he posts way too often, with lots of detail, and it takes a lot of time to read up on all that content, and to think about it with some depth. My default behavior with threads created by bearophile is just to skim or skip them over altogether. And it has nothing to do with quality of what bearophile says, because actually I think he often makes good points and brings good insights... but there are just *way* too many of them :P (not to mention the huge stream of links to articles on other sites that often accompany bearophile's posts) So yeah, bearophile, that's my plea. :-o Some of us like to sleep the recommended number of hours... -- Bruno Medeiros - Software Engineer
Re: Is there anybody working on a linear algebra library for D2?
Gareth Charnock wrote: On 05/10/10 14:41, Michael Chen wrote: I remember that one of D's goal is easy scientific computation. However I haven't seen any linear algebra package for D2. My work heavily relays on all kinds of matrix stuff (matrix multiplication, factorization, linear system etc). I like D and am willing to work with D. However without these facilities I can hardly start. I'd like to have a matrix library of which the API is kind of like Matlab. Is there anybody working on this or planning to work on this? Regards, Michael I've attempted this in the past, however, each time I manage to work up renewed enthusiasm I keep running into compiler bugs that put me off. My current feeling is I should sit back at wait for the language to mature a little. However, once D does mature there are some neat tricks that would be possible in a matrix library. For a start you could easily build something like ATLAS with all the tuning parameters being passed as template parameters. Another neat trick might be verifying that a matrix is othoginal/unitary/whatever with invariants. Again a static if and a template parameter makes this feature really trivial to add. As for things that aren't vaporware, http://www.dsource.org/projects/mathextra/browser/trunk/blade might be a good place to start. Please don't. That was a proof of concept, which had a big influence on D's array operations and the design of D's metaprogramming support. All of the ideas from BLADE will eventually be completely incorporated into array operations. Basically, right now D has DAXPY and SAXPY from BLAS1, implemented as array operations. But it doesn't have anything else at present.
Re: About Andrei's interview, part 3 (on bearophile)
On Tue, 05 Oct 2010 19:30:59 +0400, Bruno Medeiros brunodomedeiros+s...@com.gmail wrote: On 27/08/2010 03:01, Gareth Charnock wrote: On 26/08/10 07:57, Don wrote: Walter Bright wrote: bearophile wrote: This is why I don't like a lot the current work done for the 64 bit implementation. A lot of groups cannot consider D unless it supports 64 bit compilation. D2 has some design problems (I don't call them 'enhancement requests') that if you want to fix may require to break backward compatibility (they are things that can't just be added to the D2 language), few months ago I have listed about ten of them here (and I think Walter did just ignore them), 71 bugzilla issues were resolved just in the last update. I don't think it's quite fair to characterize the ongoing development as ignoring the community. You list several things *per day*. I doubt any organization could keep up with the sheer volume of your output g. I'm not suggesting that you stop doing it, quite the contrary. I just hope you can be realistic about how much can be done about them in the short term. Since February, 30% of bugzilla entries are from bearophile! It's really impressive. I kind of started thinking of Bearophile as the conscience of the newsgroup a while back ;-) Always sitting on your shoulder pointing out how things should be better or could be fixed. He really is a tireless user advocate! As for the current directly, I think the most critical matter is bugfixes, bugfixes, bugfixes, which is why I was pleased to see that last changelog. It's disheartening to run headlong into a language bug every time I code something in D2. I don't know about the rest of people here in the NG, but actually I would hope bearophile would post much less often, especially when its him creating a new thread. And that's simply because he posts way too often, with lots of detail, and it takes a lot of time to read up on all that content, and to think about it with some depth. My default behavior with threads created by bearophile is just to skim or skip them over altogether. And it has nothing to do with quality of what bearophile says, because actually I think he often makes good points and brings good insights... but there are just *way* too many of them :P (not to mention the huge stream of links to articles on other sites that often accompany bearophile's posts) So yeah, bearophile, that's my plea. :-o Some of us like to sleep the recommended number of hours... No way! Just don't read his posts if you are not interested.
Re: Type wrapping blockers
Steven Schveighoffer schvei...@yahoo.com wrote: But if you *wrap* the type that contains foo, you cannot use opDispatch to implement foo(1), because IFTI treats 1 as an int. So what you get is an instantiation of opDispatch like this: opDispatch!(foo, int)(1) Which then cannot call foo, because you cannot cast int to short. Does anyone have any other blockers that prevent type wrapping? Does anyone have any ideas on how to fix the above issue? Not directly. However, you could probably coerce std.typecons' AutoImplement to do your wrapping for you. -- Simen
Re: Module-level accessibility
On 10/5/10 7:40 CDT, Steven Schveighoffer wrote:
On Tue, 05 Oct 2010 03:25:03 -0400, Jacob Carlborg d...@me.com wrote:
Who says we need to implement it as g++ does? DMD could implement it
to not allow that.
The derived class controls everything. You cannot take control away from
the derived class, it just can't be done:
class A
{
private void cantCallMe();
}
class B : A
{
override private void cantCallMe() { butICanCallYou(); }
private void butICanCallYou() { /* do impl */ }
}
so far, private virtual functions == annoyance. I haven't seen anything
to prove otherwise yet.
-Steve
Private overridable functions come with a guarantee that hooks can never
be called from an unknown/uncontrolled context.
Andrei
Re: About Andrei's interview, part 3 (on bearophile)
Bruno Medeiros brunodomedeiros+s...@com.gmail wrote: I don't know about the rest of people here in the NG, but actually I would hope bearophile would post much less often, especially when its him creating a new thread. And that's simply because he posts way too often, with lots of detail, and it takes a lot of time to read up on all that content, and to think about it with some depth. My default behavior with threads created by bearophile is just to skim or skip them over altogether. And it has nothing to do with quality of what bearophile says, because actually I think he often makes good points and brings good insights... but there are just *way* too many of them :P (not to mention the huge stream of links to articles on other sites that often accompany bearophile's posts) Understandable, but bearophile's threads are often among the most interesting ones I feel, and well worth staying up late for. So yeah, bearophile, that's my plea. :-o Some of us like to sleep the recommended number of hours... That I've given up on a long time ago. -- Simen
Re: Type wrapping blockers
On 10/5/10 9:15 CDT, Steven Schveighoffer wrote: On Tue, 05 Oct 2010 10:06:58 -0400, Mafi m...@example.org wrote: Am 05.10.2010 14:50, schrieb Steven Schveighoffer: One of the good goals of D I think is to be able to automatically encapsulate a type, and all its attributes/functions, in order to slightly alter the functionality. I think this is probably a pattern, but I don't know what it is (Interceptor?). One of the best methods to wrap a type is to use opDispatch. But there are some problems that block this. It might be good to get a bug report that gathers these together. I have one that I just ran into -- IFTI and literals. Basically, if you have a function: void foo(short x); you can call foo(1) no problem. But if you *wrap* the type that contains foo, you cannot use opDispatch to implement foo(1), because IFTI treats 1 as an int. So what you get is an instantiation of opDispatch like this: opDispatch!(foo, int)(1) Which then cannot call foo, because you cannot cast int to short. Does anyone have any other blockers that prevent type wrapping? Does anyone have any ideas on how to fix the above issue? -Steve Iff you are only wrapping one other thing (ie struct, class...), you should be able to use alias this. It should in my opinion correctly resolve to foo(short). If dmd doesn't find foo in your wrapper it should look for foo in the alias before saying that 1 has to be int. But I didn't test. Alias this does not allow interception of calls. I want to do something inside opDispatch besides just calling foo(1). -Steve If you only want to intercept a few specific calls, you may want to use alias this and simply define the appropriate methods. They will be found by name lookup before alias this kicks in. For intercepting all calls even to method names you don't know, indeed opDispatch is the way to go. Andrei
Re: Type wrapping blockers
On Tue, 05 Oct 2010 16:50:04 +0400, Steven Schveighoffer schvei...@yahoo.com wrote: One of the good goals of D I think is to be able to automatically encapsulate a type, and all its attributes/functions, in order to slightly alter the functionality. I think this is probably a pattern, but I don't know what it is (Interceptor?). One of the best methods to wrap a type is to use opDispatch. But there are some problems that block this. It might be good to get a bug report that gathers these together. I have one that I just ran into -- IFTI and literals. Basically, if you have a function: void foo(short x); you can call foo(1) no problem. But if you *wrap* the type that contains foo, you cannot use opDispatch to implement foo(1), because IFTI treats 1 as an int. So what you get is an instantiation of opDispatch like this: opDispatch!(foo, int)(1) Which then cannot call foo, because you cannot cast int to short. Does anyone have any other blockers that prevent type wrapping? Does anyone have any ideas on how to fix the above issue? -Steve You can try iterating over all class methods and construct proxy ones using string mixins at compile time. Might be next to impossible to implement properly though :)
Re: Is D right for me?
On 10/5/10 9:37 CDT, Gour D. wrote: On Tue, 05 Oct 2010 16:01:41 +0200 Don == Donnos...@nospam.com wrote: Don I would estimate the truck factor as between 2.0 and 2.5. Two Don years ago, the truck factor was 1.0, but not any more. Nice, nice...Still SO people say: Neither Haskell nor D is popular enough for it to be at all likely that you will ever attract a single other developer to your project... :-) If developer attraction is a concern, you're likely better off with D. Programmers who have used at least one Algol-like language (C, C++, Java, C#) will have no problem feeling comfortable in D. With Haskell you'd need to stick with the choir. If just QtD hadn't been suspended... I agree that's a bummer. I suggest you write the developers and ask what would revive their interest. The perspective of a solid client is bound to be noticeable. Andrei
Re: Module-level accessibility
On Tue, 05 Oct 2010 12:07:21 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 10/5/10 7:40 CDT, Steven Schveighoffer wrote:
On Tue, 05 Oct 2010 03:25:03 -0400, Jacob Carlborg d...@me.com wrote:
Who says we need to implement it as g++ does? DMD could implement it
to not allow that.
The derived class controls everything. You cannot take control away from
the derived class, it just can't be done:
class A
{
private void cantCallMe();
}
class B : A
{
override private void cantCallMe() { butICanCallYou(); }
private void butICanCallYou() { /* do impl */ }
}
so far, private virtual functions == annoyance. I haven't seen anything
to prove otherwise yet.
-Steve
Private overridable functions come with a guarantee that hooks can never
be called from an unknown/uncontrolled context.
And when would a protected hook be callable from an unknown/uncontrolled
context? In whose eyes, the base or derived class?
The thing is, any class that defines a private function implementation is
able to call it. You can't prevent that. So in the eyes of any base
class, it has no way to restrict that. In the eyes of the derived class,
it has no control over whether a base class can call it or not.
Essentially a private overridable function has one additional guarantee
over a protected function -- a derived class cannot call it if it hasn't
defined its own version (and isn't in the same module). But that's not
the property desired, the property desired for NVI is that *nobody* can
call it except the base class, even derived classes. That's simply not
possible. So we have to pretend that we can't call it, which is fine,
just as easy with protected.
Consider this:
abstract class A
{
public void myAPIFn() { foo(); }
abstract private void foo();
}
abstract class B : A
{
public void bar() {myAPIFn();}
}
class C : B
{
private void foo() {}
}
So good so far. But I can alter B so it can circumvent myAPIFn by adding
its own implementation for foo (which does nothing), and now I'm able to
call foo directly from myAPIFn. Basically, even though B does not intend
for its version of foo to be the real implementation (knowing that it's
abstract and must be derived), it can hijack A's ability to funnel all
calls through myAPIFn by simply adding a blank function.
I just don't see the benefit over protected anywhere. You can't say
you're allowed to define this, but you're not allowed to call it. That
makes no sense at all, and as I've shown, is impossible to enforce.
-Steve
Re: One more update on d-programming-language.org
On 10/09/2010 01:07, Andrei Alexandrescu wrote: http://d-programming-language.org From David Gileadi: the annoying Google Translate bar behavior on browsers with other languages has been fixed, the behavior when shrinking and growing the window size has been improved, the Reddit button is gone, and a few styles were changed. Could have sworn I sent this already, it just disappeared. Andrei The Translate gadget looks broken on my machine: http://oi56.tinypic.com/2r23was.jpg (latest Firefox, default zoom) Also, the search section looks fugly, IMO. The textbutton itself is not bad, but the dropdown is, and not just on aspect, but also functionality. I'm surprised no else commented likewise. :( My suggestion is to remove the drop-down altogether. Let the more refined search scope options be available elsewhere, perhaps on the search results page itself. Also, we should use Google Custom Search. Just linking to raw google looks amateurish. That's because (amongst other things) the search page shows up with all the Google personalized homepage stuff (if you enable it for google.com). Compare: http://oi55.tinypic.com/350mmxc.jpg to: http://www.google.com/cse?q=foobarcx=013598269713424429640%3Ag5orptiw95wie=UTF-8sa=Search Here's an example of what I'm suggesting for the search functionality, try it out: http://svn.dsource.org/projects/descent/downloads/dwebpage.htm (obviously the layout and colors are broken, I just want to demo the functionality, especially using Google Custom Search) An alternative is to maintain the current behavior: and have the search page be presented on its own, instead of contained the D programming language site: http://www.google.com/cse?cx=016833344392370455076%3Afjy38cei55cie=UTF-8q=foobarsa=Search However I don't know how to customize the CSS for this hosted page, plus, when you click the scope labels, the search query changes: you get an annoying extra more:library_reference keyword one it. Meh. Yet another alternative is to put the search textbutton as a section in the navigation leftbar, and put the three search scopes as 3 radio buttion options, each on their own line... but please, no dropdown on a header! :S -- Bruno Medeiros - Software Engineer
Re: Is there anybody working on a linear algebra library for D2?
On 05/10/10 16:31, Don wrote: Gareth Charnock wrote: On 05/10/10 14:41, Michael Chen wrote: I remember that one of D's goal is easy scientific computation. However I haven't seen any linear algebra package for D2. My work heavily relays on all kinds of matrix stuff (matrix multiplication, factorization, linear system etc). I like D and am willing to work with D. However without these facilities I can hardly start. I'd like to have a matrix library of which the API is kind of like Matlab. Is there anybody working on this or planning to work on this? Regards, Michael I've attempted this in the past, however, each time I manage to work up renewed enthusiasm I keep running into compiler bugs that put me off. My current feeling is I should sit back at wait for the language to mature a little. However, once D does mature there are some neat tricks that would be possible in a matrix library. For a start you could easily build something like ATLAS with all the tuning parameters being passed as template parameters. Another neat trick might be verifying that a matrix is othoginal/unitary/whatever with invariants. Again a static if and a template parameter makes this feature really trivial to add. As for things that aren't vaporware, http://www.dsource.org/projects/mathextra/browser/trunk/blade might be a good place to start. Please don't. That was a proof of concept, which had a big influence on D's array operations and the design of D's metaprogramming support. All of the ideas from BLADE will eventually be completely incorporated into array operations. Basically, right now D has DAXPY and SAXPY from BLAS1, implemented as array operations. But it doesn't have anything else at present. Okay, sorry, I may have somewhat misunderstood the purpose of that library, I hadn't really looked at it in great detail, I just knew it was a math library.
Immutable and cache coherence
I've been reading about caching mechanisms in today's processors -- amazing in their intricacy. It made me wonder, is there a way to exclude immutable regions of memory from a cache coherence mechanism? I mean, let the processor know: no invalidation for cache lines from immutable memory. And even if it's possible, how much would it really help? I have no intuition about how expensive those coherence mechanisms are. CPU geeks speak up! :) -- Tomek
Re: Is D right for me?
On Tue, 05 Oct 2010 11:29:03 -0500 Andrei == Andrei Alexandrescu wrote: Andrei If developer attraction is a concern, you're likely better off Andrei with D. Programmers who have used at least one Algol-like Andrei language (C, C++, Java, C#) will have no problem feeling Andrei comfortable in D. With Haskell you'd need to stick with the Andrei choir. Yeah, I'm aware of it... btw, let me personally congatulate for a great talk at Google! Andrei I agree that's a bummer. I suggest you write the developers and Andrei ask what would revive their interest. The perspective of a Andrei solid client is bound to be noticeable. You think that D beginner with a open-source project is solid client? Otoh, there is nothing to lose... Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Type wrapping blockers
On Tue, 05 Oct 2010 08:50:04 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
One of the good goals of D I think is to be able to automatically
encapsulate a type, and all its attributes/functions, in order to
slightly alter the functionality. I think this is probably a pattern,
but I don't know what it is (Interceptor?).
One of the best methods to wrap a type is to use opDispatch. But there
are some problems that block this. It might be good to get a bug report
that gathers these together. I have one that I just ran into -- IFTI
and literals. Basically, if you have a function:
void foo(short x);
you can call foo(1) no problem.
But if you *wrap* the type that contains foo, you cannot use opDispatch
to implement foo(1), because IFTI treats 1 as an int. So what you get
is an instantiation of opDispatch like this:
opDispatch!(foo, int)(1) Which then cannot call foo, because you
cannot cast int to short.
Does anyone have any other blockers that prevent type wrapping? Does
anyone have any ideas on how to fix the above issue?
Found another one, really old bug: 1748
Basically, if you have
class C(T)
{
}
and you try to get (C!int).stringof you get just C. This makes
specifying wrapped arguments that are class templates impossible for
mixins.
I'm giving up my workaround to try and implement the Nifty chaining, it
appears it's just not possible with the compiler bugs today :(
-Steve
Re: Immutable and cache coherence
Tue, 05 Oct 2010 20:49:34 +0200, Tomek Sowiński wrote: I've been reading about caching mechanisms in today's processors -- amazing in their intricacy. It made me wonder, is there a way to exclude immutable regions of memory from a cache coherence mechanism? I mean, let the processor know: no invalidation for cache lines from immutable memory. And even if it's possible, how much would it really help? I have no intuition about how expensive those coherence mechanisms are. CPU geeks speak up! :) What generation of CPUs are you talking about? Based on discussions here, it seems people like Nick S. are still using single core, single socket PII/PIII class systems. The Opteron/Xeon systems look like NUMA systems and consumer systems use the simpler FSB. I don't know about other architectures.
Re: Is there anybody working on a linear algebra library for D2?
Gareth Charnock napisał: I've attempted this in the past, however, each time I manage to work up renewed enthusiasm I keep running into compiler bugs that put me off. My current feeling is I should sit back at wait for the language to mature a little. Welcome to the club:) I'm writing matrix modules for my QuantLibD project but compiler/Phobos bugs/changes are slowing me down. I wonder how many people belong to that 'club'. If we join forces, we *might* end up with a usable matrix lib:) -- Tomek
Re: phobos is failure
On Tue, 05 Oct 2010 23:59:20 +1100, Darth Tango da...@death-to-phobos.org wrote: Exackaly. Tango rulez. May the meta-force be beside you. :-) Darth My Lord, how is the migration of Tango to D2 going? The last commit I saw on the experimental branch was pretty old.
Re: Immutable and cache coherence
Tomek S.: is there a way to exclude immutable regions of memory from a cache coherence mechanism? I mean, let the processor know: no invalidation for cache lines from immutable memory. I don't know the answer, but regarding cache coherence and immutable data, if your data structure (like a graph) is immutable, then it doesn't need free spaces and data necessary to allow its growth. So you are often able to pack it more in memory, and this saves some RAM and reduces cache misses, improving performance too. Bye, bearophile
Re: On C/C++ undefined behaviours (there is no Eclipse)
Am 02.10.2010 21:21, schrieb Don: Sadly, software seems to be bloating at a rate which is faster than Moore's law. That's Wirth's law. See http://en.wikipedia.org/wiki/Wirth%27s_law . Mafi
Re: phobos is failure
On Tue, 05 Oct 2010 15:10:33 -0400, Juanjo Alvarez f...@fakeemail.com wrote: On Tue, 05 Oct 2010 23:59:20 +1100, Darth Tango da...@death-to-phobos.org wrote: Exackaly. Tango rulez. May the meta-force be beside you. :-) Darth My Lord, how is the migration of Tango to D2 going? The last commit I saw on the experimental branch was pretty old. Look at who did it :) I think it's safe to say D2 for tango isn't going to happen any time soon, if at all. -Steve
Re: On C/C++ undefined behaviours (there is no Eclipse)
On Tue, 5 Oct 2010 17:59:26 + (UTC), retard r...@tard.com.invalid wrote: I assume all of them (the latest versions, of course) start in less than 3.5 seconds. I pondered this a bit and am now willing to buy Don's magic computer. I really do have need for a laptop that can launch those applications in less than 3.5 seconds. Yes, my 2.40ghz i5 with 6gbs RAM takes about ten seconds to open Eclipse 64bits; I need to get one of those SSDs.
Re: About Andrei's interview, part 3 (on bearophile)
On Tue, 05 Oct 2010 16:30:59 +0100, Bruno Medeiros brunodomedeiros+s...@com.gmail wrote: I don't know about the rest of people here in the NG, but actually I would hope bearophile would post much less often, especially when its I like to read his posts. If you used a NNTP reader on a smartphone (like, SPAM, the one I wrote for Android) you could reserve these posts for some moments like waiting in a queue or the tea to start boiling ;)
Re: Is D right for me?
On Tue, 05 Oct 2010 20:29:03 +0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 10/5/10 9:37 CDT, Gour D. wrote: On Tue, 05 Oct 2010 16:01:41 +0200 Don == Donnos...@nospam.com wrote: Don I would estimate the truck factor as between 2.0 and 2.5. Two Don years ago, the truck factor was 1.0, but not any more. Nice, nice...Still SO people say: Neither Haskell nor D is popular enough for it to be at all likely that you will ever attract a single other developer to your project... :-) If developer attraction is a concern, you're likely better off with D. Programmers who have used at least one Algol-like language (C, C++, Java, C#) will have no problem feeling comfortable in D. With Haskell you'd need to stick with the choir. If just QtD hadn't been suspended... I agree that's a bummer. I suggest you write the developers and ask what would revive their interest. The perspective of a solid client is bound to be noticeable. Andrei I've heard from one of the developers that one of the most frustrating parts was inability of having struct default ctors (http://d.puremagic.com/issues/show_bug.cgi?id=3852), and dtors that aren't called (http://d.puremagic.com/issues/show_bug.cgi?id=3516). I also know they also had *huge* issues with optlink (http://d.puremagic.com/issues/show_bug.cgi?id=2436 and many others), but those hopefully got fixed. I'll try to talk eldar into sharing his development experience and the issues they came across. Until then you may be interested in reading these posts: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=103453 http://h3.gd/devlog/?p=22 - increasingly more people are unsatisfied with D2 and talking about a fork so I wouldn't be surprised to see one sooner or later (!)
Re: Is D right for me?
Every language you choose will have its issue, and your listed requirements are basically set up so the answer is 'none.' Not one language fulfills every requirement for various reasons. It sounds to me like you want to use Haskel but due to the loss in potential help you are looking at D. You say there were a few people who didn't get on board because of Haskel, ask them if instead D was used would the join. If not go with Haskel, if yes than I wish to make on thing clear. You will have to support the libraries you use or wait patiently. I am not saying there isn't code to use or people willing/working to support that code. I mean that we are a small community and have had some ruff hills to clime. Lots of libraries/tools were written for D1, lots of libraries were written using Tango (D1 only). Even when effort was taken to support D2, the result was a broken library on a future compiler release (it was expected as it was clearly stated, no longer the issue). So even if something claims support for D2 it may require work to bring it up to the latest language specs. But the community is working, things are progressing. And I don't think D will be dieing. The more libraries D has, the more users will come and use the language resulting in more libraries. Right now we are missing some vital libraries that everyone wants, but no one wants to make/maintain (usually do to time issues). In relation to compilers[1] I would not worry about it. By the time your project reaches a stage that must work an more platforms, it is likely that LDC and GDC, and maybe even DMD will be updated for D2 and a multitude of platforms. But for a GUI library, you would probably need to choose one and progress it as you do the project. I do not wish to discourage you from choosing D, but feel it is always good to know what to expect. And really you could probably start your project, test the components you wish to use. It should be pretty obvious if you find something you couldn't live with. 1. http://www.wikiservice.at/d/wiki.cgi?D__Tutorial/StartingWithD/Compiler
Re: Immutable and cache coherence
Tomek Sowiński wrote: I've been reading about caching mechanisms in today's processors -- amazing in their intricacy. It made me wonder, is there a way to exclude immutable regions of memory from a cache coherence mechanism? I mean, let the processor know: no invalidation for cache lines from immutable memory. And even if it's possible, how much would it really help? I have no intuition about how expensive those coherence mechanisms are. CPU geeks speak up! :) Based on my reading of AMD's docs, it should happen automatically. The cache lines will be marked as 'exclusive' when the first core reads them, and will change to 'shared' when other cores read them. Whenever a new core accesses that memory, it will ALWAYS get it from the main memory, never from the other cores. As far as I know, the cost for cache coherency comes when core-to-core transfer is required.
Re: Is D right for me?
Denis Koroskin: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=103453 Yes, among the things D2 is designed to support, a there's a lack of built-in (or user-defined) basic features to create GUIs. But the good thing is that (I think) all the useful features here are additive changes. Bye, bearophile
Re: Is D right for me?
On Tue, 05 Oct 2010 23:59:07 +0400 Denis == Denis Koroskin 2kor...@gmail.com wrote: Denis ...increasingly more people are unsatisfied with D2 and talking Denis about a fork so I wouldn't be surprised to see one sooner or Denis later (!) Unsatisfied that D2 changed (too) much or with bugs and development in general? To me, it looks very early to fork D2... Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
On Tue, 05 Oct 2010 16:14:49 -0400 Jesse == Jesse Phillips jessekphillip...@gmail.com wrote: Jesse Every language you choose will have its issue, and your listed Jesse requirements are basically set up so the answer is 'none.' Not Jesse one language fulfills every requirement for various reasons. True. Jesse It sounds to me like you want to use Haskel but due to the loss Jesse in potential help you are looking at D. Well, I'm somewhat familiar with Haskell and have zero experience with D. Not even knowing which build system one use to develop. Jesse You will have to support the libraries you use or wait Jesse patiently. I am not saying there isn't code to use or people Jesse willing/working to support that code. I mean that we are a small Jesse community and have had some ruff hills to clime. Right. I'm ready to help, according to my skills, the projects providing bindings as I'd do to e.g. help qthaskell project, but with Haskell one, at least, does not start from the scratch. Here, I'd choose D, it is not certain that QtD will be revived at any time in the future. Jesse Lots of libraries/tools were written for D1, lots of libraries Jesse were written using Tango (D1 only). Even when effort was taken Jesse to support D2, the result was a broken library on a future Jesse compiler release (it was expected as it was clearly stated, no Jesse longer the issue). Otoh, GHC is quite stable and 7.0 is just around the corner... Jesse So even if something claims support for D2 it may require work Jesse to bring it up to the latest language specs. But the community Jesse is working, things are progressing. And I don't think D will be Jesse dieing. But I already heard rumors about the fork of D2? JesseThe more libraries D has, the more users will come and Jesse use the language resulting in more libraries. Right now we are Jesse missing some vital libraries that everyone wants, but no one Jesse wants to make/maintain (usually do to time issues). I'm following Haskell community for quite some time and I know when there was no Hackage at all, iow I can understand what it means 'young' community. However, it looks that D1 -- D2 has brought different winds, altgough it will probably pay off later. Jesse In relation to compilers[1] I would not worry about it. By the Jesse time your project reaches a stage that must work an more Jesse platforms, it is likely that LDC and GDC, and maybe even DMD Jesse will be updated for D2 and a multitude of platforms. Correct. Having choice for compiler is great and makes one peaceful. Jesse But for a GUI library, you would probably need to choose one Jesse and progress it as you do the project. This is a big problem for a desktop GUI project making the whole project very uncertain right from the beginning... Jesse I do not wish to discourage you from choosing D, but feel it is Jesse always good to know what to expect. And really you could Jesse probably start your project, test the components you wish to Jesse use. It should be pretty obvious if you find something you Jesse couldn't live with. As I wrote earlier, besides sqlite3 bindings and using existent C-lib which needs to be bound to D, we need to write lot of native libs for our app, but it all fails without proper GUI. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature
Re: Is D right for me?
On 10/5/10 14:59 CDT, Denis Koroskin wrote: http://h3.gd/devlog/?p=22 - increasingly more people are unsatisfied with D2 and talking about a fork so I wouldn't be surprised to see one sooner or later (!) I'm confused. Reading through the link reveals exactly two people mentioning that a fork would be good. That doesn't quite qualify for increasingly more people in normal conversation. Andrei
Re: Is D right for me?
Gour D. schrieb: On Tue, 05 Oct 2010 16:14:49 -0400 Jesse == Jesse Phillips jessekphillip...@gmail.com wrote: Jesse You will have to support the libraries you use or wait Jesse patiently. I am not saying there isn't code to use or people Jesse willing/working to support that code. I mean that we are a small Jesse community and have had some ruff hills to clime. Right. I'm ready to help, according to my skills, the projects providing bindings as I'd do to e.g. help qthaskell project, but with Haskell one, at least, does not start from the scratch. Here, I'd choose D, it is not certain that QtD will be revived at any time in the future. What about using gtk instead of qt? GtkD is, according to their homepage ( http://www.dsource.org/projects/gtkd ) and http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries stable and usable. BTW: the quotation style of your email/ng-client is strange.
Enum proprierties
The current way enums are designed may cause name clashes that the DMD ignores:
enum SillyEnum {
init,
length,
max,
min,
}
And to find some basic info about an enum you have to use not nice things as
EnumMembers and __traits(allMembers) scattered around.
So here I have suggested to disallow a single field name like meta or info
and use it to access enum information:
http://d.puremagic.com/issues/show_bug.cgi?id=4997
Example:
import std.stdio: writeln;
enum MyEnum : ushort {
FOO = 10,
BAR = 20,
BAZ = 40,
SPAM = 30
}
void main() {
writeln(First enum member value: , MyEnum.meta.init);
writeln(Smallest value of enum: , MyEnum.meta.min);
writeln(Largest value of enum: , MyEnum.meta.max);
writeln(Size of storage for an enumerated value: , MyEnum.meta.sizeof);
writeln(Number of enum members: , MyEnum.meta.length);
writeln(Enum Base Type: , MyEnum.meta.basetype.stringof); // was wrong
in bug 4997
writeln(Enum names as strings: , MyEnum.meta.names);
writeln(Enum values: , MyEnum.meta.values);
}
Bye,
bearophile
What would you rewrite in D?
Just asking out of curiosity. With all the great language features, I'm sure that many of you have thought about this. For me, I figured a good start would be your basic Unix/Linux/BSD utilities, like cat and grep. I figure it may make the code easier to read and maintain as well as potentially improve the quality of the software. Of course, most of these are so old they're probably quite bug free, but some probably could use a rewrite. Some may even benefit for threading. Anyone else? Casey
Re: Is D right for me?
Gour D. wrote: Andrei I agree that's a bummer. I suggest you write the developers and Andrei ask what would revive their interest. The perspective of a Andrei solid client is bound to be noticeable. You think that D beginner with a open-source project is solid client? Otoh, there is nothing to lose... Few things work better than customers letting a company know they are interested in such-and-such a product.
Re: What would you rewrite in D?
sybrandy: Anyone else? There are several things I'd like to translate to D. Some of them are: - a constraint solver that I use in Python - many small things to perform combinatorics (this is partially fit for Phobos2 too). - The mem.c/mem.h memory management utility written by Walter for C programming, from here: http://c.snippets.org/code/temp/snip-c.zip for when you need to use manual memory management in D :-) - A hierarchical memory manager, http://swapped.cc/halloc/ again for low-level manual memory management. - This little C++ solver for the fifteen puzzle: http://www.codeguru.com/dbfiles/get_file/puzzle_src.zip - Some other small and medium-sized bioinformatics tools. Bye, bearophile
Re: Is D right for me?
Jesse But for a GUI library, you would probably need to choose one Jesse and progress it as you do the project. This is a big problem for a desktop GUI project making the whole project very uncertain right from the beginning... What I meant was that there is something created and functioning (I really don't know how much) which may be just what you need. But I can not state that cross-platform GUI is available for D at this time.
Re: Immutable and cache coherence
As far as I know, the cost for cache coherency comes when core-to-core transfer is required. Can we expect thread-local storage to be faster than shared memory ?
Re: phobos is failure
Are you using a translator to translate from Chinese to English? Read-understand“ doesn't mean understand in English, only in Chinese :). Phobos2 is being worked on right now. I think it's getting better. On Tue, Oct 5, 2010 at 5:11 AM, dolive doliv...@sina.com wrote: Yao G. 写到: On Tue, 05 Oct 2010 04:11:18 -0500, dolive doliv...@sina.com wrote: 2, templat + range subversion use habit, Lost the popularization base sorry! I don't understand this last point. sorry! -- Yao G. Don't read understand for templat + range for most people (Including me), Lost the popular base .
Suggestions for std.stream (esp. for 64bit)
I'm using some of std.stream's classes (and also SocketStream) in a
project of mine (it currently uses D1 but std.Stream hasn't changed much
so all this is valid for D2 as well).
std.stream is mostly what I expect from classes for Streams (having
experience with Java's equivalents). However there are a few things that
I think could/should be improved.
1. (important for 64bit D): write(char[]) and read(char[]) are too
platform specific.
These methods (and the wchar counterparts) write (or read) a string,
together with its length. This is fine (even though I would rather
expect writeString/readString to do this magic, but nevermind), *but*
the length is written as a size_t - making it heavily platform dependant.
This means that you can't use write(char[]) to write into a file on a
x86 system and later read that file on an amd64 system. Also consider
SocketStream.. you can't use SocketStream.write(char[]) to communicate
between a x86 and an amd64 box (when an 64bit executable is used an the
latter).
This could easily be fixed by using uint or ulong instead of size_t on
all platforms. (uint is probably ok, Java even uses short in a similar
method (java.io.DataOutput.writeUTF() - never use this, it's no real
UTF-8)).
Unfortunately the libphobos of GDC (that already supports 64bit targets)
has been using size_t for ages, so in D1 it should maybe stay like that
to avoid breaking compatibility (on the other hand probably no GDC user
who thinks at least a bit cross-platform uses write(char[]) anyway - in
that case just use uint so it's compatible with existing 32bit binaries
from DMD).
But at least for D2/phobos2 that should be changed.
2. The documentation says for write(): Outside of byte, ubyte, and
char, the format is implementation-specific and should only be used in
conjunction with read. Throw WriteException on error.
So how do I write files for other programs to read? How do I communicate
with servers/clients not written in D with a SocketStream?
Fortunately the documentation exaggerates. Apart from write(char[]) and
write(wchar[]) the claim is not true.
The simple types are platform specific, not specific to D/std.stream -
so a program written in C (or any other language) is probably able to
read that data (if it supports the type - may be tricky with real and
maybe the imaginary types).
And by using the EndianStream, most of the types probably can be read by
other platforms (again, real and the imaginary types might cause
trouble.. and maybe floating point types in general, if the other
platform doesn't support IEEE 754 floats - but integer types are
definitely safe).
This is bad, because if someone wants to use SocketStream he's confused
by that statement until he looks at the source to find out that it's not
so implementation specific after all.
So please document how exactly write( (w)char[]) encodes the length and
also make clear that write( basic type ) does no strange voodoo, but
just dumps the bytes of the value (in platform specific big/little
endian order).
3. InputStream's read( type val) often is inconvenient.
If you want to read an int (or any other basic type) from an InputStream
s you have to do:
int foo; s.read(foo);
This doesn't look soo horrible.. but maybe you want to pass that value
directly to a function?
int foo; s.read(foo); bar(foo);
This is inconvenient. Java has something like Stream.readInt(), so you
can write
bar( s.readInt() );
That's much shorter and you don't need to invent a name for that value
you only want to use once anyway.
For D I'd suggest a templated method for that:
T read(T)() { T ret; readExact(ret, ret.sizeof); return ret; }
So you could write
int foo = s.read!int; // instead of int foo; s.read(foo);
or even
auto foo = s.read!int;
and
bar( s.read!int ); // instead of int foo; s.read(foo); bar(foo);
(The implementation should probably make sure T is a basic type or maybe
a struct, but no array or Object or pointer. Also special cases for
char[] and wchar[] might be needed for consistency.)
4. Minor inconsistencies:
In InputStream there is a read(ubyte[]) method, but no
readExact(ubyte[]) method.
I'd suggest adding
void readExact(ubyte[] buf) { readExact(buf.ptr, buf.length); }
and, for convenience
ubyte[] readExact(size_t len) {
ubyte[] ret = new ubyte[len];
readExact(ret.ptr, len);
return ret;
}
Also there is a write(ubyte[]) method in OutputStream, but no
writeExact(ubyte[]) method, so I'd suggest adding
void writeExact(ubyte[] buf) { // maybe const(ubyte[]) buf for D2
writeExact(buf.ptr, buf.length);
}
All code above is untested and thus to be considered pseudo-code ;-)
Cheers,
- Daniel
Re: Module-level accessibility
On Tuesday 05 October 2010 09:42:14 Steven Schveighoffer wrote:
And when would a protected hook be callable from an unknown/uncontrolled
context? In whose eyes, the base or derived class?
The thing is, any class that defines a private function implementation is
able to call it. You can't prevent that. So in the eyes of any base
class, it has no way to restrict that. In the eyes of the derived class,
it has no control over whether a base class can call it or not.
Essentially a private overridable function has one additional guarantee
over a protected function -- a derived class cannot call it if it hasn't
defined its own version (and isn't in the same module). But that's not
the property desired, the property desired for NVI is that *nobody* can
call it except the base class, even derived classes. That's simply not
possible. So we have to pretend that we can't call it, which is fine,
just as easy with protected.
Consider this:
abstract class A
{
public void myAPIFn() { foo(); }
abstract private void foo();
}
abstract class B : A
{
public void bar() {myAPIFn();}
}
class C : B
{
private void foo() {}
}
So good so far. But I can alter B so it can circumvent myAPIFn by adding
its own implementation for foo (which does nothing), and now I'm able to
call foo directly from myAPIFn. Basically, even though B does not intend
for its version of foo to be the real implementation (knowing that it's
abstract and must be derived), it can hijack A's ability to funnel all
calls through myAPIFn by simply adding a blank function.
I just don't see the benefit over protected anywhere. You can't say
you're allowed to define this, but you're not allowed to call it. That
makes no sense at all, and as I've shown, is impossible to enforce.
Well, I don't see why it wouldn't be possible for the compiler to enforce that
overridden private methods can't be called by anyone but the base class. That
being the case, then allowing for private virtual functions is most definitely
useful. However, if it really isn't possible to restrict it so that derived
classes can't call the private methods that they've overridden, then I do agree
that we might as well just stick to using protected and make private functions
unoverridable. But if we _can_ make it so that derived classes can't call
overridden private methods, I think that that would be valuable and desirable.
- Jonathan M Davis
Re: What would you rewrite in D?
DMD -- ... IXOYE
Re: What would you rewrite in D?
There is DDMD. On Wed, Oct 6, 2010 at 10:04 AM, BCS n...@anon.com wrote: DMD -- ... IXOYE
Re: What would you rewrite in D?
On 10/5/10 17:27 CDT, sybrandy wrote: Just asking out of curiosity. With all the great language features, I'm sure that many of you have thought about this. For me, I figured a good start would be your basic Unix/Linux/BSD utilities, like cat and grep. I figure it may make the code easier to read and maintain as well as potentially improve the quality of the software. Of course, most of these are so old they're probably quite bug free, but some probably could use a rewrite. Some may even benefit for threading. Anyone else? Casey I wouldn't spend much time on rewriting classic utilities in D. There's plenty to be done anew. One category of tools to be written in D are utilities aimed at D itself (parsers, analyzers, Thrift bindings, protocol buffers bindings, code for DB interface, etc.) Andrei
Re: What would you rewrite in D?
sybrandy sybra...@gmail.com wrote in message news:i8g8oi$1hv...@digitalmars.com... Just asking out of curiosity. With all the great language features, I'm sure that many of you have thought about this. For me, I figured a good start would be your basic Unix/Linux/BSD utilities, like cat and grep. I figure it may make the code easier to read and maintain as well as potentially improve the quality of the software. Of course, most of these are so old they're probably quite bug free, but some probably could use a rewrite. Some may even benefit for threading. Not that I would want to do it myself, but I'd like to see LLMV and Scintilla moved to D. But really, just about anything in C/C++ that I might ever want to modify. If I never have to touch another line of C/C++ it'll be too soon.
Re: What would you rewrite in D?
On Tuesday 05 October 2010 20:16:41 Andrei Alexandrescu wrote: On 10/5/10 17:27 CDT, sybrandy wrote: Just asking out of curiosity. With all the great language features, I'm sure that many of you have thought about this. For me, I figured a good start would be your basic Unix/Linux/BSD utilities, like cat and grep. I figure it may make the code easier to read and maintain as well as potentially improve the quality of the software. Of course, most of these are so old they're probably quite bug free, but some probably could use a rewrite. Some may even benefit for threading. Anyone else? Casey I wouldn't spend much time on rewriting classic utilities in D. There's plenty to be done anew. One category of tools to be written in D are utilities aimed at D itself (parsers, analyzers, Thrift bindings, protocol buffers bindings, code for DB interface, etc.) Andrei Indeed. It could be reasonable to convert existing C or C++ code to D if you're going to be heavily changing it, but converting pre-existing applications which are currently in C or C++, and which you don't need to maintain, seems like a waste of time. It _could_ be an interesting exercise in how to do things in D and could very well show shortcomings in D, dmd's current implementation, and/or shortcomings in Phobos, but then so would new applications. At this point, if I can choose what language I'm going to write something in, I'm almost certainly going to choose D (though obviously stuff like GUI apps may not really be properly feasible in D yet, and some things are just gonig to work better in other languages), but I have enough to do (and not enough time to do it) without spending the time to rewrite entire, working applications in D. - Jonathan M Davis
Associative arrays give compile error
I can't seem to get any sense out of associative arrays. Even the simplest definition won't compile so I must be doing something daft. int[string] aa = [hello:42]; Error: non-constant expression [hello:42] What exactly is not constant about this. The example is straight out the book. Using D 2.0. bob
Re: Associative arrays give compile error
On Tue, 05 Oct 2010 14:23:47 +0400, Bob Cowdery b...@bobcowdery.plus.com wrote: I can't seem to get any sense out of associative arrays. Even the simplest definition won't compile so I must be doing something daft. int[string] aa = [hello:42]; Error: non-constant expression [hello:42] What exactly is not constant about this. The example is straight out the book. Using D 2.0. bob What exactly compiler version are you using (run dmd with no args)? Works perfectly fine here (dmd2.049).
Re: Associative arrays give compile error
On 05/10/2010 11:45, Denis Koroskin wrote: On Tue, 05 Oct 2010 14:23:47 +0400, Bob Cowdery b...@bobcowdery.plus.com wrote: I can't seem to get any sense out of associative arrays. Even the simplest definition won't compile so I must be doing something daft. int[string] aa = [hello:42]; Error: non-constant expression [hello:42] What exactly is not constant about this. The example is straight out the book. Using D 2.0. bob What exactly compiler version are you using (run dmd with no args)? Works perfectly fine here (dmd2.049). It says 2.049. How odd. I've got a fair amount of code and everything else compiles fine.
Re: Associative arrays give compile error
On Tue, 05 Oct 2010 14:57:22 +0400, Bob Cowdery b...@bobcowdery.plus.com
wrote:
On 05/10/2010 11:45, Denis Koroskin wrote:
On Tue, 05 Oct 2010 14:23:47 +0400, Bob Cowdery
b...@bobcowdery.plus.com wrote:
I can't seem to get any sense out of associative arrays. Even the
simplest definition won't compile so I must be doing something daft.
int[string] aa = [hello:42];
Error: non-constant expression [hello:42]
What exactly is not constant about this. The example is straight out
the
book. Using D 2.0.
bob
What exactly compiler version are you using (run dmd with no args)?
Works perfectly fine here (dmd2.049).
It says 2.049. How odd. I've got a fair amount of code and everything
else compiles fine.
Can you please post complete code snippet that fails to compile?
Here is the code I used to test:
module aa;
import std.stdio;
void main()
{
int[string] aa = [hello:42];
writeln(aa[hello]);
}
# dmd -run aa.d
Re: Associative arrays give compile error
On 05/10/2010 12:04, Denis Koroskin wrote:
On Tue, 05 Oct 2010 14:57:22 +0400, Bob Cowdery
b...@bobcowdery.plus.com wrote:
On 05/10/2010 11:45, Denis Koroskin wrote:
On Tue, 05 Oct 2010 14:23:47 +0400, Bob Cowdery
b...@bobcowdery.plus.com wrote:
I can't seem to get any sense out of associative arrays. Even the
simplest definition won't compile so I must be doing something daft.
int[string] aa = [hello:42];
Error: non-constant expression [hello:42]
What exactly is not constant about this. The example is straight
out the
book. Using D 2.0.
bob
What exactly compiler version are you using (run dmd with no args)?
Works perfectly fine here (dmd2.049).
It says 2.049. How odd. I've got a fair amount of code and everything
else compiles fine.
Can you please post complete code snippet that fails to compile?
Here is the code I used to test:
module aa;
import std.stdio;
void main()
{
int[string] aa = [hello:42];
writeln(aa[hello]);
}
# dmd -run aa.d
Ah! It's some other code below it that is not giving an error but
causing the error above. So the compiler is getting confused. What I was
actually trying to do was create an associative array with a string as a
key and a Tuple as the value. Now
auto aa = [
some string: (100.0, 6100.0)
]
compiles but is clearly wrong and gives rise to other errors. Does
anyone know the correct way to define this and then access the tuple.
Re: Associative arrays give compile error
On Tue, 05 Oct 2010 15:08:39 +0400, Bob Cowdery b...@bobcowdery.plus.com
wrote:
On 05/10/2010 12:04, Denis Koroskin wrote:
On Tue, 05 Oct 2010 14:57:22 +0400, Bob Cowdery
b...@bobcowdery.plus.com wrote:
On 05/10/2010 11:45, Denis Koroskin wrote:
On Tue, 05 Oct 2010 14:23:47 +0400, Bob Cowdery
b...@bobcowdery.plus.com wrote:
I can't seem to get any sense out of associative arrays. Even the
simplest definition won't compile so I must be doing something daft.
int[string] aa = [hello:42];
Error: non-constant expression [hello:42]
What exactly is not constant about this. The example is straight
out the
book. Using D 2.0.
bob
What exactly compiler version are you using (run dmd with no args)?
Works perfectly fine here (dmd2.049).
It says 2.049. How odd. I've got a fair amount of code and everything
else compiles fine.
Can you please post complete code snippet that fails to compile?
Here is the code I used to test:
module aa;
import std.stdio;
void main()
{
int[string] aa = [hello:42];
writeln(aa[hello]);
}
# dmd -run aa.d
Ah! It's some other code below it that is not giving an error but
causing the error above. So the compiler is getting confused. What I was
actually trying to do was create an associative array with a string as a
key and a Tuple as the value. Now
auto aa = [
some string: (100.0, 6100.0)
]
compiles but is clearly wrong and gives rise to other errors. Does
anyone know the correct way to define this and then access the tuple.
import std.stdio;
import std.typecons;
void main()
{
auto aa = [hello: tuple(100.0, 6100.0)];
auto result = aa[hello];
writeln(result.field[0], , result._1); // primary and alternative way
}
Re: Associative arrays give compile error
On 05/10/2010 12:13, Denis Koroskin wrote:
On Tue, 05 Oct 2010 15:08:39 +0400, Bob Cowdery
b...@bobcowdery.plus.com wrote:
On 05/10/2010 12:04, Denis Koroskin wrote:
On Tue, 05 Oct 2010 14:57:22 +0400, Bob Cowdery
b...@bobcowdery.plus.com wrote:
On 05/10/2010 11:45, Denis Koroskin wrote:
On Tue, 05 Oct 2010 14:23:47 +0400, Bob Cowdery
b...@bobcowdery.plus.com wrote:
I can't seem to get any sense out of associative arrays. Even the
simplest definition won't compile so I must be doing something daft.
int[string] aa = [hello:42];
Error: non-constant expression [hello:42]
What exactly is not constant about this. The example is straight
out the
book. Using D 2.0.
bob
What exactly compiler version are you using (run dmd with no args)?
Works perfectly fine here (dmd2.049).
It says 2.049. How odd. I've got a fair amount of code and everything
else compiles fine.
Can you please post complete code snippet that fails to compile?
Here is the code I used to test:
module aa;
import std.stdio;
void main()
{
int[string] aa = [hello:42];
writeln(aa[hello]);
}
# dmd -run aa.d
Ah! It's some other code below it that is not giving an error but
causing the error above. So the compiler is getting confused. What I was
actually trying to do was create an associative array with a string as a
key and a Tuple as the value. Now
auto aa = [
some string: (100.0, 6100.0)
]
compiles but is clearly wrong and gives rise to other errors. Does
anyone know the correct way to define this and then access the tuple.
import std.stdio;
import std.typecons;
void main()
{
auto aa = [hello: tuple(100.0, 6100.0)];
auto result = aa[hello];
writeln(result.field[0], , result._1); // primary and
alternative way
}
Thanks. I've established that works for me and also that the actual
array I'm using also works in the test program but it won't compile in
the real program. I've commented everything else out of the file and
just left...
import std.typecons;
auto A_RX_FILT = [
6K0: tuple(100.0, 6100.0),
2K4: tuple(300.0, 2700.0),
2K1: tuple(300.0, 2400.0),
1K0: tuple(300.0, 1300.0),
500: tuple(500.0, 1000.0),
250: tuple(600.0, 850.0),
100: tuple(700.0, 800.0)
];
I get an error on every line:
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(100,6100) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(300,2700) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(300,2400) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(300,1300) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(500,1000) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(600,850) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(700,800) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(100,6100) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(300,2700) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(300,2400) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(300,1300) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(500,1000) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(600,850) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(700,800) at
compile time|
||=== Build finished: 14 errors, 0 warnings ===|
This is a bit worrying now. I moved the array into the file that uses it
but I still get the same errors. Any ideas?
Re: Associative arrays give compile error
On 05/10/2010 12:40, Bob Cowdery wrote:
On 05/10/2010 12:13, Denis Koroskin wrote:
On Tue, 05 Oct 2010 15:08:39 +0400, Bob Cowdery
b...@bobcowdery.plus.com wrote:
On 05/10/2010 12:04, Denis Koroskin wrote:
On Tue, 05 Oct 2010 14:57:22 +0400, Bob Cowdery
b...@bobcowdery.plus.com wrote:
On 05/10/2010 11:45, Denis Koroskin wrote:
On Tue, 05 Oct 2010 14:23:47 +0400, Bob Cowdery
b...@bobcowdery.plus.com wrote:
I can't seem to get any sense out of associative arrays. Even the
simplest definition won't compile so I must be doing something daft.
int[string] aa = [hello:42];
Error: non-constant expression [hello:42]
What exactly is not constant about this. The example is straight
out the
book. Using D 2.0.
bob
What exactly compiler version are you using (run dmd with no args)?
Works perfectly fine here (dmd2.049).
It says 2.049. How odd. I've got a fair amount of code and everything
else compiles fine.
Can you please post complete code snippet that fails to compile?
Here is the code I used to test:
module aa;
import std.stdio;
void main()
{
int[string] aa = [hello:42];
writeln(aa[hello]);
}
# dmd -run aa.d
Ah! It's some other code below it that is not giving an error but
causing the error above. So the compiler is getting confused. What I was
actually trying to do was create an associative array with a string as a
key and a Tuple as the value. Now
auto aa = [
some string: (100.0, 6100.0)
]
compiles but is clearly wrong and gives rise to other errors. Does
anyone know the correct way to define this and then access the tuple.
import std.stdio;
import std.typecons;
void main()
{
auto aa = [hello: tuple(100.0, 6100.0)];
auto result = aa[hello];
writeln(result.field[0], , result._1); // primary and
alternative way
}
Thanks. I've established that works for me and also that the actual
array I'm using also works in the test program but it won't compile in
the real program. I've commented everything else out of the file and
just left...
import std.typecons;
auto A_RX_FILT = [
6K0: tuple(100.0, 6100.0),
2K4: tuple(300.0, 2700.0),
2K1: tuple(300.0, 2400.0),
1K0: tuple(300.0, 1300.0),
500: tuple(500.0, 1000.0),
250: tuple(600.0, 850.0),
100: tuple(700.0, 800.0)
];
I get an error on every line:
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(100,6100) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(300,2700) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(300,2400) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(300,1300) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(500,1000) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(600,850) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(700,800) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(100,6100) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(300,2700) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(300,2400) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(300,1300) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(500,1000) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(600,850) at
compile time|
Definitions\dspDefs.d|51|Error: cannot evaluate tuple(700,800) at
compile time|
||=== Build finished: 14 errors, 0 warnings ===|
This is a bit worrying now. I moved the array into the file that uses it
but I still get the same errors. Any ideas?
Oh dear, this is getting worse and worse. I've still got problems with a
simple definition. If I take out the one with the tuple and leave in
this one:
enum E_MODE
{
LSB,// 0
USB,// 1
DSB,// 2
CWL,// 3
CWU,// 4
FMN,// 5
AM,// 6
DIGU,// 7
SPEC,// 8
DIGL,// 9
SAM,// 10
DRM// 11
}
// Associative array for translation
auto A_MODE = [
LSB: E_MODE.LSB,
USB: E_MODE.USB,
DSB: E_MODE.DSB,
CWL: E_MODE.CWL,
CWU: E_MODE.CWU,
FMN: E_MODE.FMN,
AM: E_MODE.AM,
DIGU: E_MODE.DIGU,
SPEC: E_MODE.SPEC,
DIGL: E_MODE.DIGL,
SAM: E_MODE.SAM,
DRM: E_MODE.DRM
];
I get:
Definitions\dspDefs.d|25|Error: non-constant expression
[LSB:cast(E_MODE)0,USB:cast(E_MODE)1,DSB:cast(E_MODE)2,CWL:cast(E_MODE)3,CWU:cast(E_MODE)4,FMN:cast(E_MODE)5,AM:cast(E_MODE)6,DIGU:cast(E_MODE)7,SPEC:cast(E_MODE)8,DIGL:cast(E_MODE)9,SAM:cast(E_MODE)10,DRM:cast(E_MODE)11]|
||=== Build finished: 1 errors, 0 warnings ===|
Something is seriously broken here.
