Re: dmd: why not use fully qualified names for types in error messages?

[Jacob Carlborg via Digitalmars-d]

On 2017-06-14 06:50, Timothee Cour via Digitalmars-d wrote:

eg:
Error: no property 'IF_gray' for type 'ImageFormat'
=>
Error: no property 'IF_gray' for type 'foo.bar.ImageFormat'

and also, why not show where the symbol is defined?

would PR's for that be accepted? is that hard to implement?


Technically, for templates, the fully qualified name include all the 
template arguments. In many (some) cases  this will be way too long to 
print.


--
/Jacob Carlborg

Re: Isn't it about time for D3?

[Sebastien Alaiwan via Digitalmars-d]

On Tuesday, 13 June 2017 at 17:57:14 UTC, Patrick Schluter wrote:
Before even contemplating a big disrupting language split like 
proposed by the OP, wouldn't it first more appropriate to write 
a nice article, DIP, blog, whatever, listing the defects of the 
current language that can not be solved by progressive 
evolution?
I haven't the impression that the *language* itself suffer from 
so big flaws that it would warrant to fork it in a way that 
will lead to a lot frustration and bewilderment.
D is not perfect, no question, but it is not in a state that 
would jusrify such a harsh approach.


+1
Does anyone currently maintain somewhere such a list of 
not-gonna-be-fixed-in-D2 defects?

This might provide more solid grounds to this discussion.

Re: dmd: why not use fully qualified names for types in error messages?

[H. S. Teoh via Digitalmars-d]

On Tue, Jun 13, 2017 at 09:50:29PM -0700, Timothee Cour via Digitalmars-d wrote:
> eg:
> Error: no property 'IF_gray' for type 'ImageFormat'
> =>
> Error: no property 'IF_gray' for type 'foo.bar.ImageFormat'

I support such a change.  Is there an issue filed in bugzilla for this?

I'd add that this would be very useful with Voldemort types, esp. Phobos
ones that are generally just named "Result".


> and also, why not show where the symbol is defined?

Might not be a bad idea, if you're dealing with overloads and don't want
to manually scroll through every definition to see which is the relevant
one.  I'm not 100% sure, but I think this info should already be
available in the symbol definition.


> would PR's for that be accepted? is that hard to implement?

Only Walter / Andrei can answer the first question.

For the second question, it doesn't seem hard but it's hard to tell for
sure until I look at the actual code.


T

-- 
Having a smoking section in a restaurant is like having a peeing section in a 
swimming pool. -- Edward Burr 

[your code here]

[Jorge nqvr via Digitalmars-d]

Please send a code

dmd: why not use fully qualified names for types in error messages?

[Timothee Cour via Digitalmars-d]

eg:
Error: no property 'IF_gray' for type 'ImageFormat'
=>
Error: no property 'IF_gray' for type 'foo.bar.ImageFormat'

and also, why not show where the symbol is defined?

would PR's for that be accepted? is that hard to implement?

Re: foreach range with index

[9il via Digitalmars-d]

On Wednesday, 14 June 2017 at 03:06:26 UTC, Luís Marques wrote:

On Wednesday, 14 June 2017 at 02:54:30 UTC, 9il wrote:
Random access iteration is more expensive then front/popFront 
in general case.
For arrays it is not true. But for many other kinds of ranges 
it is. For example ranges that do not have contiguous memory 
representation (strided vectors, flattened matrixes and etc)


I'm not sure I understand what you are saying. I was suggesting 
that foreach(range) would iterate range[0...length] in that 
order. Wouldn't that be an equivalent access pattern to 
front/popFront?


---A
foreach(__i; 0 .. r.length)
{
auto e = r[__i];
}


---B
for (auto __r = range; !__r.empty; __r.popFront())
{
auto e = __r.front;
...
}

They are equivalent, but "A" is slower then "B" in general case.
So, B is preferred.

Re: foreach range with index

[Luís Marques via Digitalmars-d]

On Wednesday, 14 June 2017 at 02:54:30 UTC, 9il wrote:
Random access iteration is more expensive then front/popFront 
in general case.
For arrays it is not true. But for many other kinds of ranges 
it is. For example ranges that do not have contiguous memory 
representation (strided vectors, flattened matrixes and etc)


I'm not sure I understand what you are saying. I was suggesting 
that foreach(range) would iterate range[0...length] in that 
order. Wouldn't that be an equivalent access pattern to 
front/popFront?

Re: foreach range with index

[Luís Marques via Digitalmars-d]

