Hi, https://github.com/D-Programming-Language/druntime/pull/198 Can anyone weigh in on this? I really need to know whether I'm talking nonsense here, or if this is the way forward. Thanks! -- -- Alex Rønne Petersen alex <at> lycus.org http://lycus.org
http://blog.thebird.nl/?p=93 http://www.reddit.com/r/programming/comments/tzpdh/d_is_a_dragon_or_why_d_matters_for_bioinformatics/
On Reddit they have linked an article that shows auto vectorization in GCC 4.7: http://locklessinc.com/articles/vectorize/ http://www.reddit.com/r/programming/comments/tz6ml/autovectorization_with_gcc_47/ GCC is good, it knows many tricks, it contains a lot of pattern matching code and other code to allow such vectorizations, and that C code is almost transparent & standard (restrict is standard, and I think __builtin_assume_aligned isn't too much hard to #define away when not available. And something like --fast-math is available on most compilers (despite Walter doesn't like it)). So it's good to optimize legacy C code too. But this article also shows why such strategy is not usable for serious purposes. If small changes risk turning off such major optimizations, you can't rely much on them. More generally, writing low-level code and hoping the compiler recovers that high level semantics of the code is a bit ridiculous. It's way better to express that semantics in a more direct way, in a standard way that's understood by all compilers of a language (this also because the code shown in that article has very simple semantics). How is the development of the D SIMD ops going? Are those efforts (maybe with the help of another higher level Phobos lib) going to avoid the silly problems shown in that article? Bye, bearophile(Continue reading)
Ha yes, it is on the website. You'll find here an article about that, and how Go do much better because of goroutines : http://blog.bitcartel.com/2012/05/nodejs-cpu-blocking-thing.html I'd be very interested to know how D compare to that, for example with vide.d ?
On 2012-05-22 18:22, shd wrote: > I agree in almost everything what Jacob said. > I would say, that binding generator improvement is even higher than > testing framework though. Absolutely, I just wrote the list in no particular order. But at the same time you need to be able to test the binding generator :) > Tools are good, but making compiler and library more reliable is crucial thing. Yeah, it always comes back to the compiler. And preferably it should be written in D as a library. > Still, some kind of library which would share (AST or i don't know how > to name that) implementation with compilers front-end is just after > that. > I'm not really sure if that's what you mean (since you mentioned more > high-level features), but without separating some code out from > compiler, different IDEs will rewrite the same code again and again. > And i guess we all agree that single IDE wont satisfy needs of > everyone (of course there is more uses of library like that than only > IDEs) That was that I meant. One compiler library every tool can take advantage of. The actual compiler should use the library as well, of course. -- -- /Jacob Carlborg(Continue reading)
Since Win9x isn't supported any more why do we have ASCII WinAPI
functions in druntime's core.sys.windows.windows (and, possibly, other
places)?
Reasons against *A functions:
* using of every such function is unsafe (with really seldom exceptions
like LoadLibraryA("ntdll")) because inability to encode non-ASCII
characters to OEM encoding will almost always give unpredictable results
for programmer (simple test: you, reader, what will happen?);
* in D it's too easy to make a mistake by passing UTF-8 string pointer
to such function because D has no string types other than UTF and
elimination of such function is the only solution unless ASCII string
type is created
* it performs worse because Windows has to convert ASCII string to
UTF-16 first
And yes, druntime already has encoding bugs because of using such functions.
P.S.
Let's finally solve encoding problems that should be solved 10 years
ago! By the way, Git+TurtoiseGit still has encoding problems on Windows
and it is awful (see its changelog).
--
--
Денис В. Шеломовский
Denis V. Shelomovskij
On Tuesday, 22 May 2012 at 16:23:46 UTC, Kevin Cox wrote: > On May 22, 2012 12:13 PM, "s" <some <at> one.com> wrote: >> +1 for a GUI lib, which is in sync with DMD releases. > Is there any way to bind Qt without the dreaded moc and > friends? Because > that would give you a cross platform solution without too much > work. QtD? It includes a CTFE/template-based substitute for moc. David
On Tuesday, 22 May 2012 at 16:23:46 UTC, Kevin Cox wrote: > On May 22, 2012 12:13 PM, "s" <some <at> one.com> wrote: >> >> +1 for a GUI lib, which is in sync with DMD releases. >> > > Is there any way to bind Qt without the dreaded moc and > friends? Because > that would give you a cross platform solution without too much > work. Surely much of the functionality moc provides can be replaced by proper D features?
On Tuesday, 22 May 2012 at 16:23:46 UTC, Kevin Cox wrote: > On May 22, 2012 12:13 PM, "s" <some <at> one.com> wrote: >> >> +1 for a GUI lib, which is in sync with DMD releases. >> > > Is there any way to bind Qt without the dreaded moc and > friends? Because > that would give you a cross platform solution without too much > work. Well, for cross-platform Gtk+ should be enough, and it has C bindings.
An interesting post and case for using D in bioinformatics by Pjotr Prins http://blog.thebird.nl/?p=93
http://d-coding.com/2012/05/22/dct-use-cases.html
RSS Feed2560 | |
|---|---|
2886 | |
3307 | |
2790 | |
2760 | |
3584 | |
2360 | |
2244 | |
2235 | |
2125 | |
1708 | |
2536 | |
1564 | |
2279 | |
2537 | |
2480 | |
2670 | |
2317 | |
2580 | |
2672 | |
1574 | |
2284 | |
1353 | |
2104 | |
1281 | |
944 | |
1678 | |
1296 | |
1253 | |
1695 | |
2696 | |
2645 | |
1414 | |
1205 | |
1905 | |
1130 | |
2414 | |
2087 | |
1971 | |
1862 | |
1614 | |
1253 | |
708 |
