Re: Properties don't behave like variables?
Any news?
Re: OSCON 2012 notes
On Saturday, July 21, 2012 08:48:57 Paulo Pinto wrote: > After becoming disapointed with Go leaving in the past, I've come to the > conclusion that between the two, D is a much better choice. I still need to study up on Go one of these days (along with a variety of other languages which are on my to-learn list), but the more I learn about it, the less I understand why Go and D are treated as competitors. I guess it's because of the systems language moniker (though Go doesn't mean it in the same was as C++ and D, so that skews things already), but Go and D are just so radically different in their basic approaches and philosophies, that I would expect that the folks who like one would dislike the other in most cases. They're just so completely different that I wouldn't expect them to really compete with one another save for the fact that developers only have so much time to check out new languages, so if one's getting a lot more attention, that could reduce how many people check out the other one, even if most people who check out the first one don't end up liking it. - Jonathan M Davis
Re: Re-thinking D's modules
On Wednesday, 18 July 2012 at 09:25:03 UTC, Russel Winder wrote: For those that don't know .NET, due to the DLL Hell experience, Microsoft has built version support in the CLR from day 1. But, as ever, Microsoft see things like this as a way to try and get everyone to use Windows via proprietary lock-in rather than by trying to educate people about possible solutions. AFAIK MS tried to use java, but they wasn't allowed to do it. They had to invent a completely alternative solution. And .net is a possible solution, and MS educates people about it. Also versioning of components is done by COM for ages, though the application has to be designed and written with COM in mind. Components don't even have to be implemented in the same language nor reside in the same process, nor on the same machine.
Re: Re-thinking D's modules
On Wednesday, 18 July 2012 at 09:25:03 UTC, Russel Winder wrote: For those that don't know .NET, due to the DLL Hell experience, Microsoft has built version support in the CLR from day 1. But, as ever, Microsoft see things like this as a way to try and get everyone to use Windows via proprietary lock-in Also why mono exists, if it's meant to be a lock-in?
Re: Just where has this language gone wrong?
Am Fri, 20 Jul 2012 16:43:18 +0200 schrieb Jacob Carlborg : > On 2012-07-20 16:33, Marco Leise wrote: > > > I think C++ uses a pragmatic approach: No overhead for explicit > > initialization. But everything that goes into the executable and doesn't > > have a specific value, will go into the BSS section, where it A) takes up > > no space and B) the OS will take care of zero initializing it _anyways_. > > > > If it is stored in the .exe, it is 0! > > Is it defined what is placed in the executable? P.S.: s/section/segment/ Someone else would have to answer that question. I assume anything that is kind of static, like globals, class variables, D's .init blocks. It makes sense to me, because the compiler can issue static references to that data, instead of generating code that creates space for it e.g. on the heap and have the program use a pointer to get at it. -- Marco
Re: std.random and mersenne twister
On Friday, 20 July 2012 at 21:45:17 UTC, Andrei Alexandrescu wrote: On 7/20/12 8:51 AM, Andrea Fontana wrote: CMWC is proven to be a valid method and it passes diehard tests. It was written by prof. George Marsiglia (he developed xorshift too - included in std.random). He was one of the best experts in PRNG. Would be great if you wanted to contribute an implementation of CMWC to std.random. Thanks, Andrei That's something I could undertake confidently. Writing both an actual engine, and creating aliases for pre-optimized schemes. I'd just have to wait to finish my current development (I don't know how to have parallel forks).
Re: std.random and mersenne twister
On Saturday, 21 July 2012 at 10:28:58 UTC, monarch_dodra wrote: I'd just have to wait to finish my current development (I don't know how to have parallel forks). Just create a single GitHub fork with multiple branches, one for each feature/bug you are working on. After pushing them to GitHub, you can create separate pull requests for each of them. David
Re: Re-thinking D's modules
"Kagamin" writes: > On Wednesday, 18 July 2012 at 09:25:03 UTC, Russel Winder wrote: >>> For those that don't know .NET, due to the DLL Hell experience, >>> Microsoft >>> has built version support in the CLR from day 1. >> >> But, as ever, Microsoft see things like this as a way to try and get >> everyone to use Windows via proprietary lock-in rather than by >> trying to >> educate people about possible solutions. > > AFAIK MS tried to use java, but they wasn't allowed to do it. They were, but they had to make changes -- and that, they weren't allowed to do. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a
There is nothing cooler than a macr- Err… Mixin?
Great post on D's mixins and Philippe Sigaud's Pegged: http://idorobots.org/2012/07/20/macro-mixin/ and on Reddit: http://www.reddit.com/r/programming/comments/wws65/there_is_nothing_cooler_than_a_macr_err_mixin/ -- Simen
Re: OSCON 2012 notes
Am 21.07.2012 10:20, schrieb Jonathan M Davis: On Saturday, July 21, 2012 08:48:57 Paulo Pinto wrote: After becoming disapointed with Go leaving in the past, I've come to the conclusion that between the two, D is a much better choice. I still need to study up on Go one of these days (along with a variety of other languages which are on my to-learn list), but the more I learn about it, the less I understand why Go and D are treated as competitors. I guess it's because of the systems language moniker (though Go doesn't mean it in the same was as C++ and D, so that skews things already), but Go and D are just so radically different in their basic approaches and philosophies, that I would expect that the folks who like one would dislike the other in most cases. They're just so completely different that I wouldn't expect them to really compete with one another save for the fact that developers only have so much time to check out new languages, so if one's getting a lot more attention, that could reduce how many people check out the other one, even if most people who check out the first one don't end up liking it. - Jonathan M Davis Go is an evolution of Limbo (http://www.vitanuova.com/inferno/limbo.html), where ADTs got replaced by interfaces coupled with method declarations syntax from Component Pascal (http://www.oberon.ch/pdf/CP-Lang.pdf), an extension to Oberon. If you spend some time reading Inferno and Limbo documentation after learning Go, you'll see how they share so many concepts. http://doc.cat-v.org/inferno/books/inferno_programming_with_limbo/ Regarding systems programming, Go could actually play in the same league as D, since Oberon was used to write the Native Oberon and A2 operating systems. Besides the assembly for the GC and boot, everything else is written in Oberon. As a personal workstation the system was used a lot by the ETHZ researchers during the 90's. A quite cool environment where you get a Smalltalk like environment, with a strong typed language. Nowadays it is mainly used to teach OS principles at ETHZ, and embedded systems development. You can read more it here, http://www.ethoberon.ethz.ch/native/WebScreen.html(screenshots) http://www.ethoberon.ethz.ch/WirthPubl/ProjectOberon.pdf (how it was implemented) http://www.astrobe.com/Oberon.htm (embedded systems support) The trick with Oberon, which Go also uses, is to have a special module reckognised by the compiler with primitives to do the low tricks C offers. Additionaly any function/method without body can be implemented in Assembly. This is nothing new, Modula-2 already worked like this. What I miss from Go, and is what makes me like more of D is, - enumerations - exceptions - metaprogramming - generics - dynamic loading - constness - operator overloading - method overloading - support for FP Basically everything that has become part of the enterprise world since the late 90's. Wirth has a nice paper where we describes the evolution of the languages he designed, stating on the chapter 7, that Oberon failed in the industry because companies preferred the code bloat of other languages instead of Oberon's simplicity. http://www.inf.ethz.ch/personal/wirth/Articles/Modula-Oberon-June.pdf This is exactly the same school of thought that Go designers follow. If language design would be considered art, they would probably be part of the Minimalism mouvement. -- Paulo
Re: There is nothing cooler than a macr- Err… Mixin?
On Sat, Jul 21, 2012 at 2:22 PM, Simen Kjaeraas wrote:
> Great post on D's mixins and Philippe Sigaud's Pegged:
>
> http://idorobots.org/2012/07/20/macro-mixin/
>
> and on Reddit:
>
> http://www.reddit.com/r/programming/comments/wws65/there_is_nothing_cooler_than_a_macr_err_mixin/
I think I just had a geekgasm. Thanks Kajetan, that makes my day!
Is that a code-into-code call right there?
*** LOOP code
with data = $$ // Yo dawg...
mixin(Loope!q{
for i from 0.0 to max by 1.337
collect i
}); $$
***
That's mightily cool!
Another solution could be to add a special syntax ($! ... !$ or
whatever) to insert code into code:
***
with date = $! for i from 0.0 to max by 1.337
collect i
!$
***
Geez, I should be hacking on Pegged right now.
Philippe
Re: OSCON 2012 notes
On 2012-07-21 06:48:57 +, Paulo Pinto said: We need something like std.database for web development, which as far as I know is currently on hold. WinRT support would also be a nice feature. Need to spend some time checking how to work with type libraries. The web is a low-hanging fruit for D. The language is already very suitable for it: being able to talk to C APIs, socket IO, and starting external processes plenty enough. All it needs really is some library code. Supporting WinRT, or Cocoa, in any pleasant way is a much bigger project. Both these APIs use OO extensively and, while they are accessible from C, dealing with such code using C functions is a pain. I'm convinced that what D needs is direct support for new object models in the language. The good news is that semantically both the WinRT model and the Cocoa model of an object are close enough to the D model -- single inheritance, one root object -- and I've shown with my experimental DMD/Objective-C branch[1] that such a model integrates quite well to D despite the differences. In fact, WinRT, being based on COM, would probably map better than Cocoa. [1]: http://michelf.ca/projects/d-objc/ So in short, to be successful in GUI development, D need to support the native object model of the GUI platform it runs on without having to jump through hoops and without having a complicated layer of bindings. Using D code within a GUI app should be as easy as using C++ code within it would be. Otherwise, you cannot really compete. And also, more and more it'd require ARM support to be competitive in the GUI area. Compare those requirements to those of web development, were almost all servers are x86, where C, socket IO, and execution of external processes is all that's needed interface with other components, and you'll see that web dev is truly the low-hanging fruit in terms of market for D. -- Michel Fortin michel.for...@michelf.ca http://michelf.ca/
Re: OSCON 2012 notes
On Saturday, 21 July 2012 at 13:47:06 UTC, Michel Fortin wrote: The web is a low-hanging fruit for D. Yea, I've been eating that fruit for years. While my libs are out there, I haven't gotten around to doing the rest of the documentation or anything. My libraries are just a means to an end to me. They get the job done, so I focus on the job, and then I have other stuff the rest of my time. But there's people who have used my libs regardless so if you are interested, here it is: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff
Re: Preview LLVM Deimos bindings
Bernard Helyer wrote: > Very interesting. I'd be interested in making some D Native feeling > bindings, because the LLVM C bindings are A, inconsistent, and B, > complete shit. So this is interesting. Building a better wrapper on top of these would be nice. Can you give examples for A and B? Jens
Re: Re-thinking D's modules
On Sat, 2012-07-21 at 11:26 +0200, Kagamin wrote: […] > AFAIK MS tried to use java, but they wasn't allowed to do it. > They had to invent a completely alternative solution. And .net is > a possible solution, and MS educates people about it. Microsoft changed the Java Virtual Machine (JVM) on Windows and Sun objected to them doing this. Sun's position was that the JVM should be the same on all platforms – which is an entirely reasonable position for them to take. Microsoft didn't think so and tried to persevere with changing the JVM so Sun took them to court and won. Which was right. Microsoft then created the CLR and C# which seems fine. The problem for C# is that Microsoft marketing has put about FUD for anyone using C# on a platform other than Windows. But this has nothing to do with D! -- 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: std.random and mersenne twister
On 7/21/12 6:28 AM, monarch_dodra wrote: On Friday, 20 July 2012 at 21:45:17 UTC, Andrei Alexandrescu wrote: On 7/20/12 8:51 AM, Andrea Fontana wrote: CMWC is proven to be a valid method and it passes diehard tests. It was written by prof. George Marsiglia (he developed xorshift too - included in std.random). He was one of the best experts in PRNG. Would be great if you wanted to contribute an implementation of CMWC to std.random. Thanks, Andrei That's something I could undertake confidently. Writing both an actual engine, and creating aliases for pre-optimized schemes. I'd just have to wait to finish my current development (I don't know how to have parallel forks). That would be awesome (both RNG and getting fluent with parallel forks). Andrei
Re: There is nothing cooler than a macr- Err… Mixin?
On 7/21/12 8:22 AM, Simen Kjaeraas wrote: Great post on D's mixins and Philippe Sigaud's Pegged: http://idorobots.org/2012/07/20/macro-mixin/ and on Reddit: http://www.reddit.com/r/programming/comments/wws65/there_is_nothing_cooler_than_a_macr_err_mixin/ Very solid work. Who is I do robots? We must bring him on the team! Andrei
Re: There is nothing cooler than a macr- Err… Mixin?
On 7/21/12 9:46 AM, Philippe Sigaud wrote: I think I just had a geekgasm. Yah, same here (in abstract that is). Do you know the author? Geez, I should be hacking on Pegged right now. Yes please. I've shown a Pegged example at OSCON (see my slides towards the end) and there were quite a few "bouche bée"s. Andrei
Re: OSCON 2012 notes
On 7/21/12 10:08 AM, Adam D. Ruppe wrote: On Saturday, 21 July 2012 at 13:47:06 UTC, Michel Fortin wrote: The web is a low-hanging fruit for D. Yea, I've been eating that fruit for years. While my libs are out there, I haven't gotten around to doing the rest of the documentation or anything. My libraries are just a means to an end to me. They get the job done, so I focus on the job, and then I have other stuff the rest of my time. But there's people who have used my libs regardless so if you are interested, here it is: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff Would you agree if someone took your code, modified it for the purposes of passing it through the forks of the review process, and pushed it into Phobos? You'd still receive credit, of course, but it would be shared with that person or group because that's significant work. Let us know - thanks! Andrei
Re: Preview LLVM Deimos bindings
On Friday, 20 July 2012 at 05:36:26 UTC, Jens Mueller wrote: Hi, I've written some Deimos interface for LLVM. https://github.com/jkm/deimos-llvm/commits/master I'd like to get some feedback on those. Firstly to finish these and secondly to finish some guidelines that I'd like to propose to be published on dlang.org. Jens I tried with my port of the Kaleidoscope, apart from some comestic changes, it worked like a charm ! (Using LLVM 3.0) Here's the diff: https://github.com/mlarouche/llvm-d-tutorial/commit/8e3b53a1040db672c16fd0685bd0e6fd7d075b48#main.d
Re: There is nothing cooler than a macr- Err… Mixin?
On Saturday, 21 July 2012 at 16:42:55 UTC, Andrei Alexandrescu wrote: Do you know the author? That would be me. I'm very pleased both of you liked it, I didn't expect my lousy loop to get that much attention. :) Kajtek
Re: Preview LLVM Deimos bindings
=?UTF-8?B?Ik1pY2hhw6ts?=.Larouche" "@puremagic.com wrote: > On Friday, 20 July 2012 at 05:36:26 UTC, Jens Mueller wrote: > >Hi, > > > >I've written some Deimos interface for LLVM. > >https://github.com/jkm/deimos-llvm/commits/master > > > >I'd like to get some feedback on those. > >Firstly to finish these and secondly to finish some guidelines > >that I'd > >like to propose to be published on dlang.org. > > > >Jens > > I tried with my port of the Kaleidoscope, apart from some comestic > changes, it worked like a charm ! (Using LLVM 3.0) Thanks. To be honest I took your main.d to verify that it works. But I'm unsure what kind of examples to add to make sure it works. Just want something simple but complete. Jens
Optional name mangling
Hi. Is there any way to instruct the D compiler not to use name mangling when referencing an external C++ function? For example: extern (System) bool PathRenameExtension(LPSTR pszPath, LPCSTR pszExt); In this particular case, the exported function being referenced is not called _PathRenameExtension@8 - it's just called PathRenameExtension. Now, it's great that D helpfully mangles the name for me when appropriate, but we really need some way to disable it when necessary. Is there any way to import this function without creating a .def file with "_PathRenameExtension@8 = PathRenameExtension"? And if not, why not?
Re: Preview LLVM Deimos bindings
On Saturday, 21 July 2012 at 15:30:46 UTC, Jens Mueller wrote: Bernard Helyer wrote: Very interesting. I'd be interested in making some D Native feeling bindings, because the LLVM C bindings are A, inconsistent, and B, complete shit. So this is interesting. Building a better wrapper on top of these would be nice. Can you give examples for A and B? Jens The verbs used change from function to function. I can't remember any off the top of my head, but I run into bunch when using it for SDC. As to B, they're incomplete, undocumented, and awkward to use. No reflection on your fine work, of course. :)
Re: OSCON 2012 notes
On Sat, 21 Jul 2012 09:47:06 -0400 Michel Fortin wrote: > > And also, more and more it'd require ARM support to be competitive in > the GUI area. > Yes. But there's an even bigger reason for ARM: Mobile devices, like iOS and Android. I'm not personally a fan of them, but nonetheless those things are HUGE (no pun intended). And yet the ONLY real language choices there are C++, Java and Objective-C (and Lua if you count "Son-of-Flash", ie Corona - which I don't count). And half of THOSE are out of the question if you want cross platform, which any sane developer should. So PERFECT fertile ground for D. I know I keep harping on that, but it's a big issue for me since I'm deep into that stuff now and goddamn do I wish I could be doing it in D, but D's support on those devices (or just outputting C/C++) unfortunately just isn't mature enough ATM.
Re: There is nothing cooler than a macr- Err… Mixin?
On 7/21/12 3:00 PM, Kajetan Rzepecki wrote: On Saturday, 21 July 2012 at 16:42:55 UTC, Andrei Alexandrescu wrote: Do you know the author? That would be me. I'm very pleased both of you liked it, I didn't expect my lousy loop to get that much attention. :) Kajtek Awesome. Oh, so you're the roman numerals guy from a while ago (http://idorobots.org/2012/03/04/romans-rubies-and-the-d/) which used to crash the compiler but not anymore. Cool! Are you interested in furthering your involvement with D (e.g. the standard library)? If you lurk in here, you sure know we're on the lookout for creative, ingenious contributors. Cheers, Andrei
Re: OSCON 2012 notes
On 7/21/12 1:14 AM, Andrei Alexandrescu wrote: I'm back from OSCON 2012, where my talk has enjoyed a somewhat unexpected good reception (OSCON is not the most down-D's-alley audience). The talk abstract is at http://www.oscon.com/oscon2012/public/schedule/detail/23888 and the slides are at http://www.slideshare.net/andreialexandrescu1/generic-programming-galore-using-d. There will be a video up some time in the future for the entire talk. Slides are being discussed on reddit: http://www.reddit.com/r/programming/comments/wxjv0/generic_programming_galore_using_d/ Andrei
Re: Optional name mangling
On 21-07-2012 21:24, Stuart wrote: Hi. Is there any way to instruct the D compiler not to use name mangling when referencing an external C++ function? For example: extern (System) bool PathRenameExtension(LPSTR pszPath, LPCSTR pszExt); In this particular case, the exported function being referenced is not called _PathRenameExtension@8 - it's just called PathRenameExtension. Now, it's great that D helpfully mangles the name for me when appropriate, but we really need some way to disable it when necessary. Is there any way to import this function without creating a .def file with "_PathRenameExtension@8 = PathRenameExtension"? And if not, why not? Shouldn't you be using extern (Windows) ? -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: OSCON 2012 notes
On 21-07-2012 21:51, Nick Sabalausky wrote: On Sat, 21 Jul 2012 09:47:06 -0400 Michel Fortin wrote: And also, more and more it'd require ARM support to be competitive in the GUI area. Yes. But there's an even bigger reason for ARM: Mobile devices, like iOS and Android. I'm not personally a fan of them, but nonetheless those things are HUGE (no pun intended). And yet the ONLY real language choices there are C++, Java and Objective-C (and Lua if you count "Son-of-Flash", ie Corona - which I don't count). And half of THOSE are out of the question if you want cross platform, which any sane developer should. So PERFECT fertile ground for D. ... and C# ;) I know I keep harping on that, but it's a big issue for me since I'm deep into that stuff now and goddamn do I wish I could be doing it in D, but D's support on those devices (or just outputting C/C++) unfortunately just isn't mature enough ATM. GDC is pretty far along as far as ARM support goes; I intend to have another run through it one of these days to look at any remaining issues. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: Optional name mangling
On Saturday, July 21, 2012 21:56:36 Alex Rønne Petersen wrote: > On 21-07-2012 21:24, Stuart wrote: > > Hi. Is there any way to instruct the D compiler not to use name mangling > > when referencing an external C++ function? > > > > For example: > > extern (System) bool PathRenameExtension(LPSTR pszPath, LPCSTR > > pszExt); > > > > In this particular case, the exported function being referenced is not > > called _PathRenameExtension@8 - it's just called PathRenameExtension. > > Now, it's great that D helpfully mangles the name for me when > > appropriate, but we really need some way to disable it when necessary. > > > > Is there any way to import this function without creating a .def file > > with "_PathRenameExtension@8 = PathRenameExtension"? And if not, why not? > > Shouldn't you be using extern (Windows) ? extern(System) should be fine in that it's the same as extern(Windows) on Windows, but since it's a Windows-specific function, it probably _should_ be using extern(Windows). Of course, since PathRenameExtensions does what std.path.setExtension does, it would probably be better to just use that, but the OP's question _does_ apply to other functions which may not have D replacements, so the question is still relevant. - Jonathan M Davis
Re: Preview LLVM Deimos bindings
Bernard Helyer wrote: > On Saturday, 21 July 2012 at 15:30:46 UTC, Jens Mueller wrote: > >Bernard Helyer wrote: > >>Very interesting. I'd be interested in making some D Native > >>feeling > >>bindings, because the LLVM C bindings are A, inconsistent, and > >>B, > >>complete shit. So this is interesting. > > > >Building a better wrapper on top of these would be nice. > >Can you give examples for A and B? > > > >Jens > > > The verbs used change from function to function. > I can't remember any off the top of my head, but I run into bunch > when > using it for SDC. > > As to B, they're incomplete, undocumented, and awkward to use. I see. Maybe they will improve. > No reflection on your fine work, of course. :) Yeah. I just translated those header files. I haven't written them. Jens
Re: There is nothing cooler than a macr- Err… Mixin?
On Saturday, 21 July 2012 at 19:53:09 UTC, Andrei Alexandrescu wrote: Awesome. Oh, so you're the roman numerals guy from a while ago (http://idorobots.org/2012/03/04/romans-rubies-and-the-d/) which used to crash the compiler but not anymore. Cool! Are you interested in furthering your involvement with D (e.g. the standard library)? If you lurk in here, you sure know we're on the lookout for creative, ingenious contributors. Cheers, Andrei If anything I do is deemed useful I sure wouldn't mind adding it to the standard library, however, my general "hacking about" tends to be rather far from useful ;) I'm probably going to expand on the idea behind the Loop template and create a set of functions for use with D code generation (so DSLs mainly) as it seems to be a little tedious at the moment. By the way, I've managed to crash the compiler once or twice with the Loop template on my way here ;) I have yet to find a minimal test case for that, tho.
Re: OSCON 2012 notes
On Sat, 21 Jul 2012 01:14:57 -0400 Andrei Alexandrescu wrote: > I'm back from OSCON 2012, where my talk has enjoyed a somewhat > unexpected good reception (OSCON is not the most down-D's-alley > audience). > > The talk abstract is at > http://www.oscon.com/oscon2012/public/schedule/detail/23888 and the > slides are at > http://www.slideshare.net/andreialexandrescu1/generic-programming-galore-using-d. > > There will be a video up some time in the future for the entire talk. > Great stuff! It's a perfect way of explaining why D kicks so much ass. Side note though: Seriously, no download with registration?!? WTF > A small framework or simply a couple of standard > library components that would make e.g. Vladimir's work (on > forum.lang.org) or Adam Ruppe's work easy to assemble from > preexisting parts would be just awesome. > What do you mean by "make it easy to assemble Vladimir's and Adam's web libraries from preexisting parts"? A couple months ago I had a little bit of free time and used it to work on a custom...uhh...*cough* "not-a-blog" system I've been putting together for myself. I used the combination of: - Vibe.d's CGI library and HTTP server - simendsjo's fork of Steve Teale's native MySQL library: https://github.com/simendsjo/mysqln/tree/misc-cleanups (Actually, I think this is included in Vibe.d now?) - Adam's HTML DOM (And I cached partial and full results in memory, of course, so I wasn't DOMming it up on every request) It was working out BEAUTIFULLY for me, at least until I ran out of free time and had to leave it unfinished :(
Re: There is nothing cooler than a macr- Err… Mixin?
On Sat, 21 Jul 2012 22:17:37 +0200 "Kajetan Rzepecki" wrote: > > By the way, I've managed to crash the compiler once or twice with > the Loop template on my way here ;) > I have yet to find a minimal test case for that, tho. DustMite can help with that: https://github.com/CyberShadow/DustMite/wiki
Re: OSCON 2012 notes
On Sat, 21 Jul 2012 16:17:00 -0400 Nick Sabalausky wrote: > On Sat, 21 Jul 2012 01:14:57 -0400 > Andrei Alexandrescu wrote: > > > I'm back from OSCON 2012, where my talk has enjoyed a somewhat > > unexpected good reception (OSCON is not the most down-D's-alley > > audience). > > > > The talk abstract is at > > http://www.oscon.com/oscon2012/public/schedule/detail/23888 and the > > slides are at > > http://www.slideshare.net/andreialexandrescu1/generic-programming-galore-using-d. > > > > There will be a video up some time in the future for the entire > > talk. > > > > Great stuff! It's a perfect way of explaining why D kicks so much ass. > > Side note though: Seriously, no download with registration?!? WTF > s/with/without/
Re: OSCON 2012 notes
On Sat, 21 Jul 2012 21:59:12 +0200 Alex Rønne Petersen wrote: > On 21-07-2012 21:51, Nick Sabalausky wrote: > > On Sat, 21 Jul 2012 09:47:06 -0400 > > Michel Fortin wrote: > >> > >> And also, more and more it'd require ARM support to be competitive > >> in the GUI area. > >> > > > > Yes. But there's an even bigger reason for ARM: Mobile devices, like > > iOS and Android. I'm not personally a fan of them, but nonetheless > > those things are HUGE (no pun intended). And yet the ONLY real > > language choices there are C++, Java and Objective-C (and Lua if > > you count "Son-of-Flash", ie Corona - which I don't count). And > > half of THOSE are out of the question if you want cross platform, > > which any sane developer should. So PERFECT fertile ground for D. > > ... and C# ;) > Oh, yea. I assume you're referring to Unity, right? > > > > I know I keep harping on that, but it's a big issue for me since I'm > > deep into that stuff now and goddamn do I wish I could be doing > > it in D, but D's support on those devices (or just outputting C/C++) > > unfortunately just isn't mature enough ATM. > > > > GDC is pretty far along as far as ARM support goes; I intend to have > another run through it one of these days to look at any remaining > issues. > That is encouraging to hear :) What about druntime and phobos, though? And what about D feature set, is it up to 2.059? I wonder if maybe I could somehow tell Marmalade's annoying proprietary build system to pass in some extra object files to the linker? I'll have to ask on their forums. Because maybe then I could compile some stuff with GDC and link it in.
Re: OSCON 2012 notes
On 21-07-2012 22:26, Nick Sabalausky wrote: On Sat, 21 Jul 2012 21:59:12 +0200 Alex Rønne Petersen wrote: On 21-07-2012 21:51, Nick Sabalausky wrote: On Sat, 21 Jul 2012 09:47:06 -0400 Michel Fortin wrote: And also, more and more it'd require ARM support to be competitive in the GUI area. Yes. But there's an even bigger reason for ARM: Mobile devices, like iOS and Android. I'm not personally a fan of them, but nonetheless those things are HUGE (no pun intended). And yet the ONLY real language choices there are C++, Java and Objective-C (and Lua if you count "Son-of-Flash", ie Corona - which I don't count). And half of THOSE are out of the question if you want cross platform, which any sane developer should. So PERFECT fertile ground for D. ... and C# ;) Oh, yea. I assume you're referring to Unity, right? Nah, more of a shameless plug: http://xamarin.com/ (I work for Xamarin ;)) I know I keep harping on that, but it's a big issue for me since I'm deep into that stuff now and goddamn do I wish I could be doing it in D, but D's support on those devices (or just outputting C/C++) unfortunately just isn't mature enough ATM. GDC is pretty far along as far as ARM support goes; I intend to have another run through it one of these days to look at any remaining issues. That is encouraging to hear :) What about druntime and phobos, though? And what about D feature set, is it up to 2.059? GDC is up to DMD FE 2.059, so as far as the language goes, D on ARM should be up to date. Phobos should already build on ARM as-is (I sent some ARM patches upstream recently, too). druntime might need tweaking for some recent changes in in the threading/GC infrastructure, but I'll have to investigate further to see what the state is. I'll probably get around to that on Monday. I wonder if maybe I could somehow tell Marmalade's annoying proprietary build system to pass in some extra object files to the linker? I'll have to ask on their forums. Because maybe then I could compile some stuff with GDC and link it in. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: OSCON 2012 notes
On Saturday, 21 July 2012 at 16:45:20 UTC, Andrei Alexandrescu wrote: Would you agree if someone took your code, modified it for the purposes of passing it through the forks of the review process, and pushed it into Phobos? Yes, no problem at all. You'd still receive credit, of course, but it would be shared with that person or group because that's significant work. That's why I haven't done it myself yet! It is in a state where it works for me and the phobos cost is just too high in my current situation.
Re: OSCON 2012 notes
On Saturday, 21 July 2012 at 20:17:11 UTC, Nick Sabalausky wrote: - Adam's HTML DOM (And I cached partial and full results in memory, of course, so I wasn't DOMming it up on every request) DOMing it up every request rox. That's what I do and so far the impact of those have been negligible in the profiling.
Re: Just where has this language gone wrong?
Let me just add, I really *like* the terse syntax of D. Lambdas, uniform function call syntax, and so on. Although the most important difference between C++ and D, in my opinion, is the absence of the damn #include statement!! That archaic assembly-language-inspired way of cramming billions of lines of code into a single text document; then compiling it; and then bitching about redefined symbols and incompatibilities between headers has caused me more hours of hair-tearing frustration than any single other language "feature". Garbage-collection I can live without. Closures, properties and events I really miss when they're not available. But header files were the single worst thing to ever befall coders.
Re: Optional name mangling
On Saturday, 21 July 2012 at 19:56:37 UTC, Alex Rønne Petersen wrote: Shouldn't you be using extern (Windows) ? Yeah. I changed it to (System) in the hope it'd try *not* mangling the name; and didn't bother changing it back when I discovered it didn't help. The language (which, let me say, is looking pretty damn good!) really, desperately needs an "extern(C)" keyword. I mean, like, yesterday!
Re: Optional name mangling
On Saturday, 21 July 2012 at 20:07:00 UTC, Jonathan M Davis wrote: Of course, since PathRenameExtensions does what std.path.setExtension does, it would probably be better to just use that, but the OP's question _does_ apply to other functions which may not have D replacements, so the question is still relevant. I didn't know about std.path.setExtension. Is there some kind of table where I can look up D equivalents to API function calls? In any event, yes, my question is still relevant. What if I want to call some other API function? Or OpenGL? Or something I wrote in C++ with "extern(C)" linkage? (Something I do from time to time)
Re: Optional name mangling
On Saturday, 21 July 2012 at 21:17:17 UTC, Stuart wrote: The language (which, let me say, is looking pretty damn good!) really, desperately needs an "extern(C)" keyword. I mean, like, yesterday! extern(C) exists … and we couldn't even have made it to "yesterday" without it. David
Re: Optional name mangling
On Saturday, 21 July 2012 at 21:17:17 UTC, Stuart wrote: On Saturday, 21 July 2012 at 19:56:37 UTC, Alex Rønne Petersen wrote: Shouldn't you be using extern (Windows) ? Yeah. I changed it to (System) in the hope it'd try *not* mangling the name; and didn't bother changing it back when I discovered it didn't help. The language (which, let me say, is looking pretty damn good!) really, desperately needs an "extern(C)" keyword. I mean, like, yesterday! D already has extern(C).
Re: Optional name mangling
On Saturday, July 21, 2012 23:18:46 Stuart wrote: > On Saturday, 21 July 2012 at 20:07:00 UTC, Jonathan M Davis wrote: > > Of course, since PathRenameExtensions does what > > std.path.setExtension does, it > > would probably be better to just use that, but the OP's > > question _does_ apply > > to other functions which may not have D replacements, so the > > question is still > > relevant. > > I didn't know about std.path.setExtension. Is there some kind of > table where I can look up D equivalents to API function calls? No. If you want to know what's there, you need to look at the documentation. For the most part, the module names are reasonbly well named after what they do, so you should be able to figure out what module contains the functionality you're looking for without too much difficulty. As for this case, Path-related stuff goes in std.path, stuff that operates on a file as a whole is in std.file, and stuff that involves more general I/O (including reading a file in pieces) is in std.stdio. - Jonathan M Davis
Re: Optional name mangling
On Saturday, July 21, 2012 23:17:16 Stuart wrote: > On Saturday, 21 July 2012 at 19:56:37 UTC, Alex Rønne Petersen > > wrote: > > Shouldn't you be using extern (Windows) ? > > Yeah. I changed it to (System) in the hope it'd try *not* > mangling the name; and didn't bother changing it back when I > discovered it didn't help. > > The language (which, let me say, is looking pretty damn good!) > really, desperately needs an "extern(C)" keyword. I mean, like, > yesterday! http://dlang.org/interfaceToC.html http://dlang.org/cpp_interface.html http://dlang.org/htomodule.html - Jonathan M Davis
Time for std.reflection
Walter and I discussed the idea below a long time (years) ago. Most
likely it's also been discussed in this newsgroup a couple of times.
Given the state of the compiler back then, back then it seemed like a
super cool idea that's entirely realizable, it would just take time for
the compiler to become as capable as needed. Nowadays we're in shape to
tackle it.
Here "it" is.
Back when runtime reflection was being discussed, my response was "let's
focus on compile-time reflection, and then we can do run-time reflection
on demand as a library". Though this might sound sensible, I initially
didn't have a design. Now here's what we can do.
Currently we have information about symbols as __traits(...) intrinsics
wrapped in nice but scattered ways. Now that CTFE is good enough to
manipulate structs and arrays thereof, we have the possibility to
finally approach things in a nicely unified, structured way.
First, we need to prime std.reflection with a few abstractions that
characterize entities in a D program.
class ModuleInfo {
@property:
string name();
ImportInfo[] imports();
DataInfo[] data();
FunctionInfo[] functions();
ClassInfo[] classes();
StructInfo[] structs(); // includes unions
TemplateInfo[] templates();
EnumInfo[] enums();
bool hasStaticCtor(), hasStaticDtor(),
hasSharedCtor(), hasSharedDtor();
}
Probably there are a few more pieces of data, but you get the idea. Then
for each of the entities mentioned above we have a similar definition.
For example:
enum Protection { isPublic, isPackage, isProtected, isPrivate }
class ClassInfo {
@property:
string name();
string baseName();
string parentName(); // if applicable, null otherwise
string[] interfaces();
bool isShared();
Protection protection();
DataMemberInfo[] data();
MethodInfo[] methods();
Object defaultConstructor();
...
}
Then for an e.g. method declaration we'd have:
class MethodInfo {
@property:
string name();
bool isStatic(), isFinal(), isOverride();
Protection protection();
string[] parameterTypes();
string[] parameterNames();
}
Some details may vary, e.g. some may be straight members instead of
properties etc. (I used properties to allude to use of lazy gathering of
information).
So so far we have a nice collection of structured data associated with
the entities in a D program. Note how this structuring differs yet has
similar power to the primitives in std.traits; std.traits offers
unstructured bits of information on demand (e.g. ParameterTypeNames)
etc. but the objects above group information together per entity
declared. All of the above goes in std.reflection, of course.
===
On to primitives that return such data.
Given that D can (since relatively recently) create and manipulate class
objects during compilation too, it follows that the classes above can be
accessed in two ways - through compile-time API and run-time API. When
possible, the APIs may even use the same functions; some other times
they will be necessarily different.
There are two possible approaches to discovering such information. One
is by fetching the ModuleInfo for the whole module and navigating it.
Another one is by using search primitives from strings.
So we should have e.g.
// inside std.reflection
ModuleInfo getModuleInfo(string moduleName);
so a CT call would go like:
// client code
static info = getModuleInfo("std.algorithm");
whereas a run-time call would be:
// client code
auto info = getModuleInfo("std.algorithm");
In the latter case, the module needs to save all needed information for
ri, so it should plant this:
// inside std.algorithm
mixin(makeModuleInfoAvailableDynamically());
The mixin would generate all information needed and would store it for
later dynamic use.
A search API would go like e.g.
ClassInfo getClassInfo(string className);
In this case the class name could be qualified with module information etc.
===
With this design we unify compile-time and run-time type manipulation in
simple ways, by defining structured information about declarations that
can be queried during compilation or dynamically.
Please chime in with thoughts. Would someone want to pioneer this project?
Andrei
Re: OSCON 2012 notes
On 7/21/12 3:59 PM, Alex Rønne Petersen wrote: GDC is pretty far along as far as ARM support goes; I intend to have another run through it one of these days to look at any remaining issues. That's awesome. I got a feel at OSCON that a combination of big iron + ARM-based small devices is the most popular combo going forward. Andrei
Re: OSCON 2012 notes
On 7/21/12 4:17 PM, Nick Sabalausky wrote: Side note though: Seriously, no download with registration?!? WTF Crap. Didn't know, otherwise I might've chosen differently. Andrei
Re: OSCON 2012 notes
On 7/21/12 4:17 PM, Nick Sabalausky wrote: What do you mean by "make it easy to assemble Vladimir's and Adam's web libraries from preexisting parts"? I mean putting much of their work in std, such that people can write their own Web/NNTP/CGI/etc stuff with much less code than they had to write. A couple months ago I had a little bit of free time and used it to work on a custom...uhh...*cough* "not-a-blog" system I've been putting together for myself. I used the combination of: - Vibe.d's CGI library and HTTP server - simendsjo's fork of Steve Teale's native MySQL library: https://github.com/simendsjo/mysqln/tree/misc-cleanups (Actually, I think this is included in Vibe.d now?) - Adam's HTML DOM (And I cached partial and full results in memory, of course, so I wasn't DOMming it up on every request) It was working out BEAUTIFULLY for me, at least until I ran out of free time and had to leave it unfinished :( A feeling experienced by me all too often. My point is instead of having people buy these batteries, charging them by hand, and connecting them via diodes, to integrate the batteries with std. Andrei
Re: Time for std.reflection
On Saturday, July 21, 2012 17:44:51 Andrei Alexandrescu wrote: > With this design we unify compile-time and run-time type manipulation in > simple ways, by defining structured information about declarations that > can be queried during compilation or dynamically. > > Please chime in with thoughts. Are you proposing that we replace std.traits or that std.reflection be built on top of it? Having std.reflection will be awesome for a lot of stuff - particularly the more complicated stuff - and would be a great addition to Phobos, but it seems like overkill for a lot of basic template constraints, so I wouldn't want to see it replace std.traits. - Jonathan M Davis
Re: Time for std.reflection
On 7/21/12 5:51 PM, Jonathan M Davis wrote: On Saturday, July 21, 2012 17:44:51 Andrei Alexandrescu wrote: With this design we unify compile-time and run-time type manipulation in simple ways, by defining structured information about declarations that can be queried during compilation or dynamically. Please chime in with thoughts. Are you proposing that we replace std.traits or that std.reflection be built on top of it? On top. std.reflection would be a complete reflection solution, whereas std.traits gives casual type traits as needed. Having std.reflection will be awesome for a lot of stuff - particularly the more complicated stuff - and would be a great addition to Phobos, but it seems like overkill for a lot of basic template constraints, so I wouldn't want to see it replace std.traits. My thoughts exactly. Andrei
Re: Time for std.reflection
On Sat, 21 Jul 2012 14:51:30 -0700, Jonathan M Davis wrote: On Saturday, July 21, 2012 17:44:51 Andrei Alexandrescu wrote: With this design we unify compile-time and run-time type manipulation in simple ways, by defining structured information about declarations that can be queried during compilation or dynamically. Please chime in with thoughts. Are you proposing that we replace std.traits or that std.reflection be built on top of it? Having std.reflection will be awesome for a lot of stuff - particularly the more complicated stuff - and would be a great addition to Phobos, but it seems like overkill for a lot of basic template constraints, so I wouldn't want to see it replace std.traits. - Jonathan M Davis I too would want it in a different module But my read of Andrei's proposal is that it would be. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: Time for std.reflection
On 2012-07-21 21:44:51 +, Andrei Alexandrescu said: Please chime in with thoughts. Unifying runtime and compile-time reflection is a good idea, in theory at least. At least it'd make compile-time reflection easier. But when I think about the use case, unification the way you're proposing doesn't seem that great. If you need runtime reflection in one class, you probably need it on all the derived classes too. That's the real problem runtime reflection solves: it allows you to know something about the subclasses you might otherwise not know about (because your code only know the base class). So to make runtime reflection not a hassle, the thing that generates the runtime reflection info should be inherited somehow. The other thing is: you very rarely need runtime reflection of everything. Especially, why would you ever need runtime reflection for a struct, where all the reflected info is available at compile time? And why create info for all fields and methods in a class in a case where all you need to get at is a pair of serialize/unserialize functions? -- Michel Fortin michel.for...@michelf.ca http://michelf.ca/
Re: Just where has this language gone wrong?
On Sat, 21 Jul 2012 23:14:12 +0200 "Stuart" wrote: > Let me just add, I really *like* the terse syntax of D. Lambdas, > uniform function call syntax, and so on. > Yea. I used Java in college and ever since then I've been a fan of non-verbose systax - ie syntax that's the *opposite* of Java ;) > > Garbage-collection I can live without. Closures, properties and > events I really miss when they're not available. But header files > were the single worst thing to ever befall coders. I agree, a proper module system was one of the first, biggest things that drew me to D - It was one of the handful of things Java actually got *right* compared to C++ (another big one being reference semantics for classes). When I use C++, a proper module system is one of the biggest things I miss. Aside from the issues you mention, there's another big benefit to killing off the #include system and switching to D: Type names and other identifiers aren't cluttered up with the noise of a make-shift module system. (Yea, there's namespaces, but not everyone seems to use them. I assume there's probably good reasons for that...besides easier integration with D ;) ) For example, I'm using the IwGame C++ library ( http://www.drmop.com/index.php/iwgame-engine/ ) and fucking *EVERY* type name is prefixed with "CIwGame...". And anything from the underlying Marmalade starts with "CIw..." so basic vectors are named convoluted shit like "CIwFVec2". Of course, this is on top of the fact that until C++11 becomes more widespread there isn't a damn bit of type inference anywhere, so those horrific full names have to be used EVERYWHERE. With a proper module system like D's, there'd be no problem with names like "ImageActor" and "FVec2" instead of "CIwGameImageActor" and "CIwFVec2", because conflicts could be easily detected and dealt with. And of course the other real obvious benefit of killing #include: None of that separate cpp/h file bullshit. C++ is living in the 70's. It should have a mascot wearing a leisure suit.
Re: Just where has this language gone wrong?
On 7/21/12 6:16 PM, Nick Sabalausky wrote: Yea. I used Java in college and ever since then I've been a fan of non-verbose systax - ie syntax that's the *opposite* of Java ;) On slide 19 of the OSCON slides there's this sample: auto s = ["abc", "a", "xz"]; auto m = s.argmin!((x) => x.length); People in the audience were quite pleasantly surprised to figure that although there's no mention of a type, that code is all the compiler needs to figure there's a lambda that takes a string and returns an unsigned integer etc. Andrei
Re: Optional name mangling
On Saturday, 21 July 2012 at 21:25:29 UTC, JImmy Cao wrote: On Saturday, 21 July 2012 at 21:17:17 UTC, Stuart wrote: On Saturday, 21 July 2012 at 19:56:37 UTC, Alex Rønne Petersen wrote: Shouldn't you be using extern (Windows) ? Yeah. I changed it to (System) in the hope it'd try *not* mangling the name; and didn't bother changing it back when I discovered it didn't help. The language (which, let me say, is looking pretty damn good!) really, desperately needs an "extern(C)" keyword. I mean, like, yesterday! D already has extern(C). Well, yes and no: extern (C) bool PathRenameExtension(LPSTR pszPath, LPCSTR pszExt); Attempts to bind to a function called _PathRenameExtension. Which is, naturally, of no use whatsoever.
Re: Optional name mangling
On Saturday, 21 July 2012 at 21:21:41 UTC, David Nadlinger wrote: extern(C) exists … and we couldn't even have made it to "yesterday" without it. Yes, but it prepends "_" to the function name.
Re: Optional name mangling
On Saturday, 21 July 2012 at 22:38:32 UTC, Stuart wrote: Attempts to bind to a function called _PathRenameExtension. Which is, naturally, of no use whatsoever. That is the norm on Windows though: http://en.wikipedia.org/wiki/Name_mangling#C_name_decoration_in_Microsoft_Windows If you're using implib on a DLL to make a .lib for D though, the /S switch might help: http://www.digitalmars.com/ctg/implib.html "Prepend '_' to exported internal names."
Re: Just where has this language gone wrong?
On Sat, 21 Jul 2012 18:24:04 -0400 Andrei Alexandrescu wrote: > On 7/21/12 6:16 PM, Nick Sabalausky wrote: > > Yea. I used Java in college and ever since then I've been a fan of > > non-verbose systax - ie syntax that's the *opposite* of Java ;) > > On slide 19 of the OSCON slides there's this sample: > > auto s = ["abc", "a", "xz"]; > auto m = s.argmin!((x) => x.length); > > People in the audience were quite pleasantly surprised to figure that > although there's no mention of a type, that code is all the compiler > needs to figure there's a lambda that takes a string and returns an > unsigned integer etc. > Exactly. And what many people (depressingly) don't realize, is that dynamic typing (or OO boxing) is NOT needed to achieve that. I was actually impressed with that slide, too, but for a different reason: I've come across need for a function like argmin on occasion, but I didn't know it existed (Don't recall if it was actually in D, may have been another language I was using). That really is a fantastically useful function.
Incorrect warning: use '{ }' for an empty statement, not a ';'
The following code -
void STOP() { asm { int 3; }; }
- generates the warning:
Incorrect warning: use '{ }' for an empty statement, not a ';'
That's wrong, yeah?
Re: Incorrect warning: use '{ }' for an empty statement, not a ';'
On Saturday, 21 July 2012 at 22:53:25 UTC, Alex Rønne Petersen
wrote:
On 22-07-2012 00:52, Stuart wrote:
The following code -
void STOP() { asm { int 3; }; }
- generates the warning:
Incorrect warning: use '{ }' for an empty statement, not a
';'
That's wrong, yeah?
No. Drop the semicolon after the curly brace.
Ah. Silly me.
Re: OSCON 2012 notes
On Sat, 21 Jul 2012 14:41:05 +0200 Paulo Pinto wrote: > > Regarding systems programming, Go could actually play in the same > league as D [...] > The trick with Oberon, which Go also uses, is to have a special module > reckognised by the compiler with primitives to do the low tricks C > offers. Additionaly any function/method without body can be > implemented in Assembly. This is nothing new, Modula-2 already worked > like this. > If a language has to resort to such "outside-of-the-language" tricks like that to do system software, then it's just simply not a systems language. If that meant Go^H^HIssue 9 could play in the same systems league as D, then scripting languages like Lua or JavaScript or even VBScript would qualify, too.
Re: OSCON 2012 notes
On Saturday, July 21, 2012 19:13:20 Nick Sabalausky wrote: > On Sat, 21 Jul 2012 14:41:05 +0200 > > Paulo Pinto wrote: > > Regarding systems programming, Go could actually play in the same > > league as D > > [...] > > > The trick with Oberon, which Go also uses, is to have a special module > > reckognised by the compiler with primitives to do the low tricks C > > offers. Additionaly any function/method without body can be > > implemented in Assembly. This is nothing new, Modula-2 already worked > > like this. > > If a language has to resort to such "outside-of-the-language" tricks > like that to do system software, then it's just simply not a systems > language. I tend to agree. However, it's my understanding that when the Go folks talk about Go being a "systems language," they mean that it's meant for building large systems, not that it's meant for writing low-level stuff like kernels, which is what C++ and D mean when they call themselves systems languages. So, I believe that the core problem here is that the term is being used differently by different languages rather than Go claiming that they're a systems language in the C++/D sense when they have to rosert to outside of the language tricks. But I could be wrong about what they mean. - Jonathan M Davis
Re: Optional name mangling
On Saturday, 21 July 2012 at 22:51:14 UTC, Adam D. Ruppe wrote: On Saturday, 21 July 2012 at 22:38:32 UTC, Stuart wrote: Attempts to bind to a function called _PathRenameExtension. Which is, naturally, of no use whatsoever. That is the norm on Windows though: Granted. But not everyone's exported functions are prefixed with an underscore. I've written DLLs myself using __dllexport, and they've been named normally. It'd just be helpful to have the option, y'know? If you're using implib on a DLL to make a .lib for D though, the /S switch might help: http://www.digitalmars.com/ctg/implib.html "Prepend '_' to exported internal names." I'm sorry, but the /S (or /system) switch doesn't seem to do anything. I still get non-underscore-prefixed output in my .lib file. I opened it in a hex editor to verify this; and D says "Error 42: Symbol Undefined _PathRenameExtension". Do I need a different copy of implib, maybe? When I call it with /?, I get: --- Digital Mars Import Library Manager Version 7.6B1n Copyright (C) Digital Mars 2000. All Rights Reserved. Usage: IMPLIB [switches] implibname.lib [ file.dll | file.def ] switches: /? Print this message /b Batch /h Print this message /i Ignore case of symbols /noiBe case sensitive. Mark library as case sensitive /nowep Ignore WEP /p:number Set page size to number (a power of 2) /system Prepend '_' to exported internal names (NT system DLL) ---
Re: Time for std.reflection
I agree with most things proposed, however I am not a fan of the idea of mixing in runtime reflection info. Many times, you want reflection info from a type that is not your own, and thus I believe reflection should be generated by specifying a type. More importantly, a method should exist for recursively generating reflection info. Also, I'd like to see a hierarchal approach to reflection data. The main advantage to std.reflection would be being able to use it at run-time, at which point we can't simply rely on templates, and instead if we want to store something we must rely on a base type. I think the best approach would be a hierarchal system where all reflection data derives from MemberInfo. My ideal API would like something like: https://workflowy.com/shared/62d4f791-e397-a86d-c018-09eab98b9927/
Re: Time for std.reflection
On 7/21/12 8:16 PM, Kapps wrote:
I agree with most things proposed, however I am not a fan of the idea of
mixing in runtime reflection info. Many times, you want reflection info
from a type that is not your own, and thus I believe reflection should
be generated by specifying a type. More importantly, a method should
exist for recursively generating reflection info.
I confess I have trouble understanding each of the sentences above.
Also, I'd like to see a hierarchal approach to reflection data. The main
advantage to std.reflection would be being able to use it at run-time,
at which point we can't simply rely on templates, and instead if we want
to store something we must rely on a base type.
At no place in the proposed approach is the use of templates required or
needed.
I think the best
approach would be a hierarchal system where all reflection data derives
from MemberInfo. My ideal API would like something like:
https://workflowy.com/shared/62d4f791-e397-a86d-c018-09eab98b9927/
I cringed at
MemberType -> { Module, Type, Field, Method, Parameter }
I was hoping to get away from slapping tagging on types just for the
sake of using inheritance.
Andrei
Re: Time for std.reflection
On 21-07-2012 23:44, Andrei Alexandrescu wrote:
Walter and I discussed the idea below a long time (years) ago. Most
likely it's also been discussed in this newsgroup a couple of times.
Given the state of the compiler back then, back then it seemed like a
super cool idea that's entirely realizable, it would just take time for
the compiler to become as capable as needed. Nowadays we're in shape to
tackle it.
Here "it" is.
Back when runtime reflection was being discussed, my response was "let's
focus on compile-time reflection, and then we can do run-time reflection
on demand as a library". Though this might sound sensible, I initially
didn't have a design. Now here's what we can do.
Currently we have information about symbols as __traits(...) intrinsics
wrapped in nice but scattered ways. Now that CTFE is good enough to
manipulate structs and arrays thereof, we have the possibility to
finally approach things in a nicely unified, structured way.
First, we need to prime std.reflection with a few abstractions that
characterize entities in a D program.
class ModuleInfo {
@property:
string name();
ImportInfo[] imports();
DataInfo[] data();
FunctionInfo[] functions();
ClassInfo[] classes();
StructInfo[] structs(); // includes unions
TemplateInfo[] templates();
EnumInfo[] enums();
bool hasStaticCtor(), hasStaticDtor(),
hasSharedCtor(), hasSharedDtor();
}
Probably there are a few more pieces of data, but you get the idea. Then
for each of the entities mentioned above we have a similar definition.
For example:
enum Protection { isPublic, isPackage, isProtected, isPrivate }
class ClassInfo {
@property:
string name();
string baseName();
string parentName(); // if applicable, null otherwise
string[] interfaces();
bool isShared();
Protection protection();
DataMemberInfo[] data();
MethodInfo[] methods();
Object defaultConstructor();
...
}
Then for an e.g. method declaration we'd have:
class MethodInfo {
@property:
string name();
bool isStatic(), isFinal(), isOverride();
Protection protection();
string[] parameterTypes();
string[] parameterNames();
}
Some details may vary, e.g. some may be straight members instead of
properties etc. (I used properties to allude to use of lazy gathering of
information).
So so far we have a nice collection of structured data associated with
the entities in a D program. Note how this structuring differs yet has
similar power to the primitives in std.traits; std.traits offers
unstructured bits of information on demand (e.g. ParameterTypeNames)
etc. but the objects above group information together per entity
declared. All of the above goes in std.reflection, of course.
===
On to primitives that return such data.
Given that D can (since relatively recently) create and manipulate class
objects during compilation too, it follows that the classes above can be
accessed in two ways - through compile-time API and run-time API. When
possible, the APIs may even use the same functions; some other times
they will be necessarily different.
There are two possible approaches to discovering such information. One
is by fetching the ModuleInfo for the whole module and navigating it.
Another one is by using search primitives from strings.
So we should have e.g.
// inside std.reflection
ModuleInfo getModuleInfo(string moduleName);
so a CT call would go like:
// client code
static info = getModuleInfo("std.algorithm");
whereas a run-time call would be:
// client code
auto info = getModuleInfo("std.algorithm");
In the latter case, the module needs to save all needed information for
ri, so it should plant this:
// inside std.algorithm
mixin(makeModuleInfoAvailableDynamically());
The mixin would generate all information needed and would store it for
later dynamic use.
A search API would go like e.g.
ClassInfo getClassInfo(string className);
In this case the class name could be qualified with module information etc.
===
With this design we unify compile-time and run-time type manipulation in
simple ways, by defining structured information about declarations that
can be queried during compilation or dynamically.
Please chime in with thoughts. Would someone want to pioneer this project?
Andrei
I'm just curious about one thing: How do you plan to reify templates
(they are Turing complete after all)?
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
Re: Time for std.reflection
On 21/07/2012 23:44, Andrei Alexandrescu wrote:
Walter and I discussed the idea below a long time (years) ago. Most
likely it's also been discussed in this newsgroup a couple of times.
Given the state of the compiler back then, back then it seemed like a
super cool idea that's entirely realizable, it would just take time for
the compiler to become as capable as needed. Nowadays we're in shape to
tackle it.
Here "it" is.
Back when runtime reflection was being discussed, my response was "let's
focus on compile-time reflection, and then we can do run-time reflection
on demand as a library". Though this might sound sensible, I initially
didn't have a design. Now here's what we can do.
Currently we have information about symbols as __traits(...) intrinsics
wrapped in nice but scattered ways. Now that CTFE is good enough to
manipulate structs and arrays thereof, we have the possibility to
finally approach things in a nicely unified, structured way.
First, we need to prime std.reflection with a few abstractions that
characterize entities in a D program.
class ModuleInfo {
@property:
string name();
ImportInfo[] imports();
DataInfo[] data();
FunctionInfo[] functions();
ClassInfo[] classes();
StructInfo[] structs(); // includes unions
TemplateInfo[] templates();
EnumInfo[] enums();
bool hasStaticCtor(), hasStaticDtor(),
hasSharedCtor(), hasSharedDtor();
}
Probably there are a few more pieces of data, but you get the idea. Then
for each of the entities mentioned above we have a similar definition.
For example:
enum Protection { isPublic, isPackage, isProtected, isPrivate }
class ClassInfo {
@property:
string name();
string baseName();
string parentName(); // if applicable, null otherwise
string[] interfaces();
bool isShared();
Protection protection();
DataMemberInfo[] data();
MethodInfo[] methods();
Object defaultConstructor();
...
}
Then for an e.g. method declaration we'd have:
class MethodInfo {
@property:
string name();
bool isStatic(), isFinal(), isOverride();
Protection protection();
string[] parameterTypes();
string[] parameterNames();
}
Some details may vary, e.g. some may be straight members instead of
properties etc. (I used properties to allude to use of lazy gathering of
information).
So so far we have a nice collection of structured data associated with
the entities in a D program. Note how this structuring differs yet has
similar power to the primitives in std.traits; std.traits offers
unstructured bits of information on demand (e.g. ParameterTypeNames)
etc. but the objects above group information together per entity
declared. All of the above goes in std.reflection, of course.
===
On to primitives that return such data.
Given that D can (since relatively recently) create and manipulate class
objects during compilation too, it follows that the classes above can be
accessed in two ways - through compile-time API and run-time API. When
possible, the APIs may even use the same functions; some other times
they will be necessarily different.
There are two possible approaches to discovering such information. One
is by fetching the ModuleInfo for the whole module and navigating it.
Another one is by using search primitives from strings.
So we should have e.g.
// inside std.reflection
ModuleInfo getModuleInfo(string moduleName);
so a CT call would go like:
// client code
static info = getModuleInfo("std.algorithm");
whereas a run-time call would be:
// client code
auto info = getModuleInfo("std.algorithm");
In the latter case, the module needs to save all needed information for
ri, so it should plant this:
// inside std.algorithm
mixin(makeModuleInfoAvailableDynamically());
The mixin would generate all information needed and would store it for
later dynamic use.
A search API would go like e.g.
ClassInfo getClassInfo(string className);
In this case the class name could be qualified with module information etc.
===
With this design we unify compile-time and run-time type manipulation in
simple ways, by defining structured information about declarations that
can be queried during compilation or dynamically.
Please chime in with thoughts. Would someone want to pioneer this project?
Andrei
I don't understand. Are theses structures generated by the compiler or
some kind of libraries at compile time on a per needed basis ?
Re: Time for std.reflection
On 7/21/12, Andrei Alexandrescu wrote:
> class ModuleInfo {
> @property:
> string name();
> ImportInfo[] imports();
> DataInfo[] data();
> FunctionInfo[] functions();
> ClassInfo[] classes();
> StructInfo[] structs(); // includes unions
> TemplateInfo[] templates();
> EnumInfo[] enums();
> bool hasStaticCtor(), hasStaticDtor(),
>hasSharedCtor(), hasSharedDtor();
> }
Are class/struct/function/etc templates going to be stored in the
templates field? Then you'd have to tag each template with a type,
e.g. "class template" vs "function template" to be able to filter them
out.
Otherwise classes/functions/etc could have an optional
"TemplateTypeInfo[] typeParams" field so you could filter out
templated from non-templated types by checking their typeParams field,
e.g.: auto tempClasses = filter!(a => !empty(a.typeParams)
)(modinfo.classes);
I use a similar structure to what you've defined for my code generator
and it worked out nicely for me.
Re: Optional name mangling
On Saturday, 21 July 2012 at 23:53:01 UTC, Stuart wrote: On Saturday, 21 July 2012 at 22:51:14 UTC, Adam D. Ruppe wrote: On Saturday, 21 July 2012 at 22:38:32 UTC, Stuart wrote: Attempts to bind to a function called _PathRenameExtension. Which is, naturally, of no use whatsoever. That is the norm on Windows though: Granted. But not everyone's exported functions are prefixed with an underscore. I've written DLLs myself using __dllexport, and they've been named normally. It'd just be helpful to have the option, y'know? If you're using implib on a DLL to make a .lib for D though, the /S switch might help: http://www.digitalmars.com/ctg/implib.html "Prepend '_' to exported internal names." I'm sorry, but the /S (or /system) switch doesn't seem to do anything. I still get non-underscore-prefixed output in my .lib file. I opened it in a hex editor to verify this; and D says "Error 42: Symbol Undefined _PathRenameExtension". Do I need a different copy of implib, maybe? When I call it with /?, I get: --- Digital Mars Import Library Manager Version 7.6B1n Copyright (C) Digital Mars 2000. All Rights Reserved. Usage: IMPLIB [switches] implibname.lib [ file.dll | file.def ] switches: /? Print this message /b Batch /h Print this message /i Ignore case of symbols /noiBe case sensitive. Mark library as case sensitive /nowep Ignore WEP /p:number Set page size to number (a power of 2) /system Prepend '_' to exported internal names (NT system DLL) --- Use either /s or /system
Re: OSCON 2012 notes
On Sat, Jul 21, 2012 at 5:38 PM, Jonathan M Davis wrote: > On Saturday, July 21, 2012 19:13:20 Nick Sabalausky wrote: > > On Sat, 21 Jul 2012 14:41:05 +0200 > > > > Paulo Pinto wrote: > > > Regarding systems programming, Go could actually play in the same > > > league as D > > > > [...] > > > > > The trick with Oberon, which Go also uses, is to have a special module > > > reckognised by the compiler with primitives to do the low tricks C > > > offers. Additionaly any function/method without body can be > > > implemented in Assembly. This is nothing new, Modula-2 already worked > > > like this. > > > > If a language has to resort to such "outside-of-the-language" tricks > > like that to do system software, then it's just simply not a systems > > language. > > I tend to agree. However, it's my understanding that when the Go folks talk > about Go being a "systems language," they mean that it's meant for building > large systems, not that it's meant for writing low-level stuff like > kernels, > which is what C++ and D mean when they call themselves systems languages. > So, > I believe that the core problem here is that the term is being used > differently > by different languages rather than Go claiming that they're a systems > language > in the C++/D sense when they have to rosert to outside of the language > tricks. > But I could be wrong about what they mean. > > - Jonathan M Davis > The Go people no longer refer to Go as a systems language. I believe they did intend for it to be a systems language in the same manner D is but over time they decided to focus less on that. Here's what Russ Cox said on that matter: "We removed the word 'systems' because it was too limiting. Go is more general than that. It is still a great language for writing systems." Regards, Brad Anderson
Re: Optional name mangling
On 7/22/2012 6:18 AM, Stuart wrote: In any event, yes, my question is still relevant. What if I want to call some other API function? Or OpenGL? Or something I wrote in C++ with "extern(C)" linkage? (Something I do from time to time) The Deimos project[1] provides a number of bindings to C libraries in a manner that requires compile-time linkage (using static libraries or import libraries as the case may be). Derelict[2] is a set of bindings to C libraries (including OpenGL) that loads the libraries at runtime (via LoadLibrary on Windows and dlopen elsewhere). [1] https://github.com/D-Programming-Deimos [2] https://github.com/aldacron/Derelict3
Re: Optional name mangling
On 7/22/2012 4:24 AM, Stuart wrote: Hi. Is there any way to instruct the D compiler not to use name mangling when referencing an external C++ function? For example: extern (System) bool PathRenameExtension(LPSTR pszPath, LPCSTR pszExt); In this particular case, the exported function being referenced is not called _PathRenameExtension@8 - it's just called PathRenameExtension. Now, it's great that D helpfully mangles the name for me when appropriate, but we really need some way to disable it when necessary. Is there any way to import this function without creating a .def file with "_PathRenameExtension@8 = PathRenameExtension"? And if not, why not? extern(System) is extern(Windows) on Windows and extern(C) everywhere else. extern(Windows) is stdcall, which is the Win32 API calling convention. stdcall function names are mangled to _funcName@N. So extern(System) is doing the right thing here. What's odd is that your PathRenameExtension isn't mangled.
Re: Just where has this language gone wrong?
Nick Sabalausky wrote: > On Sat, 21 Jul 2012 18:24:04 -0400 > Andrei Alexandrescu wrote: > > > On 7/21/12 6:16 PM, Nick Sabalausky wrote: > > > Yea. I used Java in college and ever since then I've been a fan of > > > non-verbose systax - ie syntax that's the *opposite* of Java ;) > > > > On slide 19 of the OSCON slides there's this sample: > > > > auto s = ["abc", "a", "xz"]; > > auto m = s.argmin!((x) => x.length); > > > > People in the audience were quite pleasantly surprised to figure that > > although there's no mention of a type, that code is all the compiler > > needs to figure there's a lambda that takes a string and returns an > > unsigned integer etc. > > > > Exactly. And what many people (depressingly) don't realize, is > that dynamic typing (or OO boxing) is NOT needed to achieve that. > > I was actually impressed with that slide, too, but for a different > reason: I've come across need for a function like argmin on occasion, > but I didn't know it existed (Don't recall if it was actually in D, may > have been another language I was using). That really is a fantastically > useful function. Where is argmin defined? I couldn't find it. Jens
Re: Time for std.reflection
On Sunday, 22 July 2012 at 00:21:31 UTC, Andrei Alexandrescu
wrote:
On 7/21/12 8:16 PM, Kapps wrote:
I agree with most things proposed, however I am not a fan of
the idea of
mixing in runtime reflection info. Many times, you want
reflection info
from a type that is not your own, and thus I believe
reflection should
be generated by specifying a type. More importantly, a method
should
exist for recursively generating reflection info.
I confess I have trouble understanding each of the sentences
above.
What I meant was that when something requires reflection, it
generally requires that everything it contains has reflection
information as well. If using a mixin directly in the module
itself, when a module does not include this mixin it will never
get reflection information. This may or may not be desired.
However it completely prevents many common uses of reflection,
including serialization. So long as there is any dependency on
any type or method that does not have reflection info, the entire
operation would fail. This means that people will either start
adding reflection to modules that do not need it in fear that
someone may try to use a member of their module, or too sparsely
thus making reflection all but unuseable for many common
situations.
Also, I'd like to see a hierarchal approach to reflection
data. The main
advantage to std.reflection would be being able to use it at
run-time,
at which point we can't simply rely on templates, and instead
if we want
to store something we must rely on a base type.
At no place in the proposed approach is the use of templates
required or needed.
What I mean by this is that people rely on the ability to use
templates as a replacement to inheritance or common interfaces.
For example, ranges rely on methods existing rather than using an
interface for a range. With reflection, this isn't ideal. For
example, if you wanted to get all the fields and properties in a
module, including nested ones, you'd currently have to get all
fields, in a module, add those, then get all types in a module,
then all types in that type, then get all fields from those, etc.
With a hierarchal approach where MemberInfo has a Children
property, you'd simply get all children that are a FieldInfo or
PropertyInfo, and recurse for all returned values that have
children.
I think the best
approach would be a hierarchal system where all reflection
data derives
from MemberInfo. My ideal API would like something like:
https://workflowy.com/shared/62d4f791-e397-a86d-c018-09eab98b9927/
I cringed at
MemberType -> { Module, Type, Field, Method, Parameter }
I was hoping to get away from slapping tagging on types just
for the sake of using inheritance.
Admittedly, the MemberType wouldn't be necessary and I don't see
as having a huge benefit. In almost all cases you know what you
want to operate on, inheritance simply makes the API cleaner and
gives access to common methods more easily.
Re: Time for std.reflection
On Sunday, July 22, 2012 05:19:39 Kapps wrote: > What I meant was that when something requires reflection, it > generally requires that everything it contains has reflection > information as well. If using a mixin directly in the module > itself, when a module does not include this mixin it will never > get reflection information. This may or may not be desired. > However it completely prevents many common uses of reflection, > including serialization. So long as there is any dependency on > any type or method that does not have reflection info, the entire > operation would fail. This means that people will either start > adding reflection to modules that do not need it in fear that > someone may try to use a member of their module, or too sparsely > thus making reflection all but unuseable for many common > situations. Runtime reflection _must_ be opt-in. We do _not_ want to make all types pay the cost of having it. That means that however it's done is going to require that every type that has it be marked in one way or another to enable that functionality. That's part of the cost of being a systems language. Whatever solution we come up with must take that into account. - Jonathan M Davis
Re: Time for std.reflection
On Sunday, 22 July 2012 at 03:47:16 UTC, Jonathan M Davis wrote: Runtime reflection _must_ be opt-in. We do _not_ want to make all types pay the cost of having it. That means that however it's done is going to require that every type that has it be marked in one way or another to enable that functionality. That's part of the cost of being a systems language. Whatever solution we come up with must take that into account. - Jonathan M Davis But the whole point is that not every type has it; only those that are registered. It just happens that you can register types besides yourself, which is an absolute necessity for many common purposes of reflection. For serialization for example, the serializer / deserializer should create reflection information for all types contained in a class.
Re: Time for std.reflection
On 7/21/12 8:41 PM, deadalnix wrote: I don't understand. Are theses structures generated by the compiler or some kind of libraries at compile time on a per needed basis ? These are all library structures. Internally they use std.traits, which in turns uses compiler magic with __traits. Andrei P.S. What this thing wit quoting a long message to make a 1-line point? Is that a thing?
Re: Time for std.reflection
On 7/21/12 8:28 PM, Alex Rønne Petersen wrote: I'm just curious about one thing: How do you plan to reify templates (they are Turing complete after all)? I don't know. Andrei P.S. Please don't overquote.
Re: Time for std.reflection
On 7/21/12 8:46 PM, Andrej Mitrovic wrote:
On 7/21/12, Andrei Alexandrescu wrote:
class ModuleInfo {
@property:
string name();
ImportInfo[] imports();
DataInfo[] data();
FunctionInfo[] functions();
ClassInfo[] classes();
StructInfo[] structs(); // includes unions
TemplateInfo[] templates();
EnumInfo[] enums();
bool hasStaticCtor(), hasStaticDtor(),
hasSharedCtor(), hasSharedDtor();
}
Are class/struct/function/etc templates going to be stored in the
templates field? Then you'd have to tag each template with a type,
e.g. "class template" vs "function template" to be able to filter them
out.
Perhaps we could accommodate parameterized types together with
non-parameterized types by having e.g. additional properties that are
null for non-parameterized types.
Otherwise classes/functions/etc could have an optional
"TemplateTypeInfo[] typeParams" field so you could filter out
templated from non-templated types by checking their typeParams field,
e.g.: auto tempClasses = filter!(a => !empty(a.typeParams)
)(modinfo.classes);
I use a similar structure to what you've defined for my code generator
and it worked out nicely for me.
That sounds great!
Andrei
Re: OSCON 2012 notes
On 7/21/12 10:16 PM, Brad Anderson wrote: The Go people no longer refer to Go as a systems language. I believe they did intend for it to be a systems language in the same manner D is but over time they decided to focus less on that. Here's what Russ Cox said on that matter: "We removed the word 'systems' because it was too limiting. Go is more general than that. It is still a great language for writing systems." Yah, it's one of those things that stuck just like "Scala is FP on the JVM", characterization that Martin Odersky himself was surprised of (and refuted). Andrei
Re: OSCON 2012 notes
On Saturday, 21 July 2012 at 14:08:48 UTC, Adam D. Ruppe wrote: On Saturday, 21 July 2012 at 13:47:06 UTC, Michel Fortin wrote: The web is a low-hanging fruit for D. Yea, I've been eating that fruit for years. +1 Web development with D is quite easy and very enjoyable. With Adam's work it even more easier. I've done couple projects already with some of personal and Adam's stuff. Also I've try out a bit with Vibe.d, Adam's stuff, Serenity and they give the feel of php-like capabilities but I think it would be better to get something like Ruby on Rails, Django or Whatever-php-framework-you-may-use that allows Rapid Web Development. While making basic stuff like databases support, CGI/FCGI support etc to Phobos seems fine to me, I think that creating specialized D framework for web development would be better idea (and for sure it shouldn't be placed in standard library).
Re: OSCON 2012 notes
On Saturday, 21 July 2012 at 05:14:57 UTC, Andrei Alexandrescu wrote: I'm back from OSCON 2012, where my talk has enjoyed a somewhat unexpected good reception (OSCON is not the most down-D's-alley audience). The talk abstract is at http://www.oscon.com/oscon2012/public/schedule/detail/23888 and the slides are at http://www.slideshare.net/andreialexandrescu1/generic-programming-galore-using-d. There will be a video up some time in the future for the entire talk. [...] Cheers, Andrei Looking forward to see it
Re: Preview LLVM Deimos bindings
Am 20.07.2012 07:35, schrieb Jens Mueller: Hi, I've written some Deimos interface for LLVM. https://github.com/jkm/deimos-llvm/commits/master I'd like to get some feedback on those. Firstly to finish these and secondly to finish some guidelines that I'd like to propose to be published on dlang.org. Jens Are the bindings for 3.0 or 3.1? I'm asking because at least some enum members have changed (don't exactly remember which).
Re: Optional name mangling
"Stuart" wrote in message news:hmapfdehxvvuuxswr...@forum.dlang.org... > Hi. Is there any way to instruct the D compiler not to use name mangling > when referencing an external C++ function? > > For example: > >extern (System) bool PathRenameExtension(LPSTR pszPath, LPCSTR pszExt); > > In this particular case, the exported function being referenced is not > called _PathRenameExtension@8 - it's just called PathRenameExtension. Now, > it's great that D helpfully mangles the name for me when appropriate, but > we really need some way to disable it when necessary. > > Is there any way to import this function without creating a .def file with > "_PathRenameExtension@8 = PathRenameExtension"? And if not, why not? The problem isn't that D is mangling names it shouldn't, the problem is that your import library uses the wrong mangling for the internal names of imported symbols. Using the .def file with implib is the correct solution, unless you want to try converting a coff import library to omf (I've never got that to work). The reason implib needs a def file to work correctly is because only the exported name is stored in the dll, not the mangled name.
