Re: good form? posting semi D-related part-time contract job to announce?

[Stefan Koch via Digitalmars-d]

On Monday, 29 February 2016 at 01:05:55 UTC, Laeeth Isharc wrote:

Hi.

Just to check if it's good form.

I'm looking for someone to help (initially) part-time with 
linux server admin.  Happy if scripts are written in D and it's 
for a project where most code is in D.  Is it okay to post to 
announce?



Laeeth.


How can one contact you about that offer ?

Re: Hotfix release vibe.d 0.7.28

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

Am 29.02.2016 um 00:47 schrieb sigod:

On Saturday, 27 February 2016 at 16:21:05 UTC, Sönke Ludwig wrote:

This is a small bugfix release that mainly fixes two critical
regressions:

 - FreeListRef!T, which is used heavily in the HTTP server code, stored
   its reference count in an unallocated memory region, leading to
   possible memory leaks or memory corruption

 - A TCP connection with a non-empty write buffer that got closed by
   the remote peer and locally at the same time could result in the
   calling task to starve (i.e. it got never resumed after yielding
   execution). In particular, this could happen when accessing HTTPS
   servers with the HTTP client in conjunction with "Connection: close".

http://vibed.org/blog/posts/vibe-release-0.7.28


You forgot to update site header.


Thanks, also forgot the documentation (even if nothing has changed).



Is there any plans on when big split will happen?


It will be a step-by-step process. I'm currently working on a new 
version of the `vibe.core` package that contains some large changes 
under the hood. Once that is in a functional state, I'll look into how 
to enable optional replacement of the existing vibe:core package by this 
new, separately hosted vibe-core package. vibe:core, at that point, will 
only receive bug fixes and continues to live for a while (let's say a 
year or one and a half).


The same procedure will then happen for vibe:http (the new package will 
include HTTP/2 support) and the other sub packages.


All of the new packages will get a version number of 1.0.0, once they 
can be considered reasonably stable.


One unfortunate aspect of my current work on vibe-core is that I'm 
building on a new event loop abstraction that I built as a prototype to 
see where the performance bottlenecks of the current system are. 
libasync was too slow and it had a too complicated structure to make 
quick tests for improving performance. Now I'm leaning towards 
finalizing the new prototype library and proposing it for Phobos 
inclusion at some point.

Re: State of the Compiler

[Suliman via Digitalmars-d]

On Monday, 29 February 2016 at 04:53:16 UTC, Jack Stouffer wrote:
On Monday, 29 February 2016 at 00:10:33 UTC, Walter Bright 
wrote:

12. start retrofitting with phobos algorithms


Other DMD devs have taken a hard line stance that Phobos code 
cannot and should not be used in ddmd. What's your opinion on 
that?


Please, explain the situation...

Re: State of the Compiler

[Jacob Carlborg via Digitalmars-d]

On 2016-02-29 05:57, Walter Bright wrote:


There are good reasons for that. But there's no reason why
std.algorithm.sort, for example, cannot still be used (cut & paste).


Unfortunately Phobos has quite a complex dependency graph. Pulling in 
std.algorithm.sort will most likely pull in half of Phobos.


--
/Jacob Carlborg

Re: Why is mangling different for separate compilation?

[Jacob Carlborg via Digitalmars-d]

On 2016-02-28 22:03, Chris Wright wrote:


Or like there's a global counter that is incremented for each unittest. A
different order of traversal of unittests would result in a different
mangled name for the same unittest in different runs.


The question is why it would be different.

Here's a guess:

* The compiler will perform semantic analysis of the code in the current 
module before processing any imports


* It will also process all files on the command line before processing 
any imports


* The compiler will process object.d before processing any other imports

That would mean in the case when compiling foo.d during separate 
compilation it would process object.d before processing bar.d. That 
would mean the compiler is processing a lot unittest blocks through 
object.d and its imports before processing the unittest block in bar.d.


--
/Jacob Carlborg

Re: A suggestion for dub

[Brad Anderson via Digitalmars-d]

On Monday, 29 February 2016 at 05:59:56 UTC, mahdi wrote:
On Monday, 29 February 2016 at 05:16:50 UTC, Brad Anderson 
wrote:

On Monday, 29 February 2016 at 04:46:13 UTC, mahdi wrote:

[...]


A neat feature would be to deploy it using the github releases 
feature. There is an API for it: 
https://developer.github.com/v3/repos/releases/


Being able to upload program binaries for end users 
(non-programmers) to use would be killer.


But definitely those binaries won't be cross-platform! That's 
why I think uploading/downloading source code is more robust.


You can upload multiple platform binaries. I'm pretty sure LDC or 
GDC can do some cross compiling too. It's not reasonable to 
expect all end users to compile a program.

Re: A suggestion for dub

[Chris Wright via Digitalmars-d]

On Mon, 29 Feb 2016 04:46:13 +, mahdi wrote:

> I just want to get some feedback to see if this is a good idea or no.
> 
> I propose adding a new command to dub (`dub dist` or `dub package`)
> which will produce a zipped version of the current package. This zip
> file can be uploaded to a central repository (code.dlang.com maybe), and
> others can use this package in their `dub.json` file by adding relevant
> dependency (Behind the scene, dub will fetch and decompress the
> package).

In other words, you want to distribute your source code, but you don't 
want to host a publicly accessibly git repository and don't want to use 
any of the free git hosting services around.

I'm not sure how this would be an advantage. You don't have to learn git, 
I guess? It's less VCS lockin? Though it probably wouldn't be so hard to 
add mercurial and svn plugins for dub.

Something that *would* be useful is a command that produces binaries and, 
in the case of libraries, D interface files so people can depend on the 
library even if the full source code isn't available. The obvious 
problem: D is typically compiled to native code. That means you have to 
compile once for each platform. Also, you need a different binary for 
every set of version() flags the thing supports. That makes binary 
distribution tricky in the general case.

Re: Terminix 0.51.0 Released

[Gerald via Digitalmars-d-announce]

On Sunday, 28 February 2016 at 22:33:23 UTC, Mike Wey wrote:

Great work.


Thanks Mike, coming from you that's a real compliment. I really 
appreciate all your work on GtkD and the support you've given me 
in answering questions and dealing with issues.

Re: A suggestion for dub

[mahdi via Digitalmars-d]

On Monday, 29 February 2016 at 05:16:50 UTC, Brad Anderson wrote:

On Monday, 29 February 2016 at 04:46:13 UTC, mahdi wrote:
I just want to get some feedback to see if this is a good idea 
or no.


