Re: New homepage design of d-p-l.org is now live. eom
On 14/12/2011 10:12, Andrei Alexandrescu wrote: On 12/12/11 7:46 PM, Stewart Gordon wrote: On 06/12/2011 05:44, Andrei Alexandrescu wrote: http://d-p-l.org Andrei Why does it have an HTML 4.01 doctype but then go on to use XHTML syntax??? Stewart. I wouldn't know. What needs to be done? Are you saying someone else put that doctype there behind your back? Or that you found it on a lot of webpages and just copied it without any clue of what it means? Since what you've obviously learned is a mishmash of old-fashioned HTML, modern HTML and XHTML, the first step would be to learn the differences between them. This will get you started: http://www.w3schools.com/html/html_xhtml.asp My preference nowadays is to use XHTML Strict !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; though I may still use other doctypes while maintaining sites that have been around for a long time, like XHTML Transitional !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; The main difference between Strict and Transitional is that Transitional includes legacy presentational elements and attributes whereas Strict doesn't. The proper way to do things nowadays is to write the content and structure in (X)HTML and use CSS for the presentation. But whatever I try to validate it as, there are errors. A good plan would be to change it to XHTML 1.0 Transitional and fix the handful of validation errors that still show up. I can help you to do this. Once you've got your head around these, you could consider migrating to XHTML 1.0 Strict. Stewart.
Re: New homepage design of d-p-l.org is now live. eom
On Friday, 16 December 2011 at 13:33:06 UTC, Stewart Gordon wrote: But whatever I try to validate it as, there are errors. Does validation make any positive difference at all? I used to do it, but it prohibits things that are useful and work fine in practice* without offering much, if anything, in return. I've found that checking for well-formedness - that your tags are closed, attributes quoted, and entities encoded - is worth it, but the structure imposed by the doctype offers almost no help. * An example being custom attributes. The html5 validator will allow some of them, but the other ones won't.
Re: dmd 2.057 release
On Wednesday, 14 December 2011 at 07:05:25 UTC, Walter Bright
wrote:
Highlights are use of XMM floating point registers in 64 bit
targets, and now supporting OS X 64 as a target.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.057.zip
A lot of people put a ton of effort into making this D's best
release ever. Thanks!
I found a bug when slicing static arrays. It's not new to 2.057
but I totally forgot about it (my bad) and didn't simplify a test
case.
auto x() {
ubyte[4] a;
return a;
}
auto y() {
return x()[1..$];
}
void main() {
y();
}
Gives:
Internal error: ..\ztc\cgcs.c 354
Is this known or should I file a bug?
Re: dmd 2.057 release
On Friday, December 16, 2011 16:26:11 Christian Manning wrote:
On Wednesday, 14 December 2011 at 07:05:25 UTC, Walter Bright
wrote:
Highlights are use of XMM floating point registers in 64 bit
targets, and now supporting OS X 64 as a target.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.057.zip
A lot of people put a ton of effort into making this D's best
release ever. Thanks!
I found a bug when slicing static arrays. It's not new to 2.057
but I totally forgot about it (my bad) and didn't simplify a test
case.
auto x() {
ubyte[4] a;
return a;
}
auto y() {
return x()[1..$];
}
void main() {
y();
}
Gives:
Internal error: ..\ztc\cgcs.c 354
Is this known or should I file a bug?
It may bhttp://d.puremagic.com/issues/show_bug.cgi?id=4414
I'd point out though that that is really bad code, which should probably give
an error when you try and compile it (though it obviously shouldn't cause the
compiler to ICE regardless).
http://d.puremagic.com/issues/show_bug.cgi?id=7087
- Jonathan M Davis
Re: New homepage design of d-p-l.org is now live. eom
On 12/16/2011 5:33 AM, Stewart Gordon wrote: Or that you found it on a lot of webpages and just copied it without any clue of what it means? You can blame me for that, not Andrei.
Re: New homepage design of d-p-l.org is now live. eom
Adam D. Ruppe destructiona...@gmail.com wrote in message
news:virlzxfnfkylbbcce...@dfeed.kimsufi.thecybershadow.net...
On Friday, 16 December 2011 at 13:33:06 UTC, Stewart Gordon wrote:
But whatever I try to validate it as, there are errors.
Does validation make any positive difference at all?
I used to do it, but it prohibits things that are useful
and work fine in practice* without offering much, if anything,
in return.
I've found that checking for well-formedness - that your tags
are closed, attributes quoted, and entities encoded - is worth
it, but the structure imposed by the doctype offers almost no
help.
* An example being custom attributes. The html5 validator will
allow some of them, but the other ones won't.
I've come to figure the same thing. I like to keep things as compliant as I
can within reason, but I've been wondering more and more how strict it's
really worthwhile to be.
For example, I have an articles section on my site that (currently) uses
TangoCMS. I neither know nor care what doctype TangoCMS is sending out (and
I have even less interest in mucking with it's internals to change it), and
yet when I want to bold or italicize something in a post, I've started going
back to b and i. Why?
A. They're not as insanely verbose as span style=font-weight: bold;
font-style: italic (And they're much, MUCH easier to remember: Is it
text or font? Is it -bold, -weight, -italic, -style, -slant,
-skew or some nonstandard made-up term like text?/font?-decoration:
line-through? Who has *ever* called that anything but strikeout?). Or even
span class=bold (And even at that I'd have to go out of my way to go
grab and mess with the CSS files).
B. It works. On everything.
C. Let's face it, it's always going to work.
D. I don't give a rat's ass about the purity of HTML content vs style.
(X)HTML *is* presentation if you ask me: the content is in the model, and
that's stored in a DB, not XML files. And it all renders the same anyway.
And seriously, who's going to be applying a custom stylesheet to my pages?
(and if they do, they can just change the defined styles for b{} and i{}).
E. The W3C can kiss my ass ;)
Re: New homepage design of d-p-l.org is now live. eom
On Friday, 16 December 2011 at 18:28:07 UTC, Nick Sabalausky wrote: I've started going back to b and i. Why? I find this generally sane, but I can't agree with D. (lol) And seriously, who's going to be applying a custom stylesheet to my pages? My work D project recently brought on a new designer. Unlike the old designer who would mock it up and send me a picture, the new guy actually edits the site himself. But, he doesn't have access to all the html, and what he does have access to, I don't want him to edit anyway. He restyles the whole site through css; applying a custom stylesheet to my page. (He, and the boss, fought this for a while, but I think they are seeing the benefits of my approach since I pushed back on it.) It works quite well - the html I output doesn't have to change for each client, so adding new content doesn't require any repetition. We just do another stylesheet adjustment. The same html can be dropped in many places too. When they wanted the news added to the sidebar, I just said document.requireElementById(sidebar-new-holder).appendChild( getNews().toHtmlElement()); and the sidebar css adjusted it; I didn't have to write new queries or templates. Very convenient. The important thing though is to make sure the html describes the data well. Once you put in any kind of presentation in there, you break this approach. class=red no no, what if it's a blue theme? class=brand-name there we go. class=grid no no, what if we want it in a linear column? class=news-item there we go. and so on; the html describes the data in as much detail as is reasonable and the css makes the rest work.
Re: D1 dmd 1.072 release
On Saturday, 10 December 2011 at 23:05:11 UTC, Walter Bright wrote: Highlights are use of XMM floating point registers in 64 bit targets, and now supporting OS X 64 as a target. http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.072.zip The D2 version will follow in a few days, as those following the D n.g. know. Sorry, didn't get around to test this release until now on OSX. http://d.puremagic.com/issues/show_bug.cgi?id=7119 Other then that it looks good. Cheers, Jakob.
Re: New homepage design of d-p-l.org is now live. eom
Adam D. Ruppe destructiona...@gmail.com wrote in message news:anfqlbdugtkomnzbu...@dfeed.kimsufi.thecybershadow.net... The important thing though is to make sure the html describes the data well. Once you put in any kind of presentation in there, you break this approach. class=red no no, what if it's a blue theme? class=brand-name there we go. class=grid no no, what if we want it in a linear column? class=news-item there we go. and so on; the html describes the data in as much detail as is reasonable and the css makes the rest work. In many cases I do agree, but there are some problems: A. While CSS is acceptable for styling (though I would change some things), it's pure shit for layouts. CSS3 doesn't change my mind on that. And beyond that, I have zero faith in W3C's ability to ever contrive (X)HTML and CSS into a real model and view. No matter how much we *want* (X)HTML to be purely data-description, it just *isn't* and likely never will be. B. When you're talking about *inside* an article or posting, etc, all of that *is* the content. If the author intends something to be bold, italic, red, green, blue, whatever, then they should be able to specify it as such and not some vague psuedo-equivalent like emphasis, comment, string literal, etc, that may or may not exist in the site's CSS and may or may not always even be what the author really wanted anyway. C. You may be operating with a workflow where the web designer is CSS-only, but that's not always the case, and I think reasonable argments can be made for doing it differently (point A above, for example).
Re: dmd 2.057 release
On Friday, 16 December 2011 at 16:43:29 UTC, Jonathan M Davis
wrote:
On Friday, December 16, 2011 16:26:11 Christian Manning wrote:
On Wednesday, 14 December 2011 at 07:05:25 UTC, Walter Bright
wrote:
Highlights are use of XMM floating point registers in 64 bit
targets, and now supporting OS X 64 as a target.
http://www.digitalmars.com/d/2.0/changelog.html
http://ftp.digitalmars.com/dmd.2.057.zip
A lot of people put a ton of effort into making this D's best
release ever. Thanks!
I found a bug when slicing static arrays. It's not new to 2.057
but I totally forgot about it (my bad) and didn't simplify a
test
case.
auto x() {
ubyte[4] a;
return a;
}
auto y() {
return x()[1..$];
}
void main() {
y();
}
Gives:
Internal error: ..\ztc\cgcs.c 354
Is this known or should I file a bug?
It may bhttp://d.puremagic.com/issues/show_bug.cgi?id=4414
I'd point out though that that is really bad code, which should
probably give an error when you try and compile it (though it
obviously shouldn't cause the compiler to ICE regardless).
http://d.puremagic.com/issues/show_bug.cgi?id=7087
- Jonathan M Davis
It was just some mess around code, but I'll avoid it in the
future, so thanks for pointing it out :)
It does indeed look to be the same problem as
http://d.puremagic.com/issues/show_bug.cgi?id=4414
I should also point out that the appearance of the error is
dependant on the slice size.
How about this as a better test case?
ubyte[4] a;
auto x() {
return a;
}
void main() {
auto b = x()[1..$];
}
Re: New homepage design of d-p-l.org is now live. eom
On Friday, 16 December 2011 at 21:19:27 UTC, Nick Sabalausky wrote: A. While CSS is acceptable for styling (though I would change some things), it's pure shit for layouts. I wouldn't say that, completely. I do use a html template, but only for the outer layouts; it's a frame of sorts that I can put content into. The content itself gets by pretty ok with css as long as you group it. Sometimes the order of appearance matters (ugh ugh ugh, I hate css float especially) but it's not bad most the time. Not perfect, but it gets the job done. B. When you're talking about *inside* an article or posting, etc, all of that *is* the content. Yes, for the most part. I'd still say specify only what needs to be specified for the content, so then it fits in better with the user's environment. (In this case, it's perverted in that the user is the web designer, but it's the same idea.) So iis cool/i, but body color= is probably bad. C. You may be operating with a workflow where the web designer is CSS-only, but that's not always the case, and I think reasonable argments can be made for doing it differently (point A above, for example). Yeah, that's why I do the hybrid thing, but when they tried to make the arguments to get more access to the html, I reject them and so far I think I'm right. (The designer hasn't actually needed to edit any of the html files I gave him access too!)
Re: New homepage design of d-p-l.org is now live. eom
Adam D. Ruppe destructiona...@gmail.com wrote in message news:dxjkyeeqrhsgsknfh...@dfeed.kimsufi.thecybershadow.net... So iis cool/i, but body color= is probably bad. Yea, I totally agree. C. You may be operating with a workflow where the web designer is CSS-only, but that's not always the case, and I think reasonable argments can be made for doing it differently (point A above, for example). Yeah, that's why I do the hybrid thing, but when they tried to make the arguments to get more access to the html, I reject them and so far I think I'm right. (The designer hasn't actually needed to edit any of the html files I gave him access too!) It's an interesting problem that's not too dissimilar to what game developers have wrestled with the last so many years: Programmable rendering piplines (pixel shaders) allow phenomenal control over how a surface looks...and that's clearly within the realm of artist...but it's actually done with code: the programmer's realm. Artist's can't code. Coder's can't draw. So who does it? And how? A combination artist/coder? Where do you find them? And if you do, how can hope to you afford them? They've found ways to get by, and have gotten better at dealing with the issue, but it was never an easy problem and it's still not entirely solved. The problem here is very similar. There are designers who come up with the look, but their medium is code-based ((X)HTML and CSS), and it's tightly integrated with the full-on code of the programmer's realm. (Personally, I think the real solution here is abandon (X)HTML/CSS in favor of some unified thing that's actually *designed* to be a real presentation layer, and not a hacked up document format, and then create RAD-style editors based on it.)
Re: dmd 2.057 release
On Friday, December 16, 2011 22:37:50 Christian Manning wrote:
How about this as a better test case?
ubyte[4] a;
auto x() {
return a;
}
void main() {
auto b = x()[1..$];
}
That actually has exactly the same problem. You're slicing a temporary. You
can't slice a static array unless it's an actual variable, or you're going to
have problems. b points to a slice of a static array which doesn't exist
anymore. It _might_ work depending on how the registers used and how the stack
is laid out, but it's still a bad idea.
Regardless, the compiler shouldn't be ICEing though.
- Jonathan M Davis
Re: New homepage design of d-p-l.org is now live. eom
On 16/12/2011 18:26, Nick Sabalausky wrote: snip For example, I have an articles section on my site that (currently) uses TangoCMS. I neither know nor care what doctype TangoCMS is sending out (and I have even less interest in mucking with it's internals to change it), and yet when I want to bold or italicize something in a post, I've started going back tob andi. Why? A. They're not as insanely verbose asspan style=font-weight: bold; font-style: italic snip But you shouldn't be using span style=font-weight: bold; font-style: italic anyway. You should be looking at what the boldness or italicness _means_, and either using the appropriate semantic HTML element or (if one doesn't exist) defining a CSS class named after this semantic. This is also about making code self-documenting. Stewart.
Re: New homepage design of d-p-l.org is now live. eom
On 16/12/2011 15:09, Adam D. Ruppe wrote: On Friday, 16 December 2011 at 13:33:06 UTC, Stewart Gordon wrote: But whatever I try to validate it as, there are errors. Does validation make any positive difference at all? Yes: - it's a useful step in diagnosing problems with a webpage - it helps with cross-browser compatibility - it helps syntax-highlighting and code-folding editors - it enables code-manipulation tools to work correctly - it's good for your public image I used to do it, but it prohibits things that are useful and work fine in practice* without offering much, if anything, in return. What are these things that are useful to which you refer? snip * An example being custom attributes. The html5 validator will allow some of them, but the other ones won't. Are custom attributes distinguished from standard attributes in some way, in order to keep attributes invented by different browser manufacturers from clashing with each other and with attributes that become part of a later HTML standard? Stewart.
Re: New homepage design of d-p-l.org is now live. eom
On Friday, 16 December 2011 at 22:25:27 UTC, Nick Sabalausky wrote: *snip* I agree pretty much entirely, but meh, when web 2.0 gives you a turd, you make a shit sandwich and you LIKE it!
Re: dmd 2.057 release
On Friday, 16 December 2011 at 22:48:21 UTC, Jonathan M Davis wrote: That actually has exactly the same problem. You're slicing a temporary. You can't slice a static array unless it's an actual variable, or you're going to have problems. b points to a slice of a static array which doesn't exist anymore. It _might_ work depending on how the registers used and how the stack is laid out, but it's still a bad idea. Ah I get it now, thanks.
Re: dmd 2.057 release
On 12/15/2011 2:25 PM, Walter Bright wrote: On 12/15/2011 4:16 AM, Jacob Carlborg wrote: I wonder if we can list breaking changes in a separate sections in the changelog. Any bug fix is a breaking change - code can and does depend on bugs (often inadvertently). I've never seen code depend on an ICE :)
Re: New homepage design of d-p-l.org is now live. eom
Adam D. Ruppe destructiona...@gmail.com wrote in message news:xhaizhcmeybruijmp...@dfeed.kimsufi.thecybershadow.net... On Friday, 16 December 2011 at 22:25:27 UTC, Nick Sabalausky wrote: *snip* I agree pretty much entirely, but meh, when web 2.0 gives you a turd, you make a shit sandwich and you LIKE it! lol, how true :)
Re: New homepage design of d-p-l.org is now live. eom
Stewart Gordon smjg_1...@yahoo.com wrote in message news:jcgkhi$2ohd$1...@digitalmars.com... On 16/12/2011 18:26, Nick Sabalausky wrote: snip For example, I have an articles section on my site that (currently) uses TangoCMS. I neither know nor care what doctype TangoCMS is sending out (and I have even less interest in mucking with it's internals to change it), and yet when I want to bold or italicize something in a post, I've started going back tob andi. Why? A. They're not as insanely verbose asspan style=font-weight: bold; font-style: italic snip But you shouldn't be using span style=font-weight: bold; font-style: italic anyway. You should be looking at what the boldness or italicness _means_, and either using the appropriate semantic HTML element or (if one doesn't exist) defining a CSS class named after this semantic. This is also about making code self-documenting. If it's actually part of some span class=conceptui element/span, or span class=conceptwidget/span, or some span class=conceptstandard recurring concept/span, etc, then yes, I would agree in that case, span class=personStewart/span. But if it's ijust/i ordinary text that simply needs to be bbolded/b or iitalicized/i, then handling it in any roundabout way like that is just iridiculous/i (and self-documenting would be completely inapplicable). In such a situation, replacing hardcoded bold or italic with some vague concept of emphasis (old-school example: the em tag) or extra-emphasis, etc, is not only a useless abstraction merely for the sake of abstraction, it bican/i/b subtly change meaning/interpretation of the actual icontent/i because only the iauthor/i, not the stylist, is able to look at the final result and know whether the result bicorrectly/i/b depicts the amount/type of emphasis intended. Additionally, how does the stylist know if a given styling is going to cause too much visual noise? Or be too visually monotone? They ican't/i, because it's icompletely/i dependent on the text that the biauthor/i/b writes. It might be too much visual stuff for one article and just right for another. Only the text's author can know what's appropriate, not the stylesheet.
Re: D1 to be discontinued on December 31, 2012
On 12/15/2011 11:04 PM, Gour wrote: On Thu, 15 Dec 2011 16:42:26 -0800 Walter Brightnewshou...@digitalmars.com wrote: Right. And we make D2 work or we fail completely. Please, make it work! I have every intention to!
Re: Dot syntax to access static variables of functions
On 12/16/2011 12:48 AM, bearophile wrote:
In some cases I use a global variable only from a small small number of
functions, like foo() and main() here:
import std.stdio;
__gshared static int x = 10;
void foo() {
// uses x
writeln(foo);
}
void main() {
auto fptr =foo;
fptr();
auto y = x; // uses x
}
To write more tidy code in some of those situations I'd like a dot syntax to
access static variables of a function:
void foo() {
__gshared static int x = 10;
// uses x
writeln(foo);
}
void main() {
auto fptr =foo;
fptr();
auto y = foo.x; // uses foo.x
}
Its semantics is similar to just a struct with a static field and a static
opCall:
import std.stdio;
struct Foo {
__gshared static int x = 10;
static void opCall() {
// uses x
writeln(foo);
}
}
void main() {
auto y = Foo.x;
auto fptr =Foo.opCall;
fptr();
}
The advantage of using the dot syntax is that I don't need to modify the
function code and turn it into a struct, with uppercase name, etc.
Bye,
bearophile
Local variables are not part of the function interface. They are
implementation details.
Re: What can be done to reduce executable size?
On 12/16/11 1:12 AM, Jonathan M Davis wrote: Simply making it so that std.file is only imported in std.stdio with version(unittest) cut off _that_ much? Yah, but the matter is more complex. The issue is that std.file pulls std.datetime, which (a) has static this() code, and (b) pulls core.time, which in turn has static this() code. The issue with that is as follows. Any file that transitively imports a module with constructors will have its own module info generated. When that happens, all vtables in that module will be instantiated, so all methods will be linked in. That in turn causes all functions they call to also be linked in. That's why many programs using std are large. We can attack this in two ways: 1. Revise and reduce all static this() uses in phobos and druntime; 2. Improve the compiler to do minimal linking when static this() does come about. Andrei
The D Lie
Pattern of uselessness exhibited by many projects. I am afraid that Walt feels responsible for this fiasco. D is nothing. and not your fault. No one in these groups would fault you for trying and failing. D is not your worth. Trying is of value, but other things count more. Maybe they don't. Maybe this is all you have. I don't think you have all these people. I am afraid for you. Didn't I say that right? You're not afraid. Do you seek greatness? I would trade that in a second, if it was you to see god before me. Your live and time and existence is not of any god damn political, or god I hate you nun, um Note: it doesn't mean I love you, it just means I may have the hots for your wife.
I will not be responsible for your leader's death
I worry about all the crazies like him. you shut this thing down, and let him live and stop being the virus you are.
Re: 64-bit DMD for windows?
On 16.12.2011 00:35, Mehrdad wrote: On 12/15/2011 3:20 PM, Trass3r wrote: dealbreaker - i'd love to use D for my scientific programming, but my datasets often reach several GB... my computer has 16GB and i intend to make use of them. Scientific programming on Windoze? You can't be serious :P lol, that's not even the only issue. 32-bit programs can't show 64-bit dialogs. So Open this file... actually shows the SysWOW64 folder instead of the System32 folder, and there's _no way_ to bypass this unless you build a 64-bit app. Most people are not actually doing scientific programming. And they don't actually need to open an open file dialog to access files that are in the real System32. But if they do, there are several easy solutions.[1] Another reason for needing a 64-bit program on Windows would be if you are creating a shell extension. TortoiseSVN comes in both 32-bit and 64-bit flavors for this reason. People coming from Linux are accustomed to a running only 64-bit programs if they have a 64-bit OS. That's simply because Linux is usually distributed through downloading. To limit the download size, they leave out the 32-bit versions of libraries. Which means you can't actually run 32-bit programs without downloading and installing the packages containing those libraries first. At least that's my understanding. This issue doesn't exist on Windows. Probably not on OS X either, but I'm not too familiar with that system. So when people ask for 64-bit versions without stating why they need it, I always have to ask what features they want that the 32-bit version doesn't have. [1] http://www.ghisler.ch/wiki/index.php/Some_Files_and_Folders_Shown_by_Windows_Explorer_Are_Not_Shown_by_Total_Commander!#Solutions
Re: What can be done to reduce executable size?
Andrei Alexandrescu: Right now an executable starts at around 218KB, which includes druntime (gc, type info, the works). Importing std.stdio and using writeln() only adds a couple of KBs. Now using ulink the hello world exe becomes 129_564 bytes. Bye, bearophile
Re: 64-bit DMD for windows?
On 2011-12-16 10:10, torhu wrote: On 16.12.2011 00:35, Mehrdad wrote: On 12/15/2011 3:20 PM, Trass3r wrote: dealbreaker - i'd love to use D for my scientific programming, but my datasets often reach several GB... my computer has 16GB and i intend to make use of them. Scientific programming on Windoze? You can't be serious :P lol, that's not even the only issue. 32-bit programs can't show 64-bit dialogs. So Open this file... actually shows the SysWOW64 folder instead of the System32 folder, and there's _no way_ to bypass this unless you build a 64-bit app. Most people are not actually doing scientific programming. And they don't actually need to open an open file dialog to access files that are in the real System32. But if they do, there are several easy solutions.[1] Another reason for needing a 64-bit program on Windows would be if you are creating a shell extension. TortoiseSVN comes in both 32-bit and 64-bit flavors for this reason. People coming from Linux are accustomed to a running only 64-bit programs if they have a 64-bit OS. That's simply because Linux is usually distributed through downloading. To limit the download size, they leave out the 32-bit versions of libraries. Which means you can't actually run 32-bit programs without downloading and installing the packages containing those libraries first. At least that's my understanding. This issue doesn't exist on Windows. Probably not on OS X either, but I'm not too familiar with that system. Mac OS X has universal binaries, that is, libraries and executables containing code for multiple architectures. All system libraries bundled with the OS are compiled (at least) both for 32 and 64bit. This makes it no problem running either 32 or 64bit applications, the user don't have to know or care. -- /Jacob Carlborg
Re: 64-bit DMD for windows?
On 12/16/2011 1:17 AM, Jacob Carlborg wrote: On 2011-12-16 10:10, torhu wrote: People coming from Linux are accustomed to a running only 64-bit programs if they have a 64-bit OS. That's simply because Linux is usually distributed through downloading. To limit the download size, they leave out the 32-bit versions of libraries. Which means you can't actually run 32-bit programs without downloading and installing the packages containing those libraries first. At least that's my understanding. This issue doesn't exist on Windows. Probably not on OS X either, but I'm not too familiar with that system. Mac OS X has universal binaries, that is, libraries and executables containing code for multiple architectures. All system libraries bundled with the OS are compiled (at least) both for 32 and 64bit. This makes it no problem running either 32 or 64bit applications, the user don't have to know or care. The Mac universal binaries are simply the 32 bit and 64 bit versions concatenated into one file. It doesn't save on download size.
Re: Export and Protected Scoping in Dynamic Libraries
On 12/14/2011 11:41 AM, Adam Wilson wrote: Hello Everyone, I want to start this conversation by pointing out that I come from a C/C++/C# background and my ideas and frustrations in this post will be colored by that history. When I first approached D, the idea of an 'export' confused me. I've since figured out, at least in libraries, that in C# terms D's 'export' means 'public'. I'm not too familiar with C#'s public, but what D 'export' means is a function is an entry point for a DLL. In the Windows world, that means it gets an extra level of indirection when calling it, and it corresponds to: __declspec(export) in Windows compilers. However, this raise a problem, specifically, how do I export a protected member from a dynamic library? Do you mean how does one directly call a protected function inside a DLL from outside that DLL, without going through the virtual table?
Re: Second Round CURL Wrapper Review
Please make sure that you remove trailing whitespace from the file. A lot of
the lines have trailing whitespace. Also, make sure that you don't have any
tabs in the file. There are a few places where you used tabs.
Line# 916 claims that the code there won't work and that it needs to be fixed,
so please fix it before it goes into Phobos (assuming that it's voted in).
On line# 1051, just do
auto arr = new Char[](bufferSize);
There's no reason to create it and then assign to its length property.
The braces in the block follow line# 1131 need to be fixed. The indentation is
wrong on some of them, and not all of them are on their own line.
You should see if the cast(void[])'s can be removed from byLineAsync. They
might still be necessary, but null was given a type with the last release, so
it might work without the cast now. The same goes with byChunkAsync.
Same with line# 1215 as 1051. There's no point in wasting a line of code by
declaring an array and the assigning to its length variable. The code is
probably slightly less efficient that way too. Just allocate a new array of the
correct length.
On line#1297, the braces need to be fixed. Same with line# 1308 and line# 1334.
Just check over your braces in general to make sure that they're consistent
and are on their own line unless you're dealing with something like a one line
lambda.
And as I mentioned before, all of these enforces which take a new
CurlException, should be changed to use enforceEx after you've fixed
CurlException's constructor.
The documentation on Protocol's isValid is wrong. It claims that isValid is
true if the instance is stoppend and invalid. Wouldn't that mean that the
object _wasn't_ valid?
There are quite a few places where you're concatenating several strings and
format would make the code much cleaner (e.g. Protocol's netInterface
function). Unless you're avoiding format in an attempt to allow functions to
be pure (since unfortunately, format can't currently be pure), you really
should be using format.
I'd argue that it's better to use empty than check whether a string is equal
to . e.g. domain.empty instead of domain != on line# 1538.
There bodies of Http's constructor, static opCall, and dup functions are all
very similar - especially the constructor and static opCall. You should look
at refactoring those so that they don't have to duplicate so much code. Maybe
it can't be reasonably done easily, but it would certainly be better if that
code duplication could be reduced.
Change setTimeCondition to take a SysTime. DateTime is not intended for
timestamps. It's intended for calendar-based time, not the system time. Also,
SysTime makes it easier to convert to time_t. In general, the fact that you're
looking to deal with a time_t is a sign that you should be using SysTime. This
is especially true, since DateTime is going to give the wrong time_t in
general, since it has no time zone. As it stands, the timestamp is assumed to
be in UTC. That's just begging for bugs. Users won't expect that. Definitely
make it a SysTime. And once that's done, line# 2016 would disappear, and line#
2017 would become
p.curl.set(CurlOption.timevalue, timestamp.toUnixTime());
On line# 2247, why do you use format with no format string? There should be no
~ or to!string in a call to format. It's just creating unnecessary memory
allocations. It should be something more like
format(%s%s(%s., code, reason, majorVersion, minorVersion);
Though I find that '(' to be rather odd, since it has no matching closing
paren, so one may need to be added. Regardless, that line shouldn't be
concatenating strings or use conv.to. format takes care of all of that and
should do it with fewer memory allocations.
Pointers really should have their * next to the type not floating in space like
on line #2274. As it is, the code looks like a multiplication. Unlike in
C/C++, the * is clearly associated with the type. e.g.
int* a, b;
creates an int* and an int in C, but it creates int* and int* in D. Separating
the * from the type has a tendancy to make the code harder to understand.
Ftp's consturctor and static opCall have a code duplication problem similar to
that of Http.
Make encoding take a string. Any time that you are _always_ going to idup a
parameter which is a character array, make it a string, _not_ const. That way,
if it's a string, no idup is necessary, and if it's char[], then it can be
iduped when it's passed in, and iduping only occurs when it's actually
necessary.
In Smtp's constructor, yo ushould probably create a variable for the toLowered
url. e.g.
auto lowered = url.toLower();
That way, you avoid having to lower it twice if the else branch of the if-else
is taken.
Is p.curl.perform a property? If so, line# 2455 does nothing. If not, then it
needs parens. The curl module should be able to be built with -property. I
believe that Phobos as a whole is currently being built with tha flag. If not,
Re: 64-bit DMD for windows?
On 2011-12-16 10:24, Walter Bright wrote: On 12/16/2011 1:17 AM, Jacob Carlborg wrote: On 2011-12-16 10:10, torhu wrote: People coming from Linux are accustomed to a running only 64-bit programs if they have a 64-bit OS. That's simply because Linux is usually distributed through downloading. To limit the download size, they leave out the 32-bit versions of libraries. Which means you can't actually run 32-bit programs without downloading and installing the packages containing those libraries first. At least that's my understanding. This issue doesn't exist on Windows. Probably not on OS X either, but I'm not too familiar with that system. Mac OS X has universal binaries, that is, libraries and executables containing code for multiple architectures. All system libraries bundled with the OS are compiled (at least) both for 32 and 64bit. This makes it no problem running either 32 or 64bit applications, the user don't have to know or care. The Mac universal binaries are simply the 32 bit and 64 bit versions concatenated into one file. It doesn't save on download size. Exactly, I didn't say anything else. -- /Jacob Carlborg
Re: What can be done to reduce executable size?
On Friday, December 16, 2011 02:38:09 Andrei Alexandrescu wrote: On 12/16/11 1:12 AM, Jonathan M Davis wrote: Simply making it so that std.file is only imported in std.stdio with version(unittest) cut off _that_ much? Yah, but the matter is more complex. The issue is that std.file pulls std.datetime, which (a) has static this() code, and (b) pulls core.time, which in turn has static this() code. The issue with that is as follows. Any file that transitively imports a module with constructors will have its own module info generated. When that happens, all vtables in that module will be instantiated, so all methods will be linked in. That in turn causes all functions they call to also be linked in. That's why many programs using std are large. We can attack this in two ways: 1. Revise and reduce all static this() uses in phobos and druntime; 2. Improve the compiler to do minimal linking when static this() does come about. Well, both std.datetime and core.time need static this() and can't not have it. There may be other places in Phobos where module and class constructors can be avoided or removed, but aside from unit tests, when they're used, they're generally required. If some _can_ be removed though, that would be great, since their presence also risks circular dependencies, which is a far worse issue than the executable's size IMHO. But we can't get rid of them all. Any work that can be done in the compiler to reduce the executable's size due to static this would be great though. - Jonathan M Davis
Re: Export and Protected Scoping in Dynamic Libraries
On 2011-12-16 10:34, Walter Bright wrote:
On 12/14/2011 11:41 AM, Adam Wilson wrote:
Hello Everyone,
I want to start this conversation by pointing out that I come from a
C/C++/C#
background and my ideas and frustrations in this post will be colored
by that
history.
When I first approached D, the idea of an 'export' confused me. I've
since
figured out, at least in libraries, that in C# terms D's 'export' means
'public'.
I'm not too familiar with C#'s public, but what D 'export' means is a
function is an entry point for a DLL. In the Windows world, that means
it gets an extra level of indirection when calling it, and it
corresponds to:
__declspec(export)
in Windows compilers.
However, this raise a problem, specifically, how do I export a
protected member from a dynamic library?
Do you mean how does one directly call a protected function inside a DLL
from outside that DLL, without going through the virtual table?
What I think he wants is a member that is overrideable in a subclass
outside of the DLL but otherwise only reachable within the module its
defined in.
// foo.dll/foo.d
class Foo
{
export protected void foo () {}
}
// foo.dll/bar.d
auto foo = new Foo;
foo.foo; // error can't access protected member
// bar.dll/bar.d
class Bar : Foo
{
export protected override void foo () {} // it's fine to override
the method since it's protected, it's reachable in this dll since it's
exported
}
--
/Jacob Carlborg
Re: 64-bit DMD for windows?
On Friday, December 16, 2011 10:10:57 torhu wrote: On 16.12.2011 00:35, Mehrdad wrote: On 12/15/2011 3:20 PM, Trass3r wrote: dealbreaker - i'd love to use D for my scientific programming, but my datasets often reach several GB... my computer has 16GB and i intend to make use of them. Scientific programming on Windoze? You can't be serious :P lol, that's not even the only issue. 32-bit programs can't show 64-bit dialogs. So Open this file... actually shows the SysWOW64 folder instead of the System32 folder, and there's _no way_ to bypass this unless you build a 64-bit app. Most people are not actually doing scientific programming. And they don't actually need to open an open file dialog to access files that are in the real System32. But if they do, there are several easy solutions.[1] Another reason for needing a 64-bit program on Windows would be if you are creating a shell extension. TortoiseSVN comes in both 32-bit and 64-bit flavors for this reason. People coming from Linux are accustomed to a running only 64-bit programs if they have a 64-bit OS. That's simply because Linux is usually distributed through downloading. To limit the download size, they leave out the 32-bit versions of libraries. Which means you can't actually run 32-bit programs without downloading and installing the packages containing those libraries first. At least that's my understanding. On Linux, there's frequently no point in having 32-bit libraries installed. Everything is built for the native architecture, so why bother having the 32- bit libraries if they're not needed? There are the occasional exception - such as if you want to run wine in 32-bit mode, but even that can be in 64-bit now (though the risk of it not being appropriately compatible with Windows programs is greater in 64-bit, since it's newer). I would fully expect Windows to run 32-bit programs, but I would also think that 64-bit programs would become the norm such that there would eventually be no reason to have 32-bit programs aside from legacy stuff which isn't rebuilt. And considering that there are no x86 chips sold these days which aren't x86_64, I find it rather baffling that Microsoft even sells a 32-bit version of Windows. As long as the 64-bit versions runs the 32-bit programs properly, I don't see any point in having a 32-bit version of the OS - especially computers increasingly have too much memory to be able to use it all with a 32-bit OS. - Jonathan M Davis
Re: 64-bit DMD for windows?
On Friday, 16 December 2011 at 09:56:47 UTC, Jonathan M Davis wrote: considering that there are no x86 chips sold these days which aren't x86_64, I find it rather baffling that Microsoft even sells a 32-bit version of Windows. This is simply not true. I don't know about processors sold separately, but many netbooks and laptops still come with 32 bit processors.
Re: 64-bit DMD for windows?
On 16.12.2011 10:17, Jacob Carlborg wrote: On 2011-12-16 10:10, torhu wrote: On 16.12.2011 00:35, Mehrdad wrote: On 12/15/2011 3:20 PM, Trass3r wrote: dealbreaker - i'd love to use D for my scientific programming, but my datasets often reach several GB... my computer has 16GB and i intend to make use of them. Scientific programming on Windoze? You can't be serious :P lol, that's not even the only issue. 32-bit programs can't show 64-bit dialogs. So Open this file... actually shows the SysWOW64 folder instead of the System32 folder, and there's _no way_ to bypass this unless you build a 64-bit app. Most people are not actually doing scientific programming. And they don't actually need to open an open file dialog to access files that are in the real System32. But if they do, there are several easy solutions.[1] Another reason for needing a 64-bit program on Windows would be if you are creating a shell extension. TortoiseSVN comes in both 32-bit and 64-bit flavors for this reason. People coming from Linux are accustomed to a running only 64-bit programs if they have a 64-bit OS. That's simply because Linux is usually distributed through downloading. To limit the download size, they leave out the 32-bit versions of libraries. Which means you can't actually run 32-bit programs without downloading and installing the packages containing those libraries first. At least that's my understanding. This issue doesn't exist on Windows. Probably not on OS X either, but I'm not too familiar with that system. Mac OS X has universal binaries, that is, libraries and executables containing code for multiple architectures. All system libraries bundled with the OS are compiled (at least) both for 32 and 64bit. This makes it no problem running either 32 or 64bit applications, the user don't have to know or care. I know that much, but I wasn't sure why they were so keen on having 64 bit versions of apps. Maybe just to accelerate the switch to 64-bits by making it easier for developers to support both. And now they have started to leave things like Carbon behind in 32-bit land. At least you can't say that Apple isn't moving forward.
Re: 64-bit DMD for windows?
On Friday, December 16, 2011 11:09:25 Jakob Ovrum wrote: On Friday, 16 December 2011 at 09:56:47 UTC, Jonathan M Davis wrote: considering that there are no x86 chips sold these days which aren't x86_64, I find it rather baffling that Microsoft even sells a 32-bit version of Windows. This is simply not true. I don't know about processors sold separately, but many netbooks and laptops still come with 32 bit processors. Hmm. That's the first I've heard of 32-bit x86 processors in ages. All of the ones that I've seen or heard about for quite a while have been x86_64, even if they're running 32-bit Windows. The only 32-bit processors that I've heard about are ARM processors. I guess that I don't pay enough attention to that sort of stuff. - Jonathan M Davis
Re: 64-bit DMD for windows?
Some intel atoms still use 32-bit architecture. Il giorno ven, 16/12/2011 alle 02.48 -0800, Jonathan M Davis ha scritto: On Friday, December 16, 2011 11:09:25 Jakob Ovrum wrote: On Friday, 16 December 2011 at 09:56:47 UTC, Jonathan M Davis wrote: considering that there are no x86 chips sold these days which aren't x86_64, I find it rather baffling that Microsoft even sells a 32-bit version of Windows. This is simply not true. I don't know about processors sold separately, but many netbooks and laptops still come with 32 bit processors. Hmm. That's the first I've heard of 32-bit x86 processors in ages. All of the ones that I've seen or heard about for quite a while have been x86_64, even if they're running 32-bit Windows. The only 32-bit processors that I've heard about are ARM processors. I guess that I don't pay enough attention to that sort of stuff. - Jonathan M Davis
Re: 64-bit DMD for windows?
Jakob Ovrum Wrote: On Friday, 16 December 2011 at 09:56:47 UTC, Jonathan M Davis wrote: considering that there are no x86 chips sold these days which aren't x86_64, I find it rather baffling that Microsoft even sells a 32-bit version of Windows. This is simply not true. I don't know about processors sold separately, but many netbooks and laptops still come with 32 bit processors. New laptops and netbooks don't. Even recent (less than two years old) versions of intel atom are x86_64.
LLVM talks 1: Clang for Chromium
There are the videos of the 2011 LLVM Developer Meeting:
http://www.youtube.com/playlist?list=PL970A5BD02C11F80C
Slides too:
http://llvm.org/devmtg/2011-11/
As usual the LLVM talks are quite interesting. I have started to see the
videos/slides, it will require some time.
An interesting talk, Using clang in the Chromium project:
http://www.youtube.com/watch?v=IvL3f8xY7Uw
Slides:
http://llvm.org/devmtg/2011-11/Weber_Wennborg_UsingClangInChromium.pdf
---
It shows some problems found by Clang.
a.cc:2:9: warning: using the result of an assignment as a condition without
parentheses [-Wparentheses]
if (x |= y)
~~^~~~
a.cc:2:9: note: use '!=' to turn this compound assignment into an inequality
comparison
if (x |= y)
^~
!=
1 warning generated.
This code doesn't compile with DMD:
Error: assignment cannot be used as a condition, perhaps == was meant?
void main() {
int x, y;
if (x = y) {}
}
But this gives no errors:
void main() {
int x, y;
if (x |= y) {}
if (x += y) {}
}
Do you know why DMD forbids assignments as conditions, but it accepts compound
assignments there? It looks like a incongruence that's better to remove.
---
10.25 in the video:
a.cc:2:16: warning: operator '?:' has lower precedence than '+'; '+' will be
evaluated first
return x + b ? y : 0;
~ ^
a.cc:2:16: note: place parentheses around the '?:' expression to evaluate it
first
return x + b ? y : 0;
^
( )
1 warning generated.
They say:
It's a bug every time!
Given the frequence of bugs caused by the ?: operator, I think something like
this will be good to have in D too.
---
a.cc:8:23: warning: argument to sizeof in memset call is the same
expression as the destination;
did you mean to dereference it?
memset(s, 0, sizeof(s));
~^
1 warning generated.
---
At 14.45-16.39 there is an interesting part, about slide 22 of the PDF. It's
about crashes/bugs caused by undefined order of evaluation of function
arguments. This is a class of bugs that don't have to happen in D2 code.
Bye,
bearophile
Re: Deprecated typedef
On 16.12.2011 08:41, Jacob Carlborg wrote:
I know that this might be too late but wouldn't it be possible to defer
the error message about typedef to later in the compile phase. Making it
possible to put a typedef in a version statement, something like:
version (D_Version2) {}
else {
typedef int foo;
}
This would allow to both support D1 and D2 in a library without the need
for string mixins. Obviously the compiler still knows about typedef
since it can give a proper error message about it so I was hoping it
wouldn't have to be as the case with the new D2 keywords which do
require a string mixin if you're supporting both D1 and D2.
Why not just change your D1 code to use alias instead of typedef?
LLVM talks 2: TESLA
Second interesting thing I've found from the 2011 LLVM Developer Meeting:
http://www.youtube.com/playlist?list=PL970A5BD02C11F80C
Slides:
http://llvm.org/devmtg/2011-11/
In the Integrating LLVM into FreeBSD talk I have seen a reference to TESLA
(the talk itself is not interesting). It's not so easy to find good info about
TESLA, I have found this little tutorial:
http://wiki.freebsd.org/ShmSoc2011QGTT
And two examples:
https://socsvn.freebsd.org/socsvn/soc2011/shm/TESLA/examples/example2/
https://socsvn.freebsd.org/socsvn/soc2011/shm/TESLA/examples/ping/
From the page:
What is the TESLA?
TESLA is a framework for testing temporal properties of a software written in
the C language. Standard assertions i.e. assert(3) are able to test simple
expressions which refer only to an actual state of a program, testing temporal
properties in this case (e.g. conformance with the protocols, condition checks
before usage etc.) is complex, requires additional code and data structures,
thus it could be a source of unnecessary complexity and bugs. TESLA introduces
assertions which test temporal expressions, it means that it's able to refer to
the future and to the past, which is a great help when a goal is to verify some
property which refers to the time, i.e. check if access control checks were
done.
You write a simple automata like this using temporal logic:
automaton simple_protocol() {
void main(struct test *t) {
t-state = P1;
multiple {
either {
t-state = P2;
} or {
t-state = P3;
}
}
either {
t-state = P4;
} or {
t-state = P5;
}
t-state = P6;
exit;
}
}
And the TESLA tool adds asserts (and small functions that contain asserts) to
your C code that enforce those temporal constraints.
It seems nice, its purpose seems similar to the typestates of the Rust
language, but this works on C programs.
Bye,
bearophile
Re: 64-bit DMD for windows?
On Friday, 16 December 2011 at 12:14:50 UTC, a wrote: Jakob Ovrum Wrote: On Friday, 16 December 2011 at 09:56:47 UTC, Jonathan M Davis wrote: considering that there are no x86 chips sold these days which aren't x86_64, I find it rather baffling that Microsoft even sells a 32-bit version of Windows. This is simply not true. I don't know about processors sold separately, but many netbooks and laptops still come with 32 bit processors. New laptops and netbooks don't. Even recent (less than two years old) versions of intel atom are x86_64. The keyword here is sold, and besides, IA32 is still extremely common on cheap netbooks and laptops, even some recent models. The Atom line having 64 bit models doesn't mean a whole lot for the present reality. 32-bit x86 is definitely disappearing, but there is a long road ahead and 32 bit x86 is still ubiquitous. And I bet if you counted all the offices using Windows around the world, you'd find the vast majority of them using 32-bit hardware. There's no reason Microsoft shouldn't offer upgrade opportunities for that userbase as long as their new OS' work fine on old hardware.
Re: Deprecated typedef
Don: Why not just change your D1 code to use alias instead of typedef? Walter introduced typedef in D1 for a purpose: it introduces stronger static typing. So if in future you will want to modify/refactor your D1 code, typedefs will help you avoid introducing some bugs. If you replace them with alias, you lose something. Bye, bearophile
Re: 64-bit DMD for windows?
Il giorno ven, 16/12/2011 alle 07.14 -0500, a ha scritto: Jakob Ovrum Wrote: On Friday, 16 December 2011 at 09:56:47 UTC, Jonathan M Davis wrote: considering that there are no x86 chips sold these days which aren't x86_64, I find it rather baffling that Microsoft even sells a 32-bit version of Windows. This is simply not true. I don't know about processors sold separately, but many netbooks and laptops still come with 32 bit processors. New laptops and netbooks don't. Even recent (less than two years old) versions of intel atom are x86_64. It says instruction set 32 bit. Released on Q2 2011... http://ark.intel.com/products/55663/
Re: Deprecated typedef
On 2011-12-16 13:31, Don wrote:
On 16.12.2011 08:41, Jacob Carlborg wrote:
I know that this might be too late but wouldn't it be possible to defer
the error message about typedef to later in the compile phase. Making it
possible to put a typedef in a version statement, something like:
version (D_Version2) {}
else {
typedef int foo;
}
This would allow to both support D1 and D2 in a library without the need
for string mixins. Obviously the compiler still knows about typedef
since it can give a proper error message about it so I was hoping it
wouldn't have to be as the case with the new D2 keywords which do
require a string mixin if you're supporting both D1 and D2.
Why not just change your D1 code to use alias instead of typedef?
In this case it's a serialization library and I would like to support
all available types.
--
/Jacob Carlborg
Re: Deprecated typedef
Why not just change your D1 code to use alias instead of typedef? Walter introduced typedef in D1 for a purpose: it introduces stronger static typing. So if in future you will want to modify/refactor your D1 code, typedefs will help you avoid introducing some bugs. If you replace them with alias, you lose something. Which we will do in D2 too if we don't finish the library based typedef soon.
Re: What can be done to reduce executable size?
Am 16.12.2011, 10:15 Uhr, schrieb bearophile bearophileh...@lycos.com: Andrei Alexandrescu: Right now an executable starts at around 218KB, which includes druntime (gc, type info, the works). Importing std.stdio and using writeln() only adds a couple of KBs. Now using ulink the hello world exe becomes 129_564 bytes. What is its secret?
Re: What can be done to reduce executable size?
Am 16.12.2011, 14:52 Uhr, schrieb Trass3r u...@known.com: Am 16.12.2011, 10:15 Uhr, schrieb bearophile bearophileh...@lycos.com: Andrei Alexandrescu: Right now an executable starts at around 218KB, which includes druntime (gc, type info, the works). Importing std.stdio and using writeln() only adds a couple of KBs. Now using ulink the hello world exe becomes 129_564 bytes. What is its secret? Didn't it also compress the exe?
Re: What can be done to reduce executable size?
On Friday, 16 December 2011 at 09:50:30 UTC, Jonathan M Davis wrote: Well, both std.datetime and core.time need static this() and can't not have it. Why are they necessary? It looks like it sets the time zone... wouldn't it work to put that into DateTime's regular constructor?
2.057 regression and Result structs in std.algorithm
Some code using std.algorithm.filter broke today when I updated dmd.
Here's a test case:
-
import std.stdio, std.algorithm;
void main() {
writeln(filter!a != 'r'(Merry Christmas!));
}
Compiling with -inline gives:
/src/phobos/std/algorithm.d(1120): Error: function
std.algorithm.filter!(a != 'r').filter!(string).filter is a nested
function and cannot be accessed from formatValue
This reduced test case gives a clue as to what is going on:
-
auto fun()
{
struct Result {
this(int u) {}
auto bar() {
return Result(0);
}
}
return Result();
}
void main() {
auto t = fun();
auto a = t.bar();
}
-
Compiled with -inline:
t.d(7): Error: function t.fun is a nested function and cannot be
accessed from main
It seems what is happening is that bar is being inlined in main, but
dmd doesn't know where to get the new fun.Result's context pointer
from.
I'll file a bug report on this, but it made me wonder why
std.algorithm has so many non-static Result structs. Would it be a
good idea to make them static, where possible?
Torarin
Re: What can be done to reduce executable size?
What I have in mind is if the timezone was something along the lines of a singleton property, so it still works the same way, except it is lazy loaded on first use. (if this is indeed the right static constructor!)
Re: LLVM talks 1: Clang for Chromium
On Friday, 16 December 2011 at 12:23:25 UTC, bearophile wrote:
This code doesn't compile with DMD:
if (x = y) {}
But this gives no errors:
if (x |= y) {}
Do you know why DMD forbids assignments as conditions, but it
accepts compound assignments there? It looks like a
incongruence that's better to remove.
They aren't similar at all. Sometimes, if I'm coming from
a couple days writing Visual Basic, I'll hit the wrong
equal sign.
If a = 10 Then ' correct VB
blah
End If
if(a = 10) // wrong C/C++/D/etc
blah
That's a mistake that's pretty easy to make, especially if
you switch languages.
But I've never myself, nor seen anybody else, actually
write += or |= when they meant == or !=. The keys aren't
even close (on en-US anyway) so it's not a likely typo, and
the concepts are nothing alike so a brain or language mixup
isn't likely to cause it.
If you write if(a += 10), you almost certainly meant to say
if(a += 10).
That's not the case with (a = 10) vs (a == 10).
a.cc:2:16: warning: operator '?:' has lower precedence than
'+'; '+' will be evaluated first
return x + b ? y : 0;
They say:
It's a bug every time!
They're wrong. I've done something similar for plurals
where you only care about if it is equal to one or not,
and that was intentional.
That said, if I have to put any effort at all into thinking
about a line of code, I usually rewrite it.
(That's why in some of my code you'll see stuff like
return a != 0 ? true : false;
even though I could have just said
return a != 0;
Sometimes my brain gets mixed up with the double
negative so I just write it out anyway.)
In the case of the ternary, sometimes the precidence
is easy to forget, so I put a lot of parenthesis around
it.
return ((a) ?
(b) :
(c));
Just because then each piece is obviously grouped in a certain
way.
That's just a personal style though. I don't think the language
should enforce it since sometimes those parenthesis make it
worse, not better, to read.
At 14.45-16.39 there is an interesting part, about slide 22 of
the PDF. It's about crashes/bugs caused by undefined order of
evaluation of function arguments. This is a class of bugs that
don't have to happen in D2 code.
I believe the order of evaulation is defined in D.
Re: LLVM talks 1: Clang for Chromium
On 16-12-2011 13:23, bearophile wrote:
There are the videos of the 2011 LLVM Developer Meeting:
http://www.youtube.com/playlist?list=PL970A5BD02C11F80C
Slides too:
http://llvm.org/devmtg/2011-11/
As usual the LLVM talks are quite interesting. I have started to see the
videos/slides, it will require some time.
An interesting talk, Using clang in the Chromium project:
http://www.youtube.com/watch?v=IvL3f8xY7Uw
Slides:
http://llvm.org/devmtg/2011-11/Weber_Wennborg_UsingClangInChromium.pdf
---
It shows some problems found by Clang.
a.cc:2:9: warning: using the result of an assignment as a condition without
parentheses [-Wparentheses]
if (x |= y)
~~^~~~
a.cc:2:9: note: use '!=' to turn this compound assignment into an inequality
comparison
if (x |= y)
^~
!=
1 warning generated.
This code doesn't compile with DMD:
Error: assignment cannot be used as a condition, perhaps == was meant?
void main() {
int x, y;
if (x = y) {}
}
But this gives no errors:
void main() {
int x, y;
if (x |= y) {}
if (x += y) {}
}
Do you know why DMD forbids assignments as conditions, but it accepts compound
assignments there? It looks like a incongruence that's better to remove.
---
10.25 in the video:
a.cc:2:16: warning: operator '?:' has lower precedence than '+'; '+' will be
evaluated first
return x + b ? y : 0;
~ ^
a.cc:2:16: note: place parentheses around the '?:' expression to evaluate it
first
return x + b ? y : 0;
^
( )
1 warning generated.
They say:
It's a bug every time!
Given the frequence of bugs caused by the ?: operator, I think something like
this will be good to have in D too.
---
a.cc:8:23: warning: argument to ’sizeof’ in ’memset’ call is the same
expression as the destination;
did you mean to dereference it?
memset(s, 0, sizeof(s));
~^
1 warning generated.
---
At 14.45-16.39 there is an interesting part, about slide 22 of the PDF. It's
about crashes/bugs caused by undefined order of evaluation of function
arguments. This is a class of bugs that don't have to happen in D2 code.
Bye,
bearophile
I generally don't like that a compiler throws warnings at me for
perfectly valid code. Yes, it *can* be error prone, but most often, I
know what I'm doing and am actually utilizing a language feature.
Personally, I'd make no warnings the default and add an option that
looks for suspicious stuff like if (a = b).
- Alex
Re: LLVM talks 1: Clang for Chromium
Adam D. Ruppe: But I've never myself, nor seen anybody else, actually write += or |= when they meant == or !=. The keys aren't even close (on en-US anyway) so it's not a likely typo, and the concepts are nothing alike so a brain or language mixup isn't likely to cause it. If you write if(a += 10), you almost certainly meant to say if(a += 10). That's not the case with (a = 10) vs (a == 10). OK. In the case of the ternary, sometimes the precidence is easy to forget, so I put a lot of parenthesis around it. return ((a) ? (b) : (c)); Just because then each piece is obviously grouped in a certain way. That's just a personal style though. I don't think the language should enforce it since sometimes those parenthesis make it worse, not better, to read. I see. But unlike the if(a|=x) case, I have seen many cases where expressions like x+b?y:0 have caused troubles (I am able to show you some examples). So I will think about this some more. I believe the order of evaulation is defined in D. I don't know. Thank you for your answer, bearophile
dmd/druntime/phobos makefile horror
I've always built my libs like that: cd druntime git pull -v make MODEL=64 -f posix.mak -j2 make MODEL=32 -f posix.mak -j2 cd ../phobos git pull -v make MODEL=64 -f posix.mak -j2 mv generated/linux/release/64/libphobos2.a ../../linux/lib64 make MODEL=32 -f posix.mak -j2 mv generated/linux/release/32/libphobos2.a ../../linux/lib32 Normally I don't need 32bit but now I tried to build an app which fails miserably with phobos2 not found. After removing -L--no-warn-search-mismatch and playing with 'ar x' and 'file' I finally found out 32bit libphobos contains the 64bit version of druntime. The reason is druntime doesn't build separate libs like phobos does. This is just an example of the incoherence of the build system. (Another really bad one is dmd's makefile not allowing to specify debug/release while the windows version sort of does) Can't we get this straight once and for all?
Re: D1 to be discontinued on December 31, 2012
On Thursday, 15 December 2011 at 20:42:26 UTC, Jacob Carlborg wrote: On 2011-12-15 20:41, Walter Bright wrote: On 12/15/2011 9:49 AM, Robert Clipsham wrote: * Do it all in one go, and DO NOT GET DISTRACTED. The moment you start trying to clean up code as well as finish porting it you introduce lots of issues I've done many projects that translated code from one language to another, some were pretty large. The One Big Most Important Rule is: DO NOT REFACTOR/ENHANCE/IMPROVE/FIX/CLEANUP THE CODE WHILE TRANSLATING I know how tempting it is. It's incredibly tempting. It's a huge mistake. The method that works is to turn your brain off, and simply translate. Strive for a 1:1 correspondence between the original code and the translated code. Do not divert from this until after your translation is done, and it behaves identically to the original. The reason is that the translated version inevitably will not behave like the original. A lot of things will be broken. If you did a 1:1 translation, you can instrument both, find where the translation diverges, and fix it in a fairly quick and straightforward manner. If you changed the way it is organized or works, then you have no idea if it is a translation error or your changes broke it, and you have a much, much harder time fixing it. Having ported the Mac OS X version of SWT from Java to D (and a couple of other code bases) I completely agree with everything above. You just have to turn your mind off and work like a machine when porting. It's extremely tempting do some small fixes here and there but restrain yourself, you'll thank yourself in the end. Thanks for the tips! Cheers, Jakob.
Re: dmd/druntime/phobos makefile horror
On 16-12-2011 16:48, Trass3r wrote: I've always built my libs like that: cd druntime git pull -v make MODEL=64 -f posix.mak -j2 make MODEL=32 -f posix.mak -j2 cd ../phobos git pull -v make MODEL=64 -f posix.mak -j2 mv generated/linux/release/64/libphobos2.a ../../linux/lib64 make MODEL=32 -f posix.mak -j2 mv generated/linux/release/32/libphobos2.a ../../linux/lib32 Normally I don't need 32bit but now I tried to build an app which fails miserably with phobos2 not found. After removing -L--no-warn-search-mismatch and playing with 'ar x' and 'file' I finally found out 32bit libphobos contains the 64bit version of druntime. Ahahaha! So that explains those weird linker errors I never figured out! The reason is druntime doesn't build separate libs like phobos does. This is just an example of the incoherence of the build system. (Another really bad one is dmd's makefile not allowing to specify debug/release while the windows version sort of does) Can't we get this straight once and for all? I still wonder why druntime has to be in libphobos. It seems silly and error-prone to me. - Alex
Re: What can be done to reduce executable size?
On Friday, December 16, 2011 16:16:53 Adam D. Ruppe wrote: What I have in mind is if the timezone was something along the lines of a singleton property, so it still works the same way, except it is lazy loaded on first use. (if this is indeed the right static constructor!) That would break purity, so no that doesn't work. The singletons are pure. - Jonathan M Davis
Re: dmd/druntime/phobos makefile horror
Also why does druntime come with .di headers but phobos does not? OTOH I doubt it would save much on compilation time since virtually everything in phobos is a template..
Re: dmd/druntime/phobos makefile horror
On Friday, December 16, 2011 17:41:13 Andrej Mitrovic wrote: Also why does druntime come with .di headers but phobos does not? OTOH I doubt it would save much on compilation time since virtually everything in phobos is a template.. It would also kill CTFE for stuff that isn't a template. I'd sooner have druntime _not_ use .di files than have Phobos use them. However, I believe that one of the reasons that druntime does is so that compilation time is saved for the garbage collector. - Jonathan M Davis
Re: What can be done to reduce executable size?
On Friday, 16 December 2011 at 16:35:27 UTC, Jonathan M Davis
wrote:
That would break purity, so no that doesn't work. The
singletons are pure.
I'm tempted to say just cast it away, since you aren't actually
breaking purity in any meaningful way; the return value is always
the same and it should have no other side effects (except on the
internal variable).
Lying around pure was a bit of a pain... but this seems to have
done the trick:
alias pure string function () hax;
private string impureConstructor() {
static string cache;
if(cache is null)
cache = lol pure defeated;
return cache;
}
private pure hax getPureConstructor() { return cast(hax)
impureConstructor; }
public @system @property pure string test() {
return getPureConstructor()();
}
// test now works
Re: The D Lie
wut?
Re: .dmg installer for OSX?
Sounds like most of the apps I actually use wouldn't qualify for the app store. Sent from my iPhone On Dec 15, 2011, at 11:26 PM, Jacob Carlborg d...@me.com wrote: On 2011-12-15 21:53, Sean Kelly wrote: On Dec 15, 2011, at 4:47 AM, Michel Fortin wrote: On 2011-12-15 11:33:15 +, Ruslan Mullakhmetovtiaba...@gmail.com said: Probably, Mac App Store instalation would be the best? I don't know, do Apple policies allow to install a command line utilities via Macc App Store, but at least apple itself install OS X Lion and XCode via MAS. So, there is technical posibility to install arbitary toolset, not only pure GUI.app located in /Application. What do you say? Not a chance. The App Store is for applications. And applications are required to be self-contained, they are not allowed to use an installer. Apple is bypassing its own rules for Xcode. There is some grey area here though. TextMate, for example, is an application but has a preference that will put a link in /usr/bin to launch it from the command-line. So apps are allowed to configure the environment on request. For DMD you'd probably really have to bundle it with an IDE to qualify it as an app store item though. An alpha of TextMate 2 has recently been release and TextMate 2 will not be in the App Store because it would need to give up features. The BBEdit editor is available on the App Store but: ...BBEdit does not support automatic installation and updating of the bbedit, bbfind, and bbdiff command-line tools... -- /Jacob Carlborg
Re: What can be done to reduce executable size?
Am 16.12.2011, 04:40 Uhr, schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org: https://github.com/D-Programming-Language/phobos/commit/b7f42ec925fb1d64564d48ea419e201bfc65ed53 Yeah one could also use the new (function-)local imports. However, this also shows another problem common to C and D: You don't get any warnings if an import is unused. A tool that detects removable import declarations would be awesome. I wish dmd was designed modularly and as a library like Clang...
Re: What can be done to reduce executable size?
Trass3r: Now using ulink the hello world exe becomes 129_564 bytes. What is its secret? Linkers use grey magic, as you know. And it doesn't use compression. Bye, bearophile
Re: dmd/druntime/phobos makefile horror
On 12/16/11, Jonathan M Davis jmdavisp...@gmx.com wrote: It would also kill CTFE for stuff that isn't a template. I never thought of that.. interesting, so if you want to hide your sources your users won't be able to use CTFE. (I don't mind that, idc about any closed-source D /libraries/).
Re: What can be done to reduce executable size?
On 12/16/11 3:49 AM, Jonathan M Davis wrote: On Friday, December 16, 2011 02:38:09 Andrei Alexandrescu wrote: On 12/16/11 1:12 AM, Jonathan M Davis wrote: Simply making it so that std.file is only imported in std.stdio with version(unittest) cut off _that_ much? Yah, but the matter is more complex. The issue is that std.file pulls std.datetime, which (a) has static this() code, and (b) pulls core.time, which in turn has static this() code. The issue with that is as follows. Any file that transitively imports a module with constructors will have its own module info generated. When that happens, all vtables in that module will be instantiated, so all methods will be linked in. That in turn causes all functions they call to also be linked in. That's why many programs using std are large. We can attack this in two ways: 1. Revise and reduce all static this() uses in phobos and druntime; 2. Improve the compiler to do minimal linking when static this() does come about. Well, both std.datetime and core.time need static this() and can't not have it. I am pretty sure they don't need static this(). Only last night I removed static this() from core.time. Andrei
Re: LLVM talks 1: Clang for Chromium
On 12/16/2011 06:50 PM, Walter Bright wrote: D2 intends to define the order of evaluation of function arguments as strictly left-to-right. There are some problems implementing this, but that's where we want to go with it. What would be a case where this currently does not hold?
Re: LLVM talks 1: Clang for Chromium
On 12/16/2011 4:23 AM, bearophile wrote:
This code doesn't compile with DMD:
Error: assignment cannot be used as a condition, perhaps == was meant?
void main() {
int x, y;
if (x = y) {}
}
But this gives no errors:
void main() {
int x, y;
if (x |= y) {}
if (x += y) {}
}
Do you know why DMD forbids assignments as conditions, but it accepts compound
assignments there? It looks like a incongruence that's better to remove.
Because using = where == was meant is commonplace, but I've never seen the
others in the wild.
a.cc:2:16: warning: operator '?:' has lower precedence than '+'; '+' will be
evaluated first
return x + b ? y : 0;
~ ^
a.cc:2:16: note: place parentheses around the '?:' expression to evaluate it
first
return x + b ? y : 0;
^
( )
1 warning generated.
They say:
It's a bug every time!
Given the frequence of bugs caused by the ?: operator, I think something like
this will be good to have in D too.
I haven't seen the bug every time with this.
a.cc:8:23: warning: argument to ’sizeof’ in ’memset’ call is the same
expression as the destination;
did you mean to dereference it?
memset(s, 0, sizeof(s));
~^
1 warning generated.
Fixing bugs in C code is not in D's charter, which is why it also does not scan
printf strings, etc.
At 14.45-16.39 there is an interesting part, about slide 22 of the PDF. It's
about crashes/bugs caused by undefined order of evaluation of function
arguments. This is a class of bugs that don't have to happen in D2 code.
D2 intends to define the order of evaluation of function arguments as strictly
left-to-right. There are some problems implementing this, but that's where we
want to go with it.
Re: 64-bit DMD for windows?
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.1595.1324029407.24802.digitalmar...@puremagic.com... And considering that there are no x86 chips sold these days which aren't x86_64, I find it rather baffling that Microsoft even sells a 32-bit version of Windows. (Chips sold) != (Chips in use) Why would MS want to give a big F.U. to someone who wants to give MS money but isn't buying new hardware? Wouldn't make any sense.
Re: 64-bit DMD for windows?
Nick Sabalausky a@a.a wrote in message news:jcg0q8$145v$1...@digitalmars.com... Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.1595.1324029407.24802.digitalmar...@puremagic.com... And considering that there are no x86 chips sold these days which aren't x86_64, I find it rather baffling that Microsoft even sells a 32-bit version of Windows. (Chips sold) != (Chips in use) Why would MS want to give a big F.U. to someone who wants to give MS money but isn't buying new hardware? Wouldn't make any sense. Also, the 64-bit versions can't run 16-bit software, and yes, I know that's getting *really*, *really* old, but I wouldn't be surprised if there are people out there (companies, especially) that are still relying on something 16-bit. (In case anyone's wondering, and I'm sure some people are ;) : No, I'm not personally using Windows's 16-bit compatability for anything.)
Re: 64-bit DMD for windows?
On 12/16/2011 9:59 AM, Nick Sabalausky wrote: Also, the 64-bit versions can't run 16-bit software, and yes, I know that's getting *really*, *really* old, but I wouldn't be surprised if there are people out there (companies, especially) that are still relying on something 16-bit. (In case anyone's wondering, and I'm sure some people are ;) : No, I'm not personally using Windows's 16-bit compatability for anything.) I still have some customers using DMC for 16 bit work, and I still run DMC through all those tests.
Re: 64-bit DMD for windows?
On Friday, 16 December 2011 at 18:01:21 UTC, Nick Sabalausky wrote: No, I'm not personally using Windows's 16-bit compatability for anything.) One of the reasons I like Digital Mars is the compiler still targets 16 bit. (That was hugely important as a newb, and I don't use it much anymore, but it's very nice to have when I still want it.) When I tried college round two, assembly language class did 16 bit DOS programs too, running on Windows, of course. This was... I think 2007.
Re: LLVM talks 1: Clang for Chromium
Walter: Given the frequence of bugs caused by the ?: operator, I think something like this will be good to have in D too. I haven't seen the bug every time with this. Surely it's not a bug every time (but maybe was often enough a bug in the Chromium project, that is several millions lines of code). But in articles about PVS-Studio, and elsewhere, I have seen several cases where code like x+b?y:0 was a bug in good and real code. But I don't yet know how common those problems are. I will study some more on this. D2 intends to define the order of evaluation of function arguments as strictly left-to-right. There are some problems implementing this, but that's where we want to go with it. Good. There is also the problem of code like this, that will require one or more solutions for D2. Defining or refusing or this kind of code are the possibilities (or both of such solutions, in different situations): x = x++; Thank you for your answers, bearophile
Re: dmd/druntime/phobos makefile horror
On Friday, December 16, 2011 18:45:01 Andrej Mitrovic wrote: On 12/16/11, Jonathan M Davis jmdavisp...@gmx.com wrote: It would also kill CTFE for stuff that isn't a template. I never thought of that.. interesting, so if you want to hide your sources your users won't be able to use CTFE. (I don't mind that, idc about any closed-source D /libraries/). Templates need to be in the .di file regardless, but for anything not in the .di file, you can't inline it or use it in CTFE. As such, I'm generally very much against the use of .di files. We've actually had some issues with stuff not being CTFEable because its source wasn't in druntime's .di files. - Jonathan M Davis
Program size, linking matter, and static this()
Hello,
Late last night Walter and I figured a few interesting tidbits of
information. Allow me to give some context, discuss them, and sketch a
few approaches for improving things.
A while ago Walter wanted to enable function-level linking, i.e. only
get the needed functions from a given (and presumably large) module. So
he arranged things that a library contains many small object files
(that actually are generated from a single .d file and never exist on
disk, only inside the library file, which can be considered an archive
like tar). Then the linker would only pick the used object files from
the library and link those in. Unfortunately that didn't have nearly the
expected impact - essentially the size of most binaries stayed the same.
The mystery was unsolved, and Walter needed to move on to other things.
One particularly annoying issue is that even programs that don't
ostensibly use anything from an imported module may balloon inexplicably
in size. Consider:
import std.path;
void main(){}
This program, after stripping and all, has some 750KB in size. Removing
the import line reduces the size to 218KB. That includes the runtime
support, garbage collector, and such, and I'll consider it a baseline.
(A similar but separate discussion could be focused on reducing the
baseline size, but herein I'll consider it constant.)
What we'd simply want is to be able to import stuff without blatantly
paying for what we don't use. If a program imports std.path and uses no
function from it, it should be as large as a program without the import.
Furthermore, the increase should be incremental - using 2-3 functions
from std.path should only increase the executable size by a little, not
suddenly link in all code in that module.
But in experiments it seemed like program size would increase in sudden
amounts when certain modules were included. After much investigation we
figured that the following fateful causal sequence happened:
1. Some modules define static constructors with static this() or
static shared this(), and/or static destructors.
2. These constructors/destructors are linked in automatically whenever a
module is included.
3. Importing a module with a static constructor (or destructor) will
generate its ModuleInfo structure, which contains static information
about all module members. In particular, it keeps virtual table pointers
for all classes defined inside the module.
4. That means generating ModuleInfo refers all virtual functions defined
in that module, whether they're used or not.
5. The phenomenon is transitive, e.g. even if std.path has no static
constructors but imports std.datetime which does, a ModuleInfo is
generated for std.path too, in addition to the one for std.datetime. So
now classes inside std.path (if any) will be all linked in.
6. It follows that a module that defines classes which in turn use other
functions in other modules, and has static constructors (or includes
other modules that do) will baloon the size of the executable suddenly.
There are a few approaches that we can use to improve the state of affairs.
A. On the library side, use static constructors and destructors
sparingly inside druntime and std. We can use lazy initialization
instead of compulsively initializing library internals. I think this is
often a worthy thing to do in any case (dynamic libraries etc) because
it only does work if and when work needs to be done at the small cost of
a check upon each use.
B. On the compiler side, we could use a similar lazy initialization
trick to only refer class methods in the module if they're actually
needed. I'm being vague here because I'm not sure what and how that can
be done.
Here's a list of all files in std using static cdtors:
std/__fileinit.d
std/concurrency.d
std/cpuid.d
std/cstream.d
std/datebase.d
std/datetime.d
std/encoding.d
std/internal/math/biguintcore.d
std/internal/math/biguintx86.d
std/internal/processinit.d
std/internal/windows/advapi32.d
std/mmfile.d
std/parallelism.d
std/perf.d
std/socket.d
std/stdiobase.d
std/uri.d
The majority of them don't do a lot of work and are not much used inside
phobos, so they don't blow up the executable. The main one that could
receive some attention is std.datetime. It has a few static ctors and a
lot of classes. Essentially just importing std.datetime or any std
module that transitively imports std.datetime (and there are many of
them) ends up linking in most of Phobos and blows the size up from the
218KB baseline to 700KB.
Jonathan, could I impose on you to replace all static cdtors in
std.datetime with lazy initialization? I looked through it and it
strikes me as a reasonably simple job, but I think you'd know better
what to do than me.
A similar effort could be conducted to reduce or eliminate static cdtors
from druntime. I made the experiment of commenting them all, and that
reduced the size of the baseline from 218KB to 200KB. This is a
Re: 64-bit DMD for windows?
Walter Bright newshou...@digitalmars.com wrote in message news:jcg1k1$15kk$2...@digitalmars.com... On 12/16/2011 9:59 AM, Nick Sabalausky wrote: Also, the 64-bit versions can't run 16-bit software, and yes, I know that's getting *really*, *really* old, but I wouldn't be surprised if there are people out there (companies, especially) that are still relying on something 16-bit. (In case anyone's wondering, and I'm sure some people are ;) : No, I'm not personally using Windows's 16-bit compatability for anything.) I still have some customers using DMC for 16 bit work, and I still run DMC through all those tests. See, everyone! There's people (plural, apparently!) even more anachronistic than me! ;)
Re: 64-bit DMD for windows?
On Thu, 15 Dec 2011 05:47:54 -0500, torhu no@spam.invalid wrote: On 14.12.2011 12:54, dmd.20.browse...@xoxy.net wrote: Hi, Is there a 64-bit version of DMD for windows? The download page offers only an x86 version. Or am I reading too much into that? Cheers, buk There's not much you would need a 64-bit compiler for on Windows. What are you going to use it for? Linking to 64-bit programs. Also, I work on GPGPU medical imaging problems and I have run my 3GB Tesla card out of ram on occasion.
Re: What can be done to reduce executable size?
On Friday, December 16, 2011 11:45:42 Andrei Alexandrescu wrote: On 12/16/11 3:49 AM, Jonathan M Davis wrote: On Friday, December 16, 2011 02:38:09 Andrei Alexandrescu wrote: On 12/16/11 1:12 AM, Jonathan M Davis wrote: Simply making it so that std.file is only imported in std.stdio with version(unittest) cut off _that_ much? Yah, but the matter is more complex. The issue is that std.file pulls std.datetime, which (a) has static this() code, and (b) pulls core.time, which in turn has static this() code. The issue with that is as follows. Any file that transitively imports a module with constructors will have its own module info generated. When that happens, all vtables in that module will be instantiated, so all methods will be linked in. That in turn causes all functions they call to also be linked in. That's why many programs using std are large. We can attack this in two ways: 1. Revise and reduce all static this() uses in phobos and druntime; 2. Improve the compiler to do minimal linking when static this() does come about. Well, both std.datetime and core.time need static this() and can't not have it. I am pretty sure they don't need static this(). Only last night I removed static this() from core.time. I don't know how you could do that in core.time, since ticksPerSec and appOrigin are immutable and have to be set at runtime. How on earth can you do that without a static constructor? std.datetime has the same problem with the added fun of having to avoid breaking purity, because the functions for getting the singletons are pure. - Jonathan M Davis
Re: LLVM talks 1: Clang for Chromium
On 12/16/2011 9:52 AM, Timon Gehr wrote: On 12/16/2011 06:50 PM, Walter Bright wrote: D2 intends to define the order of evaluation of function arguments as strictly left-to-right. There are some problems implementing this, but that's where we want to go with it. What would be a case where this currently does not hold? The back end will evaluate them in different orders, as it is more efficient to evaluate varargs functions from right-to-left, and others from left-to-right. It's not an insurmountable problem, it just needs to be worked on.
Re: LLVM talks 1: Clang for Chromium
On 12/16/2011 10:16 AM, bearophile wrote: There is also the problem of code like this, that will require one or more solutions for D2. Defining or refusing or this kind of code are the possibilities (or both of such solutions, in different situations): x = x++; Define order of evaluation as rvalue, then lvalue.
Re: LLVM talks 1: Clang for Chromium
On 12/16/2011 10:43 AM, Walter Bright wrote: x = x++; Define order of evaluation as rvalue, then lvalue. Which, I might add, is a tractable problem. Trying to nail down every case of OOE dependencies is flat out impossible.
Re: graph algorithms library
On Thu, Dec 15, 2011 at 02:33, Martin Nowak d...@dawgfoto.de wrote: Actually 'git svn clone svn://foo' is much simpler than having to remember those svn command I forgot two years ago. Hey, good to know, thanks! Still, I'll clone your git repository, just for the fun of using github functionalities :) Most of the code was in a good shape and the library contains some real gems. Thank you again.
Re: DMD 1.072 and DMD 2.057 64bit on Mac OS X
Alex Rønne Petersen xtzgzo...@gmail.com wrote in message news:jcdep3$2gs3$1...@digitalmars.com... being on a 32-bit OS from 2001 https://www.semitwist.com/articles/article/view/why-use-a-10-year-old-os-!
Re: dmd/druntime/phobos makefile horror
On 16-12-2011 19:27, Jonathan M Davis wrote: On Friday, December 16, 2011 18:45:01 Andrej Mitrovic wrote: On 12/16/11, Jonathan M Davisjmdavisp...@gmx.com wrote: It would also kill CTFE for stuff that isn't a template. I never thought of that.. interesting, so if you want to hide your sources your users won't be able to use CTFE. (I don't mind that, idc about any closed-source D /libraries/). Templates need to be in the .di file regardless, but for anything not in the .di file, you can't inline it or use it in CTFE. As such, I'm generally very much against the use of .di files. We've actually had some issues with stuff not being CTFEable because its source wasn't in druntime's .di files. - Jonathan M Davis That does seem like a major drawback for anything open source. - Alex
Re: LLVM talks 1: Clang for Chromium
On 12/16/2011 07:45 PM, Walter Bright wrote: On 12/16/2011 10:43 AM, Walter Bright wrote: x = x++; Define order of evaluation as rvalue, then lvalue. Which, I might add, is a tractable problem. Trying to nail down every case of OOE dependencies is flat out impossible. How can that work together with NRVO?
Re: dmd/druntime/phobos makefile horror
On Dec 16, 2011, at 8:45 AM, Jonathan M Davis wrote: On Friday, December 16, 2011 17:41:13 Andrej Mitrovic wrote: Also why does druntime come with .di headers but phobos does not? OTOH I doubt it would save much on compilation time since virtually everything in phobos is a template.. It would also kill CTFE for stuff that isn't a template. Yup. I may have to change the build process to simply copy modules to the import directory so CTFE works. It just stinks that this would be necessary.
Re: What can be done to reduce executable size?
On Dec 15, 2011, at 7:40 PM, Andrei Alexandrescu wrote:
On 12/10/11 9:39 AM, Bane wrote:
Short term and long term suggestions ? Anything we can do ? I heard it
is some problem with linking dead code?
import std.stdio;
int main(){
writefln(Hello Bloat!);
return 0;
}
dmd -release -O hello.d
On Windows:
v1.071 = 339 Kb
v2.056 = 1017 Kb
It looks very ugly and might distract some people.
In fact there was a low-hanging fruit, and I'm sure there are some more. This
diff reduces the size of hello, world (compiled with -O -release -inline and
after strip) from 700KB to 220 KB:
https://github.com/D-Programming-Language/phobos/commit/b7f42ec925fb1d64564d48ea419e201bfc65ed53
Right now an executable starts at around 218KB, which includes druntime (gc,
type info, the works). Importing std.stdio and using writeln() only adds a
couple of KBs.
So importing std.file adds 800K to a executable?
Re: What can be done to reduce executable size?
On 12/16/11 12:40 PM, Jonathan M Davis wrote:
On Friday, December 16, 2011 11:45:42 Andrei Alexandrescu wrote:
I am pretty sure they don't need static this(). Only last night I
removed static this() from core.time.
I don't know how you could do that in core.time, since ticksPerSec and
appOrigin are immutable and have to be set at runtime. How on earth can you do
that without a static constructor?
std.datetime has the same problem with the added fun of having to avoid
breaking purity, because the functions for getting the singletons are pure.
This goes back to the issue of lazy initialization. Today you need a
cast to do that. Here's my code:
static @trusted @property long ticksPerSec() pure nothrow
{
return (cast(immutable(long) function() pure nothrow)
ticksPerSecImpl)();
}
static @property immutable(long) ticksPerSecImpl() nothrow
{
static long result;
if (result)
{
return result;
}
... initialization ...
return result;
}
The presence of the cast is unsightly but the code does something
unusual (modifies what looks from the outside like a constant) so it is
justifiable, particularly since we're talking about the language's core
library.
Andrei
Re: What can be done to reduce executable size?
On Dec 16, 2011, at 11:04 AM, Andrei Alexandrescu wrote:
On 12/16/11 12:40 PM, Jonathan M Davis wrote:
On Friday, December 16, 2011 11:45:42 Andrei Alexandrescu wrote:
I am pretty sure they don't need static this(). Only last night I
removed static this() from core.time.
I don't know how you could do that in core.time, since ticksPerSec and
appOrigin are immutable and have to be set at runtime. How on earth can you
do
that without a static constructor?
std.datetime has the same problem with the added fun of having to avoid
breaking purity, because the functions for getting the singletons are pure.
This goes back to the issue of lazy initialization. Today you need a cast to
do that. Here's my code:
static @trusted @property long ticksPerSec() pure nothrow
{
return (cast(immutable(long) function() pure nothrow)
ticksPerSecImpl)();
}
This is fine, but the whole point of static ctors in D is to eliminate all the
stupid workarounds required to use statics in C++. I'd much rather we find a
way to make the use of static ctors more efficient than give up on the feature.
Re: What can be done to reduce executable size?
On Friday, December 16, 2011 11:07:14 Sean Kelly wrote:
On Dec 16, 2011, at 11:04 AM, Andrei Alexandrescu wrote:
On 12/16/11 12:40 PM, Jonathan M Davis wrote:
On Friday, December 16, 2011 11:45:42 Andrei Alexandrescu wrote:
I am pretty sure they don't need static this(). Only last night I
removed static this() from core.time.
I don't know how you could do that in core.time, since ticksPerSec and
appOrigin are immutable and have to be set at runtime. How on earth
can you do that without a static constructor?
std.datetime has the same problem with the added fun of having to
avoid
breaking purity, because the functions for getting the singletons are
pure.
This goes back to the issue of lazy initialization. Today you need a cast
to do that. Here's my code:
static @trusted @property long ticksPerSec() pure nothrow
{
return (cast(immutable(long) function() pure nothrow)
ticksPerSecImpl)();
}
This is fine, but the whole point of static ctors in D is to eliminate all
the stupid workarounds required to use statics in C++. I'd much rather we
find a way to make the use of static ctors more efficient than give up on
the feature.
Agreed.
- Jonathan M Davis
Re: dmd/druntime/phobos makefile horror
On Friday, December 16, 2011 18:55:29 Alex Rønne Petersen wrote: On 16-12-2011 19:27, Jonathan M Davis wrote: On Friday, December 16, 2011 18:45:01 Andrej Mitrovic wrote: On 12/16/11, Jonathan M Davisjmdavisp...@gmx.com wrote: It would also kill CTFE for stuff that isn't a template. I never thought of that.. interesting, so if you want to hide your sources your users won't be able to use CTFE. (I don't mind that, idc about any closed-source D /libraries/). Templates need to be in the .di file regardless, but for anything not in the .di file, you can't inline it or use it in CTFE. As such, I'm generally very much against the use of .di files. We've actually had some issues with stuff not being CTFEable because its source wasn't in druntime's .di files. - Jonathan M Davis That does seem like a major drawback for anything open source. Why open source? I mean, if you want to use .di files, that's a problem in general, but what's worse about open source? Usually, I'd expect someone to say that it's worse for closed source, since it makes it harder to give the equivalent of a header file when dealing with 3rd parties you don't want to give all of your code to. - Jonathan M Davis
Re: Dot syntax to access static variables of functions
On Dec 15, 2011, at 3:48 PM, bearophile wrote:
In some cases I use a global variable only from a small small number of
functions, like foo() and main() here:
import std.stdio;
__gshared static int x = 10;
void foo() {
// uses x
writeln(foo);
}
void main() {
auto fptr = foo;
fptr();
auto y = x; // uses x
}
To write more tidy code in some of those situations I'd like a dot syntax to
access static variables of a function:
void foo() {
__gshared static int x = 10;
// uses x
writeln(foo);
}
void main() {
auto fptr = foo;
fptr();
auto y = foo.x; // uses foo.x
}
struct foo {
__gshared int x = 10;
static void opCall() {
// uses x
writeln(foo);
}
}
void main() {
auto fptr = foo; // sad that the syntax has to change here
fptr();
auto y = foo.x; // uses foo.x
}
Re: Program size, linking matter, and static this()
Interesting stuff. Andrei Alexandrescu seewebsiteforem...@erdani.org wrote in message news:jcg2lu$17p2$1...@digitalmars.com... We can use lazy initialization instead of compulsively initializing library internals. I think this is often a worthy thing to do in any case (dynamic libraries etc) because it only does work if and when work needs to be done at the small cost of a check upon each use. That also has the benefit of reducing the risk of dreaded circular ctor dependency problems.
Re: Program size, linking matter, and static this()
On Fri, 16 Dec 2011 13:29:18 -0500, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Hello,
Late last night Walter and I figured a few interesting tidbits of
information. Allow me to give some context, discuss them, and sketch a
few approaches for improving things.
A while ago Walter wanted to enable function-level linking, i.e. only
get the needed functions from a given (and presumably large) module. So
he arranged things that a library contains many small object files
(that actually are generated from a single .d file and never exist on
disk, only inside the library file, which can be considered an archive
like tar). Then the linker would only pick the used object files from
the library and link those in. Unfortunately that didn't have nearly the
expected impact - essentially the size of most binaries stayed the same.
The mystery was unsolved, and Walter needed to move on to other things.
One particularly annoying issue is that even programs that don't
ostensibly use anything from an imported module may balloon inexplicably
in size. Consider:
import std.path;
void main(){}
This program, after stripping and all, has some 750KB in size. Removing
the import line reduces the size to 218KB. That includes the runtime
support, garbage collector, and such, and I'll consider it a baseline.
(A similar but separate discussion could be focused on reducing the
baseline size, but herein I'll consider it constant.)
What we'd simply want is to be able to import stuff without blatantly
paying for what we don't use. If a program imports std.path and uses no
function from it, it should be as large as a program without the import.
Furthermore, the increase should be incremental - using 2-3 functions
from std.path should only increase the executable size by a little, not
suddenly link in all code in that module.
But in experiments it seemed like program size would increase in sudden
amounts when certain modules were included. After much investigation we
figured that the following fateful causal sequence happened:
1. Some modules define static constructors with static this() or
static shared this(), and/or static destructors.
2. These constructors/destructors are linked in automatically whenever a
module is included.
3. Importing a module with a static constructor (or destructor) will
generate its ModuleInfo structure, which contains static information
about all module members. In particular, it keeps virtual table pointers
for all classes defined inside the module.
4. That means generating ModuleInfo refers all virtual functions defined
in that module, whether they're used or not.
5. The phenomenon is transitive, e.g. even if std.path has no static
constructors but imports std.datetime which does, a ModuleInfo is
generated for std.path too, in addition to the one for std.datetime. So
now classes inside std.path (if any) will be all linked in.
6. It follows that a module that defines classes which in turn use other
functions in other modules, and has static constructors (or includes
other modules that do) will baloon the size of the executable suddenly.
There are a few approaches that we can use to improve the state of
affairs.
A. On the library side, use static constructors and destructors
sparingly inside druntime and std. We can use lazy initialization
instead of compulsively initializing library internals. I think this is
often a worthy thing to do in any case (dynamic libraries etc) because
it only does work if and when work needs to be done at the small cost of
a check upon each use.
B. On the compiler side, we could use a similar lazy initialization
trick to only refer class methods in the module if they're actually
needed. I'm being vague here because I'm not sure what and how that can
be done.
I disagree with this assessment. It's good to know the cause of the
problem, but let's look at the root issue -- reflection. The only reason
to include class information for classes not being referenced is to be
able to construct/use classes at runtime instead of at compile time. But
if you look at D's runtime reflection capabilities, they are quite poor.
You can only construct a class at runtime if it has a zero-arg constructor.
So essentially, we are paying the penalty of having runtime reflection in
terms of bloat, but get very very little benefit.
I think there are two things that need to be considered:
1. We eventually should have some reasonably complete runtime reflection
capability
2. Runtime reflection and shared libraries go hand-in-hand. With shared
library support, the bloat penalty isn't nearly as significant.
I don't think the right answer is to avoid using features of the language
because the compiler/runtime has some design deficiencies. At some point
these deficiencies will be fixed, and then we are left with a library that
has seemingly odd
Re: Program size, linking matter, and static this()
On Friday, December 16, 2011 12:29:18 Andrei Alexandrescu wrote: Jonathan, could I impose on you to replace all static cdtors in std.datetime with lazy initialization? I looked through it and it strikes me as a reasonably simple job, but I think you'd know better what to do than me. A similar effort could be conducted to reduce or eliminate static cdtors from druntime. I made the experiment of commenting them all, and that reduced the size of the baseline from 218KB to 200KB. This is a good amount, but not as dramatic as what we can get by working on std.datetime. Hmm. I had reply for this already, but it seems to have disappeared, so I'll try again. You could make core.time use property functions instead of the static immutable variables that it's using now for ticksPerSec and appOrigin, but in order to do that right would require introducing a mutex or synchronized block (which is really just a mutex under the hood anyway), and I'm loathe to do that in time-related code. ticksPerSec gets used all over the place in TickDuration, and that could have a negative impact on performance for something that needs to be really fast (since it's used in stuff like StopWatch and benchmarking). On top of that, in order to maintain the current semantics, the property functions would have to be pure, which they can't be without doing some nasty casting to convince the compiler that stuff which isn't pure is actually pure. For std.datetime, the problem would be reduced if a class could be created in CTFE and still be around at runtime, but we can't do that yet, and it wouldn't completely solve the problem, since the shared static constructor related to LocalTime has to call tzset. So, some sort of runtime initialization must be done. And the instances for the singleton are not only immutable, but the functions for getting them are pure. So, once again, some nasty casting would be required to get it to work without breaking purity. And once again, we'd have introduce a mutex. And for both core.time and std.datetime we're talking about a mutex would be needed only briefly to ensure that we don't end up with two threads trying to initialize the variable at the same time. After that, it would just be impeding performance for no value. They're classic situations for static constructors - initializing static immutable variables - and really, they _should_ be using static constructors. If we have to get rid of them, it's to get around other problems in the language or compiler instead of fixing those problems. So, on some level, that seems like a failure on the part of the language and the compiler. If we _have_ to find a workaround, then we have to find a workaround, but I find the need to be distasteful to say the least. I previously tried to get rid of the static constructors in std.datetime and couldn't precisely because they're needed unless you play major casting games to get around immutable and pure. If we play nice, it's impossible to get rid of the static constructors in std.datetime. It probably is possible if we do nasty casting, but (much as I hate to use the word) it seems like this is a hack to get around the fact that the compiler isn't dealing with static constructors as well as we'd like. I'd _really_ like to see this fixed at the compiler level. And honestly, I think that a far worse problem with static constructors is circular dependencies. _That_ is something that needs to be addressed with regards to static constructors. In general at this point, it's looking like static constructors are turning out to be a bit of a failure on some level, given the issues that we're having because of them, and I think that we should fix the language and/or compiler so that they _aren't_ a failure. - Jonathan M Davis
Re: Program size, linking matter, and static this()
On 12/16/11 1:23 PM, Steven Schveighoffer wrote: I disagree with this assessment. It's good to know the cause of the problem, but let's look at the root issue -- reflection. The only reason to include class information for classes not being referenced is to be able to construct/use classes at runtime instead of at compile time. But if you look at D's runtime reflection capabilities, they are quite poor. You can only construct a class at runtime if it has a zero-arg constructor. So essentially, we are paying the penalty of having runtime reflection in terms of bloat, but get very very little benefit. I'd almost agree, but the code showed doesn't use Object.factory(). So that shouldn't be linked in, and shouldn't pull vtables. I think there are two things that need to be considered: 1. We eventually should have some reasonably complete runtime reflection capability 2. Runtime reflection and shared libraries go hand-in-hand. With shared library support, the bloat penalty isn't nearly as significant. I don't think the right answer is to avoid using features of the language because the compiler/runtime has some design deficiencies. At some point these deficiencies will be fixed, and then we are left with a library that has seemingly odd design choices that we can't change. Runtime reflection is great, but I think it's a separate issue from what's discussed here. Andrei
Re: Program size, linking matter, and static this()
On 12/16/2011 08:41 PM, Jonathan M Davis wrote: On Friday, December 16, 2011 12:29:18 Andrei Alexandrescu wrote: Jonathan, could I impose on you to replace all static cdtors in std.datetime with lazy initialization? I looked through it and it strikes me as a reasonably simple job, but I think you'd know better what to do than me. A similar effort could be conducted to reduce or eliminate static cdtors from druntime. I made the experiment of commenting them all, and that reduced the size of the baseline from 218KB to 200KB. This is a good amount, but not as dramatic as what we can get by working on std.datetime. Hmm. I had reply for this already, but it seems to have disappeared, so I'll try again. You could make core.time use property functions instead of the static immutable variables that it's using now for ticksPerSec and appOrigin, but in order to do that right would require introducing a mutex or synchronized block (which is really just a mutex under the hood anyway), and I'm loathe to do that in time-related code. ticksPerSec gets used all over the place in TickDuration, and that could have a negative impact on performance for something that needs to be really fast (since it's used in stuff like StopWatch and benchmarking). On top of that, in order to maintain the current semantics, the property functions would have to be pure, which they can't be without doing some nasty casting to convince the compiler that stuff which isn't pure is actually pure. lazy variables would resolve this. For std.datetime, the problem would be reduced if a class could be created in CTFE and still be around at runtime, but we can't do that yet, and it wouldn't completely solve the problem, since the shared static constructor related to LocalTime has to call tzset. So, some sort of runtime initialization must be done. And the instances for the singleton are not only immutable, but the functions for getting them are pure. So, once again, some nasty casting would be required to get it to work without breaking purity. And once again, we'd have introduce a mutex. And for both core.time and std.datetime we're talking about a mutex would be needed only briefly to ensure that we don't end up with two threads trying to initialize the variable at the same time. After that, it would just be impeding performance for no value. They're classic situations for static constructors - initializing static immutable variables - and really, they _should_ be using static constructors. If we have to get rid of them, it's to get around other problems in the language or compiler instead of fixing those problems. So, on some level, that seems like a failure on the part of the language no. and the compiler. yes. Although I am not severely affected by 500kb of bloat. If we _have_ to find a workaround, then we have to find a workaround, but I find the need to be distasteful to say the least. I previously tried to get rid of the static constructors in std.datetime and couldn't precisely because they're needed unless you play major casting games to get around immutable and pure. If we play nice, it's impossible to get rid of the static constructors in std.datetime. It probably is possible if we do nasty casting, but (much as I hate to use the word) it seems like this is a hack to get around the fact that the compiler isn't dealing with static constructors as well as we'd like. I'd _really_ like to see this fixed at the compiler level. And honestly, I think that a far worse problem with static constructors is circular dependencies. _That_ is something that needs to be addressed with regards to static constructors. Circular dependencies are not to be blamed on the design of static constructors. In general at this point, it's looking like static constructors are turning out to be a bit of a failure on some level, given the issues that we're having because of them, and I think that we should fix the language and/or compiler so that they _aren't_ a failure. - Jonathan M Davis We are having (minor!!) problems because the task of initializing global data in a modular way is inherently hard. Just have a look how other languages handle initialization of global data and you'll notice that the D solution is actually very sensible.
