Re: DlangIDE v0.8.0 released

[puming via Digitalmars-d-announce]

On Tuesday, 26 September 2017 at 15:20:54 UTC, Vadim Lopatin 
wrote:

New DlangIDE version is released.

Prebuilt win32 binaries are available on 
https://github.com/buggins/dlangide/releases


Milestone 0.8 is reached.
List of 56 issues closed in this milestone: 
https://github.com/buggins/dlangide/milestone/2?closed=1


As well, many DlangUI changes were implemented for some of 
DlangIDE features.


Thank you for everyone who reported issues / sent PRs and 
feature requests.


Now I'm considering DlangIDE as mostly usable.


Thanks for the new release!

Just checked the windows version and it works well.

waiting for the vim mode support 
(https://github.com/buggins/dlangide/issues/86)  to switch it as 
my main IDE.

Re: code.dlang.org internal server error

[puming via Digitalmars-d]

On Thursday, 9 February 2017 at 12:19:12 UTC, Daniel Kozák wrote:

V Thu, 9 Feb 2017 11:54:05 +0100
Sönke Ludwig via Digitalmars-d  
napsáno:



[...]


In general issue is not with connectivity to China but with
GFW (https://en.wikipedia.org/wiki/Great_Firewall), So you 
would need
some VPS inside china, unfortunately AFAIK all VPS inside Hong 
Kong are

outside of GFW so it is still posible it would not help.

But in our company we have VPS inside GFW (for our chinese 
customers),

so maybe I could ask if they dont mind to provide it for dub
mirror purpose


Yes, GFW is the main problem. What's more, to setup a HTTP site 
in China, one has to file for permission from the govt.

Re: code.dlang.org internal server error

[puming via Digitalmars-d]

On Thursday, 9 February 2017 at 10:54:05 UTC, Sönke Ludwig wrote:

Am 09.02.2017 um 03:34 schrieb puming:
On Wednesday, 8 February 2017 at 14:11:48 UTC, Sönke Ludwig 
wrote:

[...]


I have a VPS slot in Hong Kong for personal use, with 1GB 
memory, 30GB

disk and 300GB monthly bandwidth. Is that OK for a mirror site?


That should work! Considering that connectivity from my VPS to 
China generally appears to be sub optimal, that would be good 
to have as an alternative anyway.


We just need to implement a mirror mode, where user and package 
management is disabled and updates are pulled from 
code.dlang.org instead of from github directly.


When you get mirror mode working, please make an anouncement so 
that I can contact you about setting up the mirror. I can afford 
to increase VPS capacity to 2GB Mem/60GB disc or something 
similar if neccessary.

Re: code.dlang.org internal server error

[puming via Digitalmars-d]

On Wednesday, 8 February 2017 at 14:11:48 UTC, Sönke Ludwig wrote:

Am 08.02.2017 um 14:29 schrieb singingbush:

[...]


Yes, we need to prioritize this somehow. Having a fallback 
mirror, coupled with dependency upgrade checks that run 
asynchronously would get rid of these issues. It would be great 
if somebody could find the time to tackle one or the other. I 
personally have an very limited time budget for open source at 
the moment and I need to focus that on vibe.d for a bit.


BTW, the server is running again (it ran out of disk space 
again and I need to configure a proactive alert for that).


I have a VPS slot in Hong Kong for personal use, with 1GB memory, 
30GB disk and 300GB monthly bandwidth. Is that OK for a mirror 
site?

Re: Internal error on Wiki page

[Puming via Digitalmars-d]

On Wednesday, 8 February 2017 at 02:19:23 UTC, Ali Çehreli wrote:

On 02/06/2017 06:43 PM, Luís Marques wrote:
This page 
 shows

an error instead of displaying the Wiki content:

[54c97baea4172eeabd69f522] 2017-02-06 13:47:44: Fatal 
exception of type

"Error"




Probably related. Help! :)

code.dlang.org/

500 - Internal Server Error

Internal Server Error

Ali


+1

this is the first time that I realize how important 
code.dlang.org is, I can not do anything now that dub won't 
work

Re: Replace/Rename DWT forum with GUIs forum?

[Puming via Digitalmars-d]

On Thursday, 22 September 2016 at 05:48:42 UTC, Vadim Lopatin 
wrote:

On Sunday, 18 September 2016 at 23:21:26 UTC, Gerald wrote:
I would like to suggest that the existing DWT forum be renamed 
or replaced with a more generic GUIs forum. As far as I can 
tell, the DWT forum doesn't get much traffic these days and I 
don't believe any of the current GUI options for D are 
sufficiently popular to warrant their own specific forum.


While I primarily work with and have an interest in GtkD, I'm 
interested in posts with regards to all of the available GUI 
options (GtkD, DLangUI, etc) for D since I have general 
interest in desktop applications. I think grouping everything 
in one forum, similar to what is done for IDEs and Debuggers, 
would bring together posts and people that share a common 
interest.


+1


+1

Re: New Diet template engine almost complete, ready for comments

[Puming via Digitalmars-d-announce]

On Tuesday, 26 July 2016 at 05:54:39 UTC, Sönke Ludwig wrote:

Am 26.07.2016 um 05:22 schrieb Puming:

[...]


A real runtime solution would require a D runtime interpreter 
or JIT compiler. There would be an alternative solution based 
on compiling each template to a shared library and then 
dynamically recompiling/reloading those as required, but that 
currently doesn't work due to the alias parameter based 
interface of render!(...).


However, what should work well is a combination of 
https://github.com/dlang/dub/pull/446 and 
https://github.com/rejectedsoftware/vibe.d/pull/1385 - I'll 
merge the latter one into vibe.d master today. It will require 
to store session information and similar things in an external 
store, and on Linux the Gold linker should be used for speed, 
but then it should be almost as good as a runtime solution.


Thanks！Shared lib reloading is good. Looking forward to it fully 
working :-)

Re: New Diet template engine almost complete, ready for comments

[Puming via Digitalmars-d-announce]

On Monday, 25 July 2016 at 09:29:38 UTC, Sönke Ludwig wrote:
The Diet template language is aimed at providing a way to 
define procedurally generated HTML/XML pages (or other output 
formats), with minimal visual noise. Syntax and feature set are 
heavily inspired by Jade , but instead 
of JavaScript, all expressions and statements are D statements, 
and everything that can be done at compile-time is done at 
compile-time.


[...]


A feature I want the most for Diet is the ability to parse Diet 
templates at RUNTIME instead of compile time with a switch, 
similar to Regex/CtRegex.


In this way one can do quick turnarounds in dev mode, tweaking 
little corners of the pages, and then when a page is finished, it 
can be switched to compile mode for faster render time.


Do you think this is feasible?

Re: Blocking points for further D adoption

[Puming via Digitalmars-d]

On Friday, 1 July 2016 at 00:08:51 UTC, dalailambda wrote:

On Thursday, 30 June 2016 at 23:48:29 UTC, Mike Parker wrote:
DMD *is* the official compiler. That's what a reference 
compiler is. The other compilers are there for those who want 
them and are developed independently of DMD. It's no different 
from the situation with Java (with the exception that Oracle 
doesn't link to other compilers on their JDK download page). 
No one says you *have* to use LDC or GDC for production, or 
that you can't use DMD. It's just as a recommendation for 
those who care about squeezing out every last drop of 
performance.


Sure, but overwhelmingly the community suggests to use DMD for 
development for fast compilation speeds and then use LDC/GDC 
for production. I'm not saying that the law mandates it but the 
impression I get as a newcommer to the community is that DMD is 
the ugly stepchild that isn't suitable for real world use case.


As an example, look at whenever a benchmark comes up, someone 
will say "have you tried compiling with LDC?". I feel the is 
relevant since, as a systems language, performance should be a 
feature.


It's been suggested that DMD/LDC/GDC could be combined into a 
bundle, say DCC, and when you call


DCC hello.d

it will call dmd hello.d,

and if you call

DCC -fast hello.d

it will call ldc hello.d or gdc hello.d

This will give newcomers a different experience.

Re: Command line utilities for tab-separated value files

[Puming via Digitalmars-d-announce]

On Wednesday, 13 April 2016 at 17:21:58 UTC, Jon D wrote:

On Wednesday, 13 April 2016 at 17:01:33 UTC, Dicebot wrote:

On Wednesday, 13 April 2016 at 16:34:16 UTC, Jon D wrote:

[...]


You don't need to put anything on path to run utils from dub 
packages. `dub run` will take care of setting necessary 
envionment (without messing with the system):


dub fetch package_with_apps
dub run package_with_apps:app1 --flags args


These are command line utilities, along the lines of unix 
'cut', 'grep', etc, intended to be used as part of unix 
pipeline. It'd be less convenient to be invoking them via dub. 
They really should be on the path themselves.


--Jon


if dub supports something like:

```
dub deploy
```

and you can specifiy some dir like '/usr/bin/' in the dub.sdl,

it would be great

Re: Command line utilities for tab-separated value files

[Puming via Digitalmars-d-announce]

On Wednesday, 13 April 2016 at 16:34:16 UTC, Jon D wrote:

Thanks Rory, Puming. I'll look into this and see how best to 
make it fit. I'm realizing also there's one additional 
capability it'd be nice to have in dub for tools like this, 
which in an option to install the executables somewhere that 
can be easily be put on the path. Still, even without this 
there'd be benefit to having them fetched via dub.


--Jon


Well, you can do that:

In the subpackage dub.sdl, add targetPath:



 ```
 name "app1"
 targetType "executable"
 targetPath "../bin/"
 dependency "myapp:common" version="*"
 ```

Re: Command line utilities for tab-separated value files

[Puming via Digitalmars-d-announce]

On Tuesday, 12 April 2016 at 07:17:05 UTC, Jon D wrote:

On Tuesday, 12 April 2016 at 06:22:55 UTC, Puming wrote:

On Tuesday, 12 April 2016 at 00:50:24 UTC, Jon D wrote:

Hi all,

I've open sourced a set of command line utilities for 
manipulating tab-separated value files. They are 
complementary to traditional unix tools like cut, grep, etc. 
They're useful for manipulating large data files. I use them 
when prepping files for R and similar tools. These tools were 
part of my 'explore D' programming exercises.


[...]


Interesting, I have large csv files, and this lib will be 
useful.
Can you put it onto code.dlang.org so that we could use it 
with dub?


I'd certainly like to make it available via dub, but I wasn't 
sure how to set it up. There are two issues. One is that the 
package builds multiple executables, which dub doesn't seem to 
support easily. More problematic is that quite a bit of the 
test suite is run against the executables, which I could 
automate using make, but didn't see how to do it with dub.


If there are suggestions for setting this up in dub that'd be 
great. An example project doing something similar would be 
really helpful.


--Jon


Here is what I know of it, using subPackages:

Say you have a project named myapp, and you need three 
executables, app1, app2, app3, they all depend on a common code 
base, which you name it common.


Using dub, you can have a parent project myapp, that does nothing 
but is a container of the three apps and their common code.


dub.sdl in myapp dir:

```
name "myapp"

dependency ":common" version="*"
subPackage "./common/"

dependency ":app1" version="*"
subPackage "./app1/"

dependency ":app2" version="*"
subPackage "./app2/"

dependency ":app3" version="*"
subPackage "./app3/"
```

the comma in dependency name ":common" is equal to "myapp:common"

now use `dub init common` and the like to create subdirectories.

change dub.sdl in the subdirectory common so that it becomes a 
library type:


```
name "common"

targetType "library"

```

change dub.sdl in myapp* subdirectories to depend on common:

```
name "app1"
targetType "executable"

dependency "myapp:common" version="*"
```

note here you need to add root project name "myapp:common".

Then you should register your whole project into the local dub 
repo, so that subpackages can find its dependencies when building:


in the project root directory:

dub add-local .

Now you can build each executable with:

dub build :app1
dub build :app2
dub build :app3

Unfortunately dub does not build all sub packages at once when 
you dub in the root directory.


But I think there might be a better way to handle multiple 
executables?

Re: Command line utilities for tab-separated value files

[Puming via Digitalmars-d-announce]

On Tuesday, 12 April 2016 at 00:50:24 UTC, Jon D wrote:

Hi all,

I've open sourced a set of command line utilities for 
manipulating tab-separated value files. They are complementary 
to traditional unix tools like cut, grep, etc. They're useful 
for manipulating large data files. I use them when prepping 
files for R and similar tools. These tools were part of my 
'explore D' programming exercises.


[...]


Interesting, I have large csv files, and this lib will be useful.
Can you put it onto code.dlang.org so that we could use it with 
dub?

Re: execute bash?

[Puming via Digitalmars-d-learn]

On Sunday, 10 April 2016 at 10:43:48 UTC, wobbles wrote:



This would be cool. I'll have a think about how to go about it!


Looking forward to your updates! :P

Re: execute bash?

[Puming via Digitalmars-d-learn]

On Sunday, 10 April 2016 at 02:59:41 UTC, Adam D. Ruppe wrote:

On Sunday, 10 April 2016 at 00:47:28 UTC, Puming wrote:
3. when hiting 'vim a.file' on the command, things go messy. 
Have you got these interactive commands work in dexpect?


It is surely capturing exactly what vim sends to a terminal, 
which is primarily a series of control sequences to draw the 
screen, move the cursor, color it, etc.


Yes, I guess if I fully forward every output/input, it'll work.



You might want to watch for those and just forward them 
directly to the user terminal... but this is getting kinda 
wild


Well, I'm not sure whether I can handle the complexity here. I 
don't even quite understand terminal io/sequence characters yet. 
Come back to this later when I get my little repl running.





1. Fully proxy for a bash shell.
2. Result data are separated for each command. So I can easily 
search for hitorical sent commands or results.



What you probably want to do is just send one command at a time 
to the bash process and handle the rest yourself.


Or just forget bash and write your own shell.


An indepedent shell would be GREAT! I hope someday we get a REPL 
in D, and it is also an independent shell, just like FishShell, 
but implemented in D, and scripts are also in D.

Re: execute bash?

[Puming via Digitalmars-d-learn]

On Saturday, 9 April 2016 at 08:56:17 UTC, wobbles wrote:

On Friday, 8 April 2016 at 23:06:06 UTC, Puming wrote:

On Friday, 8 April 2016 at 18:23:32 UTC, wobbles wrote:

On Friday, 8 April 2016 at 16:07:13 UTC, Adam D. Ruppe wrote:

On Friday, 8 April 2016 at 15:20:09 UTC, Puming wrote:
I tried with signal, but didn't catch SIGTTOU, it seems 
that spawnProcess with `bash -i -c` will signal with 
SIGTTIN.


Oh, surely because it wants to be interactive and is thus 
waiting for user input from the terminal..


You might need to rig up a pseudo terminal that the bash can 
talk to. That's getting to be a pain though.


You could run it through dexpect to get the effect of a 
pseudo terminal.


https://github.com/grogancolin/dexpect


Looked in the code, it is exacly what I need! Thanks.

Also it has spawnInPty


Cool. Any questions on using it let me know. I'm all for a bit 
of feedback also!


I tried dexpect, now it works for the bash emulation!

But there are still some issues:

1. Spawn's data is a string, so it stores ALL data, but Expect 
class does not have a clear() method, so the data piles up and 
takes memory.


2. There seems to be a visible lag for each send->read cycle. I 
haven't look in the details to find where, but it feels not as 
smooth as ssh does.


3. when hiting 'vim a.file' on the command, things go messy. Have 
you got these interactive commands work in dexpect?


My wish list for the Expect class ( or design a separate class, 
like BashProxy ):


1. Fully proxy for a bash shell.
2. Result data are separated for each command. So I can easily 
search for hitorical sent commands or results.


But for now it works fine for my needs.
I'll try to improve it when I get major parts of my repl lib done.

Re: execute bash?

[Puming via Digitalmars-d-learn]

On Friday, 8 April 2016 at 16:16:27 UTC, Adam D. Ruppe wrote:

On Friday, 8 April 2016 at 15:31:13 UTC, Puming wrote:

The D version behavior is strange.


Are you still calling bash? Cuz that is going to complicate 
things a lot because bash does its own signal handling too and 
could be intercepting it.


No, this happens in a simple demo program:

import std.stdio;
import std.process;
import core.stdc.signal;
import core.thread;
import std.datetime;


extern(C) void sig_hand(int signal) nothrow @nogc @system {
import core.stdc.stdio: printf;
printf("signal %d catched!\n", signal);
}

void main() {
if (signal(SIGINT, _hand) == SIG_ERR) {
writeln("can't catch SIGINT");
}

string line;
write("> ");
while(1) {
Thread.sleep(1.seconds);
}
}

But after trying again on my machine, it behaved the same as in 
the C code.


Maybe I got the wrong behavior last night due to running it on a 
remote server.




When Using while with readln, after hitting Ctrl-C, the next 
readln will throw exception:


This is normal though. If a signal interrupts a read/write 
call, it returns an error saying it was interrupted so you can 
choose to abort or try again. (this way you can catch ctrl+c to 
cancel input)


Thanks, so I'll just catch it.

Re: execute bash?

[Puming via Digitalmars-d-learn]

On Friday, 8 April 2016 at 18:23:32 UTC, wobbles wrote:

On Friday, 8 April 2016 at 16:07:13 UTC, Adam D. Ruppe wrote:

On Friday, 8 April 2016 at 15:20:09 UTC, Puming wrote:
I tried with signal, but didn't catch SIGTTOU, it seems that 
spawnProcess with `bash -i -c` will signal with SIGTTIN.


Oh, surely because it wants to be interactive and is thus 
waiting for user input from the terminal..


You might need to rig up a pseudo terminal that the bash can 
talk to. That's getting to be a pain though.


You could run it through dexpect to get the effect of a pseudo 
terminal.


https://github.com/grogancolin/dexpect


Looked in the code, it is exacly what I need! Thanks.

Also it has spawnInPty :-)

