Re: auto: useful, annoying or bad practice?
auto has its uses, but it's wildly overused, especially in library code and documentation, and really, really, *really* much so in documentation examples. On 05/01/2018 06:09 AM, Craig Dillabaugh via Digitalmars-d wrote: On Monday, 30 April 2018 at 21:11:07 UTC, Gerald wrote: I'll freely admit I haven't put a ton of thought into this post (never a good start), however I'm genuinely curious what people's feeling are with regards to the auto keyword. Speaking for myself, I dislike the auto keyword. Some of this is because I have a preference for static languages and I find auto adds ambiguity with little benefit. Additionally, I find it annoying that the phobos documentation relies heavily on auto obscuring return types and making it a bit more difficult to follow what is happening which gives me a bad taste for it. clip So I'm curious, what's the consensus on auto? As some have pointed out, it certainly has value. For example, in functions returning ranges, etc. where you wouldn't want to have to write out the whole type. However, as an infrequent D user I admit I prefer to see the actual type where it is feasible, as I find 'auto' is a barrier to understanding to someone who isn't familiar with a particular piece of code. I would never use auto in place of a basic type.
Re: Why 16Mib static array size limit?
On 08/16/2016 01:49 PM, Steven Schveighoffer via Digitalmars-d wrote:
On 8/16/16 4:11 PM, Yuxuan Shui wrote:
On Tuesday, 16 August 2016 at 17:51:13 UTC, Johan Engelen wrote:
On Tuesday, 16 August 2016 at 01:28:05 UTC, Ali Çehreli wrote:
With ldc2, the best option is to go with a dynamic array ONLY IF you
access the elements through the .ptr property. As seen in the last
result, using the [] operator on the array is about 4 times slower
than that.
As Yuxuan Shui mentioned the difference is in vectorization. The
non-POINTER version is not vectorized because the semantics of the
code is not the same as the POINTER version. Indexing `arr`, and
writing to that address could change `arr.ptr`, and so the loop would
do something different when "caching" `arr.ptr` in `p` (POINTER
version) versus the case without caching (non-POINTER version).
Evil code demonstrating the problem:
```
ubyte evil;
ubyte[] arr;
void doEvil() {
// TODO: use this in the obfuscated-D contest
arr = (&evil)[0..50];
}
```
The compiler somehow has to prove that `arr[i]` will never point to
`arr.ptr` (it's called Alias Analysis in LLVM).
Perhaps it is UB in D to have `arr[i]` ever point into `arr` itself, I
don't know. If so, the code is vectorizable and we can try to make
it so.
-Johan
Wait, doesn't D have strict aliasing rules? ubyte* (&evil) should not be
allowed to alias with ubyte** (&arr.ptr).
Even if it did, I believe the wildcard is ubyte*. Just like in C,
char* can point at anything, ubyte is D's equivalent.
-Steve
I think what you say is true (look at the code of std.outbuffer), but
IIRC the documentation says that's supposed to be the job of void*.
Re: Is this the best way to share Tids between threads?
Sorry this ended up here rather than at learn. I followed up there with something more explicit. See "Multi-Thread message passing approach" in learn. The problem here is that the threads will be doing the same thing, sort of, modulus an integer. And the number of them should be set at run time by checking the number of available CPUs. Which is handled in today's code example (see learn), but I'm not really sure I'm doing things the best way, or even that it's safe. (I'm using a shared Tid[].) There will be a couple of specialized threads, for which that looks like a good approach, though I could easily just special case those. It's the more general case that I'm concerned about. If the approach of using "shared Tid[]" is safe, then it's probably the best approach, but since I have to cast away the "shared" to use it, I worry about it's safety. If it's unsafe, then I probably need to set up an relay in the main thread. I suppose I could register "th1", "th2", ... "thn" and then only spawn a limited number of threads, and then use that to get the Tid[] as a local variable, or some other work around, but that seems quite clumsy, besides, if "shared Tid[]" is unsafe, then probably so is using Tids retrieved by locate in multiple independent threads. On 08/14/2016 01:55 AM, angel via Digitalmars-d wrote: Let each thread have a name related to its task. It is like having a shared Tid array, but already implemented. Reference: http://dlang.org/phobos/std_concurrency.html#.register
Is this the best way to share Tids between threads?
I'm trying to figure out the best way to have multiple threads that can
each send messages to the other threads.
I've come up with two basic approaches, one uses the main thread as a
relay, and the other uses a shared array of Tid...thus:
importstd.concurrency;
importstd.stdio;
importcore.thread;
sharedTid[8]tidList;
voidworker (int ndx)
{ Thread.sleep (5.msecs);
writeln ("worker is done");
}
voidmain()
{
auto tid=spawn (&worker, 0);
tidList[0]=cast(shared Tid)tid;
Thread.sleep (40.msecs);
writeln ("main is done");
}
Is there a reasonable way to decide which way is best? Is there a
better way that I just haven't thought of? Are there problems with
sending messages via shared Tids that I just haven't thought of yet?
Re: Why D is not popular enough?
On 08/01/2016 09:37 AM, eugene via Digitalmars-d wrote: On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote: For years, i was travelling along Golang, Rust, Perl, Ruby, Python, PHP, JScript, JVM Languages. Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many more that i can't remember. I'm 24 years old, my first lang was PHP and VBasic then C,C++ and i first heard about D after 2005 when i was 14-15 years old. I always ignored D, i prejudiced that D failed, because nobody were talking about it. I decided to check it yesterday, it has excellent documentation, i almost covered all aspects. I think D is much better than the most of the other popular langs. It's clear as JScript, Swift, Julia and PHP, also it's capable enough as C,C++. I think D deserves a bigger community. Why people need NodeJS, Typescript etc, when there is already better looking lang? Everyone talking about how ugly is Golang. So why people are going on it? Performance concerns? Why languages that are not backed up by huge companies are looking like they failed? maybe another reason is that people who tried to use D still think it is unstable I have never experienced D as being unstable. I have, however, experienced problems using various libraries with D. Whenever you need to use a foreign library you invite problems, but D wrappers around libraries have a habit of showing up and then not being maintained. THAT has caused me problems...enough problems that if I don't need the performance I'll pick Python. As for D1 being a failure...that depends on what you wanted to do with it. Until it started being influenced by Tango I was quite pleased, and even Tango wasn't all bad. It had a few good unicode tools that haven't yet been incorporated into D2. D2 I'm less satisfied with, though that may just be a rosy-glasses memory of D1. Most of my needs aren't fancy compile time techniques but rather run-time techniques. (I did mention Python as the alternate rather than C++.) But what the best language is depends a lot on what you are doing. To talk in terms of other languages, Objective C is a better language for my needs than C++. It isn't really because of the commitment to 16-bit unicode, but outside of that... So in either version of D I have mixed uses of 8-bit unicode and 32-bit unicode. D seems to handle this better than any other language. And it's got lots of other nice features. I love garbage collection, as I hate memory management. I'm less attracted to ranges as implemented by D, though I like them in Ruby and Python. A lot of this has to do with what gets done at compile time and what gets done at run time, though, so for me that just means that I'd rather avoid needing to use ranges when I need speed. For my purposes the template language is overblown, and I'd be satisfied with a much simpler form with some run-time supplementation...but different people would like different simplifications even among those who want it to be simpler. Traits, e.g., I find indispensable (especially isPOD) and I need to be able to test THAT at compile time, but most people who talk about templates don't even mention traits. Many languages become significant when there is an popular application or library that depends on them. Others grow slowly. There *is*, however, a network effect, so that popular languages tend to become more popular, and this is often driven by a "niche" application (a place where there is no competition, so everyone who wants to work in that niche must use that language). An example of this, if you go back to before it was popular, is JavaScript.
Re: Make D language as Apache foundation project
On 08/01/2016 08:56 AM, Emre Temelkuran via Digitalmars-d wrote: On Wednesday, 27 July 2016 at 13:28:04 UTC, Adam D. Ruppe wrote: On Wednesday, 27 July 2016 at 13:08:17 UTC, eugene wrote: Hello everyone, why not to make a D language as a project of Apache foundation as it happened to groovy? My impression of Apache foundation stuff is it is a graveyard of other people's abandoned stuff not the message I'd want to send. I know what you tried to say. You're right and wrong. :D. Yes, ASF got lots of trash but 1/2 of that list is alive and useful. http://www.apache.org/index.html#projects-list - Some projects are definitely killer. Linux Foundation is another option. The Linux Foundation is less appropriate for what it intended to be a cross-platform application. And the FSF wants it's projects to be GPL. Of the major ... repositories isn't the right word, but what is? ... Apache seems the most appropriate choice. GitHub, e.g., doesn't seem to be quite the same category of thing.
Re: Overflows in Phobos
On 07/26/2016 07:36 AM, ketmar via Digitalmars-d wrote: On Tuesday, 26 July 2016 at 14:28:48 UTC, Timon Gehr wrote: "The expression assert(0) is a special case; it signifies that it is unreachable code. [...] The optimization and code generation phases of compilation may assume that it is unreachable code." so specs should be fixed. i bet everyone is using `assert(0);` to mark some "immediate error exit" cases. FWIW, in that case I always use assert (false, "..."); I try to never use integers for booleans. But this may well be a common usage.
Re: Vision for the D language - stabilizing complexity?
On 07/18/2016 03:37 PM, Walter Bright via Digitalmars-d wrote: On 7/18/2016 6:48 AM, Andrew Godfrey wrote: We risk scaring away potential community members, and alienating existing ones, by the way we say "no" to proposals for breaking changes. We could improve how we say "no", by having a place to point people to. Potential topics: Anything we do will risk scaring away people. The only answer is we have to do what is right. 3) Why we feel that breaking changes risk killing D outright. (I just don't see it. I wonder if we're confusing "dfixable" breaking changes, with other more disruptive kinds (such as Tango=>Phobos).) Because if you thoroughly break a person's code, you put them in a position of rewriting it, and they may not choose to rewrite it in D3. They may choose a more stable language. I have many older programs in different languages. It's nice if they recompile and work. It's not nice if I have to go figure out how they work again so I can get them to work again. For some changes there could be switches, rather like optimization level switches, or those managed by version. This would allow the compilation version to be set based on a compile time variable, I'm not totally sure whether this should be file level or, as with version, block level...or selectable. This would get to be a huge maintenance chore after awhile, but it would allow you a few years to deprecate code. The question is "How important would a change need to be to justify this kind of action?", and my guess is that it would need to be pretty important.
Re: Our docs should be more beautiful
I think the Python docs looks better and are more useful...but the older Python docs were even better. Sometimes fancier HTML just makes things less useful. That said, I think that when feasible docs should be auto-generated from code included within the code files. More like ddoc or javadoc then Sphinx or such. But this shouldn't necessarily apply to the basic frameworks. The basic D documentation is extremely good, it's when we get to the libraries that things become a bit iffy. (Then again, I don't like the template syntax. I thought the D1 docs were better than the D2 docs, but this might be because when they were rewritten they assumed things that give me trouble. I prefer the way that Python handles ranges to the way the D does. Etc. These impact the understanding of the documentation of many Phobos files.) On 07/18/2016 06:41 PM, Andrei Alexandrescu via Digitalmars-d wrote: On 07/18/2016 09:28 PM, Carl Vogel wrote: Racket's docs have actually been designed by a professional typographer, so might be a good reference point. Example: https://docs.racket-lang.org/reference/flonums.html They do look nice! -- Andrei
Re: D is crap
Garbage collection allows many syntax "liberalizations" that lack of garbage collection renders either impossible or highly dangerous. (In this definition of "garbage collection" I'm including variations like reference counting.) For an example of this consider the dynamic array type. You MUST have garbage collection to use that safely...unless you require the freeing of memory with every change in size. C++ does that with the STL, but if you want the dynamic types built into the language, then you need garbage collection built into the language. (This is different from saying it needs to be active everywhere, but once you've got it, good places to use it keep showing up.) One of the many advantages of the dynamic array type being built into the language is that arrays of different sizes are reasonably comparable by methods built into the language. This is used all over the place. In D I almost never need to use "unchecked conversion". On 07/11/2016 02:30 AM, Chris via Digitalmars-d wrote: On Sunday, 10 July 2016 at 03:25:16 UTC, Ola Fosheim Grøstad wrote: Just like there is no C++ book that does not rant about how great RAII is... What do you expect from a language evangelic? The first Java implementation Hotspot inherited its technology from StrongTalk, a Smalltalk successor. It was not a Java phenomenon, and FWIW both Lisp, Simula and Algol68 were garbage collected. Please stop intentionally missing the point. I don't care if Leonardo Da Vinci already had invented GC - which wouldn't surprise me - but this is not the point. My point is that GC became a big thing in the late 90ies early 2000s which is in part owed to Java having become the religion of the day (not Lisp or SmallTalk)[1]. D couldn't have afforded not to have GC when it first came out. It was expected of a (new) language to provide GC by then - and GC had become a selling point for new languages. [1] And of course computers had become more powerful and could handle the overhead of GC better than in the 80ies. What was "new" with Java was compile-once-run-everywhere. Although, that wasn't new either, but it was at least marketable as new. Java was the main catalyst for GC - or at least for people demanding it. Practically everybody who had gone through IT courses, college etc. with Java (and there were loads) wanted GC. It was a given for many people. Well, yes, of course Java being used in universities created a demand for Java and similar languages. But GC languages were extensively used in universities before Java. Yes, it didn't last long. But the fact that they bothered to introduce it, shows you how big GC was/is. No, it shows how demanding manual reference counting was in Objective-C on regular programmers. GC is the first go to solution for easy memory management, and has been so since the 60s. Most high level languages use garbage collection. It wasn't demanding. I wrote a lot of code in Objective-C and it was perfectly doable. You even have features like `autorelease` for return values. The thing is that Apple had become an increasingly popular platform and more and more programmers were writing code for OS X. So they thought, they'd make it easier and reduce potential memory leaks (introduced by not so experienced Objective-C coders) by adding GC, especially because a lot of programmers expected GC "in this day and age".
Re: Should we add another SmallArray to DMD?
On 07/07/2016 03:51 AM, Guillaume Chatelet via Digitalmars-d wrote: On Thursday, 7 July 2016 at 07:56:44 UTC, Stefan Koch wrote: On Thursday, 7 July 2016 at 06:39:19 UTC, Guillaume Chatelet wrote: On Tuesday, 5 July 2016 at 19:41:18 UTC, Guillaume Chatelet wrote: DMD currently provides the Array type: https://github.com/dlang/dmd/blob/master/src/root/array.d [...] Walter, Daniel, Thoughts? I guess a few number of the perf difference this can make would be helpful. It's not so much about performance gain (although it wouldn't hurt). It's more about codebase sanity: idiomatic D, documentation, tests. I think it's currently hard to contribute to DMD. Sure it improved a lot with the migration to D but it still bears the marks of the past. If it's just for code sanity, why wouldn't an alias suffice? I often alias types to create a "type" for a specialized purpose. Of course, if you want a real type you could wrap it in a struct...which I do with classes when it's *IMPORTANT* that the finalizer be called.
Re: D is almost the exact language I need...
On 07/03/2016 01:31 AM, Walter Bright via Digitalmars-d wrote: On 7/3/2016 12:21 AM, Charles Hixson via Digitalmars-d wrote: I do wish that phobos included a D wrapper around SQLite, There was one recently announced. Thanks. I missed the announcement. I'd also like to be able to depend on class finalizers being called. Sometimes I wrap a class in a struct just so I can depend on the finalizer. That's the way to do it. It works, but it's a bit of added friction when I'm coding. Especially if I need access to the internals of the class...then I need to manually mangle the names. (I'm not implying I need to match the compiler's version of the name.) The last time I checked DDoc stopped working after encountering an extern "C" block in a file. I'm not aware of this. Is there a bug report filed? I wasn't sure it was a bug. And it may not still be present. Since I figured out the cause I've just put the C externals in a separate file. DDoc could use considerable work in formatting. I'd like to be able to globally control the font attributes of classes, structs, aliases, enums. DDoc relies on having a user-supplied xxx.ddoc file to provide the formatting, css, etc. I wasn't able to figure out how to highlight classes differently from structs, etc. I have built small .ddoc files to make custom changes, but that was for defining macros. I'd like to be able to document private routines or not depending on a (compiler) switch. I'm not sure what the point of that would be. Private functions shouldn't be called by anything outside of the file, and you already have the file open in the editor when working on it. But you can always submit an enhancement request for it on bugzilla. That's not for export. The documentation is written for me to use a month or more later. Most of my needs are for run time flexibility rather than for more compile time flexibility. E.g., I'd like to be able to declare a statically sized array from a parameter. You can do it more or less with alloca(). I know C99 has this feature, and some people swear by it, but I just don't think it pulls its weight. Yes, I could manually allocate them. But that adds a lot of resistance. If they are too much effort, well, OK, but that's an example of the kind of thing that I want that D doesn't address. No language does everything, and D is one of the two or three languages I consider best. Python is another, but slow. Vala shows promise, but it's not portable, and the development is glacial. Also it's poorly documented. It's advantage is it's fast AND has a lot of wrapped libraries. (But last I checked it seemed FAR from 1.0.) I feel sort of guilty for "complaining" this way when I've been devoting all my efforts to my own projects, but you did, essentially, invite comments. If something good can come from it, it's good. My chances of getting any usable result from my work are *very* low. OTOH, if I do the social payoff will be huge. So I persevere. Except when I get discouraged.
Re: D is almost the exact language I need...
FWIW, I feel that the elaboration of the template language doesn't serve me well. That's my use case, so I try to ignore it as much as possible, but phobos has been re-written to be much less intelligible to me. I'm sure that many people find the inclusion of ranges into everything useful, but it rarely helps me. I really like the way D handles unicode. D and Vala are the two languages that seem to handle it well, and Vala isn't portable. And I really like having garbage collection, and especially the syntax that it enables. I was just considering a hash table (associative array) in C++, and realized that I had to either allocate on the heap, or I couldn't easily do an increment of a struct variable. (Well, I'm thinking about QHash, because walking the files of a directory path in standard C++ is unpleasant, and Qt makes both that and unicode tests [the ones I need to do] pretty simple.) But if I allocate structs on the heap I have to make sure that everything gets released when I'm through, so I need to use an enhanced pointer construct, so It's a lot simpler in D. I do wish that phobos included a D wrapper around SQLite, something object oriented. I'd also like to be able to depend on class finalizers being called. Sometimes I wrap a class in a struct just so I can depend on the finalizer. The last time I checked DDoc stopped working after encountering an extern "C" block in a file. This is not desirable, even though one can work around it by moving all the extern routines to another file. DDoc could use considerable work in formatting. I'd like to be able to globally control the font attributes of classes, structs, aliases, enums. I'd like to be able to document private routines or not depending on a (compiler) switch. I frequently end up declaring things to be protected rather than private just so I can generate documentation. Most of my needs are for run time flexibility rather than for more compile time flexibility. E.g., I'd like to be able to declare a statically sized array from a parameter. I do appreciate D's speed, but complex templates aren't something I ever use. (Truth is, I was pretty well satisfied with D1, though perhaps I'm forgetting some limitations, but even then I'm pretty much sure that I felt the main limitation was a lack of well interfaced libraries.) Too many of D's libraries seem to try to re-invent the wheel. When a library is working well and has been debugged, the best think if to create a wrapper around it. The wrapper *does* need to adapt the library to the syntax of the language, but that's not a huge problem. A major part of Python's success is "batteries included". I feel sort of guilty for "complaining" this way when I've been devoting all my efforts to my own projects, but you did, essentially, invite comments. On 07/02/2016 11:23 PM, Walter Bright via Digitalmars-d wrote: Thanks for taking the time to write this. Let me see if I can help. On 7/2/2016 9:37 PM, D is crap wrote: 1. The language is not completely well defined. While the language itself contains many nice features and what makes D appealing, too many features are cobbled together and don't completely work 100% properly. This creates very subtle bugs or problem areas that can stop one in their tracks. One can see how these things are cobbled together by observing the forms and the discussions about how to proceed in certain areas. This is true. I'm interested in which of these have caused you problems. Naturally, people in the forum are going to debate the edge cases, as they do in every language. It isn't necessary to use those edge cases to write very successful code, however. 2. The compilation process is riddled with meaningless error messages and a simple missing ';' can launch one off to the moon to figure out it is missing. The error messages can cascade. Fix the ';' and 20 messages disappear. I agree this is true for the syntax checker, but also I'm not aware of any compiler that has successfully dealt with this problem other than simply stopping after the first message. The semantic pass is much better at having one and only one error message per actual error. Usually each message is 100 characters+ when it involves templates. Again, you are right, but this is a consequence of templates being complex. The compiler tries to emit all the relevant context to enable the user to figure out the right fix. Rather than just telling you what is grammatically missing, like any normal modern compiler does, you have to hunt and peck and fill your head with meaningless information. Most of the error messages out of the syntax checker are of the form "xxx expected", so if you could present an example of a bad error message I'd appreciate it so it can be improved. 3. The compilers are designed as if they come straight out of the 70's. The setup is obscure, relies on assumptions that are not tr
Re: UTF-8 Everywhere
On 06/19/2016 11:44 PM, Walter Bright via Digitalmars-d wrote: On 6/19/2016 11:36 PM, Charles Hixson via Digitalmars-d wrote: To me it seems that a lot of the time processing is more efficient with UCS-4 (what I call utf-32). Storage is clearly more efficient with utf-8, but access is more direct with UCS-4. I agree that utf-8 is generally to be preferred where it can be efficiently used, but that's not everywhere. The problem is efficient bi-directional conversion...which D appears to handle fairly well already with text() and dtext(). (I don't see any utility for utf-16. To me that seems like a first attempt that should have been deprecated.) That seemed to me to be true, too, until I wrote a text processing program using UCS-4. It was rather slow. Turns out, 4x memory consumption has a huge performance cost. The approach I took (which worked well for my purposes) was to process the text a line at a time, and for that the overhead of memory was trivial. ... If I'd needed to go back and forth this wouldn't have been desirable, but there was one dtext conversion, processing, and then several text conversions (of small portions), and it was quite efficient. Clearly this can't be the approach taken in all circumstances, but for this purpose it was significantly more efficient than any other approach I've tried. It's also true that most of the text I handled was actually ASCII, which would have made the most common conversion processes simpler. To me it appears that both cases need to be handled. The problem is documenting the tradeoffs in efficiency. D seems to already work quite well with arrays of dchars, so there may well not be any need for development in that area. Direct indexing of utf-8 arrays, however, is a much more complicated thing, which I doubt can ever be as efficient. Memory allocation, however, is a separate, though not independent, complexity. If you can work in small chunks then it becomes less important.
Re: UTF-8 Everywhere
To me it seems that a lot of the time processing is more efficient with UCS-4 (what I call utf-32). Storage is clearly more efficient with utf-8, but access is more direct with UCS-4. I agree that utf-8 is generally to be preferred where it can be efficiently used, but that's not everywhere. The problem is efficient bi-directional conversion...which D appears to handle fairly well already with text() and dtext(). (I don't see any utility for utf-16. To me that seems like a first attempt that should have been deprecated.) On 06/19/2016 05:49 PM, Walter Bright via Digitalmars-d wrote: http://utf8everywhere.org/ It has a good explanation of the issues and problems, and how these things came to be. This is pretty much in line with my current (!) opinion on Unicode. What it means for us is I don't think it is that important anymore for algorithms to support strings of UTF-16 or UCS-4.
Re: Andrei's list of barriers to D adoption
On 06/05/2016 09:17 PM, Adam D. Ruppe via Digitalmars-d wrote: On Monday, 6 June 2016 at 02:30:55 UTC, Pie? wrote: Duh! The claim is made that D can work without the GC... but that's a red herring... If you take about the GC what do you have? Like 90% of the language, still generally nicer than most the competition. Though, I wish D would just own its decision instead of bowing to Reddit pressure. GC is a proven success in the real world with a long and impressive track record. Yes, there are times when you need to optimize your code, but even then you aren't really worse off with it than without it. Usually correct, but there are times when you want to suspend the garbage collection. The problem is this should always be a scoped decision, because it's easy to accidentally leave it turned off, and then it's MUCH worse than not having it.
Re: Proposal: Database Engine for D
FWIW, were I proposing a "Database Engine for D" I'd be proposing a B+Tree that was restricted to storing explicit data (no pointers or other indirection...including strings, you'd need to specify fixed size arrays of char, wchar, or dchar). There would be one "type"/file, and the "type" would be given by a struct that contained no pointers either obvious or hidden (i.e., dynamic arrays, strings, etc.). This would be for simplicity of implementation and basic functionality. Later I would consider implementing secondary keys which would be implemented as databases storing only the key value and the record number. Since records are of fixed size, sorting them would be trivial, but only the secondary keys would provide this option because you want the record number of the main file to be reliable and invariant. SQL seems like a poor fit to D. At some point one might consider a fancier front end to the database that would allow indirections, but that's a whole can of worms, with threats of multiple copies that have different values for items that started out pointing to the same variable. On 01/04/2016 12:39 PM, Andrei Alexandrescu via Digitalmars-d wrote: On 01/04/2016 01:28 PM, Russel Winder via Digitalmars-d wrote: Rusts macros show it can be done well. Do you have a few examples handy? Thanks. -- Andrei
Re: Wishlist for D
On 12/14/2015 01:27 PM, tsbockman via Digitalmars-d wrote: On Sunday, 13 December 2015 at 11:25:37 UTC, Ola Fosheim Grøstad wrote: On Sunday, 13 December 2015 at 11:18:31 UTC, Robert burner Schadek wrote: On Saturday, 12 December 2015 at 22:57:55 UTC, Ola Fosheim Grøstad wrote: 2. Debug-mode testing of integer overflow. https://github.com/D-Programming-Language/phobos/pull/3389 I know, but that does not help when one are debugging code that doesn't use it. I have spent a lot of time trying to design the best checked integer type possible for Phobos, and I intend to finish the job (hopefully soon). Nevertheless, I fully agree with Ola: compiler support (similar to how array bounds checking is handled already) would be much better than any library solution could be. Doing it right would also be a fundamental breaking change, though, so this will have to wait for a hypothetical D3. It wouldn't need to be a breaking change if checked integer were a separate type series, as the unsigned series is. The types could be called "cint" etc. I expect that they would incur significant overhead, as I don't think there is hardware support for checked integers, and as such the current types would need to be maintained.
Re: Wishlist for D
On 12/12/2015 03:47 PM, Jack Stouffer via Digitalmars-d wrote: On Saturday, 12 December 2015 at 19:55:27 UTC, Charles Hixson wrote: Now I'll occasionally use it, but I so often need to iterate over multiple arrays that I use indexing much more often Why not use foreach(ref a, ref b, ref c; lockstep(array1, array2, array3)) ? Because indexing is easier, more intelligible, and less error prone.
Re: Wishlist for D
A "batteries included" extension to phobos modeled after the Python modules. Esp. I'd like a standard linkage to Sqlite via D rather than C, but I'm sure that other have other most desired libraries. Additionally, I'd like fewer language changes. D is a great language now, and changes, while interesting, are (for my purposes) of at best dubious value. (Bug fixes, of course, is a different matter.) OTOH, I am usually not interested in compile time enhancement, but only in execution time enhancements. E.g., I generally find that using ranges is both less intelligible and less flexible than using indexed access. (I originally hoped that foreach would be to allow parallel execution, as that was the only use I could see for it. Now I'll occasionally use it, but I so often need to iterate over multiple arrays that I use indexing much more often.) On 12/01/2015 08:43 AM, Ozan via Digitalmars-d wrote: Hi We all have experience with several programming languages and the great ideas implemented there. It is close to Xmas and I think the right time for wishes about future functions in D. Where is right place to put these inspirations on? Shall we send them directly to the D Foundation presidents? The Secretary? A central mailbox? Regards, Ozan
Re: Right after allocators: containers or database connectivity?
On 06/09/2015 10:56 AM, luminousone via Digitalmars-d wrote: On Tuesday, 9 June 2015 at 17:05:19 UTC, Andrei Alexandrescu wrote: My work on allocators takes the last turn before the straight line. I've arranged with Dicebot to overlap the review period with finalizing details so I can act on feedback quickly. After that I'm ready for some major library work, and I had two things in mind. One would be a good pass of std.container, in particular (a) a design review with the DbI glasses on; (b) better documentation - sadly it seems to me so inadequate as to make containers themselves unusable; (c) investigate use of UFCS - std.container's design predates UFCS yet is a perfect fit for it, and most likely other cool language improvements we've added since. The other would be database connectivity. Erik Smith has shown some cool ideas at DConf, and I encourage him to continue working on them, but it seems to me this is an area where more angles mean more connectivity options. For database connectivity I'm thinking of using ODBC. What I see is that on all major platforms, vendors offer mature, good quality ODBC drivers, and most programs that have anything to do with databases offer ODBC connectivity. So connecting with ODBC means the individual database drivers are already there; no need to waste effort on creating drivers for each (or asking vendors to, which we can't afford). So I gave myself ten minutes the other night just before I went to sleep to see if I can get an ODBC rig on my OSX machine starting from absolutely nothing. I got http://www.odbcmanager.net but then got confused about where to find some dumb driver (text, csv) and gave up. Last night I gave myself another ten minutes, and lo and behold I got up and running. Got a demo CSV driver from http://www.actualtech.com/product_access.php (which also supports Access and others). Then I headed to http://www.easysoft.com/developer/languages/c/odbc_tutorial.html and was able to run a simple ODBC application that lists the available drivers. Nice! It's trivial work to convert the C headers to D declarations. Then it's straight library design to offer convenient libraries on top of the comprehensive but pedestrian ODBC C API. Then, voilà - we'll have database connectivity for all databases out there! Please help me choose what to work on next. Andrei I would think a good database lib would depend on a good container lib, So IMO, the order is self evident. 1000+ to containers. I'd say what it depends on is good serialization. If you extend containers to include disk based B+Trees then I'd agree with you, otherwise not.
Re: What are the worst parts of D?
On 09/20/2014 05:39 AM, Tofu Ninja via Digitalmars-d wrote: There was a recent video[1] by Jonathan Blow about what he would want in a programming language designed specifically for game development. Go, Rust, and D were mentioned and his reason for not wanting to use D is is that it is "too much like C++" although he does not really go into it much and it was a very small part of the video it still brings up some questions. What I am curious is what are the worst parts of D? What sort of things would be done differently if we could start over or if we were designing a D3? I am not asking to try and bash D but because it is helpful to know what's bad as well as good. I will start off... GC by default is a big sore point that everyone brings up "is" expressions are pretty wonky Libraries could definitely be split up better What do you think are the worst parts of D? [1] https://www.youtube.com/watch?v=TH9VCN6UkyQ The worst part of D is the limited libraries. This often causes me to choose Python instead, I'm sure it often causes others to choose Java or C++ or ... Mind you, many of the libraries "sort of" exist, but they don't work well. This is a pity, because if there were, say, a decent wrapper for SQLite then there would be many more uses. (Yes, I know that the C interface code is included...that's why I picked that particular example.) OTOH, it's not clear how to solve this, outside of convincing more people to spend time wrapping libraries. But I'm not the right person, because my prior attempts have ended up being half-hearted failurealso I don't really like the D template syntax. (For that matter I'm dubious about the entire "template" approach, though many people clearly find it reasonable.)
Re: Unicode handling comparison
On 11/27/2013 08:53 AM, Jakob Ovrum wrote: On Wednesday, 27 November 2013 at 16:18:34 UTC, Wyatt wrote: I agree with the assertion that people SHOULD know how unicode works if they want to work with it, but the way our docs are now is off-putting enough that most probably won't learn anything. If they know, they know; if they don't, the wall of jargon is intimidating and hard to grasp (more examples up front of more things that you'd actually use std.uni for). Even though I'm decently familiar with Unicode, I was having trouble following all that (e.g. Isn't "noe\u0308l" a grapheme cluster according to std.uni?). On the flip side, std.utf has a serious dearth of examples and the relationship between the two isn't clear. I thought it was nice that std.uni had a proper terminology section, complete with links to Unicode documents to kick-start beginners to Unicode. It mentions its relationship with std.utf right at the top. Maybe the first paragraph is just too thin, and it's hard to see the big picture. Maybe it should include a small leading paragraph detailing the three levels of Unicode granularity that D/Phobos chooses; arrays of code units -> ranges of code points -> std.uni for graphemes and algorithms. Yes, please. While operations on single codepoints and characters seem pretty robust (i.e. you can do lots of things with and to them), it feels like it just falls apart when you try to work with strings. It honestly surprised me how many things in std.uni don't seem to work on ranges. -Wyatt Most string code is Unicode-correct as long as it works on code points and all inputs are of the same normalization format; explicit grapheme-awareness is rarely a necessity. By that I mean the most common string operations, such as searching, getting a substring etc. will work without any special grapheme decoding (beyond normalization). The hiccups appear when code points are shuffled around, or the order is changed. Apart from these rare string manipulation cases, grapheme awareness is necessary for rendering code. I would put things a bit more emphatically. The codepoint is analogous to assembler, where the character is analogous to a high level language (and the binary representation is analogous to a binary representation). The desire is to make the characters easy to use in a way that is cheap to do. To me this means that the highlevel language (i.e., D) should make it easy to deal with characters, possible to deal with codepoints, and you can deal with binary representations if you really want to. (Also note the isomorphism between assembler code and binary is matched by an isomorphism between codepoints and binary representation.) To do this cheaply, D needs to know what kind of normalization each string is in. This is likely to cost one byte per string, unless there's some slack in the current representation. But is this worth while? This is the direction that things will eventually go, but that doesn't really mean that we need to push them in that direction today. But if D had a default normalization that occurred during i/o operations, to cost of the normalization would probably be lost during the impedance matching between RAM and storage. (Again, however, any default requires the ability to be overridden.) Also, of course, none of this will be of any significance to ASCII. -- Charles Hixson
Re: Unicode handling comparison
On 11/27/2013 06:45 AM, David Nadlinger wrote: On Wednesday, 27 November 2013 at 12:46:38 UTC, bearophile wrote: Through Reddit I have seen this small comparison of Unicode handling between different programming languages: http://mortoray.com/2013/11/27/the-string-type-is-broken/ D+Phobos seem to fail most things (it produces BAFFLE): http://dpaste.dzfl.pl/a5268c435 If you need to perform this kind of operations on Unicode strings in D, you can call normalize (std.uni) on the string first to make sure it is in one of the Normalization Forms. For example, just appending .normalize to your strings (which defaults to NFC) would make the code produce the "expected" results. As far as I'm aware, this behavior is the result of a deliberate decision, as normalizing strings on the fly isn't really cheap. David I don't like the overhead, and I don't know how important this is, but perhaps the best way to solve it would be to have string include a "normalization" byte, saying whether it was normalized, and if so in what way. That there can be multiple ways of normalizing is painful, but it *is* the standard. And this would allow normalization to be skipped whenever the comparison of two strings showed the same normalization (or lack thereof). What to do if they're normalized differently is a bit of a puzzle, but most reasonable solutions would work for most cases, so you just need a way to override the defaults. -- Charles Hixson
Re: D Language Citation
On 11/17/2013 05:44 AM, Sumit Adhikari wrote: Thanks, Book of Andrei is the only material I am left with, nevertheless, some article of Walter is also in my bib file. I am not particular for any specific material in D, my aim is to prove the novelty of D. Hence, my search should be: 1. Qualitative analysis between C++ and D. 2. Outlook of D. 3. Objective orientation in D. Book of Andrei has become too old for what D has walked over last 3 years. I have particular problem to cite them. Thanks for understanding me at least. On Sun, Nov 17, 2013 at 5:26 PM, qznc <mailto:q...@web.de>> wrote: On Sunday, 17 November 2013 at 07:03:53 UTC, Sumit Adhikari wrote: Dear User Community, This mail is in particular to the citation of D. D is extremely poorly cited (Yes this comes from a R&D guy). I searched and searched (everywhere including IEEEXplore) and nothing comes in my hand! There are materials available on internet which are not peer reviewed and hence I cannot use for Journal citation! It is like I have everything but I cannot cite! It would be great idea as a beneficiary of D to publish for the future of D. Please consider what I am saying :). Please publish. In terms of academic citations, there is probably only Andreis book. If you just want a citation for D in general, this is fine. Do you need to reference anything more specific? Alexandrescu A, The D Programming Language, Addison-Wesley, 2010. Publication Date: June 12, 2010 | ISBN-10: 0321635361 | ISBN-13: 978-0321635365 | Edition: 1 -- Sumit Adhikari, IIRC Dr. Dobbs did an article on D a few years ago. Is that publication? (I don't have it anymore, and I don't know for certain that it was in a print edition. Do those matter?) FWIW, no library that I have access to has any information on any computer language less than about a decade old, except for some magazines to which they are donated subscriptions, and which they don't keep around. (I think they officially retain them for about a year now, but they often go missing sooner.) Even the used book stores around here don't stock computer books...which I find quite annoying. -- Charles Hixson
how to compare immutable ints?
(Sorry if this double posts. I'm having trouble getting through at all.) How should I compare immutable ints to ensure that they are actually equal? I was quite surprised to receive the following error message: cbt2.d(732): Error: function object.Object.opEquals (Object o) is not callable using argument types (immutable(int)) when I tried to assert that two values were equal. They were (should be), indeed, immutable ints, but I'd prefer that I could check that they were equivalent without printing them both out. (I'm having a bit of trouble keeping my logic straight, so I'm trying to assert many things that should obviously be true. And sometimes I've been surprised.) -- Charles Hixson
Re: Go rant
Don wrote: > dsimcha wrote: >> == Quote from Don (nos...@nospam.com)'s article >>> "the bubble sort seems to have nothing to recommend it, except a catchy >>> name " - Knuth. >> >> Well, the bubble sort distance is a pretty good metric of how similarly >> ordered >> two lists are. It's useful, for example, in statistics such as Kendall's >> Tau. One of the easiest ways to calculate it is...with a bubble sort. > > I don't think that's a coincidence. It seems to be defined in terms of > bubble sort! > > The whole bubble sort phenonemon seems to be self-perpetuating. There > were loads of really crap algorithms in the 1950's. Why was this one not > forgotten with the rest? Because it's SIMPLE. And because for the small sample sizes used in most classes (still?) scaling with n^2 isn't all that bad. Someone said that the insertion sort is better even for small sample sizes, but if you don't have an array type that implements insertion, then that means writing an extra loop to move things down. I might have suggested that the exchange sort was a good choice. But with small sample sizes and limited memory (no longer a significant problem for cases where this is even vaguely reasonable) the bubble sort isn't that bad. In fact it's difficult to measure the difference as n tends towards 3. For n == 2 there's no other even vaguely reasonable choice. The problem with bubble sorts is the factor of n^2. My teacher might well have been wrong when he put n as high as 25 for where the bubble sort was optimal, but it's clearly optimal when n is less than 4. It's just that those cases don't matter in the real world. (And actually, they'd probably be handled with a case statement, or a nested if.) But if you have code that needs to handle sorting array sizes between 3 and 25 (varying in the calls, and tending towards the low end), then there's no reason to go for anything more complicated. Of course, a better choice yet is often to use a library function. Even if the low end calls have excess overhead, it won't matter much, and you don't need to worry about coding errors. (Yeah, I believe that Knuth said there was no reason for the bubble sort existing. And without knowing the exact context in which he said it, I'm not going to call him wrong. The times to use it are not only extremely limited, there's also a tendency to use it at the wrong times, just because you have the code handy, and it's easy.) P.S.: If you have an Array class, and the array class has an insert method, then the insertion sort is clearly better for building a sorted list. It's less clear if you're sorting a list that you already have, and you're trying to avoid allocating new memory. Especially if it's not stored a container class with an insert method. N.B.: If the bubble sort weren't taught, it would be continually re- invented. And as it's so rarely the proper choice, it needs to be warned against. Preferably by having someone write something that, sorts things interactively, and then having them start adding things to be sorted. But processors may be fast enough to defeat this experiential learning unless you add things in a way that doubles the collection size each time you make an addition.
Re: Go rant
Denis Koroskin wrote: > On Tue, 22 Dec 2009 00:10:44 +0300, Jérôme M. Berger > wrote: > >> Andrei Alexandrescu wrote: >>> Walter Bright wrote: retard wrote: > I have several imperative language programming books and instead of > qsort they introduce the reader to the wonderful world of bubble sort! Bubble sort should be part of an introductory programming course, if only because: 1. it's an algorithm that gets reinvented if one is not aware of it 2. one needs to be able to recognize it, as one will encounter it a lot in production code 3. it's a great way to introduce concepts like big O 4. it's a great stepping stone to introducing better sorts I've run into bubble sort reimplementations in production code written by famous programmers who should know better. It happens all the time. >>> >>> Fro your arguments 1-4 and your conclusion, I infer you made a slight >>> typo. Let me fix that for you. >>> >>> s/should be/should not be/ >>> >> No, he's right, it should be part of any introductory programming >> course, along with a good explanation of why it is so bad. They say >> that "for every problem there is a solution which is simple, >> elegant, and wrong", and bubble sort is as good a way as any to make >> that point. >> >> However, it is essential that the teacher actually *make* that >> point and not leave the students believing that bubble sort is a >> good algorithm. >> >> Jerome > > Bubble sort is not that bad (e.g. a sequence with one element out of > place), it's just niche algorithm. I believe that I was taught that a bubble sort was optimal for lists of fewer than about 25 elements. I.e., where n is very small, the overhead for the other sorts wasn't worth it.
