Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 06:20:33 UTC, Joakim wrote: Eh, there were always the BSDs and essentially nobody runs GNU code today. Uhm... Many do. And beyond GNU, the GPL/LGPL are the most common licenses in community driven open source productivity applications: Gimp, Inkscape, Blender, Audacity... My point is that people see the success of open source and his early role as a vocal proponent and assume he was "critical," when the truth is more complicated, as his extreme formulation of completely "free software" has not done that well. It has not done well with corporations, but it has done very well with open source end-user software! Even projects that are not GPL tend to use LGPL code. Yet, Linux did manage to scare the juggernauts, so now even Microsoft is starting to publish under liberal licenses (first very restrictive, now very liberal). This is why you should generally only work on something you actually need, which is a great discipline. Even if it's rejected, you can code it up and use it yourself, though that's not always possible with certain language changes and DIPs. Well, yes. Unless you are designing a standard library. The original open source projects were mostly about recreating existing designs, but with a open source license. So the missing features were obvious. In the case of GNU (Unix), it is a cluster of individual small programs. So if people was unhappy they wrote a new version from scratch. And the most popular ones survived. Creative designs that went open source tended to be research projects... so you had a clear vision (and people who were experts in their field leading the design). So, the linked rant is pretty clueless IMO. You need to form consensus in order to gain focus. If you don't have focus you'll never end up with something coherent. If the author believed in what he wrote, then why did he write it? He obviously wrote it because he believe that communication can lead to change. And thereby he undermines his own argument... What brought original FOSS projects focus was the fact that they were not implementing original designs. And there has been LOTS of advocacy and arguments on usenet about every creek and cranny in software... since way before the Internet existed. So, it was an entertaining rant... and nothing more. For example, I asked about ARM and mobile support for D in 2011, noting that mobile was starting to take off and that people had been asking for ARM support periodically for years even prior to that. I was told it was one of many priorities, but nobody knew when it'd be worked on. Yes, and this is all good, but it is not a language issue. It fits well with what makes contributing to GNU/Unix easy. You can write an isolated piece. While this is not generalizable for all D PRs, ie nobody wants to maintain a fork of certain language features, it is for Several people have created their own languages because they have given up on the D development process... for dmd. Caring enough about a change to code it yourself is a good test for whether it is worth doing, which is one point the original post alludes to. Writing code without a fork, when you know it will be rejected, is pointless. Spending days or weeks on a DIP, in order to have it dismissed by a "nice technical DIP, but does not fit with our vision", is very wasteful. So people create their own languages instead, but without building consensus, meaning they end up in an incomplete state or being to close to D, having a different set of issues. Which is a key aspect of D's problem too, it is too close to C++ to not be compared to it. So fixing some issues and introducing others isn't good enough for adoption. Building consensus is very important. Just take a look at politics. Communicating a clear vision and a believable path to implementation is essential. And listening. Good leaders are always very good at listening, IMO.
Re: Wannabe contributor frustrations
Dne 11.2.2016 v 08:23 Jonathan M Davis via Digitalmars-d napsal(a): On Thursday, 11 February 2016 at 06:57:39 UTC, Daniel Kozak wrote: Dne 11.2.2016 v 01:20 Adam D. Ruppe via Digitalmars-d napsal(a): IMO it is a denial of reality to put them in three separate repositories since they are so strongly coupled in practice - their makefiles reference each other! Yes, this is the main reason why I does not do dmd and druntime development much often. I really hate when I try to bisect regressions. That's what digger is for: https://github.com/CyberShadow/Digger But yes, having everything in one repo would make some things easier. - Jonathan M Davis Yeah I know it there is a some tool, but I can not find it last time. I just find dustmite and dvm. Thanks :)
Re: Wannabe contributor frustrations
On Thursday, 11 February 2016 at 06:57:39 UTC, Daniel Kozak wrote: Dne 11.2.2016 v 01:20 Adam D. Ruppe via Digitalmars-d napsal(a): IMO it is a denial of reality to put them in three separate repositories since they are so strongly coupled in practice - their makefiles reference each other! Yes, this is the main reason why I does not do dmd and druntime development much often. I really hate when I try to bisect regressions. That's what digger is for: https://github.com/CyberShadow/Digger But yes, having everything in one repo would make some things easier. - Jonathan M Davis
Re: Wannabe contributor frustrations
Dne 11.2.2016 v 05:52 Walter Bright via Digitalmars-d napsal(a): On 2/10/2016 6:07 PM, Etienne wrote: It took me way more than 2 hours to grasp how this build process works. It wasn't until I had read through the whole source code actually. These are opportunities to improve things. If you could issue PRs to improve the documentation at the pain points, it'll help the next traveler. Or at least open a bugzilla issue for it. Documentation is only one part of problem. Every time when I want to contribute to D(dmd, druntime + phobos) it takes hours(days) of persuasion of myself. Adding some new feature or fix something new is generaly easy (still it is useless hard), but when I want to find out regression it is really annoying and I often give up.
Re: Wannabe contributor frustrations
Dne 11.2.2016 v 05:37 Jonathan M Davis via Digitalmars-d napsal(a): On Thursday, 11 February 2016 at 02:07:54 UTC, Etienne wrote: On Wednesday, 10 February 2016 at 23:30:03 UTC, Márcio Martins wrote: My expectation was that given I followed the official "tutorial" closely, everything was going to just work, instead I spent about 2 hours on this and got nowhere... It took me way more than 2 hours to grasp how this build process works. It wasn't until I had read through the whole source code actually. ... Personally, I'd love to see it changed to something more maintainable, but we'd have to be sure that what we were switching to really was better. I think that anything would be better than what we have now :) - Jonathan M Davis
Re: Wannabe contributor frustrations
Dne 11.2.2016 v 01:20 Adam D. Ruppe via Digitalmars-d napsal(a): On Wednesday, 10 February 2016 at 23:30:03 UTC, Márcio Martins wrote: I did my changes to druntime, rebuilt with make -f posix.mak You really need to build all three together to see changes effectively... IMO it is a denial of reality to put them in three separate repositories since they are so strongly coupled in practice - their makefiles reference each other! Yes, this is the main reason why I does not do dmd and druntime development much often. I really hate when I try to bisect regressions. Separate repositories make this really annoying. This is one of thing where gdc developers makes better than ldc.
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 06:20:33 UTC, Joakim wrote: On Thursday, 11 February 2016 at 05:31:54 UTC, tsbockman wrote: As of today, the "Study" group for safe reference-counting doesn't appear to be going much of anywhere, because Walter and Andrei have rejected the DIP69 approach without having a real alternative in hand. (DIP77 seems better than nothing to me, but has not been well-received by those in the community who are most invested in, and most knowledgeable of, memory management issues.) I'll note that not knowing a better solution doesn't mean one must simply accept the solution at hand, especially if that temporary solution will be difficult to unwind later. Sometimes you simply need more time to come up with something better. It all depends on the scale of the project and the suitability of the solution presented; you cannot simply say that "some" solution is better than nothing, as the original quoted post does. But yeah, maybe the reasons for rejection can be communicated better. Although I realize it might sound like I am, I'm not really criticizing either side in this. I don't really know whether either DIP69 or DIP77 actually represents a reasonable solution to the problem; as I said, I am unqualified to make that determination. I was simply giving my impression of where the discussion stands at the moment. I am certainly not advocating that DIP77 be implemented over the objections of so many of the people in the community who *are* qualified. In the spirit of the original post, perhaps what is needed is simply for someone to fork DMD and implement DIP69, so that people can actually try it instead of just imagining it. That's a lot of time and effort to invest though, knowing that your work will most likely be rejected for purely subjective reasons. This is why you should generally only work on something you actually need, which is a great discipline. Even if it's rejected, you can code it up and use it yourself, though that's not always possible with certain language changes and DIPs. Definitely. For example, I asked about ARM and mobile support for D [...] Your efforts are appreciated! I don't know if anyone else is using your work *yet*, but give it time and I'm confident that they will. ARM and Android are very important platforms.
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 06:01:29 UTC, Laeeth Isharc wrote: Beyond my pay grade, but looks to me like study group is devoted to just this kind of question It's not just devoted to this *kind* of question - it's devoted to this *exact* question. It was formed explicitly for the purpose of trying to work out an acceptable solution to the reference-counting safety problem. and in response to observation that this is something very important to get right and very difficult the discussion is beginning "Starting over" or maybe even "sidetracking" would be more accurate - quite a lot of other stuff got posted in the study group before the RCString thing came up. No consensus was emerging, hence the reset. with a simpler but important (there were some stats on chrome that were quite shocking) problem of how to do RC strings. If there's one area where you shouldn't just accept patches this surely must be it ! True. It's a hard problem, especially since they're shooting for making safe RC a non-breaking change. And I don't see the people that are grumbling participating in the study group... ? But some of them are. The grumbling over RC is a reflection of how hard the problem is to solve, not a collective unwillingness to contribute code on the part of either side.
Game Character Animation Services using 3d softwares
With the help of 3D softwares GameYan Design 3D contents Like Charactr, Animal, Vehicle, Weapon etc.We Also Provide Game Character Animations, Modeling, Lighting , Shading and Many More Services. http://www.gameyan.com/
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 04:27:43 UTC, Laeeth Isharc wrote: Joakim: "Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus." No - I think he used Stallman as an example of someone who although he whined a lot actually did a hell of a lot of work even so and became the change in the world he wanted. In my view productivity isn't about how many projects you don't manage to finish, but how many you do get done, and I am not sure I am in a position to criticize Stallman from that perspective He got some stuff done, which I alluded to, but his big project to build an OS on which to run his tools didn't. even if his ideological approach isn't entirely my cup of tea, I do recognize he played a critical role there that was necessary. Eh, there were always the BSDs and essentially nobody runs GNU code today. Android, that big open-source success, comes with almost no GNU code, just the linux kernel from Linus and company and a bunch of Apache-licensed code. A lot of the BSD guys went to work at Apple, where they have now spread the permissively-licensed Darwin base of OS X and iOS to more than a billion devices, along with llvm and other permissively-licensed projects. Stallman's GNU/GPL effort has largely failed, so he was clearly neither critical nor necessary. Was he important, as a vocal proponent of FOSS early on? Perhaps, but things would likely have progressed this way regardless, as his extremist, quasi-religious preaching of "free software" is largely dying out. That religious fervor may even have hurt as much as it helped early on, as that collaborative model only really took off after the more business-friendly rebranding as "open source," which has also led to a move to more permissive licenses, ie not the GPL. My point is that people see the success of open source and his early role as a vocal proponent and assume he was "critical," when the truth is more complicated, as his extreme formulation of completely "free software" has not done that well. On Thursday, 11 February 2016 at 05:31:54 UTC, tsbockman wrote: So, I'm not necessarily saying that it should have been accepted - but I can definitely understand how frustrating it is for those who worked on it over the course of several months to have it rejected (as far as I can tell) simply because it is "too complicated". This is non-constructive in the sense that it is a subjective judgment which does not point the way to a better solution. As of today, the "Study" group for safe reference-counting doesn't appear to be going much of anywhere, because Walter and Andrei have rejected the DIP69 approach without having a real alternative in hand. (DIP77 seems better than nothing to me, but has not been well-received by those in the community who are most invested in, and most knowledgeable of, memory management issues.) I'll note that not knowing a better solution doesn't mean one must simply accept the solution at hand, especially if that temporary solution will be difficult to unwind later. Sometimes you simply need more time to come up with something better. It all depends on the scale of the project and the suitability of the solution presented; you cannot simply say that "some" solution is better than nothing, as the original quoted post does. But yeah, maybe the reasons for rejection can be communicated better. In the spirit of the original post, perhaps what is needed is simply for someone to fork DMD and implement DIP69, so that people can actually try it instead of just imagining it. That's a lot of time and effort to invest though, knowing that your work will most likely be rejected for purely subjective reasons. This is why you should generally only work on something you actually need, which is a great discipline. Even if it's rejected, you can code it up and use it yourself, though that's not always possible with certain language changes and DIPs. For example, I asked about ARM and mobile support for D in 2011, noting that mobile was starting to take off and that people had been asking for ARM support periodically for years even prior to that. I was told it was one of many priorities, but nobody knew when it'd be worked on. Two years later, seeing mobile still hadn't been done (though others had gotten ldc/gdc working on linux/ARM to some extent), I took it up and, along with Dan, alpha releases for iOS and Android are now listed on the main download page. It doesn't matter to me if nobody here uses D on mobile- though I certainly think that would be a huge missed opportunity- as _I_ want to use D on Android and now I can. While this is not generalizable for all D PRs, ie nobody wants to maintain a fork of certain language featu
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 05:31:54 UTC, tsbockman wrote: On Thursday, 11 February 2016 at 04:59:16 UTC, Laeeth Isharc wrote: On Thursday, 11 February 2016 at 04:54:15 UTC, tsbockman wrote: True. Just pointing out that for certain recurring issues, the reason that people have fallen back to grumbling is because some DIPs *did* get written, but were rejected for vague, non-constructive reasons, with no (workable) alternative being offered. Which ones, out if interest ? And in your opinion were they thought through ? Specifically, DIP69 and its predecessors, which propose a Rust-inspired lifetime and escape analysis system as a solution to many of D's memory model woes. It seemed (and still seems) like a good solution to me, but I recognize that I am insufficiently experienced and knowledgeable in the relevant areas to deserve a vote in the matter. So, I'm not necessarily saying that it should have been accepted - but I can definitely understand how frustrating it is for those who worked on it over the course of several months to have it rejected (as far as I can tell) simply because it is "too complicated". This is non-constructive in the sense that it is a subjective judgment which does not point the way to a better solution. As of today, the "Study" group for safe reference-counting doesn't appear to be going much of anywhere, because Walter and Andrei have rejected the DIP69 approach without having a real alternative in hand. (DIP77 seems better than nothing to me, but has not been well-received by those in the community who are most invested in, and most knowledgeable of, memory management issues.) In the spirit of the original post, perhaps what is needed is simply for someone to fork DMD and implement DIP69, so that people can actually try it instead of just imagining it. That's a lot of time and effort to invest though, knowing that your work will most likely be rejected for purely subjective reasons. Beyond my pay grade, but looks to me like study group is devoted to just this kind of question and in response to observation that this is something very important to get right and very difficult the discussion is beginning with a simpler but important (there were some stats on chrome that were quite shocking) problem of how to do RC strings. If there's one area where you shouldn't just accept patches this surely must be it ! And I don't see the people that are grumbling participating in the study group...
Re: DMD compilation speed
On Thursday, 11 February 2016 at 05:38:54 UTC, Andrew Godfrey wrote: I just upgraded from DMD 2.065.0 (so about 2 years old) to 2.070.0, and noticed a difference in compilation speed. I'll detail what I see, in case it's interesting, but really I just want to ask: What should I expect? I know that DMD is now selfhosting, and I know there's a tradeoff between compilation speed and speed of generated code. Or maybe it's just a tweak to default compiler options. So maybe this is completely known. [...] I don't think it's unexpected, though something to work on beating back.
DMD compilation speed
I just upgraded from DMD 2.065.0 (so about 2 years old) to 2.070.0, and noticed a difference in compilation speed. I'll detail what I see, in case it's interesting, but really I just want to ask: What should I expect? I know that DMD is now selfhosting, and I know there's a tradeoff between compilation speed and speed of generated code. Or maybe it's just a tweak to default compiler options. So maybe this is completely known. What I see: DMD 32 running on Windows 10, on my laptop that's quite a few years old. Random tiny single-file .d program; I'm looking at what happens when I make a change and then run the program (with or without "-unittest"). On 2.065.0: This takes around 1.9 seconds. On 2.070.0: This takes around 3.6 seconds. I really don't want to trigger an investigation if this is just an anomaly - I'm still quite happy with 4 seconds to compile and run unit tests. I mainly mention it in case it's an interesting surprise.
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 04:59:16 UTC, Laeeth Isharc wrote: On Thursday, 11 February 2016 at 04:54:15 UTC, tsbockman wrote: True. Just pointing out that for certain recurring issues, the reason that people have fallen back to grumbling is because some DIPs *did* get written, but were rejected for vague, non-constructive reasons, with no (workable) alternative being offered. Which ones, out if interest ? And in your opinion were they thought through ? Specifically, DIP69 and its predecessors, which propose a Rust-inspired lifetime and escape analysis system as a solution to many of D's memory model woes. It seemed (and still seems) like a good solution to me, but I recognize that I am insufficiently experienced and knowledgeable in the relevant areas to deserve a vote in the matter. So, I'm not necessarily saying that it should have been accepted - but I can definitely understand how frustrating it is for those who worked on it over the course of several months to have it rejected (as far as I can tell) simply because it is "too complicated". This is non-constructive in the sense that it is a subjective judgment which does not point the way to a better solution. As of today, the "Study" group for safe reference-counting doesn't appear to be going much of anywhere, because Walter and Andrei have rejected the DIP69 approach without having a real alternative in hand. (DIP77 seems better than nothing to me, but has not been well-received by those in the community who are most invested in, and most knowledgeable of, memory management issues.) In the spirit of the original post, perhaps what is needed is simply for someone to fork DMD and implement DIP69, so that people can actually try it instead of just imagining it. That's a lot of time and effort to invest though, knowing that your work will most likely be rejected for purely subjective reasons.
Re: Wannabe contributor frustrations
On Thursday, 11 February 2016 at 04:37:39 UTC, Jonathan M Davis wrote: And building the documentation is that much worse. I'm fixing that at least! My docs: http://dpldocs.info/experimental-docs/std.stdio.html are built with a single simple command: docs path/to/phobos done. No need to install several repos of crap.
Re: Wannabe contributor frustrations
On Thursday, 11 February 2016 at 04:48:31 UTC, Laeeth Isharc wrote: (and as Ray Charles said, everything is easy when you know how to do it). Not the case here: even when you know how to use the D build system, it still sucks and is very hard to use. The PR review team has let wrong things go past several times because it is so convoluted.
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 04:54:15 UTC, tsbockman wrote: On Thursday, 11 February 2016 at 04:50:04 UTC, Laeeth Isharc wrote: For the most difficult/contentious issues, writing a DIP is just another form of arguing. Well writing code might be better, but writing a DIP is a superior form of arguing to just plain grumbling as its more constructive. True. Just pointing out that for certain recurring issues, the reason that people have fallen back to grumbling is because some DIPs *did* get written, but were rejected for vague, non-constructive reasons, with no (workable) alternative being offered. Which ones, out if interest ? And in your opinion were they thought through ?
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 04:50:04 UTC, Laeeth Isharc wrote: On Thursday, 11 February 2016 at 04:35:27 UTC, tsbockman wrote: On Thursday, 11 February 2016 at 04:27:43 UTC, Laeeth Isharc wrote: would we be better off if some people that like to argue were to pick just one of their points and write some code or a DIP? For the most difficult/contentious issues, writing a DIP is just another form of arguing. Well writing code might be better, but writing a DIP is a superior form of arguing to just plain grumbling as its more constructive. And not only is it more constructive but the structured format forces you to think things through and to make explicit what isn't in a forum post (which may reduce contention since its much clearer what you mean). And even if this were not the case then there are plenty of things that people like to grumble about but that wouldn't be all that contentious once expressed in a thought through DIP even if people didn't agree with you. Because then its all set out clearly and it becomes more of an objective technical debate.
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 04:50:04 UTC, Laeeth Isharc wrote: For the most difficult/contentious issues, writing a DIP is just another form of arguing. Well writing code might be better, but writing a DIP is a superior form of arguing to just plain grumbling as its more constructive. True. Just pointing out that for certain recurring issues, the reason that people have fallen back to grumbling is because some DIPs *did* get written, but were rejected for vague, non-constructive reasons, with no (workable) alternative being offered.
Re: Wannabe contributor frustrations
On 2/10/2016 6:07 PM, Etienne wrote: It took me way more than 2 hours to grasp how this build process works. It wasn't until I had read through the whole source code actually. These are opportunities to improve things. If you could issue PRs to improve the documentation at the pain points, it'll help the next traveler. Or at least open a bugzilla issue for it.
Re: Wannabe contributor frustrations
On 2/10/2016 6:07 PM, Etienne wrote: It took me way more than 2 hours to grasp how this build process works. It wasn't until I had read through the whole source code actually. "Use the Source, Luke" -- Unix Documentation
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 04:35:27 UTC, tsbockman wrote: On Thursday, 11 February 2016 at 04:27:43 UTC, Laeeth Isharc wrote: would we be better off if some people that like to argue were to pick just one of their points and write some code or a DIP? For the most difficult/contentious issues, writing a DIP is just another form of arguing. Well writing code might be better, but writing a DIP is a superior form of arguing to just plain grumbling as its more constructive.
Re: Wannabe contributor frustrations
On Wednesday, 10 February 2016 at 23:30:03 UTC, Márcio Martins wrote: I decided to try a couple ideas in druntime and followed this http://wiki.dlang.org/Starting_as_a_Contributor#Fetch_dmd_from_GitHub Everything went fast and smooth - I have a custom built dmd version. Bootstrapping and building dmd was suspiciously fast - took around 15 secs maybe, if I remember right, I did my changes to druntime, rebuilt with make -f posix.mak Compiled a test case with ../dmd/src/dmd test.d, but my changes were not reflected. So, I double check I actually did recompile druntime and look for the output lib files, and immediately thought that it must be picking up the system include and lib paths instead of this development env. I create a dmd.conf in ../dmd/src right next to my custom dmd binary, but still doesn't work. I try again invoking ../dmd/src/dmd -conf=../dmd/src/dmd.conf but still nothing. I try passing the -I and -L arguments in the command line but still it is not using my custom druntime. At this point I flip the table and give up - what could I be doing wrong? My expectation was that given I followed the official "tutorial" closely, everything was going to just work, instead I spent about 2 hours on this and got nowhere... dmd should have a verbose mode where it outputs what it's trying to do and with which settings, so I could have a chance at seeing what I have messed up, and what linker command it is invoking, ... as it is, I felt totally in the dark, and that just adds to the frustration. I am on Ubuntu 15 and got a system-wide dmd installed from the official .deb package. When you figure it out maybe you could draft a clear explanation of whats missing from the existing wiki instructions to append as a set of hints and tips. One of the biggest problems with explaining things is that it's hard to remember what it was like not to know something, and so experts can often be terrible at explaining things because it seems obvious (and as Ray Charles said, everything is easy when you know how to do it).
Re: Wannabe contributor frustrations
On Thursday, 11 February 2016 at 02:07:54 UTC, Etienne wrote: On Wednesday, 10 February 2016 at 23:30:03 UTC, Márcio Martins wrote: My expectation was that given I followed the official "tutorial" closely, everything was going to just work, instead I spent about 2 hours on this and got nowhere... It took me way more than 2 hours to grasp how this build process works. It wasn't until I had read through the whole source code actually. It's also a pain to edit. It's been suggested several times that we change the build system (e.g. to use https://github.com/atilaneves/reggae), but IIRC, Walter and Andrei have generally been opposed to the idea of changing it. It's one of those things that frequent contributors have more or less sorted out and don't usually worry about much anymore (aside perhaps from the rare occasions when they need to edit the makefiles), whereas it definitely tends to bite folks who aren't familiar with it. And building the documentation is that much worse. Personally, I'd love to see it changed to something more maintainable, but we'd have to be sure that what we were switching to really was better. As it is, I wrote a program that I use to update the source and do builds on my machine so that building is semi-sane, and I suspect that other contributors have done similar. - Jonathan M Davis
Re: OT: 'conduct unbecoming of a hacker'
On Thursday, 11 February 2016 at 04:27:43 UTC, Laeeth Isharc wrote: would we be better off if some people that like to argue were to pick just one of their points and write some code or a DIP? For the most difficult/contentious issues, writing a DIP is just another form of arguing.
Re: OT: 'conduct unbecoming of a hacker'
On Wednesday, 10 February 2016 at 17:17:40 UTC, Nick Sabalausky wrote: Unfortunately, that sounds very similar to experiences I've had here in D-land :( Gets very frustrating. Yes - one trigger for posting it was the tone of some messages in some recent forum discussions (although it's really a tiny part of things on the whole). 'D is broken and needs a complete redesign', 'D has no chance against C# and Swift' etc. Maybe, but grumbling isn't going to make it better, once the ground has been covered once. I should they that although I have read his blog in the past, the trigger for reading that note was his commentary on the nanomsg hoohah (please - let's discuss that on another thread if necessary, not on this one). And that's the project he was referring to in this note. I don't know all the details there, but I think his broader point about the decline of hacker culture is a much stronger one than the specific application he makes with nanomsg (my take would be a bit different). [I'm not really able to judge situation as regards pull requests for D, although I wonder sometimes about type 1 vs type 2 errors and the balance between maintaining high standards and letting the best be the enemy of the good, given that something imperfect but useful can be the seeds of something that ends up becoming truly excellent - depending on the intrinsic sunk costs from doing things not perfectly the first time which might depend on the particular problem but also might not be obvious beforehand]. Eg for all the time spent arguing about what's holding D back, some of the real progress in terms of making the language attractive to real end-users who are going to hire people and maybe contribute resources came from people just doing stuff. ndslice, PyD Magic (integration with python notebook), bachmeier's integration with R (which means access to all the R libraries, which is huge). I notice Kenji rarely argues about things in the forum. Would we be better off if he were to spend much more time here instead of fixing bugs ? :) would we be better off if some people that like to argue were to pick just one of their points and write some code or a DIP? Joakim: "Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus." No - I think he used Stallman as an example of someone who although he whined a lot actually did a hell of a lot of work even so and became the change in the world he wanted. In my view productivity isn't about how many projects you don't manage to finish, but how many you do get done, and I am not sure I am in a position to criticize Stallman from that perspective, and even if his ideological approach isn't entirely my cup of tea, I do recognize he played a critical role there that was necessary. Nick: "That's a REALLY good article - quoting 'a patch in the hand is better than two in the bush'." Yes, I think so. Though it's delicate. Problem is for some things making the wrong decision can be a disaster. But, for example, with dirEntries right now - it's broken for serious use (last I checked and if it's fixed now, the point stands as it was broken for a long time). Almost decent solutions have been proposed but fell short of perfection and then they were kind of dropped. So the consequence is it's (possibly and if not then was for a long time) still broken. That's not the first time this kind of thing has happened. Was that the right trade-off between Type 1 and Type 2 errors? If you're not making some of each kind of mistake then it may be the case that the balance is wrong. (Depending on the situation of course - depends on what the consequences are of making a mistake. Conservatism isn't always the lower risk option, even though it feels that way). "* Bare assertions that there is no need for the feature, when the fact that somebody wrote a patch should be prima facie evidence that the feature was needed" Yes. Though with language features it's delicate, and I respect the taste of Andrei/Walter and other key people. "Really, what I’m asking is this: Which is more convincing? Concrete computer code authored by someone with first-hand knowledge of the defect? Or the bare assertion that something is wrong with it? I mean, either one might be correct. But the first is better supported." Yes - quite. Lobo - thanks for video link. Will watch. His montage of the shift in the front cover of hacker magazines was rather revealing of broader societal shifts. (From Byte and Dr Dobbs in the 80s to their successors becoming more like lifestyle magazines today). I've seen the same thing happen in my lifetime in certain parts of finance. In the beginning you have a bunch of highly unusual people who ended
Re: Offering Access to Parser
On Wednesday, 10 February 2016 at 12:24:49 UTC, Jacob Carlborg wrote: That's very close to AST macros. The only difference is the need to parse the input, "bar" in this case. Well yes, that's my point. AST macros don't need any new special syntax or language support, just access to the compiler's syntax parser. Then you can use normal mixins to get the code you want. I dunno. I don't really care that much. It was just an idea I had that turned into way too many words.
Re: OT: 'conduct unbecoming of a hacker'
On Wednesday, 10 February 2016 at 23:55:17 UTC, deadalnix wrote: Also because context switching got from a handful of cycle at the time to about 1000 cycles on modern CPU, making the idea of microkernel somewhat less attractive. But saying Stallman released nothing is unfair. If we can consider hurd a failure, he was also behind emacs, early gcc and other things. Nobody said "nothing," I specifically noted his "GNU tools" and that a microkernel was ambitious. Just remarking that his kernel didn't get done, for a variety of reasons.
Re: Safe cast of arrays
On Wed, 10 Feb 2016 22:39:20 -0500, Steven Schveighoffer wrote: > I think casting a mutable array to any array type is a recipe for memory > issues, no matter what is in the elements. Remember that you are casting > a reference that still has a mutable pointer to it. > > @safe should start from a very cautious and overtightened state, and > then we loosen it as we find issues. > > As it was done, it has holes, and so when we fix things, code breaks. > > -Steve I agree with the principle, but it's always safe to read a pointer as if it were not a pointer, and that's what a cast to an immutable array would do.
Re: Wannabe contributor frustrations
On Thursday, 11 February 2016 at 02:07:54 UTC, Etienne wrote: On Wednesday, 10 February 2016 at 23:30:03 UTC, Márcio Martins wrote: My expectation was that given I followed the official "tutorial" closely, everything was going to just work, instead I spent about 2 hours on this and got nowhere... It took me way more than 2 hours to grasp how this build process works. It wasn't until I had read through the whole source code actually. "Use the source, Luke!"
Re: Safe cast of arrays
On 2/10/16 5:49 PM, Chris Wright wrote: On Wed, 10 Feb 2016 21:40:21 +, Iakh wrote: On Wednesday, 10 February 2016 at 20:14:29 UTC, Chris Wright wrote: @safe protects you from segmentation faults and reading and writing outside an allocated segment of memory. With array casts, @safety is assured Yes, @safe protects from direct cast to/from ref types but there still is a trick with T[] -> void[] -> T2[] cast: So no safety in this world. Okay, that's a problem. It should always be safe to cast from void[] to immutable(T)[] where T doesn't contain pointers. I didn't see a bug for this, so I'm filing it. I think casting a mutable array to any array type is a recipe for memory issues, no matter what is in the elements. Remember that you are casting a reference that still has a mutable pointer to it. @safe should start from a very cautious and overtightened state, and then we loosen it as we find issues. As it was done, it has holes, and so when we fix things, code breaks. -Steve
Re: Babylon JS-like game engine or complete port
On 11/02/16 9:07 AM, karabuta wrote:
I like the feel when using Babylon JS(http://www.babylonjs.com/) and how
the APIs are designed. It has glTF, STL & OBJ importers and many more
cool features for game devs
(http://www.babylonjs.com/#featuresdemossection).
But, it does give me the power and performance I need since it is based
on webGL and JS.
Now, how practical will it be to port this JS game engine to D (OpenGL /
Vulkhan/ **)? There seems to be a Haxe Version
(http://babylonhx.gamestudiohx.com/) which has something to do with C++
(seems Haxe can target C++).
Is anyone doing something like that?
Example;
// Babylon
var engine = new BABYLON.Engine(canvas, true);
var scene = new BABYLON.Scene(engine);
var camera = new BABYLON.FreeCamera("Camera", new
BABYLON.Vector3(-190, 120, -243), scene);
camera.setTarget(new BABYLON.Vector3(-189, 120, -243));
camera.rotation = new BABYLON.Vector3(0.30, 1.31, 0);
camera.attachControl(canvas);
I can handle brutal honesty so, destroy :)
We have no need to port. We can do better.
Interested on working on an audio lib playing/recording/abstractions?
Its the last major thing missing that something like that has.
Re: Wannabe contributor frustrations
On Wednesday, 10 February 2016 at 23:30:03 UTC, Márcio Martins wrote: My expectation was that given I followed the official "tutorial" closely, everything was going to just work, instead I spent about 2 hours on this and got nowhere... It took me way more than 2 hours to grasp how this build process works. It wasn't until I had read through the whole source code actually.
Re: D's equivalent to C++'s std::move?
On Thursday, 11 February 2016 at 00:54:21 UTC, Ola Fosheim Grøstad wrote: On Thursday, 11 February 2016 at 00:32:11 UTC, Matt Elkins wrote: unique owner falls out of scope. This situation occurs a lot for me, and RAII plus move semantics are pretty close to ideal for handling it. Yes, it can be approximated with reference counting, but reference counting has its own downsides. C++ unique_ptr is a semantically a reference-counting ptr with a max count of 1. True, but with unique_ptr the max count is enforced by the compiler and can only be subverted by a programmer explicitly choosing to do so -- if that is possible with normal reference counting, I don't know of a way. Moreover, there is no heap allocation required which may or may not matter for a given use case. Of course there are ways to avoid or mitigate heap allocations for reference-counted pointers, but the point is that unique_ptr has the next best thing to no overhead at all, which allows it to be used in a broader range of contexts. In C++ it is a type system issue, and the actual semantics are up to the programmer. In D it is just copy and clear, which does extra work and is less flexible _and_ forces the copying to happen so you cannot escape it. Fair point.
Re: Wannabe contributor frustrations
On 2/10/16 6:40 PM, Chris Wright wrote: On Wed, 10 Feb 2016 23:30:03 +, Márcio Martins wrote: So, I double check I actually did recompile druntime and look for the output lib files, and immediately thought that it must be picking up the system include and lib paths instead of this development env. I'm working on druntime stuff now, and I'm about to run into the same issue. I notice that the dmd 2.070 package does not contain libdruntime. I presume it's rolled into libphobos. And I notice that the phobos makefile references "../druntime". Try building phobos as well and see how that works? Psst! libdruntime was never used. It was always used as compiled in phobos. I don't know why it was ever included. -Steve
Re: Wannabe contributor frustrations
On 2/10/2016 4:45 PM, H. S. Teoh via Digitalmars-d wrote: dmd should have a verbose mode where it outputs what it's trying to do and with which settings, so I could have a chance at seeing what I have messed up, and what linker command it is invoking, ... as it is, I felt totally in the dark, and that just adds to the frustration. You're looking for: dmd -v http://dlang.org/dmd-windows.html#switch-v
Re: D's equivalent to C++'s std::move?
On Thursday, 11 February 2016 at 00:32:11 UTC, Matt Elkins wrote: unique owner falls out of scope. This situation occurs a lot for me, and RAII plus move semantics are pretty close to ideal for handling it. Yes, it can be approximated with reference counting, but reference counting has its own downsides. C++ unique_ptr is a semantically a reference-counting ptr with a max count of 1. So, when you are using a shared_ptr, you also use move semantics. Meaning, you can transfer one shared_ptr to another without the overhead which would be a "move", or you can "copy" by increasing the count by one. C++11 definitely supports this use case. I -think- that D does as well, possible compiler issues aside, though I haven't used it as extensively here to be sure yet. In C++ it is a type system issue, and the actual semantics are up to the programmer. In D it is just copy and clear, which does extra work and is less flexible _and_ forces the copying to happen so you cannot escape it. In C++ the type system tells the class what it _may_ do, not what has already happened (which is what D does). In C++ you aren't required to move, you can choose to use a different strategy/semantics. Like, in C++ you could do: "take_one_but_not_both(std::move(a),std::move(b))" That would not work in D.
Re: Wannabe contributor frustrations
On Wed, Feb 10, 2016 at 11:30:03PM +, Márcio Martins via Digitalmars-d wrote: > I decided to try a couple ideas in druntime and followed this > http://wiki.dlang.org/Starting_as_a_Contributor#Fetch_dmd_from_GitHub > > Everything went fast and smooth - I have a custom built dmd version. > Bootstrapping and building dmd was suspiciously fast - took around 15 > secs maybe, if I remember right, > > > I did my changes to druntime, rebuilt with make -f posix.mak > > Compiled a test case with ../dmd/src/dmd test.d, but my changes were > not reflected. Druntime is not linked to compiled programs by itself; it gets linked as part of Phobos. So after making changes in druntime, you have to also rebuild Phobos before you will see your changes reflected. [...] > dmd should have a verbose mode where it outputs what it's trying to do > and with which settings, so I could have a chance at seeing what I > have messed up, and what linker command it is invoking, ... as it is, > I felt totally in the dark, and that just adds to the frustration. [...] You're looking for: dmd -v T -- Freedom of speech: the whole world has no right *not* to hear my spouting off!
Re: D's equivalent to C++'s std::move?
On Tuesday, 9 February 2016 at 13:45:13 UTC, Hara Kenji wrote: On Tuesday, 9 February 2016 at 00:25:33 UTC, Matt Elkins wrote: On Thursday, 4 February 2016 at 02:33:06 UTC, Andrei Alexandrescu wrote: Got it, thanks. That's a bug in the implementation, no two ways about it. No copy should occur there, neither theoretically nor practically. Please report it to bugzilla at http://issues.dlang.org. Thanks very much! -- Andrei Done (sorry for the delay): https://issues.dlang.org/show_bug.cgi?id=15662 I've replied to issue 15662. The point of that issue is, an array concatenation or appending may cause the elements' copy. The copy occurrence is determined by the runtime situation, so compiler needs to reject such the operation for the @disable this(this) elements conservatively. Kenji Hara Actually, I have a follow-up question about this: when you say that an array concatenation may cause the elements' copy, do you mean only the element being appended? Or can elements already in the array be copied? If the latter, isn't it a problem that my workaround for appending non-copyable objects into the array compiles? My workaround is like this (typing directly without testing): // Foo has opAssign defined for rvalues, but post-blit and opAssign for lvalues disabled Foo[] fooArray; ++fooArray.length; fooArray[$ - 1] = Foo();
Re: D's equivalent to C++'s std::move?
On Wednesday, 10 February 2016 at 20:42:29 UTC, w0rp wrote: The only remaining time you need to avoid copies is when you take something already on the stack, and then put it into some other object, into some collection, etc. That's the other power that std::move affords you. The move functions in std.algorithm should take care of that. Maybe someone else will correct me on a point or two there, but that's the understanding of move semantics in D that I have had. Maybe this is what you are referring to, but the primary use I get out of move semantics (in general, not language-specific) has little to do with performance-on-copy. It is for handling resources which logically aren't copyable, which have a unique owner at all times and which should be cleaned up as soon as unique owner falls out of scope. This situation occurs a lot for me, and RAII plus move semantics are pretty close to ideal for handling it. Yes, it can be approximated with reference counting, but reference counting has its own downsides. C++11 definitely supports this use case. I -think- that D does as well, possible compiler issues aside, though I haven't used it as extensively here to be sure yet. It does seem as though one has to be more careful using these semantics in D, because of how easy it is to stuff such an object into a GC-based container and thereby lose the deterministic nature of the cleanup, but that's just more something to be aware of than a true limitation.
Re: Wannabe contributor frustrations
On Wednesday, 10 February 2016 at 23:30:03 UTC, Márcio Martins wrote: dmd should have a verbose mode where it outputs what it's trying to do and with which settings, so I could have a chance at seeing what I have messed up, and what linker command it is invoking, ... as it is, I felt totally in the dark, and that just adds to the frustration. The "-v" (verbose) option does this. You can find a list of DMD options and such here: http://dlang.org/dmd-linux.html
Re: Wannabe contributor frustrations
On Wednesday, 10 February 2016 at 23:30:03 UTC, Márcio Martins wrote: I did my changes to druntime, rebuilt with make -f posix.mak You really need to build all three together to see changes effectively... IMO it is a denial of reality to put them in three separate repositories since they are so strongly coupled in practice - their makefiles reference each other! I create a dmd.conf in ../dmd/src right next to my custom dmd binary, but still doesn't work. That shouldn't be necessary, but building phobos as well as your custom druntime probably is. dmd should have a verbose mode where it outputs what it's trying to do and with which settings, so I could have a chance at seeing what I have messed up, and what linker command it is try `dmd -v`
Re: OT: 'conduct unbecoming of a hacker'
On Wednesday, 10 February 2016 at 18:31:22 UTC, Nick Sabalausky wrote: On 02/10/2016 01:09 PM, Joakim wrote: Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus. [Unimportant theorizing ahead...] I wouldn't say that's necessarily true: It could be argued the existence and proliferation of the Linux kernel reduced the priority of his Hurd work, even if only to a subconscious extent. If it hadn't been for the Linux kernel, maybe there would have been more drive (and more contributors) to Hurd. Also because context switching got from a handful of cycle at the time to about 1000 cycles on modern CPU, making the idea of microkernel somewhat less attractive. But saying Stallman released nothing is unfair. If we can consider hurd a failure, he was also behind emacs, early gcc and other things.
Re: Wannabe contributor frustrations
On Wed, 10 Feb 2016 23:30:03 +, Márcio Martins wrote: > So, I double check I actually did recompile druntime and look for the > output lib files, and immediately thought that it must be picking up the > system include and lib paths instead of this development env. I'm working on druntime stuff now, and I'm about to run into the same issue. I notice that the dmd 2.070 package does not contain libdruntime. I presume it's rolled into libphobos. And I notice that the phobos makefile references "../druntime". Try building phobos as well and see how that works?
Wannabe contributor frustrations
I decided to try a couple ideas in druntime and followed this http://wiki.dlang.org/Starting_as_a_Contributor#Fetch_dmd_from_GitHub Everything went fast and smooth - I have a custom built dmd version. Bootstrapping and building dmd was suspiciously fast - took around 15 secs maybe, if I remember right, I did my changes to druntime, rebuilt with make -f posix.mak Compiled a test case with ../dmd/src/dmd test.d, but my changes were not reflected. So, I double check I actually did recompile druntime and look for the output lib files, and immediately thought that it must be picking up the system include and lib paths instead of this development env. I create a dmd.conf in ../dmd/src right next to my custom dmd binary, but still doesn't work. I try again invoking ../dmd/src/dmd -conf=../dmd/src/dmd.conf but still nothing. I try passing the -I and -L arguments in the command line but still it is not using my custom druntime. At this point I flip the table and give up - what could I be doing wrong? My expectation was that given I followed the official "tutorial" closely, everything was going to just work, instead I spent about 2 hours on this and got nowhere... dmd should have a verbose mode where it outputs what it's trying to do and with which settings, so I could have a chance at seeing what I have messed up, and what linker command it is invoking, ... as it is, I felt totally in the dark, and that just adds to the frustration. I am on Ubuntu 15 and got a system-wide dmd installed from the official .deb package.
Re: OT: 'conduct unbecoming of a hacker'
On Wednesday, 10 February 2016 at 02:11:25 UTC, Laeeth Isharc wrote: http://sealedabstract.com/rants/conduct-unbecoming-of-a-hacker/ (His particular suggestion about accept patches by default is not why I post this). ' We’re all talk [...] On Wednesday, 10 February 2016 at 02:11:25 UTC, Laeeth Isharc wrote: [] Interesting timing! At my workplace we have a geekfest video session once a month and last week it was this: https://youtu.be/-F-3E8pyjFo It's worth a watch and it covers very similar ground. The presenters discuss their experiences developing subversion and other FOSS projects. bye, lobo
Re: Safe cast of arrays
On Wed, 10 Feb 2016 22:49:33 +, Chris Wright wrote: > It should always be safe to cast from void[] to immutable(T)[] where T > doesn't contain pointers. > > I didn't see a bug for this, so I'm filing it. Filed https://issues.dlang.org/show_bug.cgi?id=15672
Re: Safe cast of arrays
On Wednesday, 10 February 2016 at 20:14:29 UTC, Chris Wright wrote: Show a way to read or write outside allocated memory with this, or to cause a segmentation fault, and that will require a change in @safe. You're looking for something else, data safety rather than memory safety. You want to disallow unions and anything that lets you emulate them. Does this count? http://dpaste.dzfl.pl/96db07a5104e
Re: Safe cast of arrays
On Wed, 10 Feb 2016 21:40:21 +, Iakh wrote: > On Wednesday, 10 February 2016 at 20:14:29 UTC, Chris Wright wrote: >> @safe protects you from segmentation faults and reading and writing >> outside an allocated segment of memory. With array casts, @safety is >> assured > > Yes, @safe protects from direct cast to/from ref types but there still > is a trick with T[] -> void[] -> T2[] cast: > > So no safety in this world. Okay, that's a problem. It should always be safe to cast from void[] to immutable(T)[] where T doesn't contain pointers. I didn't see a bug for this, so I'm filing it.
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 16:26:33 UTC, Gary Willoughby wrote: Can I get more opinions on increasing the logo size on the website please. See here for an example: https://github.com/D-Programming-Language/dlang.org/pull/1227 Destroy! It is better on large screen, worse on small ones.
Re: D's equivalent to C++'s std::move?
On Wednesday, 10 February 2016 at 20:42:29 UTC, w0rp wrote:
Back on the original topic, Scott Meyers often says "std::move
doesn't move." It's more like std::rvalue_cast. C++ uses
r-value references in order to be able to rip the guts out of
objects and put them into other objects.
Well. In C++ "std::move(x)" is just a "static_cast(x)" for
"T x".
"T&&" references are different from "T&" by acting like T&
references when used, but not on overloads. They are primarily
for distinguishing between overloads on temporaries in function
calls, T&& binds to temporaries. So you use "std::move(x)" to
tell the type system that you want it to be cast as a references
to a temporary like reference (or rvalue reference).
So that's why constructors with "T&&" are called move
constructors (taking stuff from temporaries) and "const T&" are
called copy constructors (assuming that the parameter might have
a long life on it's own).
That kind of return value optimisation was the original
motivation for r-value references, for when C++98 RVO isn't
good enough, from my understanding.
It is for overloading. Why allocate lots of stuff by copying it
if you know that the referenced object is about to die anyway? If
it is dying we just steal the stuff it is holding.
stack.push(string("hiii")) // we could steal this stuff
string x("hiii")
stack.push(x) // we have to copy this stuff
Maybe someone else will correct me on a point or two there, but
that's the understanding of move semantics in D that I have had.
I don't think D has move semantics... It does copying and
clearing... The postblit thing looks like a dirty hack to me.
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 21:44:54 UTC, anonymous wrote: On 10.02.2016 22:37, CraigDillabaugh wrote: I know I can take the logo from the website and blow it up, but it is pretty small and enlarging it so much will result in a pretty awful looking image. It's an SVG file, so enlarging should work beautifully. If you're having trouble with it, I can upload a larger SVG or PNG version. Is 256x256 the ideal format? Does it need to be square? The logo on the site is more wide than high. Do you want it cropped or centered? Thanks. I found the SVG version, which I should be able to resize. For some reason Google wants a logo at least 256x256. Not sure if it has to be square, need to check their site again, think it has to be 256 on the smallest dimension. I am reasonably competent with image processing software, so I should be OK, even if I have to crop/squish it. Actually, it would make more sense to just add a white background and centre it on that if they don't take irregular shapes. If I get stuck, I will know who to ask.
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 21:31:39 UTC, anonymous wrote: On 10.02.2016 21:38, Ola Fosheim Grøstad wrote: Ask for a Creative Commons license? I've shot him an email. Great, maybe also mention that it would be nice if it could be used on T-shirts and book covers?
Re: Can I get more opinions on increasing the logo size on the site please
On 10.02.2016 22:37, CraigDillabaugh wrote: I know I can take the logo from the website and blow it up, but it is pretty small and enlarging it so much will result in a pretty awful looking image. It's an SVG file, so enlarging should work beautifully. If you're having trouble with it, I can upload a larger SVG or PNG version. Is 256x256 the ideal format? Does it need to be square? The logo on the site is more wide than high. Do you want it cropped or centered?
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 21:37:29 UTC, CraigDillabaugh wrote: On Wednesday, 10 February 2016 at 16:26:33 UTC, Gary Willoughby wrote: clip Speaking of the logo, does anyone know where I can get my hands on a 256x256 PNG version of the logo (or at least larger than the website one). I need to upload it for the GSOC application. I know I can take the logo from the website and blow it up, but it is pretty small and enlarging it so much will result in a pretty awful looking image. OK, found the SVG version, so I should be good. Sorry for the noise ... you can go back to arguing about fair use :o)
Re: Safe cast of arrays
On Wednesday, 10 February 2016 at 20:14:29 UTC, Chris Wright
wrote:
@safe protects you from segmentation faults and reading and
writing outside an allocated segment of memory. With array
casts, @safety is assured
Yes, @safe protects from direct cast to/from ref types but there
still is a trick with T[] -> void[] -> T2[] cast:
import std.stdio;
int[] f(void[] a) @safe pure
{
return cast(int[])a;
}
struct S
{
int* a;
}
void main() @safe
{
S[] a = new S[4];
immutable b = a.f();
writeln(b);
a[0].a = new int;
writeln(b);
//b[0] = 0;
//writeln(*a[0].a);
}
So no safety in this world.
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 16:26:33 UTC, Gary Willoughby wrote: Can I get more opinions on increasing the logo size on the website please. See here for an example: https://github.com/D-Programming-Language/dlang.org/pull/1227 Destroy! Speaking of the logo, does anyone know where I can get my hands on a 256x256 PNG version of the logo (or at least larger than the website one). I need to upload it for the GSOC application. I know I can take the logo from the website and blow it up, but it is pretty small and enlarging it so much will result in a pretty awful looking image.
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 21:20:35 UTC, Bubbasaur wrote: On Wednesday, 10 February 2016 at 21:01:11 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 10 February 2016 at 20:57:41 UTC, Bubbasaur wrote: Even with music, you can make "remix" and distribute for free legally, but of course you can't sell. No. You cannot make a remix or use samples without a license. YOU CAN! Err... no you can't. In general, you can't. Yes, I know what "fair use" is. It differs widely from jurisdiction to jurisdiction and within an jurisdiction and is very much a case-by-case issue. E.g. professionals often get the right to display examples of their work to prospective customers, or you get to create a satirical work based on other works, or for research etc. "education" isn't good enough, alone, if it was it would be impossible to sell educational works. But the Bern convention set out to protect copyright holders, not end users. So all it says is what the minimum requirements are... but all jurisdictions can grant creators _more_ rights than what the convention says. The only obligation is that local and foreign creators are treated equally.
Re: Can I get more opinions on increasing the logo size on the site please
On 10.02.2016 21:38, Ola Fosheim Grøstad wrote: Ask for a Creative Commons license? I've shot him an email.
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 21:01:11 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 10 February 2016 at 20:57:41 UTC, Bubbasaur wrote: Even with music, you can make "remix" and distribute for free legally, but of course you can't sell. No. You cannot make a remix or use samples without a license. YOU CAN! I'll give you one example: https://www.youtube.com/yt/copyright/fair-use.html#yt-copyright-four-factors Please read this from TOP-DOWN, between the lines, 3 times before start answering me. And understand the part of FAIR USE. Again before replying, read that link again one more time, and pay attention on the part of FAIR USE. I have a friend which was judged and won on this matter last year. Bubba. PS: Please before replying, read that link again one more time, and pay attention on the part of FAIR USE. :)
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 21:00:10 UTC, Brad Anderson wrote: https://dlang.org :P (the forums just haven't updated yet) Ohh. Yes that's better. :) Bubba.
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 20:57:41 UTC, Bubbasaur wrote: Even with music, you can make "remix" and distribute for free legally, but of course you can't sell. No. You cannot make a remix or use samples without a license.
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 20:49:02 UTC, Bubbasaur wrote: On Wednesday, 10 February 2016 at 16:26:33 UTC, Gary Willoughby wrote: Can I get more opinions on increasing the logo size on the website please. See here for an example: https://github.com/D-Programming-Language/dlang.org/pull/1227 Destroy! I'd prefer this version but smaller. The current one with black borders is ugly for the new layout. Bubba. https://dlang.org :P (the forums just haven't updated yet)
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 20:25:05 UTC, anonymous wrote: ... COPYRIGHT © SUKIMASHITA 2006 ALL FREE TO USE. ONLY SELLING THESE IMAGES IS PROHIBITED. I'd understand that to allow derivative works, but disallow selling them. I'm not a lawyer, though. ... You're right, he would lose "IF" he tried to sue anyone. He was very clear when he said the only prohibited thing is selling, end case. The "USE" is too generic for this case that It can be interpreted as modify, and again, he never said anything about that, but ONLY SELLING, again end case. Even with music, you can make "remix" and distribute for free legally, but of course you can't sell. Bubba.
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 16:26:33 UTC, Gary Willoughby wrote: Can I get more opinions on increasing the logo size on the website please. See here for an example: https://github.com/D-Programming-Language/dlang.org/pull/1227 Destroy! I'd prefer this version but smaller. The current one with black borders is ugly for the new layout. Bubba.
Re: D's equivalent to C++'s std::move?
Back on the original topic, Scott Meyers often says "std::move doesn't move." It's more like std::rvalue_cast. C++ uses r-value references in order to be able to rip the guts out of objects and put them into other objects. D doesn't have a distinct r-value reference type, and postblit is part of the struct types. If you write simply T foo(); and you return some struct T, D already moves the struct out of the function without you having to define any move constructors. That kind of return value optimisation was the original motivation for r-value references, for when C++98 RVO isn't good enough, from my understanding. The only remaining time you need to avoid copies is when you take something already on the stack, and then put it into some other object, into some collection, etc. That's the other power that std::move affords you. The move functions in std.algorithm should take care of that. Maybe someone else will correct me on a point or two there, but that's the understanding of move semantics in D that I have had.
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 20:25:05 UTC, anonymous wrote: The exact text on the site of the original author [1] is COPYRIGHT © SUKIMASHITA 2006 ALL FREE TO USE. ONLY SELLING THESE IMAGES IS PROHIBITED. I'd understand that to allow derivative works, but disallow selling them. I'm not a lawyer, though. My understanding is that "use" means creating copies only. I does not say "modify". He is giving you the right to create copies. Then he puts in the single constrain that it cannot be exchanged for money. I don't think the constraint is granting additional rights. Probably depends on your jurisdiction, but my understanding of the legislation in my country is that an artist has rights related to protecting his integrity as an artist. It is not uncommon that liberal creative licenses states that you are not allowed to use relate a derived work to the the original creators name... (or the opposite). Like, if a historian wrote a book on 2WW, he probably doesn't want someone to create a derived work of it that is rewritten as a holocaust-denial and associate it with him. Likewise, even if people buy/commission an artwork instalment (in my country), it is still illegal to modify or destroy it without contacting the artist. If those terms don't allow us to mess with the logo, what kind of statement or license do we need from the author? Ask for a Creative Commons license?
Re: Support for D in VSCode
On Tuesday, 9 February 2016 at 23:17:48 UTC, bitwise wrote: Also, can you create an install-wizard or zip/package with the extension and all dependencies? I don't really have time to figure out how to install everything separately. Made a wizard which automatically clones, builds and copies all executables now: https://github.com/Pure-D/workspace-d-installer
Re: Just because it's a slow Thursday on this forum
On Wednesday, 10 February 2016 at 19:30:26 UTC, Andrei Alexandrescu wrote: On 02/10/2016 01:51 PM, w0rp wrote: I wonder if the addition of another function for printing will confuse some new users. In my experience: * two names for the same exact thing => annoyance (not only in D, e.g. dual use of "class" and "typename" in C++) * two different names that do the same thing in slightly different without a distinction, interchangeable ways => confusion and annoyance (e.g. "class" vs "struct" in C++) * two names that do the same thing, one poorly and one better => confusion (e.g. "stringstream" vs. "strstream", vector vs vector_bool in C++) * two names that do two similar, but distinct things => "oh ok" (e.g. "map" vs. "multimap"). So I think we're safe. Andrei Yeah, that makes sense. Fair enough.
Re: Can I get more opinions on increasing the logo size on the site please
On 10.02.2016 17:49, Ola Fosheim Grøstad wrote: If you guys are going to create a new logo based on the old one, you probably should clear it with the original creator. On his website he has give us use rights for non-commercial use, but not rights to create derivative works... The new logo is not part of the pull request. It's already on the site. If there's a legal problem, we should probably revert that. The exact text on the site of the original author [1] is COPYRIGHT © SUKIMASHITA 2006 ALL FREE TO USE. ONLY SELLING THESE IMAGES IS PROHIBITED. I'd understand that to allow derivative works, but disallow selling them. I'm not a lawyer, though. If those terms don't allow us to mess with the logo, what kind of statement or license do we need from the author? [1] http://media.sukimashita.com/d/
Re: Safe cast of arrays
On Wed, 10 Feb 2016 08:49:21 +, w0rp wrote:
> I think this should be addressed, as if you can't cast between pointer
> types, you shouldn't be allowed to cast between slice types either.
> Because slices are just a pointer plus a length. Another way to
> demonstrate the problem is like this.
>
> @safe int* badCast(long[] slice) {
> return (cast(int[]) slice).ptr;
> }
>
>
> @system void main(string[] argv) {
> auto larger = new long[5];
> auto smaller = badCast(larger);
> }
@safe protects you from segmentation faults and reading and writing
outside an allocated segment of memory. With array casts, @safety is
assured:
int[] a = [1, 2, 3, 4];
long[] b = cast(long[])a;
writeln(b.length); // prints "2"
Versus:
int[] a = [1, 2, 3, 4, 5];
long[] b = cast(long[])a;
This throws an "object.Error: array cast misalignment" specifically
because there's no correct, safe way to execute the cast. You'd be left
with a dangling half of a long.
But if you're using pointers, the runtime can't do this kind of
validation, so it's not @safe to cast int* to long*. It is, however, safe
to cast long* to int*, because writing four bytes to a long* won't
overflow the memory allocated to it.
So this isn't a problem with @safe.
Show a way to read or write outside allocated memory with this, or to
cause a segmentation fault, and that will require a change in @safe.
You're looking for something else, data safety rather than memory safety.
You want to disallow unions and anything that lets you emulate them.
Babylon JS-like game engine or complete port
I like the feel when using Babylon JS(http://www.babylonjs.com/)
and how the APIs are designed. It has glTF, STL & OBJ importers
and many more cool features for game devs
(http://www.babylonjs.com/#featuresdemossection).
But, it does give me the power and performance I need since it is
based on webGL and JS.
Now, how practical will it be to port this JS game engine to D
(OpenGL / Vulkhan/ **)? There seems to be a Haxe Version
(http://babylonhx.gamestudiohx.com/) which has something to do
with C++ (seems Haxe can target C++).
Is anyone doing something like that?
Example;
// Babylon
var engine = new BABYLON.Engine(canvas, true);
var scene = new BABYLON.Scene(engine);
var camera = new BABYLON.FreeCamera("Camera", new
BABYLON.Vector3(-190, 120, -243), scene);
camera.setTarget(new BABYLON.Vector3(-189, 120, -243));
camera.rotation = new BABYLON.Vector3(0.30, 1.31, 0);
camera.attachControl(canvas);
I can handle brutal honesty so, destroy :)
Re: OT: 'conduct unbecoming of a hacker'
On Wednesday, 10 February 2016 at 19:44:50 UTC, Joakim wrote: Perhaps historically as a guinea pig, but its use is waning for more permissive licenses, which have been around for decades too. Well, they had been around for things like X11, which had a commercial consortium driving the development. X11 was just a reference implementation, and members got early access to it so that they could implement it in their proprietary X11 terminals before the general public got access to it... But as (even public) universities were pressured to earn money from their research the heads higher up insisted on anti-commercial licensing. Only when GPL gained traction could the comp. sci. people start to push for something more liberal. IIRC the most standard licensing was educational-use, non-commercial-use or public domain back then. People had to pay for their compilers and IDEs too... quite a lot... And phone bills from using BBSes. Shareware was a much more accepted concept at that point in time too... GPL changed the world quite significantly.
Re: Just because it's a slow Thursday on this forum
On Wed, Feb 10, 2016 at 02:32:37PM -0500, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 02/10/2016 02:25 PM, Nick Sabalausky wrote:
> >I see no non-trivial cost.
>
> I, to, am not getting the cost story. H.S. Teoh, could you please
> substantiate? -- Andrei
Sorry, I meant technical debt. My point was that this function needs to
provide more value than what's effectively just an alias for
writefln("%s, %s, %s", x, y, z).
T
--
Never ascribe to malice that which is adequately explained by incompetence. --
Napoleon Bonaparte
Re: OT: 'conduct unbecoming of a hacker'
On Wednesday, 10 February 2016 at 18:31:22 UTC, Nick Sabalausky wrote: On 02/10/2016 01:09 PM, Joakim wrote: Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus. [Unimportant theorizing ahead...] I wouldn't say that's necessarily true: It could be argued the existence and proliferation of the Linux kernel reduced the priority of his Hurd work, even if only to a subconscious extent. If it hadn't been for the Linux kernel, maybe there would have been more drive (and more contributors) to Hurd. I've read that the bigger issue was that they couldn't quite get Hurd working on '90s hardware, and the simpler linux kernel outpaced it, ie I doubt linux displaced Hurd contribution as they're different approaches. On Wednesday, 10 February 2016 at 19:07:27 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 10 February 2016 at 18:09:57 UTC, Joakim wrote: Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus. Well, 386BSD was there in 1992-1994, and several other OSes, so I don't think Linux is that special. Linux did have the right timing. Amiga and other specialized hardware was becoming less attractive at that point in time, and students were getting x86 PCs with MMUs and wanted an OS that was more like Unix, but less crude than Minix. Still means he'd have had to rely on others to provide his OS, plus BSD was under a legal cloud at the time, which is one of the reasons people say linux lapped it, and he'd probably resent it not being GPL, so it wouldn't work for him anyway. But I don't think Hurd is much of a Stallman coding-project. His core project is the GPL and he did created Emacs and GCC which were very important for the spread of the GPL. I thought he was intimately involved with Hurd, but I don't follow it. Before GPL most academic software had very limiting "free for non-commercial educational use" clauses in their licenses. The GPL itself is much more important than any individual piece of software. Perhaps historically as a guinea pig, but its use is waning for more permissive licenses, which have been around for decades too. As for the main point about useless bickering replacing hacking, that's probably because it was a much smaller community back then, so it consisted of only the really hard-core who wanted to _do_ something, whereas now it's expanded outside that group to the more half-hearted. Either that or he has on the usual rose-colored glasses for the past, the usual veteran complaint, "Everything was better when I was young!" :D Well, both Emacs and GCC have had their forks... so. Yes. Forks are a different issue, as he'd probably say that's real technical disagreement. He's talking more about silly reasons, though I guess forks are sometimes started because of the same dismissiveness he lays out.
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 16:26:33 UTC, Gary Willoughby wrote: Can I get more opinions on increasing the logo size on the website please. See here for an example: https://github.com/D-Programming-Language/dlang.org/pull/1227 Destroy! Making it big is more like a flat design, which is better IMO. But the rest of the page would also have to also be flat in design. Else a smaller version will be a good match with the current design. By the way, the plain white color of the forum body really hurts my eyes. Why not the grey on the homepage?
Re: Just because it's a slow Thursday on this forum
On 02/10/2016 02:25 PM, Nick Sabalausky wrote: I see no non-trivial cost. I, to, am not getting the cost story. H.S. Teoh, could you please substantiate? -- Andrei
Re: Just because it's a slow Thursday on this forum
On 02/10/2016 02:08 PM, H. S. Teoh via Digitalmars-d wrote: 1) It's clear that it's only intended for debugging (i.e., the name should make it clear it isn't for general output, so `dump` rather than `print` would be preferable); Those would be two different functions. -- Andrei
Re: Just because it's a slow Thursday on this forum
On 02/10/2016 01:51 PM, w0rp wrote: I wonder if the addition of another function for printing will confuse some new users. In my experience: * two names for the same exact thing => annoyance (not only in D, e.g. dual use of "class" and "typename" in C++) * two different names that do the same thing in slightly different without a distinction, interchangeable ways => confusion and annoyance (e.g. "class" vs "struct" in C++) * two names that do the same thing, one poorly and one better => confusion (e.g. "stringstream" vs. "strstream", vector vs vector_bool in C++) * two names that do two similar, but distinct things => "oh ok" (e.g. "map" vs. "multimap"). So I think we're safe. Andrei
Re: Just because it's a slow Thursday on this forum
On 02/10/2016 02:08 PM, H. S. Teoh via Digitalmars-d wrote: On Wed, Feb 10, 2016 at 06:51:21PM +, w0rp via Digitalmars-d wrote: I wonder if the addition of another function for printing will confuse some new users. I can't imagine it would in any significant way. Certainly not if it's named "dump", anyway. Currently I don't see much value in it to justify the costs. BUT, there might be a case for it if: [...] I see no non-trivial cost. I've been using a homemade equivalent of it for years, and I can speak from experience that it's definitely a big help. Not only that, but the only two reasons I've ever had for NOT using it are fixed by this proposal: - Can now be done without bulky "mixin(...)" at the usage site. - Built into Phobos so never a need, in any project, to [temporarily or otherwise] tie in a new dependency just for a temporary debugging aid. I'm hugely in favor of this. Me want.
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 16:26:33 UTC, Gary Willoughby wrote: Can I get more opinions on increasing the logo size on the website please. See here for an example: https://github.com/D-Programming-Language/dlang.org/pull/1227 Destroy! I agree it's too tall in that PR. Maybe go for a happy medium? http://racket-lang.org/, https://golang.org/, and http://fsharp.org/ all have the same header height: about halfway between current dlang.org and your PR. -Wyatt
Re: Just because it's a slow Thursday on this forum
On Wednesday, 10 February 2016 at 18:51:21 UTC, w0rp wrote: I wonder if the addition of another function for printing will confuse some new users. I'm a relatively new D user. For the most part, all I use is writeln because that's what was used in the Hello World examples. I only bother looking for other printing functions when I need them. Nevertheless, I struggle with some of the documentation in std.stdio. A few functions, like byChunk, are documented in a high-quality way. For others, the situation is not so good. Look at stdout, just says standard output stream. There's no definition of stream anywhere in there, or a link to maybe the wikipedia page on streams. When I google output stream it brings up Java documentation. I happen to know what it means and someone with other programming experience will too, but not a new programmer. Many other functions are documented in a similarly terse fashion. So no, I don't think adding another function to std.stdio will be confusing ipso facto. Instead, if you think new users will find std.stdio confusing, may I suggest improving the documentation (of both old and new functionality).
Re: OT: 'conduct unbecoming of a hacker'
On 02/09/2016 09:11 PM, Laeeth Isharc wrote: http://sealedabstract.com/rants/conduct-unbecoming-of-a-hacker/ (His particular suggestion about accept patches by default is not why I post this). Just read the rest of the article. That's a REALLY good article. Especially these bits: === "Consider the following outcomes, which happen with some regularity: * [...] * Objections that the problem should be solved another way, but that are accompanied without any volunteers to do it that way. A patch in the hand is better than two in the bush. If somebody does end up doing it the “right” way someday, git revert is only 10 keystrokes. The fact that someday a better patch might appear is not an argument against merging an adequate patch right now. * Bare assertions that there is no need for the feature, when the fact that somebody wrote a patch should be primae facie evidence that the feature was needed" --- "Really, what I’m asking is this: Which is more convincing? Concrete computer code authored by someone with first-hand knowledge of the defect? Or the bare assertion that something is wrong with it? I mean, either one might be correct. But the first is better supported." == Really like: "A patch in the hand is better than two in the bush."
Re: Just because it's a slow Thursday on this forum
On Wed, Feb 10, 2016 at 06:51:21PM +, w0rp via Digitalmars-d wrote: > I wonder if the addition of another function for printing will confuse > some new users. Currently I don't see much value in it to justify the costs. BUT, there might be a case for it if: 1) It's clear that it's only intended for debugging (i.e., the name should make it clear it isn't for general output, so `dump` rather than `print` would be preferable); 2) It's actually useful for debugging, meaning: a) It will use introspection to recursively output aggregate members (preferably with field members labelled); b) Arrays and AA likewise should be output in the expected format; c) Attributes, and perhaps the full type, should be included in the output, especially if function pointers and delegates are involved, e.g.: const(char)[] data = ...; int delegate(float) @safe dg; dump(data, dg); should output something like: (const(char)[])"Some string data", (int delegate(float) @safe)0x12345678 (Why the full type? because it's useful for debugging `auto` variables in range-based code and other such code. And also to make it absolutely clear that this isn't meant for anything other than debugging output.) d) It will, optionally, walk recursive data structures and output each node in some sensible way. 3) The output format should be standard, readable by default, and should not need (nor allow) customization. (Otherwise, we might as well go back to writefln & friends.) T -- It is impossible to make anything foolproof because fools are so ingenious. -- Sammy
Re: OT: 'conduct unbecoming of a hacker'
On Wednesday, 10 February 2016 at 18:09:57 UTC, Joakim wrote: Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus. Well, 386BSD was there in 1992-1994, and several other OSes, so I don't think Linux is that special. Linux did have the right timing. Amiga and other specialized hardware was becoming less attractive at that point in time, and students were getting x86 PCs with MMUs and wanted an OS that was more like Unix, but less crude than Minix. But I don't think Hurd is much of a Stallman coding-project. His core project is the GPL and he did created Emacs and GCC which were very important for the spread of the GPL. Before GPL most academic software had very limiting "free for non-commercial educational use" clauses in their licenses. The GPL itself is much more important than any individual piece of software. As for the main point about useless bickering replacing hacking, that's probably because it was a much smaller community back then, so it consisted of only the really hard-core who wanted to _do_ something, whereas now it's expanded outside that group to the more half-hearted. Either that or he has on the usual rose-colored glasses for the past, the usual veteran complaint, "Everything was better when I was young!" :D Well, both Emacs and GCC have had their forks... so. Yes.
Re: Just because it's a slow Thursday on this forum
I wonder if the addition of another function for printing will confuse some new users.
Re: reduce -> fold?
On Saturday, 30 January 2016 at 18:08:00 UTC, David Nadlinger wrote: Currying is turning (A, B, C) -> D into A -> (B -> (C -> D)), i.e. a function with multiple arguments into a sequence of functions that each take a single argument to apply each. I think I've implemented something like that for fun once, but never really found much use for it. In the few places where I could have used it (mostly binary functions), just using a lambda and partial application seemed to be much more idiomatic. I guess D lacks any idioms that would make its use come naturally. - David I'm late to the party, but I wrote these novetly tidbits a few months ago: Curry using nested structs https://gist.github.com/JakobOvrum/8b2cd11b911079735b14 Curry using delegates https://gist.github.com/JakobOvrum/1a19f670e7a3359006af Neither approach seems to fit in with idiomatic D.
Re: OT: 'conduct unbecoming of a hacker'
On 02/10/2016 01:09 PM, Joakim wrote: Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus. [Unimportant theorizing ahead...] I wouldn't say that's necessarily true: It could be argued the existence and proliferation of the Linux kernel reduced the priority of his Hurd work, even if only to a subconscious extent. If it hadn't been for the Linux kernel, maybe there would have been more drive (and more contributors) to Hurd.
Re: Safe cast of arrays
Yeah, I think it should only allow the equivalent of a dynamic_cast for types in @safe code, and not allow the equivalent of a reinterpret_cast, for T, T*, or T[].
Re: OT: 'conduct unbecoming of a hacker'
On Wednesday, 10 February 2016 at 02:11:25 UTC, Laeeth Isharc wrote: http://sealedabstract.com/rants/conduct-unbecoming-of-a-hacker/ (His particular suggestion about accept patches by default is not why I post this). ' We’re all talk [...] Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus. As for the main point about useless bickering replacing hacking, that's probably because it was a much smaller community back then, so it consisted of only the really hard-core who wanted to _do_ something, whereas now it's expanded outside that group to the more half-hearted. Either that or he has on the usual rose-colored glasses for the past, the usual veteran complaint, "Everything was better when I was young!" :D I don't think the D community actually has these problems that much, as most of the talk is about technical issues, not whether Apple is doing this or that with their business. The fact is that software was not as big a business back then, whereas the largest companies on the planet are built to write software nowadays, so of course people talk a lot more about how the giant software company du jour's actions affect them.
Re: OT: 'conduct unbecoming of a hacker'
On Wed, Feb 10, 2016 at 12:17:40PM -0500, Nick Sabalausky via Digitalmars-d wrote: > On 02/09/2016 09:11 PM, Laeeth Isharc wrote: > > > >My email is inevitably met not with acceptance, nor with constructive > >discussion, but with some attempt to derail the entire enterprise. > >Here are some real examples, paraphrased by yours truly: > > > > I think it should be done some other way, even though the other > >way obviously doesn’t work for you and so far nobody has ever been > >found who is willing to implement it that way > > I don’t want to solve this problem without also solving > >[unrelated problem X], your proposal doesn’t address [unrelated > >problem X], therefore I am inclined to reject it > > I don’t know you and there might be a bug in your patch. This > >patch is too important to leave to somebody new. At the same time it > >is not important enough for any of the core committers to get to it. > > Defend this proposal. You’re telling me you “need” encryption in > >an internet communications library, or you “need” unicode support in > >an object storage library. I don’t believe you. We’ve gotten along > >just fine for N months without it, and we’ll get along for another 2N > >months just fine thanks. > > Look, we’ve already implemented [sort-of related feature] even > >though it’s buggy and doesn’t cover your usecase. That decision was > >complicated and people were arguing about it for years and I really > >don’t want to go through that jungle again. If you wanted to do it > >this way you should have spoken up two years ago. > > > > Unfortunately, that sounds very similar to experiences I've had here > in D-land :( Gets very frustrating. Have to agree with you there. :-( While, on the whole, my experience of D has been very pleasant, and I will probably stick to it for the long term, there *are* some rough edges that, arguably, should have been ironed out by now. But every time the topic comes up people get defensive and then the interminable forum threads ensue, and at the end nothing gets done because everyone is spent from all the arguments. More and more, I've found that participating in forum threads is, in general (there *are* exceptions), inversely proportional to actually getting stuff done. So nowadays I rather just submit a PR instead of getting entangled in the latest Great Debate. OTOH, even PR's can also get discouraging sometimes when it touches certain controversial issues, when it can get stonewalled for months on end, a great deterrent for new contributors to join in. T -- Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen
Re: OT: 'conduct unbecoming of a hacker'
On 02/09/2016 09:11 PM, Laeeth Isharc wrote: My email is inevitably met not with acceptance, nor with constructive discussion, but with some attempt to derail the entire enterprise. Here are some real examples, paraphrased by yours truly: I think it should be done some other way, even though the other way obviously doesn’t work for you and so far nobody has ever been found who is willing to implement it that way I don’t want to solve this problem without also solving [unrelated problem X], your proposal doesn’t address [unrelated problem X], therefore I am inclined to reject it I don’t know you and there might be a bug in your patch. This patch is too important to leave to somebody new. At the same time it is not important enough for any of the core committers to get to it. Defend this proposal. You’re telling me you “need” encryption in an internet communications library, or you “need” unicode support in an object storage library. I don’t believe you. We’ve gotten along just fine for N months without it, and we’ll get along for another 2N months just fine thanks. Look, we’ve already implemented [sort-of related feature] even though it’s buggy and doesn’t cover your usecase. That decision was complicated and people were arguing about it for years and I really don’t want to go through that jungle again. If you wanted to do it this way you should have spoken up two years ago. Unfortunately, that sounds very similar to experiences I've had here in D-land :( Gets very frustrating.
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 16:26:33 UTC, Gary Willoughby wrote: Can I get more opinions on increasing the logo size on the website please. See here for an example: https://github.com/D-Programming-Language/dlang.org/pull/1227 Destroy! I like the big one, it looks more solid. But I would keep the small logo for small screen sizes (phones), since the top bar is to tall otherwise.
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 16:26:33 UTC, Gary Willoughby wrote: Can I get more opinions on increasing the logo size on the website please. See here for an example: https://github.com/D-Programming-Language/dlang.org/pull/1227 Destroy! It's too big. I like the menu bar the size it is right now. The new logo itself looks very nice, though.
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 16:26:33 UTC, Gary Willoughby wrote: Can I get more opinions on increasing the logo size on the website please. See here for an example: https://github.com/D-Programming-Language/dlang.org/pull/1227 It takes up a bit much vertical space. If you guys are going to create a new logo based on the old one, you probably should clear it with the original creator. On his website he has give us use rights for non-commercial use, but not rights to create derivative works... Not being able to use it on commercial items (like t-shirts) is a bit restrictive, IMO.
Can I get more opinions on increasing the logo size on the site please
Can I get more opinions on increasing the logo size on the website please. See here for an example: https://github.com/D-Programming-Language/dlang.org/pull/1227 Destroy!
Re: Just because it's a slow Thursday on this forum
On 02/10/2016 09:22 AM, Daniel Kozak via Digitalmars-d wrote: It is something else. Same as php has echo and var_dump. writeln just output value of some variable, but dump will print names and values of variables, so you can see structure of your data. Oh btw one nice thing about dump would be to display strings in "dson" format, i.e. the same way they'd appear in a D declaration. Example: s = "This is\na\tstring." writeln(s) would output: This is astring. whereas dump!(s) would write: s = "This is\na\tstring." Andrei
Re: Visual studio official d support
On Wednesday, 10 February 2016 at 14:15:26 UTC, Steven Schveighoffer wrote: On 2/9/16 7:15 PM, bitwise wrote: On Tuesday, 9 February 2016 at 22:11:12 UTC, Steven Schveighoffer wrote: A while ago there was a movement to get d included officially in visual studio. Just got this email: An idea you supported has been closed. Thank you for your feedback. Message: This is a great candidate for a language service extension. Moved to newly created wiki for requested extensions. https://github.com/Microsoft/vscode/wiki/Requested-Extensions http://forum.dlang.org/thread/rfixfspmybtolmzhr...@forum.dlang.org =) Bit Yes, when I started writing, your post hadn't been shown yet :) I assume we got the email from MS at the same time... -Steve No such thing as too much good news ;) Bit
Re: Just because it's a slow Thursday on this forum
On Wednesday, 10 February 2016 at 14:06:02 UTC, Suliman wrote: Sorry, but where dump! function can be helpful? What's wrong with writeln? Formatting complex data automatically makes it a lot easier to see what you're getting. Makes debugging so much easier when your data is actually readable. Long strings, complex structs, byte arrays, json or xml, these all really need more formatting to read than writeln does.
Re: Just because it's a slow Thursday on this forum
Dne 10.2.2016 v 15:06 Suliman via Digitalmars-d napsal(a): On Tuesday, 9 February 2016 at 18:02:50 UTC, Andrei Alexandrescu wrote: On 02/09/2016 10:34 AM, ixid wrote: On Tuesday, 9 February 2016 at 12:46:34 UTC, Jakob Ovrum wrote: I'm not a fan of non-trivial string mixins except in extenuating circumstances. This is something Steven Schveighoffer commented on in these discussions as well. As this is a fundamental D feature and it's currently rather clunky and hard to use it would suggest this needs improvement. What should be done with it if anything and with what methods? An alternate solution is liable to be too clever for its own good. Everybody and their cat understands string concatenation. What we need here is better tactical tools, e.g. a simple string template/interpolation engine. -- Andrei Sorry, but where dump! function can be helpful? What's wrong with writeln? It is something else. Same as php has echo and var_dump. writeln just output value of some variable, but dump will print names and values of variables, so you can see structure of your data.
