D Cookbook [eBook] Free on PackPub

[Rory McGuire via Digitalmars-d-announce]

Hi all,

Today's free ebook on PacktPub is "D Cookbook [eBook]".

Get it while its hot.

Cheers,
R

[Issue 15389] extern(C++) forward referencing problem

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15389

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: Evolutionary Programming!

[crimaniak via Digitalmars-d]

On Tuesday, 5 January 2016 at 20:11:10 UTC, Ola Fosheim Grøstad 
wrote:


But I think the most powerful concept now is _software 
synthesis_. The basic idea being that you specify the 
constraints and let the computer write the actual code, or some 
variation over that.

  It's called Prolog.

Subject of this entire thread:
http://www.e-commerce-review.com/wp-content/uploads/2010/09/image51.png

Re: Evolutionary Programming!

[Guillaume Piolat via Digitalmars-d]

On Tuesday, 5 January 2016 at 16:10:21 UTC, Jason Jeffory wrote:


Any more thoughts?


In our times programming languages exist and are adopted for 
market reasons.
Because the basic needs have been fulfilled, better alternatives 
like D can get relatively ignored by the market for a long time.
We never had such excellent languages, such an amount of new 
ones, yet the old players tend to get more entrenched like 
somehow history stopped.


Brookes noted long ago that new language design would yield 
diminishing returns: 
http://worrydream.com/refs/Brooks-NoSilverBullet.pdf


That and the fact that hardware/OS vendors have incentive to push 
entrenched languages to developers, I don't see something too 
shocking happening in the language space.

Re: D Cookbook [eBook] Free on PackPub

[Rory McGuire via Digitalmars-d-announce]

On 06 Jan 2016 12:38, "Iain Buclaw via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On 6 January 2016 at 11:34, Chris via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
>>
>> On Wednesday, 6 January 2016 at 09:52:14 UTC, Rory McGuire wrote:
>>>
>>> Hi all,
>>>
>>> Today's free ebook on PacktPub is "D Cookbook [eBook]".
>>>
>>> Get it while its hot.
>>>
>>> Cheers,
>>> R
>>
>>
>> How do you get it? Do you have a link?
>
>
>
> It's here: https://www.packtpub.com/packt/offers/free-learning
>
> 13 hours and 20 minutes to go! (As of writing)
>
>
Thanks Iain, I forgot the link and couldn't update the mail I sent.

Re: Redesign of dlang.org

[anonymous via Digitalmars-d]

On 06.01.2016 09:00, welkam wrote:

This reminded me when at work we got new design in html/css and had to
put it on the site. It looked better but lacked 1/3 of fields and
functionality. Then backend developers had to fix design and in the end
it was better than before but not as good as html/css from designer.


Also check out http://d-ag0aep6g.rhcloud.com/ where I'm currently 
working on the implementation. It's a little different from the mockup, 
precisely because I'm trying not to drop features/content.

Struct Union behavior

[Voitech via Digitalmars-d-learn]

Hello, i am new to D language and trying to learn it by coding.
I compile my programs on Xubuntu 14.04 with DMD64 D Compiler 
v2.069.2.
So i have a struct/union which contains two fields representing 
real and string values:


public union Element
{
private real _value;
private string _rawValue;

@property{
real value(){
return _value;
}
void value(real value){
_value=value;
}

}
@property {
ref string rawValue(){
return _rawValue;
}
void rawValue(ref string value){
_rawValue=value;
}

}


public Element opBinary(string op)(Element other){
Element newElement;
real value=mixin("this.value "~op~"other.value");
newElement.value=value;
return newElement;
}

public bool opEquals(Element other){
if(this.rawValue == null && other.rawValue == null){
return this.opEquals(other.rawValue);
}
return this.opEquals(other.value);
}
public bool opEquals(real value){
return this.value==value;
}
public bool opEquals(string rawValue){
return this.rawValue==rawValue;
}

unittest{
Element e1 = {4},e2 ={5};
writeln("e1 is at address: ",);
writeln("e2 is at address: ",);
writeln("e1.value is at address: ",_value);
writeln("e2.value is at address: ",_value);
assert(e1+e2==9);
}

unittest{
Element s1={_rawValue:"+"},s2,s3,s4;
writeln("s1 is at address: ",);
writeln("s2 is at address: ",);
writeln("s3 is at address: ",);
writeln("s1.value is at address: ",_value);
writeln("s2.value is at address: ",_value);
writeln("s3.value is at address: ",_value);
writeln("s4.value is at address: ",_value);
writeln("s1.rawValue ",s1._rawValue);
writeln("s1.value: ",s1._value);
writeln("s2.value: ",s2._value);
writeln("s3.value: ",s3._value);
writeln("s4.value: ",s4._value );
assert(s1!=s2);
}
}

The unit test results are:

e1 is at address: 7FFCEFBA7510
e2 is at address: 7FFCEFBA7520
e1.value is at address: 7FFCEFBA7510
e2.value is at address: 7FFCEFBA7520
s1 is at address: 7FFCEFBA7500
s2 is at address: 7FFCEFBA7510
s3 is at address: 7FFCEFBA7520
s1.value is at address: 7FFCEFBA7500
s2.value is at address: 7FFCEFBA7510
s3.value is at address: 7FFCEFBA7520
s4.value is at address: 7FFCEFBA7530
s1.rawValue +
s1.value: 0.125
s2.value: 4
s3.value: 5
s4.value: 9

Can anyone tell me why s2,s3,s4 have initialized _value field?  
Shouldn't it be collected by GC when first unit test (with e1,e2) 
finishes ? If not how to handle this behavior, to use union 
without preinitialized fields.

Re: Regex benchmarks in Rust, Scala, D and F#

[wobbles via Digitalmars-d]

On Wednesday, 6 January 2016 at 07:05:43 UTC, israel wrote:

On Tuesday, 5 January 2016 at 17:52:39 UTC, Karthikeyan wrote:

Hi,

Came across this post in rust-lang subreddit about the regex 
benchamrks. Scala surprisingly outperforms D. LDC also gives a 
good advantage for efficiency of D.


http://vaskir.blogspot.ru/2015/09/regular-expressions-rust-vs-f.html


I think the problem with these "benchmarks" is that when their 
favorite language is up there and not doing as good as the 
others, people begin to yell out that they didnt optimize the 
code well, either through compiler flags or something else.


There should be a public benchmark standard.

No special functions. No special linker flags. Just the plain 
code and compilation process.


That'll never work though.
'Just the plain code' to me isn't 'just the plain code' to you.

Ideally, a Git repo somewhere with a lot of benchmarks that the 
community can edit and make better. Over time (assuming the repo 
becomes somewhat popular) all benchmarking programs will use each 
language to it's fullest - thus giving accurate, comparable 
results across the board.

Re: What are you planning for 2016?

[Claude via Digitalmars-d]

I'll do more work on my OpenGL 3D engine/game in D.

Later, I'd like to either:
1/ write a RT streaming framework (kind of like gStreamer, but 
without the gLib non-sense).


or:
2/ write a baremetal OS in D and assembly towards ARMv5 
compatible architecture (on Rasberry Pi maybe). Something very 
simple, just for the proof of concept.


I'd really like to see D more in the embedded/system language 
side. I think it's got some very good potential but I'm not sure 
it's quite there yet. I want to check that out by myself.


At work, we work on ARM targets with GNU/Linux, I don't know if I 
can write a full process in D and integrate a D compiler in our 
build chain easily. Why not, some other guy already managed to do 
that with Vala... :-S

Re: Testing Nightly Build Service

[Martin Nowak via Digitalmars-d-announce]

On Tuesday, 5 January 2016 at 18:34:57 UTC, Johan Engelen wrote:

Hi Martin,
  Any news on this?

(and it'd be great if LDC could be added too! ;-)

cheers,
  Johan


Yes, test phase successful, waiting for time to do the rest.
http://forum.dlang.org/post/56806778.2040...@dawg.eu

I'm not in charge of any ldc building, but can offer to 
collaborate on integrating any ldc nightly build service.

[Issue 15324] symbol is already defined / size of symbol changed

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15324

Vincent R  changed:

   What|Removed |Added

 CC||v.richo...@gmail.com

--- Comment #4 from Vincent R  ---
Any progress ??

--

Re: What are you planning for 2016?

[wobbles via Digitalmars-d]

On Wednesday, 6 January 2016 at 11:16:20 UTC, Chris wrote:
Don't think I'll have time for that and once you use D, you 
lose interest in other languages :-)


Amen to that.
Had to write some Java recently and kept trying to go call 
functions UFCS style.


And if I have to match up angle brackets for a generic list of a 
generic list of a generic type one more time I'll poke my eyes 
out!

Re: vibe.d benchmarks

[Atila Neves via Digitalmars-d]

On Tuesday, 5 January 2016 at 13:09:55 UTC, Etienne Cimon wrote:

On Tuesday, 5 January 2016 at 10:11:36 UTC, Atila Neves wrote:

[...]


The Rust mio library doesn't seem to be doing any black magic. 
I wonder how libasync could be optimized to match it.


No black magic, it's a thin wrapper over epoll. But it was faster 
than boost::asio and vibe.d the last time I measured.


Atila

Re: vibe.d benchmarks

[Atila Neves via Digitalmars-d]

On Tuesday, 5 January 2016 at 14:15:18 UTC, rsw0x wrote:

On Tuesday, 5 January 2016 at 13:09:55 UTC, Etienne Cimon wrote:

On Tuesday, 5 January 2016 at 10:11:36 UTC, Atila Neves wrote:
On Thursday, 31 December 2015 at 08:23:26 UTC, Laeeth Isharc 
wrote:

 [...]


vibe.d _was_ faster than Go. I redid the measurements 
recently once I wrote an MQTT broker in Rust, and it was 
losing to boost::asio, Rust's mio, Go, and Java. I told 
Soenke about it.


I know it's vibe.d and not my code because after I got the 
disappointing results I wrote bindings from both boost::asio 
and mio to my D code and the winner of the benchmarks shifted 
to the D/mio combo (previously it was Rust - I figured the 
library was the cause and not the language and I was right).


I'd've put up new benchmarks already, I'm only waiting so I 
can show vibe.d in a good light.


Atila


The Rust mio library doesn't seem to be doing any black magic. 
I wonder how libasync could be optimized to match it.


Have you used perf(or similar) to attempt to find bottlenecks 
yet?


Extensively. I optimised my D code as much as I know how to. And 
that's the same code that gets driven by vibe.d, boost::asio and 
mio.


Nothing stands out anymore in perf. The only main difference I 
can see is that the vibe.d version has far more cache misses. I 
used perf to try and figure out where those came from and 
included them in the email I sent to Soenke.


Perf is a bit hard to understand if you've never used it 
before, but it's also very powerful.


Oh, I know. :)

Atila