I propose adding a new command to dub (`dub dist` or `dub 
package`) which will produce a zipped version of the current 
package. This zip file can be uploaded to a central repository 
(code.dlang.com maybe), and others can use this package in 
their `dub.json` file by adding relevant dependency (Behind 
the scene, dub will fetch and decompress the package).


A neat feature would be to deploy it using the github releases 
feature. There is an API for it: 
https://developer.github.com/v3/repos/releases/


Being able to upload program binaries for end users 
(non-programmers) to use would be killer.


But definitely those binaries won't be cross-platform! That's why 
I think uploading/downloading source code is more robust.

Re: good form? posting semi D-related part-time contract job to announce?

[Laeeth Isharc via Digitalmars-d]

On Monday, 29 February 2016 at 01:52:38 UTC, Walter Bright wrote:

On 2/28/2016 5:05 PM, Laeeth Isharc wrote:

Hi.

Just to check if it's good form.

I'm looking for someone to help (initially) part-time with 
linux server admin.
Happy if scripts are written in D and it's for a project where 
most code is in

D.  Is it okay to post to announce?


Laeeth.


For the time being, yes. If such starts getting a lot of 
traffic, we can create another n.g. for it.


Thanks, Walter and Mike.

Re: A suggestion for dub

[Brad Anderson via Digitalmars-d]

On Monday, 29 February 2016 at 04:46:13 UTC, mahdi wrote:
I just want to get some feedback to see if this is a good idea 
or no.


I propose adding a new command to dub (`dub dist` or `dub 
package`) which will produce a zipped version of the current 
package. This zip file can be uploaded to a central repository 
(code.dlang.com maybe), and others can use this package in 
their `dub.json` file by adding relevant dependency (Behind the 
scene, dub will fetch and decompress the package).


A neat feature would be to deploy it using the github releases 
feature. There is an API for it: 
https://developer.github.com/v3/repos/releases/


Being able to upload program binaries for end users 
(non-programmers) to use would be killer.

Re: State of the Compiler

[Walter Bright via Digitalmars-d]

On 2/28/2016 8:53 PM, Jack Stouffer wrote:

On Monday, 29 February 2016 at 00:10:33 UTC, Walter Bright wrote:

12. start retrofitting with phobos algorithms


Other DMD devs have taken a hard line stance that Phobos code cannot and should
not be used in ddmd. What's your opinion on that?


There are good reasons for that. But there's no reason why std.algorithm.sort, 
for example, cannot still be used (cut & paste).

Re: A suggestion for dub

[Rikki Cattermole via Digitalmars-d]

On 29/02/16 5:46 PM, mahdi wrote:

I just want to get some feedback to see if this is a good idea or no.

I propose adding a new command to dub (`dub dist` or `dub package`)
which will produce a zipped version of the current package. This zip
file can be uploaded to a central repository (code.dlang.com maybe), and
others can use this package in their `dub.json` file by adding relevant
dependency (Behind the scene, dub will fetch and decompress the package).


Most of the work is already done.
code.dlang.org already grabs a zip of the contents of the repo from e.g. 
Github.
Dub then just downloads + extracts it. However I don't think its cached 
on code.dlang.org side.


Basically the hard part is writing a new provider and adding the ability 
to upload via api.



Of course the implementation may have changed in the last year or so.

Re: State of the Compiler

[Jack Stouffer via Digitalmars-d]

On Monday, 29 February 2016 at 00:10:33 UTC, Walter Bright wrote:

12. start retrofitting with phobos algorithms


Other DMD devs have taken a hard line stance that Phobos code 
cannot and should not be used in ddmd. What's your opinion on 
that?

A suggestion for dub

[mahdi via Digitalmars-d]

I just want to get some feedback to see if this is a good idea or 
no.


I propose adding a new command to dub (`dub dist` or `dub 
package`) which will produce a zipped version of the current 
package. This zip file can be uploaded to a central repository 
(code.dlang.com maybe), and others can use this package in their 
`dub.json` file by adding relevant dependency (Behind the scene, 
dub will fetch and decompress the package).

Re: State of the Compiler

[Chris Wright via Digitalmars-d]

On Mon, 29 Feb 2016 15:13:28 +1300, Rikki Cattermole wrote:

> I have to suggest this, but how much work do you believe it would take
> to switch over to sdc's frontend instead? (Keeping in mind it isn't
> compiling much right now).

Not impossible, just difficult.

The first step is to catch SDC up to the latest DMD release. That's for 
what it compiles, what it errors about, what it warns about, and ddoc, at 
a minimum. That's for FreeBSD, Linux, OSX, and Windows.

After that, we keep SDC up to date with DMD for some amount of time. We 
announce that we're cutting over and people should migrate their PRs to 
SDC.

In the meantime, the SDC team is just porting changes from DMD to SDC.

Refactoring in place means your PR might need changes to apply correctly, 
but it won't need to be rewritten from scratch. It's far less of an 
interruption.

Re: State of the Compiler

[Rikki Cattermole via Digitalmars-d]

On 29/02/16 1:10 PM, Walter Bright wrote:

I'm pretty unhappy with the state of dmd. I think the best that can be
said for it at the moment is that it works.

1. every time we fix something, there are unexpected regressions.
2. the code is a hopeless tangle.
3. too much global state (like global.errors, which is itself a source
of repeated regressions)
4. it's slowed down substantially.
5. near complete lack of encapsulation
6. my ideas on how software should be written have evolved a lot since
it was laid out

This cannot be fixed overnight, but I've been working on it off and on
in between doing other more urgent things, and submitting PRs for them.
The goals of all this are (and this includes the back end):

1. elimination of all conditional compilation, and macros. All that code
should be encapsulated and banished to Port or Target.

2. encapsulation of all memory management. For example, StringExp's
instance of string data is allocated and free'd all over the place. I've
made some progress in encapsulating it. Getting it properly encapsulated
means we can do Small String Optimization in it, which should get us a
nice boost. SSO for all these sorts of structures needs to be done.

3. retrofit in const as much as possible, and later try to use pure.

4. get rid of all global state variables, except for configuration stuff
set by command line switches

5. convert back end to D.

6. use nested functions to improve encapsulation.

7. remove C++ artifacts, like the fake delegates, and replace them with
real delegates

8. replace symbol tables and custom hash code with builtin hashes, and
fix the builtin hashes if they aren't as fast

9. change to "full lazy" semantic analysis of imports, i.e. only parse
them far enough to build the symbol table. Do semantic analysis of the
symbols only on demand. I did this for enums a while back, and the
results have been very pleasing.

10. use rc memory for CTFE, or even stack memory. this is already done
to a small extent, but should go much further

11. encapsulate, encapsulate, encapsulate

12. start retrofitting with phobos algorithms

13. use ranges


One benefit of all this is we could start using multicores to compile!

