NASA/JPL Rules for writing Critical Software
http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf
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.
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.
Re: Fastest Way of Accessing Entries in an AA
On Thursday, 8 January 2015 at 23:06:39 UTC, Nordlöw wrote: On Thursday, 8 January 2015 at 16:11:07 UTC, ketmar via Digitalmars-d-learn wrote: how can it? compiler doesn't know what the code is supposed to do. if compilers will know such things someday, we can stop writing programs altogether, as compilers will be able to write any program for us. ;-) Correction: I thought it would be nice if the compiler explained to me that key in aa ? aa[key] is a sub-optimal performance-wise. You know, that you kan reuse the result of the in operator by AAs? example: auto ptr = key in aa; ptr ? *ptr : ValueType.init
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: 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!
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: D idioms list
I saw recently (at last in this thread:
http://forum.dlang.org/thread/tdfydchrairigdlgt...@forum.dlang.org#post-qakiogaqvmiwlneimhgu:40forum.dlang.org)
that many users use
key in aa ? aa[key] : ValueType.init;
instead of
auto ptr = key in aa;
ptr ? *ptr : ValueType.init;
which is more economic.
Maybe you can add it to your list:
import std.stdio;
void main() {
immutable string key = foo;
immutable string[string] arr = [key : bar];
if (auto ptr = key in arr)
writeln(*ptr);
}
[Issue 9119] [AA] Forward range addition to associative arrays.
https://issues.dlang.org/show_bug.cgi?id=9119 --- Comment #13 from hst...@quickfur.ath.cx --- Furthermore, printing of the range returned by byPair() produces output of the form: - immutable(Tuple!(string, int))(a, 123) immutable(Tuple!(string, int))(b, 234) immutable(Tuple!(string, int))(c, 345) - So the printing issue is also taken care of. --
[Issue 13936] groupBy must be redone
https://issues.dlang.org/show_bug.cgi?id=13936 --- Comment #9 from hst...@quickfur.ath.cx --- The nice thing about assuming non-equivalence relation by default is that it's the most general: it will produce correct behaviour in all use cases with no further work required from the user. In my initial implementation of groupBy, it assumed equivalence relation by default, and led to buggy behaviour like non-terminating empty ranges or wrong groupings because either transitivity or reflexivity failed to hold, but the code assumed they did. My initial reaction was to define it away -- state that only equivalence relations are supported and close the bug. But upon further thought, I decided that supporting non-equivalence relations opens up more possibilities: you can now do things like grouping by maximum adjacent difference, for example, which can be useful as a kind of edge detector in a stream of data, but maximum adjacent difference is not an equivalence relation due to non-transitivity. It makes groupBy useful beyond the usual mundane equivalence relation based predicates. In any case, this is a (mostly) orthogonal issue to performance. The problem I see with your call home proposal is that it introduces a lot of hidden complexities that either may offset the performance gain, or introduces subtle semantic corner cases that are ugly to deal with. First of all, this would require the subranges to retain a reference to the outer range. There are several problems with this: (1) the outer range can no longer be a by-value type, because if it's a struct, structs are liable to being moved around, invalidating references to it; (2) so we have to allocate on the heap, which is already a minus given the current push for reducing Phobos allocations. (3) Which in turn means GC load, unless we introduce reference counting, which adds additional complication (plus overhead to maintain the ref count). (4) The subranges may need extra care to implement -- if they are a by-value struct type, the struct may get copied around, leaving stray references to the outer range, so either you need GC to clean up, or you need to tread into dangerous territory of struct dtors (which leads into areas with many compiler bugs and/or limitations, and fragile behaviour -- a lot of Phobos code doesn't work well with structs that have dtors because they don't have nice semantics for things like T tmp; return tmp; to get an empty range of the same type, for example). (5) This *still* doesn't fully solve the performance issue -- if I have a 1000-element subrange and I iterate over 900 of them and then give up and decide to move on to the next subrange, the parent range will still repeat the 1000 popFront's from the beginning of the subrange because the subrange never called home. (6) Your call-home trick falls flat on its face if somebody calls .save on the outer range. Which copy of the outer range should the subranges call home to? Using the single-subrange idea I had, does solve (5), but then it introduces poor API because the subranges can no longer be forward ranges. (In retrospect this is not surprising, since we *are* trying to optimize for the single-pass use case, so input-only ranges would be the natural solution. It's wanting *both* single-pass performance *plus* the full semantics of range-of-ranges that makes things complicated.) One idea that occurs to me is to store the subrange as a struct inside the parent range (so it never needs to call home, the parent range just picks up on where it left off and continues scanning for the next subrange), and have .save just return an independent copy of the subrange. However, this isn't a foolproof solution either, since a common idiom with forward ranges is to always work with a .save'd copy of a range, so then the user never actually uses the embedded copy of the subrange and any popFront()'s called on the .save'd copy doesn't benefit the outer range. One possible solution I can think of, that still requires the extra complexity of heap-allocating the outer range, but does solve (5): one of the possibly multiple copies of the subranges is designated as the furthest subrange, and gets the special privilege of having a reference to it from the outer range. Each copy of the subrange competes for this position by keeping a pop-counter that is bumped every time popFront is called. If the pop-counter exceeds the pop-counter of the current furthest subrange, the range that went further installs itself as the new furthest subrange in the outer range, replacing the old champion. (The old champion can snatch the position back if it later on has more popFront's called.) When popFront on the outer range is called, it .save's the current furthest subrange and scans for the next subrange boundary. It also bumps the serial number, which indicates to all previous subranges that they've all been demoted and can no longer compete for the furthest subrange trophy. This ensures that the outer
Re: Game development
On 9 January 2015 at 02:53, Ras via Digitalmars-d digitalmars-d@puremagic.com 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.
Re: DConf 2015 Call for Submissions is now open
On 1/8/2015 8:42 AM, Jonathan M Davis via Digitalmars-d-announce wrote: On Thursday, January 08, 2015 10:31:37 Iain Buclaw via Digitalmars-d-announce wrote: On 6 January 2015 at 23:24, Andrei Alexandrescu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Hello, Exciting times! DConf 2015 will take place May 27-29 2015 at Utah Valley University in Orem, UT. Awesome, that runs over my birthday (28th). My friends and family won't be too pleased. :-) Just get them to help chip in for the airfare and hotel costs for your birthday present. ;) Or they can come to the conference, too!
[Issue 13936] groupBy must be redone
https://issues.dlang.org/show_bug.cgi?id=13936 --- Comment #12 from hst...@quickfur.ath.cx --- I don't see what's the big problem with supporting non-equivalence relations, all it means is that you have to evaluate the predicate only between adjacent elements rather than between an element and the head of its subrange (which was what was done in the initial implementation). But whatever, I don't actually have any current code that relies on groupBy supporting non-equivalence relations, so I don't really care. I just don't understand why this has suddenly become such a major issue. By it's complicated I do not mean it's complicated to write code for -- that's a non-issue. What I mean is it introduces complicated semantics, which inevitably results in obscure corner cases that have unexpected/pathological behaviour. This includes effects of similar calibre as transient ranges (they technically conform 100% to the range API but have unusual behaviour that cannot be easily dealt with). One such effect is the semantics of .save. The compiler bugs bit, I admit, is a bit a of red herring, though. :-P Don't forget that random-access ranges are still forward ranges, so you still have to deal with the semantics of .save. And I wasn't trying to find reasons it can't be done; I was just pointing out obvious flaws in your proposed solution that would introduce more problems than it solves. --
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: We're looking for a Software Developer! (D language)
If you email me at john DOT carter AT taitradio DOT com we can take this conversation out of the D forum as it is going way off topic. On Fri, Jan 9, 2015 at 4:05 PM, Rikki Cattermole via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 9/01/2015 2:53 p.m., John Carter via Digitalmars-d-announce wrote: Whilst we are not currently using D at Tait Electronics I am certainly trying to make it happen. So if this job fits you... http://www.taitradio.com/about-us/careers/new-zealand/ jobs-in-new-zealand/embedded-software-engineer2 You can help me try! Part of the problem with getting a new language accepted in a company, is to develop a critical mass of willing and capable programmers in that language. On Fri, Jan 9, 2015 at 2:20 AM, Rikki Cattermole via Digitalmars-d-announce digitalmars-d-announce@puremagic.com mailto:digitalmars-d-announce@puremagic.com wrote: On 9/01/2015 12:10 a.m., Johanna Burgos wrote: Your Mission Support our team in the development of our event-based infrastructure Development of high-performance applications and services Writing applications to work with our distributed DHT database system You will be coding in the D-language Your Track Record Degree in Computer Science, or closely-related Knowledge of Github Strong interest in distributed architectures Experienced in C, C++ or D (you’ll be programming in D) Fluency in written and spoken English Your Style You don’t like being thrown in at the deep end. You like to jump yourself You live and breathe globalization and love to work and travel internationally You mesmerize people with a friendly and open-minded, yet trustworthy and reliable personality You think in achievements, not in departments, responsibilities or hierarchy As a quick learner, first mover and fast thinker you can keep pace with one of the fastest growing technology start ups You are driven by curiosity and innovation, and always up for a good challenge Our Promise Employment in Berlin, full-time and full of fun challenges, with flexible working hours Access to a high-profile professional network of international Internet companies Possibility to show your excellent competence and your creative ideas to a broad audience A competitive compensation and incentive plan that rocks when you rock Personal development and training that will help you evolve from the pro you are right now to the champ you’re destined to be Basic German language courses for non-native speakers Help with residence permit processing for non-EU citizens Daily adrenalin rushes while working and learning in one of the fastest growing sectors in online advertising Access to an international high-profile network A company culture driven by pioneer-thinking and talent that exceeds departments and hierarchies The challenge is on. If you think it’s you we’re looking for, send us your battle plan along with a certificate of your super powers at care...@sociomantic.com mailto:care...@sociomantic.com. Alternatively, a motivational cover letter and resume in English will do, too. For now. Unfortunately I half wish you guys had a New Zealand office. As I am in need of a job. -- John Carter Phone : (64)(3) 358 6639 Tait Electronics PO Box 1645 Christchurch New Zealand This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. Wow there is actually somebody working right round the corner of me! I did not expect this. Out of curiosity how do
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're looking for a Software Developer! (D language)
On Thursday, 8 January 2015 at 13:21:05 UTC, Rikki Cattermole wrote: The challenge is on. If you think it’s you we’re looking for, send us your battle plan along with a certificate of your super powers at care...@sociomantic.com. Alternatively, a motivational cover letter and resume in English will do, too. For now. Unfortunately I half wish you guys had a New Zealand office. As I am in need of a job. We already have a kiwi in our lines, Ben, they guy organizing the Berlin meetup. You can ask him how was moving from NZ to DE. ;-)
Re: We're looking for a Software Developer! (D language)
On 9/01/2015 2:53 p.m., John Carter via Digitalmars-d-announce wrote: Whilst we are not currently using D at Tait Electronics I am certainly trying to make it happen. So if this job fits you... http://www.taitradio.com/about-us/careers/new-zealand/jobs-in-new-zealand/embedded-software-engineer2 You can help me try! Part of the problem with getting a new language accepted in a company, is to develop a critical mass of willing and capable programmers in that language. On Fri, Jan 9, 2015 at 2:20 AM, Rikki Cattermole via Digitalmars-d-announce digitalmars-d-announce@puremagic.com mailto:digitalmars-d-announce@puremagic.com wrote: On 9/01/2015 12:10 a.m., Johanna Burgos wrote: Your Mission Support our team in the development of our event-based infrastructure Development of high-performance applications and services Writing applications to work with our distributed DHT database system You will be coding in the D-language Your Track Record Degree in Computer Science, or closely-related Knowledge of Github Strong interest in distributed architectures Experienced in C, C++ or D (you’ll be programming in D) Fluency in written and spoken English Your Style You don’t like being thrown in at the deep end. You like to jump yourself You live and breathe globalization and love to work and travel internationally You mesmerize people with a friendly and open-minded, yet trustworthy and reliable personality You think in achievements, not in departments, responsibilities or hierarchy As a quick learner, first mover and fast thinker you can keep pace with one of the fastest growing technology start ups You are driven by curiosity and innovation, and always up for a good challenge Our Promise Employment in Berlin, full-time and full of fun challenges, with flexible working hours Access to a high-profile professional network of international Internet companies Possibility to show your excellent competence and your creative ideas to a broad audience A competitive compensation and incentive plan that rocks when you rock Personal development and training that will help you evolve from the pro you are right now to the champ you’re destined to be Basic German language courses for non-native speakers Help with residence permit processing for non-EU citizens Daily adrenalin rushes while working and learning in one of the fastest growing sectors in online advertising Access to an international high-profile network A company culture driven by pioneer-thinking and talent that exceeds departments and hierarchies The challenge is on. If you think it’s you we’re looking for, send us your battle plan along with a certificate of your super powers at care...@sociomantic.com mailto:care...@sociomantic.com. Alternatively, a motivational cover letter and resume in English will do, too. For now. Unfortunately I half wish you guys had a New Zealand office. As I am in need of a job. -- John Carter Phone : (64)(3) 358 6639 Tait Electronics PO Box 1645 Christchurch New Zealand This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. Wow there is actually somebody working right round the corner of me! I did not expect this. Out of curiosity how do you guys consider CPIT's Degree in ICT keep in mind that it doesn't cover c/c++. Well until I pushed for D(native) anyway.
Re: D idioms list
On Thu, 08 Jan 2015 21:22:30 + ponce via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 8 January 2015 at 20:23:11 UTC, ketmar via Digitalmars-d-announce wrote: i'm not sure, but maybe it worth renaming struct inheritance to extending a struct? or even something completely different. what it does is actually extending/augmenting the struct, but not OO-inheritance, as one cannot pass augmented struct to the function which expects original struct. at least without hackery. Renamed, thanks! we actually can pass extended struct as original one, as Artur shown, but i believe that extending is still better. p.s. you forgot to fix TOC, which still reads struct inheritance. signature.asc Description: PGP signature
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
Parameterized enum does not work
Hi,
Should following coding work?
string lpad(ubyte length, long n)
{
import std.string: rightJustify;
import std.conv: to;
return rightJustify(to!string(n), length, '0');
}
enum lpad14(long n) = lpad(14, n);
void main()
{
lpad14(123);
}
There is following error from dmd:
source\app.d(12): Error: template app.lpad14 cannot deduce
function from argumen
t types !()(int), candidates are:
source\app.d(8):app.lpad14(long n)
Kind regards
André
Re: Game development
On Thu, 08 Jan 2015 22:27:53 +0100 Joseph Rushton Wakeling via Digitalmars-d digitalmars-d@puremagic.com 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 Fri, 09 Jan 2015 05:35:04 + Ras via Digitalmars-d digitalmars-d@puremagic.com 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 digitalmars-d@puremagic.com 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
checking if template arg is literal, possible ER for compiler change
Hello.
disclaimer: please, ignore compiler inlining abilities while you are
reading this post. i'll give some reasoning later.
let's imagine that we have such function:
void putPixel (int x, int y, uint color) {
if ((color0xff) == 0) {
// replace pixel
} else if ((color0xff) != 0xff) {
// do color blending
} // and do nothing for transparent pixels
}
and it's often calling like this: `putPixel(x, y, Color.White);` (or
another color constant). `Color.White` is not transparent.
but why we should do all the checks if we know the argument value at
compile time? it would be wonderful if we'll be able to do something
like this:
void putPixel() (int x, int y, uint color) {
static if (isLiteralArg!color) {
static if ((literalArgValue!color0xff) == 0) {
// replace pixel
} else static if ((literalArgValue!color0xff) != 0xff) {
// do color blending with code
// optimised for the given color
} // and do nothing for transparent pixels
} else {
if ((color0xff) == 0) {
// replace pixel
} else if ((color0xff) != 0xff) {
// do color blending
} // and do nothing for transparent pixels
}
}
i named new traits `isLiteralArg` and `literalArgValue` here. yes, we
see code duplication here, but this is another story. what is important
is that we can generate specialised versions of `putPixel` based on
argument value which is known in compile time.
sure, for easy cases like this we can rely on compiler inlining
abilities. yet inlining may fail without warning (having warning about
failing inlines is nice, but this is completely different story).
and what is much more important is that we can specialise `putPixel`
with known color value. we can, for example, generate different code
for different opacities and so on.
we can introduce range checking for `x` and `y` and omit that if we
know their values at compile time.
the thing is that we have controlled inlining here without resorting
to something like this:
void putPixel(alias x, alias y, alias color) ()
if (isIntegral!(typeof(x)) isIntegral!(typeof(y))
isIntegral!(typeof(color))
{
static if (!is(color)) {
// color is literal
} else {
// color is not known in compile time
}
}
besides looking ugly with all those `isIntegral!` checks, which makes
signature unreadable, we now forced to call it like
`putPixel!(x, y, c);` instead of `putPixel(x, y, c);`.
ah, and compiler error messages are not really readable in this case.
what i want to say here is that having a way to check if *function*
args for templated function are literals (and get their values) can be
useful for various patterns of compile-time code generation and
parameterization without resorting to ugly signatures and unnatural
bang calling.
this can break template instantiation though, as we cannot assume that
template with identical argument types will instantiate to identical
functions, but i don't think that this is of great importance: compiler
can do AST comparisons on various instances later.
this will change some instantiated function signatures too, as they now
will depend of literal arguments. so it will be wise to do this only
for templates that explicitly used `isLiteralArg` and `literalArgValue`
traits.
this seems to be a not-so-small change of compiler internals, so i want
to know if i'm completely insane here or there are more people that see
a sane practical value in such feature.
signature.asc
Description: PGP signature
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 digitalmars-d@puremagic.com 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: Game development
On Thu, 8 Jan 2015 21:25:24 + (UTC) Justin Whear via Digitalmars-d digitalmars-d@puremagic.com 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: Fastest Way of Accessing Entries in an AA
On Friday, January 09, 2015 00:20:07 Foo via Digitalmars-d-learn wrote:
On Thursday, 8 January 2015 at 23:06:39 UTC, Nordlöw wrote:
On Thursday, 8 January 2015 at 16:11:07 UTC, ketmar via
Digitalmars-d-learn wrote:
how can it? compiler doesn't know what the code is supposed to
do. if
compilers will know such things someday, we can stop writing
programs
altogether, as compilers will be able to write any program for
us. ;-)
Correction:
I thought it would be nice if the compiler explained to me that
key in aa ? aa[key]
is a sub-optimal performance-wise.
You know, that you kan reuse the result of the in operator by AAs?
example:
auto ptr = key in aa;
ptr ? *ptr : ValueType.init
This idiom is quite common:
if(auto ptrToValue = key in aa)
{
}
though I'm not sure that that quite fits in with what Nordlow seems to be
trying to do with init. aa.get probably does a better job of that, though
looking at the implementation for get, it's basically doing what you're
suggesting:
auto p = key in aa;
return p ? *p : defaultValue;
though that has the downside of using a lazy parameter for the default
value, which is convenient but doesn't do great things for performance.
- Jonathan M Davis
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: 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: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Thursday, 8 January 2015 at 15:15:59 UTC, Robert burner Schadek wrote: use canFind like such: bool a = canFind(strs,s) = 1; let the compiler figger out what the types of the parameter are. canFind is work for such as : bool x = canFind([exe,lib,a,dll],a ); but can't work for canFind([exe,lib,a,dll],hello.lib); So I very want to let the function 'indexOfAny' do the same work. Thank you. Frank
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Fri, 09 Jan 2015 07:10:14 +
FrankLike via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
On Thursday, 8 January 2015 at 15:15:59 UTC, Robert burner
Schadek wrote:
use canFind like such:
bool a = canFind(strs,s) = 1;
let the compiler figger out what the types of the parameter are.
canFind is work for such as :
bool x = canFind([exe,lib,a,dll],a );
but can't work for canFind([exe,lib,a,dll],hello.lib);
So I very want to let the function 'indexOfAny' do the same work.
Thank you.
Frank
be creative! ;-)
import std.algorithm, std.stdio;
void main () {
string fname = hello.exe;
import std.path : extension;
if (findAmong([fname.extension], [.exe, .lib, .a, .dll]).length) {
writeln(got it!);
} else {
writeln(alas...);
}
}
note the dots in extension list.
yet you can do it even easier:
import std.algorithm, std.stdio;
void main () {
string fname = hello.exe;
import std.path : extension;
if ([.exe, .lib, .a, .dll].canFind(fname.extension)) {
writeln(got it!);
} else {
writeln(alas...);
}
}
as you obviously interested in extension here -- check only that
part! ;-)
signature.asc
Description: PGP signature
Re: Parameterized enum does not work
On Friday, 9 January 2015 at 06:17:53 UTC, Andre wrote:
Hi,
Should following coding work?
string lpad(ubyte length, long n)
{
import std.string: rightJustify;
import std.conv: to;
return rightJustify(to!string(n), length, '0');
}
enum lpad14(long n) = lpad(14, n);
void main()
{
lpad14(123);
}
There is following error from dmd:
source\app.d(12): Error: template app.lpad14 cannot deduce
function from argumen
t types !()(int), candidates are:
source\app.d(8):app.lpad14(long n)
Kind regards
André
What are you trying to do?
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:
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: Parameterized enum does not work
On Friday, 9 January 2015 at 07:50:53 UTC, Daniel Kozak wrote:
On Friday, 9 January 2015 at 06:17:53 UTC, Andre wrote:
Hi,
Should following coding work?
string lpad(ubyte length, long n)
{
import std.string: rightJustify;
import std.conv: to;
return rightJustify(to!string(n), length, '0');
}
enum lpad14(long n) = lpad(14, n);
void main()
{
lpad14(123);
}
There is following error from dmd:
source\app.d(12): Error: template app.lpad14 cannot deduce
function from argumen
t types !()(int), candidates are:
source\app.d(8):app.lpad14(long n)
Kind regards
André
What are you trying to do?
OK I probably see it now :):
import std.stdio;
string lpad(ubyte length, long n)
{
import std.string: rightJustify;
import std.conv: to;
return rightJustify(to!string(n), length, '0');
}
enum lpad14(long n) = lpad(14, n);
void main()
{
writeln(lpad14!(123));
}
Re: Fastest Way of Accessing Entries in an AA
On Friday, 9 January 2015 at 06:18:53 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
On Friday, January 09, 2015 00:20:07 Foo via
Digitalmars-d-learn wrote:
On Thursday, 8 January 2015 at 23:06:39 UTC, Nordlöw wrote:
On Thursday, 8 January 2015 at 16:11:07 UTC, ketmar via
Digitalmars-d-learn wrote:
how can it? compiler doesn't know what the code is supposed
to
do. if
compilers will know such things someday, we can stop writing
programs
altogether, as compilers will be able to write any program
for
us. ;-)
Correction:
I thought it would be nice if the compiler explained to me
that
key in aa ? aa[key]
is a sub-optimal performance-wise.
You know, that you kan reuse the result of the in operator by
AAs?
example:
auto ptr = key in aa;
ptr ? *ptr : ValueType.init
This idiom is quite common:
if(auto ptrToValue = key in aa)
{
}
though I'm not sure that that quite fits in with what Nordlow
seems to be
trying to do with init. aa.get probably does a better job of
that, though
looking at the implementation for get, it's basically doing
what you're
suggesting:
auto p = key in aa;
return p ? *p : defaultValue;
though that has the downside of using a lazy parameter for the
default
value, which is convenient but doesn't do great things for
performance.
- Jonathan M Davis
I just wasn't sure that he knows about it.
Re: D idioms list
On Thu, 08 Jan 2015 22:25:11 +0100
Artur Skawina via Digitalmars-d-announce
digitalmars-d-announce@puremagic.com wrote:
On 01/08/15 21:23, ketmar via Digitalmars-d-announce wrote:
i'm not sure, but maybe it worth renaming struct inheritance to
extending a struct? or even something completely different. what it
does is actually extending/augmenting the struct, but not
OO-inheritance, as one cannot pass augmented struct to the function
which expects original struct. at least without hackery.
'alias this' is just the D syntax for implicit conversions.
The feature /is/ crippled, but there's no need for hackery;
at least not for simple things like that.
struct A { int a; }
struct B { A a; alias a this; string b; }
int f(A a) { return a.a+1; }
int g(ref A a) { return a.a+1; }
ref A h(ref A a) { return a; }
int main() {
B b;
return f(b)+g(b)+h(b).a;
}
artur
mea culpa. i completely forgot about that feature of `alias this`, and
was pretty sure that the code above is invalid. i never bothered to
really check it. sorry.
signature.asc
Description: PGP signature
Re: D idioms list
On Thu, 08 Jan 2015 21:22:30 + ponce via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 8 January 2015 at 20:23:11 UTC, ketmar via Digitalmars-d-announce wrote: i'm not sure, but maybe it worth renaming struct inheritance to extending a struct? or even something completely different. what it does is actually extending/augmenting the struct, but not OO-inheritance, as one cannot pass augmented struct to the function which expects original struct. at least without hackery. Renamed, thanks! p.p.s. maybe it's worth adding Artur's code sample[1] too, to show that extended structure can be passed to functions which requires original one? it's not obvious, at least for me. ;-) [1] http://forum.dlang.org/post/mailman.4332.1420752329.9932.digitalmars-d-annou...@puremagic.com signature.asc Description: PGP signature
Re: Fastest Way of Accessing Entries in an AA
On Thu, 08 Jan 2015 23:06:38 + Nordlöw via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Thursday, 8 January 2015 at 16:11:07 UTC, ketmar via Digitalmars-d-learn wrote: how can it? compiler doesn't know what the code is supposed to do. if compilers will know such things someday, we can stop writing programs altogether, as compilers will be able to write any program for us. ;-) Correction: I thought it would be nice if the compiler explained to me that key in aa ? aa[key] is a sub-optimal performance-wise. although it's right in most cases, it's still implying that compiler is able to understand the code behind `in` and `[key]`, as they aren't built into the compiler, but rather coded in druntime. producing warning on such code can create wrong impression about compiler code analysing abilities. this time i think that it's a work for a linter, 'cause there is nothing wrong with the code, it's just a questionable style. so let linter question it. ;-) signature.asc Description: PGP signature
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 hypothetical.
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: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!
[Issue 13901] Improvements to documentation
https://issues.dlang.org/show_bug.cgi?id=13901 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
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: D idioms list
On Thursday, 8 January 2015 at 10:21:26 UTC, ponce wrote: I've started a list of curated D tips and tricks here: http://p0nce.github.io/d-idioms/ Anything that you wished you learned earlier at one point in the D world is welcome to be added or suggested. I think the focus should be on stuff that could make you more productive, or is just funky but that is up to debate. Of course the D Cookbook still stays irreplaceable for a consistent, in-depth discussion of being D-enabled. Thoughts? Not much to add but I enjoy reading 'idiomatic' D content - coming from C++, I feel like I'm often not writing my D code like I should be. Thanks for the extra resource.
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
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: idiomatic D: what to use instead of pointers in constructing a tree data structure?
On 07/01/15 16:02, Laeeth Isharc via Digitalmars-d-learn wrote:
class node
{
string name;
node ref;
}
Small recommendation (apart from the reserved word issue which you fixed): it's
generally considered good D style to give structs and classes names that start
with capital letters, JustLikeThis. So, I suggest Node rather than node.
Very minor point, and of course, your code is yours to style as you wish, but it
can be helpful to meet the standard style conventions in order to make it as
easy as possible for everyone else to understand.
See also: http://dlang.org/dstyle.html
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: 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: We're looking for a Software Developer! (D language)
Is there any chance that in the future your company hire D developers in Warsaw office ?
Re: Sociomantic: We're looking for a Software Developer! (D language)
On 2015-01-08 14:01 Joseph Rushton Wakeling wrote: Just to mention that this call is particularly focused on getting new people for my team at Sociomantic. There is one important piece of information missing: Are you still using only D1? If not, how is your code base currently split into D1 and D2?
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: 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 ListT you are going to use a specialization of the template such as Listint which is not template anymore.
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: Fastest Way of Accessing Entries in an AA
On Thursday, 8 January 2015 at 16:11:07 UTC, ketmar via Digitalmars-d-learn wrote: how can it? compiler doesn't know what the code is supposed to do. if compilers will know such things someday, we can stop writing programs altogether, as compilers will be able to write any program for us. ;-) Correction: I thought it would be nice if the compiler explained to me that key in aa ? aa[key] is a sub-optimal performance-wise.
We're looking for a Linuy Systems Admin!
Your Mission Provide server administration to our data centers Provisioning new servers, imaging, monitoring, and other daily routines Daily monitoring and maintenance of servers Perform backup, file replications, and script management for servers Test and apply new software and patches Complete security audits on a routine basis Report to the VP Product and Innovations Your Track Record 5+ years Linux System administration (experience with Debian-based distributions (Ubuntu in particular) desired) Working knowledge of complex web hosting configuration components, including firewalls, HA Proxy, web and database servers Ability to deploy, support, and diagnose real (hardware, software and network) issues for a production environment Knowledge of TCP/IP, bash/python scripting, postfix, smartmontools, Puppet, LVM, RAID, collectd, cacti, nagios and other monitoring solutions is highly appreciated Experience in nginx web servers, PHP and MySQL configuration, as well as deploying custom in-house developed services Experience in communicating with external suppliers Your Style You don’t like being thrown in at the deep end. You like to jump yourself You live and breathe globalization and love to work and travel internationally You mesmerize people with a friendly and open-minded, yet trustworthy and reliable personality You think in achievements, not in departments, responsibilities or hierarchies As a quick learner, first mover and fast thinker you can keep pace with one of the fastest growing technology start ups You are driven by curiosity and innovation, and always up for a good challenge Fluency and strong communication skills in both written and spoken English Our Promise Employment in Berlin, full-time and full of fun challenges, with flexible working hours A competitive compensation and incentive plan that rocks when you rock Personal development and training that will help you evolve from the pro you are right now to the champ you’re destined to be Daily adrenalin rushes while working and learning in one of the fastest growing sectors in online advertising Access to an international high-profile network A company culture driven by pioneer-thinking and talent that exceeds departments and hierarchies The challenge is on. If you think it’s you we’re looking for, send us your battle plan along with a certificate of your super powers at care...@sociomantic.com. Alternatively, a motivational cover letter and resume will do, too. For now.
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: D idioms list
On Thursday, 8 January 2015 at 10:21:26 UTC, ponce wrote: I've started a list of curated D tips and tricks here: http://p0nce.github.io/d-idioms/ Anything that you wished you learned earlier at one point in the D world is welcome to be added or suggested. I think the focus should be on stuff that could make you more productive, or is just funky but that is up to debate. Of course the D Cookbook still stays irreplaceable for a consistent, in-depth discussion of being D-enabled. Thoughts? They are really cool, thanks :) Question: Where did this syntax came from? It is not documented for 'import' keyword.(first time I see that D has built-in resource compiler): ubyte[] sdlBytes = cast(ubyte[]) import(SDL2.dll);
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: idiomatic D: what to use instead of pointers in constructing a tree data structure?
this conversation is so funny: well what's wrong with this . It's a keyword... Aa Ha ha ha ha , rol. Seriously, is it so complicated to use a D editor ? I mean with syntax color... Man afraid to ask stoopid questions stays stoopid. And compiler error message far from informative. Not everyone is very visually oriented, and sometimes vi is quicker.
Re: D idioms list
On Thu, 08 Jan 2015 11:24:34 + Szymon Gatner via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 8 January 2015 at 10:21:26 UTC, ponce wrote: I've started a list of curated D tips and tricks here: http://p0nce.github.io/d-idioms/ Anything that you wished you learned earlier at one point in the D world is welcome to be added or suggested. I think the focus should be on stuff that could make you more productive, or is just funky but that is up to debate. Of course the D Cookbook still stays irreplaceable for a consistent, in-depth discussion of being D-enabled. Thoughts? They are really cool, thanks :) Question: Where did this syntax came from? It is not documented for 'import' keyword.(first time I see that D has built-in resource compiler): ubyte[] sdlBytes = cast(ubyte[]) import(SDL2.dll); it is documented: http://dlang.org/expression.html#ImportExpression it's a nice D habit of overloading keywords. signature.asc Description: PGP signature
Re: D idioms list
On Thursday, 8 January 2015 at 10:56:00 UTC, bearophile wrote: ponce: I'm not familiar with the terse, range-heavy, UFCS style that has emerged from Phobos In Rosettacode I have inserted tons of examples of that coding style. An example, given a tuple of arbitrary length, with items all of the same type, how do you compute the total of its items? The last way I've invented is: myTuple[].only.sum It's also @nogc. But it causes a little of template bloat. Bye, bearophile Cool. I will link to the Rosettacode D pages since I've used them in the past when time-constrained, especially all things regarding text files.
Re: D idioms list
On Thursday, 8 January 2015 at 11:31:14 UTC, ketmar via Digitalmars-d-announce wrote: On Thu, 08 Jan 2015 11:24:34 + Szymon Gatner via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 8 January 2015 at 10:21:26 UTC, ponce wrote: I've started a list of curated D tips and tricks here: http://p0nce.github.io/d-idioms/ Anything that you wished you learned earlier at one point in the D world is welcome to be added or suggested. I think the focus should be on stuff that could make you more productive, or is just funky but that is up to debate. Of course the D Cookbook still stays irreplaceable for a consistent, in-depth discussion of being D-enabled. Thoughts? They are really cool, thanks :) Question: Where did this syntax came from? It is not documented for 'import' keyword.(first time I see that D has built-in resource compiler): ubyte[] sdlBytes = cast(ubyte[]) import(SDL2.dll); it is documented: http://dlang.org/expression.html#ImportExpression it's a nice D habit of overloading keywords. Ah, thanks. Follow up then: can such imported string be used for mixin?
Re: D idioms list
On Thursday, 8 January 2015 at 11:41:43 UTC, Szymon Gatner wrote: Question: Where did this syntax came from? It is not documented for 'import' keyword.(first time I see that D has built-in resource compiler): ubyte[] sdlBytes = cast(ubyte[]) import(SDL2.dll); it is documented: http://dlang.org/expression.html#ImportExpression it's a nice D habit of overloading keywords. Ah, thanks. Follow up then: can such imported string be used for mixin? Yes.
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: What does dmd 2.066 want from me?
On Wednesday, 7 January 2015 at 20:10:35 UTC, Artem Tarasov wrote: I'm trying to compile my software with the latest compiler, and it spits out the following error: $ make ... rdmd --force --build-only -IBioD -g -L-Lhtslib -L-l:libhts.a -L-l:libphobos2.a -ofbuild/sambamba.o main.d ... /tmp/.rdmd-1000/rdmd-main.d-5E103AD0DCA0998F00B4F9BA5B181EDE/objs/sambamba.o.o:(.data._D80TypeInfo_S3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamRead6__initZ+0x30): undefined reference to `_D3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamRead9__xtoHashFNbNeKxS3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamReadZm' /tmp/.rdmd-1000/rdmd-main.d-5E103AD0DCA0998F00B4F9BA5B181EDE/objs/sambamba.o.o:(.data._D80TypeInfo_S3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamRead6__initZ+0x38): undefined reference to `_D3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamRead11__xopEqualsFKxS3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamReadKxS3bio3bam4read41__T12EagerBamReadTS3bio3bam4read7BamReadZ12EagerBamReadZb' What the heck do these lines mean? Presumably they come from the recent change in hash implementation, but I don't use this struct in any dictionary whatsoever! It doesn't have opCmp either and perfectly worked until now. Are you totally sure that you don't have any old .o or .a files lying around? Remember that D offers no binary compatibility across compiler releases. Also, are you absolutely certain that 1) the correct dmd.conf is being used and 2) the correct version of druntime/phobos is specified in dmd.conf
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: How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows?
On Thursday, 8 January 2015 at 10:11:38 UTC, Danny wrote: Hi, sigh, so I have to annoy you with the truth... On Tuesday, 6 January 2015 at 17:15:28 UTC, FrankLike wrote: How to prevent sensitive information is displayed when the extension 'exe' is modified to 'txt' on windows? By not putting it in in the first place. Everything else is no good in the end. Encryption, xoring, everything is almost useless for that purpose. If you build a exe ,such as which can get Data from DataBase,when you modify the exe's extension to 'txt', and you open it by notepad.exe (on windows),you will find the info,it's important for me,so how to stop the info to display ? Do you mean find the password? (I don't see that field in your example) Remove the password field and let the operating system care of auth forwarding to the database server. Then create all the users on your database and make sure to set their permissions right. That way, your computer and the database server will negotiate whether they let the user in and it's their problem. I always do it like that. Also, that way, you already have existing permission management tools (in the dbms). If you don't want to grant them permission on the table, don't. Create a view with the harmless info and grant them permission to that. Likewise, if you want to completely abstract it away, create stored procedures in the database as the interface for your app and grant them only permission to execute them. Trusted_Connection=Yes\ Well, now I don't see what the problem you are trying to solve is. You are doing as outlined above already. So what is the problem you are trying to solve? 'Trusted_Connection=Yes' is for local DB(127.0.0.1) ,but for network ,must have the username and password. I have known how to do,but thank you.
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: 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 ctype.h (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: idiomatic D: what to use instead of pointers in constructing a tree data structure?
On Thursday, 8 January 2015 at 11:29:30 UTC, Laeeth Isharc wrote: this conversation is so funny: well what's wrong with this . It's a keyword... Aa Ha ha ha ha , rol. Seriously, is it so complicated to use a D editor ? I mean with syntax color... Man afraid to ask stoopid questions stays stoopid. And compiler error message far from informative. Not everyone is very visually oriented, and sometimes vi is quicker. don't worry about it. use whatever you're comfortable with.
Re: D idioms list
On Thursday, 8 January 2015 at 11:43:30 UTC, ponce wrote: On Thursday, 8 January 2015 at 11:41:43 UTC, Szymon Gatner wrote: Question: Where did this syntax came from? It is not documented for 'import' keyword.(first time I see that D has built-in resource compiler): ubyte[] sdlBytes = cast(ubyte[]) import(SDL2.dll); it is documented: http://dlang.org/expression.html#ImportExpression it's a nice D habit of overloading keywords. Ah, thanks. Follow up then: can such imported string be used for mixin? Yes. That is pretty damn cool then.
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: 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 ctype.h (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 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 ctype.h (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: D idioms list
On Thu, 08 Jan 2015 11:41:42 + Szymon Gatner via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 8 January 2015 at 11:31:14 UTC, ketmar via Digitalmars-d-announce wrote: On Thu, 08 Jan 2015 11:24:34 + Szymon Gatner via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 8 January 2015 at 10:21:26 UTC, ponce wrote: I've started a list of curated D tips and tricks here: http://p0nce.github.io/d-idioms/ Anything that you wished you learned earlier at one point in the D world is welcome to be added or suggested. I think the focus should be on stuff that could make you more productive, or is just funky but that is up to debate. Of course the D Cookbook still stays irreplaceable for a consistent, in-depth discussion of being D-enabled. Thoughts? They are really cool, thanks :) Question: Where did this syntax came from? It is not documented for 'import' keyword.(first time I see that D has built-in resource compiler): ubyte[] sdlBytes = cast(ubyte[]) import(SDL2.dll); it is documented: http://dlang.org/expression.html#ImportExpression it's a nice D habit of overloading keywords. Ah, thanks. Follow up then: can such imported string be used for mixin? sure. either directly, or you can use CTFE to parse imported data and generate code. for now it's somewhat limited, 'cause CTFE parsing eats alot of memory, but when we'll have 128GB of RAM at bare minimum... i don't think that i'll be using external preprocessors to generate D code from various text and binary files. signature.asc Description: PGP signature
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: 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: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Wednesday, 7 January 2015 at 17:08:55 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
Try this:
http://dlang.org/phobos-prerelease/std_algorithm#.findAmong
T
You mean ? The result is not that I want to get!
---test.d--
import std.stdio, std.algorithm,std.string;
auto ext =[exe,lib,a,dll];
auto strs = hello.exe;
void main()
{
auto b = findAmong(ext,strs);
writeln(b is ,b);
}
-result-
b is [exe,lib,a,dll]
note:
1. I only want to find the given string 'hello.exe' whether to
include any a string in the [exe,lib,a,dll].
2. I think the 'indexOfAny' function of string.d do the same work
with 'indexOf',This is not as it should be.
Frank
Sociomantic: We're looking for a Software Developer! (D language)
Hello all, Just to mention that this call is particularly focused on getting new people for my team at Sociomantic. It may be of especial interest to anyone who wants to work on machine learning problems (we have lots of fun stuff in the pipeline), but whatever your background, this is a great opportunity to work full-time with D, in a great company that has a very extensive and exciting D codebase. You can also review the job ad on our company website: https://www.sociomantic.com/jobs/d-software-developer/#.VK5xsV2YOlM Best wishes, -- Joe (Software Dev @ Sociomantic:-)
Sociomantic: We're looking for a Linux Systems Admin!
It is probably not obvious why our HR department posted this job ad to this newsgroup, particularly to anyone who doesn't know Sociomantic's relationship to the D community. Most of the apps running on our servers, are written in D. The role doesn't involve D programming, and the job ad doesn't even mention D, but it will involve working very closely with our D developers, in supporting the deployment and operation of D code. You can also review the job ad on our company website: https://www.sociomantic.com/jobs/linux-system-administrator/#.VK5_XV3ydwE - Don.
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Wednesday, 7 January 2015 at 17:08:55 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
Try this:
http://dlang.org/phobos-prerelease/std_algorithm#.findAmong
T
Thank you,it can work. but it's not what I want.
---test.d--
import std.stdio, std.algorithm,std.string;
auto ext =[exe,lib,a,dll];
auto strs = hello.dll;
void main()
{
auto b = findAmong(ext,strs);
writeln(b is ,b);
}
-result-
b is [dll]
I think if 'indexOfAny' function of string.d do the work ,it
should be ok.
such as :
auto b = hello.dll.indexOfAny([exe,lib,a,dll]);
writeln(b is ,b);
The result should be 'true',if it can work.
Can you suggest 'phobos' to update 'indexOfAny' fuction?
Thank you.
Frank
Re: idiomatic D: what to use instead of pointers in constructing a tree data structure?
what's wrong with the code above ? i get an error no identifier for declarator node. (I have not used classes much, since structs often seem to be enough for what I need to do mostly). ref is a reserved keyword. -- Paulo this conversation is so funny: well what's wrong with this . It's a keyword... Aa Ha ha ha ha , rol. Seriously, is it so complicated to use a D editor ? I mean with syntax color... No need to make fun of anyone.
json generation from ddoc: painfully close
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
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: What does dmd 2.066 want from me?
On Thursday, 8 January 2015 at 01:22:54 UTC, Rikki Cattermole wrote: Have you got opEqual's defined? Its wanting that and toHash I think. Yes, I have opEquals defined. I've just tried to add dummy toHash (returning a constant), but it doesn't help :( OK, it seems I'll have to stick with 2.065 and LDC 0.15. These new bugs in every new version of compiler drive me nuts. Thanks for trying to help, anyway.
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
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: 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: DConf 2015 Call for Submissions is now open
On 6 January 2015 at 23:24, Andrei Alexandrescu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Hello, Exciting times! DConf 2015 will take place May 27-29 2015 at Utah Valley University in Orem, UT. Awesome, that runs over my birthday (28th). My friends and family won't be too pleased. :-) Iain
Re: D idioms list
On Thursday, 8 January 2015 at 10:30:38 UTC, uri wrote: This is great, thanks. Something I personally would find useful is a comparison between the C++ way and idiomatic D with Phobos. I finding coming from C/C++ to D very easy but I'm always wondering if I'm doing things the D way. Cheers, uri I'm not familiar with the terse, range-heavy, UFCS style that has emerged from Phobos so I'm not sure if I can write that. What could help is a list of tasks for which you asked yourself what the D way was. Is there one?
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.
D idioms list
I've started a list of curated D tips and tricks here: http://p0nce.github.io/d-idioms/ Anything that you wished you learned earlier at one point in the D world is welcome to be added or suggested. I think the focus should be on stuff that could make you more productive, or is just funky but that is up to debate. Of course the D Cookbook still stays irreplaceable for a consistent, in-depth discussion of being D-enabled. Thoughts?