Re: GTKD Cairo get pixel color

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Wednesday, 6 January 2016 at 01:41:03 UTC, Basile B. wrote:
Until a certain "time" my answers were useful. But I recognize 
that after this "time" I've managed to turn the topic into 
something totally delirious because, to be honest I was 
completly sratched by alcohool. I'm sorry but life is so...


No worries! The OP got his question answered, an other people got 
entertained, so it worked out ok :-)

Re: D Cookbook [eBook] Free on PackPub

[Chris via Digitalmars-d-announce]

On Wednesday, 6 January 2016 at 09:52:14 UTC, Rory McGuire wrote:

Hi all,

Today's free ebook on PacktPub is "D Cookbook [eBook]".

Get it while its hot.

Cheers,
R


How do you get it? Do you have a link?

Re: Evolutionary Programming!

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 6 January 2016 at 09:03:04 UTC, crimaniak wrote:
On Tuesday, 5 January 2016 at 20:11:10 UTC, Ola Fosheim Grøstad 
wrote:


But I think the most powerful concept now is _software 
synthesis_. The basic idea being that you specify the 
constraints and let the computer write the actual code, or 
some variation over that.

  It's called Prolog.


Prolog uses unification that is rather explicit, but Horn clauses 
(which is the gut of Prolog) is used. Datalog (a restricted 
variation of Prolog) is used for code analysis for instance and 
is also the guts of IBM's SQL query engine. It can be executed 
bottom up, in parallel.


What people use for specification is SMTLIB2 or some variation of 
it. There have been great advances for solving difficult problems 
using Satisfiability Modulo Theories (SMT) in the past decades.


So, no, it is not called Prolog, but Prolog is part of the 
history.

Re: What are you planning for 2016?

[Chris via Digitalmars-d]

On Tuesday, 5 January 2016 at 12:27:12 UTC, Ola Fosheim Grøstad 
wrote:
I wonder what kind of programming people plan or _hope_ to use 
D for in 2016?


Do you have plans to:



3. create web services with vibe.d?


I'm already doing this, but will extend and improve existing 
services.



4. run D apps in the cloud?


How does that differ from point 3?


5. run D apps on mobile?


Will try to do that.


8. or something else?


There's always "something else", like writing tools for instance.

What other languages do you think you will use or toy with in 
2016 and for what purpose?


Don't think I'll have time for that and once you use D, you lose 
interest in other languages :-)

Re: What are you planning for 2016?

[rsw0x via Digitalmars-d]

On Wednesday, 6 January 2016 at 11:16:20 UTC, Chris wrote:
Don't think I'll have time for that and once you use D, you 
lose interest in other languages :-)


I legitimately cannot use C++ anymore after using D, especially 
anything related to template/compile-time metaprogramming.

Re: What are you planning for 2016?

[wobbles via Digitalmars-d]

On Tuesday, 5 January 2016 at 12:27:12 UTC, Ola Fosheim Grøstad 
wrote:
I wonder what kind of programming people plan or _hope_ to use 
D for in 2016?


Do you have plans to:

6. create runtime less programs (games, embedded)?
Am currently knee deep in my first game in D. Using DTiled and 
DSFML, has been very fun so far.

A rogue-like nomadic city-builder. (That's a thing?!)


7. work on the D language/phobos ?
I don't have the knowledge or skills sadly. I will attempt to 
help out on the  documentation at some stage.


What other languages do you think you will use or toy with in 
2016 and for what purpose?


Been using Groovy more and more in work.
Will also sadly have to write Java code for some in-house Jenkins 
plugins.


Personally, I've been using D a lot more in work recently, and 
quick and dirty tools I need I always go to D first.
One example, we use sysstat to monitor all our servers resource 
usage, and had no centralised way to view those stats. I wrote a 
vibe.d service to do just that, plotting the data via plotly.js.
I might clean it up and put it up on Github actually... could be 
useful to someone.

[Issue 15505] extern(C++) array parameter mangling gains surprise const

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15505

Manu  changed:

   What|Removed |Added

Summary|cxtern(C++) array parameter |extern(C++) array parameter
   |mangling gains surprise |mangling gains surprise
   |const   |const

--

Re: Evolutionary Programming!

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 6 January 2016 at 05:43:37 UTC, Jason Jeffory wrote:
Yeah, I'm not sure I understand the StackOverflow thing but it 
would be cool if people didn't waste so much time having to do 
the same boilerplate code.


What I meant is that often what we seek is recipes for solving 
specific problems. Python is pretty high level and expressive. 
Quite often we find cut'n'paste solutions in Python to specific 
problems.


What if we had a better way of locating recipes? What if we had 
high level recipes and an AI program that could turn it into 
something more specific and executable?


Basically we not only need a better programming language, but a 
language for helping the AI to locate the best recipes and a 
global infrastructure that can provide all this knowledge 
compilers.


I'm not sure if AI is far enough along. Proper AI learning 
algorithms could potentially help(they might suck at first but 
this is what training/practice is for. Eventually they will be 
better at it than us


I think we need more computational power. Which will happen, but 
takes time. In our computers the physical chip is the size of a 
confetti. One idea that is being explored is to build chips as 
"cubes" with pipes through them for efficient cooling. And we 
need lots of storage too. Chess players memorize good moves given 
specific configurations, compilers should too. Our compilers 
don't learn... that's rather primitive.


There are solutions that generate machine language by stringing 
together random sequences of instructions and selecting the ones 
that can become part of a working program. But it takes lots of 
computing. With more computing power and storage it might become 
practical, but we'll see more efficient AI based approaches. 
Still, stochastic optimizers like STOKE is hinting of what might 
come.


https://cs.stanford.edu/people/eschkufz/
https://github.com/StanfordPL/stoke-release

all out... we are on track. It just feels like there it is very 
inefficient... but like most things, it tends to be exponential.


Yes, or maybe we need _lots_ of storage. It seems to help chess 
computers. Storage also don't need as much energy as computation, 
so it is easier to scale up? Just think about how much storage 
one cubic meter of memorysticks represents... and we are only at 
the beginning of solid state storage.


Our brain is also quite slow, I think parts of it is working at 
100hz? But we have lots of relevant information in storage to 
access ("experience").


I suppose the average programmer can't comprehend the 
complexities require for the initial adaptation and it takes 
time for them to "get with the program". Think of when C added 
++... most programmers were not good at oop... now it seems 
everyone has a pretty solid understanding of it.


Yes, tradition can be limiting. Most have a fair understanding of 
OOP, but many also don't understand that OO is more about 
modelling than programming and can be implemented in any 
language... So I think you are right, programmers probably think 
in rather concrete terms of their code, but the kind of 
futuristic programming language need more abstract thinking than 
commercial languages require.


I remember a visit with a game company in the 90s. They said that 
many of their original coders left when they transitioned from 
coding in assembler to C/C++, the programmers had trouble 
changing how they thought about programming to a higher level.


For us that is difficult to understand, right?

Re: D Cookbook [eBook] Free on PackPub

[Iain Buclaw via Digitalmars-d-announce]

On 6 January 2016 at 11:34, Chris via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Wednesday, 6 January 2016 at 09:52:14 UTC, Rory McGuire wrote:
>
>> Hi all,
>>
>> Today's free ebook on PacktPub is "D Cookbook [eBook]".
>>
>> Get it while its hot.
>>
>> Cheers,
>> R
>>
>
> How do you get it? Do you have a link?
>


It's here: https://www.packtpub.com/packt/offers/free-learning

13 hours and 20 minutes to go! (As of writing)

Re: Evolutionary Programming!

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 6 January 2016 at 10:09:57 UTC, Guillaume Piolat 
wrote:
Brookes noted long ago that new language design would yield 
diminishing returns: 
http://worrydream.com/refs/Brooks-NoSilverBullet.pdf


That and the fact that hardware/OS vendors have incentive to 
push entrenched languages to developers, I don't see something 
too shocking happening in the language space.


"no silver bullet" is an anecdotal meme from the 80s. The only 
"insight" it provides is that we cannot engineer out the need for 
good designers. That's rather obvious, isn't it?


The problem is that we don't express the designs. We express 
minutiae.


This isn't how the Egyptian pyramids were built. You had 
architects that gave the overall vision, and lots of workers 
doing the minutiae.


There is no reason for not letting the computer do the minutiae. 
Just like robots are doing minutiae in factories. You need the 
skilled designer, yes. Do you need all the factory workers? Not 
really.

Re: D Cookbook [eBook] Free on PackPub

[Chris via Digitalmars-d-announce]

On Wednesday, 6 January 2016 at 10:38:05 UTC, Iain Buclaw wrote:
On 6 January 2016 at 11:34, Chris via Digitalmars-d-announce < 
digitalmars-d-announce@puremagic.com> wrote:


On Wednesday, 6 January 2016 at 09:52:14 UTC, Rory McGuire 
wrote:



Hi all,

Today's free ebook on PacktPub is "D Cookbook [eBook]".

Get it while its hot.

Cheers,
R



How do you get it? Do you have a link?




It's here: https://www.packtpub.com/packt/offers/free-learning

13 hours and 20 minutes to go! (As of writing)


Thanks. Got it as epub now. I only had the PDF version which is 
not optimal for e-readers. I see that "Learning D" (Michael 
Parker) is also available in different formats now. Very good 
(epub, mobi, kindle). It was about time!

[Issue 15389] extern(C++) forward referencing problem

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15389

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/11d309ff1c766715e06671bbb586809a9b0d5af8
fix Issue 15389 - extern(C++) forward referencing problem

https://github.com/D-Programming-Language/dmd/commit/b21432a31061b7106c3d2d9f0d4b42a2faa070e0
Merge pull request #5330 from WalterBright/fix15389

fix Issue 15389 - extern(C++) forward referencing problem

--

Re: DLanguage IntelliJ plugin released

[Russel Winder via Digitalmars-d-announce]

On Tue, 2016-01-05 at 23:19 +, Israel via Digitalmars-d-announce
wrote:
> […]
> 
> I Agree but CLion is not free and accessible as IDEA. I believe 
> it should still get support but IDEA should have top priority.

Actually CLion is free for those who can show their use is for a FOSS
project. I have a licence for Zipios. But you have to apply.

IntelliJ IDEA Community is indeed just download and go, but it is
fundamentally JDK Maven/Gradle oriented. OK so Gradle has a C++ build
capability, but it doesn't have a SCons, CMake or Dub one really.

My background here is that I think all builds should be driven by a
text file. Whilst Eclipse and IntelliJ IDEA used to demand manually
constructed projects, this approach is now history. All the IDEs now
focus on generating projects from external build descriptions. For all
my projects I use a Gradle, CMake, or SCons file and then generate
projects as needed.

I am told there are some differences between plugins for CLion and
IntelliJ IDEA but not too different so a single code base should
suffice.
 
-- 
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

[Issue 15384] assignment is sometimes still accepted as a condition

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15384

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/95453495fdb38b9c596a977595ce23966fa55be7
fix Issue 15384 - assignment is sometimes still accepted as a condition

1. Add CommaExp.toBoolean to show error message.
2. Add checkAssignmentAsCondition and call it before semantic analysis to
provide informative diagnostic.

https://github.com/D-Programming-Language/dmd/commit/66ca6fe6cfe45f251664abed7304814c4e07af68
Merge pull request #5293 from 9rnsr/fix15384

Issue 15384 - assignment is sometimes still accepted as a condition

--

Re: What are you planning for 2016?

[Puming via Digitalmars-d]

On Tuesday, 5 January 2016 at 12:27:12 UTC, Ola Fosheim Grøstad 
wrote:
I wonder what kind of programming people plan or _hope_ to use 
D for in 2016?


Do you have plans to:


8. or something else?


What other languages do you think you will use or toy with in 
2016 and for what purpose?


What would it take for you to use D instead, or what changes 
would be needed for you to move from language X to D?


I've been lurking here for a long time, but this year I need to 
actually do some projects in D and learn it in the process.


Things on my wish list:

1. Write some data processing code in D for work. Currently I'm 
using Python/C++, and D would be a very good replacement. If 
things turn out good, I may become a happy D-at-work coder :)


2. Make a working prototype of my toy language, Venus, in D. 
(https://github.com/zhaopuming/Venus)


3. Learn about SDC and hopefully make some contributions. Venus 
is implemented based on SDC design/code.


4. Dive into dlangui/dlangide, and make a simple repl/editor for 
my language with them.

[Issue 15384] assignment is sometimes still accepted as a condition

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15384

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: Evolutionary Programming!

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 6 January 2016 at 12:47:15 UTC, Ola Fosheim Grøstad 
wrote:
Systems are realized in a different way today than in the 80s, 
for sure.


Sure some systems use cutting edge techniques and management. 
Maybe I'm oblivious to that since I was born in late 80s.


In some ways I think we still haven't catched up in significant 
numbers with some of what Brookes proposed. Like the Surgical 
Team http://c2.com/cgi/wiki?SurgicalTeam (original article is 
worth reading). Such an organization definately happens but I'd 
by accident.


Like Microsoft said about their C++ compiler, we must discover 
flight before we invent space travel.

Re: Better docs for D (WIP)

[Jacob Carlborg via Digitalmars-d-announce]

On 2016-01-05 15:18, Andrei Alexandrescu wrote:


There's been a recent discussion with Walter and Martin about using
wildcards in makefiles (which would obviate the necessity of being
explicit about files).

My understanding is that build scripts (including makefiles) are
recommended to include a manifest list of files that are part of the
project, as opposed to picking up files with wildcards. That way there's
less likelihood to pick up litter along with the legitimate files, or to
produce incomplete builds if some files are missing by mistake. The
underlying thesis is that that's a good kind of redundancy.


druntime already uses wildcards [1], if I read the makefile correctly, 
in some places.


[1] 
https://github.com/D-Programming-Language/druntime/blob/master/posix.mak#L147-L159


--
/Jacob Carlborg

Re: noob in c macro preprocessor hell converting gsl library header files

[John Colvin via Digitalmars-d-learn]

On Wednesday, 6 January 2016 at 13:36:03 UTC, data pulverizer 
wrote:
I have been converting C numeric libraries and depositing them 
here: https://github.com/dataPulverizer. So far I have glpk and 
nlopt converted on a like for like c function basics. I am now 
stuck on the gsl library, primarily because of the preprocessor 
c code which I am very new to. The following few are 
particularly baffling to me:


#define INLINE_FUN extern inline // used in gsl_pow_int.h: 
INLINE_FUN double gsl_pow_2(const double x) { return x*x;   }


Could I just ignore the INLINE_FUN and use alias for function 
pointer declaration? For example ...


alias gsl_pow_2 = double gsl_pow_2(const(double) x);


Yes, you should be able to ignore INLINE_FUN

double gsl_pow_2(const double x);

is the correct declaration.

#define INLINE_DECL // used in interpolation/gsl_interp.h: 
INLINE_DECL size_t gsl_interp_bsearch(const double x_array[], 
double x, size_t index_lo, size_t index_hi);


I would guess the same as for INLINE_FUN?


yes

#define GSL_VAR extern // used in rng/gsl_rng.h:GSL_VAR const 
gsl_rng_type *gsl_rng_borosh13;


perhaps GSL_VAR can be ignored and I could use:

gsl_rng_borosh13 const(gsl_rng_type)*;


It should be

extern gsl_rng_type* gsl_rng_borosh13;

I have been using these kind of fixes and have not been able to 
get the rng module to recognise the ported functions, meaning 
that something has been lost in translation.


I am currently getting the following error:

$ gsl_rng_print_state

rng_example.o: In function `_Dmain':
rng_example.d:(.text._Dmain+0x13): undefined reference to 
`gsl_rng_print_state'

collect2: error: ld returned 1 exit status

I can't seem to call any of the functions but the types are 
recognized.


Thanks in advance


I think you might have some confusion between function 
declarations:


T myFunction(Q myArg);

function pointer type declarations:

alias MyFunctionPointerType = T function(Q myArg);

and function pointer declarations:

MyFunctionPointerType myFunctionPointer;

Re: Better docs for D (WIP)

[Jacob Carlborg via Digitalmars-d-announce]

On 2016-01-06 05:29, Adam D. Ruppe wrote:


I actually do NOT use wildcards in most of my own makefiles for exactly
these reasons, I tend to keep dead files around.


"git ls-files" should take care of that.

--
/Jacob Carlborg

Re: Hash Tables in D

[Minas Mina via Digitalmars-d-announce]

On Wednesday, 6 January 2016 at 12:19:45 UTC, Jacob Carlborg 
wrote:

On 2016-01-05 15:44, Minas Mina wrote:

It won't, but to use it again you need to allocate a new one 
(If I'm not

mistaken).


Not explicitly. I don't know if the runtime allocates a new 
one. This works:


void main()
{
auto foo = ["foo" : 1];
foo = null;
foo["bar"] = 2;
assert(foo["bar"] == 2);
}


I believe it does, check out this example:
import std.stdio;

class C
{
int[int] squares;
}

void main()
{
auto squares = [0 : 0, 1 : 1];

C c = new C();
c.squares = squares;

writeln(c.squares is squares); // true

squares = null;
squares[10] = 100;
writeln(c.squares is squares); // false
}

If the runtime used the same underlying memory, the second 
writeln() would print true, right?

So if I am correct, a new AA is allocated.

Re: Evolutionary Programming!

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 6 January 2016 at 13:08:46 UTC, Guillaume Piolat 
wrote:

Sure some systems use cutting edge techniques and management.


I think Jason brought up the idea that programmers by tradition 
think a particular way and this probably will delay change IMO. 
Pushing Mythical Man Month and Moore's law can steer what people 
believe is possible or should happen, like a self-fulfilling 
prophecy (we believe it is true, and therefore act in ways that 
makes it true).


But... maybe hardware changes will force a shift in tradition, 
then it will be easier to establish completely new practices. The 
industry will probably try to uphold Moore's law, by increasing 
the number of cores. At some point that will force a change 
(using 100  actors/agents instead of 1 monolithic program). I 
hope.



Maybe I'm oblivious to that since I was born in late 80s.


I think we all take SQL for granted, but relational databases was 
a major shift in data modelling/implementation. And NoSQL is 
major step back as a database tech (back to hierarchical database 
structures), but still a leap forward in a cloud setting compared 
to using a regular file system. So... what is technological 
advance? Depends on what it replaces, not only the tech.


In some ways I think we still haven't catched up in significant 
numbers with some of what Brookes proposed. Like the Surgical 
Team http://c2.com/cgi/wiki?SurgicalTeam (original article is 
worth reading). Such an organization definately happens but I'd 
by accident.