This will all take years, but we've already made good progress such as
the conversion of the source code to D.



I have to suggest this, but how much work do you believe it would take 
to switch over to sdc's frontend instead? (Keeping in mind it isn't 
compiling much right now).

Re: good form? posting semi D-related part-time contract job to announce?

[Mike Parker via Digitalmars-d]

On Monday, 29 February 2016 at 01:05:55 UTC, Laeeth Isharc wrote:

Hi.

Just to check if it's good form.

I'm looking for someone to help (initially) part-time with 
linux server admin.  Happy if scripts are written in D and it's 
for a project where most code is in D.  Is it okay to post to 
announce?



Laeeth.


Yes

Re: good form? posting semi D-related part-time contract job to announce?

[Walter Bright via Digitalmars-d]

On 2/28/2016 5:05 PM, Laeeth Isharc wrote:

Hi.

Just to check if it's good form.

I'm looking for someone to help (initially) part-time with linux server admin.
Happy if scripts are written in D and it's for a project where most code is in
D.  Is it okay to post to announce?


Laeeth.


For the time being, yes. If such starts getting a lot of traffic, we can create 
another n.g. for it.

good form? posting semi D-related part-time contract job to announce?

[Laeeth Isharc via Digitalmars-d]

Hi.

Just to check if it's good form.

I'm looking for someone to help (initially) part-time with linux 
server admin.  Happy if scripts are written in D and it's for a 
project where most code is in D.  Is it okay to post to announce?



Laeeth.

[Issue 15735] std.algorithm.iteration.splitter returns empty range

[via Digitalmars-d-bugs]

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

--- Comment #1 from Dragos Carp  ---
Fixed with https://github.com/D-Programming-Language/phobos/pull/4030

--

State of the Compiler

[Walter Bright via Digitalmars-d]

I'm pretty unhappy with the state of dmd. I think the best that can be said for 
it at the moment is that it works.


1. every time we fix something, there are unexpected regressions.
2. the code is a hopeless tangle.
3. too much global state (like global.errors, which is itself a source of 
repeated regressions)

4. it's slowed down substantially.
5. near complete lack of encapsulation
6. my ideas on how software should be written have evolved a lot since it was 
laid out


This cannot be fixed overnight, but I've been working on it off and on in 
between doing other more urgent things, and submitting PRs for them. The goals 
of all this are (and this includes the back end):


1. elimination of all conditional compilation, and macros. All that code should 
be encapsulated and banished to Port or Target.


2. encapsulation of all memory management. For example, StringExp's instance of 
string data is allocated and free'd all over the place. I've made some progress 
in encapsulating it. Getting it properly encapsulated means we can do Small 
String Optimization in it, which should get us a nice boost. SSO for all these 
sorts of structures needs to be done.


3. retrofit in const as much as possible, and later try to use pure.

4. get rid of all global state variables, except for configuration stuff set by 
command line switches


5. convert back end to D.

6. use nested functions to improve encapsulation.

7. remove C++ artifacts, like the fake delegates, and replace them with real 
delegates


8. replace symbol tables and custom hash code with builtin hashes, and fix the 
builtin hashes if they aren't as fast


9. change to "full lazy" semantic analysis of imports, i.e. only parse them far 
enough to build the symbol table. Do semantic analysis of the symbols only on 
demand. I did this for enums a while back, and the results have been very pleasing.


10. use rc memory for CTFE, or even stack memory. this is already done to a 
small extent, but should go much further


11. encapsulate, encapsulate, encapsulate

12. start retrofitting with phobos algorithms

13. use ranges


One benefit of all this is we could start using multicores to compile!

This will all take years, but we've already made good progress such as the 
conversion of the source code to D.

Re: [WIP] Native SQLite Database reader (works at CTFE)

[Laeeth Isharc via Digitalmars-d]

On Sunday, 28 February 2016 at 01:55:50 UTC, Stefan Koch wrote:
On Sunday, 28 February 2016 at 01:45:48 UTC, Laeeth Isharc 
wrote:
Great project, Stefan.  Any idea what kind of maximum database 
size will be feasible ?  I realise it is early days so far and 
not your main focus.


Laeeth


The limits will be almost the same as in sqlite.
So a few 100TB


nice.  and thanks.  Laeeth.

Re: Hotfix release vibe.d 0.7.28

[sigod via Digitalmars-d-announce]

On Saturday, 27 February 2016 at 16:21:05 UTC, Sönke Ludwig wrote:
This is a small bugfix release that mainly fixes two critical 
regressions:


 - FreeListRef!T, which is used heavily in the HTTP server 
code, stored
   its reference count in an unallocated memory region, leading 
to

   possible memory leaks or memory corruption

 - A TCP connection with a non-empty write buffer that got 
closed by
   the remote peer and locally at the same time could result in 
the
   calling task to starve (i.e. it got never resumed after 
yielding
   execution). In particular, this could happen when accessing 
HTTPS
   servers with the HTTP client in conjunction with 
"Connection: close".


http://vibed.org/blog/posts/vibe-release-0.7.28


You forgot to update site header.

Is there any plans on when big split will happen?

Re: Cannot link using DMD nightly

[Matt Elkins via Digitalmars-d-learn]

On Sunday, 28 February 2016 at 22:16:39 UTC, Rene Zwanenburg 
wrote:

On Sunday, 28 February 2016 at 19:02:21 UTC, Matt Elkins wrote:

Any suggestions?


I don't know how to fix that error, but 2.070.1 has been 
released and contains a fix for your issue:


http://dlang.org/changelog/2.070.1.html


...I don't know how I missed this. Thanks! It works like a champ, 
including the fix!

Re: Official compiler

[Walter Bright via Digitalmars-d]

On 2/28/2016 1:35 AM, Iain Buclaw via Digitalmars-d wrote:

Surely with Fibers everything would be deterministic though?


I don't see the point of fibers if:

1. they are running on the same core
2. none of them do any waiting, such as waiting on I/O requests

The only I/O a compiler does is reading the source files and writing the object 
file. At one time, dmd did have an async thread to read the source files, but 
that was removed as discussed in this thread.


To speed up dmd, using multicores is necessary, and that requires 
synchronization.

[Issue 15735] New: std.algorithm.iteration.splitter returns empty range

[via Digitalmars-d-bugs]

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

  Issue ID: 15735
   Summary: std.algorithm.iteration.splitter returns empty range
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: dragosc...@gmail.com

The docs say "If the empty range is given, the result is a range with one empty
element."

---
unittest
{
import std.algorithm : equal, splitter;

assert("".splitter('_').equal([""])); // asserts: returned range is empty
}

--

Re: Installing DUB on OSX