On Wednesday, 14 June 2017 at 02:48:34 UTC, Luís Marques wrote:
Hmm, I suppose that even if we have all of the good stuff of 
length, opIndex, opSlice, etc., we can't assume the indices are 
[0..length], right? But there should be some way for, say, map 
to preserve that information from the slice, the same way 
random access is preserved.


A quick look into std.algorithm.iteration suggests that this is 
not actually true. For instance:


static if (hasLength!R)
{
foreach (k; 0 .. data.length / 16)

So I guess we are assuming that if we have length then indexing 
is always [0..length]. These are the kinds of details that I 
never know because there is no spec for ranges :(

Re: foreach range with index

[9il via Digitalmars-d]

On Wednesday, 14 June 2017 at 02:42:46 UTC, Luís Marques wrote:
On Tuesday, 13 June 2017 at 21:44:43 UTC, Steven Schveighoffer 
wrote:
But I think leaving the definition of the index up to the 
range itself is paramount -- I don't want every range to be 
able to have a size_t index, as that's not always what you 
want, and it conflicts with other items. What we may need is a 
smarter way to get from the type parameters at the front of 
the foreach to an iterable type.


That's why I mentioned random access ranges, as in that case we 
can sidestep this discussion; since foreach understands input 
ranges, why can't foreach understand random access ones, and 
iterate them as if they were slices, including maintaining a 
foreach-generated index? That is, it would have nothing to do 
with tuple unpacking. Plus, it would work transparently in the 
cases you replace `slice` with `slice.algorithm`, where 
algorithm maintains random-access. Instead of having to add 
.enumerate in each place the slice (now a range) is iterated, 
it would just work.


Random access iteration is more expensive then front/popFront in 
general case.
For arrays it is not true. But for many other kinds of ranges it 
is. For example ranges that do not have contiguous memory 
representation (strided vectors, flattened matrixes and etc)

Re: foreach range with index

[Luís Marques via Digitalmars-d]

On Wednesday, 14 June 2017 at 02:42:46 UTC, Luís Marques wrote:
On Tuesday, 13 June 2017 at 21:44:43 UTC, Steven Schveighoffer 
wrote:
But I think leaving the definition of the index up to the 
range itself is paramount -- I don't want every range to be 
able to have a size_t index, as that's not always what you 
want, and it conflicts with other items. What we may need is a 
smarter way to get from the type parameters at the front of 
the foreach to an iterable type.


That's why I mentioned random access ranges, as in that case we 
can sidestep this discussion; since foreach understands input 
ranges, why can't foreach understand random access ones, and 
iterate them as if they were slices, including maintaining a 
foreach-generated index? That is, it would have nothing to do 
with tuple unpacking. Plus, it would work transparently in the 
cases you replace `slice` with `slice.algorithm`, where 
algorithm maintains random-access. Instead of having to add 
.enumerate in each place the slice (now a range) is iterated, 
it would just work.


Hmm, I suppose that even if we have all of the good stuff of 
length, opIndex, opSlice, etc., we can't assume the indices are 
[0..length], right? But there should be some way for, say, map to 
preserve that information from the slice, the same way random 
access is preserved.

Re: foreach range with index

[Luís Marques via Digitalmars-d]

On Tuesday, 13 June 2017 at 21:44:43 UTC, Steven Schveighoffer 
wrote:
But I think leaving the definition of the index up to the range 
itself is paramount -- I don't want every range to be able to 
have a size_t index, as that's not always what you want, and it 
conflicts with other items. What we may need is a smarter way 
to get from the type parameters at the front of the foreach to 
an iterable type.


That's why I mentioned random access ranges, as in that case we 
can sidestep this discussion; since foreach understands input 
ranges, why can't foreach understand random access ones, and 
iterate them as if they were slices, including maintaining a 
foreach-generated index? That is, it would have nothing to do 
with tuple unpacking. Plus, it would work transparently in the 
cases you replace `slice` with `slice.algorithm`, where algorithm 
maintains random-access. Instead of having to add .enumerate in 
each place the slice (now a range) is iterated, it would just 
work.

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote:

[ ... ]


Slice Assignment bugs fixed!
With that we are green again.

I am going to improve concat a little such that it computes the 
buffer lengths if it can.

And allocs the needed amount upfront.

The alternative is lazy concat which is much more work. With alot 
of potential for bugs.


|| and && still have me puzzledw :)

Re: foreach range with index

[Steven Schveighoffer via Digitalmars-d]

On 6/13/17 1:15 PM, Luís Marques wrote:

In the documentation for foreach with range concepts (not x..y ranges)
() I did not
find anything about foreach supporting iteration indices/tuple unpacking
for ranges, such as `foreach(i, elm; range)`. It is "documented" in an
example for std.range.enumerate though [1].

I found a bug report asking for that to be documented [2] and one saying
that it should be removed [3].

One of the things that I like in D is the plasticity of the code. In the
situation that brought me to this issue, I started with a plain slice
which I iterated with foreach(i, foo; foos). Then `foos` became a range,
and the foreach became foreach(i, foo; foos.enumerate); Thus, I didn't
have to restructure my foreach iteration, moving the index variable
outside the foreach statement, and manually incrementing the index,
making this change less disruptive.

Some thoughts about this:

- It doesn't strike me as very realistic to remove support for
foreach(i, e; range.enumerate) now, as probably a lot of people are
relying on this. I find it very useful, especially as currently there
doesn't seem to be a good alternative.


We aren't going to as far as I can tell. I closed that bug report.


- The plasticity was not perfect in my example; ideally I wouldn't have
to change the foreach statement at all (i.e., add ..enumerate).
Consider: my range had random access, why couldn't foreach itself
generate the index, as it does for slices, instead of relying on
.enumerate and tuple unpacking? Maybe it would even make sense for input
ranges, I'm not sure.


The issue here is the difference between foreach on arrays (which has 
nothing to do with ranges), and foreach on a range. In the former, the 
array index is wholly a concept of the foreach loop itself. The compiler 
inserts and maintains the index in the loop, as the array structure has 
no storage or maintenance of an index.


In the latter, the index is maintained by the range, and so stored 
there. AND it's copied and stored as a temporary for your loop via the 
unpacking of the tuple.


I feel a change in the way foreach and ranges interact may be needed to 
make things more efficient and less awkward. opApply has some really 
nice features, one of them being that you can declare loop-specific data 
such as an index, and another being that foreach'ing an opApply 
structure with different types/numbers of parameters works just fine.


But I think leaving the definition of the index up to the range itself 
is paramount -- I don't want every range to be able to have a size_t 
index, as that's not always what you want, and it conflicts with other 
items. What we may need is a smarter way to get from the type parameters 
at the front of the foreach to an iterable type.



- Since foreach with ranges and unpacking (i.e., indices when using
.enumerate) seems here to stay for now, please document it. The code I
was writing was supporting material for an article. But I'm afraid to
advocate an approach which relies on behavior which is undocumented and
which people are arguing should be removed. Not exactly confidence
inspiring...


It should be documented, 100%.

-Steve

Re: Makefile experts, unite!

[ketmar via Digitalmars-d]

Ralph Amissah wrote:

On Sun, Jun 11 2017, Jonathan M Davis via Digitalmars-d 
 wrote:


And where do existing D build systems fit into the picture, I seem to
recall this general discussion around the announcement of "button", which
seems interesting, potentially awesome even:

Button announcement
https://forum.dlang.org/post/uhozcvatvyztfuhiv...@forum.dlang.org


"tracing system calls". a no-no for any general solution. no sane person 
with even rudimentary care for privaly will give *build* *system* 
privileges for injecting .so libraries or trace system calls.


actually, requiring such privileges is my main objection agains any "modern 
automagic build system".

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

crimaniak wrote:


If it depended on me, I would declare an embargo on language changes


that's why we (me, and others like me ;-) need D3. i don't need "better 
phobos", for example ('cause i'm trying to aboid using phobos anyway), but 
i really need named arguments (`foo(a:42, b:"hello")`). i want '=>' to be 
usable for any method/free function, not only for lambdas. i want $-expands 
in mixin strings. warnings on unary minus on byte/short types (do you know 
that D doesn't do int promition in this case, and C does? it bites me 
several times!). i want `foreach_reverse` to be replaced with `foreach 
(auto a; b; reverse)` (and *require* type, modifier or `auto` there). i 
want optional `ref` and `out` marks for function *calls*. i want... i want 
alot of things, i'm not even started yet. especially not started to talk 
about breaking changes. i cannot do that now (i have my private fork of 
dmd), 'cause i need to keep compatibility with vanilla, and i have zero 
hopes to see it all introduced in D2 (language stability, etc.). with D2, 
i'll have a chance to bring 'em on a table.

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Patrick Schluter wrote:

Before even contemplating a big disrupting language split like proposed 
by the OP, wouldn't it first more appropriate to write a nice article, 
DIP, blog, whatever, listing the defects of the current language that can 
not be solved by progressive evolution?
I haven't the impression that the *language* itself suffer from so big 
flaws that it would warrant to fork it in a way that will lead to a lot 
frustration and bewilderment.
D is not perfect, no question, but it is not in a state that would 
jusrify such a harsh approach.


the main reason for D3 is not language changes, but workarounding "don't 
break user code" thingy. it is completely impossible to experiment freely 
or introduce breaking changes in D2 (for a reason, there is nothing bad in it).

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

jmh530 wrote:


Nevertheless, C++ is still a constantly evolving language.


one of the key features of evolution is removing old and rudimentary 
things. without this, it is not evolution, it is mutilation...

Re: Isn't it about time for D3?

[crimaniak via Digitalmars-d]

On Tuesday, 13 June 2017 at 17:57:14 UTC, Patrick Schluter wrote:

I haven't the impression that the *language* itself suffer from 
so big flaws that it would warrant to fork it in a way that 
will lead to a lot frustration and bewilderment.
 I have the same opinion. Raw libraries, poor documentation and 
infrastructure are much more problematic. If it depended on me, I 
would declare an embargo on language changes and throw all the 
forces to eliminate the problems of infrastructure and libraries.

Re: Makefile experts, unite!

[Ralph Amissah via Digitalmars-d]

On Sun, Jun 11 2017, Jonathan M Davis via Digitalmars-d 
 wrote:

And where do existing D build systems fit into the picture, I seem to
recall this general discussion around the announcement of "button", which
seems interesting, potentially awesome even:

Button announcement
https://forum.dlang.org/post/uhozcvatvyztfuhiv...@forum.dlang.org

Features
https://code.dlang.org/packages/button
- Implicit dependency detection.
- Correct incremental builds.
- Can display a graph of the build.
- Recursive. Can generate a build description as part of the build.
- Very general. Does not make any assumptions about the structure of your 
project.
- Detects and displays cyclic dependencies.
- Detects race conditions.

example build description provided (the build description is done in
lua)
https://github.com/jasonwhite/dmd/blob/button/src/BUILD.lua

http://jasonwhite.github.io/button/

I have not used it, but if it works as described on the box most should
be pleased to get to know and to use and promote, no?... I assume it
will work well with dub if necessary? Other D based build systems have
been mentioned, who is able to review them?

> On Sunday, June 11, 2017 16:47:30 Ali Çehreli via Digitalmars-d wrote:
>> On 06/11/2017 12:27 PM, ketmar wrote:
>>  > p.s.: or replacing make-based build system with D-based. as we need
>>  > working D compiler to compile dmd anyway, i see no reason to not use it
>>  > more.
>>
>> I had the pleasure of working with Eyal Lotem, main author of buildsome.
>> The buildsome team are aware of all pitfalls of all build systems and
>> offer build*some* as an awe*some* ;) and correct build system:
>>
>>http://buildsome.github.io/buildsome/
>
> Atila did some work to get dmd, druntime, phobos, etc. building with
> reggae/dub, and I _think_ that he had it all working. As I understand it,
> the main barrier to switching to it officially was political. A number of us
> would _love_ to see the makefiles killed off, and there's really no
> technical barrier to doing so. It's really a question of convincing folks
> like Walter, Andrei, and Martin, and I get the impression that to an extent,
> there's an attitude of not wanting to mess with what's working (though I
> dispute that it works all that well from a maintenance perspective).
>
> It's certainly a pain to edit the makefiles though, and I think that we'd be
> far better off in the long run if we switched to something like reggae - and
> since reggae is written in D and uses dub, we'd be dogfooding our own stuff
> in the process.
>
> - Jonathan M Davis
>
>