Oh yes, methodology should be different from team to team based 
on problem area, people involved, organization... The "no silver 
bullet" holds there, which is useful for students, since process 
consultants sell "the one true way" (the process they know) as 
universal. E.g. I think "agile" often just means "no methodology, 
but we still have a little bit of structure".


I think methodology and programming languages aren't really 
comparable entities. The "no silver bullet" claim holds for 
methodology, I agree. For programming languages... not a silver 
bullet, but you can get a long way with high quality "forks", 
"knives" and "spoons".


Currently we have rusty knives, we have to be careful or we cut 
our tongues. The Haskell crowd are eating with bent tea spoons, 
lucky guys... ;)

Nothrow front() when not empty()

[Nordlöw via Digitalmars-d-learn]

At

https://github.com/D-Programming-Language/phobos/pull/3752

it would be nice if

return !haystack.empty && haystack.front.unaryFun!pred

was made nothrow.

Is this possible somehow?

Re: Evolutionary Programming!

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 6 January 2016 at 10:49:45 UTC, Ola Fosheim Grøstad 
wrote:
On Wednesday, 6 January 2016 at 10:09:57 UTC, Guillaume Piolat 
wrote:
Brookes noted long ago that new language design would yield 
diminishing returns: 
http://worrydream.com/refs/Brooks-NoSilverBullet.pdf


That and the fact that hardware/OS vendors have incentive to 
push entrenched languages to developers, I don't see something 
too shocking happening in the language space.


"no silver bullet" is an anecdotal meme from the 80s. The only 
"insight" it provides is that we cannot engineer out the need 
for good designers. That's rather obvious, isn't it?


I guess obvious in hindsight.
The point stands about programming languages: their debut brought 
us order of magnitude improvements, and new PL won't. But i'll 
take the 50% improvement any day of the week of course. :)

Re: Struct Union behavior

[Nicholas Wilson via Digitalmars-d-learn]

On Wednesday, 6 January 2016 at 11:39:44 UTC, Voitech wrote:

Hello, i am new to D language and trying to learn it by coding.
I compile my programs on Xubuntu 14.04 with DMD64 D Compiler 
v2.069.2.
So i have a struct/union which contains two fields representing 
real and string values:


public union Element
{
private real _value;
private string _rawValue;

@property{
real value(){
return _value;
}
void value(real value){
_value=value;
}

}
@property {
ref string rawValue(){
return _rawValue;
}
void rawValue(ref string value){
_rawValue=value;
}

}


public Element opBinary(string op)(Element other){
Element newElement;
real value=mixin("this.value "~op~"other.value");
newElement.value=value;
return newElement;
}

public bool opEquals(Element other){
if(this.rawValue == null && other.rawValue == null){
return this.opEquals(other.rawValue);
}
return this.opEquals(other.value);
}
public bool opEquals(real value){
return this.value==value;
}
public bool opEquals(string rawValue){
return this.rawValue==rawValue;
}

unittest{
Element e1 = {4},e2 ={5};
writeln("e1 is at address: ",);
writeln("e2 is at address: ",);
writeln("e1.value is at address: ",_value);
writeln("e2.value is at address: ",_value);
assert(e1+e2==9);
}

unittest{
Element s1={_rawValue:"+"},s2,s3,s4;
writeln("s1 is at address: ",);
writeln("s2 is at address: ",);
writeln("s3 is at address: ",);
writeln("s1.value is at address: ",_value);
writeln("s2.value is at address: ",_value);
writeln("s3.value is at address: ",_value);
writeln("s4.value is at address: ",_value);
writeln("s1.rawValue ",s1._rawValue);
writeln("s1.value: ",s1._value);
writeln("s2.value: ",s2._value);
writeln("s3.value: ",s3._value);
writeln("s4.value: ",s4._value );
assert(s1!=s2);
}
}