[Joel via Digitalmars-d-learn]

On Sunday, 28 February 2016 at 11:06:26 UTC, Jacob Carlborg wrote:

On 2016-02-28 04:33, Joel wrote:


Things just silently not work.

Joels-MacBook-Pro:packages joelcnz$ ls -l -a ~/ | grep dub
drwxr-xr-x4 joelcnz  staff 136 26 Sep 12:47 .dub
Joels-MacBook-Pro:packages joelcnz$


That looks correct. If you don't get any error message it's 
very hard to help.


Yes, it does look better. Thanks Jacob.

Re: VisualD/cv2pdb doesn't display AA's properly in the watch window.

[Lewis via Digitalmars-d-debugger]

On Thursday, 18 February 2016 at 23:01:24 UTC, Rainer Schuetze 
wrote:



On 18.02.2016 01:36, Lewis wrote:

Test code (in a newly created project):


import std.stdio;

int main(string[] argv)
{
 writeln("Hello Blah!");

 string[string] testAA = null;
 testAA["test1"] = "Hello";
 testAA["test2"] = "Goodbye";
 testAA["blah"] = "string";
 testAA["bloop"] = "another string";
 testAA["words"] = "test string";

 int[] testArray = null;
 testArray ~= 3;
 testArray ~= 10;
 testArray ~= 11;
 testArray ~= -2;
 testArray ~= 14;

 readln();  // Breakpoint on this line
 return 0;
}


When I check the watch window, I see the following:
http://imgur.com/mxOxitP

I'm using DMD 2.069.0. The project is set to use the VS 
debugger and
cv2pdb. I'm using VS2015, with native compatibility and edit 
and

continue enabled: http://imgur.com/6mBDtN4

The debugger displays the dynamic array just fine. It correctly
identifies the AA as an aa2, complete with types, and knows 
its size. It
just doesn't display its contents correctly. I've tried 
reinstalling
VisualD with no luck. I've checked the autoexp.dat and the 
VisualD
entries are there as expected. I tried mucking with 
autoexp.dat a bit to
see if I could make it work myself, but to no avail, although 
that tells

me VS is indeed using autoexp.dat as I'd expect.

Any ideas what's going on? My suspicion is that something in 
D's
representation of AAs changes slightly, and now the 
autoexp.dat just
needs a tweak, but I don't know nearly enough to know what to 
fix myself.


Thanks in advance!