combined with terminal.d, I think I might get a very handy shell 
now.

Re: execute bash?

[Puming via Digitalmars-d-learn]

On Friday, 8 April 2016 at 16:08:02 UTC, Adam D. Ruppe wrote:

On Friday, 8 April 2016 at 14:09:16 UTC, Puming wrote:

I just found that you have terminal.d in arsd repo, are you
writing a repl with it? I'm hoping I might be able to use it.


I have done it before. terminal.d has a getline function and 
writeln functions you could loop over. Its getline has features 
like tab completion, editing, etc.


wow, that is just what I need. I'll look at it, thanks.

Do you have this pseudo terminal thing in terminal.d?

Re: execute bash?

[Puming via Digitalmars-d-learn]

On Friday, 8 April 2016 at 16:07:13 UTC, Adam D. Ruppe wrote:

On Friday, 8 April 2016 at 15:20:09 UTC, Puming wrote:
I tried with signal, but didn't catch SIGTTOU, it seems that 
spawnProcess with `bash -i -c` will signal with SIGTTIN.


Oh, surely because it wants to be interactive and is thus 
waiting for user input from the terminal..


You might need to rig up a pseudo terminal that the bash can 
talk to. That's getting to be a pain though.


Indeed, this makes sense.

Re: execute bash?

[Puming via Digitalmars-d-learn]

On Friday, 8 April 2016 at 13:25:37 UTC, Adam D. Ruppe wrote:

On Friday, 8 April 2016 at 13:23:10 UTC, Adam D. Ruppe wrote:
Odds are it is that there's terminal output for the background 
process


NOT a character btw, just any output, then the OS puts you on 
hold so it can do its thing.


To catch a signal, it is just like in C 
http://stackoverflow.com/a/35687472/1457000


simplest case:

import core.stdc.signal;
signal(SIGTTOU, SIG_IGN); // ignore the output thing


and see what happens next


Found another problem: I can't even catch SIGINT in a simple 
program:


import std.stdio;
import std.process;
import core.stdc.signal;
import core.thread;
import std.datetime;


extern(C) void sig_hand(int signal) nothrow @nogc @system {
import core.stdc.stdio: printf;
printf("signal %d catched!\n", signal);
}

void main() {
if (signal(SIGINT, _hand) == SIG_ERR) {
writeln("can't catch SIGINT");
}

string line;
write("> ");
while(1) {
Thread.sleep(1.seconds);
}
/*
while ((line = readln()) != null) {
writeln("you said:", line);
write("> ");
}
*/
}

When using while with Thread.sleep, Ctrl+C will show

signal 2 catched!

then the program is gone, but its process is still found with `ps 
-ef`, which I have to kill manually.


In the c version as shown here 
, the loop will go on and you can press multiple Ctrl-C.


The D version behavior is strange.

When Using while with readln, after hitting Ctrl-C, the next 
readln will throw exception:


std.stdio.StdioException@std/stdio.d(3977): Input/output error

??:? void std.stdio.StdioException.opCall() [0x498531]
??:? ulong 
std.stdio.readlnImpl(shared(core.stdc.stdio._IO_FILE)*, ref 
char[], dchar, std.stdio.File.Orientation) [0x498676]
/usr/include/dmd/phobos/std/stdio.d:1565 ulong 
std.stdio.File.readln!(char).readln(ref char[], dchar) [0x486fac]
/usr/include/dmd/phobos/std/stdio.d:1426 immutable(char)[] 
std.stdio.File.readln!(immutable(char)[]).readln(dchar) [0x486eb1]
/usr/include/dmd/phobos/std/stdio.d:3385 immutable(char)[] 
std.stdio.readln!(immutable(char)[]).readln(dchar) [0x486e3b]

source/app.d:25 _Dmain [0x48677e]
??:? 
_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv 
[0x48ad2a]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate()) [0x48ac74]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).runAll() [0x48ace6]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate()) [0x48ac74]

??:? _d_run_main [0x48abe5]
??:? main [0x487b0b]
??:? __libc_start_main [0xc7628ec4]

Re: execute bash?

[Puming via Digitalmars-d-learn]

On Friday, 8 April 2016 at 13:25:37 UTC, Adam D. Ruppe wrote:

On Friday, 8 April 2016 at 13:23:10 UTC, Adam D. Ruppe wrote:
Odds are it is that there's terminal output for the background 
process


NOT a character btw, just any output, then the OS puts you on 
hold so it can do its thing.


To catch a signal, it is just like in C 
http://stackoverflow.com/a/35687472/1457000


simplest case:

import core.stdc.signal;
signal(SIGTTOU, SIG_IGN); // ignore the output thing


and see what happens next


I tried with signal, but didn't catch SIGTTOU, it seems that 
spawnProcess with `bash -i -c` will signal with SIGTTIN.


When I catch SIGTTIN with:

 extern(C) void sig_hand(int signal) nothrow @nogc @system {
import core.stdc.stdio: printf;
printf("signal %d catched!\n", signal);
 }

I get an infinite loop of

signal 21 catched!
signal 21 catched!
signal 21 catched!

Not sure how to handle that. Maybe I can't use `bash -i`.

Re: execute bash?

[Puming via Digitalmars-d-learn]

On Friday, 8 April 2016 at 13:23:10 UTC, Adam D. Ruppe wrote:

On Friday, 8 April 2016 at 10:08:07 UTC, Puming wrote:
but with each command loop, the program is stopped (equal to 
Ctrl-Z).


Your program is stopped, right?

Odds are it is that there's terminal output for the background 
process, which sends your program a signal which, by default, 
stops it.


From man 7 stop:

   SIGSTOP   17,19,23StopStop process
   SIGTSTP   18,20,24StopStop typed at terminal
   SIGTTIN   21,21,26StopTerminal input for 
background process
   SIGTTOU   22,22,27StopTerminal output for 
background process



Ah, that must be the case. Thanks :-)

I just found that you have terminal.d in arsd repo, are you
writing a repl with it? I'm hoping I might be able to use it.

I'm writing a simple repl for my toy language for learning.




I'd say try catching one of those signals and confirm if it is 
one of them and then figure out what to do next. Maybe ignoring 
the signal is what you want to do.

execute bash?

[Puming via Digitalmars-d-learn]

Hi,

I'd like to write an interactive commmand line tool for my 
commands, and that also support bash commands.


My first thinking is 'why not just execute those bash commands 
with bash'? But it turns out to have some problem.


When I use executeShell, I found that .bashrc is not loaded so 
that custom aliases like 'll' are not usable, and there is no 
color in the output.


Then I use spawnProcess:

```
import std.process;
void main() {
  for (int i = 0; i < 3; ++i) { // emulate the interactive loop
string cmd = "ll";
wait(spwanProcess(["/bin/bash", "-i", "-c", cmd]));
  }
}
```

with the bash option "-i", the .bashrc is loaded and the output 
is colored, but with each command loop, the program is stopped 
(equal to Ctrl-Z).


I thought the subprocess may have returned some special char like 
Ctrl-Z, so I changed to use pipeProcess to try to catch them. But 
it does not work either.


My question is:

1. what can I do to prevent this stop effect?
2. what is the best way to make a proxy to a bash process?

Re: is std.algorithm.joiner lazy?

[Puming via Digitalmars-d-learn]

On Friday, 8 April 2016 at 08:44:36 UTC, Mike Parker wrote:

On Friday, 8 April 2016 at 03:20:53 UTC, Puming wrote:
On Friday, 8 April 2016 at 02:49:01 UTC, Jonathan M Davis 
wrote:

[...]


Thanks. I'll adopt this idiom. Hopefully it gets used often 
enough to warrent a phobos function :-)


What would such a function look like? I don't think such a 
thing could exist. This is more than just an idiom, IMO. It's a 
basic principle of ranges that, if not followed, is likely to 
produce a broken range and/or one whose front is more expensive 
than it needs to be. The trouble is that it isn't necessarily 
obvious and is easy to overlook when first implementing a 
custom range.




I thought it was just like map!readNext.cache



[...]

Re: is std.algorithm.joiner lazy?

[Puming via Digitalmars-d-learn]

On Friday, 8 April 2016 at 02:49:01 UTC, Jonathan M Davis wrote:

[...]


Thanks. I'll adopt this idiom. Hopefully it gets used often 
enough to warrent a phobos function :-)

Re: how to parse a string into a phobos datatype with additional logic