The unit test results are:

e1 is at address: 7FFCEFBA7510
e2 is at address: 7FFCEFBA7520
e1.value is at address: 7FFCEFBA7510
e2.value is at address: 7FFCEFBA7520
s1 is at address: 7FFCEFBA7500
s2 is at address: 7FFCEFBA7510
s3 is at address: 7FFCEFBA7520
s1.value is at address: 7FFCEFBA7500
s2.value is at address: 7FFCEFBA7510
s3.value is at address: 7FFCEFBA7520
s4.value is at address: 7FFCEFBA7530
s1.rawValue +
s1.value: 0.125
s2.value: 4
s3.value: 5
s4.value: 9

Can anyone tell me why s2,s3,s4 have initialized _value field?  
Shouldn't it be collected by GC when first unit test (with 
e1,e2) finishes ? If not how to handle this behavior, to use 
union without preinitialized fields.


Probably because you are accessing uninitialised memory. the 
values 4,5,9 appear in the first unittest and are left on the 
stack. Unions ,unlike structs, do not initialise their fields 
because it does not make sense to do so because the memory 
aliases. This can be observed by looking at the size of element 
(16 bytes) which is less than the size of an array (on 64 bit 
systems) , 2*8 bytes plus size of a real (8 or 10 bytes (x86/64)).


other things unrelated to your question. Things are public by 
default so the 'public's are redundant. strings are arrays so 
(most of the time) don't need ref, as the elements are accessed 
through a pointer.


See also Algebraic for cases (most) when you want to know the 
type of the value of the union.


Comparisons to null should use 'is' expressions

Having _value and _rawvalue as private and then providing getters 
and setters is redundant. the same behaviour can be achieved by 
making the public. getters and setters are for either heaving 
only a getter or calling a function when a field is changed (e.g. 
updating a cache)


Nic

Re: Struct Union behavior

[Voitech via Digitalmars-d-learn]

On Wednesday, 6 January 2016 at 12:25:31 UTC, Nicholas Wilson 
wrote:
Probably because you are accessing uninitialised memory. the 
values 4,5,9 appear in the first unittest and are left on the 
stack. Unions ,unlike structs, do not initialise their fields 
because it does not make sense to do so because the memory 
aliases. This can be observed by looking at the size of element 
(16 bytes) which is less than the size of an array (on 64 bit 
systems) , 2*8 bytes plus size of a real (8 or 10 bytes 
(x86/64)).


[...]


Thank you for your answer it was very helpful :)
Cheers.

Re: What are you planning for 2016?

[Jacob Carlborg via Digitalmars-d]

On 2016-01-05 13:27, Ola Fosheim Grøstad wrote:


3. create web services with vibe.d?


I would like to try for work.


4. run D apps in the cloud?

5. run D apps on mobile?

6. create runtime less programs (games, embedded)?

7. work on the D language/phobos ?


* I'm currently working on native TLS for OS X. Hopefully it will be 
ready soon, if I can manage to solve the remaining bug(s)


* At some point I need to get std.serialization ready
* Get more of the Objective-C support into upstream


8. or something else?


In no particular order:

* JPort, a tool to convert Java to D, for DWT - Not written in D though
* Fixing bugs in the D TextMate grammar, used by GitHub as well
* Enhancing the D TextMate bundle, i.e. adding support for DCD
* Maintaining existing projects, DVM, DStep, DWT

Probably some other stuff I can't recall right now.


What would it take for you to use D instead, or what changes would be
needed for you to move from language X to D?


For work that would mean libraries for connecting to PostgreSQL and 
RabbitMQ. Ideally compatible with vibe.d.


--
/Jacob Carlborg

Re: Nothrow front() when not empty()

[anonymous via Digitalmars-d-learn]

On 06.01.2016 14:52, Nordlöw wrote:

At

https://github.com/D-Programming-Language/phobos/pull/3752

it would be nice if

 return !haystack.empty && haystack.front.unaryFun!pred

was made nothrow.

Is this possible somehow?



try return !haystack.empty && pred(haystack.front);
catch (Exception e) assert(false);


You must be 100% sure that the code cannot actually throw an Exception, 
of course.


Alternatively, you could change `.front` to assert instead of throwing 
an Exception, considering it a programmer error when `.empty` is not 
checked before accessing `.front`.

Re: Hash Tables in D

[Jacob Carlborg via Digitalmars-d-announce]

On 2016-01-05 15:44, Minas Mina wrote:


It won't, but to use it again you need to allocate a new one (If I'm not
mistaken).


Not explicitly. I don't know if the runtime allocates a new one. This works:

void main()
{
auto foo = ["foo" : 1];
foo = null;
foo["bar"] = 2;
assert(foo["bar"] == 2);
}

--
/Jacob Carlborg

Re: Regex benchmarks in Rust, Scala, D and F#

[Daniel Kozak via Digitalmars-d]

On Tuesday, 5 January 2016 at 18:09:54 UTC, deadalnix wrote:

On Tuesday, 5 January 2016 at 17:52:39 UTC, Karthikeyan wrote:

Hi,

Came across this post in rust-lang subreddit about the regex 
benchamrks. Scala surprisingly outperforms D. LDC also gives a 
good advantage for efficiency of D.


http://vaskir.blogspot.ru/2015/09/regular-expressions-rust-vs-f.html


I'm willing to bet the bad result D has come from the use of 
DMD.


Honestly, pushing DMD as the reference implementation cost us 
quite a lot on the PR side of things. D appears to be slower 
that it really is.


not at all:

D(LDC): 5.778s
D(GDC): 5.612s
D(DMD): 5.267s
scalac: 5.748s
rustc: 9.287s

so DMD is the fastest

Re: Google Summer of Code 2016

[Jacob Carlborg via Digitalmars-d]

On 2016-01-05 23:28, Laeeth Isharc wrote:


What do you think about the idea of building higher-level bindings for
Apple mobile + Android as a project, now that the compiler itself is at
a useful stage of development?


D has only basic support for interfacing with Objective-C, there's more 
in the works.


--
/Jacob Carlborg

Re: Proposal: Database Engine for D

[Jacob Carlborg via Digitalmars-d]

On 2016-01-05 18:32, Chris Wright wrote:


Which some people call a DSL, and DSLs were, I understand, something we
were trying to avoid. You get far less readability than you do with plain
D or a SQL string.


The above is plain D. Not sure what you're referring to. And a DSL is 
usually used to increase readability.


Andrei and Walter want to avoid expression templates, not a DSL, as far 
as I understand it.


--
/Jacob Carlborg

Re: Proposal: Database Engine for D

[Marc Schütz via Digitalmars-d]

On Tuesday, 5 January 2016 at 22:12:05 UTC, Mengu wrote:
but as a web developer, i don't mind if i have to type 
User.where("first_name = ? AND age > 27", 
request.POST.get('name')). this will generate the same query 
above. i added the question mark to say the parameters should 
be escaped properly.


As a web developer, I _do_ care, though. For one, I shouldn't 
have to know how the fields are called in the database. But more 
importantly, it isn't composable: in the general case, you can 
not write e.g.


User.joins("other_table ON ...").where("first_name = ? ...");

and expect it to work, because `first_name` could be ambiguous. 
This in turn means that you can't create abstractions, for 
example:


auto users = User
 .onlyMale
 .where(["birthday": Date.today])
 .orderBy!(User.firstName);

Here your query would have to know how male and female users are 
represented in your database, e.g. by an integer, a lowercase 
'm', an uppercase 'M'... Such lack of abstraction can quickly 
make your codebase unmaintainable.

Re: Evolutionary Programming!

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 6 January 2016 at 12:13:37 UTC, Guillaume Piolat 
wrote:

I guess obvious in hindsight.


I think that book is overrated, it was a debate book for the 80s 
where startups sold snake-oil... Yes, lecturers at universities 
toss it to their students for debate, because it was a classic, 
but if you want to dig into actual research on progress then 
Thomas Kuhn's thoughts about paradigm shifts are more relevant.


Basically what happens is that we have certain shifts that enable 
change. Like electricity, radios, CRTs, transistors, LCDs... Or 
right now: cloud computing, SMT solvers, probabilistic 
programming languages or other ideas that can trigger shifts.


We've had several advances that affects software development:

1. Algol (60s)
2. OO (late 60s)
3. Structured programming (60s/70s)
4. Structured analysis, entity modelling (60s/70s)
5. RDBMS (80s)
6. OO methodologies (70-90s)
7. Networked programming (80s)
8. Web (90s)
9. Grid/Cloud computing (2000s)
10. Formal provers (2010s)

The point stands about programming languages: their debut 
brought us order of magnitude improvements, and new PL won't. 
But i'll take the 50% improvement any day of the week of 
course. :)


I am more like 10-20x more productive in Python than in C++... 
;-) Not that I consider Python to be a significant advancement.


We'll probably see a paradigm shift as a result of both a change 
in computing hardware combined with alternative approaches to 
software (like SMT solvers, probabilistic computing, actors).


Our hardware today consists of a lot of packaging, and the 
computing/storage happens on something the size of a small stamp. 
That's pitiful compared to the size of our brain.


Increased complexity requires change. We need robust solutions 
that tolerate human error (so actors, probabilistic computing, 
and proof systems). This is kinda happening already with 
web-services.


Systems are realized in a different way today than in the 80s, 
for sure.

noob in c macro preprocessor hell converting gsl library header files

[data pulverizer via Digitalmars-d-learn]

I have been converting C numeric libraries and depositing them 
here: https://github.com/dataPulverizer. So far I have glpk and 
nlopt converted on a like for like c function basics. I am now 
stuck on the gsl library, primarily because of the preprocessor c 
code which I am very new to. The following few are particularly 
baffling to me:


#define INLINE_FUN extern inline // used in gsl_pow_int.h: 
INLINE_FUN double gsl_pow_2(const double x) { return x*x;   }


Could I just ignore the INLINE_FUN and use alias for function 
pointer declaration? For example ...


alias gsl_pow_2 = double gsl_pow_2(const(double) x);

#define INLINE_DECL // used in interpolation/gsl_interp.h: 
INLINE_DECL size_t gsl_interp_bsearch(const double x_array[], 
double x, size_t index_lo, size_t index_hi);


I would guess the same as for INLINE_FUN?