cv2pdb has not been updated to the new AA implementation in dmd 
2.068 
(http://dlang.org/changelog/2.068.0.html#aa-open-addressing) 
yet. That's why the type information generated by cv2pdb does 
not fit and autoexp.dat cannot extract the info.


IIRC mago has been updated, so you might want to use this 
debugger engine instead.


Gotcha, thanks for the reply! Just tested with Mago, and it 
indeed shows AAs as expected.


As an aside, I noticed a quirk when viewing AAs with Mago in VS. 
If I have an AA of strings to structs, I can see all the keys and 
struct addresses no problem. However, I can't drill down further 
and inspect the contents of an individual struct. That being 
said, I can create a second watch of the form 'testAA["key"]', 
and now I can see the contents of that struct.


Just curious if there is a technical or design limitation 
preventing this, or if it just never got implemented. If it's the 
latter, may I humbly add this as a feature request for whenever 
yourself or another developer who knows Mago has time? I'm 
guessing I'd just add an issue on the github page?


Thanks!

Lewis

Re: Terminix 0.51.0 Released

[Mike Wey via Digitalmars-d-announce]

On 02/28/2016 12:13 AM, Gerald wrote:

Terminix is a tiling Linux terminal emulator I've been working on
designed for the Gnome 3 environment and using GtkD. This newest release
fixes a number of bugs and adds some new features. I'm announcing it
here primarily for D programmers interested in development using GtkD
since this might be useful as a real world GtkD program that exercises a
significant percentage of the GTK API. Also, if anyone wants to
contribute to the effort I'm always looking for help.

Terminix can be found here: https://github.com/gnunn1/terminix


Great work.

--
Mike Wey

Re: Official compiler

[Andrei Alexandrescu via Digitalmars-d]

On 02/28/2016 11:15 AM, Márcio Martins wrote:

There is no reason why it should be limited to these forums, is there?
Such a survey should be fairly more "realistic" and "representative"
than feelings, emotions and anecdotal evidence.

I think it would be interesting and useful to know what is important for:
-users just starting to use D
-users already heavily invested in the language
-users in each distinct usage (gamedev, web, scripts, real-time, ...)
-users proficient in alternative languages
-companies of different sizes
-size of D codebase


Putting the horses on the proper end of the cart is to first make sure 
we make it easy to align the three compiler versions together. Only 
then, choosing which compiler is more promoted, default etc. becomes a 
simple matter of branding.


Márcio, we are a small enough community that we can't enact things by 
fiat. We've tried before, invariably with bad results. Of course you are 
free to speculate that this time may be different, but it's just that - 
speculation.



Andrei

Re: Cannot link using DMD nightly

[Rene Zwanenburg via Digitalmars-d-learn]

On Sunday, 28 February 2016 at 19:02:21 UTC, Matt Elkins wrote:

Any suggestions?


I don't know how to fix that error, but 2.070.1 has been released 
and contains a fix for your issue:


http://dlang.org/changelog/2.070.1.html

Re: scone 0.1.0 super-alpha

[Vladimirs Nordholm via Digitalmars-d-announce]

On Sunday, 28 February 2016 at 20:49:19 UTC, asdf wrote:

[...]
The 7-Day Roguelike Challenge is coming up. 
http://7drl.org/2016/01/13/7drl-2016-announced-for-5-13-march/ 
Maybe someone could use this.


As of now it would only work for Windows. However, thanks for 
notifying me!

[Issue 15734] New: Need this for map

[via Digitalmars-d-bugs]

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

  Issue ID: 15734
   Summary: Need this for map
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: temta...@gmail.com

import std.algorithm;

class S {
int foo(int a) { return a; }

void test() {
[ 1, 2, 3 ].map!foo;
}
}

Error: this for foo needs to be type S not type MapResult!(foo, int[])

changing foo to (a => foo(a))
makes it compileable

--

Re: Why is mangling different for separate compilation?

[Chris Wright via Digitalmars-d]

On Sun, 28 Feb 2016 20:23:59 +0100, Jacob Carlborg wrote:

> On 2016-02-27 04:51, Walter Bright wrote:
> 
>> It uses a sequence number to generate different ids for the unit tests.
>> In the former, it's the 531st unit test, the latter, the first.
> 
> It sounds like the compiler is seeing different unit tests during the
> different compilation. But why is that the case.

Or like there's a global counter that is incremented for each unittest. A 
different order of traversal of unittests would result in a different 
mangled name for the same unittest in different runs.

Re: scone 0.1.0 super-alpha

[asdf via Digitalmars-d-announce]

On Sunday, 28 February 2016 at 17:50:38 UTC, Vladimirs Nordholm 
wrote:


Scone (Simple CONsole Engine) is a small library to make it 
easier for developers to make CLI applications efficiently 
(intentionally/originally for console games), cross-platform. 
(Please note that it is not fully cross-platform yet, currently 
only working properly on Windows).


Features:
* Efficient writing to the console/terminal
* Keyboard input (currently only Windows)


Yoyo,
vladde


The 7-Day Roguelike Challenge is coming up. 
http://7drl.org/2016/01/13/7drl-2016-announced-for-5-13-march/ 
Maybe someone could use this.

Re: nanomsg for Deimos collection

[Laeeth Isharc via Digitalmars-d-announce]

On Saturday, 27 February 2016 at 15:48:53 UTC, Ilya Yaroshenko 
wrote:

Hi all,

D interface to nanomsg library http://nanomsg.org/ was 
released. This bindings follows Deimos style. 90% of tests was 
ported to D.


github: https://github.com/9il/nanomsg
dub: http://code.dlang.org/packages/nanomsg

BTW, what should I do to include it to Deimos collection?
https://github.com/D-Programming-Deimos

See also https://github.com/Laeeth/d-nanomsg

Best regards,
Ilya


Nice work, Ilya.

I mentioned on the nanomsg gitter channel, but you might want to 
mention on the mailing list too (nanomsg.org then community), so 
it gets added to the list of bindings on the main page.

Re: Why is mangling different for separate compilation?

[Jacob Carlborg via Digitalmars-d]

On 2016-02-27 04:51, Walter Bright wrote:


It uses a sequence number to generate different ids for the unit tests.
In the former, it's the 531st unit test, the latter, the first.


It sounds like the compiler is seeing different unit tests during the 
different compilation. But why is that the case.


--
/Jacob Carlborg

Re: nanomsg for Deimos collection

[Ilya Yaroshenko via Digitalmars-d-announce]

On Sunday, 28 February 2016 at 19:21:04 UTC, Jacob Carlborg wrote:

On 2016-02-27 16:48, Ilya Yaroshenko wrote:


BTW, what should I do to include it to Deimos collection?
https://github.com/D-Programming-Deimos


I don't see a point in doing that. Just make sure it's put in 
the correct category at code.dlang.org.


0mq already in Deimos collection --Ilya

Re: nanomsg for Deimos collection

[Jacob Carlborg via Digitalmars-d-announce]

On 2016-02-27 16:48, Ilya Yaroshenko wrote:


BTW, what should I do to include it to Deimos collection?
https://github.com/D-Programming-Deimos


I don't see a point in doing that. Just make sure it's put in the 
correct category at code.dlang.org.


--
/Jacob Carlborg

[Issue 14327] Unhandled exception from writeln() in C++/D application

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/druntime/commit/de2788d911129545531e0e42d1c8630b3f406e7c
Merge pull request #1412 from rainers/issue_14327

https://github.com/D-Programming-Language/druntime/commit/82715d0589d815a77c7139a59193899866a35f02
fixed Issue 14327 - Unhandled exception from writeln()

--

[Issue 15430] [REG2.069] amdMmx hangs up

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/druntime/commit/97d3999a4f3ab3c8409060bc6bb381fcc2a43c54
fix Issue 15430 - amdMmx hangs up

https://github.com/D-Programming-Language/druntime/commit/d0e4dc96a265ae562e98ad81d0a7d56b752b48ef
Merge pull request #1463 from MartinNowak/fix15430

--

[Issue 15334] [REG 2.069] OS X core.time ticksPerSecond calculation is incorrect

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/druntime/commit/fdad9f502dc3a5cac0bac0cfa7d55fc4b7c273b5
Merge pull request #1432 from smolt/ticksPerSecOSXFixStable

--

Cannot link using DMD nightly

[Matt Elkins via Digitalmars-d-learn]

I'm attempting to use the DMD nightly build (because this fix 
matters a lot to my project: 
https://issues.dlang.org/show_bug.cgi?id=15661), but the build 
fails at the link step. Here is my full output:


[output]
"C:\Program Files (x86)\dub\dub.exe" run --force --build debug 
--build-mode separate

Performing "debug" build using dmd for x86.
cake ~master: building configuration "library"...
derelict-util 2.0.4: building configuration "library"...
derelict-ft 1.0.2: building configuration "library"...
derelict-gl3 1.0.18: building configuration "library"...
derelict-glfw3 1.1.1: building configuration "library"...
gl3n 1.3.1: building configuration "library"...
cakegl ~master: building configuration "library"...
common ~master: building configuration "library"...
client ~master: building configuration "application"...
Linking...
OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
..\cakegl\out\cakegl.lib(utf)
 Error 163: Cannot CVPACK Type 0002
--- errorlevel 1
dmd failed with exit code 1.
[/output]

"cakegl" is one of my libraries used by the application.

I have manually removed every trace of any object file or library 
I could find which was compiled with my previous install of DMD 
(including the third-party ones pulled by dub, such as derelict), 
and am also building with the --force flag; I should note that I 
am using dub for my builds rather than dmd directly.


If I swap back in the released version of DMD it all builds fine. 
This is on 64-bit Windows 7, using the 32-bit DMD nightly build 
downloaded today, Feb 28th.


Any suggestions?

Re: Clojure vs. D in creating immutable lists that are almost the same.

[QAston via Digitalmars-d]

On Saturday, 27 February 2016 at 22:31:28 UTC, Brother Bill wrote:
Clojure supports immutable lists that allow adding and removing 
elements, and yet still have excellent performance.


For D language, what are the recommended techniques to use 
functional programming, without massive copying of data and 
garbage collection, so that it remains immutable.


That is, how to create one-off changes to an immutable data 
structure, while keeping the original immutable, as well as the 
one-off change, and maintain good performance.


Thank you


As a user of Clojure i can tell that "excellent" is an 
overstatement. Still persistent data structures are much better 
than naive copy (unless you really, REALLY need all data in 
cache) and copy on write (unless you only very rarely modify an 
object).


That said, I've seen nobody programming with all-immutable 
objects in D. People mostly use immutable objects only for 
objects never modified, and use const as an immutable view of a 
modifiable object. No clojure-style applying method calls with 
reduce.


With some metaprogramming you could probably write update-in 
function which would work with nested class objects. With that 
and having your classes return new object instead of modifying 
existing one you could have a somewhat clojurish experience.


For cool stuff like records clojure uses persistent maps, which 
would be much less convenient to use because of static typing.


I know no implementation of persistent data structures (hell, 
phobos lacks even some regular data structures). I'm implementing 
transducers for D though, which could be useful if someone 
implemented the datastructures.

scone 0.1.0 super-alpha

[Vladimirs Nordholm via Digitalmars-d-announce]

Once upon a time, in a repository long deleted, there was a 
project called "clayers" which was a programmers summer project, 
in which to create an easy way to make games that relied on the 
console. The repo start of nicely, but after more and more 
developing the project started to get messier and messier, while 
still being unfinished and containing many bugs. The author (me) 
decided that he would start a new project, which he named "scone" 
https://github.com/vladdeSV/scone


---

Scone (Simple CONsole Engine) is a small library to make it 
easier for developers to make CLI applications efficiently 
(intentionally/originally for console games), cross-platform. 
(Please note that it is not fully cross-platform yet, currently 
only working properly on Windows).


Features:
* Efficient writing to the console/terminal
* Keyboard input (currently only Windows)

For anyone on a Windows machine, you can test a few examples that 
gives the basic idea of what scone can do here: 
https://github.com/vladdeSV/scone/tree/master/examples


However, I have one big problem which I cannot overcome, namely 
keyboard input on POSIX. I would very much ask for help in this 
area. Judging from Adam's terminal.d, input on POSIX seems to be 
this huge beast which I cannot slay myself. Feedback and/or help 
very much appreciated!


Yoyo,
vladde

Re: Clojure vs. D in creating immutable lists that are almost the same.

[Chris Wright via Digitalmars-d]

On Sat, 27 Feb 2016 22:31:28 +, Brother Bill wrote:

> Clojure supports immutable lists that allow adding and removing
> elements, and yet still have excellent performance.
> 
> For D language, what are the recommended techniques to use functional
> programming, without massive copying of data and garbage collection, so
> that it remains immutable.
> 
> That is, how to create one-off changes to an immutable data structure,
> while keeping the original immutable, as well as the one-off change, and
> maintain good performance.
> 
> Thank you

It's pretty straightforward for arrays:

  immutable(T[]) array = ...;
  auto inserted = chain(array[0..5], [new T], array[5..$]);
  auto dropped = chain(array[0..5], array[6..$]);
  auto appended = chain(array, [new T, new T]);

After K mutations, you have a tree of chain!(...).Result structs; this 
tree is of height K and contains O(2**K) Result structs (if you're 
removing or inserting items in the middle of the array).

That's not too bad if you're rarely mutating the array. Maybe choose a 
period; after that many mutations, you copy the data into a new 
collection.

But there's a bigger problem. In the above example, there are four 
variables, and each has a different type. That's fine if you're declaring 
new variables. If you are dealing with aggregate fields, it's trouble.

Re: Official compiler

[Márcio Martins via Digitalmars-d]

On Sunday, 28 February 2016 at 15:02:24 UTC, Mike Parker wrote:
On Sunday, 28 February 2016 at 13:31:17 UTC, Márcio Martins 
wrote:


Could we maybe create a quick informative survey, 
(surveymonkey?), so we can get a glimpse of why people like D 
and what they believe would improve their experience with the 
language? Perhaps also why they have chosen to or not to adopt 
D more seriously or professionally?


Given that there is such a wide diversity of people currently 
using it, I think it would be nice for the project leadership 
and all of us in the community to get a more realistic view on 
this matter, to better understand what's important, chose the 
future direction and what are the real selling points. Right 
now it seems like there are a lot of mixed signals even among 
long-time users and contributors.


Such a survey wouldn't be anywhere near "realistic." The number 
and types of users who regularly keep up with the forums are 
highly unlikely to be a representative sample of D users.


There is no reason why it should be limited to these forums, is 
there?
Such a survey should be fairly more "realistic" and 
"representative" than feelings, emotions and anecdotal evidence.


I think it would be interesting and useful to know what is 
important for:

-users just starting to use D
-users already heavily invested in the language
-users in each distinct usage (gamedev, web, scripts, real-time, 
...)

-users proficient in alternative languages
-companies of different sizes
-size of D codebase

Re: Official compiler

[asdf via Digitalmars-d]

On Sunday, 28 February 2016 at 12:59:01 UTC, Dibyendu Majumdar 
wrote:
Should LLVM move to an Apache License would that help in 
migrating to an LLVM backend as the standard backend?


Regards
Dibyendu


LLVM is great but you wouldn't want to be locked down to only one 
backend, probably. LLVM does have good support for a variety of 
architectures though... A bytecode code generator might be good 
for bootstrapping (after the nuclear apocalypse) but everyone 
just cross-compiles.

Re: Normal distribution

[asdf via Digitalmars-d]

On Saturday, 20 February 2016 at 14:01:22 UTC, Andrei 
Alexandrescu wrote:
Do we have a good quality converter of uniform numbers to 
Gaussian-distributed numbers around? -- Andrei


Forth Engineering Practice™ is to add a few uniform distributions 
together... http://www.colorforth.com/e-x2.htm Accurate to 2 
decimal places!

Re: Terminix 0.51.0 Released

[karabuta via Digitalmars-d-announce]

On Saturday, 27 February 2016 at 23:13:47 UTC, Gerald wrote:
Terminix is a tiling Linux terminal emulator I've been working 
on designed for the Gnome 3 environment and using GtkD. This 
newest release fixes a number of bugs and adds some new 
features. I'm announcing it here primarily for D programmers 
interested in development using GtkD since this might be useful 
as a real world GtkD program that exercises a significant 
percentage of the GTK API. Also, if anyone wants to contribute 
to the effort I'm always looking for help.


Terminix can be found here: https://github.com/gnunn1/terminix


Sweet! Hope you will announce it in the elementary, Ubuntu and 
Linux G+ community, right?

Re: Release D 2.070.1

[Ilya Yaroshenko via Digitalmars-d-announce]

On Saturday, 27 February 2016 at 20:07:04 UTC, Martin Nowak wrote:

Glad to announce D 2.070.1.

http://dlang.org/download.html

This point release fixes a few issues over 2.070.1, see the 
changelog for more details.


http://dlang.org/changelog/2.070.1.html

-Martin


Thanks!

Re: nanomsg for Deimos collection

[Martin Nowak via Digitalmars-d-announce]

On 02/27/2016 04:48 PM, Ilya Yaroshenko wrote:
> Hi all,
> 
> D interface to nanomsg library http://nanomsg.org/ was released. This
> bindings follows Deimos style. 90% of tests was ported to D.
> 
> github: https://github.com/9il/nanomsg
> dub: http://code.dlang.org/packages/nanomsg
> 
> BTW, what should I do to include it to Deimos collection?
> https://github.com/D-Programming-Deimos

Send a mail to Walter and ask him to create a repo.
You could also transfer your existing repo. This would leave you w/ full
commit access, reducing friction when fixing sth. or tagging a new release.

Re: Official compiler

[Mike Parker via Digitalmars-d]

On Sunday, 28 February 2016 at 15:02:24 UTC, Mike Parker wrote:



Such a survey wouldn't be anywhere near "realistic." The number 
and types of users who regularly keep up with the forums are 
highly unlikely to be a representative sample of D users.


Not to mention that only a fraction of people who view the forums 
would actually take the survey.

Re: Official compiler

[Mike Parker via Digitalmars-d]

On Sunday, 28 February 2016 at 13:31:17 UTC, Márcio Martins wrote:

Could we maybe create a quick informative survey, 
(surveymonkey?), so we can get a glimpse of why people like D 
and what they believe would improve their experience with the 
language? Perhaps also why they have chosen to or not to adopt 
D more seriously or professionally?


Given that there is such a wide diversity of people currently 
using it, I think it would be nice for the project leadership 
and all of us in the community to get a more realistic view on 
this matter, to better understand what's important, chose the 
future direction and what are the real selling points. Right 
now it seems like there are a lot of mixed signals even among 
long-time users and contributors.


Such a survey wouldn't be anywhere near "realistic." The number 
and types of users who regularly keep up with the forums are 
highly unlikely to be a representative sample of D users.

Re: ErrnoException

[Mike Parker via Digitalmars-d-learn]

On Sunday, 28 February 2016 at 13:10:20 UTC, Jirka wrote:
I have a question about ErrnoException. When I throw it (throw 
new ErrnoException()), won't it overwrite the errno value 
before it can capture it?


Its constructor [1] simply fetches the current errno and gets an 
error message from it.


[1] 
https://github.com/D-Programming-Language/phobos/blob/master/std/exception.d#L1491

Re: Normal distribution

[Márcio Martins via Digitalmars-d]

On Friday, 26 February 2016 at 20:15:10 UTC, Andrei Alexandrescu 
wrote:

On 2/26/16 2:32 PM, Joseph Rushton Wakeling wrote:
Yup.  The basic problem of getting this stuff into phobos are 
the

architectural problems discussed in that talk.  Unlike uniform
distribution (which is straightforward to implement as a 
function, no
questions asked), the normal distribution is best implemented 
as a range
which keeps some state.  So the 
reference-type/non-reference-type issues

start becoming a factor.


Would it work to define Gaussian generators as regular 
generators (same as the existing ones), which keep the uniform 
engine as a member? -- Andrei


This C implementation of the Marsaglia/Tsang Ziggurat method 
keeps no state except for that of the uniform rng and 3 small 
static lookup tables that can be initialized in the module's 
shared constructor:

http://people.sc.fsu.edu/~jburkardt/cpp_src/ziggurat_inline/ziggurat_inline.cpp

I wrote a D implementation of that with the uniform rngs factored 
out, leaving it at ~50 loc - not up to Phobos' standards for sure 
- but I suppose but it could be a starting point. If someone is 
interested in that let me know.

Re: Official compiler

[Márcio Martins via Digitalmars-d]

On Thursday, 25 February 2016 at 01:53:51 UTC, Walter Bright 
wrote:

On 2/17/2016 4:35 PM, Chris Wright wrote:

And since DMD is
something like twice as fast as LDC, there's at least some 
argument in

favor of keeping it around.


When I meet someone new who says they settled on D in their 
company for development, I casually ask why they selected D?


  "Because it compiles so fast."

It's not a minor issue.


Could we maybe create a quick informative survey, 
(surveymonkey?), so we can get a glimpse of why people like D and 
what they believe would improve their experience with the 
language? Perhaps also why they have chosen to or not to adopt D 
more seriously or professionally?


Given that there is such a wide diversity of people currently 
using it, I think it would be nice for the project leadership and 
all of us in the community to get a more realistic view on this 
matter, to better understand what's important, chose the future 
direction and what are the real selling points. Right now it 
seems like there are a lot of mixed signals even among long-time 
users and contributors.

ErrnoException

[Jirka via Digitalmars-d-learn]

I have a question about ErrnoException. When I throw it (throw 
new ErrnoException()), won't it overwrite the errno value before 
it can capture it?

Re: Why is mangling different for separate compilation?

[John Colvin via Digitalmars-d]

On Sunday, 28 February 2016 at 12:59:53 UTC, Atila Neves wrote:

On Saturday, 27 February 2016 at 11:31:53 UTC, Joakim wrote:
On Saturday, 27 February 2016 at 11:27:39 UTC, Walter Bright 
wrote:

On 2/27/2016 1:12 AM, Atila Neves wrote:
I've had similar problems in the past with template mixins. 
It seems D's
compile-time features don't mix with any kind of separate 
compilation, which is

a shame.


Any ideas on how unit tests should be named?


Why has the additional count been added?  You're already using 
the line number to differentiate unit test blocks.  For unit 
test blocks that are all on one line? ;)


