Re: Fiber overhead

[Profile Anaysis via Digitalmars-d-learn]

On Saturday, 4 February 2017 at 06:54:01 UTC, Ali Çehreli wrote:

On 02/03/2017 08:47 PM, Profile Anaysis wrote:

What is the overhead of using a fiber?


The performance overhead of call() and yield() are comparable 
to function calls because it's simply a few register 
assignments in each case. (Change the stack pointer, etc.)


Memory overhead is memory for call stack, size of which can be 
determined by the programmer.


Ali


Thanks, that was what I was hoping.

Re: The extent of trust in errors and error handling

[Ali Çehreli via Digitalmars-d]

On 02/01/2017 06:29 PM, Chris Wright wrote:
> On Wed, 01 Feb 2017 11:25:07 -0800, Ali Çehreli wrote:
>> 1) There is the well-known issue of whether Error should ever be caught.
>> If Error represents conditions where the application is not in a defined
>> state, hence it should stop operating as soon as possible, should that
>> also carry over to other applications, to the OS, and perhaps even to
>> other systems in the whole cluster?
>
> My programs tend to apply operations to a queue of data. It might be a
> queue over time, like incoming requests, or it might be a queue based on
> something else, like URLs that I extract from HTML documents.
>
> Anything that does not impact my ability to manipulate the queue can be
> safely caught and recovered from.
>
> Stack overflow? Be my guest.
>
> Null pointer? It's a bug, but it's probably specific to a small 
subset of

> queue items -- log it, put it in the dead letter queue, move on.
>
> RangeError? Again, a bug, but I can successfully process everything else.

In practice, both null pointer and range error can probably be dealt 
with and the program can move forward.


However, in theory you cannot be sure why that pointer is null or why 
that index is out of range. It's possible that something horrible 
happened many clock cycles ago and you're seeing the side effects of 
that thing now.


What operations can you safely assume that you can still perform? Can 
you log? Are you sure? Even if you caught RangeError, are you sure that 
arr.ptr is still sane? etc.


In theory, at least the way I understand it, a program lives on a very 
narrow path. Once it steps outside that well known path, all bets are 
off. Can a caught Error bring it back on the path or are we on an 
alternate path now.


>> 2) What if an intermediate layer of code did in fact handle an Error
>> (perhaps raised by a function pre-condition check)? Should the callers
>> of that layer have a say on that? Should a higher level code be able to
>> say that Error should not be handled at all?
>>
>> For example, an application code may want to say that no library that it
>> uses should handle Errors that are thrown by a security library.
>
> There's a bit of a wrinkle there. "Handling" an error might include
> catching it, adding some extra data, and then rethrowing.

Interestingly, attempting to add extra data can very well produce the 
opposite effect: Stack trace information that would potentially be 
available can indeed be corrupted while adding that extra data.


The interesting part is trust. Once there is an Error, what can you trust?

>> I think there is no way of
>> requiring that e.g. a square root function not have side effects at all:
>> The compiler can allow a piece of code but then the library that was
>> actually linked with the application can do anything else that it wants.
>
> You can write a compiler with its own object format and linker, which 
lets

> you verify these promises at link time.

Good idea. :) As Joakim reminded, the designers of Midori did that and more.

> As an aside on this topic, I might recommend looking at Vigil, the
> eternally morally vigilant programming language:
> https://github.com/munificent/vigil
>
> It has a rather effective way of dealing with errors that aren't
> explicitly handled.
>

Thank you, I will look at it next.

Ali

[Issue 17139] [BLOCKING] dscanner needs to handle 'scope' function attributes

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/4fab50175481d9b1c00ae168c444580de92f258c
fix issue 17139 - dscanner needs to handle 'scope' function attributes

https://github.com/dlang/phobos/commit/72a2b2eb93b30806d4fa0cb162f24091fdfb651e
Merge pull request #5085 from BBasile/issue-17139

fix issue 17139 - dscanner needs to handle 'scope' function attributes

--

[Issue 17139] [BLOCKING] dscanner needs to handle 'scope' function attributes

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: The extent of trust in errors and error handling

[Ali Çehreli via Digitalmars-d]

On 02/01/2017 01:27 PM, Joakim wrote:
> On Wednesday, 1 February 2017 at 19:25:07 UTC, Ali Çehreli wrote:
>> tl;dr - Seeking thoughts on trusting a system that allows "handling"
>> errors.
>>
>> [...]
>
> Have you seen this long post from last year, where Joe Duffy laid out
> what they did with Midori?
>
> http://joeduffyblog.com/2016/02/07/the-error-model/
>
> Some relevant stuff in there.

Thank you. Yes, very much related and very interesting!

Joe Duffy says "Midori [is] a system that "drew significant inspiration 
from KeyKOS and its successors EROS and Coyotos." I'm happy to see that 
KeyKOS is mentioned there as Norm Hardy, the main architect of KeyKOS, 
is someone who is involved in the Mill CPU and whom I have the privilege 
of knowing personally and seeing weekly. :)


Ali

Re: Fiber overhead

[Ali Çehreli via Digitalmars-d-learn]

On 02/03/2017 08:47 PM, Profile Anaysis wrote:

What is the overhead of using a fiber?


The performance overhead of call() and yield() are comparable to 
function calls because it's simply a few register assignments in each 
case. (Change the stack pointer, etc.)


Memory overhead is memory for call stack, size of which can be 
determined by the programmer.


Ali

Re: GSoC Project Idea's Part 2

[Arun Chandrasekaran via Digitalmars-d]

On Friday, 3 February 2017 at 04:12:10 UTC, Craig Dillabaugh 
wrote:
So the GSoC ideas page is now at least partially complete, you 
can find it here:


https://wiki.dlang.org/GSOC_2017_Ideas

In the previous thread some of you (Rikki, Adam) had suggested 
some improvements to dub/the code.dlang.org website.  Either of 
you interested in mentoring something around that?


So new project ideas are welcome, and feel free to post any 
ideas you have here for comment.  Also we need mentors so if 
you post a new project, or see one on the existing ideas page 
please feel free to offer your services as a mentor.


The application process finishes on Feb. 9th.

Cheers

Craig


D libraries for interprocess communication will be a boon. 
Something similar to `boost::interprocess` [1].


[1] http://boost.org/libs/interprocess

Re: Name That Technique!

[Nick Sabalausky via Digitalmars-d]

On 02/03/2017 06:50 PM, Ali Çehreli wrote:

"the imp idiom" might do but imps have a very
insignificant appearance in Harry Potter.


But they have much significance in Doom :)

...part of which takes place on Phobos ;)

Fiber overhead

[Profile Anaysis via Digitalmars-d-learn]

What is the overhead of using a fiber?

Re: A public domain game written in D

[SimonN via Digitalmars-d]

On Friday, 3 February 2017 at 21:14:48 UTC, Dukc wrote:

http://lixgame.com/

A public domain game very much like Lemmings. I'm almost sure 
some of you here have played Lemmings.


NOTE: I have not made or even contributed to that project. I 
just stumbled upon it when surfing the net and thought you may 
be interested to hear.


Hi, I'm the author, ask me anything. :-)

Lix is a Lemmings-like game with working singleplayer, but I'm 
still porting the networked multiplayer. I've deferred my 
announcement to the D community because multiplayer is still WIP.


With dmd 2.073, Lix doesn't compile because CTFE can't initialize 
classes/struct pointers anymore. I'm working on this. Lix builds 
with 2.072 and earlier.


-- Simon

Re: GC question

[Dsby via Digitalmars-d-learn]

On Friday, 3 February 2017 at 11:36:26 UTC, osa1 wrote:

On Friday, 3 February 2017 at 10:49:00 UTC, Kagamin wrote:
Leaks are likely in 32-bit processes and unlikely in 64-bit 
processes. See e.g. 
https://issues.dlang.org/show_bug.cgi?id=15723


This looks pretty bad. I think I'll consider something else 
until D's memory management story gets better. This is sad 
because the language otherwise looks quite good, and I'd love 
to try assertions, contracts, scope guards, macros etc.