#define GSL_VAR extern // used in rng/gsl_rng.h:GSL_VAR const 
gsl_rng_type *gsl_rng_borosh13;


perhaps GSL_VAR can be ignored and I could use:

gsl_rng_borosh13 const(gsl_rng_type)*;

I have been using these kind of fixes and have not been able to 
get the rng module to recognise the ported functions, meaning 
that something has been lost in translation.


I am currently getting the following error:

$ gsl_rng_print_state

rng_example.o: In function `_Dmain':
rng_example.d:(.text._Dmain+0x13): undefined reference to 
`gsl_rng_print_state'

collect2: error: ld returned 1 exit status

I can't seem to call any of the functions but the types are 
recognized.


Thanks in advance

Re: Google Summer of Code 2016

[CraigDillabaugh via Digitalmars-d]

On Wednesday, 6 January 2016 at 13:28:56 UTC, Jacob Carlborg 
wrote:

On 2016-01-05 23:28, Laeeth Isharc wrote:

What do you think about the idea of building higher-level 
bindings for
Apple mobile + Android as a project, now that the compiler 
itself is at

a useful stage of development?


D has only basic support for interfacing with Objective-C, 
there's more in the works.


I assume, based on my limited knowledge, that this would likely
be two separate projects then:

- bindings for Android
- bindings for Apple Mobile

Would a GSOC project be helpful in moving the Objective-C work 
forward.

Re: link to C function whose name is a D keyword

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 6 January 2016 at 15:41:27 UTC, Carl Sturtivant 
wrote:

//D that doesn't work:
extern(C) int try(int x);


Try:

pragma(mangle, "try")
extern(C) int try_(int x);

then call it with the udnerscore in D, the linker should tie it 
up thanks to the pragma.

Re: noob in c macro preprocessor hell converting gsl library header files

[data pulverizer via Digitalmars-d-learn]

On Wednesday, 6 January 2016 at 13:59:44 UTC, John Colvin wrote:
#define INLINE_FUN extern inline // used in gsl_pow_int.h: 
INLINE_FUN double gsl_pow_2(const double x) { return x*x;   }


Could I just ignore the INLINE_FUN and use alias for function 
pointer declaration? For example ...


alias gsl_pow_2 = double gsl_pow_2(const(double) x);


Yes, you should be able to ignore INLINE_FUN

double gsl_pow_2(const double x);

is the correct declaration.



#define GSL_VAR extern // used in rng/gsl_rng.h:GSL_VAR const 
gsl_rng_type *gsl_rng_borosh13;


perhaps GSL_VAR can be ignored and I could use:

gsl_rng_borosh13 const(gsl_rng_type)*;


It should be

extern gsl_rng_type* gsl_rng_borosh13;


I see. Thanks.

I think you might have some confusion between function 
declarations:


T myFunction(Q myArg);

function pointer type declarations:

alias MyFunctionPointerType = T function(Q myArg);

and function pointer declarations:

MyFunctionPointerType myFunctionPointer;


Sorry in my haste to describe what I was doing I wrote down a 
function pointer instead of a function - my original code was a 
function. Your suggestion of looking at the 
https://github.com/abrown25/gsld library is a good call. I'll 
probably end up sending a pull request to that library after 
using it as a basic outline of how to deal with these 
preprocessors.

Re: link to C function whose name is a D keyword

[Carl Sturtivant via Digitalmars-d-learn]

On Wednesday, 6 January 2016 at 15:42:34 UTC, Adam D. Ruppe wrote:
On Wednesday, 6 January 2016 at 15:41:27 UTC, Carl Sturtivant 
wrote:

//D that doesn't work:
extern(C) int try(int x);


Try:

pragma(mangle, "try")
extern(C) int try_(int x);

then call it with the udnerscore in D, the linker should tie it 
up thanks to the pragma.


Very handy! Thank you.

[Issue 15520] New: Phobos Pull Requests Should Have Automatic Coverage Statistics

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15520

  Issue ID: 15520
   Summary: Phobos Pull Requests Should Have Automatic Coverage
Statistics
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

Ifs it's with coveralls.io or some other service, on each Phobos PR, the
reviewers should be able to see the impact the PR has on the coverage
percentage. This would allow for a "ratchet" effect, where no loss in
percentage is accepted and any decrease must be first offset by a larger
increase in percentage covered.

--

Re: Better docs for D (WIP)

[Adam D. Ruppe via Digitalmars-d-announce]

On Wednesday, 6 January 2016 at 10:25:50 UTC, Martin Nowak wrote:
We already have a nice and powerful documentation generator 
called ddox.


You say that like I've never hard of it before, when I've spent 
quite a few words over the last ten days writing up my critiques 
of it, including both bugs and questioning its fundamental 
approach.


I guess I'll write more about it. I really wish you guys would 
actually read the arguments you're replying to though before 
posting. This is very frustrating and contrary to popular belief, 
I'm not a saint with infinite patience.



https://github.com/rejectedsoftware/ddox
It also contains an experimental libdparse based input (rather 
than relying on dmd's json ouput).


I confess I didn't actually know it had that (it has zero 
mention... anywhere outside the source)... though the fact that 
it is there actually strengthens my position! Look at the ddox 
issues list, marked external. Those are from dmd... but they 
aren't all bugs. The JSON isn't just for docs, and when there's a 
trade off between doc and whatever else people use the json for, 
the doc side often loses.


e.g.:
https://github.com/rejectedsoftware/ddox/issues/19

Apparently, the ddox team agrees with me that being wed to dmd is 
a flawed approach.



Though, looking at its source, it doesn't actually use libdparse 
for much beyond the basics - just getting enough to feed into the 
existing core, which reflects its preference for the inferior 
json, and it appears to be stalled there. It is still limited by 
its initial decision of going down the dmd route.



It is flexible enough to be templated/styled very differently


That's trivial. Even the worst html file is flexible enough to be 
templated/styled very differently because that's part of html's 
core nature.



the project is actively maintained


With about 1/3 of its github bugs still open, including about 
half its open bugs more than one year old. About half its D 
bugzilla bugs are still open, including ones over 2 1/2 years old.


I know projects get bugs open when they are used, but ddox is a 
one-person project and that one person doesn't seem terribly 
active in it.


https://github.com/rejectedsoftware/ddox/graphs/contributors


Looking at the bug list, lol:
https://issues.dlang.org/show_bug.cgi?id=14608

It was open for six months without so much as a comment. The 
thing Andrei is asking for and Sonke agrees is a good model... is 
exactly the way I did mine the first time.


http://dpldocs.info/experimental-docs-2/std.algorithm.searching.OpenRight.html



And yes, yes, I'm sure if I spent 60 hours on ddox over this 
Christmas instead of on my new system, some of those bugs would 
be closed. But I betcha I would have hit some annoying wall and 
instead spent the time on my paying job or something (I do have a 
big tax bill looming and probably should be doing paying work!), 
so that's all hypothetical.


And when I did open a pull request, it'd probably sit there for 
over two months without comment like the other ones that are open 
right now. I'd have to fork the site anyway to get any changes 
live!


ddox compatible tools can easily be integrated with dub, and 
whatever you want to change for template constraints should be 
easy to achieve.


The template constraint formatting is just the beginning.

link to C function whose name is a D keyword

[Carl Sturtivant via Digitalmars-d-learn]

Hello,

Is there a way from D to do this, without writing a C wrapper?

e.g. I want to call a C function named 'try'.

/* C prototype */
int try(int x);

//D that doesn't work:
extern(C) int try(int x);

Re: Redesign of dlang.org

[welkam via Digitalmars-d]

On Wednesday, 6 January 2016 at 11:35:12 UTC, anonymous wrote:
Also check out http://d-ag0aep6g.rhcloud.com/ where I'm 
currently working on the implementation. It's a little 
different from the mockup, precisely because I'm trying not to 
drop features/content.


I am aware of your work. I will finish my "meditation" tomorrow 
and let you know

Re: Redesign of dlang.org

[welkam via Digitalmars-d]

On Thursday, 24 December 2015 at 06:43:32 UTC, Andrei 
Alexandrescu wrote:
Currently dlang.org has over 62KLOC of Ddoc source, so any 
significant surgery on it will be a large effort. Dropping ddoc 
means we'd need to use another templating engine (getting back 
to raw html would be too much trouble), and 10 people have 11 
ideas about which template engine is used by "everyone".


Because using text editor that can auto complete html is too much 
to ask?
From what I saw most Ddoc is used to make simple html tags like 
$(P text) is translated to text so running few regex 
replace should fix that. Unless there are some macros that are 
more advanced.


When the alternate documentation was introduced using vibe.d, 
my hope was that everybody would be all over it like a cheap 
white suit on rice


What skills web developers have: html/css, javascript, PHP, 
MySQL, Apache.


What skills are needed for dlang.org: CSS, javascript, make 
files, ddoc, D, dub, Vibe.d and its own way of generating html.


Not to mention that dlang has unique way of generating static 
html pages


You are not making it more accessible by adding one more 
technology that is not usually used for web development.


Here is how various languages are embedded in html
PHP:  or 
Ruby on rails: <% code %>
Django(python): {% code %}
Hack: Why cant D be used like all other web languages? (rhetorical 
question)


It would be nice if there were possibility of writing html with 
 in html and with structure like this:








and rdmd.dd could be found in folder views/Compilers/

this way any PHP, Ruby, Python, Hack developer could just look at 
dlang.org project and feel at home.


Todays system might not be terrible, but lack of documentation 
was a deal breaker for me. I wanted to fiddle with website layout 
and here how it went.


Welkam followed instructions and successfully generated html 
files. Why welkam needed to compile new dmd is not clear. Then 
welkam opened dlang.org folder. He saw 155 items and sighed. 
Anyway he wanted to edit documentation so the mess didnt bothered 
too much so he opened 
/home/welkam/D/dlang.org/dpl-docs/source/app.d. "I need to look 
at posix.mak to better understand how this page is built" - he 
said, but after looking at mak file he got more confused, because 
he doesnt understand make language. Welkam gave up and decided 
that editing html of one page would be easier for him and if he 
created something useful he would ask some help implementing it.

[Issue 15093] optimize slist_reset

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15093

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com

--- Comment #1 from John Colvin  ---
I did some testing building phobos and slist_reset is a no-op for approx.
99.95% of the symbols it iterates over.

Another possible approach, perhaps a bit complicated/intrusive: hide the reset
members of Symbol behind getters/setters, have a global reset counter, with a
cache in each Symbol, Symbols reset all relevant members in any getter/setter
if the counter is larger than their cached value, then cache the current
counter. slist_reset increments the counter.

--

Custom type creation guidelines

[rumbu via Digitalmars-d-learn]

Let's suppose that I want to implement a custom arithmetic type. 
Looking through phobos at Complex, BigInt, HalfFloat, Variant, 
etc, there is no consistent or idiomatic way to implement various 
operators or functions on custom types.