[Puming via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 11:07:35 UTC, Marc Schütz wrote:

On Thursday, 7 April 2016 at 08:06:03 UTC, Puming wrote:

On Thursday, 7 April 2016 at 07:45:06 UTC, yawniek wrote:

what is the way one is supposed to parse e.g. a
double of unixtime (as delived by nginx logs) into a SysTime?

currently i'm creating a wrapper struct around SysTime with 
alias this as:


https://gist.github.com/yannick/6caf5a5184beea0c24f35d9d4a4c7783

really ugly imho.

is there a better way to do this?


you mean 
http://dlang.org/phobos/std_datetime.html#.SysTime.fromUnixTime ?


That one only accepts `long`, though, so you'd lose sub-second 
precision.


Yes, might be due to that standard UnixTime only has second 
precision.


For the sub-second part, you need to add a duration like nsecs. 
It's still ugly, but you don't need another struct if what you 
want is just a SysTime.


SysTime parseNginxTime(string t) {
   // assuming the nginx time has precision of nano-seconds.
   return SysTime.fromUnixTime(t[0..$-9].to!long)
   + t[$-9..$].to!long.nsecs;
}

The problem though is that SysTime only hode precision to the 
hnsec, so the last three digits is actually lost.

Re: is std.algorithm.joiner lazy?

[Puming via Digitalmars-d-learn]

On Friday, 8 April 2016 at 01:14:11 UTC, Jonathan M Davis wrote:

[...]

Well, given your example, I would strongly argue that you 
should write a range that calls read in its constructor and in 
popFront rather (so that calling front multiple times doesn't 
matter) rather than using map. While map can theoretically be 
used the way that you're trying to use it, it's really intended 
for converting an element using rather than doing stuff like 
I/O in it. Also, if the range that you give map is random 
access (like an array would be), then opIndex could be used to 
access random elements, which _really_ wouldn't work with 
reading from a file. So, I think that map is just plain a bad 
choice for what you're trying to do.




Well, I used map because of when viewing the scenario in a data 
flow, map seems an intuitive choise:


what I have: a bunch of large files, each file containing 
sections of data, each sections is composed of many lines of 
record. For each file, I have an list of indices.


what I want: given a list of files and indices for each file, I 
want to construct a lazy stream of records for other program to 
use.


here is the data flow:

query constraints
-> [(filePath, [index])]
-> [(File, [index])] // map, needs cache
-> [[section]] // map, needs cache
-> [[[record]]]  // joiner.joiner
-> Range of record

And after reading cache's docs, I get that cache is perfect for 
converting a Range with front side effect into a Range with 
popFront side effect.


So if cache and map works harmoniously, they should do the same 
trick as manually writing two Ranges here.




- Jonathan M Davis

Re: is std.algorithm.joiner lazy?

[Puming via Digitalmars-d-learn]

On Friday, 8 April 2016 at 01:14:11 UTC, Jonathan M Davis wrote:

[...]

Lazy means that it's not going to consume the entire range when 
you call the function. Rather, it's going to return a range 
that you can iterate over. It may or may not process the first 
element before returning, depending on how it works, and 
there's definitely nothing that says whether it's going to 
access front multiple times or not before calling popFront. And 
accessing front multiple times without calling popFront is 
_normal_ whether you're dealing with a lazy range or an eager 
one. All that lazy means is that you're getting a range from 
the function rather than it consuming the range before 
returning.


So, whatever you do with a range, in general, you have to 
assume that an algorithm might access front multiple times, and 
the implementation is free to change so that it accesses it 
more times or fewer times, because the range API says nothing 
about whether front is accessed multiple times or not. front 
needs to return equal values every time that it's called before 
popFront is called, but that doesn't mean that they have to be 
the same objects, and it doesn't mean that there's any 
restriction on how many times front is accessed before a call 
to popFront.


So, I see no reason for joiner to say anything in its docs 
about how many times it accesses front. It's pretty much 
irrelevant to how ranges are expected to work, and it could 
change. If it actually matters for what you're doing, then you 
need to figure out how to rework your code so that it doesn't 
matter whether front is accessed multiple times per call to 
popFront or not. That's just part of working with ranges, 
though I can certainly understand if you didn't realize that 
previously.

That makes sense. Thanks for the clarification.


There is another problem, map, cache, and joiner don't work 
when composed multiple times. I've submitted a bug, 
https://issues.dlang.org/show_bug.cgi?id=15891, can you 
confirm?


Well, given your example, I would strongly argue that you 
should write a range that calls read in its constructor and in 
popFront rather (so that calling front multiple times doesn't 
matter) rather than using map. While map can theoretically be 
used the way that you're trying to use it, it's really intended 
for converting an element using rather than doing stuff like 
I/O in it. Also, if the range that you give map is random 
access (like an array would be), then opIndex could be used to 
access random elements, which _really_ wouldn't work with 
reading from a file. So, I think that map is just plain a bad 
choice for what you're trying to do.


So what you mean is to read the front in constructor, and read 
further parts in the popFront()? that way multiple access to the 
front won't hurt anything. I think it might work, I'll change my 
code.


So the guideline is: when accessing front is costly, don't use 
map, use a customized range struct instead. right?




It's not obvious to me why your example is failing to compile - 
the problem appears to be with cache specifically and has 
nothing to do with joiner - and I am inclined to agree that 
there's a bug there (be it in cache or in the compiler), but I 
really think that using map is a bad move for what you're 
trying to do anyway - especially when you consider what will 
happen if opIndex is used. I'd strongly encourage you to just 
write a range that does what you need instead.


OK, hope it'll get fixed. I'll try to look for it once I'm able 
to understande the code in phobos.




- Jonathan M Davis

Re: is std.algorithm.joiner lazy?

[Puming via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 18:15:07 UTC, Jonathan M Davis wrote:
On Thursday, April 07, 2016 08:47:15 Puming via 
Digitalmars-d-learn wrote:

On Thursday, 7 April 2016 at 08:27:23 UTC, Edwin van Leeuwen

wrote:
> On Thursday, 7 April 2016 at 08:17:38 UTC, Puming wrote:
>> On Thursday, 7 April 2016 at 08:07:12 UTC, Edwin van 
>> Leeuwen wrote:

>>
>> OK. Even if it consumes the first two elements, then why 
>> does it have to consume them AGAIN when actually used? If 
>> the function mkarray has side effects, it could lead to 
>> problems.

>
> After some testing it seems to get each element twice, calls 
> front on the MapResult twice, on each element. The first two 
> mkarray are both for first element, the second two for the 
> second. You can solve this by caching the front call with:

>
> xs.map!(x=>mkarray(x)).cache.joiner;

Thanks! I added more elements to xs and checked that you are 
right.


So EVERY element is accessed twice with joiner. Better add 
that to the docs, and note the use of cache.


I would note that in general, it's not uncommon for an 
algorithm to access front multiple times. So, this really isn't 
a joiner-specific issue. If anything, it's map that should get 
a note in its docs, not joiner. You really should just expect 
front to be called multiple times. So, if that's a problem, use 
cache. But joiner is not doing anything abnormal.


But in the joiner docs, it says joiner is lazy. But accessing 
front multiple times is not true laziness. I think it better note 
that after the lazy part: "joiner is lazy, but it will access the 
front twice".


If there are many other lazy functions behave like this, I 
suggest to make a new name for it, like 'semi-lazy', to be more 
accurate.


Maybe its my fault, I didn't know what cache does before Edwin 
told me.
So there is the solution, it just is not easy for newbies to find 
out because there is no direct link between these functions.




And it's not even the case that it necessarily makes sense to 
make a rule of thumb that ranges should copy front instead of 
calling it multiple times, because if front returns by ref, 
calling front multiple times is likely to be cheapepr, and 
while we don't properly support non-copyable types (like 
UniquePtr) with ranges right now, we really should, so if 
anything, it becomes the case that algorithms should favor 
calling front multiple times over copying its value.


Indeed. I think copy is not good. But multiple access is a thing 
to note. When I want to use lazy things, it usually is that I'm 
reading files, so accessing twice is not acceptable.




So, there are pros and cons involved with copying front vs 
calling it multiple times, and I think that both approaches are 
both pretty common at this point. So, given how frequently it 
makes sense for map to allocate (e.g. to!string(a)), map should 
probably have a note about cache, but overall, it's just 
something that you need to be aware of. Regardless, I don't 
think that it makes sense to put anything in joiner's docs 
about it.


There is another problem, map, cache, and joiner don't work when 
composed multiple times. I've submitted a bug, 
https://issues.dlang.org/show_bug.cgi?id=15891, can you confirm?


Because of this, now I have to read a file multiple times(using 
only joiner), or have to eagerly retrieve data in an array (which 
is too big), or fall back to an imperative way of manually 
accessing each file. They are all bad.


- Jonathan M Davis

Re: is std.algorithm.joiner lazy?

[Puming via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 10:57:25 UTC, Edwin van Leeuwen 
wrote:

On Thursday, 7 April 2016 at 09:55:56 UTC, Puming wrote:

[...]


That seems like a bug to me and you might want to submit it to 
the bug tracker. Even converting it to an array first does not 
seem to work:


[...]


Thanks. I just looked at the joiner code, but didn't find the 
source of error. I'll submit a bug report.

Re: is std.algorithm.joiner lazy?

[Puming via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 08:27:23 UTC, Edwin van Leeuwen 
wrote:

On Thursday, 7 April 2016 at 08:17:38 UTC, Puming wrote:
On Thursday, 7 April 2016 at 08:07:12 UTC, Edwin van Leeuwen 
wrote:


OK. Even if it consumes the first two elements, then why does 
it have to consume them AGAIN when actually used? If the 
function mkarray has side effects, it could lead to problems.


After some testing it seems to get each element twice, calls 
front on the MapResult twice, on each element. The first two 
mkarray are both for first element, the second two for the 
second. You can solve this by caching the front call with:


xs.map!(x=>mkarray(x)).cache.joiner;


There is another problem with cache, that is if I want another 
level of this map(which is my code scenario, where I'm 
reading a bunch of files, with each one I need to read multiple 
locations with seek and return a bunch of lines with each seek), 
adding cache will result compiler error:


simplified demo:

auto read(int a) {
   writeln("read called!", a);
   return [0, a]; // second level
}

auto mkarray(int a) {
  writeln("mkarray called!", a);
  return [-a, a].map!(x=>read(x)).cache.joiner; // to avoid 
calling read twice

}

void main() {
  auto xs = [1,2 ,3, 4];
  auto r = xs.map!(x=>mkarray(x)).cache.joiner; // to avoid 
calling mkarray twice


  writeln(r);
}

When compiled, I get the error:

Error: open path skips field __caches_field_0
source/app.d(19, 36): Error: template instance 
std.algorithm.iteration.cache!(MapResult!(__lambda1, int[])) 
error instantiating

Re: is std.algorithm.joiner lazy?

[Puming via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 08:27:23 UTC, Edwin van Leeuwen 
wrote:

On Thursday, 7 April 2016 at 08:17:38 UTC, Puming wrote:
On Thursday, 7 April 2016 at 08:07:12 UTC, Edwin van Leeuwen 
wrote:


OK. Even if it consumes the first two elements, then why does 
it have to consume them AGAIN when actually used? If the 
function mkarray has side effects, it could lead to problems.


After some testing it seems to get each element twice, calls 
front on the MapResult twice, on each element. The first two 
mkarray are both for first element, the second two for the 
second. You can solve this by caching the front call with:


xs.map!(x=>mkarray(x)).cache.joiner;


Thanks! I added more elements to xs and checked that you are 
right.


So EVERY element is accessed twice with joiner. Better add that 
to the docs, and note the use of cache.

Re: is std.algorithm.joiner lazy?

[Puming via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 08:07:12 UTC, Edwin van Leeuwen 
wrote:

On Thursday, 7 April 2016 at 07:07:40 UTC, Puming wrote:

[...]


Apparently it works processing the first two elements at 
creation. All the other elements will be processed lazily.


Even when a range is lazy the algorithm still often has to 
"consume" one or two starting elements, just to set initial 
conditions. It does surprise me that joiner needs to process 
the first two, would have to look at the implementation why.


OK. Even if it consumes the first two elements, then why does it 
have to consume them AGAIN when actually used? If the function 
mkarray has side effects, it could lead to problems.

Re: how to parse a string into a phobos datatype with additional logic

[Puming via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 07:45:06 UTC, yawniek wrote:

what is the way one is supposed to parse e.g. a
double of unixtime (as delived by nginx logs) into a SysTime?

currently i'm creating a wrapper struct around SysTime with 
alias this as:


https://gist.github.com/yannick/6caf5a5184beea0c24f35d9d4a4c7783

really ugly imho.

is there a better way to do this?


you mean 
http://dlang.org/phobos/std_datetime.html#.SysTime.fromUnixTime ?

is std.algorithm.joiner lazy?

[Puming via Digitalmars-d-learn]

Hi:

when I use map with joiner, I found that function in map are 
called. In the document it says joiner is lazy, so why is the 
function called?


say:

int[] mkarray(int a) {
   writeln("mkarray called!");
   return [a * 2]; // just for test
}

void main() {
   auto xs = [1, 2];
   auto r = xs.map!(x=>mkarray(x)).joiner;
}

running this will get the output:

mkarray called!
mkarray called!

I suppose joiner does not consume?

when I actually consume the result by writlen, I get more output:

mkarray called!
mkarray called!
[2mkarray called!
mkarray called!
, 4]

I don't understand

Re: Build release and debug with dub

[Puming via Digitalmars-d-learn]

On Thursday, 7 April 2016 at 02:07:18 UTC, Puming wrote:

On Wednesday, 6 April 2016 at 19:49:38 UTC, Suliman wrote:

[...]


In the document it says you can not specify targetName in 
buildType. I wonder why is that?


But you can use two configurations like this(assumming your 
project is named "App"):


```
configuration "App" {
targetType "executable"
targetName "hello"

typo: "hello" -> "App"

}
configuration "AppDebug" {
targetType "executable"
targetName "AppDebug"
}
```

and use `dub -c AppDebug` for AppDebug.exe, and `dub -b 
release` for App.exe

Re: Build release and debug with dub

[Puming via Digitalmars-d-learn]

On Wednesday, 6 April 2016 at 19:49:38 UTC, Suliman wrote:
Is it's possible to make rule, that allow to build two version 
of App? One release and one debug at same time. I looked at 
"buildTypes" https://code.dlang.org/package-format?lang=json


But it's not possible to set different names for output files. 
I want to build App.exe and AppDebug.exe after simple command 
dub build.


In the document it says you can not specify targetName in 
buildType. I wonder why is that?


But you can use two configurations like this(assumming your 
project is named "App"):


```
configuration "App" {
targetType "executable"
targetName "hello"
}
configuration "AppDebug" {
targetType "executable"
targetName "AppDebug"
}
```

and use `dub -c AppDebug` for AppDebug.exe, and `dub -b release` 
for App.exe

Re: The Sparrow language

[Puming via Digitalmars-d]

On Wednesday, 6 April 2016 at 20:42:27 UTC, Lucian Radu 
Teodorescu wrote:

On Wednesday, 6 April 2016 at 14:54:18 UTC, Puming wrote:
On Wednesday, 6 April 2016 at 13:15:48 UTC, Andrei 
Alexandrescu wrote:

[...]


Interesting. I've thinking about concepts too. Hopefully they 
could come into D. Actually, I think concept and interfaces 
could be combined into one feature. An interface is just a 
special case of a concept, saying its implementer should have 
the matching function signatures.


In my opinion implementing concepts in terms of interfaces is 
more restrictive than implementing them as boolean predicates. 
You cannot create interfaces based on existence of attributes, 
on existence of dependent types or on the existence of extern 
function that apply to your types. Moreover, you cannot create 
concepts based on the compile-time values associated with your 
type.


Well, I meant the opposite, interfaces be implemented with 
concept.

So in my opinion, interface is just a spcecial case of concept.
I'm in the same park with you.
See 
https://github.com/venus-lang/venus/blob/master/docs/reference/trait.md where I call concept 'trait'.




One basic example, from C++, is that you cannot create a 
concept that distinguishes between vector and 
vector, as they theoretically should have the same 
interface.


The main uses of concepts are in my view most of the time 
related to dependent types. I would like to have an InputRange 
concept that will also tell me the type of the elements I can 
read from it.




Exactly, that is well I found InputRange in D awkward, where I 
have to specify a long predicate everywhere in my function 
definiations of a call chain.


Implementing concepts as predicates, give you much more 
freedom. I would argue that you can represent many more 
concepts with predicates. Not only you can represent all the 
"has-a" relations, but you can also place conditions on the 
compile-time values that your types might have, and how that 
class may be used.



Yes, indeed.

My two cents,
LucTeo

Re: The Sparrow language

[Puming via Digitalmars-d]

On Wednesday, 6 April 2016 at 13:15:48 UTC, Andrei Alexandrescu 
wrote:

I just got word about Sparrow (from its creator no less):

presentation_offline_Sparrow.pdf - https://db.tt/m2WwpxIY
Speak.mp4 - https://db.tt/RDmrlEu7
ThesisLucTeo.pdf - https://db.tt/1ylGHuc1

An interesting language that shares a lot of D's vision and 
features. The languages differ in a few aspects: Sparrow has a 
much more flexible syntax allowing a variety of custom 
operators. (I happen to disagree that's a good thing as I 
believe highly flexible syntax easily leads to transmission 
noise code). On the plus side Sparrow has a smoother 
integration of compile-time vs. run-time computation, which 
makes it a bit easier to transition from one to another. 
Another feature we could consider adding to D is a simple 
definition of concepts as complex Boolean predicates. That's 
essentially identical to isForwardRange etc. etc. but makes for 
simpler use of these predicates.



Andrei


Interesting. I've thinking about concepts too. Hopefully they 
could come into D. Actually, I think concept and interfaces could 
be combined into one feature. An interface is just a special case 
of a concept, saying its implementer should have the matching 
function signatures.

Re: Release D 2.071.0

[Puming via Digitalmars-d-announce]

On Tuesday, 5 April 2016 at 22:43:05 UTC, Martin Nowak wrote:

Glad to announce D 2.071.0.

http://dlang.org/download.html

This release fixes many long-standing issues with imports and 
the module

system.
See the changelog for more details.

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

-Martin


Thanks! upgraded to the new version at work.

Re: infer type argument in classe constructor?

[Puming via Digitalmars-d-learn]

On Tuesday, 29 March 2016 at 10:29:46 UTC, Simen Kjaeraas wrote:

On Tuesday, 29 March 2016 at 10:13:28 UTC, Puming wrote:

Hi,

I'm writing a generic class：

```d

struct Message { ... }

class Decoder(MsgSrc) {
}
```

When using it, I'd have to include the type of its argument:

```
void main() {
   Message[] src = ...;

   auto decoder = new Decoder!(Message[])(src);

   ...
}
```

Can it be inferred so that I only need to write?

```d
auto decoder = new Decoder(src); // you can infer the type 
from src.

```


Nope. To see why, consider a class like this:

class A(T) {
  T data;
  this(int n) {
  }
}

void main() {
   auto a = new A(3); // What is T?
}


Sorry I don't see it. In this case, I don't see an ambiguity?

`int n` and T are not connected, so invoking A(3) means you are 
only setting the argument n to 3, so T can not be infered, and 
the compiler could just complain 'generic type T is not provided'.



The common solution is a simple 'create' function:

Decoder!T decoder(T)(T msg) {
return new Decoder!T(msg);
}

--
  Simen

infer type argument in classe constructor?

[Puming via Digitalmars-d-learn]

Hi,

I'm writing a generic class：

```d

struct Message { ... }

class Decoder(MsgSrc) {
}
```

When using it, I'd have to include the type of its argument:

```
void main() {
   Message[] src = ...;

   auto decoder = new Decoder!(Message[])(src);

   ...
}
```

Can it be inferred so that I only need to write?

```d
auto decoder = new Decoder(src); // you can infer the type from 
src.

```

Re: string and char[] in Phobos

[Puming via Digitalmars-d-learn]

On Friday, 18 March 2016 at 20:06:27 UTC, Jonathan M Davis wrote:


When a function accepts const(char)[] than it can accept char[],
const(char)[], const(char[]), immutable(char)[], and 
immutable(char[]),

which, whereas if it accepts string, then all it accepts are
immutable(char)[] and immutable(char[]). So, it's more
So I need to use const(char)[] in my function definitions instead 
of in char[]?

restrictive, but if
you need to return a slice of the array you passed in, if your 
function
accepts const rather than mutable or immutable, then the slice 
has to be
const, and you've lost the type information, which is why inout 
exists -

Well, I never got inout until now, thanks!

[...]
I don't know what you're using in Phobos that takes string and 
returns char[]. That implies an allocation, and if the function 
is pure, char[] may have been selected, because it could be 
implicitly converted to string thanks to the fact that the 
compiler could prove that the char[] being returned had to have 
been allocated in the function and that there could be no other 
references to that array. But without knowing exactly which 
functions you're talking about, I can't really say. In general 
though, the solution that we've gone with is to templatize 
functions that operate on strings, and a function that's taking 
a string explicitly is most likely storing it, in which case, 
it needs an explicit type, and using an immutable value ensures 
that it doesn't change later.


I just got this feeling from using functions in the std.file 
module, like dirEntries and File constructor itself. After 
reading your explaination, it makes sense now. And with a second 
look up, most functions there ARE alread templatized. Thanks for 
your clarification.


On a side note, I'd strongly argue against using "in" on 
function arguments that aren't delegates. in is equivalent to 
const scope, and scope currently does nothing for any types 
other than delegates - but it might later, in which case, you 
could be forced to change your code, depending on the exact 
semantics of scope for non-delegates. But it does _nothing_ now 
with non-delegate types regardless, so it's a meaningless 
attribute that might change meaning later, which makes using it 
a very bad idea IMHO. Just use const if you want const and 
leave scope for delegates. I'd actually love to see in 
deprecated, because it adds no value to the language (since 
it's equivalent to const scope, which you can use explicitly), 
and it hides the fact that scope is used.


Well, this is too complicated level for me now. I'll get to that 
later when I learn more with the language.


My take away from your post:

- when the function is pure for the stringlike, use 
'const(char)[]' or 'inout(char)[]' when neccessary.

- when the argument is stored in the function, use string.
- manually convert stringlike objects to string with to!string 
when calling those functions.


are those above correct?



- Jonathan M Davis

string and char[] in Phobos

[Puming via Digitalmars-d-learn]

Hi,

I saw from the forum that functions with string like arguments 
better use `in char[]` instead of `string` type, because then it 
can accept both string and char[] types.


But recently when actually using D, I found that many phobos 
functions/constructors use `string`, while many returns `char[]`, 
causing me to do a lot of conv.to!string. And many times I have 
to fight with the excessive template error messages.


Is there a reason to use `string` instead of `in char[]` in 
function arguments? Do you tend to change those phobos functions?

Re: Official compiler

[Puming via Digitalmars-d]

On Thursday, 25 February 2016 at 02:48:24 UTC, Walter Bright 
wrote:

On 2/24/2016 6:05 PM, Adam D. Ruppe wrote:
I've also heard from big users who want the performance more 
than compile time

and hit difficulty in build scaling..


I know that performance trumps all for many users. But we can 
have both - dmd and ldc/gdc.


My point is that compile speed is a valuable and distinguishing 
feature of D. It's one that I have to constantly maintain, or 
it bit rots away. It's one that people regularly dismiss as 
unimportant. Sometimes it seems I'm the only one working on the 
compiler who cares about it.


For comparison, C++ compiles like a pig, I've read that Rust 
compiles like a pig, and Go makes a lot of hay for compiling 
fast.


Maybe in the future, when ldc/gdc catches up versions with dmd, 
we can combine them into a bundle for downloads? Then new people 
can just download the compiler bundle and run dmd or ldc/gdc as 
they like.

Re: Vision for the first semester of 2016

[Puming via Digitalmars-d-announce]

On Friday, 29 January 2016 at 23:41:47 UTC, Ola Fosheim Grøstad 
wrote:




Yep, a curated list like those awesome-lists found on github 
would be a start.




I've got one before there were many awesome-lists: 
https://github.com/zhaopuming/awesome-d

Re: What is the best declaration type for a string like parameter?

[Puming via Digitalmars-d-learn]

On Thursday, 28 January 2016 at 15:03:38 UTC, sigod wrote:

On Thursday, 28 January 2016 at 13:36:46 UTC, Puming wrote:

[...]


`in char[]` is short for `scope const char[]` or `scope 
const(char[])`.


See http://dlang.org/spec/function.html#parameters

It depends on the situation. If possible I would use `in` 
modifier. If not then just `const`.



[...]


Please, don't define such aliases. I'm sure a lot of developers 
will find it confusing. As I do.


`const(char)[]` or `in char[]` is perfectly understandable as 
soon as you know what it means.


Also, read this: http://dlang.org/spec/const3.html


Thanks. Now I get it.

Yes it is understandable now, but as a newbie the question "Why 
my function that accepts a string does not work with lines in 
file?" will pop.

What is the best declaration type for a string like parameter?

[Puming via Digitalmars-d-learn]

I have a function that reads a line of string and do some 
computation.


I searched the forum and found that people use `const(char)[]` or 
`in char[]` to accept both string and char[] arguments.



What's the difference between `const(char)[]` and `in char[]`?

If they are not the same, then which is better? If they are, then 
why both forms exists?


I found it a bit confusing and not quite readable, so I made an 
alias:


alias str = const(char)[]

and so far it works. But if `in char[]` is better, then I cannot 
alias it:


alias str = in char[]

this does not compile.

Re: What is the best declaration type for a string like parameter?

[Puming via Digitalmars-d-learn]

On Thursday, 28 January 2016 at 15:10:38 UTC, Adam D. Ruppe wrote:


But for just both string and char[], yeah, const is the way to 
do it.


[...]


Thanks for the clear explaination. So `in char[]` is stricter 
(and safer) than `const(char)[]`. I will stick to that.

Re: Vision for the first semester of 2016

[Puming via Digitalmars-d-announce]

On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:

Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


For PRs, I suggest the goal to be number of PRs MERGED instead of 
created. That may provide the core team a subconsious incentive 
to look at long pending PRs and hit a good cycle.


For tooling, I suggest a look at GUI/IDEs, now that 
dlangui/dlangide seems a good candidate(native D, crossplatform). 
A good official supported GUI library will attract many people.

Re: Vision for the first semester of 2016

[Puming via Digitalmars-d-announce]

On Monday, 25 January 2016 at 03:49:56 UTC, Rikki Cattermole 
wrote:

On 25/01/16 4:21 PM, Puming wrote:
On Monday, 25 January 2016 at 02:37:40 UTC, Andrei 
Alexandrescu wrote:
Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- 
Andrei


For PRs, I suggest the goal to be number of PRs MERGED instead 
of
created. That may provide the core team a subconsious 
incentive to look

at long pending PRs and hit a good cycle.

For tooling, I suggest a look at GUI/IDEs, now that 
dlangui/dlangide
seems a good candidate(native D, crossplatform). A good 
official

supported GUI library will attract many people.


That won't be happening anytime soon.
Until we have image and windowing in Phobos (I'm working on 
both) there is no way a GUI toolkit is going in. And from what 
I know there will be a LOT of work to update it.


Well I'm not saying that a GUI toolkit should go into Phobos.
I'd rather it stand alone, while taking some official support, 
say, link in D frontpage(like visualD).

Re: Vision for the first semester of 2016

[Puming via Digitalmars-d-announce]

On Monday, 25 January 2016 at 05:50:34 UTC, Rikki Cattermole 
wrote:


I want us to hold off on that as well.


I agree that we need a more solid base.

I want people to really have a go with making GUI toolkits in D 
without the worry about how to do the cross platformy technical 
things.


Is dlangui a good start on this?



We just don't know what could be done yet and I'm looking 
forward to finding out.


I think improving dlangide will give us many opportunities for 
what a good D native GUI library needs.

Re: [dlang.org] new forum design

[Puming via Digitalmars-d]

On Monday, 18 January 2016 at 10:20:13 UTC, Vladimir Panteleev 
wrote:
As the new design rolled out on dlang.org, I decided to push 
the changes on forum.dlang.org as well. From what I gathered 
from the previous feedback thread, I believe we've addressed 
the most stringent issues. Once again thanks to anonymous / 
@aG0aep6G for doing practically all the work, and to everyone 
who's provided feedback so far.


I often found that I have to hover mouse on the title when 
viewing "Last Post" on the forum index pages, and think that is a 
bit annoying.


The "Group" column is very wide, with not any content.

So I changed the css a little and get this looking:

http://imgur.com/MxJJURL

Now "Last Post" column is at the center of focus and most of the 
times the title is shown wholy.


As for the subtitle in "Group" columns, I think you can make it a 
hover tip instead of directly displaying.


Do you think this looks better?

Re: [dlang.org] new forum design - preview

[Puming via Digitalmars-d]

On Wednesday, 13 January 2016 at 06:01:41 UTC, Vladimir Panteleev 
wrote:

http://beta.forum.dlang.org/

https://github.com/CyberShadow/DFeed/pull/51


My 2 cents:

1. The left side bar is too wide. The content pane should be 
wider.

2. The "Group" column is too wide.
3. The "Last Post" column is too narrow. This column is what we 
actually want to read, so it should be given highest priority, 
one should be able to read the whole title without mouse hover. 
Also its background color should not be grey.

4. Font

Re: What are you planning for 2016?

[Puming via Digitalmars-d]

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


Do you have plans to:


8. or something else?


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


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


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


Things on my wish list:

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


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


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


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

Multiple range enumeration

[puming via Digitalmars-d-learn]

Hi,

If I have multiple ranges, say:

auto a = [1, 2, 3];
auto b = ["a", "b", "c"];
auto c = ["x", "y", "z"];

I'd like a composition range that enumerate all combinations of 
these ranges,

having the same effect as a nested foreach loop:

foreach (i; a) {
  foreach (j; b) {
foreach (k; c) {
   writlen(i, j, k);
}
  }
}

Is there such a generic function in std lib?

Re: Multiple range enumeration

[puming via Digitalmars-d-learn]

On Wednesday, 11 November 2015 at 02:55:25 UTC, cym13 wrote:

On Wednesday, 11 November 2015 at 02:38:19 UTC, puming wrote:

Hi,

If I have multiple ranges, say:

auto a = [1, 2, 3];
auto b = ["a", "b", "c"];
auto c = ["x", "y", "z"];

I'd like a composition range that enumerate all combinations 
of these ranges,

having the same effect as a nested foreach loop:

foreach (i; a) {
  foreach (j; b) {
foreach (k; c) {
   writlen(i, j, k);
}
  }
}

Is there such a generic function in std lib?


http://dlang.org/phobos/std_algorithm_setops.html#.cartesianProduct ?


Thanks :-)

Re: Type helpers instead of UFCS

[Puming via Digitalmars-d]

On Sunday, 13 September 2015 at 14:37:36 UTC, Kagamin wrote:

On Saturday, 12 September 2015 at 21:04:47 UTC, BBasile wrote:
You've got the idea. IDE plugins can not decently provide 
completion based on the UFCS possibilities.


It's possible, just not implemented yet.


Mono-d seems to have experimental UFCS support

Re: Programming in D – Tutorial and Reference

[puming via Digitalmars-d-announce]

On Friday, 28 August 2015 at 22:58:30 UTC, Luís Marques wrote:

On Friday, 28 August 2015 at 22:42:00 UTC, sigod wrote:

Actual link: https://news.ycombinator.com/item?id=10136882


I think Walter didn't post the direct link because the referrer 
impacts the voting algorithm. So, please don't use the direct 
link.


Can we post a text without link and people could copy/paste the 
address? Will HN check that also?

Re: The object operator

[puming via Digitalmars-d]

On Friday, 14 August 2015 at 04:17:25 UTC, TheHamster wrote:



assert(@@myObj.Do(3).Do(@).Do(@2) == 9);




If what you want is to omit the object during the call chain, you 
can use with statement to mimic this feature, though not as 
compact as you suggested:


```
import std.stdio;
class MyClass {
  int run(int x) { return x + 2; }
}
void main() {
  auto ob = new MyClass();
  int res;
  with (ob) {
run(3);
run(4);
run(5);
  }
}
```

Re: D3

[Puming via Digitalmars-d]

On Tuesday, 9 December 2014 at 05:04:35 UTC, Jeremy DeHaan wrote:
On Tuesday, 9 December 2014 at 03:52:01 UTC, ketmar via 
Digitalmars-d wrote:

On Mon, 08 Dec 2014 21:08:03 +
Brad Anderson via Digitalmars-d digitalmars-d@puremagic.com 
wrote:


On Monday, 8 December 2014 at 20:21:51 UTC, Andrej Mitrovic 
via Digitalmars-d wrote:
 On 12/8/14, Russel Winder via Digitalmars-d 
 digitalmars-d@puremagic.com wrote:

 It seems that D3 is already available:

 https://github.com/mbostock/d3

 Guess we'll just have to skip a number and call the next D 
 - D4. :)


Major version numbers are actually in the letter so we should 
go to E1.

there was E language too: http://en.wikipedia.org/wiki/Amiga_E
with only 26 letters it's hard to be original. i'm voting for 
using

Japan or Chineese hieroglyphs, as there are plenty of them.


For Japanese it would be ディ which is pronounced the same as 
the name of the letter D.


For Chinese it would be 帝 which pronounces the same as 'D' and 
means Emperor.
An interesting coincidence is that Walter also created the game 
Empire :-)


source: I'm Chinese

Re: D in my trashbin

[Puming via Digitalmars-d]

The only OS that I found problematic with the dmd zip is CentOS 
5.8, all other systems I've tried: Centos 6.x, Ubuntu, Windows, 
MacOS, they all work perfectly.



On Friday, 24 October 2014 at 02:42:13 UTC, frustrated wrote:

Two days later and I still cant get a 'Hello World' to compile.
It is far beyond me how a project can exist for so many years
and still not have a straightforward installation that works out
of the box. Yes.. read the forums and search google for 
solutions

that may or may not work depending on the phases of the moon,
I have to ask you:
Why bother ?
Why would anybody trust a compiler written by people
who regard making it run out of the box an after-thought ?

Re: Announcing libasync, a cross-platform D event loop

[Zhao Puming via Digitalmars-d]

Great work Etienne!

will libasync make it into phobos?

On Wednesday, 24 September 2014 at 13:13:34 UTC, Etienne wrote:

It's finally here: https://github.com/etcimon/libasync

We all know how event loops are the foundation of more popular 
libraries Qt and Nodejs.. we now have a natively compiling 
async library entirely written in D.


This event library was tested on Win32, Linux x64, Mac OS x64, 
with DMD 2.066, offers the more low-level async objects: 
timers, file i/o, dns resolver, tcp, udp, listeners, signals 
(cross-thread), notifications (same thread), and more recently 
(and with great efforts for implementing with OS X / BSD) a 
directory watcher.


e.g. You can run a timer with:

import std.datetime; import std.stdio; import libasync.all;
EventLoop evl = new EventLoop;
auto timer = new AsyncTimer(evl);
	timer.duration(2.seconds).periodic().run({ writeln(Another 2 
seconds have passed); });

while(evl.loop()) continue;

The tests may be most revealing: 
https://github.com/etcimon/libasync/blob/master/source/libasync/test.d


A (lightly tested) vibe.d driver using all those async objects 
is also available and currently ongoing a pull request:


https://github.com/etcimon/vibe.d/tree/native-events

The incentive was to make vibe.d compile in completely native 
D, I'm now moving onto a botan C++ = D wrapper for it, I plan 
on moving objects to D over the years until the TLS library can 
be completely native. I thank Walter for the efforts on 
extern(C++)


Finally, I release this on the basis of an MIT license, looking 
forward to seeing our community flourishing with yet more 
native libraries. Code on

Clojure transducers

[Puming via Digitalmars-d]

Clojure is introducing a new way of composing functions (reducers 
this time), called transducers. It looks similar to 
composition/binding of functions, but somehow different. My 
functional-fu is not that deep to understand the statement 
transducers are as fundamental as function composition but it 
seems quite interesting. What is D's attitude toward this concept?


Here is a blog I read about transducers today:

http://thecomputersarewinning.com/post/Transducers-Are-Fundamental/

Re: sdlang-d can not link after updating to dmd 2.066

[Puming via Digitalmars-d-learn]

I updated dub to 0.9.22 and still got the same error...

THis is the output of `dub build --force`:

--- output ---

## Warning for package sdlang-d ##

The following compiler flags have been specified in the package 
description
file. They are handled by DUB and direct use in packages is 
discouraged.
Alternatively, you can set the DFLAGS environment variable to 
pass custom flags

to the compiler, or use one of the suggestions below:

-wi: Use the buildRequirements field to control warning behavior


## Warning for package sdlang-d, configuration unittest ##

The following compiler flags have been specified in the package 
description
file. They are handled by DUB and direct use in packages is 
discouraged.
Alternatively, you can set the DFLAGS environment variable to 
pass custom flags

to the compiler, or use one of the suggestions below:

-debug: Call dub with --build=debug
-unittest: Call dub with --build=unittest


## Warning for package sdlang-d ##

The following compiler flags have been specified in the package 
description
file. They are handled by DUB and direct use in packages is 
discouraged.
Alternatively, you can set the DFLAGS environment variable to 
pass custom flags

to the compiler, or use one of the suggestions below:

-wi: Use the buildRequirements field to control warning behavior


## Warning for package sdlang-d, configuration unittest ##

The following compiler flags have been specified in the package 
description
file. They are handled by DUB and direct use in packages is 
discouraged.
Alternatively, you can set the DFLAGS environment variable to 
pass custom flags

to the compiler, or use one of the suggestions below:

-debug: Call dub with --build=debug
-unittest: Call dub with --build=unittest

Building sdlang-d 0.8.4 configuration library, build type debug.
Running dmd...
Building haha ~master configuration application, build type 
debug.

Compiling using dmd...
Linking...
Undefined symbols for architecture x86_64:
  
_D7sdlang_3ast3Tag103__T11MemberRangeTC7sdlang_3ast3TagVAyaa7_616c6c54616773VAyaa11_746167496e646963696573VAyaa5_5f74616773Z11MemberRange11__invariantMxFZv, 
referenced from:
  
_D7sdlang_3ast3Tag103__T11MemberRangeTC7sdlang_3ast3TagVAyaa7_616c6c54616773VAyaa11_746167496e646963696573VAyaa5_5f74616773Z11MemberRange30__T13opBinaryRightVAyaa2_696eZ13opBinaryRightMFAyaZb 
in haha.o

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to 
see invocation)

--- errorlevel 1
FAIL 
.dub/build/application-debug-posix.osx-x86_64-dmd-561BEB9B9938BB39E9AD2177AB127CD0/ 
haha executable

Error executing command build: dmd failed with exit code 1.

-- end ---


On Wednesday, 27 August 2014 at 16:35:18 UTC, Israel wrote:


It looks fine here, OSX 10.9.4

sdlang-d: =0.8.4

Im using DUB RC2 though

sdlang-d can not link after updating to dmd 2.066

[Puming via Digitalmars-d-learn]

Hi,

I'm using sdlang-d version 0.8.4 
(http://code.dlang.org/packages/sdlang-d).


When I update dmd to version 2.066 today, I found that sdlang-d 
won't link, with these errors:


Undefined symbols for architecture x86_64:
  
_D7sdlang_3ast3Tag103__T11MemberRangeTC7sdlang_3ast3TagVAyaa7_616c6c54616773VAyaa11_746167496e646963696573VAyaa5_5f74616773Z11MemberRange11__invariantMxFZv, 
referenced from:
  
_D7sdlang_3ast3Tag103__T11MemberRangeTC7sdlang_3ast3TagVAyaa7_616c6c54616773VAyaa11_746167496e646963696573VAyaa5_5f74616773Z11MemberRange30__T13opBinaryRightVAyaa2_696eZ13opBinaryRightMFAyaZb 
in haha.o

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to 
see invocation)


I'm using Mac OSX. Do you have similar issue?

I reduced code to this:

```d
import std.stdio;
import sdlang;

void main()
{
auto cfg = parseFile(hello.sdl);
Tag t = cfg.tags[name][0];
writeln(t);
}
```

I'm wondering sdlang-d needs an update. Or is there a new project 
about sdlang?(heard about SDL becoming official in dub, wondering 
how dub is parsing SDL).

Awesome-D, and an invitation to you awesome guys

[Puming via Digitalmars-d-announce]

Hi,

I'm maintaining this awesome-d list similar to other 
awesome-stuff lists on github, for keeping a hook on interesting 
D related links.


https://github.com/zhaopuming/awesome-d

At first it was only for my personal use, but recently I got some 
ideas about it that could potentially contribute to the 
community, so here I am making this little announcement and 
invating all you awesome guys to help me :-)


The ideas are:

1. Awesome-People list that made D awesome.
2. A relation network on github projects

First one is about the awesome people, that is you guys. I've 
been lurking in this forum for many years (dating back to D1 
days). But only recently, after watching the great dconf videos, 
have I realized that it is the awesome people that makes the 
language/ecosystem awesome. I want to know you. And I think the 
new comers of D would also like to know you, each one of you 
great guys who made a library/tool that make their programming 
life a better place.


For lack of information and for the respect of privacy, currently 
I have only listed Walter and Andrei on the list, 
https://github.com/zhaopuming/awesome-d#people. But I'd really 
like to know about other people here, like kenji the great bug 
killing machie always in the shadow, or bearophile who studied an 
endless list of languages and exploded bugzilla, and many other.


For privacy, I think it's best that only the descriptions 
provided by people themselves or really related people should be 
allowed, or at least a permission is acquired by the person. 
(Sorry Walter and Andrei, I haven't asked for your permissions. 
But you're the stars and public faces here :-), privacy for you 
is a past).


I think people would be interesting to know who you are, what 
have you done, what do you think about D and it's future, what 
are you interesting, etc. Maybe an interview is a better option, 
but I don't know how to do that here. Do you guys have any ideas?


For the second stuff, after I made the awesome-d list, the 
awesome-awesome list maintainer made a pull request to add mine 
to his list and connect. Then I found a list of awesome-c, 
awesome-clojure, and all other awesome lists:


https://github.com/bayandin/awesome-awesomeness

which is very interesting and a good way to find information.

So the similar idea came to me: Why don't try to build a network 
about D stuff? D libs are scattered even in github--you don't 
have a good way to search for the libs you're interested in.


Now we have code.dlang.org, but it is also a one way list. 
Ideally it would be two way: if a person bumped into one of the D 
projects, and in the project there is a link that says enlisted 
on code.dlang.org, then he can easily go to code.dlang.org and 
see what other interesting, related projects their are.
This is very similar to what for me on github does, it makes a 
network.


Of couse, what I want to have is also enlisted on awesome-d. Do 
you project maintainers think it's good?


One last request for help: You might noticed that I'm not a 
native english speaker, so there are many grammar or style 
problems in the awesome-d list, if you find any, please help me 
fix it.


Best Regards.

Puming

Re: Awesome-D, and an invitation to you awesome guys

[Puming via Digitalmars-d-announce]

I forgot to note about wiki.dlang.org, and here it is:

I knew we have maintained a library list on wiki.dlang.org, 
actually I made several links to it in awesome-d. But why should 
I create this separate list on github? After some thinking, I 
justified it with the following reasons:


1. It is more personal and customizable. Every one can fork their 
own list and only keep things they're interested in. It is more 
opionioned.


2. For github users, especially new comers in D, wiki.dlang.org 
are an external
link, and a github page is more familiar and welcome. It is very 
easy to 'star'
a github page, compared to go to wike.dlang.org and find the 
list. This also applies to the dlang.org homepage and is also the 
reason why python\ruby also has a github awesome-list.


3. Its easier to contribute. Although this might not seem 
obvious, but I've seem that when D goes into github, the 
contribution got a big boost. People tend to contribute on github 
more than if it is in a private code repo. I think similar things 
apply for awesome-list vs wiki.


3. awesome-d joins the awesome-awesome list and would be more 
discoverable than wiki.dlang.org in github. this 'awesome' thing 
is already familiar to people.


4. we can make a bidirectional link network on github to 
advertise for good libraries.


So this list is only a companion to wiki.dlang.org's list.

I hope it's useful.

Of cause, it would be better we make a official awesome-d list on 
D-Programming-Language's github page.



On Sunday, 10 August 2014 at 09:28:48 UTC, Puming wrote:

Hi,

I'm maintaining this awesome-d list similar to other 
awesome-stuff lists on github, for keeping a hook on 
interesting D related links.


https://github.com/zhaopuming/awesome-d

At first it was only for my personal use, but recently I got 
some ideas about it that could potentially contribute to the 
community, so here I am making this little announcement and 
invating all you awesome guys to help me :-)


The ideas are:

1. Awesome-People list that made D awesome.
2. A relation network on github projects

First one is about the awesome people, that is you guys. I've 
been lurking in this forum for many years (dating back to D1 
days). But only recently, after watching the great dconf 
videos, have I realized that it is the awesome people that 
makes the language/ecosystem awesome. I want to know you. And I 
think the new comers of D would also like to know you, each one 
of you great guys who made a library/tool that make their 
programming life a better place.


For lack of information and for the respect of privacy, 
currently I have only listed Walter and Andrei on the list, 
https://github.com/zhaopuming/awesome-d#people. But I'd 
really like to know about other people here, like kenji the 
great bug killing machie always in the shadow, or bearophile 
who studied an endless list of languages and exploded bugzilla, 
and many other.


For privacy, I think it's best that only the descriptions 
provided by people themselves or really related people should 
be allowed, or at least a permission is acquired by the person. 
(Sorry Walter and Andrei, I haven't asked for your permissions. 
But you're the stars and public faces here :-), privacy for you 
is a past).


I think people would be interesting to know who you are, what 
have you done, what do you think about D and it's future, what 
are you interesting, etc. Maybe an interview is a better 
option, but I don't know how to do that here. Do you guys have 
any ideas?


For the second stuff, after I made the awesome-d list, the 
awesome-awesome list maintainer made a pull request to add mine 
to his list and connect. Then I found a list of awesome-c, 
awesome-clojure, and all other awesome lists:


https://github.com/bayandin/awesome-awesomeness

which is very interesting and a good way to find information.

So the similar idea came to me: Why don't try to build a 
network about D stuff? D libs are scattered even in github--you 
don't have a good way to search for the libs you're interested 
in.


Now we have code.dlang.org, but it is also a one way list. 
Ideally it would be two way: if a person bumped into one of the 
D projects, and in the project there is a link that says 
enlisted on code.dlang.org, then he can easily go to 
code.dlang.org and see what other interesting, related projects 
their are.
This is very similar to what for me on github does, it makes 
a network.


Of couse, what I want to have is also enlisted on awesome-d. 
Do you project maintainers think it's good?


One last request for help: You might noticed that I'm not a 
native english speaker, so there are many grammar or style 
problems in the awesome-d list, if you find any, please help me 
fix it.


Best Regards.

Puming

Re: Awesome-D, and an invitation to you awesome guys

[Puming via Digitalmars-d-announce]

On Sunday, 10 August 2014 at 10:01:58 UTC, NCrashed wrote:

On Sunday, 10 August 2014 at 09:28:48 UTC, Puming wrote:

Hi,

I'm maintaining this awesome-d list similar to other 
awesome-stuff lists on github, for keeping a hook on 
interesting D related links.


https://github.com/zhaopuming/awesome-d

At first it was only for my personal use, but recently I got 
some ideas about it that could potentially contribute to the 
community, so here I am making this little announcement and 
invating all you awesome guys to help me :-)