you can use less auto GC. use the RC to replace the GC.
https://github.com/huntlabs/SmartRef

Re: Thoughts about exception reporting

[Chris Wright via Digitalmars-d]

On Fri, 03 Feb 2017 19:50:19 +, pineapple wrote:
> - nothrow might be repurposed to mean "doesn't throw recoverable
> exceptions", and it not forbid throwing objects that inherit from Error.

That's what it means today:

  void foo() nothrow
  {
throw new Error("Ohai!");
  }

Re: Automatic imports?

[Walter Bright via Digitalmars-d]

On 2/3/2017 4:01 PM, Ali Çehreli wrote:

void foo(std.datetime.Duration dur) {
// ...
}

Can the compiler automatically import std.datetime for both the implementation
above and the user? Or, too much beer at work on this Friday? :o)


How does the compiler know that "std" is supposed to be an import rather than a 
misspelling of a previously declared "stc" ?

Automatic imports?

[Ali Çehreli via Digitalmars-d]

On 02/03/2017 06:43 AM, Dominikus Dittes Scherkl wrote:
> DIP 1005 provides new syntax to make it possible to avoid global imports.

I haven't followed DIP 1005 closely. Has there been any discussion of 
automatic imports that seems to have potential to make both the user's 
and implementor's lives easier:


void foo(std.datetime.Duration dur) {
// ...
}

Can the compiler automatically import std.datetime for both the 
implementation above and the user? Or, too much beer at work on this 
Friday? :o)


Ali

Re: Name That Technique!

[deadalnix via Digitalmars-d]

On Friday, 3 February 2017 at 23:33:58 UTC, Walter Bright wrote:
I agree, it's pretty dazz! We need to give this technique a 
memorable name (not an acronym). I thought "Voldemort Types" 
turned out rather well, whereas CTFE is klunky, UFCS is even 
worse. The absolute worst is C++ SFINAE.


Any ideas?

  Scherkl-Nielsen Lookup?

The perfect bikeshedding moment!

Daniel, Dominikus: please consider writing an article about 
this.


That's obviously a self important lookup.

Re: Name That Technique!

[Ali Çehreli via Digitalmars-d]

On 02/03/2017 03:33 PM, Walter Bright wrote:

>> On 2/3/17 10:41 AM, Daniel N wrote:

>>> auto fun_time(imp!"std.datetime".SysTime tm)

> We need to give this technique a memorable name (not an acronym).

If it's going to stay "imp" (which I initially found confusing; How 
about "Import"?), "the imp idiom" might do but imps have a very 
insignificant appearance in Harry Potter. (There are "Pepper Imps sold 
at Honeydukes in Hogsmeade".)


Ali

Name That Technique!

[Walter Bright via Digitalmars-d]

On 2/3/2017 11:14 AM, Andrei Alexandrescu wrote:

On 2/3/17 10:41 AM, Daniel N wrote:

On Friday, 3 February 2017 at 14:43:01 UTC, Dominikus Dittes Scherkl wrote:

DIP 1005 provides new syntax to make it possible to avoid global imports.
Any thoughts?


I like it!

template imp(string mod)
{
  mixin("import imp = " ~ mod ~ ";");
}

auto fun_time(imp!"std.datetime".SysTime tm)
{
  return tm;
}

void main()
{
  import std.stdio;
  import std.datetime;

  fun_time(Clock.currTime()).writeln;
}


Wow. This is... brilliant. Thanks for the great idea. I ran a few tests and it
seems to be doing out of the box most of what we want with DIP1005 with no
language change at all.

Congratulations!


I agree, it's pretty dazz! We need to give this technique a memorable name (not 
an acronym). I thought "Voldemort Types" turned out rather well, whereas CTFE is 
klunky, UFCS is even worse. The absolute worst is C++ SFINAE.


Any ideas?

  Scherkl-Nielsen Lookup?

The perfect bikeshedding moment!

Daniel, Dominikus: please consider writing an article about this.

Re: Snap packages for D compilers and core projects

[Joseph Rushton Wakeling via Digitalmars-d]

On Sunday, 29 January 2017 at 20:07:50 UTC, Joseph Rushton 
Wakeling wrote:
I started by trying to snap LDC, mainly because the cmake build 
system made for a very easy integration with the snapcraft 
package-build system.  The LDC developers have been kind enough 
to accept this as an official contribution, and a first 
submission is currently waiting for review in the Ubuntu snap 
store, based on the following package definition:

https://github.com/ldc-developers/ldc2.snap


This LDC snap is now published in the official snap store.  See:
https://forum.dlang.org/thread/rkxyvsmgwhfkigybj...@forum.dlang.org

... for more details.

Snap package for LDC 1.1.0 available to test

[Joseph Rushton Wakeling via Digitalmars-d-announce]

As of earlier today, a snap package for LDC 1.1.0 has been 
published in the 'edge' channel of the Ubuntu store.


Snap packages are a new format developed by Ubuntu to facilitate 
upstreams being able to provide the latest versions of their apps 
directly to users.  The format is also designed to provide 
effective confinement for apps, so that they can only access the 
parts of the host system that they need to.  While developed by 
Ubuntu, the format is gaining quite a bit of of cross-distro 
traction: see http://snapcraft.io/ for more information.


On Ubuntu 16.04 or later, or Debian Sid, it should be possible to 
install this package using the following commands:


sudo apt install snapd   # in order to be able to install 
snap packages at all


sudo snap install --classic --edge ldc2

The `--classic` flag is needed in order to accept the confinement 
choice of the ldc2 package, while the `--edge` flag is needed to 
search in the similarly-named package channel.  As the name 
suggests this is for 'bleeding edge' packages.


The package includes the ldc2 compiler plus its 'dmd-like' 
version ldmd2, as well as ldc-profdata and ldc-prune-cache.  
You'll find the commands in /snap/bin/ : note that the latter 
three will (for now) be called ldc2.ldmd2, ldc2.ldc-profdata and 
ldc2.ldc-prune-cache (these names will hopefully be simplified in 
a future release).


It should be possible to use ldc2 and ldc2.ldmd2 in the same way 
that you would use their equivalents installed by any other 
package manager.  Please let me know of any issues you encounter 
in trying to use this!


In principle it should also be possible to install this snap on 
other distros that have support for snap packages (e.g. Arch, 
Gentoo, Fedora, OpenSUSE); however, it will require an up-to-date 
version of snapd (2.21 or later) which some distros may not yet 
have made available.  For instructions on how to install snapd on 
other distros, see:

http://snapcraft.io/docs/core/install

For information on 'classic' confinement, see:
https://insights.ubuntu.com/2017/01/09/how-to-snap-introducing-classic-confinement/

Finally, for the snap package definition, see:
https://github.com/ldc-developers/ldc2.snap

I would be happy to explain any aspects of the snap packaging 
process or syntax that anyone is interested in.


Finally, thanks to the LDC developers who eagerly embraced this 
project to create and distribute an LDC snap package, and for all 
the helpful advice and support they have offered throughout the 
process.


Please do let me know what your experience is trying the package!

Thanks & best wishes,

-- Joe

Re: Snap packages for D compilers and core projects

[Joseph Rushton Wakeling via Digitalmars-d]

On Friday, 3 February 2017 at 08:51:38 UTC, qznc wrote:

I just tried FlatPak and Snap. Snap is actually useable.


One of the first things that struck me about snap packaging was 
the ease of its syntax and how straightforward it was to get 
things working.  I actually started creating snap packages as an 
easy way to build and install D compilers and other tools on my 
own system.  It's both simpler and cleaner than doing those 
builds by hand or writing custom scripts.


The fact that it's then trivially easy to share the results with 
everyone else is the cherry on the cake :-)


FlatPak might be superior technology with its sandboxing, but 
I'm no expert. FlatPak has no central repository, which makes 
it unuseable for the layman at the moment. It feels like the 
PPA situation in Ubuntu.