--
ralph.amis...@gmail.com

Re: Isn't it about time for D3?

[Patrick Schluter via Digitalmars-d]

Before even contemplating a big disrupting language split like 
proposed by the OP, wouldn't it first more appropriate to write a 
nice article, DIP, blog, whatever, listing the defects of the 
current language that can not be solved by progressive evolution?
I haven't the impression that the *language* itself suffer from 
so big flaws that it would warrant to fork it in a way that will 
lead to a lot frustration and bewilderment.
D is not perfect, no question, but it is not in a state that 
would jusrify such a harsh approach.

foreach range with index

[Luís Marques via Digitalmars-d]

In the documentation for foreach with range concepts (not x..y 
ranges) 
() I 
did not find anything about foreach supporting iteration 
indices/tuple unpacking for ranges, such as `foreach(i, elm; 
range)`. It is "documented" in an example for std.range.enumerate 
though [1].


I found a bug report asking for that to be documented [2] and one 
saying that it should be removed [3].


One of the things that I like in D is the plasticity of the code. 
In the situation that brought me to this issue, I started with a 
plain slice which I iterated with foreach(i, foo; foos). Then 
`foos` became a range, and the foreach became foreach(i, foo; 
foos.enumerate); Thus, I didn't have to restructure my foreach 
iteration, moving the index variable outside the foreach 
statement, and manually incrementing the index, making this 
change less disruptive.