1) Regarding unary operator overloading, what's the best way to 
implement them?


auto ref opUnary(string op)() if (op == "+") { ... }
auto ref opUnary(string op : "+")() if (op == "+") { ... }
auto ref opUnary(string op)() { static if (op == "+") { } else 
... }


2) Regarding binary operator overloading, question 1 apply also, 
but there is more: what's the best signature?


ref T opBinary(string op, T)(auto const ref T rhs) { ... }
inout(T) opBinary(string op, T)(inout(T) rhs) { ... }
ref T opBinary(string op, T)(T rhs) { ... }

3) Regarding comparison operators:
- is there a way to have the same result for != and == (similar 
to float nans)
- is there a way to return the same result for <, <=, >=, > 
(similar to float nans)

- is there a way to overload float comparison operators?

4) regarding casting:
- we have opCast(T) to convert my custom type to type T. Is there 
any method to overload the casting operation from a built in 
type, e.g. cast(MyType)(int)?


5) Any other guidelines?

Thanks.

link to C++ function in a namespace whose name is a D keyword

[Carl Sturtivant via Digitalmars-d-learn]

Hello,

From D I want to call e.g.

/* C++ prototype */
namespace ns {
int try(int x);
}

without writing a C or C++ wrapper.

Presumably the following D doesn't work, because it doesn't 
mangle the name as if it's in the namespace ns.


pragma(mangle, "try") extern(C++, ns) int try_(int x);

So how to I get correct mangling here?

Re: link to C++ function in a namespace whose name is a D keyword

[Ali Çehreli via Digitalmars-d-learn]

On 01/06/2016 10:35 AM, Carl Sturtivant wrote:

Hello,

 From D I want to call e.g.

/* C++ prototype */
namespace ns {
 int try(int x);
}

without writing a C or C++ wrapper.

Presumably the following D doesn't work, because it doesn't mangle the
name as if it's in the namespace ns.

pragma(mangle, "try") extern(C++, ns) int try_(int x);

So how to I get correct mangling here?



This looks like an oversight to me. I tried the following workaround but 
it uses D mangling scheme:


import core.demangle;

// PROBLEM: No way of saying "mangle C++ name".
pragma(mangle, mangle!(int function(int))("ns::body"))
extern(C++, ns)
int body_(int x);

void main() {
assert(ns.body_(42) == 42);
}

And yes, 'try' is a C++ keyword as well; so I moved to 'body. :)

Ali

[Issue 15389] extern(C++) forward referencing problem

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15389

--- Comment #6 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/8399e29190a31746f695ae517cc28ec29806ae8a
Merge pull request #5330 from WalterBright/fix15389

fix Issue 15389 - extern(C++) forward referencing problem

--

Re: D runs on watchOS! and on Android Wear too!

[Dan Olson via Digitalmars-d-announce]

Laeeth Isharc  writes:

> I can confirm that D also runs on Android Wear (Huawei watch) and
> passes all unit tests.  Forgive the slight hijack, but I mention this
> here as people might see this thread and not the obscure one where I
> reported this previously.

I think it is a good hijack!