I'm no expert on sandboxing either, but snapcraft certainly also 
provides confinement -- and to be honest my impression is it does 
so in a more effective and flexible way than Flatpak.  Some of 
the non-Ubuntu distros may however be disabling the confinement 
right now as some issues with different confinement systems are 
worked through.


Snap has stuff like pulseaudio (audio daemon) or ogre 
(rendering engine) in the repo. That seems weird, because these 
are not applications. The first belongs into the base system, 
the second into a development environment.


I think this is by design.  For example, it makes perfect sense 
that a daemon like pulseaudio might live in an isolated, confined 
environment where only applications that specifically need access 
are allowed to talk to it.  Probably its presence in the store is 
in order to allow people to explore working with it in that way.


I can't speak to ogre, but I don't think the use-cases of snap 
packaging are intended to be limited to applications in the long 
run.  It also makes sense that a development library could be 
provided via a read-only filesystem, so that while anyone might 
_read_ it to build or run a program, it couldn't be overwritten 
by another application.


For an example of a library snap, I believe some core KDE 
frameworks are being distributed as a snap in their own right, 
which other KDE application snaps can then depend on.

Re: Is there anything fundamentally wrong with this code?

[Ali Çehreli via Digitalmars-d-learn]

On 02/03/2017 11:43 AM, WhatMeWorry wrote:

On Friday, 3 February 2017 at 18:37:15 UTC, Johan Engelen wrote:

On Friday, 3 February 2017 at 17:20:43 UTC, WhatMeWorry wrote:

[...]


The error is in this line. Instead of assigning to the `postProc` at
module scope, you are defining a new local variable and assigning to it.


[...]


Thank you so much.  This is where I deserve a big Duh.  I guess there is
no way to to make this idiot proof.  I'll print it out and hang it over
my desk.


No matter how experienced, these happen to most programmers. :-/ 
Somebody else had a similar problem just the other day on this forum.


The same problem somewhat commonly happens when one copy+pastes members 
into the constructor and assigns to them forgetting to remove the types:


struct S {
int i;
int j;

this(int a) {
// Declarations pasted from the members
int i = 42 + a;// meant 'i = 42 + a' (or this.i = ...)
int j = 43 + a;
}
}

Another related one is assigning to a parameter usually in the constructor:

struct S {
int i;

this(int i) {
i = i;// meant this.i = i
}
}

Ali

Re: memcpy() comparison: C, Rust, and D

[Walter Bright via Digitalmars-d]

On 2/3/2017 4:10 AM, Atila Neves wrote:

Right, but we're talking about finding memory corruption bugs _before_ they
manifest themselves. As I mentioned in my other reply, if you have memory
corruption bugs in common cross-platform code, valgrind and asan will (nearly
always) catch them. You don't need to wait for weird effects that are hard to
trace back. Run on Linux with both valgrind and asan and you'll be fine 99.9%*
of the time.


You're right - if you've got a test suite that'll tickle it!

Re: Boston D Meetup 2/9: `shared` Experiences

[bitwise via Digitalmars-d-announce]

On Monday, 30 January 2017 at 21:48:57 UTC, Steven Schveighoffer 
wrote:
Attention fellow Boston D enthusiasts: I have set up a meetup 
for February, and Michael Coulombe will give a presentation on 
his experiences with shared.


As before, this will be at the Capital One Cafe in the back bay 
(across from Prudential center).


Hope to see you all there!

https://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/237324049/

-Steve


Will there be a recording of this?

Re: Workaround for DIP 1005

[Daniel Nielsen via Digitalmars-d]

On Friday, 3 February 2017 at 20:04:22 UTC, Daniel Nielsen wrote:
On Friday, 3 February 2017 at 19:14:16 UTC, Andrei Alexandrescu 
wrote:


Wow. This is... brilliant. Thanks for the great idea. I ran a 
few tests and it seems to be doing out of the box most of what 
we want with DIP1005 with no language change at all.


Congratulations!


Andrei




I just had to try one more thing. It never ceases to amaze me 
what is possible in D today.


template imp(string mod) { mixin("import imp = " ~ mod ~ ";"); }
auto fun_time(imp!"std.datetime".SysTime tm) { return tm; }

void main()
{
  with(imp!"std.datetime")
static if(is(Clock))
  with(imp!"std.stdio")
Clock.currTime.fun_time.writeln;
}

A public domain game written in D

[Dukc via Digitalmars-d]

http://lixgame.com/

A public domain game very much like Lemmings. I'm almost sure 
some of you here have played Lemmings.


NOTE: I have not made or even contributed to that project. I just 
stumbled upon it when surfing the net and thought you may be 
interested to hear.

[Issue 17139] [BLOCKING] dscanner needs to handle 'scope' function attributes

[via Digitalmars-d-bugs]

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

briancsch...@gmail.com changed:

   What|Removed |Added

 CC||briancsch...@gmail.com

--- Comment #2 from briancsch...@gmail.com ---
https://github.com/Hackerpilot/Dscanner/releases/tag/v0.4.0-beta.4

--

Re: Workaround for DIP 1005

[Daniel Nielsen via Digitalmars-d]

On Friday, 3 February 2017 at 19:14:16 UTC, Andrei Alexandrescu 
wrote:


Wow. This is... brilliant. Thanks for the great idea. I ran a 
few tests and it seems to be doing out of the box most of what 
we want with DIP1005 with no language change at all.


Congratulations!


Andrei


Thank you very much. I was just going to mail you directly to 
make sure the idea wasn't lost in the forum flood, will be 
exciting to see some measurements using this idiom.


Daniel N

Thoughts about exception reporting

[pineapple via Digitalmars-d]

Something I keep going back and forth on is the best way to 
handle exception reporting in different contexts. There are so 
many idioms to use here and none of them feel quite ideal. I'm 
not sure the best way to improve it, but I'm hoping a discussion 
might produce some useful ideas.


Some suggestions, apart from the obvious "exceptions shouldn't 
require the gc":


- nothrow might be repurposed to mean "doesn't throw recoverable 
exceptions", and it not forbid throwing objects that inherit from 
Error. It's limiting to have to use asserts to report 
nonrecoverable errors in nothrow code, rather than specialized 
error classes that might provide better information as to what 
went wrong.


- pure might no longer prevent code from throwing `static const` 
objects, so that error reporting can still be done using @nogc 
and user-defined error classes in pure functions. It's 
unintuitive that asserts and `throw new WhateverError` should be 
allowed, but not `static const error = new WhateverError; throw 
error`.

Re: LDC 1.1.0 released

[Kai Nacke via Digitalmars-d-announce]

On Friday, 3 February 2017 at 12:21:09 UTC, deadalnix wrote:
On Wednesday, 1 February 2017 at 03:43:10 UTC, David Nadlinger 
wrote:

Hi all,

Version 1.1.0 of LDC, the LLVM-based D compiler, has finally 
been released: 
https://github.com/ldc-developers/ldc/releases/tag/v1.1.0


Please head over to the digitalmars.D.ldc forums for more 
details and discussions: 
http://forum.dlang.org/post/etynfqwjosdvuuukl...@forum.dlang.org


 — David


What's the state of cent/ucent ?