Some thoughts about this:

- It doesn't strike me as very realistic to remove support for 
foreach(i, e; range.enumerate) now, as probably a lot of people 
are relying on this. I find it very useful, especially as 
currently there doesn't seem to be a good alternative.


- The plasticity was not perfect in my example; ideally I 
wouldn't have to change the foreach statement at all (i.e., add 
.enumerate). Consider: my range had random access, why couldn't 
foreach itself generate the index, as it does for slices, instead 
of relying on .enumerate and tuple unpacking? Maybe it would even 
make sense for input ranges, I'm not sure.


- Whatever changes you decide for tuple unpacking and foreach, 
please try to keep in mind this plasticity concern. I'm trying 
some techniques to make data-oriented designs more flexible, and 
this feature seems like an important tool for the approach I'm 
following/devising.


- Since foreach with ranges and unpacking (i.e., indices when 
using .enumerate) seems here to stay for now, please document it. 
The code I was writing was supporting material for an article. 
But I'm afraid to advocate an approach which relies on behavior 
which is undocumented and which people are arguing should be 
removed. Not exactly confidence inspiring...


Thank you for your hard work.

Cheers,
Luís

[1] 
[2] 
[3] 

Re: Supporting musl libc

[Joakim via Digitalmars-d]

On Tuesday, 13 June 2017 at 10:10:38 UTC, Joseph Rushton Wakeling 
wrote:

On Tuesday, 13 June 2017 at 09:42:43 UTC, Joakim wrote:
Also, it's possible others are still adding Glibc stuff as 
just linux, as that's happened a couple times since then, but 
I don't follow it and tell them to change it, as it usually 
doesn't affect me on Android.  If these are affecting you, 
submit a pull for druntime and ping me, I'll review it.


That sounds like something that automated testing ought to be 
able to catch ... ?


Depends how deep you want it go, what did you have in mind?

Re: atomic operations compared to c++

[Kagamin via Digitalmars-d]

LDC uses seq_cst seq_cst

Re: Isn't it about time for D3?

[Mike Parker via Digitalmars-d]

On Tuesday, 13 June 2017 at 13:29:45 UTC, jmh530 wrote:

Companies clearly value C++'s backwards compatibility. However, 
if there's one lesson from the D1/D2 or the Python 2/Python 3 
split, it's that it's hugely disruptive (so much so that I find


The D1/D2 split was actually a unifier. It was the Phobos/Tango 
divide that was the problem. D2 healed that rift, brought us a 
single runtime that both libraries could share, improved Phobos, 
and was relatively easy for most projects to transition to 
(Sociomantic's experience was not common), and D1 was eventually 
retired. We're all better off for it. A vastly different 
situation than what happened with Python, where you find 2.x 
releases continuing on and some projects requiring one or the 
other.


That said, at this stage, I can't imagine a D2/D3 transition 
being anything other than negatively disruptive.

Re: Isn't it about time for D3?

[jmh530 via Digitalmars-d]

On Tuesday, 13 June 2017 at 12:23:19 UTC, ketmar wrote:

Sebastien Alaiwan wrote:

My point precisely was that "not splitting D1/D2" might 
correspond to "doing things right".


"not splitting" here means "we're stuck with D1". deprecation 
cycle of several years (not counting the time required to 
actually *start* the process) means "no evolution".


i must make myself clear here, i guess: i value "good language" 
way more than "stable language". i absolutely don't mind fixing 
my code if it makes it better/more clear/etc. while it's hard 
to sell "constantly evolving" language to Big Enterprise 
Wheels, not making breaking changes means cloning worst C++ 
feature. ;-)


Companies clearly value C++'s backwards compatibility. However, 
if there's one lesson from the D1/D2 or the Python 2/Python 3 
split, it's that it's hugely disruptive (so much so that I find 
the idea of D3, at the moment, to be such an obviously terrible 
idea that I really wanted to avoid commenting on this thread). 
Nevertheless, C++ is still a constantly evolving language. C++14 
looks a lot different from C++98. Maintaining backwards 
compatibility, however, has significantly increased the 
complexity.


Thus, I think there's a trade-off. Breaking changes that improve 
the language may be good in certain circumstances, but 
Walter/Andrei should try to get the buy-in from big D users 
beforehand (even with a depreciation cycle). Requiring some kind 
of broad support from big D users would mean that breaking 
changes only happen if the the costs of breaking changes are 
smaller than the improvement to the language.

Re: Makefile experts, unite!

[Meta via Digitalmars-d]

On Tuesday, 13 June 2017 at 06:05:16 UTC, Sebastien Alaiwan wrote:

On Monday, 12 June 2017 at 15:57:13 UTC, Meta wrote:
On Monday, 12 June 2017 at 06:34:31 UTC, Sebastien Alaiwan 
wrote:

On Monday, 12 June 2017 at 06:30:16 UTC, ketmar wrote:

Jonathan M Davis wrote:


It's certainly a pain to edit the makefiles though


and don't forget those Great Copying Lists to copy modules. 
forgetting to include module in one of the lists was 
happened before, not once or twice...


I don't get it, could you please show an example?


https://github.com/dlang/phobos/pull/3843


Thanks!

Please, tell me that the Digital Mars implementation of Make 
*does* support generic rules...


I have no idea. I'm not very well versed in Make to begin with, 
much less Digital Mars Make.

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Sebastien Alaiwan wrote:

My point precisely was that "not splitting D1/D2" might correspond to 
"doing things right".


"not splitting" here means "we're stuck with D1". deprecation cycle of 
several years (not counting the time required to actually *start* the 
process) means "no evolution".


i must make myself clear here, i guess: i value "good language" way more 
than "stable language". i absolutely don't mind fixing my code if it makes 
it better/more clear/etc. while it's hard to sell "constantly evolving" 
language to Big Enterprise Wheels, not making breaking changes means 
cloning worst C++ feature. ;-)

