Re: gRPC in D good idea for GSOC 2018?
On Monday, 15 January 2018 at 19:28:08 UTC, Ali Çehreli wrote: I know a project where D could benefit from gRPC in D, which is not among the supported languages: https://grpc.io/docs/ Do you think gRPC support is worth adding to GSOC 2018 ideas? https://wiki.dlang.org/GSOC_2018_Ideas Ali I can share a fresh experience from mentoring a student in a similar (also RPC) project last summer. We built native D-Bus bindings in D based on libasync. The student had had no previous experience with D or RPC, and within ~2.5 months of focused work she implemented the following: 1. (de)serialization of all D-Bus data types, including the use of compile-time reflection to recursively marshall structs, arrays, and variants. Except Variant, for which we decided to make our own D-Bus-specific tagged union type, all other D-Bus types are mapped to built-in D types. 2. A class to connect to the bus via libasync sockets, read the incoming messages and dispatch them to the registered handlers, and send messages to the bus. 3. Proxy (client) and server class templates that generate all the code necessary to make the remote calls look almost like local ones (the return value/out arguments are passed to a delegate that handles the output instead of being returned synchronously). So, more or less an equivalent of vibe.d's REST interface generator, only with fewer customization points. There were still some opportunities for refactorings and optimizations, so I wouldn't consider it production ready. Also, some planned features weren't implemented, such as a more convenient way for handling signals or allowing transports other than unix sockets on libasync. On the other hand, what we have is almost 100% covered with unit tests. This not only made adding successive layers quite pleasant, as little (if any) debugging of previously written stuff was ever necessary, but also helps to keep the stuff working as we modify it. Based on my experience, I'd say that implementing gRPC may be of a right size for a GSoC project, as long as you split it into smaller components/layers, prioritize them, and focus on having at least the basic stuff usable and tested, instead of expecting it to cover all usage cases and be heavily optimized.
Re: Maybe D is right about GC after all !
On Tuesday, 19 December 2017 at 09:54:05 UTC, Walter Bright wrote: "C, Python, Go, and the Generalized Greenspun Law" http://esr.ibiblio.org/?p=7804 Aaaa... if only D had no GC! But then there is no such thing as perfection in this world.
Re: Adding Markdown to Ddoc
On Wednesday, 6 December 2017 at 12:13:56 UTC, Walter Bright wrote: On 12/5/2017 8:11 PM, Walter Bright wrote: (I know this has come up before, and I've been opposed to it, but I've changed my mind.) Part of this change of mind was driven by the bit of markdown that Ddoc already supports - the backticks to quote code and auto detection of URLs - and how nice that has turned out. This is going to be the right time to deprecate the automatic change of some words that happen to be parameter names into code. :)
Re: String import an entire directory
On Monday, 13 November 2017 at 16:18:06 UTC, Andre Pany wrote: Three is a use case. (...) Yeah, I could probably find more use cases, but from the OP's question it's not clear what would be the benefit of doing it at compile time in OP's case.
Re: String import an entire directory
On Saturday, 11 November 2017 at 14:11:50 UTC, Neia Neutuladh wrote: At my job, I put together a database migration tool for our services. It scans for resources in your JAR file with an appropriate path, interprets them as SQL scripts, and applies them to the database if it hasn't been done yet. I want to implement this in D. However, while D allows you to import individual files, it doesn't let you import an entire directory. I can make a prebuild script to generate code for this, but I'm wondering: do other people find themselves needing this periodically? If so, I can write a DIP for it, or at least publish a codegen tool that other people can use. Why do you want to import files at compile time? Why can't it be done in run time, by simply reading directory with dirEntries and opening std.stdio.File for each one?
Static initialization of pointers
The D language specification under "Global and static initializers" [1], says the following: The Initializer for a global or static variable must be evaluatable at compile time. Whether some pointers can be initialized with the addresses of other functions or data is implementation defined. Runtime initialization can be done with static constructors. What is the rationale of making this implementation defined? What's the range of possible behaviors? Are there any circumstances in which a pointer can't be initialized with an address of a function or data? If so, couldn't a subset of cases have an explicitly defined, portable behavior? As far as I've tested this, DMD, GDC and LDC can handle static initialization of pointers to functions or data (except that LDC fails if function pointer(s) are obtained via __traits(getUnitTests, module_name)), even across separately compiled modules, which is consistent with a similar feature of C and C++. IIUC, the C standard always allows such initialization. In 6.6 Constant expressions, N1570 [2] says: 7 More latitude is permitted for constant expressions in initializers. Such a constant expression shall be, or evaluate to, one of the following: — an arithmetic constant expression, — a null pointer constant, — an address constant, or — an address constant for a complete object type plus or minus an integer constant expression. and 9 An address constant is a null pointer, a pointer to an lvalue designating an object of static storage duration, or a pointer to a function designator; it shall be created explicitly using the unary & operator or an integer constant cast to pointer type, or implicitly by the use of an expression of array or function type. The array-subscript [] and member-access . and -> operators, the address & and indirection * unary operators, and pointer casts may be used in the creation of an address constant, but the value of an object shall not be accessed by use of these operators. [1] https://dlang.org/spec/declaration.html#global_static_init [2] http://iso-9899.info/n1570.html
Re: @safe and null dereferencing
On Thursday, 27 July 2017 at 17:43:17 UTC, H. S. Teoh wrote: On Thu, Jul 27, 2017 at 05:33:22PM +, Adrian Matoga via Digitalmars-d wrote: [...] Why can't we just make the compiler insert null checks in @safe code? Because not inserting null checks is a sacred cow we inherited from the C/C++ days of POOP (premature optimization oriented programming), and we are loathe to slaughter it. :-P We should seriously take some measurements of this in a large D project to determine whether or not inserting null checks actually makes a significant difference in performance. That's exactly what I thought.
Re: DIP 1012--Attributes--Preliminary Review Round 1
On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote: DIP 1012 is titled "Attributes". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on August 10 (3:59 AM GMT August 11), or when I make a post declaring it complete. At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round. Otherwise, it will be queued for the formal review and evaluation by the language authors. Thanks in advance to all who participate. Destroy! I don't want to see monsters like "@core.attribute.GarbageCollectedness.inferred" as part of any declaration, ever. I agree that the problem is valid, but I don't think adding the complexity and verboseness presented in the DIP can solve it.
Re: @safe and null dereferencing
On Thursday, 27 July 2017 at 15:03:02 UTC, Steven Schveighoffer
wrote:
Inside the thread for adding @safe/@trusted attributes to OS
functions, it has come to light that @safe has conflicting
rules.
For the definition of safe, it says:
"Safe functions are functions that are statically checked to
exhibit no possibility of undefined behavior."
In the definition of @trusted, it says:
"Trusted functions are guaranteed by the programmer to not
exhibit any undefined behavior if called by a safe function."
Yet, safe functions allow dereferencing of null pointers.
Example:
void foo() @safe
{
int *x;
*x = 5;
}
There are various places on the forum where Walter argues that
null pointer dereferencing should cause a segmentation fault
(or crash) and is checked by the hardware/OS. Therefore,
checking for null pointers before any dereferencing would be a
waste of cycles.
However, there do exist places where dereferencing null may NOT
cause a segmentation fault. For example, see this post by
Moritz Maxeiner:
https://forum.dlang.org/post/udkdqogtrvanhbotd...@forum.dlang.org
In such cases, the compiled program can have no knowledge that
the zero page is mapped somehow. There is no way to prevent it,
or guarantee it during compilation.
It's also worth noting that C/C++ identifies null dereferencing
as undefined behavior. So if we are being completely pedantic,
we could say that no C/C++ code could be marked safe if there
is a possibility that a null pointer would be dereferenced.
The way I see it, we have 2 options. First, we can disallow
null pointer dereferencing in @safe code. This would be hugely
disruptive. We may not have to instrument all @safe code with
null checks, we could do it with flow analysis, and assuming
that all pointers passed into a @safe function are not null.
But it would likely disallow a lot of existing @safe code.
The other option is to explicitly state what happens in such
cases. I would opt for this second option, as the likelihood of
these situations is very low.
If we were to update the spec to take this into account, how
would it look?
A possibility:
"@safe D does not support platforms or processes where
dereferencing a null pointer does not crash the program. In
such situations, dereferencing null is not defined, and @safe
code will not prevent this from happening."
In terms of not marking C/C++ code safe, I am not convinced we
need to go that far, but it's not as horrible a prospect as
having to unmark D @safe code that might dereference null.
Thoughts?
-Steve
Why can't we just make the compiler insert null checks in @safe
code? We can afford bounds checking even in @system -O -release.
C++ can afford null check upon executing an std::function. The
pointer would most likely be in a register anyway, and the
conditional branch would almost always not be taken, so the cost
of that check would be barely measurable. Moreover, the compiler
can elide the check e.g. if the access via pointer is made in a
loop in which the pointer doesn't change. And if you prove that
this tiny little check ruins performance of your code, there's
@trusted to help you.
Re: D easily overlooked?
On Friday, 14 July 2017 at 13:29:30 UTC, Joakim wrote: Yes, D's compile-time regex are still the fastest in the world. I've been benching it recently for a marketing-oriented blog post I'm preparing for the official D blog, std.regex beats out the top C and Rust entries from the benchmarks game on linux/x64 with a single core: http://benchmarksgame.alioth.debian.org/u64q/regexredux.html https://github.com/joakim-noah/regex-bench D comes in third on Android/ARM, but not far behind, suggesting it would still be third on that list if run with a bunch of other languages on mobile. Dmitry thinks it might be alignment issues, the bane of cross-platform, high-performance code on ARM, as he hasn't optimized his regex code for ARM. Interesting. A few months ago I wanted to sell ctRegex as the fastest one in a presentation, but in my benchmarks (based on [1]) I found it to be of equal speed or slower than boost::regex (LDC vs Clang). I've got to take a look at your benchmarks, and repeat mine to check again if I didn't mess something up. [1] http://lh3lh3.users.sourceforge.net/reb.shtml
Re: DIP 1010--Static foreach--Formal Review
On Wednesday, 12 July 2017 at 10:57:37 UTC, Steven Schveighoffer wrote: Perhaps the deprecation path should include a removal of straight foreach over a tuple working (use static foreach explicitly). This would make the distinction even more obvious. I'd also vote for gradual removal of foreach over a tuple. It would be one less awkward moment when teaching D.
Re: version=D_16
On Monday, 10 July 2017 at 21:30:44 UTC, Walter Bright wrote: On 7/10/2017 1:52 PM, Luís Marques wrote: On Monday, 10 July 2017 at 20:19:46 UTC, Walter Bright wrote: On 7/10/2017 12:46 PM, Luís Marques wrote: I'm curious how that implementation addresses the issues I brought up: I'm not really sure how to respond, you mostly just made statements about your worldview. For instance: "C++ on a 64K machine is like using a tank to get to the grocery store". If you mean using all of C++ features, sure, that's inappropriate. If you mean that there are no C++ features that you could use in a microcontroller, there are non-trivial amounts of people the disagree with you. You can't use RTTI or Exceptions, for example. Those generate bloat even if they are not used - a compiler switch is typical to disable them. It's not true that C++ is "pay only for what you use". If the C++ usage is "C with member functions", then yes, it'll work and be useful. There's more to that. Since these chips have limited computational capabilities, you really want to move as much computation as possible into compile time. And this is what makes C++ a better choice than C, and D a better choice than C++. It's also the safer and more expressive type system that saves you the time you would spent on debugging every kind of bug resulting from casting everything to void* and back.
Re: Analysis of D GC
On Tuesday, 20 June 2017 at 11:49:49 UTC, Jacob Carlborg wrote: You need to move to 64bit. Apple is already deprecating support for 32bit apps and after the next version of macOS (High Sierra) they're going to remove the support for 32bit apps. There are other 32-bit platforms that are going to stay on the market for a while. 32-bit ARMs won't disappear anytime soon.
Re: atomic operations compared to c++
On Tuesday, 13 June 2017 at 06:12:46 UTC, gzp wrote: (...) There is no consume in D. What do you currently use for in C++? It is temporarily deprecated in C++17.
Re: DIP 1003 Formal Review
On Friday, 12 May 2017 at 16:17:03 UTC, Mike Parker wrote: ... 3. deprecate, remove, forget. During the deprecation period, it could live as "contextual keyword", or actually with grammar modified to expect an identifier "body" instead of keyword. That would allow using "body" as identifier immediately.
Re: Fantastic exchange from DConf
On Wednesday, 10 May 2017 at 12:18:40 UTC, Patrick Schluter wrote: On Wednesday, 10 May 2017 at 11:16:57 UTC, Atila Neves wrote: [...] The likelihood of a randomly picked C/C++ programmer not even knowing what a profiler is, much less having used one, is extremely high in my experience. I worked with a lot of embedded C programmers with several years of experience who knew nothing but embedded C. We're talking dozens of people here. Not one of them had ever used a profiler. I've worked 10 years in embedded (industry, time acquisition and network gears) and I can say that there is a good reason to that. It's nearly impossible to profile in an embedded system (nowadays it's often possible because of the generalization of Linux and gnu tools but at that time it wasn't). The tools don't exist or if they do, the instrumentation breaks the constraints of the controller. This was also one of the reason we chose our embedded CPU's very carefully. We always chose processors for which there existed mainstream desktop versions so that we could at least use the confortable tooling to test some parts of the code on a nice environment. We used Z80 (CP/M), 80186 (MS-C on DOS) and then 68030 (Pure-C on Atari TT). TL;DR profiling for embedded is order of magnitudes harder than for nice OS environments. IMO it's just different. The thing is, the tools you can use don't need to be marketed as "profilers". People will always find excuses if they lack time, will or knowledge. In practice, there's always a way to profile and debug, even if you don't have dedicated tools for it. It's also a lot easier to reason about performance on small chips with no caches, ILP, etc. and with fixed instruction timing, than it is on modern complex CPUs with hundreds of tasks competing for resources. One universal tool is oscilloscope, for sure you have one on your colleague's desk if you really do embedded stuff. A common way to profile on home computers from the '80s such as Atari XE (6502), was simply to change screen colors. That way you always knew the time taken by the measured code with 1-cycle precision. 13.5 scanlines are white? That's 1539 cycles! The time it took to execute a tight loop could even be computed accurately with pen and paper by just looking at the assembly. It's also a lot easier to implement a cycle-exact emulator for such simple chips, and then you can measure everything without observer effect.
Re: DConf 2017 Hackathon report
On Tuesday, 9 May 2017 at 13:19:12 UTC, Steven Schveighoffer wrote: But it was very awesome to be able to go around and find the people to discuss a PR/idea without going through a forum thread. I think there's a psychological barrier that happens when you post a complete argument, and then your counterpart forms an interpretation in their mind of what the argument means, forms their complete counter argument, and neither side really understands what the other is saying or willing to do. Doing it in person allows so much more interaction -- you can cut off early any misinterpretations. It's also harder to be nasty in person :) +1! For the same reasons, it's also a lot easier for people who don't use English as their 1st language to express their ideas as one doesn't need to spend time carefully looking up the meaning of words to make sure the "complete argument" will be understood as intended. :)
Re: DConf 2017 Hackathon report
On Tuesday, 9 May 2017 at 04:35:40 UTC, Ali Çehreli wrote: Please list what we've achieved during the hackathon, including what is started but is likely to be finished in the coming days or months. For me: - Finished updating "Programming in D" to 2.074.0 (the HTML is now up to date but I could not get to the still manual work of preparing the ebooks) - Contributed to the logo and branding discussions - Opened two bugs - Ate German cookies :) Ali I: 1. Started a PR adding -Xcc switch to LDC [1]. 2. Discussed a solution to [2] and [3] with Sönke, implementation is in progress. 3. Briefly went through sources of Stefan's CTFE implementation. To me it was also a good quick lesson about part of DMD internals I didn't know yet, and I hope I'll be able to review his code from time to time and motivate him. 4. Got a ton of inspiration and motivation. [1] https://github.com/ldc-developers/ldc/pull/2104 [2] https://github.com/dlang/dub/issues/628 [3] https://github.com/dlang/dub/issues/228
Re: "I made a game using Rust"
On Wednesday, 10 May 2017 at 15:03:19 UTC, Adam D. Ruppe wrote: On Wednesday, 10 May 2017 at 14:02:38 UTC, Adrian Matoga wrote: Would you mind giving some examples? What bothers me on a regular basis is overloading. Basic case: $ dmd lll lll.d(6): Error: none of the overloads of 'foo' are callable using argument types (int, double), candidates are: lll.d(1):lll.foo(int a, int a) lll.d(2):lll.foo(int a, string s) Contrast that to g++: $ g++ lll.cpp lll.cpp: In function ‘int main()’: lll.cpp:7:14: error: no matching function for call to ‘foo(int, Foo)’ foo(0, Foo()); ^ lll.cpp:7:14: note: candidates are: lll.cpp:1:6: note: void foo(int, char*) void foo(int a, char* b); ^ lll.cpp:1:6: note: no known conversion for argument 2 from ‘Foo’ to ‘char*’ lll.cpp:2:6: note: void foo(int, float) void foo(int a, float b); ^ lll.cpp:2:6: note: no known conversion for argument 2 from ‘Foo’ to ‘float’ The g++ example isn't great either... but is better because of this: "no known conversion for argument 2 from ‘Foo’ to ‘float’" It actually told me which argument didn't match! clang is similar: $ clang lll.cpp lll.cpp:7:2: error: no matching function for call to 'foo' foo(0, Foo()); ^~~ lll.cpp:1:6: note: candidate function not viable: no known conversion from 'Foo' to 'char *' for 2nd argument void foo(int a, char* b); ^ lll.cpp:2:6: note: candidate function not viable: no known conversion from 'Foo' to 'float' for 2nd argument void foo(int a, float b); With the dmd one, especially on a long function, it is hard to tell just which argument is giving trouble. The C++ errors just flat out tell me which argument didn't match for each candidate. In this simple case above, I actually prefer DMD's messages, as there's simply less text for my eyes to read and brain to parse, so I can quickly spot where the problem is. I agree, though, that with longer argument lists, especially with const vs. non-const or template constraints, trying to figure out what's wrong could be at least frustrating. Templates with constraints are even worse. lll.d(3): Error: template std.algorithm.sorting.sort cannot deduce function from argument types !()(int), candidates are: /home/me/d/dmd2/linux/bin32/../../src/phobos/std/algorithm/sorting.d(1830):std.algorithm.sorting.sort(alias less = "a < b", SwapStrategy ss = SwapStrategy.unstable, Range)(Range r) if ((ss == SwapStrategy.unstable && (hasSwappableElements!Range || hasAssignableElements!Range) || ss != SwapStrategy.unstable && hasAssignableElements!Range) && isRandomAccessRange!Range && hasSlicing!Range && hasLength!Range) What a mess! Just formatting that output might help, but I'd especially love it if it told me which individual boolean elements failed, passed, and were short-circuited. The compiler knows this, it had to evaluate that to figure out it didn't match, but it doesn't tell me. At a glance, can you even tell what I passed to the function? Bonus points would be it telling me why, for example, `isInputRange` failed, but I understand that is an even bigger problem to solve. It's indeed painful, but I found UDAs to be useful in dealing with it. First, I'm sure you know Atila's concepts [1]. I also use UDAs in flod [2], so instead of checking whether the implementation satisfies a constraint, I only check if it's explicitly tagged with a specific UDA. Now, I immediately see whether it's a method that I forgot to implement or just a typo, instead of being forced to guess by a "missing overload" message. Of course, C++ doesn't have constraints so there's no comparison there. Lastly, check this out: lll.d(5): Error: function lll.foo (Color c) is not callable using argument types (Color) WTF, right? Well, I have a locally defined `struct Color` and an imported one. Same name, but different type. The error message doesn't tell me which one is which. Yeah, that one was funny. :) These are the top 3 dmd error messages that bother me regularly. At runtime, little drives me more nuts than RangeError not telling me the index and the length. Again, it knows, the code checked it, but it didn't report it. Same with assertions. I usually end up adding wrappers like assertEqual, and the more I use them, the more I feel like switching to something like [3] or [4], as much as I normally prefer to keep the number of dependencies low. I think RangeError could be solved without much effort by changing the compiler/runtime interface at _d_arraybounds*. Assertions are probably harder. [1] http://forum.dlang.org/post/eoxerbkaowxpgjubh...@forum.dlang.org [2] https://github.com/epi/flod/blob/develop/source/flod/package.d [3] https://code.dlang.org/packages/fluent-asserts [4] http://code.dlang.org/packages/unit-threaded
Re: "I made a game using Rust"
On Wednesday, 10 May 2017 at 14:00:08 UTC, Ethan Watson wrote: On Wednesday, 10 May 2017 at 13:22:22 UTC, Adam D. Ruppe wrote: Those of you on IRC know that I've been pushing hard for better error messages. I think that is *the* killer feature clang offered and I see it brought up again and again. D used to do well. Now we're lagging behind. No language change needed to vastly improve error messages. I find it a very curious state of affairs myself that Microsoft's C++ compiler has significantly better error messages than DMD. Would you mind giving some examples?
Re: Fantastic exchange from DConf
On Tuesday, 9 May 2017 at 09:22:13 UTC, Joakim wrote: On Tuesday, 9 May 2017 at 06:15:12 UTC, H. S. Teoh wrote: On Mon, May 08, 2017 at 06:33:08PM +, Jerry via Digitalmars-d wrote: [...] Is that a subtle joke, or are you being serious? [...] Heh, I saw you wrote the post and knew it would be long, then I kept scrolling and scrolling... :) Please, please, please submit this as a post on the D blog, perhaps prefaced by the Walter/Scott exchange and with some links to the issues you mention and the relevant portions of the D reference. I think it would do well. +1
Re: DLang quarterly EU?
On Sunday, 7 May 2017 at 16:37:02 UTC, Ethan Watson wrote: On Sunday, 7 May 2017 at 11:32:53 UTC, Adam Wilson wrote: On 5/7/17 12:57, Seb wrote: +1 - maybe its worth considering to make it for two days (=one weekend) That can work. It would be two or three days vacation depending on flight schedules. ... Not to mention a cool way to see new cities if it moves around. Yes, that was the intention on both counts. There's no point to flying somewhere just for the day. Especially since there will doubtless be Micro BeerConfs in the evening ;-) Andrei suggested that Bucharest be the first city we hold this in. Sounds like a great plan to me. Count me in!
Re: See you soon at dconf
On Wednesday, 3 May 2017 at 07:42:51 UTC, Luís Marques wrote: On Tuesday, 2 May 2017 at 20:19:02 UTC, Stefan Koch wrote: Hi, I am very happy to see you soon at dconf. And I apologize in advance for my nearly slideless talk. Hope this time there is dmd on the machine! Cheers Stefan Well, I have too many. Want some? Can anyone get me a phillips screwdriver? Seriously. I'll be at the official hotel or you can lend me one tomorrow morning at the conference. I've got one with me. I'm not staying in Ibis, but it's close to my hotel. I shall get there at about 9pm. See you!
Re: CTFE Status 2
On Sunday, 30 April 2017 at 19:52:27 UTC, H. S. Teoh wrote: On Sun, Apr 30, 2017 at 01:26:09PM +, Stefan Koch via Digitalmars-d wrote: On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: > [ ... ] Big news! The first step to include debug info has been done. Yes this means you will be able to step through ctfe code while the compiler executes it. Wow! Will that be accessible to users in the end? That could be a totally awesome way of debugging CTFE code! I used to think the same, but with each new line of code I write that is to be executed in CT, I become more convinced that there's no need to expose such debugging interface to the end user. Why? Because the end user expects that CTFE either gives exactly the same results as run-time execution or that it stops with an explicit error message on something that is not designed to be executed in CT. Any other problem found during CTFE execution must be 100% reproducible in run time or it's an ICE. Any CTFE debugging should be only for compiler maintainers, and the user shouldn't worry that CTFE could mess up something.
Re: CTFE Status 2
On Wednesday, 3 May 2017 at 04:22:00 UTC, Stefan Koch wrote: On Tuesday, 2 May 2017 at 22:08:31 UTC, Moritz Maxeiner wrote: [...] Using TCP would just remove any potential future headache from the equation. I think any ordering should be done explicitly at the debugging protocol level. for example when sending sourceline messages the order is given by the line number and ordering can be done by the application. It's the same for breakpoint setting or for breakpoint trigger notification. As for lost packages, we want to respond intelligently as well. And maybe reduce the amount of data in the package, to make arrival of future packages more likely. So you're going to reinvent TCP in your debugging protocol?
Re: DConf Hackathon Ideas
On Thursday, 27 April 2017 at 14:53:02 UTC, Mike Parker wrote: This year, DConf has an extra day tacked on for problem solving in the form of a hackathon. The intent is to work on issues people find frustrating in the D ecosystem. While there will be time given at the event for proposals, and those involving third-party projects are welcome, it will help speed things along for the organizers to come in with a list of big issues to get the ball rolling. To help in compiling the list, what are some major issues from the ecosystem that you'd like to see fixed? It's probably not a "major issue", but I'd be interested in joining any efforts towards making dub more cross-compilation-friendly. "--compiler=" and "--arch=" aren't quite useful in any serious scenario with multiple target platforms that use different compiler settings and sysroots.
Re: Compare boost::hana to D
On Saturday, 22 April 2017 at 07:53:49 UTC, Johannes Pfau wrote: OT but is there any benefit to identify events with strings? As long as you use compile time only events I'd prefer a syntax as in https://github.com/WebFreak001/EventSystem (one benefit is that it's 100% IDE autocomplete compatible) I guess if you want runtime registration of events identifying by name is useful. But then you also somehow have to encode the parameter types to make the whole thing safe... I agree. Personally, I'd probably also start with something like WebFreak001's ES and only think about how to add run-time dispatch later if I absolutely need it.
Re: DConf 2017 Berlin - bicycles
On Friday, 21 April 2017 at 13:37:17 UTC, Steven Schveighoffer wrote: After the bike tour I had last year, I can 100% agree that having a bike is a fabulous way to get around the city quickly. You can ride the subway with your bike (although IIRC, you need to buy a ticket for it), but the thing that makes Berlin so accessible via bike is that it's totally flat. Those 10 minute walks become 1 minute rides, and it's a very bike-friendly city. I mused while riding around that the tour would be nearly impossible, or at least a huge workout if we did something like that in Boston :) I don't know about Boston, but I've heard many times that Lisbon was too hilly to ride a bike there, but in reality it wasn't all that bad (well, maybe on the hottest summer days), and in recent years the city council has been investing in dedicated infrastructure to improve it. I guess people will always find excuses. :) Warsaw, where I live now, is almost just as flat as Berlin and quite pleasant to ride around, especially in spring and summer (I rarely choose the shortest way home), but it's not as bike-friendly yet for other reasons. Cities like Berlin are a live explanation of the term "critical mass" – there's just enough people on bikes so they're treated as normal and respected in the streets, unlike in Polish cities where riding to work is still considered eccentric and casual cyclists are thought of as traffic obstacles, members of leftist sects, or just too poor to own a car. Glad you are coming, Adrian, looking forward to seeing you again! Yeah, can't wait to hear your talk on iopipe! :)
Re: DConf 2017 Berlin - bicycles
On Friday, 21 April 2017 at 16:49:36 UTC, Iain Buclaw wrote: On 19 April 2017 at 20:22, Adrian Matoga via Digitalmars-d wrote: I'm arriving at Berlin Ostbahnhof on Wednesday evening and will be heading to Britz Hotel, but last year I learnt that the best way to get around the city is on a bicycle. Can you recommend a place (preferably near the station) where I could rent a not-so-small bike for 4 days for a reasonable price? Thanks! Almost every single bike shop you stumble across in Berlin offers rentals, all pretty much at the same price of around 10€ a day. If you have a native german to help you, maybe you'll even get a swindled deal. However, the one notable thing that has changed from last year is that there's a new competitor in the form of a Lidl bike. I've seen literally hundreds of them inside the Berlin S-bahn ring, one major advantage of using them is that they don't need a dedicated docking station for you to park them in. I'll just refer to this blog on the more fine grain details. https://schnaeppchenfuchs.com/news/lidl-bike-berlin Looks like they even come with a GPS locator, which probably is used for DB's smartphone app. https://www.lidl-bike.de/de/rad-finden Good idea, I'll try to find one before I look for some "traditional" rental. I'm only afraid that as a sort of public bikes they're all in a "normalized" size which probably won't be safe for me – I sometimes ride nextbike bikes here in Warsaw (this year they look exactly the same as in Berlin) and they kill my knees very quickly. I really wanted to take my own bike but the train operator sucks – there's only one train in the timetable that allows bicycles and it's at 6am and costs twice as much as the one in the afternoon.
Re: Python : Pythonista / Ruby: Rubyist : / D : ?
On Friday, 21 April 2017 at 17:20:14 UTC, Vasudev Ram wrote: Hi list, I hope the question is self-evident from the message subject. If not, it means: what are D developers generally called (to indicate that they develop in D)? The question occurred to me somehow while browsing some D posts on the forums just now. DLanger? DLangist? D'er? Doer? :) I tend to favor DLanger, FWIW. In just 2 weeks we'll get a chance to be called Drunkards.
Re: Compare boost::hana to D
On Friday, 21 April 2017 at 13:10:43 UTC, Adam D. Ruppe wrote:
On Wednesday, 19 April 2017 at 18:02:46 UTC, Adrian Matoga
wrote:
[2] https://epi.github.io/2017/03/18/less_fun.html
BTW in your D foreach, you could also have done `switch`
void trigger(string event) {
switch(event) {
foreach (i, e; events) {
case e:
foreach (c; callbacks_[i])
c();
return;
}
default:
assert(false, "trying to trigger an unknown event: "
~ event);
}
}
And the compiler+runtime can optimize that into a binary search
when it gets larger automatically.
Thanks, I completely forgot about it. I should update the article
soon.
Re: Compare boost::hana to D
On Friday, 21 April 2017 at 12:37:03 UTC, Mike Parker wrote: On Friday, 21 April 2017 at 12:34:53 UTC, Mike Parker wrote: On Thursday, 20 April 2017 at 07:37:17 UTC, Mike Parker wrote: On Thursday, 20 April 2017 at 05:01:17 UTC, Adrian Matoga wrote: On Wednesday, 19 April 2017 at 19:22:11 UTC, Ali Çehreli wrote: Thank you. Has this been on Reddit yet? I haven't posted it there, I don't have an account. I'll post it, but not today. It will get more attention if I wait until Friday afternoon GMT. https://www.reddit.com/r/programming/comments/66ovil/metaprogramming_is_less_fun_in_d/ And I should add (for anyone paying attention), this is exactly the sort of thing I'm looking for more of on the D Blog. Submissions welcome :-) This, and the generally positive feedback on r and HN are quite motivating. :) I have some ideas for more articles but being a non-native English speaker I need a lot of time to make the text look at least understandable, so I usually give up quickly and move on to play with code instead. :)
Re: Compare boost::hana to D
On Friday, 21 April 2017 at 12:34:53 UTC, Mike Parker wrote:
On Thursday, 20 April 2017 at 07:37:17 UTC, Mike Parker wrote:
On Thursday, 20 April 2017 at 05:01:17 UTC, Adrian Matoga
wrote:
On Wednesday, 19 April 2017 at 19:22:11 UTC, Ali Çehreli
wrote:
Thank you. Has this been on Reddit yet?
I haven't posted it there, I don't have an account.
I'll post it, but not today. It will get more attention if I
wait until Friday afternoon GMT.
https://www.reddit.com/r/programming/comments/66ovil/metaprogramming_is_less_fun_in_d/
Thanks!
Maaan, reddit takes ages to load on mobile and doesn't let me
read anything until I close all these annoying popups. Yet the
comments are mostly in the same tone I saw a few times in the
past when links were posted here ("D sucks" and so on) and made
me think of reddit as a complete waste of time. It looks like
it's all the time the same topic – bad, bad GC, D1 vs. D2, oh,
and Rust and Go are better.
OTOH, I saw it posted also on HN
(https://news.ycombinator.com/item?id=14165198)
and there, the discussion seems to be slightly more interesting.
Re: DConf 2017 Berlin - bicycles
On Wednesday, 19 April 2017 at 20:13:52 UTC, Walter Bright wrote: On 4/19/2017 11:22 AM, Adrian Matoga wrote: I'm arriving at Berlin Ostbahnhof on Wednesday evening and will be heading to Britz Hotel, but last year I learnt that the best way to get around the city is on a bicycle. Can you recommend a place (preferably near the station) where I could rent a not-so-small bike for 4 days for a reasonable price? Thanks! I personally found that the transit system in Berlin was excellent. You can buy a 3 day pass from the ticket machines, it's under "Tourist Fahrkarte" if I remember correctly. It is! In many discussions about public transport, Berlin is mentioned as an example that should be followed, and I must agree with that after a few rides I had.
Re: DConf 2017 Berlin - bicycles
On Wednesday, 19 April 2017 at 19:03:40 UTC, Fool wrote: No personal experience, but http://www.yaambike.de/ sounds like an option. Looks good, thanks.
Re: Compare boost::hana to D
On Wednesday, 19 April 2017 at 19:22:11 UTC, Ali Çehreli wrote:
Thank you. Has this been on Reddit yet?
I haven't posted it there, I don't have an account.
Two typos:
1) A missing underscore made me believe C++ gained a new
keyword (make). :)
auto events = make event_system("foo"_s, "bar"_s, "baz"_s});
Uhh, that underscore isn't the only problem in this line. ;)
Fixed both, thank you!
Re: Compare boost::hana to D
On Wednesday, 19 April 2017 at 18:57:19 UTC, David Gileadi wrote: On 4/19/17 11:30 AM, Adrian Matoga wrote: On Wednesday, 19 April 2017 at 18:26:20 UTC, Sebastiaan Koppe wrote: On Wednesday, 19 April 2017 at 18:02:46 UTC, Adrian Matoga wrote: [2] https://epi.github.io/2017/03/18/less_fun.html Minor nit in the article--in the following paragraph "runtime" should probably be replaced with "compile time": "Note the enum in place where C++ version used auto. The type is also inferred automatically, but using enum forces index to be computed at runtime and only then it can be used in static assert." Fixed, thanks a lot! It seems impossible to spot all mistakes without someone else's eyes even if I read it a thousand times... :|
Re: Compare boost::hana to D
On Wednesday, 19 April 2017 at 18:26:20 UTC, Sebastiaan Koppe wrote: On Wednesday, 19 April 2017 at 18:02:46 UTC, Adrian Matoga wrote: [2] https://epi.github.io/2017/03/18/less_fun.html Great article! Thanks! I should mention I've also got somewhat positive feedback from Louis [1]. [1] https://twitter.com/LouisDionne/status/843227582803849216
DConf 2017 Berlin - bicycles
I'm arriving at Berlin Ostbahnhof on Wednesday evening and will be heading to Britz Hotel, but last year I learnt that the best way to get around the city is on a bicycle. Can you recommend a place (preferably near the station) where I could rent a not-so-small bike for 4 days for a reasonable price? Thanks!
Re: Compare boost::hana to D
On Wednesday, 19 April 2017 at 08:19:52 UTC, Ali Çehreli wrote: I'm brushing up on my C++ to prepare for my C++Now 2017 presentation[1]. boost::hana is an impressive library that overlaps with many D features: http://www.boost.org/doc/libs/1_64_0_b2/libs/hana/doc/html/index.html Have you used boost::hana? What are your thoughts on it? And please share your ideas for the presentation. There has been threads here about C++ closing the gap. Does D still bring competitive advantage or is it becoming irrelevant? (Obviously, some think its irrelevant already.) I'm trying to collect opinions... :) Thank you, Ali [1] http://cppnow.org/2017-conference/announcements/2017/04/09/d-keynote.html I was at C++ Meeting 2016 in Berlin, where Louis Dionne talked about hana in his keynote [1]. I've summarized my feelings in a blog post [2]. In short, you can do the same tricks in D, but frequently there's an idiomatic way to express the same thing just as concisely without them. And of course, feel free to use any part of my post in your talk. :) [1] https://www.youtube.com/watch?v=X_p9X5RzBJE [2] https://epi.github.io/2017/03/18/less_fun.html
Re: PDF generation in D?
On Wednesday, 16 November 2016 at 01:22:33 UTC, Jot wrote: What's your point? My point is that PS as a textual format can be easily generated without external libraries or tools, and then converted to an identically looking PDF.
Re: PDF generation in D?
On Tuesday, 15 November 2016 at 11:13:54 UTC, Jot wrote: On Tuesday, 15 November 2016 at 09:39:09 UTC, Adrian Matoga wrote: On Friday, 11 November 2016 at 09:47:21 UTC, Robert burner Schadek wrote: I used text files and LaTeX in the past, it works with everything textfile -> process -> LaTeX -> pdf This. Another (a bit lower-level) option would be to produce a PostScript file and pass it to (e)ps2pdf. Then that begs the question about how to generate ps in D and just kicks the can down the road. PostScript is a programming language and PS files are plain text files with programs written in it, so formatted file output is your friend here. "Lower-level" means that you need to take care of the layout of items on a page manually, using physical positions. It's quite straightforward for simple vector graphics, but not so much for multi-page text documents with figures and tables.
Re: PDF generation in D?
On Friday, 11 November 2016 at 09:47:21 UTC, Robert burner Schadek wrote: I used text files and LaTeX in the past, it works with everything textfile -> process -> LaTeX -> pdf This. Another (a bit lower-level) option would be to produce a PostScript file and pass it to (e)ps2pdf.
Re: If Statement with Declaration
On Friday, 4 November 2016 at 15:34:00 UTC, Jerry wrote:
On Friday, 4 November 2016 at 14:16:44 UTC, Matthias Bentrup
wrote:
On Thursday, 3 November 2016 at 22:29:34 UTC, Jerry wrote:
if(int i = someFunc(); i >= 0)
{
// use i
}
Thoughts on this sort of feature?
I would prefer the syntax
if( (int i = someFunc()) >= 0 )
{
// use i
}
as this matches the already existing assignment expression
syntax if you pull the declaration out of the if expression.
Well you can argue the "if( init ; condition )" syntax matches
"for( init ; condition ; update)", minus the "update" section.
You've just answered your own question:
for (int i = someFunc(); i >= 0; )
{
// use i
break;
}
Re: Is dmd fast?
On Wednesday, 22 June 2016 at 14:28:19 UTC, Adam D. Ruppe wrote: BTW this more measures linker speed than compiler. dmd -c -o- just runs the compiler and skips filesystem output... it'd be pretty fast and if there's similar options for other compilers (gcc has -c too at least) it might be better for small programs. Larger programs I think is fair to include the link step, since it should be less a percentage there and you do need to run it anyway. Yeah, you do need to run it anyway, even if you build incrementally. It'd be a lie to omit the link time when the compiler actively works to make linker's job harder by inflating the symbol table to tens or hundreds of megabytes.
Re: Non movable structs
On Sunday, 19 June 2016 at 02:06:59 UTC, deadalnix wrote: Long story short, I need structs that do not move. I'm sure there are many other use cases. I needed that for a struct member function to be passed as delegate for a fiber. The easiest way I found was to malloc the struct.
Re: Allowing DConf presentations to be spoken in other languages
On Friday, 10 June 2016 at 21:31:36 UTC, Jesse Phillips wrote: After this year's DConf I started to wonder if it could be beneficial to provide a slot during the conference where the speaker would do his presentation in a language other than English. I realize that many are like me and would not be able to consume such information, which is why the suggestion is to limit talks from other languages. My hope would be that it would help produce more language information content outside of English and strengthen those communities. Possibly uniting communities we don't see, but still center around D. This isn't for me, such an idea is not helpful for me. Is there anyone in a position who could speak to this being a reasonable thing to try? That's what local or national conferences are for. Still, even in such ones people often prefer to use English (I've seen it in Portugal and Poland), as CS vocabulary for other languages is usually awkward, non-consistent or non-existent, and it feels even more awkward to use English verbs and nouns interspersed with your native prepositions.
Re: Idea: swap with multiple arguments
On Tuesday, 24 May 2016 at 02:40:24 UTC, Observer wrote: As for utility, if you're a PostScript programmer, where keeping track of data is done via a stack-oriented model, this capability gets used all the time, to bring relevant arguments to the top of the stack to be operated upon, or to shove arguments deeper into the stack for later use. Forth also has "swap" and "rot". The former moves 2nd value to the top of the stack (i.e. a, b becomes b, a). The latter moves 3rd value to the top (i.e. a, b, c becomes b, c, a).
Re: So, About That Official Blog...
On Friday, 6 May 2016 at 13:47:48 UTC, Adam D. Ruppe wrote: On Friday, 6 May 2016 at 13:34:02 UTC, Jack Stouffer wrote: Using JS for an eye candy feature on the internet is not "outrageous". It's not like with JS turned off the code would be displayed with no formatting and in sans-serif. Those JS things have a habit of lagging my laptop to a crawl, whereas a server side highlighter works beautifully without slowdown. When your site works better without JS than with, you've made a mistake somewhere, especially when what the JS is doing could be free! I totally agree. This tumblr site easily lagged a bored i7. A big NO from me.
Re: Post-DConf brunch?
On Saturday, 7 May 2016 at 08:55:50 UTC, Joseph Rushton Wakeling wrote: Hello all, For anyone who's still in town and fancies grabbing a nice late breakfast/early lunch in a nice Berlin food place, I'll be doing my usual Saturday morning thing of dropping by this cafe/restaurant Cool! I'll be there in ca. 20 minutes.
Re: How are you enjoying DConf? And where to go next?
On Friday, 6 May 2016 at 20:59:29 UTC, John Colvin wrote: On Friday, 6 May 2016 at 14:57:59 UTC, Chris wrote: On Friday, 6 May 2016 at 14:53:15 UTC, Jonathan M Davis wrote: [...] Facebook have their European headquarters in Dublin. Maybe they'd be willing to sponsor DConf2017 (there are loads of other tech companies in Dublin). Flights from the U.S. to Ireland and back are very frequent. Dublin has cheap direct flights from quite a few places in the US, as well as pretty much everywhere in europe. Yup, +1 for Dublin.
Re: With statement extension
On Wednesday, 27 April 2016 at 18:34:18 UTC, Artur Skawina wrote:
[...]
void foo (Matrix matrix, SameType e1, SameType e2)
{
ref M() { return matrix.rawArr; }
ref Ex1() { return e1.someProperties.someModulusX; }
ref Ey1() { return e1.someProperties.someModulusY; }
ref Ex2() { return e2.someProperties.someModulusX; }
ref Ey2() { return e2.someProperties.someModulusY; }
ref v() { return e1.someProperties.aRatio; }
foreach (i; ...) foreach (j; ...) {
M[...] = Ex1 > Ex2 ?
1/v^^2 * sqrt(v * (Ex1 + Ex2)^^2 + v^^2 * (Ey1 -
Ey2)^^2) :
1/v^^2 * sqrt(v * (Ex1 + Ex2)^^2 + v^^2 * (Ey1 +
Ey2)^^2) ;
}
}
artur
Unless any of the properties is an enum or, well, a @property,
and I'd expect both in such case.
Re: The day before DConf 2016
On Thursday, 7 April 2016 at 18:13:16 UTC, Mike Parker wrote: I'm flying in to Berlin late on May 2nd. I'll be staying at the Hotel Ibis, slated to be the "unofficial hangout place" according to the DConf site. I'm curious who else will be in the area on the 3rd. I'm usually an explorer when I visit a city for the first time, but on this trip I'd be more interested in hanging out with others from DLand, conversing about our favorite language, if anyone's up for it. I'm arriving at Ostbahnhof on May 3rd at about 7:30pm. It doesn't leave much time for sightseeing, but it would be cool to join you for a dinner or a few pints. :)
Re: Can I get more opinions on increasing the logo size on the site please
On Wednesday, 10 February 2016 at 20:25:05 UTC, anonymous wrote: On 10.02.2016 17:49, Ola Fosheim Grøstad wrote: If you guys are going to create a new logo based on the old one, you probably should clear it with the original creator. On his website he has give us use rights for non-commercial use, but not rights to create derivative works... The new logo is not part of the pull request. It's already on the site. If there's a legal problem, we should probably revert that. The exact text on the site of the original author [1] is COPYRIGHT © SUKIMASHITA 2006 ALL FREE TO USE. ONLY SELLING THESE IMAGES IS PROHIBITED. I'd understand that to allow derivative works, but disallow selling them. I'm not a lawyer, though. If those terms don't allow us to mess with the logo, what kind of statement or license do we need from the author? [1] http://media.sukimashita.com/d/ The same site also says, under "Guide": "Ease creation of derivative art (icons, banners etc.)", which is certainly not an explicit legal statement, but gives an idea of the author's intention.
Re: reduce -> fold?
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu wrote: As has been discussed before there's been discussion about std.algorithm.reduce taking the "wrong" order of arguments (its definition predates UFCS). I recall the conclusion was there'd be subtle ambiguities if we worked reduce to implement both orders. So the next best solution is to introduce a new name such as the popular "fold", and put them together in the documentation. Thoughts? YES! There was a topic on this [1] and some implementation proposed. I'm not sure if it was the only one. [1] http://forum.dlang.org/post/sqbizjwcyavbrxwag...@forum.dlang.org
Re: Distributed Memory implementation
On Monday, 18 January 2016 at 05:59:15 UTC, tcak wrote: I, due to a need, will start implementation of distributed memory system. Idea is that: Let's say you have allocated 1 GiB space in memory. This memory is blocked into 4 KiB. After some reservation, and free operations, now only the blocks 0, 12, and 13 are free to be allocated. Problem is that those memory blocks are not consecutive. With the implementation of distributed memory, those blocks will be appended into a struct or object (however it is implemented), and that struct or object will allow access to that 12 KiB of space (3 x 4 KiB blocks) like it is allocated in memory consecutively. Is there anything like this in Phobos, or shall I start my own implementation? Just a note about terminology: I'd rather call it "fragmented memory" or something alike. The term "distributed memory" usually refers to something really different [1]. Your idea seems interesting, but IMHO a compacting GC should be the preferred solution for heap fragmentation. [1] https://en.wikipedia.org/wiki/Distributed_memory
Re: We need a good code font for the function signatures on dlang.org
On Wednesday, 16 December 2015 at 21:05:27 UTC, Andrei Alexandrescu wrote: I was looking at https://github.com/D-Programming-Language/dlang.org/pull/1169 and that bold sans serif proportional text for the code is just... well let's say it's time to replace it. What would be a good code font to use for those? My favourites would be: Menlo, DejaVu Sans Mono, Ubuntu Mono. But don't embed them, just provide a safe fallback, like monospace.
Re: Redesign of dlang.org
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg wrote: Thoughts? Excellent, both for increasing the apparent brand value for newcomers and for reducing frustration of existing users. Minimalistic, modern, professional and consistent look & feel, easy to read and navigate - even at the very first sight at the main site one can instantly find what they're looking for.
Re: We need better documentation for functions with ranges and templates
On Tuesday, 15 December 2015 at 16:12:18 UTC, Chris Wright wrote: On Tue, 15 Dec 2015 09:09:43 +, Adrian Matoga wrote: Fantastic example of why this strategy should be just banned. Just as well I wasn't recommending it as a long-term solution. I was more offering it as additional evidence that template definitions can get a bit large and people have known that this is a problem for documentation for eight years now. "Banned" is a strong term. Perhaps you simply meant it should not be recommended and should not be used in Phobos? Yes, perhaps "strongly discouraged" would be a more appropriate wording. version(StdDdoc) already appears about 40 times in Phobos, sometimes wrapping quite large blocks of declarations. I doubt the maintainability of such setup in the long term.
Re: We need better documentation for functions with ranges and templates
On Tuesday, 15 December 2015 at 01:10:01 UTC, Chris Wright wrote:
This reminds me of the Tango strategy for this kind of thing.
tango.core.Array was arranged like this:
version(TangoDoc) {
/** Documentation comment. */
bool isSameLangth(Range1, Range2)(Range1 r1, Range2 r2) {
return true;
}
} else {
bool isSameLength(Range1, Range2)(Range1 r1, Range2 r2)
if (
isInputRange!Range1 &&
isInputRange!Range2 &&
!isInfinite!Range1 &&
!isInfinite!Range2) {
// actual implementation
}
}
Fantastic example of why this strategy should be just banned. You
need to duplicate the signature in the source, and you are free
to make any mistake that won't be caught by the compiler, such as
the typo in the word 'Length' here. A beginner then copies the
signature and fills in the argument part, and then spends minutes
decrypting error messages or even grepping Phobos source to find
out that the name of the function should be spelled
'isSameLength', as it's quite easy to overlook, especially when
you copy-paste from the official documentation, which you expect
to be correct.
Re: Advent of Code
On Wednesday, 2 December 2015 at 03:50:20 UTC, Charles wrote:
(..)
auto input = "arbitrarily long string of '(' and ')'";
int floor;
foreach(movement; input)
floor += (movement == '(' ? 1 : -1);
writeln(floor);
Speak D to me, please.
stdin.byLine.front.map!(a => a.predSwitch('(', 1, ')', -1,
0)).sum.writeln;
Re: Thought on the 2015H2 Vision Participation Goal
On Sunday, 15 November 2015 at 02:56:35 UTC, Charles wrote: Hi everyone, Just looked at the vision for this half, and I had an idea pop in my head. Before I get to that idea, let me explain what I think might be an issue with it as-is. I've consistently seen D's participation metrics marked by the number of pull requests created and closed, which is great. This gives us input as to how active people are on actually developing the core part of D. Unfortunately it doesn't give us an indication as to what caused this number to increase. Was it new users? Was it people becoming more familiar being more productive? Etc. While I don't doubt participation is correlated to pull request counts, I don't think its a great indicator of new users. Furthermore, I don't know if this can scale. We get small dedicated group capable of taking out 3-5 issues a month each, and where does that leave us? With a lot of issues open probably. How do we fix that? Ask the small dedicated group to take more time out of their, presumably busy, life and fix our problems for us. # So what should we do instead? Why not try and target people who haven't worked on a language previously that are interested in doing so, but don't know where to get started. I definitely fall into this group. I know there's something I could do that would be useful, but I don't know how to find it to get it done. I just wish there was something out there that literally baby stepped me through the entire process. Yeah, I might not be tackling extremely difficult problems right out of the gate, but if there was even 20% of our issues that the only thing holding them up is a lack of someone assigned to them, this could be a huge win for everyone. # What could we do to accomplish this? Here's where I think that reorienting the goal actually makes the goal a lot more manageable. At the cost of efficiency now, what I (and presumably people like me) need are those baby steps. Ideas could include: * A video about setting up their environment from scratch. This is presumably 1 time thing for most users, but honestly one of the easiest ways to get discouraged. If you're on your own for this it instantly feels like you're going to be on your own for all of it. It really shreds any notion of a community working together. Because of the experience this can cause, and the minimal amount of time that's required to do this, it should be a no-brainer. * Flags for issues that are based on expected completion time for someone reasonably competent with D. As a newcomer, I might not know how involved an issue is. E.g. I don't mind spending 1-3 hours this week, but *every* issue looks like it might unravel on me and take a really long time. * Live code reviews where there can be feedback from experts on how to approach things in a D oriented way. The forums work great for getting a quick answer on something, but a lot of times newcomers don't know the correct question to ask. This kind of interaction is also extremely marketable... look at Jonathan Blow with Jai, and he isn't even letting people use it yet. People interested in helping out with this kind of project need to learn somewhere... why not D? TL;DR: Change our participation goal to be more oriented towards force multiplication. I question whether PR activity is a sustainable metric. I generally try to avoid participating in discussions about what could or should be done if I'm not sure I'd be able and willing to dedicate some significant amount of time to actually implement the idea, but [1] has recently been quite successful in bringing a few guys in my team at work from "not knowing anything about kernel programming" to "having an idea where to start if I need to do X", so I decided to mention it. A similar set for D could go from trivial "download the sources and build the compiler" to eventually fixing the real issues from bugzilla. [1] http://eudyptula-challenge.org/
Re: Out for the week
On Thursday, 5 November 2015 at 14:09:46 UTC, nazriel wrote: On Wednesday, 4 November 2015 at 00:31:14 UTC, Andrei Alexandrescu wrote: I'm leaving for http://codedive.pl/en/agenda/ to destroy. Will be out for the week. -- Andrei Andrei destroyed once again with his talk: THREE COOL THINGS ABOUT D [1] Awesome! http://codedive.pl/en/agenda/three-cool-things-about-d/ Regards, Damian Ziemba Hope to see the recording, ehm, sooner rather than later. :) I wasn't fortunate enough to get inside for Andrei's afternoon talks. Btw. Damian, are you still around so we could chat a bit?
Re: Out for the week
On Wednesday, 4 November 2015 at 00:31:14 UTC, Andrei Alexandrescu wrote: I'm leaving for http://codedive.pl/en/agenda/ to destroy. Will be out for the week. -- Andrei Live report: Andrei's talk is excellent, as usual - very instructive and immensely entertaining.
Re: Out for the week
On Wednesday, 4 November 2015 at 00:31:14 UTC, Andrei Alexandrescu wrote: I'm leaving for http://codedive.pl/en/agenda/ to destroy. Will be out for the week. -- Andrei I'll be there too, see you!
Re: I have this game engine...
On Wednesday, 4 November 2015 at 09:14:12 UTC, Manu wrote: On 4 November 2015 at 18:34, Adrian Matoga via Digitalmars-d wrote: On Tuesday, 3 November 2015 at 04:10:57 UTC, Manu wrote: On 3 November 2015 at 11:07, mattcoder via Digitalmars-d wrote: On Sunday, 1 November 2015 at 02:36:16 UTC, Manu wrote: ... Does it support Dreamcast? :P I don't know if you are being serious here but if yes... what's the catch with Dreamcast? I mean this is a Fan thing or what? I'm just a massive nerd, and the Dreamcast was a great console! :P By the way, since it's called fuji, I assume it runs on Atari. ;) Hah! That's really pushing the limits! I did write some little Atari2600 games once... we even did a 2600 demo comp once ;) Terrible machine! There's a chance I've seen that demo. what's its title? I've tried (with success) compiling C for STe with pre-built gcc, I only gave up porting D because I couldn't get my head around these messy patches the Atari gcc port is full of.
Re: I have this game engine...
On Tuesday, 3 November 2015 at 04:10:57 UTC, Manu wrote: On 3 November 2015 at 11:07, mattcoder via Digitalmars-d wrote: On Sunday, 1 November 2015 at 02:36:16 UTC, Manu wrote: ... Does it support Dreamcast? :P I don't know if you are being serious here but if yes... what's the catch with Dreamcast? I mean this is a Fan thing or what? I'm just a massive nerd, and the Dreamcast was a great console! :P By the way, since it's called fuji, I assume it runs on Atari. ;)
Re: Vision
On Wednesday, 21 October 2015 at 20:50:29 UTC, Andrei Alexandrescu wrote: Better late than later. http://wiki.dlang.org/Vision/2015H2_(draft) Destroy. After we make this good I'll rename it and make it official. Andrei Emphasize vibe.d No significant progress. There has been pushback regarding merging vibe.d into the standard distribution. IIRC the idea to package dub with DMD received a bit more favorable response, though. And having dub installed it's now just "dub init -t vibe.d" to actually use vibe.d as well.
Re: [OT] LLVM Community Code of Conduct
On Friday, 16 October 2015 at 14:36:55 UTC, Laeeth Isharc wrote: On Friday, 16 October 2015 at 10:25:07 UTC, Chris wrote: On Friday, 16 October 2015 at 08:29:18 UTC, Kagamin wrote: On Thursday, 15 October 2015 at 09:09:22 UTC, Chris wrote: [...] Do people have the same impression from generic code in Go? It doesn't matter. It _feels_ neat, tidy and finished. We're not talking about engineering, we're talking about subjective human impressions. Apart from that, I think the fact that D is still not fit for mobile platforms is a huge drawback. Loads of people want apps, loads of people have some sort of smart phone, tablet or whatever. Sometimes I think that we're getting sucked in by the quick sand of language specs, pointers, GC etc. while important issues like targeting mobile platforms are second class citizens. Nim for example targeted mobile platforms right from the start. So did Go. I cannot recommend D wholeheartedly unless it also works on ARM at the click of a button. Please correct me if I'm wrong here, but mobile is not yet 100%. Fwiw I think it's okay on ARM linux. I have compiled and run small programs on my phone (a oneplusone). Thanks to dicebot you can just install with yaourt. That's not what you meant of course, and Android ARM seems a little further away. But in case anyone else sees this and doesn't bother trying. I'm running a vibe.d app on Raspberry Pi without any trouble. Even something like 3 years ago I rebuilt some non-trivial app (an Atari XE disk drive emulator) with GDC for RPi and it compiled and worked fine out of the box. So it seems it's just mobile OS support that is missing.
Re: D 2015/2016 Vision?
On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote:
For the THIRD time, I'll post my example:
class Texture { }
class Texture2D : Texture {
this() { /* load texture... */ }
~this { /* free texture */ } // OOPS, when, if ever,
will this be called?
}
Now, does this really seem like a realistic use case to you?
using(Texture tex = new Texture2D) {
// ...
}
It does, entirely. I usually translate it to D this way:
{
Texture tex = new Texture2D;
scope(exit) tex.destroy;
// ...
}
Of course, nothing protects you from passing the reference
outside the scope and having a dangling ref after the scope ends,
so it's by no means safe, but the destruction is deterministic.
Re: iterate over a directory, dealing with permission errors
On Friday, 18 September 2015 at 11:54:32 UTC, Robert burner
Schadek wrote:
http://dlang.org/phobos/std_exception.html#.handle
foreach(file; dirEntries(args[1], SpanMode.depth)
.handle!(Exception, RangePrimitive.front, (e, r) =>
DirEntry())) {
writeln(file.name);
}
change Exception to the Exception Type to handle and select the
throwing range primitive (RangePrimitive). Then just supply a
delegate that does the actual handling.
This will not break any range chain!
Cool, I wish I had this idea back in 2012.
Re: iterate over a directory, dealing with permission errors
On Friday, 18 September 2015 at 11:35:45 UTC, John Colvin wrote:
Posting here instead of learn because I think it uncovers a
design flaw
void main(string[] args)
{
import std.file : dirEntries, SpanMode;
import std.stdio : writeln;
foreach(file; dirEntries(args[1], SpanMode.depth))
writeln(file.name);
}
Modify this program such that it will print " access
denied" instead of crashing with an exception whenever it hits
a permissions problem. Remember that you might not even have
permission to read the directory given in args[1]. Remember
that access permissions can change at any time.
It can be done, but it is seriously ugly.
https://github.com/D-Programming-Language/phobos/pull/931
I had to move to some urgent stuff instead of improving the PR
and later I forgot about it. The discussion points out what not
to do when solving this issue. :)
Re: Runtime error in code on main page
On Tuesday, 25 August 2015 at 08:40:48 UTC, BBasile wrote: please, stop spamming about that. http://forum.dlang.org/thread/qslurvxijgmfuqptc...@forum.dlang.org and file an issue on the bug tracker. God damnit. Jesus Christ, I'm just a passerby who noticed something in passing; sorry I didn't have the incentive to file a bug report.
Runtime error in code on main page
The "Get your local weather report" sample code on the main page generates the following error: /d683/f748.d(32): Error: undefined identifier centerJustifier Someone might want to address that.
Re: Working with pdf
On Thursday, 30 July 2015 at 11:19:48 UTC, Kingsley wrote: Hi Can anyone recommend any ways of pdf creation using D. I am generating an HTML and JavaScript page but I would like it in pdf format as well. Another indirect solution would be to generate PostScript (there's no existing lib in D that I know of, but I did it in plain C++ some time ago and it wasn't that unpleasant) and then convert it using something like ps2pdf.
Re: force inline/not-inline
On Tuesday, 28 July 2015 at 02:05:56 UTC, Daniel Murphy wrote: "tcak" wrote in message news:psflpqqpsukpfgpzh...@forum.dlang.org... Why not like pragma(inline, [try | force | no]) ? Walter liked the boolean version, which is certainly better than nothing. I regret I missed this pull request and the chance to vote for "always"/"never" proposed by yebblies, which hit the right neurons in reader's brain instantly, unlike the generic true/false.
Re: dmd 2.068, 2.069, 2.0xx Evil Plan going forward
On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote: 2.069 - translate to D. No new features, no refactoring. Only regression fixes and what's already in HEAD. This should give us a solid baseline. It also means that open PRs that address other issues will not be pulled for 2.069. Perhaps we should name this 2.100, to signify such a milestone. This may also be the best moment to start keeping frontend versions among DMD/GDC/LDC synchronized, forever.
Re: wrong code: code with undeclared variables compiles (cf b/14813)
On Monday, 20 July 2015 at 07:01:34 UTC, Timothee Cour wrote:
reposting https://issues.dlang.org/show_bug.cgi?id=14813 here
as it seems quite weird:
Try this and think again:
import std.stdio;
void main()
{
alias A = void delegate(int);
//WTF?
A temp1 = (some_inexistant_field) {
writeln(typeof(some_inexistant_field).stringof); };
temp1(42);
//WTF?
A temp2 = delegate(some_inexistant_field) { writeln(typeof
(some_inexistant_field).stringof); };
temp2(1337);
alias A2 = void delegate(int,double);
//WTF?
A2 temp3 = (some_inexistant_field,sadfasfd) {
writeln(typeof(some_inexistant_field).stringof, " ",
typeof(sadfasfd).stringof); };
temp3(42, 3.14);
}
Re: Why aren't you using D at work?
On Wednesday, 15 July 2015 at 16:27:56 UTC, Piotr Szturmaj wrote: By the way.. does anyone know if Sociomantic accepts remote D jobs? I guess it's best to ask them directly. BTW, I was hoping maybe for a software division in Warsaw office.
Re: Wait, what? What is AliasSeq?
On Wednesday, 15 July 2015 at 21:44:37 UTC, Timon Gehr wrote: It should instead be acknowledged that there /should/ be no difference in what three things can be passed to X(T...) and X(alias a, alias b, alias c). The X(T...) if(T.length==k) pattern is ridiculous. +1
Re: Wait, what? What is AliasSeq?
On Thursday, 16 July 2015 at 05:51:01 UTC, Mike wrote: "A template parameter pack is a template parameter that accepts zero or more template arguments (non-types, types, or templates). A function parameter pack is a function parameter that accepts zero or more function arguments. A template with at least one parameter pack is called a variadic template." Sound familiar? I propose simply "Pack". + 1
Re: Let's bikeshed std.experimental.testing assertions/checks/whatchamacallits
On Tuesday, 30 June 2015 at 11:14:55 UTC, Atila Neves wrote:
On Tuesday, 30 June 2015 at 08:38:44 UTC, Adrian Matoga wrote:
On Tuesday, 30 June 2015 at 08:06:37 UTC, Atila Neves wrote:
I'm not convinced composability brings anything to the table
except for editor dot-completion. I don't like the verbosity
of what's there now, but my prefererred syntax doesn't work
except for the ubiquitous check for equality (`should ==`).
Could you give some examples of your preferred syntax and why
it doesn't work?
`foo.should == "bar";` works. Nothing else does (and in fact in
retrospect it's surprising that == does) because they do
nothing by themselves. `foo.should != bar` is the same as
`!(foo == bar)`, which on a statement by itself is nonsensical
and rejected by the compiler with "has no effect in expression"
error. You could write something like `if(foo.should != "bar")
{}` and that compiles fine but it's super hacky and ugly.
Atila
Thanks. I took a second look and now it looks obvious.
I'd vote for Dicebot's bikeshed design (2b). It's short and looks
equally readable for every possible test.
Another hackish possibility could be to change the behavior of
assert so that it also passes the stringified expression to
_d_assert* and _d_unittest* in druntime.
Re: Let's bikeshed std.experimental.testing assertions/checks/whatchamacallits
On Tuesday, 30 June 2015 at 08:06:37 UTC, Atila Neves wrote: I'm not convinced composability brings anything to the table except for editor dot-completion. I don't like the verbosity of what's there now, but my prefererred syntax doesn't work except for the ubiquitous check for equality (`should ==`). Could you give some examples of your preferred syntax and why it doesn't work?
Re: Suggested enhancement: New basic datatype: 'dec'.
On Thursday, 25 June 2015 at 09:24:28 UTC, DLearner wrote: A signed decimal datatype to support writing userland accounting programs (major business application area), without loss of accuracy (including losses caused by not all 'decimal decimals' having exact 'binary decimal' representation). Syntax: dec(a,b) foo; Where a is an integer 1<=a<=99 (total no of digits, including any decimal digits). b is also an integer 0 <= b <= a (no. of decimal digits); b = 0 implies b can be omitted e.g. 'dec(4,0) foo;' can also be written 'dec(4) foo;'. Basic arithmetic supported. Normal assignment rule is truncation/padding, but a 'round(d)' function to round to d decimal places provided. Also provide a formatting function to convert dec type to printable character string. Not very interesting from a theoretical viewpoint (just COBOL or PL/I datatype), but (I think) of practical value in encouraging D adoption. Decimal data type is something that can and should be done in library, not in the language itself. There is already a proposed implementation, you too can review it: http://wiki.dlang.org/Review_Queue https://github.com/andersonpd/eris/tree/master/decimal
Re: Future(s) for D.
On Wednesday, 24 June 2015 at 09:21:46 UTC, Martin Drašar wrote: Then again, there can just be an obligation to post this job add as a requirement for getting grant money for a project (many EU projects have this), but you have your own person in mind for the job, so you fit the add for her. Confirmed, I've seen quite a few such ads for research positions in computer architecture written specifically for me or my colleagues.
Re: New names - 2.068 roundup
On Wednesday, 24 June 2015 at 01:04:01 UTC, Adam D. Ruppe wrote: [...] Moreover, with this, some old code will *automatically* be upgraded to laziness without needing to change at all too. Tell me that doesn't at least tempt you! +1
Re: D could catch this wave: web assembly
On Thursday, 18 June 2015 at 08:07:47 UTC, Rikki Cattermole wrote: Would be pretty awesome to write both client side and server in D using it. I just found about WebAssembly while having lunch and that was exactly my thought.
Re: std.container: fork in the road
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu wrote: 1. Just keep the current spec and deal with it. Some containers are and will remain garbage collected because they started as such. Add new containers that are better alongside them. 2. Do break compatibility of containers, mainly by taking advantage of them being under-documented. In a way we wouldn't break much because not much has been specified. There are, however, parts where we'd need to change specification. 3. Leave std.container alone and move forward with std.experimental.collection. I am confident the language and its endorsed idioms have reached enough maturity to not make this addition into a regular event. 2. std.container has always looked like a draft, discouraging from actually using it for something serious.
Re: Tip: unittest-only artifacts should not be version(unittest) if used across modules
On Friday, 12 June 2015 at 19:20:41 UTC, Jeremy Powers wrote: On Thu, Jun 11, 2015 at 11:09 PM, Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com> wrote: Just ran into this with Phobos: https://github.com/D-Programming-Language/phobos/pull/3403 If unittest-only artifacts are not constrained to just unittest builds, does this not make them open to be not unittest-only? That is to say, if there is a method or whatever that is just for tests, without marking it 'version(unittest)' how do you ensure it is not actually used in the regular, shipped code? Not sure best way to solve the across-module problem and still keep test code restricted to tests... maybe instead put the shared test code in its own module, and import with version(unittest). I encountered a similar problem a few days ago and what Jeremy proposes seems the most reasonable solution for me.
Re: RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)
On Thursday, 11 June 2015 at 00:26:39 UTC, Mike wrote: On Wednesday, 10 June 2015 at 10:06:19 UTC, Adrian Matoga wrote: 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. I haven't had a pay-as-you-go experience with RTTI. In fact TypeInfo has become my mortal enemy [1]. I submitted a bug report for now [2]. [1] TypeInfo not garbage collected (discussion) - http://forum.dlang.org/post/quemhwpgijwmqtpxu...@forum.dlang.org [2] TypeInfo not garbage collected (bug report) - http://bugzilla.gdcproject.org/show_bug.cgi?id=184 There is an implementation of an -fno-rtti switch [3], but unfortunately, I have found it compromises on a few things (slicing, postblit, and maybe others). I think the best way forward is to move TypeInfo to the runtime as described in [4]. I'm currently working on an initial pull request for it, but I have to admit that I don't know much about what I'm doing in the compiler and am struggling with it. But I'm afraid if I don't do it, it won't happen. I can't even continue with my work without it. [3] -fno-rtti implementation - https://github.com/D-Programming-GDC/GDC/pull/100 [4] Move TypeInfo to the D Runtime - https://issues.dlang.org/show_bug.cgi?id=12270 If there's anything I can help with, let me know. My experience with GDC is close to non-existent (I managed to make some one-line hacks to make it compile for AVR or to show the sizes of TypeInfos, but that was pretty easy), and I didn't even bother to build LDC, but I want to write stuff for STMs in D so I'm motivated to learn by doing. I'll try to push this work on github later this week. I look forward to seeing it. It's encouraging to see more interest in using D for this Domain. Here it is: https://github.com/epi/dirt It's just a playground where I try adding different features by trial and error, so it's very far from being as clean and organized as your projects. I wouldn't even start without your and Adam Ruppe's work, so thank you for that. Apart from first steps towards formatted print and exception support I mentioned earlier, there's a try on running static constructors (which is most likely broken anyway) in the correct order. The machinery used to make it work wastes some text and data memory to do it in run time, but since we're linking everything statically in the end, I wonder if the linker could be forced to put it all together instead.
Re: std.(experimental.)logger voting manager wanted
On Saturday, 13 June 2015 at 08:17:24 UTC, extrawurst wrote:
I found one issue using it the last day: It does not seem to be
formatting arguments in the XYZf() methods quite the same as
writefln. for example an exception object ist not automatically
converted to call its .toString() when passing errorf("err:
%s",e);
Is that intended or a bug ?
The following must definitely be a bug:
import std.stdio;
import std.experimental.logger;
void main()
{
writefln("{%04d}", 15);
infof("{%04d}", 15);
writefln("{%08d}", 42);
infof("{%08d}", 42);
}
Result (Linux x86_64, dmd 2.067.1):
$ rdmd logg.d
{0015}
2015-06-13T10:29:25.014:logg.d:main:7 {00015}
{0042}
2015-06-13T10:29:25.014:logg.d:main:9 {042}
Re: You too can work on D for iOS
On Friday, 12 June 2015 at 07:36:51 UTC, Paulo Pinto wrote: The minimum wage in Portugal is around 400€ after taxes, with around 1000€ for many university degrees. You can guess how many go out and buy a Mac. -- Paulo I remember I saw almost every student at IST with a Mac, and when everyone started to talk about the crisis, people were like "uhm, well, we can't now afford to replace our Macs with new ones every year, only every other year maybe".
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: Bottom line re GC in D
Thanks Mike... Looking into that.
Re: Bottom line re GC in D
On Wednesday, 9 July 2014 at 11:44:31 UTC, Marc Schütz wrote: This will not happen even in one hundred years. So if that's what you want, you will never be satisfied by D GC. Uhmm... what makes you think so? Good question actually...
Re: Bottom line re GC in D
Have you written enough D code where you have seen the current GC is not good enough for you? How much good has to be the D GC for you to use it? Bye, bearophile Hi, As I said at the start, I have been away a while but I wrote a fair amount of code in D about a year ago to test the waters. From my experience of those tests, I mainly targeted the GC and if I remember well, I had written code that, based on command line switches, specified if the incorporated GC is to be used for memory allocation/deallocation or whether memory is done entirely manually (I managed this through some posts in the forum where community members instructed me how to achieve this). From my limited tests, the ones which used manual memory management ran in roughly half the time; the GC ones took almost double the time and in some cases more than that. I don't have the code at hand (I might need to dig it out), but I certainly can vouch for a significant discrepancy in performance between the GC versions and manual versions. So yes, this is a significant issue (i.e. the current GC is not good enough for me and I cannot overlook it). As for your second question (i.e. how good the GC needs to be for me), I would probably be satisfied with a GC that matches the Java one (used in conjunction with D's ability to take over memory management completely in the critical parts where needed) - but admittedly, I don't know the implications in achieving that within D's memory model, etc. I am embarking on a start-up pretty soon and I have been looking at possible languages/frameworks to use; I've looked at Go in detail, had a cursory look (so far) at Rust and have also used to a fair degree. D is the most natural fit for me and my team coming from a mainly C++ and Java background, but I would really like to make an informed decision vis-a-vis the GC implications. Thanks for your help. - Adrian.
Re: Bottom line re GC in D
Hi folks, Thank you all for your very informative answers - much appreciated. Great to see such an active community there. To summarise what you said: + No, the GC can't be taken out, but with careful attention one can - relatively easily - bypass it. This can come at a price of some great features of the language, but then if the requirement is to not use the GC one can do so. This is perhaps flexibility no? + The current GC will be improved, but it's taking some time for that to happen - which is a shame, for if the GC is stumbling block for some people (such as myself), an inefficient/weak one does not help in convincing GC sceptics to accept it. + The @nogc stuff and work you mentioned with the standard library is also encouraging. Now, going forward, is there a comprehensive and precise set of instructions available that one could follow in order to write D programs entirely devoid of the GC? That would be most helpful if available. Once again, thank you all. - Adrian.
Bottom line re GC in D
Hi all, I know there's been quite some discussion about the GC in D, but I've been busy doing other things and haven't been following that closely. So I'd appreciate it if someone could fill me in about proceedings/decisions in this regard... + Has the GC been dropped? + If not, can it be disabled entirely/completely? D has always greatly impressed me, but I need a systems language without garbage collection; has D become that now? Thanks in advance for any responses. Adrian.
Re: Disable GC entirely
"Minas Mina" Wrote in message: > I agree that language support for disabling the GC should exist. > D, as I understand, is targeting C++ programmers (primarily). > Those people are concerned about performance. If D as a systems > programming language, can't deliver that, they aren't going to > use it just because it has better templates (to name something). > very well put. I want to be able to write programs as fast as C++ ones... in D. D is it for me... I just need not be hampered by a GC - particularly when its implementation is somewhat lagging. Android NewsGroup Reader http://www.piaohong.tk/newsgroup
Re: Disable GC entirely
> That's the critical missing piece of the puzzle. In effect we > need to be able to use a sub-set of D that is 100% GC free. That's it actually - spot on. If only we could write 100% GC free D code... that would be it. Android NewsGroup Reader http://www.piaohong.tk/newsgroup
