Re: [OT] Windows dying
On Thursday, 2 November 2017 at 06:28:52 UTC, codephantom wrote: Linus gave a great talk about this important principle back in 2001: https://www.youtube.com/watch?v=WVTWCPoUt8w btw. 36:12 is a good starting point in the video, it's where Ken Thompson (yes, the one and only) asks Linus a question about communal programming.
Re: [OT] Windows dying
On Thursday, 2 November 2017 at 05:13:42 UTC, H. S. Teoh wrote: There is another side to this argument, though. How many times have *you* reviewed the source code of the software that you use on a daily basis? Do you really *trust* the code that you theoretically *can* review, but haven't actually reviewed? Do you trust the code just because some random strangers on the internet say they've reviewed it and it looks OK? I did make that point ;-) Of course you can't even view closed source. So there is no way to audit it, and therefore no way to trust it. Full stop. That cannot be argued against. On the otherhand, just being open source, does not mean it can be trusted - just look at the OpenSSL debacle - that's a great case study if ever there was one.. But Ken Thompson summed it all up nicely: "You can't trust code that you did not totally create yourself." http://vxer.org/lib/pdf/Reflections%20on%20Trusting%20Trust.pdf But the key value of open source, is not that you can (or cannot) trust it, but that it's an enabler of evolution (and sometimes just a slow ;-) Linus gave a great talk about this important principle back in 2001: https://www.youtube.com/watch?v=WVTWCPoUt8w
Re: What is the FreeBSD situation?
On Thursday, 2 November 2017 at 04:25:26 UTC, Andrei Alexandrescu wrote: From the recent PR-related discussion I gather that FreeBSD 12 has made some breaking changes to file primitives such as stat. Do binaries built for pre-v12 crash on v12? If that's the case we should have two distinct build platforms, FreeBSD "legacy" and FreeBSD 12. They would be selected statically. IF older binaries don't crash, what mechanism is FreeBSD 12 using to identify old API calls? Thanks, Andrei Targetted versioning should be implemented. Full stop ;-) Pre ino64 ABI compatibility can be obtained in 12, **if** the kernel is compiled with option COMPAT_FREEBSD11 (presumably this option is enabled in the DEFAULT kernel)... That option enables 'several techniques' that can mitigate for ABI breakage, but it won't work for all cases - really depends on what the application is doing with struct stat. https://svnweb.freebsd.org/base/head/sys/sys/stat.h?view=markup#l158
Re: [OT] Windows dying
On Thu, Nov 02, 2017 at 04:13:39AM +, codephantom via Digitalmars-d wrote:
> On Wednesday, 1 November 2017 at 18:42:07 UTC, Bo wrote:
> > /Signed: A pissed off Windows user
>
> I think you've summed it all up right there ;-)
>
> But seriously, Windows rightly has its place... and for good reasons.
>
> Most importantly, it provided the ease of installation along with a
> easy to use and easy to understand GUI, that simply could not be
> provided by open source alternatives.
It's a matter of opinion. *I*, personally, find Windows atrociously
hard to do anything useful in. I get an aneurysm trying to click
through countless nested menus just to find that one button I need, when
I could have typed the right command in 3 seconds in a Bash shell. But
OTOH, I also know that my opinion is in the minority (by far!). :-P I
think it just boils down to personal preference and habit built from
past familiarity. As they say, there is no accounting for taste.
One thing is clear, though: claiming that Windows is "dead" is, frankly,
ridiculous. Even a non-Windows person like me who rarely has any reason
to notice things Windows-related, can see enough circumstantial evidence
around me that Windows is still very much alive and kicking. (Even if
in my ideal world there would be no Windows... but then, if the world
were my ideal, 90% of computer users out there would probably be very
angry about being forced to use obscure text-only interfaces that I'm
completely comfortable in. So it's probably not a bad thing the real
world doesn't match my ideal one. :-D)
[...]
> But software is for the user, not the vendor. A user should be able to
> adapt software to meet their own requirements. Closed source prevents
> that.
>
> I think open-source really is the future, and Windows will fade into
> obscurity - but only if open source continues to deliver the benefits
> that Windows has always been able to deliver. If that keeps occuring,
> then there is little justification for having a closed source
> operating system - whether you call it Windows or whatever.
>
> And I think trust will become a bigger issue in the near future
> too...i.e. how can you trust code you can't view? You can barely even
> trust code you can view ;-)
[...]
There is another side to this argument, though. How many times have
*you* reviewed the source code of the software that you use on a daily
basis? Do you really *trust* the code that you theoretically *can*
review, but haven't actually reviewed? Do you trust the code just
because some random strangers on the internet say they've reviewed it
and it looks OK?
It is a common argument among open source proponents that having more
eyes will reduce the number of bugs... It sounds convincing, but the
problem with that, is that this only works when there is a relatively
small amount of code and a very large pool of potential reviewers.
Unfortunately, the hard reality today is that there is so much open
source code out there, and the rate at which open source code is being
written far exceeds the rate of growth of the number of open source
reviewers, that I'd venture to say 80-90% of open source code out there
has never seen more than a very small number of reviewers. Probably not
more than 1 or 2 for a significant fraction of it, if even that. I have
seen open source code that probably has *never* been reviewed, because
any review would have instantly brought to light the blatantly-obvious
bugs and problems that riddle just about every page of code. And some
of that code is so ugly that even if I had personally reviewed it to
death, I still wouldn't trust anything that depends on it, sorry to say.
And among the scant few projects that do get above average contributors
(and thus code reviewers), we *still* have bugs like Heartbleed that go
undetected for *years*. And this is in cryptographic code that,
ostensibly, undergoes far more careful scrutiny than more "ordinary"
code. Where does that leave the trust level of said ordinary code?
Especially code that comes from lesser projects that don't enjoy the
same level of review as high-visibility projects like OpenSSL?
That's not to say that proprietary code is any better, though. Having
worked in proprietary software development ("enterprise" software
development) for the past 2 decades or so, I can say that the code
quality isn't any better. Just because you pay somebody to do the job
doesn't guarantee they'll do a *good* job, let's just put it that way.
There's a widespread mentality of "not my problem" that goes around in
proprietary software development. You don't want to touch some ugly
code that isn't directly your responsibility, because it could break and
the blame would fall on you. You often don't know why something was
written a certain way -- it could be part of an elaborate bugfix for a
critical customer bug, so you really don't want to touch it and break
things. So you just work around it in the code you *are* responsib
Re: What is the FreeBSD situation?
On Thursday, November 02, 2017 00:25:26 Andrei Alexandrescu via Digitalmars- d wrote: > From the recent PR-related discussion I gather that FreeBSD 12 has made > some breaking changes to file primitives such as stat. > > Do binaries built for pre-v12 crash on v12? If that's the case we should > have two distinct build platforms, FreeBSD "legacy" and FreeBSD 12. They > would be selected statically. > > IF older binaries don't crash, what mechanism is FreeBSD 12 using to > identify old API calls? Technically speaking, with how FreeBSD deals with its API/ABI, it promises compatibility across major releases but not minor ones, so _any_ time you go up a major version, there's a risk of breakage (though I don't know how often APIs get changed in practice). In that respect, the fact that we've been doing FreeBSD releases that don't target a particular version of FreeBSD is kind of crazy, though for the most part, I think that the API and ABI have not changed sufficiently in the areas that matter to dmd or Phobos for it to be a big issue, though occasionally, fixes have had to be made because something worked on one version of FreeBSD but not another. But we don't currently have a way to version code for a particular version of FreeBSD even if we wanted to. So, while we could do separate builds for different versions of FreeBSD (and thus handle ABI changes), the source code would have to be the same. AFAIK, the closest that we can currently come to versioning the source code based on the version of FreeBSD is to check the uname at runtime and run different code depending on the version, but that obviously doesn't work in all situations. Right now, what we have mostly works on FreeBSD 10.x and 11.x (it looks like 64-bit has a dmd test failure, and 32-bit has a Phobos test failure) as well as older versions of 12-to-be (that's what I run locally, since that's what TrueOS is based on), but several months ago, FreeBSD did make changes to stat and related functions so that inodes are 64-bit, and that obviously changed the API. They did a lot of work to make that compatible so that programs didn't just break, but the compatibility stuff that they did was for C/C++, and we don't use C/C++ headers; we duplicate their declarations in D. So, we have to do work of some kind to be compatible, and I'm not familiar enough with the details to know what needs doing. The related bug report is https://issues.dlang.org/show_bug.cgi?id=17596 and some work has been done to figure out what needs doing including a suggested way to wrap the API changes at least until we're only supporting FreeBSD 12+ (which is quite a ways off, since it hasn't even been released yet). I don't know exactly what the situation with that currently is. I keep hoping that it will be sorted out by December, since that's when the next TrueOS update happens, and then it'll be based on a new enough version of FreeBSD 12 that D will break if I upgrade, but I haven't had time to look into it, and clearly those who looked into it previously haven't finished doing whatever needs doing. - Jonathan M Davis
Re: Improve "Improve Contract Syntax" DIP 1009
On Thu, Nov 02, 2017 at 03:40:17AM +, codephantom via Digitalmars-d wrote: > On Wednesday, 1 November 2017 at 22:04:10 UTC, Andrei Alexandrescu wrote: > > There are some unsupported claims Sigh. At the time of the review, I *did* mention that it needs to be clearer in its presentation and especially should include the rationale for the syntax as proposed. However, the response I got was "it's not necessary, because it already references the previous versions of the DIP and therefore ought to be clear already". Well, so much for that. > Well, I'm struggling with the 'claims' on which the DIP mounts its > argument. > > (1) That the current syntax for contract programming limits its > usability. This could have been better worded. It doesn't technically *limit* anything, but is more of a deterrent to using contracts because doing so with the current syntax brings quite a bit of verbosity to the code. A lot of the arguments and reasonings happened on the forum review thread, which *should* have been included in summary form in the final version of the DIP. But it didn't. *sigh* > (2) That the more concise syntax being proposed, is both easier to > read and write, and will therefore increase the usage of contract > programming. [...] > The evidence for claim (2) is?? > > Claims asserted as true without justification are just assumptions. > > DIP authours would do well too study the Toulmin method of > argumentation. This is uncalled for. This DIP did go through extensive review and discussion on the forum review threads, and actual code examples and syntax alternatives were put forth and argued for/against. There was ample evidence in the form of testimonials from various D users about the verbosity of the current cumbersome syntax, and this DIP certainly was not the first time this issue was brought up. Calling it mere "assumptions" is a bit heavy-handed, given the actual precedents. It's not entirely your fault, though, since you probably were not here at the time, and wouldn't have been aware of said discussions. This is why the DIP should have included all of those discussions (in summary form, of course), which is its only real fault here. I did raise this issue, but it wasn't heeded to. The argument at the time was that summarizing the discussions in the forum threads was unnecessary because, supposedly, Walter and Andrei would have already seen the discussions, and it was thought better to minimize the workload on their part by shortening the DIP. Well, that didn't quite go so well, did it? Now somebody will have to go through those review threads, summarize them, and add them to the DIP. T -- ASCII stupid question, getty stupid ANSI.
What is the FreeBSD situation?
From the recent PR-related discussion I gather that FreeBSD 12 has made some breaking changes to file primitives such as stat. Do binaries built for pre-v12 crash on v12? If that's the case we should have two distinct build platforms, FreeBSD "legacy" and FreeBSD 12. They would be selected statically. IF older binaries don't crash, what mechanism is FreeBSD 12 using to identify old API calls? Thanks, Andrei
Re: [OT] Windows dying
On Wednesday, 1 November 2017 at 18:42:07 UTC, Bo wrote: /Signed: A pissed off Windows user I think you've summed it all up right there ;-) But seriously, Windows rightly has its place... and for good reasons. Most importantly, it provided the ease of installation along with a easy to use and easy to understand GUI, that simply could not be provided by open source alternatives. Things have changed a lot though, over the last decade. The only thing I can think of, that is wrong with Windows, is that you can't fork it. Therefore it cannot evolve, unless the vendor wants it to, and even then, only in the way the vendor wants it to. But software is for the user, not the vendor. A user should be able to adapt software to meet their own requirements. Closed source prevents that. I think open-source really is the future, and Windows will fade into obscurity - but only if open source continues to deliver the benefits that Windows has always been able to deliver. If that keeps occuring, then there is little justification for having a closed source operating system - whether you call it Windows or whatever. And I think trust will become a bigger issue in the near future too...i.e. how can you trust code you can't view? You can barely even trust code you can view ;-) Having a go at a platform is not the same as having a go at the users of the platform. Please understand the difference. Even in the open source world, opinions differ... a lot. /Signed: Happy FreeBSD user.
Re: Improve "Improve Contract Syntax" DIP 1009
On Wednesday, 1 November 2017 at 22:04:10 UTC, Andrei Alexandrescu wrote: There are some unsupported claims Andrei Well, I'm struggling with the 'claims' on which the DIP mounts its argument. (1) That the current syntax for contract programming limits its usability. (2) That the more concise syntax being proposed, is both easier to read and write, and will therefore increase the usage of contract programming. The problem with the DIP, as I see it, is: The evidence for claim (1) is presumably points 1,2,3 in the Rationale. However, there is no convincing evidence to suggest there really is a connection between those points and that claim. The evidence for claim (2) is?? Claims asserted as true without justification are just assumptions. DIP authours would do well too study the Toulmin method of argumentation.
Re: Improve "Improve Contract Syntax" DIP 1009
On Wednesday, 1 November 2017 at 22:04:10 UTC, Andrei Alexandrescu wrote: We're having difficulty reviewing https://github.com/dlang/DIPs/blob/master/DIPs/DIP1009.md. The value is there, but the informal and sometimes flowery prose affects the document negatively. There are some unsupported claims and detailed description is sketchy. We need a careful pass that replaces the unclear or imprecise statements with clear, straightforward scientific claims. Can anyone help with this? For example, the first paragraph: "D has already made a significant commitment to the theory of Contract Programming, by means of its existing in, out, and invariant constructs. But limitations remain to their usability, both in their syntax and in their implementation. This DIP addresses only the syntax aspect of those limitations, proposing a syntax which makes in, out, and invariant contracts much easier to read and write." could be: "The D language supports Contract Programming by means of its in, out, and invariant constructs. Their current syntactic form is unnecessarily verbose. This DIP proposes improvements to the contract syntax that makes them easier to read and write." The change: * eliminates the entire "implementation sucks" allegation which seems taken straight from a forum flamewar; * replaces adjective-laden language with simple and precise statements; * provides a brief factual overview of what follows. Who wants to help? Andrei This actually makes the DIP slightly longer but hopefully makes it more clear. https://github.com/dlang/DIPs/pull/95 I'm heading off to bed so I won't be able to respond right away to suggested changes.
Re: Link errors when compiling shared lib on windows
On Wednesday, 1 November 2017 at 16:02:37 UTC, Daniel Fitzpatrick wrote: On Wednesday, 1 November 2017 at 15:52:17 UTC, kinke wrote: On Wednesday, 1 November 2017 at 15:15:27 UTC, Daniel Fitzpatrick wrote: I am following this short tutorial on compiling a shared lib: https://wiki.dlang.org/Call_D_from_Ruby_using_FFI Because it's on Windows I am using these compiler options: -shared -m64 -defaultlib=libphobos2.so i.d However, I am receiving rather a lot of linker errors. Not sure what else to provide the compiler. Try less, especially no `-defaultlib` overridden with a Linux shared-object. You'll have to edit the hardcoded `./i.so` in the example as well obviously. Oops, missed that! What i've tried is -shared -m64 i.d -shared -m64 -defaultlib=libphobos2.dll i.d Still seeing a lot of linker errors. Errors for the former: There's no shared library of Phobos for Windows with either DMD or LDC. You have to statically link to it.
Re: [OT] Windows dying
On Wednesday, 1 November 2017 at 21:55:56 UTC, Joakim wrote: [snip] I'm not sure anybody cares about these market share arguments anyway. Ha, fair enough.
Re: TLS + LDC + Android (ARM) = FAIL
On Wednesday, 1 November 2017 at 21:50:09 UTC, Johannes Pfau wrote: Am Wed, 01 Nov 2017 19:24:42 + schrieb Joakim : On Wednesday, 1 November 2017 at 18:28:12 UTC, Johannes Pfau wrote: > ARM: Fine. Android: probably won't work well. AFAIK we're > only missing emulated TLS / GC integration, so most test > will pass but real apps will crash because of GC memory > corruption. I guess I should finally get back to fixing that > problem ;-) OTOH Android doesn't even support GCC anymore, > so I don't really see much benefit in maintaining GDC > Android support. I don't see what their deciding to drop gcc has to do with whether gdc should support Android. If there's a backend bug in GCC related to Android nobody will take responsibility as it's not officially supported. All tutorials and documentation will focus on LLVM based compilers. It's certainly still interesting to use GDC for Android, but it is more work (especially considering Android is one of the few systems requiring emutls) for little benefit, especially if most users are going to use LLVM anyway. With the limited time available I think GDC should focus on systems where GCC is a first class or even the preferred compiler. X86/MIPS/ARM/PPC/Linux as some distributions such as debian might prefer a GCC based compiler. Then there are embedded toolchains which primarily use GCC: MSP and ARM (GCC Arm Embedded project). Also many console homebrew toolchains exclusively use GCC. I just don't think we have to support two compilers for any target with the little resources we have. Here's the thing though: Android is basically just linux/ARM without native TLS and replacing glibc with the bionic C runtime. If you're going to support linux/ARM with glibc, it's not going to take much to support Android too, particularly since I upstreamed all my Bionic declarations and support into stock druntime. Far be it from me to tell you what to work on, and I realize getting emulated TLS working with the garbage-collector is a pain, but it won't take much more than emulated TLS for gdc to support Android. If you grep the llvm codebase for Android, you find almost nothing, basically just emulated TLS. I agree that we don't need two D compilers for every platform, but it'd be nice to have for the most widely deployed OS platform on the planet. ;)
Improve "Improve Contract Syntax" DIP 1009
We're having difficulty reviewing https://github.com/dlang/DIPs/blob/master/DIPs/DIP1009.md. The value is there, but the informal and sometimes flowery prose affects the document negatively. There are some unsupported claims and detailed description is sketchy. We need a careful pass that replaces the unclear or imprecise statements with clear, straightforward scientific claims. Can anyone help with this? For example, the first paragraph: "D has already made a significant commitment to the theory of Contract Programming, by means of its existing in, out, and invariant constructs. But limitations remain to their usability, both in their syntax and in their implementation. This DIP addresses only the syntax aspect of those limitations, proposing a syntax which makes in, out, and invariant contracts much easier to read and write." could be: "The D language supports Contract Programming by means of its in, out, and invariant constructs. Their current syntactic form is unnecessarily verbose. This DIP proposes improvements to the contract syntax that makes them easier to read and write." The change: * eliminates the entire "implementation sucks" allegation which seems taken straight from a forum flamewar; * replaces adjective-laden language with simple and precise statements; * provides a brief factual overview of what follows. Who wants to help? Andrei
Re: [OT] Windows dying
On Wednesday, 1 November 2017 at 21:19:55 UTC, jmh530 wrote: On Wednesday, 1 November 2017 at 19:49:04 UTC, Joakim wrote: As for saying Windows is dying, that is a factual examination of the data When you say it is dying, I (and perhaps most others) would assume the argument you are making is that not only is Windows in decline, but also that it is about to no longer exist as a meaningful platform for programmers to code on. This is a forecast about the future. However, the future is inherently un-knowable. Forecasts are opinions. While these forecasts may be based on facts and people could disagree about the likelihood of the forecast or their confidence in the forecast, it is opinion. It is not fact. I wouldn't dispute that Windows is in decline. I looked up the stack overflow survey of platforms that people program on and added up the Windows components from 2013 to 2016. In 2013 it was 60.4% and steadily fell to 52.2% in 2016. The largest growth of the share was OS X (not Linux). However, even falling from 60% to 50%, it's still 50%. That's huge. And this is programmers who use Stack Overflow, not normal users. Look at the developer environment and its either Visual Studio or a text editor (Sublime or Notepad++) as most popular. The evidence says it is in decline. And the trend doesn't look good. However, that doesn't mean it's going away. It also doesn't mean you can project the current trend into the future at the current rate or at a faster or slower rate. Who knows what the rate could be. What matters is that half of all developers (by this measure) use Windows now. Who knows what the equilibrium will be? Maybe it will stabilize at roughly equal shares across shares across Linux/OSX/Windows. Maybe Windows will become niche (in which case you could conceivably make the argument that it's dying). God only knows. But you cannot say that it is all fact and not opinion. It is opinion. It is a forecast. [1] https://insights.stackoverflow.com/survey/2016 I say dying, you say decline, no point in debating the semantics. I will agree with you that we don't know how soon Windows will actually, effectively die: an imminent collapse is merely my forecast, which I tried to back up with data and examples of how mobile is gunning to kill it off. Dying tech can sometimes rebound for some time, so it is certainly possible for Windows. But ultimately all this discussion of market share won't matter if nobody wants to do the work. Windows has historically been the dominant tech platform and D's support for it is much more advanced than its support for the currently dominant platform, Android, which I'm the only person working on. I'm trying to influence people to work more on Android and less on Windows, based on the aforementioned market share and product data. You presumably believe Windows won't fade that fast and should still receive a higher level of investment than I would recommend. We've each made our case. Given the current levels of investment, I'm not sure anybody cares about these market share arguments anyway. ;) More likely, it is completely idiosyncratic, just based on the need, skill, and time of the particular D dev. We can only hope that this data and argument has had some influence on the community.
Re: TLS + LDC + Android (ARM) = FAIL
Am Wed, 01 Nov 2017 19:24:42 + schrieb Joakim : > On Wednesday, 1 November 2017 at 18:28:12 UTC, Johannes Pfau > wrote: > > ARM: Fine. Android: probably won't work well. AFAIK we're only > > missing emulated TLS / GC integration, so most test will pass > > but real apps will crash because of GC memory corruption. I > > guess I should finally get back to fixing that problem ;-) OTOH > > Android doesn't even support GCC anymore, so I don't really see > > much benefit in maintaining GDC Android support. > > I don't see what their deciding to drop gcc has to do with > whether gdc should support Android. If there's a backend bug in GCC related to Android nobody will take responsibility as it's not officially supported. All tutorials and documentation will focus on LLVM based compilers. It's certainly still interesting to use GDC for Android, but it is more work (especially considering Android is one of the few systems requiring emutls) for little benefit, especially if most users are going to use LLVM anyway. With the limited time available I think GDC should focus on systems where GCC is a first class or even the preferred compiler. X86/MIPS/ARM/PPC/Linux as some distributions such as debian might prefer a GCC based compiler. Then there are embedded toolchains which primarily use GCC: MSP and ARM (GCC Arm Embedded project). Also many console homebrew toolchains exclusively use GCC. I just don't think we have to support two compilers for any target with the little resources we have. -- Johannes
Re: TLS + LDC + Android (ARM) = FAIL
Am Wed, 01 Nov 2017 18:32:37 + schrieb Igor Shirkalin : > On Wednesday, 1 November 2017 at 18:28:12 UTC, Johannes Pfau > wrote: > > Am Wed, 01 Nov 2017 17:42:22 + > > schrieb David Nadlinger : > > > >> On Wednesday, 1 November 2017 at 17:30:05 UTC, Iain Buclaw > >> wrote: > >> > [...] > >> > >> Or quite possibly fewer, depending on what one understands > >> "platform" and "support" to mean. ;) > >> > >> What is the state of GDC on Android/ARM – has anyone been > >> using it recently? > >> > >> — David > >> > > > > ARM: Fine. Android: probably won't work well. AFAIK we're only > > missing emulated TLS / GC integration, so most test will pass > > but real apps will crash because of GC memory corruption. I > > guess I should finally get back to fixing that problem ;-) OTOH > > Android doesn't even support GCC anymore, > > > so I don't really see much benefit in maintaining GDC Android > > support. > > -- Johannes > > That's too bad. I'd do it here for food. > > - Igor > I understand that D support for Android is important. I just think that if google now supports only LLVM for Android, focusing on a LLVM based compiler such as LDC is a more reasonable way to support Android. -- Johannes
Re: [OT] Windows dying
On Wednesday, 1 November 2017 at 21:19:55 UTC, jmh530 wrote: When you say it is dying, I (and perhaps most others) would assume the argument you are making is that not only is Windows in decline, but also that it is about to no longer exist as a meaningful platform for programmers to code on. I would rephrase part of this as: "...but also that it is, at some point in the near future, to no longer exist..."
Re: TLS + LDC + Android (ARM) = FAIL
On Wednesday, 1 November 2017 at 18:06:29 UTC, Joakim wrote: If you're having problems with the emulated TLS I put together for Android, it is most likely because I didn't document well what needs to be done when linking for Android. Specifically, there are three rules that _must_ be followed: 1. You must use the ld.bfd linker, ld.gold won't do. 2. You must have a D main function, even for a shared library (which can be put next to android_main, if you're using the default Android wrapper from my D android library). 3. The ELF object with the D main function must be passed to the linker first. If you look at my examples on the wiki, you'll see that they all follow these rules: https://wiki.dlang.org/Build_D_for_Android I should have called these rules out separately though, like I'm doing here, a documentation oversight. I've added a new section to the Android wiki page with this info, and some more relevant details: https://wiki.dlang.org/Build_D_for_Android#Changes_for_Android
Re: [OT] Windows dying
On Wednesday, 1 November 2017 at 19:49:04 UTC, Joakim wrote: As for saying Windows is dying, that is a factual examination of the data When you say it is dying, I (and perhaps most others) would assume the argument you are making is that not only is Windows in decline, but also that it is about to no longer exist as a meaningful platform for programmers to code on. This is a forecast about the future. However, the future is inherently un-knowable. Forecasts are opinions. While these forecasts may be based on facts and people could disagree about the likelihood of the forecast or their confidence in the forecast, it is opinion. It is not fact. I wouldn't dispute that Windows is in decline. I looked up the stack overflow survey of platforms that people program on and added up the Windows components from 2013 to 2016. In 2013 it was 60.4% and steadily fell to 52.2% in 2016. The largest growth of the share was OS X (not Linux). However, even falling from 60% to 50%, it's still 50%. That's huge. And this is programmers who use Stack Overflow, not normal users. Look at the developer environment and its either Visual Studio or a text editor (Sublime or Notepad++) as most popular. The evidence says it is in decline. And the trend doesn't look good. However, that doesn't mean it's going away. It also doesn't mean you can project the current trend into the future at the current rate or at a faster or slower rate. Who knows what the rate could be. What matters is that half of all developers (by this measure) use Windows now. Who knows what the equilibrium will be? Maybe it will stabilize at roughly equal shares across shares across Linux/OSX/Windows. Maybe Windows will become niche (in which case you could conceivably make the argument that it's dying). God only knows. But you cannot say that it is all fact and not opinion. It is opinion. It is a forecast. [1] https://insights.stackoverflow.com/survey/2016
Re: Required Reading: "How Non-Member Functions Improve Encapsulation"
On Wed, Nov 01, 2017 at 03:38:32AM +, codephantom via Digitalmars-d wrote: > On Tuesday, 31 October 2017 at 15:45:42 UTC, H. S. Teoh wrote: > > The one case where the difference matters is when you're trying to > > debug something. In that case, I'd say the onus is really upon the > > debugger to tell you what kind of function it was. > > Yes, this is my main concern I guess, as I use pretty plain editors > that tell me nothing. I rely on the code to tell me what I need to > know. [...] > I guess with a more enhanced editor I could just mouse over UFCS > syntax, and it could identify a free function from a member function. > That would be nice, since there's no other way to know without > exploring code elsewhere... I'm a vim user, and frankly, I don't find the need for "enhanced" editors at all. (I don't even use syntax highlighting, but that's another story. :P) If there's a function call that could be either a member function or a UFCS free function, all I need is to have the debugger print a stacktrace and that ought to clear things up. It will even resolve other issues like telling me exactly which overload is being called, if there are complicated overload sets, and point me to the exact file/line of the code. At that point, the difference between UFCS free function or member function is basically irrelevant. > I guess the days of use a plain text editor...are slowly coming to and > end ;-( [...] Nope. Plain text editors still rule. GUIs are for wimps. :-P T -- The best way to destroy a cause is to defend it poorly.
Re: [OT] Windows dying
On Wednesday, 1 November 2017 at 18:42:07 UTC, Bo wrote: For a dying platform as so many advocate here, it seems to be doing fairly well. Maybe i am too old but the whole dying platform gig has been doing all the way to Windows ME and Vista and 8 and ... The reality is, for any user that wants to be productive Windows is hard to beat. The only thing that comes close is the extreme hardware restrictive OSx from Apple. I do think that people here have a massive anti Microsoft bias by just reading the comments. Mobile will overtake PC for productivity? No ... simply no. Windows is dying? Hardly... Has the market changed because some users can use tablets, as they are not hardcore user but only want to simply browse and mail? Yes... There has been a shift there. But will Windows be out fazed on the corporate floor? No ... Will Windows be removed as a gaming platform and replaced by Linux / OSx? No ... While Linux and OSx can be used very well, both platforms share too many issues. OSx being hardware limited by design, as it makes testing more easy for Apple. Linux as a market that is so fragmented on the desktop level. At times people may want to appreciate the level of robustness that Windows is. Its easily as stable like Linux but has the support level for almost every piece of hardware. With the inclusion of WSL ( guess what i use D on because, well, i do not want to install VS! ), it combines both world. Maybe for some people the reason why they are being so annoying and frankly rude, is there own bias is getting in the way of the message. Its not because a person wants to write D code, that they want to install a multi GIGABYTE installation just so they can compile 64bit programs. Same with the comments that come down to "i do not see a reason why you want 64bit on Windows", is not a good excuse. On Wednesday, 1 November 2017 at 09:24:57 UTC, Joakim wrote: I don't propose ignoring it, but I suggest not to invest too much more into it, like all the work it would take to get VS or other Windows IDE support up to the level where Windows devs seem to want. Its just shows a pure vileness to Windows users as "We do not care to fix issues on your platform, use our platform or install VS and have it bit rote on your hard drive for no reason beyond we simply do not want to support Windows on D". No wonder some people think that Windows is a second tier citizen in the D community. It sure as hell does not feel very welcoming reading this thread. When a person has a issue, the response seem to be very aggressive attacking that person and the platform but ignoring the actual issue. How many people posted here claiming that he wanted to have 64bit removed, when it was NOT what he wrote. There is a issue with Windows. The whole attacking the messenger, the whole idiotic argumentation's that Windows is dying, it is all pure useless trolling the people who ask a simple questions: How to solve the D 64bit issue so that like on the Linux or OSx platform, the users can have the SAME level of consistency. Its so strange that Go has solved the 64bit Windows a long time ago. Or C. Or C++ ... and so many other compilers that do NOT need VS installed to produce 64bit binaries on the Windows platform. So in other words, all these comments about just install VS are pure bullshit. If you do not like to answer the question, then do not troll people. And frankly, Walter or whoever, there needed to have been put a stop to this anti Windows bullshit several days ago. As long as people use this level of disrespect towards community members because they are not using the "right" platform. /Signed: A pissed off Windows user Your rant is rife with mistakes, both factual and perceived. Your main claim seems to be that Windows users who want to use D but don't want VS are being attacked, because the D devs are too lazy to find a way to do that. More likely, that's considered a niche use case that the D devs on Windows don't want to bother with, since most developing for Windows probably use VS already, just like you have to use Xcode on macOS or for iOS. As for saying Windows is dying, that is a factual examination of the data with one recommendation/application: don't bother spending a lot of time on improving D's Windows IDE support. Nobody suggested it had anything to do with supporting Windows users who don't use VS, and it's bonkers to suggest it means we're "anti-Windows" or shows "disrespect" for Windows users. We don't support Haiku OS either, it's not because we're anti-Haiku or disrespect its users. It's just too small and niche for us to care. The evidence is that Windows is heading that way too.
Re: [OT] Windows dying
On Wednesday, 1 November 2017 at 18:59:21 UTC, Adam D. Ruppe wrote: Windows 32 bit is the special one - it is the ONLY platform where D works out of the box without additional downloads. That's one reason why I advocate it for just playing around - it just works. On ALL other platforms for dmd: Win64, Linux 32/64, Mac, freebsd, you require additional downloads from the OS vendor to build your program. The only difference is size of the download from the OS vendor, and odds that it was already installed by something else. But it is the same idea - you use the OS vendor's linker and system libs to facilitate interoperability with other language code. DMD with the default -m32 is great for just playing around. No Windows D user would deny it. I compile with that far more than with -m64 (or any LDC for that matter). It's only really when you need -m64 (or -m32mscoff for that matter), and I mean really need it, that one needs to bother with Visual Studio. Perhaps that's part of the frustration. Things are so easy with the default and so frustrating when you have to make the change. For me, that point comes when trying to call C libraries in D. Downloading Visual Studio and installing it is a one-time cost, but getting C libraries working with D is something I don't do enough to remember the tricks. If the C library is compiled with Visual Studio, then you have to use the VS linker. But it usually will be something MinGW or Cygwin. From there, you might have some series of steps that I would never remember and always need to google to get it working. That's the frustrating part. Installing Visual Studio is annoying, but not really a huge deal for me in the grand scheme of things.
Re: TLS + LDC + Android (ARM) = FAIL
On Wednesday, 1 November 2017 at 18:28:12 UTC, Johannes Pfau wrote: ARM: Fine. Android: probably won't work well. AFAIK we're only missing emulated TLS / GC integration, so most test will pass but real apps will crash because of GC memory corruption. I guess I should finally get back to fixing that problem ;-) OTOH Android doesn't even support GCC anymore, so I don't really see much benefit in maintaining GDC Android support. I don't see what their deciding to drop gcc has to do with whether gdc should support Android. On Wednesday, 1 November 2017 at 18:56:00 UTC, Igor Shirkalin wrote: Everything was beautiful for Win/Linux/iOS/Android. Some day we had to use LDC (for some obvious reasons). I marked every function with @nogc and pure (it helped me to optimize the code). The problem is TLS. Android doesn't support it. At all. If you understand I talk about -betterC feature. Android doesn't have native TLS, but __thread-annotated variables will work with clang: it uses emulated TLS. betterC is not going to save you, many parts of the standard library won't work with it. Please open an issue for ldc. In it, give us as much relevant detail as you can. Are you building the D component as a separate shared library or does it just get linked into a single binary with your C/C++ code? Are you making sure to initialize the D runtime using rt_init, as described here? https://wiki.dlang.org/Runtime_internals Have you followed the three linking rules for emulated TLS that I laid out in an earlier post? Put that info in an issue on the ldc github and we can help you out.
Re: TLS + LDC + Android (ARM) = FAIL
On Wednesday, 1 November 2017 at 18:33:45 UTC, Iain Buclaw wrote: On 1 November 2017 at 19:28, Johannes Pfau via Digitalmars-d wrote: Am Wed, 01 Nov 2017 17:42:22 + schrieb David Nadlinger : [...] ARM: Fine. Android: probably won't work well. AFAIK we're only missing emulated TLS / GC integration, so most test will pass but real apps will crash because of GC memory corruption. I guess I should finally get back to fixing that problem ;-) OTOH Android doesn't even support GCC anymore, so I don't really see much benefit in maintaining GDC Android support. -- Johannes What's the thread model on Android? You could perhaps get away with --enable-threads=single. I didn't pick this option up. We need multithreading.
Re: [OT] Windows dying
On Wednesday, 1 November 2017 at 18:42:07 UTC, Bo wrote: There is a issue with Windows. The whole attacking the messenger, the whole idiotic argumentation's that Windows is dying, it is all pure useless trolling the people who ask a simple questions: How to solve the D 64bit issue so that like on the Linux or OSx platform, the users can have the SAME level of consistency. Windows 32 bit is the special one - it is the ONLY platform where D works out of the box without additional downloads. That's one reason why I advocate it for just playing around - it just works. On ALL other platforms for dmd: Win64, Linux 32/64, Mac, freebsd, you require additional downloads from the OS vendor to build your program. The only difference is size of the download from the OS vendor, and odds that it was already installed by something else. But it is the same idea - you use the OS vendor's linker and system libs to facilitate interoperability with other language code.
Re: TLS + LDC + Android (ARM) = FAIL
On Wednesday, 1 November 2017 at 18:30:28 UTC, Johannes Pfau wrote: Am Wed, 01 Nov 2017 18:06:29 + schrieb Joakim : On Wednesday, 1 November 2017 at 17:24:32 UTC, Igor Shirkalin wrote: > [...] If you're having problems with the emulated TLS I put together for Android, it is most likely because I didn't document well what needs to be done when linking for Android. Specifically, there are three rules that _must_ be followed: 1. You must use the ld.bfd linker, ld.gold won't do. 2. You must have a D main function, even for a shared library (which can be put next to android_main, if you're using the default Android wrapper from my D android library). 3. The ELF object with the D main function must be passed to the linker first. If you look at my examples on the wiki, you'll see that they all follow these rules: https://wiki.dlang.org/Build_D_for_Android I should have called these rules out separately though, like I'm doing here, a documentation oversight. Also when mixing D and C code, you can't access extern TLS variables across the language boundary. Maybe OP tries to do that as he mixes D/C code? -- Johannes Everything was beautiful for Win/Linux/iOS/Android. Some day we had to use LDC (for some obvious reasons). I marked every function with @nogc and pure (it helped me to optimize the code). The problem is TLS. Android doesn't support it. At all. If you understand I talk about -betterC feature. - Igor
Re: Link errors when compiling shared lib on windows
On Wednesday, 1 November 2017 at 16:02:37 UTC, Daniel Fitzpatrick wrote: Oops, missed that! What i've tried is -shared -m64 i.d -shared -m64 -defaultlib=libphobos2.dll i.d Still seeing a lot of linker errors. Errors for the former: Are you using LDC? That's the only way I've been able to create a working DLL. I've never had to add the -defaultlib option with LDC on Windows. Here's a post describing all the steps I took to make a DLL that can be called from R: https://lancebachmeier.com/computing/d-from-r-windows.html The references to R are not important. Should be straightforward to adopt for your use case.
Re: [OT] Windows dying
For a dying platform as so many advocate here, it seems to be doing fairly well. Maybe i am too old but the whole dying platform gig has been doing all the way to Windows ME and Vista and 8 and ... The reality is, for any user that wants to be productive Windows is hard to beat. The only thing that comes close is the extreme hardware restrictive OSx from Apple. I do think that people here have a massive anti Microsoft bias by just reading the comments. Mobile will overtake PC for productivity? No ... simply no. Windows is dying? Hardly... Has the market changed because some users can use tablets, as they are not hardcore user but only want to simply browse and mail? Yes... There has been a shift there. But will Windows be out fazed on the corporate floor? No ... Will Windows be removed as a gaming platform and replaced by Linux / OSx? No ... While Linux and OSx can be used very well, both platforms share too many issues. OSx being hardware limited by design, as it makes testing more easy for Apple. Linux as a market that is so fragmented on the desktop level. At times people may want to appreciate the level of robustness that Windows is. Its easily as stable like Linux but has the support level for almost every piece of hardware. With the inclusion of WSL ( guess what i use D on because, well, i do not want to install VS! ), it combines both world. Maybe for some people the reason why they are being so annoying and frankly rude, is there own bias is getting in the way of the message. Its not because a person wants to write D code, that they want to install a multi GIGABYTE installation just so they can compile 64bit programs. Same with the comments that come down to "i do not see a reason why you want 64bit on Windows", is not a good excuse. On Wednesday, 1 November 2017 at 09:24:57 UTC, Joakim wrote: I don't propose ignoring it, but I suggest not to invest too much more into it, like all the work it would take to get VS or other Windows IDE support up to the level where Windows devs seem to want. Its just shows a pure vileness to Windows users as "We do not care to fix issues on your platform, use our platform or install VS and have it bit rote on your hard drive for no reason beyond we simply do not want to support Windows on D". No wonder some people think that Windows is a second tier citizen in the D community. It sure as hell does not feel very welcoming reading this thread. When a person has a issue, the response seem to be very aggressive attacking that person and the platform but ignoring the actual issue. How many people posted here claiming that he wanted to have 64bit removed, when it was NOT what he wrote. There is a issue with Windows. The whole attacking the messenger, the whole idiotic argumentation's that Windows is dying, it is all pure useless trolling the people who ask a simple questions: How to solve the D 64bit issue so that like on the Linux or OSx platform, the users can have the SAME level of consistency. Its so strange that Go has solved the 64bit Windows a long time ago. Or C. Or C++ ... and so many other compilers that do NOT need VS installed to produce 64bit binaries on the Windows platform. So in other words, all these comments about just install VS are pure bullshit. If you do not like to answer the question, then do not troll people. And frankly, Walter or whoever, there needed to have been put a stop to this anti Windows bullshit several days ago. As long as people use this level of disrespect towards community members because they are not using the "right" platform. /Signed: A pissed off Windows user
Re: TLS + LDC + Android (ARM) = FAIL
On Wednesday, 1 November 2017 at 18:28:12 UTC, Johannes Pfau wrote: Am Wed, 01 Nov 2017 17:42:22 + schrieb David Nadlinger : On Wednesday, 1 November 2017 at 17:30:05 UTC, Iain Buclaw wrote: > [...] Or quite possibly fewer, depending on what one understands "platform" and "support" to mean. ;) What is the state of GDC on Android/ARM – has anyone been using it recently? — David ARM: Fine. Android: probably won't work well. AFAIK we're only missing emulated TLS / GC integration, so most test will pass but real apps will crash because of GC memory corruption. I guess I should finally get back to fixing that problem ;-) OTOH Android doesn't even support GCC anymore, so I don't really see much benefit in maintaining GDC Android support. -- Johannes That's too bad. I'd do it here for food. - Igor
Re: TLS + LDC + Android (ARM) = FAIL
Am Wed, 01 Nov 2017 18:06:29 + schrieb Joakim : > On Wednesday, 1 November 2017 at 17:24:32 UTC, Igor Shirkalin > wrote: > > We solved the subject with modifying druntime source related > > with tls. Imaging, we have lost a lot of D's features. > > As far as I know DMD or GDC are not available for ARM > > architecture. So we need LDC. > > A short story: we have big C/C++ project that links D (LDC) > > code for different platforms. > > > > Does new "-betterC" mean we may use parallelism with using > > separate linker? > > > > - IS > > If you're having problems with the emulated TLS I put together > for Android, it is most likely because I didn't document well > what needs to be done when linking for Android. Specifically, > there are three rules that _must_ be followed: > > 1. You must use the ld.bfd linker, ld.gold won't do. > 2. You must have a D main function, even for a shared library > (which can be put next to android_main, if you're using the > default Android wrapper from my D android library). > 3. The ELF object with the D main function must be passed to the > linker first. > > If you look at my examples on the wiki, you'll see that they all > follow these rules: > > https://wiki.dlang.org/Build_D_for_Android > > I should have called these rules out separately though, like I'm > doing here, a documentation oversight. Also when mixing D and C code, you can't access extern TLS variables across the language boundary. Maybe OP tries to do that as he mixes D/C code? -- Johannes
Re: TLS + LDC + Android (ARM) = FAIL
On 1 November 2017 at 19:28, Johannes Pfau via Digitalmars-d wrote: > Am Wed, 01 Nov 2017 17:42:22 + > schrieb David Nadlinger : > >> On Wednesday, 1 November 2017 at 17:30:05 UTC, Iain Buclaw wrote: >> > GDC supports the same or maybe more platforms than LDC. :-) >> >> Or quite possibly fewer, depending on what one understands >> "platform" and "support" to mean. ;) >> >> What is the state of GDC on Android/ARM – has anyone been using >> it recently? >> >> — David >> > > ARM: Fine. Android: probably won't work well. AFAIK we're only > missing emulated TLS / GC integration, so most test will pass but real > apps will crash because of GC memory corruption. I guess I should > finally get back to fixing that problem ;-) OTOH Android doesn't even > support GCC anymore, so I don't really see much benefit in maintaining > GDC Android support. > > > -- Johannes > What's the thread model on Android? You could perhaps get away with --enable-threads=single.
Re: TLS + LDC + Android (ARM) = FAIL
Am Wed, 01 Nov 2017 17:42:22 + schrieb David Nadlinger : > On Wednesday, 1 November 2017 at 17:30:05 UTC, Iain Buclaw wrote: > > GDC supports the same or maybe more platforms than LDC. :-) > > Or quite possibly fewer, depending on what one understands > "platform" and "support" to mean. ;) > > What is the state of GDC on Android/ARM – has anyone been using > it recently? > > — David > ARM: Fine. Android: probably won't work well. AFAIK we're only missing emulated TLS / GC integration, so most test will pass but real apps will crash because of GC memory corruption. I guess I should finally get back to fixing that problem ;-) OTOH Android doesn't even support GCC anymore, so I don't really see much benefit in maintaining GDC Android support. -- Johannes
Re: TLS + LDC + Android (ARM) = FAIL
On Wednesday, 1 November 2017 at 17:46:29 UTC, David Nadlinger wrote: On Wednesday, 1 November 2017 at 17:24:32 UTC, Igor Shirkalin wrote: Does new "-betterC" mean we may use parallelism with using separate linker? `-betterC` does not add any emulation of missing platform features — on the contrary, it *removes* language runtime functionality! Thus, if TLS doesn't work for you (IIRC, emulated TLS should work on Android following Joakim's work!), adding `-betterC` won't improve the situation. I undrastand that. Could you please open an ticket on the LDC GitHub tracker with details on the issue? I'd try with help. — David
Re: TLS + LDC + Android (ARM) = FAIL
On Wednesday, 1 November 2017 at 17:44:11 UTC, Joakim wrote: On Wednesday, 1 November 2017 at 17:24:32 UTC, Igor Shirkalin wrote: We solved the subject with modifying druntime source related with tls. Imaging, we have lost a lot of D's features. You'd have been better off opening an issue for ldc: https://github.com/ldc-developers/ldc/issues TLS should work fine, though it's emulated, as Android doesn't support native TLS. You have to be careful how you link the emulated TLS, and you have to include a main function even for a shared library: https://wiki.dlang.org/Build_LDC_for_Android#Directions_for_future_work You'd be better off talking to the ldc devs- this is the first I'm hearing about this- rather than going in and making changes to druntime. As far as I know DMD or GDC are not available for ARM architecture. So we need LDC. A short story: we have big C/C++ project that links D (LDC) code for different platforms. Does new "-betterC" mean we may use parallelism with using separate linker? You'll need to expand on this: you want to use std.parallelism, which isn't working for you now, or something else to do with We use external D libraries in C project. Using parallelisms means we have to initialize druntime. But tls stops it (therefore we had changed it). Sure, we have tried to build pure D part and it didnt work. the linker is going wrong? of course the linker was working properly.
Re: TLS + LDC + Android (ARM) = FAIL
On Wednesday, 1 November 2017 at 17:24:32 UTC, Igor Shirkalin wrote: We solved the subject with modifying druntime source related with tls. Imaging, we have lost a lot of D's features. As far as I know DMD or GDC are not available for ARM architecture. So we need LDC. A short story: we have big C/C++ project that links D (LDC) code for different platforms. Does new "-betterC" mean we may use parallelism with using separate linker? - IS If you're having problems with the emulated TLS I put together for Android, it is most likely because I didn't document well what needs to be done when linking for Android. Specifically, there are three rules that _must_ be followed: 1. You must use the ld.bfd linker, ld.gold won't do. 2. You must have a D main function, even for a shared library (which can be put next to android_main, if you're using the default Android wrapper from my D android library). 3. The ELF object with the D main function must be passed to the linker first. If you look at my examples on the wiki, you'll see that they all follow these rules: https://wiki.dlang.org/Build_D_for_Android I should have called these rules out separately though, like I'm doing here, a documentation oversight.
Re: TLS + LDC + Android (ARM) = FAIL
On Wednesday, 1 November 2017 at 17:24:32 UTC, Igor Shirkalin wrote: Does new "-betterC" mean we may use parallelism with using separate linker? `-betterC` does not add any emulation of missing platform features — on the contrary, it *removes* language runtime functionality! Thus, if TLS doesn't work for you (IIRC, emulated TLS should work on Android following Joakim's work!), adding `-betterC` won't improve the situation. Could you please open an ticket on the LDC GitHub tracker with details on the issue? — David
Re: TLS + LDC + Android (ARM) = FAIL
On Wednesday, 1 November 2017 at 17:30:05 UTC, Iain Buclaw wrote: GDC supports the same or maybe more platforms than LDC. :-) Or quite possibly fewer, depending on what one understands "platform" and "support" to mean. ;) What is the state of GDC on Android/ARM – has anyone been using it recently? — David
Re: TLS + LDC + Android (ARM) = FAIL
On Wednesday, 1 November 2017 at 17:30:05 UTC, Iain Buclaw wrote: On 1 November 2017 at 18:24, Igor Shirkalin via Digitalmars-d wrote: We solved the subject with modifying druntime source related with tls. Imaging, we have lost a lot of D's features. As far as I know DMD or GDC are not available for ARM architecture. So we need LDC. GDC supports the same or maybe more platforms than LDC. :-) Could you please give the reference how to build it in linux or windows?
Re: TLS + LDC + Android (ARM) = FAIL
On Wednesday, 1 November 2017 at 17:24:32 UTC, Igor Shirkalin wrote: We solved the subject with modifying druntime source related with tls. Imaging, we have lost a lot of D's features. You'd have been better off opening an issue for ldc: https://github.com/ldc-developers/ldc/issues TLS should work fine, though it's emulated, as Android doesn't support native TLS. You have to be careful how you link the emulated TLS, and you have to include a main function even for a shared library: https://wiki.dlang.org/Build_LDC_for_Android#Directions_for_future_work You'd be better off talking to the ldc devs- this is the first I'm hearing about this- rather than going in and making changes to druntime. As far as I know DMD or GDC are not available for ARM architecture. So we need LDC. A short story: we have big C/C++ project that links D (LDC) code for different platforms. Does new "-betterC" mean we may use parallelism with using separate linker? You'll need to expand on this: you want to use std.parallelism, which isn't working for you now, or something else to do with the linker is going wrong?
Re: TLS + LDC + Android (ARM) = FAIL
On 1 November 2017 at 18:24, Igor Shirkalin via Digitalmars-d wrote: > We solved the subject with modifying druntime source related with tls. > Imaging, we have lost a lot of D's features. > As far as I know DMD or GDC are not available for ARM architecture. So we > need LDC. GDC supports the same or maybe more platforms than LDC. :-)
TLS + LDC + Android (ARM) = FAIL
We solved the subject with modifying druntime source related with tls. Imaging, we have lost a lot of D's features. As far as I know DMD or GDC are not available for ARM architecture. So we need LDC. A short story: we have big C/C++ project that links D (LDC) code for different platforms. Does new "-betterC" mean we may use parallelism with using separate linker? - IS
Re: Link errors when compiling shared lib on windows
On Wednesday, 1 November 2017 at 15:52:17 UTC, kinke wrote: On Wednesday, 1 November 2017 at 15:15:27 UTC, Daniel Fitzpatrick wrote: I am following this short tutorial on compiling a shared lib: https://wiki.dlang.org/Call_D_from_Ruby_using_FFI Because it's on Windows I am using these compiler options: -shared -m64 -defaultlib=libphobos2.so i.d However, I am receiving rather a lot of linker errors. Not sure what else to provide the compiler. Try less, especially no `-defaultlib` overridden with a Linux shared-object. You'll have to edit the hardcoded `./i.so` in the example as well obviously. Oops, missed that! What i've tried is -shared -m64 i.d -shared -m64 -defaultlib=libphobos2.dll i.d Still seeing a lot of linker errors. Errors for the former: i.obj : error LNK2019: unresolved external symbol _D3std5stdio13trustedStdoutFNdNeZS3std5stdio4File referenced in function _D3std5stdio16__T7writelnTAyaZ7writelnFNfAyaZv i.obj : error LNK2019: unresolved external symbol _D3std5stdio4File17lockingTextWriterMFNfZS3std5stdio4File17LockingTextWriter referenced in function _D3std5stdio16__T7writelnTAyaZ7writelnFNfAyaZv i.obj : error LNK2019: unresolved external symbol _D3std3utf12isValidDcharFNaNbNiNfwZb referenced in function _D3std5stdio4File17LockingTextWriter10__T3putTwZ3putMFNfwZv i.obj : error LNK2019: unresolved external symbol _d_assert_msg referenced in function _D3std5stdio4File17LockingTextWriter12__T3putTAyaZ3putMFNfAyaZv i.obj : error LNK2019: unresolved external symbol _aApplycd1 referenced in function _D3std5stdio4File17LockingTextWriter12__T3putTAyaZ3putMFNfAyaZv i.obj : error LNK2019: unresolved external symbol _D3std3utf12UTFException6__ctorMFNaNbNiNfAyaAyamC6object9ThrowableZC3std3utf12UTFException referenced in function _D3std3utf98__T13_utfExceptionVE3std8typecons55__T4FlagVAyaa19_7573655265706c6163656d656e744463686172Z4Flagi0Z13_utfExceptionFNaNfAyawZw i.obj : error LNK2019: unresolved external symbol _fputwc_nolock referenced in function _D3std5stdio4File17LockingTextWriter10__T3putTwZ3putMFNfwZ13trustedFPUTWCFNbNiNeiPS4core4stdc5stdio6_iobufZi i.obj : error LNK2019: unresolved external symbol _d_throwc referenced in function _D3std9exception135__T12errnoEnforceTiVAyaa50_633a5c445c646d64325c77696e646f77735c62696e5c2e2e5c2e2e5c7372635c70686f626f735c7374645c737464696f2e64Vmi2776Z12errnoEnforceFNfiLAyaZi i.obj : error LNK2019: unresolved external symbol _D3std5stdio4File17LockingTextWriter6__dtorMFNeZv referenced in function _D3std5stdio16__T7writelnTAyaZ7writelnFNfAyaZv i.obj : error LNK2019: unresolved external symbol _D3std9exception14ErrnoException6__ctorMFNeAyaAyamZC3std9exception14ErrnoException referenced in function _D3std9exception135__T12errnoEnforceTiVAyaa50_633a5c445c646d64325c77696e646f77735c62696e5c2e2e5c2e2e5c7372635c70686f626f735c7374645c737464696f2e64Vmi2776Z12errnoEnforceFNfiLAyaZi i.obj : error LNK2019: unresolved external symbol _D3std3utf12UTFException7__ClassZ referenced in function _D3std3utf98__T13_utfExceptionVE3std8typecons55__T4FlagVAyaa19_7573655265706c6163656d656e744463686172Z4Flagi0Z13_utfExceptionFNaNfAyawZw i.obj : error LNK2019: unresolved external symbol _d_newclass referenced in function _D3std9exception135__T12errnoEnforceTiVAyaa50_633a5c445c646d64325c77696e646f77735c62696e5c2e2e5c2e2e5c7372635c70686f626f735c7374645c737464696f2e64Vmi2776Z12errnoEnforceFNfiLAyaZi i.obj : error LNK2019: unresolved external symbol _D3std9exception14ErrnoException7__ClassZ referenced in function _D3std9exception135__T12errnoEnforceTiVAyaa50_633a5c445c646d64325c77696e646f77735c62696e5c2e2e5c2e2e5c7372635c70686f626f735c7374645c737464696f2e64Vmi2776Z12errnoEnforceFNfiLAyaZi i.obj : error LNK2019: unresolved external symbol _fputc_nolock referenced in function _D3std5stdio4File17LockingTextWriter10__T3putTwZ3putMFNfwZ12trustedFPUTCFNbNiNeiPS4core4stdc5stdio6_iobufZi i.obj : error LNK2019: unresolved external symbol fwrite referenced in function _D3std5stdio21__T13trustedFwriteTaZ13trustedFwriteFNbNiNePOS4core4stdc5stdio6_iobufxAaZm i.obj : error LNK2019: unresolved external symbol _D3std5stdio4File6__dtorMFNfZv referenced in function _D3std5stdio16__T7writelnTAyaZ7writelnFNfAyaZv i.obj : error LNK2019: unresolved external symbol _d_assertp referenced in function _D3std5stdio4File17LockingTextWriter10__T3putTwZ3putMFNfwZv i.obj : error LNK2019: unresolved external symbol _D3std5stdio4File17LockingTextWriter7handle_MFNdNeZPS4core4stdc5stdio6_iobuf referenced in function _D3std5stdio4File17LockingTextWriter10__T3putTwZ3putMFNfwZv i.obj : error LNK2019: unresolved external symbol _d_arrayboundsp referenced in function _D3std5stdio4File17LockingTextWriter10__T3putTwZ3putMFNfwZv LINK : error LNK2001: unresolved external symbol _DllMainCRTStartup i.dll : fatal error LNK1120: 20 unresolved externals Error: linker exited with status 1120
Re: Link errors when compiling shared lib on windows
On Wednesday, 1 November 2017 at 15:15:27 UTC, Daniel Fitzpatrick wrote: I am following this short tutorial on compiling a shared lib: https://wiki.dlang.org/Call_D_from_Ruby_using_FFI Because it's on Windows I am using these compiler options: -shared -m64 -defaultlib=libphobos2.so i.d However, I am receiving rather a lot of linker errors. Not sure what else to provide the compiler. Try less, especially no `-defaultlib` overridden with a Linux shared-object. You'll have to edit the hardcoded `./i.so` in the example as well obviously.
Link errors when compiling shared lib on windows
I am following this short tutorial on compiling a shared lib: https://wiki.dlang.org/Call_D_from_Ruby_using_FFI Because it's on Windows I am using these compiler options: -shared -m64 -defaultlib=libphobos2.so i.d However, I am receiving rather a lot of linker errors. Not sure what else to provide the compiler. i.obj : error LNK2019: unresolved external symbol _D3std5stdio4File17LockingTextWriter6__dtorMFNeZv referenced in function _D3std5stdio16__T7writelnTAyaZ7writelnFNfAyaZv i.obj : error LNK2019: unresolved external symbol _D3std9exception14ErrnoException6__ctorMFNeAyaAyamZC3std9exception14ErrnoException referenced in function _D3std9exception135__T12errnoEnforceTiVAyaa50_633a5c445c646d64325c77696e646f77735c62696e5c2e2e5c2e2e5c7372635c70686f626f735c7374645c737464696f2e64Vmi2776Z12errnoEnforceFNfiLAyaZi i.obj : error LNK2019: unresolved external symbol _D3std3utf12UTFException7__ClassZ referenced in function _D3std3utf98__T13_utfExceptionVE3std8typecons55__T4FlagVAyaa19_7573655265706c6163656d656e744463686172Z4Flagi0Z13_utfExceptionFNaNfAyawZw i.obj : error LNK2019: unresolved external symbol _d_assert_msg referenced in function _D3std5stdio4File17LockingTextWriter12__T3putTAyaZ3putMFNfAyaZv i.obj : error LNK2019: unresolved external symbol _D3std9exception14ErrnoException7__ClassZ referenced in function _D3std9exception135__T12errnoEnforceTiVAyaa50_633a5c445c646d64325c77696e646f77735c62696e5c2e2e5c2e2e5c7372635c70686f626f735c7374645c737464696f2e64Vmi2776Z12errnoEnforceFNfiLAyaZi i.obj : error LNK2019: unresolved external symbol _fputc_nolock referenced in function _D3std5stdio4File17LockingTextWriter10__T3putTwZ3putMFNfwZ12trustedFPUTCFNbNiNeiPS4core4stdc5stdio6_iobufZi i.obj : error LNK2019: unresolved external symbol fwrite referenced in function _D3std5stdio21__T13trustedFwriteTaZ13trustedFwriteFNbNiNePOS4core4stdc5stdio6_iobufxAaZm i.obj : error LNK2019: unresolved external symbol _D3std5stdio4File6__dtorMFNfZv referenced in function _D3std5stdio16__T7writelnTAyaZ7writelnFNfAyaZv i.obj : error LNK2019: unresolved external symbol _d_throwc referenced in function _D3std9exception135__T12errnoEnforceTiVAyaa50_633a5c445c646d64325c77696e646f77735c62696e5c2e2e5c2e2e5c7372635c70686f626f735c7374645c737464696f2e64Vmi2776Z12errnoEnforceFNfiLAyaZi i.obj : error LNK2019: unresolved external symbol _D3std5stdio4File17LockingTextWriter7handle_MFNdNeZPS4core4stdc5stdio6_iobuf referenced in function _D3std5stdio4File17LockingTextWriter10__T3putTwZ3putMFNfwZv i.obj : error LNK2019: unresolved external symbol _d_newclass referenced in function _D3std9exception135__T12errnoEnforceTiVAyaa50_633a5c445c646d64325c77696e646f77735c62696e5c2e2e5c2e2e5c7372635c70686f626f735c7374645c737464696f2e64Vmi2776Z12errnoEnforceFNfiLAyaZi i.obj : error LNK2019: unresolved external symbol _d_assertp referenced in function _D3std5stdio4File17LockingTextWriter10__T3putTwZ3putMFNfwZv i.obj : error LNK2019: unresolved external symbol _d_arrayboundsp referenced in function _D3std5stdio4File17LockingTextWriter10__T3putTwZ3putMFNfwZv i.obj : error LNK2019: unresolved external symbol _D3std5stdio13trustedStdoutFNdNeZS3std5stdio4File referenced in function _D3std5stdio16__T7writelnTAyaZ7writelnFNfAyaZv i.obj : error LNK2019: unresolved external symbol _D3std5stdio4File17lockingTextWriterMFNfZS3std5stdio4File17LockingTextWriter referenced in function _D3std5stdio16__T7writelnTAyaZ7writelnFNfAyaZv i.obj : error LNK2019: unresolved external symbol _D3std3utf12isValidDcharFNaNbNiNfwZb referenced in function _D3std5stdio4File17LockingTextWriter10__T3putTwZ3putMFNfwZv i.obj : error LNK2019: unresolved external symbol _aApplycd1 referenced in function _D3std5stdio4File17LockingTextWriter12__T3putTAyaZ3putMFNfAyaZv i.obj : error LNK2019: unresolved external symbol _D3std3utf12UTFException6__ctorMFNaNbNiNfAyaAyamC6object9ThrowableZC3std3utf12UTFException referenced in function _D3std3utf98__T13_utfExceptionVE3std8typecons55__T4FlagVAyaa19_7573655265706c6163656d656e744463686172Z4Flagi0Z13_utfExceptionFNaNfAyawZw i.obj : error LNK2019: unresolved external symbol _fputwc_nolock referenced in function _D3std5stdio4File17LockingTextWriter10__T3putTwZ3putMFNfwZ13trustedFPUTWCFNbNiNeiPS4core4stdc5stdio6_iobufZi LINK : error LNK2001: unresolved external symbol _DllMainCRTStartup i.dll : fatal error LNK1120: 20 unresolved externals Error: linker exited with status 1120
Re: [OT] Windows dying
On Wednesday, 1 November 2017 at 09:24:57 UTC, Joakim wrote: I don't propose ignoring it, but I suggest not to invest too much more into it, like all the work it would take to get VS or other Windows IDE support up to the level where Windows devs seem to want. I'm not sure how much work that would take, TBH, but I think that this is perhaps a better way to phrase your concerns. Saying that people working on Windows IDEs are wasting their time is probably not going to convince them of your point of view. Rather the argument that investing X hours in improving IDE would be better spent investing it in Y other D project is a much less inflammatory point. Granted, I think people could quibble with this, but it wouldn't drive me nuts to hear it.
Re: Project Elvis
On Tuesday, 31 October 2017 at 19:39:17 UTC, bauss wrote: On Tuesday, 31 October 2017 at 08:15:24 UTC, Mark wrote: On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei Alexandrescu wrote: Walter and I decided to kick-off project Elvis for adding the homonym operator to D. [...] Thanks, Andrei The Elvis operator's purpose is to make working with null easier, but isn't null "The Billion Dollar Mistake"? :@ Null is not the problem. The usage of types that can be null is the problem. Although only concepts, these will solve most issues with null references. https://github.com/visionlang/vsl/wiki/%2316-Null-safety https://github.com/visionlang/vsl/wiki/%2325-not-null-types https://github.com/visionlang/vsl/wiki/%2336-Error-Handling#nothrow I don't know... Personally I prefer Haskell's approach with Option types, but maybe it's too late to add something like that to D.
Re: [OT] Windows dying
On Wednesday, 1 November 2017 at 08:49:05 UTC, Joakim wrote: If your point is that the 1% of PC users who do such things will stick with PCs and the remaining 99% will switch to mobile, I agree with you. :) You leave only 0% for DeX :)
Re: [OT] Windows dying
On Wednesday, 1 November 2017 at 09:14:22 UTC, Shachar Shemesh wrote: On 29/10/17 23:21, Joakim wrote: On Sunday, 29 October 2017 at 20:58:45 UTC, 12345swordy wrote: On Sunday, 29 October 2017 at 18:52:06 UTC, Joakim wrote: [...] What makes you think that windows is a "dying platform"!? There is no evidence to suggest this. Take a look at the links in the thread I linked you, which show PC sales dropping for the last six years and back at the level of a decade ago. Yes, Windows is dying, and has been for a long long time now. And I'll add one or two "good riddance" while we're at it. The point to remember, however, is that it still has a long long time still to completely die. Windows has been somewhat marginalized as development platform in recent years, but it will be along time still before it becomes irrelevant for users. I'm not sure it makes sense for D to ignore this platform, despite its bleak future. Shachar I don't propose ignoring it, but I suggest not to invest too much more into it, like all the work it would take to get VS or other Windows IDE support up to the level where Windows devs seem to want.
Re: [OT] Windows dying
On 29/10/17 23:21, Joakim wrote: On Sunday, 29 October 2017 at 20:58:45 UTC, 12345swordy wrote: On Sunday, 29 October 2017 at 18:52:06 UTC, Joakim wrote: [...] What makes you think that windows is a "dying platform"!? There is no evidence to suggest this. Take a look at the links in the thread I linked you, which show PC sales dropping for the last six years and back at the level of a decade ago. Yes, Windows is dying, and has been for a long long time now. And I'll add one or two "good riddance" while we're at it. The point to remember, however, is that it still has a long long time still to completely die. Windows has been somewhat marginalized as development platform in recent years, but it will be along time still before it becomes irrelevant for users. I'm not sure it makes sense for D to ignore this platform, despite its bleak future. Shachar
Re: [OT] Windows dying
On Wednesday, 1 November 2017 at 00:16:19 UTC, Mengu wrote: On Monday, 30 October 2017 at 13:32:23 UTC, Joakim wrote: I don't know how intense your data analysis is, but I replaced a Win7 ultrabook that had a dual-core i5 and 4 GBs of RAM with an Android tablet that has a quad-core ARMv7 and 3 GBs of RAM as my daily driver a couple years ago, without skipping a beat. I built large mixed C++/D codebases on my ultrabook, now I do that on my Android/ARM tablet, which has a slightly weaker chip than my smartphone. how do you program on your tablet? what are your tools? what is your setup? i also believe laptops are here to go. I use the Termux app that I mentioned before, along with a Rapoo bluetooth keyboard and a cheap, foldable stand to prop up my tablet: https://play.google.com/store/apps/details?id=com.termux&hl=en `apt install clang ldc vim git gdb cmake ninja python` in Termux and I'm ready to go (well, not quite, as I also need some library packages depending on the project, but you get the idea). You can also install Termux on a Chromebook laptop that runs Android apps: https://mobile.twitter.com/rmloveland/status/908529214357458946 https://mobile.twitter.com/termux It's far from an IDE, but I never used those before anyway. I want to try out something like that Sentio laptop shell one day, as the bigger 11.6" screen does make sense for me. So far, I've been fine with my 8.4" tablet screen though. On Wednesday, 1 November 2017 at 00:30:21 UTC, Tony wrote: On Monday, 30 October 2017 at 13:32:23 UTC, Joakim wrote: There will always be a few Windows cockroaches that survive the mobile nuclear blast, but we're talking about the majority who won't. Why do predictions about the future matter when at the present Windows dominates the desktop and is also strong in the server space? Because that desktop market matters much less than it did before, see the current mobile dominance, yet the D core team still focuses only on that dying x86 market. As for the future, why spend time getting D great Windows IDE support if you don't think Windows has much of a future? I have seen conflicting reports about what OS is bigger in the server market, but Windows is substantial and the more frequent winner. https://community.spiceworks.com/networking/articles/2462-server-virtualization-and-os-trends https://www.1and1.com/digitalguide/server/know-how/linux-vs-windows-the-big-server-check/ I have never seen any report that Windows is "bigger in the server market." Last month's Netcraft survey notes, "which underlying operating systems are used by the world's web facing computers? By far the most commonly used operating system is Linux, which runs on more than two-thirds of all web-facing computers. This month alone, the number of Linux computers increased by more than 91,000; and again, this strong growth can largely be attributed to cloud hosting providers, where Linux-based instances are typically the cheapest and most commonly available." https://news.netcraft.com/archives/2017/09/11/september-2017-web-server-survey.html Your first link is actually a bad sign for Windows, as it's likely just because companies are trying to save money by having their employees run Windows apps off a virtualized Windows Server, rather than buying a ton more Windows PCs. Meanwhile, your second link sees "Linux maintaining a noticeable lead" in the web-hosting market. And if desktop OSes were going to go away, the MacOS would go before Windows. Oh, Apple wants that to happen, one less legacy OS to support, which is why all the Mac-heads are crying, because macOS doesn't get much attention nowadays. Do you know the last time Apple released a standalone desktop computer? 2014, when they last updated the Mac Mini. They haven't updated the Mac Pro since 2013. They see the writing on the wall, which is why they're lengthening their release cycles for such legacy products. On Wednesday, 1 November 2017 at 01:59:19 UTC, codephantom wrote: On Monday, 30 October 2017 at 13:32:23 UTC, Joakim wrote: I don't know how intense your data analysis is, but I replaced a Win7 ultrabook that had a dual-core i5 and 4 GBs of RAM with an Android tablet that has a quad-core ARMv7 and 3 GBs of RAM as my daily driver a couple years ago, without skipping a beat. I built large mixed C++/D codebases on my ultrabook, now I do that on my Android/ARM tablet, which has a slightly weaker chip than my smartphone. hahhaa hahhaa... I can't stop laughing...hahaaa haha. 3GB of ram, 4GB of ram..hahhaa..hahhha I'm starting to feel ill too...hahha...hahha. ok. I'm back...to normal now... Can your tablet run FreeBSD as host, and run multiple vm's at the same time too? Can you put multiple SSD RAID into your tablet? Can you upgrade its ram to 32GB? Can you upgrade its video card to 6GB? Can you overclock its cpu to 4GHz? Can you even replace its cpu?