Re: Isn't it about time for D3?

[Sebastien Alaiwan via Digitalmars-d]

On Tuesday, 13 June 2017 at 06:56:14 UTC, ketmar wrote:

Sebastien Alaiwan wrote:


On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote:

Guillaume Piolat wrote:

On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray 
wrote:
I realize that there are people who want to continue using 
D as it is, but those people may continue to use D2.


Well, no thanks.
The very same strategy halved the community for D1/D2 split 
and almost killed D.


as you can see, D is alive and kicking, and nothing 
disasterous or fatal happens.
Yes, but could it have been a lot more alive and kicking, 
hadn't we shot ourselves in the foot with this D1/D2 split?


this question has no answer. can we do better if we will do 
everything right on the first try? of course!


My point precisely was that "not splitting D1/D2" might 
correspond to "doing things right".

Re: anyone using msgpackrpc-d ? it's currently broken and doesn't seem maintained

[Atila Neves via Digitalmars-d]

On Monday, 12 June 2017 at 18:12:38 UTC, Timothee Cour wrote:
any help on this would be most welcome: 
https://github.com/msgpack-rpc/msgpack-rpc-d/issues/16


Unfortunately I find the RPC support in D lacking. Having a 
good RPC integration for D is key for production use of D where 
one wants to integrate with other existing services (that could 
be written in other languages for eg)


Thrift?

Atila

Re: D, DStep, and Deimos

[Jacob Carlborg via Digitalmars-d]

On 2017-06-13 13:22, Russel Winder via Digitalmars-d wrote:

Having now got some bits of libdvbv5 usable from D with aid of DStep –
which let's be honest did 90.357% (roughly) of the work – thoughts turn
to maintenance and distribution. So a few questions/comments:

1. Is Deimos "alive and well" as a place to host the current state of a
D adaptor library,


No, I would avoid Deimos.


or is it best to just have a repository somewhere:
Git/GitHub, Git/BitBucket, Mercurial/BitBucket, Bazaar/Launchpad.


Yes, GitHub to make it accessible to Dub.


2. There needs to be an idiomatic process for updating DStep generated
but manually amended libraries using DStep.


DStep has a flag to ignore translating the specified symbols. If you 
specify that flag for the symbols you need to translate manually. would 
that be an ok workflow?



3. I take it as given this needs to be in the Dub repository, is this
fair?


Yes. If think there's specific category in Dub for bindings to C 
libraries [1].



4. DStep is great.


Thanks :)

[1] http://code.dlang.org/?sort=updated&category=library.binding

--
/Jacob Carlborg

Re: D, DStep, and Deimos

[rikki cattermole via Digitalmars-d]

On 13/06/2017 12:22 PM, Russel Winder via Digitalmars-d wrote:

Having now got some bits of libdvbv5 usable from D with aid of DStep –
which let's be honest did 90.357% (roughly) of the work – thoughts turn
to maintenance and distribution. So a few questions/comments:

1. Is Deimos "alive and well" as a place to host the current state of a
D adaptor library, or is it best to just have a repository somewhere:
Git/GitHub, Git/BitBucket, Mercurial/BitBucket, Bazaar/Launchpad.

2. There needs to be an idiomatic process for updating DStep generated
but manually amended libraries using DStep.

3. I take it as given this needs to be in the Dub repository, is this
fair?


You're limited to Github and Bitbucket, so that'll answer 1 as well.

Re: D, DStep, and Deimos

[Jonathan M Davis via Digitalmars-d]

On Tuesday, June 13, 2017 12:22:52 Russel Winder via Digitalmars-d wrote:
> Having now got some bits of libdvbv5 usable from D with aid of DStep –
> which let's be honest did 90.357% (roughly) of the work – thoughts turn
> to maintenance and distribution. So a few questions/comments:
>
> 1. Is Deimos "alive and well" as a place to host the current state of a
> D adaptor library, or is it best to just have a repository somewhere:
> Git/GitHub, Git/BitBucket, Mercurial/BitBucket, Bazaar/Launchpad.

In theory, deimos is the place to put C bindings, but at this point, I
wouldn't bother, because if you do put them there, you don't control the
repo, which can get annoying, and the important thing for finding and using
the bindings is to have them on code.dlang.org. Regardless, if you're
talking about creating a wrapper library rather than bindings, then deimos
isn't really the place for that.

- Jonathan M Davis

D, DStep, and Deimos

[Russel Winder via Digitalmars-d]

Having now got some bits of libdvbv5 usable from D with aid of DStep –
which let's be honest did 90.357% (roughly) of the work – thoughts turn
to maintenance and distribution. So a few questions/comments:

1. Is Deimos "alive and well" as a place to host the current state of a
D adaptor library, or is it best to just have a repository somewhere:
Git/GitHub, Git/BitBucket, Mercurial/BitBucket, Bazaar/Launchpad.

2. There needs to be an idiomatic process for updating DStep generated
but manually amended libraries using DStep.

3. I take it as given this needs to be in the Dub repository, is this
fair?

4. DStep is great.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: Supporting musl libc

[Joseph Rushton Wakeling via Digitalmars-d]

On Tuesday, 13 June 2017 at 09:42:43 UTC, Joakim wrote:
Also, it's possible others are still adding Glibc stuff as just 
linux, as that's happened a couple times since then, but I 
don't follow it and tell them to change it, as it usually 
doesn't affect me on Android.  If these are affecting you, 
submit a pull for druntime and ping me, I'll review it.


That sounds like something that automated testing ought to be 
able to catch ... ?

Re: Supporting musl libc

[Joakim via Digitalmars-d]

On Monday, 10 October 2016 at 15:19:00 UTC, Daniel Kozak wrote:

Dne 10.10.2016 v 15:27 openwrt via Digitalmars-d napsal(a):


On Sunday, 9 October 2016 at 15:48:49 UTC, Daniel Kozak wrote:
On Sunday, 9 October 2016 at 13:38:33 UTC, Jacob Carlborg 
wrote:

On 2016-10-08 20:47, Daniel Kozak wrote:

What is the current status? Without support of musl-libc, I 
can not ad support for a Alpine linux distribution. It is a 
shame because they already have go and rust support.


I've not worked at this at all. For my use case it was 
easier to just build in Docker instead.


I solved this by using libexecinfo library from freebsd


openwrt also use musl,  and I can not run my d code on 
it(unless I rebuild everythings with glic).
Yes, even libexecinfo does not fixed all issues, we really need 
to add other C runtimes. In D runtime and phobos there is a lot 
of places which  wrongly use version(linux) instead of 
CRuntime_Glibc.


Sorry, didn't see your comment till this thread was just bumped.  
I was the one who separated out linux and Glibc in druntime, I 
noted then that some blocks were still mixed:


https://github.com/dlang/druntime/pull/1010#issuecomment-69815792

Also, it's possible others are still adding Glibc stuff as just 
linux, as that's happened a couple times since then, but I don't 
follow it and tell them to change it, as it usually doesn't 
affect me on Android.  If these are affecting you, submit a pull 
for druntime and ping me, I'll review it.

Re: Makefile experts, unite!

[Russel Winder via Digitalmars-d]