Nothing changed as I am busy with non-D related tasks right now. 
:-(


Regards,
Kai

Re: Is there anything fundamentally wrong with this code?

[WhatMeWorry via Digitalmars-d-learn]

On Friday, 3 February 2017 at 18:37:15 UTC, Johan Engelen wrote:

On Friday, 3 February 2017 at 17:20:43 UTC, WhatMeWorry wrote:

[...]


The error is in this line. Instead of assigning to the 
`postProc` at module scope, you are defining a new local 
variable and assigning to it.



[...]


Thank you so much.  This is where I deserve a big Duh.  I guess 
there is no way to to make this idiot proof.  I'll print it out 
and hang it over my desk.

Re: How to write Good IDE?

[MGW via Digitalmars-d]

On Wednesday, 1 February 2017 at 15:12:42 UTC, unDEFER wrote:

And what important for you for Good IDE?


Simple IDE. It is possible that that is useful from this what is. 
I permanently use it as it is very quickly.


https://www.youtube.com/watch?v=RBan5Dwt_JM
https://github.com/MGWL/QtE5/tree/master/ide5

Re: Workaround for DIP 1005

[Andrei Alexandrescu via Digitalmars-d]

On 2/3/17 2:14 PM, Andrei Alexandrescu wrote:

On 2/3/17 10:41 AM, Daniel N wrote:

On Friday, 3 February 2017 at 14:43:01 UTC, Dominikus Dittes Scherkl
wrote:

DIP 1005 provides new syntax to make it possible to avoid global
imports.
Any thoughts?


I like it!

template imp(string mod)
{
  mixin("import imp = " ~ mod ~ ";");
}

auto fun_time(imp!"std.datetime".SysTime tm)
{
  return tm;
}

void main()
{
  import std.stdio;
  import std.datetime;

  fun_time(Clock.currTime()).writeln;
}


Wow. This is... brilliant. Thanks for the great idea. I ran a few tests
and it seems to be doing out of the box most of what we want with
DIP1005 with no language change at all.

Congratulations!


I should also extend thanks to Dominik, who provided the initial idea 
and the inspiration for this one. -- Andrei

Re: Workaround for DIP 1005

[Andrei Alexandrescu via Digitalmars-d]

On 2/3/17 10:41 AM, Daniel N wrote:

On Friday, 3 February 2017 at 14:43:01 UTC, Dominikus Dittes Scherkl wrote:

DIP 1005 provides new syntax to make it possible to avoid global imports.
Any thoughts?


I like it!

template imp(string mod)
{
  mixin("import imp = " ~ mod ~ ";");
}

auto fun_time(imp!"std.datetime".SysTime tm)
{
  return tm;
}

void main()
{
  import std.stdio;
  import std.datetime;

  fun_time(Clock.currTime()).writeln;
}


Wow. This is... brilliant. Thanks for the great idea. I ran a few tests 
and it seems to be doing out of the box most of what we want with 
DIP1005 with no language change at all.


Congratulations!


Andrei

Re: D IDE Coedit - version 3 beta 3

[Basile B. via Digitalmars-d-announce]

On Monday, 30 January 2017 at 23:32:12 UTC, dminded wrote:
Ok, the debugger also works if i write a bit more then just a 
'writeln' into main.


How can i set breakpoints? If i click on the left side of a 
row, a little red dot appears. But the debugger seems to ignore 
it and instead every statement is a breakpoint. I also can not 
find a "step out of function" button.


I was writing the manual page for the debugger then I remembered 
your Q. I bet that you used to wrong toolbar icon.


▷: is for resuming (e.g until next breakpoint/watchpoint/signal)
↓: is for stepping.

(http://bbasile.github.io/Coedit/widgets_gdb_commander)

If you stepped it's normal that it broke at each line ;]

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Wednesday, 1 February 2017 at 11:53:09 UTC, Stefan Koch wrote:

On Tuesday, 31 January 2017 at 16:21:27 UTC, Stefan Koch wrote:

function pointer support is coming!


This is more difficult then I expected,
since the argument handling system was build without 
considering that we could have functions as arguments, 
therefore when trying to evaluate the function-argument it will 
overwrite the data-structures that are supposed to hold the 
information for the function we currently processing the 
arguments for.


maybe this can be fixed by handling the arguments before 
handling the function itself.


I have not fixed the bug with top-level function arguments yet,
However I have enabled function-pointer support for non-toplevel 
use

such as in :
int[] filterBy(int[] arr , bool function(uint) fn)
{
int[] result;
uint resultLength;

result.length = arr.length;
foreach(i;0 .. arr.length)
{
auto e = arr[i];
bool r = true;
r = fn(e);
if(r)
{
result[resultLength++] = e;
}
}

   int[] filterResult;
   filterResult.length = resultLength;

   foreach(i; 0 .. resultLength)
   {
 filterResult[i] = result[i];
   }

  return filterResult;
}


bool isDiv2(uint e)
{
  bool result_;
  result_ = (e % 2 == 0);
  return result_;
}

bool isNotDiv2(uint e)
{
  bool result_;
  result_ = (e % 2 != 0);
  return result_;
}

int[] run(int[] arr, bool div2)
{
  return filterBy(arr, div2 ?  : );
}


static assert(run([3,4,5], true) == [4]);
static assert(run([3,4,5], false) == [3,5]);

//static assert(filterBy([3,4,5], ) == [4]);
// top-level function arguments do currently not work with newCTFE

Enjoy!

Re: Is there anything fundamentally wrong with this code?

[Johan Engelen via Digitalmars-d-learn]

On Friday, 3 February 2017 at 17:20:43 UTC, WhatMeWorry wrote:


-file post_processor.d --
module post_processor;

class PostProcessor
{
...
GLuint FBO;

}

-file game.d ---
module game;

PostProcessor  postProc; // just a declaration (no memory 
allocation)


class Game
{
...
void initGame(){
...
PostProcessor postProc = new PostProcessor(...);


The error is in this line. Instead of assigning to the `postProc` 
at module scope, you are defining a new local variable and 
assigning to it.



...
}
...
void update(GLfloat deltaTime){
...
writeln("Right Before");
writeln("postProcesor.FBO = ", postProc.FBO);
writeln("Right After);
...
}
...
}

Re: unDE 0.2.0 - unusual command line and keybar

[unDEFER via Digitalmars-d-announce]

On Friday, 3 February 2017 at 17:11:26 UTC, Chris Wright wrote:
I think `mkdirRecurse` doesn't complain about directories that 
already exist.


Thank you!

[Issue 17141] New: CommonType!(dchar, char) returns uint

[via Digitalmars-d-bugs]

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

  Issue ID: 17141
   Summary: CommonType!(dchar, char) returns uint
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

Should return dchar.

This breaks range functions like chain, example:

string name = "Jack";
auto app = appender!string();
app.put(
chain(name, toChars(10))
);


Error: template std.array.Appender!string.Appender.put cannot deduce function
from argument types !()(Result), candidates are:
/usr/local/Cellar/dmd/2.073.0/include/dlang/dmd/std/array.d(2820):   
std.array.Appender!string.Appender.put(U)(U item) if (canPutItem!U)
/usr/local/Cellar/dmd/2.073.0/include/dlang/dmd/std/array.d(2848):   
std.array.Appender!string.Appender.put(Range)(Range items) if
(canPutConstRange!Range)
/usr/local/Cellar/dmd/2.073.0/include/dlang/dmd/std/array.d(2857):   
std.array.Appender!string.Appender.put(Range)(Range items) if
(canPutRange!Range)

--

Is there anything fundamentally wrong with this code?

[WhatMeWorry via Digitalmars-d-learn]

The code below compiles fine but I always get a run time abort 
with the error down below.  Isn't the postProc at module scope so 
shouldn't the class instance always be around (ie not 
deallocated?)  If it helps, this was translated from C++ code.  
Thanks.



-file post_processor.d --
module post_processor;

class PostProcessor
{
...
GLuint FBO;

}

-file game.d ---
module game;

PostProcessor  postProc; // just a declaration (no memory 
allocation)


class Game
{
...
void initGame(){
...
PostProcessor postProc = new PostProcessor(...);
...
}
...
void update(GLfloat deltaTime){
...
writeln("Right Before");
writeln("postProcesor.FBO = ", postProc.FBO);
writeln("Right After);
...
}
...
}


Right Before
Program exited with code -1073741819
myapp exited with code 2

Re: unDE 0.2.0 - unusual command line and keybar

[Chris Wright via Digitalmars-d-announce]

On Fri, 03 Feb 2017 14:18:05 +, Basile B. wrote:
> Also before that there's two FileException thrown because you use
> mkdir() systematically with a silent try catch. You should rather test
> if the the directories exist (when you create ~/.unde/  and
> ~/.unde/bdb/, global_state.d) because it tends to be annoying when
> trying to get that stack trace for the real exception !

I think `mkdirRecurse` doesn't complain about directories that already 
exist.

Re: Workaround for DIP 1005

[Chris Wright via Digitalmars-d]

On Fri, 03 Feb 2017 14:43:01 +, Dominikus Dittes Scherkl wrote:
> fun.ST fun()
> {
> import someModule.SomeType;
> alias ST = SomeType;
> ...
> }

What compiler version is this? I'm getting segfaults with both 2.072.2 and 
2.073.0.

Reported as https://issues.dlang.org/show_bug.cgi?id=17140

[Issue 17140] Segfault when using function-name-qualified renamed import as function return type

[via Digitalmars-d-bugs]

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

Chris Wright  changed:

   What|Removed |Added

 OS|Windows |Linux

--

[Issue 17140] Segfault when using function-name-qualified renamed import as function return type

[via Digitalmars-d-bugs]

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

--- Comment #1 from Chris Wright  ---
Doesn't have to be a static import:

---
fun.S fun()
{
import std.socket;
alias S = Socket;
return null;
}
---

--

[Issue 17140] Segfault when using function-name-qualified renamed import as function return type

[via Digitalmars-d-bugs]

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

Chris Wright  changed:

   What|Removed |Added

   Keywords||ice

--

[Issue 17140] New: Segfault when using function-name-qualified renamed import as function return type

[via Digitalmars-d-bugs]

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

  Issue ID: 17140
   Summary: Segfault when using function-name-qualified renamed
import as function return type
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: dhase...@gmail.com

I don't know if this is supposed to be valid code or not.

Code:

foo.socks.Socket foo()
{
import socks = std.socket;
return null;
}

Stacktrace:

#0  0x0059a934 in Scope::search(Loc, Identifier*, Dsymbol**, int) ()
#1  0x00671eb3 in TypeIdentifier::resolve(Loc, Scope*, Expression**,
Type**, Dsymbol**, bool) ()
#2  0x0067210a in TypeIdentifier::semantic(Loc, Scope*) ()
#3  0x0066d5a0 in TypeFunction::semantic(Loc, Scope*) ()
#4  0x005d5658 in VarExp::semantic(Scope*) ()
#5  0x005d9247 in UnaExp::unaSemantic(Scope*) ()
#6  0x005dc737 in DotIdExp::semanticX(Scope*) ()
#7  0x005dcf4e in DotIdExp::semanticY(Scope*, int) ()
#8  0x005dc639 in DotIdExp::semantic(Scope*) ()
#9  0x005d9247 in UnaExp::unaSemantic(Scope*) ()
#10 0x005dc737 in DotIdExp::semanticX(Scope*) ()
#11 0x005dcf4e in DotIdExp::semanticY(Scope*, int) ()
#12 0x005dc639 in DotIdExp::semantic(Scope*) ()
#13 0x00671238 in TypeQualified::resolveHelper(Loc, Scope*, Dsymbol*,
Dsymbol*, Expression**, Type**, Dsymbol**, bool) ()
#14 0x00671efc in TypeIdentifier::resolve(Loc, Scope*, Expression**,
Type**, Dsymbol**, bool) ()

--

[Issue 17130] [Reg 2.074] ambiguous implicit super call when inheriting core.sync.mutex.Mutex

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #4 from Martin Nowak  ---
https://github.com/dlang/dmd/pull/6513

--

Re: unDE 0.2.0 - unusual command line and keybar

[unDEFER via Digitalmars-d-announce]

On Friday, 3 February 2017 at 14:18:05 UTC, Basile B. wrote:

Also before that there's two FileException thrown because you 
use mkdir() systematically with a silent try catch. You should 
rather test if the the directories exist (when you create 
~/.unde/  and ~/.unde/bdb/, global_state.d) because it tends to 
be annoying when trying to get that stack trace for the real 
exception !


OK, will be fixed.

Re: unDE 0.2.0 - unusual command line and keybar

[unDEFER via Digitalmars-d-announce]

On Friday, 3 February 2017 at 14:05:58 UTC, Basile B. wrote:

What is the name of the static lib we have to install for for 
"DB" ?


/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: ne 
peut trouver -ldb
collect2: error: ld returned 1 exit status
Error: linker exited with status 1


You must usr libdb 5.3. Your seg.fault because you use version 
lesser.

Re: Workaround for DIP 1005

[Dominikus Dittes Scherkl via Digitalmars-d]

On Friday, 3 February 2017 at 14:59:09 UTC, rikki cattermole 
wrote:

On 04/02/2017 3:43 AM, Dominikus Dittes Scherkl wrote:
DIP 1005 provides new syntax to make it possible to avoid 
global imports.

But this can already be worked around with some nice trick:
Any thoughts?


Needless syntax sugar:

?!?
What is syntactic sugar?
I did NOT propose any new syntax - my workaround already works 
with the current D language. In fact I think DIP1005 is syntactic 
sugar (maybe even "needless").

Re: Workaround for DIP 1005

[Daniel N via Digitalmars-d]

On Friday, 3 February 2017 at 14:43:01 UTC, Dominikus Dittes 
Scherkl wrote:
DIP 1005 provides new syntax to make it possible to avoid 
global imports.

Any thoughts?


I like it!

template imp(string mod)
{
  mixin("import imp = " ~ mod ~ ";");
}

auto fun_time(imp!"std.datetime".SysTime tm)
{
  return tm;
}

void main()
{
  import std.stdio;
  import std.datetime;

  fun_time(Clock.currTime()).writeln;
}

Re: GSoC Project Idea's Part 2

[rikki cattermole via Digitalmars-d]

On 04/02/2017 3:53 AM, CRAIG DILLABAUGH wrote:

On Friday, 3 February 2017 at 04:14:58 UTC, rikki cattermole wrote:

FYI there has been a few people asking about GSOC on #D, any chance
you could hang out there so if anybody turns up you can help em' out?


I will make a point of going on #D whenever I can over the coming weeks,
but that may be limited.  Anyone please feel free to direct students to
our ideas page (where they can find my email address).  I tend to do a
better job of answering emails.


We already do that.
Generally they are at the stage that they are considering it and want 
more information. But not enough as to email you.

Re: Workaround for DIP 1005

[rikki cattermole via Digitalmars-d]

On 04/02/2017 3:43 AM, Dominikus Dittes Scherkl wrote:

DIP 1005 provides new syntax to make it possible to avoid global imports.
Till now global imports are necessary if a function uses types declared
in some imported module within it's declaration or definition (otherwise
a local import will do).

But this can already be worked around with some nice trick:

import someModule.SomeType;

SomeType fun()
{
   ...
}

can be replaced by:

fun.ST fun()
{
   import someModule.SomeType;
   alias ST = SomeType;
   ...
}

The same strategy works with types used in parameters or constraints, of
course.

Any thoughts?


Needless syntax sugar:

struct Foo { int x; }

Foo func() {
return Foo(9);  
}

typeof(func()) func2() {
return func();  
}

void main() {
assert(func2.x == 9);   
}

Re: GSoC Project Idea's Part 2

[CRAIG DILLABAUGH via Digitalmars-d]

On Friday, 3 February 2017 at 04:14:58 UTC, rikki cattermole 
wrote:

On 03/02/2017 5:12 PM, Craig Dillabaugh wrote:
So the GSoC ideas page is now at least partially complete, you 
can find

it here:

https://wiki.dlang.org/GSOC_2017_Ideas

In the previous thread some of you (Rikki, Adam) had suggested 
some

improvements to dub/the code.dlang.org website.  Either of you
interested in mentoring something around that?


I'm quite busy this semester, so I am unavailable.

So new project ideas are welcome, and feel free to post any 
ideas you
have here for comment.  Also we need mentors so if you post a 
new
project, or see one on the existing ideas page please feel 
free to offer

your services as a mentor.

The application process finishes on Feb. 9th.

Cheers

Craig


FYI there has been a few people asking about GSOC on #D, any 
chance you could hang out there so if anybody turns up you can 
help em' out?


I will make a point of going on #D whenever I can over the coming 
weeks, but that may be limited.  Anyone please feel free to 
direct students to our ideas page (where they can find my email 
address).  I tend to do a better job of answering emails.

Workaround for DIP 1005

