Re: execute bash?
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?
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?
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?
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?
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?
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?
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?
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
Re: execute bash?
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?
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?
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?
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?
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
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?
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?
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?
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?
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?
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?
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?
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
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?
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
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
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: infer type argument in classe constructor?
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?
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
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
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: What is the best declaration type for a string like parameter?
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?
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?
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.
Multiple range enumeration
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
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: sdlang-d can not link after updating to dmd 2.066
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
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).
Re: Are there desktop appications being developed in D currently?
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?
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?
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?
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?
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?
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?
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?
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?
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: Member access of __gshared global object
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
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
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
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
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
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
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
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
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
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
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: How can I express the type '(int) = int' where it is a function or a delegate
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
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
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
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
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?
How can I express the type '(int) = int' where it is a function or a delegate
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]);
Re: new properties for basic types
On Monday, 14 July 2014 at 10:28:30 UTC, Dominikus Dittes Scherkl
wrote:
Is it possible to write custom properties for basic types, so
that I can write e.g. int.myProp instead of myProp!int()
[analogue to x.myProp instead of myProp(x)]?
yes, just define a funciton with the first parameter int:
```d
@property int triple(int x)
{
return x * 3;
}
void main()
{
int x = 4;
assert(12 == x.triple);
}
```
Re: spawn and wait
On Thursday, 3 July 2014 at 04:51:07 UTC, Ali Çehreli wrote:
On 07/02/2014 08:29 PM, Puming wrote:
I want to spawn several similar tasks and then wait for all
of them to
complete to go on do some other things
If you don't care about account for each of them individually,
core.thread.thread_joinAll would work. The following program
starts two waves of threads and waits for both of the waves to
complete:
import std.stdio;
import std.concurrency;
import core.thread;
void foo(Duration duration)
{
writefln(Working for %s, duration);
Thread.sleep(duration);
}
void spawnThreads(size_t count)
{
foreach (i; 0 .. count) {
spawn(foo, (i + 1).seconds);
}
writefln(Started %s workers, count);
}
void main()
{
spawnThreads(2);
writefln(Waiting for all to finish);
thread_joinAll();
spawnThreads(3);
writefln(Waiting for all to finish);
thread_joinAll();
}
Ali
Thanks that is what I'm looking for
spawn and wait
Hi,
I want to spawn several similar tasks and then wait for all of
them to complete to go on do some other things, like:
```d
void task(int id)
{
// do the stuff
}
void main()
{
foreach (i; 0..10) {
spawn(task, i);
}
wait(?); // wait for all task to complete
doSomeOtherThings();
}
```
But I don't see a `wait` method for Tid, similar to Pid in
std.process.
What is the idiomatic way to do these things?
My current workaround is using messages:
```d
#!/usr/bin/rdmd
import std.stdio;
import std.concurrency;
void child(int id)
{
writeln(Starting child: , id);
ownerTid.send(id);
}
void main()
{
foreach (i; 0..10)
{
spawn(child, i);
}
for (int n = 0; n 10; ++n) {
receive((int i) {
writeln(Received:, i);
});
}
}
```
But it is verbose and seems error prone.
Re: struct, ref in, and UFCS
On Tuesday, 1 July 2014 at 07:53:27 UTC, bearophile wrote: Puming: is this a good practice to use `ref in` with structs instead of traditional pointer syntax (which does not play well with UFCS though) ? Is there any perfomance implications with `ref in`? I tried that it does not seem to copy the parameter value, A ref is equivalent to a pointer that can't be null, so performance is the same as using a pointer (so it's good for larger structs, but not good if your struct is tiny). Bye, bearophile Thanks for the clarification. Now I can safely assume ref is better than pointer here because it plays nicely with UFCS.
Re: struct, ref in, and UFCS
On Tuesday, 1 July 2014 at 13:53:12 UTC, Ali Çehreli wrote:
On 07/01/2014 03:21 AM, Puming wrote:
I can safely assume ref is better than pointer here
I agree.
because it plays nicely with UFCS.
I don't understand that part. :) The following is the same
program with just two differences: prompt() takes a pointer and
'server' is a pointer.
import std.conv;
struct Server
{
string name;
string ip;
int port;
string user;
}
string prompt(Server * server)
{
return server.user ~ @ ~ server.ip ~ : ~
server.port.to!string;
}
void main()
{
auto server = new Server(bzzt, 192.168.0.1, 80,
nobody);
string p = server.prompt;
}
Ali
Wow, I've tested with some other code and pointer did not work,
maybe I got something else wrong. Anyway, it's nice to know
pointers also works with UFCS :-)
struct, ref in, and UFCS
Hi,
I have a struct and want to extends its methods, like:
```d
struct Server
{
string name;
string ip;
int port;
string user;
}
```
extension method here:
```d
string prompt(ref in Server server)
{
return server.user ~ @ ~ server.ip ~ : ~ server.port;
}
```
and call it with UFSC:
```d
string p = server.prompt;
```
is this the correct way to use struct and UFCS? it does not seem
to copy there.
Re: struct, ref in, and UFCS
On Tuesday, 1 July 2014 at 05:09:49 UTC, Puming wrote:
Hi,
I have a struct and want to extends its methods, like:
```d
struct Server
{
string name;
string ip;
int port;
string user;
}
```
extension method here:
```d
string prompt(ref in Server server)
{
return server.user ~ @ ~ server.ip ~ : ~ server.port;
}
```
should be `server.port.to!int`;
and call it with UFSC:
```d
string p = server.prompt;
```
is this the correct way to use struct and UFCS? it does not
seem to copy there.
Re: struct, ref in, and UFCS
On Tuesday, 1 July 2014 at 05:26:47 UTC, Ali Çehreli wrote:
On 06/30/2014 10:11 PM, Puming wrote:
On Tuesday, 1 July 2014 at 05:09:49 UTC, Puming wrote:
Hi,
I have a struct and want to extends its methods, like:
```d
struct Server
{
string name;
string ip;
int port;
string user;
}
```
extension method here:
```d
string prompt(ref in Server server)
{
return server.user ~ @ ~ server.ip ~ : ~ server.port;
}
```
should be `server.port.to!int`;
I think it should actually be server.port.to!string;
is this the correct way to use struct and UFCS? it does not
seem to
copy there.
I don't understand your question but I wanted to help others by
making complete code from your messages:
import std.conv;
struct Server
{
string name;
string ip;
int port;
string user;
}
string prompt(ref in Server server)
{
return server.user ~ @ ~ server.ip ~ : ~
server.port.to!string;
}
void main()
{
auto server = Server(bzzt, 192.168.0.1, 80, nobody);
string p = server.prompt;
}
Ali
Thanks, This code works and my question is that is this a good
practice to use `ref in` with structs instead of traditional
pointer syntax (which does not play well with UFCS though) ? Is
there any perfomance implications with `ref in`? I tried that it
does not seem to copy the parameter value, which is good for me:
```d
#!/usr/bin/rdmd
import std.stdio;
struct Server
{
string name;
}
string prompt(ref in Server server)
{
__server.name = new name;
return server.name ~ ;
}
Server __server;
void main()
{
__server.name = old_name;
writeln(__server.prompt);
}
```
which prints
```
newname
```
meaning the `return server.name ~ ` code in promt is using a
reference of __server instead of copying the value.
Re: import except one?
On Sunday, 29 June 2014 at 07:28:12 UTC, Kapps wrote: A bit late, but you should also be able to do: import scriptlike; alias Config = std.process.Config; Thanks, so an alias or an additional single symbol import will shadow the earlier imported symbol. That's fine for me :-)
import except one?
Hi, I'm using scriptlike, which imports everything from std.process for convienience, but I also need to import another module, which contains a class `Config`, it conflicts with std.process.Config. I don't actually need std.process.Config, but I need many other symbols in scriptlike and std.process. What I want to achieve is to import ALL symbols from scriptlike EXCEPT std.process.Config, something like: ```d import scriptlike: !Config; ``` or rename it AND import all other symbols, to resolve the confliction. ```d import scriptlike: *, Cfg = Config; ``` I don't know how to achieve these effects, selective import and rename seems to only import the one I specified.
Re: import except one?
On Thursday, 26 June 2014 at 16:02:15 UTC, sigod wrote: Dirty solution: ``` import scriptlike; import your_module; import your_module : Config; ``` So, `Config` from your module will override one from scriptlike. I'm currenly renaming my own symbol: ```d import scriptlike; import config : Cfg = Config; ``` Your solution works for me :-) Thanks
Re: import except one?
On Thursday, 26 June 2014 at 08:02:24 UTC, bearophile wrote: Puming: I'm using scriptlike, which imports everything from std.process for convienience, but I also need to import another module, which contains a class `Config`, it conflicts with std.process.Config. I don't actually need std.process.Config, but I need many other symbols in scriptlike and std.process. What I want to achieve is to import ALL symbols from scriptlike EXCEPT std.process.Config, something like: ```d import scriptlike: !Config; A similar idea is present in Haskell, but it was refused by Walter. Thanks :-) I wander what was the rationale behind Walter's rejection. IMHO if we have a selective filter mechanism for imports, the complement exclude mechinism works as well. But of cause we are not that far yet, final, nothrow, pure and others don't have their complements either. The use of scriptlike is going to cause you similar problems, it's not for a fine tuning of imports. The problem is that we don't have a complete mechanism to fine tuning the imports. Selective filtering is only half of the cake. Bye, bearophile