On Mon, 2017-06-12 at 10:39 -0700, H. S. Teoh via Digitalmars-d wrote:
> 
[…]
> Don't forget tup, and others inspired by it, which use modern OS
> features to reduce the cost of determining what to build to an O(1)
> database lookup rather than an O(n) whole-source tree scan. I.e.,
> much
> faster code-compile-test cycle.  Much as I have come to love SCons, I
> think ultimately the build system of the future will be something
> derived from the tup model.

Ninja.

However good Tup may be, I think Ninja has the mindshare as the build
engine underneath CMake, Meson, etc.

I am ambivalent about SCons. It is a huge improvement over Make, great
strides are being made in performance along with the Python 2 → Python
3 thing (removing all the Python < 2.7 stuff and replacing with modern
Python code), but it's model is from the 2000s and as you say the 2010s
have new things which are not getting in to SCons, mostly because it is
a pure volunteer project with no companies putting any resources in. I
am doing work on it for D builds mostly because I can't really cope
with Dub as a build tool.

> [...]
> 
> I don't agree with the notion that everything must be "forward
> looking"
> in order to be "good".  If something existing works well and does
> what
> we need it to do, there's no reason to keep reinventing the wheel.

Forward looking is always good, this does not exclude leaving things as
is, or bringing things that got forgotten from the past, it is about
thinking about what is right next year, not what we have last year.

> However, I do agree that where there is room for improvement,
> improvements ought to be made. On this front, make leaves a lot to be
> desired.  It requires far too much babysitting, manual work, and
> dependence on human infallibility (which we all know works all too
> well). Not to mention that it fails the basic tenet of a reliable
> build
> system: reproducible builds, i.e., given *any* arbitrary workspace
> state, running the build command ought to produce products
> (executables,
> etc.) that are *guaranteed* to reflect the current state of the
> source
> code.
> 
[…]

It all comes down to two things:

1. Is anyone willing to create the new build.
2. Will the new build be accepted and used.

Given some people's tone here, and the lack of contribution from Walter
and Andrei on replacing Make, the answer to 2 is NO. Thus the answer to
1 is "don't bother". Thus this thread is useless. Thus D will continue
to use an outdated and increasingly difficult to use build system. Not
a way of attracting new contributors. Its not the outdated so much as
the difficult to use.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: Makefile experts, unite!

[Russel Winder via Digitalmars-d]

On Mon, 2017-06-12 at 21:27 +0200, Jacob Carlborg via Digitalmars-d
wrote:
> 
[…]
> the 
> makefiles, just recently [1]. And not just the makefiles, now there's
> a 
> Visual Studio project that needs to kept up to date as well.
> 
> [1] https://github.com/dlang/dmd/pull/6837


There should only ever be one specification of the project and how to
build it. IDE project files should be generated from that
specification, never hand built.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: Makefile experts, unite!

[ketmar via Digitalmars-d]

Sebastien Alaiwan wrote:


On Monday, 12 June 2017 at 06:38:34 UTC, ketmar wrote:

Sebastien Alaiwan wrote:


The selling points, to me, are:
1) the automatic dependency detection through filesystem hooks
2) recipes also are dependencies
3) the genericity/low-level. I believe build systems should let me 
define my own abstractions, instead of trying to define for me what an 
"executable" or a "static library" should be.


i'm not that all excited by "1", though. tbh, i prefer simplier things, 
like regexp scanning. while regexp scanners may find more dependencies 
than there really are, they doesn't require any dirty tricks to work.


I understand your point ; I was explaining to my colleagues yesterday 
that "1" was a "good step in the wrong direction".

..
However: "1" is still a "good" step. Compared to where we are now, it's 
in theory equivalent to perfectly doing regexp/gcc-MM scanning, in a 
langage agnostic way. It's a net win!


it is still a kludge. and it has a huge chance to stay with us for a very 
long time -- this is what usually happens with kludges. ;-)

Re: Isn't it about time for D3?

[ketmar via Digitalmars-d]

Sebastien Alaiwan wrote:


On Sunday, 11 June 2017 at 17:59:54 UTC, ketmar wrote:

Guillaume Piolat wrote:


On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
I realize that there are people who want to continue using D as it is, 
but those people may continue to use D2.


Well, no thanks.
The very same strategy halved the community for D1/D2 split and almost 
killed D.


as you can see, D is alive and kicking, and nothing disasterous or fatal 
happens.
Yes, but could it have been a lot more alive and kicking, hadn't we shot 
ourselves in the foot with this D1/D2 split?


this question has no answer. can we do better if we will do everything 
right on the first try? of course!