Re: D Binding to GUI libraries
On Sunday, 21 October 2018 at 07:33:45 UTC, Russel Winder wrote: The GTK/Qt battle on Linux was won by GTK+2 hence GNOME over KDE as the default for Debian and Fedora. Whether this was right or wrong is left as a choice for the reader! Linux is not only the desktop, and Qt simply dominates in industrial, medical and automation sector, that's where the money is. Qt is pushing strongly on the embedded marked, bare metal or linux (kernel) based... - Paolo
Re: Truly @nogc Exceptions?
On Saturday, 20 October 2018 at 14:56:37 UTC, Mike Parker wrote: On Saturday, 20 October 2018 at 13:48:32 UTC, Paolo Invernizzi wrote: If `@nogc` could be relaxed for `new Error` exactly for that reason, pieces of Phobos could be turned `@nogc`... But I admit that that change would be controversial... https://github.com/dlang/DIPs/blob/master/DIPs/DIP1008.md Yep, you are right, of course... 8-/ /P
Re: D Binding to GUI libraries
On Saturday, 20 October 2018 at 14:24:56 UTC, Russel Winder wrote: On Sat, 2018-10-20 at 12:43 +, tide via Digitalmars-d wrote: […] I mean it *may* work, but that isn't the problem if the developers completely lack support for the platform. I can download Qt with prebuilt libraries and it works out of the box with MSVC. There's an obvious difference between the two developers support. As someone else said GTK look like ass on Windows, Qt is really the only crossplatform GUI API written in a native-compile-able language out there that gets most things right. I do not disagree, especially about GTK+ not really being available on Windows and macOS, it is fundamentally a Linux and UNIX framework – I think we can ignore the fact that macOS is sort of FreeBSD in this circumstance due to macOS. I'd agree Qt is a much better cross-platform GUI framework that GTK+. I've use it with Python very successfully – originally with PySide, then PyQt, but now back with PySide2. I tried QML with Go to move to native code from Python, but it didn't really work for me as yet, though some people gave me a few tips a few weeks back that I haven't followed up on as yet. wxWidgets seems still to be going though and wxPython is rising as a phoenix . I haven't really used them though but maybe the latest version is worth a whirl. I guess people doing Qt stuff really do work with C++ if they don't work with Python? I'd call this an opportunity for D. The trick has to be to automate the creation of the binding. I have to admit I do not know what the technique is for PySide2 but PyQt certainly has a system for generation of the binding. Of course, Rust https://github.com/rust-qt As a company that will be hosted in the QT booth at SPS IPC Drives 2018 in Nuremberg at the end of November, C++ dominates. We are calling a little D codebase from a QT application, but just to leverage some legacy old code. I've used PySide, years ago, but nowadays the performance of the C++ compilers, and the agility of QT Creator are closing the bridge for a fast edit/compile/test cycle... the big advantage of PySide is the tremendous amount of python libraries that you can use in your application. Said that, we are using QML, but I don't love it a lot... - Paolo
Re: Truly @nogc Exceptions?
On Thursday, 20 September 2018 at 17:14:12 UTC, Steven Schveighoffer wrote: On 9/20/18 12:24 PM, Adam D. Ruppe wrote: On Thursday, 20 September 2018 at 15:52:03 UTC, Steven Schveighoffer wrote: I needed to know what the slice parameters that were failing were. Aye. Note that RangeError is called by the compiler though, so you gotta patch dmd to make it pass the arguments to it for index. Ugh. I did a PR for this once but it got shot down because of an allegeded (without evidence btw) performance degradation. Ugh. Well, you can always override that. Just do the check yourself and throw the error you want ;) In my case, that's what I did anyway. I don't know how a performance problem can occur on an error being thrown anyway -- the process is about to end. -Steve If `@nogc` could be relaxed for `new Error` exactly for that reason, pieces of Phobos could be turned `@nogc`... But I admit that that change would be controversial... - Paolo
Re: Shared - Another Thread
On Thursday, 18 October 2018 at 21:14:54 UTC, Stanislav Blinov wrote: On Thursday, 18 October 2018 at 20:59:59 UTC, Erik van Velzen wrote: [...] Quite a simple reason: it was years ago, however old you are now you were younger and less experienced, and probably didn't understand something back then. [...] Then I don't know what to tell you. It literally talks about compiler forbidding unsafe operations and *requiring* you to go the extra mile, by just rejecting invalid code (something that Manu is proposing to forego!). But that's *code*, not logic. [...] Tangetially?! There's a whole section on writing `shared`-aware code (none of which would even compile today, I don't know if it's addressed in his errata). [...] Yeah, some of that never happened and never will. But that aside, none of it says "threading will be safe by default". It says "threading will be a lot less unsafe by default". And *that* is what we must achieve. The "threading will be a lot less unsafe by default" is related to the default TLS usage. I remember like Erik, maybe wrongly, that the ambitions on shared were more directed towards the "threading will be safe by default" goal. I've to read again some post from Bartosz Milewski... /Paolo
Re: Shared - Another Thread
On Wednesday, 17 October 2018 at 21:55:48 UTC, H. S. Teoh wrote: The problem, of course, is that they are also charged particles, and the electromagnetic forces that hold the atom in place would be greatly disturbed if two atoms were to occupy the same space simultaneously, leading to a (very fast and very violent) reorganization of nucleii and electrons. What that looks like macroscopically, I can't say exactly, but certainly delicate structures like proteins, DNA, lipid layers, and such would cease to exist, their constituent particles being violently scattered every which way in the course of reorganizing themselves into new structures that would bring the electromagnetic forces back into balance (and that, in all likelihood, won't resemble anything close to their starting molecular structures). Whatever the result may be, I'm pretty certain it would not have good consequences for the biological processes built upon said delicate structures. To say the least. :-D Even worst than that: conversion to/from E is involved in the process! :-P
Re: shared - i need it to be useful
On Thursday, 18 October 2018 at 06:20:02 UTC, Manu wrote: On Wed, Oct 17, 2018 at 5:05 AM Timon Gehr via Digitalmars-d wrote: [... all text ...] OMFG, I just spent about 3 hours writing a super-detailed reply to all of Timon's posts in aggregate... I clicked send... and it's gone. I don't know if this is a gmail thing, a mailing list thing... no idea... but it's... gone. I can't repeat that effort :( Never never write something super-detailed in a web-based "thing"! Native application, and copy-past! :-O But' now I'm curious about your reply! Timon argumentation are really strong (IMHO), so it's a double effort! :-/ /Paolo
Re: My statements related to terminating my SAoC relationship
On Wednesday, 17 October 2018 at 20:03:23 UTC, lagfra wrote: On Monday, 15 October 2018 at 21:26:52 UTC, solidstate1991 wrote: I have done two mistakes: I underestimated the scope of the project and overestimated my capabilities. This caused a chain reaction, which in turn made the first milestone unreachable. Hi, I'm one of the other participants to the SAoC project and I'm replying on behalf of me and Francesco, the other SAoC student. We just wanted to tell you not to be too hard on yourself and that we understand the difficult time you're going through. Also, if you want a change of air or a place were you can look for new opportunities, we both are students in Turin (Italy) right now and you're welcome to join us anytime. We hope the best for you. I agree with lagfra, take your time... BTW, it seems that the Italian D Programmers League is more crowded that expected... /Paolo
Re: Deep nesting vs early returns
On Saturday, 6 October 2018 at 18:55:48 UTC, Patrick Schluter wrote: On Saturday, 6 October 2018 at 05:36:59 UTC, Paolo Invernizzi wrote: [...] In the 90s I used to add the C preprocessor to other languages which lacked efficient constant definition (i.e. compile time constructs). AutoLISP, the LISP dialect used to write application in AutoCAD. There were nearly a 100 of small programs in different files and throughout the whole project there were a lot repetitions that could not be factorized with AutoCAD means. Include, define and ifdef allowed to do things, that were very difficult to do at that time (it was on AutoCAD v9.0 which had only 64K memory for the LISP code). I also added the C preprocessor to the DBASE III and the compatible MS-DOS based Foxbase. Fox, the speediest indexes in the country... what a time! :-P /P
Re: Deep nesting vs early returns
On Friday, 5 October 2018 at 19:04:26 UTC, Nick Sabalausky (Abscissa) wrote: On 10/04/2018 11:40 PM, rikki cattermole wrote: [...] It's not *my* statement about newer/older. If you recall the programming atmosphere around 2000, OO was widely being touted as a newer thing, superior to "old-fashioned" imperative, even though there's a million things about that whole assessment that are false (not the least of which being the at-the-time popular notion that Java-style OO somehow wasn't still imperative, or, as you pointed out, that OO was a new invention). There's one minor aspect of it that was true though: Widespread popularity of OO was certainly a new thing, even if OO itself wasn't. The hype was hight also in the 90... I remember having used (in production!) a 3rd party extension to Clipper (I don't remember if Summer 87, or 5.0.x) that added OO to the language! 0__o /Paolo
Re: DIP 1014
On Thursday, 4 October 2018 at 08:10:31 UTC, Shachar Shemesh wrote: On 04/10/18 11:05, Stanislav Blinov wrote: On Thursday, 4 October 2018 at 03:06:35 UTC, Shachar Shemesh wrote: [...] For the love of Pete, that program was an example of how a move hook should work, *not* a demonstration of achieving the DIP behavior without changing the language. I know the example is brittle and have said as much. The example isn't brittle. It is simply not an example. If you want to leave it out, however, then I think you should submit an orderly proposal. The changes you seem to be suggesting have consequences that go beyond what I think you understand, and there can be no serious discussion of it while it is not clear from your posts which part of what you say is the relevant one. Shachar While I want to thank you both, about the quality of this thread, what kind of "consequences that go beyond what I think you understand" are you thinking of? Can you give an example? Thanks, Paolo
Re: OT: Bad translations
On Thursday, 27 September 2018 at 07:03:51 UTC, Andrea Fontana wrote: On Thursday, 27 September 2018 at 05:15:01 UTC, Ali Çehreli wrote: A delicious Turkish desert is "kabak tatlısı", made of squash. Now, it so happens that "kabak" also means "zucchini" in Turkish. Imagine my shock when I came across that desert recipe in English that used zucchini as the ingredient! :) Ali You can't even imagine how many italian words and recipes are distorted... Andrea +1 :-P
Re: Rather D1 then D2
On Saturday, 22 September 2018 at 16:22:31 UTC, Russel Winder wrote: This is just so reminiscent of the Python 2 / Python 3 fiasco. Python 3 was clearly an improvement over Python 2, but the way in which the changes came to the community caused a violent split. Even after many years, there are those for whom Python 3 is anathema and not to be used. [...] Have you followed the discussion of Jonathan on @implicit? It seems that D2 is going in the opposite direction: more cruft is being added, for sake of (dubious) compatibility.
Re: phobo's std.file is completely broke!
On Wednesday, 19 September 2018 at 06:05:38 UTC, Vladimir Panteleev wrote: Operating on paths longer than MAX_PATH is not a typical situation. https://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/1499/ The worst situation was node.js on Windows, anyway...
Re: Forums intermittently going down?
On Monday, 17 September 2018 at 11:51:04 UTC, Vladimir Panteleev wrote: On Monday, 17 September 2018 at 11:02:39 UTC, Michael wrote: It has been occurring for the past two weeks now, at least. When I try to load the forum (on different networks) it will often hang for a while, and when it does eventually load a page, it is likely that clicking a link will cause it to get stuck loading again, or eventually display the following message: forum.dlang.org is temporarily down for maintenance, and should be back up shortly. Apologies for the inconvenience. Is anyone else experiencing this? I thought it might just be me but it seems to be happening across browsers and on different networks. Not just you. The server is just overloaded. The high load is temporary, but will take a week or two to resolve. I can confirm that in the last two weeks the overload is very frequent... almost one over five click.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Thursday, 6 September 2018 at 07:23:57 UTC, Chris wrote: Seriously, people need to get over the fantasy that they can just use Unicode without understanding how Unicode works. Most of the time, you can get the illusion that it's working, but actually 99% of the time the code is actually wrong and will do the wrong thing when given an unexpected (but still valid) Unicode string. Is it asking too much to ask for `string` (not `dstring` or `wstring`) to behave as most people would expect it to behave in 2018 - and not like Python 2 from days of yore? I agree with Chris. The boat is sailed, so D2 should just go full throttle with the original design and auto decode to graphemes, regardless of the performance.
Re: extern(C++, ns) is wrong
On Wednesday, 5 September 2018 at 05:32:43 UTC, Manu wrote: On Tue, 4 Sep 2018 at 21:40, Walter Bright via Digitalmars-d wrote: [...] "A handwavy description"! What do you mean? I started the email with the code... if you compiled it you would have reproduced those error messages. Yes the line numbers would have been different line numbers, because I deleted all the other lines, but the code I pasted reproduces the errors precisely. And you know that anyway. You don't need to compile the code to understand the error, we've been over it countless times for years now. what about run.dlang.org?
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Monday, 3 September 2018 at 14:26:46 UTC, Laeeth Isharc wrote: I just spoke with Dicebot about work stuff. He incidentally mentioned what I said before based on my impressions. The people doing work with a language have better things to do than spend a lot of time on forums. And I think in open source you earn the right to be listened to by doing work of some kind. He said (which I knew already) it was an old post he didn't put up in the end - somebody discovered it in his repo. He is working fulltime as a consultant with me for Symmetry and is writing D as part of that role. I don't think that indicates he didn't mean his criticisms, and maybe one could learn from those. But a whole thread triggered by this is quite entertaining. I'm the person how found the post, and I'm enjoying the readings... and I'm learning something also! I'm amused by the amount of different topics, minus one, the original: why feature branches are not an option in DLangLand. /Paolo
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Monday, 27 August 2018 at 01:15:49 UTC, Laeeth Isharc wrote: It's simple, I went to GitLab to see the code of the tool, and I found the articles among the other projects of the author. I don't think he was very happy about the process around DIP1000 but I am not myself well placed to judge. The whole story is pretty simple [1]. From my perspective, the request was to confine feature development into separate branch, to don't impact language adopters. Pay-as-you-go all way down, also for the compiler/rt/phobos codebase itself. I definitely think a stable version with backfixes ported would be great if feasible. The other way round: "keep it in sync with specification document, design set of acceptance tests and do all the development in a separate branch until is verified to both have desired semantics and don't cause any breakage in existing projects." [2] I would like your opinion on that specific request, "keep it in sync with specification document" versus "bureaucracy" [3] I wonder if we are approaching the point where enterprise crowd-funding of missing features or capabilities in the ecosystem could make sense. If you look at how Liran managed to find David Nadlinger to help him, it could just be in part a matter of lacking social organisation preventing the market addressing unfulfilled mutual coincidences of wants. Lots of capable people would like to work full time programming in D. Enough firms would like some improvements made. If takes work to organise these things. If I were a student I might be trying to see if there was an opportunity there. That would great for the ecosystem, for the language... [4] [1] https://forum.dlang.org/thread/o62rml$mju$1...@digitalmars.com [2] https://forum.dlang.org/post/o6fih1$2b14$1...@digitalmars.com [3] https://github.com/dlang/dmd/pull/8346 [4] https://forum.dlang.org/post/detxilaksggqsrdao...@forum.dlang.org /Paolo
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Sunday, 26 August 2018 at 22:54:18 UTC, Walter Bright wrote: On 8/26/2018 1:55 PM, Walter Bright wrote: I will tiresomely ask again, do you have a list of each and every aspect of the poor integration? I know you don't like filing bug reports. I'll make it easy for you. Every time someone you work with says: "I can't use D because ..." "I'm abandoning D because ..." "D sux because ..." Just append a note of it to a text file. It doesn't matter what the reason is, any information is valuable, including: "... because Walter killed and ate my dog" "... because my apartment contract stipulates no pets, no smokers, no D programming" "... because I can't take D jokes anymore" "... because Walter won't stop droning on with his boring Boeing anecdotes" Now and then, just email me the file. It's 2.30 AM here, and you've made me smile :-P /P
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 21:57:55 UTC, Meta wrote: On Friday, 24 August 2018 at 21:53:18 UTC, H. S. Teoh wrote: I think it's clear by now that most of D's woes are not really technical in nature, but managerial. Agreed. I'm not sure how to improve this situation, since I'm no manager type either. Money is the only feasible solution IMO. How many people posting on this forum would quit their job tomorrow and solely contribute to OSS and/or work on their own projects if money wasn't an issue? The majority of people don't like being told what to do, and only want to work on what they're interested in. The only way to get them to work on something they're not interested in is to pay them. As the discussion seed is a post from Mihails, I want to recall the author [1]: "Didn't intend to chime in, but no, that was not what I have meant at all. My stance is that as long as current leadership remains in charge and keep sames attitude, no amount of money or developer time will fix D. What is the point in hiring someone to manage things if Walter still can do stuff like -dip1000? For me moment of understanding this was exact point of no return." What are the opinions on that, specifically on the attitude? [1] https://forum.dlang.org/post/yadddavkoopieykha...@forum.dlang.org /Paolo
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote: On 8/24/2018 6:04 AM, Chris wrote: For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency. Every programmer who says this also demands new (and breaking) features. There's also who demands less (and may be breaking) features.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Wednesday, 22 August 2018 at 11:59:37 UTC, Paolo Invernizzi wrote: Just found by chance, if someone is interested [1] [2]. /Paolo After having seen all the discussions around Mihails post in these days, I'm puzzled by one fact. There was no discussions around one paragraph: "You can't assume there is any control over how declared vision documents get executed in practice. You can't trust any promises from language authors because they don't keep any track of those." I think that this is one of the central points of the post, so why? /Paolo
Dicebot on leaving D: It is anarchy driven development in all its glory.
Just found by chance, if someone is interested [1] [2]. /Paolo [1] https://gitlab.com/mihails.strasuns/blog/blob/master/articles/on_leaving_d.md [2] https://blog.mist.global/articles/My_concerns_about_D_programming_language.html
Re: [OT] Re: C's Biggest Mistake on Hacker News
On Saturday, 28 July 2018 at 14:09:44 UTC, Laeeth Isharc wrote: On Saturday, 28 July 2018 at 13:55:31 UTC, Paolo Invernizzi Perceptions, expectations, prediction... an easy read I suggest on the latest trends [1], if someone is interested... I forgot the link... here it is: https://www.quantamagazine.org/to-make-sense-of-the-present-brains-may-predict-the-future-20180710 Yes - it's a competitive advantage, but opportunity often comes dressed in work clothes. Curiosity is the salt of evolution... for example I'm now intrigued by the Master and His Emissary, I've to read it. And another curiosity: I studied in the 90 in Milano, what was your thought on Hayek, von Mises, in those time? Classic Economics was so boring... We're in an era when most people are not used to discomfort and have an inordinate distaste for it. If you're fine with that and make decisions as best you can based on objective factors (objectivity being something quite different from 'evidence-based' because of the drunk/lamppost issue) then there is treasure everywhere (to steal Andrey's talk title). Opportunities are abundant where people aren't looking because they don't want to. Me and my colleague are pretty different, in the approach to that kind of stuff... Maybe I'll post on the Forum a 'Request for D Advocacy', a-la PostgreSQL, so the community can try to address some of his concerns about modern D, and lower his discomfort! :-P /Paolo
Re: [OT] Re: C's Biggest Mistake on Hacker News
On Saturday, 28 July 2018 at 12:43:55 UTC, Laeeth Isharc wrote: each project I start I give some very hard thought about which development environment I'm going to use, and D is often one of those options. The likely future of D on the different platforms is an important part of that assessment, hence 'predicting' the future of D, hard and very unreliable though that is, is an important element in some of my less trivial decisions. Since you already know D you need to answer a different question. What's the chance the compiler will die on the relevant horizon, and how bad will it be for me if that happens. Personally I'm not worried. If D should disappear in a few years, it wouldn't be the end of the world to port things. I just don't think that's very likely. Of course it depends on your context. The people who use D at work seem to be more principals who have the right to take the best decision as they see it then agents who must persuade others who are the real decision-makers. That's a recipe for quiet adoption that's dispersed across many industries initially and for the early adopters of D being highly interesting people. Since, as the Wharton professor, Adam Grant observes, we are in an age where positive disruptors can achieve a lot within an organisation, that's also rather interesting. A very interesting discussion... really. Perceptions, expectations, prediction... an easy read I suggest on the latest trends [1], if someone is interested... BTW, Laeeth is right in the last paragraph two. I was one of the 'principal' who took the decision to use D in production, 14 years ago, and he described the reasoning of that era very well. Today I'm still convinced that the adoption of D is a competitive advantage for a company, I definitely have to work to improve my bad temper (eheh) to persuade my actual CTO to give it another change. /Paolo (btw, I'm the CEO...)
Re: Looking for the article comparing D to Ada and others
On Wednesday, 25 July 2018 at 21:59:52 UTC, Ali Çehreli wrote: Somebody had posted an article here on how well different languages matched certain requirements of a certain coding safety standards. I remember D was doing pretty well and I think Ada (or SPARK?) was included as well. What article? Where? Thank you, Ali https://forum.dlang.org/post/yzlzlmhshfhetmpxi...@forum.dlang.org
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Wednesday, 25 July 2018 at 17:52:00 UTC, 12345swordy wrote: On Wednesday, 25 July 2018 at 16:43:38 UTC, Paolo Invernizzi wrote: That's an opinion, naturally. No I am expressing an argument not an opinion. I don't know what vocabulary you are used to consult, but your 'pointless' it's a plain and simple opinion. To me it's not pointless at all. "let's force the programmer to think about what he is doing, passing an rvalue by ref" Nonsense, you have shown no evidence that they don't know what they are doing when making a automatic conversion. You might as well argue against the existence of var. Actually, by definition, every bug is made by a programmer that THINK to know what he is doing... no? Aren't you. going a little too far in judging? At best, is "let's catch early some bugs (caused by other problems as Manu pointed out)". He also pointed it is own class of problems, as it can be replicated without ref. An so? Jonathan argumentation and mine is that are are. losing a way to catch such bugs earlier. Set of problems as automatic promotion or conversion, as decades of problems with unsigned/signed have proved... False Equivalence. We are not discussing numeric overflows here. It's not a false equivalence fallacy: all the discussion is about IMPLICIT conversion or rvalues to lvalues... your argumentation smell a little about strawmen (eheh) There's not a magic conversion between apples and oranges in a foreach loop... ref value apart. https://dlang.org/spec/type.html#usual-arithmetic-conversions You where saying? I'm saying that a foreach statement is easily lowered mentally in a for statement, and that implicitly converting between rvalue and lvalue is entirely another beast. I will stop here... btw
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Wednesday, 25 July 2018 at 13:36:38 UTC, 12345swordy wrote: On Wednesday, 25 July 2018 at 12:40:16 UTC, Paolo Invernizzi wrote: That proposal is a 'Syntactic Sugar' feature, that simply hide what normally need to be explicitly coded: proved a temp rvalue, pass it to a callable taking ref. What you call 'simplification', I call it 'obfuscation'; what you call uniformity I call trying to spread a well justified restriction... /Paolo A restriction which causes pointless redundant code for the caller who doesn't always have source code access. If my old teacher assistant taught me anything it is this: Redundant code is bad. You are literately forcing the programmer to create tmp variables that risk the possibility of being shadowed or worse, having its value change. That's an opinion, naturally. What it's "pointless redundant" for you, it is let's "let's force the programmer to think about what he is doing, passing an rvalue by ref" for me, at least. At best, is "let's catch early some bugs (caused by other problems as Manu pointed out)", but as Jonathan states. Your manual solution suggestion have it own set of problems. Set of problems as automatic promotion or conversion, as decades of problems with unsigned/signed have proved... You might as well argue against the foreach statement, because its "obfuscation" There's not a magic conversion between apples and oranges in a foreach loop... ref value apart. /Paolo
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Wednesday, 25 July 2018 at 08:34:30 UTC, Manu wrote: With UFCS as a super popular feature of D, 'this' is not really much of a special guest at all. It's just as much the first argument of a function as the first argument of *any* UFCS call. Guido van Rossum has raised an objection on that a couple of decades ago... There's a tension between Walter effort in turning D as a suitable language for memory correctness, and a good candidate for writing 'bug free rock solid software fast' and the continuous addition of features like this. This isn't 'a feature' so much as lifting a restriction for the sake of a bunch of uniformity and simplification. I can't really see how you can find that disagreeable from your apparent position... That proposal is a 'Syntactic Sugar' feature, that simply hide what normally need to be explicitly coded: proved a temp rvalue, pass it to a callable taking ref. What you call 'simplification', I call it 'obfuscation'; what you call uniformity I call trying to spread a well justified restriction... Finally, sorry to use often the term 'feeling', and sorry for not being constructive: but really is a 'feeling'... I don't pretend to be right. So no problems in just ignoring that It upsets me when people present strong opinions about this who literally have no horse in the race. This is only really meaningful, and only affects you if it actually affects you... It's clearly not important to you, or you wouldn't be basing your opinion on *I kinda feel...* Jonathan's argument is similar. He's worried about something that this thread has tried and failed to determine exactly what is. Meanwhile I think we have determined that the presumed practical trouble cases are even less that I suspected up front. Experience, in programming, has value: Walter is famous for his anecdotes on that. D2 has already a lot of problematic stuff to solve, I not buy adding more (yes) features for the sake of an hypothetical 'simplification' of what it's already possibile. Just to be clear, I'm also against all the new proposed addition for, named parameter, new struct initialisation and so on No pun, really :-P /Paolo
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Wednesday, 25 July 2018 at 02:21:18 UTC, Marco Leise wrote: Am Sat, 21 Jul 2018 19:22:05 + schrieb 12345swordy : On Saturday, 21 July 2018 at 08:55:59 UTC, Paolo Invernizzi wrote: > Frankly speaking, my feeling is that D is becoming a > horrible mess for the programmer... > /Paolo How!? Please Explain. You need to demonstrate evidence instead of appeal to emotional fallacy by resorting to "feels". -Alexander The DIP increases consistency recalling that rvalues are accepted: - for the implicit 'this' parameter in methods - in foreach loop variables declared as ref No more special rules: rvalues are implicitly promoted to lvalues where needed. That's correct, but 'this' is already a special guest in C++ style PL, with its own special rules. The support for ref variable in foreach loop can be removed (yup!), or made stricter.. no more inconsistency. The feeling probably comes from the inevitable realization that the community is pluralistic and Dlang acquired a lot of features that go towards someone else's vision for a good PL. Some want a relaxed stance towards breaking change, some want C++ or ObjC compatibility, some want to know what assembly a piece of code compiles to or have soft realtime constraints that don't work with a system language's mark&sweep GC. Is D2 messier than D1? Sure it is, and it caters to more use cases, too. As soon as you substantiate what exact feature is adding to the horrible mess, someone (often a group) will jump to defend it, because they have a good use case or two. Yep, and I'm conscious to be often a pessimistic, lurking guy here in the forum... :-/ It is kind of ironic that in order to do better than C++ you have to support most of what modern C++ compilers offer and end up having tons of unrelated features that make the language just as bloated as C++ after a decade of community feedback. It is a system PL. I think it needs to be this way and is a lot cleaner with basic data types and more expressive still, lacking a lot of C++'s legacy. There's a tension between Walter effort in turning D as a suitable language for memory correctness, and a good candidate for writing 'bug free rock solid software fast' and the continuous addition of features like this. Joke aside, I'm still on Jonathan side on this. Finally, sorry to use often the term 'feeling', and sorry for not being constructive: but really is a 'feeling'... I don't pretend to be right. So no problems in just ignoring that :-P Cheers, Paolo
Re: C's Biggest Mistake on Hacker News
On Tuesday, 24 July 2018 at 01:31:13 UTC, JohnB wrote: On Tuesday, 24 July 2018 at 00:41:54 UTC, RhyS wrote: Customers do not understand about programming. Your lucky if most clients can even get a proper specification formulated for what they want. If clients are that knowledgeable we do not need to constantly deal with issues where clients had things in their heads different then what they told / envisioned. I think that what Walter meant was when the customer have this problem where their data is leaking (and perhaps losing money) they will ask why, and an alternative to avoid this in the future will rely on a language that tend to follow the safety aspect. John B. Having read all the forum thread around the necessity to terminate an application on bugs or catch-them-and-keep-going, I'm not sure if the programmers folk are not to blame also for that problems. I agree also on the discussion about management, but, sometime, little companies has illuminate technical management, that can dare to rely on innovative languages to do their job, and compete (against big companies with no-so-illuminate-management). So definitely D has some value for them. /Paolo
Re: C's Biggest Mistake on Hacker News
On Tuesday, 24 July 2018 at 00:41:54 UTC, RhyS wrote: I am sorry to say but to succeed as a language beyond being a small or hobby language it takes: Being established already or having a big name to hype behind your "product". Anything beyond that will have topic derail and frankly, its more negative then positive. If I'm not wrong, Python has grown up really slowly and quietly, till the recent big success in the scientific field. I remember also when Ruby was released, and what a killer application like Ruby on Rails has done for its success. /Paolo
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Saturday, 21 July 2018 at 12:54:28 UTC, JohnB wrote: On Saturday, 21 July 2018 at 08:55:59 UTC, Paolo Invernizzi wrote: Frankly speaking, my feeling is that D is becoming a horrible mess for the programmer... I'm starting to think that only a D3, with a lot of thing reorganised without the obsession of breaking changes can safe that beautiful language... If a transition from D to D2 is one cause of that mess, why a new transition wouldn't continue that mess. And yes as new fellow playing with this language since 2012, I think it's becoming more like a C++ in madness. John. Not to talk about the recently revived rcstring, that by default are not a range... guess it... /P
Re: DIP 1016--ref T accepts r-values--Community Review Round 1
On Saturday, 21 July 2018 at 05:40:24 UTC, Nicholas Wilson wrote: It is not just the avoiding copying, if it were I'm not sure I'd support it. For me the greatest benefit is the increase in readability due to not having useless temporaries everywhere in ref heavy code (that may not be under API user's control). Explicit is better than implicit. (The Zen of Python) Frankly speaking, my feeling is that D is becoming a horrible mess for the programmer... And, BTW, I'm totally with Jonathan also on @implicit for copy ctor... I really really don't like it, another nail in the coffin of a beauty, symmetry, and intuitive syntax. I'm starting to think that only a D3, with a lot of thing reorganised without the obsession of breaking changes can safe that beautiful language: Python was _almost_ killed in the 2-3 transaction, but kudos to Guido and the core time, it resurrected more strong than ever. /Paolo
Re: Sutter's ISO C++ Trip Report - The best compliment is when someone else steals your ideas....
On Thursday, 19 July 2018 at 09:44:16 UTC, Steven Schveighoffer wrote: On 7/18/18 1:58 AM, John Carter wrote: With web services, most of the time the shared state you want elsewhere anyway (to make it persistent), so it's a better fit for processes than most program domains. Sharing a _complex_ state to thousand of users is the job for an ACID database. And that couples very well with separate processes. If the shared state is trivial, there's a pletora of library that abstract aways the fact that you are sending messages to a process, thread, or corutine: well, it seems that was the goal of std.concurrency, also! :-P /Paolo
Re: Sutter's ISO C++ Trip Report - The best compliment is when someone else steals your ideas....
On Friday, 13 July 2018 at 13:15:39 UTC, Steven Schveighoffer wrote: On 7/13/18 8:55 AM, Adam D. Ruppe wrote: On Wednesday, 11 July 2018 at 12:45:40 UTC, crimaniak wrote: This error handling policy makes D not applicable for creating WEB applications and generally long-running services. You use process isolation so it is easy to restart part of it without disrupting others. Then it can crash without bringing the system down. This is doable with segfaults and range errors, same as with exceptions. This is one of the most important systems engineering principles: expect failure from any part, but keep the system as a whole running anyway. But it doesn't scale if you use OS processes, it's too heavyweight. Of course, it depends on the application. If you only need 100 concurrent connections, processes might be OK. -Steve Came on, Steve... 100 concurrent connections? /P
Re: Deprecating this(this)
On Monday, 2 April 2018 at 16:00:11 UTC, bachmeier wrote: On Monday, 2 April 2018 at 15:30:23 UTC, Paolo Invernizzi wrote: Andrei wrote in the message I am looking for folks to assist me in creating a DIP for that. There will be a _lot_ of work involved, so don't take it lightly. Andrei is asking others to write a DIP to formalize a decision There's not even an attempt made to pretend there's symmetry. The only way for Manu (and basically anyone else) to propose a change is to write a DIP. Andrei won't even participate in discussions without a DIP. That's probably a good idea. What's not a good idea is to make unilateral decisions about major breaking changes, posting in the forum, and then asking others to write the DIP. That's corporate software development, and it's very discouraging to potential contributors. I think you are plain wrong on this: the 'P' in a DIP stands for Proposal, so any decision is not taken yet. And I'll bet: - Andrei will be the main author or he will partecipate in the writing. - the DIP will follow the usual proceeding, exactly like the others. /Paolo
Re: Deprecating this(this)
On Monday, 2 April 2018 at 13:55:25 UTC, bachmeier wrote: No, the reason nothing gets done is because "that would break code" is used to kill every proposal that comes along. Someone that only responds to proposals with "write a DIP" proceeds to announce a major piece of the language will be deprecated without writing a DIP himself. Corporate leadership doesn't work with an open source project. I could have gotten more involved long ago, but I'd rather not jump on a ship that's sailing in circles. From the many comments I've seen, I'm not the only one. Andrei wrote in the message I am looking for folks to assist me in creating a DIP for that. There will be a _lot_ of work involved, so don't take it lightly. So, let's keep the discussion factual. I'm pretty sure that every aspect will be taken in account and pondered prior to a decision. I'm +1 on major breaking changes if they drive D towards a better shape. /Paolo
Re: CTFE ^^ (pow)
On Monday, 19 March 2018 at 05:27:20 UTC, Norm wrote: On Monday, 19 March 2018 at 04:15:26 UTC, rikki cattermole wrote: On 19/03/2018 5:05 PM, Norm wrote: On Monday, 19 March 2018 at 03:53:07 UTC, rikki cattermole wrote: On 19/03/2018 4:43 PM, Norm wrote: [...] You just said the magic word, medical. D was never an appropriate fit here. dmd's backend has been for thirty years (or so) been up to recently licensed so that you may not use it for this purpose. Nothing has changed here. I have no idea what you're talking about now. What has the backend license got to do with medical? The code generation capabilities of dmd has not been certified for medical usage. In essence, if it generated bad code, kills somebody, your the one at fault, even if the source is fine. You would end up begging to settle out of court. It is my understanding that medical software manufacturers pay for their compilers already certified. So that suggests to me that you're not exactly life threatening but I would still caution you away from D even if that bit is just my own opinion. No, compilers do not need to be certified for class B or class C software. These are the two highest safety classes for medical SW. Beyond class C SW is not allowed, e.g. safety critical interlocks such as the big red button to shut off a radiation dose or stop a robotic system. Compilers are are treated as SOUP (Software of Unknown Provenance), i.e. a black box. Risk analysis leads to risk control measures that in turn ensure people don't die and this is done at the system and component level, not the codegen level. Verification is performed to ensure the system implements the requirements correctly, and subsequently the risk control measures. Not all requirements are risk control measures, but all requirements must be verified as correct. Cheers, Norm I was the CTO and partner of a company using D in medical devices since more than ten years ago... as Norm wrote, medical software is a strange beast... Anyway, as someone else wrote, when I leaved the company, two years ago, the new CTO and my former colleague, decided not to invest anymore in D. After ten years of use. Said that, I'm pretty happy about what's happening in D Land in the last 3/4 months, but clearly there's a lot to be done. /Paolo
Re: DIP 1006 - Preliminary Review Round 1
On Wednesday, 7 March 2018 at 16:04:50 UTC, Timon Gehr wrote: On 07.03.2018 16:30, Paolo Invernizzi wrote: On Wednesday, 7 March 2018 at 15:26:01 UTC, Timon Gehr wrote: On 07.03.2018 15:08, Paolo Invernizzi wrote: On Wednesday, 7 March 2018 at 13:55:11 UTC, Jonathan M Davis wrote: [...] Jonathan, I understand your point, but still I can't find an answer to clarify my doubts. Are we asking for no UB in @safe code? Are we asking for UB in @safe code but constrained to no memory corruptions? /Paolo UB is unconstrained by definition. If it is constrained, it is not UB. That! Thanks! So, @safe code is code where UB should not be possible? Yes. (If you have UB, memory corruption is one of the allowed outcomes, but @safe should not allow memory corruption. So @safe needs to at least ban UB. According to Walter @safe needs to ban memory corruption but not more. Therefore, as memory corruption leads to UB (it is impractical to specify anything else, at least for writes), @safe bans UB and nothing else.) Also note that even in @system code I don't want asserts to cause UB in release. There should be an @system facility for this purpose. (The situation is different than with bounds checks: if bounds checks fail, there will always be a bad memory access, which is UB, but with asserts it's always possible that the assert itself was wrong and the code itself will not trigger UB.) Is it pragmatically possible to reach that goal? /Paolo Yes. (Languages can be type safe and type systems can be arbitrarily powerful.) It is certainly possible to _aim_ for that goal, which Walter and Andrei have done on other occasions. Thanks Timon, now everything it's definitely more clear to me on that matter. I think a good compromise is to just totally ignore assert in release during optimization as a default, and use a compiler flag to let the optimiser peek to them, if a user want to explore that potential gain. Just like '-boundscheck'. Thanks to all for having clarified that point to me (and hopefully to others also!) /Paolo
Re: DIP 1006 - Preliminary Review Round 1
On Wednesday, 7 March 2018 at 15:26:01 UTC, Timon Gehr wrote: On 07.03.2018 15:08, Paolo Invernizzi wrote: On Wednesday, 7 March 2018 at 13:55:11 UTC, Jonathan M Davis wrote: [...] Jonathan, I understand your point, but still I can't find an answer to clarify my doubts. Are we asking for no UB in @safe code? Are we asking for UB in @safe code but constrained to no memory corruptions? /Paolo UB is unconstrained by definition. If it is constrained, it is not UB. That! Thanks! So, @safe code is code where UB should not be possible? Is it pragmatically possible to reach that goal? /Paolo
Re: DIP 1006 - Preliminary Review Round 1
On Wednesday, 7 March 2018 at 13:55:11 UTC, Jonathan M Davis wrote: On Wednesday, March 07, 2018 13:24:19 Paolo Invernizzi via Digitalmars-d wrote: [...] That would make assertions a lot worse to use, because then they would be in production code slowing it down. Also, as it stands, -release is not supposed to violate @safe. To do that, you have to use -boundscheck=off to turn off bounsd checking. That was a very purposeful design decision, because we did not want -release to violate @safe, and if the compiler is allowed to add optimizations which are unsafe based on assertions, then that completely destroys the ability to have @safe code with -release. And if we were going to do that, why did we leave array bounds checking on with -release? [...] Jonathan, I understand your point, but still I can't find an answer to clarify my doubts. Are we asking for no UB in @safe code? Are we asking for UB in @safe code but constrained to no memory corruptions? /Paolo
Re: DIP 1006 - Preliminary Review Round 1
On Wednesday, 7 March 2018 at 13:32:37 UTC, ag0aep6g wrote: On Wednesday, 7 March 2018 at 08:58:50 UTC, Paolo Invernizzi wrote: Just to understand, otherwise, if the assert is removed and it does not hold, you are in UB, You're not. Just let the compiler treat the code as if the asserts weren't there. If the resulting code has UB, it won't compile, because @safe code is statically checked to not have UB. so the request is to guarantee memory safety in a UB state, right? I don't think anyone is asking for that. The request is for no UB in @safe code. Are we asking to statically check things like: Assign Expressions [1] Undefined Behavior: if the lvalue and rvalue have partially overlapping storage if the lvalue and rvalue's storage overlaps exactly but the types are different Is that doable, in practise? [1] https://dlang.org/spec/expression.html#assign_expressions /Paolo
Re: DIP 1006 - Preliminary Review Round 1
On Wednesday, 7 March 2018 at 11:52:05 UTC, Jonathan M Davis wrote: On Wednesday, March 07, 2018 09:22:40 Paolo Invernizzi via Digitalmars-d wrote: On Wednesday, 7 March 2018 at 09:11:10 UTC, Jonathan M Davis wrote: >> So, the request is to just leave assert active as a default >> in @safe code, like the bounds checks? > > No. I'm saying that no optimizations should be enabled which > introduce potential memory corruption. Assertions should > have zero impact on whether code is @safe or not unless the > code in the condition or which is generating the message for > the assertion is @system, and it's no more reasonable to > assume that an assertion is going to pass than it is to > assume that bounds checking won't fail. Regardless, the key > thing here is that @safe code should be guaranteed to be > @safe so long as @trusted code is vetted properly. It should > _never_ be possible for the compiler to introduce memory > safety issues into @safe code. > >> So, the reasoning is that UB should not lead to memory >> corruption, right? > > The reasoning is that no @safe code should ever have memory > corruptions in it unless it calls @trusted code that was > incorrectly vetted by the programmer. The compiler is > supposed to guarantee that @safe code is @safe just like > it's supposed to guarantee that a const variable isn't > mutated or that a pure function doesn't access mutable, > global variables. And as such, introducing anything into > @safe code which could be memory unsafe is a violation of > the compiler's responsibility. Jonathan, I understand your reasoning, but it's not what I'm asking: are we asking for UB that do not lead to memory corruption? I'm saying that @safe code must not be violated by the compiler. Beyond that I'm not arguing about UB one way or the other. And that's clear. If UB must be disallowed to avoid violating @safe, then it must be disallowed. And how to do this, in practise I mean? If some form of UB can be allowed, because it's restricted in a manner that it can't violate @safe but may do something else stupid because the assertion would have failed if it weren't compiled out, I don't care. And that's the original question: are we asking for UB that do not lead to memory corruption? If an assertion would have failed if it weren't compiled out, then you have a bug regardless, and if the code is buggier because of an optimization, then that's fine with me. You have a bug either way. Agreed. What isn't fine is that that result violate @safe, because that would defeat the entire purpose of @safe and make it far, far more difficult to track down @safety problems. So, see above, the original question, agreed. Right now, since no optimizations like Walter has been talking about are done by the compiler, if you have memory corruption, you know that you only have to look at @system and @trusted code to find it, whereas with the unsafe optimizations that Walter is talking about, it then becomes possible that you're going to have to look through the entire program to find the problem. Or you can just turn on assertion, right? If we have corrupted memory in release, there's a bug, somewhere, in the logic or in the implementation of the logic. As you have told, we must audit @system and @trusted, we can imagine to use static checkers or some strange beast like that. But, while doing that, I think that the most common practise is keep running the code with assertion on, do you agree? And right now, you can be sure that you don't have @safety problems in @safe code if you use @trusted correctly, whereas with what Walter is talking about, simply adding an assertion could add @safety problems to your code. Nope, not adding an assertion, but having the process in UB state. And we are back again to the original question. /Paolo
Re: DIP 1006 - Preliminary Review Round 1
On Wednesday, 7 March 2018 at 09:11:10 UTC, Jonathan M Davis wrote: So, the request is to just leave assert active as a default in @safe code, like the bounds checks? No. I'm saying that no optimizations should be enabled which introduce potential memory corruption. Assertions should have zero impact on whether code is @safe or not unless the code in the condition or which is generating the message for the assertion is @system, and it's no more reasonable to assume that an assertion is going to pass than it is to assume that bounds checking won't fail. Regardless, the key thing here is that @safe code should be guaranteed to be @safe so long as @trusted code is vetted properly. It should _never_ be possible for the compiler to introduce memory safety issues into @safe code. So, the reasoning is that UB should not lead to memory corruption, right? The reasoning is that no @safe code should ever have memory corruptions in it unless it calls @trusted code that was incorrectly vetted by the programmer. The compiler is supposed to guarantee that @safe code is @safe just like it's supposed to guarantee that a const variable isn't mutated or that a pure function doesn't access mutable, global variables. And as such, introducing anything into @safe code which could be memory unsafe is a violation of the compiler's responsibility. Jonathan, I understand your reasoning, but it's not what I'm asking: are we asking for UB that do not lead to memory corruption? /Paolo
Re: DIP 1006 - Preliminary Review Round 1
On Wednesday, 7 March 2018 at 00:11:33 UTC, Timon Gehr wrote: On 06.03.2018 19:49, Paolo Invernizzi wrote: I simply don't understand why enforce or a custom check can't be used @safe code, if you want that behaviour. ... I have explained why. UB is non-modular and you don't (want to) control all the code that you use. As I've written, you should ask for debug versions of every closed source library that it's used in a project, it's always a win-only things to do. Also, enforce cannot be disabled. Because if you use it instead of assert, the enforce has just detected a bug, so it's just doing the sane thing to join that cases: stop the execution because the process is entering UB. And no, keeping the check or introducing UB are not the only sensible options. Just to understand, as I've already asked: do we aim at UB that guarantees no memory corruptions? /Paolo
Re: DIP 1006 - Preliminary Review Round 1
On Tuesday, 6 March 2018 at 23:50:20 UTC, Timon Gehr wrote: On 06.03.2018 10:02, Walter Bright wrote: On 3/6/2018 12:45 AM, Timon Gehr wrote: Anyway, "do not use assert" is not the solution, as I have explained many times now. My interpretation is you want D assert to behave like C assert. This interpretation is wrong. I, as well as other people, want a compiler option to make the compiler ignore D asserts and contracts. Not more, not less. Is it an option having the compiler not to remove the asserts from @safe code, like bounds check? Just to understand, otherwise, if the assert is removed and it does not hold, you are in UB, so the request is to guarantee memory safety in a UB state, right? The point I don't grasp is why keep running in UB in @safe is acceptable, while memory corruption not. Creating library asserts is why D has special support for __FILE__ and __LINE__ like C does, and for the same reasons. What I want is special support for sane built-in assert semantics using a compiler flag. and that's a reasonable request, that, IMHO, does not hurts anybody That does not mean that there cannot _also_ be a flag to unleash the nasal demons upon unworthy programmers who were stupid enough to collaborate with someone who imported an external library that was written by somebody who had a bad day one time and left in a wrong assertion. That's a process management problem, I think. Debug version of external libraries can be requested, and the author can be reported about the bad-day wrong assert. I know, if I can catch it... Again: There is no reason why we need to force one behavior over the other. This should be configurable. I'm all in for having the maximum flexibility in configuration, but I would stick with Walter as keeping its idea as the default. /Paolo
Re: DIP 1006 - Preliminary Review Round 1
On Tuesday, 6 March 2018 at 20:03:11 UTC, Jonathan M Davis wrote: On Tuesday, March 06, 2018 18:49:42 Paolo Invernizzi via Digitalmars-d wrote: I simply don't understand why enforce or a custom check can't be used @safe code, if you want that behaviour. If the program must HALT on this or that, well, what is better than an explicit piece of unremovable code that do that? Instead of writing 'assert', one should write 'enforce'. 1. It's quite common for folks to want to add debugging checks that are compiled out in -release. That's exactly what assert is for in pretty much every lanugage that has it. It's what folks expect to use and what your average programmer will use without thinking about @safety issues at all. It's what everyone uses right now, and I'm pretty sure that almost everyone using it has no clue that Walter considers it okay for assertions to introduce optimizations which are not memory safe, and if/when he does do so, a lot of D code will suddenly have @safe code which is not memory safe. Such problems will hopefully be hit rarely, because hopefully, the code will have been well-tested, and the assertions will have found all of the related bugs, but there's every possibility that some bugs will manage to not be caught, thereby resulting in @safe code being unsafe. No one is going to be looking to use solutions other than assertions for what assertions are for unless we start telling everyone to avoid assertions, because they make @safe code unsafe. And honestly, if assertions make @safe code unsafe, I don't see a good argument for using them at all. If I didn't care about code being @safe, I wouldn't be using @safe. @safe is supposed to guarantee that the code is memory safe. Understood. Are asking that UB should not include memory corruptions? 2. I think that it's fundamentally a terrible idea to allow built-in language features to violate @safe. Aside from issues related to @trusted being misused, @safe code should be guaranteed to be memory safe, and it should be considered a bug any time that it isn't. That's why @safe exists. No one should have to be looking at @safe code to track down memory safety problems. And if they do, then @safe is not doing it's job. Array bounds checks are left in @safe code for exactly these reasons. So, the request is to just leave assert active as a default in @safe code, like the bounds checks? I'm all for introducing optimizations that do not violate @safe, but if we allow @safe code to be unsafe, then why do we even have it? So, the reasoning is that UB should not lead to memory corruption, right? /P
Re: DIP 1006 - Preliminary Review Round 1
On Tuesday, 6 March 2018 at 17:34:08 UTC, 12345swordy wrote: On Tuesday, 6 March 2018 at 17:24:35 UTC, Jonathan M Davis wrote: On Tuesday, March 06, 2018 16:30:09 John Colvin via Digitalmars-d wrote: On Tuesday, 6 March 2018 at 02:05:58 UTC, Walter Bright wrote: > [...] So, to clarify, adding asserts to my code makes my release builds violate @safe? If the compiler actually optimized based on assertions, then yes, but not right now. As I understand it, the problem is theoretical at the moment, because the compiler does not yet optimize based on assertions, but once it does, if it's allowed to introduce optimizations that would be not be memory safe if the assertion would have failed if it hadn't been compiled out, then @safe will be violated, and at that point, I would be telling everyone to never use assertions, because they're too dangerous. If we can restrict the compiler to optimizations that are memory safe, then I don't see a problem, but clearly, Walter is not in agreement that the optimizations should be restricted in that manner. - Jonathan M Davis I think a reasonable compromise is to introduce a new system attribute such as @unsafeoptimize to tell the programmer that this function may have it's @safe attribute removed when making optimizations based on the asserts. We have @trusted attribute for a good reason here. I simply don't understand why enforce or a custom check can't be used @safe code, if you want that behaviour. If the program must HALT on this or that, well, what is better than an explicit piece of unremovable code that do that? Instead of writing 'assert', one should write 'enforce'. /Paolo
Re: DIP 1006 - Preliminary Review Round 1
On Tuesday, 6 March 2018 at 16:30:09 UTC, John Colvin wrote: On Tuesday, 6 March 2018 at 02:05:58 UTC, Walter Bright wrote: On 3/5/2018 2:30 PM, John Colvin wrote: This just feels bad. Adding extra failsafes for my debug program shouldn't make my release program less safe. Then use `enforce()`. So, to clarify, adding asserts to my code makes my release builds violate @safe? Only if the assert does not hold, you have _not_ tested it, and a future optimiser will use the assert expression for some hints that generated broken code. At the end, I'm with Walter: you should have tested the code with the assert enabled, and you should have noticed that the assert it's not holding _before_ running the code in release without them. /Paolo
Re: dip1000 state
On Friday, 2 March 2018 at 18:07:34 UTC, carblue wrote: (It may be absolutely unrelated, but there once was a very productive and knowledgeable compiler et. al. contributor, 9rnsr, Hara Kenji; though not contributing to dmd since ~ 1.5 years any more, he's still ranked #1 in number of contributions; I think, he's a busy professor at a Tokyo university, but I'm really curious to know why he stopped coding; I guess, dmd improvement speed still suffers from his decision). https://github.com/dlang/dmd/pull/5239 https://github.com/dlang/dmd/pull/5304
Re: Opt-in non-null class references?
On Friday, 2 March 2018 at 10:41:05 UTC, Stefan Koch wrote: On Friday, 2 March 2018 at 09:59:53 UTC, deadalnix wrote: Honestly, this is not that hard. It's very hard in DMD because it doesn't go through an SSA like form at any point. It's rather disappointing to see the language spec being decided upon based on design decision made in a compiler many years ago. And how easy is transformation into SSA ? that's not all loads and stores ? It's the single assignment the key...
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 17:46:58 UTC, Adam D. Ruppe wrote: On Tuesday, 27 February 2018 at 17:41:07 UTC, H. S. Teoh wrote: And just about every new dmd release, people fume on this forum about regressions and gratuitous code breakages. Not all deprecations/code breakages are *regressions* and *gratuitous*. You just need to do a cost/benefit look at it. For C++ though, supporting decades of very widespread use is doing to adjust the cost calculus of a change relative to D, of course. +1
Re: Postgres and other database interfaces
On Saturday, 24 February 2018 at 15:32:32 UTC, Adam D. Ruppe wrote: On Saturday, 24 February 2018 at 14:13:18 UTC, Joe wrote: Again, coming from Python, I'm familiar with RTD So I actually just made this extension to my dpldocs website: http://ddb.dpldocs.info/ddb.postgres.html You can try going to http://any-dub-package.dpldocs.info and it will try to build the docs on demand. for example: http://dpq.dpldocs.info/dpq.html If you're the first user to hit a page, it might take some time to load and send you to a random page once generation is complete, but then you can navigate with the sidebar to see the rest. I literally just slapped this together now, so I expect it won't be perfect, but this has been on my todo list for a year (I even bought a VPS to host it on... 6 months ago and have been paying for it without even using it!), so it was time to do. :-O Adam, you are the man! I'll never stop of being surprised by your way of coding! Great Job! Joe: I think this is also a terrific 'welcome aboard' about how fast and quickly things can be done in D! :-P /Paolo
Re: Postgres and other database interfaces
On Saturday, 24 February 2018 at 09:10:03 UTC, aberba wrote: On Saturday, 24 February 2018 at 08:32:38 UTC, Paolo Invernizzi wrote: On Saturday, 24 February 2018 at 07:57:47 UTC, aberba wrote: On Saturday, 24 February 2018 at 05:33:56 UTC, Joe wrote: 4. ddb. About the same number of downloads as the above. Implemented on top of front/backend protocol. No documentation although repository has a folder with two sample programs. Some developers spend hours writing code but don't feel the need to speed minutes documenting or at least showing how to use their code. Part of the reason others roll their own (one they will understand). Goes on and on. Have you tried to generate the documentation? Look for example inside the source files... https://github.com/pszturmaj/ddb/blob/bd55beea0df6e5da86a71535ff6d9800c0711c7c/source/ddb/postgres.d#L2 https://github.com/pszturmaj/ddb/blob/bd55beea0df6e5da86a71535ff6d9800c0711c7c/source/ddb/db.d#L19 /Paolo Worst case answer I just talked about I think no... The documentation on how to use the package is present, it's just inside the modules as Ddoc documentation. Joe, you can easily 'extract' it using the proper -D compiler switch /Paolo
Re: Postgres and other database interfaces
On Saturday, 24 February 2018 at 07:57:47 UTC, aberba wrote: On Saturday, 24 February 2018 at 05:33:56 UTC, Joe wrote: 4. ddb. About the same number of downloads as the above. Implemented on top of front/backend protocol. No documentation although repository has a folder with two sample programs. Some developers spend hours writing code but don't feel the need to speed minutes documenting or at least showing how to use their code. Part of the reason others roll their own (one they will understand). Goes on and on. Have you tried to generate the documentation? Look for example inside the source files... https://github.com/pszturmaj/ddb/blob/bd55beea0df6e5da86a71535ff6d9800c0711c7c/source/ddb/postgres.d#L2 https://github.com/pszturmaj/ddb/blob/bd55beea0df6e5da86a71535ff6d9800c0711c7c/source/ddb/db.d#L19 /Paolo
Re: Annoyance with new integer promotion deprecations
On Monday, 5 February 2018 at 23:18:58 UTC, Timon Gehr wrote: On 05.02.2018 22:56, Walter Bright wrote: It's necessary. Working C expressions cannot be converted to D while introducing subtle changes in behavior. ... Neither byte nor dchar are C types. The idea is a byte can be implicitly converted to a dchar, but not the other way around. Hence, f(byte) is selected as being the "most specialized" match. The overloading rules are fine, but byte should not implicitly convert to char/dchar, and char should not implicitly convert to byte. +1
Re: Quora: Why hasn't D started to replace C++?
On Friday, 2 February 2018 at 18:17:30 UTC, H. S. Teoh wrote: On Fri, Feb 02, 2018 at 03:06:57PM +, Mark via It has, to some extent. But the fundamental problem remains that more manpower is needed so that he can be freed up to do the more important things. Having to personally review all new public symbols added to Phobos, for example, just doesn't seem scalable in the long run. But, as Andrei himself said, the last time he left that decision to somebody else, there was a noticeable deterioration in the quality of code in Phobos. So we need not only more manpower, but also more *trusted* manpower; people who share the same views as Andrei, whom he can trust to make the right decisions without his intervention. There's no silver bullet to this, and it's indeed a very difficult task. Having done this for a lot of my life, my advice is simply to keep that always present in every decision, and, sometime, be more permissive in the short term decisions, to just archive that more important long term goal. Growing (and discovering!), talents it's indeed a job by itself. /P
Re: Quora: Why hasn't D started to replace C++?
On Friday, 2 February 2018 at 08:21:33 UTC, Martin Tschierschke wrote: On Thursday, 1 February 2018 at 22:38:36 UTC, Walter Bright wrote: On 2/1/2018 3:11 AM, Martin Tschierschke wrote: Idea: There should be some kind of news ticker for all enhancements and important decisions, maybe at first just via twitter with a special #tag beside #dlang where all updates are announced. And a place on the homepage, where this feed is displayed separately. It's already there on the right side of https://dlang.org/ with a special #tag beside #dlang The focus was on a feed with _two_ tags #dlang and #dfoundation for example. In the feed on the homepage everything is mixed up and I am feeling a lot information about progress - made in the background - is missing. Maybe there should be a blog post, with some kind of status report every .. weeks or .. month? Telling more about the focus of the D foundation, statistics of downloads, number of fixed bugs, partly similar to Adams week in D but more official. I think the content of such a post may find its way into more mainstream IT magazines, if marked as official d foundation press release even more. The best status report I've met is definitely the FreeBSD quarterly status report: https://www.freebsd.org/news/status/status.html I suggest to take a look at that, as an inspiration and yes, a quarterly report is enough. /Paolo
Re: Quora: Why hasn't D started to replace C++?
On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote: On Wednesday, 31 January 2018 at 10:35:06 UTC, Benny wrote: [...] Not sure why that's a bad thing. They all have their ups and downs: [...] That's the most refreshing post on D future since a long time. Thanks, really. /Paolo
Re: D as a betterC a game changer ?
On Monday, 29 January 2018 at 10:34:35 UTC, Russel Winder wrote: On Wed, 2017-12-27 at 19:11 +, Laeeth Isharc via Digitalmars-d wrote: […] People also continue to think and write as if the D Foundation has this inexhaustible fund of resources (pecuniary and people) that it can command to work on whatever Andrei and Walter think best. But on the other hand there is little or no presence of The D Foundation in online places I frequent. The D Foundation does need to have a plan for becoming a thing that people would put resource into. For example, any news on the new CTFE? /Paolo
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Sunday, 28 January 2018 at 08:40:35 UTC, Basile B. wrote: On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote: You know you're not the first coming with this topic. I've developped a theory. You guys are looking for excuses to not get into D. If IDE were okay you would find something else. That's the wrong mood to have with someone just reporting what's a fact: D Langland IDE quality is FAR lower than the major competitors out there. Full stop. /P
Re: What don't you switch to GitHub issues
On Friday, 5 January 2018 at 22:55:43 UTC, Adam D. Ruppe wrote: On Friday, 5 January 2018 at 22:45:15 UTC, Walter Bright wrote: I could easily spend 30 hours per day just reading the n.g. Learn threads tend to be quite short. Just skim the first post in a thread to see what people talk about. It takes mere minutes, spread out over the day. +1 We all have to manage time, me too: for example, I try to give advices on something that's specific in my domain, see [1], as I've very very little time to spare in d-land... You wrote [2] that the main problem is "more people doing quality work. Not more process". So It really worth spending your time in coding for compiler coloured messages and not in trying to solve that? As an example for reasoning, you have just written [3] that merging PR that are OK but not great is bad, as they resulted in more regression to be fixed by you. Main problem: more people doing quality work. """ Dear community, as we are trying to leverage the number of people doing quality work on the compiler, we will merge PR that are OK but not great, for a Z months period. We are expecting an increase in the number of people studying and working on the compiler, training them to become potential future core team members. In the judgement of the core time, now we have X skilled core contributors, while you can find below: - the numbers for distinct people who opened pull request month by month. - the numbers of regressions open and closed weekly for the past period. - the numbers for OK and great PR pushed in the past. We are expecting to increase the number of skilled core contributors from X to Y at the end of the period, an increase of the monthly open regression to K balanced by an increased rate of closed regression by Z. """ Then, after the period, you simply retake the measure, and you have put in front of everybody an evidence. That is just a fast crafted example, not so pertinent, but it gives the idea of what I'm trying to suggest. I would be interested in hearing Laeeth opinion on that. But, where are the metrics? I'm always so marvelled that engineers use so often 'their personal impressions' instead of a sane, carefully crafted metric (instead of the actual vanity and not actionable number of downloads). That would be a good field of work for the foundation, for example. /P [1] http://forum.dlang.org/post/pdbpremnjtuzakkja...@forum.dlang.org [2] http://forum.dlang.org/post/p2pdn5$8dm$1...@digitalmars.com [3] http://forum.dlang.org/post/p2pcts$76k$1...@digitalmars.com
Re: What don't you switch to GitHub issues
On Friday, 5 January 2018 at 13:02:20 UTC, Andrei Alexandrescu wrote: On 1/5/18 6:04 AM, Paolo Invernizzi wrote: Andrei recently posted that he is following less the forums as he prefer to invest his time in a different way ... Adam suggested Walter to follow the 'learn' forum to have a cleaner idea about common problems in the language usage, and Walter replied that he prefers to invest his time digging and solving Bugzilla issues... There's nothing wrong with that, and it's reasonable also. But it's a sign, IMHO, of something wrong with the management of the 'human factors' in dlang-land. Thanks for writing. We are following the forums, just that we are trying to convert idle debates into actual impact. Michael Parker is very helpful as well. My perception is we are in touch with the community, though definitely things could be improved. -- Andrei Thanks Andrei, glad to hear that, and you are right about Michael. Laeeth is also doing a very positive work in keep things focused in discussions. Having just read that Walter is working on coloured error messages, as a contribution to the community I'm quoting what I've emailed to you quite long ago. Let's see if we can do something about this. "Regarding what I’ve written as an advice, I’m not an engineer, I’m coming for school of economics (but I’m a programmer, too), but hey, my fast advice are: - be proud: commercials are appreciating that the D core team is encouraging companies to submit their needs. Not only Industry proven, Industry Friendly and supportive, should be big on the DLang site, and it’s already happening. - be selective: their needs in the _actual_ D usage; they are taking a risk and investing in D, feedback coming from companies using D daily with large codebase, must have a bigger weight than other feedback. - be open: just transform that feedback, with the right omissis if necessary, in something public. - be addicted to facts: try to separate opinions from facts on the previous point, digging from requests for a feature to the problem that they are trying to solve with the requested feature. - be predictive: before taking a choice on the language, make a public statement about what you are expecting as a result in the use of D, and how it will be measured in the future: a LOT of things are measurable. - be quantitative: your download statistics are a good start, try to collect from commercials statistics about the length of the codebase, the compilation times, how many are using a feature (C++ integration, allocators, scope when polished). - be fact driven: analyse your own predictions about metrics with what you are as results from measuring, and iterate on the next decisions (also) based on that." /Paolo
Re: What do you want to see for a mature DLang?
On Friday, 5 January 2018 at 01:29:04 UTC, Laeeth Isharc wrote: So it's highly unusual sets of people like that, or like the founders of Sociomantic, or like the EMSI guys, or Liran's guys at Weka that are likely to be D adopters in the next wave. Not people who can't see through error messages (which are much better than C++ anyway). +1000 I would add that D should leverage the fact that is a "company friendly" language: the core team cares about problems raised by commercials that are using it (or, at least, it try hard to do it! :-P). That's pretty unique, in that phase of his history, compared to what we can see around. Well, it should do this in a more structured way, as I've suggested to Andrei, but it's definitely a big plus. /Paolo
Re: What don't you switch to GitHub issues
On Thursday, 4 January 2018 at 19:06:14 UTC, Jonathan M Davis wrote: On Thursday, January 04, 2018 10:27:37 H. S. Teoh via Digitalmars-d wrote: On Thu, Jan 04, 2018 at 10:23:57AM +, Paolo Invernizzi via Digitalmars-d wrote: > On Thursday, 4 January 2018 at 07:47:41 UTC, H. S. Teoh > wrote: > > [...] > > I'm missing Kenji... Me too. :-( Does anybody know what happened to him? He just sortof dropped off the radar suddenly and I haven't been able to find out where he went or what happened to him since ~2 years ago. I don't know the details, but I heard that he got annoyed when Andrei closed some of his PRs that were supposed to reformat the compiler's code to match what it had been before it was automatically converted to D (since apparently, the automatic conversion mucked with some of the formatting). I gather than Keji preferred the way that the code had been formatted before, whereas Andrei thought that PRs that just changed formatting were a waste of time, but I don't know. There may have been other causes of friction involved, or something else may have happened in his personal life, but it sounded like Kenji got annoyed/frustrated over what was happening with his PRs for dmd and left. Either way, he was a strong contributor, and it's a shame that he's gone now. Plenty of other good contributors have basically fallen off the map as well, but his loss is probably more strongly felt than most given that he was able to do an insane amount of work, and he was one of the core contributors to the compiler. - Jonathan M Davis I remember very well that event... along with others. Andrei recently posted that he is following less the forums as he prefer to invest his time in a different way ... Adam suggested Walter to follow the 'learn' forum to have a cleaner idea about common problems in the language usage, and Walter replied that he prefers to invest his time digging and solving Bugzilla issues... There's nothing wrong with that, and it's reasonable also. But it's a sign, IMHO, of something wrong with the management of the 'human factors' in dlang-land. /Paolo
Re: What don't you switch to GitHub issues
On Thursday, 4 January 2018 at 20:05:30 UTC, Steven Schveighoffer wrote: On 1/4/18 2:21 PM, H. S. Teoh wrote: Another person I miss is bearophile... while AFAIK he did not actually contribute code, he was very active in submitting bugs and enhancement requests, many of which led to significant improvements to D. He also just dropped off the radar without any sign of what happened. Did he get frustrated with D and went to Rust or Go or something? bearophile went to Rust I think. https://www.reddit.com/r/programming/comments/6d25mg/faster_command_line_tools_in_d/di01i54/ -Steve Ooo! I was unaware he is an Italian like me... I'm wondering if he is living not too far from Milano... /P
Re: Maybe D is right about GC after all !
On Thursday, 4 January 2018 at 10:18:29 UTC, Dan Partelly wrote: Id rather use a nice language as D to write new software, not to port old **working** tools which are only maintained and not developed to it. I see no sense for that. And the reality of having ported the DMD frontend to D and that Walter is porting the DMC frontend to D is here to just tell us that such things are worth sometimes... /P
Re: What don't you switch to GitHub issues
On Thursday, 4 January 2018 at 07:47:41 UTC, H. S. Teoh wrote: [...] I'm missing Kenji...
Re: D as a betterC a game changer ?
On Wednesday, 27 December 2017 at 18:01:46 UTC, Russel Winder wrote: On Wed, 2017-12-27 at 16:50 +, Paolo Invernizzi via Digitalmars-d wrote: […] That's another things I really don't understand... The community know of C, obviously. They know of C++ and have consciously ignored it. They know of Rust and have embraced it. They have never heard of D. I still think that's just a matter of doing well the homework. If you are searching for alternatives to C, D is not so hidden, if alone I alone managed to find it, long ago... /** * KickStart provides logic to upgrade\start\watchdog a target process. * * Author: Paolo Invernizzi * Date: Jun 26, 2006 * * License: All rights are reserved. Reproduction or transmission in whole or * in part, in any form or by any means, electronic, mechanical or otherwise, is * prohibited without prior written permission of the copyright owner. * */ module kickstart.kickstart;
Re: D as a betterC a game changer ?
On Wednesday, 27 December 2017 at 16:42:49 UTC, Russel Winder wrote: D wasn't an option here due to lack of knowledge by the GStreamer crew. That's another things I really don't understand... /Paolo
Re: Maybe D is right about GC after all !
On Wednesday, 27 December 2017 at 15:37:22 UTC, rjframe wrote: On Tue, 26 Dec 2017 14:54:14 -0800, Walter Bright wrote: On 12/26/2017 1:03 AM, Paolo Invernizzi wrote: The point is that the presence of one @safe: line in the module can be mechanically checked, over one million devs working on a codebase. The whole point of Walter argumentation is 'mechanically'. That's right. C++ is based on faith in the programmer using best practices. D is not based on faith, it can be automatically checked. If the programmer opts-in to those checks... it's a +1 for pragmatism but does make marketing the language a bit weird -- one-liners spawn objections to the integrity of the claim (such as a portion of this thread; if there are objections within the community, how much more will we find objections outside it!). When I hear someone talk about a memory-safe language (especially as a major feature), I do think memory-safe by default. The thing is, D does have support for memory-safety by default (bound-checked arrays, etc.), and allows you to opt-in to greater safety guarantees; but that's not what many think of when they think memory-safe (it doesn't really help that every language provides their own, slightly different, definition). And D has faith that programmers using @trusted know what they're doing (for both writing and calling the function). There is no avoiding trust in a useful language. I prefer pragmatism over marketing all the times. If I was a company evaluating a language, I would notice that my safety goal can be reached right today: - the language guarantees that pieces of written code are memory safe. - there are plenty of easy way to force that, during the development process. - there's the possibility to escape this safety net to gain flexibility, and such part of the code can by easily searched and peer reviewed for memory corruption problems. That's a big, big advancement compared to the status quo (C/C++). It's difficult for me to comprehend why a company should not take advantage of it, if it cares about memory safety, only because @safe is not the default: that's a really _minor_ issue, compared to the gain of having the work done. /Paolo
Re: Maybe D is right about GC after all !
On Tuesday, 26 December 2017 at 11:54:12 UTC, codephantom wrote:
On Tuesday, 26 December 2017 at 10:00:25 UTC, Paolo Invernizzi
wrote:
IMHO, the lost list of vulnerability in code shipped by "first
class enterprises" is just crying out that C/C++ is not
mechanically checkable.
And we are talking about company that can literally spend an
Everest of money on that.
/Paolo
Well, the 'mechanics of checking' continue to need improvement,
whether it's C, C++, D, or whatever
A language that is flexible enough to do the things you can do
with such a language, comes at a cost.. which is safety (or
program correctness to be precise). Flexibility breeds bugs!
That's just how it is. It's inescapable.
And I doubt that it has anything to do with how much money you
can spend.
In the example below, which is D code, I simply have to
'forget' to annotate with @safe, and then it's anyone's guess
at to what will happen (at least in the second example)
i.e. the mechanical checks don't occur because I simply
'forgot' to do something.
// ---
module test;
import std.stdio;
// from:
https://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/
// look at how flexible D is...
void main()
{
auto buf = new int[1];
//buf[2] = 1; // compiles ok, even with @safe.
// but get range violation at runtime,
// whether you use @safe or not
// (unless you've disabled bounds checking)
buf.ptr[2] = 1; // compiles ok, runs ok - or does it?
// however, if you 'remember' to use @safe,
// then it won't compile, and you're safe.
}
// -
I have to disagree, again.
It's factual that you can mechanically impose that a module
contains only @safe code, and you can do it in multiple ways. You
can 'mechanically' impose to write memory safe code in D.
With C/C++ you simply can't do it anything similar, today (and,
IMHO, neither tomorrow): the rising of Rust is here to tell us
exactly that.
/Paolo
Re: Maybe D is right about GC after all !
On Tuesday, 26 December 2017 at 09:21:20 UTC, codephantom wrote: On Tuesday, 26 December 2017 at 09:03:31 UTC, Paolo Invernizzi wrote: The point is that the presence of one @safe: line in the module can be mechanically checked, over one million devs working on a codebase. The whole point of Walter argumentation is 'mechanically'. /Paolo My C/C++ code can be 'mechanically' checked too.. and those checks are better than they've even been, and getting better. IMHO, the lost list of vulnerability in code shipped by "first class enterprises" is just crying out that C/C++ is not mechanically checkable. And we are talking about company that can literally spend an Everest of money on that. /Paolo
Re: Maybe D is right about GC after all !
On Tuesday, 26 December 2017 at 07:01:16 UTC, codephantom wrote:
On Tuesday, 26 December 2017 at 04:47:35 UTC, Walter Bright
wrote:
Only if someone considers this as fixed:
int foo(int* p) { return p[1]; }
int bar(int i) { return foo(&i); }
clang++ -c test.cpp -Wall
good example..and it makes a good point.
however, let that point be not that C/C++ is flawed (since
pointers are meant to let you point to anywhere), but rather
that the code example is flawed.
there is a difference between a flawed language, and flawed use
of that language.
e.g. what if I accidently left out the @safe attribute on those
functions in D?
The point is that the presence of one @safe: line in the module
can be mechanically checked, over one million devs working on a
codebase.
The whole point of Walter argumentation is 'mechanically'.
/Paolo
Re: lld status
On Friday, 22 December 2017 at 09:46:40 UTC, Jacob Carlborg wrote: On 2017-12-22 00:11, Atila Neves wrote: I tried lld on Linux for D binaries and some of them crash. That might not mean anything on Windows, but given that I've run into 2 dmd bugs so far in which picking one of ld.bfd or ld.gold produced crashing binaries, I'd be wary of using lld on Windows until it's thoroughly tested on dozens of executables. I tried to use lld to cross compile to macOS on Linux. It crashed on the first try, might even have been a C program. It worked for me the other way round, to Linux on macOS, and worked also to Win64 on macOS. /Paolo
Re: @ctfeonly
On Friday, 8 December 2017 at 02:14:09 UTC, H. S. Teoh wrote: On Thu, Dec 07, 2017 at 07:20:57PM -0700, Jonathan M Davis via Digitalmars-d wrote: [...] In spite of the fact that CTFE is done at compile time, __ctfe is a runtime thing - it's just that it's runtime from the perspective of CTFE. So, stuff like static if or static assert doesn't work. You have to use if or a ternary operator or some other runtime conditional, though it's a common misunderstanding that __ctfe is used with static if, and people screw it up all the time. I don't know why it's a runtime thing rather than a compile time thing though. There's probably a good reason for it, but at first glance, it seems like a rather weird choice. [...] Sigh: https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time T Woaaa... amazing job, Teoh! It seems that no link in the wiki points to that, or I'm wrong? That valuable stuff should be more visible... /Paolo
Re: Website down: code.dlang.org
On Tuesday, 28 November 2017 at 15:33:39 UTC, Jack Stouffer wrote: On Monday, 27 November 2017 at 10:20:17 UTC, Chris wrote: There seems to be a problem with http://code.dlang.org/ at the moment (27.11.) Down again. And so it was my CI pipeline... /P
Re: D vs Rust
On Sunday, 3 September 2017 at 19:40:27 UTC, Ali Çehreli wrote: > Hi Bearophile! I'm afraid bearophile has moved to greener pastures. I've run into bearophile on Reddit on Rust-related threads. He uses a different name there. *sigh*
Re: Need some vibe.d hosting advice
On Friday, 11 August 2017 at 13:06:54 UTC, aberba wrote: So I'm into this platform with a vibe.d api server + back-end and I'm confused/curious to know the hosting package to use. I will have a lot of images uploaded by users. [...] We are using dockerized vibe.d containers in a docker swarm hosted on DigitalOcean. /Paolo
Re: Dub
On Friday, 23 June 2017 at 10:38:23 UTC, Russel Winder wrote: 350 issues, 42 pull requests. I have to admit I am shocked. +1 /Paolo
Re: Replacing Make for the DMD build
On Friday, 16 June 2017 at 07:00:10 UTC, Jacob Carlborg wrote: On 2017-06-16 08:30, Russel Winder via Digitalmars-d wrote: A direct question to Walter and Andrei really. If someone, let us say Russel Winder, create a CMake/Ninja and/or Meson/Ninja build for DMD, is there any chance of it being allowed to replace the Make system? If the answer is no, then Russel will obviously not waste his time doing something that will not be accepted. I would guess it's more likely that Make would be replaced by a build script written in D than any of the above. +1! Along with a simple sh/bat generated script that simply builds everything, without checking the dependencies ... /P
Re: Makefile experts, unite!
On Monday, 12 June 2017 at 20:04:22 UTC, H. S. Teoh wrote: On Mon, Jun 12, 2017 at 10:41:13PM +0300, ketmar via we have to basically build the entire OS along with all its utilities and other application software that will run on it. ... and tup can do it [1]... ;-P /P [1] http://gittup.org/gittup/
Re: CTFE Status 2
On Tuesday, 6 June 2017 at 18:51:58 UTC, H. S. Teoh wrote: Things like this make you *really* appreciate D features and the oft-maligned but life-saving GC. +1000! GC is an opportunity, not a burden! :-P /Paolo
Re: Bad array indexing is considered deadly
On Sunday, 4 June 2017 at 19:12:42 UTC, Jacob Carlborg wrote: On 2017-06-04 20:15, Joseph Rushton Wakeling wrote: On Friday, 2 June 2017 at 15:19:29 UTC, Andrei Alexandrescu wrote: Array bound accesses should be easy to intercept and have them just kill the current thread. Ideally, fiber, as well. Probably the real ideal for this sort of problem is to be able to be as close as possible to Erlang, where errors bring down the particular task in progress, but not the application that spawned the task. Erlang has the philosophy of share nothing between processes (green processes), or task as you call it here. All allocations are process local, that makes it easier to know that a failing process doesn't affect any other process. If I'm not wrong, it also uses a VM, also if there's the availability of a native code compiler... If a VM is involved, it's another game... /Paolo
Re: Bad array indexing is considered deadly
On Saturday, 3 June 2017 at 10:47:36 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 3 June 2017 at 10:21:03 UTC, Paolo Invernizzi
wrote:
It doesn't seems to me that the trends to try to handle
somehow, that something, somewhere, who knows when, has gone
wild it's coherent with the term "robustness".
That all depends. It makes perfect sense in a "strongly pure"
function to just return an exception for basically anything
that went wrong in that function.
I use this strategy in other languages for writing
validator_functions, it is a very useful and time-saving way of
writing validators. E.g.:
try {
…
validated_field = validate_input(unvalidated_input);
}
I don't really care why validate_input failed, even if it was a
logic flaws in the "validate_input" code itself it is perfectly
fine to just respond to the exception, log the failure return a
failure status code and continue with the next request.
The idea that programs can do provably full veracity checking
of input isn't realistic in evolving code bases that need
constant updates.
Sorry Ola, I can't support that way of working.
Don't take it wrong, Walter is doing a lot on @safe, but
compilers are built from a codebase, and the codebase has,
anyway, bugs.
I can't approve a "ok, do whatever you want in the validate_input
and I try to *safely* throw"
IMHO you can only do that if the validator is totally segregated,
and to me that means in a separate process, neither in another
thread.
I'm trying to exactly do that, I like to think myself as a
very pragmatic person...
What do you mean by "pragmatic"? Shutting down a B2B website
because one insignificant request-handler fails on some
requests (e.g. requesting a help page) is not very pragmatic.
Pragmatic in this context would be to specify which handlers
are critical and which ones are not.
To me, pragmatic means that the B2B website has to be organised
in a way that the impact is minimum if one of the processes that
are handling the requests are restarted, for a bug or not. See
Laeeth [1]. Just handle "insignificant requests" to a cheeper,
less robust, less costly, web stack.
But we were talking about another argument...
/Paolo
[1]
http://forum.dlang.org/post/uvhlxtolghfydydox...@forum.dlang.org
Re: Bad array indexing is considered deadly
On Saturday, 3 June 2017 at 09:48:05 UTC, Timon Gehr wrote: On 03.06.2017 08:55, Paolo Invernizzi wrote: On Friday, 2 June 2017 at 23:23:45 UTC, nohbdy wrote: It's exacerbated because Walter is in a mindset of writing mission-critical applications where any detectable bug means you need to restart the program. Honestly, if I were writing flight control systems for Airbus, I could modify druntime to raise SIGABRT or call exit(3) when you try to throw an Error. It would be easy, and it would be worthwhile. If you really need cleanup, atexit(3) is available. The worst thing happened in programming in the last 30 years is just that less and less programmers are adopting Walter mindset... I'm really really puzzled by why this topic pops up so often... /Paolo I don't get why you would /restart/ mission-critical software that has been shown to be buggy. What you need to do instead: Have a few more development teams that create independent implementations of your service. (Completely from scratch, as the available libraries were not developed to the necessary standard.) All of them should run on different hardware produced in different factories by different companies. Furthermore, you need to hire a team of testers and software verification experts vastly exceeding the team of developers in magnitude, etc. That's what should be done in mission-critical software, and we are relaxing the constraint of mission critical, it seems [1] The point is software, somehow, has to be run, with bugs, or sometimes logic flaws: alas bugged software is running here [2]... So, if you have to, you should restart 'not-so-critical-software', and you should code it as it should be restarted from time to time. It's an opinion, when it's the better moment to just restart it, and a judgement between risks and opportunities. My personal opinion, it should be stopped ASAP a bug is detected. /Paolo [1] http://exploration.esa.int/mars/59176-exomars-2016-schiaparelli-anomaly-inquiry [2] https://motherboard.vice.com/en_us/article/the-f-35s-software-is-so-buggy-it-might-ground-the-whole-fleet
Re: Bad array indexing is considered deadly
On Saturday, 3 June 2017 at 07:51:55 UTC, Ola Fosheim Grøstad wrote: On Saturday, 3 June 2017 at 06:55:35 UTC, Paolo Invernizzi wrote: The worst thing happened in programming in the last 30 years is just that less and less programmers are adopting Walter mindset... Really? On the contrary. What is being adopted is robustness and program verification. More and more. It doesn't seems to me that the trends to try to handle somehow, that something, somewhere, who knows when, has gone wild it's coherent with the term "robustness". And the fact that the "nice tries" are done at runtime, in production, is the opposite of what I'm thinking is program verification. Assuming that a program shouldn't be able to flush its buffers out of some flawed reasoning about program correctness does not support your argument at all. Even if your program is fully based on event-sourcing and can deal with an immediate shutdown YOU STILL WANT TO FLUSH YOUR EVENT-BUFFERS TO DISK! There's a fundamental difference between trying to flush logs and trying to report what's happened, with the scope of gaining more information of what happened, and trying to "automagically" handle the fact that there's an error in the implementation, or in the logic, or in the HW. The argument Walter is follwing is flawed. If a failed assert means you should not be able to flush to disk, then it also means that you should undo everything the program has ever written to disk. The incorrect program state could have occured at install. The argument Walter is following is not flawed: it's a really beautiful pragmatic balance of risks and engineering way of developing software, IMHO. You have to reason about these things in probabilistic terms and not in absolutes. I'm trying to exactly do that, I like to think myself as a very pragmatic person... /Paolo
Re: Bad array indexing is considered deadly
On Friday, 2 June 2017 at 23:23:45 UTC, nohbdy wrote: It's exacerbated because Walter is in a mindset of writing mission-critical applications where any detectable bug means you need to restart the program. Honestly, if I were writing flight control systems for Airbus, I could modify druntime to raise SIGABRT or call exit(3) when you try to throw an Error. It would be easy, and it would be worthwhile. If you really need cleanup, atexit(3) is available. The worst thing happened in programming in the last 30 years is just that less and less programmers are adopting Walter mindset... I'm really really puzzled by why this topic pops up so often... /Paolo
Re: Bad array indexing is considered deadly
On Thursday, 1 June 2017 at 19:20:01 UTC, Timon Gehr wrote: On 01.06.2017 10:47, Paolo Invernizzi wrote: On Thursday, 1 June 2017 at 06:11:43 UTC, H. S. Teoh wrote: On Thu, Jun 01, 2017 at 03:24:02AM +, John Carter via Digitalmars-d wrote: [...] [...] [...] Again, from an engineering standpoint, this is a tradeoff. [...] That's exactly the point: to use the right tool for the requirement of the job to be done. /P There is no such tool. Process isolation was exactly crafted for that. /Paolo
Re: Bad array indexing is considered deadly
On Thursday, 1 June 2017 at 18:54:51 UTC, Timon Gehr wrote: On 01.06.2017 14:25, Paolo Invernizzi wrote: I can detail exactly what happened in my code -- I am accepting dates from a given week from a web request. One of the dates fell outside the week, and so tried to access a 7 element array with index 9. Nothing corrupted memory, but the runtime corrupted my entire process, forcing a shutdown. And that's a good thing! The input should be validated, especially because we are talking about a web request. See it like being kind with the other side of the connection, informing it with a clear "rejected as the date is invalid". :-) You seem to not understand what happened. There was a single server serving multiple different web pages. There was an out-of-bounds error due to a single user inserting invalid data into a single form with missing data validation. The web server went down, killing all pages for all users. There is no question that input data should be validated, but if it isn't, the response should be proportional. It's enough to kill the request, log the exception , notify the developer, and maybe even disable the specific web page. I really understand what is happening: I've a vibe.d server that's serving a US top 5 FMCG world company, and sometime it goes down for a crash. It's dockerized, in a docker swarm, and every times it crashes (or it's "unhealty") it's restarted, and we've a log, that it's helping us to squeeze bugs. Guess it, it's not a problem for the customer (at least right now!) as long as we have taken a clear approach: we are squeezing bug, and if process state is signalling us that a bug has occurred, we simply pull the plug. A proportional response can be archived having multiple processes handling the requests.. it's the only sane way I can think to not kill "all" the sessions, but only a portion. /Paolo
Re: Bad array indexing is considered deadly
On Thursday, 1 June 2017 at 10:26:24 UTC, Steven Schveighoffer wrote: On 5/31/17 9:05 PM, Walter Bright wrote: On 5/31/2017 6:04 AM, Steven Schveighoffer wrote: Technically this is a programming error, and a bug. But memory hasn't actually been corrupted. Since you don't know where the bad index came from, such a conclusion cannot be drawn. You could say that about any error. You could say that about malformed unicode strings, malformed JSON data, file not found. In this mindset, everything should be an Error, and nothing should be recoverable. Everything coming as an input of the _process_ should be validated... once validated, if still find during the execution malformed JSON data, malformed unicode strings, etc, there's a bug, and the process should terminate. This seems like a large penalty for "almost" corrupting memory. No other web framework I've used crashes the entire web server for such a simple programming error. Hence the endless vectors for malware insertion in those other frameworks. No, those are due to the implementation of the interpreter. If the interpreter is implemented in @safe D, then you don't have those problems. It seems to me that reducing the danger only to corrupted memory is underestimating the damage that can be done, for example by a simple SQL injection, that can be done without corrupting memory at all. Compare this to, let's say, a malformed unicode string (exception), malformed JSON data (exception), file not found (exception), etc. That's because those are input and environmental errors, not programming bugs. Not necessarily. A file name could be sourced from the program, but have a typo. An index could come from the environment. The library can't know, but makes assumptions one way or the other. Just like we assume you want to use the GC, these assumptions are harmful for those who need it to be the other way. The library should not assume nothing about anything coming from the environment, the filesystem, etc: there's must be a validation at the boundaries. I can detail exactly what happened in my code -- I am accepting dates from a given week from a web request. One of the dates fell outside the week, and so tried to access a 7 element array with index 9. Nothing corrupted memory, but the runtime corrupted my entire process, forcing a shutdown. And that's a good thing! The input should be validated, especially because we are talking about a web request. See it like being kind with the other side of the connection, informing it with a clear "rejected as the date is invalid". :-) /Paolo
Re: Bad array indexing is considered deadly
On Thursday, 1 June 2017 at 06:11:43 UTC, H. S. Teoh wrote: On Thu, Jun 01, 2017 at 03:24:02AM +, John Carter via Digitalmars-d wrote: [...] [...] [...] Again, from an engineering standpoint, this is a tradeoff. [...] That's exactly the point: to use the right tool for the requirement of the job to be done. /P
Re: Weak Eco System?
On Wednesday, 17 May 2017 at 16:32:45 UTC, juanjux wrote: On Wednesday, 17 May 2017 at 11:08:00 UTC, ezneh wrote: [...] I use D with the Vim plugin, Dutyl. The installation of dependences is somewhat manual but once it installed it works perfectly well. Compared with the Go plugin the only thing that I miss is auto downloading of dependences; maybe I'll try to make a PR tonight. The original poster attitude to the exclamation sounds incredibly disproportionate. Replies were friendly until that point. As another newcomer newcomer, sounds like another Rust user extending the Crusade, but maybe is just me. I suggest you to tryout also 'ale' [1], it works amazingly well! [1] https://github.com/w0rp/ale /Paolo
Re: Walter and Andrei and community relationship management
On Thursday, 13 April 2017 at 11:31:12 UTC, Guillaume Piolat wrote: And the most impressive to me is actually the way Walter answers to D users. If you are reading this forum since years you know what I mean. I try to emulate some of this with customers. That's really true: I sincerely think that he has a real talent in that. Just keep going on that way, Walter: humble and pragmatic! (BTW, if someone has access to this: https://hbr.org/2017/04/if-humble-people-make-the-best-leaders-why-do-we-fall-for-charismatic-narcissists) :-P --- Paolo
Re: Can vibed be fast as Go or Python?
On Wednesday, 29 March 2017 at 02:36:37 UTC, Laeeth Isharc wrote: Education isn't a bad idea, but I think hearing from people who are using it to do things is most powerful in persuading people at this stage. So the talks from Ethan of Remedy and Liran of Weka were very important That's exactly the best strategy: I strongly agree. Maybe D users in the enterprise should organise themselves a little because perhaps there are some such obstacles and frictions that are well worth solving and it's simply a coordination problem to figure out how. Reality isn't potentially Pareto optimal and life always falls short of the production possibility frontier. That's probably best done at this stage by people talking to each other directly and collaborating on things rather than starting with something formal. Do you have some practical suggestion on that? --- Paolo
Re: More exception classes into Phobos?
On Thursday, 23 March 2017 at 11:56:45 UTC, rikki cattermole wrote: On 24/03/2017 12:29 AM, Ola Fosheim Grøstad wrote: On Thursday, 23 March 2017 at 11:15:45 UTC, Георгий wrote: On Thursday, 23 March 2017 at 11:09:33 UTC, Jonathan M Davis wrote: [...] I don't agree. On the web, in production, even if this is a bug, the page may down, the request may down, but not entire application. And more importantly, the server should return a HTTP status indicating that there was a problem and that the request should not be repeated. Just silently dying does not work as well in a bigger setting where you want other services to adapt. And even better, have it damn well logged! O God, not again, please!
Re: memcpy() comparison: C, Rust, and D
On Wednesday, 1 February 2017 at 23:49:29 UTC, H. S. Teoh wrote: On Wed, Feb 01, 2017 at 11:49:25PM +, Mike via We would love to change the defaults, but unfortunately that boat has already sailed a long time ago. If we could do it all over again, I'm sure a lot of defaults would be the opposite of what they are today. But we can't reasonably change that now without massive breakage of current code. T My opinion is that the current situation is not that bad: it's some sort of bottom-up approach. Almost always, in a company, programmers are under time pressure and rushing, so I bet that almost always they will add a @system: on the top of the module. Maybe not true, but It come in my mind the Java "throw Exception" parade in function declaration /Paolo
Re: The extent of trust in errors and error handling
On Wednesday, 1 February 2017 at 21:55:40 UTC, Dukc wrote: On Wednesday, 1 February 2017 at 19:25:07 UTC, Ali Çehreli Regarding that, I have trought that wouldn't it be better if it was bounds checking instead of debug vs release what determined if in contracts are called? If the contract had asserts, they would still be compiled out in release mode like all asserts are. But if it had enforce():s, their existence would obey the same logic as array bounds checks. This would let users to implement custom bounds checked types. Fibers for example could be made @trusted, with no loss in performance for @system code in release mode. The right move is to ship a compiled debug version of the library, if closed source, along with the release one. I still don't understand why that's not the default also for Phobos and runtime /Paolo
