Re: DConf 2019: Shepherd's Pie Edition
On Thursday, 27 December 2018 at 08:25:23 UTC, Russel Winder wrote: On Thu, 2018-12-27 at 02:13 +, Joakim via Digitalmars-d-announce wrote: […] Wow, you've really gone off the deep end now. First you lie that I presented no data, then when called out, start claiming defamation and talk about bringing lawyers into it. You seem to be a beginner at gaslighting. Your initial data was simply two articles expressing an opinion. There was no data about conferences generally just a perception of a failure of conferences in the iOS arena. Good luck with that. :) I will have good luck. The lawyer is a person I have done expert witness work for on libel and email usage in the past in the High Court. I am not a beginner at this sort of thing. You will treat this email as a formal cease and desist letter requiring you stop defaming my character in public written statements. If you continue to defame me in public emails, I will escalate and apply for a cease and desist order in the High Court. Heh, nobody cares about you and your blatant L I E S.
Re: DConf 2019: Shepherd's Pie Edition
On Wednesday, 26 December 2018 at 09:34:48 UTC, Russel Winder wrote: On Wed, 2018-12-26 at 05:07 +, Joakim via Digitalmars-d-announce wrote: […] I wrote. I have never called anyone any name or insult in anything I wrote. I have used a pejorative for a type of argument that was being used, or characterized certain actions negatively. […] I beg to differ. I have the emails with you hurling personal abuse. Your continuous, data free, but combative on others providing no data, hectoring is beginning to annoy people who are trying to be constructive within the D community. You have made your point, that you believe, and no one else here now gives a shit about. I don't know who's going around deleting forum posts, which I'm against normally though in this case concede that our OT squabbling added nothing to this thread, but you missed this post, where he first started lying about what I wrote.
Re: DConf 2019: Shepherd's Pie Edition
On Wednesday, 26 December 2018 at 16:56:17 UTC, Russel Winder wrote: On Wed, 2018-12-26 at 09:45 +, Joakim via Digitalmars-d-announce wrote: […] Wtf are you talking about? I've never emailed you in my life. If you mean in this forum thread, quote what you think is "personal abuse," I see none. We can get to that later, no need for now given your statement below. I see, so you have nothing, as always. […] I have not made my point, since most responding seem to think I'm trying to lessen in-person interaction, like even Walter above with his concert example, when that's the opposite of what I'm saying! I chalk that up to people like you, who lie about my not presenting any data when that's clearly linked in my first post, either because you don't know how to read or choose to lie anyway. So we do not need any history of this thread to see that you have no compunction libelling people. Yes there is free speech, but there is also defamation via the written word which is a civil offence in UK law. This paragraph is almost certainly libellous. I am tempted to take legal advice from a UK libel solicitor of my acquaintance. Wow, you've really gone off the deep end now. First you lie that I presented no data, then when called out, start claiming defamation and talk about bringing lawyers into it. Good luck with that. :) For someome who claims not to give a shit, you certainly keep replying a lot to me and lying about what I wrote. You claimed you were going to stop engaging with me, email on this list 2018- 12-23T0808+00:00, but it seems you are failing to keep your promises. I have stopped engaging with you on the thread topic, DConf, since then, but once you started lying about the tone and content of my posts, I've addressed that.
Re: DConf 2019: Shepherd's Pie Edition
On Wednesday, 26 December 2018 at 09:34:48 UTC, Russel Winder wrote: On Wed, 2018-12-26 at 05:07 +, Joakim via Digitalmars-d-announce wrote: […] I wrote. I have never called anyone any name or insult in anything I wrote. I have used a pejorative for a type of argument that was being used, or characterized certain actions negatively. […] I beg to differ. I have the emails with you hurling personal abuse. Wtf are you talking about? I've never emailed you in my life. If you mean in this forum thread, quote what you think is "personal abuse," I see none. Your continuous, data free, but combative on others providing no data, hectoring is beginning to annoy people who are trying to be constructive within the D community. You have made your point, that you believe, and no one else here now gives a shit about. I have not made my point, since most responding seem to think I'm trying to lessen in-person interaction, like even Walter above with his concert example, when that's the opposite of what I'm saying! I chalk that up to people like you, who lie about my not presenting any data when that's clearly linked in my first post, either because you don't know how to read or choose to lie anyway. For someome who claims not to give a shit, you certainly keep replying a lot to me and lying about what I wrote.
Re: DConf 2019: Shepherd's Pie Edition
On Tuesday, 25 December 2018 at 23:09:40 UTC, Walter Bright wrote: On 12/25/2018 10:54 AM, Joakim wrote: [...] It's fine that you disagree with others, and it's ok when you insult me, but when you insult others it's time to stop. It's not clear what you're referring to, since you quote nothing I wrote. I have never called anyone any name or insult in anything I wrote. I have used a pejorative for a type of argument that was being used, or characterized certain actions negatively. I stand by those negative descriptions, and if you consider it an "insult" that I said "you just had to be there" is a stupid argument, I don't know what to tell you. Almost anyone who thinks about such matters believes that. I could sit here and say it was "insulting" how people repeatedly characterized me as wanting to stop all in-person interaction, when that is _the exact opposite_ of what I wrote! But I don't go around making up grievances like that, I suggest you don't either.
Re: DConf 2019: Shepherd's Pie Edition
On Tuesday, 25 December 2018 at 11:27:29 UTC, Nicholas Wilson wrote: On Tuesday, 25 December 2018 at 05:01:43 UTC, Joakim wrote: On Monday, 24 December 2018 at 22:22:08 UTC, Steven Schveighoffer wrote: The 0.1% of the community that attend seem to like it, the vast majority don't, or at least don't care. You think we have 200k users? More to the point you neglect the benefit of development and progress is shared by all users. I, for one, will not be donating to the foundation as long as they continue to waste money this way, just as others have said they won't donate as long as it doesn't put out a Vision document anymore or otherwise communicate what it's doing with their money. I agree this does need to happen, the foundation will be having a another meeting in Feb to set the vision, which I hope will be a little more planned and productive than the last one. Nobody is asking for your money for this conference (unless you want to attend), and if you feel this way, that's totally your choice. I'm not talking about the registration fee, I'm talking about contributing anything to the foundation, which Walter indicates above covers some of the expenses for DConf. Some additional transparency would help, Mike? I like the results that come from the conferences, I've been to all of them since 2013, on my dime for 3, and with assistance for 3. I felt it was 100% worth it for all. Yet you cannot give a single reason _why_ you felt it was worth it, or why my suggestions wouldn't make it better. I'll give my reasons: I got a job out of it. I got useful insight into various bits of the compiler. I got connections for collaboration with stuff that I'm interested. If you're making a bad decision, it _should_ be questioned. Indeed, but none of us think DConf is a bad idea or that the format doesn't work for us. Almost nothing that has been decided so far would stop most of my three suggestions from still being implemented. You haven't managed to convince us that that would be an improvement. As for how they feel about it, I don't care. The reason most projects and companies fail is because the decision-making process stops being about putting out a good product but about "feelings" and various people "saving face," especially when higher up the hierarchy, ie politics. And don't make up some nonsense that I'm saying that it's okay if everybody starts cursing each other out like Linus did: we're talking about _questioning a decision_. That is the whole point of having a community. The day this community starts being more about saving face is the day I leave it, as that's the beginning of the end, and I don't want to be around for that end. I totally agree, but again, you haven't convinced us that it is an improvement. Not at all, the whole reason I'm willing to debate is that other worthwhile perspectives may be out there. I think the evidence and arguments strongly favor the suggestions I'm putting forward, but I'm perfectly willing to consider other arguments. That is the same stance they should have, but don't appear to. My problem with this "debate" is that nobody was able to defend the current DConf format at all. That reasoning is backwards: in our experience DConf, as done in the past, works, and it works well. The onus is on you to convince us that it would work better the way you describe. Simply repeating over and over again that you're not "convinced" is not an argument, nor do your own personal reasons above argue for one format over another. I asked for a rationale above and got none from Mike and a very weak, confused one from Walter. It's fairly obvious that there was never any real deliberation on the DConf format, and that you guys have dug in and decided to cut off your nose to spite your face. Fine with me, your loss. Consider some of Walter's silly arguments above: at one point he says he wants "successful instantiations of your theories," implying that these are all things I'm just talking about and nobody's doing them, though it's not clear which aspects he thinks that of since I've presented evidence for much of it. But at another point, he says that other D meetups are already doing something I suggest (I pointed out that he's wrong about that one, but let's assume he believes it), so there's no reason for DConf to do it. First of all, 95+% of D meetups appear to follow the DConf format of having a single speaker lecture to a room, so why isn't that an argument against doing that yet again at DConf? What works at one scale doesn't necessarily work at another. I see, so you're arguing that DConf shouldn't be doing in-person talks because it's larger than most D meetups? Don't answer that, scale as a reason makes no sense and there's no way you can make it. To do something very different from a "traditional" conference would be a significant risk when what we have works well. I see no
Re: DConf 2019: Shepherd's Pie Edition
On Tuesday, 25 December 2018 at 07:10:46 UTC, rikki cattermole wrote: On 25/12/2018 6:01 PM, Joakim wrote: See my responses to Nicholas above, I don't think the Android port merits a talk. By the same standards I apply to others' talks above, I don't think my work merits a talk either. ;) A talk covering ARM and Android development in general would be very well received in the context of D. If you want to be convinced we could do a poll on who would want to see it (but I expect quite a large number of people would be in support of). I don't see how it could be worthwhile: nobody has ever given such a DConf talk about a port to a specific platform because it doesn't really make sense. The whole point of a port is to abstract away the platform, so you can simply recompile most of your D source for it, as H. S. Teoh has indicated he's been able to do with the Android app he's been developing in D recently. The way to do that talk is to abstract multiple ports into a general porting guide, which is the talk Kai already gave, or maybe talk about the details of a port to a very obscure or different platform, as Igor did this year: https://dconf.org/2018/talks/cesi.html While it was fascinating to hear how much work he put into it, much more than me, my interest was squelched somewhat because he couldn't reveal the platform and it's likely I would never use it anyway (not a game programmer). I mean, who really develops for non-Windows, non-Posix OS platforms? I haven't since college. For those few who do, maybe the talk was great. But the Android port wasn't that obscure: it's basically a linux/ARM distro with a different libc, Bionic. If you really mean "ARM and Android development in general" and not the details of the port, I can't claim much knowledge of that, as I don't have a large Android codebase that I've developed and deployed. Hopefully, even if I did, there would be nothing to say: as it should be pretty similar to writing D code for a desktop platform. My phone- on whose 5.5" screen I'm viewing the text of this forum response as I type it out on a separate, full-sized bluetooth keyboard paired with it- has 6 GBs of RAM and 128 GBs of storage (of which I have 8 GB free right now). That's about what midrange desktops and laptops come with these days (though with much larger screens ;) ), so you can't say mobile presents much of a constraint in terms of hardware. I've pointed out before that I compile code on my phone about as fast as a Macbook Air from a couple years ago: https://forum.dlang.org/thread/sqbtgmbtrorgthspl...@forum.dlang.org If you see some other angle on an Android talk that I'm missing, I'd be happy to hear it, but I don't see it. Maybe someday when I have a huge, successful Android app in D, I'll write about or put up a talk online about the architecture I used, but hopefully there won't be much specific to Android there. :)
Re: DConf 2019: Shepherd's Pie Edition
On Monday, 24 December 2018 at 22:22:08 UTC, Steven Schveighoffer wrote: On 12/24/18 2:44 AM, Joakim wrote: On Sunday, 23 December 2018 at 22:36:05 UTC, Steven Schveighoffer wrote: Huh? It's their decision, not yours. Even if the decision has no reason at all, it's still theirs. What is the problem? Start your own D "conference competitor" if you think you can do better. They are accountable to the community, so the decision and its reasons matter. My impression is that the community likes and benefits from these conferences, so everything's cool there. The 0.1% of the community that attend seem to like it, the vast majority don't, or at least don't care. I, for one, will not be donating to the foundation as long as they continue to waste money this way, just as others have said they won't donate as long as it doesn't put out a Vision document anymore or otherwise communicate what it's doing with their money. Nobody is asking for your money for this conference (unless you want to attend), and if you feel this way, that's totally your choice. I'm not talking about the registration fee, I'm talking about contributing anything to the foundation, which Walter indicates above covers some of the expenses for DConf. I like the results that come from the conferences, I've been to all of them since 2013, on my dime for 3, and with assistance for 3. I felt it was 100% worth it for all. Yet you cannot give a single reason _why_ you felt it was worth it, or why my suggestions wouldn't make it better. Nobody cares to debate something that has already been scheduled and planned, the time to bring up concerns was earlier, when you brought it up before. But that failed to convince, now it's decided, time to move on. So you agree with me that there's no point in "debating" it again, perhaps you should have addressed this comment to Mike then? Mike didn't start the debate in this thread, you did. I did no such thing: I asked for the reasons _why_ the decision was made, considering the previous debate. That is not restarting the debate, simply asking for the rationale. Others then tried to debate me again, and while I did respect them enough to engage with their arguments, I repeatedly pointed out that I wasn't looking to debate it again. Consider how one feels when careful deliberation is made, and a final decision, combined with an announcement is made. Would you like to have people question your decisions AFTER they are made, and commitments have already been established? The time to question them is before they are made, not after. Questioning after is simply viewed (rightly) as sour grapes. You didn't get your way, move on. If you're making a bad decision, it _should_ be questioned. Almost nothing that has been decided so far would stop most of my three suggestions from still being implemented. As for how they feel about it, I don't care. The reason most projects and companies fail is because the decision-making process stops being about putting out a good product but about "feelings" and various people "saving face," especially when higher up the hierarchy, ie politics. And don't make up some nonsense that I'm saying that it's okay if everybody starts cursing each other out like Linus did: we're talking about _questioning a decision_. That is the whole point of having a community. The day this community starts being more about saving face is the day I leave it, as that's the beginning of the end, and I don't want to be around for that end. If it's such a great idea, that should be an easy case to make, compared to the alternatives given. Yet all I get is a bunch of stone-walling, suggesting no reasoning was actually involved, just blindly aping others and the past. It is easy, for those who have attended conferences and like them -- they work well. All past dconfs are shining examples. Just drop it and move on to something else. You lost the battle for this one, it's no longer up for discussion. Heh, there was no "battle," as most of those responding didn't even understand what I wrote, like Iain above, gave no arguments (we "like them -- they work well"), and as finally clear from Mike and Walter's responses here, there was no real deliberation on the matter. You think they just flipped a coin one day, and didn't think about any past experience at all? No real thinking must have gone into it because only intelligent people can come to the conclusion you reached, right? This kind of "debate" where the assumption is that only my way is correct is common out there these days, it's tiring. Not at all, the whole reason I'm willing to debate is that other worthwhile perspectives may be out there. I think the evidence and arguments strongly favor the suggestions I'm putting forward, but I'm perfectly willing to consider other arguments. That is the same stance they should have, but don't appear to. My problem
Re: DConf 2019: Shepherd's Pie Edition
about me. I'm pointing out trends for _most_ devs, DConf has been growing in size every year it has been held, as have IWOCL and the LLVM conferences. Has it? I don't see any official numbers, but this year's DConf eye-balled smaller to me on the videos. I'm sure some topics for some conferences are declining, it may well even be an industry wide trend, but I'd bet good money that the new equilibrium will have conferences as a staple. Perhaps, but not with the outdated format D currently follows. my own preferences are irrelevant. I certainly hope not. Of course it is. Just as Walter shouldn't be making decisions based on what he "enjoys," I shouldn't either. Significant attention should be paid to what the majority of the audience wants, which is why it is important to pay attention to data like that which I presented, that shows conference attendance and events significantly declining. But consider that the foundation reimburses speakers and I personally would be very interested to hear what you have been doing with Andoird/ARM and I'm sure many others would as well, the question becomes: is it worth your time? I don't understand what's so special about "speakers" that it couldn't simply reimburse non-speakers that the foundation wants at one of the decentralized locations instead. It seems like the talk is a made-up excuse to pay for some members of the core team to come, when the real reason is to collaborate with them. Why not dispense with that subterfuge? The talks together with the topic of the conference are what draw people to the conference and make it economically viable. It is a perfectly rational decision. If I was running a conference trying to turn a profit I'd probably get more applications for the available speaker slots => better quality speakers => more attendees => $$$. This is a giant assumption, that those blog posts explicitly call out as not holding anymore, now that most of those speakers already get their message out easily online. DCompute would not exist were it not for that reimbursement, as a poor student that made the difference between this is something I can work towards, afford to go to and get good value out of vs not. Perhaps we could run general travel grants like LLVM does but I don't think we're large enough for that, Mike Parker would be the person to talk to about that. But if, like me, they are students and wan't to have something to talk about to aid in networking, then giving a talk will help with that. Then have them do a pre-recorded talk like every other speaker, pick some strong contributors to attend every year as you're already doing, but don't have them talk, and spend all that valuable in-person time actually networking, doing BoF, getting things done. I see little value in a full talk about a port to a new platform like Android, that is basically another linux distro with a different libc. It's not a matter of my time, I don't think it's worth the audience's time. I wish those organizing DConf would focus on that more. You can choose the length of the talk you think would fit the topic. It _might_ make sense for a 5-15 min. lightning talk. You could cover the basics of using the port for developing Android apps Trivial and available on the wiki, no need. the difficulties you experienced doing the port A port is all about fixing a ton of one-off incompatibilities, that is the recipe for a bad talk. It could be used as a launching point for a much larger exploration of the platform itself- say Walter using his DWARF port as a launching point to talk about the DWARF format and such debug formats generally- but I don't know enough about Android to do that, nor would it really make sense at DConf. and the troubles others might have in doing their own, Kai gave an excellent, general version of this talk already, there's nothing substantive I could add to it other than a bit more technical detail of how it applied to my port: https://dconf.org/2016/talks/nacke.html I wish it had been available when I started my port three years earlier! ... as they say, the stage is yours. It would also present an opportunity to convince others of the direction you think we should be going in e.g. w.r.t mobile/ARM/AArch64. I thought about submitting that as a topic last year, but it's better done on the forum, as I've been doing. On Sunday, 23 December 2018 at 15:32:41 UTC, Iain Buclaw wrote: On Sun, 23 Dec 2018 at 16:05, Joakim via Digitalmars-d-announce wrote: I'm not sure how a talk is supposed to inspire anything substantive _before_ you've heard it, and pre-recorded talks watched at home would fill the same purpose after. No one is interested in watching pre-recorded talks. Let's look at the numbers. There were around 100 people at DConf this year? Youtube reports 875 views for Andrei's keynote after being recorded and put online
Re: DConf 2019: Shepherd's Pie Edition
On Sunday, 23 December 2018 at 10:07:40 UTC, Walter Bright wrote: On 12/22/2018 10:20 PM, Joakim wrote: Honestly, yours are routinely the worst presentations at DConf. Your strength as a presenter is when you dig deeply into a bunch of technical detail or present some new technical paradigm, similar to Andrei. Yet, your DConf keynotes usually go the exact opposite route and go very lightly over not very much at all. Eh, I went pretty far into the DIP 1000 material. That one had more technical examples, but I didn't think it was very well-motivated and could probably have had more detail. My feeling is that you save your best stuff for your NWCPP talks and present the baby versions at DConf. 1) Ditch in-person presentations for pre-recorded talks that people watch on their own time. Getting everybody in the same room in London to silently watch talks together is a horrible waste, that only made sense before we all had high-speed internet-connected TVs and smartphones with good cameras. Do a four-day hackathon instead, ie mostly collaboration, not passive viewing. It's very different listening to a presentation live rather than pre-recorded. There are the before and after interactions they inspire. I'm not sure how a talk is supposed to inspire anything substantive _before_ you've heard it, and pre-recorded talks watched at home would fill the same purpose after. Perhaps this is a generation gap, as I see that you and Russel are a couple decades older than me, so let me give my perspective. I've probably watched a week or two of recorded tech talks online over the last year, and maybe a couple hours in person. Invariably, I find myself wishing for a skip-ahead button on those in-person talks, like I have for the online videos. ;) I suspect there are many more like me these days than you two. 2) Rather than doing a central DConf that most cannot justify attending, do several locations, eg in the cities the core team already lives in, like Boston, Seattle, San Jose, Hong Kong, etc. This makes it cost-effective for many more people to attend, and since you'll have ditched the in-person tech talks, spend the time introducing the many more attendees to the language or have those who already know it work on the language/libraries, ie something like the current DConf hackathon. London is the most cost-effective destination for most D team members. For distributed meetings, there have been several D meetups that do what you suggest. While fun and valuable, they're not a replacement for DConf. I have never heard of a meetup doing what I suggest, ie an all-day D event with almost no in-person talks, possibly co-ordinated with other cities. I think this would be _much better_ for D than DConf. 3) Get the core team together as a separate event, either as an offline retreat or online video conference or both. I know you guys need to meet once in awhile, but it makes no sense to spend most of that in-person time at DConf staring at talks that could be viewed online later. If you ever came to one, you might see it differently. I'm not a member of the core team, so I'm not sure how that's relevant. If you just mean that I could observe how the core team is getting a lot of value out of in-person talks, I call BS. While I find it questionable to say that they couldn't easily find and recruit those people online, given that D is primarly an online project where most everything and everyone is easily available online, I see no reason why any of the changes above would stop that. There's a very clear connection between DConf and successful collaborations with industry and D developers. Why mess with success? For the chance of much more success? I'm sure there have been some fruitful collaborations and hiring at DConf. I'm saying there would likely be _even more_ with my suggestions. It seems clear to me that you, at the very least, have not engaged with the links and ideas I've been providing about why the current DConf format is broken. Your opinions would have more weight if (1) you've ever attended a DConf Perhaps but since I haven't been, you could presumably articulate what you find so great about DConf that contradicts my opinions, but you mention nothing here and your reasons elsewhere aren't too worthwhile. and (2) can point to successful instantiations of your theories. What do you consider a "theory" above: that you could have better outreach at several locations or that pre-recorded talks watched at home are a better use of valuable in-person time? I don't think that's theorizing, it's well-accepted by most everyone who knows these subjects. I started off by pointing to documented evidence of conferences going down, and popular bloggers and people who track this stuff talking about how online talks have replaced them, so it is well-known that this trend away from the old conference format is underway. I
Re: DConf 2019: Shepherd's Pie Edition
On Sunday, 23 December 2018 at 09:51:58 UTC, Nicholas Wilson wrote: On Sunday, 23 December 2018 at 08:08:59 UTC, Joakim wrote: On Sunday, 23 December 2018 at 06:54:26 UTC, Russel Winder wrote: Others have cited Rust and Go. I shall cite Python, Ruby, Groovy, Java, Kotlin, Clojure, Haskell, all of which have thriving programming language oriented conferences all over the world. Then there are the Linux conferences, GStreamer conferences, conference all about specific technologies rather than programming languages. And of course there is ACCU. There is much more evidence that the more or less traditional conference format serves a purpose for people, and are remaining very successful. Many of these conferences make good profits, so are commercially viable. That's all well and good, but none of this addresses the key points of whether there are less tech conferences being done and whether they make sense in this day and age. There are still people riding in horse and carriage, that doesn't mean it's still a good idea. :) You say that like some superior technology exists to replace the conference. It does, read the first link I gave in my first post above. Yes, DConf may benefit from tutorials, workshops, BoFs, whatever, but the value it brings to the community is very real. It may bring some value, but that's not the question: the question is whether we could get more value out of the alternatives, particularly at a cheaper cost? The fact that you and others keep avoiding this question suggests you know the answer. Thus I reject the fundamental premise of your position that the conference format is dying off. It isn't. The proof is there. Yes, the proof is there: the conference is dying. Hardly. IME there are two kinds of conferences (or maybe they form a spectrum, whatever) academic and industrial. Academic is going nowhere, research needs presenting, organisation of collaboration needs to happen. Research conferences are irrelevant. I don't pay attention to them and the fact that the Haskell link Atila gave above says their conferences are for presenting research is one big reason why almost nobody uses that PL in industry. Industrial, there is project coordination, employment prospectus, business opportunities, why do you think companies sponsor conferences? They get their moneys worth out of it. Clearly not in the iOS community, and according to a commenter in my second link above, the Javascript community in his country, as the number of tech conferences is going down a lot. It is my impression that this is true across the board for pretty much every tech community, but I presented that iOS link because he actually tallies the evidence. That is a canary in the coal mine for the conference format, that the largest burgeoning dev market on the planet has a dying conference scene. Perhaps you as an individual believe that they are not cost effective for you, fine. As I keep repeating, this is not about me. I'm pointing out trends for _most_ devs, my own preferences are irrelevant. But consider that the foundation reimburses speakers and I personally would be very interested to hear what you have been doing with Andoird/ARM and I'm sure many others would as well, the question becomes: is it worth your time? I don't understand what's so special about "speakers" that it couldn't simply reimburse non-speakers that the foundation wants at one of the decentralized locations instead. It seems like the talk is a made-up excuse to pay for some members of the core team to come, when the real reason is to collaborate with them. Why not dispense with that subterfuge? I see little value in a full talk about a port to a new platform like Android, that is basically another linux distro with a different libc. It's not a matter of my time, I don't think it's worth the audience's time. I wish those organizing DConf would focus on that more.
Re: DConf 2019: Shepherd's Pie Edition
On Sunday, 23 December 2018 at 09:36:19 UTC, Russel Winder wrote: On Sun, 2018-12-23 at 08:08 +, Joakim via Digitalmars-d-announce wrote: […] This questioning of iOS is so removed from reality that it makes me question if you are qualified to comment on this matter at all. iOS is the largest consumer software platform that is still growing, as it's estimated to bring in twice the revenue of google's Play store (that doesn't count other Android app stores, but they wouldn't make up the gap): Fair enough I have no interest in iOS at all. But you must agree that you are clearly so far removed from the reality of putting on technical conferences generally, that you are not qualified to make assertions such as "conferences are a dead form". You could make various arguments for why they're still having less and less conferences, as my second link above listing them does. But to argue that iOS is not doing well is so ludicrous that it suggests you don't know much about these tech markets. Ludicrous is a good description of the entire situation in this thread. You are making assertions as though they are facts, working on the principle that if you shout long enough and loud enough, people will stop disagreeing. A classic technique. […] Yes, the proof is there: the conference is dying. You simply don't want to admit it. This is just assertions with no data and thus is a religious position. And I know conferences are thriving, you just do not want to admit that. This seems to be a religious issue for you, with your bizzare assertions above, so I'll stop engaging with you now. No it is you that has faith in the death of conferences, I am involved in the reality of conferences being a relevant thing that people want to attend. Just because you do not want to go to conferences doesn't give you the right to try and stop others from doing so. If you are going to stop ranting on this, I think that will make a lot of people very happy. The idea of this email list is to announce things, not debate things. Also on the debating lists the idea is to have a collaborative not combative debate about things. That includes if some people want to do something they should be allowed to do it and not be harangued from the wings. If people want to have a DConf, it is not your position to tell them they cannot. Your statements above are so ridiculous that they refute themselves, no need for me to do so. :) As for your final ridiculous characterization that I'm "ranting/haranguing" people on this matter, I have only ever presented evidence and reasons for why the DConf format doesn't make sense. If that's "ranting" to you, it's clear you don't understand reasoned debate. In this thread, all I've asked is why all those reasons were ignored, as Mike never gave any arguments for why those reasons aren't worth heeding. Walter's response suggests he never read my suggestions or reasons in the first place. Nobody is telling "anyone they cannot," as though any of us have that power. Rather, I'm trying to figure out how this decision was made, in the face of all the reasons given and almost none given for maintaining the status quo.
Re: DConf 2019: Shepherd's Pie Edition
On Sunday, 23 December 2018 at 06:54:26 UTC, Russel Winder wrote: On Sat, 2018-12-22 at 13:46 +, Joakim via Digitalmars-d-announce wrote: […] Given that this conference format is dying off, is there any explanation for why the D team wants to continue this antiquated ritual? https://marco.org/2018/01/17/end-of-conference-era http://subfurther.com/blog/2018/01/15/the-final-conf-down/ https://forum.dlang.org/thread/ogrdeyojqzosvjnth...@forum.dlang.org […] So iOS conferences are a dying form. Maybe because iOS is a dying form? This questioning of iOS is so removed from reality that it makes me question if you are qualified to comment on this matter at all. iOS is the largest consumer software platform that is still growing, as it's estimated to bring in twice the revenue of google's Play store (that doesn't count other Android app stores, but they wouldn't make up the gap): https://techcrunch.com/2018/07/16/apples-app-store-revenue-nearly-double-that-of-google-play-in-first-half-of-2018/ You could make various arguments for why they're still having less and less conferences, as my second link above listing them does. But to argue that iOS is not doing well is so ludicrous that it suggests you don't know much about these tech markets. Your evidence of the failure of the iOS community to confer is not evidence of the failure of the conference in other communities. I never said they fail to confer, I said they're doing it much less, because the format is not relevant anymore. Others have cited Rust and Go. I shall cite Python, Ruby, Groovy, Java, Kotlin, Clojure, Haskell, all of which have thriving programming language oriented conferences all over the world. Then there are the Linux conferences, GStreamer conferences, conference all about specific technologies rather than programming languages. And of course there is ACCU. There is much more evidence that the more or less traditional conference format serves a purpose for people, and are remaining very successful. Many of these conferences make good profits, so are commercially viable. That's all well and good, but none of this addresses the key points of whether there are less tech conferences being done and whether they make sense in this day and age. There are still people riding in horse and carriage, that doesn't mean it's still a good idea. :) Thus I reject the fundamental premise of your position that the conference format is dying off. It isn't. The proof is there. Yes, the proof is there: the conference is dying. You simply don't want to admit it. This seems to be a religious issue for you, with your bizzare assertions above, so I'll stop engaging with you now.
Re: DConf 2019: Shepherd's Pie Edition
On Saturday, 22 December 2018 at 22:13:44 UTC, Walter Bright wrote: On 12/22/2018 6:26 AM, Atila Neves wrote: If you don't like conferences you don't have to go. I for one am excited about being in London in May. Please don't sour it for other who think/feel like I do. That's right. And hefting a pint with Atila is guaranteed to be a highlight of the conference! I recommend it for those who haven't had the pleasure. I'm sure he's fun to be around, the question is whether it's worth the cost of flying to London. That said, I think we've probably tried to cram too many presentations into the schedule. We should probably have fewer and put gaps between them for people to digest and talk about them. The question is if it's worth doing in-person presentations at all. Also, I try to make my presentations less "I lecture and you listen silently" to be much more interactive and engaging with you guys. I suggest others planning a presentation to also think along those lines. Honestly, yours are routinely the worst presentations at DConf. Your strength as a presenter is when you dig deeply into a bunch of technical detail or present some new technical paradigm, similar to Andrei. Yet, your DConf keynotes usually go the exact opposite route and go very lightly over not very much at all. Reading through your listed benefits of DConf below tells me you didn't read anything I wrote in the linked forum thread above from months ago, as nowhere did I say not to get people together in person at all, which is where most of your benefits come from. Rather, I made three primary suggestions for how to get people together instead: 1) Ditch in-person presentations for pre-recorded talks that people watch on their own time. Getting everybody in the same room in London to silently watch talks together is a horrible waste, that only made sense before we all had high-speed internet-connected TVs and smartphones with good cameras. Do a four-day hackathon instead, ie mostly collaboration, not passive viewing. 2) Rather than doing a central DConf that most cannot justify attending, do several locations, eg in the cities the core team already lives in, like Boston, Seattle, San Jose, Hong Kong, etc. This makes it cost-effective for many more people to attend, and since you'll have ditched the in-person tech talks, spend the time introducing the many more attendees to the language or have those who already know it work on the language/libraries, ie something like the current DConf hackathon. 3) Get the core team together as a separate event, either as an offline retreat or online video conference or both. I know you guys need to meet once in awhile, but it makes no sense to spend most of that in-person time at DConf staring at talks that could be viewed online later. Some other advantages of DConf off the top of my head, in no particular order: 1. putting a face and name to the person greatly helps working with people remotely the rest of the year Maybe, but only 2) above mitigates it somewhat, and is it worth the cost? 2. it's amazing how intractable, obstinate online positions just melt away when discussed in person over a beer 1) and 3) enable that more, 2) sacrifices that for greater outreach. 3. it's fun to see what other people are doing, as it's easy to miss what's important by just monitoring the n.g. 1) and 3) enable that more, 2) sacrifices it somewhat. 4. I regard all you folks as my friends, and it's fun to be with y'all Is that more important than outreach and getting things done? 5. many, many collaborations have spawned from meeting like minded individuals at DConf They still would with the suggestions above, just differently. 6. employers come to DConf looking for D developers, and many D developers have gotten jobs from them. If that isn't a win-win, I don't know what is! While I find it questionable to say that they couldn't easily find and recruit those people online, given that D is primarly an online project where most everything and everyone is easily available online, I see no reason why any of the changes above would stop that. It seems clear to me that you, at the very least, have not engaged with the links and ideas I've been providing about why the current DConf format is broken. My fundamental point is that the current DConf conference format is an outdated relic, that made sense decades ago when getting everybody together in a room in Berlin was a fantastic way to get everybody connected. With the ready availability of high-speed internet and video displays to everybody who can afford to pay the registration fee and go to London, that hoary conference format needs to be rethought for the internet age. I have no problem with anybody disagreeing with my suggestions or the reasoning behind them, but I find it flabbergasting for anyone to suggest, as Mike has above, that the old conference format
Re: DConf 2019: Shepherd's Pie Edition
On Saturday, 22 December 2018 at 17:36:08 UTC, Bastiaan Veelo wrote: On Saturday, 22 December 2018 at 16:57:10 UTC, Joakim wrote: On Saturday, 22 December 2018 at 16:35:27 UTC, Johannes Loher wrote: Also I don't think this is the right place for this discussion. If you feel that we indeed need to rediscuss this issue, I think it should be done in a separate thread. I'm not trying to discuss it with you or the community. I'm asking the D team [...] Then why post in the announce thread? If you don’t feel your previous thread got your message through, you know how to reach the foundation. Why wouldn't I post in here? There's currently a 84-post thread in this Announce forum discussing Atila's blog post about what D got wrong. Similarly, this is the thread where the topic is the next DConf. I almost never send private emails over community matters, which should be discussed publicly. I don’t understand how you can argue against technical conferences so much if you never attended one, much less DConf. I didn't say I never attended one, I probably sat through something back in my college days. I watch some conf videos now and then, but like most techies these days, don't find any value in going. I know the odds are slim, but I hope to meet you there someday. I'd like to meet you too, but I think if it happens, it won't ever be at an outdated format like the current DConf. :P
Re: DConf 2019: Shepherd's Pie Edition
On Saturday, 22 December 2018 at 17:13:06 UTC, Mike Parker wrote: On Saturday, 22 December 2018 at 16:57:10 UTC, Joakim wrote: I'm not trying to discuss it with you or the community. I'm asking the D team who're making this decision why it's being made, despite all the reasoning in that thread, and reiterating that it's a bad move. I suspect they're not thinking this through, but they can speak for themselves. The decision was made because your reasoning failed to convince anyone involved in the planning that maintaining the current format of DConf is a mistake. Nor do they agree with you that it's a bad move. We like the current format and see no need to change it at this time. I see, so you admit no reasoning was involved on your part? Because you present none, either there or here. If you would like to carry on another debate about this, please open another thread in thhe General forum. This one isn't the place for it. Thanks! As I just noted, I don't care to "debate" it with people who make no arguments. Instead, I'm asking you or whoever made this horrible decision why it's being made. If it's such a great idea, that should be an easy case to make, compared to the alternatives given. Yet all I get is a bunch of stone-walling, suggesting no reasoning was actually involved, just blindly aping others and the past.
Re: DConf 2019: Shepherd's Pie Edition
On Saturday, 22 December 2018 at 16:35:27 UTC, Johannes Loher wrote: On Saturday, 22 December 2018 at 15:11:10 UTC, Joakim wrote: On Saturday, 22 December 2018 at 14:26:29 UTC, Atila Neves wrote: On Saturday, 22 December 2018 at 13:46:39 UTC, Joakim wrote: On Saturday, 22 December 2018 at 12:18:25 UTC, Mike Parker wrote: The egregious waste of time and resources of this DConf format strongly signals that D is not a serious effort to build a used language, It's the same signal being emitted by all of these "failures" as well: Go: https://twitter.com/dgryski/status/1034939523736600576 Rust: https://rustconf.com/ Clojure: https://clojure.org/community/events Haskell: https://wiki.haskell.org/Conferences C++: https://cppcon.org/ https://cpponsea.uk/ http://cppnow.org/ https://meetingcpp.com/ etc. To me it's obvious from that short list that took me less than 5min to come up with that conferences aren't a dying format. I gave up on C++ conferences after the 4th link, there are just too many. The fact that a short list of conferences still exists at all somehow makes it "obvious" to you that they're not dying? Did you even look at my second link that actually tallies some numbers for a particular tech market? It is true that a few conferences are still being done, even my second link above never said they're _all_ gone. But simply saying some are still following this outdated ritual is not an argument for continuing it, nor does it contradict anything I said about the number of conferences going down. If you don't like conferences you don't have to go. This has nothing do me: I've never been to DConf or most any other tech conference and likely never will. This is about whether the D team should be wasting time with this dying format. I for one am excited about being in London in May. Please don't sour it for other who think/feel like I do. Heh, so that's your two big arguments for why the conference format should continue: other languages are doing it and you want to visit London in May? You are exemplifying the mindset that I'm pointing out with these flimsy arguments, everything that is wrong with D and DConf. We talked a great deal about this in your thread (https://forum.dlang.org/thread/ogrdeyojqzosvjnth...@forum.dlang.org). I believe the main takeaway from that discussion was that many of us disagree with your opinion to at least some degree. As I recall, you largely agreed with me: "I totally agree with you on your first point, i.e. making DConf more interactive." "I disagree with your second point, i.e. decentralising DConf... On the other hand, I have to admit that decentralising the event would open it up for a much bigger audience, which definitely is a good idea." https://forum.dlang.org/post/omsxuayxkaqbxeobe...@forum.dlang.org I know that you are very convinced about your idea of how we should do DConf being superior and that is OK. Maybe you are just ahead of time in this case, I don't know. But it is also a fact that many people stated that they actually enjoy the current DConf format very much and believe it is not a waste of time and money at all. So to me, it is no surprise at all that it was decided to to stick with the current format. I really don't care how many people agree or disagree. All I care about is the reasoning presented. As I see it, I gave lots of good reasons, and like Atila here, they gave none: only "I enjoyed myself." That's not a worthwhile reason, if the goal is to further the D language and community. Also I don't think this is the right place for this discussion. If you feel that we indeed need to rediscuss this issue, I think it should be done in a separate thread. I'm not trying to discuss it with you or the community. I'm asking the D team who're making this decision why it's being made, despite all the reasoning in that thread, and reiterating that it's a bad move. I suspect they're not thinking this through, but they can speak for themselves.
Re: DConf 2019: Shepherd's Pie Edition
On Saturday, 22 December 2018 at 14:26:29 UTC, Atila Neves wrote: On Saturday, 22 December 2018 at 13:46:39 UTC, Joakim wrote: On Saturday, 22 December 2018 at 12:18:25 UTC, Mike Parker wrote: The egregious waste of time and resources of this DConf format strongly signals that D is not a serious effort to build a used language, It's the same signal being emitted by all of these "failures" as well: Go: https://twitter.com/dgryski/status/1034939523736600576 Rust: https://rustconf.com/ Clojure: https://clojure.org/community/events Haskell: https://wiki.haskell.org/Conferences C++: https://cppcon.org/ https://cpponsea.uk/ http://cppnow.org/ https://meetingcpp.com/ etc. To me it's obvious from that short list that took me less than 5min to come up with that conferences aren't a dying format. I gave up on C++ conferences after the 4th link, there are just too many. The fact that a short list of conferences still exists at all somehow makes it "obvious" to you that they're not dying? Did you even look at my second link that actually tallies some numbers for a particular tech market? It is true that a few conferences are still being done, even my second link above never said they're _all_ gone. But simply saying some are still following this outdated ritual is not an argument for continuing it, nor does it contradict anything I said about the number of conferences going down. If you don't like conferences you don't have to go. This has nothing do me: I've never been to DConf or most any other tech conference and likely never will. This is about whether the D team should be wasting time with this dying format. I for one am excited about being in London in May. Please don't sour it for other who think/feel like I do. Heh, so that's your two big arguments for why the conference format should continue: other languages are doing it and you want to visit London in May? You are exemplifying the mindset that I'm pointing out with these flimsy arguments, everything that is wrong with D and DConf.
Re: DConf 2019: Shepherd's Pie Edition
On Saturday, 22 December 2018 at 12:18:25 UTC, Mike Parker wrote: Thanks to Symmetry Investments, DConf is heading to London! We're still ironing out the details, but I've been sitting on this for weeks and, now that we have a venue, I just can't keep quiet about it any longer. I've updated the DConf site and published a blog post, but I ask that you please don't share this to reddit just yet. I want to wait until after Christmas to share it there. We're still ironing out some details (deadlines, prices, hotels) and I'll update the DConf site in the coming days with info as I get it. Happy Holidays! http://dconf.org/2019/index.html https://dlang.org/blog/2018/12/22/dconf-2019-shepherds-pie-edition/ Given that this conference format is dying off, is there any explanation for why the D team wants to continue this antiquated ritual? https://marco.org/2018/01/17/end-of-conference-era http://subfurther.com/blog/2018/01/15/the-final-conf-down/ https://forum.dlang.org/thread/ogrdeyojqzosvjnth...@forum.dlang.org It costs $3k to hire a pull request manager, something D desperately needed, yet here you are having the average conference participant spend that mostly on flights and hotels to go to London, only to stare silently at presentations most of the time, while surrounded by a room full of people. What are the possible priorities that this can be considered a good idea? The egregious waste of time and resources of this DConf format strongly signals that D is not a serious effort to build a used language, but a hobby project by two tech retirees, W, who just want to prototype some different ideas, show it off to a bunch of fellow hobbyists, and then have some beers and go sight-seeing. If this is the core team's goal, please just stop stating otherwise and broadcast this on the front page of the website, as you're essentially doing by the way this blog post was written. Giant companies like google or Microsoft can afford these antiquated, giant wastes of time known as conferences and even they are cutting back. The fact that the D team is moving forward with this given how tech is moving is a horrible sign, suggesting it is completely out of touch and unable to prioritize well.
Re: LDC 1.13.0
On Sunday, 16 December 2018 at 15:57:25 UTC, kinke wrote: Glad to announce LDC 1.13: * Based on D 2.083.1. * The Windows packages are now fully self-sufficient, i.e., a Visual Studio/C++ Build Tools installation isn't required anymore. * Substantial debug info improvements. * New command-line option `-fvisibility=hidden` to hide functions/globals not marked as export, to reduce the size of shared libraries. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.13.0 New Wiki page highlighting cross-compilation: https://wiki.dlang.org/Cross-compiling_with_LDC Thanks to all contributors! Native Android packages for the Termux app have been updated, including an Android/x64 package for the first time (with the std.variant issue from the last beta now fixed). While no Android device uses x64, many x64 and AArch64 Chromebooks support installing Android apps like Termux, so if you have a Chromebook, you can now start writing and compiling D code on there too: :) https://medium.com/@clumsycontraria/learning-to-code-on-a-bone-stock-chromebook-a7d0e75303bb An Alpine build of ldc for Docker containers and microservices is also up now.
Re: Liran Zvibel of WekaIO on using D to Create the World’s Fastest File System
On Wednesday, 5 December 2018 at 19:59:46 UTC, Joakim wrote: On Wednesday, 5 December 2018 at 09:04:49 UTC, Walter Bright wrote: #4 on HackerNews front page! https://news.ycombinator.com/ 33 points at the moment! Now one of the top-voted links on the front page of HN. I'd just like to point out that Andrei put Liran and I together to do this interview in summer '17- though I had emailed Liran about doing one in '15 and never got a response- and he finally got some time to respond this summer. Now I just need Andrei to finally do an interview, which he's been putting off for even longer. :) Got to fifth highest-voted link all-time from dlang.org on HN: https://hn.algolia.com/?sort=byPopularity=false=0=all=story=false=dlang.org
Re: I've just released Vasaro
On Thursday, 6 December 2018 at 20:45:07 UTC, Andrea Fontana wrote: Hi! I've just released the first version of vasaro. It's a simple program I wrote to create 3d printable vases. It's written in D (of course). It uses derelict-gl, derelict-sdl and gtkd. It should work on linux, macOS and Windows. A special thanks to Adam Ruppe and his SimpleDisplay library I used on earlier versions :) A demo video: https://www.youtube.com/watch?v=HkYo8WCW9jM On reddit: https://www.reddit.com/r/3Dprinting/comments/a3qykj/ive_just_released_vasaro_the_easytouse_software/ On github: https://github.com/trikko/vasaro/ Feel free to test it! Andrea Nice, when does the version with genetic algorithms come out? ;) https://www.economist.com/technology-quarterly/2015/09/03/wonderful-widgets JK, of course, demo looks good.
Re: Liran Zvibel of WekaIO on using D to Create the World’s Fastest File System
On Wednesday, 5 December 2018 at 09:04:49 UTC, Walter Bright wrote: #4 on HackerNews front page! https://news.ycombinator.com/ 33 points at the moment! Now one of the top-voted links on the front page of HN. I'd just like to point out that Andrei put Liran and I together to do this interview in summer '17- though I had emailed Liran about doing one in '15 and never got a response- and he finally got some time to respond this summer. Now I just need Andrei to finally do an interview, which he's been putting off for even longer. :)
D is in GCC 9 proggit thread
For those who missed it: https://www.reddit.com/r/programming/comments/a30hg9/gcc_9_adds_frontend_support_for_the_d_programming/
Re: Interview with Liran Zvibel of WekaIO
On Wednesday, 5 December 2018 at 13:30:21 UTC, Joakim wrote: On Wednesday, 5 December 2018 at 08:02:21 UTC, M.M. wrote: On Tuesday, 4 December 2018 at 14:21:02 UTC, Mike Parker wrote: [...] Interesting read. I am new to dlang, and after reading the post, I asked myself: the company liked the language, but tweaked the compiler. Could the company now switch to one of the official compilers? If not, why? All three compilers listed on the official download page use the same frontend, written in D: https://dlang.org/download The LDC and GDC teams take that DMD frontend and attach it to the LLVM and GCC code-generation backends. As for Weka's tweaks, github shows these different commits from their last 1.11 release to the official tag: https://github.com/ldc-developers/ldc/compare/v1.11.0...weka-io:weka-2.071 Sorry, I compared the wrong Weka branch. Here's the right tag, shows fewer commits different: https://github.com/ldc-developers/ldc/compare/v1.11.0...weka-io:weka-v1.11
Re: Interview with Liran Zvibel of WekaIO
On Wednesday, 5 December 2018 at 08:02:21 UTC, M.M. wrote: On Tuesday, 4 December 2018 at 14:21:02 UTC, Mike Parker wrote: Joakim interviewed Liran for the D Blog about their file system, Matrix, and their use of D. Thanks to Joakim for putting it together, and to Liran for taking the time to participate! Blog: https://dlang.org/blog/2018/12/04/interview-liran-zvibel-of-wekaio/ Reddit: https://www.reddit.com/r/programming/comments/a3106x/interview_liran_zvibel_of_wekaio/ Interesting read. I am new to dlang, and after reading the post, I asked myself: the company liked the language, but tweaked the compiler. Could the company now switch to one of the official compilers? If not, why? All three compilers listed on the official download page use the same frontend, written in D: https://dlang.org/download The LDC and GDC teams take that DMD frontend and attach it to the LLVM and GCC code-generation backends. As for Weka's tweaks, github shows these different commits from their last 1.11 release to the official tag: https://github.com/ldc-developers/ldc/compare/v1.11.0...weka-io:weka-2.071 I get the sense that's mostly patches backported from newer LDC releases, as they understandably go slower than official LDC for stability, and some git cruft from maintaining their own branch. Their tweaks don't appear to be substantial on a skim, which makes sense since Johan is a committer on the LDC team. Since LDC is an OSS project, they're free to tweak it for their own use and use it as they like. Johan has done much work for them which they've contributed back upstream to LDC. See Johan's blog posts for more info: http://johanengelen.github.io
Re: Liran Zvibel of WekaIO on using D to Create the World’s Fastest File System
On Wednesday, 5 December 2018 at 09:04:49 UTC, Walter Bright wrote: #4 on HackerNews front page! https://news.ycombinator.com/ 33 points at the moment! It's on lobste.rs now too: https://lobste.rs/t/d Thanks, Atila!
Re: Liran Zvibel of WekaIO on using D to Create the World’s Fastest File System
On Wednesday, 5 December 2018 at 09:04:49 UTC, Walter Bright wrote: #4 on HackerNews front page! https://news.ycombinator.com/ 33 points at the moment! Fantastic, I want to get more commercial uses like this highlighted on the blog- started another interview now with a financial/ML firm using D- so nobody can say D isn't being used. BTW, the top HN comment asks for more detail: tell him to click on the DConf links in the post for Liran's slides and videos. There's a surfeit of tech detail there, this is just an overview to get people started on learning more.
Re: Interview with Liran Zvibel of WekaIO
On Wednesday, 5 December 2018 at 06:50:13 UTC, Mike Parker wrote: On Tuesday, 4 December 2018 at 17:15:44 UTC, Joakim wrote: On Tuesday, 4 December 2018 at 14:21:02 UTC, Mike Parker wrote: Great to see this finally up! I agree with the only proggit comment though: the title is not descriptive enough for reddit/HN, as I doubt most have heard of Liran or Weka. It's on HN now under a better title. Thanks, let's see if it does any better. I asked Atila to submit it to lobste.rs too, his mutex post did well on there last month: https://lobste.rs/t/d
Re: Interview with Liran Zvibel of WekaIO
On Tuesday, 4 December 2018 at 14:21:02 UTC, Mike Parker wrote: Joakim interviewed Liran for the D Blog about their file system, Matrix, and their use of D. Thanks to Joakim for putting it together, and to Liran for taking the time to participate! Blog: https://dlang.org/blog/2018/12/04/interview-liran-zvibel-of-wekaio/ Reddit: https://www.reddit.com/r/programming/comments/a3106x/interview_liran_zvibel_of_wekaio/ Great to see this finally up! I agree with the only proggit comment though: the title is not descriptive enough for reddit/HN, as I doubt most have heard of Liran or Weka.
Re: LDC 1.13.0-beta2
On Thursday, 22 November 2018 at 16:54:55 UTC, Joakim wrote: On Thursday, 22 November 2018 at 16:36:22 UTC, H. S. Teoh wrote: On Thu, Nov 22, 2018 at 01:25:53PM +, Joakim via Digitalmars-d-announce wrote: On Wednesday, 21 November 2018 at 10:43:55 UTC, kinke wrote: > Glad to announce the second beta for LDC 1.13: > > * Based on D 2.083.0+ (yesterday's DMD stable). [...] I've added native builds for Android, including Android/x86_64 for the first time. Several tests for std.variant segfault, likely because of the 128-bit real causing x64 codegen issues, but most everything else passes. [...] What's the status of cross-compiling to 64-bit ARM? On the wiki you wrote that it doesn't fully work yet. Does it work with this new release? It's been mostly working since 1.11. That note on the wiki links to this tracker issue that lists the few remaining holes, mostly just extending Phobos support for 80-bit precision out to full 128-bit Quadruple precision in a few spots and finishing off the C/C++ compatibility: https://github.com/ldc-developers/ldc/issues/2153 Btw, if you ever want to check the current status of the AArch64 port, all you have to do is look at the logs for the latest run of the ldc AArch64 CI, which kinke setup and is run for every ldc PR, on this dashboard: https://app.shippable.com/github/ldc-developers/ldc/dashboard Clicking on the last job on the master branch, expanding the build_ci output in the log, then doing the same for the stdlib tests, I see only five Phobos modules with failing tests. Three are mentioned in the tracker issue above, while std.complex has a single assert that trips, because it's a few bits off at 113-bit precision, which is still much more accurate than the 64-bit precision (or less) it's normally run at on x86/x64. Also, a single assert on std.algorithm.sorting trips for the same reason as a handful of tests in std.math: -real.nan at compile-time is output as real.nan by ldc running natively on AArch64, though not when cross-compiling. std.internal.math.gammafunction works fine at 64-bit precision on AArch64, but only a couple of the 100 or so constant reals it uses are at full 113-bit precision, so several tests assert that only allow a couple bits to be off from full real precision. Obviously that only matters if you need full 113-bit precision from that module. kinke recently disabled the tests for core.thread on the CI because they're super-flaky on linux/glibc/AArch64, while I haven't had that problem with Bionic/AArch64. You will see more tests failing if you cross-compile from x64, because of the mismatch between 64-bit precision for compile-time reals and 113-bit precision for runtime reals on AArch64. Also, you can see the 10-12 modules that assert in the dmd compiler testsuite earlier in that log, most because of missing core.stdc.stdarg.va_arg support to call C varargs on AArch64. That's about it: help is appreciated on tightening those last few screws.
Re: D compilation is too slow and I am forking the compiler
On Monday, 26 November 2018 at 16:42:40 UTC, bachmeier wrote: On Monday, 26 November 2018 at 16:21:39 UTC, Joakim wrote: I agree that it was a risky title, as many who don't know D will simply see it and go, "Yet another slow compiler, eh, I'll pass" and not click on the link. Whereas others who have heard something of D will be intrigued, as they know it's already supposed to compile fast. And yet more others will click on it purely for the controversy, just to gawk at some technical bickering. I don't actually think it was risky. What are the odds that someone was going to start using D for a major project but then changed her mind upon seeing a title on HN or Reddit? Probably very small that even one person did that. Yes, but you're ignoring the much larger group I mentioned- those who only vaguely heard of D, if at all- and the negative title gives them a reason not to look into it further. And then there is always the fact that there was a story on HN/Reddit about D. It's hard for publicity for a language like D to be bad when so few people use it. The quote that "there's no such thing as bad publicity" comes from art and show business though, don't think it's true for tech and other markets. When your audience is looking for a tool and not entertainment, there's lots of ways for bad publicity to sink it. Anyway, I noted in this case that the provocative title may actually have gotten more people to read a positive post, so the pros likely outweighed the cons. We can just never know how large the unclicked-on downside was: you can never measure how many people heard of but _didn't_ buy your book, because they didn't like the title or something else about its exterior. On Monday, 26 November 2018 at 16:53:59 UTC, Guillaume Piolat wrote: On Monday, 26 November 2018 at 16:21:39 UTC, Joakim wrote: In my opinion language adoption is a seduction/sales process very much like business-to-consumer is, the way I see it it's strikingly similar to marketing B2C apps, unless there will be no "impulse buy". I find that hard to believe: we are talking about a technical tool here. How many times have you been in this conversation: -- - What language are you using? - D. - I know next to nothing about D. - Oh, it's very good, I even built a business on it! list of arguments and features>. - Oh no thanks. I should try Rust, it's secure, fast, modern blah blah; facts don't matter to me. But in reality I won't even learn a new language, I'm happy with a language without multi-threading. -- It happens to me ALL THE TIME. This pattern is so predictable it's becoming boring so now I just keep silent. Never, I don't go around trying to convince people one-on-one to use D. I have given talks to groups introducing the language, that's how I go about it. What happens? Rust / Go have outmarketed us with words. The battle (of marketing) is on words not technical features, Rust happen to own "programming language" + "safety", what do we own? D is good in all kinds of directions and the marketing message is less simple. The leaders choose to own the word "fast" (see our new motto "fast code, fast" which is very accurate) and it's important to get aligned. I'll note that in your example they haven't actually learnt Rust either. I don't think marketing is that relevant for D at this stage, nor for Rust/Go either. The way anything- tech, fashion, TV shows- becomes popular is that some early tastemaker decides that it's worth using or backing. Eventually, enough early adopters find value that it spreads out to the majority, who simply follow their lead. Most people aren't early adopters of most things. They like to think they are, so they'll give you all kinds of rational-sounding reasons for why they don't like some new tech, but the real underlying thought process goes something like this, "I have no idea if this new tech will do well or not. I could take a risk on it but it's safer not to, so I will just wait and see if it gets popular, then follow the herd." Very few will admit this though, hence the list of plausible-sounding reasons that don't actually make sense! ;) As Laeeth always says, you're best off looking for people who're actually capable and empowered to make such risky decisions, rather than aiming for the majority too early, because they only jump on board once the bandwagon is stuffed and rolling downhill. Also, regardless of how languages are chosen as they get into the majority, D is very much still in the innovators/early-adopters stage: But the current state of D would very much accomodate the middle-of-the-curve adopters. The language rarely breaks stuff. People making money with it, making long-term bets. Hell, I could make a laundry list of things that are better in D versus any alternatives! That doesn't bring users. I'm not talking about the quality of
Re: D compilation is too slow and I am forking the compiler
On Monday, 26 November 2018 at 16:00:36 UTC, Guillaume Piolat wrote: On Thursday, 22 November 2018 at 04:48:09 UTC, Vladimir Panteleev wrote: On Wednesday, 21 November 2018 at 20:51:17 UTC, Walter Bright wrote: Unfortunately, you're right. The title will leave the impression "D is slow at compiling". You have to carefully read the article to see otherwise, and few will do that. Sorry about that. I'll have to think of two titles next time, one for the D community and one for everyone else. If it's of any consolation, the top comments in both discussion threads point out that the title is inaccurate on purpose. Please don't get me wrong, it's an excellent article, a provocative title, and fantastic work going on. I didn't meant to hurt! In my opinion language adoption is a seduction/sales process very much like business-to-consumer is, the way I see it it's strikingly similar to marketing B2C apps, unless there will be no "impulse buy". I find that hard to believe: we are talking about a technical tool here. Also, regardless of how languages are chosen as they get into the majority, D is very much still in the innovators/early-adopters stage: https://en.m.wikipedia.org/wiki/Technology_adoption_life_cycle That is a very different type of sales process, much more geared towards what the new tech can actually do. Actually no less than 3 programmer friends came to (I'm the weirdo-using-D and people are _always_ in disbelief and invent all sorts of reasons not to try) saying they saw an article on D on HN, with "D compilation is slow", and on further examination they didn't read or at best the first paragraph. But they did remember the title. They may rationally think their opinion of D hasn't changed: aren't we highly capable people? With people like that, it's almost impossible to get them in the early adopter stage. They will only jump on the bandwagon once it's full, ie as part of the late majority. I'm not making that up! So why is it a problem ? HN may be the only time they hear about D. The words of the title may be their only contact with it. The first 3 words of the title may be the only thing associated with the "D language" chunk in their brain. The associative mind doesn't know _negation_ so even a title like "D compilation wasn't fast so I forked the compiler" is better from a marketing point of view since it contains the word "fast" in it! That's why marketing people have the annoying habit of using positive words, you may think this stuff is unimportant but this is actually the important meat. Reasonable people may think marketing and biases don't apply to them but they do, it works without your consent. I agree that it was a risky title, as many who don't know D will simply see it and go, "Yet another slow compiler, eh, I'll pass" and not click on the link. Whereas others who have heard something of D will be intrigued, as they know it's already supposed to compile fast. And yet more others will click on it purely for the controversy, just to gawk at some technical bickering. Given how well it did on HN/reddit/lobste.rs, I think Vlad's gamble probably paid off. We can't run the counterfactual of choosing a safer title to see if it would have done even better, let's just say it did well enough. ;)
Re: LDC 1.13.0-beta2
On Thursday, 22 November 2018 at 16:36:22 UTC, H. S. Teoh wrote: On Thu, Nov 22, 2018 at 01:25:53PM +, Joakim via Digitalmars-d-announce wrote: On Wednesday, 21 November 2018 at 10:43:55 UTC, kinke wrote: > Glad to announce the second beta for LDC 1.13: > > * Based on D 2.083.0+ (yesterday's DMD stable). [...] I've added native builds for Android, including Android/x86_64 for the first time. Several tests for std.variant segfault, likely because of the 128-bit real causing x64 codegen issues, but most everything else passes. [...] What's the status of cross-compiling to 64-bit ARM? On the wiki you wrote that it doesn't fully work yet. Does it work with this new release? It's been mostly working since 1.11. That note on the wiki links to this tracker issue that lists the few remaining holes, mostly just extending Phobos support for 80-bit precision out to full 128-bit Quadruple precision in a few spots and finishing off the C/C++ compatibility: https://github.com/ldc-developers/ldc/issues/2153
Re: LDC 1.13.0-beta2
On Wednesday, 21 November 2018 at 10:43:55 UTC, kinke wrote: Glad to announce the second beta for LDC 1.13: * Based on D 2.083.0+ (yesterday's DMD stable). * The Windows packages are now fully self-sufficient, i.e., a Visual Studio/C++ Build Tools installation isn't required anymore. * Substantial debug info improvements. * New command-line option `-fvisibility=hidden` to hide functions/globals not marked as export, to reduce the size of shared libraries. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.13.0-beta2 Thanks to all contributors! I've added native builds for Android, including Android/x86_64 for the first time. Several tests for std.variant segfault, likely because of the 128-bit real causing x64 codegen issues, but most everything else passes. This means that if you have an x86 or x64 Chromebook that supports running Android apps, you can install the Termux app and compile D code on there: https://nosarthur.github.io/coding/2018/01/15/termux.html
Re: DMD backend now in D
On Tuesday, 13 November 2018 at 20:42:00 UTC, Temtaime wrote: On Monday, 12 November 2018 at 02:37:54 UTC, Walter Bright wrote: On 11/11/2018 3:58 PM, Mike Franklin wrote: This is a significant milestone. Congratulations, Walter! Many people helped out with this, too. There are still a few .c files in https://github.com/dlang/dmd/tree/master/src/dmd/backend, so what's the significance of those? tk.c fp.c os.c strtold.c tk/mem.c These could be converted too, but are independent from everything else and hardly seem worth the bother. Sebastian has a PR for os.cd. Will there ever be a day when we no longer need a C/C++ compiler to build DMD? Sure. No, as phobos is dependent on C libraries such as a zlib for example. DMD doesn't use Phobos. Also D is dependent on libc. It's possible to reimplement the subset of libc functions that DMD depends on in D.
Re: DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement
On Monday, 12 November 2018 at 17:25:15 UTC, Johannes Loher wrote: On Monday, 12 November 2018 at 16:39:47 UTC, Mike Parker wrote: Walter and Andrei take the position that this is incorrect the wrong way to view a bool. Unfortunately you did not include their justification for this position (if any). To me it would be interesting to know about the reasoning that is behind this position. Maybe you didn't read the link to their reasoning in the DIP, but it's quite simple: they view a bool as an integral type with two possible values, a `bit` if you like. As such, they prefer to fit it into the existing scheme for integral types rather than special-casing booleans as Mike proposed.
Re: The New Fundraising Campaign
On Saturday, 10 November 2018 at 16:09:12 UTC, Mike Parker wrote: I've just published a new blog post describing our new fundraising campaign. TL;DR: We want to pay a Pull Request Manager to thin out the pull request queues and coordinate between relevant parties on newer pull requests so they don't go stale. We've launched a three-month campaign, and Nicholas Wilson has agreed to do the work. We have high hopes that this will help reduce frustration for current and future contributors. And we will be grateful for your support in making it happen. Please read the blog post for more details: https://dlang.org/blog/2018/11/10/the-new-fundraising-campaign/ For the impatient: https://www.flipcause.com/secure/cause_pdetails/NDUwNTY= "Walter and Andrei both" -> both Walter and Andrei "Pull requests were" -> Pull Requests (PRs) were "the list. The one linked above, for example." -> the list, for example, the one linked above. Nice work setting this up, looking forward to many more targeted campaigns like this.
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 08:29:28 UTC, Manu wrote: On Thu, Nov 8, 2018 at 12:10 AM Joakim via Digitalmars-d-announce wrote: On Thursday, 8 November 2018 at 07:54:56 UTC, Manu wrote: > On Wed, Nov 7, 2018 at 10:30 PM Vladimir Panteleev via > Digitalmars-d-announce > wrote: >> >> On Thursday, 8 November 2018 at 06:08:20 UTC, Vladimir >> Panteleev wrote: >> > It was definitely about 4 seconds not too long ago, a few >> > years at most. >> >> No, it's still 4 seconds. >> >> digger --offline --config-file=/dev/null -j auto -c >> local.cache=none build 7.31s user 1.51s system 203% cpu >> 4.340 total >> >> > It does seem to take more time now; I wonder why. >> >> If it takes longer, then it's probably because it's being >> built in one CPU core, or in the release build. > > https://youtu.be/msWuRlD3zy0 Lol, I saw that link and figured it was either some comedy video, like the Python ones Walter sometimes posts, or you were actually showing us how long it takes. Pretty funny to see the latter. It's not so funny when every one-line tweak burns 2 minutes of my life away. I was laughing that you actually proved your point with direct video evidence, obviously it's sad that it takes so long. > DMD only builds with one core, since it builds altogether. Yes, but your build time is unusually long even with one core. Are the D backend and frontend at least built in parallel to each other? That doesn't matter, you can clearly see the backend built in less than 2 seconds. The C/C++ files in the beginning are built very fast, but the D files in the backend appear to take much longer, kicking in at 1:18 of your video and then the next compilation step starts at 1:40. I suspect part of the problem is that your build is being done completely serially, even for separate compilation. I have no experience with VS, so I don't know why that is. It doesn't seem to be even doing that, though they're separate invocations of DMD. I didn't configure the build infrastructure! Maybe you can? I have no experience with VS, but surely it has some equivalent of ninja -j5? > And all builds are release builds... what good is a debug > build? DMD > is unbelievably slow in debug. If it wasn't already slow > enough... if > I try and build with a debug build, it takes closer to 5 > minutes. > > I suspect one part of the problem is that DMD used to be > built with a C compiler, and now it's built with DMD... it > really should be built with LDC at least? Could be part of the problem on Windows, dunno. Well... ffs... people need to care about this! >_< I agree that the official release of DMD for Windows should be faster, and we should be building it with ldc... if that's the problem.
Re: Backend nearly entirely converted to D
On Wednesday, 7 November 2018 at 21:40:58 UTC, welkam wrote: On Wednesday, 7 November 2018 at 14:39:55 UTC, Joakim wrote: I don't know why you think that would matter: I'm using the same compilers to build each DMD version and comparing the build times as the backend was translated to D What did you compared is whether clang or DMD compiles code faster not whether D code compiles faster than C++. To check that you should compile both C++ and D with the same backend. I'm not making any general statements about whether C++ or D compiles faster, only pointing out that in a common setup of building dmd with clang and dmd on linux/x64, I didn't see much of a speed gain. However, I did mention that the frontend should be removed to really measure the backend conversion, so that's what I just did. I built the backends for DMD 2.080.1 through master in the same single-core VPS by slightly modifying src/posix.mak, only replacing the line "all: $G/dmd" with "all: $G/backend.a". Here are the results I got and how many D files were built in each backend: 2.080.1 - 1D 8.0s 2.081.2 - 4D 7.2s 2.082.1 - 27D 6.9s 2.083.0 - 45D 5.6s master d398d8c - 50D 4.3s So the frontend might have been obscuring things, as we see a clear win from moving the backend to D, with only about 10 C/C++ files left in the backend now and compilation time cut almost in half. I think we'll see even more of a gain if the D files in the backend are built all at once.
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 07:54:56 UTC, Manu wrote: On Wed, Nov 7, 2018 at 10:30 PM Vladimir Panteleev via Digitalmars-d-announce wrote: On Thursday, 8 November 2018 at 06:08:20 UTC, Vladimir Panteleev wrote: > It was definitely about 4 seconds not too long ago, a few > years at most. No, it's still 4 seconds. digger --offline --config-file=/dev/null -j auto -c local.cache=none build 7.31s user 1.51s system 203% cpu 4.340 total > It does seem to take more time now; I wonder why. If it takes longer, then it's probably because it's being built in one CPU core, or in the release build. https://youtu.be/msWuRlD3zy0 Lol, I saw that link and figured it was either some comedy video, like the Python ones Walter sometimes posts, or you were actually showing us how long it takes. Pretty funny to see the latter. DMD only builds with one core, since it builds altogether. Yes, but your build time is unusually long even with one core. Are the D backend and frontend at least built in parallel to each other? It doesn't seem to be even doing that, though they're separate invocations of DMD. And all builds are release builds... what good is a debug build? DMD is unbelievably slow in debug. If it wasn't already slow enough... if I try and build with a debug build, it takes closer to 5 minutes. I suspect one part of the problem is that DMD used to be built with a C compiler, and now it's built with DMD... it really should be built with LDC at least? Could be part of the problem on Windows, dunno.
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 07:41:58 UTC, Manu wrote: On Wed, Nov 7, 2018 at 10:30 PM Joakim via Digitalmars-d-announce wrote: On Thursday, 8 November 2018 at 04:16:44 UTC, Manu wrote: > On Tue, Nov 6, 2018 at 10:05 AM Vladimir Panteleev via > Digitalmars-d-announce > wrote: >> [...] > > "Indeed, a clean build of DMD itself (about 170’000 lines of > D and 120’000 lines of C/C++) takes no longer than 4 seconds > to build on a rather average developer machine." > > ...what!? DMD takes me... (compiling) ... 1 minute 40 > seconds to build! And because DMD does all-files-at-once > compilation, rather than separate compilation for each > source file, whenever you change just one line in one file, > you incur that entire build time, every time, because it > can't just rebuild the one source file that changed. You > also can't do multi-processor builds with all-in-one build > strategies. > > 4 seconds? That's just untrue. D is actually kinda slow > these days... In my experience it's slower than modern C++ > compilers by quite a lot. It sounds like you're not using "a rather average developer machine" then, as there's no way DMD should be that slow to build on a core i5 or better: https://forum.dlang.org/post/rqukhkpxcvgiefrdc...@forum.dlang.org I'm on an i7 with 8 threads and plenty of ram... although threads are useless, since DMD only uses one ;) Running Windows XP? ;) That does sound like Windows though, as I do remember being surprised how long dmd took to build on Win7 when I tried it 8-9 years back. I still don't think the toolchain should be _that_ much slower than linux though. Btw, the extra cores are _not_ useless for the DMD backend, which has always used separate compilation, whether written in C++ or D.
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 04:16:44 UTC, Manu wrote: On Tue, Nov 6, 2018 at 10:05 AM Vladimir Panteleev via Digitalmars-d-announce wrote: [...] "Indeed, a clean build of DMD itself (about 170’000 lines of D and 120’000 lines of C/C++) takes no longer than 4 seconds to build on a rather average developer machine." ...what!? DMD takes me... (compiling) ... 1 minute 40 seconds to build! And because DMD does all-files-at-once compilation, rather than separate compilation for each source file, whenever you change just one line in one file, you incur that entire build time, every time, because it can't just rebuild the one source file that changed. You also can't do multi-processor builds with all-in-one build strategies. 4 seconds? That's just untrue. D is actually kinda slow these days... In my experience it's slower than modern C++ compilers by quite a lot. It sounds like you're not using "a rather average developer machine" then, as there's no way DMD should be that slow to build on a core i5 or better: https://forum.dlang.org/post/rqukhkpxcvgiefrdc...@forum.dlang.org
Re: Backend nearly entirely converted to D
On Wednesday, 7 November 2018 at 15:12:13 UTC, Dukc wrote: On Wednesday, 7 November 2018 at 14:39:55 UTC, Joakim wrote: I don't know why you think that would matter: I'm using the same compilers to build each DMD version and comparing the build times as the backend was translated to D. Because generally, LLVM compilers provide faster code, but compile slower than Digital Mars compilers AFAIK. So if you compile the D code with DMD but C code with LDC, the program will likely compile faster but execute slower as increasing portions are written in D, compared to using the same backend for both languages. I'm not sure if you benchmarked the time used to build DMD, or the time used by generated DMD to compile some other program. If it was the former, the "real" result is probably worse than your results. But if it was the latter, it is likely better. The former, if it wasn't clear. It's also possible something slowed down building the frontend in successive DMD versions, so ideally I'd only time building the backend for each DMD version, but I haven't looked into that.
Re: Backend nearly entirely converted to D
On Wednesday, 7 November 2018 at 11:22:13 UTC, Dukc wrote: On Wednesday, 7 November 2018 at 08:31:21 UTC, Joakim wrote: I just benchmarked building the last couple versions of DMD, when most of the backend was converted to D, by building them with the latest DMD 2.083.0 official release and clang 6.0 in a single-core linux/x64 VPS. Here are the times I got, best of 3 runs for each: 2.081.2 - 11.5s 2.082.1 - 10.5s 2.083.0 - 9.9s master - 10.8s Not quite the gains hoped for, particularly with those last large files you just converted to D seemingly slowing compilation down Could this be because you used a LLVM compiler for the C code but a Mars compiler for D code? If one either uses DMC for C or LDC for D, perhaps the results will be better. I don't know why you think that would matter: I'm using the same compilers to build each DMD version and comparing the build times as the backend was translated to D. Maybe I'd get different results by using different compilers, but these are two fairly fast and commonly used compilers so they're worth checking with.
Re: Backend nearly entirely converted to D
On Tuesday, 6 November 2018 at 22:12:02 UTC, Walter Bright wrote: With the recent merging of the last of the big files machobj.d: https://github.com/dlang/dmd/pull/8911 I'm happy to say we're over the hump in converting the backend to D! Great! Although I wish it didn't have to be you mostly doing this grunt work. Remaining files are minor: tk.c, cgen.c, dt.c, fp.c, os.c, outbuf.c, sizecheck.c, strtold.c and mem.c. I'll probably leave a couple in C anyway - os.c and strtold.c. sizecheck.c will just go away upon completion. Thanks to everyone who helped out with this! Of course, the code remains as ugly as it was in C. It'll take time to bit by bit refactor it into idiomatic D. I just benchmarked building the last couple versions of DMD, when most of the backend was converted to D, by building them with the latest DMD 2.083.0 official release and clang 6.0 in a single-core linux/x64 VPS. Here are the times I got, best of 3 runs for each: 2.081.2 - 11.5s 2.082.1 - 10.5s 2.083.0 - 9.9s master - 10.8s Not quite the gains hoped for, particularly with those last large files you just converted to D seemingly slowing compilation down, but maybe it will get better with refactoring and when the entire backend is compiled at once, rather than the DMD separate compilation used now. The more immediate benefit is to get rid of all the parallel .h files, which were a constant source of bugs when they didn't match the .d versions. I was going to ask why you wouldn't need those headers for your C/C++ compiler, DMC, but it looks like you've translated that to mostly D already: https://github.com/DigitalMars/Compiler/tree/master/dm/src/dmc
Re: Lost in Translation: Encapsulation
On Tuesday, 6 November 2018 at 15:14:55 UTC, Mike Parker wrote: Last week, inspired by another discussion in these forums about D's private-to-the-module form of encapsulation, I spent a few hours putting a new article together for the blog. Ali, Joakim, Nicholas helped me get it in shape. The blog: https://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/ Reddit: https://www.reddit.com/r/programming/comments/9up2yo/lost_in_translation_encapsulation_in_d/ Nicely done, think this could do well on proggit/HN/lobste.rs.
Re: LDC 1.13.0-beta1
On Friday, 2 November 2018 at 21:04:13 UTC, kinke wrote: Glad to announce the first beta for LDC 1.13: * Based on D 2.083.0. * The Windows packages are now fully self-sufficient, i.e., a Visual Studio/C++ Build Tools installation isn't required anymore. * Substantial debug info improvements for GDB. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.13.0-beta1 Thanks to all contributors! I've added native Termux builds for Android, including x86 for the first time. Cross-compiling to Android/x64 mostly works, but LDC itself segfaults when cross-compiled and run on Android/x64, likely because it uses a 128-bit real just like AArch64. I'll see if I can get that fixed before the final 1.13 release.
Re: smile.amazon.com Promotion
On Thursday, 1 November 2018 at 03:18:44 UTC, SealabJaster wrote: On Monday, 29 October 2018 at 16:40:20 UTC, FooledDonor wrote: On Monday, 29 October 2018 at 16:01:38 UTC, Mike Parker wrote: One of the easiest ways to support the D Language Foundation is using smile.amazon.com when you make a purchase. Until Nov 2, they're running a special where they're donating 5% (10 times the usual amount) you buy through AmazonSmile. smile.amazon.com/ch/47-5352856 Perhaps a fundamental principle is not clear enough at the foundation: transparency. Where is the vision of the third and fourth quarter? Where are the deliveries of things in the pipeline? What is the progress of the various jobs started? Which people is funding, with how much money and for what expected results? Where is the newCTFE? Was the work on this point financed by the foundation? I've never seen a report on the state of affairs, neither from the president, nor from Andrei, nor from Walter. How do you hope to obtain trust and funding, if NO one even deigns to give the least development plan or feedback on past developments? It seems that everyone has locked up in their ivory tower ... It's kind of discouraging to see that your post, as well as another thread asking something similar regarding the vision document[1] have gone unanswered... Maybe the people who could answer these things just don't see them, or maybe they're purposefully being quiet. It would be nice to know what's going on at the very least ;( [1] https://forum.dlang.org/thread/qmwovarkjgvxyibsl...@forum.dlang.org My guess, and this is purely a guess, is that they got discouraged by how few people paid attention to the Vision document or donated to the foundation on Opencollective and haven't bothered with this stuff since. I think that's a mistake, as you may need to do this stuff for awhile before it picks up. In any case, I don't care that it isn't happening, as I always said that it's better to have decentralized bounties, like we had on bountysource, rather than centralized funding through the D Foundation. Maybe the upcoming targeted campaigns will be a good middle ground, in that you will be able to directly contribute to specific targets: https://dlang.org/blog/2018/07/13/funding-code-d/
Re: Add D front-end, libphobos library, and D2 testsuite... to GCC
On Monday, 29 October 2018 at 09:57:46 UTC, Walter Bright wrote: On 10/28/2018 8:43 PM, Mike Parker wrote: Congratulations are in order for Iain Buclaw. His efforts have been rewarded in a big way. Last Friday, he got the greenlight to move forward with submitting his changes into GCC: Reddit: https://www.reddit.com/r/programming/comments/9sb74k/the_d_language_frontend_finally_merged_into_gcc_9/ HackerNews (at #12 on the front page): https://news.ycombinator.com/news On Lobsters too: https://lobste.rs/s/9ziils/d_language_front_end_finally_merged_into
Re: New Initiative for Donations
On Friday, 26 October 2018 at 17:20:08 UTC, Neia Neutuladh wrote: On Fri, 26 Oct 2018 06:19:29 +, Joakim wrote: On Friday, 26 October 2018 at 05:47:05 UTC, Neia Neutuladh wrote: On Fri, 26 Oct 2018 02:38:08 +, Joakim wrote: As with D, sometimes the new _is_ better, so perhaps you shouldn't assume old is better either. There's no assuming going on. Cryptocurrencies are worse than credit cards for everything that normal people care about, Such as? I already noted that they're easier and cheaper, you simply flatly state that "normal people" find them worse. In most countries where people are going to donate to D, the vast majority of people have access to a credit card. That's not really true, and that's not actually something "worse" about cryptocurrencies. If you really mean have some lying around, it is true that more are using credit cards. If you actually mean access, crypto-currencies are pretty easy to buy these days. If for some reason cryptocurrencies become popular and sufficiently stable to be used as currency, I have no doubt that existing credit card companies will start offering automatic currency exchange, so you can have an account in USD and pay a vendor who accepts only Ethereum, or vice versa. As such, accepting credit card payments is good enough. I don't know what we'd be waiting for, the tokens I mentioned are all worth billions and widely used, particularly by techies: Very few merchants accept any sort of cryptocurrency. I think I've found three. One was through a cryptocurrency forum, and one was Valve announcing that they would stop accepting it. You must not have looked very hard, there are online retailers accepting crypto-tokens and websites that will make payments for you on Amazon or other sites through Bitcoin: https://www.overstock.com/blockchain https://purse.io/shop Why would I wait for antiquated credit-card companies to accept these tokens? The whole point of these new tokens is to obsolete the credit card companies. You wouldn't wait. You haven't waited. For you, the benefits are large enough and the downsides small enough that it doesn't make sense to wait. But I'm not you. No, I'm not much of a cryptocurrency user or online shopper even. I mostly buy locally with cash. I would wait because I've lost access to important credentials before and had to send a copy of my government-issued ID to a company to get them to deactivate two-factor authentication. I've had to use password reset mechanisms frequently. I don't trust myself not to lose access to a cryptocurrency private key. And that would destroy currency and lose me my life savings. I don't blame you for being careful if you've had these problems, most of which I've never had, but you wildly exaggerate with your last sentence. Crypto-tokens are a replacement for cash and credit cards, which you should never be carrying around more than a couple hundred or thousand dollars worth of. If you're carrying around your life savings in cash or credit cards and are worried about moving them to bitcoin, you have much bigger problems. ;) I would wait because I want a mechanism to dispute transactions. Maybe I authorized that transaction, but the merchant didn't deliver. I don't think the payment provider is the right mechanism for that. The seller wants to protect their reputation and your payment is publicly verifiable through the blockchain. There are much better ways to build trust through those building blocks than the currently broken credit card chargeback process: https://www.shopify.com/retail/what-is-a-chargeback I would wait because I want an environmentally-friendly system instead of one that uses as much electricity as Afghanistan to process fifteen transactions per second. Yes, I noted the Bitcoin "Proof of work" problem in this forum almost five years ago, so I'm well aware: https://forum.dlang.org/post/xzuzvykrqouqlsjmk...@forum.dlang.org There are "Proof of stake" crypto-tokens out there that purport to avoid that issue: https://blockgeeks.com/guides/proof-of-work-vs-proof-of-stake/ Ether, one of the tokens I mentioned originally, is moving to this scheme. I would wait because cryptocurrencies have extremely volatile exchange rates, which makes it difficult to set prices or store value in them. If you're buying online, which is what we're talking about, it's trivially simple to track the exchange rates and instantaneously set store prices accordingly. It may be a bit different for consumers, but by the time they're all using some payments tech like this, the exchange rates will likely have settled down. I would wait because I can't use cryptocurrency to do anything useful, so I would incur a fee to transfer money into it and another to transfer money out of it. Not necessarily- it depends on who you're buying your tokens from- and crypto-tokens usually work out cheaper once you include other
Re: New Initiative for Donations
On Friday, 26 October 2018 at 05:47:05 UTC, Neia Neutuladh wrote: On Fri, 26 Oct 2018 02:38:08 +, Joakim wrote: As with D, sometimes the new _is_ better, so perhaps you shouldn't assume old is better either. There's no assuming going on. Cryptocurrencies are worse than credit cards for everything that normal people care about, Such as? I already noted that they're easier and cheaper, you simply flatly state that "normal people" find them worse. and they're better than credit cards for illegal transactions. Yes, just like cash, and have other benefits that come with cash too. This might eventually change, and we can re-evaluate then. If for some reason cryptocurrencies become popular and sufficiently stable to be used as currency, I have no doubt that existing credit card companies will start offering automatic currency exchange, so you can have an account in USD and pay a vendor who accepts only Ethereum, or vice versa. As such, accepting credit card payments is good enough. I don't know what we'd be waiting for, the tokens I mentioned are all worth billions and widely used, particularly by techies: https://coinmarketcap.com Why would I wait for antiquated credit-card companies to accept these tokens? The whole point of these new tokens is to obsolete the credit card companies.
Re: New Initiative for Donations
On Thursday, 25 October 2018 at 22:35:40 UTC, Nick Sabalausky wrote: On Wednesday, 24 October 2018 at 10:25:17 UTC, Joakim wrote: On Wednesday, 24 October 2018 at 10:18:51 UTC, Mike Parker wrote: On Wednesday, 24 October 2018 at 10:12:50 UTC, Joakim wrote: Any effort underway to take Bitcoin Cash, Ether, or Ripple as donations? The current payment options seem fairly antiquated: credit cards, wire transfers, and the like. Not that I'm aware of. I'd hardly call credit cards antiquated, though :-) 60-year old tech seems pretty old to me: https://en.m.wikipedia.org/wiki/Credit_card#BankAmericard_and_Master_Charge And yet it's still by far the most common payment method. So what if it isn't trendy. Deal with it. In the US maybe, not in most of the world, where they're still using cash. ;) I almost never use my cards, and like that crypto-currencies have more in similar to cash. On Thursday, 25 October 2018 at 23:10:50 UTC, H. S. Teoh wrote: On Thu, Oct 25, 2018 at 10:35:40PM +, Nick Sabalausky via Digitalmars-d-announce wrote: On Wednesday, 24 October 2018 at 10:25:17 UTC, Joakim wrote: > On Wednesday, 24 October 2018 at 10:18:51 UTC, Mike Parker > wrote: > > On Wednesday, 24 October 2018 at 10:12:50 UTC, Joakim > > wrote: [...] > > > [...] > > > > Not that I'm aware of. I'd hardly call credit cards > > antiquated, though :-) > > 60-year old tech seems pretty old to me: > > https://en.m.wikipedia.org/wiki/Credit_card#BankAmericard_and_Master_Charge > And yet it's still by far the most common payment method. So what if it isn't trendy. Deal with it. Common fallacy: new == better. As with D, sometimes the new _is_ better, so perhaps you shouldn't assume old is better either.
Re: Interfacing D with C: Arrays Part 1
On Wednesday, 17 October 2018 at 15:20:08 UTC, Mike Parker wrote: I had intended to publish the next GC series post early this month, but after many revisions and discussions with a couple of reviewers, I've decided to put it on hold until something gets worked out about the conflation of destruction and finalization in D (something I'll be pushing for soon). [...] "article is has morphed"
Re: Iain Buclaw at GNU Tools Cauldron 2018
On Sunday, 7 October 2018 at 15:41:43 UTC, greentea wrote: Date: September 7 to 9, 2018. Location: Manchester, UK GDC - D front-end GCC https://www.youtube.com/watch?v=iXRJJ_lrSxE Thanks for the link, just watched the whole video. The first half-hour sets the standard as an intro to the language, as only a compiler developer other than the main implementer could give, ie someone with fresh eyes. I loved that Iain started off with a list of real-world projects. That's a mistake a lot of tech talks make, ie not motivating _why_ anybody should care about their tech and simply diving into the tech itself. I hadn't heard some of that info either, great way to begin. My only nitpick is that I wish he'd emphasized how much of a focus D puts on metaprogramming, as I've noticed a lot of comments on proggit/HN/etc. saying that the power and ease of use of D's metaprogramming really stood out for them when trying the language.
Re: Webassembly TodoMVC
On Saturday, 22 September 2018 at 19:51:48 UTC, Sebastiaan Koppe wrote: On Saturday, 22 September 2018 at 14:54:29 UTC, aberba wrote: [...] Currently the whole thing is not so developer-friendly, it was just the easiest way for me to get it up and running. [...] Vladimir mentioned that there's a Musl port to wasm, have you tried it? https://github.com/jfbastien/musl Druntime and ldc support Musl.
Re: LLVM 7.0.0 no mention of D anymore
On Wednesday, 19 September 2018 at 13:10:07 UTC, Daniel Kozak wrote: http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html#external-open-source-projects-using-llvm-7 no mention of D anymore :( http://releases.llvm.org/6.0.0/docs/ReleaseNotes.html#external-open-source-projects-using-llvm-6 http://releases.llvm.org/5.0.0/docs/ReleaseNotes.html#external-open-source-projects-using-llvm-5 http://releases.llvm.org/4.0.0/docs/ReleaseNotes.html#external-open-source-projects-using-llvm-4-0-0 I think Kai used to make sure every LLVM release worked and notified them to mention ldc. I don't he's had time to do much with ldc lately, so maybe it slipped through.
Re: A Brief Intro to the SAoC Projects
On Saturday, 15 September 2018 at 07:47:46 UTC, Mike Parker wrote: I've posted to the blog a brief introduction to the projects that were selected for the Symmetry Autumn of Code. As the event goes on, I hope to provide more details about the projects and the individuals working on them. The blog: https://dlang.org/blog/2018/09/15/symmetry-autumn-of-code-is-underway/ Reddit: https://www.reddit.com/r/d_language/comments/9fzrqd/symmetry_autumn_of_code_is_underway/? Proggit post, I think they'll be interested in knowing what was chosen too: https://www.reddit.com/r/programming/comments/9g2ifo/symmetry_autumn_of_code_is_underway_the_d_blog/
Re: LDC 1.12.0-beta1
On Friday, 7 September 2018 at 07:54:37 UTC, Petar Kirov [ZombineDev] wrote: On Friday, 7 September 2018 at 03:12:50 UTC, Joakim wrote: On Wednesday, 5 September 2018 at 05:15:45 UTC, Joakim wrote: I'll add native beta builds for Android in a couple days. The native Android builds are up at the above github release link. I think this is the last time I'll put beta builds out, too much of a PITA to rebuild llvm each time. I'll continue maintaining the ldc package in the official Termux package repo though. The Termux package build script used to build these betas is online here: https://github.com/joakim-noah/termux-packages/tree/beta/packages/ldc-beta Can the Android builds be done automatically on the CI, like those for other platforms or the process is more involved? They could, though our tweaked llvm still has to be rebuilt for each Android platform. It may be worth setting up at some point. I've been thinking of setting up an Alpine CI for ldc, so I don't have to manually build each release, just as kinke now does for linux/armhf also.
Re: LDC 1.12.0-beta1
On Wednesday, 5 September 2018 at 05:15:45 UTC, Joakim wrote: I'll add native beta builds for Android in a couple days. The native Android builds are up at the above github release link. I think this is the last time I'll put beta builds out, too much of a PITA to rebuild llvm each time. I'll continue maintaining the ldc package in the official Termux package repo though. The Termux package build script used to build these betas is online here: https://github.com/joakim-noah/termux-packages/tree/beta/packages/ldc-beta
Re: LDC 1.12.0-beta1
On Tuesday, 4 September 2018 at 23:03:30 UTC, Arun Chandrasekaran wrote: On Tuesday, 4 September 2018 at 22:47:39 UTC, kinke wrote: Glad to announce the first beta for LDC 1.12: * Based on D 2.082.0. * LTO working for Win64 targets. * IR-based PGO working for Windows targets. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.12.0-beta1 Thanks to all contributors! Fantastic work! This is the first time LDC caught up with DMD in a single day, I guess. No, kinke has had this down before, as the first 1.10 beta came out within two weeks and the 1.11 beta came out on the same day as its upstream dmd: https://forum.dlang.org/thread/lyzbdiqcnohbvphzg...@forum.dlang.org https://forum.dlang.org/thread/gpeecjveashtvfpih...@forum.dlang.org This _is_ the first time we're releasing a native build of LDC for linux/AArch64 on the release date, because of the work kinke did to add a Linux/AArch64 CI for LDC, which also automatically uploads the release build. 1.11 was the first release with an AArch64 build, but that was added manually a week later, as can be seen from the datestamps here: http://www.somsubhra.com/github-release-stats/?username=ldc-developers=ldc I'll add native beta builds for Android in a couple days.
Re: D support for ChromeOS
On Tuesday, 28 August 2018 at 12:34:50 UTC, Martin Tschierschke wrote: On Wednesday, 22 August 2018 at 10:28:32 UTC, Joakim wrote: https://play.google.com/store/apps/details?id=com.termux=en $ apt search ldc Sorting... Done Full Text Search... Done ipcalc/stable 0.41 aarch64 Calculates IP broadcast, network, Cisco wildcard mask, and host ranges ldc/stable 1.11.0 aarch64 D programming language compiler, built with LLVM http://termux.net/dists/stable/main/binary-aarch64/ You should post it, as an extra topic on announce: D on Android with Termux LDC now 32 and 64 Bit! ... Thank you - it works! I did, though not as a new topic: https://forum.dlang.org/post/zgjzldisifhkgcgxk...@forum.dlang.org I'm updating the wiki on how to use it and getting rid of the main function requirement, then I'll write up a post for Mike on the D blog.
Re: LDC 1.11.0
On Saturday, 18 August 2018 at 16:47:35 UTC, kinke wrote: Glad to announce LDC 1.11: * Based on D 2.081.2. * Prebuilt packages now using LLVM 6.0.1 and including additional cross-compilation targets (MIPS, MSP430, RISC-V and WebAssembly). * Rudimentary support for compiling & linking directly to WebAssembly. See the dedicated Wiki page [1] for how to get started. * AArch64 (64-bit ARM) now mostly working on Linux/glibc and Android. * Some support for classes without TypeInfos, for -betterC and/or a minimal (d)runtime. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.11.0 Thanks to all contributors! [1] https://wiki.dlang.org/Generating_WebAssembly_with_LDC Since this is the first ldc release with a mostly working 64-bit ARM, ie AArch64, port, I've put up ldc builds for linux/AArch64 and Android. You can get the linux build at the github link above; the Android build is available from the Termux app in the Android store, by running `pkg install ldc`: https://play.google.com/store/apps/details?id=com.termux=en You can see what else remains to be done for the AArch64 port by looking at the logs from the linux/AArch64 Shippable CI linked from the github release and the checklist in this ldc tracking issue: https://github.com/ldc-developers/ldc/issues/2153 I've added info on how to cross-compile a D runtime and standard library for linux/AArch64 to the wiki: https://wiki.dlang.org/Building_LDC_runtime_libraries#Usage_for_cross-compilation I've also started updating the wiki on how to build Android apps in D for 64-bit ARM devices.
Re: LDC 1.11.0
On Friday, 24 August 2018 at 12:21:32 UTC, Uknown wrote: On Tuesday, 21 August 2018 at 15:31:16 UTC, Joakim wrote: On Sunday, 19 August 2018 at 10:11:42 UTC, 鲜卑拓跋枫 wrote: [...] I tried looking for a RISC-V VPS or dev board recently and found basically nothing, just two boards from SiFive that are too small or too expensive. There is the SHAKTI Program by IIT Madras : http://shakti.org.in/about.html I've actually heard of it, what of it? Is someone using it in a production environment, or do they have a VPS or dev board? If not, academic projects sitting half-finished in some grad students' computers somewhere aren't relevant to my questions.
Re: LDC 1.11.0
On Thursday, 23 August 2018 at 09:51:30 UTC, Brian wrote: On Tuesday, 21 August 2018 at 15:31:16 UTC, Joakim wrote: On Sunday, 19 August 2018 at 10:11:42 UTC, 鲜卑拓跋枫 wrote: Many thanks for your effort! And hope the subsequent LDC releases with LLVM 7.0 will be mature enough on AArch64 and RISC-V for production environment. Who is actually running AArch64 or RISC-V in a "production environment?" Maybe a few for AArch64, but pretty much nobody for RISC-V. I tried looking for a RISC-V VPS or dev board recently and found basically nothing, just two boards from SiFive that are too small or too expensive. We need support AArch64 :) Why?
Re: D support for ChromeOS
On Wednesday, 22 August 2018 at 10:06:39 UTC, Joakim wrote: On Wednesday, 22 August 2018 at 07:14:22 UTC, Martin Tschierschke wrote: On Wednesday, 22 August 2018 at 01:56:45 UTC, Joakim wrote: unning. [...] Oh, I forgot, if you're running Android apps in your Chromebook, you can install the Termux app and use LDC through there: https://play.google.com/store/apps/details?id=com.termux=en The first AArch64 build of LDC for Termux should be up in a day or so, `apt install ldc`, or you can build it from source in Termux, if you can't wait. ;) +1 ; Cool, not sure if I can wait, but probably I will :-) I must say I really like looking at this version string, straight from the Termux app: $ ldc2 --version LDC - the LLVM D compiler (1.11.0): based on DMD v2.081.2 and LLVM 6.0.1-2 built with LDC - the LLVM D compiler (1.11.0) Default target: aarch64--linux-android Host CPU: cortex-a73 http://dlang.org - http://wiki.dlang.org/LDC Registered Targets: aarch64- AArch64 (little endian) aarch64_be - AArch64 (big endian) arm- ARM arm64 - ARM64 (little endian) armeb - ARM (big endian) thumb - Thumb thumbeb- Thumb (big endian) x86- 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 It's up: $ apt search ldc Sorting... Done Full Text Search... Done ipcalc/stable 0.41 aarch64 Calculates IP broadcast, network, Cisco wildcard mask, and host ranges ldc/stable 1.11.0 aarch64 D programming language compiler, built with LLVM http://termux.net/dists/stable/main/binary-aarch64/
Re: D support for ChromeOS
On Wednesday, 22 August 2018 at 07:14:22 UTC, Martin Tschierschke wrote: On Wednesday, 22 August 2018 at 01:56:45 UTC, Joakim wrote: unning. [...] Oh, I forgot, if you're running Android apps in your Chromebook, you can install the Termux app and use LDC through there: https://play.google.com/store/apps/details?id=com.termux=en The first AArch64 build of LDC for Termux should be up in a day or so, `apt install ldc`, or you can build it from source in Termux, if you can't wait. ;) +1 ; Cool, not sure if I can wait, but probably I will :-) I must say I really like looking at this version string, straight from the Termux app: $ ldc2 --version LDC - the LLVM D compiler (1.11.0): based on DMD v2.081.2 and LLVM 6.0.1-2 built with LDC - the LLVM D compiler (1.11.0) Default target: aarch64--linux-android Host CPU: cortex-a73 http://dlang.org - http://wiki.dlang.org/LDC Registered Targets: aarch64- AArch64 (little endian) aarch64_be - AArch64 (big endian) arm- ARM arm64 - ARM64 (little endian) armeb - ARM (big endian) thumb - Thumb thumbeb- Thumb (big endian) x86- 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64
Re: D support for ChromeOS
On Wednesday, 22 August 2018 at 01:48:01 UTC, Joakim wrote: On Tuesday, 21 August 2018 at 20:29:34 UTC, Emil wrote: On Saturday, 3 February 2018 at 18:11:15 UTC, Daniel Kozak wrote: [...] Tried it on an Acer Chromebook R13 running Version 69.0.3497.35 (Official Build) dev (32-bit). I have no previous experience with llvm. [...] Looks like your Chromebook's got a MediaTek AArch64 processor, ie 64-bit ARM, which wasn't supported by D until the just released LDC 1.11. I'd try building 1.11 from source, using these instructions: https://wiki.dlang.org/Building_LDC_from_source You will need a working CMake though, looks like the one you're trying to use isn't running. Oh, I forgot, if you're running Android apps in your Chromebook, you can install the Termux app and use LDC through there: https://play.google.com/store/apps/details?id=com.termux=en The first AArch64 build of LDC for Termux should be up in a day or so, `apt install ldc`, or you can build it from source in Termux, if you can't wait. ;)
Re: D support for ChromeOS
On Tuesday, 21 August 2018 at 20:29:34 UTC, Emil wrote: On Saturday, 3 February 2018 at 18:11:15 UTC, Daniel Kozak wrote: [...] Tried it on an Acer Chromebook R13 running Version 69.0.3497.35 (Official Build) dev (32-bit). I have no previous experience with llvm. [...] Looks like your Chromebook's got a MediaTek AArch64 processor, ie 64-bit ARM, which wasn't supported by D until the just released LDC 1.11. I'd try building 1.11 from source, using these instructions: https://wiki.dlang.org/Building_LDC_from_source You will need a working CMake though, looks like the one you're trying to use isn't running.
Re: LDC 1.11.0
On Sunday, 19 August 2018 at 10:11:42 UTC, 鲜卑拓跋枫 wrote: Many thanks for your effort! And hope the subsequent LDC releases with LLVM 7.0 will be mature enough on AArch64 and RISC-V for production environment. Who is actually running AArch64 or RISC-V in a "production environment?" Maybe a few for AArch64, but pretty much nobody for RISC-V. I tried looking for a RISC-V VPS or dev board recently and found basically nothing, just two boards from SiFive that are too small or too expensive.
Re: Dpp on run.dlang.io
On Saturday, 4 August 2018 at 05:06:26 UTC, Joakim wrote: On Saturday, 4 August 2018 at 02:39:23 UTC, Mike Franklin wrote: On Saturday, 4 August 2018 at 01:27:49 UTC, Laeeth Isharc wrote: Thanks to Seb and Atila it is now very easy to show a D program just #includeing C headers. If just works. Modulo bugs. In time I am hopeful Atila will start to have more of C++ headers working too. https://run.dlang.io/is/JlH3Th Cool! Can we now deprecate and eventually jettison C/C++ bindings from druntime, please? No, because dpp is new, not commonly used, and I think only works with DMD. Scratch that last part, works with LDC too: https://travis-ci.org/atilaneves/dpp
Re: Dpp on run.dlang.io
On Saturday, 4 August 2018 at 02:39:23 UTC, Mike Franklin wrote: On Saturday, 4 August 2018 at 01:27:49 UTC, Laeeth Isharc wrote: Thanks to Seb and Atila it is now very easy to show a D program just #includeing C headers. If just works. Modulo bugs. In time I am hopeful Atila will start to have more of C++ headers working too. https://run.dlang.io/is/JlH3Th Cool! Can we now deprecate and eventually jettison C/C++ bindings from druntime, please? No, because dpp is new, not commonly used, and I think only works with DMD. It might make sense to split those bindings off into their own git repo, separate from the compiled parts of druntime though.
Re: SAoC Updates
On Tuesday, 31 July 2018 at 03:23:41 UTC, Mike Parker wrote: I've updated the SAoC page to reflect the decision to accept applications from non-university students. Great! I think this will open up the pool of applicants considerably.
Re: LDC 1.11.0 beta2
On Sunday, 15 July 2018 at 19:46:24 UTC, kinke wrote: Glad to announce the second beta for LDC 1.11. * Based on D 2.081.1+ (today's DMD stable). * Prebuilt packages now using LLVM 6.0.1 and including additional cross-compilation targets (MIPS, MSP430, RISC-V and WebAssembly). * Rudimentary support for compiling & linking directly to WebAssembly. See the dedicated Wiki page [1] for how to get started. * Some support for classes without TypeInfos, for -betterC and/or a minimal (d)runtime. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.11.0-beta2 Thanks to all contributors! [1] https://wiki.dlang.org/Generating_WebAssembly_with_LDC Ldc 1.11 beta 2 is also the first ldc release with a mostly working Android/AArch64 port. In order to cross-compile the stdlib for 64-bit ARM, follow these instructions for linux/x64, adapted from the wiki page for Android/ARM (https://wiki.dlang.org/Build_D_for_Android), which require the same build tools- CMake, the Android NDK, and either Make or Ninja: export CC=/path/to/your/android-ndk-r17b/toolchains/llvm/prebuilt/linux-x86_64/bin/clang /path/to/your/ldc2-1.11.0-beta2-linux-x86_64/bin/ldc-build-runtime --ninja --targetPreset=Android-aarch64 Leave off the --ninja flag if you're using Make instead, and adjust the paths in all the commands, replacing /path/to/your/ with the correct paths on your system. This will download the ldc source into a temporary directory called ldc-build-runtime.tmp and attempt to cross-compile the stdlib for Android/AArch64, but fail with the following error: std/math.d(4320): Error: static assert: `infL > 2.0L && (infL <= 4.0L)` is false Download and apply a small workaround patch for Phobos (https://gist.github.com/joakim-noah/7b997a7f8c49ff8f9d93658f78ec3cbe) to get it to work: curl -L -O https://gist.githubusercontent.com/joakim-noah/7b997a7f8c49ff8f9d93658f78ec3cbe/raw/a7c7a2d46a679e34236f00fa9a5dee19e3b50667/compile_phobos_aarch64 git apply compile_phobos_aarch64 /path/to/your/ldc2-1.11.0-beta2-linux-x86_64/bin/ldc-build-runtime --ninja --targetPreset=Android-aarch64 --reset You can now cross-compile command-line binaries for Android/AArch64, similar to Android/ARM as shown on the wiki: export NDK=/path/to/your/android-ndk-r17b /path/to/your/ldc2-1.11.0-beta2-linux-x86_64/bin/ldc2 -mtriple=aarch64-none-linux-android -L-L/path/to/your/ldc-build-runtime.tmp/lib -Xcc=--sysroot=$NDK/platforms/android-21/arch-arm64 -Xcc=-fuse-ld=bfd -Xcc=-gcc-toolchain -Xcc=$NDK/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64 -Xcc=-target -Xcc=aarch64-none-linux-android -Xcc=-fpie -Xcc=-pie sieve.d The Phobos patch shows the remaining pieces that need to be ported, support for 128-bit real floating-point at compile-time (as that static assert tripping is likely because the 128-bit `real.max` is slightly larger than the 80-bit one and overflows to Inf) and core.stdc.stdarg.va_arg for AArch64. You can also build the stdlib test runners, after applying this druntime patch to disable a few tests that cannot be compiled (https://gist.github.com/joakim-noah/417ffbac4d6041242d3091001595981d): curl -L -O https://gist.githubusercontent.com/joakim-noah/417ffbac4d6041242d3091001595981d/raw/555d5c85f9055fe63d7c2c6a0493425a9c21edd2/disable_druntime_tests_aarch64 git apply disable_druntime_tests_aarch64 /path/to/your/ldc2-1.11.0-beta2-linux-x86_64/bin/ldc-build-runtime --ninja --targetPreset=Android-aarch64 --testrunners You can then copy the druntime-test-runner and phobos2-test-runner binaries from the ldc-build-runtime.tmp directory to the Termux app on an Android/AArch64 device to see what tests fail. In my experience, all the druntime tests pass and tests only fail for 6-7 Phobos modules, mostly related to CTFE not supporting 128-bit floating point: https://github.com/ldc-developers/ldc/issues/2153#issuecomment-379847985 The debug versions of the above test binaries (which are also built with the above command) hang when run, tripping an assert in the GC on startup, though they work fine when natively compiled with an older ldc 0.17 on an Android/AArch64 device. If you'd like to chip in on any of these remaining issues, here's a straightforward way to get started on porting D to the most widely-deployed CPU architecture used for personal computing on the planet, with almost all iOS devices and about half of Android devices now running on AArch64, billions of devices. I'll get those last few druntime tests ported next.
Re: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 07:30:26 UTC, Joakim wrote: On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ "join us" for "submit an application" -> apply (confusing otherwise) Maybe sum up and make clear that each student can earn between $3000-4000, instead of capped at $1k. This is why I suggested stating the total sum clearly: "20 hours/week for four months for a salary of $1000 seems kind of crappy. Am I reading this wrong?" https://www.reddit.com/r/programming/comments/8yram3/comment/e2gttg2 You're currently requiring people to read carefully and do the math to understand this: most people do neither.
Re: LDC 1.11.0 beta2
On Wednesday, 18 July 2018 at 01:35:11 UTC, Ali wrote: On Sunday, 15 July 2018 at 19:46:24 UTC, kinke wrote: Glad to announce the second beta for LDC 1.11. * Prebuilt packages now using LLVM 6.0.1 and including additional cross-compilation targets (MIPS, MSP430, RISC-V and WebAssembly). * Rudimentary support for compiling & linking directly to WebAssembly. See the dedicated Wiki page [1] for how to get started. [1] https://wiki.dlang.org/Generating_WebAssembly_with_LDC The WebAssembly part discussed on hackernews https://news.ycombinator.com/item?id=17546063 Second link on the front page now.
Re: Funding code-d
On Friday, 13 July 2018 at 14:20:19 UTC, Mike Parker wrote: As promised in my tweet of June 30 (and to the handful of people who emailed me), the cloud of mystery surrounding the use of the money raised for code-d and its supporting tools has now been (partially) lifted! In this post, I lay out the details of how the first $1000 will be paid out to project maintainer Jan Jurzitza, a.k.a Webfreak001, and explain what we hope to achieve with this ecosystem fundraising initiative going forward. This time around, it all came together in the background of prepping for DConf with little forethought beyond activating an Open Collective goal and then working with Jan to determine the details. Lessons were learned. Later this year, you'll see the result when we announce the next of what we hope to be an ongoing series of funding targets. In the meantime: The blog https://dlang.org/blog/2018/07/13/funding-code-d/ Reddit https://www.reddit.com/r/d_language/comments/8yka7b/funding_coded_the_d_blog/ Nice explication of the plan, really needed. Why github never rolled out such a bounty program for OSS and other public projects has to be one of the head-scratching moves of all time, no wonder they were about to run out of money before they sold. A good way to decide on future projects would be to let prospective donors stake money on various proposals, to see how much backing they might receive, sort of like how kickstarter and other crowdfunding sites work.
Re: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 13:57:12 UTC, Laeeth Isharc wrote: On Saturday, 14 July 2018 at 07:30:26 UTC, Joakim wrote: On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ "join us" for "submit an application" -> apply (confusing otherwise) Maybe sum up and make clear that each student can earn between $3000-4000, instead of capped at $1k. Why limit it to students? If the goal is to have a youth injection, just use an age limit- say 18-25- I see no reason for the stupid college bias. Hi Joakim. Thanks for suggestions. Sure, thanks for funding this worthwhile initiative. I don't know what legal aspects there are relating to targeting age in different countries. We are definitely targeting people earlier in their careers. I agree with you that talent isn't only found amongst students, and I've in the past hired someone that didn't even finish high school and has gone on to do good work for the D community. So as far as Symmetry goes we are very open to unusual talent. A degree is just one piece of interesting information. Yes, but the current requirements exclude, for example, recent college grads who may not be employed yet and might do much better work than a harried college student. I don't know the legal risks in detail, but I can't imagine the risk/reward to opening it up would favor the current limitation.
Re: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: Thanks to the sponsorship of Symmetry Investments, the D Language Foundation is happy to announce the Symmetry Autumn of Code! We're looking for three university students to hack on D this autumn, from September - January. We're also in search of potential mentors and ideas for student projects. Head to the Symmetry Autumn of Code page for the details. Spread the word! https://dlang.org/blog/symmetry-autumn-of-code/ "join us" for "submit an application" -> apply (confusing otherwise) Maybe sum up and make clear that each student can earn between $3000-4000, instead of capped at $1k. Why limit it to students? If the goal is to have a youth injection, just use an age limit- say 18-25- I see no reason for the stupid college bias.
Re: LDC 1.11.0 beta
On Saturday, 7 July 2018 at 18:26:45 UTC, Johan Engelen wrote: On Saturday, 7 July 2018 at 18:17:49 UTC, Seb wrote: Would be great to include https://github.com/dlang/dmd/pull/8456 as it's a serious regression and the reason for the early 2.081.1 release. Because the quality of new DMD releases is often subpar, the LDC release plan is to only release after a good point release of DMD (usually *.*.1, but if this is a hasty .1 release, we probably better wait until 2.081.2) -Johan In other words, this is only a beta: the final 1.11 release will be done next month, only with the final release of the DMD 2.081 frontend, likely 2.081.2.
Re: Work on ARM backend for DMD started
On Thursday, 20 July 2017 at 16:22:59 UTC, solidstate1991 wrote: On Friday, 7 July 2017 at 11:09:27 UTC, Temtaime wrote: [...] A few things you should be aware before you trash the reference compiler for D: [...] Btw, if you're still interested in this, AArch64 would be a better target, as 32-bit ARM is being replaced by it.
Re: Release D 2.081.0
On Wednesday, 4 July 2018 at 14:55:56 UTC, Mike Parker wrote: On Wednesday, 4 July 2018 at 10:03:57 UTC, Martin Nowak wrote: Glad to announce D 2.081.0. This release comes with... http://dlang.org/download.html http://dlang.org/changelog/2.081.0.html - -Martin The blog announcement: https://dlang.org/blog/2018/07/04/dmd-2-081-0-released/ "much quiter"
Re: I have a plan.. I really DO
On Sunday, 1 July 2018 at 15:40:20 UTC, Ecstatic Coder wrote:
On Sunday, 1 July 2018 at 14:01:11 UTC, Jonathan M Davis wrote:
On Sunday, July 01, 2018 13:37:32 Ecstatic Coder via
Digitalmars-d-announce wrote:
On Sunday, 1 July 2018 at 12:43:53 UTC, Johannes Loher wrote:
> Am 01.07.2018 um 14:12 schrieb Ecstatic Coder:
>> Add a 10-liner "Hello World" web server example on the
>> main page and that's it.
>
> There already is one in the examples:
>
> #!/usr/bin/env dub
> /+ dub.sdl:
> name "hello_vibed"
> dependency "vibe-d" version="~>0.8.0"
> +/
> void main()
> {
>
> import vibe.d;
> listenHTTP(":8080", (req, res) {
>
> res.writeBody("Hello, World: " ~ req.path);
>
> });
> runApplication();
>
> }
Yeah I know, guess who asked for it...
But the last step, which is including such functionality into
the standard library , will never happen, because nobody here
seems to see the point of doing this.
I guess those who made that for Go and Crystal probably did
it wrong.
What a mistake they did, and they don't even know they make a
mistake, silly them... ;)
What should and shouldn't go in the standard library for a
language is something that's up for a lot of debate and is
likely to often be a point of contention. There is no clear
right or wrong here. Languages that have had very sparse
standard libraries have done quite well, and languages that
have had kitchen sink libraries have done quite well. There
are pros and cons to both approaches.
- Jonathan M Davis
I agree.
But here I'm just talking of the "public image" of the language.
Languages which integrates HTTP-related components in their
standard library, and advertize on that (like Crystal for
instance), obviously apply a different "marketing" strategy
than languages which have chosen not to do so.
That's all I say...
Two points:
- Andrei pushed to include vibe.d but it didn't happen.
"There's no web services framework (by this time many folks know
of D, but of those a shockingly small fraction has even heard of
vibe.d). I have strongly argued with Sönke to bundle vibe.d with
dmd over one year ago, and also in this forum. There wasn't
enough interest."
https://forum.dlang.org/post/nipb14$ldb$1...@digitalmars.com
- As you acknowledge, integration has drawbacks too. I thought
this was an interesting recent article about how it has now
hobbled one of the biggest tech companies in the world:
https://stratechery.com/2018/intel-and-the-danger-of-integration/
I don't think the web matters enough these days that it is worth
bundling, which is why a webassembly port is also not worth it
for most:
https://www.mobiloud.com/blog/mobile-apps-vs-the-mobile-web/
Re: I have a plan.. I really DO
On Saturday, 30 June 2018 at 07:28:24 UTC, Ecstatic Coder wrote: On Saturday, 30 June 2018 at 07:11:18 UTC, Joakim wrote: On Saturday, 30 June 2018 at 06:52:01 UTC, Ecstatic Coder wrote: [...] I'd hope a manager would look at actually meaningful stats like downloads, rather than just fluffy stats such as "likes": http://www.somsubhra.com/github-release-stats/?username=crystal-lang=crystal http://www.somsubhra.com/github-release-stats/?username=ldc-developers=ldc I see around 9k total downloads of the various Crystal 0.24 and 0.25 versions over the last 8 months, compared to 14k downloads of the ldc 1.9 compiler alone from two months ago. Of course, all these stats can be gamed, but I think it'd be hard to argue Crystal is more popular. Obviously you haven't read my post. No problem, I'll repeat it. I said that Crystal is probably gaining popularity FASTER than D. I've never said that Crystal is more used than D. FYI, D is in the top 50 at the TIOBE index, while Crystal is only in the top 100. Of course, you will tell me that these rankings are numbers, and that a higher number means nothing. Right ? I'll tell you that all data should be carefully vetted before using it to draw conclusions. For example, I just checked and the ldc data includes a download for every CI run, which skews it upwards, but I doubt enough to change my conclusion above: https://github.com/ldc-developers/ldc/blob/master/.circleci/config.yml#L62
Re: I have a plan.. I really DO
On Saturday, 30 June 2018 at 06:52:01 UTC, Ecstatic Coder wrote: On Friday, 29 June 2018 at 22:59:25 UTC, bachmeier wrote: On Friday, 29 June 2018 at 20:13:07 UTC, Ecstatic Coder wrote: Have a look at Crystal's Github project, you will see that Crystal, still in development and quite far from its 1.0 mile version (= despite no parallism and windows support, etc) ALREADY has 11206 stars, 881 forks and 292 contributors : https://github.com/crystal-lang/crystal Not bad for a language in its 0.25 version and first released in June 2014 (4 years), especially compared to D in its 2.0 version and first released in December 2001 (16 years), whose official compiler has 1806 stars, 452 forks and 168 contributors : https://github.com/dlang/dmd If those numbers means anything, I think its that Crystal is probably getting popularity much quicker than D, and honestly, after having tried it, I think it's really deserved, even if I agree that there are still many things that remain to be implemented before it's really ready for an official "production-ready" 1.0 release. Do you by chance work as a manager? Managers like comparisons that involve one number, with a higher number being better. I don't know what can be learned about D from that comparison and I don't think anyone else does either. That's your opinion. First, most managers don't become manager by chance, but because of their skills. Like being able to take the right decisions, based on facts, not on personal preferences. For instance, if a good manager sees that the github project of a 4 years old compiler has been liked by 11206 persons, and the github project of a 16 years old compiler has been liked by 1806 persons, I think he could probably think that MUCH more people are interested in the development of the first github project than in the second. I'd hope a manager would look at actually meaningful stats like downloads, rather than just fluffy stats such as "likes": http://www.somsubhra.com/github-release-stats/?username=crystal-lang=crystal http://www.somsubhra.com/github-release-stats/?username=ldc-developers=ldc I see around 9k total downloads of the various Crystal 0.24 and 0.25 versions over the last 8 months, compared to 14k downloads of the ldc 1.9 compiler alone from two months ago. Of course, all these stats can be gamed, but I think it'd be hard to argue Crystal is more popular.
Re: I have a plan.. I really DO
On Friday, 29 June 2018 at 22:54:34 UTC, bachmeier wrote: On Friday, 29 June 2018 at 07:03:52 UTC, Dmitry Olshansky wrote: P.S. I mean what you think the future of native code is??? Rust? Crystal?? Nim??? The future of native code will be replacing scripting languages. D is really good at that task. This will never happen, doesn't matter how good D is at it, they will always be better because they sacrifice performance for ease of use. The future of native code will not be one language. I don't know why the discussion always turns to that, because it goes against the steady increase in the number of good languages that are available. Different folks have different preferences, many of us use multiple languages, and our preferences change over our lifetimes. These days language interoperability is getting so good that "choosing a language" is becoming obsolete. If we keep reducing the obstacles to using D, the number of users will continue to grow. Yep, agreed. WRT donating money, isn't it natural to explain what will be done with the money? There's been some movement in the direction of transparency. I'll only say there's more to be done in that area and leave it at that. Let me echo this: transparency has historically been a big problem for D. AFAIK, nobody in the broader community was ever told that the D foundation money would be used to fund a bunch of Romanian interns, it just happened. In the end, it appears to have worked out great, but why would anybody donate without being given transparency on where the money was going in the first place, when it could have ended badly? I understand Andrei had connections with that Romanian university, but some donor might have had connections with a Brazilian or Chinese university that might have worked out even better. We'll never explore such connections and alternatives without transparency. The current move to fund some IDE work with Opencollective is better in that regard, but with no concrete details on what it entails, not significantly better: https://forum.dlang.org/post/pxwxhhbuburvddnha...@forum.dlang.org Anyway, I don't use such IDEs, so not a reason for me to donate anyway. Honestly, Dmitry's posts starting this thread are incoherent, I'm not sure what he was trying to say. If he feels D users should be donating much more, he and others need to make clear how that money will be spent.
Re: docker images
On Friday, 29 June 2018 at 06:13:53 UTC, Anton Fediushin wrote: On Friday, 29 June 2018 at 04:51:49 UTC, Joakim wrote: On Thursday, 28 June 2018 at 17:54:45 UTC, Radu wrote: [...] Note that there is also an Alpine container with LDC, should be useful for building D microservices: https://hub.docker.com/r/andrewbenton/alpine-ldc/ It would be so nice if I knew about this image earlier. I ended up making my own minimal image for LDC with OpenSSL 1.1 and goinsu for privilege lowering. https://hub.docker.com/r/ohboi/minildc/ It's 153MiB, which is just 53MiB bigger than alpine-based image. I think I did a pretty good job there, most importantly there aren't any problems with musl libc, since it's based on debian-slim. Yet still I don't really use this image - LDC has some problems compiling my vibe.d applications. For every CI build I use my other image: https://hub.docker.com/r/ohboi/minidmd/ Which is the same thing, but with DMD instead. It's even smaller, only 91MiB. Try out the Alpine image and see if it doesn't have the same issue with vibe-d. Also, if you report your problem with ldc here, preferably with a reduced sample, someone will take a look: https://github.com/ldc-developers/ldc/issues
Re: docker images
On Thursday, 28 June 2018 at 17:54:45 UTC, Radu wrote: Created a couple of docker images useful for dlang dev. LDC cross compiler for ARM - https://hub.docker.com/r/rracariu/ldc-linux-armhf/ This image allows one to easily cross compile to ARM. Main use-case is continuous integration servers. - https://hub.docker.com/r/rracariu/dub-registry/ Allows easily running a private dub repository on cloud. Note that there is also an Alpine container with LDC, should be useful for building D microservices: https://hub.docker.com/r/andrewbenton/alpine-ldc/
Re: How an Engineering Company Chose to Migrate to D
On Wednesday, 20 June 2018 at 13:21:30 UTC, Mike Parker wrote: If you saw Bastiaan Veelo's DConf 2017 presentation, you'll know that his employer was evaluating D as a candidate for migrating their code base away from Extended Pascal. Recently, the decision was made and D was the coice. In this post, Bastiaan tells the story of how that came to be and how they'll be moving forward. The blog: https://dlang.org/blog/2018/06/20/how-an-engineering-company-chose-to-migrate-to-d/ "that's were" -> that's where The code example for the string80 alias has a closing HTML code tag leaked into the displayed example somehow.
Re: LDC 1.10.0
On Wednesday, 20 June 2018 at 09:11:32 UTC, Russel Winder wrote: Great to see LDC being as up to date with DMD as possible quickly. Sadly due to a Phobos bug, I need D 2.081.0 :-( It is very easy to build ldc from source, I do it all the time, even on my Android tablet or smartphone: https://wiki.dlang.org/Building_LDC_from_source If you're waiting on a Phobos fix, you can always backport it to LDC 1.10 and build it yourself. You can also try out the WIP pull for the next release, available on its own branch, particularly if you're on linux where it's mostly working: https://github.com/ldc-developers/ldc/pull/2752
Re: LDC 1.10.0
On Tuesday, 19 June 2018 at 22:10:38 UTC, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce LDC 1.10. The highlights of this version in a nutshell: * Based on D 2.080.1. * Win64: Breaking ABI change by passing vectors efficiently in registers. * Config file extensions for cross-compilation. * Support for DragonFly BSD. * Various fixes, most notably wrt. exception stack traces on Linux. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.10.0 Thanks to all contributors! Nice work, LDC has caught up to the latest DMD version, and that's with the much faster DMD release cycle since last year, good to see.
Re: D only has Advantages
On Friday, 15 June 2018 at 04:19:22 UTC, Tony wrote: On Friday, 15 June 2018 at 02:17:26 UTC, Adam D. Ruppe wrote: On Friday, 15 June 2018 at 02:02:52 UTC, Tony wrote: Have their been other languages - besides D - that compiled to object code and used a garbage collector? You can use a GC with C++ and you can compile Java to native code ahead of time. The distinctions aren't really that sharp, it just depends on how you use it. After I posted I wanted to edit it to add "disregarding JIT in conjunction with a VM like JVM or .NET". Have there been any C++ compilers that used a garbage collector? What I was getting at was, if someone says "I've got a systems level project I want to play around with, however GC is not a deal breaker for me. ", it seems like they are making an implied reference to D as I assume "systems level" means "compile to object code and link with linker to executable". Search this forum or HN for Paulo and Oberon, you'll find plenty of posts like this, where he lists all of them: :) https://forum.dlang.org/post/mioycakymbdpzryme...@forum.dlang.org
[OT]: companies
On Thursday, 14 June 2018 at 20:59:06 UTC, Jonathan M Davis wrote: On Thursday, June 14, 2018 16:04:32 Nick Sabalausky via Digitalmars-d- announce wrote: On 06/14/2018 05:01 AM, AnotherTorUser wrote: > If all such people stopped working for such companies, what > do you think the economic impact would be? What do you think is the social impact if they don't? And don't even try to pretend the companies can't trivially solve the "economic" issues for themselves in an instant by knocking off the behaviour that causes loss of talent. But that would imply that they have a frontal lobe. :) In all seriousness, it is surprising how frequently companies seem to be incapable of making decisions that would fix a lot of their problems, and they seem to be incredibly prone to thinking about things in a shortsighted manner. I'm reminded of an article by Joel Spoelskey where he talks about how one of the key things that a source control software solution can do to make it more likely for folks to be willing to try it is to make it easy to get your source code and history back out again and into another source control system. However, companies typically freak out at the idea of making it easy to switch from their product to another product. They're quite willing to make it easy to switch _to_ their product so that they can start making money off of you, but the idea that making it low cost to leave could actually improve the odds of someone trying their product - and thus increase their profits - seems to be beyond them. Another case which is closer to the exact topic at hand is that many companies seem to forget how much it costs to hire someone when they consider what they should do to make it so that their employees are willing - or even eager - to stay. Spending more money on current employees (be that on salary or something else to make the workplace desirable) or avoiding practices that tick employees off so that they leave can often save money in the long run, but companies frequently ignore that fact. They're usually more interested in saving on the bottom line right now than making decisions that save money over time. So, while I completely agree that companies can technically make decisions that solve some of their problems with things like retaining talent, it seems like it's frequently the case that they're simply incapable of doing it in practice - though YMMV; some companies are better about it than others. This was an interesting read on that topic, which I've linked on this forum before, where an engineer points out that companies would be better off not chasing "rockstars" with hot keywords on their resumes but improving their training, processes, and culture so that even average programmers can be productive, including mentioning using source control and the Joel test that you just referenced: https://danluu.com/programmer-moneyball/ Of course, the reason companies mostly don't do it is they're prone to the same cognitive failings as anybody else: it's easier to chase a quick fix than doing the hard work of putting in a system like this.
Re: Encouraging preliminary results implementing memcpy in D
On Thursday, 14 June 2018 at 02:32:51 UTC, errExit wrote:
On Wednesday, 13 June 2018 at 17:04:11 UTC, Ali Çehreli wrote:
I am part of the D community. I haven't discriminated against
anyone. I don't know what a Tor user is.
I've just searched: So Tor is an old idea of mine,
implemented. :o)
Ali
Tor is our last line of defence against an Orson Wells future,
where everyones actions are scrutinized by big brother, so that
big brother can use that knowledge to put fear into, control
and manipulate, those that don't conform.
assert("bad tor user" != "all tor users are bad");
(actually there are more bad non-tor users)
Unfortunately, it's becoming increasingly, the norm, to
discriminate against tor users (no doubt those doing that
discrimination are those that are happy to conform, of which
there will be many, sadly).
https://people.torproject.org/~lunar/20160331-CloudFlare_Fact_Sheet.pdf
Tor is merely one tool used to route around those building
centralized systems on top of the internet. The real solution is
that as more and more decentralized tech does well, like git or
cryptocurrencies, to get rid of these obsolete centralized
systems altogether.
Re: DasBetterC: Converting make.c to D
On Monday, 11 June 2018 at 14:21:20 UTC, Mike Parker wrote: Walter's latest post on -betterC is now on the blog. Here, he shows step-by-step an example of using -betterC to convert a real-world program, one small enough to describe in a blog post, from C to D. The blog: https://dlang.org/blog/2018/06/11/dasbetterc-converting-make-c-to-d/ Reddit: https://www.reddit.com/r/programming/comments/8q9u5t/dasbetterc_converting_makec_to_d/ The example for replacing grouping together multiple pointer declarations has some raw HTML leaked into it, at least for me in Chrome.
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 20:00:45 UTC, Maksim Fomin wrote: On Monday, 4 June 2018 at 19:26:23 UTC, Joakim wrote: On Monday, 4 June 2018 at 19:06:52 UTC, Maksim Fomin wrote: Unlikely, you don't spend $7.5 billion on a company because you want to send a message that you're a good dev tools company, then neglect it. You have no idea about how big corporations' management spends money. As with Nokia and Skype - I don't know whether it was initially a plan to destroy products or management was just silly. I suggest you look at their online slides linked from the Nadella blog post to see their stated plan, such as integrating github into VS Code more: http://aka.ms/ms06042018 and likely vastly overpaid for an unprofitable company in the first place :) this is exactly how such deals are done - paying $7.5 bl. for nonprofitable company. Unfortunately, their books are unavailable because they are private company, but scarce information in the web suggests that in most of their years they have losses. Just as rough estimate: to support $7.5 bl valuation Microsoft must turn -$30 ml. net loss company into business generating around $750 ml. for many years. There is no way to get these money from the market. Alternatively, the project can have payoff if something is broken and Microsoft cash flows increase by $750 ml. This is more likely... but they emphasize that they intend to keep github open and independent. They can claim anything which suits best their interests right now. Or, as alternative, github can be broken in a such way, that their promises on surface are kept. Business is badly compatible with opensource by design. I just finished reading this interesting article by a former Microsoft business guy, which makes the same point I did, that MS is unlikely to neglect github or otherwise force it in some direction to leverage it: https://stratechery.com/2018/the-cost-of-developers/ You're right that MS has had many acquisitions go badly already, such as Nokia and Skype (though I'd argue both were long-term doomed before they were bought), but, as always, incompetence is the much more likely reason than malice.
Re: GitHub could be acquired by Microsoft
On Thursday, 7 June 2018 at 19:02:31 UTC, Russel Winder wrote: On Thu, 2018-06-07 at 10:17 -0700, H. S. Teoh via Digitalmars-d-announce wrote: […] Exactly!!! Git was built precisely for decentralized, distributed development. Anyone should be (and is, if they bothered to put just a tiny amount of effort into it) able to set up a git server and send the URL to prospective collaborators. Anyone is free to clone the git repo and redistribute that clone to anyone else. Anyone can create new commits in a local clone and send the URL to another collaborator who can pull the commits. It should never have become the tool to build walled gardens that inhibit this free sharing of code. I think there is an interesting tension between using a DVCS as a DVCS and no central resource, and thus no mainline version, and using a DVCS in combination with a central resource. In the latter category the central resource may just be the repository acting as the mainline, or, as with GitHub, GitLab, Launchpad, the central resource provides sharing and reviewing support. Very few organisations, except perhaps those that use Fossil, actually use DVCS as a DVCS. Everyone seems to want a public mainline version: the repository that represents the official state of the project. It seems the world is not capable of working with a DVCS system that does not even support "eventually consistent". Perhaps because of lack of trying or perhaps because the idea of the mainline version of a project is important to projects. Well, as Jonathan says, you have to release a build eventually, and you need a mainline version that you know has all the needed commits to release from. If you have multiple people all releasing their own builds with each build getting a roughly equivalent number of downloads, then a mainline version may not be needed, but I know of no large project like that. In the past Gnome, Debian, GStreamer, and many others have had a central mainline Git repository and everything was handled as DVCS, with emailed patches. They tended not to support using remotes and merges via that route, not entirely sure why. GitHub and GitLab supported forking, issues, pull requests, and CI. So many people have found this useful. Not just for having ready made CI on PRs, but because there was a central place that lots of projects were at, there was lots of serendipitous contribution. Gnome, Debian, and GStreamer are moving to private GitLab instances. It seems the use of a bare Git repository is not as appealing to these projects as having the support of a centralised system. Nobody uses a DVCS alone, even the linux kernel guys have mailing lists and other software they use to coordinate with around git. I think that whilst there are many technical reasons for having an element of process support at the mainline location favouring the GitHubs and GitLabs of this Gitty world, a lot of it is about the people and the social system: there is a sense of belonging, a sense of accessibility, and being able to contribute more easily. There is some of that, but you could reproduce all of that in a technically decentralized manner. One of the aspects of the total DVCS is that it can exclude, it is in itself a walled garden, you have to be in the clique to even know the activity is happening. Right now, yes, mailing lists and bugzilla can be forbidding to the noob, compared to just signing up on github and getting everything at one go. But as Basile's link above points out, there are tools like git-ssb that try decentralize all that: http://git-ssb.celehner.com/%25RPKzL382v2fAia5HuDNHD5kkFdlP7bGvXQApSXqOBwc%3D.sha256 All of this is not just technical, it is socio-technical. It is all ultimately technical, but yes, social elements come into play. One big thing that web software like github or trac helps with is reviewing pulls to the main repo. I'm not about to add dozens of remotes to my local repo to review pulls from all the contributors to dmd/druntime/phobos, the github pull review workflow is much easier than the git command-line equivalent. However, it wouldn't be that hard to decentralize most of what github provides by coming up with a standard format to store issues and other discussion in a git repo, as I'm guessing git-ssb does. The only aspect that might present difficulty is that you may not get as nice a web viewer as github provided, as the built-in gitweb is not very good compared to github's web UI. In that way, while many are complaining about using github, the OSS community doing so for all these years may have been optimal, in that as long as a money-losing company was willing to do that work for you for years, why not use it? Where was all that money being lost after all, if not on providing features to users who weren't paying enough to sustain it? Then, once you know whether github's business model works or not, apparently
Re: SecureD moving to GitLab
On Tuesday, 5 June 2018 at 06:45:48 UTC, Adam Wilson wrote: Hello Fellow D'ers, As some of you know I work for Microsoft. And as a result of the recent acquisition of GitHub by Microsoft, I have decided, out of an abundance of caution, to move all of my projects that currently reside on GitHub to GitLab. [...] This reads like a joke, why would it matter if you contributed to open source projects on an open platform that your employer runs?
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 19:06:52 UTC, Maksim Fomin wrote: On Monday, 4 June 2018 at 08:42:08 UTC, Walter Bright wrote: On 6/3/2018 8:51 PM, Anton Fediushin wrote: This is still just a rumour, we'll know the truth on Monday (which is today). We'll stay on Github as long as it continues to serve our interests, which it has done very well, and I have no reason to believe will change. We have a number of ties to Microsoft: 1. It's just down the street. 2. Many D users work at Microsoft. 3. Microsoft has always been helpful and supportive of Digital Mars, note the files licensed from Microsoft in the distribution. 4. Microsoft has invited myself and Andrei to speak at Microsoft from time to time. 5. Microsoft hosts the nwcpp.org meetings, which provide a venue for me to try out D presentations to a friendly crowd. 6. Microsoft has been generous with helping me solve some vexing compatibility problems from time to time. OK, so Digital Mars is in good relationship with Microsoft (I am surprised because have never heard about it). However, judging by Microsoft acqusition experience my prediction is that github will slowly but surely degradate (as suggested on some forums, everything will be firstly switched to Microsoft account - to track data, then everything will be mangled by ads, then some features deemed unnecessary by Microsoft will be removed, then linux will be badly supoorted, then some features incompatible with Microsoft services will stop working, then servers will start work poorly like skype...). P.S. My second reaction after reading news (after shock) was to visit D forum. Unlikely, you don't spend $7.5 billion on a company because you want to send a message that you're a good dev tools company, then neglect it. I suggest you look at their online slides linked from the Nadella blog post to see their stated plan, such as integrating github into VS Code more: http://aka.ms/ms06042018 Of course, this is Microsoft: they probably won't execute that plan well, and likely vastly overpaid for an unprofitable company in the first place, but they emphasize that they intend to keep github open and independent.
Re: GitHub could be acquired by Microsoft
On Monday, 4 June 2018 at 09:47:58 UTC, Anton Fediushin wrote: Oh look, rumours are confirmed: https://itsfoss.com/microsoft-github/ MS bought GitHub for $5 billion. It's official, Nat Friedman, formerly of Xamarin, is the new CEO: https://blog.github.com/2018-06-04-github-microsoft/ MS is basically selling a story to Wall Street, "Everything new we tried since Windows and Office has failed abysmally, so we've learned our lesson and will be the business software company from now on," hence buying LinkedIn, pushing Azure, and now buying Github. I don't expect this new management direction to go any better.
