Re: Walter and Andrei and community relationship management

2017-04-11 Thread HaraldZealot via Digitalmars-d

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

2017-04-11 Thread HaraldZealot via Digitalmars-d

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 "@"?

2016-12-14 Thread HaraldZealot via Digitalmars-d

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 "@"?

2016-12-14 Thread HaraldZealot via Digitalmars-d
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: Argumnentation against external function operator overloading is unconvincing

2016-09-22 Thread HaraldZealot via Digitalmars-d
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

2016-09-22 Thread HaraldZealot via Digitalmars-d
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

2016-09-22 Thread HaraldZealot via Digitalmars-d

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

2016-09-21 Thread HaraldZealot via Digitalmars-d
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

2016-09-21 Thread HaraldZealot via Digitalmars-d

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

2016-09-21 Thread HaraldZealot via Digitalmars-d

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

2016-09-21 Thread HaraldZealot via Digitalmars-d
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

2016-06-07 Thread HaraldZealot via Digitalmars-d

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

2016-06-03 Thread HaraldZealot via Digitalmars-d

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?

2016-05-03 Thread HaraldZealot via Digitalmars-d

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: DIP 88: Simple form of named parameters

2016-01-25 Thread HaraldZealot via Digitalmars-d

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: DIP 88: Simple form of named parameters

2016-01-25 Thread HaraldZealot via Digitalmars-d
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: Referencer

2015-11-23 Thread HaraldZealot via Digitalmars-d
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`




Re: Referencer

2015-11-23 Thread HaraldZealot via Digitalmars-d
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

2015-11-23 Thread HaraldZealot via Digitalmars-d

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

2015-11-20 Thread HaraldZealot via Digitalmars-d

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 `(&foo).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.







Referencer

2015-11-20 Thread HaraldZealot via Digitalmars-d
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: RFC: Units of measurement for D (Phobos?)

2015-09-09 Thread HaraldZealot via Digitalmars-d

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: Truly lazy ranges, transient .front, and std.range.Generator

2015-08-18 Thread HaraldZealot via Digitalmars-d
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: Truly lazy ranges, transient .front, and std.range.Generator

2015-08-18 Thread HaraldZealot via Digitalmars-d
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: `examplevalues` property

2015-08-03 Thread HaraldZealot via Digitalmars-d

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.


Re: `examplevalues` property

2015-08-03 Thread HaraldZealot via Digitalmars-d

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).


`examplevalues` property

2015-08-03 Thread HaraldZealot via Digitalmars-d
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: dmd 2.068, 2.069, 2.0xx Evil Plan going forward

2015-07-21 Thread HaraldZealot via Digitalmars-d

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?

2015-07-08 Thread HaraldZealot via Digitalmars-d

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: Convert std.random to a package

2015-07-01 Thread HaraldZealot via Digitalmars-d
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

2015-07-01 Thread HaraldZealot via Digitalmars-d

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

2015-06-17 Thread HaraldZealot via Digitalmars-d
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

2015-06-13 Thread HaraldZealot via Digitalmars-d


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: Dconf Video / Projector Information

2015-05-22 Thread HaraldZealot via Digitalmars-d

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

2015-05-14 Thread HaraldZealot via Digitalmars-d

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.


Re: [website redesign] PR for the one with the big red menu bar

2015-02-01 Thread HaraldZealot via Digitalmars-d

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: [website redesign] PR for the one with the big red menu bar

2015-02-01 Thread HaraldZealot via Digitalmars-d


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: Mars Drafting Library - Official community driven library

2015-02-01 Thread HaraldZealot via Digitalmars-d


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?

2015-01-15 Thread HaraldZealot via Digitalmars-d

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

2015-01-06 Thread HaraldZealot via Digitalmars-d
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.




Re: decodeReverse

2015-01-06 Thread HaraldZealot via Digitalmars-d
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!!!



decodeReverse

2015-01-05 Thread HaraldZealot via Digitalmars-d
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]

2015-01-02 Thread HaraldZealot via Digitalmars-d
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

2014-12-31 Thread HaraldZealot via Digitalmars-d

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

2014-10-18 Thread HaraldZealot via Digitalmars-d

On Wednesday, 15 October 2014 at 14:42:30 UTC, Regan Heath wrote:
On Thu, 09 Oct 2014 09:50:44 +0100, Martin Nowak  
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

2014-06-14 Thread HaraldZealot via Digitalmars-d
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: D Users Survey: Primary OS?

2014-05-29 Thread HaraldZealot via Digitalmars-d

I use Archlinux 64 exclusivly.

And my students use arch, LinuxMint and Windows7 for their D 
projects


Re: std.experimental – DConf?

2014-05-29 Thread HaraldZealot via Digitalmars-d

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: Suggestion/proposal regarding std.logger candidate

2014-05-24 Thread HaraldZealot via Digitalmars-d
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

2014-05-07 Thread HaraldZealot via Digitalmars-d

This looks like interesting.



Re: More radical ideas about gc and reference counting

2014-05-06 Thread HaraldZealot via Digitalmars-d
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

2014-05-06 Thread HaraldZealot via Digitalmars-d
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: Why not memory specific destructors?

2014-05-06 Thread HaraldZealot via Digitalmars-d
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

2014-05-06 Thread HaraldZealot via Digitalmars-d


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: More radical ideas about gc and reference counting

2014-05-06 Thread HaraldZealot via Digitalmars-d



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 quick&dirty 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

2014-05-05 Thread HaraldZealot via Digitalmars-d
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

2014-05-05 Thread HaraldZealot via Digitalmars-d
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.