The ideas are:

1. Awesome-People list that made D awesome.
2. A relation network on github projects

First one is about the awesome people, that is you guys. I've 
been lurking in this forum for many years (dating back to D1 
days). But only recently, after watching the great dconf 
videos, have I realized that it is the awesome people that 
makes the language/ecosystem awesome. I want to know you. And 
I think the new comers of D would also like to know you, each 
one of you great guys who made a library/tool that make their 
programming life a better place.


For lack of information and for the respect of privacy, 
currently I have only listed Walter and Andrei on the list, 
https://github.com/zhaopuming/awesome-d#people. But I'd 
really like to know about other people here, like kenji the 
great bug killing machie always in the shadow, or bearophile 
who studied an endless list of languages and exploded 
bugzilla, and many other.


For privacy, I think it's best that only the descriptions 
provided by people themselves or really related people should 
be allowed, or at least a permission is acquired by the 
person. (Sorry Walter and Andrei, I haven't asked for your 
permissions. But you're the stars and public faces here :-), 
privacy for you is a past).


I think people would be interesting to know who you are, what 
have you done, what do you think about D and it's future, what 
are you interesting, etc. Maybe an interview is a better 
option, but I don't know how to do that here. Do you guys have 
any ideas?


For the second stuff, after I made the awesome-d list, the 
awesome-awesome list maintainer made a pull request to add 
mine to his list and connect. Then I found a list of 
awesome-c, awesome-clojure, and all other awesome lists:


https://github.com/bayandin/awesome-awesomeness

which is very interesting and a good way to find information.

So the similar idea came to me: Why don't try to build a 
network about D stuff? D libs are scattered even in 
github--you don't have a good way to search for the libs 
you're interested in.


Now we have code.dlang.org, but it is also a one way list. 
Ideally it would be two way: if a person bumped into one of 
the D projects, and in the project there is a link that says 
enlisted on code.dlang.org, then he can easily go to 
code.dlang.org and see what other interesting, related 
projects their are.
This is very similar to what for me on github does, it makes 
a network.


Of couse, what I want to have is also enlisted on awesome-d. 
Do you project maintainers think it's good?


One last request for help: You might noticed that I'm not a 
native english speaker, so there are many grammar or style 
problems in the awesome-d list, if you find any, please help 
me fix it.


Best Regards.

Puming


I like the idea to collect useful links, but more useful to 
collect all info on single portal. Integrate wiki, dlang, 
code.dlang.org, bugtracker, add some github integration via its 
api - dreams, the only dreams.


Wow, that is an interesting idea. And that page should be put on 
the first page of dlang.org :-)

Re: Are there desktop appications being developed in D currently?

[Puming via Digitalmars-d-learn]

On Sunday, 10 August 2014 at 05:34:49 UTC, thedeemon wrote:

On Sunday, 10 August 2014 at 04:41:45 UTC, Puming wrote:


Photo processing app:
Disk space visualizer and redundancy searcher:
A tool for watching some folders and processing video files 
there...



Interesting :-)

Unfortunately they are all windows only apps, I don't have a 
windows machine.


If you have Linux they work fine via Wine.


Can I link them on my bookmarks about D projects?
https://github.com/zhaopuming/awesome-d


I'm not in position to decide if they're awesome or not. :)
Not sure they fit into that list, but if you want to include a 
mention, I don't mind for sure.


added your organization to :

https://github.com/zhaopuming/awesome-d#organizations

Re: Are there desktop appications being developed in D currently?

[Puming via Digitalmars-d-learn]

Wow, it just happens that I checked your terminal.d code on the 
list an hour ago :-)


Definitely gonna look at it.

What do you mean by 'boring'? I think a shell in D would be 
awesome.



I'm planning to make a shell scripting lib in D, I would like it 
to be very powerful, but my coding skills was holding me back. 
Here is a list of what I want it to be:


1. multimode. I want it to combine shell and repl, I don't like 
that in the other repl you lose the ablility to call normal shell 
commands. So I think this shell could have a multiple mode just 
like what vi does: you change to a different mode by a key 
stroke. This will make it seemless to switch between repl mode 
and shell mode and other modes.


2. repl.

3. shell mode that interacts with repl. For example, the results 
of each shell command call will be stored in a repl variable for 
further repl computing.


4. remote mode. A config file sets up remote machines access, 
then we can call shell commands  repl commands as if on the 
remote machine, and even do them concurrently. It should also 
make resource/code syncing between machines easy(with rsync and 
lftp style of remote file management).


5. MVC style input/output. The out put of commands can be 
formated with a template (with color and indentations, even 
markdown support). traditional shell outputs are a mess.


6. bookmarks of every thing. Folders\Variables\routine 
commands\remote resources


7. autocomplete and auto style. write colorful code in the repl. 
Vi/emacs support of inline editing is also a plus.


8. dub support. You can create a project in the shell, and import 
dependencies interactly, and the dub.json will be updated as you 
type.


9. interactive coding  building. Interact with editors, and with 
dub and repl support, we can write code in a interactive way. You 
try some code in the repl and fit it into the project, no 
copy/pasting required.


All these combined will become a very complicated project, far 
beyond my ability. Currently I'm only doing item 4 and 5. (item 4 
was my initial requirement, we need a tool to manage shell 
scripts on multiple servers). I heard that someone was writing a 
repl, but forgot where it is, I'm waiting for it.


On Sunday, 10 August 2014 at 13:23:25 UTC, Adam D. Ruppe wrote:
I wrote a terminal emulator in D a while ago 
https://github.com/adamdruppe/terminal-emulator


terminal emulators are pretty boring as far as desktop 
applications go though. I have more on my to do list but 
haven't actually gotten to them yet.

Re: Are there desktop appications being developed in D currently?

[Puming via Digitalmars-d-learn]

Sorry for my misunderstanding.

After looking at your code I realized that your terminal emulator 
is a GUI application and I was responding about a shell :-)


Nonetheless, a terminal emulator is a very interesting tool.

On Sunday, 10 August 2014 at 13:25:32 UTC, Adam D. Ruppe wrote:
My thing works on Windows and Linux btw, though the windows 
version pipes to the plink program to talk to ssh. It'd be 
pretty easy to make it a stand alone thing though with a few 
tweaks, then it could be like an escape sequence handling 
library.

Re: Are there desktop appications being developed in D currently?

[Puming via Digitalmars-d-learn]

On Sunday, 10 August 2014 at 18:40:23 UTC, Adam D. Ruppe wrote:

On Sunday, 10 August 2014 at 14:28:33 UTC, Puming wrote:
What do you mean by 'boring'? I think a shell in D would be 
awesome.


tbh I think shells are a bit boring too, but like you said in 
the other message, they are two different things.


But a terminal emulator isn't much of a gui because all it 
displays is text (and mine actually can display pictures too) - 
no buttons, text areas, checkboxes, etc. like typically comes 
to mind when you think of a desktop gui app.


http://xiki.org/ provides a more GUI like terminal that has more 
gui widgets.


xcode's swift language playground also shows a more visiual way 
of doing repl.




I've been slowly writing a miniature gui widget library too, 
with the goal of zero dependencies and  300kb compiled 
executables... but I just haven't had the time. Whenever I need 
a quick gui for a personal project I've actually been 
outputting html or something and reading the response with my 
cgi.d. html forms cover like 95% of my use cases.


5. MVC style input/output. The out put of commands can be 
formated with a template (with color and indentations, even 
markdown support). traditional shell outputs are a mess.


I like what Windows Powershell does - it talks in objects which 
can be formatted to string or passed to other commands that 
understand them.


Wow, I didn't know about that. This is another thing that windows 
does better.




For a while, I was toying with doing that in D too. I don't 
remember where I put the file (a super-simplified version is in 
my book somewhere though)... but the shell commands were 
actually just D functions that return strongly typed stuff. 
When composing them, it calls the function directly and 
communicating with external commands  it does some simple 
toString serialization and deserialization so that works too.


But I haven't finished it in great part because I find regular 
old bash to work well enough for me.


7. autocomplete and auto style. write colorful code in the 
repl. Vi/emacs support of inline editing is also a plus.


gnu readline which bash uses allows the editing and 
autocomplete which is cool.


Thanks, I'll try that.

Re: Are there desktop appications being developed in D currently?

[Puming via Digitalmars-d-learn]

On Saturday, 9 August 2014 at 21:46:45 UTC, Peter Alexander wrote:

On Saturday, 9 August 2014 at 00:34:43 UTC, Puming wrote:
Yes, rust is a more infantile language compared to D, but 
people are already using them to create complicate 
applications like browser!


Rust was designed to build Servo. The people building Servo are 
the people building Rust. With all due respect to Rust, I don't 
think that counts as endorsement of the language.


I didn't know about that. I don't actually know much about Rust 
except the hype on hackernews :-)


But nonetheless, this indicates that a serious application like a 
browser is a good driving force for a language to evolve.

Re: Are there desktop appications being developed in D currently?

[Puming via Digitalmars-d-learn]

On Saturday, 9 August 2014 at 15:19:35 UTC, ketmar via 
Digitalmars-d-learn wrote:

On Sat, 09 Aug 2014 00:34:42 +
Puming via Digitalmars-d-learn 
digitalmars-d-learn@puremagic.com

wrote:

yes, there is. all of ours apps are done with D and GtkD now. 
alas,

it's in-house, but alot of people using them. ;-)


Can you give me some links? What platforms are they on?

Re: Are there desktop appications being developed in D currently?

[Puming via Digitalmars-d-learn]

Interesting :-)

Unfortunately they are all windows only apps, I don't have a 
windows machine.


Can I link them on my bookmarks about D projects?

https://github.com/zhaopuming/awesome-d


On Saturday, 9 August 2014 at 17:14:39 UTC, thedeemon wrote:

On Saturday, 9 August 2014 at 00:34:43 UTC, Puming wrote:
Yes, rust is a more infantile language compared to D, but 
people are already using them to create complicate 
applications like browser!


Heh, Rust was initially created exactly to create a browser. 
Servo project is its main driver and purpose.


I see the current hotspot of D are compilers、libs、http-server 
and game area, but haven't encountered an application project 
such as an editor, music player, etc.


We've got some.

Photo processing app:
http://www.infognition.com/blogsort/

Disk space visualizer and redundancy searcher:
http://www.infognition.com/undup/

A tool for watching some folders and processing video files 
there:

http://www.infognition.com/VideoEnhancer/autovideoenhance.html

And we're going to make the next major version of Video 
Enhancer itself in D too.


