Re: D 2015/2016 Vision?

[bitwise via Digitalmars-d]

On Friday, 9 October 2015 at 05:21:13 UTC, Andrei Alexandrescu 
wrote:

On 10/9/15 4:47 AM, bitwise wrote:
On Thursday, 8 October 2015 at 17:21:52 UTC, Andrei 
Alexandrescu wrote:

On 10/8/15 5:59 PM, bitwise wrote:
With DIP74, the ref counting is hard coded into the type 
itself.


I think that should be the case. -- Andrei


Can you comment on the status of the next vision document?


The H1 vision document has had some effectiveness albeit 
limited. I'll discuss outlook with Walter during our road trip, 
and plan to update it when we get back. -- Andrei


Any news on this?

 Bit

Re: [OT] LLVM Community Code of Conduct

[Vladimir Panteleev via Digitalmars-d]

On Saturday, 17 October 2015 at 23:42:01 UTC, Walter Bright wrote:

On 10/17/2015 2:24 PM, Vladimir Panteleev wrote:
I wish the extent of platform support for GDC and LDC was 
clearer. I
decided not to list any platforms on D's download page unless 
support

for those platforms was rock-solid and is expected to work.

At least at that time, iOS and Android support, as I 
understood it, was
in the "well, if you download this thing some guy uploaded to 
his
personal website and patch that file and don't do this thing 
which
doesn't work yet, you might get a "hello world" that runs from 
the
terminal if you SSH in" ballpark. I'm not sure we should be 
advertising
support for any platform at that level. Personally, I feel 
that if a
platform/architecture is listed on a language's download page, 
I should
be able to download the compiler and build a fully-working 
application
within a few minutes, and as I understand we are nowhere close 
to that
yet. I don't feel particularly strong about this, but if we do 
decide to
lower the bar, then we should reconsider all the other 
platforms that
have been left out (such as the long list of GDC architectures 
which I
understood Iain to say that, well, since the build succeeds 
and Debian
successfully packages it, then it has to work. I might be 
wrong, though,
which is my point exactly - there is really insufficient 
information
about what exactly one can expect to work on each 
platform/architecture

(and their combinations).


I think it'll be alright if these are clearly marked as 
unofficial and alpha quality, and perhaps with a blurb with 
some details on what it's state actually is, like "compiles 
hello world".


Should all this really be on the download page, though? There's 
like a score platforms/architectures/combinations of such between 
all compilers combined.


Have you looked at the linked wiki page?

http://wiki.dlang.org/Compilers

I'm not sure we should essentially be copying that table to 
dlang.org.


I think we are good as we are right now. There is an "others" 
link on the download page, so people interested in support for 
less common or less supported platforms can find said information 
on the wiki.

[Issue 15220] New: [REG2.065] std.getopt parses -o=value as "=value"

[via Digitalmars-d-bugs]

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

  Issue ID: 15220
   Summary: [REG2.065] std.getopt parses -o=value as "=value"
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P3
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: thecybersha...@gmail.com

/ test.d /
import std.getopt;

void main()
{
string[] args = ["program", "-o=str"];
string o;
getopt(args, "o", );
assert(o == "str");
}
//

Introduced in https://github.com/D-Programming-Language/phobos/pull/1779

This broke invoking catdoc.d from dlang.org's win32.mak.

--

[Issue 15214] [REG2.065.0] ICE in Mangler::mangleFunc

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com
Summary|ICE in Mangler::mangleFunc  |[REG2.065.0] ICE in
   ||Mangler::mangleFunc

--- Comment #1 from Vladimir Panteleev  ---
In 2.064.2, this caused an error during semantic analysis:

test.d(2): Error: function has no effect in expression (__lambda1)

Since 2.065.0, this causes a segfault or ICE.

Introduced in https://github.com/D-Programming-Language/dmd/pull/2961

--

[Issue 15215] Erroneous error messages in to!IntegralType conversions

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Vladimir Panteleev  ---
https://github.com/D-Programming-Language/phobos/pull/3728

--

Re: 0 in version number?

[Shriramana Sharma via Digitalmars-d]

bitwise wrote:

> touch f1.098
> touch f1.099
> touch f1.1.0
> touch f1.1.1
> ls

Sorry don't understand what you are getting at...

-- 
Shriramana Sharma, Penguin #395953

Re: 0 in version number?

[bitwise via Digitalmars-d]

On Sunday, 18 October 2015 at 02:26:22 UTC, Shriramana Sharma 
wrote:

bitwise wrote:


touch f1.098
touch f1.099
touch f1.1.0
touch f1.1.1
ls


Sorry don't understand what you are getting at...


Not sure what you're getting at either.

Re: 0 in version number?

[Shriramana Sharma via Digitalmars-d]

bitwise wrote:

> Not sure what you're getting at either.

By `ls -v1` I was illustrating that directory listing utilities are capable 
of sorting numbers meaningfully, so there is no need for leading zeroes for 
*that* purpose...

-- 
Shriramana Sharma, Penguin #395953

Re: 0 in version number?

[Shriramana Sharma via Digitalmars-d]

Shriramana Sharma wrote:

> Major versions zero are often used to
> indicate that the API is not yet stable and minor versions don't guarantee
> API stability. Since that's true for Phobos, where we don't have a stable
> versioning system yet, the zero as the major version number (ignoring the
> language version 2) is correct in a way, I guess.

Looks like SemVer (http://semver.org/) already mentions this:

"""Major version zero (0.y.z) is for initial development. Anything may 
change at any time. The public API should not be considered stable."""

But "initial development", really!

https://wiki.qt.io/Qt-Version-Compatibility

-- 
Shriramana Sharma, Penguin #395953

Re: [OT] LLVM Community Code of Conduct

[Andrei Alexandrescu via Digitalmars-d]

On 10/18/15 2:57 AM, Vladimir Panteleev wrote:

I think we are good as we are right now. There is an "others" link on
the download page, so people interested in support for less common or
less supported platforms can find said information on the wiki.


Mobile support is huge, and one of the first things people ask about D. 
If ldc supports mobile platforms, that tidbit should be mentioned FRONT 
AND CENTER.


Again: I didn't know it! People ask me about mobile support all the time 
and I'm telling them "not yet".



Andrei

Re: Walter Bright, Scott Meyers and me live on the most watched morning show in Romania

[Ali Çehreli via Digitalmars-d-announce]

On 10/17/2015 02:36 AM, Andrei Alexandrescu wrote:

use Google Translate for the text).


Ok, let's try it: His name is Andrei Alexandrescu - and is famous as 
"novel from Facebook".


:)

Ali

Re: Phobos still being statically linked in?

[Adam D. Ruppe via Digitalmars-d]

On Saturday, 17 October 2015 at 10:00:20 UTC, Shriramana Sharma 
wrote:
Is this still true as it seems to be? If so, how do I tell 
dmd/ldc2 not to do that, but to use the available SO at:


I'm not sure about ldc but the dmd option 
`-defaultlib=libphobos2.so` should do it. I think ldmd also works 
with that.

[Issue 15218] DMD should link dynamically to libphobos by default

[via Digitalmars-d-bugs]

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

