Re: RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)
I somehow missed this topic earlier but I played a bit with embedded runtime last month so I'll share some thoughts. On Sunday, 10 May 2015 at 06:55:07 UTC, Jens Bauer wrote: On Sunday, 10 May 2015 at 01:55:53 UTC, Mike wrote: I've also considered another interesting approach. It seems possible to port all features of D right to the metal, essentially embedding the RTOS directly into the runtime. Then D is your RTOS :-) I do like this approach better, and that resembles the way I've been thinking until now. Yes, it might require more work, but strongly I think it's worth it. I believe this would also give the user the most convenient D-compiler (and toolchain). I'm also strongly in favor of integrating an RTOS with the runtime, especially if we publish it under a liberal license, just as the D runtime is distributed now. Since most of existing RTOSes are distributed under either proprietary license or GPL, having a ready-to-use RTOS without legal restrictions could work towards the adoption of D in the embedded market. I would start with evaluating the existing concurrency APIs in terms of their applicability in such RTOS. Generally, if we stick to the pay-as-you-go approach most features of D runtime (even exceptions and RTTI) can be ported. They will not imply any costs when not used, but will be ready to use out-of-the-box when they're needed. We could advertise it using e.g. automatically generated charts showing the cost of each feature. Also, there are already compiler switches to show GC allocations and TLS variables, so a similar approach could be used for other potentially costly features. As for TLS, I think we should not change D semantics by implicitly making all globals __gshared, but instead follow Dan's suggestion to create a specific TLS model which statically resolves thread-local variables to regular globals in single-threaded builds. I did some experiments with porting small parts of Phobos and druntime. Initial tests show that e.g. semihosted writefln costs about 4KB of flash initially + about 0.5KB per each new argument type list (GDC, -Os, Cortex-M3). Sure, it may seem a lot if your uC has 16KB or less, but in such case you probably wouldn't use formatted output much in C either. You don't pay for it when you don't call it, and when you need it - it's there and it's fully functional and type safe (unlike C's printf). And of course there're probably ways to optimize it. Also I think exceptions could be possible to implement without large costs. I've already got scope(exit) and scope(success) working, and IMHO this is already a huge advantage over manual cleanup. I started working on unwinding using the libgcc support but other duties stopped me from finishing it. I'll try to push this work on github later this week. I've run the above on LM3S6965 (qemu) and STM32F103 (Nucleo-F103RB).
Re: Daily downloads in decline
On 05/06/2015 21:29, extrawurst wrote: On Friday, 5 June 2015 at 19:02:15 UTC, Bruno Medeiros wrote: On 01/06/2015 20:47, weaselcat wrote: at the risk of sounding like a broken record, if ldc/gdc not being 2.067 stops a DDMD release due to dmd's generated code being too slow, maybe it's time to phase dmd out ;) It's past the time. The traction and support that Rust gained, even before 1.0, showed that having your primary toolchain based on GCC or LLVM is the only sustainable way forward (and even of those two, GCC might not be able to keep with LLVM). Nice work on the RustDT IDE btw. (https://users.rust-lang.org/t/rustdt-0-1-0-released-a-new-eclipse-rust-ide) Thanks! (it already has more likes/stars in Github than DDT, even though it's nowhere near as feature full :S ) -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Tuesday, 9 June 2015 at 18:53:06 UTC, Dennis Ritchie wrote: On Tuesday, 9 June 2015 at 18:46:48 UTC, Israel wrote: Ruby that compiles? Yet Rust, Nim and Crystal is a very young languages. And alas, life is not eternal to wait five years of a flourishing language :) There are already ready to be used option. This is D. Yes, Nim and Crystal have a couple of more years to go. Rust has been backed by Mozilla for 6 years and is being used in production projects, so I would not downplay the potential uptake. I think Rust has an advantage over Go in the name Mozilla alone, they are more idealistic than Google. But the Rust memory model will be hard on many programmers, also game programmers who don't want a single-threaded memory model, so D can reach a non-Rust segment over time by focusing on ease-of-use. I think D needs to change focus to get there though, like tweaking the semantics to support faster/local GC and perhaps even move to benchmark-driven design. I don't really think people pick an AoT language because of meta-programming. There are so many semi/dynamic languages with excellent meta-programming-capabilities.
Re: Right after allocators: containers or database connectivity?
On 6/9/15 6:20 PM, Vladimir Panteleev wrote: On Tuesday, 9 June 2015 at 21:53:55 UTC, Andrei Alexandrescu wrote: Also, I think we should stay with libc-based I/O. Um, won't this mean that the library then won't be usable by any application that will want to do more than a few simultaneous queries? Database engines usually concentrate on concurrency, not latency, so non-asynchronous I/O is only adequate for simple programs. He hasn't seen the contrast yet :) In any case, I have zero plans to abandon what I've been working on (glacially) over the last 3 years. -Steve
Re: Right after allocators: containers or database connectivity?
On 6/9/15 7:38 PM, Jonathan M Davis wrote: On Tuesday, 9 June 2015 at 22:37:32 UTC, Andrei Alexandrescu wrote: On 6/9/15 3:11 PM, Jonathan M Davis wrote: And containers are really the main place, I think, where iterators actually do better than ranges. I think iterators would need to add huge value to warrant addition. -- Andrei I don't disagree. I think that we should stick with ranges. I just think that this is one of the few areas where ranges are actually worse than iterators, whereas in most other areas, they're better. The result is that some of the idioms that are used with iterators in C++ become increasingly unwieldy with ranges - finding an element and removing it from the container is probably the simplest example. What's needed is a simple way to refer to exactly one element. I solved that problem in dcollections. -Steve
Re: DIP80: phobos additions
On 6/9/15 5:46 PM, Andrei Alexandrescu wrote: On 6/9/15 1:53 PM, Steven Schveighoffer wrote: On 6/9/15 2:59 PM, Andrei Alexandrescu wrote: On 6/9/15 11:42 AM, Dennis Ritchie wrote: And finally `std.bigint` offers good (but not outstanding) performance. BigInt should use reference counting. Its current approach to allocating new memory for everything is a liability. Could someone file a report for this please. -- Andrei Slightly OT, but this reminds me. RefCounted is not viable when using the GC, because any references on the heap may race against stack-based references. How do you mean that? If you add an instance of RefCounted to a GC-destructed type (either in an array, or as a member of a class), there is the potential that the GC will run the dtor of the RefCounted item in a different thread, opening up the possibility of races. Can we make RefCounted use atomicInc and atomicDec? It will hurt performance a bit, but the current state is not good. I spoke with Erik about this, as he was planning on using RefCounted, but didn't know about the hairy issues with the GC. If we get to a point where we can have a thread-local GC, we can remove the implementation detail of using atomic operations when possible. The obvious solution that comes to mind is adding a Flag!interlocked. Can you explain it further? It's not obvious to me. -Steve
[Issue 13912] Offer to 'import missing packages' like C# and Java
https://issues.dlang.org/show_bug.cgi?id=13912 Jacob Carlborg d...@me.com changed: What|Removed |Added CC||d...@me.com --- Comment #5 from Jacob Carlborg d...@me.com --- In Eclipse, the IDE will automatically add missing imports if autocomplete is used to select a symbol. --
Re: Is it possible to add items to the arrays and hashes at compile time?
On 06/09/2015 09:36 PM, Dennis Ritchie wrote: But I can not do so: enum int[][int][int] ctHash = init_ctHash(5); ctHash = merge(ctHash, init_ctHash(6)); I have a question: why variables may not be initialized more than once? Why can't they to resave at compile time? My phrasing was off: By definition, initialization happens once. :) What I meant is, once initialized, a compile-time variable cannot be reassigned. The reason is, to effect compile time evaluation, one needs to use 'enum' (or 'static const') but 'enum' is a literal, i.e. it cannot be modified. As I've shown, it is possible to use an expression that will be used as the value of the compile-time variable. As long as it is evaluable at compile time, the expression can be arbitrarily complex. Ali
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 16:01:34 UTC, Andrei Alexandrescu wrote: Same as with @safe @nogc @nothrow @pure. No, these are attributes that change the function's type; constexpr does not. AIU, it still does something along those lines. If you don't have ctfeability expressed in function's contract, you have no idea how you can modify the function's implementation so that to not break other people's code. Sorry for making c++ look cute again :) I guess you could do a lot worse than using a unittest to make sure a function is CTFEable. Isn't it Speculatively mark everything in sight as ctfe?
Re: DIP80: phobos additions
On Tuesday, 9 June 2015 at 16:14:24 UTC, Dennis Ritchie wrote: On Tuesday, 9 June 2015 at 15:26:43 UTC, Ilya Yaroshenko wrote: D definitely needs BLAS API support for matrix multiplication. Best BLAS libraries are written in assembler like openBLAS. Otherwise D will have last position in corresponding math benchmarks. Yes, those programs on D, is clearly lagging behind the programmers Wolfram Mathematica :) https://projecteuler.net/language=D https://projecteuler.net/language=Mathematica To solve these problems you need something like Blas. Perhaps BLAS - it's more practical way to enrich D techniques for working with matrices. I suspect this is more about who the Mathematica and D users are as Project Euler is mostly mathematical rather than code optimization. More of the Mathematica users would have strong maths backgrounds. I haven't felt held back by D at all, it's only been my own lack of ability. I'm in 2nd place atm for D users.
Re: DIP80: phobos additions
On Wed, 10 Jun 2015 09:12:15 +, John Chapman wrote: On Wednesday, 10 June 2015 at 07:56:46 UTC, John Chapman wrote: It's a shame ucent/cent never got implemented. But couldn't they be added to Phobos? I often need a 128-bit type with better precision than float and double. Other things I often have a need for: Weak references +inf for including that into Phobos. current implementations are hacks that may stop working when internals will change, but if it will be in Phobos, it will be always up-to-date. signature.asc Description: PGP signature
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 01:21:05 UTC, weaselcat wrote: On Tuesday, 9 June 2015 at 18:25:36 UTC, Dennis Ritchie wrote: On Tuesday, 9 June 2015 at 18:02:55 UTC, Ali Çehreli wrote: http://www.reddit.com/r/programming/comments/396c95/of_the_emerging_systems_languages_rust_d_go_nim/ ... People also refer to Haskell as if it's some new hip language and it's almost as old as ANSI C. It is hip, because all those years have made its compilers quite good and made it one of most important languages currently in the world for Functional Programming research. It also has all these companies paying money for using/improving it: http://industry.haskell.org/partners https://github.com/commercialhaskell/commercialhaskell#readme You will find a few well known names there. -- Paulo
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 07:40:23 UTC, Paulo Pinto wrote: On Wednesday, 10 June 2015 at 01:21:05 UTC, weaselcat wrote: On Tuesday, 9 June 2015 at 18:25:36 UTC, Dennis Ritchie wrote: On Tuesday, 9 June 2015 at 18:02:55 UTC, Ali Çehreli wrote: http://www.reddit.com/r/programming/comments/396c95/of_the_emerging_systems_languages_rust_d_go_nim/ ... People also refer to Haskell as if it's some new hip language and it's almost as old as ANSI C. It is hip, because all those years have made its compilers quite good and made it one of most important languages currently in the world for Functional Programming research. It also has all these companies paying money for using/improving it: http://industry.haskell.org/partners https://github.com/commercialhaskell/commercialhaskell#readme You will find a few well known names there. -- Paulo only one that really stands out is microsoft, and haskell is basically a microsoft research project at this point.
Re: [OT] Modules dropped out of C++17
On 2015-06-10 01:02, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: I could, but D would not check it? It could most likely be implemented with AST macros. -- /Jacob Carlborg
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 08:17:05 UTC, weaselcat wrote: On Wednesday, 10 June 2015 at 07:40:23 UTC, Paulo Pinto wrote: On Wednesday, 10 June 2015 at 01:21:05 UTC, weaselcat wrote: On Tuesday, 9 June 2015 at 18:25:36 UTC, Dennis Ritchie wrote: On Tuesday, 9 June 2015 at 18:02:55 UTC, Ali Çehreli wrote: http://www.reddit.com/r/programming/comments/396c95/of_the_emerging_systems_languages_rust_d_go_nim/ ... People also refer to Haskell as if it's some new hip language and it's almost as old as ANSI C. It is hip, because all those years have made its compilers quite good and made it one of most important languages currently in the world for Functional Programming research. It also has all these companies paying money for using/improving it: http://industry.haskell.org/partners https://github.com/commercialhaskell/commercialhaskell#readme You will find a few well known names there. -- Paulo only one that really stands out is microsoft, and haskell is basically a microsoft research project at this point. Facebook Banks like Standard Chartered, Tsuru Capital, Capital Match,...
Re: [OT] Modules dropped out of C++17
On 10/06/15 11:31, Kagamin wrote: Huh? If you have type's method diskIdx and a local variable diskIdx, and they are confusing, what it has to do with UFCS? auto diskIdx = data.diskIdx();
Re: Right after allocators: containers or database connectivity?
On Tuesday, 9 June 2015 at 17:56:57 UTC, luminousone 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. Yep. Containers. containers + right allocation strategy = interfacing to data base with the right containers
Re: DIP80: phobos additions
On Wednesday, 10 June 2015 at 09:30:37 UTC, Robert burner Schadek wrote: On Wednesday, 10 June 2015 at 09:12:17 UTC, John Chapman wrote: Logging std.experimental.logger!? Perfect, he said sheepishly.
Re: DIP80: phobos additions
On Wednesday, 10 June 2015 at 08:50:31 UTC, Dennis Ritchie wrote: On Wednesday, 10 June 2015 at 08:39:12 UTC, ixid wrote: I suspect this is more about who the Mathematica and D users are as Project Euler is mostly mathematical rather than code optimization. Here and I say that despite the fact that in D BigInt not optimized very well, it helps me to solve a wide range of tasks that do not require high performance, so I want to BLAS or something similar was in D. Something is better than nothing! You rarely need to use BigInt for heavy lifting though, often it's just summing, not that I would argue against optimization. I think speed is absolutely vital and one of the most powerful things we could do to promote D would be to run the best benchmarks site for all language comers and make sure D does very well. Every time there's a benchmark contest it seems to unearth D performance issues that can be greatly improved upon. I'm sure you will beat me pretty quickly, as I said my maths isn't very good but it might motivate me to solve some more! =)
Re: Bug 14666, can we prioritize ?
2015-06-10 15:55 GMT+09:00 Walter Bright via Digitalmars-d digitalmars-d@puremagic.com: On 6/9/2015 10:39 PM, deadalnix wrote: The actual code is far more complex than the presented sample :) That what I'm trying to do in general, but here I'm faced with cases that are very hard to untangle. The 'tangle' of cyclical import graphs, as you so appropriately put, is not only hard on the compiler, it makes it much harder for human readers to make sense of code. Even reading your little code snippet hurts my brain. Go, in one of their better decisions, decided Thou Shalt Not Have Import Cycles. This forces users to untangle their code, and I believe that is A Good Thing. I'd like to do that for D, but of course it is far too late for that. D has true forward reference resolution mechanism. In that case modules are cyclic imported, but the declared symbols don't have actual cyclic references. Therefore the snippet should work. https://github.com/D-Programming-Language/dmd/pull/4735 And the regression was introduced by your unrelated change. While fixing the issue, I couldn't understand why it was necessary. https://github.com/D-Programming-Language/dmd/commit/a04cf864b932061ad7b72e7cad8b16fabc6a825a Kenji Hara
Re: [OT] Modules dropped out of C++17
On Wednesday, 10 June 2015 at 08:53:40 UTC, Shachar Shemesh wrote: On 10/06/15 11:31, Kagamin wrote: Huh? If you have type's method diskIdx and a local variable diskIdx, and they are confusing, what it has to do with UFCS? auto diskIdx = data.diskIdx(); auto diskIdx1 = this.diskIdx; diskIdx1 = f(diskIdx1); return diskIdx;
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 17:43:18 UTC, Steven Schveighoffer wrote: On 6/9/15 4:06 AM, Brian Schott wrote: On Tuesday, 9 June 2015 at 07:49:24 UTC, Shachar Shemesh wrote: Also, you say 5 seconds as if that's a short amount of time. If it takes an automatic scanner 5 seconds, it means the amount of coverage it needs to perform is huge. If anybody was wondering why DCD doesn't support UFCS, this is the answer. I can't find a way to make it fast, useful, or compact in terms of memory use. I can't see how a UFCS lookup is any slower than a normal function lookup. It's just a rewrite. i.e.: a.foo 1. try finding member foo on type a. 2. try finding function foo a. If found, find overload that will take a. What happens as you type: foo(a ??? how is it any different? -Steve One problem is that any auto-complete list becomes completely unmanageable.
[Issue 14675] New: template specialization for T: T* and T: T[] has issues with IFTI
https://issues.dlang.org/show_bug.cgi?id=14675
Issue ID: 14675
Summary: template specialization for T: T* and T: T[] has
issues with IFTI
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: spec
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: schvei...@yahoo.com
Some background:
http://forum.dlang.org/post/rvflnpxwzetpcphwx...@forum.dlang.org
When a specialization of the form:
void foo(T : T*)(T* t)
void foo(T : T[])(T[] t)
exists in a function template, it cannot be matched for IFTI, only explicit
instantiation:
int i;
foo(i); // error
foo!(int *)(i); // ok
However, this will match both calls:
void foo(T : U*, U)(T t)
void foo(T : U[], U)(T t)
The docs say that parameters involved with specialization cannot be used for
IFTI, but that simply isn't the case for almost all specializations (2 examples
are the secondary forms above). Just these 2 as far as I can tell don't work.
First, their existence is redundant. The secondary forms are superior in almost
every way.
Second, they are confusing. A T is specialized as a T*? But then it's not?
Third, if they must exist, I think they should be usable with IFTI. There
doesn't seem to be any reasonable explanation as to why these particular
templates cannot be used for IFTI.
As an example of why this is important, consider the following:
void foo(T)(T t) { /* impl 1 */}
void foo(T:T*)(T* t) { /* impl 2 */}
int i;
foo(i); // calls impl 1
foo!(typeof(i))(i) // calls impl 2
This makes absolutely no sense, and seems extremely error prone.
Valid resolutions here:
1. Deprecate. This would break some code, but the ability to use the second
form at least gives a path forward.
2. Allow IFTI. At least this would not break code (at least not *reasonable*
code), but could potentially change code paths. It's possible someone has
exploited this confusing behavior to have two code paths for calling a function
with the same parameters. I don't think we should support this though.
--
[Issue 14666] [REG2.061] Bogus forward reference error
https://issues.dlang.org/show_bug.cgi?id=14666 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid Hardware|x86 |All OS|Mac OS X|All --- Comment #5 from Kenji Hara k.hara...@gmail.com --- (In reply to deadalnix from comment #4) Sorry for the missing filenames, here they are: [snip] Thanks! https://github.com/D-Programming-Language/dmd/pull/4735 --
Re: Right after allocators: containers or database connectivity?
Containers seems like the best thing to work on after the allocators. Then you could start using the allocators for the containers, so you can choose different allocation strategies for them. I'd definitely like to see a standard container for sets, instead of the void[0][T] thing I usually do.
Re: Make dub part of the standard dmd distribution
Am 04.06.2015 um 17:47 schrieb Atila Neves: On a related note, it's also a pity that Reggae mixes incremental build improvements (from which DUB itself could greatly profit, too - just as a Ninja generator for DUB would be a nice feature) with a separate, layered build description. I mean there is of course no reason to not have alternative approaches for build descriptions available in general, but when mixed with a public package repository, it just leads to fragmentation. I can add a ninja generator to dub if you want, with the default being per-package compilation (since right now for dub it's one file or everything at once). That would be great! If the per-package mode has such practical benefits, we could also simply make it the general default, for all generators that can support it. However, I just briefly looked at your benchmark results, the performance boost seems to be solely because of parallel compiler invocations. We already had issues with per-module parallel compilation and out-of-memory errors, so this optimization seems to be only suitable for certain projects or build machines. So at least with the current compiler memory requirements I'm not sure if this would be a good default build mode. But I wrote reggae because: 1. Declarative is preferable but imperative is needed. My (our?) favourite imperative language is D, so I want to specify builds in it. This is of course perfectly fine and reasonable (although I personally find the D syntax to be a bit too verbose for this task, but thats really just personal taste - oh, and JSON is awful, too ;). The problems just start to creep in as soon as public DUB packages start to depend on Reggae - then we'll possibly get another split in the ecosystem. I'd say we should generally try to focus on a single standard solution, however that looks and however the tool is split into executables or packages. 2. I want a build tool that builds on dub but doesn't require it Fair enough. 3. I wanted it to make it easy to link with C and C++ This really also needs to be solved within DUB (i.e. without resorting to preBuildCommands). That is going to be the next priority after getting the 1.0.0 features ready. As I've mentioned before, I know the kind of things I'd want to do with the build system if I had a large and complicated enough project, and I know I wouldn't be able to do it easily using dub alone. As I've also mentioned before, building with dub is just fine for most people. Getting some of those use cases on a Wiki page or something would be great. There have been some ideas to approach the procedural aspect from a different angle - using procedural DUB plugins that can be invoked from within the declarative build description. This would have the advantage that a lot of information can be gathered about a package without executing procedural code (with the possible accompanying security risks and performance issues or the efforts needed to mitigate those). I don't know if fragmentation would be an issue. The packages are still dub packages and I for one will use dub.json/sdl to list my dependencies even if reggae is actually generating the build. Yeah that would definitely not be an issue. I just fear (maybe unnecessarily) that people might start to put packages in the registry that can *only* be built using Reggae (or some other build tool). At least for libraries that would really be bad.
[Issue 14672] [REG2.067.0] Internal error: e2ir.c 4620 when copying array of derived class to an array of base class
https://issues.dlang.org/show_bug.cgi?id=14672 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --
[Issue 14672] [REG2.067.0] Internal error: e2ir.c 4620 when copying array of derived class to an array of base class
https://issues.dlang.org/show_bug.cgi?id=14672 --- Comment #2 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4736 --
Re: Make dub part of the standard dmd distribution
Am 05.06.2015 um 11:56 schrieb Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net:
On Thursday, 4 June 2015 at 13:47:41 UTC, Sönke Ludwig wrote:
A branch *is* an exact version as far as DUB goes (just one that
changes over time).
Well, that's the problem then.
But to make use of any commit relationships within a branch, it would
have to gain specific knowledge of GIT or other version management
systems.
Adding support for commit hashes in dub.selections.json is still TBD,
but would be another alternative.
I'd say it's the only consistent way.
BTW, my primary concern with all of these things is retaining a
healthy public package eco system. I personally suspect that this is
much more important for the language as a whole rather than pleasing
every single taste. This doesn't mean that the latter isn't a
worthwhile goal, but to me the former has always been more important.
What is missing is a proposal how to solve both issues at the same time.
I can understand that. But from what I've seen with rubygems, it is not
a problem in practice. You're totally right that released packages
shouldn't have such dependencies. A warning message in dub or a check on
code.dlang.org is totally okay IMO.
Well, enforcing it on code.dlang.org would indeed be an option. I still
think that using the version backed approach below, or VCS facilities is
superior in general, though. There is not much objective reason to
duplicate that functionality in the package manager AFAICS.
For example for conflict resolution. This is the foremost reason why
the *have* to be banned from dub.json. You can't really know if a
branch matches/is compatible with any particular version (range) or
another branch, so you have to either make an arbitrary guess (always
prefer the branch; always prefer the version; always prefer master,
but a tagged version otherwise; etc.), or always issue a version
conflict error.
Definitely always prefer the branch. The goal is to let the developer
override the decisions made by upstream library authors.
That's what dub.selections.json is for! It applies only to the top level
project, which can make such decisions. On the other hand, if you always
prefer the branch during *dependency resolution*, some deeply buried
dependency can simply break your build (or any upstream build) because
it chose to use an incompatible branch based dependency.
The practical effect that was already very visible in the existing
ecosystem was that packages tended to separate into two clusters. One
cluster that used branch dependencies and another that used version
dependencies. Both incompatible with each other. It also meant that a
lot of people didn't bother to make any version tags at all, which is
understandable, but also a very bad influence to the stability of the
ecosystem. Semantic versioning, if used correctly, is a very important
factor in that regard.
Yes, but that's a social problem. We can nudge people in the right
direction by printing a warning message, or even by rejecting it
completely on code.dlang.org.
The compromise solution to allow branch based dependencies only in the
version selection file doesn't really have drawbacks, but dodges all
of those issues by moving the decision to the root of the dependency
tree.
I does have obvious drawbacks: If dub.selections.json contains non-exact
versions, different developers can get slightly different dependencies.
dub.selections.json must fully determine the versions that are going to
be used, otherwise it has failed its purpose.
You can also check out certain branches locally and use dub
add-local or dub add-path to let DUB use it instead of the publicly
registered one.
This is not an option in a larger team. Everyone would have to do that
manually, or you'd need to write a custom script to do what is actually
the package manager's task.
Using dub.selections.json should be the right tool then.
As explained above, it isn't.
If you want commit granularity then that's a different thing. The
intended way to support this is to still use version tags - DUB will
then associate a branch with the latest matching version tag, so that
normal version based dependencies can be used.
If that case applies, dub.selections.json will contain something like
{somedep: 1.0.0+commit.14.f23a56gb}. Currently this information
isn't used to drive GIT to fetch the right tag, but a ticket for that is
open and this could be a viable middleground solution.
You could of course also use things like git submodules + path based
dependencies in this case, there is no need to force everything into
one schema (especially when it doesn't fit well, such as versions and
branches).
Yes, and I'm sure I can come up with even more workarounds ;-)
It's not really a workaround. The package manager has a version based
dependency handling logic that has the proper semantics for this kind of
task. Trying to squeeze branches and commits into this isn't
Re: Bug 14666, can we prioritize ?
I have always been wondering why cyclic imports are allowed in D and if those enable certain design that is not possible otherwise. That mixin case sounds interesting but doesn't click :)
Re: Make dub part of the standard dmd distribution
That would be great! If the per-package mode has such practical benefits, we could also simply make it the general default, for all generators that can support it. However, I just briefly looked at your benchmark results, the performance boost seems to be solely because of parallel compiler invocations. We already had issues with per-module parallel compilation and out-of-memory errors, so this optimization seems to be only suitable for certain projects or build machines. So at least with the current compiler memory requirements I'm not sure if this would be a good default build mode. From mine and Andrei's results it seems to be a much better default. This is of course perfectly fine and reasonable (although I personally find the D syntax to be a bit too verbose for this task, but thats really just personal taste - oh, and JSON is awful, too ;). The problems just start to creep in as soon as public DUB packages start to depend on Reggae - then we'll possibly get another split in the ecosystem. I'd say we should generally try to focus on a single standard solution, however that looks and however the tool is split into executables or packages. I'm working on the syntax ;) As I've mentioned before, I know the kind of things I'd want to do with the build system if I had a large and complicated enough project, and I know I wouldn't be able to do it easily using dub alone. As I've also mentioned before, building with dub is just fine for most people. Getting some of those use cases on a Wiki page or something would be great. I'd have to go back to my old work project and read all the CMake code... I don't know if fragmentation would be an issue. The packages are still dub packages and I for one will use dub.json/sdl to list my dependencies even if reggae is actually generating the build. Yeah that would definitely not be an issue. I just fear (maybe unnecessarily) that people might start to put packages in the registry that can *only* be built using Reggae (or some other build tool). At least for libraries that would really be bad. I think that if a project is a dub package, then it needs to be able to be built with dub. If anything on code.dlang.org doesn't (correctly) build with `dub build` then that would be incredibly wrong. Also, I'm not as sure as you that reggae will catch on that much :) Atila
[Issue 13912] Offer to 'import missing packages' like C# and Java
https://issues.dlang.org/show_bug.cgi?id=13912 --- Comment #4 from Manu turkey...@gmail.com --- (In reply to Rainer Schuetze from comment #3) Let's see if Mono-D can do it, we might then be able to do it, too ;-) More seriously, with the current rush to use selective local imports, a little more interaction might be necessary to select where to put that import. Also, adding to existing imports might be desirable... Yeah you're right, it's a lot more comprehensive than C# :) I can imagine some nice solutions, but yeah, quite a few details. There are 4 states I can imagine, global/local (ie, import placed in local function) and whole-module/single-symbol. There would want to be logic such that single-symbol imports would be appended to a comma separated list of other symbols that may already be import from the same module. The 4 states that the user may select may be a little awkward for ui :) --
Re: Right after allocators: containers or database connectivity?
On Wednesday, 10 June 2015 at 07:50:24 UTC, Jacob Carlborg wrote: On 2015-06-09 20:49, Brad Anderson wrote: 1. vector/array 2. hash map 3. hash set 4. flat map 5. flat set 6. map 7. set 8. deque 9. stack 10. queue 11. linked list 12. hash multimap 13. hash multiset 14. flat multimap 15. flat multiset 16. multimap 17. multiset 18. priority queue I think RedBlackTree isn't a very good name though. It's long and is an implementation detail. In that case you would need to remove hash and perhaps flat from all containers to be consistent. Also linked list would be just list. It would be difficult to come up with better names since there would be name clashes. It would be useful to have trees, heaps, (un)directed graphs...
Re: Right after allocators: containers or database connectivity?
On 2015-06-09 20:49, Brad Anderson wrote: 1. vector/array 2. hash map 3. hash set 4. flat map 5. flat set 6. map 7. set 8. deque 9. stack 10. queue 11. linked list 12. hash multimap 13. hash multiset 14. flat multimap 15. flat multiset 16. multimap 17. multiset 18. priority queue I think RedBlackTree isn't a very good name though. It's long and is an implementation detail. In that case you would need to remove hash and perhaps flat from all containers to be consistent. Also linked list would be just list. It would be difficult to come up with better names since there would be name clashes. -- /Jacob Carlborg
Re: DIP80: phobos additions
It's a shame ucent/cent never got implemented. But couldn't they be added to Phobos? I often need a 128-bit type with better precision than float and double.
Re: rt_finalize question
On Wednesday, 10 June 2015 at 00:04:16 UTC, Oleg B wrote: Why it's extern(C)? For easy linking. What must do collectHandler function? Looks like it overrides the destruction procedure. If I understand correctly monitor relates to multithreading control (Mutex?). Yes.
Re: DIP80: phobos additions
On Wednesday, 10 June 2015 at 07:56:46 UTC, John Chapman wrote: It's a shame ucent/cent never got implemented. But couldn't they be added to Phobos? I often need a 128-bit type with better precision than float and double. I think the next release of LDC will support it, at least on some platforms...
Re: DIP80: phobos additions
On Wednesday, 10 June 2015 at 09:12:17 UTC, John Chapman wrote: Logging std.experimental.logger!?
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote: One big difference between the D community and other languages' communities is is that D people keep criticizing the language and see every little flaw in every little corner, which is good and which is why D is the way it is. Other languages' communities are more like This is theee language of the future, it's super-duper, no question asked, none permitted either! this is actually one of my favorite parts of the D community too(besides it being extremely friendly/helpful) bunch of language snobs on this NG ;)
Re: Daily downloads in decline
On 10/06/2015 7:02 p.m., deadalnix wrote: On Wednesday, 10 June 2015 at 04:55:43 UTC, Rikki Cattermole wrote: I think that a lot of the people asking for a 2.067 LDC are just users of D, and (I am including myself in this group) a lot of those people don't know the first thing about LLVM or good complier design in general. While it may seem dishonest for people to ask for these things and not help, keep in mind that the vast majority of programmers are not even able to help. I for one would love to help. But I barely understand X86. Not to mention having to get a setup going ext. Not really worth it right now for me. Although I'd rather work on SDC instead of LDC. Primarily because well it's so shinyy. I would be happy to write a book to teach compiler development from everything from basic x86 encoding to complex optimization strategies. If only I knew it and yes I know they exist just wrong method for teaching it IMO. Lately, I've been listening to a playlist of interview, presentations and other thing involving Elon Musk. The playlist is hours long and I'm listening to it while doing other things. After selling paypal, Musk wanted to use part of his money to revive the desire to explore space. What he plan to do is to send a plant on Mars, a very symbolic stunt that would, he hopes, renew the interest in space exploration, maybe increase NASA funding or whatnot. Thing is, he doesn't know about space that much. He has a physic major working on batteries, and then went to have a payment processing company. So he could have said, like you guys, well I don't know much about space/compiler let's wait for others to make things happen. But nope, he went to talk to space specialists, engineer and scientists, and then, went got in touch with some Russian to buy refurbished ICBM in order to start experimenting. One of the notable thing is how amazed people are that he went to buy ICBM from the russian. Well guess what, that is one of the cheapest thing that can go into space, so if you want to make something happen, that is an excellent starting point. I can continue the story with myself (because everyone knows I compare to Elon in so many ways, and he is greatly inspired by my vision and capability to make things happen). Recently I got to a point on SDC where working on the GC became an important item. Thing is, I know about compiler not memory allocator. Having low level knowledge of how the CPU operate does not provide me wisdom about what kind of algorithm and datastructure will behave nicely on a typical wokload. So I went to read tcmalloc source code, jemalloc source code, libc's malloc, I read a ton of paper about various allocators, and went after Jason Evan - one of the great perk of working for Facebook is to have all these amazing people who can make you feel like an idiot because they know so much more than you do - as to get as much of the why as possible. the code told me the what/how but that is not sufficient to get a good grasp of the matter at hand. Making things happen is not about waiting for the wisdom to fall from the sky to deliver you the deep and arcane knowledge of compiler/memory management/rocketry . It is about learning enough to get started, and then start do do thing while continuing to learn more. To get back on point, yes some task in LDC or SDC (or DMD, or GDC) require some good knowledge of compiler stuff. Obviously, these are compiler, and I'd add D compiler, which involve a certain level of complexity. But let's be honest, a good chunk of the work is not guru level compiler arcane. Most of the work is actually dumb shit that just need to be done like it is for all other software. You don't wait to know how to paint like Rembrandt to start painting. Because that will never happen. You just paint dumb shit again and again, trying to make the new shit a bit less shitty than the old shit. You do that while studying Rembrandt's techniques. And, after thousand of painting, you finally get there. I'm well aware. I've been hammering out over long term to learn the underlying technologies. For example writing a PE-COFF linker. My experience is well ugh lets just say, if something seems hard and almost impossible maybe something isn't quite right. Unfortunately I'm in a war of attrition trying to learn x86 and friends. And its a long one!
Re: DIP80: phobos additions
On Wednesday, 10 June 2015 at 08:39:12 UTC, ixid wrote: I suspect this is more about who the Mathematica and D users are as Project Euler is mostly mathematical rather than code optimization. More of the Mathematica users would have strong maths backgrounds. I haven't felt held back by D at all, it's only been my own lack of ability. I'm in 2nd place atm for D users. OK, if D is at least BLAS, I will try to overtake you :)
Re: DIP80: phobos additions
On Wednesday, 10 June 2015 at 07:56:46 UTC, John Chapman wrote: It's a shame ucent/cent never got implemented. But couldn't they be added to Phobos? I often need a 128-bit type with better precision than float and double. Other things I often have a need for: Weak references Queues, stacks, sets Logging Custom date/time formatting Locale-aware number/currency formatting HMAC (for OAuth) URI parsing Sending email (SMTP) Continuations for std.parallelism.Task Database connectivity (sounds like this is on the cards) HTTP listener
Re: Right after allocators: containers or database connectivity?
On Tuesday, 9 June 2015 at 17:05:19 UTC, Andrei Alexandrescu wrote: Please help me choose what to work on next. Andrei My vote goes for std.containers! Anyway imho std.database should be a generic database module. Not a sql-oriented one. ODBC is sql-oriented! If not, call it std.sql or std.database.sql. Andrea
Re: Daily downloads in decline
On 10 June 2015 at 09:02, deadalnix via Digitalmars-d digitalmars-d@puremagic.com wrote: On Wednesday, 10 June 2015 at 04:55:43 UTC, Rikki Cattermole wrote: I think that a lot of the people asking for a 2.067 LDC are just users of D, and (I am including myself in this group) a lot of those people don't know the first thing about LLVM or good complier design in general. While it may seem dishonest for people to ask for these things and not help, keep in mind that the vast majority of programmers are not even able to help. I for one would love to help. But I barely understand X86. Not to mention having to get a setup going ext. Not really worth it right now for me. Although I'd rather work on SDC instead of LDC. Primarily because well it's so shinyy. I would be happy to write a book to teach compiler development from everything from basic x86 encoding to complex optimization strategies. If only I knew it and yes I know they exist just wrong method for teaching it IMO. Lately, I've been listening to a playlist of interview, presentations and other thing involving Elon Musk. The playlist is hours long and I'm listening to it while doing other things. After selling paypal, Musk wanted to use part of his money to revive the desire to explore space. What he plan to do is to send a plant on Mars, a very symbolic stunt that would, he hopes, renew the interest in space exploration, maybe increase NASA funding or whatnot. Thing is, he doesn't know about space that much. He has a physic major working on batteries, and then went to have a payment processing company. So he could have said, like you guys, well I don't know much about space/compiler let's wait for others to make things happen. But nope, he went to talk to space specialists, engineer and scientists, and then, went got in touch with some Russian to buy refurbished ICBM in order to start experimenting. One of the notable thing is how amazed people are that he went to buy ICBM from the russian. Well guess what, that is one of the cheapest thing that can go into space, so if you want to make something happen, that is an excellent starting point. I can continue the story with myself (because everyone knows I compare to Elon in so many ways, and he is greatly inspired by my vision and capability to make things happen). Recently I got to a point on SDC where working on the GC became an important item. Thing is, I know about compiler not memory allocator. Having low level knowledge of how the CPU operate does not provide me wisdom about what kind of algorithm and datastructure will behave nicely on a typical wokload. So I went to read tcmalloc source code, jemalloc source code, libc's malloc, I read a ton of paper about various allocators, and went after Jason Evan - one of the great perk of working for Facebook is to have all these amazing people who can make you feel like an idiot because they know so much more than you do - as to get as much of the why as possible. the code told me the what/how but that is not sufficient to get a good grasp of the matter at hand. Making things happen is not about waiting for the wisdom to fall from the sky to deliver you the deep and arcane knowledge of compiler/memory management/rocketry . It is about learning enough to get started, and then start do do thing while continuing to learn more. To get back on point, yes some task in LDC or SDC (or DMD, or GDC) require some good knowledge of compiler stuff. Obviously, these are compiler, and I'd add D compiler, which involve a certain level of complexity. But let's be honest, a good chunk of the work is not guru level compiler arcane. Most of the work is actually dumb shit that just need to be done like it is for all other software. +1 The current 'arcane' job being done in my camp is encapulating related codegen routines under a single umbrella.
Re: Daily downloads in decline
On 10/06/2015 7:35 p.m., Iain Buclaw via Digitalmars-d wrote: On 10 June 2015 at 09:11, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote: On 10/06/2015 7:02 p.m., deadalnix wrote: On Wednesday, 10 June 2015 at 04:55:43 UTC, Rikki Cattermole wrote: I think that a lot of the people asking for a 2.067 LDC are just users of D, and (I am including myself in this group) a lot of those people don't know the first thing about LLVM or good complier design in general. While it may seem dishonest for people to ask for these things and not help, keep in mind that the vast majority of programmers are not even able to help. I for one would love to help. But I barely understand X86. Not to mention having to get a setup going ext. Not really worth it right now for me. Although I'd rather work on SDC instead of LDC. Primarily because well it's so shinyy. I would be happy to write a book to teach compiler development from everything from basic x86 encoding to complex optimization strategies. If only I knew it and yes I know they exist just wrong method for teaching it IMO. Lately, I've been listening to a playlist of interview, presentations and other thing involving Elon Musk. The playlist is hours long and I'm listening to it while doing other things. After selling paypal, Musk wanted to use part of his money to revive the desire to explore space. What he plan to do is to send a plant on Mars, a very symbolic stunt that would, he hopes, renew the interest in space exploration, maybe increase NASA funding or whatnot. Thing is, he doesn't know about space that much. He has a physic major working on batteries, and then went to have a payment processing company. So he could have said, like you guys, well I don't know much about space/compiler let's wait for others to make things happen. But nope, he went to talk to space specialists, engineer and scientists, and then, went got in touch with some Russian to buy refurbished ICBM in order to start experimenting. One of the notable thing is how amazed people are that he went to buy ICBM from the russian. Well guess what, that is one of the cheapest thing that can go into space, so if you want to make something happen, that is an excellent starting point. I can continue the story with myself (because everyone knows I compare to Elon in so many ways, and he is greatly inspired by my vision and capability to make things happen). Recently I got to a point on SDC where working on the GC became an important item. Thing is, I know about compiler not memory allocator. Having low level knowledge of how the CPU operate does not provide me wisdom about what kind of algorithm and datastructure will behave nicely on a typical wokload. So I went to read tcmalloc source code, jemalloc source code, libc's malloc, I read a ton of paper about various allocators, and went after Jason Evan - one of the great perk of working for Facebook is to have all these amazing people who can make you feel like an idiot because they know so much more than you do - as to get as much of the why as possible. the code told me the what/how but that is not sufficient to get a good grasp of the matter at hand. Making things happen is not about waiting for the wisdom to fall from the sky to deliver you the deep and arcane knowledge of compiler/memory management/rocketry . It is about learning enough to get started, and then start do do thing while continuing to learn more. To get back on point, yes some task in LDC or SDC (or DMD, or GDC) require some good knowledge of compiler stuff. Obviously, these are compiler, and I'd add D compiler, which involve a certain level of complexity. But let's be honest, a good chunk of the work is not guru level compiler arcane. Most of the work is actually dumb shit that just need to be done like it is for all other software. You don't wait to know how to paint like Rembrandt to start painting. Because that will never happen. You just paint dumb shit again and again, trying to make the new shit a bit less
Re: [OT] Modules dropped out of C++17
On Wednesday, 10 June 2015 at 06:34:13 UTC, Shachar Shemesh wrote: On 10/06/15 09:14, deadalnix wrote: I do think you think at it the wrong way. people are not telling you it is bad code. You are telling us it is bad code (because you mention having problem that people using other style do not have). It is not a problem in C++. It is not a problem with no UFCS. If the D attitude is if your style doesn't work with D, then it is wrong, then D has already lost. Huh? If you have type's method diskIdx and a local variable diskIdx, and they are confusing, what it has to do with UFCS?
Re: DIP80: phobos additions
On Wednesday, 10 June 2015 at 07:56:46 UTC, John Chapman wrote: It's a shame ucent/cent never got implemented. But couldn't they be added to Phobos? I often need a 128-bit type with better precision than float and double. FWIW: https://github.com/d-gamedev-team/gfm/blob/master/math/gfm/math/wideint.d
Re: rvalue references
On Tuesday, 9 June 2015 at 20:25:28 UTC, Namespace wrote: No opinions on the semantics for `in` I proposed earlier? `in T` would be something like a non-escapable `const auto ref T` accepting rvalues without codebloat and avoiding the indirection for small POD types T. Wouldn't that eliminate 99% of the use cases for `auto ref`, improve readability substantially and be the solution for all the C++ guys missing the rvalue-bindability of `const T`? 'in' means 'const scope' and 'scope ref' together with 'in ref' was proposed in DIP 36 which was rejected. Let's see if Andrei thinks that my current work is satisfying. I hope so. :) Can you point me to the justifications for the rejection? It should be pretty obvious that something like that is required. Personally, I'd go with `ref` being non-escapable by default and hence providing implicit rvalue-bindability, and having to use `escapable ref` if the parameter may escape and disallowing rvalues for these parameters. I know it's never gonna happen, it's just what I'd prefer. I know what `in` currently means. Your proposed `in ref T` syntax is imo not much better than C++ `const T`, so I'd prefer a simple and convenient `in T`. Semantics would be identical to your `in ref` with the additional optimization for small POD types. And for beginners, one could simply describe it as: 'Use the in keyword for a parameter if you're not going to mutate it. Don't rely on its identity as the argument may be passed by value or reference, whatever seems more efficient for the compiler and the target platform.'
Re: DIP80: phobos additions
On Wednesday, 10 June 2015 at 08:39:12 UTC, ixid wrote: I suspect this is more about who the Mathematica and D users are as Project Euler is mostly mathematical rather than code optimization. Here and I say that despite the fact that in D BigInt not optimized very well, it helps me to solve a wide range of tasks that do not require high performance, so I want to BLAS or something similar was in D. Something is better than nothing!
Re: [OT] Modules dropped out of C++17
On Tuesday, 9 June 2015 at 23:11:35 UTC, Timon Gehr wrote: enum ct(alias a)=a; Thanks! I need to remember that enum means compile-time constant and not strictly enumeration. I guess one can use __ctfe to use a function at compile time and a lut a runtime too, e.g. __ctfe ? sin(x) : lut_sin[x]
Re: Bug 14666, can we prioritize ?
On Wednesday, 10 June 2015 at 06:55:43 UTC, Walter Bright wrote: On 6/9/2015 10:39 PM, deadalnix wrote: The actual code is far more complex than the presented sample :) That what I'm trying to do in general, but here I'm faced with cases that are very hard to untangle. The 'tangle' of cyclical import graphs, as you so appropriately put, is not only hard on the compiler, it makes it much harder for human readers to make sense of code. Even reading your little code snippet hurts my brain. Go, in one of their better decisions, decided Thou Shalt Not Have Import Cycles. This forces users to untangle their code, and I believe that is A Good Thing. I'd like to do that for D, but of course it is far too late for that. That wouldn't be possible. For the most part, the cases where I have these kind of thing are due to mixin being non hygienic, forcing to import thing I should have been passing via template argument. A typical example of that in SDC is the way types are handled. SDC has AST and IR, which share some common feature when it comes to type, but are also different. There is a module that implement the common feature for IR types and AST types. Problem is, this base uses bitfield from the standard lib, which in turn uses mixin. Meaning I can't use the base with importing all modules where it is going to be instantiated. This in turn cause the forward reference thing and forces me to bypass the type system in various places to avoid it. This means either make Liskov very sad and create a 'tangle' with imports, or just not use the standard lib and duplicate a ton of code.
Re: Daily downloads in decline
On 10 June 2015 at 09:11, Rikki Cattermole via Digitalmars-d digitalmars-d@puremagic.com wrote: On 10/06/2015 7:02 p.m., deadalnix wrote: On Wednesday, 10 June 2015 at 04:55:43 UTC, Rikki Cattermole wrote: I think that a lot of the people asking for a 2.067 LDC are just users of D, and (I am including myself in this group) a lot of those people don't know the first thing about LLVM or good complier design in general. While it may seem dishonest for people to ask for these things and not help, keep in mind that the vast majority of programmers are not even able to help. I for one would love to help. But I barely understand X86. Not to mention having to get a setup going ext. Not really worth it right now for me. Although I'd rather work on SDC instead of LDC. Primarily because well it's so shinyy. I would be happy to write a book to teach compiler development from everything from basic x86 encoding to complex optimization strategies. If only I knew it and yes I know they exist just wrong method for teaching it IMO. Lately, I've been listening to a playlist of interview, presentations and other thing involving Elon Musk. The playlist is hours long and I'm listening to it while doing other things. After selling paypal, Musk wanted to use part of his money to revive the desire to explore space. What he plan to do is to send a plant on Mars, a very symbolic stunt that would, he hopes, renew the interest in space exploration, maybe increase NASA funding or whatnot. Thing is, he doesn't know about space that much. He has a physic major working on batteries, and then went to have a payment processing company. So he could have said, like you guys, well I don't know much about space/compiler let's wait for others to make things happen. But nope, he went to talk to space specialists, engineer and scientists, and then, went got in touch with some Russian to buy refurbished ICBM in order to start experimenting. One of the notable thing is how amazed people are that he went to buy ICBM from the russian. Well guess what, that is one of the cheapest thing that can go into space, so if you want to make something happen, that is an excellent starting point. I can continue the story with myself (because everyone knows I compare to Elon in so many ways, and he is greatly inspired by my vision and capability to make things happen). Recently I got to a point on SDC where working on the GC became an important item. Thing is, I know about compiler not memory allocator. Having low level knowledge of how the CPU operate does not provide me wisdom about what kind of algorithm and datastructure will behave nicely on a typical wokload. So I went to read tcmalloc source code, jemalloc source code, libc's malloc, I read a ton of paper about various allocators, and went after Jason Evan - one of the great perk of working for Facebook is to have all these amazing people who can make you feel like an idiot because they know so much more than you do - as to get as much of the why as possible. the code told me the what/how but that is not sufficient to get a good grasp of the matter at hand. Making things happen is not about waiting for the wisdom to fall from the sky to deliver you the deep and arcane knowledge of compiler/memory management/rocketry . It is about learning enough to get started, and then start do do thing while continuing to learn more. To get back on point, yes some task in LDC or SDC (or DMD, or GDC) require some good knowledge of compiler stuff. Obviously, these are compiler, and I'd add D compiler, which involve a certain level of complexity. But let's be honest, a good chunk of the work is not guru level compiler arcane. Most of the work is actually dumb shit that just need to be done like it is for all other software. You don't wait to know how to paint like Rembrandt to start painting. Because that will never happen. You just paint dumb shit again and again, trying to make the new shit a bit less shitty than the old shit. You do that while studying Rembrandt's techniques. And, after thousand of painting, you finally get there. I'm well aware. I've been hammering out over long term to learn the underlying technologies. For example writing a PE-COFF linker. My experience is well ugh lets just say, if something seems hard and almost impossible maybe something isn't quite right. Unfortunately I'm in a war of attrition trying to learn x86 and friends. And its a long one! Good luck with that. :-)
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Tuesday, 9 June 2015 at 18:53:06 UTC, Dennis Ritchie wrote: On Tuesday, 9 June 2015 at 18:46:48 UTC, Israel wrote: Ruby that compiles? Yet Rust, Nim and Crystal is a very young languages. And alas, life is not eternal to wait five years of a flourishing language :) There are already ready to be used option. This is D. Exactly. Nim for example sounds interesting, however, we already have D. I've used it for years and I know that it scales and that I can write reliable real world applications in it. With Nim etc. it would take years to actually know, if it scales or if you hit a brick wall after a couple of years. D has overcome many of the child diseases that Nim, Crystal etc still have to face. One big difference between the D community and other languages' communities is is that D people keep criticizing the language and see every little flaw in every little corner, which is good and which is why D is the way it is. Other languages' communities are more like This is theee language of the future, it's super-duper, no question asked, none permitted either!
Re: DIP80: phobos additions
On Wednesday, 10 June 2015 at 09:12:17 UTC, John Chapman wrote: HMAC (for OAuth) https://github.com/D-Programming-Language/phobos/pull/3233 Unfortunately it triggers a module cycle bug on FreeBSD that I can't figure out, so it hasn't been merged yet.
Re: [OT] Modules dropped out of C++17
On Wednesday, 10 June 2015 at 13:43:45 UTC, Shachar Shemesh wrote: On 10/06/15 15:37, Kagamin wrote: On Wednesday, 10 June 2015 at 08:53:40 UTC, Shachar Shemesh wrote: On 10/06/15 11:31, Kagamin wrote: Huh? If you have type's method diskIdx and a local variable diskIdx, and they are confusing, what it has to do with UFCS? auto diskIdx = data.diskIdx(); auto diskIdx1 = this.diskIdx; diskIdx1 = f(diskIdx1); return diskIdx; Was this meant to prove that you can make it confusing? It was your requirement that variables and methods must be similar. What does diskIdx1 mean? Same as in your example, a variable, which receives the disk index. What does f do? Processes the disk index and returns another index according to its logic. Is this.diskIdx a member or a function? A property, which extracts the disk index as you described the function. where did the diskIdx you returned came from? It's defined as a member of the type.
Re: [OT] Modules dropped out of C++17
On 10/06/15 17:05, Kagamin wrote: On Wednesday, 10 June 2015 at 13:43:45 UTC, Shachar Shemesh wrote: On 10/06/15 15:37, Kagamin wrote: On Wednesday, 10 June 2015 at 08:53:40 UTC, Shachar Shemesh wrote: On 10/06/15 11:31, Kagamin wrote: Huh? If you have type's method diskIdx and a local variable diskIdx, and they are confusing, what it has to do with UFCS? auto diskIdx = data.diskIdx(); auto diskIdx1 = this.diskIdx; diskIdx1 = f(diskIdx1); return diskIdx; Was this meant to prove that you can make it confusing? It was your requirement that variables and methods must be similar. I made no such requirement. I just said it sometimes makes sense. You have not answered my most important question: what was it that you were trying to make? Shachar
Re: Coedit 1 gold released
On Wednesday, 10 June 2015 at 06:57:09 UTC, Andrei Alexandrescu wrote: On 6/9/15 6:22 PM, Basile Burg wrote: Coedit, the small IDE for the D DMD compiler goes gold I can haz OSX pliz pliz ok thx bye -- Andrei No, because i don't have the hardware necessary to release the mac OSX version. There's someone who succeeded to build it but it doesn't look like he wanted to be more involved than that in the project.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote: One big difference between the D community and other languages' communities is is that D people keep criticizing the language and see every little flaw in every little corner, which is good and which is why D is the way it is. Or perhaps D simply has more flaws to criticize. On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote: Other languages' communities are more like This is theee language of the future, it's super-duper, no question asked, none permitted either! Perhaps you are depicting other communities as a bunch of group-think hipsters because you are insecure about your own community? Look, I can make baseless accusations too. Wouldn't you agree it would be nicer (and more effective, I imagine) to promote your community by calling attention rather to its positive qualities, rather than demonizing other communities? Especially when your negative portrayals of other communities are not accompanied by any evidence? I'm sure you're a smart person and will for each of the communities in question be able to find evidence of at least one person who at some point in time acted in the way you suggested. Of course such a thing would not prove that the behaviour is representative of the community, so please don't.
Re: [OT] Modules dropped out of C++17
On 10/06/15 15:37, Kagamin wrote: On Wednesday, 10 June 2015 at 08:53:40 UTC, Shachar Shemesh wrote: On 10/06/15 11:31, Kagamin wrote: Huh? If you have type's method diskIdx and a local variable diskIdx, and they are confusing, what it has to do with UFCS? auto diskIdx = data.diskIdx(); auto diskIdx1 = this.diskIdx; diskIdx1 = f(diskIdx1); return diskIdx; Was this meant to prove that you can make it confusing? I have no idea what you were trying to convey here. Please explain the point you're trying to make. What does diskIdx1 mean? What does f do? Is this.diskIdx a member or a function? where did the diskIdx you returned came from? Shachar
[Issue 14674] Importing std.stdio causes another module to become undefined
https://issues.dlang.org/show_bug.cgi?id=14674 --- Comment #4 from Kenji Hara k.hara...@gmail.com --- (In reply to sigsve from comment #2) Undefined symbols for architecture x86_64: _D5Stack12__ModuleInfoZ, referenced from: _D4Main12__ModuleInfoZ in Main.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) It says a ModuleInfo symbol of Stack module is missing. (In reply to sigsve from comment #3) Sorry, I though DMD compiled and linked Stack.d automagically(Which it seems to have done, when I do not import std.stdio) If you don't list a module file in dmd command line, the symbols in it are compiled (== semantic analysis done) but those code won't be output to any object files. When you don't add `import std.stdio;` in Stack.d, today's dmd fortunately determines the ModuleInfo object of Stack module is unnecessary, so the build will succeed. However it's just undocumented behavior, and might be changed in the future. So I'd recommend to compile and link Stack.d always when you import it from other modules. --
reggae v0.2.3: minimal build, reggae as a library
https://github.com/atilaneves/reggae Ask, and ye shall receive: Stick -version=minimal when building reggae itself (or use the minimal_bootstrap.sh in the repo) and reggae has no dependencies on anything. All it can do then is D builds and the only backend is the binary one. No dub support either. Don't want to build reggae / dub run reggae / run it as a command-line tool? Run this: REGGAE=/path/to/reggae/repo rdmd -I/$REGGAE/src -I$REGGAE/payload -J$REGGAE/payload/reggae -version=reggaelib /path/to/your/reggaefile.d -b backend project dir Now you have a build wherever you ran that from. Your build description... becomes reggae itself. To my surprise, you can add -version=minimal to that command line and it seems to work. I know, I know, there're loads of flags there right now. It's the best I could come up with without even more massive amounts of refactoring. It's silly you still have to specify `-b binary` when you've built a version that doesn't know how to do anything else, but... them's the breaks right now. I've only tried -version=reggaelib on a toy build system and reggae itself. But it ourobourosed nicely. So I'm assuming it works, but it might not. I was a bad programmer and only tested any of this manually. -version=reggaelib only works if the `build` template mixin was used, which it probably always should. But... there's no change needed to any exiting build description, just -version=reggaelib (basically the template mixin expands to something else) and voila. Atila
Re: [OT] Modules dropped out of C++17
On Wednesday, 10 June 2015 at 05:31:18 UTC, Shachar Shemesh wrote: On 10/06/15 00:29, Walter Bright wrote: First off, D does not allow shadowing local variable declarations. Secondly, if you've got a lot of global variables, you've got a program design problem anyway. And lastly, naming everything diskIdx is a problem of your own creation. The first one is called so because it names the index of the disk within a RAID stripe. It's probably an iterator. How would you call the second time I use such an iterator? You might argue that the function that extracts the disk index should be named something more verbose (i.e. - extractTheDiskIndex), but then you are just repeating Ola's criticism[1] of D as if it is a desirable thing. People on this list hold a certain paradigm in their head when they make design decisions. That's fine, except if you hold on to this paradigm and assume anything that violates it is bad code, you are going to end up with Go: a language only fit for those problems that happen to fall within that paradigm. People have preconceptions on how code should look like. I would humbly like to ask people to stop -assuming- that anything that violates them is bad code. Shachar 1 - http://forum.dlang.org/post/uvajlhfztejvwnubs...@forum.dlang.org I do think you think at it the wrong way. people are not telling you it is bad code. You are telling us it is bad code (because you mention having problem that people using other style do not have).
Re: Honey, I shrunk the build times
On Tuesday, 9 June 2015 at 16:20:35 UTC, Andrei Alexandrescu wrote: On 6/9/15 4:06 AM, Atila Neves wrote: On Saturday, 6 June 2015 at 21:42:47 UTC, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/phobos/pull/3379 Punchline: major reduction of both total run time and memory consumed. Andrei Are the inter-package dependencies handled correctly? It's hard to say looking at the diff, but I don't see where it's done. With the compile everything at once model it's not an issue; everything is getting recompiled anyway. With per-package... if foo/toto.d gets changed and bar/tata.d has an import foo.toto; in it, then both foo and bar packages need to get recompiled. Or is this change recompiling everything all of the time but just happens to do it a package at a time? Last one's right. From the diff: # Each package depends on everything. We may improve that in the future. Ah right, sorry, I missed that. reggae already calculates dependencies by asking the compiler and (modulo bugs) only recompiles packages that need to be recompiled. Atila
Re: [OT] Modules dropped out of C++17
On 10/06/15 09:14, deadalnix wrote: I do think you think at it the wrong way. people are not telling you it is bad code. You are telling us it is bad code (because you mention having problem that people using other style do not have). It is not a problem in C++. It is not a problem with no UFCS. If the D attitude is if your style doesn't work with D, then it is wrong, then D has already lost. Shachar
Re: [OT] Modules dropped out of C++17
On Wednesday, 10 June 2015 at 01:28:40 UTC, Walter Bright wrote: I'm bemused by the argument that D is deficient because it doesn't implement a non-existent feature of C++. I think you are offended ;^]. I have not said that D is deficient regarding constexpr, I've suggested that I think D is moving more in a high level direction than C++. Which is neither good or bad, just different. constexpr has advantages and disadvantages. But C++ constexpr was originally restricted to expression-like functions. Loops were added later (making it easier to init arrays) AFAIK. My primary use case for constexpr in C++ is: 1. Initializing global constant arrays. These functions I label ct_make_lut_sin(size) etc and only use them for that purpose. 2. Signifiying that a standard class member-function is returning a constant value in a particular version of the class where you expect a varying value, e.g. size(). I only add constexpr when I have to and only use constexpr functions that are O(N) and only where beneficial. It's more like Do I _have_ to make this constexpr?, not Oh yes, I can make this constexpr!. However, D's primary advantage over C++ is that D is easier to get into. No sane person would want to learn C++ from scratch (if they have other options). C++XX is more for people that already know it or have to learn it (for work). D's position will benefit from becoming simpler and more streamlined, not more complex, so constexpr is not the right thing for D, IMO. (Rust and C++ have complexity as a barrier-to-entry) some of these posts. I'm hoping to entice you to contribute in the substantial way that I know you can. I think prodding people to view things differently is substantial, besides it helps me figure out what I want from a language ;-). But I suppose you mean code, I am thinking about doing comparative synthetic benchmarks between idiomatic/readable C++, Rust and D vs not-so-readable hardware oriented C. I think you will find that more people will chime in when the compiler has completed the transition to D and the codebase has been refactored. It doesn't make much sense to get into the C++ codebase at this point where you are transitioning.
Re: Potential abuse of .stringof
On 2015-06-10 02:50, Andrei Alexandrescu wrote: An effective solution is to specify .stringof to return types that are valid D types (i.e. can be pasted in D code and aliased to identifiers). Exceptions: Voldemort types and function types. Is that enough? The original problem I had, and the reason for my comment on GitHub, was that I had used .stringof on a member of .tupleof to get the name of an instance variable. Originally .stringof returned a string containing both the name of the type and the name of the instance variable. Then in some release it was change to return just the name of the instance variable. -- /Jacob Carlborg
Re: Coedit 1 gold released
On 6/9/15 6:22 PM, Basile Burg wrote: Coedit, the small IDE for the D DMD compiler goes gold I can haz OSX pliz pliz ok thx bye -- Andrei
Re: Bug 14666, can we prioritize ?
On 6/9/2015 10:39 PM, deadalnix wrote: The actual code is far more complex than the presented sample :) That what I'm trying to do in general, but here I'm faced with cases that are very hard to untangle. The 'tangle' of cyclical import graphs, as you so appropriately put, is not only hard on the compiler, it makes it much harder for human readers to make sense of code. Even reading your little code snippet hurts my brain. Go, in one of their better decisions, decided Thou Shalt Not Have Import Cycles. This forces users to untangle their code, and I believe that is A Good Thing. I'd like to do that for D, but of course it is far too late for that.
Re: Potential abuse of .stringof
On Wednesday, 10 June 2015 at 00:50:48 UTC, Andrei Alexandrescu
wrote:
Exceptions: Voldemort types and function types.
Why not Voldemort types?
Example: http://dpaste.dzfl.pl/450dcdb5f7f8
---
import std.stdio;
auto createVoldemortType(int value)
{
struct TheUnnameable
{
int getValue() { return value; }
}
return TheUnnameable();
}
void main()
{
auto voldemort = createVoldemortType(123);
writeln(typeof(voldemort).stringof);
}
---
Seems to return the correct result, although it TheUnnameable
cannot be cut and pasted outside of the createVoldemortType
scope. Perhaps that's the limitation you are referring to.
Mike
Re: Daily downloads in decline
On Wednesday, 10 June 2015 at 04:55:43 UTC, Rikki Cattermole wrote: I think that a lot of the people asking for a 2.067 LDC are just users of D, and (I am including myself in this group) a lot of those people don't know the first thing about LLVM or good complier design in general. While it may seem dishonest for people to ask for these things and not help, keep in mind that the vast majority of programmers are not even able to help. I for one would love to help. But I barely understand X86. Not to mention having to get a setup going ext. Not really worth it right now for me. Although I'd rather work on SDC instead of LDC. Primarily because well it's so shinyy. I would be happy to write a book to teach compiler development from everything from basic x86 encoding to complex optimization strategies. If only I knew it and yes I know they exist just wrong method for teaching it IMO. Lately, I've been listening to a playlist of interview, presentations and other thing involving Elon Musk. The playlist is hours long and I'm listening to it while doing other things. After selling paypal, Musk wanted to use part of his money to revive the desire to explore space. What he plan to do is to send a plant on Mars, a very symbolic stunt that would, he hopes, renew the interest in space exploration, maybe increase NASA funding or whatnot. Thing is, he doesn't know about space that much. He has a physic major working on batteries, and then went to have a payment processing company. So he could have said, like you guys, well I don't know much about space/compiler let's wait for others to make things happen. But nope, he went to talk to space specialists, engineer and scientists, and then, went got in touch with some Russian to buy refurbished ICBM in order to start experimenting. One of the notable thing is how amazed people are that he went to buy ICBM from the russian. Well guess what, that is one of the cheapest thing that can go into space, so if you want to make something happen, that is an excellent starting point. I can continue the story with myself (because everyone knows I compare to Elon in so many ways, and he is greatly inspired by my vision and capability to make things happen). Recently I got to a point on SDC where working on the GC became an important item. Thing is, I know about compiler not memory allocator. Having low level knowledge of how the CPU operate does not provide me wisdom about what kind of algorithm and datastructure will behave nicely on a typical wokload. So I went to read tcmalloc source code, jemalloc source code, libc's malloc, I read a ton of paper about various allocators, and went after Jason Evan - one of the great perk of working for Facebook is to have all these amazing people who can make you feel like an idiot because they know so much more than you do - as to get as much of the why as possible. the code told me the what/how but that is not sufficient to get a good grasp of the matter at hand. Making things happen is not about waiting for the wisdom to fall from the sky to deliver you the deep and arcane knowledge of compiler/memory management/rocketry . It is about learning enough to get started, and then start do do thing while continuing to learn more. To get back on point, yes some task in LDC or SDC (or DMD, or GDC) require some good knowledge of compiler stuff. Obviously, these are compiler, and I'd add D compiler, which involve a certain level of complexity. But let's be honest, a good chunk of the work is not guru level compiler arcane. Most of the work is actually dumb shit that just need to be done like it is for all other software. You don't wait to know how to paint like Rembrandt to start painting. Because that will never happen. You just paint dumb shit again and again, trying to make the new shit a bit less shitty than the old shit. You do that while studying Rembrandt's techniques. And, after thousand of painting, you finally get there.
[Issue 14677] New: cast correctness not checked inside is(typeof())
https://issues.dlang.org/show_bug.cgi?id=14677
Issue ID: 14677
Summary: cast correctness not checked inside is(typeof())
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: pub...@dicebot.lv
```
void main()
{
void* x;
// Error: e2ir: cannot cast x of type void* to type int[30]
auto y = cast (int[30]) x;
// But this passes
static assert (is(typeof({ auto y = cast(int[30])x; })));
}
```
Looks like correctness of cast is checked after normal semantic phase and thus
ignored by `is(typeof())`
--
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 16:02:36 UTC, Ola Fosheim Grøstad wrote: Yeah, I think it would be nice if one could change the culture of programming so that people easily could combine any 2 languages in the same project. But shouldn't there be one language that's right for everyone? (BTW I wanted to use that line in my dconf talk and forgot to!)
Re: Make dub part of the standard dmd distribution
On 06/10/2015 08:11 AM, Sönke Ludwig wrote: Am 04.06.2015 um 17:47 schrieb Atila Neves: I don't know if fragmentation would be an issue. The packages are still dub packages and I for one will use dub.json/sdl to list my dependencies even if reggae is actually generating the build. Yeah that would definitely not be an issue. I just fear (maybe unnecessarily) that people might start to put packages in the registry that can *only* be built using Reggae (or some other build tool). At least for libraries that would really be bad. I've found the opposite to be true. We can *already* get packages in code.dlang.org that work with a custom buildscript, but then fail when doing dub build. I know this because I've *already* done it by accident multiple times. And then I get bug reports of X or Y build problem under dub. But if we can easily tell dub via dub.json, Hey, don't use your internal build system to build this, I've stuck the appropriate command in pre/postBuildCommands, then dub build will automatically just simply work. Major bonus compatibility points the more information we can pass from dub to the custom command (ex: Which 'built type' did the user request with '--build='? or...well, everything provided by dub describe --data). Remember, libraries do NOT need to use the same build system to be used together. As long as there's a common interface to... 1. Trigger a build, and 2. Get the lists of import paths and output binaries (and maybe any other required flags), ...then everything's golden. This is the job of a package manager. Each library author tells the package manager: 1. When someone asks you to build me, here's how you do it and 2. When someone asks you for my import paths and output binaries (etc.), this is what you tell them For DUB, #1 above can be done via pre/postBuildCommands as long as we can tell it Don't go trying to build this yourself. (I'm wondering if targetType: none would help here.) And for #2, DUB can do that via my --data= pull request. Ok, only one possible issue left: Source libraries (as opposed to binary libraries) *could* be an issue just because of the differences in collecting the list of files to be compiled. But that's solvable two ways: 1. If your lib *requires* something like RDMD-style dependency collecting, then the lib must be a binary lib. Or much, much better yet: 2. Option in dub.json to say when you collect this package's list of source files, do it RDMD-style. Sure, that may not be appropriate for ALL packages, but that's exactly why it'd be a per-package OPTION. And there it is, the *existing* issues of splitting the dub ecosystem are thus eliminated, without creating new splits.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 16:22:51 UTC, Idan Arye wrote: Wasn't LLVM supposed to solve that, being a virtual machine for compilation to low level native code? May still be possible, Apple just announced that the default format to submit apps for iOS will be bitcode from now on, which people are speculating is some form of llvm bitcode: http://arstechnica.com/apple/2015/06/app-thinning-will-be-a-major-boon-for-8gb-and-16gb-iphones-and-ipads/ Apple will then compile the bitcode for you on their servers, before sending the final binary to users.
Re: [OT] Modules dropped out of C++17
On 6/10/15 8:48 AM, Joakim wrote: On Wednesday, 10 June 2015 at 15:12:47 UTC, ZombineDev wrote: On Monday, 8 June 2015 at 18:17:13 UTC, Paulo Pinto wrote: Apparently modules have been pushed into a Technical Specification, and won't be ready on time for inclusion into ANSI C++ 17. https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-in-lenexa-may-2015/ So, here is another feature that D wins over C++. -- Paulo Sorry, I couldn't resist to share this: https://www.youtube.com/watch?v=ND-TuW0KIgg Lol, that was hilarious. :D Saw a few of those, this is far and away the best one. I guess for a German speaker it would be all like, meh. -- Andrei
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 16:02:36 UTC, Ola Fosheim Grøstad wrote: Probably related to the main creator's programming-experience, but as far as credits go one should really credit the first language/author to bring about a concept. (e.g. Lisp, Simula, BCPL etc) I wonder why Walter was inspired to add modules to D, Walter?
[Issue 13816] [REG2.066.0] The compiler crashes with recursive tuple expansion
https://issues.dlang.org/show_bug.cgi?id=13816
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Keywords||ice
Hardware|x86_64 |All
Summary|The compiler crashes with |[REG2.066.0] The compiler
|getProtection trait |crashes with recursive
||tuple expansion
OS|Mac OS X|All
Severity|blocker |regression
--- Comment #1 from Kenji Hara k.hara...@gmail.com ---
It's a regression from 2.066.0.
Reduced test case:
alias TypeTuple(T...) = T;
template ItemProperty()
{
static if (true)
{
alias ItemProperty = TypeTuple!(ItemProperty!()); // line 14
}
}
void main()
{
alias items = ItemProperty!(); // line 19
enum num = items.length;// line 21
}
Until 2.065, the code had printed:
test.d(14): Error: alias test.ItemProperty!().ItemProperty recursive alias
declaration
test.d(19): Error: template instance test.ItemProperty!() error instantiating
But since 2.066, line 19 makes no error, and line 21 will crash the compiler.
--
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 14:29:51 UTC, Thiez wrote: On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote: One big difference between the D community and other languages' communities is is that D people keep criticizing the language and see every little flaw in every little corner, which is good and which is why D is the way it is. Or perhaps D simply has more flaws to criticize. How can you tell that e.g. Nim has less flaws when it's still so young? It's too early to tell. On Wednesday, 10 June 2015 at 09:23:54 UTC, Chris wrote: Other languages' communities are more like This is theee language of the future, it's super-duper, no question asked, none permitted either! Perhaps you are depicting other communities as a bunch of group-think hipsters because you are insecure about your own community? Look, I can make baseless accusations too. Wouldn't you agree it would be nicer (and more effective, I imagine) to promote your community by calling attention rather to its positive qualities, rather than demonizing other communities? Especially when your negative portrayals of other communities are not accompanied by any evidence? I'm sure you're a smart person and will for each of the communities in question be able to find evidence of at least one person who at some point in time acted in the way you suggested. Of course such a thing would not prove that the behaviour is representative of the community, so please don't. I've been following post-C(++) programming languages for quite a while now. Back in the day Java was a big thing, and Python was also hip. Then we had Ruby and whatnot. The base line would always be it's a cool language, it's the future and flaws would hardly ever be mentioned, critical voices silenced. All the benchmarking tricks used by the Java community to make people believe it's as fast as native code - while you know from your own experience that it's not - are just one example. Ah, and there was Ajax, remember? How's jQuery doing, by the way? I've used some of these technologies and none of them would live up to my expectations. But the pattern is always the same It's th thing, wow, a must-have! Sorry, but whenever I hear a language is (almost) perfect and theee way to go, I grow suspicious. If all communities are as critical as D's, why then do we have so much mediocre technology out there? I am interested in Nim and welcome it. But it's too early to say whether it's good or mediocre. I wonder, though, when you look Nim up on Wikipedia it states: Influenced by Ada, Modula-3, Lisp, C++, Object Pascal, Python, Oberon Did they really never get any inspiration from D?? I wonder. Seems a bit odd, but well.
Re: Bug 14666, can we prioritize ?
On Wednesday, 10 June 2015 at 06:55:43 UTC, Walter Bright wrote: On 6/9/2015 10:39 PM, deadalnix wrote: The actual code is far more complex than the presented sample :) That what I'm trying to do in general, but here I'm faced with cases that are very hard to untangle. The 'tangle' of cyclical import graphs, as you so appropriately put, is not only hard on the compiler, it makes it much harder for human readers to make sense of code. Even reading your little code snippet hurts my brain. Go, in one of their better decisions, decided Thou Shalt Not Have Import Cycles. This forces users to untangle their code, and I believe that is A Good Thing. I'd like to do that for D, but of course it is far too late for that. Ada (83 and 95) were also rigid about not allowing any kind of import cycles. At some point, probably after Ada 95 when OO was added, it was decided after much experience that there were some cases where it was better to allow it. If you're interested, in the Ada world this issue was dubbed the with-ing problem and a quick Google search gives http://www.ada95.ch/doc/within/FAQ.html#what http://www.adaic.org/resources/add_content/standards/05rat/html/Rat-4-2.html also in the world of Haskell, this thread https://mail.haskell.org/pipermail/haskell-cafe/2004-September/006885.html and I'm sure in many other places too. I agree with you, Walter, that mutual recursion amongst imports is usually bad, but I think you inadvertently made the right decision by allowing it in D, and that the bug should be fixed. If people overuse it to write messy code then the community should tell them to write that code better.
Re: Utf8 to Utf32 cast cost
Am Mon, 8 Jun 2015 12:59:31 +0200
schrieb Daniel Kozák via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com:
On Mon, 08 Jun 2015 10:41:59 +
Kadir Erdem Demir via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
I want to use my char array with awesome, cool std.algorithm
functions. Since many of this algorithms requires like slicing
etc.. I prefer to create my string with Utf32 chars. But by
default all strings literals are Utf8 for performance.
With my current knowledge I use to!dhar to convert Utf8[](or
char[]) to Utf32[](or dchar[])
dchar[] range = to!dchar(erdem.dup)
How costly is this?
import std.conv;
import std.utf;
import std.datetime;
import std.stdio;
void f0() {
string somestr = some not so long utf8 string forbenchmarking;
dstring str = to!dstring(somestr);
}
void f1() {
string somestr = some not so long utf8 string forbenchmarking;
dstring str = toUTF32(somestr);
}
void main() {
auto r = benchmark!(f0,f1)(1_000_000);
auto f0Result = to!Duration(r[0]);
auto f1Result = to!Duration(r[1]);
writeln(f0 time: ,f0Result);
writeln(f1 time: ,f1Result);
}
/// output ///
f0 time: 2 secs, 281 ms, 933 μs, and 8 hnsecs
f1 time: 600 ms, 979 μs, and 8 hnsecs
Please have the result of the transcode influence the program
output. E.g. Add the first character of the UTF32 string to
some global variable and print it out. At the moment - at
least in theory - you allow the compiler to deduce f0/f1 as
pure, return-nothing functions and you will benchmark anything
from your written code to an empty loop. I'm talking out of
experience here:
https://github.com/mleise/fast/blob/master/source/fast/internal.d#L99
--
Marco
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 15:37:46 UTC, Chris wrote: I am interested in Nim and welcome it. But it's too early to say whether it's good or mediocre. Yeah, I think it would be nice if one could change the culture of programming so that people easily could combine any 2 languages in the same project. But that takes either significant creator-goodwill/cooperation or platforms like .NET/JVM. I could see myself wanting to do some things in Prolog, some things in Lisp and some things in C. Today that takes too much FFI work. A problem that both Nim and D share is that they aim broad. I think that makes it a harder sell as that tend to make the language more complex and unpolished. I think most languages that gain traction by starting focused. C was very focused on OS dev. C++ piggy-backed on that by adding abstractions. Php was very focused on web scripting. Perl on text processing. Erlang on fault tolerance. Smalltalk on interactive programming. Pascal piggybacked on Algol going too big IIRC. Turbo Pascal's success was IDE focused IMO. I wonder, though, when you look Nim up on Wikipedia it states: Influenced by Ada, Modula-3, Lisp, C++, Object Pascal, Python, Oberon Did they really never get any inspiration from D?? I wonder. Seems a bit odd, but well. Probably related to the main creator's programming-experience, but as far as credits go one should really credit the first language/author to bring about a concept. (e.g. Lisp, Simula, BCPL etc)
Re: Bug 14666, can we prioritize ?
On 6/10/15 8:41 AM, Brian Rogoff wrote: I agree with you, Walter, that mutual recursion amongst imports is usually bad, but I think you inadvertently made the right decision by allowing it in D, and that the bug should be fixed. If people overuse it to write messy code then the community should tell them to write that code better. I agree. I'm one of those folks who think circular dependencies are fine, thank you very much, and the few cases in which it causes problems should be flagged and diagnosed in a principled way. Everybody also likes: * recursion and mutual recursion of any depth (there's a lot more of it going in the usual programs than one might think) * recursive and mutually recursive types * declaring top level names in any order and they just work But all of a sudden, people get sugar in their gasoline and sand in their gears when they hear of the same thing applied to modules. I suspect it's because some legacy languages didn't quite do a stellar job at it. Figuring that stuff out and pointing out problems is exactly the kind of thing computers are good at and humans, not so good. Andrei
Re: Right after allocators: containers or database connectivity?
On Wednesday, 10 June 2015 at 07:50:24 UTC, Jacob Carlborg wrote: On 2015-06-09 20:49, Brad Anderson wrote: 1. vector/array 2. hash map 3. hash set 4. flat map 5. flat set 6. map 7. set 8. deque 9. stack 10. queue 11. linked list 12. hash multimap 13. hash multiset 14. flat multimap 15. flat multiset 16. multimap 17. multiset 18. priority queue I think RedBlackTree isn't a very good name though. It's long and is an implementation detail. In that case you would need to remove hash and perhaps flat from all containers to be consistent. Also linked list would be just list. It would be difficult to come up with better names since there would be name clashes. I wasn't suggesting those as the names. I just used hash because it's familiar to everyone (whereas C++'s unordered_map is a somewhat unusual name).
Re: Potential abuse of .stringof
On 6/9/15 11:59 PM, Mike wrote: Seems to return the correct result, although it TheUnnameable cannot be cut and pasted outside of the createVoldemortType scope. Perhaps that's the limitation you are referring to. Yah, and the problem here is that outside createVoldemort, the same typename could refer to a different type. -- Andrei
Re: Make dub part of the standard dmd distribution
On 06/10/2015 09:06 AM, Atila Neves wrote: I think that if a project is a dub package, then it needs to be able to be built with dub. If anything on code.dlang.org doesn't (correctly) build with `dub build` then that would be incredibly wrong. Right. And to summarize what I said elsewhere about that: Building WITH dub need NOT imply building using dub's internal buildsystem. It only needs to mean The CORRECT buildsystem can be trigged via 'dub build', whatever buildsystem that may be. That's why the current situation is backwards and CAUSES splits rather than preventing them: We can always trigger dub's internal buildsystem via dub build, but trying to get dub build to trigger the CORRECT one INSTEAD of built-in (whenever a different one is needed) is a world of hurt.
Re: Right after allocators: containers or database connectivity?
On Tuesday, 9 June 2015 at 22:42:15 UTC, Andrei Alexandrescu wrote: With regard to which to work on, I've made my decision: http://38.media.tumblr.com/c51baf89e2f85065d669f3080c2b5cdb/tumblr_inline_n3rsrwCCcQ1qj3ir1.jpg For those voting, you can stop now: he made his decision. The Spanish in the image above translates to Why not both?
Re: Self-referential tuples?
On 06/10/2015 05:52 PM, Brian Rogoff wrote:
On Tuesday, 9 June 2015 at 23:48:05 UTC, Timon Gehr wrote:
'This' is a cute hack, but it doesn't replace a proper template
fixpoint operator.
Could you explain this a bit more, maybe using some pseudo-D for your
proposed template fixpoint operator? Thanks.
...
import std.typecons, std.variant;
alias List(T)=Algebraic!(Tuple!(),Tuple!(T,List!T*));
void main(){
List!int l;
}
The following error message is the reason why the 'This' hack is necessary:
tt.d(3): Error: template instance Algebraic!(Tuple!(), Tuple!(int,
List!int*)) recursive template expansion
tt.d(6): Error: template instance tt.List!int error instantiating
The simple solution is to just not have this error. The code can easily
be given an unambiguous meaning.
Re: Right after allocators: containers or database connectivity?
On 6/10/15 12:36 AM, Andrea Fontana wrote: ODBC is sql-oriented! If not, call it std.sql or std.database.sql. Well it's etc.c.odbc :o). -- Andrei
Re: DIP80: phobos additions
On 6/10/15 1:53 AM, ponce wrote: On Wednesday, 10 June 2015 at 07:56:46 UTC, John Chapman wrote: It's a shame ucent/cent never got implemented. But couldn't they be added to Phobos? I often need a 128-bit type with better precision than float and double. FWIW: https://github.com/d-gamedev-team/gfm/blob/master/math/gfm/math/wideint.d Yes, arbitrary fixed-size integrals would be good to have in Phobos. Who's the author of that code? Can we get something going here? -- Andrei
[Issue 13816] [REG2.066.0] The compiler crashes with recursive tuple expansion
https://issues.dlang.org/show_bug.cgi?id=13816 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #2 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4738 --
Re: Self-referential tuples?
On Tuesday, 9 June 2015 at 23:48:05 UTC, Timon Gehr wrote:
'This' is a cute hack, but it doesn't replace a proper template
fixpoint operator.
Could you explain this a bit more, maybe using some pseudo-D for
your proposed template fixpoint operator? Thanks.
I don't think I'd need such a thing for the JSON AST example,
since it isn't parameterized by type. There, the D mapping looks
clumsy because, as Andrei noticed, the 'fields' are not named. If
you map the OCaml straight to D you get something like what I
write below, and you want both the Kind and the internal
structure to be non-private so you can write functions which work
on them. It's the same as tagged unions/variants in other
languages but so much easier to use.
enum Kind {
Bool,
Number,
String,
Null,
Array,
Object
}
alias JSON = JSONStruct *;
struct JSONStruct {
public:
Kind kind;
union {
bool jsonBool;
double jsonNumber;
string jsonString;
JSON[] jsonArray;
JSON[string] jsonObject;
}
this(Kind kind, bool jsonBool)
in { assert(kind == Kind.Bool); }
body {
kind = Kind.Bool;
this.jsonBool = jsonBool;
}
this(Kind kind, double jsonNumber)
in { assert(kind == Kind.Number); }
body {
kind = Kind.Number;
this.jsonNumber = jsonNumber;
}
this(Kind kind, string jsonString)
in { assert(kind == Kind.String); }
body {
kind = Kind.String;
this.jsonString = jsonString;
}
this(Kind kind)
in { assert(kind == Kind.Null); }
body {
kind = Kind.Null;
}
this(Kind kind, JSON[] jsonArray)
in { assert(kind == Kind.Array); }
body {
kind = Kind.Array;
this.jsonArray = jsonArray;
}
this(Kind kind, JSON[string] jsonObject)
in { assert(kind == Kind.Object); }
body {
kind = Kind.Object;
this.jsonObject = jsonObject;
}
}
Re: Coedit 1 gold released
On Wednesday, 10 June 2015 at 03:49:04 UTC, Sean Campbell wrote: On Wednesday, 10 June 2015 at 01:23:00 UTC, Basile Burg wrote: Coedit, the small IDE for the D DMD compiler goes gold I've been wanting to switch a D based editor for a while but at least on windows, everything is on a different window and I cant figure out how to change this. You cant. But as the Windows are docked, is it really a problem ? If some of the widgets look superfluous to you then you can close them and just use the Window menu when you need them. I'm afraid that there might be an misunderstanding, when you started the software for the first time, it looked a bit like that: http://imgur.com/CecC9Cm , right ?
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 16:02:36 UTC, Ola Fosheim Grøstad wrote: Yeah, I think it would be nice if one could change the culture of programming so that people easily could combine any 2 languages in the same project. But that takes either significant creator-goodwill/cooperation or platforms like .NET/JVM. I could see myself wanting to do some things in Prolog, some things in Lisp and some things in C. Today that takes too much FFI work. Wasn't LLVM supposed to solve that, being a virtual machine for compilation to low level native code?
Re: Coedit 1 gold released
On 2015-06-10 7:22 AM, Basile Burg wrote: On Wednesday, 10 June 2015 at 06:57:09 UTC, Andrei Alexandrescu wrote: On 6/9/15 6:22 PM, Basile Burg wrote: Coedit, the small IDE for the D DMD compiler goes gold I can haz OSX pliz pliz ok thx bye -- Andrei No, because i don't have the hardware necessary to release the mac OSX version. There's someone who succeeded to build it but it doesn't look like he wanted to be more involved than that in the project. Did that someone submit the source code, project files, etc. necessary to build on OSX so that someone else might be able to follow in his footsteps?
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On 06/10/2015 09:05 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: ... At some point you just have question intent if there is a misunderstanding, rather than control every expression or else everything becomes it: A bad programmer create bugs when it edits its files Just use plural, it's what you mean anyway. Bad programmers create bugs when they edit their files And if people force you to write it, ... it doesn't seem appropriate. http://en.wikipedia.org/wiki/Gender-specific_and_gender-neutral_pronouns#It_and_one_as_gender-neutral_pronouns However, when not referring specifically to children, it is not generally applied to people, even in cases where their gender is unknown.
Re: Is it possible to add items to the arrays and hashes at compile time?
On Wednesday, 10 June 2015 at 17:43:36 UTC, Ali Çehreli wrote: On the other hand, if it's a manifest constant (enum, const static, etc.) then by definition it cannot be mutated. If we allowed mutation of compile-time expressions, then we would have a complicated language. Unfortunately, the halting problem says that the analyzer does not exist. Although I don't believe it! enum i = 42; enum j = foo(i);// Did foo() use 42 or 43? i = 43; enum k = foo(i);// Did foo() use 42 or 43? How can an enum value be changed? I find the above confusing. So in fact, if `int` is evaluated at compile time, then we won't need constants or enums. Because they almost would not make sense. Although the issues associated with immutability, complex, I think they can be solved differently. The great thing about D's CTFE is that we can use arbitrarily complex expressions as long as they are available at compile time. For example, it is possible to make 'i' above a foreach loop variable and call foo() with different values. There is nothing great. Everything is based on constexpr of C++. I want something more revolutionary :) What is your use case? I feel like it can be solved by other means. There is no precedent special :) I just want to know more about the possibilities of D and the possibility of its compiler. D made me a terrible interest in compilers :)
Re: dmd and string imports on Windows
On Wednesday, 10 June 2015 at 19:59:17 UTC, Atila Neves wrote:
On Linux:
foo.d:
import std.stdio;
void main() { writeln(import(dir/bar.txt)); }
dmd -J. foo.d # ok
On Windows:
Error: file dir/bar.txt cannot be found or not in a path
specified with -J
I tried the obvious buildPath(dir, bar.txt) instead and now:
Error: file dir\\bar.d cannot be found or not in a path
specified with -J
I tried rdir\bar.txt and dir\\bar.txt and still nothing.
What am I supposed to do? Thanks,
Atila
I have encountered this as well, don't know if it's a bug or
intended. My workaround is to pass -Jdir
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On 6/10/15 12:56 PM, Russel Winder via Digitalmars-d wrote: Please note, OED (which is the definition of the English language whatever any USA upstarts may try to pretend) is gearing up to define they as both singular and plural, thus at a stroke solving all the he/she, she/he, (s)he, it faffing. Is they out of its mind? :)
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 18:41:56 UTC, Adam D. Ruppe wrote: On Wednesday, 10 June 2015 at 18:18:55 UTC, Ola Fosheim Grøstad wrote: It's always a good idea to not go personal, but I think they overdo it when you're not allowed to write he as a general term because it is gender specific. That's actually a good idea, you might not have noticed it, but I rarely use he alone as a general term and I notice it when other people do. Little things like this in language can make a difference in people's feelings and cause discomfort in the environment. Contrary to technical official definition, in REAL WORLD usage, he is BOTH a masuline AND a gender-neutral pronoun. A few occasional nutbags who deliberately ignore the gender-neutral possibility in order to promote their you are all sexists agenda is NO excuse for bowing to thier pressure.
Re: Asked on Reddit: Which of Rust, D, Go, Nim, and Crystal is the strongest and why?
On Wednesday, 10 June 2015 at 19:05:15 UTC, Ola Fosheim Grøstad wrote: Sure, follow your own ethics, but that won't work in an international environment as a rule without coming off as censorship. You cannot force people globally to follow a local culture. True, and a question of balance. A little bit of mutual adjustment goes a long way. I also try to cut down on the term you as a general term since people might think I mean them personally. That's what 'one' (rather than 'you') is for. But if one uses the word 'one' in this context it comes off as archaic and elitist. So be it. A bad programmer create bugs when it edits its files And if people force you to write it, it is quite reasonable to wonder what else they strongly object to so you better just stay silent. I really do try to cut down on the term you? Quite!