> Somebody should do a blog post about this (and how to get it to work
> step by step - it's easy when you know how, but the set of people that
> don't and would like to but will get stuck is quite large).

For watchOS, soon there will be a binary release of cross compiler with
phobos and will have instructions like I have for the iOS release.

What is holding me up is I still am trying to decide how to manage
multiple releases (iOS, tvOS, and watchOS) since the libraries are all
different but the compiler is the same. It doesn't fit the mold but I'd
like to have a single bin with multiple libs.

> I might have a commercial use for this in coming months (both on
> Android and watchOS).  Since it's an internal application the rough
> edges are of less concern to me than if one expects 100,000+ users.

Laeeth, note that app store approval may be a ways off since they want
to use their own LLVM to compile bitcode and I have patches not in
official LLVM. If you only need to side load watchOS, then you will soon
be good to go.

> Wrappers for everything would help a lot (and then some tutorials) - I
> guess the Apple stuff is under way.

The D Objective-C interface is not in LDC yet and I think what is in dmd
so far only supports a subset (instance method calls I think).  There
are other ways, depending on what you need to do, but right know it
seems best to do all the UI stuff in Swift or Objective-C and use D for
everything else.

-- 
Dan

Re: Proposal: Database Engine for D

[Gianni Pisetta via Digitalmars-d]

On Monday, 4 January 2016 at 17:36:20 UTC, Piotrek wrote:
Thanks! So at least one more soul believing that D can approach 
the SQL expressiveness in db domain.


Cheers
Piotrek


Some time ago I had the same idea as yours. IMHO, no D to SQL is 
really needed for this, and the same goes for relational 
databases. My idea was to initially build a DB as library, using 
graph databases as starting point, where the metadata is defined 
only one time in the code. The query methods must allow easy 
access not only to the data, but also to the relations defined 
from object to object. As a starting point you must be able to do 
something like this:


// Stores are where the data is saved
auto localStore = FileStore!Endian.littleEndian( "some_file_name" 
); // Local file


// load() and save() on objects of type User uses this store.
User.setDefaultStore( localStore );

User user = new User();

user.name = "John";
user.password = sha1( "password" );

// Uses the default store
auto localId = user.save();
// Uses the store specified as argument
auto otherId = user.save( someOtherStore );

// load the object from the default store
User localUser = User.load( localId );
// load the object from the network store
User otherUser = User.load( someOtherStore, otherId );

// Ideally users where the last login is older than one year 
using the networkStore

auto oldUsers = User.all( someOtherStore )
  .filterUsing!(User.lastLogin, (lastLogin) => lastLogin < ( now 
- 1.year ) );


// Select the first user that match userName and hashedPassword 
in the default store, with a challenge-response login

auto loginUser = User.all.
  .filterUsing!(User.name, (name) => name == userName )
  .filterUsing!(User.password, (pass) => hmac( pass, key ) == 
hashedPassword )

  .onlyOne();

Gianni Pisetta

Re: extern(C++, ns)

[Walter Bright via Digitalmars-d]

Found and fixed another fwd ref problem with circular imports:

  https://github.com/D-Programming-Language/dmd/pull/5333

This one had nothing to do with C++ namespaces; it showed up for structs and 
classes, too. This implies that the current design is sound, and a redesign is 
not necessarily desirable.

Re: Better docs for D (WIP)

[Jacob Carlborg via Digitalmars-d-announce]

On 2015-12-28 21:15, Adam D. Ruppe wrote:

Last week, I posted in the general forum my dream for better D docs.
Today, about 4 days of work later, I'm about 1/4 of the way there.

Still a long way to go, but I've already come so far.

First, behold my old dpldocs.info site. Yes, it is still up and now it
ties into my new docs! You can use it to quickly jump to a doc given its
name:

http://dpldocs.info/


BTW, do you know of Harbored [1] and a fork of it [2]? It's 
documentation generator for D by Brian that uses libdparse.


[1] https://github.com/economicmodeling/harbored
[2] https://github.com/kiith-sa/harbored-mod

--
/Jacob Carlborg

Re: Google Summer of Code 2016

[Jacob Carlborg via Digitalmars-d]

On 2016-01-06 15:49, CraigDillabaugh wrote:


Would a GSOC project be helpful in moving the Objective-C work forward.


I'm not sure if it's a good fit for a GSOC project. The implementation 
is basically done, it just needs to be upstreamed.


--
/Jacob Carlborg

Re: Better docs for D (WIP)

[Andrei Alexandrescu via Digitalmars-d-announce]

On 01/06/2016 07:27 AM, Jacob Carlborg wrote:

On 2016-01-06 05:29, Adam D. Ruppe wrote:


I actually do NOT use wildcards in most of my own makefiles for exactly
these reasons, I tend to keep dead files around.


"git ls-files" should take care of that.


Thanks, Jacob I think this is a great idea. If anyone would like to 
initiate replacing some uses of file lists with git ls-files, please go 
ahead. And it should work on Windows, too.


The remaining issue is that that makes the makefile assume git is 
installed. Is that reasonable?



Andrei

Re: Better docs for D (WIP)

[Andrei Alexandrescu via Digitalmars-d-announce]

On 01/06/2016 08:50 AM, Jacob Carlborg wrote:

druntime already uses wildcards [1], if I read the makefile correctly,
in some places.


Yes, it recently caused Walter some headache because he had a stray 
file. I think your git ls-files idea would work a lot better. -- Andrei

Re: Catching C++ Exceptions in D

[Andrei Alexandrescu via Digitalmars-d]

On 01/05/2016 06:56 PM, Walter Bright wrote:

On 1/5/2016 1:30 PM, Jakob Ovrum wrote:

On Tuesday, 5 January 2016 at 17:23:38 UTC, Walter Bright wrote:

At the exit of a catch clause, the destructor on the caught C++
exception will
be run, as would be expected by C++ programmers.


Does this work with rethrow? What if a D exception is thrown from a
C++ catch
block - will the C++ exception still be destroyed properly?



My understanding is that rethrow invokes the copy constructor, so the
original can still be destroyed.


To clarify what C++ does, consider:

try { ... }
catch (std::exception& e)
{
   throw e;
}

This throws a copy of e and is almost always not the desired/expected 
behavior because the original dynamic type of e (which may be a class 
derived from std::exception) is lost. Now consider:


try { ... }
catch (std::exception& e)
{
   throw;
}

In this case no copy is created. The same exact dynamic object continues 
to be thrown up the chain.



Andrei

Re: TIOBE December 2015 - D rose 5 positions

[Joakim via Digitalmars-d]

On Tuesday, 5 January 2016 at 16:54:32 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 5 January 2016 at 15:20:53 UTC, Joakim wrote:
D probably should aim for a lower ceiling and keep focus on 
"advanced features". Go and Swift will try to stay "dumbed 
down", like Java and C# to remain attractive to businesses that 
want low in-house training.


Swift is dumbed down?  I'm surprised you started off by saying 
that 80%/GC is the big market, but now believe D should be 
"advanced."


Swift3 probably will try to get closer to C though. Apple seems 
to be focused on making C less frequently needed.


So they too will try to straddle both horses!

Straddling both those horses appears to be the plan, taking 
D's strength in 80%/GC and crossing over into low-level engine 
dev with @nogc and C++ integration.  Rather than splitting the 
domains as you say Apple wants to, by complementing Swift with 
C, I think the plan with D is to offer one language that does 
both, ie a general-purpose low- to mid-level language.


Well... not sure how that works out. High risk! Hardware is 
changing too. Runtimes/semantics can easily become obsolete 
(inefficient) on new platforms. A reason to keep standard 
libraries light.


Keeping things simple is good... Better to have 2 simple 
languages than 1 big. Then you can replace 1 component when the 
environment changes.


Traditionally, it's been C and C++.  I could see D providing a 
lighter version that went after C, especially in embedded, while 
the current version competes with C++.


The situation for Apple is a bit different since they control 
both hardware and software. Meaning, they can build in their 
own Swift2Metal compiler if they want to...


I think Swift could go after that market, but they too will 
probably have to add C++ integration to do it.


C++ is not big on the official iOS and OS-X frameworks. You 
essentially have Objective-C and C as the legacy platform and 
Swift and Metal with Objective-C compatible runtime as the 
modern platform.


Objective-C++ is really only for binding to portable code from 
other platforms.


We're talking cross-platform here, Swift isn't even in the game 
till they get on other platforms than OSX/iOS.


It's not a significant enough source of revenue for them, I 
doubt they care.


$100 per developer per platform + 30% is a pretty hefty charge. 
I don't trust the current Apple CEO... Steve Jobs was more 
"hacker" oriented IMO.


Yeah, but do they break 5% of yearly revenue on that?  Probably 
not, it's some small portion of the little purple chunk showing 
Services revenue in this chart:


http://www.asymco.com/2015/08/26/much-bigger-than-hollywood/

That's why I don't think they care.  They just do it because 
they're disciplined about extracting money where they can.  
They're not trying to maximize it by killing competition, 
especially because such anti-competitive moves could spook devs 
and maybe even some users, which might affect the all-important 
iPhone cash cow.


Profit margins on hardware will drop as Android hardware become 
commoditized. This is a typical trend. Margins go down over 
time if you avoid monopolies and requirements stay the same. 
And battery life and physical size limits requirements.


This is happening to some extent to Android OEMs but not to the 
iPhone, which has maintained its margins while selling millions 
more every year.  Apple does it by continually staying at the top 
of the performance heap, with their in-house designed custom ARM 
cores blowing away the benchmarks year after year and paying top 
dollar for the best components, like cameras, flash storage, and 
fingerprint sensors.


So, iPhone is a gold-mine today, but more like a copper-mine  
in 10 years? I guess flexible and unbreakable plastic phones 
could be the next step, foldable LCDs are here already. 
Popularity of fashion items are kinda bell-shaped (or 
something). 10 years ago BIG SUVs were fashionable. Right now 
Teslas are fashionable here in Norway... Just for show off, I 
think. :-/ Kinda like JavaScript frameworks!


People have been predicting Apple's downfall for years, while 
they grew to become the largest company on earth!  Of course, 
they have to level off and fall eventually, but who knows when?


The v8 compiler has certainly helped javascript on the server, 
but like I said, practically every language will be able to 
run the same code with WebAsm, and they'll have a _lot_ more 
code already running on the server.


Well. I think we will see legacy applications wrapped up in 
suitable containers and stuck into the cloud in maintenance 
mode while new projects go new routes. Fast interconnects 
(local networking) and fast compute nodes makes it possible to 
continue development in a new language and integrate software 
across machines... I think.


Maybe, but I don't see them willingly choosing javascript. :)

You can email him and take those issues up with him.  I was 
only linking it for the conclusion, 

Re: Better docs for D (WIP)

[Jacob Carlborg via Digitalmars-d-announce]

On 2016-01-06 17:37, Andrei Alexandrescu wrote:


The remaining issue is that that makes the makefile assume git is
installed. Is that reasonable?


I think so at least.

--
/Jacob Carlborg

Re: Better docs for D (WIP)

[Andrei Alexandrescu via Digitalmars-d-announce]

On 01/05/2016 01:34 PM, JohnCK wrote:

On Tuesday, 5 January 2016 at 18:09:57 UTC, Andrei Alexandrescu wrote:

Is the recent http://wiki.dlang.org/Contributing_to_dlang.org along
the lines of what you need? What other sort of documentation would you
find useful?


I took a look at that link, and you know what would be (at least for me)
more useful?

A "Let's write a doc example", for example: Creating a sample function
and documented it, step by step. I really think that would be many times
more useful and you see that pattern a lot not only for docs, but
explain things, currently we saw this in another topic about writing a
scalable chat using vibe.d!


Thanks, that's a neat idea - will keep in mind! -- Andrei

Re: Better watch out! D runs on watchOS!

[Dan Olson via Digitalmars-d-announce]

Joakim  writes:

> On Thursday, 31 December 2015 at 00:11:34 UTC, Dan Olson wrote:
>> On Wednesday, 30 December 2015 at 23:11:06 UTC, Joakim wrote:
>>> That sounds like this issue I ran into with ARM EH:
>>>
>>> https://github.com/ldc-developers/ldc/issues/489#issuecomment-143560075
>>>
>>> I was able to work around it by disabling the mentioned llvm
>>> optimization pass:
>>>
>>> https://gist.github.com/joakim-noah/1fb23fba1ba5b7e87e1a#file-android_tls-L42
>>>
>>> https://gist.github.com/joakim-noah/63693ead3aa62216e1d9#file-ldc_android_arm-L3133
>>
>> Yup, that's exactly it!  The approach I took was to leave
>> optimization on, removed the casts, and byte load the data into the
>> uint vars.  If the dwarf data is not guaranteed to be aligned to the
>> data type, then I think this is the approach to take.
>
> Sounds good, submit a PR and let's get it in.

https://github.com/ldc-developers/druntime/pull/51

Re: Redesign of dlang.org

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 6 January 2016 at 17:18:08 UTC, deadalnix wrote:

Good, everybody want to get away from this. This was a mistake.


quoted for truth

Re: Better docs for D (WIP)

[Adam D. Ruppe via Digitalmars-d-announce]

On Wednesday, 6 January 2016 at 17:10:01 UTC, Jacob Carlborg 
wrote:

BTW, do you know of Harbored [1]


Yes, I wrote about it in the TWiD link in the snipped section of 
the parent post.


In fact, until Monday, my generator actually imported a few 
modules directly from Harbored to handle things like documented 
unittests and attributes listing. (I have since refactored it, 
which happened to remove that dependency. That actually wasn't my 
goal; it was just a nice side effect of the simplified code. I 
still use the copy/pasted attributes code from harbored though, 
and still give Brian Schott huge credit for making my thing 
possible.)




and a fork of it [2]?


I did not know about that fork though. Looking at it, it falls in 
the same category to me though: good, but not great. I want 
something great.

Re: Better docs for D (WIP)

[Adam D. Ruppe via Digitalmars-d-announce]

On Tuesday, 5 January 2016 at 18:09:57 UTC, Andrei Alexandrescu 
wrote:

Again this goes back to Adam.


It occurs to me, looking at the status quo, that a single point 
of failure is more robust than several points of failure in 
series.


/library/ depends on the dlang.org, Phobos, and ddox.

dlang.org depends on nobody really knows who owns it, but it 
seems to be you.


Phobos depends on a few different people, making it the most 
reliable in the group, but it is still practically coupled to dmd.


ddox depends on Sonke and dmd (practically).

dmd depends on Walter.


Any any person in that component drops the ball, the /library/ 
code gets stalled. The fix might get into ddox but not on the 
website. It might depend on something in Phobos. It might need 
dmd's output to change.



With my system, it is all under my control. As supreme 
god-emperor of my domain, my server, my phobos fork, my 
generator, my parser fork, and my work process, yes, you'd be in 
a bit of trouble if I went away (though pretty soon you'll just 
be able to fork it yourselves in that event).


But at least I'm never blocked by someone else's problems.


Let's say we had a contributor Eve who'd gladly take emailed 
questions and suggestions and integrate them. Would that be as 
nice?


Poor Eve, on the other hand, would be often blocked by somebody 
else outside her control.

Re: std.experimental.logger formal review round 3

[Bastiaan Veelo via Digitalmars-d]

On Tuesday, 6 January 2015 at 16:51:26 UTC, Robert burner Schadek 
wrote:

please review


Two small doc issues on 
http://dlang.org/phobos/std_experimental_logger.html


"The LogLevel of an log call" -> "[...] a log call"

"[...] or The additional f enables printf-style logging" missing 
parts of a preceding sentence?


Bastiaan.

Re: Redesign of dlang.org

[Jacob Carlborg via Digitalmars-d]

On 2016-01-06 15:35, welkam wrote:


You are not making it more accessible by adding one more technology that
is not usually used for web development.

Here is how various languages are embedded in html
PHP:  or 
Ruby on rails: <% code %>
Django(python): {% code %}
Hack:  in html and with structure like this:








https://vibed.org/templates/diet

--
/Jacob Carlborg

Re: extern(C++, ns)

[Carl Sturtivant via Digitalmars-d]

On Wednesday, 6 January 2016 at 05:14:30 UTC, Carl Sturtivant 
wrote:


OK, I'm going to state the obvious here in the hope it will be 
considered afresh. :)


On Sunday, 3 January 2016 at 17:53:38 UTC, Walter Bright wrote:
5. I don't share the opinion that a C++ namespace introducing 
a scope, just as it does in C++, is something weird and 
unexpected.


Wait a second: D has modules with clever import rules and no 
global scope to manage name collisions instead of namespaces. 
See the bullet here under "features to drop from C++":

http://dlang.org/overview.html#features_to_drop

What's now going on is the reintroduction of this dropped 
feature in a way that is at cross purposes to the underlying D 
language philosophy.


In the end the disputed difficult comes down to this:
extern(C++, ns1) int fn(int x);
and
extern(C++, ns2) int fn(int x);
have different mangled names but the same D-source name. They 
also have the same C++ source name.


In the C++ source this collision is averted by namespaces. In 
the D source where the namespace mechanism has been designed 
out in favor of the module mechanism, this collision should be 
averted using the module mechanism.


If you still believe you want to be able to place the colliding 
externals in the same module, i.e. not use D's collision 
avoidance mechanism, what's needed is simply the ability to 
have two different D source names for the two functions 
specified in the two declarations. This is just a name change, 
not an entire new scope with all the complexity that would 
entail in the namespace situation.


Perhaps there's a way to do this in D already: how do you link 
to a C function whose name is 'new' or some other D keyword?


In any case, drawing a distinction between the D source name 
and the C++ source name (or the external source name in 
general) in the external declaration would do the job. e.g.


extern(C++, ns1, fn) int fn1(int x);
extern(C++, ns2, fn) int fn2(int x);

In each case the external declaration has enough information to 
compute the mangled name and attach it to a D source name 
without collision.


My opinion: Injecting C++ bad design into D in the name of 
linkage is wrong, ugly, and over complicated. I don't think the 
alternative mechanism suggested in the preceding paragraph or 
anything similar is necessary either, since D modules are the 
replacement for namespaces in going from C++ to D, and they can 
do the job. But something like that alternative is a lot less 
awful.


A clean design for external C++ linkage that handles namespaces 
could simply involve extending #pragma(mangle,...) to take a 
quoted namespace. This keeps extern() simple as a purely 
linkage/mangling related qualification, as expected, with no 
extra scope simulating a namespace being introduced.


A name collision in the existing machinery,
extern(C++,ns1) int fn(int x);
extern(C++,ns2) int fn(int x);
could instead be a compiler error, and be averted by e.g. the 
following new mechanism.


