Re: First working Win64 program!
On 8/12/2012 10:50 PM, Nick Sabalausky wrote: Even still, it's a far cry to compare ditching 16-bit with (effectively) shunning 32-bit. Yes, 64-bit is bocoming more and more important, and yes, 32-bit is becoming less and less important, but I still think you're very much jumping the gun here. We'll see. It has already happened on OSX.
Re: First working Win64 program!
On Sunday, August 12, 2012 23:21:48 Walter Bright wrote: On 8/12/2012 10:50 PM, Nick Sabalausky wrote: Even still, it's a far cry to compare ditching 16-bit with (effectively) shunning 32-bit. Yes, 64-bit is bocoming more and more important, and yes, 32-bit is becoming less and less important, but I still think you're very much jumping the gun here. We'll see. It has already happened on OSX. OSX has a lot less backwards compatibility to worry about. While D is primarily going to be used for writing new programs (and therefore can choose to be 64-bit), it's a huge impediment to adding D into an existing code base for it not be able to link with Microsoft's 32-bit linker. How much that will ultimately matter, I don't know, but I think that it's pretty much a guarante that we're losing quite a bit in the short term by not having compatability with 32-bit Microsoft C/C+ on Windows. - Jonathan M Davis
Re: OSX and 64-bit [Re: First working Win64 program!]
On Sun, 2012-08-12 at 23:29 -0700, Jonathan M Davis wrote: […] OSX has a lot less backwards compatibility to worry about. Not entirely true. semi-rant Apple's strategy appears to be that computers are non-upgradable, non-repairable, disposable items that last until the next release: everyone is supposed buy the latest version as soon as it comes out and so be on the latest kit(*). Therefore Apple don't care about backward compatibility in the way some other manufacturers do, e.g. JDK for the last 17 years. Of course sometimes this backfires, cf. many white MacBooks which have 64-bit processors but 32-bit boot PROMs. OSX detects this and will not boot 64-bit. This leads to extraordinary problems trying to compile some codes where the compiler detects 64-bit processor and assumes a 64-bit kernel API. To build some applications I first have to build the whole compiler toolchain so as to deal with this mixed chaos. (*) And as we know there are a lot of people who actually do this, which is why there is a great market in second hand Apple kit, which is fine for me, since it is reasonable kit at a reasonable price. Unlike new kit. /semi-rant -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: First working Win64 program!
On Sun, 12 Aug 2012 23:21:48 -0700 Walter Bright newshou...@digitalmars.com wrote: On 8/12/2012 10:50 PM, Nick Sabalausky wrote: Even still, it's a far cry to compare ditching 16-bit with (effectively) shunning 32-bit. Yes, 64-bit is bocoming more and more important, and yes, 32-bit is becoming less and less important, but I still think you're very much jumping the gun here. We'll see. It has already happened on OSX. Whaddya kidding me? That's an Apple product. Apple only makes disposable throw-away devices. Release it. Kill it off after 2 weeks. Let the sheep shower us with more of their money. Repeat until there's no more hipster morons with money. There's Apple and then there's the rest of reality.
Re: First working Win64 program!
On Monday, 13 August 2012 at 01:18:14 UTC, Sean Cavanaugh wrote: On 8/12/2012 8:15 PM, Andrej Mitrovic wrote: On 8/13/12, Sean Cavanaughworksonmymach...@gmail.com wrote: we had to modify the code Sure enough I've found your name: http://www.microsoft.com/games/mgsgamecatalog/halopccredits.aspx I noticed you before here but never realized you worked on Halo. It's cool to see people of your caliber having interest in D! :) I have a theory that game development accelerates the rate at which you learn to hate C++ On the other hand, you get to learn lots of stuff to write Game Programming Gems chapters about. :)
Re: OSX and 64-bit [Re: First working Win64 program!]
On Monday, 13 August 2012 at 07:05:11 UTC, Russel Winder wrote: On Sun, 2012-08-12 at 23:29 -0700, Jonathan M Davis wrote: […] OSX has a lot less backwards compatibility to worry about. Not entirely true. semi-rant Apple's strategy appears to be that computers are non-upgradable, non-repairable, disposable items that last until the next release: everyone is supposed buy the latest version as soon as it comes out and so be on the latest kit(*). Therefore Apple don't care about backward compatibility in the way some other manufacturers do, e.g. JDK for the last 17 years. Of course sometimes this backfires, cf. many white MacBooks which have 64-bit processors but 32-bit boot PROMs. OSX detects this and will not boot 64-bit. This leads to extraordinary problems trying to compile some codes where the compiler detects 64-bit processor and assumes a 64-bit kernel API. To build some applications I first have to build the whole compiler toolchain so as to deal with this mixed chaos. (*) And as we know there are a lot of people who actually do this, which is why there is a great market in second hand Apple kit, which is fine for me, since it is reasonable kit at a reasonable price. Unlike new kit. /semi-rant It is this type of issues that keeps me away from Apple products.
Re: First working Win64 program!
On 8/12/2012 11:29 PM, Jonathan M Davis wrote: On Sunday, August 12, 2012 23:21:48 Walter Bright wrote: On 8/12/2012 10:50 PM, Nick Sabalausky wrote: Even still, it's a far cry to compare ditching 16-bit with (effectively) shunning 32-bit. Yes, 64-bit is bocoming more and more important, and yes, 32-bit is becoming less and less important, but I still think you're very much jumping the gun here. We'll see. It has already happened on OSX. OSX has a lot less backwards compatibility to worry about. I fully understand that is why they are a first mover in leaving 32 bits behind. While D is primarily going to be used for writing new programs (and therefore can choose to be 64-bit), it's a huge impediment to adding D into an existing code base for it not be able to link with Microsoft's 32-bit linker. How much that will ultimately matter, I don't know, but I think that it's pretty much a guarante that we're losing quite a bit in the short term by not having compatability with 32-bit Microsoft C/C+ on Windows. 64 bits is far more important. We don't have arrows for every target, we have to pick the juiciest ones.
Re: First working Win64 program!
On Monday, 13 August 2012 at 09:52:05 UTC, Walter Bright wrote: 64 bits is far more important. We don't have arrows for every target, we have to pick the juiciest ones. Does that mean that we get x64 support on Windows (without legacy OMF support)? Linking with MSVC-produced libraries will work, too?
Re: First working Win64 program!
On 2012-08-13 08:21, Walter Bright wrote: We'll see. It has already happened on OSX. The good think on Mac OS X is that basically all system libraries are universal binaries (both 32 and 64bit) meaning it really doesn't matter for the user if an application is 32 or 64bit. BTW, around 6.6% of my currently running processes are 32bit. Mac OS X 10.7 Lion. -- /Jacob Carlborg
Re: OSX and 64-bit [Re: First working Win64 program!]
On 2012-08-13 09:04, Russel Winder wrote: semi-rant Apple's strategy appears to be that computers are non-upgradable, non-repairable, disposable items that last until the next release: everyone is supposed buy the latest version as soon as it comes out and so be on the latest kit(*). But their products last a lot longer than that. I have had my MacBook since around 2006. I had to change battery and I've upgraded the RAM, except from that everything is working great. Therefore Apple don't care about backward compatibility in the way some other manufacturers do, e.g. JDK for the last 17 years. Of course sometimes this backfires, cf. many white MacBooks which have 64-bit processors but 32-bit boot PROMs. OSX detects this and will not boot 64-bit. This leads to extraordinary problems trying to compile some codes where the compiler detects 64-bit processor and assumes a 64-bit kernel API. To build some applications I first have to build the whole compiler toolchain so as to deal with this mixed chaos. I never had any problems with 32 vs 64bit on Mac OS X. All system libraries ship with universal binaries (32 and 64bit) and it's dead easy to compile for multiple architectures. -- /Jacob Carlborg
Re: First working Win64 program!
On Monday, 13 August 2012 at 04:44:43 UTC, Nick Sabalausky wrote: It's not the current plan. Frankly, I think 32 bits is rapidly becoming irrelevant on the desktop. Bullshit. While I agree with the sentiment (in fact, one of my newest computers is 32 bit; I got a mini laptop - not quite netbook, but not regular laptop either - that is 32 bit), it is worth noting that 32 bit D isn't going away. We're going to be in the same boat we're in now, which does work.
Re: First working Win64 program!
On Monday, August 13, 2012 02:51:30 Walter Bright wrote: 64 bits is far more important. We don't have arrows for every target, we have to pick the juiciest ones. I have no idea how much mork work it is to add 32-bit COFF on top of adding 64-bit COFF, and I'm totally fine with just targeting 64-bit COFF for now. I'm just pointing out that there's a definite cost to not having 32-bit COFF support on Windows, whereas your posts seem to imply that you don't think that it's important at all. - Jonathan M Davis
Re: First working Win64 program!
On 8/13/2012 3:55 AM, d_follower wrote: Does that mean that we get x64 support on Windows (without legacy OMF support)? Linking with MSVC-produced libraries will work, too? Yes.
Re: First working Win64 program!
On 8/13/2012 6:23 AM, Jacob Carlborg wrote: On 2012-08-13 08:21, Walter Bright wrote: We'll see. It has already happened on OSX. The good think on Mac OS X is that basically all system libraries are universal binaries (both 32 and 64bit) meaning it really doesn't matter for the user if an application is 32 or 64bit. BTW, around 6.6% of my currently running processes are 32bit. Mac OS X 10.7 Lion. True, but consider that dmd is a 64 bit app, and nobody either complains about it or notices, and dmd by default produces a 64 bit app, and as far as I can tell, nobody has noticed that either.
Re: OSX and 64-bit [Re: First working Win64 program!]
On Aug 13, 2012, at 12:04 AM, Russel Winder rus...@winder.org.uk wrote: On Sun, 2012-08-12 at 23:29 -0700, Jonathan M Davis wrote: […] OSX has a lot less backwards compatibility to worry about. Not entirely true. semi-rant Apple's strategy appears to be that computers are non-upgradable, non-repairable, disposable items that last until the next release: everyone is supposed buy the latest version as soon as it comes out and so be on the latest kit(*). Therefore Apple don't care about backward compatibility in the way some other manufacturers do, e.g. JDK for the last 17 years. Of course sometimes this backfires, cf. many white MacBooks which have 64-bit processors but 32-bit boot PROMs. OSX detects this and will not boot 64-bit. This leads to extraordinary problems trying to compile some codes where the compiler detects 64-bit processor and assumes a 64-bit kernel API. To build some applications I first have to build the whole compiler toolchain so as to deal with this mixed chaos. (*) And as we know there are a lot of people who actually do this, which is why there is a great market in second hand Apple kit, which is fine for me, since it is reasonable kit at a reasonable price. Unlike new kit. /semi-rant Strangely,libc on OSX is very backwards-compatible. To the point where buggy functions were preserved as-is and updated versions exported via weird labels linked by the compiler using some evil macro code. Needless to say, D unfortunalely links to the buggy versions because there's no way to express the new symbols in-language. I suppose I should try to sort something out using string mixins and inline assembler.
Re: First working Win64 program!
On Monday, 13 August 2012 at 18:29:13 UTC, Walter Bright wrote: On 8/13/2012 6:23 AM, Jacob Carlborg wrote: On 2012-08-13 08:21, Walter Bright wrote: We'll see. It has already happened on OSX. The good think on Mac OS X is that basically all system libraries are universal binaries (both 32 and 64bit) meaning it really doesn't matter for the user if an application is 32 or 64bit. BTW, around 6.6% of my currently running processes are 32bit. Mac OS X 10.7 Lion. True, but consider that dmd is a 64 bit app, and nobody either complains about it or notices, and dmd by default produces a 64 bit app, and as far as I can tell, nobody has noticed that either. I noticed! But it hasn't been a problem. One of the things I've actually been using D for is writing simple tools for work, to be executed while in livedisc environments (diagnostics and the like), so I have to keep both 32b and 64b versions of everything, and the only missing component was 64b for Windows. So yeah, I'm pretty stoked about this.
Re: OSX and 64-bit [Re: First working Win64 program!]
On 8/13/2012 12:41 PM, Sean Kelly wrote: Strangely,libc on OSX is very backwards-compatible. To the point where buggy functions were preserved as-is and updated versions exported via weird labels linked by the compiler using some evil macro code. Needless to say, D unfortunalely links to the buggy versions because there's no way to express the new symbols in-language. I suppose I should try to sort something out using string mixins and inline assembler. An easy way is to write a .c file for druntime that accepts the call to the buggy function and calls the un-buggy one. That way the magic macros will work. I've thought many times about adding a D feature that allows one to specify use this random character string instead of the identifier as the symbol name when writing the object file, but never got around to it.
Re: OSX and 64-bit [Re: First working Win64 program!]
On 13-08-2012 23:34, Walter Bright wrote: On 8/13/2012 12:41 PM, Sean Kelly wrote: Strangely,libc on OSX is very backwards-compatible. To the point where buggy functions were preserved as-is and updated versions exported via weird labels linked by the compiler using some evil macro code. Needless to say, D unfortunalely links to the buggy versions because there's no way to express the new symbols in-language. I suppose I should try to sort something out using string mixins and inline assembler. An easy way is to write a .c file for druntime that accepts the call to the buggy function and calls the un-buggy one. That way the magic macros will work. I've thought many times about adding a D feature that allows one to specify use this random character string instead of the identifier as the symbol name when writing the object file, but never got around to it. I've wanted a feature like that on several occasions (mostly when interfacing with non-C/C++ languages). How hard it would it be to implement? Theoretically, it sounds simple enough. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: OSX and 64-bit [Re: First working Win64 program!]
On 8/13/2012 2:37 PM, Alex Rønne Petersen wrote: I've wanted a feature like that on several occasions (mostly when interfacing with non-C/C++ languages). How hard it would it be to implement? Theoretically, it sounds simple enough. You could do it with a pragma or something. It's always going to look ugly, though.
Re: OSX and 64-bit [Re: First working Win64 program!]
On 8/13/12, Walter Bright newshou...@digitalmars.com wrote: I've thought many times about adding a D feature that allows one to specify use this random character string instead of the identifier as the symbol name when writing the object file, but never got around to it. Isn't that what .def files are for? Or maybe this is only used for DLLs?
Re: OSX and 64-bit [Re: First working Win64 program!]
No doubt that COFF 64 bits it are good and with high priority, though small, but support of COFF 32 bits will be a gift that will add popularity to dmd. Anyway I have words that add + to 64 bit and to 32 bit tools that supports linking with ms toolset.
Re: OSX and 64-bit [Re: First working Win64 program!]
On 13-08-2012 23:58, Andrej Mitrovic wrote: On 8/13/12, Walter Bright newshou...@digitalmars.com wrote: I've thought many times about adding a D feature that allows one to specify use this random character string instead of the identifier as the symbol name when writing the object file, but never got around to it. Isn't that what .def files are for? Or maybe this is only used for DLLs? That's a Windows-ism. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: OSX and 64-bit [Re: First working Win64 program!]
On 8/14/12, Alex Rønne Petersen a...@lycus.org wrote: That's a Windows-ism. I think it's technically a linker-ism. Surely LD supports a similar feature?
Re: First working Win64 program!
On Mon, 13 Aug 2012 11:23:09 +0200 Paulo Pinto pj...@progtools.org wrote: On Monday, 13 August 2012 at 01:18:14 UTC, Sean Cavanaugh wrote: On 8/12/2012 8:15 PM, Andrej Mitrovic wrote: On 8/13/12, Sean Cavanaughworksonmymach...@gmail.com wrote: we had to modify the code Sure enough I've found your name: http://www.microsoft.com/games/mgsgamecatalog/halopccredits.aspx I noticed you before here but never realized you worked on Halo. It's cool to see people of your caliber having interest in D! :) I have a theory that game development accelerates the rate at which you learn to hate C++ On the other hand, you get to learn lots of stuff to write Game Programming Gems chapters about. :) Good point! I mean, what would ever happen to that series if C++ died? They'd have to change it to Game Programming...Umm...Filler Material...And Maybe a Small Gem or Two ;) (It is a good series though.)
Re: First working Win64 program!
On Mon, 13 Aug 2012 15:42:19 +0200 Adam D. Ruppe destructiona...@gmail.com wrote: On Monday, 13 August 2012 at 04:44:43 UTC, Nick Sabalausky wrote: It's not the current plan. Frankly, I think 32 bits is rapidly becoming irrelevant on the desktop. Bullshit. While I agree with the sentiment (in fact, one of my newest computers is 32 bit; I got a mini laptop - not quite netbook, but not regular laptop either - that is 32 bit), it is worth noting that 32 bit D isn't going away. We're going to be in the same boat we're in now, which does work. Well, not *exactly* the same boat. I always, perhaps mistakenly, assumed the OMF issue would eventually get addressed. To see it pretty much verified that it *won't* be happening is very discouraging and frustrating. The existence of GDC and LDC doesn't solve the problem either.
Re: OSX and 64-bit [Re: First working Win64 program!]
On Mon, 13 Aug 2012 11:25:29 +0200 Paulo Pinto pj...@progtools.org wrote: On Monday, 13 August 2012 at 07:05:11 UTC, Russel Winder wrote: Apple's strategy appears to be that computers are non-upgradable, non-repairable, disposable items that last until the next release: It is this type of issues that keeps me away from Apple products. Along with what I like to call Orwellian Hipsterism. Or maybe Orwell-Chic. A noxious combination of intolerably large doses of trendiness paired with Big Brother seeping out of every millimeter of the design. And then high prices on top of all that. The idea that Apple is the same company that put out that famous 1984 commercial would be laughable if it weren't so depressing.
Re: D overview on facepunch.com
On Sunday, 12 August 2012 at 12:04:05 UTC, Jakob Ovrum wrote: On Sunday, 12 August 2012 at 12:02:06 UTC, Andrei Alexandrescu wrote: http://facepunch.com/showthread.php?t=1204676s=affb44baf90ed48786f63e20a6052df1p=37188144#post37188144 Andrei I'm the OP. It's still a work in progress, some sections are super-thin and I need to put in more references since I don't explain most of the terms I introduce, and many of them are D-specific (e.g. scope statements). You mention in the first post that you're unaware of any IDE for Mac. MonoDevelop + MonoD is cross platform and works identical (except for Debugging) on all three platforms. Also, the way you have MonoD listed (for Linux...), it could be confused as a Linux-Only IDE to a passer-by. I noticed later on a person was comparing VisualD to VisualStudios-C#. Often, I've had a much better time with MonoD over VisualD, and for those who place a lot of importance on intelisense, MonoD has much more comparable features to C# AtM. I would recommend amending your MonoD listing to include a Cross Platform label and emphasis on intelisense support *comparable* to C#. Mono-D's not all there yet, but it actually feels faster and less buggy than Mono C#'s built-in intellisense. Project management and refactoring support are also very complete. That being said, D is a much more dynamic beast (syntactically) than C#, so there's more than a few times code-completion simply fails. Regardless, it's a great development environment and I wouldn't recommend anything else :)
Re: D overview on facepunch.com
On Sunday, 12 August 2012 at 12:04:05 UTC, Jakob Ovrum wrote: On Sunday, 12 August 2012 at 12:02:06 UTC, Andrei Alexandrescu wrote: http://facepunch.com/showthread.php?t=1204676s=affb44baf90ed48786f63e20a6052df1p=37188144#post37188144 Andrei I'm the OP. It's still a work in progress, some sections are super-thin and I need to put in more references since I don't explain most of the terms I introduce, and many of them are D-specific (e.g. scope statements). This was very good, at least much of the first items as I didn't get through everything.
Re: D Shell [was Re: A C++ interpreter]
On Mon, 2012-08-13 at 07:53 +0200, Era Scarecrow wrote: On Monday, 13 August 2012 at 04:25:19 UTC, Marco Leise wrote: Am Mon, 13 Aug 2012 05:38:01 +0200 schrieb Andrej Mitrovic andrej.mitrov...@gmail.com: On 8/13/12, bearophile bearophileh...@lycos.com wrote: http://blog.coldflake.com/posts/2012-08-09-On-the-fly-C%2B%2B.html http://dlang.org/rdmd.html Aw come on, that is not a shell Isn't rdmd just a wrapper for the compiler, then calls the compiled code (or previously saved version of it) afterwards? (That's the impression I get anyways) Shells such as Python, Scala, etc. are good for some one-off experiments and tasks, but I think in general they are over-rated in general usefulness. Much better for non-trivial experimentation is to have a super-lightweight editor/execution. Groovy has GroovyConsole, Python has IDLE. Personally I find Emacs/rdmd excellent as an experimentation combination for D codes. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Exception programming difficult
On Sunday, 12 August 2012 at 03:02:50 UTC, Marco Leise wrote:
I just got a bit frustrated and wanted to say that I like
working with Exceptions in Java a lot more.
I don't. When writing a simple command line program, when there's
an error, it usually means the user messed up and I can't
recover. I just print the message and terminate. I don't want to
have to write throws Exception for everything.
void main(string[] args) {
try {
realMain(args);
return 0;
} catch (Exception e) {
stderr.writeln(e.msg);
}
}
The idea sounds nice, but it's annoying in practice. The point of
exceptions is to _centralize_ error handling. Being forced to
either catch or declare is almost as bad as C-style errno error
handling.
Perhaps an annotation might be nice, as long as it doesn't force
catching:
void buggyFunction(string file, int exception)
@throws(StdioException);
Re: D Shell [was Re: A C++ interpreter]
Russel Winder: Shells such as Python, Scala, etc. are good for some one-off experiments and tasks, but I think in general they are over-rated in general usefulness. To me they seem underrated, go figure :-) In Python I use it all the time. Maybe in D it will be a little less useful. Bye, bearophile
Re: Exception programming difficult
Am Mon, 13 Aug 2012 10:00:31 +0200
schrieb Nathan M. Swan nathanms...@gmail.com:
On Sunday, 12 August 2012 at 03:02:50 UTC, Marco Leise wrote:
I just got a bit frustrated and wanted to say that I like
working with Exceptions in Java a lot more.
I don't. When writing a simple command line program, when there's
an error, it usually means the user messed up and I can't
recover. I just print the message and terminate. I don't want to
have to write throws Exception for everything.
But now and then you probably write something else than a simple command line
program, right?
The idea sounds nice, but it's annoying in practice. The point of
exceptions is to _centralize_ error handling. Being forced to
either catch or declare is almost as bad as C-style errno error
handling.
Ok, it is annoying. Still exceptions are not just an opaque blob with a stack
trace that you catch in your main(). They are more flexible, but it is
difficult to efficiently use this flexibility. For example a routine that
processes multiple files may continue with the next file on
FileNotFoundExceptions, but throw others. A network application may attempt a
few times to reconnect in case of a disconnect. That cannot be accomplished by
one centralized exception handler. There are also a couple of occasions where a
ConvException is better catched and rethrown as a BadServerResponseException
(e.g. a number was expected, but something else returned).
In particular when writing a library I want to offer proper exceptions, and
since they have the bad nature of aborting all your nested function calls, it
is important for me to have the thrown exceptions properly declared - a task
that the compiler can do better and faster than me.
As it stands I might diverge from my old practice and use only one exception
type for a library.
Perhaps an annotation might be nice, as long as it doesn't force
catching:
void buggyFunction(string file, int exception)
@throws(StdioException);
As someone else said, a D lint tool might help with warnings about undocumented
thrown exceptions. But personally I want to be annoyed to death by the
language until I have made it clear what I want to do with the exceptions, even
if I just write catch (ConvException) { /* cannot happen, input is known good
*/ }.
I don't know how many there are who think like me. Your @throws proposal for
example could be used to tell the compiler that I want Java style checked
exceptions for this function and have the compiler check that I listed them
all. An empty list would actually be 'nothrow' then.
--
Marco
Re: Exception programming difficult
I think I should clarify some things up front. o First of all, to be able to add @throws to a function at any point, means that the compiler would internally replace the flag 'isnothrow' with a list of thrown exceptions. That is not much different from what there is now and would be part of the mangled name as well, if acceptable (length restraints), or - since you cannot overload by exceptions - part of an extension to the object file. o nothrow would be equivalent to the empty list @throws() and usable interchangeably. o For protected and public methods of objects and interfaces that are not declared as nothrow, the thrown exceptions would inferred as @throws(Exception). This has to be done, since an override of these methods could introduce any exception type. o private methods and regular functions are properly inferred with the exceptions they actually throw. o At this point all the functions and methods carry their hidden @throws specification around, but it is neither visible in source code, nor is there any impact for developers. o Once someone adds an @throws to a function, the compiler compares it to its internal list and complains if it is missing an exception type. The explicit list can contain additional exceptions that aren't in the compiler inferred list and it can offer more general exceptions, like the base type Exception, as a catch-all. o What happens with object methods that don't declare anything? Since they are inferred as @throws(Exception), no narrowing is possible. On the other hand, I think this is the only natural way to handle it. Thoughts ? -- Marco
Re: Which D features to emphasize for academic review article
On 12/08/12 01:31, Walter Bright wrote:
On 8/11/2012 3:01 PM, F i L wrote:
Walter Bright wrote:
I'd rather have a 100 easy to find bugs than 1 unnoticed one that
went out in
the field.
That's just the thing, bugs are arguably easier to hunt down when
things default
to a consistent, usable value.
Many, many programming bugs trace back to assumptions that floating
point numbers act like ints. There's just no way to avoid knowing and
understanding the differences.
Exactly. I have come to believe that there are very few algorithms
originally designed for integers, which also work correctly for floating
point.
Integer code nearly always assumes things like, x + 1 != x, x == x,
(x + y) - y == x.
for (y = x; y x + 10; y = y + 1) { }
How many times does it loop?
Re: Exception programming difficult
On Sun, 12 Aug 2012 22:01:49 +0100, Jonathan M Davis jmdavisp...@gmx.com wrote: On Sunday, August 12, 2012 16:33:39 Adam D. Ruppe wrote: Perhaps a workable compromise is to make ddoc able to automatically output the throws list. That way, we don't have the hassle of checks, but we do have a maintained list at relatively no hassle. That's both a good idea and bad idea, because all it's going to be able to list is the exceptions thrown directly in the function. In order to list them all, it would have to go digging through the whole call list (which not only would be expensive, but isn't even necessarily possible if the source isn't fully available), and if any classes are involved, then inheritence could totally mess up the list, since different derived classes could throw different exceptions. So, unless all you care about is what's thrown directly from the function, you'd end up with a very incomplete list. The advantage is that you'd at least have a partial list, but if it gave the impression that it was the whole list, then that would be a problem. Of course, writing it by hand also tends to only list what gets thrown directly (or maybe also what's thrown in the direct helpe functions), so there wouldn't necessarily be much difference. So, it may be close to what would be written by hand. It's definitely true though that it won't be listing all of the thrown exceptions in the general case. I wonder if it might be possible to make an intellisense style GUI/IDE tool/plugin which could determine all exceptions thrown either by direct code inspection or ddoc inspection (when source is unavailable) such that it could actually build a complete list. It would need to cache results in order to be anywhere near performant I reckon. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: D Shell [was Re: A C++ interpreter]
On 08/13/2012 04:42 AM, bearophile wrote: Russel Winder: Shells such as Python, Scala, etc. are good for some one-off experiments and tasks, but I think in general they are over-rated in general usefulness. To me they seem underrated, go figure :-) In Python I use it all the time. Maybe in D it will be a little less useful. Bye, bearophile Agreed, I use Python's shell often at work - usually when I just need to test something, but sometimes when someone else asks me for a particular script that does something that (I feel) is only really good for their one situation. I use the scripts I have already and just manually write up a comprehension or five to convert the data into a format that will be useful for them. It doesn't seem worth the effort to make a whole new script just for that. -Matt Soucy
Re: A C++ interpreter
On Sunday, 12 August 2012 at 23:56:02 UTC, bearophile wrote: This not at the top of my enhancement request list, but having something like this shared by all D compilers seems a step forward for D: http://blog.coldflake.com/posts/2012-08-09-On-the-fly-C%2B%2B.html There's also CInt, but I've never tried it myself. http://root.cern.ch/drupal/content/cint
Re: Which D features to emphasize for academic review article
On 13/08/12 11:11, Don Clugston wrote:
Exactly. I have come to believe that there are very few algorithms originally
designed for integers, which also work correctly for floating point.
import std.stdio;
void main()
{
real x = 1.0/9.0;
writefln(x = %.128g, x);
writefln(9x = %.128g, 9.0*x);
}
... well, that doesn't work, does it? Looks like some sort of cheat in place to
make sure that the successive division and multiplication will revert to the
original number.
Integer code nearly always assumes things like, x + 1 != x, x == x,
(x + y) - y == x.
There's always good old if(x==0) :-)
Re: Which D features to emphasize for academic review article
Don Clugston: I have come to believe that there are very few algorithms originally designed for integers, which also work correctly for floating point. And JavaScript programs that use integers? Bye, bearophile
Re: Exception programming difficult
On 2012-08-13 12:31, Regan Heath wrote: I wonder if it might be possible to make an intellisense style GUI/IDE tool/plugin which could determine all exceptions thrown either by direct code inspection or ddoc inspection (when source is unavailable) such that it could actually build a complete list. It would need to cache results in order to be anywhere near performant I reckon. I think that would be great and possible, at lest to some extent. There's always problems with unknown subclasses, dynamically loaded code and so on. -- /Jacob Carlborg
Re: D Shell [was Re: A C++ interpreter]
On 2012-08-13 08:51, Russel Winder wrote: Shells such as Python, Scala, etc. are good for some one-off experiments and tasks, but I think in general they are over-rated in general usefulness. Much better for non-trivial experimentation is to have a super-lightweight editor/execution. Groovy has GroovyConsole, Python has IDLE. Personally I find Emacs/rdmd excellent as an experimentation combination for D codes. I'm using TextMate (Mac OS X) and rdmd. I just create a new document, type the code and run it from within TextMate. I don't even have to save the document. I probably should make it so it automatically wraps the code in a main function for even easier and more script like usage. -- /Jacob Carlborg
Re: D Shell [was Re: A C++ interpreter]
On 2012-08-13 16:03, Jacob Carlborg wrote: I'm using TextMate (Mac OS X) and rdmd. I just create a new document, type the code and run it from within TextMate. I don't even have to save the document. I probably should make it so it automatically wraps the code in a main function for even easier and more script like usage. BTW, I'm using the same method with Ruby as well. I prefer this over the IRB, the Ruby shell. I mean, I have syntax highlighting and other nice features I'm missing in the shell. -- /Jacob Carlborg
Re: A C++ interpreter
On 8/13/12, Marco Leise marco.le...@gmx.de wrote: Am Mon, 13 Aug 2012 05:38:01 +0200 schrieb Andrej Mitrovic andrej.mitrov...@gmail.com: On 8/13/12, bearophile bearophileh...@lycos.com wrote: http://blog.coldflake.com/posts/2012-08-09-On-the-fly-C%2B%2B.html http://dlang.org/rdmd.html Aw come on, that is not a shell That C++ blog post begins with talking how hard it is to just compile something to test things out. All I ever have to do is hit CTRL+ALT+J and I get a new D file opened in my editor with some common Phobos imports. Then I hit F4 and RDMD compiles and runs the app. I've been using this for years, I've got well over 1000 files in my test directory. I don't see what a shell can provide when building D scripts is so damn fast anyway. :)
Re: D Shell [was Re: A C++ interpreter]
On 8/13/12, Jacob Carlborg d...@me.com wrote: On 2012-08-13 16:03, Jacob Carlborg wrote: I'm using TextMate (Mac OS X) and rdmd. I just create a new document, type the code and run it from within TextMate. I don't even have to save the document. I probably should make it so it automatically wraps the code in a main function for even easier and more script like usage. BTW, I'm using the same method with Ruby as well. I prefer this over the IRB, the Ruby shell. I mean, I have syntax highlighting and other nice features I'm missing in the shell. + it's easier to re-edit or copy code in a text editor than in a shell.
Re: Exception programming difficult
On 12-Aug-12 07:02, Marco Leise wrote:
I just got a bit frustrated and wanted to say that I like working with
Exceptions in Java a lot more.
That has to do first but not foremost with the declaration:
---Java-
class MyException extends Exception {
public MyException(String msg) {
super(msg);
}
public MyException(String msg, Throwable next) {
super(msg, next)
}
}
-Java---
I think the true cryptonite that melts checked exceptions to a pile of
green goo is templated code:
So (*yawn*) tell what kind of exception specification the following
function should have:
auto joiner(RoR, Separator)(RoR r, Separator sep);
How would you guarantee upfront what kind of exceptions it can throw is
beyond me. It all depends on code that you can't reach or know by the
very definition of template.
Back to Java: what is I find strange is the lack of sensible tools to do
transactional or exception safe code within the language. No RAII
objects or just at least any kludge to reliably register
cleanup/rollback, only good old try/finally.
--
Dmitry Olshansky
Re: A C++ interpreter
On 13-Aug-12 07:38, Andrej Mitrovic wrote: On 8/13/12, bearophile bearophileh...@lycos.com wrote: http://blog.coldflake.com/posts/2012-08-09-On-the-fly-C%2B%2B.html http://dlang.org/rdmd.html Also check the --eval and --loop thingy ;) -- Dmitry Olshansky
Re: D Shell [was Re: A C++ interpreter]
I probably should make it so it automatically wraps the code in a main function for even easier and more script like usage. Rdmd already has this functionality with the --eval flag. You are supposed to pass the code as a command line parameter, but you can use it with files like this: cat - test.d --eval= | xargs -0 rdmd I've only tried this on Linux.
Re: Exception programming difficult
On 08/13/2012 05:32 PM, Dmitry Olshansky wrote: I think the true cryptonite that melts checked exceptions to a pile of green goo is templated code: So (*yawn*) tell what kind of exception specification the following function should have: auto joiner(RoR, Separator)(RoR r, Separator sep); How would you guarantee upfront what kind of exceptions it can throw is beyond me. It all depends on code that you can't reach or know by the very definition of template. Well, presumably the exception specification would be inferred automatically for templates.
Re: Exception programming difficult
On 13-Aug-12 19:50, Timon Gehr wrote: On 08/13/2012 05:32 PM, Dmitry Olshansky wrote: I think the true cryptonite that melts checked exceptions to a pile of green goo is templated code: So (*yawn*) tell what kind of exception specification the following function should have: auto joiner(RoR, Separator)(RoR r, Separator sep); How would you guarantee upfront what kind of exceptions it can throw is beyond me. It all depends on code that you can't reach or know by the very definition of template. Well, presumably the exception specification would be inferred automatically for templates. What's the propose then? And how end user will get any idea what to put in his function where he uses it? I see one, but it's not pretty - run compiler once - see complaints, add requested types to throws, re-run the compiler? -- Dmitry Olshansky
Re: Exception programming difficult
On 08/13/2012 05:54 PM, Dmitry Olshansky wrote: On 13-Aug-12 19:50, Timon Gehr wrote: On 08/13/2012 05:32 PM, Dmitry Olshansky wrote: I think the true cryptonite that melts checked exceptions to a pile of green goo is templated code: So (*yawn*) tell what kind of exception specification the following function should have: auto joiner(RoR, Separator)(RoR r, Separator sep); How would you guarantee upfront what kind of exceptions it can throw is beyond me. It all depends on code that you can't reach or know by the very definition of template. Well, presumably the exception specification would be inferred automatically for templates. What's the propose then? The same as the OT describes. Don't get me wrong, I am certainly no proponent of adding Java-style checked exceptions to D. And how end user will get any idea what to put in his function where he uses it? The end user is aware of what the template arguments are. I see one, but it's not pretty - run compiler once - see complaints, add requested types to throws, re-run the compiler? Either add requested types to throws or catch and handle the respective exceptions. I assume that this is basically the entire point of statically checked exception specifications.
DMD diagnostic - any way to remove identical lines from final dmd error log?
I seriously consider writing a simple postprocessor for dmd's output. Once dmd became able to recover from errors and crawl on it started to produce horrific amounts of redundant text on failure. Observe for instance that there are only 6 + 2 = 8 lines of interest: uni.d(3699): Error: template instance uni.icmp!(char,wchar) error instantiating uni.d(3683): Error: undefined identifier fullCasedMatch uni.d(3686): Error: undefined identifier fullCasedMatch uni.d(3699): Error: template instance uni.icmp!(char,dchar) error instantiating uni.d(3683): Error: undefined identifier fullCasedMatch uni.d(3686): Error: undefined identifier fullCasedMatch uni.d(3699): Error: template instance uni.icmp!(wchar,char) error instantiating uni.d(3683): Error: undefined identifier fullCasedMatch uni.d(3686): Error: undefined identifier fullCasedMatch uni.d(3699): Error: template instance uni.icmp!(wchar,wchar) error instantiating uni.d(3683): Error: undefined identifier fullCasedMatch uni.d(3686): Error: undefined identifier fullCasedMatch uni.d(3699): Error: template instance uni.icmp!(wchar,dchar) error instantiating uni.d(3683): Error: undefined identifier fullCasedMatch uni.d(3686): Error: undefined identifier fullCasedMatch uni.d(3699): Error: template instance uni.icmp!(dchar,char) error instantiating I'd ideally see this: uni.d(3683): Error: undefined identifier fullCasedMatch uni.d(3686): Error: undefined identifier fullCasedMatch --- !! During instantiation of --- uni.d(3699): template instance uni.icmp!(char,dchar) uni.d(3699): template instance uni.icmp!(char,wchar) uni.d(3699): template instance uni.icmp!(char,dchar) uni.d(3699): template instance uni.icmp!(wchar,wchar) uni.d(3699): template instance uni.icmp!(wchar,dchar) uni.d(3699): template instance uni.icmp!(dchar,char) --- ... other errors Other food for thought is to try to indicate explicitly which errors are related vs unrelated, which are collateral, like failed template instantiation that rolls out the whole path of failure (but one have to read the text carefully to get where it starts). -- Dmitry Olshansky
Re: Exception programming difficult
On Monday, 13 August 2012 at 10:02:23 UTC, Marco Leise wrote: Thoughts ? I like this idea - you can use checked exceptions, but you aren't forced. Though I think private and free functions should by default just use @throws(Exception). Not using @throws is like saying I don't pay attention to what errors might occur, a new version might be different. NMS
Re: Exception programming difficult
Am Mon, 13 Aug 2012 19:54:47 +0400 schrieb Dmitry Olshansky dmitry.o...@gmail.com: On 13-Aug-12 19:50, Timon Gehr wrote: On 08/13/2012 05:32 PM, Dmitry Olshansky wrote: I think the true cryptonite that melts checked exceptions to a pile of green goo is templated code: So (*yawn*) tell what kind of exception specification the following function should have: auto joiner(RoR, Separator)(RoR r, Separator sep); How would you guarantee upfront what kind of exceptions it can throw is beyond me. It all depends on code that you can't reach or know by the very definition of template. The good thing is whatever your argument is, nothrow inevitably has to suffer from it, too. Really I'd like to label this situation as 'bad', when you don't know what exceptions a function may throw. Then why have different exception types at all? Well, presumably the exception specification would be inferred automatically for templates. What's the propose then? And how end user will get any idea what to put in his function where he uses it? I see one, but it's not pretty - run compiler once - see complaints, add requested types to throws, re-run the compiler? Yes it is that bad(tm) ^^. Ok, who is the end user? If I am the user of someone's library and it has an @throws(...) spec, I get an exact idea what to put into my code to handle the exceptions - if I want to. If I'm writing library code on the other hand it depends on the business I'm doing. I'd expect that fast living close to the market code will likely not use this feature, whereas libraries want to be specific about their public API, which includes the exceptions that they throw. I see it as a final step alongside the documentation of a library to add the @throws(...), so it doesn't break the workflow much. As for the benefits: o can act as a contract in class hierarchies when used on overrideable methods o allows you to decide at any point to limit the thrown exceptions to a certain set (e.g. handle cases of ConvException or UTFException before the public API) o makes this automatically visible in DDoc (including any comment on the exception) @throws(ReadException /** if it is not correct. */); o you don't have to document them manually and keep the DDoc up to date, which is much more time consuming than running the compiler twice o let the compiler work for you o I am a lousy salesman writing walls of text Take a look for example at the socket API. Some methods specify the thrown exceptions, others only hint at them by catching them in examples or don't document them at all. You have to start guessing or digging through the source code to find out which error situations result in what exceptions. The InternetAddress ctor taking a host name looks innocent for example as well as most of the Socket methods. In std.datetime, there is a function TimeZone.getInstalledTZNames() where I wonder if the docs are correct. They say on Windows it throws a DateTimeException when the registry cannot be read, but around the actual registry function call I see no try catch to wrap the thrown exception. std.format is sometimes throwing FormatException, but sometimes Exception on similar cases or an UTFException. -- Marco
Broken NVI support
Hello. Please, put attention to following non-runnable due to linker errors sample http://dpaste.dzfl.pl/cad4b558. I suspect that that NVI support is broken, because (my guess) linker assumes that interface should implement functions and doesn't look to class definition. After reading relevant section in TDPL I found another issue: according to p.215 bar() and baz() may have (or even should) 'override' specifier, but currently dmd rejects it. Moreover, dmd is irrelevant about whether 'bar' and 'baz' functions (within class definition) are specified with private keyword or not: is is a bug or intentional behavior? If interface implements functions, which are called from another of interface's functions, linking goes fine. However, after rereading relevant TDPL paragraph and this Alexandrescu post [1] I think that the trick is that functions 'bar' and 'baz' are implemented *not* in interface but in class-implementer. Furthermore, if function declarations are converted to empty definitions keeping the same class definitions, dmd accepts this ambiguity (class A.bar() and interface I.bar()) and gives priority to interface's functions on calling them. So, is this a bug or my NVI misunderstanding is wrong and what is D design policy in this issue? [1] http://digitalmars.com/d/archives/digitalmars/D/The_Non-Virtual_Interface_idiom_in_D_96739.html
Re: Exception programming difficult
Am Mon, 13 Aug 2012 20:17:12 +0200 schrieb Nathan M. Swan nathanms...@gmail.com: On Monday, 13 August 2012 at 10:02:23 UTC, Marco Leise wrote: Thoughts ? I like this idea - you can use checked exceptions, but you aren't forced. Though I think private and free functions should by default just use @throws(Exception). Not using @throws is like saying I don't pay attention to what errors might occur, a new version might be different. NMS Ok, that would simplify the concept, but what would you do about templated functions that operate on ranges, like Dimitry presented? I'd rather have the compiler deduce the exceptions to @throws() where I passed in a simple int[], than have to deal with @throws(Exception). For normal functions it may be feasible. Also all existing code is not annotated, leaving us in the same situation as with other missing attributes in Phobos and people start to complain I'd like to use @throws, but everything is just @throws(Exception) :p -- Marco
Re: Broken NVI support
On Monday, 13 August 2012 at 18:48:09 UTC, Maxim Fomin wrote:
Hello.
Please, put attention to following non-runnable due to linker
errors sample http://dpaste.dzfl.pl/cad4b558.
[quote]
interface I
{
private:
void bar();
void baz();
final void foo()
[/quote]
Isn't it in the specs that overriding methods need to be public
functions? And interfaces are effectively for public interface
only so there shouldn't be any private methods? I mean, what's
the point in mentioning bar and baz if you can't call them? Or
even foo in this case
Re: Which D features to emphasize for academic review article
On 8/13/2012 5:38 AM, Joseph Rushton Wakeling wrote: Looks like some sort of cheat in place to make sure that the successive division and multiplication will revert to the original number. That's called rounding. But rounding always implies some, small, error that can accumulate into being a very large error.
Re: D Shell [was Re: A C++ interpreter]
On Mon, Aug 13, 2012 at 12:51 AM, Russel Winder rus...@winder.org.ukwrote: On Mon, 2012-08-13 at 07:53 +0200, Era Scarecrow wrote: On Monday, 13 August 2012 at 04:25:19 UTC, Marco Leise wrote: Am Mon, 13 Aug 2012 05:38:01 +0200 schrieb Andrej Mitrovic andrej.mitrov...@gmail.com: On 8/13/12, bearophile bearophileh...@lycos.com wrote: http://blog.coldflake.com/posts/2012-08-09-On-the-fly-C%2B%2B.html http://dlang.org/rdmd.html Aw come on, that is not a shell Isn't rdmd just a wrapper for the compiler, then calls the compiled code (or previously saved version of it) afterwards? (That's the impression I get anyways) Shells such as Python, Scala, etc. are good for some one-off experiments and tasks, but I think in general they are over-rated in general usefulness. Much better for non-trivial experimentation is to have a super-lightweight editor/execution. Groovy has GroovyConsole, Python has IDLE. Personally I find Emacs/rdmd excellent as an experimentation combination for D codes. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder I just use http://dpaste.dzfl.pl for my quick testing. I do miss not having vim keybindings but I do gain dmd-git support without the pain of setting it up locally. I'm often testing stuff during a discussion in #D IRC so the site makes it much easier to share as well. BA
bug with auto or what?
I'm writing an insert() function for a binary tree in D:
Note: Node is a value type (struct)
Node!(T)* insert(T) (Node!(T)* root, T val)
{
if( root is null )
{
root = new Node!T();
root.value = val;
root.left = root.right = null;
}
else
{
if( val root.value )
root.left = insert(root.left, val);
else
root.right = insert(root.right, val);
}
return root;
}
This works (compiles).
auto insert(T) (Node!(T)* root, T val)
{
if( root is null )
{
root = new Node!T();
root.value = val;
root.left = root.right = null;
}
else
{
if( val root.value )
root.left = insert(root.left, val); // line x
else
root.right = insert(root.right, val); // line y
}
return root;
}
This doesn't compile.
test.d(x): Error: forward reference to inferred return type of
function call insert((*root).left,val)
test.d(y): Error: forward reference to inferred return type of
function call insert((*root).right,val)
Is it a bug with auto or something else?
Re: Broken NVI support
On Mon, 13 Aug 2012 20:48:07 +0200, Maxim Fomin ma...@maxim-fomin.ru wrote: Hello. Please, put attention to following non-runnable due to linker errors sample http://dpaste.dzfl.pl/cad4b558. As Era pointed out, private functions in D are implicitly final, i.e. not overridable. Change all instances of 'private' to 'protected', and Bob is your proverbial uncle. -- Simen
Re: bug with auto or what?
On Monday, 13 August 2012 at 19:09:04 UTC, Minas Mina wrote: Is it a bug with auto or something else? It's not really a bug. You're using insert before its return type has been inferred. Hence, it says forward reference to inferred return type. However, in this case, it should be possible to infer the return type because they type of root is known. Maybe an enhancement request? In any case, the solution, as you've found, is to explicitly define the return type if you're going to be using it recursively.
Re: Which D features to emphasize for academic review article
On 8/12/2012 6:38 PM, F i L wrote: Also, and I'm not sure this isn't just me, but I ran a DMD (v2.057 T think) vector test (no simd) against Mono C# a few moths back where DMD got only ~10 ms improvement over C# (~79ms vs ~88ms). Now a similar test compiled with DMD 2.060 runs at ~22ms vs C#'s 80ms, so I believe there's been some definite optimization improvements in the internal DMD compiler over the last few version. There's a fair amount of low hanging optimization fruit that D makes possible that dmd does not take advantage of. I hope to get to this. One thing is I suspect that D can generate much better SIMD code than C/C++ can without compiler extensions. Another is that D allows values to be moved without needing a copyconstruct/destruct operation.
Re: Which D features to emphasize for academic review article
On 13/08/12 20:04, Walter Bright wrote: That's called rounding. But rounding always implies some, small, error that can accumulate into being a very large error. Well, yes. I was just remarking on the choice of rounding and the motivation behind it. After all, you _could_ round it instead as, x = 1.0/9.0 == 0.11 ... 111 [finite number of decimal places] but then 9*x == 0. ... [i.e. doesn't multiply back to 1.0]. ... and this is probably more likely to result in undesirable error than the other rounding scheme. (I think the calculator app on Windows used to have this behaviour some years back.)
Re: Is D Language mature for MMORPG Client ?
On 8/12/2012 5:00 AM, Araq wrote: A concrete example would really be nice here ... Inappropriate use of Outbuffer's internal data.
Re: Broken NVI support
On Monday, August 13, 2012 20:48:07 Maxim Fomin wrote: So, is this a bug or my NVI misunderstanding is wrong and what is D design policy in this issue? Currently, only public and protected functions are ever virtual: http://d.puremagic.com/issues/show_bug.cgi?id=4542 This may or may not change for interfaces in order to match TDPL, but I wouldn't expect it to ever change for classes. You should be able to do NVI just fine with protected. - Jonathan M Davis
Re: Do infinite bidirectional ranges make any sense?
Le 12/08/2012 15:28, Andrei Alexandrescu a écrit : On 8/12/12 9:11 AM, Simen Kjaeraas wrote: On Sun, 12 Aug 2012 06:11:48 +0200, Jonathan M Davis jmdavisp...@gmx.com wrote: Can anyone think of any situation where an infinite bidirectional range would make any sense at all? std.range.repeat(1); I would be very surprised if that's not both bidirectional and infinite. Nice. I'm sure there are mathematically-motivated bidirectional infinite ranges that are more interesting than the constant range. However, I think few, if any, would be of practical interest. We could and should probably proceed with the simplification that any bidirectional range must be finite. Andrei I do see the lack of actual practical use case, (it doesn't mean none exists, but few exists) but what does excluding that case brings us ?
Re: Do infinite bidirectional ranges make any sense?
On Tuesday, August 14, 2012 01:57:17 deadalnix wrote: I do see the lack of actual practical use case, (it doesn't mean none exists, but few exists) but what does excluding that case brings us ? I don't know if it's useful one way or the other as far as making it illegal goes, but it's certainly useful for generating range types to test with, since it's extra work to create an infinite range which is bidirectional. - Jonathan M Davis
Re: Which D features to emphasize for academic review article
On Monday, 13 August 2012 at 10:11:06 UTC, Don Clugston wrote:
... I have come to believe that there are very few algorithms
originally designed for integers, which also work correctly for
floating point.
Integer code nearly always assumes things like, x + 1 != x, x
== x,
(x + y) - y == x.
for (y = x; y x + 10; y = y + 1) { }
How many times does it loop?
Don,
I would appreciate your thoughts on the issue of re-implementing
numeric codes like BLAS and LAPACK in pure D to benefit from the
many nice features listed in this discussion. Is it feasible?
Worthwhile?
Thanks,
TJB
Re: D Shell [was Re: A C++ interpreter]
On Mon, 13 Aug 2012 17:36:13 +0200 jerro a...@a.com wrote: I probably should make it so it automatically wraps the code in a main function for even easier and more script like usage. Rdmd already has this functionality with the --eval flag. You are supposed to pass the code as a command line parameter, but you can use it with files like this: cat - test.d --eval= | xargs -0 rdmd I've only tried this on Linux. As a person who's still only half-way a Linux guy, I have to ask: What the hell is going on in that command? I understand bits and pieces of it, but my mind's having a hard time parsing it. Can any of you unix gurus help me out?
Re: A C++ interpreter
On Mon, 13 Aug 2012 14:13:19 +0200 Era Scarecrow rtcv...@yahoo.com wrote: On Sunday, 12 August 2012 at 23:56:02 UTC, bearophile wrote: This not at the top of my enhancement request list, but having something like this shared by all D compilers seems a step forward for D: http://blog.coldflake.com/posts/2012-08-09-On-the-fly-C%2B%2B.html There's also CInt, but I've never tried it myself. http://root.cern.ch/drupal/content/cint Heh, CInt sounds more like a boxed integer :)
Re: D Shell [was Re: A C++ interpreter]
cat - test.d --eval= | xargs -0 rdmd I've only tried this on Linux. As a person who's still only half-way a Linux guy, I have to ask: What the hell is going on in that command? The minus on the cat command line means standard input and somecommand somestring Sends somestring to the standard input of somecommand. So the first part here outputs the contents of test.d with --eval= prepended. That's what xargs get as a standard input. Xargs then calls rdmd with that string as a command line argument. The -0 flag tells xargs to treat the input as a bunch of zero separated strings and to treat backslashes and double quotes the same as other characters (the default is to treat newlines and spaces as separators and to use quotes and backslashes to prevent spliting strings on newlines and spaces). I did it that way to avoid issues with escaping characters. I understand bits and pieces of it, but my mind's having a hard time parsing it. Can any of you unix gurus help me out? I'm hardly a unix guru, I've been using linux for less than two years. I guess it's not hard to write hard to read bash commands :D
Re: For infinite loop
Am Mon, 13 Aug 2012 00:53:43 +0200 schrieb bearophile bearophileh...@lycos.com: It looks better. But you every time you use a cast in D you need to be careful, because they are like a sharp tool with almost no safeties. Bye, bearophile So true. It happens to me sometimes that I cast away const although I just want to cast a type. It's also a reason I am not a big fan of considering cast(ubyte) 0 normal. It is pragmatic though. -- Marco
Re: For infinite loop
Marco Leise: Again it seems my message you have answered to is not visible through the online reader at forum.dlang.org. So true. It happens to me sometimes that I cast away const although I just want to cast a type. It's also a reason I am not a big fan of considering cast(ubyte) 0 normal. It is pragmatic though. A not a lot documented way to remove a const it to use an empty cast() with no argument. Another way is to use unqual!(). Bye, bearophile
Linker errors after updating to DMD 2.060
Hey all, After switching to 2.060, I'm getting the following linker errors on a project of mine: Error 42: Symbol Undefined _D4core6memory2GC6extendFPvkkZk build\unittest.obj(unittest) Error 42: Symbol Undefined _D4core6memory2GC6qallocFkkZS4core6memory8BlkInfo_ build\unittest.obj(unittest) Error 42: Symbol Undefined _D4core5bitop3bsrFNaNbkZi build\unittest.obj(unittest) Error 42: Symbol Undefined _D4core6memory2GC6mallocFkkZPv build\unittest.obj(unittest) Error 42: Symbol Undefined _D3std6loader19ExeModule_GetSymbolFKPvxAyaZPv build\unittest.obj(unittest) Error 42: Symbol Undefined _D4core6memory2GC8minimizeFZv build\unittest.obj(unittest) Error 42: Symbol Undefined _D4core6memory2GC4freeFPvZv build\unittest.obj(unittest) Error 42: Symbol Undefined _D4core6memory2GC11removeRangeFxPvZv build\unittest.obj(unittest) Error 42: Symbol Undefined _D4core6memory2GC7collectFZv build\unittest.obj(unittest) Error 42: Symbol Undefined _D3std6loader14ExeModule_LoadFxAyaZPv build\unittest.obj(unittest) Error 42: Symbol Undefined _D3std6loader12__ModuleInfoZ Any idea's why it does compile but fails to link on: core.memory core.bitop std.loader (by the way the 2.059 was able to link them just fine) Code is available via github: https://github.com/DannyArends/D-coding checkout and build using rake or rake unittest
Re: Linker errors after updating to DMD 2.060
Make sure you completely wipe out your old installation. Several modules were _removed_ that may be still hanging around. On top of that, ensure that you're not linking any object files from 2.059 with new object files from 2.060 (i.e. do a complete rebuild).
Re: prevent multiple calls to rt_term
Sounds like what's needed is a call counter, so if rt_init is called N times, rt_term must be called N times before the runtime really terminates. On Aug 13, 2012, at 1:14 PM, Ellery Newcomer ellery-newco...@utulsa.edu wrote: Hello. In Pyd, I am trying to get python extension libraries working, but this requires building shared libraries with D. LDC works adequately for this, if you don't mind not having module constructors or unittests; however, in the presence of multiple shared libraries coordinating rt_init and rt_term seems to be an issue. Currently, I have each shared lib calling rt_init in _init and rt_term in _fini. I would like to know if druntime supports a way to detect if it is running. For rt_term, I have been using rt.dmain2.isHalting, but that seems to have gone away in more recent druntime, and anyways doesn't seem to be working for me. I wonder if it would make more sense to call rt_init and rt_term in the druntime shared lib's _init and _fini?
AA rehash link error
When building my program by compiling .o files first and then
linking, everything links fine, but when I try to compile all the
source files at once, I get the following link error:
build/debug/dboss-debug.o: In function `@property
boss.proc.proccmd.ProcCmd.Cmd[immutable(char)[]]
object.AssociativeArray!(immutable(char)[],
boss.proc.proccmd.ProcCmd.Cmd).AssociativeArray.rehash()':
/usr/include/dmd/druntime/import/object.di:465: undefined
reference to
`_D44TypeInfo_HAyaC4boss4proc7proccmd7ProcCmd3Cmd6__initZ'
The AA in question is a static class member declared as follows:
static immutable Cmd[string] m_cmds;
And Cmd is a class defined in the same class:
static class Cmd {
alias string function(ProcCmd c, string[] args) fExec;
string m_cmd; //Invocation name
string m_desc; //Description of command
fExec m_exec; //Function implementing command
this(string cmd, string desc, fExec exec) {
m_cmd = cmd;
m_desc = desc;
m_exec = exec;
}
}
What am I doing wrong? This is working perfectly fine when
building object files before linking.
Re: prevent multiple calls to rt_term
On 08/13/2012 01:19 PM, Sean Kelly wrote: Sounds like what's needed is a call counter, so if rt_init is called N times, rt_term must be called N times before the runtime really terminates. is it valid to call rt_init more than once?
Link .s file with dmd?
Can i link an assembler file .s with dmd like gcc with gcc out.s any.c -o out.exe? If so, how?
Re: prevent multiple calls to rt_term
On Aug 13, 2012, at 2:07 PM, Ellery Newcomer ellery-newco...@utulsa.edu wrote: On 08/13/2012 01:19 PM, Sean Kelly wrote: Sounds like what's needed is a call counter, so if rt_init is called N times, rt_term must be called N times before the runtime really terminates. is it valid to call rt_init more than once? Not currently.
Re: Link .s file with dmd?
On Monday, 13 August 2012 at 22:06:08 UTC, Namespace wrote: Can i link an assembler file .s with dmd like gcc with gcc out.s any.c -o out.exe? If so, how? .s, .c, .d files (source files), are not linked. What is linked, are object files (.obj or .o). GCC either compiles the .s file to an object file, or passes it to assembler to do it - I don't know. I think what you need to is to create an object file from the .s file and link it to your D executable. To do it: gcc out.s -c The -c switch stops after compiling. It doesn't do the linking. A .o file will be created, out.o Then dmd your_source_file.d out.o
Re: For infinite loop
On Monday, 13 August 2012 at 08:18:08 UTC, Marco Leise wrote: Am Mon, 13 Aug 2012 00:53:43 +0200 schrieb bearophile bearophileh...@lycos.com: It looks better. But you every time you use a cast in D you need to be careful, because they are like a sharp tool with almost no safeties. Bye, bearophile So true. It happens to me sometimes that I cast away const although I just want to cast a type. It's also a reason I am not a big fan of considering cast(ubyte) 0 normal. It is pragmatic though. In fact, it would be nice to do something like this: foreach(ubyte i; 0..256) writefln(%d, i); but the code above will generate an error like: 256 cannot be converted to ubyte! On the other hand: foreach(ubyte i; 0..255) writefln(%d, i); Works, but only will show numbers from 0..254, without 255! So, maybe this is more safer: foreach(ushort i; 0..ubyte.max+1) writefln(%d, cast(ubyte)i); Matheus.
Re: prevent multiple calls to rt_term
On 08/13/2012 03:37 PM, Sean Kelly wrote: On Aug 13, 2012, at 2:07 PM, Ellery Newcomer ellery-newco...@utulsa.edu wrote: On 08/13/2012 01:19 PM, Sean Kelly wrote: Sounds like what's needed is a call counter, so if rt_init is called N times, rt_term must be called N times before the runtime really terminates. is it valid to call rt_init more than once? Not currently. I guess if it were made valid then module constructors would still be out? IE if N shared libraries bring N sets of modules to the table and rt_init is called N times, then what's to prevent some module constructors from being run more than once?
Re: Reading a csv file
On Monday, 13 August 2012 at 18:49:55 UTC, Nathan M. Swan wrote: Without the -property switch, you can use non-@property functions as if they were @property. This is supposed to eventually be deprecated, so I try to not do this. To add to this, historically it was a feature. Why add properties when you can just call functions without parentheses? Long story left elsewhere, wiki4d seems to be down!!! sorry. Anyway, as it is a breaking change it takes forever to get rid of it (that way new code can start relying on it...)
[Issue 4283] static if with dangling else clause
http://d.puremagic.com/issues/show_bug.cgi?id=4283
--- Comment #2 from Ellery Newcomer ellery-newco...@utulsa.edu 2012-08-12
23:51:08 PDT ---
The problem is if parseBlock encounters a rcurly, it consumes nothing.
Otherwise, it will consume
{ decldefs }
: decldefs
decldefs
;
As near as I can tell, consuming nothing serves no purpose in the parser, but
it does allow the following:
class C{
public
}
struct S{
static auto
}
interface F{
extern(C)
}
union Z{
extern private
}
class C2{
align
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4920] Member expression tuple allowed for types, disallowed for expressions
http://d.puremagic.com/issues/show_bug.cgi?id=4920 --- Comment #2 from github-bugzi...@puremagic.com 2012-08-13 02:08:10 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/d2e632003437cbffcdcfbb82bdb2adb8003a9a49 fix Issue 4920 - Member expression tuple allowed for types, disallowed for expressions https://github.com/D-Programming-Language/dmd/commit/5590585d14e3664156063fb8ed414cfc56e5199a Merge pull request #973 from 9rnsr/fix4920 Issue 4920 - Member expression tuple allowed for types, disallowed for expressions -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8545] defined opCast disables cast(void*)this in classes
http://d.puremagic.com/issues/show_bug.cgi?id=8545
--- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-08-13
07:57:58 PDT ---
(In reply to comment #2)
I don't think this is major, because you can use a union:
{
static union U { Object o; void* p; }
U u;
u.o = this;
return u.p;
}
In fact, because a union can be used for reinterpret casting, I don't think
any
new syntax or semantics are needed.
I'm speaking in terms of wrapping C++ libraries (A C++ wrapper class has an
inner d_object pointer which it uses to invoke D virtual methods). You're
asking me to introduce overhead for every time a new class object is
instantiated.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8546] New: std.array.overlap missing from ddoc
http://d.puremagic.com/issues/show_bug.cgi?id=8546 Summary: std.array.overlap missing from ddoc Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-08-13 21:00:03 PDT --- Missed an asterisk above the 'overlap' documentation: /* - /** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