I guess that makes sense. And it'd link!

Atila


You could always add an additional number to uniquely identify 
them if there are multiple unittests on one line. It would seem 
weird to have a special case in the grammar for unittests.

Re: Why is mangling different for separate compilation?

[Atila Neves via Digitalmars-d]

On Saturday, 27 February 2016 at 11:31:53 UTC, Joakim wrote:
On Saturday, 27 February 2016 at 11:27:39 UTC, Walter Bright 
wrote:

On 2/27/2016 1:12 AM, Atila Neves wrote:
I've had similar problems in the past with template mixins. 
It seems D's
compile-time features don't mix with any kind of separate 
compilation, which is

a shame.


Any ideas on how unit tests should be named?


Why has the additional count been added?  You're already using 
the line number to differentiate unit test blocks.  For unit 
test blocks that are all on one line? ;)


I guess that makes sense. And it'd link!

Atila

Re: Official compiler

[Dibyendu Majumdar via Digitalmars-d]

On Friday, 26 February 2016 at 22:20:09 UTC, Walter Bright wrote:

I am referring to this thread:

http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html


Thanks for the pointer. If anyone wants to chip in on that 
thread, feel free!


Hi Walter,

Should LLVM move to an Apache License would that help in 
migrating to an LLVM backend as the standard backend?


