Re: Array of byLineCopy ranges behaves as they are byLine
On Monday, 11 March 2019 at 17:04:56 UTC, ag0aep6g wrote:
To avoid the re-evaluation, assign `ranges[0]` to a variable
before using it:
auto lines = ranges[0];
writeln(lines.front);
writeln(lines.front);
writeln(lines.front);
That should print the same line three times.
Ah yes, I forget about laziness of `map`. BTW, I have found other
solution, which is more fit to my initial intention.
```d
ReturnType!(std.stdio.File.byLineCopy!(char, immutable(char)))[]
ranges;
foreach(filename; args[1 .. $])
{
ranges ~= File(filename, "r").byLineCopy;
}
```
Array of byLineCopy ranges behaves as they are byLine
Let assume I have multiple files (like "file1", "file2" and so
on). I need to iterate them simultaneously with some logic. I
have tried to create random access range of ranges, however, it
behaves not as expected. Let "file1" is
```
1
2
3
4
```
Then this code
```d
File[] files;
foreach(filename; args[1 .. $])
{
files ~= File(filename, "r");
}
auto ranges = files.map!(a => a.byLineCopy);
writeln(ranges[0].front);
writeln(ranges[0].front);
writeln(ranges[0].front);
```
produces
```
1
2
3
```
Even despite I'm using `byLineCopy`.
However, this code
```d
File[] files;
foreach(filename; args[1 .. $])
{
files ~= File(filename, "r");
}
auto range = files[0].byLineCopy;
writeln(range.front);
writeln(range.front);
writeln(range.front);
```
produses
```
1
1
1
```
as expected.
What I'm doing wrong with `map`? Or is this a bug?
dmd v2.085.0
P.S. I know that I can call `dup` on `front` and I'm going to do
so as workaround. However, I'm curious why current situation is
taking place.
Re: Walter and Andrei and community relationship management
On Thursday, 6 April 2017 at 17:56:03 UTC, bachmeier wrote: On Thursday, 6 April 2017 at 13:55:43 UTC, Olivier FAURE wrote: I don't want to make any assumptions, and I do respect Walter for consistently taking on a role that means that people keep criticizing his choices whatever he does, but his approach to dealing with the community is undeniably flawed, and seems to be breeding a lot of frustration and resentment. IMO the source of the problem is that Walter and Andrei have freedom to make any language changes they want, without even consulting the community, while everyone else has to put a lot of time into a formal proposal with nearly a 100% chance that it will be denied because of [insert your favorite reason]. The design of the language is done in something of a corporate fashion, and that leads to frustrated posts.* I agree. I was never personally affected by this (because I haven't contributed to the language or library), but I have heard enough rumours and read enough posts, that see this as problematic (and even frustrated although me not personally touched). The problem exists probably because D community some years ago reached the scale when only interpersonal non-formal communication doesn't work for managing the development process. I know that Walter is oppose to any code of conduct, but it is really time for this. The formalization of processes gives transparency and objectivity, very high needed values especially for volunteer community. A depersonification could also go by hand (but not necessary, having a written rule where e.g. Walter personally designated to specific role and exceptions, better that not have rule at all). The DIP process is very good step in this way, but much more required. E.g. I have heard so much about miserable commit messages of one of pillar developers, that it would be funny if it wouldn't be so sad. I hope that D community find its good way to interoperate and hence survive. Alaksiej Stankievič
Re: Proposal 2: Exceptions and @nogc
On Sunday, 09 April 2017 at 23:14:08 UTC, Jack Stoufer wrote: You're missing the forrest for the trees. D needs a general solution to the problem of GC code in Phobos. This >tackles one specific area via special case but leaves every other GC allocation in Phobos, with no way to make >it @safe @nogc. These will either require the holistic approach eventually or more special cases. On Tuesday, 11 April 2017 at 11:39:20 UTC, rjframe wrote: I have no problem with this specific change, but this method of solving problems is going to turn D into a horrible language with all kinds of weird edge cases. I left Python for D mostly because the language was becoming one hack built on top of another; it would be nice if D could avoid that path. The occasional kludge may be necessary, but it shouldn't be normal or the first thought. --Ryan I'm personally belongs to the camp of perfectionists and holists. But there is bitter experience I want to share, that to be too purist with such approach just make unable things to happen. "Release early, release often" isn't just a good words, but real need, because of lack of early feedback your "perfect" solution just "SUDDENLY" may not match real use cases, and you don't have use cases before USE cases :) So if something going to happen and solve bunch of problem it should be done (in such way that not prevent more general holistic solution to be gone into life at some point). The real issue is only bake transitional process in such way that it addresses the problems of majority. So what could be done: 1. Implement this feature; but apply it only if special compiler flag is specified (the issue I see for this particular feature, that you should have versioned function declaration, IIRC there is no possibility to version of an attribute), emit all warnings, that may you current code clashes with upcoming feature 2. Introduce new flag that disable this feature and remove previous flag for enabling (from now it would be enabled by default), make the warnings errors. 3. Remove disabling flag. (All this describes situation if feature is accepted _as is_ by language users). Furthermore it seems to me that D need something like official binary nightmare releases. It introduces new features in the manner I have described, but also have a flag like `-disable-all-fresh-feature` which affect all features at stage 2, for those of us who need industrial compilation. This "nightmare releases" require however much more frequent major release cycle (like each 2-3 months), and that isn't bad _per se_.
Re: All function attributes possible with "@"?
On Wednesday, 14 December 2016 at 12:00:04 UTC, ketmar wrote: On Wednesday, 14 December 2016 at 09:51:00 UTC, Joseph Rushton Wakeling wrote: On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M Davis wrote: I say that when dealing with the built-in attributes, just treat @ like another letter in the keyword, learn it, and move on. **Applause** This is such a small thing and it is no problem at all to get used to. Much better to focus on things that can really make a difference. exactly the kind of logic that made c++. ... "just get used to that small thing" is a big thing that ruins D. +1
Re: All function attributes possible with "@"?
On Wednesday, 14 December 2016 at 03:49:23 UTC, Jonathan M Davis
wrote:
On Tuesday, 13 December 2016 at 22:40:47 UTC, 01010100b wrote:
The _only_ way to eliminate all of the inconsistencies with @
is to get rid of it from everywhere but UDAs, and turn all of
those built-in attributes into full-blown keywords, and we're
simply not going to do that. Any other solution is just moving
the inconsistencies around.
Almost. We have other very promising options: make them
context-keyword (this possibility already one of considerable
solution for "body" DIP). If we introduce context-keyword then
language designer are freed to add any new language defined
attributes, which will be not clashed with user defined
attributes, and OTOH not introduce full-blown keyword which clash
with other user symbol. But as preliminary work we need probably
to favour one style of context (e.g. all attributes appears after
function declaration not before, there is also (possible
solvable) problem how to interpret no-one function declaration
`pure:` and `pure{}`).
Probably we can go even further: split the whole set of keywords
into 3 subsets: full-blown keyword (like `if`, `while` etc,
probably it also time to restyle `traits`), context-keywords
(like mentioned attribution, probably even `private`, `public`
etc can be made context-keyword, and even further `const`,
`immutable` etc) but with very stric and i/e quick parse-able
context, and intrinsic types (`int`, `ulong` etc, because some of
them especially `real` should be made platform specific) swhich
almost full-blown keyword, with only point that you not
guaranteed have all of them on your platform
Re: DConf 2017: Bigger, Badder, and Berliner! Call for Submissions now open
On Monday, 14 November 2016 at 19:49:26 UTC, Andrei Alexandrescu wrote: Please join us at DConf 2017, the conference of the D programming language in Berlin, Germany, May 4-6 2017. http://dconf.org/2017/index.html Great!
Re: Argumnentation against external function operator overloading is unconvincing
On Thursday, 22 September 2016 at 08:58:54 UTC, HaraldZealot wrote: So let's vote for the following sentence: "It would be good to have an operator overloading even without support in generic function" Yes
Re: Argumnentation against external function operator overloading is unconvincing
On Thursday, 22 September 2016 at 08:53:26 UTC, HaraldZealot wrote: OK, it seems to me it's time to investigate a community opinion. So let's vote for the following sentence: "It would be good to have an operator overloading even without support in generic function"
Re: Argumnentation against external function operator overloading is unconvincing
On Thursday, 22 September 2016 at 07:14:52 UTC, H. S. Teoh wrote: It's not so simple. The UFCS operator overload could be declared in a different module from the type itself. Then there is no guarantee that it will be found. Multiple calls to the same template function with the same argument types may result in different semantics, depending on what was imported. ... T I mean (in terms of your example) that in `main` before instantiate an `algorithm` we parse all symbols visible at this point from `main`, select all possible symbols which can be called with `UserType` (including templates, meh o_O), make the set union for the such table for the rest templates params, and give this symbol table the `algorithm`. But yes this creates problem that in different module we can have different instantiation :( Probably with other radical approach (see bellow *) for generic we can solve this, but this just destroy true templates (from which we benefits now) and provide something like Java-like solution :( * radical approach for generic: each generic function creates a pseudo parameter for function pointers on the base of signature of function used in the body of generic. The caller of generic just fill this pseudo parameters with real function visible for caller at call-point.
Re: Argumnentation against external function operator overloading is unconvincing
On Thursday, 22 September 2016 at 05:38:53 UTC, HaraldZealot wrote: And problem with generic code solve independently for all UFCS functions including operators. Unfortunately I don't know compiler and all related stuff internally (time to change this ;) ), but it seems to me there is a way to solve problem with UFCS and generic code without breakage of module encapsulation. If understand correctly when we instantiate template with struct/class we pass to template some kind of "static signature of type" (if I may it call so). With the static signature of type I mean all member function of class or struct. If we instead of this before instantiate any type (including POD) create "dynamic signature of type" which include all visible at the moment of call function and templates for this type.
Re: Argumnentation against external function operator overloading is unconvincing
On Wednesday, 21 September 2016 at 21:14:15 UTC, H. S. Teoh wrote: Thank you both, I see now. So it seems to be essential point. But because we already have the same problem with UFCS, I don't see why we should prohibit external overloading of operator, it is just inequality (in political sense) for operators :) In any case we at least should change rationale, because current three points are have nothing with real problem and shouldn't be obstacle. But probably the best solution is implementing external operator overloading, just to omit special case. And problem with generic code solve independently for all UFCS functions including operators.
Re: Argumnentation against external function operator overloading is unconvincing
On Wednesday, 21 September 2016 at 19:01:40 UTC, Timon Gehr wrote: Basically, the rationale is: external operators cannot be used in generic code that does not import the module defining the operators. Could you give some elaborate example, for now I can't imagine what your mean.
Argumnentation against external function operator overloading is unconvincing
In current D, overloading operator like "+" with external
function is prohibited. There is the rationale [1] (see second
paragraph).
BUT this rationale is totally UNCONVINCING. I can say that resume
of rationale is: "it is impossible because it brakes some C++
patterns and behaviour". Further I will try to demonstrate such
resume.
Let start with an example where external operator overloading can
be useful. Imagine, we want to create some lazy matrix algebra,
where all operation return new object of corresponding to
operation subtype. E.g. `transpose` returns `TransposedMatrix`,
where `opIndex` just call `opIndex` of internally stored matrix
with switched order of indices, `plus` returns `MatrixSum`, where
`opIndex` just calculated the sum of two corresponding elements
of stored matrices and so on. Of course we want that any
resulting subtypes can interact with each other, so we require
common "denominator". There are two ways compile-time duck-typing
with template bloating, or common interface (yeah, with garbage
collection in the simplest implementation), but the last allows
us to have some run-time parameters. So regard common interface
approach: our interface should be minimal as possible, for our
purposes having `rows`, `columns` and `opIndex` seems to be
sufficient.
OK, we have:
```d
Matrix plus(Matrix A, Matrix B)
{
final class MatrixSum : Matrix
{...}
...
return new MatrixSum(A, B);
}
...
C=plus(A, B);
```
(Or even `C=A.plus(B)` because of UFCS). And this works perfect.
If we want some sugar like `C=A+B` we are in trouble. We can
create function `Matrix opBinary(string op)(Matrix A, Matrix B)
if(op == "+")`, it even can be called with full name, but not
with "+" operator, because now compiler just doesn't look for
external function as overload for operator. If we want have this
as member we should ad opBinary to our interface, what leads to
some new trouble: now each type should have opBinary, but how we
should implement this for example for `TransposedMatrix` or even
more interesting (because of kind of type recursion) how we
should implement it for `MatrixSum`. OK, me and Mathias Lang have
found workaround for my particular case we should implement (and
probably make `final`) opBinary for `Matrix` interface, which in
its turn calls function `plus` we already described. But its
create lines of code for nothing, because operators are
considered as too exceptional.
Let us return to rationale.
First point is "Operator overloading can only be done with an
argument as an object". Why??? it seems to come from "C++ mind",
before UFCS was implemented in language. If we have `1.to!string`
and `A.plus(B)` working, what wrong with `A+B` or `2*B` (where A
and B matrices). Moreover for case like `2*B` (multiplication by
scalar) we should have a bit ugly `opBinaryRight(string
op)(double scalar)` as member function. It isn't convinced.
Second point is "Operator overloads USUALLY need access to
private members of a class". It has nothing common with operator,
it is only demonstrate our C++ behave to work with private
members in operator. But having access to private member isn't
necessary for operator to work. In my example `plus` function
uses only public API of my classes, it can be done such way in
many, many cases. And also often this external function would be
placed in the same module, so it is already have "friend" in such
case. If external function in external module want to have access
to private API, it is only a sign of bad design, and should be a
problem of particular programmer how to rework the design, not
case for compiler to step in. It isn't convinced.
Third point is totally unnecessary because we don't need access
to private members.
So, no one of point convinces me.
What can really can convince me that rationale like: "if we do so
total parsing algorithm will be corrupted, and we can't use D
any-more", or at least "with that feature compiler becomes 100
times slower".
So if someone has real rationale not to have operator overloading
as external function I'm curios to arguments.
[1] http://dlang.org/rationale.html
Re: Andrei's list of barriers to D adoption
On Monday, 6 June 2016 at 09:16:45 UTC, Walter Bright wrote: Paying attention to our existing users is a much more reliable source of information. +1000
Re: mir.random - my GSoC project
On Thursday, 2 June 2016 at 10:56:36 UTC, Martin Nowak wrote:
On 04/23/2016 04:17 PM, Seb wrote:
This project is about adding non-uniform random generators to
mir and hopefully eventually to Phobos.
I just happen to need a gaussian random number generator right
now. Is there already some WIP code, or would you have an
intermediate recommendation?
Is good workaround you can use:
```d
real normalrnd(real mu, real sigma)
{
import std.random: uniform;
import std.mathspecial: normalDistributionInverse;
return mu + sigma * normalDistributionInverse(uniform(0.0L,
1.0L));
}
```
Re: Researcher question – what's the point of semicolons and curly braces?
On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote: Hi all, I'm a social scientist and I'm preparing some studies on the effects of programming language syntax on learning, motivation to pursue programming, as well as any disproportionate effects that PL syntax has on the appeal of programming to women (more on the latter in a separate post). [...] And D-specific syntax for range-based algorithms often also clearer in multi-line form: ```d stdin .byLineCopy .array .sort!((a, b) => a > b) // descending order .each!writeln; ``` (current snapshot from main page ;) )
Re: Found on twitter: a long comparison of C with D, in Russian
On Wednesday, 10 February 2016 at 09:49:07 UTC, Joakim wrote: From habrahabr.ru, a kind of Russian Slashdot: https://habrahabr.ru/post/276227/ I used Chrome's auto-translate to read it, he mentions some D features I'd never seen before. If you are interested in D topic on the habrahabr these articles from deviator seem more interesting and original: https://habrahabr.ru/post/274619/ https://habrahabr.ru/post/261349/ https://habrahabr.ru/post/261641/ https://habrahabr.ru/post/261201/
Re: DIP 88: Simple form of named parameters
On Saturday, 23 January 2016 at 14:19:03 UTC, Jacob Carlborg
wrote:
This is mostly to prevent ugly hacks like Flag [1].
http://wiki.dlang.org/DIP88
[1] https://dlang.org/phobos/std_typecons.html#.Flag
Why not simply allow programmer to declare auto variable at
function call side like in `foreach`?
E.g.
```d
void foo(int width, int height){...} //function definition
foo(width = 2, height = 3); // function call
```
Re: DIP 88: Simple form of named parameters
On Monday, 25 January 2016 at 14:35:09 UTC, arturg wrote:
On Monday, 25 January 2016 at 13:40:18 UTC, HaraldZealot wrote:
the equal sign cant be used because D behaves like this
int width, height;
foo(width = 5, height = 10); // 5
// 10
width.writeln; // 5
height.writeln; // 10
void foo(int width, int height)
{
width.writeln;
height.writeln;
}
You didn't pay attention, that in my proposal `foo(width = 5,
height = 10);` width and height were declared in place of use,
and scope is only this call
Re: Referencer
On Friday, 20 November 2015 at 19:53:23 UTC, HaraldZealot wrote: On Friday, 20 November 2015 at 18:48:51 UTC, Alex Parrill wrote: On Friday, 20 November 2015 at 18:23:57 UTC, HaraldZealot wrote: You say ranges are pass-by-value, but that's not entirely true. Ranges themselves can be classes, or be made references via std.range.refRange. Range elements can be made lvalues by using ref functions [1]. Possible refRange is what I was looking for. Thanks. Unfortunately current RefRange and refRange implementation doesn't work with out-range :( Ridiculous, because reference semantic for out-range even is more important. So I'm found myself at fork point which from my next work for community is better: * add support for out range in `RefRange` * or implement further my universal referencer?
Re: Referencer
On Monday, 23 November 2015 at 12:09:13 UTC, Jonathan M Davis wrote: On Monday, 23 November 2015 at 11:31:32 UTC, HaraldZealot wrote: RefRange is not intended to work with output ranges, and output ranges are very different beasts from input ranges, so any kind of reference type wrapper for output ranges should be a separate construct. That being said, I'd be inclined to argue that anything taking an output range should always take it by ref, precisely because copying an output range almost never results in the correct semantics. So, we should probably make it a general policy that anything accepting an output range should accept it by ref. So, you see that to open a PR about changes _by value_ to _by ref_ semantic for all functions operate with out range (especially for copy) is better way? But this breaks existing API... Certainly, I would think that your Referencer type is going in the wrong direction, because it's declaring a bunch of functions that have nothing to do with output ranges. I see my referencer as universal wrapper to any value-like stuff (e.g. structs or even simple POD variable), not only for out ranges (or input ranges). But possibly it is to general (and so not perfect) solution.
Re: Referencer
On Monday, 23 November 2015 at 15:35:32 UTC, Jonathan M Davis wrote: Well, if all you want is to get a reference type out of a value type, then putting it on the heap and using a pointer to it would be a solution. Using RefCounted would be another, and I would think that it would be similar to what you're trying to do, since what you're trying to do sounds like it would be something like a RefCounted that doesn't actually involve reference counting. Hmm, interesting. I'm looking deeper to `RefCounted`
Referencer
All ranges in Phobos pass by value, but if I have output range with state like cumulative statistics this is useless. After discussion with Dicebot I try this work-arround: http://dpaste.dzfl.pl/8af8eb8d0007 It is unfinished. But direction is observable. Is this good solution? And how about to include something like this tool in Phobos?
Re: Referencer
On Friday, 20 November 2015 at 18:48:51 UTC, Alex Parrill wrote: On Friday, 20 November 2015 at 18:23:57 UTC, HaraldZealot wrote: I'm not sure how useful this is as opposed to plain pointers. For structs, since `foo.bar` is the same as `().bar`, you may as well use a pointer, and the only thing it saves for numbers is a pointer deference or two. I realized that for my initial purposes simple pointer simply work, but when I'm trying make as possible universal template as it can be, I discover that the main problem with direct operators (and this touches not only numbers). You say ranges are pass-by-value, but that's not entirely true. Ranges themselves can be classes, or be made references via std.range.refRange. Range elements can be made lvalues by using ref functions [1]. Possible refRange is what I was looking for. Thanks. As for the code: * Your example usage (x = x += x = (x * 5)) is confusing, due to the chained assignments. This is special one of boundary cases, that clarify why is it so complicated to create full-functional wrapper.
Re: Please vote for the DConf logo
On Wednesday, 4 November 2015 at 09:30:30 UTC, Andrei Alexandrescu wrote: Reply to this with 1.1, 1.2, 2, or 3: ... Andrei 3
Re: Release D 2.069.0
On Wednesday, 4 November 2015 at 01:50:38 UTC, Martin Nowak wrote: Glad to announce D 2.069.0. ... -Martin Congratulations!!!
Re: The D Language Foundation is now incorporated
On Friday, 16 October 2015 at 10:04:36 UTC, Andrei Alexandrescu wrote: We are pleased to announce that the D Language Foundation is now incorporated with the state of Washington, USA. ... Andrei Congratulations! I hope this accelerate many things.
Re: RFC: Units of measurement for D (Phobos?)
On Tuesday, 12 April 2011 at 16:44:10 UTC, David Nadlinger wrote: Recently, I have been playing around with a little units of measurement system in D. As this topic has already been brought up quite a number of times here, I thought I would put my implementation up for discussion here. ... Anyway, here is a link to the code: https://github.com/klickverbot/phobos/tree/units (std/units.d and std/si.d). Also, I put up a build of the DDoc output at http://klickverbot.at/code/units/std_units.html resp. http://klickverbot.at/code/units/std_si.html. ... David One big problem is, that in SI base unit for mass is kilogram not gram.
Re: Moving forward with work on the D language and foundation
On Monday, 24 August 2015 at 18:43:01 UTC, Andrei Alexandrescu wrote: Hello everyone, Following an increasing desire to focus on working on the D language and foundation, I have recently made the difficult decision to part ways with Facebook, my employer of five years and nine months. ... Thanks, Andrei It is great!!!
Re: Truly lazy ranges, transient .front, and std.range.Generator
On Saturday, 15 August 2015 at 10:06:13 UTC, Joseph Rushton
Wakeling wrote:
...
In some cases we're going to want true laziness of evaluation,
but _not_ transience of .front. In these cases, the _first_
time .front is called, its value should be freshly evaluated;
but thereafter, the value is cached, until .popFront() is
called, at which point .front will be re-evaluated lazily the
next time it's called. Something like std.algorithm.cache is
inappropriate here, precisely because it's eager in its
calculation of the cached values.
...
-- Joe
Do you mean something like that:
```d
struct Range
{
public:
enum empty = false;
auto ref front() @property
{
if(mustBeEvaluated)
{
cache = fun();
mustBeEvaluated = false;
}
return cache;
}
void popFront()
{
mustBeEvaluated = true;
}
private:
ReturnType!fun cache;
bool mustBeEvaluated = true;
}
```
?
Re: Truly lazy ranges, transient .front, and std.range.Generator
On Tuesday, 18 August 2015 at 19:37:47 UTC, Joseph Rushton Wakeling wrote: Yes, broadly like your example, although note that your version won't handle multiple popFront() calls in succession without any .front call in-between. Good point! And you show acceptable solution. The last your example I prefer to parametrize with alias to functions: ```d mixin template LazyPopFront(alias frontImplementation, alias popFrontImplementation) ... ``` It gives more flexibility. One that worries me, if someone start to make odd things like create shared instance of this range.
Re: `examplevalues` property
On Monday, 3 August 2015 at 14:30:43 UTC, Andrea Fontana wrote: On Monday, 3 August 2015 at 13:54:51 UTC, HaraldZealot wrote: You have to write the same amount of code. It's just one line for each type... Something like: [...] Many thanks, it seems like good workaround for my personal use case. But have something like that in Phobos were great from my POV.
`examplevalues` property
I found myself in situation that were good that all types support `.examplevalues` property in unittest version. This property will return array of predefined values for specified type (we can even have some convention like `examplevalues[0]` is `init`, `examplevalues[1]` is `min` (for numerical type) an so on). If custom types doesn't redefine this property the array consist only from `init`. The use case for this: templated struct or class with container-like semantics and internal unittest for method of such class. Thoughts?
Re: `examplevalues` property
On Monday, 3 August 2015 at 13:13:55 UTC, Andrea Fontana wrote:
Why don't you use templates? Something like:
enum ValueType
{
Init,
Min,
Max
}
auto exampleValues(T)()
{
T[ValueType] retVal;
retVal[ValueType.Init] = T.init;
static if (__traits(compiles, T.min)) retVal[ValueType.Min] =
T.min;
static if (__traits(compiles, T.max)) retVal[ValueType.Max] =
T.max;
return retVal;
}
exampleValues!int.writeln;
exampleValues!string.writeln;
Good solution!
But there is something that not perfect: it can be customizable
only with template specialization as I see. I want not only
standard values like `init` `max` or `min` but also some example
value like 1, 2, 3, 4, 5 for `int`. In last case your template
solution not so convenient as desired (introduction in language
feature like `.testValue1` seems ridiculous, and without that
only template specialization can provide customization, as I have
said).
But this seems interesting direction, and easy to implement in
object.d (without library implementation, this feature have
little benefit).
Re: dmd 2.068, 2.069, 2.0xx Evil Plan going forward
On Monday, 20 July 2015 at 21:27:17 UTC, Mathias Lang wrote: We do follow a versioning style: '2.MAJOR.PATCH' (with major being 3 digits). It's not as good as SemVer, but better than it was few years ago, and I have faith we'll end up following SemVer at some point. Following SemVer strictly wouldn't solve the real problem: We'll go from 2.068, 2.069. 2.070.. to 3.0.0, 4.0.0, 5.0.0 and will soon end up playing catch up with Chrome. To follow SemVer we'll have to separate breaking changes from bugfixes (including regressions) from new feature, and most likely work with separate branches.. Martin already started to work on this and we're in a nicer spot now, but it requires manpower. Since we don't have 2 consecutive releases that don't break code, I see no point in changing the version scheme at this point other than satisfying the purists. Having a focus for releases will hopefully mitigate that problem. But so far most posts have been about BTW we need that fixed and our versioning scheme is broken. +100
Re: Wait, what? What is AliasSeq?
On Wednesday, 8 July 2015 at 09:13:27 UTC, Jonathan M Davis wrote: On Wednesday, 8 July 2015 at 08:59:15 UTC, deadalnix wrote: Yeah. Every name sucks. Alias seems to solve the first half of the name reasonably well, but nothing that anyone has come up with really solves the second half. [...] Array (as Andrei has suggested) is already a very overloaded term in D, and it implies a runtime data structure, which this isn't. Certainly, when folks think of arrays, they're not going to think of anything like TypeTuple/AliasSeq. List is by far the most generic, but it doesn't imply indexability, so Walter doesn't like - though Seq doesn't imply indexability either, so if that's his complaint, I don't see how it makes much differences whether we go with List or Seq. They seem pretty interchangeable to me. [...] - Jonathan M Davis Perhaps in such case we are going to invent new word? How about a kind of portmoneu word? For example tree + heap = treap. And we can have alias+list = aliast. No one have such word before an no impure association.
Re: Voting for std.experimental.allocator
On Wednesday, 8 July 2015 at 11:33:03 UTC, Dicebot wrote: Andrei is back online and thus it is time to make a decision about adding his allocator package (http://forum.dlang.org/post/vfipmwojmvseqxoiw...@forum.dlang.org) to Phobos std.experimental [...] Yes
Re: Convert std.random to a package
On Wednesday, 24 June 2015 at 14:16:04 UTC, Jonathan M Davis wrote: On Wednesday, 24 June 2015 at 12:15:10 UTC, Joseph Rushton Wakeling wrote: Hello all, As I promised at DConf (though sadly arriving a bit later than I'd hoped), I've submitted a PR to convert std.random to a package: https://github.com/D-Programming-Language/phobos/pull/3406 I'd like to ask for some attention to this because, first, I think it's important that we agree that this particular package structure is correct/logical, and second, I really don't want to have to rework this if anyone commits to std.random in the meanwhile ;-) Beyond perhaps documentation issues I hope this PR should be fairly non-controversial and easy to approve (or disapprove). Is there any point in doing this if we're going to be redesigning std.random as you've been working on? In fact, it could get in the way of that, since we could potentially just make the new version be modules in the package, and the old version be in std.random.package (meaning that if you imported std.random, you get the old, deprecated stuff, and if you import std.random.foo, you get the new stuff). - Jonathan M Davis Please not such way. Idea with package 'experimental' and 'deprecated' looks like more preferable. (This idea was discussed in std.container fork. For example new random API go to std.experimental.random all old API remain in std.random, when stable state of new API was approved that renaming happens: std.random - std.deprecated.random and in next DMD/Phobos release std.experimental.random - std.random. Also were good provide with new release tool that autofix stuff like this)
Re: pure format
On Thursday, 4 June 2015 at 17:02:46 UTC, Oleg B wrote: On Thursday, 4 June 2015 at 16:21:54 UTC, Jonathan M Davis wrote: I think toString for float must be pure, but in practice it's not. It's a bug? I read what std.format.format using libc sprintf http://www.digitalmars.com/d/archives/digitalmars/D/learn/std.conv.to_purity_68957.html and if it try it's not a bug... And I also remember that format doesn't work in CT, so it was really uncomfortable that a can't initialize array of special values for algorithm in CT. It was a more than year ago, possible something changes.
Re: std.container: fork in the road
On Wednesday, 17 June 2015 at 06:08:57 UTC, Andrei Alexandrescu wrote: Regarding compatibility, I see three possibilities: 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. Andrei 2 or 3 Better 3. And I like idea to move std.container to std.deprecated container in future.
Re: Phobos addition formal review: std.experimental.allocator
So we have: * 1 request to change names; * 3 requests to wank around the directory structure; * 0 of everything else. Sigh. Andrei Yesterday I have found an error in documentation and have left a comment about it on github PR. And I only start to read the documentation, so I think there will be plenty small things to polish.
Re: forum.dlang.org, version 2 (BETA)
On Wednesday, 10 June 2015 at 00:30:05 UTC, Vladimir Panteleev wrote: On Thursday, 4 June 2015 at 15:04:05 UTC, Vladimir Panteleev wrote: http://beta.forum.dlang.org/ Any objections against updating forum.dlang.org on Sunday or so? It has started. Super!
Re: Dconf Video / Projector Information
On Wednesday, 20 May 2015 at 22:14:56 UTC, Adam D. Ruppe wrote: Also, when are the videos going to be released this time? I'd like it on youtube as soon as possible. +1
Re: Thoughts about the ideal programming language
On Thursday, 14 May 2015 at 06:02:37 UTC, thedeemon wrote: On Wednesday, 13 May 2015 at 18:59:42 UTC, Dennis Ritchie wrote: http%3A%2F%2Fhabrahabr.ru%2Fpost%2F257875%2F Just some usual C++ critique and very vague basic principles about having a core language with some extensions and library support, nothing constructive or informative really. I generally agree with you. But his idea of language extension looks very nice, and as I think is similar to tendency in D make some features part of library (e.g. octal numbers, complex numbers). And verbalize such concept can make this tendency sharper and clearer and possible more productive. The last Andrej proposal for allocators may become example of such language extension. D specifies interface of allocators and introduce reference implementation, but for example embeded D provide other implementation.
Iterate over enum
Is it possible iterate over enum (preferable in compile time) or at least check that particular value belong to enum?
Re: Iterate over enum
On Saturday, 18 April 2015 at 20:42:09 UTC, Ali Çehreli wrote: On 04/18/2015 01:30 PM, HaraldZealot wrote: Is it possible iterate over enum (preferable in compile time) or at least check that particular value belong to enum? EnumMembers: http://dlang.org/phobos/std_traits.html#EnumMembers It returns a static tuple, meaning that a foreach over those members will be a compile-time foreach. (No loop at all at run-time, the body is unrolled for every member.) Ali Many thanks
Re: [website redesign] PR for the one with the big red menu bar
Another variant somewhere between the all-red one and the all-grey one: http://ag0aep6g-dlang.rhcloud.com/variants/grey-newlogo/ +1 but perhaps blending between logo and menu were good.
Re: [website redesign] PR for the one with the big red menu bar
On Sunday, 1 February 2015 at 09:46:16 UTC, HaraldZealot wrote: Another variant somewhere between the all-red one and the all-grey one: http://ag0aep6g-dlang.rhcloud.com/variants/grey-newlogo/ And also when Phobos and Deimos receive some grayness than D letter becomes more contrast and recognizability.
Re: Mars Drafting Library - Official community driven library
Possible initial prerequisites: - User awareness about the usage consequences - Library placed at https://github.com/D-Programming-Language/ - Only well recognized community members have pull rights - design decision made on the best known sw engineering patterns used in D - New module should be functional with D/Phobos standards applied - API and implementation allowed to change any time in order to make a progress - no external dependencies beside OS services - draft as the root module name e.g. module draft.gui Advantages: - community driven process which ensures the lowest level of controversy - fast path for modules like GUI to be standardized Disadvantages: - additional effort for the sw release process Ready to be destroyed ;) Piotrek Approximately a half year ago I have similar idea and suggestion. This is my idea: * make new feature in dub, that it can place some libraries in common namespace. For example CyberShadow's ae will be placed in something like advancex.image, or logger (lucky it is in std.experimental already, but as alternative history) is placed in stdx.logger. But they are not part of phobos in that time but usual dub package on dub registry. * create namespaces advance (or any other) for useful but not so common components (e.g. proposal windowing, image processing an so on), bind for Deimos. Phobos is std already :). And also create their experimental counterpart like advancex, bindx and stdx. (It can be other name but I prefer one worded stdx than two worded std.experimental in other level of hierarchy). * make new feature in dub and dub register that counts download, likes and bugs. When some package receives essential feedback it can be started pull request process. * all packages in special namespaces can't be orphan. Experimental version must have at least one active maintainer. More approved namespace require two responsible maintainer one of which at least someone from trusted user. If package became orphan it will be dropped out. In this manner we can create stair like development. To place simple package in dub registry you have the same condition as for now. If you want place it in experimental namespace you must complete some easy condition (more complicated in case of stdx and perhaps bindx), and you package must go through full review process in case of phobos. You can see on archlinux as example of such package management. For now I drive two interesting project, but I also try to find forces for this one.
Re: Is anyone working on a D source code formatting tool?
On Saturday, 10 January 2015 at 20:18:03 UTC, Walter Bright wrote: Has someone made a dfmt, like http://gofmt.com/ ? I with one my good student have started project coDewife 1,5 month ago. It based on some interesting theoretical approach (something like FSM, but with essential differences). It is being in very raw state by now, but has possibility to configure many good configuration. For example we can manipulate with underscore in decimal literal. I have benchmarked this decimal formatter a little, and it shows nod bad result: approximately 5 usec by one codeunit. We in active codding phase by now, but I can't predict terms of first useful release yet. And by the way I have a question. When I read http://dlang.org/lex.html#integerliteral I understand that 0b, 0x or 0x_ isn't valid, but that compiles. Is that bug or spoiled documentations?
Re: decodeReverse
I'm pretty sure that you basically have to do what strideBack does before you can decode a code point, so all decodeBack would do would be to do exactly what back already does for strings, which is to use strideBack followed by decode. - Jonathan M Davis I have to read more attentively std.utf, but strideBack seems very suitable for me. Thanks you both!!!
Re: decodeReverse
On Tuesday, 6 January 2015 at 16:58:24 UTC, Andrei Alexandrescu wrote: On 1/5/15 10:43 PM, HaraldZealot wrote: For my particular project (it binds with something like finite state machine) I will write some counterpart of decode function from std.utf. Future function will decode string backward, return dchar and change index passed by reference. Is it interesting for community that I code this feature in general way targeting in phobos for future? back() and popBack() for narrow strings do reverse decode. -- Andrei I need reverse decode from any position, not only from the last. I have coded a litle with stideBack allready, it works. But usage isn't clear as could: first strideBack, then decode, and decode move index forward, then I have to strideBack again :) Perhaps i will wrap such algorithm in some function, but an other side i will be forced to optimize that and write real decodeBack function.
decodeReverse
For my particular project (it binds with something like finite state machine) I will write some counterpart of decode function from std.utf. Future function will decode string backward, return dchar and change index passed by reference. Is it interesting for community that I code this feature in general way targeting in phobos for future?
Re: Community and contribution [was: Re: http://wiki.dlang.org/DIP25]
TL;DR: I think it would be good to have a strong community guideline that people are not to be criticized or treated badly for having requests or suggestions, even if they are not willing to implement them themselves. The quid pro quo is that it's necessary to be (calmly) candid with people about the limits of _only_ contributing ideas or requests: You can ask but not demand. What would be an appropriate place to put this? Andrei Any kind of main place, for example first page of dlang.org, but not alone. I have suggestion in my mind for a month at least: For D's community is good to formulate something like principles or axiomata. (Because as I see, many discussion goes round and round about similar things). One of those principle may sound like this for example: __D is safe by default and fast when need.__ (This about general design of D, for example about garbage collection). Main page has something like this but in descriptive not rule-provided form. After formulating such maxima many discussion calming itself, because part of ideas will follow global goals and another contradict. In my view such principles have to cover following aspects: design of D (about safety, speed, multiparadigmality, glitchness, smoothness and so on), evolution of D (in such cases breaking change is allowed and about deepness of breakage, phobos and its topics coverage and so on) and community cooperation (yes, it is suggested by Joseph Rushton Wakeling community guidline). IMO discussion about such axiomata (when comunity interesting in) need own topic.
Naming for mixin template
Has anybody some methodology or codestyle for mixin template? I use general nouns for structures and classes and verbs for functions. Variables and functions start with lowercase, structures, classes and enums uppercase, templates follow their internal content (eponymous trick helps very with this). But how are good named mixin template?
Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function
On Wednesday, 15 October 2014 at 14:42:30 UTC, Regan Heath wrote: On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak c...@dawg.eu wrote: Would this affect your code? No Do you think it makes your code better or worse? Better. More clear Is this just a pointless style change? No
Re: D Logos
Well, they're definitely cool looking (and I certainly couldn't do anything that looks that good), but nothing about them makes me think of D. - Jonathan M Davis I totally agree with Jonathan. -- Alaksiej Stankievič
Re: std.experimental – DConf?
std.experimintal is helpfull and I rejoy about. But I think, we can have better place as subpackage. I wrote some ideas about, but they have sunk in other topic. http://forum.dlang.org/thread/ljrm0d$28vf$1...@digitalmars.com?page=16#post-mdhlmsxfzaelpdgwfbfh:40forum.dlang.org
Re: D Users Survey: Primary OS?
I use Archlinux 64 exclusivly. And my students use arch, LinuxMint and Windows7 for their D projects
Re: Suggestion/proposal regarding std.logger candidate
The logger is very good and need thing. But has anybody an idea how to preserve purity of functions?
Re: From slices to perfect imitators: opByValue
This looks like interesting.
Re: More radical ideas about gc and reference counting
I have to say that all this discussion (more precisely the understanding on the side of key developers) make me very upset. It's good that Andrei agreed with impossibility of the harebrained disallowing of the class destructors. But I was very surprise, that so thought go to such head, because such solution contradicts the D spirit totally. There are many language which are very popular and have many dark moments in their design. I (and I think not only me) go to the D not for its popularity, but for its clarity, power and SANITY (that bases on strong guaranties). The strong solutions found on the strong decision makes D itself. (Examples of such strong solutions: immutabilities, default unshareness, struct and class as distinct being). And way that leads us in state where stucts have dtors and classes haven't but allow struct with dtor as member and people have to call struct dtor manually, isn't D way. Because such way relies on programmers discipline, but how Andrei has written If there one thing that decades of computing have taught us, it must be that discipline-oriented programming does not scale.[TDPL, p. 399]. Our negative filling flood out may be sane from psychologically view, but neither sane nor constructive for D future. For solving problem it's need its formulate. We have to state that current state (lack of structs' dtors call guaranty) is insane, the harebrained disallowing of the class destructors is insane too. And what is sane? If I properly understand philosophy of D, we need semiautomated (not full) resource manager with strong guaranty and good performance, and which automated mode covers the most part of use-case. It is the target. Garbage collection or reference counting or any possible third way is a detail therefor task and mean not a target. And one task, that lays on the way to target, is minimal rape of D2 language (even if solution will be D3), so IMO dtors (perhaps only for structs) must survive. I notice that I view only part of problem, can anybody link or describe me completely state and problems of current garbage collection and other resource management? It help me in finding of existence solution (at least theoretical). --- Alaksiej Stankievič
Re: More radical ideas about gc and reference counting
That experimental package idea that was discussed months ago comes to my mind again. Add that thing as exp.rational and have people report bugs or shortcomings to the original author. When it seems to be usable by everyone interested it can move into Phobos proper after the formal review (that includes code style checks, unit tests etc. that mere users don't take as seriously). As long as there is nothing even semi-official, it is tempting to write such a module from scratch in a quickdirty fashion and ignore existing work. The experimental package makes it clear that this code is eventually going to the the official way and home brewed stuff wont have a future. Something in the standard library is much less likely to be reinvented. On the other hand, once a module is in Phobos proper, it is close to impossible to change the API to accommodate for a new use case. That's why I think the most focused library testing and development can happen in the experimental phase of a module. The longer it is, the more people will have tried it in their projects before formal review, which would greatly improve informed decisions. The original std.rationale proposal could have been in active use now for months! +1 The same idea came to my mind yesterday too (that signalize that isn't void idea). And GNU/Linux community has proof that such model works. I mean Archlinux as example (but as I think other example exists). There are core, extra, community repositories and AUR (arch user repository). Today AUR contains 48489 packages and 11814 of which are orphan. But even orphanity isn't a sign of useless. Possibility to write PKGBUILD and place it in AUR has everybody and it is not such difficult. Only small part of these package goes to official repository, but this part EXISTS. And in my opinion this is the most rapid way for evolution. For example archlinux has the best support of D language through abundance of linux distributives (http://pastebin.com/tPKWS4ga and this is official repositories not in AUR). Oh, I've forgotten to mention all sorts of testing repositories. And D community have all means for evolute such way. We have dub and http://code.dlang.org/. It rests to do a little: create package (in D sense) which will contain packages that installed through dub; and some UI to vote, orphan and adopt package. There are example as how that I see: On http://code.dlang.org/ we can found package rationals (for example) with mark expstd. Than we install package with dub to some environment (it may be fakeroot, peruser import path or even perproject directory (the last likes me the least)) and address this package as import expstd.rationals; in our D projects. It's were good when dub or code.dlang.org counts installation. When some package counts enough installation and enough history (includes bug tracking), it become candidate to include in phobos. All trusted users (in therm of Archlinux) receive strong signal about and one of them review such package and become its auxiliary comaintainer. No one package can exist in official repository without maintainer. And some words about why expstd. I think that with such package model comes time to add not only phobos in namespace. There are many useful libraries which may not become part of phobos (linear algebra for example, or even GUI bindings), but should have some standardization and highway to distribution. I suggest package extra (in D sense) and bind (for deimos and perhaps not only deimos packages). Naturally they start their life as expextra and expbind. In the future we will need some other package (in D sense), but for start that three are enough. As Andrei said acta non verba. I promise that I make all, considering my life environment, to help and start this project. P.S. This theme will become independent. And this is yet another one argue, that forum forms not ideal to represent news and current state of community. Important things sink often in other topics. P.P.S. My apologies for my poor English.
Re: More radical ideas about gc and reference counting
The major issue with the garbage collector is that it's not guaranteed to run a collection. When a collection is run the GC will call the destructors for the objects it collects. If there's no guarantee a collection is run there can be no guarantee that destructors are called. A collection is usually run when allocating new memory and there's not enough memory available. So it seems that I have understood more than I've thought. If really problem rely on this than an idea came to my mind yesterday. What about separate destructors call and garbage collections mechanism? This idea reflects current D state with postblit constructor in structures. Raw memory allocation, default initialization (with T.init field) and after all that calling constructor (especially postblit). In therms of destructors it sound as: after becoming object or structure needless some automatic mechanism call cascading destructor, but memory still not fried, and GC collects memory in its time. Yes it's sounded monstrous, but perhaps when which mechanism will done only self work, each of them can be lighter. And you always can call some kind of finalizator manually for performance (some kind of flag can exist to protect from double call of destructors).
Re: Why not memory specific destructors?
Destructors of the first kind are usually called just
destructors and are used for resource management, and the
second kind are called finalizers. These are useful for
implementing weak references, caching, and various other things
where you don't require objects to be destroyed at a certain
point in time, but still want to get notified when they are.
And we come to some kind of Andrei's proposal to remove class
destructor. In my view problem lays not in the fact, that there
are two world, but in how the beings from theses world must
interacting. Now we have the fire and the water but we must
invent the steam engine.
Possible steam engine can look like that:
The structures with destructor disallowed as member of classes,
but compiler suggest in such case tip like that
class C
{
SomeKindOfSmartPointer!S p; // or better SomeKindOfMagic!S p;
}
Re: More radical ideas about gc and reference counting
This is a misunderstanding of the situation. This is brainstorming. There has to be a public place in which ideas can be discussed freely, no matter how radical. This is another misunderstanding :)). Not radicalism upset me, but proposal to create one more hole instead exist hole from man, that touched me solidness in code by his book. It were surprising. But it's only emotion.
Re: More radical ideas about gc and reference counting
This is another misunderstanding :)). Not radicalism upset me, but proposal to create one more hole instead exist hole from man, that touched me solidness in code by his book. It were surprising. But it's only emotion. But yes, It may possible as troll mode in brainstorming.
Re: More radical ideas about gc and reference counting
That said, I really want my destructors, and would be very upset to see them go. So... ARC? Manu, can you direct me what is ARC? This abbreviation is very misgooglly.
