Re: We need a DConf 2015 logo
On 2015-01-09 03:38, Andrei Alexandrescu wrote: Take a look! http://dconf.org https://github.com/D-Programming-Language/dconf.org/pull/31 The font is different compared to the PNG in the zip. The one on the site has a serif font. -- /Jacob Carlborg
Re: We need a DConf 2015 logo
On 2015-01-08 23:40, ponce wrote: There: http://ovh.to/GAYPaom - same vector logo but with text and gray background - a render in 500x150 (I've used Firefox) - instructions on how to render again Let me know if you need any change. Shouldn't the logo look at least somewhat similar to the one on dlang.org? -- /Jacob Carlborg
Re: Ready to make page-per-item ddocs the default?
On 1/8/2015 1:01 PM, Steven Schveighoffer wrote: core.stdc.config is not technically a standard C header, and it seems pretty strange. I'm going to leave that one alone unless someone objects. Yeah, the mere existence of that module grates.
Re: Ready to make page-per-item ddocs the default?
On 2015-01-08 22:25, Andrei Alexandrescu wrote: Yah, as I said it's a project. Can we at least generate the documentation on multiple platforms, just to make sure we got all modules. -- /Jacob Carlborg
Re: Ready to make page-per-item ddocs the default?
On 1/8/2015 7:41 AM, Andrei Alexandrescu wrote: If we get real cocky we might insert for each symbol a LUCKY link googling for the header name and symbol name. Livin' on the edge!
Re: Ready to make page-per-item ddocs the default?
On 2015-01-08 22:23, Adam D. Ruppe wrote: On Thursday, 8 January 2015 at 21:14:43 UTC, Andrei Alexandrescu wrote: I don't think there is a way. version(Ddoc) dummy prototypes maybe. But that gets painful. Tango is using this method quite heavily in some modules. It also gives the opportunity to simplify signatures. Though I think the compiler should NOT do conditional compilation when generating documentation. Instead, I'd prefer to just put it all out and then maybe group. So the doc would actually list the separate entries under all version headers. Not just OS, but arch or custom bits too. Then the user can see it all. Then by attaching classes to the outputted data you could easily do a filter by OS. That would be really nice. -- /Jacob Carlborg
Re: Ready to make page-per-item ddocs the default?
On 2015-01-08 22:01, Steven Schveighoffer wrote: core.stdc.config is not technically a standard C header, and it seems pretty strange. I'm going to leave that one alone unless someone objects. Shouldn't this then be documented like any other druntime/Phobos module. There are many cases where the members are dependent on the OS. The one that strikes me as the most OS dependent (so far) is errno.d. I'm guessing that only one of those docs is going to go into the online docs? Is there a standard way to make them all show up (with nice categories to show which OS they apply to) which is not painful? If not, then we really need a good way to solve this... An idea might be to make a switch that tells the compiler to override it's internal predefinitions (e.g. compile with -DWin32 on Linux) just for doc generation, and have the resulting page have a way to "flavor" the page based on the OS you select or browse from. That would be cool. -- /Jacob Carlborg
Re: What's missing to make D2 feature complete?
On Thursday, 25 December 2014 at 09:46:19 UTC, Martin Nowak wrote: On Saturday, 20 December 2014 at 19:22:05 UTC, safety0ff wrote: On Saturday, 20 December 2014 at 17:40:06 UTC, Martin Nowak wrote: Just wondering what the general sentiment is. Multiple alias this (DIP66 / #6083.) It's already in :), at least the DIP just got approved. Would it really have been a dealbreaker? Late reply: No, not a dealbreaker (at least for any of the code I've written,) I was focusing on objectively missing features rather than sentiments :) That being said, multiple alias this should considerably expand the implicit conversion and composition options in D.
Re: An idea for commercial support for D
On Tuesday, 6 January 2015 at 22:37:40 UTC, anonymous wrote: On Tuesday, 6 January 2015 at 19:46:51 UTC, Joakim wrote: On Tuesday, 6 January 2015 at 19:06:27 UTC, anonymous wrote: [...] I don't know of any commercial support model where you only pay for the fixes you need at any given moment and the fixes that others paid for are provided to you for free. I'm not knowledgeable about any of this business stuff, and I don't mean to pretend I am. I just wanted to clarify what I think Joseph meant there, as I understood it. As far as I know there are companies that employ developers to work on open source software, with their patches open-sourced immediately. I'm assuming the employer can direct where exactly the effort goes. That's essentially it, no? A few companies may do that, but he referred to paying for fixes you want right away but getting patches other companies paid for for free. I don't know of any commercial support model where that happens. I presume you're referring to support subscriptions, where you pay a monthly fee to subscribe to an stream of ongoing fixes and pay extra for fixes you need right away. But that's not "free," you're paying a monthly fee for that ongoing subscription, which subsidizes the cost of those fixes that others paid for first. No, I didn't have that in mind. Well, unless either of you can articulate exactly what model you have in mind and who's using it, it's irrelevant. [...] My point was that he's wrong that the patch's value doesn't change if others have access to it. Just because that patch doesn't clearly differentiate your product on a spec sheet doesn't mean those patches in aggregate don't differentiate your time to market and cost of making the product, which will all affect your bottom line. So, the point is that competitors can't leech off my paid patches, right? I mean, sure, that's a thing. I'm definitely not business enough to put a number on it. Seems like the number you put on it is higher than the one Joseph puts on it. Yes, _anything_ you pay for is a competitive advantage for you. He seems to think only the direct features of your product are your competitive advantage, but indirect costs like this also affect the price and overall quality of your product, at least relative to other products in the market, which are just as important. There is no disadvantage to paying for the patch in this model, because otherwise you don't get the patch. You are paying someone to write the patch so that it exists in the first place. Otherwise, you can hope that some OSS dev gets to it someday when he gets some spare time. The counter-proposal is not to rely on the free (as in beer) devs, but to hire someone to write OSS patches. This would of course allow your competition to leech off of you. But if others do the same, the benefits may be greater than if everyone is protective of their stuff. Again, I don't want to pretend to know what's best business-wise. Businesses generally don't sink money into stuff that provides them no competitive advantage. Therefore, the counter-proposal is pure fantasy. [...] It _is_ win-win, that's the whole point. It's even win-win-win, to crib a term from The Office, ;) because the OSS project eventually also gets the patch after a delay. I don't think the "win" for the customer is so clear. The "win" that your competitors have to pay, too, seems rather slim to me (remember, not a business guy). And if competitors would buy patches collectively, eliminating the need for an exclusive access period, they could be better off than when each of them pays for it separately. But this may not be realistic, of course. The win for the customer is that they're getting a patch that would not otherwise exist, not sure what's more clear than that. As for competitors, let's say you pay for a bunch of patches which you open-source right away and your competitors use those, then don't pay for any patches of their own. So they save a bunch of money that you're spending, then release their product cheaper than yours. Which company do you think is going to do better? I'm not sure exactly what you by mean by competitors buying patches collectively. If you mean that all the companies pool together and fund OSS development, how do you keep some outlier from not contributing any money, using the resulting OSS code, then undercutting you on price? It is difficult to coordinate companies this way, though I have sometimes pointed out non-profits like Linaro, which are funded by various companies and do something similar. What I think you're describing is possible, but can never garner as much investment as a paid business model. I don't know who this hypothetical competitor is who provides "immediate-access-for-everyone" and is cranking out a ton of patches. They currently don't exist. Neither exists at the moment for D. It's all hypothetica
Re: Game development
On Fri, 09 Jan 2015 05:35:04 + Ras via Digitalmars-d wrote: > On Thursday, 8 January 2015 at 18:03:48 UTC, ketmar via > Digitalmars-d wrote: > > On Thu, 08 Jan 2015 17:31:49 + > > NVolcz via Digitalmars-d wrote: > > > >> engines) and why do you want to write the engine in C++ and > >> the logic in D? > > i bet he thinking that D is a fancy "scripting language with > > native > > performance". > > No i dont. I want to use D language for as much as possible. The > reason I want to use C++ for the engine is that it always has > full support for DirectX. so i was wrong here. i'm sorry. yet you'd better explain your reasons right in the question next time, so other people can jump right to the answering, without guessing first what you *really* want to do and *why*. as you talking about "full support for DirectX", i'm supposing that your engine will support 3D environments? so you'd better start with writing the engine itself, and don't think about D here. just don't use things like multiple inheritance or excessive templating. when you'll get a solid working engine, it will be time to discuss how to build D interop with it, exploiting your engine's architecture as much as possible. or just start writing the engine in D. maybe you'll consider using OpenGL instead of DirectX, as we not only have bindings for OpenGL, but OpenGL is much more portable. so eventually your engine may be ported to MacOS X, for example, without rewriting the whole rendering part. signature.asc Description: PGP signature
Re: Game development
On Thu, 08 Jan 2015 22:27:53 +0100 Joseph Rushton Wakeling via Digitalmars-d wrote: > On 08/01/15 22:02, ketmar via Digitalmars-d wrote: > > am i fobidding someone to reply? O_O > > > > but yes, i want to create an impression that timewasters are not > > welcome. > > Well, it's one thing if you make that decision about people who are in > contact > with you personally. It's a bit different if you are unilaterally deciding > to > make that decision as a member of a collective forum of people, because in > that > case it's a bit of an imposition on the rest of us. and if i'm not reacting, it's painting *me* wrong. > i.e. just because _you've_ decided that he's a timewaster, doesn't make it OK > for you to try and make him feel unwelcome in a forum that belongs to a wider > community. if he is intelligent enough, he will understand that nobody can talk for the whole community, so in the worst case he will ignore myself personally. if he is not intelligent enough... oh, well, as nobody else wants to be a judge, i will be one. i don't feel wrong calling someone "timewaster" if he *is* one. and i can smell 'em from a distance. this has nothing in common with "elitism", though. someone can't sing, someone can't program. both skills can be trained, but not by asking meaningless questions. > Also, I don't know if you've ever had any contact or experience of this > person > in some other online space, but if not, it seems a bit harsh to jump to such > judgement straight away, even if you've previously had bad experiences with > people asking questions in a similar style. it's like a doctor. often good doctor can see that something wrong with another man without taking him to the clinic first. i'm a "timewaster doctor" with a long practice. ;-) yet i'm still waiting for three bells ringing before making my verdict. now i have five bells ringing. signature.asc Description: PGP signature
Re: Game development
On Thu, 8 Jan 2015 21:25:24 + (UTC) Justin Whear via Digitalmars-d wrote: > On Thu, 08 Jan 2015 23:02:26 +0200, ketmar via Digitalmars-d wrote: > > > but yes, i want to create an impression that timewasters are not > > welcome. > > Ironically this is exactly why I'm putting you on my ignored authors list. yet i see that you're still reading my posts and even answering. i have to inform you that your twitlist is not working. T_T signature.asc Description: PGP signature
Re: An idea for commercial support for D
On Tuesday, 6 January 2015 at 22:32:22 UTC, uri wrote: On Tuesday, 6 January 2015 at 13:34:59 UTC, Joakim wrote: Before you make such claims, you should probably think about them a little bit first. Please tell me one company that does not buy outside commercial software which they then use to build their own products. Some companies will want to cherry pick features, others will just buy an accumulated patchset against the point release from many devs. The suggestion that all companies will have to spend a great deal of time picking what patches they want is just silly. To me it doesn't make sense for a company to cherry pick compiler patches. The model you propose may work for applications where there is a clean distinction between user needs and wants but in a compiler you generally need all the features to work effectively and produce reasonable code. The optimizer may be a different story so perhaps that aspect of compilation could be split. Besides splitting the compiler will result in a maintenance headache. Missing features in the compiler will not result in subset-D and complete-D but half-baked-nearly-working-D and working-D, if you're lucky. It really doesn't matter what makes sense to you: a few companies will prefer the lower cost of a custom build and go that route. The compiler is already missing features, shared still has not been implemented to Andrei's spec in his book five years ago and all the bugs mean several features do not work as intended. D is already half-baked: you always have to pick and choose what features you use with a new tech like this, whether employing the current OSS project or with paid patches. This means A and B can't make any money off their patches, so they have to get some other job. That means they only have time to work on M and X on the occasional weekend and each of those patches takes six months to finish. You are obviously okay with that glacial pace as long as you get their work for free, but others are willing to pay to get the pace of D development sped up. This is only true if all patches are equally priced. Otherwise it breaks down and has been proven mathematically. You are referencing my paragraph detailing the current OSS route that _you_ preferred, where there are _no_ prices. If you're referring to the last sentence about paying for D development, I have no idea why you think all patches should be equally priced. If you think anything about business "has been proven mathematically," I can only laugh. :) Glad you brought this up, there are several possibilities. Many users would probably just buy all the closed patches against a point release, so there is no question of splitting features. But a handful of paying customers may be more adventurous, or cheap, ;) and choose to only buy a custom build with their needed features X,Y,Z. This probably wouldn't happen right away, as it will take more time to setup a build process to support it, but supporting custom builds like that is definitely worthwhile. OK, but the D devs still need to split the release between paid patches and non-paid patches. This is non-trivial in a compiler and adds additional work for the volunteers. Companies won't pay for the split because it isn't value adding for them so it will fall on the volunteers. The OSS project and its devs would not have access to the paid patches, as they are _closed-source_, so the only ones doing such maintenance would be the paid devs who wrote them. Once the patches are open-sourced and submitted back upstream, they would need to be maintained by the OSS project, but that is no different from any other OSS patches. As stated earlier, the patches would need to be funded up to some monetary and time limits before they would be released back to the OSS project. So party A might contract with their paying customers that they'll release patches X,Y,Z once they accumulate $5k in payments from all the customers who buy those patches, plus a six month delay after that. If they don't make $5k for a long time, the patches won't be released for a long time. Then I think most OSS users would move on to another language. There is no point working with a compiler that is half-baked unless you pay for it. This is an issue because it's the OSS community that provides ongoing maintenance to the paid for patches. If OSS isn't there anymore then Digital Mars needs to start charging maintenance costs to upkeep the codebase. I don't think that will work, but it's only my opinion. It's _already_ half-baked unless you pay for it, :) ie current companies employing D, like Sociomantic, employ in-house devs to add proprietary features that they pay their employees to develop. Providing paid patches from independent external devs changes nothing in that regard. I have no idea how you think an OSS community would provide maintenance for closed-source patches: t
Re: Game development
On Thursday, 8 January 2015 at 18:03:48 UTC, ketmar via Digitalmars-d wrote: On Thu, 08 Jan 2015 17:31:49 + NVolcz via Digitalmars-d wrote: engines) and why do you want to write the engine in C++ and the logic in D? i bet he thinking that D is a fancy "scripting language with native performance". No i dont. I want to use D language for as much as possible. The reason I want to use C++ for the engine is that it always has full support for DirectX.
Re: An idea for commercial support for D
On Thursday, 8 January 2015 at 23:22:19 UTC, Ola Fosheim Grøstad wrote: On Thursday, 8 January 2015 at 15:27:57 UTC, Joakim wrote: the customer not being very price-sensitive. As for estimating the total cost, the seller also needs to estimate his expected revenue, ie how much demand there is and at what price. With this model, you are allowing the seller to get a better estimate and more certainty. Meanwhile, the buyer takes on more risk, but if he wants that product to exist, he may be willing to do that. Realistically, a software development project can be either: 1. A small project the developer will pick pre-existing tools for, but can afford failure, and possibly let the programmers pick the language as a motivational bonus. Not a customer. 2. A pilot for a larger project evaluating existing tools. Your tool will be one of many, so you need to be "available", or the developer will select another one. 3. A larger/critical project where you get rid of unknown factors before you start. In order to attract a category 3 customer you need to offer something substantial and solid. If it isn't substantial the customer would be better off hiring a local consultant which she or he can bring in whenever they get stuck. I have little idea why you're going into all these detailed business cases that have nothing to do with the two separate concepts I've laid out, but what the hell, I'll bite. D is not ready for 3., I don't see many using it for that. It's mostly 1. and 2., and they will pay some amount for features or polish they need, though obviously not as much as 3. However, D has been used for 3. at Sociomantic, where they were willing to develop a concurrent GC and other features to make it more capable for their particular use. It is possible that other companies would similarly try to use it for 3. but outsource development of such key features that they need, though unlikely, simply because 3. is just a much bigger bet. The you have to consider this: 1. If the feature you want to sell is substantial then it also means you will have to cover the costs until you can deliver. Nobody will pay a large sum in advance unless there is a guarantee (like insurance or a very big company behind it). 2. Maybe only 30% of your products break even. That means you have to recoup all the 70% losses from the profits of those 30%. That means you cannot afford small margins on the features that are useful. That also means that competitors can wait to see what you do and implement them when they see them being successful (which makes it cheaper for them). So you have to offer something that can recoup the costs+losses from other projects in the within the timeframe you have before other solutions pop up. 3. No sane business can afford to give a away a product that is still selling, and if you are able to sell it to N customers today with no marketing, it means that you with more marketing can sell it to N*M customers until a competitor offers a better product. 4. If you have something that sells, it will be better for you to enhance it so that you can charge more for it by giving the customer features they would otherwise not pay for individually. And it will make your product too expensive to wipe out for competitors (the Adobe approach). It's psychological. This is all general business strategy that has essentially nothing to do with the specific ideas in this thread. I'm not sure what connection you're trying to make. I have no idea why you're talking about bugs and performance, as a variable pricing model has nothing to do with those software features. Maybe you're talking about the paid patches idea I laid out earlier, but that's a completely separate concept from this variable pricing model. Suffice to say, paid patches can be written for both bugfixes and performance: I never limited it to just bugfixes. On the contrary, a pricing model and the product is related. Yes, but nobody has proposed this variable pricing model for D. Zach and I were just talking about other pricing models, and I pointed out that this kind of variable pricing can and should be used for all kinds of IP. However, I did not relate it to the earlier paid patches idea. I do think variable pricing will be applied to paid patches someday, but I have not suggested doing it right away. Product differentiation has been the norm for development tools for ages. There is nothing new about it. You identify different market segments and pick the feature set. Then you leave out that one feature that breaks that segments apart (like team features or optimization). Another option is to allow plugins: photoshop, audio/music editors etc, or precompiled libraries. Many tool developers offer additional options to their base product, even if just libraries. Nothing new here. The model you are advocating fits more for the casual market as can be seen
Re: We need a DConf 2015 logo
On 1/8/15 2:40 PM, ponce wrote: There: http://ovh.to/GAYPaom - same vector logo but with text and gray background - a render in 500x150 (I've used Firefox) - instructions on how to render again Let me know if you need any change. Take a look! http://dconf.org https://github.com/D-Programming-Language/dconf.org/pull/31 Andrei
Re: What's missing to make D2 feature complete?
On 2014-12-20 23:27:18 +, aldanor said: - static foreach (declaration foreach) - fixing __traits templates (eg getProtection vein extremely flaky, allMembers not working etc) -- seeing as ctfe is one of flagship features of D, it would make sense to actually make it work flawlessly. This +10. I use this stuff in all my D projects since I learned how to do it, and it's extremely useful -- but very clunky. -S.
Re: For the lulz: ddmd vs libdparse lexer timings
On 2015-01-05 00:50:55 +, Brian Schott said: Looks like it's time to spend some more time with perf: http://i.imgur.com/k50dFbU.png X-axis: Meaningless (Phobos module file names) Y-axis: Time in "hnsecs" (Lower is better) I had to hack the ddmd code to get it compile (more "1337 h4x" were required to compile with LDC than with DMD), so I haven't uploaded the code for the benchmark to Github yet. Both tests were in the same binary and thus had the same compiler flags. I'd be interested to know where libd sits on here. It's lexer is very clever. Props to Amaury or Bernhard (whoever wrote it) -S.
Bare-metal programming in D (was GSOC - Holiday Edition)
On Wednesday, 7 January 2015 at 14:10:49 UTC, Dmitry Olshansky wrote: Truth be told none of listed in this thread feel fundamental to me. It looks more like a set of patches to each specific problem in the compiler or run-time. Yeah, run-time would better be more customizable, but it's just our *current* run-time it's not the language. Perhaps "high-impact" would be a better word than "fundamental". I think moving runtime hooks out of the compiler to .di files and Adam Ruppe's proposal to move TypeInfo to the runtime are great ideas. Enhancement 11666 [1] is another. That really highlighted a design problem in the runtime for me. If the runtime had better separation of language, platform (OS and architecture) and library, the ports would simply have their own folder in the runtime rather than their own repository. The controversy that followed the pull requests in an attempt address 11666 clearly shows the problems that high coupling to the platform can cause. If the platform were encapsulated and decoupled from the language implementation, we'd already be well on our way. [1] - https://issues.dlang.org/show_bug.cgi?id=11666 But I've been watching how such changes are perceived here, and I'm skeptical they would be accepted because so much in the language is potentially affected by them. Due to the fact that they only benefit a few bare-metal folks, but impact the full language, I'm quite confident they would be shunned, and that's been very discouraging. Thus I do not believe that immediate upstreaming of everything bare-metal is even a good thing in principle. In my opinion a Bare-Metal D project can live its life along the upstream D by providing bare-metal versions of each successive version. In fact, we do not have all that many embedded guys in core team. All generally useful patches should find their way in upstream, of course, but it takes time and should *not* be a prerequisite. Sure the bare-metal stuff can exist along-side the upstream repository. That's actually what I alluded to in my previous posts, that bare-metal programming in D will likely need to fork. In fact, due to the lack of support, I don't see it happening any other way. A toolkit will need to provide e.g build/fetch with a bootstrap script: - a ready to-go D cross-compiler(s) might be with some patches to disable language features for better experience etc. That's more-or-less what I've suggested in this thread. If that happened, I could get behind the items you listed below. But I don't know how to proceed with the compiler, that's not my interest nor within my current ability. Johannes has been exploring this territory, however, which is encouraging. - a stripped run-time instead of Phobos (come on C/C++ folks use something much unlike standard library either) - linker scripts for a (growing) set of MCUs - I/O library and register definitions for MCUs (preferably a tool to auto-generate such) - a modified driver that passes all kinds of right options for a given MCU That's a minimum for other Bare Metal D projects to even start to take off. Ideally other tools include debugger, high-level libraries for peripherals (HAL), ports or bindings to C FAT, IP, ... libraries and so on. Let me add that I think the -betterC switch, or similar, is too blunt an instrument. I'd like to have the flexibility to fine tune the language features (even on individual types) for the platform and/or application I'm building. And while compiler switches and attributes may help, I think delegating features from the compiler to the runtime is a better investment. Mike
Re: Alignment of dynamic arrays
On Friday, 9 January 2015 at 00:23:47 UTC, bearophile wrote: Luc Bourhis: With "auto a = new double[1000]", is there any guarantee that a.ptr is aligned on a 16-byte boundary? Arrays are aligned on a 16-byte. Good news! But if you slice them, this alignment can be broken. Yes, of course. It's part of the game to prevent alignment-breaking slices. In past I suggested to put the alignment of an array in the D type system, as an optional extra information (if the alignment is not correct this causes compile-time errors in some cases and some run-time errors when the slicing bounds are runtime values). I like the general idea. But it would seem more natural to me if a slice returned an aligned array if possible, otherwise a misaligned one. Thanks for your thorough answer!
Re: Alignment of dynamic arrays
Luc Bourhis: With "auto a = new double[1000]", is there any guarantee that a.ptr is aligned on a 16-byte boundary? Arrays are aligned on a 16-byte. But if you slice them, this alignment can be broken. In past I suggested to put the alignment of an array in the D type system, as an optional extra information (if the alignment is not correct this causes compile-time errors in some cases and some run-time errors when the slicing bounds are runtime values). Bye, bearophile
Re: Game development
On 9 January 2015 at 02:53, Ras via Digitalmars-d wrote: > Hello, > > I want to write the game engine in C++ and write all the game logic and ai > etc in D. How would i do this? I do this extensively. You can check out how I do D bindings for my engine: https://github.com/TurkeyMan/fuji/tree/master/dist/include/d2/fuji And also a project that uses it: https://github.com/FeedBackDevs/feedback You're welcome to use my engine if you like. It's pretty comprehensive, portable, and it's always nice to have other user feedback. I can also provide some level of engine support.
Alignment of dynamic arrays
With "auto a = new double[1000]", is there any guarantee that a.ptr is aligned on a 16-byte boundary? Indeed I would like to use core.simd and this alignment is paramount for efficient loading from memory to SSE2 registers. On MacOS X and 64-bit Linux, it looks true for dmd. Looking at the implementation of arrays, it seems that it eventually depends on gc_malloc implementation but I could not find the code of that extern(C) function.
NASA/JPL Rules for writing Critical Software
http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf
Re: An idea for commercial support for D
On Thursday, 8 January 2015 at 15:27:57 UTC, Joakim wrote: the customer not being very price-sensitive. As for estimating the total cost, the seller also needs to estimate his expected revenue, ie how much demand there is and at what price. With this model, you are allowing the seller to get a better estimate and more certainty. Meanwhile, the buyer takes on more risk, but if he wants that product to exist, he may be willing to do that. Realistically, a software development project can be either: 1. A small project the developer will pick pre-existing tools for, but can afford failure, and possibly let the programmers pick the language as a motivational bonus. Not a customer. 2. A pilot for a larger project evaluating existing tools. Your tool will be one of many, so you need to be "available", or the developer will select another one. 3. A larger/critical project where you get rid of unknown factors before you start. In order to attract a category 3 customer you need to offer something substantial and solid. If it isn't substantial the customer would be better off hiring a local consultant which she or he can bring in whenever they get stuck. The you have to consider this: 1. If the feature you want to sell is substantial then it also means you will have to cover the costs until you can deliver. Nobody will pay a large sum in advance unless there is a guarantee (like insurance or a very big company behind it). 2. Maybe only 30% of your products break even. That means you have to recoup all the 70% losses from the profits of those 30%. That means you cannot afford small margins on the features that are useful. That also means that competitors can wait to see what you do and implement them when they see them being successful (which makes it cheaper for them). So you have to offer something that can recoup the costs+losses from other projects in the within the timeframe you have before other solutions pop up. 3. No sane business can afford to give a away a product that is still selling, and if you are able to sell it to N customers today with no marketing, it means that you with more marketing can sell it to N*M customers until a competitor offers a better product. 4. If you have something that sells, it will be better for you to enhance it so that you can charge more for it by giving the customer features they would otherwise not pay for individually. And it will make your product too expensive to wipe out for competitors (the Adobe approach). It's psychological. I have no idea why you're talking about bugs and performance, as a variable pricing model has nothing to do with those software features. Maybe you're talking about the paid patches idea I laid out earlier, but that's a completely separate concept from this variable pricing model. Suffice to say, paid patches can be written for both bugfixes and performance: I never limited it to just bugfixes. On the contrary, a pricing model and the product is related. Product differentiation has been the norm for development tools for ages. There is nothing new about it. You identify different market segments and pick the feature set. Then you leave out that one feature that breaks that segments apart (like team features or optimization). Another option is to allow plugins: photoshop, audio/music editors etc, or precompiled libraries. Many tool developers offer additional options to their base product, even if just libraries. Nothing new here. The model you are advocating fits more for the casual market as can be seen in iOS appstore, the "freemium" model. The drug dealer model. You give away a free dose of the drug, then charge for "upgrades" in a slippery slope fashion. Sure, the first to pay will be existing companies using D, but you could attract a lot of new companies with paid patches, as what they really care about is having access to good tools. Ok, but then you are just selling a different compiler which uses DMD as a "framework". So then I don't really understand how that is different from a regular closed source vendor who submit patches when it makes sense for their business.
Re: We need a DConf 2015 logo
On Thursday, 8 January 2015 at 22:40:41 UTC, ponce wrote: There: http://ovh.to/GAYPaom - same vector logo but with text and gray background - a render in 500x150 (I've used Firefox) - instructions on how to render again Let me know if you need any change. I think that is a pretty sweet logo.
Re: We need a DConf 2015 logo
On Thursday, 8 January 2015 at 22:40:41 UTC, ponce wrote: There: http://ovh.to/GAYPaom - same vector logo but with text and gray background - a render in 500x150 (I've used Firefox) - instructions on how to render again Let me know if you need any change. The logo with new the perspective (the text) looks nice. I like it. May I ask if there was any inspiration? E.g I see a reference to the Interstallar movie as it was the best movie of 2014 for me ;) http://www.wired.com/wp-content/uploads/2014/09/Interstellar_ALT_Artowrk-660x1030.jpeg Sorry for being an artist for a while. I prefer to be an engineer ;) Piotrek
Re: MSBUILD 2014, C# gets an ahead of time compiler to native code.
Now I wonder how will runtime template instantiation work. it is not really difficult, but it a bit of work to make it run for example you when you use List you are going to use a specialization of the template such as List which is not template anymore.
Re: We need a DConf 2015 logo
On Wednesday, 7 January 2015 at 23:16:19 UTC, Andrei Alexandrescu wrote: On 1/7/15 3:08 PM, ponce wrote: On Wednesday, 7 January 2015 at 22:36:28 UTC, Andrei Alexandrescu wrote: On 1/7/15 12:26 PM, ponce wrote: On Tuesday, 6 January 2015 at 19:27:23 UTC, Andrei Alexandrescu wrote: The DConf 2015 dates have been confirmed and the site will be soon up - see preview at http://erdani.com/d/bvbvuntf/. Please contribute with a DConf logo image. Also any design updates for the site would be welcome, Thanks! Andrei Attempted one: http://ovh.to/KsMX3qV Thanks! But shouldn't it read "DConf 2015"? -- Andrei I was assuming the website would do that. I see now that in 2014 and 2013 site the logo is appended the text in an image http://dconf.org/2013/images/logo.png which is great for reproducibility, but it does seem possible with CSS. Yah, a logo styled after those with the new dates would be awesome. -- Andrei There: http://ovh.to/GAYPaom - same vector logo but with text and gray background - a render in 500x150 (I've used Firefox) - instructions on how to render again Let me know if you need any change.
Re: Game development
On 1/8/15 1:46 PM, Steven Schveighoffer wrote: On 1/8/15 4:32 PM, Andrei Alexandrescu wrote: The dpl-generated docs are now the default on dlang.org. I don't know what "dpl-generated" means. I'm not seeing any differences. Oh, sorry. They aren't the default yet, but they'll be soon :o). -- Andrei
Re: Game development
If you can't suffer someone's posts, please use your newsreader's filtering features to not see their posts. I know it's not perfect, but by and large it does improve things. Isn't it better for the community to politely reign in those who misbehave? Elitism is terribly damaging, we want D to be what people think of and talk about rather than 'oh, those guys are assholes'.
Re: Game development
On 08/01/15 22:11, market via Digitalmars-d wrote: just gtfo ketmar... just do it. Sorry, no. Not acceptable either.
Re: Game development
On 1/8/15 4:32 PM, Andrei Alexandrescu wrote: The dpl-generated docs are now the default on dlang.org. I don't know what "dpl-generated" means. I'm not seeing any differences. -Steve
Re: Ready to make page-per-item ddocs the default?
On Thu, Jan 08, 2015 at 01:14:43PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: > On 1/8/15 1:01 PM, Steven Schveighoffer wrote: > > > >There are many cases where the members are dependent on the OS. The > >one that strikes me as the most OS dependent (so far) is errno.d. I'm > >guessing that only one of those docs is going to go into the online > >docs? Is there a standard way to make them all show up (with nice > >categories to show which OS they apply to) which is not painful? > > > >If not, then we really need a good way to solve this... An idea might > >be to make a switch that tells the compiler to override it's internal > >predefinitions (e.g. compile with -DWin32 on Linux) just for doc > >generation, and have the resulting page have a way to "flavor" the > >page based on the OS you select or browse from. > > I don't think there is a way. Making ddoc "cross-compilation" work > would be an interesting project, but one of a lower priority. -- [...] It's not just an "interesting" project; it's a pretty important one, seeing that the "std.windows.charset" link on dlang.org has been broken for a long time (probably *years*, by my estimation), just because dlang.org happens to be built on a Linux machine, so none of the Windows module make it into the ddoc pass (and even if they did, they'd be empty due to version(Windows) in the code). Not to mention the tons of other Windows-specific docs that will never make it to dlang.org for the same reason. It's a pretty nice way to turn off Windows users who are trying to find docs on dlang.org. :-P (I'm not a Windows user btw, so this doesn't really bother me in the least. But I'm sure you're probably a lot more concerned about the potential loss of users here.) T -- Heads I win, tails you lose.
Re: Game development
On 1/8/15 1:25 PM, Justin Whear wrote: On Thu, 08 Jan 2015 23:02:26 +0200, ketmar via Digitalmars-d wrote: but yes, i want to create an impression that timewasters are not welcome. Ironically this is exactly why I'm putting you on my ignored authors list. Ironically you're replying to the message you weren't supposed to see :o). All, especially market and ketmar and those who like to get into diatribes: please help maintain a civil atmosphere on this group. We've kept a really nice atmosphere for a long time now, and it's sad to see it's become quite a bit less so in recent times. If you can't suffer someone's posts, please use your newsreader's filtering features to not see their posts. I know it's not perfect, but by and large it does improve things. I'd like to attract your attention to a much more important AND urgent matter. The dpl-generated docs are now the default on dlang.org. Sadly the conversion is imperfect and there are still quite a few issues that stay unresolved, most of them trivially simple and embarrassingly parallelizable. Please join those of us who are chipping in to fix them. Thanks, Andrei
Re: Game development
On Thu, 08 Jan 2015 23:02:26 +0200, ketmar via Digitalmars-d wrote: > but yes, i want to create an impression that timewasters are not > welcome. Ironically this is exactly why I'm putting you on my ignored authors list. --Justin
Re: http://wiki.dlang.org/DIP25
On 1/8/15 4:04 PM, Meta wrote: On Monday, 5 January 2015 at 19:21:38 UTC, Steven Schveighoffer wrote: On 1/5/15 10:05 AM, Meta wrote: IMO, inout (and const/immutable to a degree) is a failure for use with class/struct methods. This became clear to me when trying to use it for the toString implementation of Nullable. You'd have to be more specific for me to understand your point. inout was specifically designed for one-implementation accessors for members of classes/structs. -Steve I cannot remember what the exact issue is now as it was awhile ago, but it had to do with a creating inout/const/immutable Nullables. When doing something such as `Nullable!TestStruct ts; writeln(ts)`, the check inside Nullable.get is triggered instead of calling toString, because toString is not marked as inout/const/immutable. The only solution seems to have a separate version of toString for inout, const, and immutable. It seems that pretty much defeats the point of having inout in the first place. That sounds like the delegate issue. If you are not dealing with delegates, then it works well. Working with inout delegates gets tricky, because it's impossible to refer to inout the type constructor as a parameter to a function without the compiler thinking this is a new invocation of inout. Timon Gehr had ideas on how to fix it, but I don't think anything ever came of it. -Steve
Re: Ready to make page-per-item ddocs the default?
On 1/8/15 1:23 PM, Adam D. Ruppe wrote: On Thursday, 8 January 2015 at 21:14:43 UTC, Andrei Alexandrescu wrote: I don't think there is a way. version(Ddoc) dummy prototypes maybe. But that gets painful. In doc builds we can probably define Windows on Linux etc. Though I think the compiler should NOT do conditional compilation when generating documentation. Instead, I'd prefer to just put it all out and then maybe group. So the doc would actually list the separate entries under all version headers. Not just OS, but arch or custom bits too. Then the user can see it all. Then by attaching classes to the outputted data you could easily do a filter by OS. Yah, as I said it's a project. Andrei
Re: Game development
On 08/01/15 22:02, ketmar via Digitalmars-d wrote: am i fobidding someone to reply? O_O but yes, i want to create an impression that timewasters are not welcome. Well, it's one thing if you make that decision about people who are in contact with you personally. It's a bit different if you are unilaterally deciding to make that decision as a member of a collective forum of people, because in that case it's a bit of an imposition on the rest of us. i.e. just because _you've_ decided that he's a timewaster, doesn't make it OK for you to try and make him feel unwelcome in a forum that belongs to a wider community. Also, I don't know if you've ever had any contact or experience of this person in some other online space, but if not, it seems a bit harsh to jump to such judgement straight away, even if you've previously had bad experiences with people asking questions in a similar style.
Re: Ready to make page-per-item ddocs the default?
On Thursday, 8 January 2015 at 21:14:43 UTC, Andrei Alexandrescu wrote: I don't think there is a way. version(Ddoc) dummy prototypes maybe. But that gets painful. Though I think the compiler should NOT do conditional compilation when generating documentation. Instead, I'd prefer to just put it all out and then maybe group. So the doc would actually list the separate entries under all version headers. Not just OS, but arch or custom bits too. Then the user can see it all. Then by attaching classes to the outputted data you could easily do a filter by OS.
Re: Game development
On Thu, 08 Jan 2015 21:11:47 + market via Digitalmars-d wrote: > On Thursday, 8 January 2015 at 21:03:09 UTC, ketmar via > Digitalmars-d wrote: > > On Thu, 08 Jan 2015 20:56:40 + > > Tobias Pankrath via Digitalmars-d > > wrote: > > > >> On Thursday, 8 January 2015 at 20:15:50 UTC, ketmar via > >> Digitalmars-d wrote: > >> > but i can't see any reason to try to help someone who > >> > doesn't even know > >> > what he wants, and didn't take time to ask a proper > >> > question. been > >> > there, seen that. trying to refine such questions and/or > >> > answer to 'em > >> > is just a waste of time, he will make everyone who's trying > >> > to figure > >> > out what he *really* wants sick and then he will go away. > >> > > >> > >> I'd prefer if you would respond to such people by staying > >> quiet. This has several advantages: > >> > >> • No one accuses you of scaring newbros away > >> • It does not take any of your time > >> • You won't get sick > >> • Only people that spend to much time here in the first > >> place will invest in answering the question* > >> > >> Disadvantages: None. > > i read your opinion. and happily ignored it. > > just gtfo ketmar... just do it. hello, honey! i really miss you! i hope you're ok. please, don't leave me for such a long time... signature.asc Description: PGP signature
Re: 4x4
On 1/8/15 11:48 AM, Johannes Pfau wrote: Am Thu, 08 Jan 2015 10:50:10 -0800 schrieb Andrei Alexandrescu : On 1/8/15 9:16 AM, Kiith-Sa wrote: This is a problem with naming, not with DDox. It would look bad regardless of generator, or regardless of documentation at all. You could make it look slightly less bad, but you might end up hurting other documentation. (I'm not implying it should be renamed (bad reason for breaking compatibility), but I see no point in changing doc generation just because of some bad naming.) Sigh. No matter how I look at it, the same name repeated FOUR times only evokes Java's factory factory etc. -- Andrei These 4x digest variants never occur in real code though: http://dlang.org/library/std/digest/digest/digest.digest.html is a class member function. You never use the full name, it's always instance.digest() http://dlang.org/library/std/digest/digest/digest.html could be used with the full name. But ironically the name is not used outside of std.digest so it's usually not necessary to use the full name. So it doesn't look nice in the docs but it's not a huge problem when writing code. This is a matter common with words that are both noun and verb. "Let's have a Digest object that digests stuff." I think the review should have prompted a name change. -- Andrei
Re: 4x4
On 1/8/15 12:01 PM, eles wrote: On Thursday, 8 January 2015 at 16:19:44 UTC, Johannes Pfau wrote: Am Thu, 08 Jan 2015 07:44:17 -0800 schrieb Andrei Alexandrescu : On 1/8/15 4:46 AM, aldanor wrote: > On Wednesday, 7 January 2015 at 07:09:01 UTC, Andrei > Alexandrescu > wrote: What kind of action would you expect? Renaming a name which has been used for two years now without complaints, simply because it looks bad in the new documentation? I would like to see that wheel start rolling, though. On my personal list: std.uni -> std.unicode stripLeft -> stripFront stripRight -> stripBack Let's leave these alone, thanks. -- Andrei
Re: Game development
On Thursday, 8 January 2015 at 21:03:09 UTC, ketmar via Digitalmars-d wrote: On Thu, 08 Jan 2015 20:56:40 + Tobias Pankrath via Digitalmars-d wrote: On Thursday, 8 January 2015 at 20:15:50 UTC, ketmar via Digitalmars-d wrote: > but i can't see any reason to try to help someone who > doesn't even know > what he wants, and didn't take time to ask a proper > question. been > there, seen that. trying to refine such questions and/or > answer to 'em > is just a waste of time, he will make everyone who's trying > to figure > out what he *really* wants sick and then he will go away. > I'd prefer if you would respond to such people by staying quiet. This has several advantages: • No one accuses you of scaring newbros away • It does not take any of your time • You won't get sick • Only people that spend to much time here in the first place will invest in answering the question* Disadvantages: None. i read your opinion. and happily ignored it. just gtfo ketmar... just do it.
Re: Ready to make page-per-item ddocs the default?
On 1/8/15 1:01 PM, Steven Schveighoffer wrote: There are many cases where the members are dependent on the OS. The one that strikes me as the most OS dependent (so far) is errno.d. I'm guessing that only one of those docs is going to go into the online docs? Is there a standard way to make them all show up (with nice categories to show which OS they apply to) which is not painful? If not, then we really need a good way to solve this... An idea might be to make a switch that tells the compiler to override it's internal predefinitions (e.g. compile with -DWin32 on Linux) just for doc generation, and have the resulting page have a way to "flavor" the page based on the OS you select or browse from. I don't think there is a way. Making ddoc "cross-compilation" work would be an interesting project, but one of a lower priority. -- Andrei
Re: Ready to make page-per-item ddocs the default?
On 1/8/15 10:41 AM, Andrei Alexandrescu wrote: On 1/8/15 4:18 AM, Steven Schveighoffer wrote: Thoughts? I can put together a pull for core.stdc.* if it makes sense. Blurb LGTM, please make it happen. Also let's experiment with the ///'s. Just to put a semaphore on this, I'm partway through doing this, please don't someone else do it too, it's tedious work :) A couple of questions though: core.stdc.config is not technically a standard C header, and it seems pretty strange. I'm going to leave that one alone unless someone objects. There are many cases where the members are dependent on the OS. The one that strikes me as the most OS dependent (so far) is errno.d. I'm guessing that only one of those docs is going to go into the online docs? Is there a standard way to make them all show up (with nice categories to show which OS they apply to) which is not painful? If not, then we really need a good way to solve this... An idea might be to make a switch that tells the compiler to override it's internal predefinitions (e.g. compile with -DWin32 on Linux) just for doc generation, and have the resulting page have a way to "flavor" the page based on the OS you select or browse from. -Steve
Re: http://wiki.dlang.org/DIP25
On Monday, 5 January 2015 at 19:21:38 UTC, Steven Schveighoffer wrote: On 1/5/15 10:05 AM, Meta wrote: IMO, inout (and const/immutable to a degree) is a failure for use with class/struct methods. This became clear to me when trying to use it for the toString implementation of Nullable. You'd have to be more specific for me to understand your point. inout was specifically designed for one-implementation accessors for members of classes/structs. -Steve I cannot remember what the exact issue is now as it was awhile ago, but it had to do with a creating inout/const/immutable Nullables. When doing something such as `Nullable!TestStruct ts; writeln(ts)`, the check inside Nullable.get is triggered instead of calling toString, because toString is not marked as inout/const/immutable. The only solution seems to have a separate version of toString for inout, const, and immutable. It seems that pretty much defeats the point of having inout in the first place.
Re: Game development
On Thu, 08 Jan 2015 20:56:40 + Tobias Pankrath via Digitalmars-d wrote: > On Thursday, 8 January 2015 at 20:15:50 UTC, ketmar via > Digitalmars-d wrote: > > but i can't see any reason to try to help someone who doesn't > > even know > > what he wants, and didn't take time to ask a proper question. > > been > > there, seen that. trying to refine such questions and/or answer > > to 'em > > is just a waste of time, he will make everyone who's trying to > > figure > > out what he *really* wants sick and then he will go away. > > > > I'd prefer if you would respond to such people by staying quiet. > This has several advantages: > > • No one accuses you of scaring newbros away > • It does not take any of your time > • You won't get sick > • Only people that spend to much time here in the first place > will invest in answering the question* > > Disadvantages: None. i read your opinion. and happily ignored it. signature.asc Description: PGP signature
Re: Game development
On Thu, 08 Jan 2015 21:54:46 +0100 Joseph Rushton Wakeling via Digitalmars-d wrote: > On 08/01/15 21:15, ketmar via Digitalmars-d wrote: > > so maybe it's better to ask me and/or try to figure out my behavioral > > patterns before telling me that i'm alienating newcomers? maybe i have > > a solid reasons for acting like this... > > Thing is, you weren't obliged to reply to him at all, and it's not like he > was > singling out as the target of his question. > > If you've decided you don't like him or his question, why not just leave it > be, > let others reply as they will, and not spend any of your time on it? am i fobidding someone to reply? O_O but yes, i want to create an impression that timewasters are not welcome. signature.asc Description: PGP signature
Re: We need a DConf 2015 logo
On Thursday, 8 January 2015 at 15:39:19 UTC, deadalnix wrote: On Wednesday, 7 January 2015 at 20:26:06 UTC, ponce wrote: On Tuesday, 6 January 2015 at 19:27:23 UTC, Andrei Alexandrescu wrote: The DConf 2015 dates have been confirmed and the site will be soon up - see preview at http://erdani.com/d/bvbvuntf/. Please contribute with a DConf logo image. Also any design updates for the site would be welcome, Thanks! Andrei Attempted one: http://ovh.to/KsMX3qV Is that possible to have a direct link ? This force me to download a svg and then go hunting for the file to finally reopen it in my browser. Not through this host and I didn't find an image host accepting .svg.
Re: Game development
On Thursday, 8 January 2015 at 20:15:50 UTC, ketmar via Digitalmars-d wrote: but i can't see any reason to try to help someone who doesn't even know what he wants, and didn't take time to ask a proper question. been there, seen that. trying to refine such questions and/or answer to 'em is just a waste of time, he will make everyone who's trying to figure out what he *really* wants sick and then he will go away. I'd prefer if you would respond to such people by staying quiet. This has several advantages: • No one accuses you of scaring newbros away • It does not take any of your time • You won't get sick • Only people that spend to much time here in the first place will invest in answering the question* Disadvantages: None.
Re: Game development
On 08/01/15 21:15, ketmar via Digitalmars-d wrote: so maybe it's better to ask me and/or try to figure out my behavioral patterns before telling me that i'm alienating newcomers? maybe i have a solid reasons for acting like this... Thing is, you weren't obliged to reply to him at all, and it's not like he was singling out as the target of his question. If you've decided you don't like him or his question, why not just leave it be, let others reply as they will, and not spend any of your time on it?
Re: Game development
On Thu, 08 Jan 2015 19:41:07 + Phil via Digitalmars-d wrote: > This isn't the best way to get more people involved in the D > community... he doesn't come here for D, nor for doing something productive even for himself. i know this type by their first words. you can see me willingly helping people that come for something, even with simple/newb questions. but i can't see any reason to try to help someone who doesn't even know what he wants, and didn't take time to ask a proper question. been there, seen that. trying to refine such questions and/or answer to 'em is just a waste of time, he will make everyone who's trying to figure out what he *really* wants sick and then he will go away. so maybe it's better to ask me and/or try to figure out my behavioral patterns before telling me that i'm alienating newcomers? maybe i have a solid reasons for acting like this... signature.asc Description: PGP signature
Re: Game development
On Thu, Jan 08, 2015 at 07:41:07PM +, Phil via Digitalmars-d wrote: > On Thursday, 8 January 2015 at 18:03:48 UTC, ketmar via Digitalmars-d wrote: > >On Thu, 08 Jan 2015 17:31:49 + > >NVolcz via Digitalmars-d wrote: > > > >>engines) and why do you want to write the engine in C++ and the > >>logic in D? > >i bet he thinking that D is a fancy "scripting language with native > >performance". > > This isn't the best way to get more people involved in the D > community... He does not speak for the rest of us. T -- Answer: Because it breaks the logical sequence of discussion. Question: Why is top posting bad?
Re: 4x4
On Thursday, 8 January 2015 at 16:19:44 UTC, Johannes Pfau wrote: Am Thu, 08 Jan 2015 07:44:17 -0800 schrieb Andrei Alexandrescu : On 1/8/15 4:46 AM, aldanor wrote: > On Wednesday, 7 January 2015 at 07:09:01 UTC, Andrei > Alexandrescu > wrote: What kind of action would you expect? Renaming a name which has been used for two years now without complaints, simply because it looks bad in the new documentation? I would like to see that wheel start rolling, though. On my personal list: std.uni -> std.unicode stripLeft -> stripFront stripRight -> stripBack
Re: 4x4
Am Thu, 08 Jan 2015 10:50:10 -0800 schrieb Andrei Alexandrescu : > On 1/8/15 9:16 AM, Kiith-Sa wrote: > > > > This is a problem with naming, not with DDox. It would look bad > > regardless of generator, or regardless of documentation at all. You > > could make it look slightly less bad, but you might end up hurting > > other documentation. (I'm not implying it should be renamed (bad > > reason for breaking compatibility), but I see no point in changing > > doc generation just because of some bad naming.) > > Sigh. No matter how I look at it, the same name repeated FOUR times > only evokes Java's factory factory etc. -- Andrei These 4x digest variants never occur in real code though: http://dlang.org/library/std/digest/digest/digest.digest.html is a class member function. You never use the full name, it's always instance.digest() http://dlang.org/library/std/digest/digest/digest.html could be used with the full name. But ironically the name is not used outside of std.digest so it's usually not necessary to use the full name. So it doesn't look nice in the docs but it's not a huge problem when writing code.
Re: Game development
This isn't the best way to get more people involved in the D community... On Thursday, 8 January 2015 at 18:03:48 UTC, ketmar via Digitalmars-d wrote: On Thu, 08 Jan 2015 17:31:49 + NVolcz via Digitalmars-d wrote: engines) and why do you want to write the engine in C++ and the logic in D? i bet he thinking that D is a fancy "scripting language with native performance".
Re: 4x4
On Thu, Jan 08, 2015 at 10:50:10AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: > On 1/8/15 9:16 AM, Kiith-Sa wrote: > > > >This is a problem with naming, not with DDox. It would look bad > >regardless of generator, or regardless of documentation at all. You > >could make it look slightly less bad, but you might end up hurting > >other documentation. (I'm not implying it should be renamed (bad > >reason for breaking compatibility), but I see no point in changing > >doc generation just because of some bad naming.) > > Sigh. No matter how I look at it, the same name repeated FOUR times > only evokes Java's factory factory etc. -- Andrei Yes, good ole Java verbosity with class Chocolate, class ChocolateFactory, class ChocolateFactoryFactory, class ChocolateWrapper, class ChocolateWrapperFactory, class ChocolateWrapperFactoryFactoryWrapper, ad nauseaum. Utterly delicious. :-P T -- It won't be covered in the book. The source code has to be useful for something, after all. -- Larry Wall
Re: 4x4
On 1/8/15 9:16 AM, Kiith-Sa wrote: This is a problem with naming, not with DDox. It would look bad regardless of generator, or regardless of documentation at all. You could make it look slightly less bad, but you might end up hurting other documentation. (I'm not implying it should be renamed (bad reason for breaking compatibility), but I see no point in changing doc generation just because of some bad naming.) Sigh. No matter how I look at it, the same name repeated FOUR times only evokes Java's factory factory etc. -- Andrei
Re: json generation from ddoc: painfully close
On Thu, Jan 08, 2015 at 12:32:10AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
> I just experimented with a battery of macros (json.ddoc) for generating json
> via ddoc. Results for std.algorithm are in
> http://paste.ofcode.org/DFnxChvmRGJiXYpYYk2XWr.
>
> There are a couple of things that make the generated json invalid:
>
> 1. I couldn't get escaping to work. My ESCAPES is:
>
> ESCAPES=/\/\\/ /"/\"/ /&/&/ //>/
>
> So single backslashes will be doubled and quotes will be backslashed.
> Nice. The trouble is, escaping only does its job sometimes but not
> always. I haven't yet figured the circumstances.
About time somebody acknowledged that Ddoc's escaping mechanism leaves
much to be desired!
> 2. This was mentioned before - paragraph, whitespace and especially
> newline handling are handled rather poorly in ddoc. The generated json
> is full of newlines in the middle of strings, which are invalid in
> json (\n must be used). I think every paragraph should be enclosed in
> a $(DDOC_PARAGRAPH) macros that has single newlines replaced with
> spaces. Alternatively, a built-in macro could escape strings
> appropriately.
Yep, also known for a long time and only now ackowledged:
https://issues.dlang.org/show_bug.cgi?id=9731
> 3. Some descriptions feature multiple examples, leading to duplicate
> "DDOC_EXAMPLES" keys. Json strongly discourages (at least) duplicate
> keys in objects. There is no way to have some autoincrement thing that
> generates "DDOC_EXAMPLES_1", "DDOC_EXAMPLES_2" etc. It could be argued
> that that's an issue with the source, not the generator.
[...]
I disagree there's any issue with the source. The current system allows
the very nice idiom of:
/// ... some docs here
auto myFunc(...) { ... }
/// This example shows feature X of myFunc.
unittest { ... }
/// This example shows feature Y of myFunc.
unittest { ... }
The generated docs read like this:
auto myFunc(...);
... some docs here
This example shows feature X of myFunc.
... [first example here]
This example shows feature Y of myFunc.
... [second example here]
This is much more meaningful than a single gigantic example block that
the reader has to parse in his head in order to get through everything
being showcased.
Of course, the mechanics of it can be improved -- ddoc should know
better than to use the same heading "Examples:" over and over. Perhaps,
in terms of the underlying macros, it should have some kind of
autoincrementing label for each ddoc'd unittest block.
T
--
Stop staring at me like that! It's offens... no, you'll hurt your eyes!
Re: Game development
On Thu, 08 Jan 2015 17:31:49 + NVolcz via Digitalmars-d wrote: > engines) and why do you want to write the engine in C++ and the > logic in D? i bet he thinking that D is a fancy "scripting language with native performance". signature.asc Description: PGP signature
Re: Another init() bug, can we deprecate yet?
On Thu, Jan 08, 2015 at 09:46:16AM +, Peter Alexander via Digitalmars-d wrote: > On Wednesday, 7 January 2015 at 23:31:30 UTC, H. S. Teoh via Digitalmars-d > wrote: > >On Wed, Jan 07, 2015 at 10:03:00PM +, Peter Alexander via > >Digitalmars-d wrote: > >>https://issues.dlang.org/show_bug.cgi?id=13806 > >> > >>For the lazy: BitArray has an init() method, which hides the > >>property BitArray.init > >> > >>This, or something similar, appears every few months. Walter has > >>said in the past that the ability to override init is a feature. As > >>far as I can tell, no one is using it as a feature; it only seems to > >>cause trouble. > >> > >>Can we just deprecate it? At the very least deprecate functions > >>named init(). > > > >https://github.com/D-Programming-Language/phobos/pull/2854 > > > >Destroy! > > Thanks. Just to be clear, I'm advocating deprecating all user-defined > init functions, not just BitArray (so we don't get into this situation > again). Yes, but purging it from Phobos first is a first step towards that eventual goal. :-) T -- Береги платье снову, а здоровье смолоду.
Re: Game development
On Thursday, 8 January 2015 at 16:53:46 UTC, Ras wrote: Hello, I want to write the game engine in C++ and write all the game logic and ai etc in D. How would i do this? I would not recommend writing a game engine (make games not engines) and why do you want to write the engine in C++ and the logic in D? I suspect that it is easier to write everything in the same language. There are several D gamedev frameworks and engine out there, http://code.dlang.org/, there are projects that don't use dub (fuji for example). But some of them are certainly not up to date so you will have to check the commit logs for activity. Best regards, NVolcz
Re: For the lulz: ddmd vs libdparse lexer timings
"Daniel Murphy" wrote in message news:m8eihu$21to$1...@digitalmars.com... I'll run some more extensive tests tomorrow, and then have a look at some other platforms. The problem with using a fuzz tester to verify the new varargs implementation is I need to fix all the existing ABI bugs first.
Re: 4x4
On Thursday, 8 January 2015 at 16:27:48 UTC, Andrei Alexandrescu wrote: On 1/8/15 8:19 AM, Johannes Pfau wrote: What kind of action would you expect? Renaming a name which has been used for two years now without complaints, simply because it looks bad in the new documentation? As we usually don't rename functions with inconsistent naming or otherwise bad names because of backwards compatibility (TM) I guess that's not what you want. OTOH I'm not sure if ddox could be much improved in this regard. Maybe it shouldn't display the full name, only Class.member. But I don't really know what you expect. I was thinking along the way of simplifying documentation and links. -- Andrei This is a problem with naming, not with DDox. It would look bad regardless of generator, or regardless of documentation at all. You could make it look slightly less bad, but you might end up hurting other documentation. (I'm not implying it should be renamed (bad reason for breaking compatibility), but I see no point in changing doc generation just because of some bad naming.)
Re: Game development
On Thursday, 8 January 2015 at 16:53:46 UTC, Ras wrote: Hello, I want to write the game engine in C++ and write all the game logic and ai etc in D. How would i do this? Manu Evans has pretty much this, he's active on this newsgroup, maybe he can help you: https://github.com/TurkeyMan/fuji . But "writing a game engine" is not something you can simply do quickly or that someone can do for you. It can take years depending on what the engine is supposed to do. Connecting C++ with D is a trivial detail compared to all the work involved.
Re: Game development
On Thu, 08 Jan 2015 16:53:45 + Ras via Digitalmars-d wrote: > Hello, > > I want to write the game engine in C++ and write all the game > logic and ai etc in D. How would i do this? first, you have to write your game engine in C++. just fire your favorite text editor and start coding. second, you have to write your game logic in D. just fire your favorite text editor and start coding. third: now you have to connect the first and the second, but don't be afraid: you will never come to this part, actually. signature.asc Description: PGP signature
Game development
Hello, I want to write the game engine in C++ and write all the game logic and ai etc in D. How would i do this?
Re: An idea for commercial support for D
On Thursday, 8 January 2015 at 10:37:57 UTC, Joakim wrote: You're on the right track: I've talked in the past about a more advanced version of such a pricing model, that could be used for any intellectual property, not just for software. How it would work is that the developer sets a price for all the work to develop the feature, say $3k, and picks a reasonable minimum amount of customers, say 20. So he then sets the initial price at $150, which may seem high for a single feature. But assuming he gets to 20 customers, the price drops for each subsequent customer, and the first 20 get a proportionate refund. So when he gets to 30 customers, each of the last 10 to buy get charged $100, not $150, and each of the first 20 customers get their prices dropped to $100, so that the total for the developer is always $3k. Right now, this may work better for an up-front payment model, say on a site like kickstarter, or some such marketplace where the customers have ongoing accounts and it's easy to credit money back to them without having to keep issuing refunds to their payment provider, avoiding the accompanying fees. What are the advantages of such a model? Another advantage is that the developer avoids being perceived as a money-grubbing scoundrel, which seems to be a significant issue in open-source development. There seems to be a moral hazard if a developer, whose work is not substantially different in quality or quantity from the work of myriad others who contribute for free, stands to reap royalties indefinitely. Actually, this could work even with the existing developers. A marketplace is opened where developers offer features they would be willing to work on. It's like the bounty system but where developers also have a say in letting customers know what they'd be willing to do. The functionality of this system relies on the devastating fact that while hobbyists would like to always work on their own pet projects for free, they also need money just as much. This gives a way to compromise between what customers (bounty posters, i.e.) want, and what developers want, saying what they'd be willing to divert their attention towards if the price was right. And, seeing that actual money was to be made in programming for the D community, more programmers might just start jumping in. The big key is to make it so hobbyists who already contribute so much great work for free don't feel in any way abused. Inviting them to post their own offers on the marketplace might actually work. I mean, isn't the real problem with the bounty system that existing developers with the time and resources to do great work don't even really have a say, other than "yes" or "no"? Well, that and it's not always perfectly clear when the terms of a bounty have been met, due to more parties than just the developer and the customer being involved. This kind of variable pricing model would have been too costly decades ago, with all the paper bookkeeping and chargebacks. It would be trivial to implement today though and would be a much better model for many products. Yeah, the internet's great. Why isn't it done already? People are stupid, no other reason. Or, they are distrustful of new ideas, afraid of change, and need to be shown good things first - all of which are perfectly understandable. Also, don't tell people they're stupid... it's bad for business! :-)
Re: 4x4
Am Thu, 08 Jan 2015 08:27:50 -0800 schrieb Andrei Alexandrescu : > On 1/8/15 8:19 AM, Johannes Pfau wrote: > > What kind of action would you expect? Renaming a name > > which has been used for two years now without complaints, simply > > because it looks bad in the new documentation? > > > > As we usually don't rename functions with inconsistent naming or > > otherwise bad names because of backwards compatibility (TM) I guess > > that's not what you want. OTOH I'm not sure if ddox could be much > > improved in this regard. Maybe it shouldn't display the full name, > > only Class.member. But I don't really know what you expect. > > I was thinking along the way of simplifying documentation and links. > -- Andrei I guess that should be done by somebody familiar with the ddox codebase then. Two small improvements that could help: * Make names/filenames case sensitive * display only shortened names (Class.member, Module.member) This leaves the URL/link problem but I don't know how that could be solved.
Re: 4x4
On 1/8/15 8:19 AM, Johannes Pfau wrote: What kind of action would you expect? Renaming a name which has been used for two years now without complaints, simply because it looks bad in the new documentation? As we usually don't rename functions with inconsistent naming or otherwise bad names because of backwards compatibility (TM) I guess that's not what you want. OTOH I'm not sure if ddox could be much improved in this regard. Maybe it shouldn't display the full name, only Class.member. But I don't really know what you expect. I was thinking along the way of simplifying documentation and links. -- Andrei
Re: 4x4
Am Thu, 08 Jan 2015 07:44:17 -0800 schrieb Andrei Alexandrescu : > On 1/8/15 4:46 AM, aldanor wrote: > > On Wednesday, 7 January 2015 at 07:09:01 UTC, Andrei Alexandrescu > > wrote: > >> http://dlang.org/library/std/digest/digest/digest.html > >> > >> Ugh. -- Andrei > > > > This thread needs more digest: > > > > http://dlang.org/library/std/digest/digest/digest.digest.html > > Heh. Alright, any lieutenant who could get on this? > > There's a sense of urgency - these pages are live now. > > > Andrei > What kind of action would you expect? Renaming a name which has been used for two years now without complaints, simply because it looks bad in the new documentation? As we usually don't rename functions with inconsistent naming or otherwise bad names because of backwards compatibility (TM) I guess that's not what you want. OTOH I'm not sure if ddox could be much improved in this regard. Maybe it shouldn't display the full name, only Class.member. But I don't really know what you expect.
Re: Ready to make page-per-item ddocs the default?
On 1/8/15 4:18 AM, Steven Schveighoffer wrote: On 1/6/15 8:16 PM, Andrei Alexandrescu wrote: On 1/6/15 3:44 PM, weaselcat wrote: On Tuesday, 6 January 2015 at 22:43:45 UTC, Andrei Alexandrescu wrote: Let's crowdsource the review. Please check the entries linked from here: http://dlang.org/library/index.html. Andrei Is it intentional for all of the stdc pages to be empty? It's a somewhat unfortunate fallout of the level of granularity. I think each of these headers should include a standard text and a link to some good documentation in C-land. -- Andrei I like this idea. One thing that may be misleading about this -- our headers don't include *everything* from C-land. What would be a good generic blurb? strawman: core.stdc.ctype: "This contains bindings to selected types and functions from the standard C header (see http://pubs.opengroup.org/onlinepubs/009695399/basedefs/ctype.h.html). Note that this is not automatically generated, and may omit some types/functions from the original C header." I'm thinking we should actually just put a /// before every symbol, to get it in the ddoc so you can see what *is* included. Thoughts? I can put together a pull for core.stdc.* if it makes sense. Blurb LGTM, please make it happen. Also let's experiment with the ///'s. If we get real cocky we might insert for each symbol a LUCKY link googling for the header name and symbol name. Thanks! -- Andrei
Re: Ready to make page-per-item ddocs the default?
On 1/8/15 4:31 AM, Steven Schveighoffer wrote: I think anyone who has commit rights to any D project should be made moderator so they can stomp out trolls, remove fleeting/simple questions (after nudging towards d.learn), etc. Sönke could do this I think. -- Andrei
Re: 4x4
On 1/8/15 4:46 AM, aldanor wrote: On Wednesday, 7 January 2015 at 07:09:01 UTC, Andrei Alexandrescu wrote: http://dlang.org/library/std/digest/digest/digest.html Ugh. -- Andrei This thread needs more digest: http://dlang.org/library/std/digest/digest/digest.digest.html Heh. Alright, any lieutenant who could get on this? There's a sense of urgency - these pages are live now. Andrei
Re: We need a DConf 2015 logo
On Wednesday, 7 January 2015 at 20:26:06 UTC, ponce wrote: On Tuesday, 6 January 2015 at 19:27:23 UTC, Andrei Alexandrescu wrote: The DConf 2015 dates have been confirmed and the site will be soon up - see preview at http://erdani.com/d/bvbvuntf/. Please contribute with a DConf logo image. Also any design updates for the site would be welcome, Thanks! Andrei Attempted one: http://ovh.to/KsMX3qV Is that possible to have a direct link ? This force me to download a svg and then go hunting for the file to finally reopen it in my browser.
Re: An idea for commercial support for D
On Thursday, 8 January 2015 at 12:06:18 UTC, Ola Fosheim Grøstad wrote: On Thursday, 8 January 2015 at 10:37:57 UTC, Joakim wrote: supply/demand curve for his product. In this variable pricing model, the customer also takes some of that risk, ie you'll pay more if enough other people don't also want the product. Businesses don't like risk. They need to estimate the total cost before starting the project. I don't think you can advertising "less bugs" as a feature. It has to be a real feature like better performance. Yes, I've already established the risk aspect, this variable pricing model is fundamentally about better risk sharing and the customer not being very price-sensitive. As for estimating the total cost, the seller also needs to estimate his expected revenue, ie how much demand there is and at what price. With this model, you are allowing the seller to get a better estimate and more certainty. Meanwhile, the buyer takes on more risk, but if he wants that product to exist, he may be willing to do that. I have no idea why you're talking about bugs and performance, as a variable pricing model has nothing to do with those software features. Maybe you're talking about the paid patches idea I laid out earlier, but that's a completely separate concept from this variable pricing model. Suffice to say, paid patches can be written for both bugfixes and performance: I never limited it to just bugfixes. Your assumption is that businesses start on a project and then later discover that they cannot work within the limits of the tools and are willing to pay a premium for it. Sure, that is possible, but your business model is flawed because it is based on your customers having a embarked on a project with a flawed plan in order to become a customer. I assume nothing about when a business discovers limits. Presumably you're talking about the completely unrelated paid patches idea here, but if D becomes much more capable because of paid patches, companies will be much more willing to come in new and use D, regardless of whether they have to pay or not. Sure, the first to pay will be existing companies using D, but you could attract a lot of new companies with paid patches, as what they really care about is having access to good tools.
Re: const Propagation
On 1/7/15 1:27 PM, Julian Kranz wrote: On Monday, 29 December 2014 at 20:24:13 UTC, Steven Schveighoffer wrote: OK, it's not inferring the const on 'this'. It ONLY does this if you have a 'this' template parameter in the template list. This works: void blah(T, this _)(void function(T t) f) interesting, can someone explain this requirement? I'd really like to know that, too ;-). Thank you again for all your answers! Yeah, I think this is a missed opportunity. 1. A template is (most of the time) automatically not virtual. 2. If a template can be inferred const or inout, it can be called with more instances for free. 3. In some cases, when the template parameters itself may determine the ability of the function to be const or not, it's not possible to slap a "const" on there, or split it up. I notice there are already a couple of reports about this: https://issues.dlang.org/show_bug.cgi?id=7521 https://issues.dlang.org/show_bug.cgi?id=8407 -Stev
Re: BNF grammar for D?
On 22/12/2014 11:44, Kingsley wrote: Hi Bruno - would be easy to return the list of tokens included for each node in the DeeParser? You can create an utility method that does that, if you have a DeeParseResult. The DeeParseResult has a 'tokenList' member, ordered by the source range. With a node's source range, you can do a binary search in that list to find the corresponding tokens. For more convenience, I guess DeeParser could be modified so that this information - in the form of a sublist of 'tokenList' - would be stored directly in each ASTNode, in the 'data' field. This way one would not need to provide the DeeParseResult directly. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: BNF grammar for D?
On 21/12/2014 00:34, Kingsley wrote: On Friday, 19 December 2014 at 02:53:02 UTC, Rikki Cattermole wrote: On 19/12/2014 10:19 a.m., Kingsley wrote: On Wednesday, 17 December 2014 at 21:05:05 UTC, Kingsley wrote: Hi Bruno, Thanks very much. I do have a couple of questions about DDT in relation to my plugin. Firstly - I'm not too familiar with parsing/lexing but at the moment the Psi Structure I have implemented that comes from the DDT parser/lexer is not in any kind of hierarchy. All the PsiElements are available but all at the same level. Is this how the DDT parser works? Or is it down to my implementation of the Parser/Lexer that wraps it to create some hierarchy. For intellij it's going to be vastly easier to have a hierarchy with nested elements in order to get hold of a structure representing a class or a function for example - in order to do things like get the start and end lines of a class definition in order to apply code folding and to use for searching for classes and stuff. Secondly - how active it the development of DDT - does it keep up with the D2 releases. --Kingsley After doing a bit more research it looks like I have to create the psi hierarchy myself - my current psi structure is flat because I'm just converting the DeeTokens into PsiElements directly. I've still got some experimentation to do. On the plus side I implemented commenting, code folding but everything else needs a psi hierarchy I've done some more investigation and I do need to build the parser myself in order to create the various constructs. I've made a start but I haven't gotten very far yet because I don't fully understand the correct way to proceed. I also had a look at using the DeeParser - because it already does most of what I want. However the intellij plugin wants a PsiParser which returns an intellij ASTNode in the primary parse method. I can't see an easy way to hook this up with DeeParser because the ParsedResult although had a node method on it - gives back the wrong type of ASTNode. Any pointers on how I might get the DeeParser to interface to an intellij ASTNode would be appreciated. Read my codebase again, it'll answer a lot of questions. Your parser is different, but what it produces shouldn't be. and yes it supports hierarchies. Hi So finally after a lot of wrestling with the internals of intellij I finally managed to get a working parser implementation that produces a psi hierarchy based on the DeeParser from the ddt code. The main issue was that Intellij only wants you to create a parser using their toolset - which is either with a BNF grammar that you can then generate the parser - or with a hand written parser. Since I'm already using the DDT lexer and there is a perfectly good DDT parser as well - I just wanted to re-use the DDT parser. However Intellij does not provide any way to create a custom AST/PSI structure or use an external parser. So I basically had to wrap the DeeParse inside the Intellij parser and sync them up programmatically. It's not the most efficient way in the world but it at least works. In the long term I will write a BNF grammar for Intellij (using their toolkit) but I can see that will take me several months so this is a quick way to get the plugin up and running with all the power of intellij extras without spending several months stuck learning all about the complexities of grammar parsing and lexing. Thanks very much for you help. Once I get a bit more of the cool stuff done I will release the plugin. Again, I'm not familiar with Intellij internals or the PSI structure, so I don't know how the DDT parser can be adapted to that. However, I do suspect there should be a way to create a PSI structure from the DDT ASTNode structure. PS: Sorry for the long delay in replying, I don't often check the digitalmars.D newsgroup/forum, and can sometimes be behind on the posts there. If you want to grab my attention, better to post on digitalmars.D.ide as I keep a closer eye on that newsgroup. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: BNF grammar for D?
On 17/12/2014 17:19, Kingsley wrote: Secondly - how active it the development of DDT - does it keep up with the D2 releases. Yes, it keeps up, and I plan to keep that up for the foreseeable future. (Since language grammar changes are fairly uncommon, and easy to implement when they happen). -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: 4x4
On Wednesday, 7 January 2015 at 07:09:01 UTC, Andrei Alexandrescu wrote: http://dlang.org/library/std/digest/digest/digest.html Ugh. -- Andrei This thread needs more digest: http://dlang.org/library/std/digest/digest/digest.digest.html
Re: Ready to make page-per-item ddocs the default?
On 1/7/15 10:55 AM, Vladimir Panteleev wrote: On Wednesday, 7 January 2015 at 15:42:24 UTC, Andrei Alexandrescu wrote: * I still have reservations about using Disqus. I did keep that in mind. The long and short of it it it's impossible to make a change that everybody likes. We must move forward. I agree, it might very well be the least of all evils. Just a thought on this -- from personal experience I like disqus quite a lot for commenting on fleeting topics, such as blog posts or articles. But these are quite static pages. However, I've benefited greatly from e.g. php doc comments which show ways to solve problems I am trying to solve. So I think we should keep these for that purpose. We have several issues to consider with disqus (or any commenting system): Inevitably, questions about the docs will be asked. If nobody looks at the docs (and let's face it, most of our veterans do not look at the docs every day), then the perception is that nobody is listening. Can we at least forward the posts to a NG/mailing list? I doubt such questions would happen frequently. I think anyone who has commit rights to any D project should be made moderator so they can stomp out trolls, remove fleeting/simple questions (after nudging towards d.learn), etc. There is going to be a push at some point to split up docs (e.g. std.datetime), is it possible to move a disqus comment from one page to another? -Steve
Re: 4x4
On 1/7/15 2:09 AM, Andrei Alexandrescu wrote: http://dlang.org/library/std/digest/digest/digest.html Ugh. -- Andrei I remember this from the movie "being std.digest" when digest goes through the tunnel and becomes himself. -Steve
Re: Ready to make page-per-item ddocs the default?
On Thursday, 8 January 2015 at 12:18:37 UTC, Steven Schveighoffer wrote: On 1/6/15 8:16 PM, Andrei Alexandrescu wrote: On 1/6/15 3:44 PM, weaselcat wrote: On Tuesday, 6 January 2015 at 22:43:45 UTC, Andrei Alexandrescu wrote: Let's crowdsource the review. Please check the entries linked from here: http://dlang.org/library/index.html. Andrei Is it intentional for all of the stdc pages to be empty? It's a somewhat unfortunate fallout of the level of granularity. I think each of these headers should include a standard text and a link to some good documentation in C-land. -- Andrei I like this idea. One thing that may be misleading about this -- our headers don't include *everything* from C-land. What would be a good generic blurb? strawman: core.stdc.ctype: "This contains bindings to selected types and functions from the standard C header (see http://pubs.opengroup.org/onlinepubs/009695399/basedefs/ctype.h.html). Note that this is not automatically generated, and may omit some types/functions from the original C header." I'm thinking we should actually just put a /// before every symbol, to get it in the ddoc so you can see what *is* included. Thoughts? I can put together a pull for core.stdc.* if it makes sense. -Steve All public symbols in any module should have a ddoc comment, even if said comment is empty. Does that sound like a reasonable rule-of-thumb?
Re: Ready to make page-per-item ddocs the default?
On 2015-01-08 13:18, Steven Schveighoffer wrote: I like this idea. One thing that may be misleading about this -- our headers don't include *everything* from C-land. What would be a good generic blurb? strawman: core.stdc.ctype: "This contains bindings to selected types and functions from the standard C header (see http://pubs.opengroup.org/onlinepubs/009695399/basedefs/ctype.h.html). Note that this is not automatically generated, and may omit some types/functions from the original C header." I'm thinking we should actually just put a /// before every symbol, to get it in the ddoc so you can see what *is* included. Thoughts? I can put together a pull for core.stdc.* if it makes sense. I like it. -- /Jacob Carlborg
Re: Ready to make page-per-item ddocs the default?
On 1/6/15 8:16 PM, Andrei Alexandrescu wrote: On 1/6/15 3:44 PM, weaselcat wrote: On Tuesday, 6 January 2015 at 22:43:45 UTC, Andrei Alexandrescu wrote: Let's crowdsource the review. Please check the entries linked from here: http://dlang.org/library/index.html. Andrei Is it intentional for all of the stdc pages to be empty? It's a somewhat unfortunate fallout of the level of granularity. I think each of these headers should include a standard text and a link to some good documentation in C-land. -- Andrei I like this idea. One thing that may be misleading about this -- our headers don't include *everything* from C-land. What would be a good generic blurb? strawman: core.stdc.ctype: "This contains bindings to selected types and functions from the standard C header (see http://pubs.opengroup.org/onlinepubs/009695399/basedefs/ctype.h.html). Note that this is not automatically generated, and may omit some types/functions from the original C header." I'm thinking we should actually just put a /// before every symbol, to get it in the ddoc so you can see what *is* included. Thoughts? I can put together a pull for core.stdc.* if it makes sense. -Steve
Re: Ready to make page-per-item ddocs the default?
On 1/7/15 1:03 AM, Andrei Alexandrescu wrote: On 1/6/15 6:17 PM, Steven Schveighoffer wrote: On 1/6/15 5:43 PM, Andrei Alexandrescu wrote: Let's crowdsource the review. Please check the entries linked from here: http://dlang.org/library/index.html. std.algorithm has many of the "descriptions" showing samples. Also, I know the table at the top is to make things easier for standard ddoc, should that be removed? But I like it. It's redundant. Right below is the same exact info (see "Cheat sheet"). BTW, I'm all for the docs to be switched. Just the cross-referencing alone is worth it. One thing we need to do is offer for each module "view as one page" so people still have that option. That would be nice. In fact, I would recommend for when javascript is enabled, a way to "expand" a function/class inline. -Steve
Re: MSBUILD 2014, C# gets an ahead of time compiler to native code.
On Thursday, 8 January 2015 at 11:53:37 UTC, ponce wrote: On Wednesday, 2 April 2014 at 20:23:58 UTC, Paulo Pinto wrote: So it finally happened, C# gets an AOT compiler in addition to NGEN/JIT as part of standard Visual Studio tools. http://techcrunch.com/2014/04/02/microsoft-updates-visual-studio-with-support-for-universal-projects-typescript-1-0-and-net-native-code-compilation/ More information will be provided in the native sessions tomorrow and on Friday. Posting this as it has direct implications into D's adoption. -- Paulo Now I wonder how will runtime template instantiation work. Either they are using the existing solution done by NGEN/JIT, C++ style for value types and erasure for reference types, or the full C++ way. The compiler also uses heuristics for reflection, failing that you can list which classes are the target of runtime reflection, so that their metadata isn't thrown away. http://blogs.msdn.com/b/dotnet/archive/2014/05/21/net-native-deep-dive-help-i-hit-a-missingmetadataexception.aspx .. Paulo
Re: An idea for commercial support for D
On Thursday, 8 January 2015 at 10:37:57 UTC, Joakim wrote: supply/demand curve for his product. In this variable pricing model, the customer also takes some of that risk, ie you'll pay more if enough other people don't also want the product. Businesses don't like risk. They need to estimate the total cost before starting the project. I don't think you can advertising "less bugs" as a feature. It has to be a real feature like better performance. Your assumption is that businesses start on a project and then later discover that they cannot work within the limits of the tools and are willing to pay a premium for it. Sure, that is possible, but your business model is flawed because it is based on your customers having a embarked on a project with a flawed plan in order to become a customer.
Re: MSBUILD 2014, C# gets an ahead of time compiler to native code.
On Wednesday, 2 April 2014 at 20:23:58 UTC, Paulo Pinto wrote: So it finally happened, C# gets an AOT compiler in addition to NGEN/JIT as part of standard Visual Studio tools. http://techcrunch.com/2014/04/02/microsoft-updates-visual-studio-with-support-for-universal-projects-typescript-1-0-and-net-native-code-compilation/ More information will be provided in the native sessions tomorrow and on Friday. Posting this as it has direct implications into D's adoption. -- Paulo Now I wonder how will runtime template instantiation work.
Re: Even better navigation - thanks Nick Treleaven!
On Wednesday, 7 January 2015 at 23:18:03 UTC, Andrei Alexandrescu wrote: We just deployed Nick's work at https://github.com/D-Programming-Language/dlang.org/pull/726, which enables jump-to navigation for structures. For example, from http://dlang.org/phobos/std_array.html#.Appender one can jump easily to its methods. Thanks, Nick! Andrei Nice! std.datetime is a little* nicer to navigate now. (Your not guessing which toISOExtString your clicking on for example). * I do mean a LITTLE. That module is still an enigma wrapped up in a mystery all shrouded in a veil of deceit.
Re: MSBUILD 2014, C# gets an ahead of time compiler to native code.
There are some tools in the wild which allows to compile C#(MSIL) into native code (using LLVM) thus being cross-compiled as opposed to C# native compiler which Windows OS oriented. here some links: https://csnative.codeplex.com/ and https://github.com/xen2/SharpLang
Re: An idea for commercial support for D
On Tuesday, 6 January 2015 at 20:21:50 UTC, Zach the Mystic wrote: On Sunday, 4 January 2015 at 08:31:23 UTC, Joakim wrote: This is an idea I've been kicking around for a while, and given the need for commercial support for D, would perhaps work well here. The notion is that individual developers could work on patches to fix bugs or add features to ldc/druntime/phobos then sell those closed patches to paying customers. After enough time has passed, so that sufficient customers have adequately paid for the work or after a set time limit beyond that, the patch is open sourced and merged back upstream. It would have to be ldc and not dmd, as the dmd backend is not open source and the gdc backend license doesn't allow such closed patches. A funny scenario based on this proposal: Company A wants feature B, and signs a contract with a developer for a certain amount, receiving the feature as soon as possible, releasing the paid-for software to the public after a year. During that year, company C comes to the same developer wanting the same feature. They say, "It's already paid for, but you can pay company A half the development cost, minus the proportion of time left before it's open to everyone, and you can both have it!" Or something like that. You're on the right track: I've talked in the past about a more advanced version of such a pricing model, that could be used for any intellectual property, not just for software. How it would work is that the developer sets a price for all the work to develop the feature, say $3k, and picks a reasonable minimum amount of customers, say 20. So he then sets the initial price at $150, which may seem high for a single feature. But assuming he gets to 20 customers, the price drops for each subsequent customer, and the first 20 get a proportionate refund. So when he gets to 30 customers, each of the last 10 to buy get charged $100, not $150, and each of the first 20 customers get their prices dropped to $100, so that the total for the developer is always $3k. Right now, this may work better for an up-front payment model, say on a site like kickstarter, or some such marketplace where the customers have ongoing accounts and it's easy to credit money back to them without having to keep issuing refunds to their payment provider, avoiding the accompanying fees. What are the advantages of such a model? Well, usually the creator has to set a fixed price, whether $50 or $200, and take the risk that it is the sweet spot and will actually get enough customers to garner $3k, ie he has to guess at the supply/demand curve for his product. In this variable pricing model, the customer also takes some of that risk, ie you'll pay more if enough other people don't also want the product. But just like on kickstarter, that's a risk you may want to take, as long as you get the feature. There are other elaborations on this model to account for some other factors, but the basic idea is here. This kind of variable pricing model would have been too costly decades ago, with all the paper bookkeeping and chargebacks. It would be trivial to implement today though and would be a much better model for many products. Why isn't it done already? People are stupid, no other reason.
Re: We need a DConf 2015 logo
On Wednesday, 7 January 2015 at 23:16:19 UTC, Andrei Alexandrescu wrote: On 1/7/15 3:08 PM, ponce wrote: On Wednesday, 7 January 2015 at 22:36:28 UTC, Andrei Alexandrescu wrote: On 1/7/15 12:26 PM, ponce wrote: On Tuesday, 6 January 2015 at 19:27:23 UTC, Andrei Alexandrescu wrote: The DConf 2015 dates have been confirmed and the site will be soon up - see preview at http://erdani.com/d/bvbvuntf/. Please contribute with a DConf logo image. Also any design updates for the site would be welcome, Thanks! Andrei Attempted one: http://ovh.to/KsMX3qV Thanks! But shouldn't it read "DConf 2015"? -- Andrei I was assuming the website would do that. I see now that in 2014 and 2013 site the logo is appended the text in an image http://dconf.org/2013/images/logo.png which is great for reproducibility, but it does seem possible with CSS. Yah, a logo styled after those with the new dates would be awesome. -- Andrei I'll get back, with text.
Re: json generation from ddoc: painfully close
On 1/8/2015 12:32 AM, Andrei Alexandrescu wrote: I haven't yet figured the circumstances. We can't just let anybody know those things.
Re: Another init() bug, can we deprecate yet?
On Wednesday, 7 January 2015 at 23:31:30 UTC, H. S. Teoh via Digitalmars-d wrote: On Wed, Jan 07, 2015 at 10:03:00PM +, Peter Alexander via Digitalmars-d wrote: https://issues.dlang.org/show_bug.cgi?id=13806 For the lazy: BitArray has an init() method, which hides the property BitArray.init This, or something similar, appears every few months. Walter has said in the past that the ability to override init is a feature. As far as I can tell, no one is using it as a feature; it only seems to cause trouble. Can we just deprecate it? At the very least deprecate functions named init(). https://github.com/D-Programming-Language/phobos/pull/2854 Destroy! Thanks. Just to be clear, I'm advocating deprecating all user-defined init functions, not just BitArray (so we don't get into this situation again).
Re: Phobos colour module?
And for completeness: http://en.wikipedia.org/wiki/CIECAM02
Re: json generation from ddoc: painfully close
On 8/01/2015 9:32 p.m., Andrei Alexandrescu wrote: I just experimented with a battery of macros (json.ddoc) for generating json via ddoc. Results for std.algorithm are in http://paste.ofcode.org/DFnxChvmRGJiXYpYYk2XWr. There are a couple of things that make the generated json invalid: 1. I couldn't get escaping to work. My ESCAPES is: ESCAPES=/\/\\/ /"/\"/ /&/&/ //>/ So single backslashes will be doubled and quotes will be backslashed. Nice. The trouble is, escaping only does its job sometimes but not always. I haven't yet figured the circumstances. 2. This was mentioned before - paragraph, whitespace and especially newline handling are handled rather poorly in ddoc. The generated json is full of newlines in the middle of strings, which are invalid in json (\n must be used). I think every paragraph should be enclosed in a $(DDOC_PARAGRAPH) macros that has single newlines replaced with spaces. Alternatively, a built-in macro could escape strings appropriately. 3. Some descriptions feature multiple examples, leading to duplicate "DDOC_EXAMPLES" keys. Json strongly discourages (at least) duplicate keys in objects. There is no way to have some autoincrement thing that generates "DDOC_EXAMPLES_1", "DDOC_EXAMPLES_2" etc. It could be argued that that's an issue with the source, not the generator. That said, this is pretty much it. No other major impediments seem to stop the show. Thoughts and ideas on how to get this to work? Andrei Well we could do the evil method of enabling calling of code from a macro. There should be enough information to do that? We have CTFE, might as well use it.
Re: Phobos colour module?
On Thursday, 8 January 2015 at 02:56:36 UTC, Manu via Digitalmars-d wrote: L*ab, L*CHab, HSL, HWB C#'s and Java's colour struct provides what they call HSB which is related to HSV. In computer vision a variant is HSI. http://en.wikipedia.org/wiki/HSL_and_HSV Java has a separate colour space type with quite extensive support, I guess that is a good reference for what is useful: http://docs.oracle.com/javase/7/docs/api/java/awt/color/ColorSpace.html http://docs.oracle.com/javase/7/docs/api/java/awt/Color.html