--- Comment #3 from Shriramana Sharma  ---
(In reply to Adam D. Ruppe from comment #1)
> Phobos changes with every release. All executables compiled before an update
> will now be liable to break.

A valid point, obviously which I didn't think of. Am I then correct in assuming
that Phobos doesn't guarantee ABI stability as in """Minor releases are
backwards binary and source compatible."""
(https://wiki.qt.io/Qt-Version-Compatibility)?

Very well – this means the request should be postponed till such a date that
DMD starts doing stable versioning...

(In reply to Iain Buclaw from comment #2)
> Agreed.  This is not a bug on our side, more it is a decision given to the
> package maintainers for various OS's.

How is it a decision for package maintainers? In my experience, package
maintainers don't like to fiddle with the default behaviour of software.

--

Re: Fastest JSON parser in the world is a D project

[rsw0x via Digitalmars-d-announce]

On Wednesday, 14 October 2015 at 07:01:49 UTC, Marco Leise wrote:
JSON parsing in D has come a long way, especially when you look 
at it from the efficiency angle as a popular benchmark does 
that has been forked by well known D contributers like Martin 
Nowak or Sönke Ludwig.


[...]


Slightly OT:
You have a std.simd file in your repo, was this written by you or 
is there a current std.simd proposal that I'm unaware of?

[Issue 15215] Erroneous error messages in to!IntegralType conversions

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com
   Assignee|nob...@puremagic.com|thecybersha...@gmail.com

--

[Issue 15124] Order By Number Of Downloads On code.dlang.org

[via Digitalmars-d-bugs]

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

--- Comment #3 from Vladimir Panteleev  ---
The issue is not with obtaining the data, but getting it displayed.

--

[Issue 15124] Order By Number Of Downloads On code.dlang.org

[via Digitalmars-d-bugs]

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

--- Comment #2 from Jack Stouffer  ---
Amazon doesn't give you any analytics? If not, is there any software that
tracks the number of times a file has been read?

--

Re: [OT] LLVM Community Code of Conduct

[rsw0x via Digitalmars-d]

On Sunday, 18 October 2015 at 04:05:59 UTC, Andrei Alexandrescu 
wrote:

On 10/18/15 2:57 AM, Vladimir Panteleev wrote:
I think we are good as we are right now. There is an "others" 
link on
the download page, so people interested in support for less 
common or

less supported platforms can find said information on the wiki.


Mobile support is huge, and one of the first things people ask 
about D. If ldc supports mobile platforms, that tidbit should 
be mentioned FRONT AND CENTER.


Again: I didn't know it! People ask me about mobile support all 
the time and I'm telling them "not yet".



Andrei


The mobile support in LDC is at best, shaky.
being neglected here>

Re: [OT] LLVM Community Code of Conduct

[Walter Bright via Digitalmars-d]

On 10/17/2015 2:03 PM, Andrei Alexandrescu wrote:

On 10/17/15 7:55 PM, Joakim wrote:

On Saturday, 17 October 2015 at 16:38:29 UTC, Andrei Alexandrescu wrote:

Fantastic!

Could you please send a PR to upgrade http://dlang.org/download.html
so it lists the iOS and (later) Android downloads? Even I didn't know
ldc has an iOS download! -- Andrei


Will do.  Support for both platforms is at the alpha stage, but doesn't
hurt to get more hands on them, and the fact that pretty much all of the
druntime and phobos tests pass mean they're in reasonably good shape.


Great - thanks! -- Andrei



This is all very good news!

Re: [OT] LLVM Community Code of Conduct

[Walter Bright via Digitalmars-d]

On 10/17/2015 2:24 PM, Vladimir Panteleev wrote:

I wish the extent of platform support for GDC and LDC was clearer. I
decided not to list any platforms on D's download page unless support
for those platforms was rock-solid and is expected to work.

At least at that time, iOS and Android support, as I understood it, was
in the "well, if you download this thing some guy uploaded to his
personal website and patch that file and don't do this thing which
doesn't work yet, you might get a "hello world" that runs from the
terminal if you SSH in" ballpark. I'm not sure we should be advertising
support for any platform at that level. Personally, I feel that if a
platform/architecture is listed on a language's download page, I should
be able to download the compiler and build a fully-working application
within a few minutes, and as I understand we are nowhere close to that
yet. I don't feel particularly strong about this, but if we do decide to
lower the bar, then we should reconsider all the other platforms that
have been left out (such as the long list of GDC architectures which I
understood Iain to say that, well, since the build succeeds and Debian
successfully packages it, then it has to work. I might be wrong, though,
which is my point exactly - there is really insufficient information
about what exactly one can expect to work on each platform/architecture
(and their combinations).


I think it'll be alright if these are clearly marked as unofficial and 
alpha quality, and perhaps with a blurb with some details on what it's 
state actually is, like "compiles hello world".

[Issue 15220] [REG2.065] std.getopt parses -o=value as "=value"

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Vladimir Panteleev  ---
https://github.com/D-Programming-Language/phobos/pull/3727

--

Re: Sub-classing exceptions

[Jonathan M Davis via Digitalmars-d]

On Saturday, 17 October 2015 at 18:00:06 UTC, Temtaime wrote:

Checked exceptions are a lie.


??? This thread has been about declaring exception classes (many 
of which have exactly the same constructors and how it's annoying 
to have to duplicate that boilerplate). You're the first to 
mention anything about checked exceptions, and I don't see what 
it has to do with the discussion.


- Jonathan M Davis

[Issue 15207] [REG2.069b2] Wrong codegen with -inline

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

Summary|Wrong codegen with -inline  |[REG2.069b2] Wrong codegen
   ||with -inline

--

Re: 0 in version number?

[Shriramana Sharma via Digitalmars-d]

Shriramana Sharma wrote:

> I always wondered why DMD releases have a 0 in their minor version number
> -- surely 2.068 is the same as 2.68? Why then retain the zero?

BTW the Deb packages show the zero as a separate field in the SO versioning:

/usr/lib/x86_64-linux-gnu/libphobos2.so.0.68.2
/usr/lib/x86_64-linux-gnu/libphobos2.so.0.68

So what is that zero supposed to indicate now?!

Heh, it's actually sorta appropriate. Major versions zero are often used to 
indicate that the API is not yet stable and minor versions don't guarantee 
API stability. Since that's true for Phobos, where we don't have a stable 
versioning system yet, the zero as the major version number (ignoring the 
language version 2) is correct in a way, I guess.

-- 
Shriramana Sharma, Penguin #395953

Re: D 2015/2016 Vision?

[Andrei Alexandrescu via Digitalmars-d]

On 10/18/15 1:57 AM, bitwise wrote:

On Friday, 9 October 2015 at 05:21:13 UTC, Andrei Alexandrescu wrote:

On 10/9/15 4:47 AM, bitwise wrote:

On Thursday, 8 October 2015 at 17:21:52 UTC, Andrei Alexandrescu wrote:

On 10/8/15 5:59 PM, bitwise wrote:

With DIP74, the ref counting is hard coded into the type itself.


I think that should be the case. -- Andrei


Can you comment on the status of the next vision document?


The H1 vision document has had some effectiveness albeit limited. I'll
discuss outlook with Walter during our road trip, and plan to update
it when we get back. -- Andrei


Any news on this?

  Bit


Still on the road! Thanks for the prod. -- Andrei

Re: [OT] LLVM Community Code of Conduct

[Vladimir Panteleev via Digitalmars-d]

On Sunday, 18 October 2015 at 04:05:59 UTC, Andrei Alexandrescu 
wrote:

On 10/18/15 2:57 AM, Vladimir Panteleev wrote:
I think we are good as we are right now. There is an "others" 
link on
the download page, so people interested in support for less 
common or

less supported platforms can find said information on the wiki.


Mobile support is huge, and one of the first things people ask 
about D. If ldc supports mobile platforms, that tidbit should 
be mentioned FRONT AND CENTER.


Again: I didn't know it! People ask me about mobile support all 
the time and I'm telling them "not yet".


And we're not there yet.

Please correct me if I'm wrong, but as I understand, you'll get 
nowhere on mobile with any current official LDC releases. Saying 
that LDC supports iOS/Android out of the box on dlang.org would 
be false advertising at this point.


I'm not sure what expectations people have when they hear 
"language X supports iOS/Android", but at least as someone who 
hasn't done a lot of mobile development, I'd expect that the 
official compiler can emit code I can call from my app, and get 
it all working in minutes. This would include tutorials of how 
would I compile/link this D code and make it talk to my 
Java/Obj-C/Swift UI code. Again, please correct me if I'm wrong.


Don't get me wrong, I'm as excited about this as anyone, but at 
the same time I don't want people mocking us for claiming support 
when what we have is a proof-of-concept provided by a third-party 
fork.

Re: Fastest JSON parser in the world is a D project

[Brad Anderson via Digitalmars-d-announce]

On Saturday, 17 October 2015 at 09:35:47 UTC, Sönke Ludwig wrote:

Am 17.10.2015 um 13:16 schrieb Marco Leise:

Am Sat, 17 Oct 2015 09:27:46 +0200
schrieb Sönke Ludwig :
Okay, I obviously misread that as a once familiar issue. 
Maybe it indeed
makes sense to add a "JavaScript" quirks mode that behaves 
exactly like

a JavaScript interpreter would.


Ok, but remember: https://www.youtube.com/watch?v=20BySC_6HyY
And then think again. :D



What about just naming it SerializationMode.WAT?


At the very least that needs to be an undocumented alias easter 
egg. :)

[Issue 13624] Parts of the Overview page is very out of date

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/dlang.org/commit/77324039087e9283f40244195857c2f9fd4712eb
partial fix for issue 13624

https://github.com/D-Programming-Language/dlang.org/commit/5019e765fd2d68407cac2fd91927fac4935d371c
Merge pull request #1133 from JackStouffer/issue13624

Fix for issue 13624 (Part 1)

--

[Issue 15212] BigInt should implement opCast!long and opCast!int

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/phobos/commit/9bb4da24561171cf96ea4ca5f090c3be0513653b
fix Issue 15212 - BigInt should implement opCast!long and opCast!int

https://github.com/D-Programming-Language/phobos/commit/06506e407aeb83d569f0a7e01ca54c45920f957c
Merge pull request #3725 from CyberShadow/pull-20151017-003315

fix Issue 15212 - BigInt should implement opCast!long and opCast!int

--

[Issue 15212] BigInt should implement opCast!long and opCast!int

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Mobile support

[Joakim via Digitalmars-d]

On Saturday, 17 October 2015 at 16:49:44 UTC, Chris wrote:

On Saturday, 17 October 2015 at 14:37:46 UTC, Joakim wrote:
Ldc binaries for iOS were announced in July, Dan's now working 
on 64-bit support:


http://forum.dlang.org/thread/m2mvz57seb@comcast.net

Android is pretty much done, just cleaning it up by 
integrating with ldc's CMake build system and other small 
details, announcement coming next week.


Yeah, I remember the announcemment, I was very happy. Is it 
still 2.066 or is it part and parcel of the latest LDC? Your 
efforts are very much appreciated! Thank you guys!


Dan has made available some source for his work on the latest 
LDC, including 64-bit support, but not binaries like he did for 
the previous 2.066 release:


https://github.com/smolt/ldc/tree/ios-merge-2.067

On Saturday, 17 October 2015 at 21:24:34 UTC, Vladimir Panteleev 
wrote:
I wish the extent of platform support for GDC and LDC was 
clearer. I decided not to list any platforms on D's download 
page unless support for those platforms was rock-solid and is 
expected to work.


Sure, makes sense that you did that at the time, we didn't even 
list the betas there till last week.


At least at that time, iOS and Android support, as I understood 
it, was in the "well, if you download this thing some guy 
uploaded to his personal website and patch that file and don't 
do this thing which doesn't work yet, you might get a "hello 
world" that runs from the terminal if you SSH in" ballpark. I'm 
not sure we should be advertising support for any platform at 
that level. Personally, I feel that if a platform/architecture 
is listed on a language's download page, I should be able to 
download the compiler and build a fully-working application 
within a few minutes, and as I understand we are nowhere close 
to that yet. I don't feel particularly strong about this, but 
if we do decide to lower the bar, then we should reconsider all 
the other platforms that have been left out (such as the long 
list of GDC architectures which I understood Iain to say that, 
well, since the build succeeds and Debian successfully packages 
it, then it has to work. I might be wrong, though, which is my 
point exactly - there is really insufficient information about 
what exactly one can expect to work on each 
platform/architecture (and their combinations).


As Walter said, as long as we label it as alpha, we can get 
people playing with it and point out that mobile support is close.


On Saturday, 17 October 2015 at 23:57:06 UTC, Vladimir Panteleev 
wrote:
Should all this really be on the download page, though? There's 
like a score platforms/architectures/combinations of such 
between all compilers combined.


Have you looked at the linked wiki page?

http://wiki.dlang.org/Compilers

I'm not sure we should essentially be copying that table to 
dlang.org.


I think we are good as we are right now. There is an "others" 
link on the download page, so people interested in support for 
less common or less supported platforms can find said 
information on the wiki.


Yes, we shouldn't copy that page, but as Andrei said, the giant 
PR value of mobile support means that even alpha stage support 
for mobile does make sense to add.  I wasn't planning on 
submitting such a PR for the download page, was only going to 
post in the Announce forum, but I think Andrei is right that 
mobile is too important.


On Sunday, 18 October 2015 at 04:13:56 UTC, Vladimir Panteleev 
wrote:

And we're not there yet.

Please correct me if I'm wrong, but as I understand, you'll get 
nowhere on mobile with any current official LDC releases. 
Saying that LDC supports iOS/Android out of the box on 
dlang.org would be false advertising at this point.


We won't say anything about the official ldc/gdc releases.  
Rather, we'll provide links to Dan's iOS binary and one I'll 
provide for Android that'll be for experimental usage.


I'm not sure what expectations people have when they hear 
"language X supports iOS/Android", but at least as someone who 
hasn't done a lot of mobile development, I'd expect that the 
official compiler can emit code I can call from my app, and get 
it all working in minutes. This would include tutorials of how 
would I compile/link this D code and make it talk to my 
Java/Obj-C/Swift UI code. Again, please correct me if I'm wrong.


For those willing to play with alpha/experimental code, I don't 
think such hand-holding is necessary.  Anyway, I'll write up 
another wiki page for ldc, just as I did for dmd:


http://wiki.dlang.org/Build_DMD_for_Android

Don't get me wrong, I'm as excited about this as anyone, but at 
the same time I don't want people mocking us for claiming 
support when what we have is a proof-of-concept provided by a 
third-party fork.


As I said, iOS and Android now pass essentially all tests from 
druntime and phobos.  That's a long way from "hello world."  Is 
it rock solid?  Of course not, but an alpha compiler doesn't need 
to be.

Re: [OT] LLVM Community Code of Conduct

[Vladimir Panteleev via Digitalmars-d]

On Sunday, 18 October 2015 at 04:13:56 UTC, Vladimir Panteleev 
wrote:
Don't get me wrong, I'm as excited about this as anyone, but at 
the same time I don't want people mocking us for claiming 
support when what we have is a proof-of-concept provided by a 
third-party fork.


To elaborate on this a bit... the information on the downloads 
page was written only two months ago, with the collaboration of 
both GDC and LDC maintainers:


https://github.com/D-Programming-Language/dlang.org/pull/1067

Now, unless mobile support has matured significantly in the past 
two months, the point here is that the maintainers themselves 
have not pointed out that they were ready to advertise mobile 
support for their compilers on dlang.org. I don't think we should 
change this without their consent, at least. As I understand, 
development for mobile support is still occurring in a fork, and 
this might result users pestering the maintainers regarding code 
that isn't even in the repository they are maintaining.

Re: Synchronized classes have no public members

[Sean Kelly via Digitalmars-d]

On Tuesday, 13 October 2015 at 11:51:02 UTC, ponce wrote:

On Tuesday, 13 October 2015 at 10:57:55 UTC, Marco Leise wrote:


Yep, I prefer to think it sets of variables that need mutex 
protection. And these are not generally the set of member 
fields in a class.


Exactly. And that makes things using synchronized prone to 
longer and more frequent locks.


Yep. Labeling methods and classes as synchronized and shared is 
mostly for the sake of facilitating static analysis. But I think 
it comes at the cost of good program design. Beyond facilitating 
a direct port of Java code I don't know why you'd use 
synchronized at the method or class level.

Re: [OT] LLVM Community Code of Conduct

[Chris via Digitalmars-d]

On Saturday, 17 October 2015 at 14:37:46 UTC, Joakim wrote:

On Friday, 16 October 2015 at 10:25:07 UTC, Chris wrote:
Apart from that, I think the fact that D is still not fit for 
mobile platforms is a huge drawback. Loads of people want 
apps, loads of people have some sort of smart phone, tablet or 
whatever. Sometimes I think that we're getting sucked in by 
the quick sand of language specs, pointers, GC etc. while 
important issues like targeting mobile platforms are second 
class citizens. Nim for example targeted mobile platforms 
right from the start. So did Go. I cannot recommend D 
wholeheartedly unless it also works on ARM at the click of a 
button. Please correct me if I'm wrong here, but mobile is not 
yet 100%.


Ldc binaries for iOS were announced in July, Dan's now working 
on 64-bit support:


http://forum.dlang.org/thread/m2mvz57seb@comcast.net

Android is pretty much done, just cleaning it up by integrating 
with ldc's CMake build system and other small details, 
announcement coming next week.


Yeah, I remember the announcemment, I was very happy. Is it still 
2.066 or is it part and parcel of the latest LDC? Your efforts 
are very much appreciated! Thank you guys!

Re: Synchronized classes have no public members

[Sean Kelly via Digitalmars-d]

On Friday, 16 October 2015 at 06:49:06 UTC, Dicebot wrote:
On Friday, 16 October 2015 at 06:26:30 UTC, Jacob Carlborg 
wrote:

On 2015-10-15 16:28, Andrei Alexandrescu wrote:

That may be worrisome. Any information on how many are using 
DWT, and

how badly it would break if we pulled the change?

If we assess there's too much breakage, we can define a DIP 
and make the

check opt-in via a flag -dipNN.


I would like to add that the impact of a possible breakage 
depends on what the alternative is. If a function in Phobos or 
druntime is provided with the same functionality, then the 
breakage have less of an impact.


As far as I understand topic is about deprecating direct field 
access of synchronized classes, method calls in synhronized 
classes and `synchronized () {}` blocks will remain untouched.


That clarifies things. It seems a fine idea. I can't think of an 
instance where it would be advisable to have public mutable 
fields in a synchronized class. Immutable or const though, sure.

Re: Synchronized classes have no public members

[Sean Kelly via Digitalmars-d]

On Friday, 16 October 2015 at 21:54:11 UTC, Jonathan M Davis 
wrote:

[...]


std.concurrency.MessageBox is an example of why you might mix 
synchronized and non-synchronized data in a class. No methods are 
synchronized though because it's too blunt an instrument. 
Synchronization happens internally at the statement level.

Re: [OT] LLVM Community Code of Conduct

[Joakim via Digitalmars-d]

On Saturday, 17 October 2015 at 16:38:29 UTC, Andrei Alexandrescu 
wrote:

Fantastic!

Could you please send a PR to upgrade 
http://dlang.org/download.html so it lists the iOS and (later) 
Android downloads? Even I didn't know ldc has an iOS download! 
-- Andrei


Will do.  Support for both platforms is at the alpha stage, but 
doesn't hurt to get more hands on them, and the fact that pretty 
much all of the druntime and phobos tests pass mean they're in 
reasonably good shape.

Re: Example code on D homepage does not run successfully

[NX via Digitalmars-d]

On Saturday, 17 October 2015 at 12:57:25 UTC, Ralph Tandetzky 
wrote:
If I understand this cryptic error message correctly, the 
problem is missing or inadequate input. There is no floating 
point number to be parsed and hence the string "" is parsed 
unsuccessfully which leads to an exception producing this 
horrible error message. I would suggest to fix the program 
quickly, maybe by using a string that is not given at runtime 
through stdin, but as a fixed string like "Pi is approximately 
3.14159265."


It's not because input is empty, but rather that across-web 
compiling is highly broken and problematic. There is an "Input" 
button bottom of the code area which shows what input will be 
given to stdin, which is actually not empty (it's written: "2.4 
plus 2.4 equals 5 for sufficiently large values of 2.")


Maybe one day someone will take care of improving the 
infrastructure...

Re: Beta D 2.069.0-b2

[Marco Leise via Digitalmars-d-announce]

Oh wait, false alert. That was a relic from older days. My
build script placed a dummy dmd.conf there.

I do seem to get problems with ldc2-0.16.0:

  make -C druntime -f posix.mak MODEL=32 
  ../dmd/src/dmd -conf= -c -o- -Isrc -Iimport -Hfimport/core/sync/barrier.di 
src/core/sync/barrier.d
  core.exception.AssertError@expression.d(4369): Assertion failure

That is this line of code:
https://github.com/D-Programming-Language/dmd/blob/v2.069.0-b2/src/expression.d#L4369

Stack trace (with file + line numbers now, hey!):
#0  StringExp::compare(RootObject*) (this=0xb66e30, obj=0xb65c80) at 
expression.d:4341
#1  0x004fb6ed in StringExp::equals(RootObject*) (this=0xb66e30, 
o=0xb65c80) at expression.d:4175
#2  0x004c4fe9 in match(RootObject*, RootObject*) (o1=0xb66e30, 
o2=0xb65c80) at dtemplate.d:246
#3  0x004c51c6 in arrayObjectMatch(Array*, 
Array*) (oa1=0x764aca98, oa2=0x764ac898) at dtemplate.d:290
#4  0x004cddd7 in TemplateInstance::compare(RootObject*) 
(this=0x764aca00, o=0x764ac800) at dtemplate.d:6232
#5  0x004cdaf8 in 
TemplateDeclaration::findExistingInstance(TemplateInstance*, 
Array*) (this=0x764ac600, tithis=0x764aca00, fargs=0x0) at 
dtemplate.d:2039
#6  0x004d2f24 in TemplateInstance::semantic(Scope*, 
Array*) (this=0x764aca00, sc=0x765dfc00, fargs=0x0) at 
dtemplate.d:5583
#7  0x00406877 in TemplateInstance::semantic(Scope*) 
(this=0x764aca00, sc=0x765dfc00) at dtemplate.d:5967
#8  0x0057a03a in TypeInstance::resolve(Loc, Scope*, Expression**, 
Type**, Dsymbol**, bool) (this=0x764ae100, loc=..., sc=0x765dfc00, 
pe=0x7fffcec0, pt=0x7fffcec8, ps=0x7fffceb8, intypeid=false) at 
mtype.d:7412
#9  0x0057a327 in TypeInstance::toDsymbol(Scope*) (this=0x764ae100, 
sc=0x765dfc00) at mtype.d:7459
#10 0x0043c5d6 in AliasDeclaration::semantic(Scope*) 
(this=0x764ae200, sc=0x765dfc00) at .:598
#11 0x004897f9 in Module::semantic() (this=0x76378400) at 
dmodule.d:976
#12 0x00488e0f in Import::semantic(Scope*) (this=0x76a82800, 
sc=0x76aa9c00) at dimport.d:258
#13 0x0042759a in AttribDeclaration::semantic(Scope*) 
(this=0x76a82900, sc=0x76aa9600) at attrib.d:168
#14 0x004897f9 in Module::semantic() (this=0x76a7fe00) at 
dmodule.d:976
#15 0x00488e0f in Import::semantic(Scope*) (this=0x77eca100, 
sc=0x77ed2200) at dimport.d:258
#16 0x0042759a in AttribDeclaration::semantic(Scope*) 
(this=0x77eca200, sc=0x77ecee00) at attrib.d:168
#17 0x004897f9 in Module::semantic() (this=0x77ec9000) at 
dmodule.d:976
#18 0x00567de5 in tryMain(unsigned long, char const**) (argc=8, 
argv=0x7fffe978) at mars.d:1485
#19 0x0056a567 in D main () at mars.d:1695

`sz` is 0, `string` and `len` seem to be ok.

-- 
Marco

Re: opDispatch and compile time parameters

[Meta via Digitalmars-d]

On Saturday, 17 October 2015 at 15:31:00 UTC, Nikolay wrote:
I asked on SO question about opDispatch and compile time 
parameters: 
http://stackoverflow.com/questions/32998781/opdispatch-and-compile-time-parameters


Currently it looks like it is not possible to use opDispatch 
for non trivial template functions. I think opDispatch should 
get function name plus evaluated compile time arguments as 
first compile time parameter. E.g not just function name "b", 
but "b.p2!(int, 10)"  See example from SO question:


import std.stdio;

class B{
auto p1(T)(T arg) {
writeln( "p1: ", arg );
}
auto p2(T, int C)(T s) {
writeln( "p2: ", s, " / ", C);
}
}

class C(T) {
T b = new T;

auto opDispatch(string s, Args...)(Args args) {
   mixin("b."~s)(args);
}
}

void main() {
auto b = new C!(B)();
//fine: compiler is smart enough
b.p1("abc");
//oops: "no property 'p2' for type ..."
b.p2!(int, 10)(5);
auto origB = new B;
//fine:
origB.p2!(int, 10)(5);
}

Is it good idea for opDispatch improvement or may there is some 
other approach?


There is another approach, which is to automatically generate a 
declaration that more or less matches the one in b. Then you can 
call b.p2 or whatever else on the outer class, and it will be 
forwarded to the inner class. The implementation is a lot hairier 
than you might think, but I've got it mostly working now. I've 
been meaning to post an answer to your StackOverflow question, 
but I wanted to be sure that the implementation was complete and 
as bug-free as possible. You can find the code here: 
https://github.com/MetaLang/phobos/commit/6c5fa291a957f4050910064d1fa44a86ff92e760


Basically, you just do `mixin(forwardToMember!(b, "p1", "p2"));` 
inside your wrapper class and it will automatically declare the 
correct methods/properties/aliases for you. Let me know if it 
works for your usecase and I'll post it to StackOverflow as well.

Re: Silicon Valley D Meetup October 22, 2015

[Andrei Alexandrescu via Digitalmars-d-announce]

On 10/17/15 12:35 AM, Ali Çehreli wrote:

We are meeting at Innowest and you are eating pizza! :)

Innowest has graciously accepted to be our venue sponsor going forward:

   http://innowest.org/

Here is the meeting announcement:

   http://www.meetup.com/D-Lang-Silicon-Valley/events/225452180/

Do you have a regular or lightning talk? Please let us know. And please
come to the meeting! :)

Thank you,
Ali


Great. You guys have fun! -- Andrei

Re: Beta D 2.069.0-b2

[extrawurst via Digitalmars-d-announce]

On Saturday, 17 October 2015 at 08:13:03 UTC, Martin Nowak wrote:

On Friday, 16 October 2015 at 12:14:09 UTC, ponce wrote:

What changed in the backend?


http://dlang.org/changelog/2.069.0.html#backend-improvements


Is that limited to "-release" builds ?

[Issue 15213] Unexpected OPTLINK Termination at EIP = 0040347E

[via Digitalmars-d-bugs]

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

Sebastiaan Koppe  changed:

   What|Removed |Added

   Hardware|x86 |x86_64

--

Re: GCC-compatible dmd shell wrapper?

[Shriramana Sharma via Digitalmars-d]

Iain Buclaw via Digitalmars-d wrote:

>> I previously had some serious problems with GDC so never tried that ever
>> again, but dmd, ldmd2 and ldc2 all generally have the same syntax, esp.
>> w.r.t missing -o...
>>
>>
> Where's the bug report?

http://forum.dlang.org/post/mailman.572.1370073456.13711.digitalmars-d-le...@puremagic.com

http://forum.dlang.org/post/mailman.573.1370076049.13711.digitalmars-d-le...@puremagic.com

Both dated 2013-Jun-01.

The initial post I started that thread with was on the previous day: 
http://forum.dlang.org/post/mailman.520.1370020486.13711.digitalmars-d-le...@puremagic.com

And I had even provided a stacktrace at: 
http://forum.dlang.org/post/mailman.551.1370044498.13711.digitalmars-d-le...@puremagic.com

Now I'm scared off of even installing gdc on my system, sorry!

-- 
Shriramana Sharma, Penguin #395953

Re: How is std.regex.replaceAllInto more efficient?

[Shriramana Sharma via Digitalmars-d]

Dmitry Olshansky wrote:

> Feel free to improve on the examples, I'd gladly pull such patches.

How about this, using the "comifying" regex from the replaceAll example:

auto re = ctRegex!(`(?<=\d)(?=(\d\d\d)+\b)`, "g");
auto sink = appender!(char [])();
foreach (line; stdin.byLine())
{
sink.clear();
replaceAllInto(sink, line, re, ",");
writeln(sink.data());
}

-- 
Shriramana Sharma, Penguin #395953

[Issue 3850] Signed/unsigned bytes type name

[via Digitalmars-d-bugs]

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

Shriramana Sharma  changed:

   What|Removed |Added

 CC||samj...@gmail.com

--- Comment #12 from Shriramana Sharma  ---
If the default signage of byte is going to be changed, then I support the
request for tiny/utiny (a very nice choice) or some other /u pair. 

byte would then be aliased to utiny/u and ubyte slowly deprecated and
removed.

I personally haven't had much problem with byte/ubyte, but I can see where it
would be a problem for others.

--

Re: How is std.regex.replaceAllInto more efficient?

[Dmitry Olshansky via Digitalmars-d]

On 17-Oct-2015 13:06, Shriramana Sharma wrote:

Dmitry Olshansky wrote:


Feel free to improve on the examples, I'd gladly pull such patches.


How about this, using the "comifying" regex from the replaceAll example:

 auto re = ctRegex!(`(?<=\d)(?=(\d\d\d)+\b)`, "g");
 auto sink = appender!(char [])();
 foreach (line; stdin.byLine())
 {
 sink.clear();
 replaceAllInto(sink, line, re, ",");
 writeln(sink.data());
 }



My problem with it is writeln/byLine b/c it can't be unittested. 
Documented unit-tests as examples are gold.


On the other hand you can post it to list of example shown on the first 
page of dlang.org because I think it's kind of cool.


Also a variation of this example can be put in std.regex synopsis.

--
Dmitry Olshansky

Re: Error message clarity w.r.t. ref

[Shriramana Sharma via Digitalmars-d]

Jonathan M Davis wrote:

> It takes barely more time to add a bug to bugzilla than it does
> to post in the newsgroup about it

To my pleasant surprise, I found you were right! :-)

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

-- 
Shriramana Sharma, Penguin #395953

Re: Caching of Template Instantiations

[Marc Schütz via Digitalmars-d-learn]

On Saturday, 17 October 2015 at 07:48:39 UTC, Nordlöw wrote:

Does DMD cache template instantiations?


Yes, and it's required by the spec:

"Multiple instantiations of a TemplateDeclaration with the same 
TemplateArgumentList all will refer to the same instantiation."

http://dlang.org/template.html



That is, is it preferred to do, for instance, either

static  if (isIntegral!T && isUnsigned!(T)) {}
else static if (isIntegral!T && isSigned!(T)) {}

or

enum integral = isIntegral!T;
static  if (integral && isUnsigned!(T)) {}
else static if (integral && isSigned!(T)) {}


It *might* make a little difference if you have thousands of 
instantiations, because for each instantiation the compiler needs 
to check whether it has already instantiated the templation with 
that combination of arguments, but I wouldn't worry about it.

Caching of Template Instantiations

[Nordlöw via Digitalmars-d-learn]

Does DMD cache template instantiations?

That is, is it preferred to do, for instance, either

static  if (isIntegral!T && isUnsigned!(T)) {}
else static if (isIntegral!T && isSigned!(T)) {}

or

enum integral = isIntegral!T;
static  if (integral && isUnsigned!(T)) {}
else static if (integral && isSigned!(T)) {}

Re: Fastest JSON parser in the world is a D project

[Martin Nowak via Digitalmars-d-announce]

On Wednesday, 14 October 2015 at 07:35:49 UTC, Marco Leise wrote:

  - Data size limited by available contiguous virtual memory


Mmaping files for sequential reading is a very debatable choice, 
b/c the common use case is to read a file once. You should at 
least compare the numbers w/ drop_caches between each run.

https://github.com/mleise/fast/blob/69923d5a69f67c21a37e5e2469fc34d60c9ec3e1/source/fast/json.d#L1441

Re: 0 in version number?

[Shriramana Sharma via Digitalmars-d]

bitwise wrote:

> 2.100 -> transition here, maintain sortability

Again, what's this about sortability? Raise your hands please whoever is 
using strcmp or the like to do sorting on D version numbers!

-- 
Shriramana Sharma, Penguin #395953

Phobos still being statically linked in?

[Shriramana Sharma via Digitalmars-d]

I went back to see my first post here in the D world two years ago:

http://forum.dlang.org/post/mailman.413.1369930723.13711.digitalmars-d-le...@puremagic.com

I had noted then with surprise that the most basic Hello World program took 
300K+ with rdmd, but now it seems it's much more i.e. 600K+ with dmd (since 
rdmd doesn't seem to leave out any executables any more). ldc2 is much 
better at 300K+ but still doesn't compare to C/C++...

$ cat namaste.d 
import std.stdio;
void main () { writeln("Namaste!"); }
$ dmd namaste.d && ls -l namaste*
-rwxrwxr-x 1 samjnaa samjnaa 645544 Oct 17 15:21 namaste
-rw-rw-r-- 1 samjnaa samjnaa 56 Oct 17 15:20 namaste.d
-rw-r--r-- 1 samjnaa samjnaa  14932 Oct 17 15:21 namaste.o
$ ldc2 namaste.d && ls -l namaste*
-rwxrwxr-x 1 samjnaa samjnaa 346144 Oct 17 15:21 namaste
-rw-rw-r-- 1 samjnaa samjnaa 56 Oct 17 15:20 namaste.d
-rw-rw-r-- 1 samjnaa samjnaa  25456 Oct 17 15:21 namaste.o
$ dmd --version
DMD64 D Compiler v2.068.2
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
$ ldc2 -version
LDC - the LLVM D compiler (0.16.0-beta2):
  based on DMD v2.067.1 and LLVM 3.7.0
  Default target: x86_64-unknown-linux-gnu
  Host CPU: haswell

I was told then 
(http://forum.dlang.org/post/op.wxwn0jys54x...@puck.auriga.bhead.co.uk) that 
the reason was that the library was linked in statically.

Is this still true as it seems to be? If so, how do I tell dmd/ldc2 not to 
do that, but to use the available SO at:

/usr/lib/x86_64-linux-gnu/libphobos2.so.0.68.2

-- 
Shriramana Sharma, Penguin #395953

[Issue 10335] Error messages should have unique ID

[via Digitalmars-d-bugs]

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

Shriramana Sharma  changed:

   What|Removed |Added

 CC||samj...@gmail.com

--

Re: Beta D 2.069.0-b2

[Martin Nowak via Digitalmars-d-announce]

On Friday, 16 October 2015 at 12:14:09 UTC, ponce wrote:

What changed in the backend?


http://dlang.org/changelog/2.069.0.html#backend-improvements

Re: Fastest JSON parser in the world is a D project

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

On Saturday, 17 October 2015 at 08:20:33 UTC, Daniel N wrote:
On Saturday, 17 October 2015 at 08:07:57 UTC, Martin Nowak 
wrote:
On Wednesday, 14 October 2015 at 07:35:49 UTC, Marco Leise 
wrote:

  - Data size limited by available contiguous virtual memory


Mmaping files for sequential reading is a very debatable 
choice, b/c the common use case is to read a file once. You 
should at least compare the numbers w/ drop_caches between 
each run.




It's a sensible choice together with appropriate madvise().


Mmap is very expensive, as it affects all cores, you need a 
realistic multithreaded aync benchmark on smaller files to see 
the effect.

[Issue 15215] New: Erroneous error messages in to!IntegralType conversions

[via Digitalmars-d-bugs]

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

  Issue ID: 15215
   Summary: Erroneous error messages in to!IntegralType
conversions
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: samj...@gmail.com

Using DMD 2.068.2.

Code illustrating problem:

$ cat to_int_error_msg.d
import std.meta, std.conv, std.stdio;
void test(string num)
{
writeln("Testing string: ", num);
foreach(Type; AliasSeq!(ubyte, ushort, uint, ulong, byte, short, int,
long))
{
try to!Type(num);
catch (ConvException e) writefln("to!%-6s : %s", Type.stringof, e.msg);
}
writeln();
}
void main() { foreach (num; ["2A", "-2A", "#2A"]) test(num); }

Output:

$ dmd -run to_int_error_msg.d
Testing string: 2A
to!ubyte  : Unexpected 'A' when converting from type string to type ubyte
to!ushort : Unexpected 'A' when converting from type string to type ushort
to!uint   : Unexpected 'A' when converting from type string to type uint
to!ulong  : Unexpected 'A' when converting from type string to type ulong
to!byte   : Unexpected 'A' when converting from type string to type byte
to!short  : Unexpected 'A' when converting from type string to type short
to!int: Unexpected 'A' when converting from type string to type int
to!long   : Unexpected 'A' when converting from type string to type long

Testing string: -2A
to!ubyte  : Unexpected '2' when converting from type string to type uint
to!ushort : Unexpected '2' when converting from type string to type uint
to!uint   : Unexpected '2' when converting from type string to type uint
to!ulong  : Unexpected '2' when converting from type string to type ulong
to!byte   : Unexpected 'A' when converting from type string to type byte
to!short  : Unexpected 'A' when converting from type string to type short
to!int: Unexpected 'A' when converting from type string to type int
to!long   : Unexpected 'A' when converting from type string to type long

Testing string: #2A
to!ubyte  : Unexpected '2' when converting from type string to type uint
to!ushort : Unexpected '2' when converting from type string to type uint
to!uint   : Unexpected '2' when converting from type string to type uint
to!ulong  : Unexpected '2' when converting from type string to type ulong
to!byte   : Unexpected '2' when converting from type string to type int
to!short  : Unexpected '2' when converting from type string to type int
to!int: Unexpected '2' when converting from type string to type int
to!long   : Unexpected '2' when converting from type string to type long

Observations:

When input is 2A, error messages are fine.

When input is -2A, error messages are fine in case of signed types. In case of
unsigned types, there are two problems:
1) The message should flag the presence of "-" which is illegal in unsigned
types. It instead says "2" is unexpected.
2) The target type is wrongly mentioned as uint when it is actually ubyte or
ushort.

When input is #2A, error messages are not fine at all. The problems are:
1) Again, "2" is flagged as unexpected instead of "#".
2) The target type is wrongly mentioned as before, but now int is displayed for
byte and short too.

--

Re: Fastest JSON parser in the world is a D project

[Daniel N via Digitalmars-d-announce]

On Saturday, 17 October 2015 at 08:07:57 UTC, Martin Nowak wrote:
On Wednesday, 14 October 2015 at 07:35:49 UTC, Marco Leise 
wrote:

  - Data size limited by available contiguous virtual memory


Mmaping files for sequential reading is a very debatable 
choice, b/c the common use case is to read a file once. You 
should at least compare the numbers w/ drop_caches between each 
run.




It's a sensible choice together with appropriate madvise().

[Issue 15214] New: ICE in Mangler::mangleFunc

[via Digitalmars-d-bugs]

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

  Issue ID: 15214
   Summary: ICE in Mangler::mangleFunc
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: anoneu...@gmail.com

Not much to say really:
http://dpaste.dzfl.pl/ea145fd8a4d3

Source:
void main() {
cast(void) x=>mixin(x)("mixin(x);");
};

Output:
[.d(2)] __lambda1 (x)
Assertion failure: '0' on line 384 in file 'mangle.c'

Tested on x86 and x64, DMD 2.068.2 and DMD 2.069

--

Publicly exposing an exception a module throws

[Shriramana Sharma via Digitalmars-d]

If a module's function throws an exception, shouldn't that module publicly 
import that exception? Please observe:

$ cat errnoexception.d
import std.stdio;
//import std.exception;

void main()
{
File file;
try file = File("/non-existent-file");
catch (ErrnoException e) {}
}
$ dmd errnoexception.d
errnoexception.d(8): Error: undefined identifier 'ErrnoException'

Uncommenting the import of std.exception solves the problem, but I believe 
it would make sense to have the exception *publicly* imported into std.stdio 
to avoid having the user to manually import it. Agreed?

(Currently the exception is just thrown in stdio.d by errnoEnforce in l 385 
which is imported at l 383.)

-- 
Shriramana Sharma, Penguin #395953

Re: Fastest JSON parser in the world is a D project

[Sönke Ludwig via Digitalmars-d-announce]

Am 17.10.2015 um 13:16 schrieb Marco Leise:

Am Sat, 17 Oct 2015 09:27:46 +0200
schrieb Sönke Ludwig :

Okay, I obviously misread that as a once familiar issue. Maybe it indeed
makes sense to add a "JavaScript" quirks mode that behaves exactly like
a JavaScript interpreter would.


Ok, but remember: https://www.youtube.com/watch?v=20BySC_6HyY
And then think again. :D



What about just naming it SerializationMode.WAT?

Walter Bright, Scott Meyers and me live on the most watched morning show in Romania

[Andrei Alexandrescu via Digitalmars-d-announce]

D got mentioned as well.

It was an odd succession of events that ultimately had Walter, Scott, 
and myself live at ProTV's morning news.


Walter gives great advice to starting programmers. Here's the video (use 
Google Translate for the text).


http://stirileprotv.ro/ilikeit/smart-things/ilikeit-trei-dintre-cei-mai-mari-programatori-din-lume-invitatii-lui-george-buhnici-sfaturile-romanului-de-la-facebook.html


Andrei

Re: GCC-compatible dmd shell wrapper?

[Iain Buclaw via Digitalmars-d]

On 17 Oct 2015 11:50 am, "Shriramana Sharma via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> Iain Buclaw via Digitalmars-d wrote:
>
> >> I previously had some serious problems with GDC so never tried that
ever
> >> again, but dmd, ldmd2 and ldc2 all generally have the same syntax, esp.
> >> w.r.t missing -o...
> >>
> >>
> > Where's the bug report?
>
>
http://forum.dlang.org/post/mailman.572.1370073456.13711.digitalmars-d-le...@puremagic.com
>
>
http://forum.dlang.org/post/mailman.573.1370076049.13711.digitalmars-d-le...@puremagic.com
>
> Both dated 2013-Jun-01.
>
> The initial post I started that thread with was on the previous day:
>
http://forum.dlang.org/post/mailman.520.1370020486.13711.digitalmars-d-le...@puremagic.com
>
> And I had even provided a stacktrace at:
>
http://forum.dlang.org/post/mailman.551.1370044498.13711.digitalmars-d-le...@puremagic.com
>
> Now I'm scared off of even installing gdc on my system, sorry!
>
> --
> Shriramana Sharma, Penguin #395953

Looking at that backtrace I can only speculate.  Segfault in dso registry -
how stable was dmd's shared library support back then?

If you are certain that it only started segfaulting after installing
gdc-4.6, the only other case to speculate is what was the default gcc
version?

I can't see having two versions of gcc installed being a problem - as what
would have undoubtedly happened if the defaults-gcc package was 4.7 or
later, but I question how dmd did it's linking back then.  It used to call
gcc, but now calls ld directly now though, right?

In any case, dmd shared library support, or linking against a unsupported C
runtime, had the person asked you to run ldd against the broken binary,
probably would have guessed one or the other.

In any case neither directly relate to each other - different library names
different module paths - so I still have doubts over your claims.

The most common reason I'm aware of is having two versions of dmd installed.

But if you are unfamiliar with a package system you always seem to find
ways to break it that don't make much sense.

That's the long answer for "You should not be able to reproduce your
problem should you do the same again, and if you do, I'd eat my hat".

Iain.

[Issue 15216] New: Produce clearer error messages w.r.t. ref

[via Digitalmars-d-bugs]

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

  Issue ID: 15216
   Summary: Produce clearer error messages w.r.t. ref
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: samj...@gmail.com

ref int foo(ref int x) { return x ; }

void main ()
{
foo(3) ;
// Error: function rvalue_argument.foo (ref int x) is not callable using 
argument types (int)
// Comment: "argument ref int x of function rvalue_argument.foo cannot bind 
to an rvalue" would be clearer IMO

int i ;
ref ir = i ;
// Error: variable ref_type.main.ir only parameters or foreach declarations 
can be ref
// Comment: after the variable name add a colon, and add ", return values" 
after "parameters"
}

--

Re: How is std.regex.replaceAllInto more efficient?

[Marc Schütz via Digitalmars-d]

On Saturday, 17 October 2015 at 10:54:19 UTC, Dmitry Olshansky 
wrote:

On 17-Oct-2015 13:06, Shriramana Sharma wrote:

Dmitry Olshansky wrote:

Feel free to improve on the examples, I'd gladly pull such 
patches.


How about this, using the "comifying" regex from the 
replaceAll example:


 auto re = ctRegex!(`(?<=\d)(?=(\d\d\d)+\b)`, "g");
 auto sink = appender!(char [])();
 foreach (line; stdin.byLine())
 {
 sink.clear();
 replaceAllInto(sink, line, re, ",");
 writeln(sink.data());
 }



My problem with it is writeln/byLine b/c it can't be 
unittested. Documented unit-tests as examples are gold.




You can prefix it with `version(StdDdoc)`, then it will only 
appear in the documentation. It won't be really tested of course, 
but the compiler will at least do syntax checking on it, I guess.

Re: Phobos still being statically linked in?

[Marc Schütz via Digitalmars-d]

Yes, it's still linked statically by default, at least with DMD. 
I don't know why this wasn't changed yet, I just tried linking 
against libphobos.so and it worked. The resulting binary is then 
down to 13 Kb, after stripping.


On the topic of executable size, Vladimir Panteleev did some work 
to check it automatically for each version of DMD:


http://blog.thecybershadow.net/2015/05/05/is-d-slim-yet/
http://digger.k3.1azy.net/trend/

to(T, ubyte base) if (isIntegral!T)

[Shriramana Sharma via Digitalmars-d]

Hello. I thought D did not prove the Python facility of being able to handle 
bases 2 to 36 in string to integer conversion on request (there it is 
int(num, base = )), but came upon this toImpl overload:

http://dlang.org/phobos/std_conv.html#.toImpl.5

which provides for a radix to be input. There's also a corresponding parse 
overload.

However, as per the text under http://dlang.org/phobos/std_conv.html#.to:

"Entry point that dispatches to the appropriate conversion primitive. Client 
code normally calls to!TargetType(value) (and not some variant of toImpl)."

... I'm not sure why the toImpl and parse functions are even publicly 
documented. People shouldn't need to know about them.

So given that toImpl is supposed to be internal, shouldn't we have a to! 
function for specifying the base, something like:

T to(T, ubyte base) if (isIntegral!T && 2 <= base && base <= 36)

-- 
Shriramana Sharma, Penguin #395953

Re: Walter Bright, Scott Meyers and me live on the most watched morning show in Romania

[mattcoder via Digitalmars-d-announce]

On Saturday, 17 October 2015 at 09:36:08 UTC, Andrei Alexandrescu 
wrote:

D got mentioned as well.
...


Awesome!

Just a note: the guy in red suit (George Buhnici?), looks like 
you Andrei. :)


Matheus.

Re: The D Language Foundation is now incorporated

[suliman via Digitalmars-d-announce]

Can anybody outside USA join to the foundation?

[Issue 15218] New: DMD should link dynamically to libphobos by default

[via Digitalmars-d-bugs]

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

  Issue ID: 15218
   Summary: DMD should link dynamically to libphobos by default
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: samj...@gmail.com

Since a long time (even of the latest stable release 2.068.2) DMD by default
links in libphobos statically as part of all executables produced by it. AFAICS
C and C++ compilers by default don't link in libc or libstdc++, and I don't see
why DMD (and LDC, perhaps GDC too) is different.

Apart from that this is a needlessly wasteful utilization of user disk space
(though today hard/soft memory may be considered cheap), to the person newly
testing the D waters, it makes it appear as if even a Hello World in D is much
much more bloated than in C/C++/...

Therefore please make it so that DMD (and thus hopefully LDC and GDC too) links
to libphobos dynamically and not statically by default. If any rare need makes
it so that somebody needs a statically linked executable, presumably that would
not be too hard to achieve.

Note: I *don't* think this is a dup of bug 987 which was for D1...

--

[Issue 13656] clarify error message upon trying to declare a variable of type ref

[via Digitalmars-d-bugs]

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

--- Comment #2 from Shriramana Sharma  ---
Hmm... I seemed to have filed bug 13655 separately, but it's closely related to
this one.

--

Re: Phobos still being statically linked in?

[Shriramana Sharma via Digitalmars-d]

Marc Schütz wrote:

> Yes, it's still linked statically by default, at least with DMD.
> I don't know why this wasn't changed yet, I just tried linking
> against libphobos.so and it worked. The resulting binary is then
> down to 13 Kb, after stripping.

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

-- 
Shriramana Sharma, Penguin #395953

what is wrong with this code??

[steven kladitis via Digitalmars-d-learn]

import std.string, std.typecons, std.exception, 
std.algorithm,std.stdio;

import std.traits: hasIndirections;

struct GrowableCircularQueue(T) {
public size_t length;
private size_t first, last;
private T[] A = [T.init];

this(T[] items...) pure nothrow @safe {
foreach (x; items)
push(x);
}

@property bool empty() const pure nothrow @safe @nogc {
return length == 0;
}

@property T front() pure nothrow @safe @nogc {
assert(length != 0);
return A[first];
}

T opIndex(in size_t i) pure nothrow @safe @nogc {
assert(i < length);
return A[(first + i) & (A.length - 1)];
}

void push(T item) pure nothrow @safe {
if (length >= A.length) { // Double the queue.
immutable oldALen = A.length;
A.length *= 2;
if (last < first) {
A[oldALen .. oldALen + last + 1] = A[0 .. last + 
1];

static if (hasIndirections!T)
A[0 .. last + 1] = T.init; // Help for the GC.
last += oldALen;
}
}
last = (last + 1) & (A.length - 1);
A[last] = item;
length++;
}

@property T pop() pure nothrow @safe @nogc {
assert(length != 0);
auto saved = A[first];
static if (hasIndirections!T)
A[first] = T.init; // Help for the GC.
first = (first + 1) & (A.length - 1);
length--;
return saved;
}
}


const struct Board {
private enum El { floor = ' ', wall = '#', goal = '.',
  box = '$', player = '@', boxOnGoal='*' }
private alias CTable = string;
private immutable size_t ncols;
private immutable CTable sData, dData;
private immutable int playerx, playery;

this(in string[] board) immutable
in {
foreach (const row; board) {
assert(row.length == board[0].length,
   "Unequal board rows.");
foreach (immutable c; row)
assert(c.inPattern(" #.$@*"), "Not valid input");
}
} body {
/*static*/ immutable sMap =
[' ':' ', '.':'.', '@':' ', '#':'#', '$':' '];
/*static*/ immutable dMap =
[' ':' ', '.':' ', '@':'@', '#':' ', '$':'*'];
ncols = board[0].length;
writeln("ncols =",ncols);
int plx = 0, ply = 0;
CTable sDataBuild, dDataBuild;

foreach (immutable r, const row; board)
foreach (immutable c, const ch; row) {
sDataBuild ~= sMap[ch];
dDataBuild ~= dMap[ch];
if (ch == El.player) {
plx = c;
ply = r;
}
//   writeln("c ch row ",c," ",ch," ",row);
//   writeln("board =>",board);
}


this.sData = sDataBuild;
this.dData = dDataBuild;
this.playerx = plx;
this.playery = ply;
}

private bool move(in int x, in int y, in int dx,
  in int dy, ref CTable data)
const pure nothrow /*@safe*/ {
if (sData[(y + dy) * ncols + x + dx] == El.wall ||
data[(y + dy) * ncols + x + dx] != El.floor)
return false;

auto data2 = data.dup;
data2[y * ncols + x] = El.floor;
data2[(y + dy) * ncols + x + dx] = El.player;
data = data2.assumeUnique; // Not enforced.
return true;
}

private bool push(in int x, in int y, in int dx,
  in int dy, ref CTable data)
const pure nothrow /*@safe*/ {
if (sData[(y + 2 * dy) * ncols + x + 2 * dx] == El.wall ||
data[(y + 2 * dy) * ncols + x + 2 * dx] != El.floor)
return false;

auto data2 = data.dup;
data2[y * ncols + x] = El.floor;
data2[(y + dy) * ncols + x + dx] = El.player;
data2[(y + 2 * dy) * ncols + x + 2*dx] = El.boxOnGoal;
data = data2.assumeUnique; // Not enforced.
return true;
}

private bool isSolved(in CTable data)
const pure nothrow @safe @nogc {
foreach (immutable i, immutable d; data)
if ((sData[i] == El.goal) != (d == El.boxOnGoal))
return false;
return true;
}

string solve() pure nothrow /*@safe*/ {
bool[immutable CTable] visitedSet = [dData: true];

alias Four = Tuple!(CTable, string, int, int);
GrowableCircularQueue!Four open;
open.push(Four(dData, "", playerx, playery));

static immutable dirs = [tuple( 0, -1, 'u', 'U'),
 tuple( 1,  0, 'r', 'R'),
 tuple( 0,  1, 'd', 'D'),
 tuple(-1,  0, 'l', 'L')];

while (!open.empty) {
//immutable (cur, cSol, x, y) = open.pop;
immutable item = open.pop;
immutable cur = item[0];
immutable cSol = item[1];
immutable x = 

Re: 0 in version number?

[Marc Schütz via Digitalmars-d]

On Saturday, 17 October 2015 at 08:51:05 UTC, Shriramana Sharma 
wrote:

bitwise wrote:


2.100 -> transition here, maintain sortability


Again, what's this about sortability? Raise your hands please 
whoever is using strcmp or the like to do sorting on D version 
numbers!


Sorting happens in many places where the sorting program is not 
aware that it's working with version numbers. Think of directory 
listings, for example.

Re: Walter Bright, Scott Meyers and me live on the most watched morning show in Romania

[Marc Schütz via Digitalmars-d-announce]

On Saturday, 17 October 2015 at 09:36:08 UTC, Andrei Alexandrescu 
wrote:

D got mentioned as well.

It was an odd succession of events that ultimately had Walter, 
Scott, and myself live at ProTV's morning news.


Walter gives great advice to starting programmers. Here's the 
video (use Google Translate for the text).


http://stirileprotv.ro/ilikeit/smart-things/ilikeit-trei-dintre-cei-mai-mari-programatori-din-lume-invitatii-lui-george-buhnici-sfaturile-romanului-de-la-facebook.html


Wow, you're celebrities :-P This is nice publicity!

Off topic: I was surprised that this website doesn't use any 
diacritics, even though it is completely in Romanian. Is this 
usual practice?

Example code on D homepage does not run successfully

[Ralph Tandetzky via Digitalmars-d]

Hi! The following code snippet, that appears on the dlang.org 
homepage does not run successfully:



// Round floating point numbers
import std.algorithm,
std.conv,
std.functional,
std.math,
std.regex,
std.stdio;

// Transforms input into a real number,
// rounds it, then to a string
alias round = pipe!(to!real, std.math.round, to!string);

// Matches numbers that look like they need rounding
static reFloatingPoint = ctRegex!`[0-9]+\.[0-9]+`;

void main(string[] args)
{
// If arguments, process those and exit,
// otherwise wait around for input on stdin
if (args.length > 1)
args[1..$].map!round.joiner(" ").writeln;
else
// Replace anything that looks like a real
// number with the rounded equivalent.
stdin.byLine(KeepTerminator.yes)
 .map!(l => l.replaceAll!(c => c.hit.round)
 (reFloatingPoint))
 .copy(stdout.lockingTextWriter());
}


It produces the following error message.


std.conv.ConvException@/opt/compilers/dmd2/include/std/conv.d(2417): Floating point 
conversion error for input "".

./f838(pure @safe real std.conv.parse!(real, 
immutable(char)[]).parse(ref immutable(char)[])+0x43) [0x4bdd27]
./f838(pure @safe real std.conv.toImpl!(real, 
immutable(char)[]).toImpl(immutable(char)[])+0x26) [0x4bf0f2]
./f838(pure @safe real 
std.conv.to!(real).to!(immutable(char)[]).to(immutable(char)[])+0x20) [0x4bdcdc]
./f838(@safe real 
std.functional.__T7composeS27_D3std4math5roundFNbNiNeeZeS223std4conv9__T2toTeZ2toZ.compose!(immutable(char)[]).compose(immutable(char)[])+0x20) [0x4bdca4]
./f838(@safe immutable(char)[] 
std.functional.__T7composeS253std4conv11__T2toTAyaZ2toS933std10functional67__T7composeS27_D3std4math5roundFNbNiNeeZeS223std4conv9__T2toTeZ2toZ7composeZ.compose!(immutable(char)[]).compose(immutable(char)[])+0x20) [0x4bdc6c]
./f838(@property @safe immutable(char)[] 
std.algorithm.iteration.__T9MapResultS1633std10functional136__T7composeS253std4conv11__T2toTAyaZ2toS933std10functional67__T7composeS27_D3std4math5roundFNbNiNeeZeS223std4conv9__T2toTeZ2toZ7composeZ7composeTAAyaZ.MapResult.front()+0x67) [0x4bffbb]
./f838(ref @safe 
std.algorithm.iteration.joiner!(std.algorithm.iteration.__T9MapResultS1633std10functional136__T7composeS253std4conv11__T2toTAyaZ2toS933std10functional67__T7composeS27_D3std4math5roundFNbNiNeeZeS223std4conv9__T2toTeZ2toZ7composeZ7composeTAAyaZ.MapResult, immutable(char)[]).joiner(std.algorithm.iteration.__T9MapResultS1633std10functional136__T7composeS253std4conv11__T2toTAyaZ2toS933std10functional67__T7composeS27_D3std4math5roundFNbNiNeeZeS223std4conv9__T2toTeZ2toZ7composeZ7composeTAAyaZ.MapResult, immutable(char)[]).Result std.algorithm.iteration.joiner!(std.algorithm.iteration.__T9MapResultS1633std10functional136__T7composeS253std4conv11__T2toTAyaZ2toS933std10functional67__T7composeS27_D3std4math5roundFNbNiNeeZeS223std4conv9__T2toTeZ2toZ7composeZ7composeTAAyaZ.MapResult, immutable(char)[]).joiner(std.algorithm.iteration.__T9MapResultS1633std10functional136__T7composeS253std4conv11__T2toTAyaZ2toS933std10functional67__T7composeS27_D3std4math5roundFNbNiNeeZeS223std4conv9__T2toT!

eZ2toZ7composeZ7composeTAAyaZ.MapResult, 
immutable(char)[]).Result.__ctor(std.algorithm.iteration.__T9MapResultS1633std10functional136__T7composeS253std4conv11__T2toTAyaZ2toS933std10functional67__T7composeS27_D3std4math5roundFNbNiNeeZeS223std4conv9__T2toTeZ2toZ7composeZ7composeTAAyaZ.MapResult,
 immutable(char)[])+0x64) [0x4c0448]
./f838(@safe 
std.algorithm.iteration.joiner!(std.algorithm.iteration.__T9MapResultS1633std10functional136__T7composeS253std4conv11__T2toTAyaZ2toS933std10functional67__T7composeS27_D3std4math5roundFNbNiNeeZeS223std4conv9__T2toTeZ2toZ7composeZ7composeTAAyaZ.MapResult, immutable(char)[]).joiner(std.algorithm.iteration.__T9MapResultS1633std10functional136__T7composeS253std4conv11__T2toTAyaZ2toS933std10functional67__T7composeS27_D3std4math5roundFNbNiNeeZeS223std4conv9__T2toTeZ2toZ7composeZ7composeTAAyaZ.MapResult, immutable(char)[]).Result std.algorithm.iteration.joiner!(std.algorithm.iteration.__T9MapResultS1633std10functional136__T7composeS253std4conv11__T2toTAyaZ2toS933std10functional67__T7composeS27_D3std4math5roundFNbNiNeeZeS223std4conv9__T2toTeZ2toZ7composeZ7composeTAAyaZ.MapResult, immutable(char)[]).joiner(std.algorithm.iteration.__T9MapResultS1633std10functional136__T7composeS253std4conv11__T2toTAyaZ2toS933std10functional67__T7composeS27_D3std4math5roundFNbNiNeeZeS223std4conv9__T2toT!

eZ2toZ7composeZ7composeTAAyaZ.MapResult, immutable(char)[])+0x6e) [0x4c0292]
./f838(_Dmain+0x6f) [0x49e87b]
./f838(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x1f) 
[0x4d1487]
./f838(void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate())+0x2a) 
[0x4d13e2]
./f838(void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).runAll()+0x2b) [0x4d1443]
./f838(void 

[Issue 13656] clarify error message upon trying to declare a variable of type ref

[via Digitalmars-d-bugs]

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

--- Comment #1 from Shriramana Sharma  ---
*** Issue 15216 has been marked as a duplicate of this issue. ***

--

Re: 0 in version number?

[bitwise via Digitalmars-d]

On Saturday, 17 October 2015 at 11:44:31 UTC, Marc Schütz wrote:
On Saturday, 17 October 2015 at 08:51:05 UTC, Shriramana Sharma 
wrote:

bitwise wrote:


2.100 -> transition here, maintain sortability


Again, what's this about sortability? Raise your hands please 
whoever is using strcmp or the like to do sorting on D version 
numbers!


Sorting happens in many places where the sorting program is not 
aware that it's working with version numbers. Think of 
directory listings, for example.


Also, in your brain ;)

When you look at two version numbers next to each other, you have 
to be able to tell which one is larger.


2.1 > 2.099

Bit

Re: Beta D 2.069.0-b2

[Marco Leise via Digitalmars-d-announce]

Am Wed, 14 Oct 2015 15:52:57 +0200
schrieb Martin Nowak :

> Second beta for the 2.069.0 release.
> 
> http://dlang.org/download.html#dmd_beta
> http://dlang.org/changelog/2.069.0.html
> 
> Please report any bugs at https://issues.dlang.org
> 
> -Martin

When I use a specific host compiler, it still picks up the
dmd.conf provided in the package and doesn't find object.d.
Should I manually delete dmd.conf before building?

-- 
Marco

Re: [OT] LLVM Community Code of Conduct

[Joakim via Digitalmars-d]

On Friday, 16 October 2015 at 10:25:07 UTC, Chris wrote:
Apart from that, I think the fact that D is still not fit for 
mobile platforms is a huge drawback. Loads of people want apps, 
loads of people have some sort of smart phone, tablet or 
whatever. Sometimes I think that we're getting sucked in by the 
quick sand of language specs, pointers, GC etc. while important 
issues like targeting mobile platforms are second class 
citizens. Nim for example targeted mobile platforms right from 
the start. So did Go. I cannot recommend D wholeheartedly 
unless it also works on ARM at the click of a button. Please 
correct me if I'm wrong here, but mobile is not yet 100%.


Ldc binaries for iOS were announced in July, Dan's now working on 
64-bit support:


http://forum.dlang.org/thread/m2mvz57seb@comcast.net

Android is pretty much done, just cleaning it up by integrating 
with ldc's CMake build system and other small details, 
announcement coming next week.

Re: to(T, ubyte base) if (isIntegral!T)

[Marc Schütz via Digitalmars-d]

On Saturday, 17 October 2015 at 11:27:39 UTC, Shriramana Sharma 
wrote:
So given that toImpl is supposed to be internal, shouldn't we 
have a to! function for specifying the base, something like:


T to(T, ubyte base) if (isIntegral!T && 2 <= base && base <= 36)


It is actually available:

void main() {
import std.conv;
assert("1f".to!int(16) == 31);
}

I doesn't appear in the documentation explicitly, but `to` just 
forwards all of its arguments to `toImpl`. I agree that the 
documentation of the `to`-family should be consolidated.

Re: LuaD: creating a flexible data filter system

[Chris via Digitalmars-d-learn]

On Saturday, 17 October 2015 at 02:02:16 UTC, Jakob Ovrum wrote:

On Friday, 16 October 2015 at 10:45:52 UTC, Chris wrote:
Later you call the function with the Lua C API like 
"lua_pcall(L, 0, 1, 0);". It's a bit tricky to move things 
around on the Lua stack, but you'll get there! ;)


Or you could use LuaD which doesn't require you to mess around 
with the relatively unproductive, bug-prone C API :)


I've used both, LuaD and DerelictLua + my own smaller D library 
that wraps all these nasty Lua stack operations (e.g. creating, 
accessing and adding to tables). The better I got to know the Lua 
C API while writing my own wrappers, the more I came to 
appreciate LuaD :-) However, LuaD is still 5.1 and I didn't want 
to be stuck with 5.1. So I rolled my own. It's not as 
comprehensive as LuaD but did the trick.


The purpose was to experiment with Lua server pages + vibe.d 
which worked fine. Rikki gave me the idea to compile each page as 
a Lua function into memory for faster execution (etLua style[1]). 
It works fine with both LuaD and my own wrappers. In my own 
version I use the Lua C API directly in some places, though I 
don't know, if that's really a big speedup.


If I set up my own homepage, I'd probably give vibe.d + Lua a 
shot. No more PHP and sh*t like that.


[1] https://github.com/leafo/etlua

Re: LuaD: creating a flexible data filter system

[yawniek via Digitalmars-d-learn]

many thanks for the valuable insights.
so far i made a simple prototype with LuaD and classes, works 
nicely for when my niput


what so far is not 100% clear is if there is a way to have a 
parsed
msgpack or json documents being exposed in my lua code in a way 
so it behaves

like a lua object.
Ideally in a RW fashion so that changed then again can be 
processed by D code.

Re: Sub-classing exceptions

[Jacob Carlborg via Digitalmars-d]

On 2015-10-17 04:35, Shriramana Sharma wrote:


Hmmm is that in any way advantageous to what I wrote about it? Is it just
that you can now add a doc-comment that DDoc can recognize?


Less ugly. You don't have to fiddle with building strings.

--
/Jacob Carlborg

Re: Phobos still being statically linked in?

[Shriramana Sharma via Digitalmars-d]

Marc Schütz wrote:

> Yes, it's still linked statically by default, at least with DMD.
> I don't know why this wasn't changed yet, I just tried linking
> against libphobos.so and it worked. The resulting binary is then
> down to 13 Kb, after stripping.

Wow that's nice to hear! Can you outline the steps to link any given .d file 
against libphobos.so?

Thanks!

-- 
Shriramana Sharma, Penguin #395953

[Issue 15218] DMD should link dynamically to libphobos by default

[via Digitalmars-d-bugs]

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

Adam D. Ruppe  changed:

   What|Removed |Added

 CC||destructiona...@gmail.com

--- Comment #1 from Adam D. Ruppe  ---
I absolutely, strongly disagree. Dynamic linking Phobos is a bad idea - it will
lead to serious breakage around every corner for every application.

Phobos changes with every release. All executables compiled before an update
will now be liable to break.

Phobos is not commonly installed on user's computers. To distribute D programs
compiled with these defaults, we'd also have to distribute the library. That'd
be a 10x size increase and a big hassle... and moves the update breakage to the
user's side.

Phobos is also not commonly in the system library location, so on Linux, this
means running programs won't work without either changing that or setting the
library path, another big annoying hassle. I'd virtually break the zip
distribution (which is Linux distro agnostic and used by those of us who aren't
on .rpm or .deb).


I guarantee you this will cause a bigger support burden than 400 KB in hello
world and very little benefit.

C and C++ are very different - their libraries are commonly installed with
operating systems and don't break binary compatibility every couple months. If
you want me to ever get on board with dynamic linking phobos, work to get it
included with all the OSes as an independent end-user component first.

--

Re: Example code on D homepage does not run successfully

[Vladimir Panteleev via Digitalmars-d]

On Saturday, 17 October 2015 at 12:57:25 UTC, Ralph Tandetzky 
wrote:
If I understand this cryptic error message correctly, the 
problem is missing or inadequate input. There is no floating 
point number to be parsed and hence the string "" is parsed 
unsuccessfully which leads to an exception producing this 
horrible error message.


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

Re: Sub-classing exceptions

[Temtaime via Digitalmars-d]

Checked exceptions are a lie.

Re: Fastest JSON parser in the world is a D project

[Marco Leise via Digitalmars-d-announce]

Am Sat, 17 Oct 2015 16:27:06 +
schrieb Sean Kelly :

> On Saturday, 17 October 2015 at 16:14:01 UTC, Andrei Alexandrescu 
> wrote:
> > On 10/17/15 6:43 PM, Sean Kelly wrote:
> >> If this is the benchmark I'm remembering, the bulk of the time 
> >> is spent
> >> parsing the floating point numbers. So it isn't a test of JSON 
> >> parsing
> >> in general so much as the speed of scanf.
> >
> > In many cases the use of scanf can be replaced with drastically 
> > faster methods, as I discuss in my talks on optimization 
> > (including Brasov recently). I hope they'll release the videos 
> > soon. -- Andrei
> 
> Oh absolutely. My issue with the benchmark is just that it claims 
> to be a JSON parser benchmark but the bulk of CPU time is 
> actually spent parsing floats. I'm on my phone though so perhaps 
> this is a different benchmark--I can't easily check. The one I 
> recall came up a year or so ago and was discussed on D.general.

1/4 to 1/3 of the time is spent parsing numbers in highly
optimized code. You see that in a profiler the number parsing
shows up on top, but the benchmark also exercises the
structural parsing a lot. It is not a very broad benchmark
though, lacking serialization, UTF-8 decoding, validation of
results etc. I believe the author didn't realize how over time
it became the go-to performance test. The author of RapidJSON
has a very in-depth benchmark suite, but it would be a bit of
work to get something non-C++ integrated:
https://github.com/miloyip/nativejson-benchmark
It includes conformance tests as well.

-- 
Marco

Re: OT: why do people use python when it is slow?

[Laeeth Isharc via Digitalmars-d-learn]

On Wednesday, 14 October 2015 at 18:17:29 UTC, Russel Winder 
wrote:
On Wed, 2015-10-14 at 14:48 +, John Colvin via 
Digitalmars-d-learn wrote:

On Wednesday, 14 October 2015 at 14:32:00 UTC, jmh530 wrote:
> On Tuesday, 13 October 2015 at 23:26:14 UTC, Laeeth Isharc 
> wrote:

> > https://www.quora.com/Why-is-Python-so-popular-despite-being-so-s
> > low
> > Andrei suggested posting more widely.
> 
> I was just writing some R code yesterday after playing 
> around with D for a couple weeks. I accomplished more in an 
> afternoon of R coding than I think I had in like a month's 
> worth of playing around with D. The same is true for python.


As someone who uses both D and Python every day, I find that - 
once you are proficient in both - initial productivity is 
higher in Python and then D starts to overtake as a project 
gets larger and/or has stricter requirements. I hope never to 
have to write anything longer than a thousand lines in Python 
ever again.


The thing about Python is NumPy, SciPy, Pandas, Matplotlib, 
IPython, Jupyter, GNU Radio. The data science, bioinformatics, 
quant, signal provessing, etc. people do not give a sh!t which 
language they used, what they want is to get their results as 
fast as possible. Most of them do not write programs that are 
to last, they are effectively throw away programs. This leads 
them to Python (or R) and they are not really interested in 
learning anything else.


The fact that NumPy sort of sucks in terms of performance, isn't
noticed by them
as they get their results "fast enough" and a lot faster than
sequential Python. The fact that if they used Chapel or even D 
for
their compute intensive code they would rapidly discover that 
NumPy
sort of sucks never really occurs to these people as they are 
focussed

on the results not the means of achieving them.

Polyglot Python/D or Python/Chapel with Matplotlib is the way 
to go. But that really requires a D replacement for Pandas.



Russell, thanks for your thoughts - I appreciate it.

What would a Pandas replacement look like in D?

Re: LuaD: creating a flexible data filter system

[Laeeth Isharc via Digitalmars-d-learn]

On Saturday, 17 October 2015 at 13:15:17 UTC, yawniek wrote:

many thanks for the valuable insights.
so far i made a simple prototype with LuaD and classes, works 
nicely for when my niput


what so far is not 100% clear is if there is a way to have a 
parsed
msgpack or json documents being exposed in my lua code in a way 
so it behaves

like a lua object.
Ideally in a RW fashion so that changed then again can be 
processed by D code.


http://luajit.org/ext_ffi_tutorial.html

C meta methods

Re: Walter Bright, Scott Meyers and me live on the most watched morning show in Romania

[Walter Bright via Digitalmars-d-announce]

On 10/17/2015 9:09 AM, Andrei Alexandrescu wrote:

On 10/17/15 4:01 PM, mattcoder wrote:

On Saturday, 17 October 2015 at 09:36:08 UTC, Andrei Alexandrescu wrote:

D got mentioned as well.
...


Awesome!

Just a note: the guy in red suit (George Buhnici?), looks like you
Andrei. :)


Yep, Walter and Scott figured there's an ethnic look to Romanians. In
particular they say I have a "Romanian mobster" look going. -- Andrei



We had a great time, and the Romanian people we met couldn't have been 
nicer to us. Romania is a very beautiful country, and having Andrei as 
our guide was an opportunity not to be missed!

Re: Example code on D homepage does not run successfully

[Ralph Tandetzky via Digitalmars-d]

On Saturday, 17 October 2015 at 17:02:07 UTC, NX wrote:


It's not because input is empty, but rather that across-web 
compiling is highly broken and problematic. There is an "Input" 
button bottom of the code area which shows what input will be 
given to stdin, which is actually not empty (it's written: "2.4 
plus 2.4 equals 5 for sufficiently large values of 2.")


Maybe one day someone will take care of improving the 
infrastructure...


I see. Well, thanks for the quick reply. A quick fix would be 
adapting the source code, so it compiles with the given system, 
wouldn't it? Anyways, my aim was to bring the issue to attention 
and provide a possible solution. I don't know how to change the 
examples on the web site, so I just posted one here, so someone 
with the access rights can do the actual change.

Re: Example code on D homepage does not run successfully

[bachmeier via Digitalmars-d]

On Saturday, 17 October 2015 at 17:02:07 UTC, NX wrote:
Maybe one day someone will take care of improving the 
infrastructure...


The right thing to do is to get it off the homepage until it's 
fixed. Few visitors would not move on after getting an error 
where one should never occur. And as stated by the OP, that 
particular code is way too complicated to be used to promote the 
language anyway.

Re: Walter Bright, Scott Meyers and me live on the most watched morning show in Romania

[Chris via Digitalmars-d-announce]

On Saturday, 17 October 2015 at 18:25:32 UTC, Walter Bright wrote:

On 10/17/2015 9:09 AM, Andrei Alexandrescu wrote:

On 10/17/15 4:01 PM, mattcoder wrote:
On Saturday, 17 October 2015 at 09:36:08 UTC, Andrei 
Alexandrescu wrote:

D got mentioned as well.
...


Awesome!

Just a note: the guy in red suit (George Buhnici?), looks 
like you

Andrei. :)


Yep, Walter and Scott figured there's an ethnic look to 
Romanians. In
particular they say I have a "Romanian mobster" look going. -- 
Andrei



We had a great time, and the Romanian people we met couldn't 
have been nicer to us. Romania is a very beautiful country, and 
having Andrei as our guide was an opportunity not to be missed!


Of course they were nice, after all you had a 'Romanian mobster' 
with you :-)

Re: [OT] LLVM Community Code of Conduct

[Max Samukha via Digitalmars-d]

On Friday, 16 October 2015 at 08:29:18 UTC, Kagamin wrote:

On Thursday, 15 October 2015 at 09:09:22 UTC, Chris wrote:
I agree with logicchains. The impression people have is 
exactly this. Go = neat and tidy, D = mess.


Do people have the same impression from generic code in Go?


Crutches help them move along: http://blog.golang.org/generate

Re: The D Language Foundation is now incorporated

[Suliman via Digitalmars-d-announce]

On Saturday, 17 October 2015 at 16:12:42 UTC, Andrei Alexandrescu 
wrote:

On 10/17/15 4:06 PM, suliman wrote:

Can anybody outside USA join to the foundation?


As a member, yes. We'll define private and corporate membership 
with sponsorship levels etc.


As an officer, I'm not sure; I'll ask. Anyway we want to keep 
the number of officers small for the time being.



Thanks,

Andrei


I hope that I can be helpful as admin of Russian community or 
something like it. At present time we end working at our 
dlang.ru, for my regret the work on CMS take more then one year, 
but I hope that it will be open soon. Again very sorry for long 
promises to open site "in next few weeks" , but it's very hard to 
do with there is primary job.


Andrei, with whom I can talk about dsource.org? I am thinking 
that it can be very good collective forum (project forum) for D. 
I hope that our CMS that will be released very soon would be good 
for it. This NG can be stay for technical questions, while 
dsource could become collective blog as part of D Foundation. 
What do you think about it?

Re: 0 in version number?

[bitwise via Digitalmars-d]

On Saturday, 17 October 2015 at 15:36:10 UTC, Shriramana Sharma 
wrote:

Marc Schütz wrote:

Sorting happens in many places where the sorting program is 
not aware that it's working with version numbers. Think of 
directory listings, for example.


$ cd /tmp/
$ touch f{1..20}
$ ls -v1
f1
f2
f3
f4
f5
f6
f7
f8
f9
f10
f11
f12
f13
f14
f15
f16
f17
f18
f19
f20


touch f1.098
touch f1.099
touch f1.1.0
touch f1.1.1
ls

Re: The D Language Foundation is now incorporated

[Andrei Alexandrescu via Digitalmars-d-announce]

On 10/17/15 11:19 PM, Suliman wrote:

Andrei, with whom I can talk about dsource.org?


Brad Anderson 

He's very nice but just busy with things. I think he'd be glad to do 
what's right if we make it reasonably easy for him.



Andrei

[Issue 15219] New: Allow Throwable.msg to be calculated lazily

[via Digitalmars-d-bugs]

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

  Issue ID: 15219
   Summary: Allow Throwable.msg to be calculated lazily
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P4
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: thecybersha...@gmail.com

In many cases, an exception's .msg property is not trivial to compose. At the
very least, it often involves GC allocations to format the exception string.
Sometimes it involves OS API calls, e.g. when the error is caused by a failed
I/O operation, in which case the appropriate OS error string is queried. For
parsing code, an exception message will often contain the line/column, which
also can have an additional cost to calculate or keep track of.

Since exceptions are usually caught and handled higher in the application, the
error message is never seen by the user, and all the effort to calculate it
goes to waste.

Currently, it is not possible to create an exception object whose .msg is
calculated lazily. There is the virtual toString method, inherited from Object,
however this method returns the exception formatted together with the stack
trace, and is unsuitable for overriding.

We can remedy this while mostly preserving backwards-compatibility with the
following steps:

1. Change the field "string msg" to "private string _msg".
2. Provide a virtual getter property "msg", which can be overridden to
calculate the exception message lazily.
3. For backwards compatibility, also provide a setter property "msg", which
sets the private _msg field.

Moving forward, since std.exception.enforce already takes its .msg parameter
lazily, it can be changed to subclass the respective exception type, override
the "msg" property, and return the "msg" argument passed to enforce. This
should give us a performance gain for free.

Possible backwards-compatibility problems can result due to changing
Throwable.msg to a property: code that takes the address of .msg, or code that
relies that accessing .msg is a O(1) or @nogc operation, will be affected, but
I think this is within the bounds of acceptable breakage.

--