[Dominikus Dittes Scherkl via Digitalmars-d]

DIP 1005 provides new syntax to make it possible to avoid global 
imports.
Till now global imports are necessary if a function uses types 
declared in some imported module within it's declaration or 
definition (otherwise a local import will do).


But this can already be worked around with some nice trick:

import someModule.SomeType;

SomeType fun()
{
   ...
}

can be replaced by:

fun.ST fun()
{
   import someModule.SomeType;
   alias ST = SomeType;
   ...
}

The same strategy works with types used in parameters or 
constraints, of course.


Any thoughts?

Any full-text search library

[Soolayman via Digitalmars-d-learn]

Is there any usable full-text search library? for D I couldn't 
find any except the Elasticsearch client called elasticsearch-d 
in the package registry a very old Lucene port for D1 called 
dlucene. This is it or did I miss something?

Re: unDE 0.2.0 - unusual command line and keybar

[Basile B. via Digitalmars-d-announce]

On Friday, 3 February 2017 at 14:05:58 UTC, Basile B. wrote:

On Friday, 3 February 2017 at 13:48:39 UTC, Basile B. wrote:

On Sunday, 29 January 2017 at 19:00:30 UTC, unDEFER wrote:
unDE's not DE which in the future must be replacement for all 
programs in OS.
But today is very original file manager, image and text 
viewer and (what discovered with 0.2.0 version) command line 
and keybar.

More information: http://unde.sourceforge.net/en/ch25.html
Video with English subtitles: https://youtu.be/XY7Jegxq6vg


What is the name of the static lib we have to install for for 
"DB" ?


/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: ne 
peut trouver -ldb
collect2: error: ld returned 1 exit status
Error: linker exited with status 1


Isee it's BDB, never mind but now on OpenSuse I got a SEGFAULT 
during BDB init


~"#0  0x in ?? ()\n"
#0  0x in ?? ()
~"#1  0x0071ee68 in 
berkeleydb.dbenv.DbEnv.set_memory_max(uint, uint) 
(this=0x77ec5100, bytes=16777216, gbytes=0) at 
../../../.dub/packages/bdb2d-5.3.28/bdb2d/source/berkeleydb/dbenv.d:757\n"
~"#2  0x0071ef20 in 
berkeleydb.dbenv.DbEnv.set_memory_max(ulong) 
(this=0x77ec5100, bytes=16777216) at 
../../../.dub/packages/bdb2d-5.3.28/bdb2d/source/berkeleydb/dbenv.d:765\n"
~"#3  0x0065a636 in 
unde.global_state.GlobalState.__mixin109.initBDB(bool) 
(this=0x76571000, force_recover=false) at 
source/unde/global_state.d:117\n"
~"#4  0x0065baf8 in 
unde.global_state.GlobalState.this(bool) (this=0x76571000, 
force_recover=false) at source/unde/global_state.d:972\n"
~"#5  0x006f16d6 in D main (args=...) at 
source/unde/main.d:25\n"


Also before that there's two FileException thrown because you use 
mkdir() systematically with a silent try catch. You should rather 
test if the the directories exist (when you create ~/.unde/  and 
~/.unde/bdb/, global_state.d) because it tends to be annoying 
when trying to get that stack trace for the real exception !

Re: unDE 0.2.0 - unusual command line and keybar

[Basile B. via Digitalmars-d-announce]

On Friday, 3 February 2017 at 13:48:39 UTC, Basile B. wrote:

On Sunday, 29 January 2017 at 19:00:30 UTC, unDEFER wrote:
unDE's not DE which in the future must be replacement for all 
programs in OS.
But today is very original file manager, image and text viewer 
and (what discovered with 0.2.0 version) command line and 
keybar.

More information: http://unde.sourceforge.net/en/ch25.html
Video with English subtitles: https://youtu.be/XY7Jegxq6vg


What is the name of the static lib we have to install for for 
"DB" ?


/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: ne 
peut trouver -ldb
collect2: error: ld returned 1 exit status
Error: linker exited with status 1


Isee it's BDB, never mind but now on OpenSuse I got a SEGFAULT 
during BDB init


~"#0  0x in ?? ()\n"
#0  0x in ?? ()
~"#1  0x0071ee68 in 
berkeleydb.dbenv.DbEnv.set_memory_max(uint, uint) 
(this=0x77ec5100, bytes=16777216, gbytes=0) at 
../../../.dub/packages/bdb2d-5.3.28/bdb2d/source/berkeleydb/dbenv.d:757\n"
~"#2  0x0071ef20 in 
berkeleydb.dbenv.DbEnv.set_memory_max(ulong) 
(this=0x77ec5100, bytes=16777216) at 
../../../.dub/packages/bdb2d-5.3.28/bdb2d/source/berkeleydb/dbenv.d:765\n"
~"#3  0x0065a636 in 
unde.global_state.GlobalState.__mixin109.initBDB(bool) 
(this=0x76571000, force_recover=false) at 
source/unde/global_state.d:117\n"
~"#4  0x0065baf8 in 
unde.global_state.GlobalState.this(bool) (this=0x76571000, 
force_recover=false) at source/unde/global_state.d:972\n"
~"#5  0x006f16d6 in D main (args=...) at 
source/unde/main.d:25\n"


auto ret = dbenv.set_memory_max(dbenv, gbytes, bytes);

Re: unDE 0.2.0 - unusual command line and keybar

[Basile B. via Digitalmars-d-announce]

On Sunday, 29 January 2017 at 19:00:30 UTC, unDEFER wrote:
unDE's not DE which in the future must be replacement for all 
programs in OS.
But today is very original file manager, image and text viewer 
and (what discovered with 0.2.0 version) command line and 
keybar.

More information: http://unde.sourceforge.net/en/ch25.html
Video with English subtitles: https://youtu.be/XY7Jegxq6vg


What is the name of the static lib we have to install for for 
"DB" ?


/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: ne 
peut trouver -ldb
collect2: error: ld returned 1 exit status
Error: linker exited with status 1

Re: How to write Good IDE?

[unDEFER via Digitalmars-d]

On Friday, 3 February 2017 at 12:37:53 UTC, Jacob Carlborg wrote:
The old Eclipse plugin for D1, Descent [1], is the gold 
standard when it comes to IDE's for D. Check the features list 
[2] to get some ideas and inspiration.


[1] http://www.dsource.org/projects/descent
[2] http://www.dsource.org/projects/descent#Features


Thank you! Good links.

Re: vibe.d 0.8.0 and 0.7.31 beta releases

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

Am 03.02.2017 um 10:28 schrieb yazd:

On Tuesday, 31 January 2017 at 11:11:28 UTC, Sönke Ludwig wrote:

The first release of the revamped core module [1] is nearing, and
along with that, a compatible vibe.d release (0.8.0). The new core
module is still opt-in in this release and can be activated using a
`subConfiguration "vibe-d:core" "vibe-core"` directive in dub.sdl
(`"subConfigurations": {"vibe-d:core": "vibe-core"}` in dub.json).



I am always excited to see a new release of vibe-d. Thank you!



- Large parts of the API are now annotated with nothrow and @safe. In
  case of APIs that depend on callbacks, these can be breaking changes,
  but the most prominent places have deprecation paths in place.



Is it possible to have non-@safe callbacks be part of the non-deprecated
API? Personally, I think @safe adds very little value compared to the
headaches it causes and the time and efforts required to have every
piece of your code properly annotated (it is sometimes impossible when
using dependencies or even phobos and druntime without going into the
lengthy process of doing upstream changes and waiting for new versions).

I don't think it adds value because I write my code in idiomatic D,
which is mostly safe in reality but not necessarily @safe compliant.

On the other hand, I am all for nothrow changes.


Keeping the system overloads would break the safety guarantees at a 
relatively deep level and would render the whole effort rather useless 
(this is the case for non-scope callbacks only, so if you stumble over a 
deprecated function with a scope callback, then it should be fixed).


I agree that currently the effort/benefit ratio is rather limited, 
because there are still many areas in Druntime/Phobos that have not been 
updated, and because there are still some big holes in the system.


