Re: Programming in D book, User Defined Attributes (UDA) chapter
On Wednesday, 27 August 2014 at 06:16:14 UTC, Ali Çehreli wrote: I made some additions and corrections. The following are the major ones: * The 'User Defined Attributes (UDA)' chapter * @nogc * foreach_reverse * Formatted element output with %( and %) * static this, static ~this, shared static this, and shared static ~this As a reminder, the book is available as PDF, downloadable from the header of each chapter: http://ddili.org/ders/d.en/index.html Ali Good work Ali! Do you by any chance plan to release ePub version of it?
Re: COFF support for Win32 merged
On Tuesday, 19 August 2014 at 07:17:46 UTC, Jacob Carlborg wrote: On 17/08/14 11:57, Jacob Carlborg wrote: I though that this might be important enough to share on the announce list: A pull request [1] by Rainer Schuetze which adds COFF support for Win32 has recently been merged by Walter. It seems to be enabled using the -m32mscoff flag. The runtime part has been merged now as well: https://github.com/D-Programming-Language/druntime/pull/928 Pardon my ignorance but does that mean that static library written in D could be used (linked) by 32bit program compiled with Visual Studio?
Re: COFF support for Win32 merged
On 29/08/14 13:00, Szymon Gatner wrote: Pardon my ignorance but does that mean that static library written in D could be used (linked) by 32bit program compiled with Visual Studio? Yes, as far as I understand it. -- /Jacob Carlborg
Re: Programming in D book, User Defined Attributes (UDA) chapter
On 08/29/2014 03:45 AM, Dejan Lekic wrote: Do you by any chance plan to release ePub version of it? Yes. It will happen. :) Ali
Re: COFF support for Win32 merged
On Friday, 29 August 2014 at 12:50:28 UTC, Jacob Carlborg wrote: On 29/08/14 13:00, Szymon Gatner wrote: Pardon my ignorance but does that mean that static library written in D could be used (linked) by 32bit program compiled with Visual Studio? Yes, as far as I understand it. If that is indeed the case then this is huge for me. I am doing 32bit Win apps and their iOS versions. The moment I will be able to use D libraries on both platforms I will totaly do it. In fact I want to be one of the very first to release paid iOS app with D code in it ;)
Re: Blog post on hidden treasure in the D standard library.
On Friday, 29 August 2014 at 02:11:01 UTC, ketmar via Digitalmars-d-announce wrote: On Thu, 28 Aug 2014 16:18:42 + safety0ff via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: What do you have against capitalizing 'I' ? don't even noticed that until your post. but maybe that is 'cause i'm not using capitals at all... ;-) It annoyed me as well. If you're writing in a language, try to appear literate. I could live with misspelt superfragilisticexpialidocious or even a your/you're mixed by a native speaker, but this rule is very simple and has no exceptions. In fact, you could just do sed -r s/(^|[^[:alnum:]])i($|[^[:alnum:]])/\1I\2/g to have it fixed. How difficult is that?
Re: Blog post on hidden treasure in the D standard library.
On Friday, 29 August 2014 at 14:17:55 UTC, krzaq wrote: On Friday, 29 August 2014 at 02:11:01 UTC, ketmar via Digitalmars-d-announce wrote: On Thu, 28 Aug 2014 16:18:42 + safety0ff via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: What do you have against capitalizing 'I' ? don't even noticed that until your post. but maybe that is 'cause i'm not using capitals at all... ;-) It annoyed me as well. If you're writing in a language, try to appear literate. I could live with misspelt superfragilisticexpialidocious or even a your/you're mixed by a native speaker, but this rule is very simple and has no exceptions. In fact, you could just do sed -r s/(^|[^[:alnum:]])i($|[^[:alnum:]])/\1I\2/g to have it fixed. How difficult is that? I have been inadvertently too harsh. The lack of capitalized I is very annoying, but at the same time, I read the whole post and would like to thank the author for it.
Re: COFF support for Win32 merged
On 2014-08-29 16:06, Szymon Gatner wrote: If that is indeed the case then this is huge for me. I am doing 32bit Win apps and their iOS versions. The moment I will be able to use D libraries on both platforms I will totaly do it. In fact I want to be one of the very first to release paid iOS app with D code in it ;) It's your luck day (almost). I'm working on making D ABI compatible with Objective-C [1]. It's mostly done, I'm working on merging latest changes. [1] http://wiki.dlang.org/DIP43 -- /Jacob Carlborg
Re: Blog post on hidden treasure in the D standard library.
On Fri, 29 Aug 2014 14:17:53 + krzaq via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: If you're writing in a language, try to appear literate. but what if i can't, for example? i can read (and understand without dictionary, and with jokes too) books of Pratchett, Carrol, Adams, even Tolkien with his ye olde English, but i absolutely can't build correct English sentence by myself. signature.asc Description: PGP signature
Re: core.stdcpp
On Wednesday, 27 August 2014 at 04:23:28 UTC, Mike wrote: On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote: I'm asking this community to consider setting a new precedent for druntime: reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries. Please understand that I'm not suggesting we start refactoring druntime for 2.067. All I'm asking for is that we recognize that C/C++ library and OS bindings don't belong in druntime as public modules, and we gradually work towards migrating them to phobos or some other library in the years to come. The reason these are in Druntime at all is because code in Druntime depends on them. So if they were split into a separate library then it would be a required library. And even if we completely eliminate any dependency on standard C functions, I don't see any way to avoid depending on platform-specific calls. Now I would be fine with including just a subset of declarations in Druntime (which is really what we have right now anyway), but if the remainder were split into a standalone library then things start to get weird. Please let me know if you have a solution to this problem.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 21:38:04 UTC, deadalnix wrote: The problem is that you don't always want to bring libc and libstdc++ with you with every single project you write. Thus it shouldn't be in the runtime (except the very bit you can't get rid of). It can still be core.stdc . To be fair, the only part you bring with you are the dependencies that Druntime itself has. And nearly all of core.stdc is declarations anyway, so the only code bloat is unused ModuleInfo objects (notice that in places where Druntime uses C structs it declares them as =void to avoid depending on default initialization). The remaining issue becomes one of maintenance. If Druntime only declares the functions it needs, then where does the other stuff live? If you want to use that other library to get everything, does it publicly import core.stdc for the basics? What if Druntime needs a new call for some reason that's in this separate library? Do we declare it in core.stdc and cause collisions? What if D is ported to a new platform? That may require a whole raft of new declarations, both in a common API like core.stdc and in something more targeted like core.sys.linux. Don't get me wrong, I hate having to maintain the modules in core.stdc and core.sys. It's the worst job ever. I'm just not aware of a better solution to this particular problem.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 18:06:00 UTC, Daniel Murphy wrote: eles wrote in message news:rixtiaiokrukvqjsf...@forum.dlang.org... One such platform exists and is the embedded system, others are the linux kernel and the like, and even others are writing D compiler back-ends and, yes, druntimes (well, exactly the part that it is called phobos-runtime above). An embedded system that can support all of D but doesn't have a cruntime? I don't believe it. If it has a cruntime then providing bindings is a non-issue, and if it can't support all of D then supporting only a subset (and then being free to exclude core.stdc) is inevitable. There was a D runtime years ago created as a separate project around the time that Druntime had its beginnings (as Ares) that had no dependencies on standard C. The creator went by Maide in IRC, and she was doing some really cool stuff with it that made D work kind of like ObjectiveC. I don't think it's in development any more, but it's probably possible to track it down with enough googling.
Re: Blog post on hidden treasure in the D standard library.
On Friday, 29 August 2014 at 16:13:33 UTC, ketmar via Digitalmars-d-announce wrote: On Fri, 29 Aug 2014 14:17:53 + krzaq via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: If you're writing in a language, try to appear literate. but what if i can't, for example? i can read (and understand without dictionary, and with jokes too) books of Pratchett, Carrol, Adams, even Tolkien with his ye olde English, but i absolutely can't build correct English sentence by myself. The fact that you obviously can (sans capital Is, it seems) aside, I'd say it's a good reason to give yourself a pause before writing something for a wider public. The rules that say start every sentence with a capital letter or every I meaning thyself shall be capitalized are really simple to follow and you learn them very early when learning the language. Negligence to do so is, to me, either extreme laziness or lack of respect to the reader. This isn't twitter or a text message, after all, you had to have put some serious thought into writing such a post. Why not put a minute more to make it presentable? That being said, I'm sorry for my poor choice of words, I did not mean them to be as aggressive as they are.
Re: COFF support for Win32 merged
On Friday, 29 August 2014 at 15:46:33 UTC, Jacob Carlborg wrote: On 2014-08-29 16:06, Szymon Gatner wrote: If that is indeed the case then this is huge for me. I am doing 32bit Win apps and their iOS versions. The moment I will be able to use D libraries on both platforms I will totaly do it. In fact I want to be one of the very first to release paid iOS app with D code in it ;) It's your luck day (almost). I'm working on making D ABI compatible with Objective-C [1]. It's mostly done, I'm working on merging latest changes. [1] http://wiki.dlang.org/DIP43 Wow, that is great news! Thanks for this awesome work. How does that relate to C++ on iOS? My apps are 99,8% C++ with some minimal Obj-C when necessary.
Re: core.stdcpp
On 8/27/2014 2:38 PM, deadalnix wrote: The problem is that you don't always want to bring libc and libstdc++ with you with every single project you write. Remember that a library is not simply inserted bodily into the executable. A library is searched for modules that define unresolved symbols. I.e. only if you use code that refers to libc or libstd++ will those bits be linked in.
Re: Blog post on hidden treasure in the D standard library.
It's my blog and i'll do as *i* please.
Re: Blog post on hidden treasure in the D standard library.
After posting this yesterday i've so far had 9,900+ people visit this article (with 96.90% being new visitors). Good exposure for D i think. :)
Re: COFF support for Win32 merged
On Friday, 29 August 2014 at 15:46:33 UTC, Jacob Carlborg wrote: On 2014-08-29 16:06, Szymon Gatner wrote: If that is indeed the case then this is huge for me. I am doing 32bit Win apps and their iOS versions. The moment I will be able to use D libraries on both platforms I will totaly do it. In fact I want to be one of the very first to release paid iOS app with D code in it ;) It's your luck day (almost). I'm working on making D ABI compatible with Objective-C [1]. It's mostly done, I'm working on merging latest changes. [1] http://wiki.dlang.org/DIP43 I knew about this, but thought it had been abandoned. Great to see that it's alive, this is an important development!
Re: COFF support for Win32 merged
On 2014-08-29 19:16, Szymon Gatner wrote: Wow, that is great news! Thanks for this awesome work. How does that relate to C++ on iOS? My apps are 99,8% C++ with some minimal Obj-C when necessary. It's unrelated to C++. D is currently ABI compatible with C++ and if that works on OS X (I assume it does) it should work on iOS too. -- /Jacob Carlborg
Re: COFF support for Win32 merged
On 2014-08-29 20:35, Marc Schütz schue...@gmx.net wrote: I knew about this, but thought it had been abandoned. Great to see that it's alive, this is an important development! I've been working on resurrecting the great work done by Michel Fortin. It's updated to 64bit and the modern runtime. It runs on OS X 32 and 64bit and should run on iOS with minor tweaks. -- /Jacob Carlborg
Re: Programming in D book, User Defined Attributes (UDA) chapter
On 8/29/14, 6:30 AM, Ali Çehreli wrote: On 08/29/2014 03:45 AM, Dejan Lekic wrote: Do you by any chance plan to release ePub version of it? Yes. It will happen. :) Ali Awesome!! Put it on Amazon too! -- Andrei
Re: core.stdcpp
On 8/29/14, 10:02 AM, Sean Kelly wrote: Don't get me wrong, I hate having to maintain the modules in core.stdc and core.sys. It's the worst job ever. It's also one of those jobs silently appreciated by many. -- Andrei
Re: COFF support for Win32 merged
On 8/29/14, 9:40 AM, Andrej Mitrovic via Digitalmars-d-announce wrote: On 8/29/14, Jacob Carlborg via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 2014-08-29 16:06, Szymon Gatner wrote: If that is indeed the case then this is huge for me. I am doing 32bit Win apps and their iOS versions. The moment I will be able to use D libraries on both platforms I will totaly do it. In fact I want to be one of the very first to release paid iOS app with D code in it ;) It's your luck day (almost). I'm working on making D ABI compatible with Objective-C [1]. It's mostly done, I'm working on merging latest changes. [1] http://wiki.dlang.org/DIP43 There are so many amazing new features coming along for D lately. :) Keep it up! Things are really happening folks. Andrei
Re: core.stdcpp
On 08/29/2014 07:07 PM, Sean Kelly wrote: On Wednesday, 27 August 2014 at 18:06:00 UTC, Daniel Murphy wrote: eles wrote in message news:rixtiaiokrukvqjsf...@forum.dlang.org... One such platform exists and is the embedded system, others are the linux kernel and the like, and even others are writing D compiler back-ends and, yes, druntimes (well, exactly the part that it is called phobos-runtime above). An embedded system that can support all of D but doesn't have a cruntime? I don't believe it. If it has a cruntime then providing bindings is a non-issue, and if it can't support all of D then supporting only a subset (and then being free to exclude core.stdc) is inevitable. There was a D runtime years ago created as a separate project around the time that Druntime had its beginnings (as Ares) that had no dependencies on standard C. The creator went by Maide in IRC, and she was doing some really cool stuff with it that made D work kind of like ObjectiveC. I don't think it's in development any more, but it's probably possible to track it down with enough googling. It's still available at dsource: http://www.dsource.org/projects/ares
Debugging D in Vim with Vebugger
The commit where I added this is actually two months old, but I have only now made it an official release so I guess it's still news. From version 1.2.0, my debugger frontend for Vim, Vebugger, allows debugging D programs with GDB. This is done by invoking the debugger with the `VBGstartGDBForD` command. Using regular `VBGstartGDB` won't work since D uses it's own `main` function. Notice that this won't work under Windows, since GDB can not debug D programs under Windows. GitHub repo: https://github.com/idanarye/vim-vebugger vim.org page: http://www.vim.org/scripts/script.php?script_id=4941
Re: COFF support for Win32 merged
On Friday, 29 August 2014 at 19:54:04 UTC, Jacob Carlborg wrote: On 2014-08-29 19:16, Szymon Gatner wrote: Wow, that is great news! Thanks for this awesome work. How does that relate to C++ on iOS? My apps are 99,8% C++ with some minimal Obj-C when necessary. It's unrelated to C++. D is currently ABI compatible with C++ and if that works on OS X (I assume it does) it should work on iOS too. But there is still a matter of ARM/iOS runtime correct? Those merges will go to 2.067?
Re: core.stdcpp
On Friday, 29 August 2014 at 16:54:18 UTC, Sean Kelly wrote: On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote: On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote: The irony is D1 has std.c, and for D2 it was migrated to core.stdc. ...and design takes the backseat to convenience. This was a necessary part of the separation of the runtime components of the standard library from the extraneous stuff. Consider Druntime to be roughly equivalent to the java.lang package. It contains code and interfaces that pertain to the language definition, plus certain related low-level functionality. I don't believe it was necessary. D is quite capable of implementing the same logic that libc has. However, if for convenience, expediency, time-tested-reliance, optimization, or some other reason, one wishes to use libc, they can encapsulate it in the platform-specific logic, because that's what it is. It will always be a judgement call for where to draw the line. For example, should Range be in Druntime since it's something the compiler is aware of? What about basic math routines that the compiler might replace with an intrinsic call? So far, we've actually erred on the side of having less in Druntime rather than more. It currently contains user-visible code that's actually required for every D application: the GC, threads, bit operations, and atomics, plus some additional code and declarations that are required to implement these features. And that's it. If D is defined as a garbage-collected language, then it makes sense for the GC to be in druntime. If D is defined as a language the intrinsically supports threads, then that belongs in druntime, etc... But D is not defined as a superset of libc, or a standard operating system API, so there is no reason to publicly expose these. My argument can be limited to core.stdc/stdcpp for now. * Only a very limited subset of libc is needed by druntime * These can be eliminated by implementing them in D, or by using what the platform provides (kernel libs, etc...). It may not be convenient/expedient to do so, and will take significant effort and testing, but I'm not saying it needs to be done right now, just that it should be a goal. * If it is decided to keep them for convenience/expediency or another reason, they can be encapsulated by the ports that need them rather than publicly exposed. D could be so much more than what it currently is. What I eventually would like to see is the following ports: Architecture (bare metal) ports: --- X86 X86_64 ARM9 ARM7M MIPS etc.. OS Ports Windows Posix Linux MacOS etc... I believe that list shows what a narrow focus D currently has. While a libc exists for all of these, and it might be convenient to use it, it is not necessary given D's capabilities. D could do it all, and I think that would set D apart from many other languages if it did. That being said, it certainly would be convenient to make use of libc for many of these ports, so let's use it. Just encapsulate it so if, in the future, someone like me wants to submit pull requests to gradually remove the dependency on libc, they can do so without breaking the API and causing controversy. You might argue that Druntime shouldn't exist as a separate library at all, and at times I've wondered this myself, but some of the reasons for this have really borne out in practice, such as the forced elimination of unnecessary dependencies. If you look at D1 you'll find that the better part of the standard library is linked with every D application because some stuff that's always included (the GC code and what's in dmain, for example) uses high-level code which in turn depends on everything else. And while it's possible to avoid this with proper discipline, this is much easier to accomplish if the code simply isn't available in the first place. I think it is good design to separate the implementation of the language spec and compiler intrinsics from library functions that implement domain-specific logic or commonly used utility functions even if they are considered low-level. If one thinks of druntime as a low-level library, there's no reason to separate it from phobos. But if it's thought of as the language implementation, as I do, then the reason to separate the two is quite apparent, and the boundary between the two is quite stark. When making these arguments, please try thinking about the library from the perspective of a library designer and not an end user. Does the standard C interface truly belong in Phobos? In Druntime? Elsewhere? Why? And what factors might influence your decision? Are any of these factors currently present? Some of the reasons for the current design are historic and unnecessary and others are not. And anything can be changed if someone comes up with a better idea and is willing to do the work to make it so. It