All the apps were made with DFL - D Forms Library, a nice 
equivalent of .NET's WinForms.

Are there desktop appications being developed in D currently?

[Puming via Digitalmars-d-learn]

Hi,

I bumped into a blog talking about building a (toy) browser 
engine in Rust:


(http://limpet.net/mbrubeck/2014/08/08/toy-layout-engine-1.html)

In the blog I found that the OP is in the mozilla servo team 
building a parallel browser for mozilla. The servo is hosted on 
github here:


(https://github.com/servo)

Yes, rust is a more infantile language compared to D, but people 
are already using them to create complicate applications like 
browser! This kind of projects would become a huge drive force to 
strengthen best practices in the language/lib design and attract 
newcomers.


When I learned about Clojure, and found that an editor/ide [Light 
Table](http://lighttable.com) was written entirely by 
Clojure(script), was really intrigged. [Atom](http://atom.io) is 
written in nodejs/coffeescript.


So I wonder, is there similar projects in D that I can take part, 
learn and enjoy?


I see the current hotspot of D are compilers、libs、http-server and 
game area, but haven't encountered an application project such as 
an editor, music player, etc.

Re: Are there desktop appications being developed in D currently?

[Puming via Digitalmars-d-learn]

On Saturday, 9 August 2014 at 01:26:05 UTC, ed wrote:

On Saturday, 9 August 2014 at 00:34:43 UTC, Puming wrote:

Hi,

I bumped into a blog talking about building a (toy) browser 
engine in Rust:


(http://limpet.net/mbrubeck/2014/08/08/toy-layout-engine-1.html)

In the blog I found that the OP is in the mozilla servo team 
building a parallel browser for mozilla. The servo is hosted 
on github here:


(https://github.com/servo)

Yes, rust is a more infantile language compared to D, but 
people are already using them to create complicate 
applications like browser! This kind of projects would become 
a huge drive force to strengthen best practices in the 
language/lib design and attract newcomers.


When I learned about Clojure, and found that an editor/ide 
[Light Table](http://lighttable.com) was written entirely by 
Clojure(script), was really intrigged. [Atom](http://atom.io) 
is written in nodejs/coffeescript.


So I wonder, is there similar projects in D that I can take 
part, learn and enjoy?


I see the current hotspot of D are compilers、libs、http-server 
and game area, but haven't encountered an application project 
such as an editor, music player, etc.


Manu started a project a while back which you may be interested 
in looking at.


http://forum.dlang.org/thread/mailman.470.1386845003.3242.digitalmar...@puremagic.com

https://github.com/FeedBackDevs/feedback


Cheers,
ed


Thanks, I could recall the discussion, but was not able to find 
it. Definitely gonna look at it :-)

Re: Behaviour of AAs after initialization

[Puming via Digitalmars-d]

On Thursday, 7 August 2014 at 16:53:24 UTC, H. S. Teoh via 
Digitalmars-d wrote:
On Thu, Aug 07, 2014 at 11:46:48AM +, via Digitalmars-d 
wrote:
AAs are (like regular dynamic arrays) initialized to `null`. 
On first
modification (i.e. assignment of an element), memory is 
allocated and

the AA variable updated to point at it.

However, is there a guarantee that AAs are never reallocated 
once they
are initialized, i.e. is it then safe to assume that changes 
made
through a copy of an AA variable (e.g. pass by value) are 
visible

through the original variable?

The current implementation behaves like this, but the language
reference does not mention it, AFAICS. I'd like to amend the
documentation if this behaviour is reliable.

[...]

I'm not the one to make the decision, but I'd vote for 
codifying this
behaviour in the language reference. From what I understand, at 
least,

it seems that this is the intention anyway, and the current
implementation certainly suggests so. Otherwise, it leads to 
strange
awkward semantics where passing AA's around may sometimes 
change the

original view of it, and sometimes not.

It's really just the .init value of null which causes odd 
behaviour with

empty AA's. Fun fact:

void changeAA(int[string] aa) {
aa[a] = 123;
}

// Null AA:
int[string] aa1; // null

assert(aa1.length == 0);
changeAA(aa1);  // no effect

for most of the new users the WAT part is actually here :-)

In all other occations AA behaves just like a reference type: You 
want to changeAA with assignment and you get an empty(null) AA, 
you should be able to change it.


refering to an null AA and not wanting to modify it is not a 
common case.


So I'd like to suggest a rule here similar to what assignment 
does to null AA:


If someone refers to an uninitialized null AA ( in 
implementation, that maybe, a copy of a null AA struct happens), 
allocate it first.



assert(aa1.length == 0);

// Empty but non-null AA:
int[string] aa2; // null
aa2[a] = 0;
aa2.remove(a); // empty but non-null

assert(aa2.length == 0);
changeAA(aa2);  // has effect!
assert(aa2.length == 1); // WAT :-)


T

Re: Behaviour of AAs after initialization

[Puming via Digitalmars-d]

On Thursday, 7 August 2014 at 18:05:15 UTC, H. S. Teoh via 
Digitalmars-d wrote:
On Thu, Aug 07, 2014 at 05:42:28PM +, via Digitalmars-d 
wrote:

On Thursday, 7 August 2014 at 17:35:46 UTC, Puming wrote:
So I'd like to suggest a rule here similar to what assignment 
does to

null AA:

If someone refers to an uninitialized null AA ( in 
implementation,
that maybe, a copy of a null AA struct happens), allocate it 
first.


I'm afraid that copying is too general. This would trigger on 
just
about any access. It would also make copying AAs more 
expensive. I
believe a standardized method for initializing an AA is more 
likely to

be accepted.


It really just needs a standard function in druntime that does 
this.

Perhaps something like this:

// in object.di
T initialize(T : V[K], V, K)(T aa = null) {
aa[K.init] = V.init;
aa.remove(K.init);
// or if you like, encapsulate this in aaA.d and just
// allocate Impl without the add/delete hackery.

return aa;
}

// in user code
auto aa = initialize!(string[int]);

The name / syntax is up for bikeshedding, but the idea is 
pretty simple.
Make a druntime function that allocates the initial empty AA, 
and make

that function accessible to user code.


T


That is what I'm using now...
But the implementation (assignement plus remove) would look weird.

People were asking for

```
string[int] aa = [];
// or
string[int] aa = [:];
```

is it hard to implement, or confict with other language features?

But if we have a initialize mechanism, it would be better to 
deprecate the 'silent allocate on first assignment', because 
people would easily forgot to init the aa, and then refer to it, 
and the compiler being silent on this, only finding that the 
original one is not affected later, contrary to their intentions.


If we want: You must initialize an AA before refering to it, 
the compiler should enforce that.

Re: Behaviour of AAs after initialization

[Puming via Digitalmars-d]

On Thursday, 7 August 2014 at 17:42:29 UTC, Marc Schütz wrote:

On Thursday, 7 August 2014 at 17:35:46 UTC, Puming wrote:
So I'd like to suggest a rule here similar to what assignment 
does to null AA:


If someone refers to an uninitialized null AA ( in 
implementation, that maybe, a copy of a null AA struct 
happens), allocate it first.


I'm afraid that copying is too general. This would trigger on 
just about any access.


I don't know the details, I was thinking that copy only happens 
when an assignment (`auto aa2 = aa1;`) happens :-(



It would also make copying AAs more expensive.


all writes to AA already do the same check, right? but if you 
mean all reads will also incur copying, then I agree it would be 
more expensive.


I believe a standardized method for initializing an AA is more 
likely to be accepted.

Re: Member access of __gshared global object

[Puming via Digitalmars-d-learn]

Indeed it's confusing.

So AA is a value type that behaves like a pointer/reference.

We can add a rule to the initialization to make AA behave more 
like reference types:


If someone `refer` to an unitialized AA, that is, by doing:

```d
string[string] aa;

string[string] bb = aa; // bb `refers` to aa, by actually copying 
the AA struct.

```

They must want to use bb the same as aa, and it mostly will be 
followed by an assignment to bb (otherwise why bother refering 
it?). So we can initialize the AA BEFORE copying the struct, 
similar to the process before assigning an unitialized AA.


Actually, I think ANY structs that mimics a reference behavior 
should add this rule to really look like a reference.



On Thursday, 7 August 2014 at 02:17:19 UTC, H. S. Teoh via 
Digitalmars-d-learn wrote:
On Thu, Aug 07, 2014 at 02:00:27AM +, Puming via 
Digitalmars-d-learn wrote:

On Wednesday, 6 August 2014 at 15:42:05 UTC, Marc Schütz wrote:

[...]

Indeed, it was just what the OP suspected as the culprit.

You are right, I didn't know about the AA initialization 
problem then.


When I writln the AA and it outputs '[]', I thought it was
initialized, which in that case was actually null.

[...]

This is a known gotcha with AA's and built-in arrays: they are 
null
until you insert something into them, which means that while 
they are
null, passing them into functions that add stuff to them won't 
update
the original references because there is no common object that 
null
points to. But once they become non-empty, passing them around 
to
functions that change their contents will affect what's seen 
through the
original references, since now they are pointing at a common 
object in

memory.  So they behave like value types when null, but acquire
reference semantics once they are non-empty. This can be rather
confusing for newbies.


T

Re: Member access of __gshared global object

[Puming via Digitalmars-d-learn]

Yes indeed, null initial value is reasonable. My suggestion does 
not affect that rationale, but is only based on my observation 
that if someone want to `refer` to an AA, he is more likely to 
fill it very soon, and he really mean to refer to it. These are 
similar concerns:


- create a null AA, then fill it, and the compiler/runtime will 
automatically initialize it before the fill.


- create a null AA, then refer to it (and would then use it), and 
the compiler/runtime wil automatically initialize it before the 
refer.



On Thursday, 7 August 2014 at 11:05:33 UTC, Kagamin wrote:
It's an optimization of memory allocation: you can always have 
a usable AA without allocating anything for it, so when you 
fill it with data, you may want to assign it back to where it 
should stay, similar to a slice.

AA initialization

[Puming via Digitalmars-d-learn]

I found AA initialization have a strange effect:

```d
	string[string] map; // same as `string[string] map = 
string[string].init;

writeln(map); // output: []

string[string] refer = map; // make a reference
refer[1] = 2; // update the reference
	writeln(map); // output: []. The reference does not affect the 
original.

```

But if I do an assignment first, the reference works:


```d
	string[string] map; // same as `string[string] map = 
string[string].init;

writeln(map); // output: []

map[1] = 0;

string[string] refer = map; // make a reference
refer[1] = 2; // update the reference
writeln(map); // output: [1:2]. The reference does affect.
```

So if I want an empty AA and want to use a variable to refer to 
it later, I have to do this:


```d
	string[string] map; // same as `string[string] map = 
string[string].init;


map[1] = 0;
map.remove(1); // assign and then REMOVE!
writeln(map); // output: []

string[string] refer = map; // make a reference
refer[1] = 2; // update the reference
writeln(map); // output: [1:2]. The reference does affect.
```

which looks awkward.

Is it because `string[string].init == null` ? If so, how do I 
specify an empty AA which is not null? Neither `[]` or `[:]` 
seems to work.

Re: AA initialization

[Puming via Digitalmars-d-learn]

On Wednesday, 6 August 2014 at 14:38:34 UTC, Marc Schütz wrote:

On Wednesday, 6 August 2014 at 13:15:27 UTC, Kozzi11 wrote:
AFAIK there is no easy way to do it. Maybe it would be fine to 
add some function to phobos. Something like this:



auto initAA(VT,KT)() {

static struct Entry
{
Entry *next;
size_t hash;
}

static struct Impl
{
Entry*[] buckets;
size_t nodes;
TypeInfo _keyti;
Entry*[4] binit;

		@property const(TypeInfo) keyti() const @safe pure nothrow 
@nogc

{ return _keyti; }
}

static struct AA
{
Impl* impl;
}

VT[KT] aaa;
AA* aa = cast(AA*)aaa;
if (aa.impl is null)
{   aa.impl = new Impl();
aa.impl.buckets = aa.impl.binit[];
}
aa.impl._keyti = cast() typeid(aaa);
return aaa;
}


Or it would be fine if I could write something like this: auto 
aa = new VT[KT]();


`string[string] aa = [];` would be fine, too, but it currently 
doesn't compile.


Thanks for your clarification (and also in the other thread), so 
this is an implementation issue for builtin AAs.

Re: Member access of __gshared global object

[Puming via Digitalmars-d-learn]

On Wednesday, 6 August 2014 at 15:42:05 UTC, Marc Schütz wrote:

On Wednesday, 6 August 2014 at 15:18:15 UTC, Dragos Carp wrote:

On Wednesday, 6 August 2014 at 14:36:23 UTC, Marc Schütz wrote:


This would defeat the purpose, see the original post.


sorry, I red just the last post.

__gshared has no influence on this.


Indeed, it was just what the OP suspected as the culprit.


You are right, I didn't know about the AA initialization problem 
then.


When I writln the AA and it outputs '[]', I thought it was 
initialized, which in that case was actually null.








auto cmds = CONFIG.commands;
cmds[list] = new Command(...);


cmds is a thread local variable referencing the shared AA. But 
if you add new elements to cmds, cmd will be reallocated and 
the shared AA will remain unchanged. Though, updated values of 
existing keys will be visible in the original, because no 
relocation takes place.


This describes the semantics of regular arrays. Are you sure it 
also applies to AAs? I thought they will keep referring to the 
same data once they are initialized. But I might be mistaken...




If you want to change the original you need a pointer or a 
reference (for a setter function).


auto cmds = CONFIG.commands;
(*cmds)[list] = new Command(...);

Re: Member access of __gshared global object

[Puming via Digitalmars-d-learn]

On Thursday, 31 July 2014 at 10:22:28 UTC, Marc Schütz wrote:

On Thursday, 31 July 2014 at 02:03:37 UTC, Puming wrote:
1. Are AAs reference type? if so, why does the compiler copy 
it?


This is probably your problem. They are reference types, but 
initially that reference is `null`. When you write:


auto cmds = CONFIG.commands;

`cmds` contains a copy of the `null` value. On assignment, the 
actual AA is created, and assigned to `cmds`, but not back to 
`CONFIG.commands`. Try initializing the AA in your class 
constructor.


I checked the code and could concur your suggestion.

What I found strange were:

1. The only way that I can initialize it is to assign a value. 
But I want to initialize an empty AA, is that possible?


2. CONFIG.commands is not `null` before initialized, it is 
'[]'(when I writeln it). But it still behave like what you 
described (except that it won't produce an NullPointer Exception.

Re: HTP Handler

[Puming via Digitalmars-d-learn]

See this list:

https://github.com/zhaopuming/awesome-d#web-frameworks



On Wednesday, 6 August 2014 at 04:10:28 UTC, HUSSAIN wrote:

Hi ,

I am new to D, I would like to build HTTP Server in D. Can any 
one throw some light on what are all the libraries available in 
D and if there is any example it would be helpful.


Thanks
Hussain

Member access of __gshared global object

[Puming via Digitalmars-d-learn]

Hi,

I'm writing this global Config class, with an AA member:

```d
module my.config;

class Config
{
Command[string] commands;
}

__gshared Config CONFIG;
```

and initialize it in another module:

```d
module my.app;

import my.config;

void main()
{
  CONFIG = new Config();
  CONFIG.commands[bye] = new Command(...); // add commands
}
```

This is OK. But when I use a local variable to hold the commands 
AA:


```
auto cmds = CONFIG.commands;
cmds[list] = new Command(...);
```

The command list is not added.

I guess what happened here was that `cmds` is a threadlocal 
variable, so the compiler somehow copied the CONFIG.commands.


My questions are:

1. Are AAs reference type? if so, why does the compiler copy it?
2. How do I reference a member of __gshared global objects?

Re: fork/waitpid and std.concurrency.spawn

[Puming via Digitalmars-d-learn]

OK， I see your point. I didn't know much about windows, so didn't 
know that fork in windows was so different from posix. This looks 
reasonable.


What I really want is a actor modal similar to std.concurrency, 
with a similar API and spawn/send/replay semantics, but using 
processes instead of threads.


Actually, generalize this further to fibers and cross machine 
process, it would be a full blown actor system just like Akka.



On Tuesday, 22 July 2014 at 16:11:31 UTC, FreeSlave wrote:

On Tuesday, 22 July 2014 at 14:26:05 UTC, Puming wrote:
I've only found spawnProcess/spawnShell and the like, which 
executes a new command, but not a function pointer, like 
fork() and std.concurrency.spawn does.


What is the function that does what I describe?

On Tuesday, 22 July 2014 at 10:43:58 UTC, FreeSlave wrote:

On Tuesday, 22 July 2014 at 07:58:50 UTC, Puming wrote:
Is there a fork()/wait() API similar to std.concurrency 
spawn()?


The best thing I've got so far is module 
core.sys.posix.unistd.fork(), but it seems to only work in 
posix. Is there a unified API for process level concurrency? 
ideally with actor and send message support too.


You need std.process.


I'm not sure what you're trying to do. Posix fork does not just 
spawn function, it spawns new process as copy of its parent and 
continue execution from the point where fork returns.
Windows creates processes in some different way, and it seems 
there is no function with same functionality as Posix fork in 
WinAPI (by the way you can try to find some implementations on 
the Internet / use Cygwin / try to use Microsoft Posix 
Subsystem).
I think the reason why phobos does not have functionality you 
want is that standard library should be platform-agnostic. So 
instead of emulating things which are not supported by some 
platform, it just truncates them.

Re: fork/waitpid and std.concurrency.spawn

[Puming via Digitalmars-d-learn]

OK, I understand your point :-)


On Wednesday, 23 July 2014 at 09:05:49 UTC, FreeSlave wrote:
Seems like you need inter process communication. There are many 
ways to make one. For example, through sockets. You may use D 
bindings to ZMQ or other library, or just use std.socket.
Anyway the process will be represented by the whole program, 
not just one function as in case of thread.

Re: fork/waitpid and std.concurrency.spawn

[Puming via Digitalmars-d-learn]

I've only found spawnProcess/spawnShell and the like, which 
executes a new command, but not a function pointer, like fork() 
and std.concurrency.spawn does.


What is the function that does what I describe?

On Tuesday, 22 July 2014 at 10:43:58 UTC, FreeSlave wrote:

On Tuesday, 22 July 2014 at 07:58:50 UTC, Puming wrote:
Is there a fork()/wait() API similar to std.concurrency 
spawn()?


The best thing I've got so far is module 
core.sys.posix.unistd.fork(), but it seems to only work in 
posix. Is there a unified API for process level concurrency? 
ideally with actor and send message support too.


You need std.process.

Re: DConf 2014: Adam D Ruppe's amazing slideless talk on x86 Bare Metal and Custom Runtime Programming

[Puming via Digitalmars-d-announce]

I've added an indirect link to my awesome-d github page where 
your book is listed:


https://github.com/zhaopuming/awesome-d#books

But don't know whether that would be filtered also.


On Thursday, 17 July 2014 at 19:29:44 UTC, Adam D. Ruppe wrote:

On Thursday, 17 July 2014 at 18:48:11 UTC, deadalnix wrote:
You may have been shadow banned. You should contact some 
reddit admins.


It doesn't seem to be my account itself, just that link. 
Someone else says they tried posting it too but I can't see it, 
I think reddit just doesn't like the link.

Re: Continuous integration testing with travis and drone

[Puming via Digitalmars-d]

On Wednesday, 16 July 2014 at 04:11:28 UTC, Kapps wrote:
On Wednesday, 16 July 2014 at 03:31:13 UTC, Pavel Evstigneev 
wrote:

May I improve forum to support markdown?


The forum is actually an interface to a newsgroup, so most 
forms of markdown would not be supported in the interest of 
having a consistent UI for people who use mail / newsgroup 
clients vs people who use the online web interface.


Yes, but if used cautiously, [markdown][1] will not hinder the 
*readability* as a **plain text**.


especially when there are code blocks:

```d
void main()
{
   writeln(Please colorize me with Javascript if this message is 
sent to web interface.);

}
```


[1]: http://daringfireball.net/projects/markdown/

Re: How can I express the type '(int) = int' where it is a function or a delegate

[Puming via Digitalmars-d-learn]

On Wednesday, 16 July 2014 at 04:10:13 UTC, Rikki Cattermole 
wrote:

On 16/07/2014 3:50 p.m., Puming wrote:
I'd like to have a Command class, where their is a name and a 
handler

field:

```d
class Command
{
  string name;
  string delegate(string[]) handler;
}
```

this is ok, but sometimes I want the handler also accept a 
function
(lambdas are init to functions if no capture of outer scope 
variables

are present), but it can't.

So I'd like to generalize the Command to a template, the best 
I've got

sofar:

```d

alias string delegate(string[]) HandlerDele;
alias string function(string[]) HandlerFunc;

class Command(T) if (is (T HandlerDele) || is (T HandlerFunc))
{
immutable {
string name;
T handler;
}

this(string name, T handler)
{
this.name = name;
this.handler = handler;
}

}

void main()
{

HandlerFunc f = xs = xs[0]; // just a test
auto cmd = new Command!HandlerFunc(echo, f);
}
```

I've got several questions about this:

1. I cant ignore `HandlerFunc` when initiating cmd:

```d
auto cmd = new Command(echo, f); // Error: class
dshell.command.Command(T) if (is(T HandlerDele) || is(T 
HandlerFunc)) is

used as a type
```

Can DMD automatically infer the type here?

2. Is this the right way to do this?

3. I'd like a unified description of `a function pointer or a 
delegate`,
and from the experience of lambda, it seems the syntax of 
lamdba is

really useful here, if we have that, then instead of:

```d
void execute(T)(Context cxt, T handler) if (is (T HandlerFunc) 
|| is (T

HandlerDele))
{
  //...
}

we could define a function that accepts a function/delegate 
like this:


```d

void execute(T : string[] = string)(Context cxt, T handler)
{
  //...
}

// in main
ctx.execute(xs = xs[0]);


Or using std.functional toDelegate you could convert the 
function into a delegate.


class Command {
string name;
string delegate(string[]) handler;

this(string name, string delegate(string[]) handler) {
this.name = name;
this.handler = handler;
}

this(string name, string function(string[]) handler) {
import std.functional : toDelegate;
this.name = name;
this.handler = toDelegate(handler);
}
}

Just keep in mind, you can't go the opposite way.


Thanks. I wonder if functions could implicitly convert to 
delegates...but toDelegate is OK.



Also, after another dig into the language docs, I found:


The .ptr property of a delegate will return the frame pointer 
value as a void*.


The .funcptr property of a delegate will return the function 
pointer value as a function type.


Future directions: Function pointers and delegates may merge 
into a common syntax and be interchangeable with each other.


Wonder how that would happen.

lazy construction of an immutable object

[Puming via Digitalmars-d-learn]

Hi,

I'd like to use immutable data, but instead of a one time 
constructor, I would like to `build` the data lazily, by setting 
its fields separately.


In java version of protocol-buffer, there is a pattern for this 
mechanism:


1. Every data class in protobuf is immutable.
2. Each data class is companioned by a Builder class, with the 
same field of the immutable data class.
3. To create a data object, first create a Builder, then set the 
fields when ever you want.


I want to emulate this process, but without needing to create two 
classes for one data class (protobuff does this by a separate 
code generating phase to generate both classes from a data format 
file).


What is the idiomatic approach to do this in D?

if I define a class with immutable fields, like

```d
class A {
  immutable int id;
  immutable B b;
}
```

should I use a template to generate the companion Builder class, 
or is there another aproach?

Re: lazy construction of an immutable object

[Puming via Digitalmars-d-learn]

I found another way to do this, namely first create a class that 
is mutable, then cast it to an immutable object before using it.


```d

class A {
int a;
B b;
this(int a, int b)
{
this.a = a;
this.b = new B(b);
}
}


class B {
int b;
this(int b)
{
this.b = b;
}
}

@property immutable(T) freeze(T)(T obj)
{
return cast(immutable(T))(obj);
}

void main()
{

immutable c = new A(3, 4).freeze;
	c.b.b = 5; // Error: can only initialize const member b inside 
constructor

writeln(c.b.b)
}
```

But the draw back is that you can't garanteed that the mutable 
object is never used.



On Tuesday, 15 July 2014 at 10:39:42 UTC, Puming wrote:

Hi,

I'd like to use immutable data, but instead of a one time 
constructor, I would like to `build` the data lazily, by 
setting its fields separately.


In java version of protocol-buffer, there is a pattern for this 
mechanism:


1. Every data class in protobuf is immutable.
2. Each data class is companioned by a Builder class, with the 
same field of the immutable data class.
3. To create a data object, first create a Builder, then set 
the fields when ever you want.


I want to emulate this process, but without needing to create 
two classes for one data class (protobuff does this by a 
separate code generating phase to generate both classes from a 
data format file).


What is the idiomatic approach to do this in D?

if I define a class with immutable fields, like

```d
class A {
  immutable int id;
  immutable B b;
}
```

should I use a template to generate the companion Builder 
class, or is there another aproach?

Re: lazy construction of an immutable object

[Puming via Digitalmars-d-learn]

On Tuesday, 15 July 2014 at 13:59:24 UTC, Ali Çehreli wrote:

On 07/15/2014 05:20 AM, Puming wrote:
I found another way to do this, namely first create a class 
that is

mutable, then cast it to an immutable object before using it.

```d

class A {
int a;
B b;
this(int a, int b)
{
this.a = a;
this.b = new B(b);
}
}


class B {
int b;
this(int b)
{
this.b = b;
}
}

@property immutable(T) freeze(T)(T obj)
{
return cast(immutable(T))(obj);
}

void main()
{

immutable c = new A(3, 4).freeze;
c.b.b = 5; // Error: can only initialize const member b 
inside

constructor
writeln(c.b.b)
}
```

But the draw back is that you can't garanteed that the mutable 
object is

never used.


Also consider: A pure function's return value can implicitly be 
converted to immutable.


class A
{
int x;
int y;

this (int x) pure
{
this. x = x;
}
}

pure A makeA(int x)// -- returns mutable
{
auto a = new A(x);

// ...
// Set a member later on:
a.y = 42;

return a;
}

void main()
{
immutable imm = makeA(1);// -- works
}

Ali


wow, that's interesting :-) Is it the idiomatic approach to 
initiate immutable objects lazily? Or do people use data class 
with immutable fields and generate a companion builder class at 
compile time?

Re: lazy construction of an immutable object

[Puming via Digitalmars-d-learn]

On Tuesday, 15 July 2014 at 17:09:04 UTC, Meta wrote:

On Tuesday, 15 July 2014 at 15:48:10 UTC, Puming wrote:
wow, that's interesting :-) Is it the idiomatic approach to 
initiate immutable objects lazily? Or do people use data class 
with immutable fields and generate a companion builder class 
at compile time?


There's no real idiomatic approach, I think, because this is 
somewhat unexplored territory. I'd say constructing the object 
inside a pure method so it can be implicitly cast to immutable 
is more typesafe, but if you're storing the immutable reference 
to the object in a class or struct, it can only be initialized 
in that class's/struct's constructor. So the following isn't 
possible:


struct Test
{
immutable(int*) n;

private int* getPtr() pure
{
int* n = new int;
*n = 42;

return n;
}

public void initialize() pure
{
n = getPtr();
}
}

void main()
{
auto t = new Test();
test.initialize();
}


So this means that the pure method approach should also be 
transitive: the containing class should also be mutable (having 
the desired immutable object as a mutable field) and later freeze 
itself.


If there is a complex hierarchy of objects, there are three 
strategies:


1. define all classes and fields mutable, and use immutable value 
in the business logic code. This would work, but lose the 
compilers help with checking immutability in all conditions. For 
example, you coud modify the mutable reference if it is leaked.
2. define all classes and fields immutable, and only use 
constructor to eagerly create objects and there fields. This is 
the most strict, but will incur some inconvenience in 
asynchronous environments, where not all parts of the data is 
available at start.
3. define all classes and use template magic to generate 
companion builders just like protobuffer does. But that would be 
complicated and I don't know how to do it. Do you have any 
suggestion for this approach?