Re: C++ to catch up?
On Monday, 2 February 2015 at 00:49:14 UTC, Walter Bright wrote: Thanks for the good read! BTW, one effect D has had is that other languages are adopting D's features, though few will admit it. Yes - eerily out of the book from the Innovator's Dilemma. But as Jonathan said (and maybe you too), they are trapped by their installed base so one can only do so much. One sees the same thing with political parties when the tide shifts. (Let us not start on politics, though ;)
Re: C++ to catch up?
On 2/2/2015 12:20 PM, Laeeth Isharc wrote: On Monday, 2 February 2015 at 00:49:14 UTC, Walter Bright wrote: Thanks for the good read! BTW, one effect D has had is that other languages are adopting D's features, though few will admit it. Yes - eerily out of the book from the Innovator's Dilemma. But as Jonathan said (and maybe you too), they are trapped by their installed base so one can only do so much. I can't complain. D steals from other languages, too! But yes, adopting features is constrained by the base behavior of the language.
Re: H1 2015 Priorities and Bare-Metal Programming
On 2/2/2015 1:24 PM, Johannes Pfau wrote: What's your argument? That it still generates 2 instructions in the simplest case? That's an X86 specific detail. On ARM and other RISC architectures there is a difference between loading a literal (code into the instruction) or loading a runtime value. On AVR gcc can even rewrite bit-sized stores into set-bit and loads into read-bit instructions, but it needs to know the addresses at compile time. If you don't believe me get an AVR/ARM compiler and try it. A code generator for a specific architecture will naturally generate code that caters to it. volatileLoad()/Store() does not impede that, and a pragma(address) will not help.
Re: This Week in D: Issue #4
On Monday, 2 February 2015 at 04:57:10 UTC, Adam D. Ruppe wrote: I can't believe it, but yet another week has already passed, so up late to release this again! http://arsdnet.net/this-week-in-d/feb-01.html Early bird registration open for DConf, 2015 Vision released, GUI and Windows development on the forums. Today's tip is about class destructors, and Project Spotlight makes a return to introduce simpledisplay.d, in the first in what will become a series that walks us through making a bit of a little game in D. (Expect this to not be each week, it takes me a long time to write the project spotlight and I've been very busy lately and expect to continue being busy in the coming weeks. I'll probably try to do it every other week rather than every week.) http://www.reddit.com/r/programming/comments/2uhgzr/this_week_in_d_2015_vision_released_tip_on/ https://twitter.com/adamdruppe/status/562112301248290816 I'm not sure if every week needs a post to reddit. You're likely to increase the number of people who feel it is spam: https://www.reddit.com/r/programming/comments/2uhgzr/this_week_in_d_2015_vision_released_tip_on/co8v9y5 Besides, there may be weeks we want to obtain more attraction and that can be hard to do if every week is always posted. Remember, those who have found this week interested are either following it with RSS, this forum, or /r/d_language
Re: H1 2015 Priorities and Bare-Metal Programming
On 2/2/2015 10:44 AM, Iain Buclaw via Digitalmars-d wrote: On 2 February 2015 at 17:43, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 2/2/15 9:23 AM, Iain Buclaw via Digitalmars-d wrote: That code doesn't work with DMD. http://goo.gl/hgsHg0 Has that been filed yet? -- Andrei https://issues.dlang.org/show_bug.cgi?id=14114 The optimizer is regarding as a null any value being dereferenced that is less than 4096. Whether this is a bug or not is debatable.
Re: H1 2015 Priorities and Bare-Metal Programming
Am Mon, 02 Feb 2015 13:15:13 -0800
schrieb Walter Bright newshou...@digitalmars.com:
On 2/2/2015 9:15 AM, Johannes Pfau wrote:
It's also necessary that the compiler
knows after inlining that the address is a literal. Loading data
from fixed literal addresses produces different, more efficient
code than loading from an runtime address. As the function code
will generally be written for runtime values the compiler must
optimize after inlining to recognize the inlined code deals with
literals.
import core.bitop;
uint test() {
return volatileLoad(cast(uint *)0x1234);
}
---
dmd -c foo
---
_D3foo4testFZkL:
mov EAX,01234h
mov EAX,[EAX]
ret
Note that was an unoptimized build.
What's your argument?
That it still generates 2 instructions in the simplest case? That's an
X86 specific detail. On ARM and other RISC architectures there is a
difference between loading a literal (code into the instruction) or
loading a runtime value. On AVR gcc can even rewrite bit-sized stores
into set-bit and loads into read-bit instructions, but it needs to
know the addresses at compile time. If you don't believe me get an
AVR/ARM compiler and try it.
Re: Git, the D package manager
On Monday, 2 February 2015 at 21:55:21 UTC, Jonathan M Davis wrote: I've long thought that it some point, dub would be forced to support arbitrary build systems in order to actually work in the general case. There are far too many special cases and more complicated things that build scripts and the like frequently have to deal with for dub's simple approach to work in many cases. Just look at what something like cmake it can do. It blows dub out of the water when it comes to power. The fact that we have package management via dub is great, and the way it builds stuff works for many common cases (especially when you're talking about libraries), but I really don't think that its build system is powerful enough for the long run. I doubt that Sonke has time to deal with it given how much is on his plate, but we really need to look at making it so that dub supports a much more powerful build system - possibly even making it so that it can support projects building with existing build systems such as cmake. I'm sure that that sort of thing comes with its own types of problems, but what dub does right now is just too simplistic. A prime example that I've wondered about is how to deal with cases where you need to create a C or C++ wrapper for something and use it in your project. If dub supported makefiles, then that would be trivial, but as it stands, it can't do anything even close to that. Anything that's C or C++ has to already be built no the target system, be in a standard position for the linker to find it, etc., or you can't use it in a dub project. Given our need for C/C++ compatability, I think that that's a serious flaw. Dub is new, and we've gotten by thus far with what it can do, but if it's going to really be our standard build system for D, it needs to improve by quite a bit. - Jonathan M Davis I think it's the moment to point out the latest P.R. merged into dub: https://github.com/D-Programming-Language/dub/pull/489 It does support Makefiles in a way (prebuiltcommand), but I agree it's rather simplistic.
Re: Mars Drafting Library - Official community driven library
On Monday, 2 February 2015 at 06:07:29 UTC, Zach the Mystic wrote: Therefore, I think std.experimental is for all in flux APIs, from the drafting stage to the later less in flux stages. Definitely this is what I thought initially. But, IMO, it can be really hard or impossible to carry out, as you pointed one of the issues in the following part: The danger is that the phobos management will want to have their cake and eat it too, as the saying goes. You simply can't promise users both stability and a perfectly designed API at the same time, tempting as it is. Hence the *proposal* of the drafting library. Piotrek
Re: Git, the D package manager
On Monday, 2 February 2015 at 16:26:45 UTC, Atila Neves wrote: This thread has just made me decide to write a D build system, in D and configured in D that builds on dub and its packages intead of reinventing the wheel. I might ask the community for inputs on requirements. Maybe this will be my DConf 2015 submission. Why not building on cmake? You have experience with it. trentforkert made very good progress with D support in cmake and has good chances to merge it upstream [1]. If we look at the Vision/2015H1 goals, we see a couple of points, where cmake already has the necessary support: - C++ integration (hybrid projects) - alternative compilers - embedded systems This features would take a lot of effort/time to be implemented in a pure D solution, nevertheless any of these points is a niche in the D community. Apart from the ugly script language, cmake would be a pretty good fit. [1] - https://github.com/trentforkert/cmake
Re: H1 2015 Priorities and Bare-Metal Programming
On 2/2/2015 6:58 AM, Manu via Digitalmars-d wrote: They need to be wrapped to be useful, Wrapping them is a subjective matter of taste. And before anyone says I don't know what I'm talking about, I used to write embedded systems software. :-)
Re: H1 2015 Priorities and Bare-Metal Programming
On 2/2/2015 9:06 AM, Johannes Pfau wrote: _Dmain: push rbp movrbp,rsp subrsp,0x10 movrax,0x5 == movQWORD PTR [rbp-0x8],rax movecx,DWORD PTR [rax] == a register based load The instruction it should generate is mov ecx, [0x5] In 64 bit mode, there is no direct addressing like that. The above would be relative to the instruction pointer, which is RIP, and is actually: mov ECX, 5[RIP] So, to load address location 5, you would have to load it into a register first. (You'd be right for 32 bit x86. But also, all 32 bit x86's have an MMU rather than direct addressing, and it would be strange to set up the x86 embedded system to use MMIO rather than the IO instructions, which are designed for that purpose.) Not sure if it's actually more efficient on X86 but it makes a huge difference on real microcontroller architectures. What addressing mode is generated by the back end has nothing whatsoever to do with using volatileLoad() or pragma(address). To reiterate, volatileLoad() and volatileStore() are not reordered by the optimizer, and replacing them with pragma(address) is not going to make for better code generation. The only real issue is the forceinline one.
Re: Build managers
On Tue, 03 Feb 2015 05:56:51 +1300, Rikki Cattermole wrote: On 3/02/2015 5:35 a.m., ketmar wrote: On Mon, 02 Feb 2015 23:54:15 +1300, Rikki Cattermole wrote: Languages ... i can't even read that linenoise. There is three sets of files if I remember. First system level. Second user level. Lastly, project level. They override each other. The first two shouldn't need to be modified much. Mostly at first install. The last one is on a case by case basis for flexibility. And only one must be provided. So while yes there is probably a better way, I didn't choose it at the time. So if somebody was keen to take this up, then yes, that better way should be found. sorry, i mean XML per se. it's unwriteable, unreadable and unmaintainable. i just can't see the actual contents behind all that tag noise. signature.asc Description: PGP signature
Re: [website redesign] PR for the one with the big red menu bar
On 2015-02-02 at 18:29, Nick Sabalausky wrote: On 01/27/2015 03:02 PM, anonymous wrote: PR: https://github.com/D-Programming-Language/dlang.org/pull/869 - For details see here. Live version: http://ag0aep6g-dlang.rhcloud.com - If you've visited this before, you may have to clear your cache to see the proper logo color. The right-side panel is WAY too prominent. It takes nearly an entire third of the horizontal space, leaving the main content much to squished. Yes. The main content is way too narrow when the right panel finally disappears. The upper part of the left-side panel has far too much wasted vertical space. The main links don't even start until almost halfway down the first screen (ie, before you start scrolling). I love the logo with the horizon and the color scheme of the navigation panel, but I also feel that too much precious space above the fold is wasted. Compare the two: http://fgda.pl/static/dlang_org_sidebar.png
[Issue 14106] sort is @safe in release mode, @system in debug mode
https://issues.dlang.org/show_bug.cgi?id=14106 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/06fd47ffec0124dbcb4bbadea467492e9b65095b fix Issue 14106 - sort is unsafe in debug mode - need attribute inference to toString delegate https://github.com/D-Programming-Language/phobos/commit/3395af48ff11df7f5ba9dd1f325cf3a21d7c317c Merge pull request #2952 from MartinNowak/fix14106 fix Issue 14106 - sort is unsafe in debug mode --
[Issue 14106] sort is @safe in release mode, @system in debug mode
https://issues.dlang.org/show_bug.cgi?id=14106 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
Re: H1 2015 Priorities and Bare-Metal Programming
Am Mon, 02 Feb 2015 12:39:28 -0500 schrieb Steven Schveighoffer schvei...@yahoo.com: On 2/2/15 12:06 PM, Johannes Pfau wrote: Am Mon, 02 Feb 2015 02:49:48 -0800 schrieb Walter Bright newshou...@digitalmars.com: Please try it before deciding it does not work. I guess one ad hominem wasn't enough? Sorry, I'm not really vested in this discussion at all, but I don't think you realize what ad hominem means. http://en.wikipedia.org/wiki/Ad_hominem -Steve Ad hominem literally means 'to the person'. en/wikipedia reduces that to character but other definitions (de/wikipedia) include all arguments against a person instead of to the content of the arguments. Walter implicitly doubted my qualification in his last reply by claiming I don't understand how intrinsics work. Here he basically said I didn't even try to run the code and just making up issues. He's essentially saying I'm dishonest. He didn't respond to the content of my arguments. This is clearly not an argument, it's an attack on my reputation. So how is this not ad hominem?
Re: H1 2015 Priorities and Bare-Metal Programming
On 2/2/2015 6:43 AM, Manu via Digitalmars-d wrote: I'm pretty sure the only controversy is that you want it to be a pragma, everyone else wants it to be an attribute. That's correct. My reasoning is simple - an attribute defines the semantics of the interface, a pragma gives instructions to the compiler, and does not affect logical semantics. For example, attributes change the name mangling, because it affects the semantic interface. A pragma would not.
Re: how convert the range to slice ?
On Monday, 2 February 2015 at 19:04:52 UTC, Nordlöw wrote: https://github.com/nordlow/dmd/commit/40ce0ecf34f90c4d3053c47e9286d7574f596e15 Made it PR at https://github.com/D-Programming-Language/dmd/pull/4371
Re: Mars Drafting Library - Official community driven library
On Monday, 2 February 2015 at 20:09:42 UTC, Piotrek wrote: On Monday, 2 February 2015 at 06:07:29 UTC, Zach the Mystic wrote: Therefore, I think std.experimental is for all in flux APIs, from the drafting stage to the later less in flux stages. Definitely this is what I thought initially. But, IMO, it can be really hard or impossible to carry out, as you pointed one of the issues in the following part: The danger is that the phobos management will want to have their cake and eat it too, as the saying goes. You simply can't promise users both stability and a perfectly designed API at the same time, tempting as it is. Hence the *proposal* of the drafting library. Piotrek I think std.experimental should essentially be its own library, with its own slot next to phobos on the github repo. I'm open to changing the name or something... but if we have both std.experimental *and* your new mars, what do you think is the real difference? How can std.experimental be sort of experimental, but really not, whereas mars is really actually experimental? Where is the cutoff line? How would anyone know whether they reached it or not? My attitude is that any given module in std.experimental should simply indicate its current level stability at the top of its documentation - full disclosure about where it is from, say, 0 to 95%, (with anything above that already assumed qualified for std proper). I'd even make one more point, that all current phobos modules known to be in need of revamping be copied wholesale in their current forms to std.experimental, with the top documentation saying, This is the experimental version of the old std.xxx, which needs *your* help with its redesign and implementation. Feel free to break the current API by improving it. This is *not* currently considered a stable module.
Re: H1 2015 Priorities and Bare-Metal Programming
On 2/2/2015 9:15 AM, Johannes Pfau wrote:
It's also necessary that the compiler
knows after inlining that the address is a literal. Loading data from
fixed literal addresses produces different, more efficient code than
loading from an runtime address. As the function code will generally be
written for runtime values the compiler must optimize after inlining
to recognize the inlined code deals with literals.
import core.bitop;
uint test() {
return volatileLoad(cast(uint *)0x1234);
}
---
dmd -c foo
---
_D3foo4testFZkL:
mov EAX,01234h
mov EAX,[EAX]
ret
Note that was an unoptimized build.
Re: Git, the D package manager
On 02/02/15 11:13, Vladimir Panteleev via Digitalmars-d wrote: On Monday, 2 February 2015 at 10:09:00 UTC, Joseph Rushton Wakeling wrote: Well, as long as the requirements are expressed in the form, package-name: =1.2.3 This will allow Dub to pick a new major version with incompatible changes, no? Sorry, I was taking for granted that you'd understand that placing an upper bound on versions was also possible. Thanks to everyone who chipped in with examples. As I said in my reply to Mathias, what dub does breaks the module path and file path consistency when modules/subpackages lie in the repository root. Well, frankly, I think putting modules or subpackages in the repository root is a bad idea. I'm not sure why I should mind that dub enforces not doing such things.
Re: H1 2015 Priorities and Bare-Metal Programming
On Monday, 2 February 2015 at 21:01:30 UTC, Johannes Pfau wrote: Am Mon, 02 Feb 2015 12:39:28 -0500 schrieb Steven Schveighoffer schvei...@yahoo.com: On 2/2/15 12:06 PM, Johannes Pfau wrote: Am Mon, 02 Feb 2015 02:49:48 -0800 schrieb Walter Bright newshou...@digitalmars.com: Please try it before deciding it does not work. I guess one ad hominem wasn't enough? Sorry, I'm not really vested in this discussion at all, but I don't think you realize what ad hominem means. http://en.wikipedia.org/wiki/Ad_hominem -Steve Ad hominem literally means 'to the person'. en/wikipedia reduces that to character but other definitions (de/wikipedia) include all arguments against a person instead of to the content of the arguments. Walter implicitly doubted my qualification in his last reply by claiming I don't understand how intrinsics work. Here he basically said I didn't even try to run the code and just making up issues. He's essentially saying I'm dishonest. He didn't respond to the content of my arguments. This is clearly not an argument, it's an attack on my reputation. So how is this not ad hominem? I agree it was ad hominem, but I don't think Walter implied you were dishonest, so much as *ignorant* (i.e. of what would *really* happen if you just used the products as intended) - which implication is still bad, if proven false, but not quite as bad as calling you dishonest...
Re: Git, the D package manager
On 02/02/15 15:40, Dicebot via Digitalmars-d wrote: Quick summary of my opinion can look like this: 1) dub is a horrible build tool 2) git submodules is a horrible way for dependency management First thing is something we can improve on in future and, actually, dub supports using rdmd as a build tool already. Second thing is an inherent issue that won't change without some fundamental breaking changes in how hit submodules are implemented. Because of that I am trying to push dub despite the fact I don't like lot of things about it personally. Very well put. If there are issues with dub, we can and should address them -- not turn to a tool that isn't actually intended to solve the problem we are trying to address. 4) Inherently coupled with specific DVCS git and GitHub are most common (and officially endorsed) ways of version control in D world but those are not the only one. dub registry allows to use GitHub, GitBucket and source tarball packages in the same project - in simple uniform matter. It is a 100% in-house tool that does no depend on decisions of external project maintainers that provides a common API for everything else to interoperate Yup. It would be very presumptuous to assume that just because git works well for the core D project, that everyone out there should use it for their projects. By the way, talking of other VCS, I recently discovered a neat little trick for visualizing a complex git history in a clean way. You need to install bzr, and the qbzr and bzr-git plugins (this might also require bzrtools). Then, in a git branch, type, bzr qlog ... and you'll have a rather beautiful linear history of the master branch, with the option to expand out any individual merge that you want and review the commits therein. It'll take a little longer to load a large history, because it's solving a more complex problem than the standard git log tools, but I've found it a rather nice way of simplifying the view of complex, multi-branch history. I know some people have complained about the allegedly tangled mess of dmd/druntime/phobos commit history, and this might be a useful trick to help with that. I'm not aware of any git history visualizer that supports this functionality, which is a shame, because it must be possible.
Visual D prematurely closes the console
Hi. Visual D are settings in the project parameter Subsystem mode Console and command line with output still closes prematurely. How to make the command line was not closed prematurely without using system(pause)?
Re: H1 2015 Priorities and Bare-Metal Programming
On Monday, 2 February 2015 at 21:19:05 UTC, Walter Bright wrote: On 2/2/2015 9:17 AM, H. S. Teoh via Digitalmars-d wrote: Walter seems to dislike forced inlining for various reasons, preferring inlining as a hint at the most, and he probably has a point in most cases (let the compiler make the judgment). But in other cases, such as the one in question, the user needs to override the compiler's decision. Currently there's no way to do that, and it's a showstopper for those users. This is a settled issue. After all, I wrote: http://wiki.dlang.org/DIP56 Erm. Quoting the DIP: If a pragma specifies always inline, whether or not the target function(s) are actually inlined is implementation defined, although the implementation will be expected to inline it if practical. This is exactly the absolutely unacceptable part that makes your DIP useless and last discussion has stalled (from my POV) exactly at the point where you refused to negotiate any compromises on that matter.
Renaming DMD File Extensions from C to C++
Can we please change the file extensions in DMD from .c to .cpp for C++ sources?
Re: Git, the D package manager
On Monday, February 02, 2015 22:37:13 Joseph Rushton Wakeling via Digitalmars-d wrote: On 02/02/15 15:40, Dicebot via Digitalmars-d wrote: Quick summary of my opinion can look like this: 1) dub is a horrible build tool 2) git submodules is a horrible way for dependency management First thing is something we can improve on in future and, actually, dub supports using rdmd as a build tool already. Second thing is an inherent issue that won't change without some fundamental breaking changes in how hit submodules are implemented. Because of that I am trying to push dub despite the fact I don't like lot of things about it personally. Very well put. If there are issues with dub, we can and should address them -- not turn to a tool that isn't actually intended to solve the problem we are trying to address. I've long thought that it some point, dub would be forced to support arbitrary build systems in order to actually work in the general case. There are far too many special cases and more complicated things that build scripts and the like frequently have to deal with for dub's simple approach to work in many cases. Just look at what something like cmake it can do. It blows dub out of the water when it comes to power. The fact that we have package management via dub is great, and the way it builds stuff works for many common cases (especially when you're talking about libraries), but I really don't think that its build system is powerful enough for the long run. I doubt that Sonke has time to deal with it given how much is on his plate, but we really need to look at making it so that dub supports a much more powerful build system - possibly even making it so that it can support projects building with existing build systems such as cmake. I'm sure that that sort of thing comes with its own types of problems, but what dub does right now is just too simplistic. A prime example that I've wondered about is how to deal with cases where you need to create a C or C++ wrapper for something and use it in your project. If dub supported makefiles, then that would be trivial, but as it stands, it can't do anything even close to that. Anything that's C or C++ has to already be built no the target system, be in a standard position for the linker to find it, etc., or you can't use it in a dub project. Given our need for C/C++ compatability, I think that that's a serious flaw. Dub is new, and we've gotten by thus far with what it can do, but if it's going to really be our standard build system for D, it needs to improve by quite a bit. - Jonathan M Davis
Re: H1 2015 Priorities and Bare-Metal Programming
On Mon, Feb 02, 2015 at 09:53:43PM +, Dicebot via Digitalmars-d wrote: On Monday, 2 February 2015 at 21:19:05 UTC, Walter Bright wrote: On 2/2/2015 9:17 AM, H. S. Teoh via Digitalmars-d wrote: Walter seems to dislike forced inlining for various reasons, preferring inlining as a hint at the most, and he probably has a point in most cases (let the compiler make the judgment). But in other cases, such as the one in question, the user needs to override the compiler's decision. Currently there's no way to do that, and it's a showstopper for those users. This is a settled issue. After all, I wrote: http://wiki.dlang.org/DIP56 Erm. Quoting the DIP: If a pragma specifies always inline, whether or not the target function(s) are actually inlined is implementation defined, although the implementation will be expected to inline it if practical. This is exactly the absolutely unacceptable part that makes your DIP useless and last discussion has stalled (from my POV) exactly at the point where you refused to negotiate any compromises on that matter. Yes, and this is the sore point with the force-inline proponents. You're dangling the carrot of inline control in front of them, but snatch it away with the implementation-defined part. That might as well not be any control at all, since the default inlining behaviour is already implementation-defined; having two states of implementation-defined behaviour doesn't give us anything better than what we already have. The whole point behind inline control is to give the programmer a way to *override* the compiler's decision when the compiler's decision is wrong. By saying it's implementation-defined, you put the decision back in the compiler's hands, and so the compiler may continue making the same wrong decision, and we have achieved nothing at all. Of course, this is the pessimistic interpretation of DIP56, and perhaps, as a bystander, I can hazard a guess as to why forced inlining is left to the compiler's discretion -- one might want a compiler flag to disable forced inlining for debugging purposes, for example. However, without being more specific about exactly under what circumstances forced inlining is not obeyed, DIP56 leaves the decision completely in the implementor's hands, and users have no choice but to assume the worst. T -- Notwithstanding the eloquent discontent that you have just respectfully expressed at length against my verbal capabilities, I am afraid that I must unfortunately bring it to your attention that I am, in fact, NOT verbose.
Re: Mars Drafting Library - Official community driven library
On Sunday, 1 February 2015 at 23:22:55 UTC, Dicebot wrote: Newbie confusion? In what way? What library to use between Phobos and Mars, why those are separate, why those have different stability guranatees, where to submit new contributions, why bother - it all would need to be written down and explained over and over again. And this alone is huge -. IMO, there is no more confusion than using std.experimental vs other modules. Drafting modules are for developing functionality not present in Phobos, but build upon Phobos foundation. I admit I don't understand where confusion may come from. I will pay more attention to it as you described it as a huge problem. Piotrek
Re: Interfacing D to existing C++ code
On Sunday, 1 February 2015 at 22:32:37 UTC, Sativa wrote: On Friday, 23 January 2015 at 11:04:12 UTC, Walter Bright wrote: Mandatory reddit link: http://www.reddit.com/r/programming/comments/2tdy5z/interfacing_d_to_legacy_c_code_by_walter_bright/ There's been a lot of interest in this topic. Interesting... I wonder if two things could happen: 1. A tool could be written to generate the interfacing code in D from the C++ code? SWIG, but the quality is not there.
Re: H1 2015 Priorities and Bare-Metal Programming
On 02/02/2015 12:56 PM, Timo Sintonen wrote: Developers make things _for_ users. Hear hear, That's a point I always feel deserves far more attention and deliberate, conscious appreciation than it typically gets. (Just a general observation of the overall software development world, not necessarily specific to this discussion.) If this was a commercial product, lack of listening users needs would be fatal to the company. Man do I wish that really was true. It's likely true for a lot of small businesses, but the corporate big dogs can and regularly do get by fine without listening :( That's the power of oligopoly and mindshare.
Re: H1 2015 Priorities and Bare-Metal Programming
On 2/2/2015 9:17 AM, H. S. Teoh via Digitalmars-d wrote: On Mon, Feb 02, 2015 at 08:55:59AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 2/2/15 8:42 AM, Johannes Pfau wrote: Again the problem is not volatileLoad/Store which translate to single instructions it's wrappers. So does the argument boil down to better inlining control and enforcement? -- Andrei FWIW, from the POV of a bystander, the point is that force-inline for certain things (namely wrappers around certain intrinsics, like operator overloads for atomics, what-have-you) is necessary in order to guarantee that function call overhead will not be incurred no matter what. Walter seems to dislike forced inlining for various reasons, preferring inlining as a hint at the most, and he probably has a point in most cases (let the compiler make the judgment). But in other cases, such as the one in question, the user needs to override the compiler's decision. Currently there's no way to do that, and it's a showstopper for those users. This is a settled issue. After all, I wrote: http://wiki.dlang.org/DIP56 Unless we're proposing to flood the compiler with intrinsics, one for every possible operator overload of volatile loads/stores, which I think should be obviously infeasible. And even then, you still might miss one or two other obscure wrappers that users might discover that they need. It seems reasonable that instead of burdening the compiler (and compiler maintainers, and porters) to keep up with an ever-expanding set of intrinsics, making use of the language to express what is needed via forced-inline functions is a better way to do things. I agree that adding more language features instead of inline control is wrong.
Re: Mars Drafting Library - Official community driven library
On Sunday, 1 February 2015 at 23:21:36 UTC, Dicebot wrote: As per latest agreement everything in std.experimental is considered subject to any change so is perfectly flexible. - new drafting modules won't disturb usual users of the standard library That statements needs some hard data that current situation is disturbing to be considered as a rationale. If you put to many uncompleted modules in the std.experimental it can influence stable part of the Phobos. - binary size - pull request with more experimental stuff etc. IMO, std.experimental is not for the drafting stage of the SW development. Depends on your definition of draft. Anything that is good enough to be actually used in real app is good enough for std.experimental - and anything less is of no use to end user anyway. I agree that all is a matter of definition. I still doubt that fast evolving drafts would be possible in std namespace. 2) what would it give over code.dlang.org ? - community driven as opposed to individual driven - out of the box readiness - minimal fragmentation and controversy code.dlang.org is actually much more community driven because it is naturally decentralized. Controversy is inevitable anyway (hello std.json). I used the community driven in contrast to individually driven. The key property of the proposal is to minimize the controversy by community (common) drafting process. Fragmentation is a thing though - but I yet to be convinced that is a bad thing that needs to be fixed. I consider fragmentation a major problem for standards. 3) what problems are you trying to solve and why do you think this is suitable solution? Adding new modules (replacing the deprecated ones) in more robust and quicker manner. It is as quick as it can be for standard library - and code.dlang.org takes care of everything else. I have non-trivial modules in mind like gui, json, database, etc. Any library that risks quick removal of deprecated modules / API is not acceptable for standard stamp. The drafting lib is a proposition of standard not a standard itself. And I didn't said anything about removal. I was referring to: Warning: This module is considered out-dated and not up to Phobos' current standards. It will remain until we have a suitable replacement, but be aware that it will not remain long term. So far this does not seem a proposal that pulls own weight to me. I can put the burden on my shoulders. I'm in the middle of DIP creation. Unfortunately I have a regular job and other duties. Still, I hope to finish it as soon as promised. Piotrek
Re: C++ to catch up?
Wait, is this a reply today to a post made in November 2012? -- Andrei Yes, here is what happens: 1. person does a search, finds 2+ year old thread that he likes to respond to. 2. Entire thread gets pushed to the most recent posts on forum/newsgroup 3. Others now see the thread (possibly for the second time), and don't realize it's old, and read it thinking it's about today. A nice thing might be to make color of posts on forum.dlang.org based on recentness, 2+ month old be one color, 1+ year be another. This wouldn't help with newsgroup users, but it probably would help with forum users. -Steve Perhaps I should have made clearer in my post, but do you think it is necessarily inappropriate to extend a conversation that petered out rather than making a new post. Many observers (Neil Postman - 'amusing ourselves to death') have pointed to the superficiality and loss of coherence arising from the way in which we use technology. The question of D's edge and prospects isn't one that changes more than incrementally over a couple of years, as I understand it. And I thought more than a few times before deciding to post as to whether this would add value to the world, but it's an important question and my particular part of finance is not a tiny use domain. Putting oneself in the position of a prospective new user (as I have to do before suggesting my peers give D a try), one comes away from reading Slashdot discussions with the idea that there are a lot of complaints about D - and then one reads the forums and has a similar perspective. Since people are starved of attention and time, some will give up right then. So I wanted to do my small part to contextualize this. Laeeth.
Re: Should we remove int[$] before 2.067?
On Mon, 02 Feb 2015 19:13:13 +, Ola Fosheim Grøstad wrote: sure, to fully exploit that (and other things) it's better to drop that oldish object files concept and use something like delphi's .dcu. I am not familiar with that format, but using a high level intermediate representation format is the way to go for whole program optimization IMO... it's practically a .di file, but in compact binary representation. or even a full .d file for that matter. it's already parsed, checked, analyzed, maybe even some code emited -- but no AST/type information is lost. well, .dcus doesn't keep AST, but D .dcm can. ;-) they also can be used by tools too. Well, one should look to other architectures, but getting high performance levels takes focus. I am not sure if one can get beyond C++ by spreading out on all platforms. Intel intrinsics are in the thousands, and the libraries (and high level optimizer) probably should use those where they are a good fit... i think that this is the area that can be left to platform-specific part of the specs. maybe even omited completely, as it's highly backend/ arch dependent. if someone want to squeeze every cycle possible, he knows that his code will be unportable mess. ;-) signature.asc Description: PGP signature
Re: Should we remove int[$] before 2.067?
On 2/1/15 9:26 AM, Andrei Alexandrescu wrote: I agree indecision is bad. -- Andrei Whereas I'm still on the fence...
[Issue 14114] DMD optimizer defeats use of volatileLoad/Store with error: null dereference in function
https://issues.dlang.org/show_bug.cgi?id=14114 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com --- The optimizer is regarding as a null any value being dereferenced that is less than 4096. Whether this is a bug or not is debatable. --
Re: Visual D prematurely closes the console
On 02/02/2015 01:51 PM, Dennis Ritchie wrote: Hi. Visual D are settings in the project parameter Subsystem mode Console and command line with output still closes prematurely. How to make the command line was not closed prematurely without using system(pause)? I think the answer is the same as Visual C++: http://stackoverflow.com/questions/454681/how-to-keep-the-console-window-open-in-visual-c Ali
[Issue 481] Letting compiler determine length for fixed-length arrays
https://issues.dlang.org/show_bug.cgi?id=481 --- Comment #23 from Bill Baxter wbax...@gmail.com --- Whoa! 8 years later! yay! --
Re: Should we remove int[$] before 2.067?
On Monday, 2 February 2015 at 20:51:02 UTC, ketmar wrote: i think that this is the area that can be left to platform-specific part of the specs. maybe even omited completely, as it's highly backend/ arch dependent. if someone want to squeeze every cycle possible, he knows that his code will be unportable mess. ;-) Not a portable mess per se, you can have platform support described in the docs with performance notes. Most OSes have been geared towards C and Posix at some point and x86 is currently king, but hardware/coprocessors/memory architecture can be very different. Just wait till FPGAs become mainstream :-P. Don't mistake unix-style-hardware for portable code ;^) http://www.extremetech.com/extreme/184828-intel-unveils-new-xeon-chip-with-integrated-fpga-touts-20x-performance-boost
Re: Mars Drafting Library - Official community driven library
On Monday, 2 February 2015 at 21:19:01 UTC, Zach the Mystic wrote: I think std.experimental should essentially be its own library, with its own slot next to phobos on the github repo. I'm open to changing the name or something... but if we have both std.experimental *and* your new mars, what do you think is the real difference? How can std.experimental be sort of experimental, but really not, whereas mars is really actually experimental? Where is the cutoff line? How would anyone know whether they reached it or not? Hard to admit but I thought about removal of std.experimental ;), then I tried to find a better solution (not sure I did). After all I don't want to make more enemies than I have. So I got an idea that std.experimental can be adopted for the piloting new modules into Phobos when approved to be a standard. After Wikipedia: A pilot project refers to an initial roll-out of a system into production My attitude is that any given module in std.experimental should simply indicate its current level stability at the top of its documentation - full disclosure about where it is from, say, 0 to 95%, (with anything above that already assumed qualified for std proper). Yes, the drafting stage can have many sub-stages, but I didn't want to complicate the initial proposal too much and risk both low chance of the approval and later, inability of proper implementation. I learned that there can be taken only limited steps at once. I'd even make one more point, that all current phobos modules known to be in need of revamping be copied wholesale in their current forms to std.experimental, with the top documentation saying, This is the experimental version of the old std.xxx, which needs *your* help with its redesign and implementation. Feel free to break the current API by improving it. This is *not* currently considered a stable module. Haha, let's not lose our nerves :) It's not that bad. Moreover. I can barely find the equivalent level of code awesomeness as it is in D libraries. We just need to speed up the progress and reduce work fragmentation. Piotrek
Re: Git, the D package manager
On 02/02/2015 03:09 AM, Vladimir Panteleev wrote: 1a. rdmd and D's module system: [...] In contrast, Dub's default modus operandi is to blindly send to the compiler all *.d files found in the src folder, whether they're actually used or not. Not only can this be slower if not all modules are always used, but it also won't work if the source code contains multiple entry points, forcing you to write complicated configuration files (i.e. do the computer's work for it). This is one of my biggest beefs with dub, too, and constantly causes me trouble. (I love that dub exists as a package manager, but I REALLY dislike that it tries to be build system too. Especially since I don't like the way its build functionality works.) In theory, dub does have the --rdmd switch to make it select source files in a sane manner (by deferring to rdmd), but unfortunately it doesn't get well-tested and frequently breaks: https://github.com/D-Programming-Language/dub/issues/492 1b. rdmd and D's search path rdmd does not have any additional parameters to set up for where it needs to look for source files, because it relies on the compiler's search mechanism. Thus, if you can build your program with rdmd, dmd -o- program will succeed, and usually vice versa. In contrast, Dub builds its own search path using its JSON configuration files, and has no equivalent of dmd -o-. There is no simple way to syntax-check just one file in a project when using Dub. I rely on this a lot in my workflow - I configured a syntax-check key in my editor, which I use almost as often as I save. A syntax check (dmd -o-) is much faster than a full build, as it skips parsing other parts of the project, code generation, and linking. My #1 beef with Dub: It desperately needs a way to *just* obtain the -o/-version/etc args to be passed directly into dmd/rdmd/ldmd/gdmd/etc. Without that, dub is useless as a MERE package manager. It's either packaging AND building, or nothing. (Ever try to use a recent version of vibe.d in a project that *doesn't* use dub as its build system? PITA. It isn't even recommended to do so.) I tried to add that feature one time, but I had trouble grokking the relevant section of dub's source :( There's also one other big thing I don't like about it: It needlessly reinvents and renames dmd's entire set of command switches. That isn't even needed for ldc/gdc anyway since, last I heard, the ldmd and gdmd wrappers exist. I pushed to get the *actual* compiler switched accepted by dub, and the feature made it in, but trying to use it generates a big giant warning for all your library's users complaining that the feature *shouldn't* be used. Thus completely defeating the point. Argh. Again, I love that Dub (and especially it's package repository) exists. But dub just tries to hard to impose it's own way.
Re: Git, the D package manager
On 02/02/2015 05:15 PM, Nick Sabalausky wrote: My #1 beef with Dub: It desperately needs a way to *just* obtain the -o/-version/etc args to be passed directly into dmd/rdmd/ldmd/gdmd/etc. Actually I meant -I, not -o. (But I guess maybe -o too.)
Re: [website redesign] PR for the one with the big red menu bar
On 02/02/2015 04:59 PM, FG wrote: On 2015-02-02 at 18:29, Nick Sabalausky wrote: On 01/27/2015 03:02 PM, anonymous wrote: PR: https://github.com/D-Programming-Language/dlang.org/pull/869 - For details see here. Live version: http://ag0aep6g-dlang.rhcloud.com - If you've visited this before, you may have to clear your cache to see the proper logo color. The right-side panel is WAY too prominent. It takes nearly an entire third of the horizontal space, leaving the main content much to squished. Yes. The main content is way too narrow when the right panel finally disappears. I assume you mean *until* the right panel finally disappears? The upper part of the left-side panel has far too much wasted vertical space. The main links don't even start until almost halfway down the first screen (ie, before you start scrolling). I love the logo with the horizon and the color scheme of the navigation panel, but I also feel that too much precious space above the fold is wasted. Compare the two: http://fgda.pl/static/dlang_org_sidebar.png Yea, the example on the right is way better. It even *looks* much, much nicer.
Re: Renaming DMD File Extensions from C to C++
On Tue, Feb 03, 2015 at 01:49:52AM +, deadalnix via Digitalmars-d wrote: On Tuesday, 3 February 2015 at 01:39:31 UTC, H. S. Teoh wrote: Did you fix the build problems yet? Or at least make them more robust? The last time I tried to build SDC, I had to manually hack a lot of things to work in my environment, and eventually I gave up. T This is the only issue I have on the subject: https://github.com/deadalnix/SDC/issues/55 I can't fix what I don't know is broken. OK, I'll file bugs when I get around to trying SDC again. Right now I'm too busy with other things, sorry... T -- One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article Giving it all away
Re: H1 2015 Priorities and Bare-Metal Programming
On 2/2/2015 2:34 PM, Jonathan M Davis via Digitalmars-d wrote: That makes sense, though the one issue that I see with making it a pragma is the fact that pragmas are supposed to be compiler-specific and not part of the language (at least as I understand it), and I would expect that anyone looking to force inlining would want it guaranteed regardless of the compiler. Of course, all compilers could implement it, and with a shared frontend for most of the D compilers, it would likely be in most of them anyway, but if it's a pragma, it does seem like it wouldn't necessarily be guaranteed. There are already several pragmas implemented. I'd be surprised if some compiler chose not to do them. As I wrote to Dicebot, compiler implementers aim to please their users as much as possible. They do not attempt to perversely implement the spec in such a way as to conform to the letter but be useless in practice. For example, I could easily write a Standard conformant C compiler that would be useless. But nobody does such a thing unless they are incompetent, and even if they did, why would anyone waste their time using such a product?
Re: H1 2015 Priorities and Bare-Metal Programming
On Monday, 2 February 2015 at 23:29:26 UTC, Walter Bright wrote: Now, when it can't inline, do you expect the compiler to produce an error message? Yes, this is the very point of such feature - telling that if code can't be inlined, it is effectively unusable. If so, what corrective action is the user faced with: pragma(inline, some expression that determines the compiler version and evaluates to true only if this particular function can be inlined); Prohibit this generally useless misfeature and keep base semantics useful.
Re: H1 2015 Priorities and Bare-Metal Programming
On 03.02.15 00:29, Walter Bright wrote: Now, when it can't inline, do you expect the compiler to produce an error message? Or warning? Microcontroller programmers like to look at produced code, no need to force them :)
Re: Visual D prematurely closes the console
On Monday, 2 February 2015 at 22:58:06 UTC, Dennis Ritchie wrote: On Monday, 2 February 2015 at 22:14:36 UTC, Ali Çehreli wrote: http://stackoverflow.com/questions/454681/how-to-keep-the-console-window-open-in-visual-c Not helped: http://i.imgur.com/4EG84YK.png Use monoD do a hello world ,you will get the answer.
Re: H1 2015 Priorities and Bare-Metal Programming
On 2/2/2015 2:30 PM, Johannes Pfau wrote:
I does: if the backend can't know that a value is known at compile time
it cant use absolute addresses:
void test(ubyte* ptr)
{
volatileLoad(ptr); //Can't use literal addressing might be runtime
value
}
The context here is that pragma(address) allows avoiding one wrapper
function. See below.
Again, that is simply an inlining issue.
The pragma(address, 0x05) makes sure that the compiler backend always
knows that PORTA is at 0x05.
Constant propagation and inlining do that. Both are standard optimizations that
every compiler does. Adding language features on the presumption that compilers
won't do that is like trying to fix the broken engine in your car by adding
another engine in the trunk.
-O mostly fixes performance problems, but adding an additional property
function is still much uglier than declaring an extern variable with an
address in many ways. (compiler bugs,
Language features should not be added because of compiler bugs.
user-facing code,
Library wrapper types will be showing up more and more. How nice they are is up
to the library designer.
debug info, ...)
Symbolic debugging is always going to be an issue until there are debuggers that
are better designed to work with D.
Also it's a conceptually nice way for typed registers: You can read it
as: I've got a Register of type PORT which is an extern variable located
add a fixed address. PORT abstract away volatile access.
auto a = PORT!0x1234;
looks nicer than:
pragma(address, 0x1234) PORT a;
Re: H1 2015 Priorities and Bare-Metal Programming
On 2/2/2015 1:53 PM, Dicebot wrote: http://wiki.dlang.org/DIP56 Erm. Quoting the DIP: If a pragma specifies always inline, whether or not the target function(s) are actually inlined is implementation defined, although the implementation will be expected to inline it if practical. This is exactly the absolutely unacceptable part that makes your DIP useless and last discussion has stalled (from my POV) exactly at the point where you refused to negotiate any compromises on that matter. That interpretation is a little over the top. Any reasonable implementation is going to do what it can to inline when asked to - people who write compilers do not try to perversely interpret the spec in order to be as useless as possible. (After all, we are not writing the tax code!) Now, when it can't inline, do you expect the compiler to produce an error message? If so, what corrective action is the user faced with: pragma(inline, some expression that determines the compiler version and evaluates to true only if this particular function can be inlined); ? Such will necessarily be brittle, and of dubious utility.
Re: Git, the D package manager
On Monday, 2 February 2015 at 08:09:39 UTC, Vladimir Panteleev wrote: ... Sorry if it has been answered, but one of the points brought up was non-D project management. Is it possible for Dub to i.e, compile C files for me and link them with my D files? I'm currently using makefiles for this.
Re: DStep - Bindings Generator 0.0.1
On 02/02/2015 04:21 AM, Chris wrote: On Saturday, 31 January 2015 at 19:40:49 UTC, Jacob Carlborg wrote: On 2015-01-31 19:38, Chris wrote: At version 0.0.1? :) At version 0.1.0: https://github.com/jacob-carlborg/dstep/releases/tag/v0.1.0 Still loads of time to change the name. If you wanna do it, do it now. I like C.h D :) FYI, this thread started 3 years ago... -- Paul O'Neil Github / IRC: todayman
Re: This Week in D: Issue #4
On Monday, 2 February 2015 at 04:57:10 UTC, Adam D. Ruppe wrote: I can't believe it, but yet another week has already passed, so up late to release this again! Very nice! Thank you. Unfortunately, your project Spotlight does not work exactly as advertised, since simpledisplay imports arsd.color. Just to let you know.
Re: Visual D prematurely closes the console
On Monday, 2 February 2015 at 23:08:13 UTC, FrankLike wrote: Use monoD do a hello world ,you will get the answer. And Mono-D good debugger?
Re: 2015 H1 Vision
On Sunday, 1 February 2015 at 01:17:41 UTC, Andrei Alexandrescu wrote: Hello, Walter and I have been mulling for a while on a vision for the first six months of 2015. http://wiki.dlang.org/Vision/2015H1 This is stuff we consider important for D going forward and plan to work actively on. We encourage the D community to focus contributions along the same lines. While a don't see the content as disagreeable, I do find it to be a lot to focus on for the next 6 months. * Improve language stability * Memory Management * Safety * C++ integration These all seem like that could deserve their own 6 months of focus. These should all get work, but it just seems that if you're going to take priority on something it shouldn't be spread across so many large tasks. Or maybe there just needs to be a list of things not taking priority.
Re: Renaming DMD File Extensions from C to C++
On Tuesday, 3 February 2015 at 00:59:26 UTC, Andrei Alexandrescu wrote: On 2/2/15 4:23 PM, eles wrote: On Monday, 2 February 2015 at 21:51:42 UTC, Nordlöw wrote: Can we please change the file extensions in DMD from .c to .cpp for C++ sources? http://forum.dlang.org/post/peivwaklprmaafalb...@forum.dlang.org Better change them straight to .d! -- Andrei https://github.com/deadalnix/SDC/ Care to contribute ?
Re: Renaming DMD File Extensions from C to C++
On Tuesday, 3 February 2015 at 01:39:31 UTC, H. S. Teoh wrote: Did you fix the build problems yet? Or at least make them more robust? The last time I tried to build SDC, I had to manually hack a lot of things to work in my environment, and eventually I gave up. T This is the only issue I have on the subject: https://github.com/deadalnix/SDC/issues/55 I can't fix what I don't know is broken.
Re: Visual D prematurely closes the console
On Monday, 2 February 2015 at 22:14:36 UTC, Ali Çehreli wrote: http://stackoverflow.com/questions/454681/how-to-keep-the-console-window-open-in-visual-c Not helped: http://i.imgur.com/4EG84YK.png
[Issue 14117] New: core.atomic should be @safe
https://issues.dlang.org/show_bug.cgi?id=14117 Issue ID: 14117 Summary: core.atomic should be @safe Product: D Version: unspecified Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: c...@dawg.eu Most if not all functions in core.atomic are memory safe and should be marked as @safe. --
Re: Renaming DMD File Extensions from C to C++
On Monday, 2 February 2015 at 21:51:42 UTC, Nordlöw wrote: Can we please change the file extensions in DMD from .c to .cpp for C++ sources? http://forum.dlang.org/post/peivwaklprmaafalb...@forum.dlang.org
Re: Renaming DMD File Extensions from C to C++
On 2/2/15 4:23 PM, eles wrote: On Monday, 2 February 2015 at 21:51:42 UTC, Nordlöw wrote: Can we please change the file extensions in DMD from .c to .cpp for C++ sources? http://forum.dlang.org/post/peivwaklprmaafalb...@forum.dlang.org Better change them straight to .d! -- Andrei
Re: Visual D prematurely closes the console
I found the right option! http://imgur.com/KfkuBZi
Re: H1 2015 Priorities and Bare-Metal Programming
Am Mon, 02 Feb 2015 13:44:41 -0800
schrieb Walter Bright newshou...@digitalmars.com:
On 2/2/2015 9:06 AM, Johannes Pfau wrote:
_Dmain:
push rbp
movrbp,rsp
subrsp,0x10
movrax,0x5 ==
movQWORD PTR [rbp-0x8],rax
movecx,DWORD PTR [rax] == a register based
load
The instruction it should generate is
mov ecx, [0x5]
In 64 bit mode, there is no direct addressing like that. The above
would be relative to the instruction pointer, which is RIP, and is
actually:
mov ECX, 5[RIP]
So, to load address location 5, you would have to load it into a
register first.
(You'd be right for 32 bit x86. But also, all 32 bit x86's have an
MMU rather than direct addressing, and it would be strange to set up
the x86 embedded system to use MMIO rather than the IO instructions,
which are designed for that purpose.)
Well, as I said it's different on RISC. I'm mainly programming for ARM,
AVR MSP430 and similar systems, not X86.
Not sure if it's actually more efficient on X86 but it makes a huge
difference on real microcontroller architectures.
What addressing mode is generated by the back end has nothing
whatsoever to do with using volatileLoad() or pragma(address).
I does: if the backend can't know that a value is known at compile time
it cant use absolute addresses:
void test(ubyte* ptr)
{
volatileLoad(ptr); //Can't use literal addressing might be runtime
value
}
The context here is that pragma(address) allows avoiding one wrapper
function. See below.
ARM can code address literals into instructions. So you end up with one
instruction for a load from a compile time known address.
To reiterate, volatileLoad() and volatileStore() are not reordered by
the optimizer, and replacing them with pragma(address) is not going
to make for better code generation.
The only real issue is the forceinline one.
I think we're talking different languages. Nobody ever proposed
pragma(address) to replace volatileLoad. It's meant to be used together
with the volatile intrinsics like this:
-
import core.bitop;
struct Volatile(T)
{
private:
T _store;
public:
@disable this(this);
/**
* Performs 1 load followed by 1 store
*/
@attribute(inlineonly) void opOpAssign(string op)(in T rhs)
nothrow @trusted {
T val = volatileLoad(_store);
mixin(val ~ op ~ = rhs;);
volatileStore(_store, val);
}
//In reality, much more complicated wrappers are possible
//http://pastebin.com/RGhKdm9i
}
pragma(address, 0x05) extern __gshared Volatile!ubyte PORTA;
//...
PORTA |= 0b_0001;
auto addr = PORTA;
-
The pragma(address, 0x05) makes sure that the compiler backend always
knows that PORTA is at 0x05. Thinks like PORTA become trivial and the
compiler backend has exactly the same knowledge as if you'd use C
volatile = all optimizations apply.
And if you call opopAssign the backend knows that the this pointer is a
compile time literal value and generates exactly the same code as if
you wrote
T val = volatileLoad(0x05);
val ~ op ~ = rhs;
volatileStore(0x05, val);
but if you instead write
@property ref Volatile!ubyte PORTA()
{
return *(cast(Volatile!(ubyte)*)0x05)
}
PORTA |= now calls a function behind the scenes. The backend does not
immediately know that PORTA is always 0x05. Also the this pointer in
opopAssign is no longer a compile time constant. And this is were the
constant/runtime value code gen difference discussed above matters.
-O mostly fixes performance problems, but adding an additional property
function is still much uglier than declaring an extern variable with an
address in many ways. (compiler bugs, user-facing code, debug info, ...)
Also it's a conceptually nice way for typed registers: You can read it
as: I've got a Register of type PORT which is an extern variable located
add a fixed address. PORT abstract away volatile access.
Re: H1 2015 Priorities and Bare-Metal Programming
On Monday, February 02, 2015 13:01:28 Walter Bright via Digitalmars-d wrote: On 2/2/2015 6:43 AM, Manu via Digitalmars-d wrote: I'm pretty sure the only controversy is that you want it to be a pragma, everyone else wants it to be an attribute. That's correct. My reasoning is simple - an attribute defines the semantics of the interface, a pragma gives instructions to the compiler, and does not affect logical semantics. For example, attributes change the name mangling, because it affects the semantic interface. A pragma would not. That makes sense, though the one issue that I see with making it a pragma is the fact that pragmas are supposed to be compiler-specific and not part of the language (at least as I understand it), and I would expect that anyone looking to force inlining would want it guaranteed regardless of the compiler. Of course, all compilers could implement it, and with a shared frontend for most of the D compilers, it would likely be in most of them anyway, but if it's a pragma, it does seem like it wouldn't necessarily be guaranteed. - Jonathan M Davis
Re: Time for 2.067
On Friday, 30 January 2015 at 23:17:09 UTC, Andrei Alexandrescu wrote: Sorry, I thought that was in the bag. Keep current semantics, call it chunkBy. Add the key to each group when the predicate is unary. Make sure aggregate() works nice with chunkBy(). I might miss some information on this, so please forgive my naive question. Your requirements seem to be contradictory to me. 1. aggregate expects a range of ranges 2. you ask chunkBy to return something that is not a range of ranges 3. you ask chunkBy to play along nicely with aggregate There are certainly ways to make this work. Adding a special version of aggregate comes to mind. However, I fail to see the rational behind this. To me the beauty of range is the composibility of simple constructs to create complex behavior. The current chunkBy does not need to be changed to add the key to each group when the predicate is unary: r.map!(pred, a) .chunkBy!(a[0]) .map!(inner = tuple(inner.front[0], inner.map!a[1])); So I'd like to know why the above is inferior to a rework of the chunkBy's implementation. Maybe this is a question for D.learn.
Re: Git, the D package manager
So. I've reported lots of bugs in DUB and fixed some, and since using it I never looked back. It does seem more stable these days. On Monday, 2 February 2015 at 08:09:39 UTC, Vladimir Panteleev wrote: So, in order to start using Dub, I'd need to: - restructure the directory layout of my library (breaking change) I was about to say yes but perhaps that's fixable in DUB. Currently, using ae checkouted in an ae/ directory means having an import leak meaning that you have to import a path outside the checkouted repositery. That's somehow unhygienic like, er, a global namespace. But yeah DUB could isolate checkouts one directory deeper (ae-1.0.0/ae/) to make this a non-problem, this would support libraries like ae/ and make DScanner work. - update all projects which use this library to use Dub instead And drop their current build system for something hopefully more uniform and not that complicated. - give up quick syntax checking Fixed it you push code one directory further. - give up commit-granularity versioning Not necessarily if you make tags at each commit (and most of the time it's not really necessary). - begin maintaining JSON configuration files It's not that bad honestly. Actually mandatory field are few and between. If using sub-packages it does take some learning though. - begin versioning libraries by hand Yes, but with the benefit of: - helping your users choosing a version, and protecting them from churn (eg. broken build) - choosing if they want breaking changes. - see also: http://forum.dlang.org/post/nknzdktahezyztzdv...@forum.dlang.org for the diamond dependency problem. git submodules work well when you don't use third-party libs but let's be honest, not everyone understand git submodules let alone want to. I also know some D programmers that don't want to touch git. No thanks. I could invest time in improving Dub to fix or ameliorate some of the above points, but I don't see a compelling reason to. In fact, I think we should integrate rdmd into dmd - dmd clearly already knows which source files participate in compilation, as all rdmd does is basically take dmd's output and feed it back to it. This will greatly speed up compilation, too. Change my view. The DUB way does take more work and requires some learning but it makes things super simple for library _users_ and imho this benefits the ecosystem as a whole. If you want more users then DUB is nicer to them. I've also found it changed my way to develop, I'm much more likely to reuse something from the registry, and much more likely to bundle breaking changes together.
Re: Renaming DMD File Extensions from C to C++
On Tue, Feb 03, 2015 at 01:33:31AM +, deadalnix via Digitalmars-d wrote: On Tuesday, 3 February 2015 at 00:59:26 UTC, Andrei Alexandrescu wrote: On 2/2/15 4:23 PM, eles wrote: On Monday, 2 February 2015 at 21:51:42 UTC, Nordlöw wrote: Can we please change the file extensions in DMD from .c to .cpp for C++ sources? http://forum.dlang.org/post/peivwaklprmaafalb...@forum.dlang.org Better change them straight to .d! -- Andrei https://github.com/deadalnix/SDC/ Care to contribute ? Did you fix the build problems yet? Or at least make them more robust? The last time I tried to build SDC, I had to manually hack a lot of things to work in my environment, and eventually I gave up. T -- Give me some fresh salted fish, please.
Re: 2015 H1 Vision
On Mon, 2015-02-02 at 12:36 +, Atila Neves via Digitalmars-d-announce wrote: […] Indeed. Most of the issues I hear about stem from it trying to do both at the same time. It's a good package manager but unfortunately a not so good build system. This makes me think, once more, of writing a D build system that uses dub only for package dependencies. Given Gradle is both a dependency and build manager, and is the standard platform for Android builds, and has C++ as well as JVM languages support, I would suggest it would be a great base. -- 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
Re: cast a C char array - offset ?
On Monday, 2 February 2015 at 12:42:24 UTC, FG wrote:
On 2015-02-02 at 13:16, irtcupc wrote:
The manual section about interfacing from c states that
type[] is inter-compatible from C to D,
however, I face this strange case:
- C declaration:
char identifier[64];
- D declaration:
char[64] identifier;
- the result is only correct if i slice by (- pointer size):
char[64] fromC(char[64] * thing)
{
const offs = size_t.sizeof;
return thing[-offs.sizeof .. $-offs];
}
Is this correct ?
So you have to shift the whole array right by 4 or 8 bytes?
Strange.
Looks like an alignment issue. Is identifier part of a bigger
structure?
Yes:
C struct:
#pragma pack(1)
typedef struct _Disasm {
UIntPtr EIP;
UInt64 VirtualAddr;
UInt32 SecurityBlock;
char CompleteInstr[INSTRUCT_LENGTH];
UInt32 Archi;
UInt64 Options;
INSTRTYPE Instruction;
ARGTYPE Argument1;
ARGTYPE Argument2;
ARGTYPE Argument3;
PREFIXINFO Prefix;
InternalDatas Reserved_;
} DISASM, *PDISASM, *LPDISASM;
#pragma pack()
D struct:
align(1)
struct _Disasm {
void * EIP;
ulong VirtualAddr;
uint SecurityBlock;
char [INSTRUCT_LENGTH] CompleteInstr;
uint Archi;
ulong Options;
INSTRTYPE Instruction;
ARGTYPE Argument1;
ARGTYPE Argument2;
ARGTYPE Argument3;
PREFIXINFO Prefix;
uint Reserved_[40];
}
my current understanding is that:
- C: char CompleteInstr[INSTRUCT_LENGTH] is actually a raw chunk
- D: defining the member as char[INSTRUCT_LENGTH] is an error
- the first member of a D array is the .length
- first char actually stands where .length uses to be, which
explains the shift.
- I cant use fromStringz because it's not a null terminated string
Re: Git, the D package manager
On Monday, 2 February 2015 at 13:25:57 UTC, Mathias LANG wrote: To be more specific, dub won't let you compile a project with multiple definition of a function. How is that a liability ? You can't have more than one main() function. Some packages contain more than one entry point (programs / executables). In my case, my library allows selecting an entry point based on the nature of the program (console/GUI) and the platform. The program only imports one of these. Vibe does something similar, but it has only one entry point. Is rdmd able to build static and dynamic library ? Yes. If so, does it ignore files that are not imported anywhere ? Yes. I don't see any downside here. The downside is dmd -o- doesn't work. What's your editor ? Mine complains on syntax error. If you're using vi/emacs, then placing your editor in source/ (or starting dmd here) would do the trick. syntax check was not meant literally. Can your editor instantiate imported templates, too? FYI, my editor's D syntax highlighting is probably more extensive than any others': https://github.com/colorer/Colorer-schemes/blob/master/hrc/hrc/base/d.hrc git clone http://github.com/You/repo otherName breaks that workflow equally. Relying on the name under which your repo was cloned doesn't seem that robust. The distinction is that you have to go out of your way to break it. Dub not just breaks it by default, but there is no simple way to work around it, either. - But then your library is self contained and won't break if someone has another workflow that makes him clone your library under a different name. So Dub protects people from shooting themselves in the foot by cutting their feet off? How nice. - dub rely on git tags for versioning. If you want to do *real* versioning (and not just most up to date tag), you'll still have to play with branches and submodules. Yay, more buttons to press! When I could actually be getting things done instead. Hope I helped :) Sorry, not even close.
Re: cast a C char array - offset ?
On Monday, 2 February 2015 at 13:34:28 UTC, ketmar wrote:
On Mon, 02 Feb 2015 13:32:57 +, ketmar wrote:
On Mon, 02 Feb 2015 13:23:23 +, irtcupc wrote:
my current understanding is that:
- C: char CompleteInstr[INSTRUCT_LENGTH] is actually a raw
chunk - D:
defining the member as char[INSTRUCT_LENGTH] is an error -
the first
member of a D array is the .length - first char actually
stands where
.length uses to be, which explains the shift.
nope. fixed length arrays doesn't have dedicated `.length`
member. try
this:
align(1)
struct _Disasm {
align(1):
...
actually, first align is not necessary at all. i.e.:
struct _Disasm {
align(1):
the difference is that `align` before struct tells how
structure should
be packed (i.e. when you have `_Disasm[2] arr`). and `align`
*inside*
struct tells compiler how struct *members* should be packed.
Thx, problem fixed, it works now.
Re: Git, the D package manager
On Monday, 2 February 2015 at 08:52:29 UTC, Vladimir Panteleev wrote: On Monday, 2 February 2015 at 08:46:40 UTC, Daniel Kozak wrote: And this is reason why rdmd suck (in my case). Example: return cast(EntityManagerFactory)Object.factory(cz.dlang.ddpa.EntityManagerFactoryImpl); Object.factory is a misfeature. It causes ALL classes and their virtual methods and everything that they refer, and so on, to be built into the resulting binary, regardless if they're used or not, and regardless if you use Object.factory or not. // this does not work with rdmd but works ok with dub Fix: static import cz.dlang.ddpa; Not ideal solution, but probbably doable. ATM I have xml file with cz.dlang.ddpa.EntityManagerFactoryImpl so maybe I can make it .d file
Re: H1 2015 Priorities and Bare-Metal Programming
On 2/2/2015 1:39 AM, Johannes Pfau wrote: No, it doesn't even come close. * Ports.B += 7 doesn't work. This should not be done with MMIO because the read and write cycles generated are ill-defined and vary based on obscure backend details. In order to implement it you need a Volatile!ubyte wrapper, return by ref and avoid some compiler bugs What compiler bugs? * You do need force-inline to produce halfway decent code Nope. volatileLoad() and volatileStore() do not produce function calls. * You also need to enable backend optimization to produce decent code Not any more true than with volatile types, because the compiler intrinsic actually translates to a volatile type, not a function call. You are making a lot of assumptions that volatileLoad() and volatileStore() do not work. Please try it, examine the generated code, and see.
Re: 2015 H1 Vision
On Sun, 2015-02-01 at 22:46 +0100, Andrej Mitrovic via Digitalmars-d-announce wrote: On 2/1/15, Andrei Alexandrescu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: http://wiki.dlang.org/Vision/2015H1 - Create the D Language Foundation What exactly is this idea about, can you elaborate a bit? Given involvement with SCons (which used to have a foundation, but it seems to have lapsed, but we need it), and Groovy (never had one but almost certainly needs one now), I see three main issues: — A centralized organization supporting the distributed FOSS project, giving other organizations a generalized single point of contact. Also having an organization, not just a collection of individuals, given other organizations confidence in support, continuity and development. — A legally established foundation can be the holder of IP. It makes any debates about licencing, etc. easier if there is a single entity to deal with. Really though this is more to keep other organizations happy and confident. — A foundation can be a funds collection and redistribution entity. Again stuff can happen without a central not for profit organization, but it generates confidence in other organizations if there is one. Strong rather than small intermittent funded activity is more likely with a foundation than without. Then you get the questions of where (in which jurisdiction), and who are the directors and how do they get changed. There are many off-the-shelf organizational structures so it is pick one. The problem of jurisdiction is more difficult these days. The usual knee-jerk reaction is create a 'not for profit' in the USA. (Actually for D, like SCons, this is probably the most sensible start point; for Groovy it is far more difficult and less the right choice.) Unofficial legal opinion is that the USA government is currently very anti any new software language foundations. If true, that makes the Python Software Foundation model not viable. This would leave joining Eclipse or Apache (not really viable for D or SCons I suspect), or the Software Conservancy. A number of projects have gone this route, SCons is considering it since re-establishing a fully independent SCons Foundation is seeming an up-hill struggle. I am not a lawyer. -- 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
Re: Conway's game of life
On 2015-02-02 at 12:23, FG wrote: Cell(0,3) is not a neighbour bit fits the (diff1 == 1 || diff2 == 1) criterion. s/bit/but/
Re: Conway's game of life
Bloody Thunderbird has sent a reply to the OP and not to the NG.
On 2015-02-02 at 11:45, gedaiu wrote:
I don't think that the line of code is wrong. If use the function will check
for neighbours only on diagonals. Having || allows the search on the vertical and
horizontal axis and diagonals.
In short: Yes, alone would check only diagonals, but I forgot to tell you to
also change the ==.
(diff1 == 1 || diff2 == 1) -- bad, accepts whole neighbouring rows and columns
(diff1 == 1 diff2 == 1) -- bad, accepts only neighbouring diagonals
(diff1 = 1 diff2 = 1) -- correct, I think :)
This unittest should show the difference:
unittest {
CellList world = [ Cell(0,0), Cell(0,1), Cell(0,2), Cell(0,3) ];
assertEqual(Cell(1,1).neighbours(world), 3);
}
Cell(0,3) is not a neighbour bit fits the (diff1 == 1 || diff2 == 1) criterion.
Re: Build managers
On Mon, 2015-02-02 at 23:54 +1300, Rikki Cattermole via Digitalmars-d wrote: So I'm going to through a massive spanner in the works here. I want to clarify something first. I love dub and what it stands for. I don't want to change it. I think there is an undercurrent that Dub does need to evolve somewhat. Just before dub came about, I was working on a build manager as well. Except it was based heavily on Maven, but had more native usage. And I am working on the SCons tool – well not actually doing much just now as it all seems to work as those who use it, use it. We should also note that Maven is rapidly following Ant into obscurity as Gradle takes up the central role for all build to do with JVM and Android. The reason I believe this should at least be made out in the open is that we have people who want more control over their project building and dub will not provide that. Especially mixing c/c++ and D. There was a recent suggestion to split dub up into a package manager and builder. This might be a worthwhile alternative as a builder. Here was the spec that I wrote for it: […humans should never have to manually write XML…] Personally I would propose that a build specification should be as declarative as possible but no more, i.e. there is always a need for an element of programming of build. Thus a framework based on an internal DSL has to be the right choice. SCons is on Python, Gradle is on Groovy. SCons is entirely focused on mixed C, C++, Fortran and D systems. It is not perfect, it needs work – not least working on Python 3. Gradle is JVM-based, but now has C++ native code abilities. It is not beyond the bounds of possibility that a D capability could be created. […] -- 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
[Issue 14105] strideImpl fails for 0xFF
https://issues.dlang.org/show_bug.cgi?id=14105 Martin Nowak c...@dawg.eu changed: What|Removed |Added Keywords||pull --- Comment #2 from Martin Nowak c...@dawg.eu --- https://github.com/D-Programming-Language/phobos/pull/2951 --
Re: H1 2015 Priorities and Bare-Metal Programming
On 2 February 2015 at 10:57, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 2/2/2015 1:39 AM, Johannes Pfau wrote: No, it doesn't even come close. * Ports.B += 7 doesn't work. This should not be done with MMIO because the read and write cycles generated are ill-defined and vary based on obscure backend details. In order to implement it you need a Volatile!ubyte wrapper, return by ref and avoid some compiler bugs What compiler bugs? * You do need force-inline to produce halfway decent code Nope. volatileLoad() and volatileStore() do not produce function calls. I think he was referring to ubyte B() and void B(), and not the load/store intrinsics themselves.
Re: 2015 H1 Vision
On Monday, 2 February 2015 at 07:35:07 UTC, Jacob Carlborg wrote: On 2015-02-02 06:57, ketmar wrote: dub is good, but only in limited use cases. so it's almost no sense in using dub if some use cases are not suitable for it: it's way better to adapt build tool that one already using (or write his own) instead of use TWO build tools for different projects. Dub should have been two tools, one for package management and one for building. Indeed. Most of the issues I hear about stem from it trying to do both at the same time. It's a good package manager but unfortunately a not so good build system. This makes me think, once more, of writing a D build system that uses dub only for package dependencies. Atila
Re: Git, the D package manager
On Monday, 2 February 2015 at 08:09:39 UTC, Vladimir Panteleev wrote: In contrast, Dub's default modus operandi is to blindly send to the compiler all *.d files found in the src folder, whether they're actually used or not. Not only can this be slower if not all modules are always used, but it also won't work if the source code contains multiple entry points, forcing you to write complicated configuration files (i.e. do the computer's work for it). To be more specific, dub won't let you compile a project with multiple definition of a function. How is that a liability ? Is rdmd able to build static and dynamic library ? If so, does it ignore files that are not imported anywhere ? 1b. rdmd and D's search path rdmd does not have any additional parameters to set up for where it needs to look for source files, because it relies on the compiler's search mechanism. Thus, if you can build your program with rdmd, dmd -o- program will succeed, and usually vice versa. In contrast, Dub builds its own search path using its JSON configuration files, and has no equivalent of dmd -o-. I don't see any downside here. There is no simple way to syntax-check just one file in a project when using Dub. I rely on this a lot in my workflow - I configured a syntax-check key in my editor, which I use almost as often as I save. A syntax check (dmd -o-) is much faster than a full build, as it skips parsing other parts of the project, code generation, and linking. What's your editor ? Mine complains on syntax error. If you're using vi/emacs, then placing your editor in source/ (or starting dmd here) would do the trick. 2d. Git vs. Dub Unfortunately, the above-described approach is not compatible with Dub: - Dub packages are generally expected to have their source code in a src subdirectory, although you can set the source directory to . in the configuration file. - When cloning repositories, dub does not preserve the repository's directory name (so e.g. fruit will be cloned to ~/.dub/fruit-1.0.0/). Somebody has created a Dub package for my library (excluding certain packages, due to point 1a above), and the other day someone complained that it doesn't work with Dscanner, because of the above issue - the module path ae.dir.module does not correspond to the filesystem path ae-1.0.1/dir/module.d. git clone http://github.com/You/repo otherName breaks that workflow equally. Relying on the name under which your repo was cloned doesn't seem that robust. So, in order to start using Dub, I'd need to: - restructure the directory layout of my library (breaking change) - update all projects which use this library to use Dub instead - give up quick syntax checking - give up commit-granularity versioning - begin maintaining JSON configuration files - begin versioning libraries by hand - install Dub on all my computers, servers, and virtual machines No thanks. - But then your library is self contained and won't break if someone has another workflow that makes him clone your library under a different name. - That's the point. - Addressed; - Semver allows you to do much more, as mentionned before; - It isn't much of a maintainance. You rarely edit dub.json once the base is set. - dub rely on git tags for versioning. If you want to do *real* versioning (and not just most up to date tag), you'll still have to play with branches and submodules. - Only your dev stations. Change my view. Hope I helped :)
Re: Git, the D package manager
On Monday, 2 February 2015 at 13:42:19 UTC, Vladimir Panteleev wrote: On Monday, 2 February 2015 at 13:25:57 UTC, Mathias LANG wrote: To be more specific, dub won't let you compile a project with multiple definition of a function. How is that a liability ? You can't have more than one main() function. Some packages contain more than one entry point (programs / executables). In my case, my library allows selecting an entry point based on the nature of the program (console/GUI) and the platform. The program only imports one of these. Vibe does something similar, but it has only one entry point. You can do that using configuration sections: http://code.dlang.org/package-format#configurations Is rdmd able to build static and dynamic library ? Yes. If so, does it ignore files that are not imported anywhere ? Yes. I don't see how this is a feature. I want all my file parsed and put inside the archive. I don't see any downside here. The downside is dmd -o- doesn't work. It works when you're in source. No difference. What's your editor ? Mine complains on syntax error. If you're using vi/emacs, then placing your editor in source/ (or starting dmd here) would do the trick. syntax check was not meant literally. Can your editor instantiate imported templates, too? I'd like it too, but not ATM :( Is the working directory option working for you ? git clone http://github.com/You/repo otherName breaks that workflow equally. Relying on the name under which your repo was cloned doesn't seem that robust. The distinction is that you have to go out of your way to break it. Dub not just breaks it by default, but there is no simple way to work around it, either. If you go out of dub's way, you might break it. The same happen when someone goes out of your workflow. Is running dmd -o- from ./project/source instead of ./project/ impossible with your setting / IDE ? - dub rely on git tags for versioning. If you want to do *real* versioning (and not just most up to date tag), you'll still have to play with branches and submodules. Yay, more buttons to press! When I could actually be getting things done instead. Want to track a branch: ~branchName Want to track a specific commit: == x.x.x want to track a bounded commit range: ~ / = = Want to track an unbounded commit range: =
Re: Should we remove int[$] before 2.067?
On Monday, 2 February 2015 at 10:28:37 UTC, ketmar wrote: but to work on D3 people should be interested in D. and it seems that people who are interested in D and are ready to work on D development already have some codebases. i don't believe that they will welcome yet another codebase conversion. ;-) Mmmaybe, but I think more people would be more willing to work on the compiler if the goal is to produce a niche language of high standards. Basically, a best of breed for niche X. When features compete in a way that makes it impossible to be the best in any niche, then that basically kills motivation (at least mine). Complex languages that grow are usually best of breed in their niche for solving hard problems. D is getting complicated, but not to solve hard problems. That is not a good tradeoff. There are plenty of simple languages for solving easy problems. but it's matter who is driving force behind the project. yet another D fork from people you never heard about has little chances to be successful. Stability, quality and performance. Kill the less important stuff and move for performance. Performance generally trumps other parameters if you are actively getting benchmarks published IMHO. To get performance you need to focus on one platform first. D is expanding everywhere, even in the standard library... Not good. D cannot build high quality anything without staying focused. High quality means hardware optimized and best of breed. Just take a look at the numerical library in D, basically empty... If you don't have the resources to make the numerical library look complete then leave it all to a third party.
Re: This Week in D: Issue #4
On Monday, 2 February 2015 at 04:57:10 UTC, Adam D. Ruppe wrote: I can't believe it, but yet another week has already passed, so up late to release this again! http://arsdnet.net/this-week-in-d/feb-01.html Early bird registration open for DConf, 2015 Vision released, GUI and Windows development on the forums. Today's tip is about class destructors, and Project Spotlight makes a return to introduce simpledisplay.d, in the first in what will become a series that walks us through making a bit of a little game in D. (Expect this to not be each week, it takes me a long time to write the project spotlight and I've been very busy lately and expect to continue being busy in the coming weeks. I'll probably try to do it every other week rather than every week.) http://www.reddit.com/r/programming/comments/2uhgzr/this_week_in_d_2015_vision_released_tip_on/ https://twitter.com/adamdruppe/status/562112301248290816 Very nice, once again. Looking forward to next part of simpledisplay tutorial. Goal should be to make it run on iOS in 2015 ;)
Re: Git, the D package manager
On Mon, 2015-02-02 at 08:09 +, Vladimir Panteleev via Digitalmars-d wrote: […] 2. git I've found that git's submodule feature is an excellent way to manage dependencies across D libraries, and fits really well with D's package system. For clarity to readers not too familiar with Git, I'll explain by example: […] Go allows for Git, Mercurial and Bazaar. This is a good idea since it obviates the but you are not using the DVCS I want to use problem. The problem with Git is versioning. Gradle, Maven, Herd (Ceylon package repository) handle this easily. Go has a real problem with this and Gustavo created a versioning strategy that works well. cf. http://labix.org/gopkg.in -- 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
Re: Conway's game of life
Uf... you are right!
I've fixed it.
Thanks!
On Monday, 2 February 2015 at 11:23:17 UTC, FG wrote:
Bloody Thunderbird has sent a reply to the OP and not to the NG.
On 2015-02-02 at 11:45, gedaiu wrote:
I don't think that the line of code is wrong. If use the
function will check for neighbours only on diagonals. Having
|| allows the search on the vertical and horizontal axis and
diagonals.
In short: Yes, alone would check only diagonals, but I
forgot to tell you to also change the ==.
(diff1 == 1 || diff2 == 1) -- bad, accepts whole neighbouring
rows and columns
(diff1 == 1 diff2 == 1) -- bad, accepts only neighbouring
diagonals
(diff1 = 1 diff2 = 1) -- correct, I think :)
This unittest should show the difference:
unittest {
CellList world = [ Cell(0,0), Cell(0,1), Cell(0,2),
Cell(0,3) ];
assertEqual(Cell(1,1).neighbours(world), 3);
}
Cell(0,3) is not a neighbour bit fits the (diff1 == 1 || diff2
== 1) criterion.
Re: cast a C char array - offset ?
On 2015-02-02 at 13:16, irtcupc wrote:
The manual section about interfacing from c states that type[] is
inter-compatible from C to D,
however, I face this strange case:
- C declaration:
char identifier[64];
- D declaration:
char[64] identifier;
- the result is only correct if i slice by (- pointer size):
char[64] fromC(char[64] * thing)
{
const offs = size_t.sizeof;
return thing[-offs.sizeof .. $-offs];
}
Is this correct ?
So you have to shift the whole array right by 4 or 8 bytes? Strange.
Looks like an alignment issue. Is identifier part of a bigger structure?
Re: This Week in D: Issue #4
On 2015-02-02 at 05:57, Adam D. Ruppe wrote: I can't believe it, but yet another week has already passed, so up late to release this again! http://arsdnet.net/this-week-in-d/feb-01.html It's great! I have to wonder though, why have you chosen this naming convention: jan-12, jan-18, jan-25, feb-01, ... instead of just 1, 2, ... ? That would make navigation between issues much easier, even without the page with a list of all issues (which I am unable to find). :)
Re: cast a C char array - offset ?
On Mon, 02 Feb 2015 13:23:23 +, irtcupc wrote:
my current understanding is that:
- C: char CompleteInstr[INSTRUCT_LENGTH] is actually a raw chunk - D:
defining the member as char[INSTRUCT_LENGTH] is an error - the first
member of a D array is the .length - first char actually stands where
.length uses to be, which explains the shift.
nope. fixed length arrays doesn't have dedicated `.length` member. try
this:
align(1)
struct _Disasm {
align(1):
...
signature.asc
Description: PGP signature
Re: cast a C char array - offset ?
On Mon, 02 Feb 2015 13:32:57 +, ketmar wrote:
On Mon, 02 Feb 2015 13:23:23 +, irtcupc wrote:
my current understanding is that:
- C: char CompleteInstr[INSTRUCT_LENGTH] is actually a raw chunk - D:
defining the member as char[INSTRUCT_LENGTH] is an error - the first
member of a D array is the .length - first char actually stands where
.length uses to be, which explains the shift.
nope. fixed length arrays doesn't have dedicated `.length` member. try
this:
align(1)
struct _Disasm {
align(1):
...
actually, first align is not necessary at all. i.e.:
struct _Disasm {
align(1):
the difference is that `align` before struct tells how structure should
be packed (i.e. when you have `_Disasm[2] arr`). and `align` *inside*
struct tells compiler how struct *members* should be packed.
signature.asc
Description: PGP signature
Re: Time from timestamp?
On 1/31/15 1:07 AM, Jonathan M Davis via Digitalmars-d-learn wrote: On Friday, January 30, 2015 22:03:02 Jonathan M Davis via Digitalmars-d-learn wrote: Yeah. I really should add a unixTimeToSysTime function, Actually, maybe it should be a static function on SysTime called fromUnixTime to go with toUnixTime. I don't know. Regardless, it's a nicety that should be there, and I botched things by not having it. Might I suggest that you simply define an enum for UnixEpoch that's a SysTime. Then you can do whatever you want. Note that unixTimeToSysTime doesn't help the OP, his timestamp is in milliseconds since 1/1/1970. -Steve
[Issue 14106] sort is @safe in release mode, @system in debug mode
https://issues.dlang.org/show_bug.cgi?id=14106 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu Hardware|x86 |All OS|Mac OS X|All Severity|enhancement |regression --
Re: cast a C char array - offset ?
On 2/2/2015 9:16 PM, irtcupc wrote:
The manual section about interfacing from c states that type[] is
inter-compatible from C to D,
however, I face this strange case:
- C declaration:
char identifier[64];
- D declaration:
char[64] identifier;
- the result is only correct if i slice by (- pointer size):
char[64] fromC(char[64] * thing)
{
const offs = size_t.sizeof;
return thing[-offs.sizeof .. $-offs];
}
Is this correct ?
That's looking pretty wonky. You're slicing a pointer to a fixed-size
array. Why have you declared the parameter as a pointer? What problem
are you trying to solve? It would help a bit to see the declaration of
the C function that's giving you the array.
Re: Git, the D package manager
On Monday, 2 February 2015 at 12:54:02 UTC, Atila Neves wrote: Unless things have changed significantly or I remember incorrectly, vibe.d depends on C code (libevent), which gets built by dub. At least for Windows, Vibe includes pre-built libevent binaries (DLL and import library) in the git repository.
Re: Git, the D package manager
On Mon, 02 Feb 2015 12:54:01 +, Atila Neves wrote: Unless things have changed significantly or I remember incorrectly, vibe.d depends on C code (libevent), which gets built by dub. no, it's not build by dub. at least for GNU/Linux it expects to find it already installed. signature.asc Description: PGP signature
[Issue 14090] [REG2.067a] Incorrect recursive alias declaration
https://issues.dlang.org/show_bug.cgi?id=14090 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #2 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4370 --
Re: Git, the D package manager
On 2/2/2015 7:13 PM, Vladimir Panteleev wrote: On Monday, 2 February 2015 at 10:09:00 UTC, Joseph Rushton Wakeling wrote: Well, as long as the requirements are expressed in the form, package-name: =1.2.3 This will allow Dub to pick a new major version with incompatible changes, no? ~1.2.3 This will constrain it to the range of 1.2.3 ... 1.3.0.
Re: Git, the D package manager
On 2/2/2015 6:34 PM, Vladimir Panteleev wrote: On Monday, 2 February 2015 at 09:25:31 UTC, Mathias LANG wrote: On Monday, 2 February 2015 at 09:03:56 UTC, Vladimir Panteleev wrote: Is that so? Won't a security fix entail a version bump, requiring a change in the requirements file of the parent project? Also, does Dub really check for updated versions of libraries online, every time a project is built? It does. It actually does a roundtrip every time you build your project??? No. It requires 'dub upgrade'.
Re: Git, the D package manager
On Monday, 2 February 2015 at 11:59:07 UTC, ketmar wrote: On Mon, 02 Feb 2015 11:04:29 +, Tobias Pankrath wrote: On Monday, 2 February 2015 at 11:00:20 UTC, Manu wrote: On 2 February 2015 at 18:09, Vladimir Panteleev via Digitalmars-d digitalmars-d@puremagic.com wrote: On Monday, 2 February 2015 at 05:23:52 UTC, Daniel Murphy wrote: [snip] I agree with basically everything you said. I'll add, I have no use for (and no way to use) dub because I depend on cross-language build configurations. If my D project depends on a C lib, then what am I supposed to do to make dub useful for me? I don't understand, can't you just use a C build tool for the C lib and link to it via dub? and then we have TWO build tools. and a script that invokes one, and then another. THREE build tools. see the pattern? Well, we wont convince every C programmer out there whose library one wants to use to switch to dub.
