Re: What is the FreeBSD situation?
On 11/4/2017 1:54 AM, Rainer Schuetze wrote: On 04.11.2017 09:30, Walter Bright wrote: On 11/3/2017 5:29 AM, Rainer Schuetze wrote: Note that dmd still runs on Windows XP, though it is not officially supported. You just need to be careful about using TLS variables on it :-( to avoid spreading this false information: TLS in D works in dynamically loaded DLLs on WinXP since 2010. The fact that we haven't officially tested that it works for years means be careful about attesting that it does work. It is working in Visual D since that time. Ok, but does that mean you're testing the TLS support on XP? I run dmd regularly on an XP box, but that just means dmd itself runs on XP. (I converted the front end of DMC++ to D, using DMD in -betterC mode, and XP is the last operating system that supports DOS programs. XP has the DOS DMC++ test suite on it.) Even simple DLL support in Windows keeps breaking because it is not part of the autotester test suite. Agreed, they haven't been officially tested a lot in the past, but you have merged the PR to do that back in April: https://github.com/dlang/dmd/pull/6709 It's good that the samples work, but there's a bit more to the smoke test suite I had for it. I haven't tried it in a while.
Re: What are the unused but useful feature you know in D?
On Sunday, 25 June 2017 at 23:21:25 UTC, aberba wrote: Can you share feature(s) in D people are not talking about which you've found very useful? How about the compiler option: -release then I don't have to care about your god damn contract anymore. ;-)
Re: Proposal: Support for objects in switch statements
On Wednesday, 1 November 2017 at 01:16:32 UTC, solidstate1991
wrote:
After I started to alter my graphics engine to use the multiple
kinds of bitmaps (now using multiple language features, like
templates and aliases) on one layer, I noticed that type
detection of bitmap objects would be easier and better
readable, if instead of:
if(bitmapObject.classinfo == typeof(Bitmap4Bit)){
...
}else if(bitmapObject.classinfo == typeof(Bitmap8Bit)){...
I could easily use this:
switch(bitmapObject.classinfo){
case typeof(Bitmap4Bit):
...
case typeof(Bitmap8Bit):
}
On the other hand I cannot really think other uses for such
language feature, maybe with structs.
While it's not entirely ideal something like this works.
```
template ClassName(T, string mod = __MODULE__)
{
enum ClassName = mod ~ "." ~ T.stringof;
}
@property string className(T)(T o)
{
return o.classinfo.toString();
}
```
Example:
```
final switch (bitmapObject.className)
{
case ClassName!Bitmap4Bit: ... break;
case ClassName!Bitmap8Bit: ... break;
}
```
Re: What is the FreeBSD situation?
On Sunday, 5 November 2017 at 09:17:37 UTC, Walter Bright wrote: On 11/4/2017 1:54 AM, Rainer Schuetze wrote: On 04.11.2017 09:30, Walter Bright wrote: On 11/3/2017 5:29 AM, Rainer Schuetze wrote: Note that dmd still runs on Windows XP, though it is not officially supported. You just need to be careful about using TLS variables on it :-( to avoid spreading this false information: TLS in D works in dynamically loaded DLLs on WinXP since 2010. The fact that we haven't officially tested that it works for years means be careful about attesting that it does work. It is working in Visual D since that time. Ok, but does that mean you're testing the TLS support on XP? I run dmd regularly on an XP box, but that just means dmd itself runs on XP. (I converted the front end of DMC++ to D, using DMD in -betterC mode, and XP is the last operating system that supports DOS programs. XP has the DOS DMC++ test suite on it.) I don't think that's true. It's a 32bit/64bit division, not a Windows version thing. A 32 bits installation can run 16 bits and 32 bits programs, a 64 bits version can run natively 32 bits and 64 bits programs. None can run all 3 modes natively. I know with certainty that Windows 8.1 32 bits installation could still run DOS and Windows 16 bits apps. I haven't seen evidence to the contrary for Windows 10. Windows XP was the last version that was installed massively in 32 bits mode. From Vista on, the proportion of 32 bits installations (and thus losing 16 bits support) dwindeled.
Re: Note from a donor
On Saturday, 4 November 2017 at 08:16:16 UTC, Joakim wrote: I was intrigued by someone saying in this thread that Go supports Win64 COFF out of the box, so I just tried it out in wine and indeed it works with their hello world example. Running "go build -x" shows that they ship a link.exe for Win64 with their Win64 zip, guess it's the Mingw one? Does Go need WinSDK though?
Re: Note from a donor
On Sunday, 5 November 2017 at 14:19:11 UTC, MrSmith wrote: On Saturday, 4 November 2017 at 08:16:16 UTC, Joakim wrote: I was intrigued by someone saying in this thread that Go supports Win64 COFF out of the box, so I just tried it out in wine and indeed it works with their hello world example. Running "go build -x" shows that they ship a link.exe for Win64 with their Win64 zip, guess it's the Mingw one? Does Go need WinSDK though? Not for the hello world sample I tried in wine, maybe you need to get some libraries for other stuff, dunno.
Re: Improve "Improve Contract Syntax" DIP 1009
On Saturday, 4 November 2017 at 15:38:42 UTC, Jonathan M Davis
wrote:
In principle, that would be nice, but in practice, it's not
really feasible. In the general case, there's no way to save
the state of the parameter at the beginning of the function
call (you could with some types, but for many types, you
couldn't). IIRC, it's been discussed quite a bit in the past,
and there are just too many problems with it.
- Jonathan M Davis
What about making definitions in "in" block visible in "out"
block?
void fun(int par)
in {
int saved = par;
}
body {
par = 7;
}
out {
writeln(saved);
}
Re: Project Elvis
On Monday, 30 October 2017 at 19:46:54 UTC, Andrei Alexandrescu wrote: I see from comments that different people think of it in a different way. I suggest them to read this section from Kotlin docs to understand the reasoning behind the elvis operator. The principle of least astonishment indicates we should do what the lowering does: expr1 ?: expr2 ==> (x => x ? x : expr2)(expr1) An approach that does things any differently would have a much more difficult time. It is understood (and expected) that other languages have subtly different takes on the operator. Andrei I may add that the same logic is used in .get(key, defaultValue) method of Associative Arrays
Re: What is the FreeBSD situation?
On 11/5/2017 3:13 AM, Patrick Schluter wrote: On Sunday, 5 November 2017 at 09:17:37 UTC, Walter Bright wrote: I run dmd regularly on an XP box, but that just means dmd itself runs on XP. (I converted the front end of DMC++ to D, using DMD in -betterC mode, and XP is the last operating system that supports DOS programs. XP has the DOS DMC++ test suite on it.) I don't think that's true. It's a 32bit/64bit division, not a Windows version thing. A 32 bits installation can run 16 bits and 32 bits programs, a 64 bits version can run natively 32 bits and 64 bits programs. None can run all 3 modes natively. Is that an issue with the CPU, or the operating system? I know with certainty that Windows 8.1 32 bits installation could still run DOS and Windows 16 bits apps. I haven't seen evidence to the contrary for Windows 10. Windows XP was the last version that was installed massively in 32 bits mode. From Vista on, the proportion of 32 bits installations (and thus losing 16 bits support) dwindeled. Windows 7 64 bit will not run 16 bit programs. Try it and you get a dialog box "Unsupported 16-Bit Application". I haven't tried Win 7 32, but some googling around shows you are correct.
Re: Project Elvis
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.
It's easy to write in function form:
auto orElse(T)(T a, lazy T b)
{
return a ? a : b;
}
writeln(args[1].length.orElse(fibonacci(50)));
This version can also be specialized for things like Nullable,
where you can't necessarily cast it safely to a boolean but have
a check for validity.
Is it that valuable to have an operator for it instead?
As an aside, I believe feepingcreature had a custom infix
operator for this sort of thing defined, so you could write:
(a /or/ b /or/ c).doStuff();
The implementation (along with /and/) is left as an exercise to
the reader.
Re: Improve "Improve Contract Syntax" DIP 1009
On Sunday, November 05, 2017 16:25:16 MrSmith via Digitalmars-d wrote:
> On Saturday, 4 November 2017 at 15:38:42 UTC, Jonathan M Davis
>
> wrote:
> > In principle, that would be nice, but in practice, it's not
> > really feasible. In the general case, there's no way to save
> > the state of the parameter at the beginning of the function
> > call (you could with some types, but for many types, you
> > couldn't). IIRC, it's been discussed quite a bit in the past,
> > and there are just too many problems with it.
> >
> > - Jonathan M Davis
>
> What about making definitions in "in" block visible in "out"
> block?
>
> void fun(int par)
> in {
> int saved = par;
> }
> body {
> par = 7;
> }
> out {
> writeln(saved);
> }
That would help, and I think that that it was discussed previously, but it
would mean that in and out were in the same scope, which would be a breaking
change. There may have been other reasons why it would be problematic, but I
don't recall. There's certainly nothing stopping the creation of a DIP on
the topic though if someone feels strongly enough about it to put in the
time and effort.
I'm sure that there are various things that could be done to improve
contracts (and DIP 1009 is one such attempt), but I've mostly given up on
it. I don't think that they provide enough value in the first place. Aside
from issues involving contracts and inheritance, in contracts can just be
put in the function body, making them kind of pointless, and for the most
part, unit tests test anything that I would consider testing in an out
contract - and generally do it better. That combined with the issue with
invariant and void initialized objects, and as far as I'm concerned,
contracts are pretty pointless, much as they're well-intentioned. I almost
never use them.
Probably the one thing that would make me change my tune on in contracts
would be if it were somehow changed so that whether they were run depended
on whether the caller was compiled with assertions enabled rather than
whether the function being called was compiled with assertions, since with
in contracts, it's really the caller that you're testing, not the function
itself. But short of that, I doubt I'll ever do much with them.
However, one thing that annoys me enough that I might do something about it
at some point is how invariant is broken with void initialized objects,
since unlike in and out contracts, doing what invariant does without using
the feature is a royal pain. So, at some point, I may create a DIP to deal
with that (probably by providing a way to explicitly indicate that you want
the invariant skipped at the callsite), but it hasn't been a particularly
high priority for me, so I haven't done anything with it.
- Jonathan M Davis
Re: Improve "Improve Contract Syntax" DIP 1009
On Saturday, November 04, 2017 14:12:08 Adam D. Ruppe via Digitalmars-d
wrote:
> On Saturday, 4 November 2017 at 13:59:39 UTC, Jonathan M Davis
>
> wrote:
> > I'm very much of the opinion that proper unit tests pretty much
> > eliminate the need for out contracts.
>
> I think that sqrt example is just bad. Out contracts shouldn't be
> testing specific values, but rather ranges or nullness or other
> such things that arguably should be part of the return type, but
> just don't fit in the type system for whatever reason.
>
> Consider this:
>
> class A {
> A clone()
> out(result) { assert(result !is null); }
> body {
> return new A();
> }
> }
> class B : A {
> override B clone() {
> return new B();
> }
> }
>
> void main() {
> A a = new B();
> A c = a.clone();
> }
>
>
> The `clone` method defined in the base class arguably out to
> return a NotNull!A, encoding that contract in the type, but we
> can't really do that with D without breaking the inheritance -
> where B is statically defined to return B too, since NotNull!B
> isn't covariant to NotNull!A the way B is covariant to A. (At
> least not with any techniques I can think of at this time.)
>
> So you can't encode it in the return type... but you can encode
> it in the out contract for a runtime check.
>
> It also clearly documents that the subclasses must not return
> null (and can add their own restrictions to further subclasses).
> One problem I have with some of D's contracts right now is that
> they are convoluted, ugly code that make for passable internal
> unit tests, you can't reasonably display as documentation as part
> of the interface.
>
> But regardless, I say you should not think of out as tests. Think
> of it as type system extensions.
It's an interesting idea, but I use classes so rarely in D that I wouldn't
hit this use case often enough to even think about it. In fact, at the
moment, I don't think that I've _ever_ written a clone function in D, and I
probably wouldn't even bother with null checks (in general, not just with
clone functions), since the program will just segfault on me if I screw that
up, so it's not like it won't be caught, and with the way I write code, I
almost never have problems with null objects except in cases where I forgot
to initialize something, and that gets found _really_ fast in testing.
- Jonathan M Davis
Re: What is the FreeBSD situation?
On Sunday, 5 November 2017 at 20:28:38 UTC, Walter Bright wrote: Is that an issue with the CPU, or the operating system? Since you *can* install a 32-bit o/s on a 64-bit cpu, logic would suggest that it's a combination of both. Which turns out to be the case. Nice blog about it here: https://www.xylos.com/blog/en/2012/04/legacy-16-bit-applications-on-64-bit-operating-systems/ btw. I believe Windows Nano Server drops the wow64 subsystem, and so no longer even supports '32bit' applications. It's 64bit all the way with Nano.
Re: What is the FreeBSD situation?
On 11/5/2017 6:44 PM, codephantom wrote: https://www.xylos.com/blog/en/2012/04/legacy-16-bit-applications-on-64-bit-operating-systems/ Thanks for the link. I didn't know that, this clears it up!
Re: What is the FreeBSD situation?
On 11/5/2017 8:51 PM, Walter Bright wrote: On 11/5/2017 6:44 PM, codephantom wrote: https://www.xylos.com/blog/en/2012/04/legacy-16-bit-applications-on-64-bit-operating-systems/ Thanks for the link. I didn't know that, this clears it up! Interestingly, all I actually need to test the 16 bit code generation is an 8088 emulator with some of the DOS API interrupts supported. The CPU is simple enough that should be easy :-)
Re: What is the FreeBSD situation?
On Monday, 6 November 2017 at 04:56:53 UTC, Walter Bright wrote: Interestingly, all I actually need to test the 16 bit code generation is an 8088 emulator with some of the DOS API interrupts supported. The CPU is simple enough that should be easy :-) I still have 'actual' pc's here at home, from the 90's, running MS-DOS. So, don't listen to the naysayers...there is actually a market (small as it is) for 'DMD for MS-DOS'. Then I can finally retire Borland C++ 3.1 ... may it rest in peace.
Re: [OT] Windows dying
On Friday, 3 November 2017 at 14:12:56 UTC, Joakim wrote: I don't know why you're so obsessed with storage when even midrange smartphones come with 32 GBs nowadays, expandable to much more with an SD card. My tablet has only 16 GBs of storage, with only 10-12 actually accessible, but I've never had a problem building codebases that take up GBs of space with all the object files, alongside a 64 GB microSD card for many, mostly HD TV shows and movies. The smallest storage Windows 10/Linux laptops have is a 128GB SSD. Even with a faster 128GB SSD being around the price of a 1TB hard drive, I still see 1TB being the dominant low-end storage. So I am going by what I see being offered as a minimum. It may be that most or even 99% of people can get by with 32GB flash memory, but it isn't being offered (except on Chromebooks which have traditionally only been web browsers, and on Windows 10S machines which can only run Windows Store apps). Are you suggesting they are developing their games for iOS and Android devices ON those devices? Apple has XCode for developing iOS apps and it runs on macOS machines only. There is also the Xamarin IDE or IDE plug-in from Microsoft that allows C# on iOS, but it runs on macOS or WIndows. For Android, there is Android Studio - "The Official IDE of Android" - which runs on Windows, macOS and Linux. There is no Android version. Yes, of course they're still largely developing mobile games on PCs, though I'm not sure why you think that matters. But your original claim was that they're still using PC-focused IDEs, as opposed to new mobile-focused IDEs like XCode or Android Studio, which you now highlight. I never made any previous claim about what IDEs are being used. The only time I previously mentioned an IDE was with regard to RemObjects and Embarcadero offering cross-compilation to Android/iOS with their products. "There is a case to be made for supporting Android/iOS cross-compilation. But it doesn't have to come at the expense of Windows 64-bit integration. Not sure they even involve the same skillsets. Embarcadero and Remobjects both now support Android/iOS development from their Windows (and macOS in the case of Remobjects) IDEs." That was to highlight that those two compiler companies have seen fit to also cross-compile to mobile - they saw an importance to mobile development. It wasn't about what IDEs are best for mobile or even what IDEs are being used for mobile. Not that it matters, but I don't think that XCode meets the definition of "new mobile-focused IDE" as-as far as I know, it was developed for OS X development and is still used for such. Android Studio may be "new mobile-focused", even though based on IntelliJ IDEA. Yes, Windows is dominant, dominant in a niche, internal IT. The consumer mobile market is much larger nowadays, and Windows has almost no market share there. Sad too, because of all the tablet/phone interfaces, the only one that is not just "icons on a background", and my personal preference, is Windows Mobile. As for Microsoft, Windows is not their only product, they have moved Office onto the dominant mobile platforms. As long as they keep supporting mobile, they could eke out an existence. Their big bet on Azure is going to end badly though. They have Word, Excel, Powerpoint for mobile, but they are free. The Android store mentions "in-app purchases" but I wasn't offered any. Maybe it is for OneDrive storage of files. I already have that so it could be why I don't see anything to purchase in the app. Why did they fund development of a new iMac Pro which is coming this December as well as the new MacBook Pros that came out this June? That's a contradiction of "milk it like an iPod". Because their userbase was rebelling? I take it you're not that familiar with Mac users, but they were genuinely scared that Apple was leaving them behind, since they weren't refreshing Mac and Macbooks much anymore and all Apple's focus is on iOS: So, let them rebel. You said that they would like to see it go away, and/or they want to milk it. If you have to spend money on development to keep selling it, then you can't "milk it". It is ironic that Microsoft and Ubuntu both saw a convergence of mobile and desktop and began modifying their desktop interace to best suit mobile, and now Ubuntu has abandoned the idea and Microsoft has abandoned the phone market. As it turns out, any convergence will have to come from the two dominant mobile OSes as it is impossible to go the other direction due to the app catch-22.
Re: Project Elvis
On Monday, 6 November 2017 at 00:20:09 UTC, Neia Neutuladh 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.
It's easy to write in function form:
auto orElse(T)(T a, lazy T b)
{
return a ? a : b;
}
writeln(args[1].length.orElse(fibonacci(50)));
This version can also be specialized for things like Nullable,
where you can't necessarily cast it safely to a boolean but
have a check for validity.
Is it that valuable to have an operator for it instead?
As an aside, I believe feepingcreature had a custom infix
operator for this sort of thing defined, so you could write:
(a /or/ b /or/ c).doStuff();
The implementation (along with /and/) is left as an exercise to
the reader.
Sure you might be able to write it easily, but pretty much
everyone writes a function like that in their projects and you
don\t really know the implementation always and you have to
remember the exact name or else you end up writing the function
yourself in your project to make sure the implementation is
exactly like that, which in fact turns out to be re-inventing the
wheel.
By having an official syntax for it, you don't end up with code
duplication like that and the implementation details of the
behavior is clear.
Because in some implementation "orElse()" might only check if the
value is null and not necessary if the value is true.
Ex. one might implement it like:
auto orElse(T)(T a, lazy T b)
{
return a !is null ? a : b;
}
Such implementation detail is not clear from the call-side.
However with an official implementation you know exactly how it
will behave and nothing is obscure like this.