Regards
Dibyendu

[Issue 15590] 0 coverage should be ignored in __ctfe branches

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--

[Issue 15590] 0 coverage should be ignored in __ctfe branches

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID
Summary|the coverage fails in   |0 coverage should be
   |__ctfe branches |ignored in __ctfe branches

--- Comment #1 from b2.t...@gmx.com ---
Since coverage is generated by the target application, it cannot know if the
compiler has run it.

--

Re: SQLite-D alpha is here

[Stefan Koch via Digitalmars-d-announce]

On Saturday, 27 February 2016 at 16:08:21 UTC, Stefan Koch wrote:

Hello,

I am happy to announce the official alpha version of sqlite-d!

sqlite-d is a reader for the SQLite File Format 3.

In the future I will implement a SQL-like API on top of it.

Top-notch performance is one of the explicit goals of this 
project!


please note that currently only the ctfe branch is populated.

I welcome contributions!

Repo-URL : https://github.com/UplinkCoder/sqlite-d


Update I just found another case that cannot be handled properly. 
It just happens with insanely huge databases.


Also I commited my test-data now... I wonder why nobody said 
anything about the app failing on startup ...

Re: Is DUB the best place to get examples of "Best of" D code?

[Edwin van Leeuwen via Digitalmars-d-learn]