#pragma(mangle, "fn", "ns1")
extern(C++) int fn1(int x);

#pragma(mangle, "fn", "ns2")
extern(C++) int fn2(int x);

Maybe the C++ namespace's name could be permitted either quoted 
in the pragma as above (so that names that are D keywords can be 
accommodated) or implicitly taken up by the pragma from the 
external declaration as in the following.


#pragma(mangle, "fn")
extern(C++, ns1) int fn1(int x);

#pragma(mangle, "fn")
extern(C++, ns2) int fn2(int x);

Of course most of the time this wouldn't be used, because the 
offending declarations can be placed in different D modules. So 
then linkage to C++ is handled like linkage to C, simply!

Re: Better docs for D (WIP)

[Adam D. Ruppe via Digitalmars-d-announce]

On Wednesday, 6 January 2016 at 16:37:24 UTC, Andrei Alexandrescu 
wrote:
The remaining issue is that that makes the makefile assume git 
is installed. Is that reasonable?


I hate to be the one to say this, but I don't think it is 
reasonable in the packaged release. In the dev version, 
absolutely, but the packaged release is not a git repository, but 
still includes the makefile...


However, let's not let the release compromise the development. 
The release generation script can run git ls-files itself and do 
some string replacement in the relevant files.

Re: Redesign of dlang.org

[deadalnix via Digitalmars-d]

On Wednesday, 6 January 2016 at 14:35:13 UTC, welkam wrote:

Here is how various languages are embedded in html
PHP:  or 
Ruby on rails: <% code %>
Django(python): {% code %}
Hack: 

Good, everybody want to get away from this. This was a mistake.

[Issue 15519] Circular imports leads to fwd ref error with aliased imports

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15519

--- Comment #1 from Walter Bright  ---
https://github.com/D-Programming-Language/dmd/pull/5333

--

[Issue 15519] Circular imports leads to fwd ref error with aliased imports

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15519

Walter Bright  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=15389

--

[Issue 15389] extern(C++) forward referencing problem

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15389

Walter Bright  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=15519

--

[Issue 15519] New: Circular imports leads to fwd ref error with aliased imports

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15519

  Issue ID: 15519
   Summary: Circular imports leads to fwd ref error with aliased
imports
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

--- y.d
import x: NS = ns;  // fails
//import x; alias x.ns NS;  // works

extern(C++, ns)
{
 class Y { NS.X v; }
}

--- x.d
import y;
extern(C++, ns)
//struct ns
{
 class X { y.ns.Y v; }
}

---

dmd -c y.d

--

Re: Redesign of dlang.org

[welkam via Digitalmars-d]

On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg 
wrote:
[1] 
http://forum.dlang.org/thread/ejpuwwlutklvlozyf...@forum.dlang.org
[2] 
http://forum.dlang.org/thread/fdbnecqbemseocwzg...@forum.dlang.org

[3] http://www.googledrive.com/host/0B7UtafxGD9vESlB3aFBxcjNPOXM


This reminded me when at work we got new design in html/css and 
had to put it on the site. It looked better but lacked 1/3 of 
fields and functionality. Then backend developers had to fix 
design and in the end it was better than before but not as good 
as html/css from designer.


I think its a good start, but needs some layout changes. IMHO 
"Why D?" should be almost at the top or near code sample. I will 
meditate on it.

Type properties

[ric maicle via Digitalmars-d-learn]

Why is init allowed to be redefined but not sizeof?

dmd 2.069

import std.stdio;

struct Foo {
static int init = 5;
static int sizeof = 0;
}

void main()
{
writeln(Foo.init);
writeln(Foo.sizeof);
}

Error: variable integer.Foo.sizeof .sizeof property cannot be redefined

Re: Type properties

[ric maicle via Digitalmars-d-learn]

On Wednesday, 06 January, 2016 04:01 PM, ric maicle wrote:

Why is init allowed to be redefined but not sizeof?

dmd 2.069

import std.stdio;

struct Foo {
 static int init = 5;
 static int sizeof = 0;
}

void main()
{
 writeln(Foo.init);
 writeln(Foo.sizeof);
}

Error: variable integer.Foo.sizeof .sizeof property cannot be redefined


Found this

https://issues.dlang.org/show_bug.cgi?id=7066

Calling functions from other files/modules

[Namal via Digitalmars-d-learn]

Hello,

finally I want to learn how to do it right and I tried to 
understand it from here


https://en.wikibooks.org/wiki/D_(The_Programming_Language)/d2/Modules

But I have a few questions. Do I have always to include std.stdio 
in every file like in the example or is it enough just to import 
a module which has this already included?


Why do I need to define my main as the main module? I can't 
imagine that I can import it somewhere else.


Is there something like #pragma once that needs to be done?

Re: Is there a good lib out there to handle large integer of know size ?

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 6 January 2016 at 22:18:48 UTC, deadalnix wrote:

Won't do the 160 bits case


Now that I think of it, wideint could be used as a base for fixed 
point and 160 bit integers, much like unsigned BigInt is 
implemented with signed BigInt (or perhaps it's the other way 
around).


I've tried with 
https://github.com/d-gamedev-team/gfm/blob/master/math/gfm/math/fixedpoint.d but it's limited.

Re: Calling functions from other files/modules

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 6 January 2016 at 22:06:32 UTC, Namal wrote:
Do I have always to include std.stdio in every file like in the 
example or is it enough just to import a module which has this 
already included?


In every file that you use it, yes. Module imports are private to 
the module (well, unless you specifically mark them as public) 
which is different than C includes.


Why do I need to define my main as the main module? I can't 
imagine that I can import it somewhere else.


You can import it as long as you define it!


Is there something like #pragma once that needs to be done?


no need

Re: Is there a good lib out there to handle large integer of know size ?

[deadalnix via Digitalmars-d]

On Wednesday, 6 January 2016 at 21:57:13 UTC, Guillaume Piolat 
wrote:

On Wednesday, 6 January 2016 at 21:25:45 UTC, deadalnix wrote:
In my case, I'm interested in 160 and 256 bits integers. Using 
BigInt seems wasteful as I know the integer size I want. Do we 
have something like this around ?


https://github.com/d-gamedev-team/gfm/blob/master/math/gfm/math/wideint.d

public domain. Slow division. Only power-of-2 bits supported.


That is awesome ! Won't do the 160 bits case, but I can deal with 
that. Did you consider this as a worthy addition to phobos ? I 
think it is.

Re: Is there a good lib out there to handle large integer of know size ?

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 6 January 2016 at 22:18:48 UTC, deadalnix wrote:
On Wednesday, 6 January 2016 at 21:57:13 UTC, Guillaume Piolat 
wrote:

On Wednesday, 6 January 2016 at 21:25:45 UTC, deadalnix wrote:
In my case, I'm interested in 160 and 256 bits integers. 
Using BigInt seems wasteful as I know the integer size I 
want. Do we have something like this around ?


https://github.com/d-gamedev-team/gfm/blob/master/math/gfm/math/wideint.d

public domain. Slow division. Only power-of-2 bits supported.


That is awesome ! Won't do the 160 bits case, but I can deal 
with that. Did you consider this as a worthy addition to phobos 
? I think it is.


Well I've never ever used them after writing. Perhaps should be 
in their own dub package. Need wideint literals at a minimum!

Re: String interpolation

[cym13 via Digitalmars-d-learn]

On Wednesday, 6 January 2016 at 23:30:22 UTC, Guillaume Piolat 
wrote:
Is there a fancy way to have some kind of string interpolation 
in D?


Other than std.format.format that is?

Re: About Immutable struct members and arrays.

[anonymous via Digitalmars-d-learn]

On 06.01.2016 23:04, Jack Applegame wrote:

import std.algorithm;

struct Bar {
 const int a;
 int b;
}

void main() {
 Bar[1] arr;
 Bar bar = Bar(1, 2);
 bar[0].b = 4;


Assuming you meant `arr[0].b = 4;`. Just overwriting the mutable part of 
bar[0] is ok, of course.



 move(bar, arr[0]);   // ok


I consider it a bug that this compiles. You're overwriting immutable 
data, which shouldn't be possible (without casting). 
https://issues.dlang.org/show_bug.cgi?id=15315



 arr[1] = bar;// fail, why?


Assuming you meant `arr[0] = bar;`.

The error message isn't too bad here: "Error: cannot modify struct 
arr[0] Bar with immutable members". You're trying to overwrite immutable 
data, that's not allowed.



 move(Bar(1, 2), arr[0]); // fail, why source parameter isn't auto ref?


I'm not sure about the details. Maybe it would make sense for `move` to 
accept rvalues, maybe not. Breaking immutable is certainly not a good 
reason to do it, though.



}

About Immutable struct members and arrays.

[Jack Applegame via Digitalmars-d-learn]

import std.algorithm;

struct Bar {
const int a;
int b;
}

void main() {
Bar[1] arr;
Bar bar = Bar(1, 2);
bar[0].b = 4;
move(bar, arr[0]);   // ok
arr[1] = bar;// fail, why?
move(Bar(1, 2), arr[0]); // fail, why source parameter isn't 
auto ref?

}

Re: Is there a good lib out there to handle large integer of know size ?

[H. S. Teoh via Digitalmars-d]

On Wed, Jan 06, 2016 at 09:57:13PM +, Guillaume Piolat via Digitalmars-d 
wrote:
> On Wednesday, 6 January 2016 at 21:25:45 UTC, deadalnix wrote:
> >In my case, I'm interested in 160 and 256 bits integers. Using BigInt
> >seems wasteful as I know the integer size I want. Do we have
> >something like this around ?
> 
> https://github.com/d-gamedev-team/gfm/blob/master/math/gfm/math/wideint.d
> 
> public domain. Slow division. Only power-of-2 bits supported.

Looks nice.  With a bit of work, it could be a potential Phobos addition
IMO.


T

-- 
Perhaps the most widespread illusion is that if we were in power we
would behave very differently from those who now hold it---when, in
truth, in order to get power we would have to become very much like
them. -- Unknown

Re: Is there a good lib out there to handle large integer of know size ?

[Andrei Alexandrescu via Digitalmars-d]

On 1/6/16 5:18 PM, deadalnix wrote:

On Wednesday, 6 January 2016 at 21:57:13 UTC, Guillaume Piolat wrote:

On Wednesday, 6 January 2016 at 21:25:45 UTC, deadalnix wrote:

In my case, I'm interested in 160 and 256 bits integers. Using BigInt
seems wasteful as I know the integer size I want. Do we have
something like this around ?


https://github.com/d-gamedev-team/gfm/blob/master/math/gfm/math/wideint.d

public domain. Slow division. Only power-of-2 bits supported.


That is awesome ! Won't do the 160 bits case, but I can deal with that.
Did you consider this as a worthy addition to phobos ? I think it is.


Yes, we need to add that to phobos. Who could be the champion? -- Andrei