However, there are two critical reasons why I still want to embrace it 
for vibe.d. First, it actually has helped to detect some rather subtle 
issues in the past that have gone unnoticed for a long time otherwise. 
And, maybe more importantly, annotating code as safe is the only way to 
guarantee proper bounds checks, which is critical for a server 
component. And finally, I feel that if nobody starts to embrace this on 
a broader level now, it will never reach a truly mature state.


If you really don't care about these annotations, you can always simply 
put a "@trusted:" at the top of the module/class and be done with it. 
But since vibe.d is now annotated with safe, as well as an ever growing 
subset of Phobos/Druntime, writing with annotations is actually quite 
painless, except possibly for third party dependencies, of course*.



* The most annoying thing I found the language itself was that .byKey 
for associative arrays is @system.

Re: LDC 1.1.0 released

[kinke via Digitalmars-d-announce]

On Friday, 3 February 2017 at 12:21:09 UTC, deadalnix wrote:

What's the state of cent/ucent ?


Unchanged as https://github.com/ldc-developers/ldc/pull/1659 is 
still pending and Kai doesn't have time ATM. If you're very 
interested in 128-bit integers, please consider continuing that 
PR yourself (I only recall you asking for it, general interest 
seems pretty low). I don't know if newer front-ends already have 
better cent support (2.072.2 is currently being merged, see 
https://github.com/ldc-developers/ldc/pull/1987).

Re: memcpy() comparison: C, Rust, and D

[Nick Treleaven via Digitalmars-d]

On Thursday, 2 February 2017 at 20:37:32 UTC, Random D user wrote:
What if d had a -safe-defaults switch? It should be ok, since 
safe is stricter than unsafe right?


Yes, we need this because module-level '@safe:' doesn't allow 
inferrence of @system.


This way old/existing code would compile fine by default, but 
if you want to use that code/lib with safe-defaults you either 
have to do trusted wrappers or modify it to be safe.


Or just override the default with @system when you need it. 
System library code probably can't easily be wrapped with 
@trusted (correctly, see below).


I myself don't really care for @safe, it's complex and seems to 
have big practical hole with @trusted.


It's the same as Rust unsafe blocks. Without this 'hole' @safe 
would be much more limited and inefficient, so no one would use 
it. If @trusted is used in a way that exposes unsafe behaviour, 
that is a programmer bug. The good news is, projects shouldn't 
have much @trusted code and it can easily be grepped for.


I've already thrown const, immutable, inout mostly in to trash 
(string literals etc. are exception) after few tries. They make 
the code more complex and harder to modify especially when you 
have bigger system. Often you realize that your system/module 
isn't truly 100% const in the last insignificant leaf function, 
and that triggers large  cascading modifications and rewrites, 
just to get the code work.


Transitive immutability is very different to shallow const, you 
can't use it so often, but it guarantees safe sharing of data 
across threads or even just string slices in single threaded 
programs without the possibility of accidental modification.

Re: vibe.d 0.8.0 and 0.7.31 beta releases

[yazd via Digitalmars-d-announce]

On Friday, 3 February 2017 at 12:25:42 UTC, Dominikus Dittes 
Scherkl wrote:

On Friday, 3 February 2017 at 09:28:26 UTC, yazd wrote:
Is it possible to have non-@safe callbacks be part of the 
non-deprecated API?

Why?
A @safe API allows you to use it within @safe code, but it 
doesn't require you to also write @safe code.
Especially if you don't like to annotate your code to be @safe, 
even if you think it is safe, this doesn't hinders you to use 
other peoples @safe code.
Only the reverse is a problem (other people, who like to 
annotate their code @safe, can't use your code if it is not 
annotated - so they start to ignore your code even if it would 
be @safe only because you don't bother).


What you are saying is true when you are the caller, but in this 
case, the callbacks provided to the API are what is required to 
be @safe and accordingly my code is required to be @safe.


For example, this is the signature for `setTimer`:
Timer setTimer(Duration timeout, void delegate() nothrow 
@safe callback, bool periodic = false) @safe nothrow;


I can't even use `logInfo("%s", ex)` where `ex` is an `Exception` 
in @safe code, because `Exception.toString()` isn't @safe and it 
can't be @safe because it is a virtual function, and there are 
many cases of such problems.

Re: How to write Good IDE?

[Jacob Carlborg via Digitalmars-d]

On 2017-02-01 16:12, unDEFER wrote:

Hello!
So my unDE 0.2.0 is released
(http://forum.dlang.org/thread/yzfthfipouzhejfsk...@forum.dlang.org),
and this means that the time to write unDE 0.3.0 - text editor and IDE.

And I grab my head when thinking how much I want to implement.

1) It must shows unused modules
2) It must shows parts of modules which used by module
3) It must shows not caught exceptions
4) It must autocomplete always even "string".to

I have seen pretty tool from Hackerpilot (DCD, dfmt, Dscanner), but it
doesn't cover this list.

And I think how easier may be implement such IDE? From zero, or maybe
possible to use parts of dmd/gdc?
And what important for you for Good IDE?


The old Eclipse plugin for D1, Descent [1], is the gold standard when it 
comes to IDE's for D. Check the features list [2] to get some ideas and 
inspiration.


[1] http://www.dsource.org/projects/descent
[2] http://www.dsource.org/projects/descent#Features

--
/Jacob Carlborg

Re: vibe.d 0.8.0 and 0.7.31 beta releases

[Dominikus Dittes Scherkl via Digitalmars-d-announce]

On Friday, 3 February 2017 at 09:28:26 UTC, yazd wrote:
Is it possible to have non-@safe callbacks be part of the 
non-deprecated API?

Why?
A @safe API allows you to use it within @safe code, but it 
doesn't require you to also write @safe code.
Especially if you don't like to annotate your code to be @safe, 
even if you think it is safe, this doesn't hinders you to use 
other peoples @safe code.
Only the reverse is a problem (other people, who like to annotate 
their code @safe, can't use your code if it is not annotated - so 
they start to ignore your code even if it would be @safe only 
because you don't bother).

Re: LDC 1.1.0 released

[deadalnix via Digitalmars-d-announce]

On Wednesday, 1 February 2017 at 03:43:10 UTC, David Nadlinger 
wrote:

Hi all,

Version 1.1.0 of LDC, the LLVM-based D compiler, has finally 
been released: 
https://github.com/ldc-developers/ldc/releases/tag/v1.1.0


Please head over to the digitalmars.D.ldc forums for more 
details and discussions: 
http://forum.dlang.org/post/etynfqwjosdvuuukl...@forum.dlang.org


 — David


What's the state of cent/ucent ?

Re: memcpy() comparison: C, Rust, and D

[Atila Neves via Digitalmars-d]

On Thursday, 2 February 2017 at 20:50:58 UTC, Walter Bright wrote:

On 2/2/2017 6:19 AM, Atila Neves wrote:
Also, unless you're testing possible bugs in compiler backends 
or the C standard
library, it mostly doesn't matter. Compile on regular 
x86/Linux and run

valgrind/asan there.


I've often been able to flush out difficult bugs by compiling 
on another platform.


Back in the bad old DOS days, I quickly learned to develop the 
programs on a protected mode operating system, then port to 16 
bit real mode DOS as the last step. :-)


That I can see the value in. But (fortunately) those days are 
long gone.





Have I run into weird bugs that only occurred on one platform? 
Yes. Were they

_really_ rare? You betcha. *


Memory corruption bugs show themselves differently on different 
platforms, and one of them likely will make it easier to find 
the bug.


Right, but we're talking about finding memory corruption bugs 
_before_ they manifest themselves. As I mentioned in my other 
reply, if you have memory corruption bugs in common 
cross-platform code, valgrind and asan will (nearly always) catch 
them. You don't need to wait for weird effects that are hard to 
trace back. Run on Linux with both valgrind and asan and you'll 
be fine 99.9%*  of the time.


Atila

* stats totally made up

Re: Request for conference talk

[qznc via Digitalmars-d]

On Thursday, 2 February 2017 at 21:09:38 UTC, Chris Engelbert 
wrote:

Hey guys,

we organize a conference (TopConf) this year for the first time 
in Dusseldorf, Germany. I would like to see if there are 
interested speakers to give a talk about D. The conference is 
hold in English and is not specific to a single programming 
language but will feature multiple different ones as well as 
some more soft-skill like sessions / tracks.


I'm looking forward to see if there are interested people. The 
CFP page is available here: 
https://www.topconf.com/conference/duesseldorf-2017/callforpaper



I'm tempted and will think about it.

Topic idea one: Dust off my "Functional Programming in D" [0] 
talk. However, it is tight in 40 minutes for an audience, which 
probably does not know D at all.


Topic idea two: A more general talk about abstractions. Starting 
from the basics (procedures) up to Design-by-Introspection 
techniques which are quite D specific. In between stuff like the 
"magic" D Lua bindings. This topic is probably interesting for 
C++ and Java programmers as well. Other TopConf talks and thus 
the audience seem to be quite mainstream.


[0] http://beza1e1.tuxen.de/articles/functional_D.html

Re: memcpy() comparison: C, Rust, and D

[Atila Neves via Digitalmars-d]

On Thursday, 2 February 2017 at 16:44:26 UTC, Chris Wright wrote:

On Thu, 02 Feb 2017 14:19:02 +, Atila Neves wrote:
Also, unless you're testing possible bugs in compiler backends 
or the C standard library, it mostly doesn't matter. Compile 
on regular x86/Linux and run valgrind/asan there.


Assuming you're writing cross-platform code. How common is 
that? I write Java for a living, and some of my code only works 
on Linux. (It does at least fail gracefully on OSX, which my 
coworkers use.)


Ah, Java: write once, debug everywhere. :P

I almost always write cross-platform code. In C or C++, 
valgrind/asan will catch nearly all memory corruption problems on 
plain Linux. It's only weird corner cases that escape.


Which isn't to say you won't have Windows-only bugs, say. What 
I'm saying is if you read past the end of an allocated buffer you 
don't _need_ to test on all platforms. That'll be caught. i.e. 
the lack of valgrid on Windows or an embedded platform isn't a 
big deal.


Atila

Re: GC question

[osa1 via Digitalmars-d-learn]

On Friday, 3 February 2017 at 10:49:00 UTC, Kagamin wrote:
Leaks are likely in 32-bit processes and unlikely in 64-bit 
processes. See e.g. 
https://issues.dlang.org/show_bug.cgi?id=15723


This looks pretty bad. I think I'll consider something else until 
D's memory management story gets better. This is sad because the 
language otherwise looks quite good, and I'd love to try 
assertions, contracts, scope guards, macros etc.

Re: Request for conference talk

[Stefan Koch via Digitalmars-d]

On Thursday, 2 February 2017 at 21:09:38 UTC, Chris Engelbert 
wrote:

Hey guys,

we organize a conference (TopConf) this year for the first time 
in Dusseldorf, Germany. I would like to see if there are 
interested speakers to give a talk about D. The conference is 
hold in English and is not specific to a single programming 
language but will feature multiple different ones as well as 
some more soft-skill like sessions / tracks.


I'm looking forward to see if there are interested people. The 
CFP page is available here: 
https://www.topconf.com/conference/duesseldorf-2017/callforpaper


Thanks,
Chris

PS: Feel free to ask for further information :)


Hello Chris, would you also be interested in a more 
compiler-internals related talk about D ?

If so I am happy to volunteer.

Re: GC question

[Kagamin via Digitalmars-d-learn]

On Wednesday, 1 February 2017 at 06:58:43 UTC, osa1 wrote:

Are there any disallowed memory operations?


Currently can't touch GC from destructor during collection. 
Another concern is interoperability with C-allocated memory: GC 
knows nothing about C heap.



How often does it leak?


Leaks are likely in 32-bit processes and unlikely in 64-bit 
processes. See e.g. https://issues.dlang.org/show_bug.cgi?id=15723



Do I need to be careful with some operations to avoid leaks?


Leaks happen only due to false pointers. But data allocated in GC 
with new operator and known to have no pointers (e.g. strings) is 
not scanned. Premature collection happen when GC doesn't see a 
pointer to the allocated data, happens when such pointer is put 
in a memory GC doesn't see, like C heap.



Is a precise GC in the roadmap?


There's an effort on it: 
https://forum.dlang.org/post/hdwwkzqswwtffjehe...@forum.dlang.org


It's fine if I have to do manual memory management, but I don't 
want any leaks.


If you manually deallocate memory, it gets deallocated for sure, 
shouldn't leak.
Comparing to java, D GC trades GC performance for code execution 
performance, which can result in better overall performance when 
you don't allocate much and worse performance for 
allocation-heavy code that java GC is optimized for.

[Issue 17139] [BLOCKING] dscanner needs to handle 'scope' function attributes

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--- Comment #1 from ZombineDev  ---
The issue is already reported on the project's repo:
https://github.com/Hackerpilot/Dscanner/issues/397

--

Re: The reason of vibed slow down (request timeout)

[aberba via Digitalmars-d-learn]

On Friday, 3 February 2017 at 06:46:37 UTC, Suliman wrote:
If I open it's from VPS (as localhost:8080) it's work same as 
from Internet (no do not open at all).


One this I may suggest is the port if its used already (8080). 
Try to use;


import std.process: environment;
settings.port = environment.get("PORT", "8080").to!short;

Re: vibe.d 0.8.0 and 0.7.31 beta releases

[yazd via Digitalmars-d-announce]

On Tuesday, 31 January 2017 at 11:11:28 UTC, Sönke Ludwig wrote:
The first release of the revamped core module [1] is nearing, 
and along with that, a compatible vibe.d release (0.8.0). The 
new core module is still opt-in in this release and can be 
activated using a `subConfiguration "vibe-d:core" "vibe-core"` 
directive in dub.sdl (`"subConfigurations": {"vibe-d:core": 
"vibe-core"}` in dub.json).




I am always excited to see a new release of vibe-d. Thank you!



- Large parts of the API are now annotated with nothrow and 
@safe. In
  case of APIs that depend on callbacks, these can be breaking 
changes,

  but the most prominent places have deprecation paths in place.



Is it possible to have non-@safe callbacks be part of the 
non-deprecated API? Personally, I think @safe adds very little 
value compared to the headaches it causes and the time and 
efforts required to have every piece of your code properly 
annotated (it is sometimes impossible when using dependencies or 
even phobos and druntime without going into the lengthy process 
of doing upstream changes and waiting for new versions).


I don't think it adds value because I write my code in idiomatic 
D, which is mostly safe in reality but not necessarily @safe 
compliant.


On the other hand, I am all for nothrow changes.

Re: Snap packages for D compilers and core projects

[qznc via Digitalmars-d]

On Monday, 30 January 2017 at 16:53:34 UTC, Joseph Rushton 
Wakeling wrote:
Snap packaging started as something Ubuntu were developing for 
their use-case, but started gaining cross-distro interest last 
year (probably because AFAICT its feature-set and simplicity of 
use is quite a bit ahead of alternatives like Flatpak).


I just tried FlatPak and Snap. Snap is actually useable.

FlatPak might be superior technology with its sandboxing, but I'm 
no expert. FlatPak has no central repository, which makes it 
unuseable for the layman at the moment. It feels like the PPA 
situation in Ubuntu.


Snap has stuff like pulseaudio (audio daemon) or ogre (rendering 
engine) in the repo. That seems weird, because these are not 
applications. The first belongs into the base system, the second 
into a development environment.

Re: Typo on the grammar section of the spec

[Ali Çehreli via Digitalmars-d]

On 02/02/2017 10:07 PM, FatalCatharsis wrote:

> Cool, is there some place to make an issue for it?

Try the two links at the top of each page: "Report a bug" and "Improve 
this page"


> Don't want any unsuspecting goobers like me falling for it :P.

People who read those pages down to every colon deserve to suffer. :o) 
(Actually, I think you implied that one of your tools is parsing that page.)


Ali