On Sunday, 28 February 2016 at 05:59:39 UTC, WhatMeWorry wrote:


If so, is there a way to do a global search of all projects in 
DUB?


If you just want to search through package names and descriptions 
you can use the search box at the top right of code.dlang.org.


If you want to search through code. Most packages are on github, 
so you could search there (limit by D projects).

Re: Installing DUB on OSX

[Jacob Carlborg via Digitalmars-d-learn]

On 2016-02-28 04:33, Joel wrote:


Things just silently not work.

Joels-MacBook-Pro:packages joelcnz$ ls -l -a ~/ | grep dub
drwxr-xr-x4 joelcnz  staff 136 26 Sep 12:47 .dub
Joels-MacBook-Pro:packages joelcnz$


That looks correct. If you don't get any error message it's very hard to 
help.


--
/Jacob Carlborg

[Issue 15730] invalid template merging in tuple foreach

[via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

Re: Clojure vs. D in creating immutable lists that are almost the same.

[Abdulhaq via Digitalmars-d]

On Saturday, 27 February 2016 at 22:31:28 UTC, Brother Bill wrote:

That is, how to create one-off changes to an immutable data 
structure, while keeping the original immutable, as well as the 
one-off change, and maintain good performance.




Clojure uses bit-partitioned hash tries.

I recommend this video (Clojure Concurrency)
https://www.youtube.com/watch?v=dGVqrGmwOAw

slides here:
https://github.com/dimhold/clojure-concurrency-rich-hickey/blob/master/ClojureConcurrencyTalk.pdf?raw=true
 (slide 21 about bit-partitioned hash tries)

Re: Hotfix release vibe.d 0.7.28

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

Am 28.02.2016 um 02:51 schrieb Sebastiaan Koppe:

On Saturday, 27 February 2016 at 16:21:05 UTC, Sönke Ludwig wrote:

This is a small bugfix release that mainly fixes two critical regessions


Great. Thanks for the quick release!


Thanks for taking the time to do an in-depth analysis!

[Issue 15596] strip with delimiter?

[via Digitalmars-d-bugs]

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

--- Comment #6 from ag0ae...@gmail.com ---
(In reply to ag0aep6g from comment #5)
> (In reply to b2.temp from comment #4)
> > Maybe a note in the std.string doc: "see also: for more generic strip
> > funcyion..."
> 
> Already there: "There is a rich set of functions for string handling defined
> in other modules. Functions related to Unicode and ASCII are found in
> std.uni and std.ascii, respectively. Other functions that have a wider
> generality than just strings can be found in std.algorithm and std.range."

Whoops, you were talking about strip's docs specifically. Sorry for the noise.

--

[Issue 15596] strip with delimiter?

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #5 from ag0ae...@gmail.com ---
(In reply to b2.temp from comment #4)
> Maybe a note in the std.string doc: "see also: for more generic strip
> funcyion..."

Already there: "There is a rich set of functions for string handling defined in
other modules. Functions related to Unicode and ASCII are found in std.uni and
std.ascii, respectively. Other functions that have a wider generality than just
strings can be found in std.algorithm and std.range."

--

Re: Clojure vs. D in creating immutable lists that are almost the same.

[John Colvin via Digitalmars-d]

On Saturday, 27 February 2016 at 23:19:51 UTC, w0rp wrote:
On Saturday, 27 February 2016 at 22:31:28 UTC, Brother Bill 
wrote:
Clojure supports immutable lists that allow adding and 
removing elements, and yet still have excellent performance.


For D language, what are the recommended techniques to use 
functional programming, without massive copying of data and 
garbage collection, so that it remains immutable.


That is, how to create one-off changes to an immutable data 
structure, while keeping the original immutable, as well as 
the one-off change, and maintain good performance.


Thank you


I think this is a property of linked lists which could possibly 
be advantageous. However, I would keep in mind that memory 
layout is very important when it comes to execution speed, and 
that slices of memory are unbeatable in that regard. That's 
worth stating first.


I think for linked lists, you can always create a new node 
which points to another node. So you start with element a as 
immutable, then you take a head element b and point to a, so 
you get b : a, then c : b : a, etc. So you can create larger 
and large immutable linked lists because you never actually 
change a list, you just produce a new list with an element 
pointing the head of a previous list.


I'm not sure if Phobos has something suitable for this, but you 
could always implement your own singly linked list in such a 
manner pretty easily. I would be tempted just to use slices 
instead, though. Linked lists are rarely better.


Often people use a lot more advanced structures than linked lists 
for immutable data structures. 
http://www.infoq.com/presentations/Functional-Data-Structures-in-Scala

Re: Official compiler

[Iain Buclaw via Digitalmars-d]

On 27 February 2016 at 23:30, Walter Bright via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

On 2/27/2016 12:05 PM, Timon Gehr wrote:
>
>> On 26.02.2016 23:41, Walter Bright wrote:
>>
>>> On 2/26/2016 1:10 PM, Timon Gehr wrote:
>>>
 Different passes are not really required once semantic analysis becomes
 asynchronous. Just keep track of semantic analysis dependencies, with
 strong and
 weak dependencies and different means to resolve cycles of weak
 dependencies.
 Then write the semantic analysis of each component in a linear fashion
 and pause
 it whenever it depends on information that has not yet been obtained,
 until that
 information is computed.

>>>
>>> I'll put you in charge of debugging that :-)
>>>
>>
>> I am/was (I have not worked on it a lot lately). I haven't found it to be
>> particularly hard to debug.
>>
>
> It'll get 100 times harder if it's a heisenbug due to synchronization
> issues.
>
>
Surely with Fibers everything would be deterministic though?